Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Cliente. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Cliente. Mostrar todas las entradas

domingo, mayo 28, 2023

Inspirado: como crear productos de tecnología que tus clientes amen

Esta es la presentación de mi charla en el Lean Agile Summit, en Medellín este 27 de mayo de 2023. En ella brindé información sobre las prácticas y, sobre todo, los principios del enfoque exitoso de productos en empresas de tecnología y en otras con las que he trabajado a lo largo de mis 35 años de carrera profesional.

En particular, hablé de las Las causas fundamentales de los esfuerzos fallidos de producto, cómo nos pueden ayudar los enfoques Lean y Ágil en este proceso de Las 4D, descubrir, diseñar, desarrollar y distribuir productos que resuelvan la paradoja de las compañías que quieren tener éxito en el mundo convulsionado de hoy: quieren que sus clientes amen sus productos, pero no sabrán si esto es posible hasta tanto no pongan esos productos en manos de ellos.

También hablé de los principios de Lean Product Discovery y entrega frecuente y de mi tema favorito: personas. Detrás de cada gran producto hay una gran persona y, por extrapolación, un gran equipo. Principios de equipos de producto sólidos, sobre el líder de producto y el papel del liderazgo y, finalmente sobre la cultura sólida de producto que tienen las organizaciones brillantes. Por supuesto, fue tiempo para hablar de las Organizaciones B (Brillantes) y la triple restricción: estas son las empresas que no solo buscan el necesario y “sine qua non” beneficio financiero, sino también el beneficio social y ambiental. No podemos tener empresas sanas y, por consiguiente, productos sanos, en un planeta enfermo. Perentorio.

Al final, de mi libro Cultura ágil: ese oscuro objeto del deseo, mis tres leyes de la cultura:

1.    La ley del cambio

2.    La ley del lenguaje

3.    La ley del liderazgo cultural

No faltaron los consejos sobre cómo trabajar con equipos de diseño e ingeniería.

Fue un momento de compartir con amigos y colegas y un gran público que me acompañó atento durante la sesión. ¡Muchas gracias a todos!

Puedes descargar la presentación aquí: 👇

domingo, julio 25, 2021

Qué hay de "usuario" en las historias de usuario



Estamos en la era de la hiperpersonalización de productos y servicios, cada usuario, cada consumidor quiere tener su propia experiencia de consumo, de uso, de aplicación y eso ocurre a cualquier nivel, en cualquier escenario.

Entonces nos toca proporcionar productos y servicios altamente direccionados, envolventes y únicos para nuestros usuarios. Y esto comienza con cada componente del producto haciendo resonancia con los demás, para que el producto en pleno pueda ser percibido como único por sus consumidores. Esta es la manera cómo construyes relaciones más fuertes con tus clientes y usuarios.

En mi primer curso de ingeniería de software en la universidad, hace ya varias décadas aprendí algo que todavía hoy sigue vigente, pero cuya práctica se extravió en pro del seguimiento rígido a los procesos y metodologías que vinieron después: “mira al usuario en acción”. Qué hace, cómo lo hace, con quién intercambia información, qué información intercambia, a quién beneficia, qué problemas resuelve, cuáles son sus principales vicisitudes, entre otras, son algunas de las cuestiones que debes indagar para conocerlo mejor.

El apellido “de usuario” no es gratuito en las historias de usuario. Para empezar, concentrarte primero en el usuario, antes de en cualquier otra cosa de su historia, te permitirá trabajar en una estrategia de producto hacia esa hiperpersonalización exigida por los consumidores actuales para que tengan su experiencia diferenciada.

Para lograrlo tienes que practicar y fomentar una cultura de “el cliente sentado en la mesa”, pero también de ir a verlo actuando en el gemba*, el suyo, para que puedas entender a fondo sus necesidades y los escenarios en los que se desenvuelve día tras día. Es de esta forma cómo podrás:

·       Conocer su problema, incluso el problema detrás del problema, la causa raíz;

·       Identificar sus canales de comunicación preferidos;

·       Emplear un lenguaje más apropiado a sus características;

·       Generar las hipótesis de cómo el producto puede favorecerlo en la resolución de problemas;

·       De qué forma se podría arruinar su experiencia como usuario o consumidor.

Entre muchos otros aspectos de su cotidianidad.

