CONOCER CÓMO SE REALZIA UNA PLANIFICACIÓN ORIENTADA AL VALOR
CONOCER CÓMO SE REALIZA UNA PLANIFICACIÓN ORIENTADA AL VALOR
DESCRIBIR EL SIGNIFICADO DE "VALOR" EN EL DESARROLO DE UN PRODUCTO
El valor dentro del desarrollo de un producto es toda operación que se desarrolla en un proceso, sin importar si este proceso afecta directa o indirectamente al incremento de la satisfacción tanto del cliente como de los requerimientos. Por lo que aquellas operaciones que se realizan en un proceso y estas no tienen un impacto positivo sobre la satisfacción de cliente, solo son tomadas como un coste para la empresa.
En tal sentido sólo las operaciones que transforman en sucesivas estaciones de trabajo unas materias primas en un producto terminado pueden ser consideradas como operaciones de valor añadido.
DESCRIBIR 3 TÉCNICAS PARA REALIZAR LA PRIORIZACIÓN DE UN PRODUCT BACKLOG
La priorización del Product Backlog es uno de los ejercicios del desarrollo ágil de software. Cualquier proyecto tiene éxito si las partes interesadas, los clientes o la empresa, obtienen la funcionalidad más valiosa lo antes posible. Y eso es posible priorizando de manera efectiva y consistente los requisitos (historias de usuarios). La priorización de Backlog es necesaria para organizar los elementos del Product Backlog para hacer la secuencia de su desarrollo e implementación. Esta secuencia es seguida por el equipo de Scrum para elegir los elementos del Product Backlog durante la planificación del sprint.
Por eso es importante priorizar el Product Backlog, para asegurarse de que no se convierta en una lista abierta de ideas aleatorios que se tengan sobre un producto. El backlog debe estructurarse y organizarse para favorecer las cosas estratégicamente más importantes para que su equipo trabaje.
Nombrada en honor al ex presidente de EE. UU. Dwight D. Eisenhower, la Matriz de Eisenhower equilibra las cosas que son importantes frente a las cosas que son urgentes.
La Matriz de Eisenhower funciona muy bien a escalas muy grandes y muy pequeñas:
Con esta filosofía por bandera, la matriz propone cuatro tipos de cuadrantes ordenados de 1 a 4 donde debemos ubicar nuestras historias:
- Historias de usuario importantes y urgentes: estas historias son las que debemos poner en primer orden, máxima prioridad, máximo foco. Son aquellas alineadas con los objetivos, que aportan máximo valor a negocio, que aportan máximo valor al cliente, y que además, están dentro de la zona de confort del equipo de desarrollo o llevan pocos puntos de historia.
- Historias de usuario importantes pero no urgentes: todas se aquellas alineadas con los objetivos a medio/largo plazo, aquellas sin imposiciones de fecha, pero que aportan valor a negocio y clientes.
- Historias de usuario no importantes pero urgentes: al contrario que el punto anterior, vienen marcadas por una fecha, pero no van en línea de los objetivos, ni tienen un alto valor para negocio/cliente. Estas historias debemos abordarlas después de las que hemos tipificado como cuadrante 2.
- Historias de usuario no importantes y no urgentes: Éstas historias se deberían ser abordadas después de lo que se ha identificado en el cuadrante 3.
MÉTODO KANO
Este método lo creó Noriaki Kano en 1984, inspirado por la asimetría de la satisfacción e insatisfacción de los usuarios con una feature. Algunas features pueden ofrecer poca satisfacción cuando están presentes, pero su ausencia puede provocar a su vez una gran insatisfacción. Se relaciona las características de un producto con el nivel de satisfacción de sus usuarios.
Características
- Te permitirá priorizar las features principales que quieres incluir en tu producto. Este método también es colaborativo y debería llevarse a cabo en un grupo de trabajo de cuatro pasos con varios participantes.
- Kano junto a diferentes metodologías ágiles como por ejemplo Scrum, nos ayuda a medir, priorizar y visibilizar las historias de usuario en función de qué satisfará al usuario en cada momento, descartar las historias de usuario que no urgen y ver cuales se podrían mejorar.
- Para empezar a usar Kano se priorizan las historias de usuario mínimas que debería poseer el producto. En función del valor que le aporten al cliente, en Scrum el modelo Kano se suele utilizar para priorizar las historias de usuario que están en el product backlog.
- Aporta más que el MoSCoW análisis en cuanto a estrategia de producto, MoSCoW viene a adoptar un enfoque funcional, mientras que el modelo Kano, al introducir al cliente como eje de nuestro análisis, nos sirve para definir un Producto Mínimo Viable, pero también para definir nuestra propuesta de valor.
Satisfacción y Sentimiento
Satisfacción: se divide en diferentes niveles de satisfacción que van desde la satisfacción total o deleite y emoción, hasta la insatisfacción total o frustración.
Sentimiento: Esta representada por la funcionalidad o también llamada Inversión, Sofisticación o Implementación, que representan que cantidad de una característica determinada es obtenida por el cliente, lo bien que es implementada esta o cuánto hemos invertido en su desarrollo.
- Calidad esperada (must be): son necesidades básicas, atributos que esperan los clientes y sin ellos conducen a la insatisfacción extrema. Tenerlos no implica que aumente la satisfacción del cliente, al contrario, hace que el cliente no tenga esa insatisfacción.
- Calidad deseada (Performance): atributos que cuando se realizan van incrementando la satisfacción del cliente. Son características/funcionalidades que el cliente pide de forma directa.
- Calidad motivante (Delighter): atributos atractivos, generalmente inesperados hacia los clientes que pueden resultar de gran satisfacción si están disponibles, aunque no suelen ser una prioridad.
- Calidad indiferente (Indifferent): el cliente no está tan interesado en ciertas características, aunque los haya mencionado con anterioridad.
Ejemplo
Calidad esperada: Si fuéramos a un bar y pidiéramos un café, que nos lo pongan no produce satisfacción ya que es lo que hemos pedido. Sin embargo, en caso de pedirlo y que no nos lo sirvan estaríamos muy decepcionados.
Calidad deseada: sería cuando pedimos un café y nos sonríen mientras nos desean un buen día. Calidad motivante: Que el bar al que vamos nos dé Wi-Fi, o que junto con el café te den una galleta o una chocolatina son detalles que nos agradan.
Calidad motivante: Que el bar al que vamos nos dé Wi-Fi, o que junto con el café te den una galleta o una chocolatina son detalles que nos agradan.
MÉTODO MOSCOW
El modelo MoSCoW toma su nombre de las letras que componen sus criterios en inglés: debe tener (Must have), debería tener (Should have), podría tener (Could have) y no tendrá (Won’t have).
Debe tener – Must have: Si se tuviera que cancelar un lanzamiento de un producto si no se puede, entonces es “Debe Tener”. Las historias de usuario aquí son imprescindibles dado que aquellas que se garantiza entregar porque no puede ser entregar sin ellas, o sería ilegal o inseguro sin ellas. Si hay alguna forma de entregar sin él, por ejemplo, una solución alternativa, entonces debería degradarse a “Debería Tener” o “Podría tener”. Eso no significa que no se entregará. Significa que esa entrega no está garantizada.
Debería tener – Should have: las características de “Debería tener” son importantes, pero no absolutamente vitales para el éxito del lanzamiento. Puede ser doloroso dejarlas de lado y pueden tener un impacto en el producto, pero no afectan la viabilidad mínima del mismo.
Podría tener – Could have: los elementos que “Podría tener” son aquellos que se desean o son deseables, pero que son menos importantes que un elemento que “Debería tener”. Dejarlos fuera causará menos dolor que un elemento “Debería Tener”.
No tendrá – Won’t have: Las historias de usuario de “No tendrá” son aquellas en las que todos acordaron no entregar esta vez. Pueden mantenerse en el Backlog para más adelante, si es necesario hacerlo o cuando sea necesario.
CONCLUSIÓN DEL EQUIPO
El valor se puede definir como el aporte que se da a un cliente que genera satisfacción, este es de suma importancia ya que si no se tienen un impacto positivo el proceso hecho es considerado como un coste para la empresa, es por eso que en el Product Backlog debe ser correctamente priorizada esto con alguna de las técnicas mencionadas.
Comentarios
Publicar un comentario