Herramientas - Discovery Product Canvas

Discovery Product Canvas

escuchar "no es lo que el cliente desea", es un problema que persiste

Discovery Product Canvas

Algo debe estar sucediendo, ¿Se están excluyendo los requerimientos no funcionales? durante las conversaciones iniciales de lanzamiento de iniciativas y proyectos, de la definición del Mínimo Producto Viable (MVP) o de la expectativa de una entrega de valor; y es que con cierta frecuencia pareciera así, que características como eficiencia, seguridad, usabilidad (por mencionar solo algunas) fuesen ignoradas sin considerar que son también atributos para determinar la definición de calidad de un producto desde una perspectiva de su operación como sistema. Al final, para remediar nos encontramos con nuevos requerimientos que implican más trabajo, mayor costo y menor percepción de calidad.

Entre los desafíos que implica la ejecución de un proyecto software, está comprobada la imprecisión al realizar el levantamiento de requerimientos. Una problemática que desde hace mucho y desde diferentes enfoques, se ha buscado resolver con promover prácticas que logren reducir la complejidad de definir las necesidades del usuario y la ambigüedad de su entendimiento; situación que pareciera ser aún más complicada si consideramos que además de determinar el comportamiento específico, debemos prestar atención a las restricciones, condiciones y criterios que impone el cliente sobre la operación del producto que necesita y espera recibir.  

Hay muchas maneras que podemos explorar para realizar un levantamiento de requerimientos. mi propuesta de este DISCOVERY PRODUCT CANVAS brinda una alternativa donde de forma gráfica y sencilla se pueda promover el desarrollo de conversaciones y recabar así de manera efectiva la información más relevante asociada a los requisitos no funcionales del producto a desarrollar o la solución sobre la cual se realizará implementación de nuevas funcionales.

Por lo anterior, he querido compartir esta entrada, con 2 intensiones: 

1. Invitar a la reflexión:

• Ignorar, posponer o subestimar los requerimientos no funcionales pone en riesgo la aceptación del producto o los cambios realizados a una solución.
• Remediar las definiciones no consideradas o el desarrollo no realizado en el momento oportuno, implica mayor trabajo y costo. 
• En la gestión asociada a los requerimientos, entonces te invito a considerar:


• ¿Se identifican estos atributos en etapas tempranas?
• ¿Se incluyen en la definición del Backlog?
• ¿Son discutidos en ceremonias de refinamiento y planificación para considerar la estimación?
• ¿Se definen precisos criterios de aceptación?
• ¿Son verificados previos a un despliegue y validados durante o después de la liberación?
  

2. Compartir una herramienta: Una perspectiva de solución, para promover una conversación sobre las características técnicas a las cuales se atribuye el desarrollo de un producto o solución de calidad, DISCOVERY PRODUCT CANVAS un medio para considerar los requerimientos no funcionales, como aspectos relevantes para generar una definición compartida de calidad de un producto.

Para descargar el Canvas, puedes acceder aquí

Si tienes problemas para la descarga, al final dejo mis datos de contacto.

Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.

Cordialmente,

Sergio Pardo - Agile Coach

https://www.linkedin.com/in/sergiopardo/

Twitter: @Sergio_E_Pardo

Correo: sepg.sergio.pardo@gmail.com

Herramientas - Entendiendo la segregación funcional

ENTENDIENDO LA SEGREGACIÓN FUNCIONAL

Particularidades para detallar
Épicas, Características e Historias de Usuario

Ficha informativa - Segregación funcional

(link al final para descarga)

¿Y tú cuantas veces has escuchado que la capa estratégica y táctica parecen no tener el mismo entendimiento de la visión de la compañía?, ¿qué entre áreas no logran conciliar frente a sus intereses particulares?, ¿qué las necesidades del usuario superan la capacidad del proyecto para ser abordadas?; son muchos los comentarios de este tipo, que terminan desvirtuando el valor de una iniciativa o el beneficio de un producto a ser construido.  