En mi User Story Conversation Canvas ya mencionaba que el primer paso en la construcción de productos grandiosos es identificar y entender a los consumidores y usuarios. Son actividades basadas en entrevistas, observación e investigación. Hay personas que son primarias al producto o a la historia de usuario en particular, otras son secundarias e incluso otras son suplementarias.

Figura 1: Un ejemplo de User Story Conversation Canvas para la historia de usuario “acceder primero a los libros de mi interés”. Clic en la figura para ampliar.

Entre las primeras encontramos a los usuarios finales de la historia de usuario o a los consumidores del producto. Encargados como un Product Owner o un Product Manager primero, y luego el equipo de trabajo, deben conocer muy bien el perfil de estas personas, los matices personales y profesionales que los identifican, la educación, datos demográficos, sus hábitos e incluso sus motivaciones y comportamientos, lo que les gusta y lo que no. Después de todo desarrollamos productos para seres humanos. Quienes estamos comprometidos en esta tarea debemos sentir que conocemos al usuario, tener empatía con el usuario.

Las personas “secundarias” son quienes tienen algo que decir acerca de la historia de usuario (o del producto o servicio) pero que no lo usan. Pueden ser quienes lo adquieren, quienes imponen una restricción o una regulación, quienes harán la instalación o el mantenimiento, quienes venderán o distribuirán el producto a los usuarios, entre otras. Y las personas “suplementarias” son todas aquellas que de una u otra forma están o se sienten involucradas con la historia de usuario, como patrocinadores del proyecto, la dirección de la organización, representantes de los usuarios y otros interesados.

En resumen, algunos tipos de personas para tener en cuenta en y para la conversación son:

1.     Personas

2.     Usuarios o Consumidores finales

3.     Interesados

4.     Patrocinadores

5.     Equipo de desarrollo

6.     Otros (Legales, externos, etcétera)

7.     Equipo de soporte, Mercadeo, Distribución, Logística, etcétera.

Cuando observamos, entendemos y acordamos entre todos cómo las personas usan o usarán el producto, estaremos en capacidad de:

·      Planificar la accesibilidad al producto desde el principio

·      Desarrollar más rápidamente soluciones de accesibilidad

·      Tomar decisiones informadas entre diferentes opciones y evitar perder el tiempo adivinando o suponiendo o lanzando hipótesis que solo serán eso, hipótesis, hasta tanto el producto no esté en manos de quienes lo van a consumir o a usar

·      Limitar el tener que volver atrás y solucionar problemas, es decir, elaborar el producto correcto desde el principio, no generar desperdicio. Esto es más de pensamiento Lean.

·      Evitar tener que hacer concesiones más tarde porque esperamos demasiado para para conocer mejor al usuario y para abordar las características relevantes del producto.

·      Tener una mejor perspectiva sobre los estándares de uso, las pautas y otros requisitos, que es posible que deba cumplir ahora o más adelante, por ejemplo, si el producto será de uso gubernamental o debe cumplir con ciertas regulaciones.

Todo esto beneficia al equipo de trabajo, incluyendo Product Owner si lo hay, a la media y alta dirección de las organizaciones y a cualquier otro interesado en el desarrollo y puesta en marcha del producto.

User Personas

No en vano, Personas es el primer componente del lienzo para conversar sobre la historia de usuario. Ya desde antes existía este otro instrumento en el que podemos registrar lo que observemos y aprendamos del usuario en acción: se trata del User Persona o simplemente Persona.

Figura 2: un ejemplo de User Persona para registrar el conocimiento que tenemos de un usuario de nuestras historias de usuario. Clic en la figura para ampliar.

En este, podemos registrar aspectos como los de la figura 2:

·      Objetivos del usuario, esto es, las metas que quiere alcanzar o que queremos que alcance en el mediano y largo plazo con el producto

·      Barreras o problemas actuales y posibles problemas futuros

·      Puntos de dolor o necesidades

·      Comportamientos o hábitos del usuario

Y no está demás conocer algunos detalles demográficos y hasta personales del usuario en cuestión, además de ciertos aspectos biográficos que ayuden a conocerlo y, sobre todo, a entenderlo mejor, a ser más empático con esa persona. Incluso, si es alguien conocido, un colaborador de la empresa, bien podemos traer su fotografía y usar sus datos reales, y hasta un lema o declaración de vida, su distintivo o consigna.

