![](https://i.imgur.com/jnmauPu.png) # Desarrollo Lean & Priorización de Funcionalidades ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_87f8d0982d186814d51712fc23f0fe76.jpg) ## Objetivos - Explicar cómo desarrollar productos en con metodología Lean . - Entender por qué es importante construir soluciones a través de procesos iterativos y aprendizaje validado. - Resumir lo que establece un buen MVP. - Idear un MVP. - Priorizar las funciones de una idea. ## Introducción La estrategia de gestión tradicional es donde un gerente crea un plan, establece metas y supervisa a las personas que ejecutan el plan. Esto funcionaba bien en empresas establecidas que han pasado tiempo aprendiendo qué funcionó en el pasado y saben qué funcionará en el futuro. Sin embargo, la actualidad nos exige procesos muy diferentes a los que tenían las empresas tradicionales. Hoy en día no es tan fácil predecir el futuro porque todo cambia de una forma muy rápida. No sabemos lo que quieren los clientes y no sabemos qué enfoques son los mejores para hacer que el negocio sea sostenible. Las empresas deben gestionarse de manera diferente para encontrar un modelo de negocio sostenible, deben descubrir un problema que necesitan resolver y la solución adecuada para sus usuarios a través del **aprendizaje validado**. ### Proceso Lean UX ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_070b0809f42b4972aa5996469cfb3b4c.png) > **Pensar, hacer, y revisar** son las 3 principales etapas del proceso Lean UX. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_7d9493b8dd5fd4f09594bdaa206ab3c8.png =600x) #### MVP - Nos ayudan a probar nuestras suposiciones y minimizar el trabajo que ponemos en ideas no probadas. - Concentrar nuestros recursos limitados en las mejores soluciones a nuestros problemas - Dos usos diferentes: - **Pruebas de conceptos:** APRENDER algo (por ejemplo, para averiguar qué quiere el mercado - idea) - **Pruebas de prototipos:** Para COMENZAR A ENTREGAR VALOR al mercado lo más rápido posible (funcionalidad) Lean UX **prueba la hipótesis** construyendo MVPs (Producto Mínimo Viable). :::warning - Un MVP generalmente no tiene que estar hecho de código, puede ser una aproximación de la experiencia final (como un prototipo interactivo). - Un MVP no siempre tiene que ser de alta resolución. Probar con diferentes niveles a lo largo del proceso es la forma más *eficiente* de resolver el problema. ::: ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_fdbd529547cf2b585f3549bc2471eeab.png) Estos son los fundamentos de Lean UX, resumidos en **15 principios**: 1) Equipos multidisciplinarios 2) Pequeño, dedicado 3) Progreso = resultados 4) Equipos enfocados en problemas 5) Eliminación de cosas que no sirven 6) Tamaño de lote pequeño 7) Descubrimiento constante 8) GOOB (Get out of the Building, Salir de la oficina): nuestra mente centrada en el usuario 9) Compartir nuestro entendimiento 10) Sinestrellas de rock, gurús o ninjas 11) Exteriorizando nuestro trabajo 12) Rehacer el análisis 13) Aprendiendo sobre el crecimiento 14) Permiso para equivocarnos 15) Salir del negocio de *entregables* ## Bucle de crear, medir y aprender Para recopilar comentarios, debe crear una versión simple de su proyecto. Entonces tienes que probarlo y aprender de los comentarios obtenidos. Cada bucle de crear, medir y aprender nos ayuda a mejorar el producto y nos brinda información sobre lo que quieren los usuarios. Para lograr esto, el primer paso es construir el MVP. ## El MVP El producto mínimo viable (MVP) es una forma de capturar comentarios del mundo real sobre una idea. Este MVP debe ser lo más simple posible y debe contener solo lo que se necesita para brindar a los clientes una experiencia realista de cómo funcionaría el producto. Sin embargo, el producto mínimo viable debe ser un producto o plataforma desarrollado con características suficientes para satisfacer a los primeros usuarios. Debe poder funcionar con funcionalidades minimas para ir aprendiendo de la misma. Los usuarios deberían poder satisfacer sus necesidades y solucionar alguno de sus problemas planteados. Pensemos en un usuario que necesita transportarse y observe la siguiente imagen: --- ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_892b59c45d7215d2bd66e9e8dbf3cb28.png) --- Podemos diseñar el neumático perfecto. Sin embargo, este neumático por sí solo no será útil para que su usuario satisfaga sus necesidades. Ni siquiera un par de ellos funcionarán. Si agrega el chasis del automóvil, aún no será suficiente. Debe entregar todo el automóvil para ayudar a su usuario. Sin embargo, si creamos una forma de transporte no perfecta (como una patineta), tu usuario puede probarla y darte su opinión: "Sí, podría moverme, pero me sentí inseguro por no tener un lugar donde agarrarme ". Y luego puedes agregar los manillares. Entonces su usuario podría decir "Me gustaría viajar sentado" ... y así sucesivamente. ## Priorización de funcionalidades Cada proyecto tiene limitaciones de recursos: tiempo, dinero o personas. Y si estamos planeando desarrollar un MVP, deberemos seleccionar y priorizar lo que deseamos incluir en nuestra primera versión. Además, necesitamos evitar [featuritis](https://www.interaction-design.org/literature/book/the-glossary-of-human-computer-interaction/featuritis-or-creeping-featurism). Para eso, debemos planificar una implementación gradual de la solución. Cuantas más funciones tengam en el lanzamiento, más difícil será saber qué funciona y qué no. Pero, ¿cómo elegir y priorizar estas funciones? Comencemos con el panorama general. Necesitamos juntar tanta información en estas categorías como sea posible: - Objetivos de negocio - Entrevistas con las partes interesadas - Modelo de negocio - Métricas de éxito (KPIs) - Métrica más importante (KPIs) - Objetivos del usuario - Investigación de usuarios - Desarrollo de User Personas - User Persona principal - Caso de uso más importante :::success :ok_hand: **Pro-tip:** Siempre tenemos que preguntarnos cuál es la forma más sencilla de satisfacer la necesidad de negocio y la necesidad del usuario. ::: ## Métodos Ahora que hemos recopilado esta información, podemos utilizar estas técnicas: ### Método MOSCOW Dado que el conjunto completo de funciones solo se diseña y desarrolla después de considerar los comentarios de los usuarios iniciales del producto, piense en las posibles funciones e intente clasificarlas en: 1) **Debe tener**: estas son las características obligatorias. Si eliminamos una de ellas, falla el objetivo del producto. 1) **Debería tener**: estas características no son clave para satisfacer las necesidades de nuestros usuarios. Por ejemplo, en algunos casos, la información de registro no es obligatoria, pero podría mejorar seriamente su experiencia de usuario. 1) **Podría tener**: Nuestro producto no necesariamente *necesita* estas características. Ni siquiera estamos seguros de si son una ventaja para el usuario. Estas características pueden representar algunas ideas para enriquecer la experiencia del usuario. 1) **No es necesario**: estas son funciones completamente fuera de alcance. No agregan valor a nuestra solución. Incluímos aquellas que alguna vez pensamos que podrían ser útiles, pero cambiamos de opinión y no investigó. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_321755ad1149700c44907d0d1f852e0b.png) *La matriz de Moscow para un ecommerce de restaurant* ### Cuadrante de Valor vs. Complejidad En el modelo del cuadrante de valor frente a complejidad, evaluamos cada oportunidad en función de: - Su valor comercial - Su relativa complejidad para implementar Esta es una herramienta muy útil si tenemos la posibilidad de investigar con nuestros desarrolladores y encargados comerciales. La matriz es simple: las funcionalidades que tengan el valor más alto y el esfuerzo más bajo (la sección del corazón del cuadrante) serán las primeras en implementarse. Aquellas con mayor complejidad y menor valor comercial serán las menos deseados. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_2479ab6e9d81c421fbcfe2b6bd93a04c.png) ### Comprar una funcionalidad Éste es un método bastante interactivo pero necesitamos ayuda de un cliente actual o un potencial cliente, con un stakeholder. La metodología de *Comprar una funcionalidad*, mejora la calidad de priorizar las funcionalidades al poder preguntarle directamente a uno de nuestros usuarios o potenciales usuarios. Listamos las características potenciales y asignamos un "precio" a cada una (intentamos basar el precio en el costo relativo para desarrollarlo). Repartimos una cantidad determinada de efectivo falso y luego pedimos a los participantes que compren las funciones. Algunos colocarán todo su dinero en una función en particular que les interese, mientras que otros pueden repartir su dinero por las distintas funcionalidades. El resultado va a ser nuestra lista de funciones priorizadas. ## Recursos adicionales - [El ciclo construir, medir, aprender](https://www.mindtools.com/pages/article/build-measure-learn.htm) - [El modelo Kano](https://www.kanomodel.com/) - Prioritizing Customer Satisfaction and Delight