Buscar en Gazafatonario IT

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

miércoles, marzo 29, 2017

Guía Supernumeraria para un Dueño de Producto Virtuoso


El Dueño de Producto es un nuevo rol para muchas, en realidad para la gran mayoría de las compañías. Y de estas, un gran conjunto no lo entiende o simplemente no ha tenido las mejores experiencias con sus responsabilidades. En términos generales, el Dueño de Producto es un ilustre olvidado.
Mientras que la promesa de un equipo de TI es diseñar y construir el mejor producto o servicio que el negocio necesita, una solución con Valor, dadas las restricciones de tiempo, presupuesto, tecnología, entre otras, la promesa de un Dueño de Producto es trabajar con el equipo en la priorización y negociación de características del producto, lograr no solo que el equipo de desarrollo aprenda del negocio sino de lo que significa Valor para el negocio.
La proposición de valor del Dueño de Producto también incluye mantener al equipo motivado y contribuir desde su posición a que se cumplan los compromisos con los usuarios o consumidores que él mismo representa. También, mientras la organización confía en la mentalidad Ágil del equipo y del Scrum Master para mantener la alineación con las áreas de TI, delega en el Dueño de Producto la responsabilidad de mejorar los tiempos de salida al mercado a la vez que optimizar el retorno de la inversión.
El Dueño de Producto es precisamente el dueño de la visión del producto, el plan del negocio, las ganancias, el plan de entregas y de un backlog de producto cuidadosamente refinado y priorizado con precisión para que el equipo pueda trabajar sin tropiezos. Mientras el trabajo del equipo es construir correctamente el producto, el Dueño de Producto debe entregar el producto correcto. ¡Es un juego de palabras, pero es verdad!
El Dueño de Producto es o será el encargado de devolver el encanto que muchos usuarios, socios y empleados perdieron en el pasado a raíz de las soluciones de TI disfuncionales que estábamos produciendo. Eran soluciones con muy poco o ningún sentido de la calidad, tardaban años en llegar al mercado y carecían de la innovación necesaria para resolver problemas reales del negocio. Las cosas así, la responsabilidad moral de un Dueño de Producto es una carga pesada que todos en la Organización tenemos obligación de ayudar a soportar mediante el apoyo incondicional a su trabajo.
Scrum en particular y el enfoque Ágil en general proporcionan las herramientas suficientes para que el Dueño de Producto cumpla con sus responsabilidades de manera decidida y franca, para conectar efectivamente los deseos y necesidades de los usuarios y el negocio con el equipo de desarrollo, de forma dinámica y receptiva.
En su libro “Agile Product Management with Scrum”, Roman Pichler describe ampliamente las principales actividades que un Dueño de Producto de talante realiza:
Definir y manejar la Visión del Producto

Una visión efectiva del producto responde o debería responder a las siguientes cuestiones:
  • ¿Quién comprará o usará el producto? ¿Quién es el consumidor o usuario final?
  • ¿Qué necesidades cubrirá el producto? ¿Qué valor agrega el producto al usuario o a la organización?
  • ¿Cuáles son los atributos críticos del producto para que este sea exitoso?
  • ¿Cómo y qué tantas ganancias tendrá la compañía con el producto?
Entre otras no menos importantes. En resumen, la visión debería comunicar la esencia del futuro producto de una manera concisa y describir un objetivo compartido que conduzca la creación del producto pero que sea lo suficientemente amplio como para facilitar la creatividad del equipo que lo desarrollará.
Un aspecto importante a considerar aquí es el conocido como el Mínimo Producto Viable (MVP) o, a veces, el Mínimo Producto Mercadeable. Este es un producto con la mínima funcionalidad que cubra algunas de las necesidades básicas de los usuarios y genere valor a la organización. Un Dueño de Producto hábil sabe que el producto debe estar en funcionamiento muy pronto y que este debe entregarse en pequeños incrementos en cortos lapsos de tiempo. Esto reduce la incertidumbre y aumenta el aprendizaje no solo sobre el producto sino sobre los hábitos de consumo de sus usuarios finales.
Para saber más sobre cómo crear la Visión del Producto, pueden ver este Webinar sobre Inception Ágil que facilité con mi gran amigo Jorge Abad:
Es prácticamente imposible, por no decir menos, establecer una visión del producto apropiada sin tener en cuenta el factor humano. En otras palabras, definir una correcta visión del producto es un acto puramente humano.
Trabajar con el backlog de Producto