Figura 3: otro ejemplo de User Persona para registrar el conocimiento que tenemos de un usuario de nuestras historias de usuario. Clic en la figura para ampliar.

Otros aspectos que bien podrían servir son:

·      Su experiencia ideal

·      La tecnología que usa o las fuentes de información a las que accede habitualmente

·      Por qué quiere usar nuestro producto, de hecho, este aspecto es crucial, deberíamos empezar por allí.

·      Respuestas a la pregunta: ¿qué arruinaría su experiencia usando el producto?

Recomendación final

No me andaré por las ramas: nunca intentes, ni lo sueñes siquiera, empezar a implementar o a desarrollar una historia de usuario de un producto si no conoces quien la usará y por qué. Perentorio.

Conclusión

Involucrar y conocer a los usuarios en las primerísimas etapas del descubrimiento del producto y más tarde, durante el propio desarrollo de este, da como resultado mejores productos para los consumidores, un desarrollo más eficiente y otros beneficios para los interesados y, por supuesto, para los mismos usuarios o clientes.

Y tú, qué haces para conocer a tu usuario. Por favor, déjamelo saber en el foro.

 

Quieres saber más

* Gemba |現場|' es un término japonés que significa "en el sitio de acción" o en la “escena del crimen". En negocios, Gemba se refiere al lugar donde se crea "valor"; en fabricación Gemba es el piso de la fábrica y en ventas es el área de ventas o el lugar donde el proveedor de servicios interactúa directamente con el cliente.1

Más sobre el User Story Canvas en:

El libro Historias de usuario: una visión pragmática:

https://luchosalazar.com/portfolio/historias-de-usuario-una-vision-pragmatica/

O en:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html

Más sobre historias de usuario en:

bit.ly/lashistoriasdelucho

Y en octubre, una nueva edición del curso User Stories FoundationCertificatedonde te contaré de mis experiencias en este y otros asuntos sobre lo esencial de las historias de usuario.

Encuentras más información en:

https://luchosalazar.com/portfolio/nuevo-curso-historias-de-usuario/

¡Te espero!


Créditos

Imagen de la portada por Gerd Altmann en Pixabay.



miércoles, abril 14, 2021

Nuevo curso: Historias de Usuario - 10 de octubre

Las historias de usuario son un poderoso medio para fomentar la cooperación y la enseñanza de muchas cosas. Estas permiten crear un vínculo entre usuarios o consumidores y desarrolladores de productos o servicios. Y esta relación es el primer gran paso hacia la creación y pináculo de productos admirables, que influencien positivamente a las personas que los usen o consuman e incluso cambien para mejorar su estilo de vida.

Esta Certificación proporciona los fundamentos sobre las principales características de las historias de usuario como instrumentos de comunicación entre los miembros de equipo y los demás interesados en los proyectos de desarrollo de productos o servicios, sean de tecnología o de cualquier otra área del negocio.

Objetivos de Aprendizaje:

Al final del curso los participantes estarán en capacidad de:

  • Entender los beneficios de usar historias de usuario en entornos inciertos y ambiguos.
  • Desarrollar las habilidades necesarias para usar las historias de usuario como instrumentos de conversación entre las partes interesadas.
  • Aplicar varias formas de escribir historias de usuario.
  • Reconocer si una historia de usuario cumple con los atributos de toda buena historia de usuario.
  • Emplear distintas técnicas de división de historias de usuario para que estas se puedan elaborar en períodos muy breves de tiempo, desde unas pocas horas, hasta muy pocos días.
  • Usar las historias de usuario para comprender la proposición de valor del producto y de sus características desde el inicio del proyecto.
  • Guiar a otras personas de sus equipos en el uso apropiado de historias de usuario en contextos complejos y adaptativos.
  • Certificarse en User Stories Foundations Certificate (respaldando el conocimiento y la aplicación fundamental de las Historias de Usuario).

Público Objetivo:

Este curso y certificación es apropiado para cualquier persona interesada en usar las técnicas relacionadas con historias de usuario, que estén o vayan a participar en proyectos ágiles con marcos de trabajo como Scrum; también, para interesados en los proyectos que están en la cadena de valor de proporcionar características o requisitos a los equipos de desarrollo de productos o servicios.