Ante esta problemática es importante considerar, que realizar la definición de alcance de un proyecto para entender la descomposición funcional de un producto, implica asegurar una efectiva especificación y además administración por capas de los artefactos asociados a una iniciativa (Épicas, Características e Historias de usuario), ardua labor de interpretar y alinear, cómo el contexto de los intereses estratégicos - "para el direccionamiento de la organización",  logran ser abordados desde las expectativas funcionales que son clave - "para así buscar la orientación sobre la situación deseada de los procesos de negocio", que conduzca a encontrar y justificar las funcionalidades específicas sobre un producto por las cuales vale la pena invertir - "definiendo la solución que mejor satisface las necesidades de un usuario".

hablar sobre Épicas, Características e Historias de usuario implica abordar cuando menos los siguientes 4 focos de información, que permiten desarrollar un ejercicio de segregación funcional de forma transversal a las capas de la organización, estos focos son:

1. La perspectiva: ¿Cuáles intereses se pretenden satisfacer? ¿Cómo varía cada punto de vista, según la capa organizacional que lo expone?
2. El asunto: ¿Bajo que contexto (intereses, expectativas, funcionalidades) se debe analizar la intensión o problemática expuesta?
3. El lenguaje: ¿Cómo desde un enfoque funcional y según el contexto (estratégico, negocio, producto) son resueltos los puntos 1 y 2?
4. El beneficio: ¿Cómo desarrollar opciones que generen en cada involucrado la percepción de valor?

Por lo anterior, he querido compartir esta entrada, con 2 intensiones: 

1. Invitar a la reflexión:

• Al existir diferentes perspectivas de quienes están involucrados con una iniciativa, en muchas ocasiones estaremos frente a la necesidad de realizar procesos de negociación, entonces te invito a considerar:
• ¿Tenemos claros que criterios son suficientemente objetivos e independientes a las voluntades para llegar a un acuerdo efectivo? 
• ¿Tenemos una visión clara de los intereses que determinan la posición de cada una de las partes?
• Un tema en la conversación adecuada y las personas adecuadas, para el tema en conversación

2. Compartir una herramienta: Una perspectiva de solución, para realizar la segregación funcional de una iniciativa en Épicas, Características e Historias de usuario (con el desarrollo de los 4 focos de información) enseñando una propuesta de 3 pasos y los cuestionamientos más relevantes para su desarrollo.

Para descargar la ficha, puedes acceder aquí

Si tienes problemas para la descarga, al final dejo mis datos de contacto.

Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.

Cordialmente,

Sergio Pardo - Agile Coach

https://www.linkedin.com/in/sergiopardo/

Twitter: @Sergio_E_Pardo

Correo: sepg.sergio.pardo@gmail.com

Herramientas - Táctica y Estrategia - Valor de Producto

Táctica y Estrategia para la administración del Backlog

¿Qué tanto valor aporta tú producto?

Si en esa etapa donde realizas el levantamiento de alcance de un proyecto, o en ese instante que trabajas la formulación de una iniciativa o durante la planificación del trabajo de una iteración,  haz asegurado un enfoque táctico de cómo abordar la iniciativa – “entonces sabes con claridad de la viabilidad de la solución y que esta conduce a los resultados esperados”, pero además, haz formulado la estrategia que logre los resultados esperados – “entonces tienes confianza que la solución si retribuye al objetivo propuesto”. Dicho esto podrás responder de manera objetiva ¿Qué tanto valor aportará tú producto?

Sabemos que la definición del Backlog, implica cerciorarse de la identificación y relación de componentes que representan la visión del producto, dado el contexto particular de las capas estratégica, táctica y operativa, que te permite tener la correcta identificación de ítem de Backlog que mejor solventan las hipótesis de oportunidad, la hipótesis de beneficio y la respectiva necesidad funcional que materializa dichas hipótesis.

Por lo anterior, he querido compartir esta entrada, con 2 intensiones: 

1. Invitar a la reflexión:

• ¿Qué tanto tiempo dedicas para plantear la táctica de cómo abordar una iniciativa? 
• ¿Te aseguras con suficiente detalle de analizar una estrategia que permita alinear las expectativas y el contexto estratégico, táctico y operativo? Desde una perspectiva de producto.

2. Compartir una herramienta: Una perspectiva de solución, de la identificación de elementos esenciales y su respectiva relación, para entregar soluciones que generen valor.