Este artefacto hermosamente simple sufre muchas veces de la falta de atención apropiada tanto por parte del Dueño de Producto como del mismo equipo de desarrollo.
Para quienes no están familiarizados con la herramienta, es una lista priorizada de los elementos necesarios para darle vida al producto. Estos elementos incluyen la exploración de las necesidades de los usuarios, pero también puede incluir una descripción de opciones técnicas y de requisitos funcionales y no funcionales, así como el trabajo necesario para poner a punto los distintos ambientes de trabajo.
Uno de los aspectos más importantes que debe estar en el radar del Dueño de Producto es este del Valor de cada uno de los elementos del backlog. El valor es un factor común de priorización de sus elementos. El Dueño de Producto sabe que debe entregar primero los elementos de mayor valor. Al agregar nuevos elementos, el Dueño de Producto no solo revisa o establece el valor de estos nuevos elementos sino que reexamina el valor de los existentes.
También hemos aprendido que un Dueño de Producto experimentado va adelante del equipo en cuanto al conocimiento detallado que tiene de los elementos del producto. Quizás uno o dos sprints más allá del actual y está continuamente practicando refinamiento al producto.
Para profundizar más en estos asuntos pueden leer mis artículos:
Sobre gestión del producto en general, en el que abordo cuáles son los atributos (DEEP) de un buen backlog de producto:
Sobre refinamiento del producto en particular:
Planear las entregas

En su libro Agile Estimating and Planning, el gran Mike Cohn escribió que “Planificar... es una búsqueda de valor”. Otra vez emerge el Valor como factor determinante a la hora de planear las entregas de un producto. También hemos aprendido que este plan de entregas no puede ir encadenado a las aristas de tiempo, costo y alcance de manera fija e inquebrantable. Es posible adherirse a una de ellas, quizás a dos, pero no a las tres en simultáneo.
Otra vez: la meta principal de todo Dueño de Producto es entregar el producto correcto. De allí que la planificación de esta entrega de producto, en pequeñas entregas incrementales es una tarea fundamental de todo Dueño de Producto hábil. Sobre este asunto en particular pueden leer mi artículo:
En donde agrego el atributo de Valor a las ya ampliamente difundidas bases de Ágil y propongo El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor.
Colaborar con las Reuniones del Sprint

¡Scrum!

Las reuniones son oportunidades de Conversación cara a cara y, en el caso específico de Scrum, son momentos propicios para la inspección y adaptación, pilares fundamentales de la mentalidad Ágil. Y el Dueño de Producto hace parte del equipo Scrum, así que bienvenido su aporte estratégico y táctico al equipo durante estas conversaciones.
Para saber más sobre los distintos eventos en Scrum pueden ir a mi Gazafatonario:

En conclusión, el Dueño de Producto es uno de los ejes fundamentales sobre los cuales avanzan los equipos Scrum como un todo hacia la búsqueda de un objetivo común: la generación de valor a la vez que responder al cambio de manera eficiente. En particular, el Dueño de Producto se constituye en una arista esencial para la correcta gestión ágil del producto pero sobre todo para entregar productos cuyos componentes generen resonancia entre ellos e impacten el modus vivendi de sus consumidores, nosotros la humanidad.

lunes, noviembre 28, 2016

Las historias de usuario como instrumentos de negociación