● Gerentes de producto
● Dueños de Producto
● Mercadeo de productos
● Analistas del negocio
● Analistas funcionales
● Patrocinadores de los proyectos de desarrollo

También a las áreas de TI de la organización:
● Líderes técnicos
● Gerentes de Proyectos
● Desarrolladores
● Arquitectos de software
● Analistas de Prueba
● Diseñadores
● Scrum Masters
● Desarrolladores Scrum
● Consultores Comerciales,
● Consultores de Preventa de Proyectos
● Líderes Funcionales de Áreas Usuarias de Software o similares

Entre otras personas interesadas en mejorar las interacciones de manera efectiva con los demás miembros del equipo y de su empresa mediante el uso de historias de usuario.

Requisitos Previos:

Haber recibido entrenamiento o tener conocimientos o experiencia en al menos uno de estos temas:
● Scrum Master
● Product Owner
● Team Member

Opcional:
Leer el Manifiesto Ágil
Leer la guía de Scrum

Entrenamiento:

Tipo de Curso: Foundations

Código de la Certificación: USFC.

Examen de Certificación:

Formato: Opción Múltiple.
Preguntas: 40.
Lenguaje: Inglés/Español/.
Puntaje de aprobación: 32/40 o 80 %
Duración: 60 minutos máximo.
Libro Abierto: No.
Entrega: Este examen está disponible en formato en línea.
Supervisado: Será a discreción del Partner.

Información del próximo curso:

Duración: 9 horas

Modalidad: en línea (virtual)

Fechas y horarios:

Sesión 1:
martes 10 de octubre de 2023 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 2:
miércoles 11 de octubre de 2023. 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 3:
jueves 12 de octubre de 2023. 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Inversión:

U$195 precio temprano. *Hasta septiembre 12 de 2023.

U$245 precio regular.

Descuento de 10 % a grupos de tres o más personas. Escríbeme a contacto@luchosalazar.com si quieres acceder a este descuento.

QUIERO UN LUGAR EN EL CURSO

Atención: Incluye certificación User Stories Foundation Certificate

Escríbeme a contacto@luchosalazar.com para reservar tu cupo en un nuevo curso o para despejar cualquier duda que tengas.

¿Quieres este curso para tu empresa? Contáctame para más detalles.

 

domingo, noviembre 22, 2020

Ágiles 2020: o del menguado interés por el desarrollo de software en los eventos ágiles

Temas de interés en Ágiles 2020
Imagen tomada de las redes sociales.

Hace poco se llevó a cabo la más reciente edición de Ágiles Latinoamérica, Ágiles 2020. Iba a ser en Uruguay, quizás en Montevideo. Pero, por razones ampliamente conocidas o imaginadas por todos, se realizó de manera virtual. Como siempre, un evento que convoca a toda la Comunidad ágil de la región, incluso de Europa. Por ejemplo, en la charla que facilitara con mi gran amigo Jorge Abad sobre “de qué hablamos cuando hablamos de historias de usuario” había personas de España. La sorpresa es que allá eran las 2 de la madrugada del día siguiente.

A estas alturas del año, con quizás algunos miles de horas más “frente a la pantalla” que en años anteriores debido a la situación mundial, el entusiasmo de algunos no era el mismo. Sin embargo, hicimos lo posible por llegar a la cita y por cumplir con quienes apoyan el evento, con quienes lo organizaron con corazón y con pasión. A todos ellos, muchas gracias.

Pero no quiero referirme a la organización, a las vicisitudes del evento o a las sesiones, sino a su contenido. Específicamente a las categorías de contenido que hubo en el encuentro. El llamado de trabajos a presentar se hizo clasificado en cinco temas o “tracks”:

  • Producto y clientes
  • Liderazgo y cultura
  • Equipos y coaching
  • Software crafters
  • Organizaciones ágiles

Y durante la apertura se hizo una encuesta rápida sobre cuáles eran los intereses de los asistentes. Los resultados están en la imagen superior (lo siento, no pude conseguir una mejor resolución). El hecho es que desde ese mismo momento y aún después del evento llamó a muchos la atención de que el tema “técnico” no fuera del interés general (hablo de la categoría de Software crafters). El resultado muestra un interés de menos del 25 %, con una muestra representativa de 209 personas que seleccionaban sus preferencias de manera ordenada, de mayor a menor predilección. Y una primera cosa que debo aclarar es que esta es la preferencia de los asistentes, de hecho, así nos gusta hacer las cosas, con lo que les interesa a las personas “hoy”, no con lo que alguien más piensa o presume que le puede servir o concernir.