Considera que la percepción de valor de un producto estará determinada, por la correcta definición de una hipótesis de beneficio que mejor (aquí considera el Time to Market) satisface la hipótesis de oportunidad o necesidad de la organización frente a un objetivo estratégico; la visión compartida de los objetivos propuestos para la especificación y priorización de funcionalidades de valor y la especificación de criterios de aceptación que te guían para abordar la necesidad o la idea de producto de la forma correcta y entregar la solución requerida.  

Para descargar la ficha, puedes acceder aquí

Si tienes problemas para la descarga, al final dejo mis datos de contacto.

Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.

Cordialmente,

Sergio Pardo - Agile Coach

https://www.linkedin.com/in/sergiopardo/

Twitter: @Sergio_E_Pardo

Correo: sepg.sergio.pardo@gmail.com

Metáforas en el contexto de la agilidad - #2 El Espejo

#2 El ESPEJO

#2 – El Espejo, es la idealización del “Yo quiero verme”. Representa la VOLUNTAD de evaluar desde nuestra propia perspectiva, algo en nosotros mismos y sobre lo cual esperamos DECIDIR si la queremos ACEPTAR o MODIFICAR de acuerdo con "lo que vemos y queremos ver". La pregunta es la siguiente, cuando decido acercarme a El Espejo ¿qué tan consciente soy, que la decisión de hacerlo y el criterio con el cual resuelvo que postura tomar ante esa PROYECCIÓN, obedece a mi intención de valorar un resultado como mecanismo de descubrimiento?, la cuestión de estar frente a El Espejo es, que puedo aceptar el hecho lidiar con eso que no puedo cambiar dando por aceptado mi propio juicio de IMPOSIBILIDAD o en cambio, actuar para buscar en recursos una POSIBILIDAD que transforme eso que veo reflejado.

La proyección también comprende una relación con el sentido de RESPONSABILIDAD, “Soy el Scrum Master y sirvo como guía en la adopción del marco”, “Soy el Product Owner y represento los intereses del negocio”, “Soy integrante de un equipo al que aporto para ser auto gestionado y multifuncional”; son algunos ejemplos de posibles idealizaciones de quienes desempeñan dichos roles, que al estar frente a un Espejo tienen la posibilidad de reconocerse como tal y cuestionar, ¿qué tan cómodo me siento frente a mi proyección, la daría por aceptada o preferiría modificarla?, y para responderlo desde su perspectiva, puede basarse en criterios (valores, principios, objetivos, acciones, propósitos, otros.) para decidir si eso que ve, es tal como quiere y debe ser visto.

Metáforas en el contexto de la agilidad - #1 La Varita mágica

#1 - La Varita mágica

#1 - La Varita mágica, es la idealización de un recurso para conseguir un efecto de cambio. “Quiero un equipo auto gestionado”, “Quiero una historia de usuario INVEST”, “Quiero tener incrementos terminados al cierre de toda iteración”; La varita mágica se puede percibir de dos maneras opuestas y ligadas al principio de RESPONSABILIDAD. La primera, desde una posición de VICTIMA, ¿Dónde está la varita mágica?, donde la justificación está en factores ajenos que hacen que en consecuencia, un equipo no sea auto gestionado porque son las personas que conforman ese equipo las que no cooperan o no se hacen responsables, que una historia de usuario no cumpla con el acrónimo INVEST porque el Product Owner realiza una mala especificación, que no se logren incrementos terminados al cierre de toda iteración porque las dependencias del proceso de negocio impiden historias de usuario independientes. En los escenarios expuestos, el individuo que expone dichos deseos no se siente parte de la explicación de los hechos, ve entonces la necesidad de un recurso que transforme su realidad en eso que idealiza.      

La segunda desde una posición de RESPONSABLE, ¿Haré algo al respecto?, donde la causa está dada por acciones propias que infieren en el resultado, mi equipo no es auto gestionado porque no me había preocupado por enseñarlo, una historia de usuario no cumple con el acrónimo INVEST porque no había anticipado un refinamiento, no logramos incrementos terminados al cierre de toda iteración porque no refinamos las historias de usuario con la suficiente rigurosidad. Ahora, en los escenarios expuestos, el individuo que expone su punto de vista, se siente parte de la explicación de los hechos, dejando ver su VOLUNTAD, ve entonces la oportunidad de ser y actuar como instrumento para llevar a cabo dicho cambio.