Hablemos un poco de ese continuum que significa diseñar y construir soluciones de valor para una organización. Las organizaciones hoy día están hechas de software, el software está en todas partes y si de construir software se trata, los equipos ágiles tenemos algo que decir.
De los incontables utensilios que contamos en nuestra mesa de trabajo las historias de usuario están siempre a la vista de quienes transitamos por los senderos de los problemas complejos y las soluciones para ellos. Para nosotros, trabajar en soluciones mejora la comprensión de los problemas. Esta es posiblemente la razón principal por la cual los enfoques iterativo e incremental son mejores que cualquier otro en la actualidad. Y si los combinamos, mucho mejor. Los Agilistas fantásticos:
1.     Construimos de manera iterativa para minimizar el riesgo
2.    Construimos de manera incremental para maximizar el retorno de la inversión (ROI)
3.    ¡Repetimos  1 y 2 hasta la saciedad! O hasta que se esté generando el suficiente valor como para detener nuestro esfuerzo de desarrollo.
En ese camino hemos aprendido que los problemas no son subjetivos. Lo subjetivo es la percepción que tengamos de esos problemas. En general estos se basan en la realidad. Además, los enfoques de pensamiento, nuestro mindset, pueden llegar a redefinir esos problemas por completo.
Ya sabemos que una historia de usuario no es un contrato firmado en piedra, más bien es una carta de intención de algo que el sistema debe hacer y cuyos detalles se abordan durante la conversación entre el usuario (Dueño del Producto) y el equipo de desarrollo. También son cartas de negociación entre unos y otros, pero solo habrá una negociación fluida si el usuario está realmente interesado en el éxito del esfuerzo de desarrollo, si está dispuesto a comunicarse de manera efectiva y a trabajar con y como parte del equipo.
Los ingredientes clave de una historia de usuario son: quién es el usuario, qué quiere hacer el usuario y por qué lo necesita. Contrario a lo que mucha gente cree, las personas (usuarios o consumidores finales, expertos con el conocimiento, interesados, patrocinadores y otras personas impactadas por la historia), constituyen lo más importante de una historia de usuario. Esto permite o posibilita la comunicación para que hagamos las cosas correctas y nos ayuda a identificar el valor para priorizar lo que haremos primero y lo que haremos más adelante.
La parte “conversación” de una historia de usuario idealmente es una colaboración entre el usuario y el equipo que construye la solución, es una asociación para entender el problema y trabajar precisamente en una solución que resuelva ese problema y también permite confirmar más adelante que esa solución de hecho resuelve el problema adecuadamente.
Las historias de usuario proporcionan un entorno, un medio para adaptarnos, para buscar oportunidades. Si encontramos un obstáculo que no es posible sortear, siempre podemos buscar otra historia relacionada que nos permita avanzar. Es posible que, al hacerlo, encontremos la solución a la historia que no nos permitía progresar en principio y podemos volver a ella.
Ahora bien, si esa carta de intención, esa necesidad que tiene el usuario, es muy específica, la tarea del equipo es preguntar “¿por qué?” ¿Por qué y para qué se necesita esa historia?; en cambio, si es muy abstracta, preguntaremos “¿cómo?” ¿Cómo lo hace? ¿Cómo quiere o quisiera la solución? Las historias de usuario siempre son sobre “negociación” si queremos un buen balance entre costo y valor.
En general, las historias de usuario nos permiten a los Agilistas fantásticos:
1.     Lograr este balance en pequeños alcances,
2.    Construir la solución, o los incrementos de esta, de tal manera que podamos obtener una efectiva retroalimentación anticipada.
3.    Trabajar en los aspectos de más valor primero para que sean entregados y empiecen a generar ROI lo más pronto posible.
Finalmente, ninguna discusión o exposición sobre historias de usuario estaría completa si no incluimos la palabra “confianza”. Si la confianza es poca en un equipo Scrum, las historias de usuario se convertirán muy pronto en piezas muy concretas de descripciones de problemas que el Dueño de Producto le entregará al equipo de desarrollo y que quizás nadie querrá resolver. Si esto ocurre, seguramente el equipo de desarrollo también va a solicitar, con grado de exigencia, unos criterios de aceptación muy concretos. El resultado: el muy pesado, extenso y falto de humanidad documento de especificación de requisitos funcionales y no funcionales del pasado, el mismo que cargaba consigo el sinsabor de la frustración y la derrota.
Entonces, para que positivamente las historias de usuario sean una herramienta auténtica de negociación entre las áreas de TI y las del negocio y para que sean una representación de los problemas de este último y de las soluciones que puedan proporcionar los primeros, es necesario que en el ambiente haya un alto grado de confianza. El Equipo Scrum en pleno, e incluso los interesados del entorno, tienen que conformar un equipo propiamente dicho, donde el trabajo colaborativo, la adaptación, el mejoramiento continuo y la entrega continua de valor sirvan de pilares y de integradores entre sus miembros para que todo lo anterior sea posible.