Pues bien, para aquellos que piensan y sienten que esto es un contrasentido, que se está perdiendo el interés por lo “técnico”, que las personas que tenemos responsabilidades o roles como Scrum Master, coaches o mentores ágiles, facilitadores o habilitadores, no estamos interesados o, peor aún, no sabemos de lo técnico, y que todo esto es una consecuencia de lo que ha venido pasando en los últimos no solo en el Ágiles Latinoamérica sino en otros eventos de esa misma índole, los invito a reflexionar un poco sobre lo siguiente:

Yo creo que tenemos que mirar el contexto. Desde mi punto de vista esto quiere decir que el pensamiento ágil se está llevando a todos los rincones de la organización y que ha salido de una vez por todas y para siempre de las áreas de tecnología, sobre todo de las de desarrollo de software.

Es que pensar que los Scrum Masters deben saber de software es decir que solo podemos usar Scrum para hacer desarrollo de software, cuando, de hecho, hace muchos años hemos pasado esa frontera. Scrum se usa hoy en muchos contextos fuera del desarrollo de software y fuera de lo “técnico” (considerando “técnico” el software), porque cada área tiene su “técnico”. Por ejemplo, si son equipos de Talento Humano, de Operaciones, de Logística, de Mercadeo, de Ventas, incluso de la alta gerencia de la empresa, los Scrum Masters no tienen porqué saber de desarrollo de software.

Si uso Scrum o cualquier otra práctica ágil para crear un hospital, para desarrollar un producto o servicio que no tenga nada que ver con software, para investigación y desarrollo, para enseñar (incluso para aprender), para una empresa de preparación de matrimonios, para abrir y gestionar una cafetería o un restaurante o un bar, para llevar a la cúspide a un equipo deportivo, en fin, para cualquier otra cosa que no sea software, entonces necesitamos otro tipo de agentes de cambio, de facilitadores o habilitadores ágiles, de Scrum Masters, de personas que hagan el trabajo a “lo ágil”.

Quizás eso es lo que quieren decir esos números. Ya abordaremos el tema de si, cuando se trata de desarrollo de software, los Scrum Masters deben saber de software o no, yo pienso que sí. Pero eso es algo muy distinto a lo que estamos hablando aquí.

Debemos entender de una vez por todas y para siempre que la agilidad y Scrum y Kanban y todas las demás prácticas que usamos hoy, no las usamos solo para hacer software. ¿Tú que piensas? Por favor, déjamelo saber en el foro.

¡Aunque sea cuales fueren tus pensamientos, espero verte en #Agiles2021 en Panamá!


Coletilla:

Hace algunos días se publicó la nueva versión de la guía de Scrum, asunto que generó mucho interés entre la comunidad de practicantes ágiles en todo el mundo. Sobre el tema que abordé en este artículo, tengo que referirme a la declaración inicial que hacen los autores de la guía y cocreadores de Scrum, Sutherland y Schwaber. Explícitamente dicen al inicio:

Nos sentimos honrados de ver que Scrum está siendo adoptado en muchos dominios que tienen un trabajo esencialmente complejo, más allá del desarrollo de productos de software donde Scrum tiene sus raíces”.

Es definitivo, hace mucho dejamos de usar Scrum solo para desarrollo de software y las áreas de la empresa fuera de Tecnología son muchas más. Quizás a ello se deba el interés creciente en otros temas ágiles.


martes, octubre 29, 2019

La deuda de producto: cómo se manifiesta y qué hacer al respecto

The Uncomfortable Entrance - Illustration by Katerina Kamprani

Este tipo de deuda se presenta cuando el producto no constituye algo significativo para tu identidad como consumidor o usuario, para tu desarrollo personal o tu bienestar. Aquí estamos hablando de la experiencia de usuario. Es decir, si el producto no genera en sus consumidores emociones y actitudes positivas que sean capaces de impactar su estatus actual. O si esos usuarios no perciben aspectos del producto como su utilidad, la facilidad de uso y la eficiencia, entonces estamos ante una deuda en rojo.

Le faltan esos atributos tangibles e intangibles que brindan al consumidor los beneficios esperados por este y que le resuelven una necesidad específica. Con tangibles me refiero a lo que hace el producto, a la tecnología, al diseño, a la forma. Con intangibles, a los elementos emocionales que generan apego en el usuario, a su identidad de marca, a su ecosistema, a si impacta positivamente la vida de quienes lo consumen y si ese impacto es sostenible. Otra vez, estas dos clases de características es lo que hace posible una extraordinaria experiencia de consumidor, de cliente.

La deuda de producto también es interna, algo que muchas veces ni siquiera el usuario es capaz de percibir. Me refiero a la cultura de Agilidad en medio de la cual fue creado o elaborado el producto, al empoderamiento del equipo, a la felicidad de sus miembros, al foco en el cliente que pusieron todas las personas encargadas de su ideación, descubrimiento, prototipado, desarrollo y puesta en producción de ese producto.

La deuda de producto crece cuando el equipo no aprendió ni mejoró un ápice durante su desarrollo. Además, si el equipo y otros interesados no conocen al cliente, cuáles son sus necesidades o porqué deberían adquirir o usar el producto, la deuda de ese producto también se incrementa.

Si no hubo confianza en el equipo, no se le delegaron las principales responsabilidades para elaborar el producto ni se les habilitó un entorno seguro, donde el empoderamiento y la experimentación estuvieran a la orden del día, hay más deuda de producto.

Si todas las buenas ideas del producto terminan con su despliegue al mercado, todavía habrá un gran camino que recorrer, una deuda aumentada que pagar. El despliegue del producto no es el objetivo. La meta es el cliente, su satisfacción, su felicidad, mejorar su modus vivendi. Si nos quedamos en la puesta en marcha del producto, apenas si nos habremos concentrado en la salida del producto, un número de características de las cuales no sabemos cuáles serán usadas y cuáles no. Consecuencia: más deuda de producto. En cambio, si nuestro foco es el cliente y sus necesidades y la experiencia que tenga usando el producto, entonces estaremos concentrándonos en el valor, en el resultado positivo que puede entregar ese producto a la humanidad.

Otras causas de la deuda de producto:
  • Siempre aplicamos las mismas prácticas en todas partes
  • Siempre exigimos adherencia a actividades y procesos, ágiles o no
  • Definimos la cadena de herramientas permitida
  • Forzamos la estandarización en todas partes
  • Creemos que el proceso habla por sí mismo
  • Confiamos en el proceso más que en las personas y el equipo
Las cosas así, podríamos definir la deuda de producto como:

Deuda de Producto = Falta de Experiencia de Usuario + Falta de Tangibles (Tecnología, Diseño, Forma) + Falta de Intangibles (Emociones, Identidad de Marca) + Falta de Agilidad + Falta de Foco en el Cliente + Falta de Confianza en el Equipo + Falta de Delegación + Otros*

* Incluye aquí los que aplican para tu entorno específico

Para no incurrir en más deuda de producto

El Dueño de Producto debe:
  • Definir y liderar la visión del producto.
  • Investigar y probar las necesidades del cliente / mercado
  • Identificar opciones de productos de alto valor.
  • Hacer que los elementos del backlog estén "preparados" para su planificación y desarrollo
  • Aceptar solo trabajo "terminado"
  • Realizar demostraciones de producto
  • Fomentar la consistencia donde esta sea importante, en todos los niveles de la organización
  • Explicar siempre el valor detrás de un proceso
  • Observar, aprender de y analizar el mercado.
  • Compartir ideas en la organización con respecto al producto y aceptar retroalimentación oportuna
  • Decidir las fechas de lanzamiento y el contenido.
  • Salir al mercado (a producción) tan rápido como sea posible e ir afinando el producto a medida que recibe información de su uso
  • No lanzar en la fecha, lanzar en calidad (a lo Spotify).
  • Asegurarse de que el producto vaya de excelente en su salida inicial a extraordinario después del lanzamiento, afinándolo continuamente.
  • Saber cuándo descontinuar o sacar el producto del mercado
El equipo de desarrollo de producto debe:
  • Ser pragmático en la elección de las herramientas
  • No obsesionarse con las ceremonias o eventos de un proceso o marco de trabajo, por muy ágil que este parezca. Atención a eso Scrum Másters, coaches ágiles, habilitadores ágiles, consultores Lean y estrategas Kanban, entre otros.
  • Demostrar voluntad de evolucionar en función de la retroalimentación que proporcione el entorno
Toda la organización debe:
  • Concentrarse en el Valor.
¡Esperen! Sobre Valor del producto hablaré en una próxima oportunidad. Hasta entonces, déjame saber en el foro tus experiencias e impresiones sobre este asunto crítico de la deuda de producto.

Créditos de la imagen de portada:
The Uncomfortable Entrance
Illustrations by Katerina Kamprani
https://www.theuncomfortable.com/portfolio/the-uncomfortable-entrance/


domingo, febrero 10, 2019

Algunos Elementos de Agilidad Empresarial




Una empresa Ágil es una organización de personas comprometidas y centradas incansablemente en proporcionar valor al cliente; que mejoran continuamente la forma en que operan; y que utilizan el empirismo para adaptarse rápidamente al cambio de una manera sostenible.
Todas las organizaciones se adaptan a los cambios… ¡o casi todas! Pero las organizaciones ágiles lo hacen más rápido, entrenan a su gente y mejoran continuamente la forma en que crean valor. Estas empresas involucran e inspiran a las personas en torno a causas audaces y nobles, no en torno a objetivos a corto plazo. Hacen que la información esté abierta para la autorregulación, la innovación, el aprendizaje y el control; no la restringen.
Estas empresas confían en las personas y les dan libertad para actuar; y no castigan a todos si alguien abusa de ello. Además, organizan los procesos de forma dinámica en torno a los ritmos y eventos empresariales, no alrededor del calendario laboral. Finalmente, pero quizás más importante, estas empresas ágiles conectan el trabajo de todos sus asociados (empleados, colaboradores, etcétera) con las necesidades del cliente; y evitan los conflictos de intereses.
Prácticas Técnicas
Cuando una organización funciona de manera ágil, las prácticas técnicas son los instrumentos utilizados por los equipos y los líderes para entregar valor al cliente de forma rápida e incremental. Permiten construir correctamente el producto correcto. Productos que los clientes amen y que impacten su estilo de vida.
De acuerdo con Jorgen Hesselberg, una lista mínima de estos instrumentos incluye:
·       El lienzo de modelo de negocio
·       Producto Mínimo Viable (MVP) y la experimentación/validación de Lean Startup.
·       El Costo de la Demora
·       Scrum
·       Kanban
·       Value Stream Mapping
·       eXtreme Programming (XP): desarrollo conducido por pruebas (TDD), Integración Continúa, Despliegue Continuo, Programación Par, Propiedad Colectiva del Código y Refactoring (¡mi favorita!).
Lo más importante es poner a trabajar todos estos utensilios al servicio de la organización ágil y de las personas. De esta forma es posible construir no solo correctamente el producto correcto, sino también, hacerlo a la velocidad requerida para sobrevivir en el mercado cambiante y altamente competitivo de hoy.
Sistemas Empresariales
En una organización ágil, los sistemas empresariales son el conjunto de procesos, herramientas, creencias y políticas en constante evolución que mejoran el negocio. Estos sistemas permiten a los líderes tomar decisiones rápidas y priorizar para entregar valor.
El liderazgo habilita a los sistemas empresariales y estos a su vez soportan las prácticas técnicas. En la práctica, estos sistemas o procesos de negocio posibilitan que los equipos, líderes corporativos, analistas y gerentes trabajen en grupos de una manera fluida y conectados para entregar valor al cliente.
Los procesos organizacionales deben reflejar los nuevos paradigmas, como la salida  continua de valor al mercado, el cliente en el centro de la esfera corporativa, es más, el cliente sentado en la mesa – no, las ideas no surgen del negocio, emergen de los clientes, para ello el negocio se vale de instrumentos como user persona, user journey, experimentos de productos (productos y prototipos mínimos viables o mínimos deseables), entrevistas con clientes y focus groups.
Sobre creencias hablaremos a continuación.
Cultura
La cultura es un conjunto de creencias y comportamientos organizacionales. Una organización ágil apoya la capacidad de adaptarse a los cambios a medida que se producen. Se otorga un gran valor a ser transparente y realista, incluso sobre las “malas noticias”.
Las organizaciones ágiles se están moviendo hacia una cultura de energía e innovación. Están creando una cultura basada en la confianza –que hace posible la delegación “pura” y el trabajo colaborativo -, ayudando a los equipos a tomar posesión no solo de su trabajo sino de la empresa misma y no quitarles nada, alineando sus metas (de los equipos) con las metas corporativas, las del negocio y abordando honestamente la ambigüedad y la incertidumbre.
No es posible mencionar cultura sin hablar de métricas. Las métricas son importantes para evaluar e impulsar el progreso, pero pueden ser una barrera si funcionan para la cultura antigua y no para el nuevo estado de las cosas. No, las métricas no son para controlar, son para mejorar. ¡Siempre!
El comportamiento de una organización se levanta sobre los valores y creencias de la empresa, lo que creemos que es correcto: hablamos de coraje, de adaptación rápida al cambio, relacionamiento entre personas, retroalimentación continua, transparencia, respeto, colaboración. Más arriba en la pirámide de sostenimiento cultural de la empresa están los modelos mentales, las estructuras cognitivas, la forma cómo racionalizamos: la satisfacción del cliente, valor, la conversación cara a cara, el compromiso, la calidad, la simplicidad en el sentido de eliminar desperdicios.
Pero la cultura de una organización se levanta sobre hombros de sus líderes. La cultura de una empresa no puede sobrepasar la confianza, la eficiencia y el alcance combinado de sus líderes. Precisamente, liderazgo es el tema del siguiente apartado.
Liderazgo
El trabajo de los líderes es doble: 1) proporcionan una visión y parámetros que guiarán a la organización. Confían en que los equipos son capaces de hacer su trabajo. 2) Eliminan obstáculos y suavizan caminos, lo que permite que los equipos se autoorganicen.
Hoy por hoy, un líder es una persona que puede transformar su entorno o generar nuevos y mejores espacios para él, las personas que trabajan con él y sus seguidores. Así las cosas, un líder es capaz de crear un ambiente donde todas las personas se sientan seguras para actuar y para cometer errores sin temor a represalias.
Ahora bien, lo que distingue a los grandes líderes de los demás no es su coeficiente intelectual o sus habilidades técnicas. De acuerdo con Daniel Coleman [2], se trata de un grupo de cinco habilidades que habilitan a los mejores líderes para maximizar su desempeño y el de sus seguidores.
·       Autoconciencia: para conocer sus propias fortalezas, debilidades, valores, lo que los guía y el impacto en los demás
·       Autorregulación: para controlar o redirigir los impulsos disruptivos y estados de ánimo
·       Motivación: para disfrutar sus logros por el bien propio
·       Empatía: para entender el estado emocional de las demás personas
·       Habilidades sociales: para construir una relación con los demás, para moverlos en la dirección deseada
Todos tenemos algo de esos atributos, nacemos con ellos y, quizás a medida que crecemos los vamos perdiendo, algunos de nosotros más que otros. Pero los podemos fortalecer a través de la práctica, la persistencia, a través de la retroalimentación de amigos y colegas o de coaches.
Los dejo con mi decálogo para ser un mejor líder:
1.     Lidera mediante el ejemplo
2.     Conoce bien tus limitaciones
3.     Aprende del pasado
4.     Nunca dejes de mejorar
5.     Practica la comunicación efectivamente
6.     Algo de humildad siempre cae bien
7.     Promulga y cerciórate de que las reuniones sean efectivas
8.     Cultiva el sentido de pertenencia
9.     Retroalimenta y permite que te retroalimenten
10.  Encuentra un mentor, siempre hay alguien que puede enseñarte algo

Referencias y otras lecturas:
·       Unlocking Agility: An Insider's Guide to Agile Enterprise Transformation, by Jorgen Hesselberg
·       What Makes a Leader? By Daniel Goleman. Harvard Business Review.
·       Más sobre cultura en mi artículo: cultura ágil, ese oscuro objeto del deseo. Lo pueden encontrar haciendo clic en mi Gazafatonario.
·       La idea original vino del artículo: https://searchcio.techtarget.com/tip/Four-ways-to-attain-business-agility

El Póster
Puedes descargar el póster de la portada para imprimir en alta resolución: