Gestión de Proyectos y Fundamentos de metodología Agile.pptx

metodologia para la gestion de proyectos empresariales

1. Gestión de Proyectos y Fundamentos de metodología Agile Samuel Martínez Ordaz

2. Introducción Con este curso aprenderás las nociones básicas sobre el  project   management  y la metodología Agile, imprescindibles para garantizar el éxito de un proyecto basado en el entendimiento de las diferentes partes involucradas en el proyecto y la consecución del objetivo final.

3. Índice de contenidos Fundamentos y  masterclass Fundamentos de la agilidad Entender la agilidad a través de Scrum Combinar Agile con  design thinking   y Lean Startup para generar innovación Cuestiones éticas y responsabilidad en el diseño y desarrollo de productos

4. Objetivos de aprendizaje Aprender los fundamentos de la gestión de proyectos por metodología Agile. Enfocar de manera práctica y con ejemplos los fundamentos de Scrum y entender qué es, qué no es, qué hacer y qué no hacer.

5. 1. Fundamentos de la agilidad Origen de la agilidad y problemas que solventa: la agilidad un termino muy de moda en los últimos años, es la filosofía de desarrollo de productos, gestión de equipos y proyectos que surge entre finales de la década de los 90 e inicios de los 2000 en el ámbito de desarrollo de software. La industria del software crea estos marcos de trabajo porque, en sus inicios, en los 70 y 80, hereda las metodologías de gestión de proyectos de las ingenierías tradicionales, como la ingeniería civil, y se acaba dando cuenta de que esas metodologías pesadas no eras las más adecuadas para las peculiaridades que tiene el desarrollo de software. Imaginemos el proces o de construir un puente, un proyecto que exige una planificación muy extensa y rigurosa, hacer muchos números y movilizar muchos recursos con muchos riesgos asociados. En estas ingenierías tradicionales, las etapas iniciales, de planificación, diseño y cálculos son llevadas a cabo, seguimos el ejemplo imaginario, por ingenieros y arquitectos en un despacho y tienen un coste y un riesgo relativamente bajos

6. Comparadado con las fases posteriores, porque, una vez que el proyecto entra en la fase de construccion , movilizando maquinatis pesada, materiales y personal, los costes y los riesgos escalan drásticamente. Un error en esta etapa no solo imp’lica perdidas económicas enormes si no también riesgos muy importantes para la seguridad e incluso posibles tragedias humanas. Imaginemos que el puente se derrumba o que un fallo de cálculos provoca un accidente laboral. Por el contrario, la industria del software presenta una estructura de costes y riesgos muy diferente. En este caso, los costes son mas uniformes a lo largo del proyecto, ya que en gran pare se basan en las horas de trabajo de sus desarrolladores y no cambia demasiado a lo largo del proyecto.

7. 1.1. Filosofía, principios y valores; el Manifiesto Ágil En el año 2001, un grupo de reconocidos expertos en desarrollo de software como Kent Beck y Jeff Sutherland, se reunieron en las montañas de Utah para abordar las deficiencias de los métodos tradicionales, considerados demasiado rígidos y lentos para un mundo tecnológico en constante evolución. Durante esta reunión se redactó el Manifiesto Ágil, un documento que representa un punto de inflexión en la consolidación de la filosofía Ágil y marca el inicio de su evolución hacia un enfoque más flexible, adaptable y centrado en las personas. Este manifiesto no solo cuestionaba las convenciones establecidas, sino que también introducía una nueva mentalidad en la industria del  software , destacando la importancia de la colaboración, la funcionalidad del producto y la capacidad de respuesta ante cambios imprevistos.

8. Este documento establecía los 4 valores de la filosofía Ágil: Individuos e interacciones: Se enfatiza más en las personas que realizan el trabajo y en cómo colaboran, en lugar de en procesos y herramientas rígidos.  Software funcionando: Se valora más entregar  software  funcional y útil de forma regular, en lugar de una documentación exhaustiva.  Colaboración con el cliente: Se promueve la colaboración continua con el cliente para mejorar y validar el producto en lugar de la negociación de contratos.  Respuesta al cambio: Se enfoca en la capacidad de adaptarse a los cambios en lugar de seguir un plan fijo.

9. Estos valores se aterrizan en los 12 principios del Manifiesto Ágil: Satisfacción del cliente: Satisfacción del cliente a través de entregas tempranas y continuas de  software  valioso. Entrega periódica :  Entrega periódica de  software  funcional, con preferencia en ciclos cortos.  Proyectos : Proyectos construidos alrededor de individuos motivados, proporcionando el ambiente y apoyo necesario.  Software : Software  funcional como principal medida de progreso.  Atención continua : Atención a la excelencia técnica y al buen diseño.  Equipos: Equipos autoorganizados para la mejor arquitectura, requisitos y diseños. 

10. Cambios: Bienvenida a los cambios en requisitos, incluso en etapas tardías del desarrollo. Colaboración : Colaboración estrecha y diaria entre el equipo de desarrollo y los clientes.  Comunicación : Comunicación cara a cara como el método más eficaz de transmisión de información.  Sostenibilidad : Desarrollo sostenible, manteniendo un ritmo constante.  Simplicidad : Simplicidad como arte de maximizar la cantidad de trabajo no realizado.  Reflexión : Reflexión regular sobre cómo ser más eficaces, ajustando el comportamiento en consecuencia.  Como vemos, la agilidad no se limita solo a los métodos de desarrollo de un producto, sino a una filosofía más amplia que abarca la gestión y cohesión de equipos, incluso desde un nivel emocional, y un cambio radical en la mentalidad sobre la relación con el cliente, la manera de supervisar el trabajo de las personas y las prioridades al evaluar el progreso de un proyecto. 

11. Lectura recomendada En el siguiente enlace puedes acceder al manifiesto original: Manifiesto por el desarrollo Ágil de software (s.f.). Disponible  aquíLinks to an external site. . 

12. 1.2. Marco de trabajo Ágile más comunes: Scrum y Kanban Quizás se hayan fijado en que utilizamos la expresión “marco de trabajo” y no “método” o “metodología”. Esto es porque, como ya has aprendido, lo importante es que los equipos se autorregulen y que examinen sus procesos, rituales y herramientas y adaptarlos a su realidad para mejorar de forma continua. Cualquier método puede ser algo cerrado, y es precisamente lo que la agilidad no quiere: recetas rígidas que seguir al pie de la letra. Por este motivo, el marco de trabajo, o  framework  en inglés, es el concepto que mejor describe el conjunto de pautas y filosofías suficientemente definido como para servir de guía de trabajo, pero lo bastante abiertos como para que cada cual lo interprete y aplique a su manera. Entre los panoramas Ágil, Scrum y Kanban destacan dos como los marcos más populares. SCRUM: Conocido por su estructura de  sprints   y roles definidos. Se enfoca en la planificación y ejecución iterativa. KANBAM: Por la gestión visual del flujo de trabajo, ya que promueve la eficiencia y flexibilidad.  

13. Ambos marcos, con sus enfoques característicos, proporcionan soluciones flexibles para la gestión de equipos y proyectos, promoviendo la colaboración y la mejora continua.    Dado que Scrum es ampliamente adoptado como el marco Ágil de referencia y que cada vez más empresas buscan roles especializados, certificaciones y conocimientos de esta metodología seguiremos explorando la agilidad a través de su principal exponente. Así, garantizamos que se familiaricen con los conceptos y directrices de Scrum, requisito esencial en entornos de innovación y desarrollo de proyectos actualmente. Pero antes, queremos revisar Kanban una de las herramientas más célebres y muy útil para tu día a día.   

14. Como vemos es algo tan simple como tener de una forma visual y organizada listas de tareas.  En su versión más simple estas podrían ser: PENDIENTE, EN PROCESO, TERMINDO. Esta versión tiene una lista de “prioridades” que facilita el proceso de seleccionar con qué nuevas tareas comenzaremos cuando se terminan las anteriores. Si tenemos un listado demasiado amplio de tareas pendientes, podremos distinguir las tareas críticas, porque tienen un plazo determinado de entrega o porque sin ellas no podemos abordar otros procesos. Esta herramienta es muy útil tanto para el trabajo individual como en equipo. Lo más interesante cuando se utiliza en equipo es que ayuda a visualizar el estado del proyecto y flujo de trabajo. Por ejemplo, quiénes ven lo que se está haciendo, quién lo hace y en qué estado están las tareas. Además, ayuda a detectar cuellos de botella. Kanban nos propone tres claves a la hora de utilizar este sistema: Limitar el trabajo en curso o WIP ( work  in  progress ) : Para evitar abordar más trabajo del que se puede, mantener la eficiencia, concentración y ritmo de trabajo. Menos, es más.  Visualizar los estados: Como decíamos, esta herramienta se basa en la visibilidad, tiene que permitir entender de un vistazo el estado del proyecto.  Medir para la mejora constante: Kanban propone implementar un mecanismo de mejora continua mediante la medición el ciclo de tareas:   Lead time : el tiempo desde que se establece un objetivo (porque lo pide un cliente o porque iniciamos el proyecto) hasta que el proyecto está terminado/entregado.  Cycle time : el tiempo desde el que una tarea para a WIP hasta que es terminada.  Implementar algo tan sencillo tiene potentes efectos en la gestión de equipos y proyectos por su simplicidad, efecto visual y transparencia en la compartición de información. 

15. 2. Entendiendo la agilidad a través de Scrum Origen del término “Scrum” y su significado metafórico: " Scrum " un término que proviene del rugby y describe una formación donde los jugadores de ambos equipos se entrelazan y empujan para ganar control del balón.     Este concepto fue adoptado por Ikujiro Nonaka y Takeuchi en los años 80 para explicar un enfoque de trabajo en equipo que observaron en empresas tecnológicas como Fuji-Xerox, Canon y Hewlett- Packar .  Lectura recomendada: Estos autores, tras el análisis de estas empresas junto con su reflexión acerca de la organización de los equipos y su analogía con el rugby, publicaron en 1986 un artículo para Harvard Business  Review  “El Nuevo Juego del Desarrollo de Nuevos Productos” y que puedes leer aquí:  Links to an external site. Nonaka & Takeuchi.   The  New  New   Product   Development   Game , 1986, Harvard Business  Review.Links to an external site.      En 1995, Ken Schwaber y Jeff Sutherland, inspirados por esta idea, presentaron en la Conferencia sobre Sistemas y Aplicaciones de Programación Orientada a Objetos, la OOPSLA 95, el "Scrum development process ", aplicando la metáfora del  scrum  a la gestión de proyectos de  software .     “Scrum” es una traducción de la dinámica del rugby al ámbito tecnológico que simboliza la colaboración intensa y la estrategia coordinada de un equipo cohesionado para alcanzar objetivos comunes.

16. 2.1. La esencia de Scrum. Parte I 2.1.1. Equipos autogestionados Scrum se aplica a través de un enfoque de proyecto planificado en  sprints   o cortos periodos de tiempo, desde una semana a dos meses, durante los cuales el equipo de desarrollo trabaja de forma autogestionada y autosuficiente para completar las tareas seleccionadas, con el objetivo de producir una versión funcional del producto. Que el equipo trabaje de forma autogestionada y autosuficiente tiene muchísima trascendencia y es una parte muy importante de la esencia de Scrum. La autosuficiencia significa que el equipo debe tener todas las habilidades, recursos y competencias necesarias para desarrollar cada versión planificada del producto. Esta autonomía es clave para avanzar de forma eficaz y sin dependencias externas. En cuanto a la autogestión, implica que, durante el período de desarrollo, el equipo no tiene supervisión ni dirección externa, es decir, no hay un jefe de proyecto ni   project manager  que examine al equipo o le diga cómo organizarse ni lo que tiene que hacer. Para que esta autogestión sea posible es imprescindible que además de la autosuficiencia, el equipo trabaje la autoinspección.

17. Importante : Por esta razón, Scrum se presenta como un conjunto de directrices y herramientas, que incluyen roles, dinámicas y mecanismos, diseñados para promover la autoevaluación mediante la transparencia y la visibilidad del flujo de trabajo, así como la asignación y ejecución de tareas y objetivos laborales.  Este proceso es crucial para reducir la dirección externa, que puede llevar a cambios de rumbo y costosas interrupciones. La injerencia externa durante un  sprint  puede generar una pérdida de enfoque y efectividad, así como un incremento en el coste por cambio de tareas. La combinación de autogestión y autosuficiencia permite que los equipos trabajen de manera más enfocada y eficiente. En los equipos de Scrum la jerarquía es plana y no existe un jefe o director, las decisiones sobre cómo llevar a cabo su trabajo se toman de manera democrática basándose en el conocimiento que el equipo tiene de su propio desempeño, capacidad y ritmo productivo. Aunque se piense que este enfoque “asambleario” es una gestión de proyecto con menor control que en la forma tradicional de tener un director que evalúe y mida al equipo, la realidad es que, si de verdad se aplica el marco, el control sobre el trabajo, el rendimiento y la calidad es muchísimo mayor y no está limitado a las capacidades, conocimiento y disponibilidad de una única persona externa al equipo. Además, entre  sprints , se valida el trabajo con clientes o  stakeholders   para asegurar que el producto se alinea con las necesidades y expectativas, manteniendo así un equilibrio óptimo entre independencia y responsabilidad hacia el proyecto.  Estos clientes y  stakeholders  pueden ser internos o externos. 

18. Cliente: Un cliente interno sería representante de la propia empresa si el producto lo va a utilizar la empresa, como un sistema de gestión o de trabajo interno, o externo si es otra empresa quien lo ha pedido para utilizarlo o comercializarlo.  Stakeholders : Los   stakeholders  son personas o entidades que tienen algún tipo de interés e involucración relevante en el proyecto o empresa. Pueden ser clientes, managers, socios, inversores y otros, tanto externos como internos.  2.1.2.  Sprints  y desarrollo iterativo e incremental  Planificar en  sprints  es “trocear” el proyecto en ciclos iterativos, facilitando la adaptación y el aprendizaje continuo. Es imprescindible determinar qué funcionalidades del producto son más prioritarias, ya sea porque sean esenciales para la utilidad del producto, su nivel de criticidad respecto al éxito del producto o por motivos estratégicos como su potencial comercial, interés del cliente u otros.

19. Gracias a esta priorización se va abordando aquello más “ core ” o prioritario cuanto antes para lograr una primera versión funcional del producto y validar lo que el cliente quería. El testar que funciona e identificar fallos y errores técnicos o de planteamiento sirve para poder rectificar. En los siguientes  sprints  se retoma el desarrollo del producto aplicando los aprendizajes obtenidos. Se mejoran y corrigen las funcionalidades y utilidades de la primera versión del producto, es decir, se perfecciona, se refina y se asegura que encaja con lo que el cliente necesita. Además, en cada  sprint  se incrementa el producto, o sea, se añaden nuevas funcionalidades y características al producto. Por ello, todos los  sprints  finalizan con un incremento funcional de la versión anterior del producto, permitiendo al equipo y al cliente evaluar y ajustar el rumbo del proyecto basándose en resultados concretos y  feedback  real. Este enfoque, conocido como desarrollo iterativo-incremental, permite al equipo centrarse primero en construir una versión básica pero funcional del producto, a menudo denominada producto mínimo viable (MVP) y favorece la obtención de producto y aprendizaje temprano, en contraste con los enfoques tradicionales de larga planificación que postergan la entrega del producto final.

20. ¿A qué nos referimos con definir, priorizar y desarrollar funcionalidades del producto? Pongamos de ejemplo una plataforma para encontrar, comparar y reservar hoteles. Las "funcionalidades" se refieren a las características distintivas y operaciones que la plataforma puede realizar. Algunos ejemplos de funcionalidades para este tipo de producto podrían incluir: Búsqueda de hoteles: La capacidad de buscar hoteles por ubicación, fecha, número de huéspedes, etc.  Filtros y comparación : Herramientas para filtrar hoteles por precio, estrellas, servicios ofrecidos y comparar diferentes opciones.  Sistema de reservas: Una interfaz para seleccionar una habitación y completar la reserva.  Valoraciones y reseñas: Sección para ver y publicar opiniones y calificaciones de otros usuarios sobre los hoteles.  Gestión de cuentas de usuario : Funcionalidad para crear y manejar perfiles de usuario, incluyendo historial de reservas, preferencias y datos personales.  Para comenzar un proyecto Ágil debemos desarrollar las funcionalidades más críticas, como la búsqueda y reserva de hoteles, y luego se irían añadiendo progresivamente características adicionales como filtros avanzados, valoraciones y gestión de cuentas. Este enfoque iterativo y adaptable hace de Scrum un marco ideal para proyectos de producto digital en entornos cambiantes, donde la capacidad de responder rápidamente a las necesidades del mercado y del cliente es crucial.

21. 2.1. La esencia de Scrum. Parte II 2.1.3. Producto funcional y MVP En Scrum, el " producto funcional o valor " es lo que el equipo entrega al final de cada  sprint : una versión del producto que funciona y aporta valor al usuario. Este concepto está estrechamente relacionado con el "incremento del producto", que es la adición de nuevas funcionalidades al producto en cada  sprint . Se construye y mejora sobre la versión anterior y, por tanto, se hace crecer al producto basándose en el conocimiento y resultados obtenidos. Definición: El producto mínimo viable o MVP ( minimum  viable  product   por sus siglas en inglés) es la versión más básica del producto que aun así proporciona el valor crítico necesario para satisfacer a las necesidades del cliente y obtener retroalimentación y resultados de su funcionamiento técnico para futuras mejoras. Además, este MVP debería ser viable de comercializar. Es decir, el valor que proporciona debería ser suficiente para que el cliente esté dispuesto a pagar por ello. Siguiendo el ejemplo de las plataformas de comparación y reserva de hoteles, un MVP podría ser una plataforma donde lanzar una búsqueda y encontrar qué hoteles hay en la zona, sin poder acceder aún a ver las fotografías o a reservar desde la plataforma, estas serían funcionalidades incrementales que se irían añadiendo más adelante conforme se ha asegurado que la primera y más importante funciona. En Scrum, el desarrollo del MVP y los incrementos posteriores se realizan a través de los sprints , asegurando un desarrollo continuo y la adaptación a la viabilidad técnica y necesidades que soluciona.

22. 2.1.4. Maximización del  product-market-fit  y gestión del riesgo El concepto  product-market fit   se refiere al encaje entre las características y funcionalidades de un producto y las necesidades del usuario o cliente que va a pagar por ello, ya que, si un producto no satisface las necesidades de nadie, fracasaría en el mercado. Es ese  match  entre el mercado y el producto donde este satisface una demanda real, resolviendo problemas o cumpliendo deseos de los consumidores de manera efectiva y, por tanto, asegurando su éxito, venta y obtención de beneficios. En la agilidad y en Scrum, lograr el  product-market fit  es uno de sus pilares. A través de sprints cortos y ciclos iterativos, Scrum posibilita la entrega temprana de versiones funcionales del producto, permitiendo una validación constante con el mercado y ajustando el producto según la retroalimentación real de los usuarios. A diferencia de la planificación en cascada o el uso de diagramas de Gantt, donde el producto se desarrolla en fases sucesivas que convergen al final del proceso, el enfoque iterativo e incremental de Scrum reduce significativamente el riesgo.

23. En la planificación en cascada ( waterfall ), la falta de retroalimentación durante el desarrollo puede resultar en un producto que no cumple con las necesidades del mercado lo cual supone un riesgo enorme, ya que, si el producto no satisface la necesidad real o no funciona bien técnicamente, la inversión de tiempo, dinero y recursos que se han empleado serían en vano y con altos costes económicos, de reputación y moral en la empresa. En cambio, Scrum, con su enfoque en la validación y adaptación constantes, minimiza estos riesgos y maximiza las posibilidades de éxito en el mercado. En esta infografía se compara un enfoque Ágil con la metodología en cascada representando el nivel de riesgo y los momentos de entrega de valor.

24. En Scrum, la gestión del riesgo es como desactivar una bomba potencial: se minimiza con cada  sprint . El desarrollo del producto es un camino donde, con cada paso, el riesgo de invertir en algo que no funciona o no es necesario, crece. Imaginemos una bomba que crece según crece el producto. Al final de cada  sprint , Scrum permite un hito de validación y experimentación, probando no solo que el producto funciona técnicamente, sino que también cumple las necesidades del cliente. En comparación, el modelo en cascada es como ir creando una gran bomba de riesgo que no se resuelve hasta que llega “el momento de la verdad”, ya que el desempeño técnico y comercial del producto completo solo se revela al final, lo cual puede acabar en un desajuste entre el producto y el mercado. Este es el principal motivo del fracaso de productos y  start -ups . Gráficamente, el riesgo en una planificación en cascada sin hitos de validación se vería de este modo:

25. De este modo, el producto o solución que se entrega tras un desarrollo en cascada entrega un producto que lleva asociado un riesgo elevado. En el caso de Scrum, el riesgo en una planificación por  sprint  con hitos de validación se vería de esta otra manera: La cajita de regalo representa el valor o producto desarrollado. Observa como crece en cada  sprint , de ahí el concepto “incremental”.

26. 2.2. La Guía de Scrum Scrum se caracteriza por pautar una serie de roles, artefactos y eventos, que conforman el marco de trabajo y que se recogen en la Guía de Scrum. La Guía de Scrum podría considerarse como "la biblia del Scrum". Publicada por Ken Schwaber y Jeff Sutherland, dos de los principales ideólogos de Scrum en 2010, esta guía es el documento fundamental para quienes quieren entender e implantar Scrum, recoge de forma “oficial” toda su parafernalia, pautas y vocabulario.  Está disponible en  ScrumGuides.org Links to an external site . , donde se actualiza de forma frecuente para adaptarla a nuevas comprensiones y prácticas. Esta actualización es una declaración de intenciones sobre la naturaleza evolutiva que esta guía debería tener. El documento abarca los siguientes conceptos básicos que componen el ciclo de Scrum: Roles fundamentales, Artefactos, Eventos. Existe cierto debate entre la interpretación y aplicación más “ortodoxa” de este documento, los exámenes para certificaciones de Scrum.org son buenos ejemplos de ello. Sin embargo, existe el cuestionamiento de que una interpretación tan cerrada puede entrar en contradicho con la filosofía Ágil, ya que emplea marcos de trabajo abiertos que se pueden adaptar a los propios equipos.

27. 2.2.1. Roles De acuerdo con la Guía de Scrum, estos son los roles y cometidos: Scrum master: Este rol es el mentor y facilitador del equipo Scrum. Es similar al de un director de orquesta. Asegura que cada sección siga la partitura de Scrum, pero sin tocar ningún instrumento. Se enfoca en eliminar obstáculos y fomentar una comunicación fluida, garantizando que el equipo se adhiera a los principios de Scrum.  Product   owner : Actúa como el representante de los intereses del negocio y los usuarios. Se asemeja al traductor. Interpreta las necesidades del mercado y los  stakeholders   para el equipo y establece las prioridades en el  product backlog  para atender a esas necesidades. Su visión guía la construcción del producto y asegura que se alinee con las expectativas del cliente y los objetivos del negocio. Equipo de desarrollo: Son los artesanos del producto, un equipo autoorganizado y multifuncional. Podemos imaginarlos como un grupo de profesionales que colaboran para construir un edificio, donde cada uno aporta sus habilidades únicas. Deciden cómo abordar las tareas y trabajan juntos para entregar incrementos de calidad del producto.  Stakeholders : Incluyen a todos los que tienen un interés en el proyecto, como usuarios, clientes y patrocinadores. Son esenciales para proporcionar retroalimentación y ayudar a priorizar las funcionalidades, asegurando que el producto final cumpla con sus necesidades y expectativas.  Cliente: Es el destinatario final del producto. Representa no solo a los usuarios finales, sino también a quienes van a pagar por él, que no siempre son la misma persona (imagina un producto que compran unos padres, pero usan sus hijos/as).  Sus necesidades y expectativas son cruciales para el éxito del producto, y el equipo de Scrum trabaja para satisfacerlas de la mejor manera posible. 

28. 2.2.2. Artefactos Los artefactos en Scrum, tal como se detallan en la Guía de Scrum, son elementos clave que apoyan la planificación y seguimiento del progreso del proyecto: Product  backlog : Es una lista ordenada de todo lo que se necesita en el producto, y es el único origen de los requisitos para cualquier cambio a realizar en el producto. El  product   owner   es responsable de su contenido, disponibilidad y ordenación.  Sprint backlog : Consiste en los elementos seleccionados del  product  backlog  para el  sprint , más un plan para entregar el incremento del producto y alcanzar el objetivo del  sprint .  Incremento: Es la suma de todos los elementos del  product  backlog  completados durante un  sprint  y todos los anteriores. Al final de estos, el nuevo incremento debe estar en una condición de "hecho", lo que significa que está listo para ser usado y cumple con la definición de "hecho" del equipo.  Vamos a explicar aquí otro elemento que, si bien no se refleja en la Guía de Scrum como uno de los artefactos, es de suma importancia para la implementación práctica de Scrum.

29. Historias de usuario  Como se ha explicado, uno de los mecanismos de la agilidad es “trocear las cosas”. La manera en la que se dividen las funcionalidades de un producto digital, y que es una manera válida para otro tipo de soluciones son las historias de usuario. La historia de usuario consiste en crear una tarjeta (física o virtual) que complete la siguiente plantilla: Como (ROL) quiero hacer (FUNCIONALIDAD) con el objetivo de (BENEFICIO). Esta es una manera muy sintetizada de expresar las funcionalidades del software o las utilidades y características de cualquier servicio. Ejemplos, digitales o no: Como usuario que busca un hotel online quiero poder comparar precios y servicios entre varios hoteles de una zona con el objetivo de tomar una decisión y reservar. Como huésped del hotel quiero poder saber dónde aparcar el coche para hacer el check -in con el objetivo ahorrar tiempo y evitar confusiones. Como recepcionista del hotel quiero poder acceder a la ficha de reserva del nuevo huésped con el objetivo de saber si ha realizado una petición especial y tenerla en cuenta. A la hora de trabajar de forma Ágil es importante acompañar a la historia de usuario de estos cinco elementos:

30. DESCRIPCIÓN: Contexto para los diferentes perfiles que trabajarán en ella. VALOR: El valor estimado, en una escala del 1 al 10, que se prevé que genere esta funcionalidad al usuario. ESTIMACIÓN: Estimación de cuánto tiempo/esfuerzo llevará el desarrollo de esta función. Se suele medir en unidades de desarrollo (métrica del mundo software) o puntos de historia, que son puntuaciones numéricas que le da el equipo en función de la dificultad que estiman. Para ello utilizan técnicas como el poker planning que se explica más adelante. DEPENDENCIAS: Hay que tener claro si esta historia de usuario depende de que otras se ejecuten antes. DEFINICIÓN DE TERMINADO: DOD ( definition of done), criterios consensuados entre el cliente y el equipo para decidir cuándo se pueden dar por terminadas estas historias de usuario. El equipo, al planificar el sprint, decidirá sobre qué historias de usuario va a trabajar y definirá cuáles son las tareas necesarias para completar una historia de usuario.

31. 2.2.2. Eventos Sprint: Es el corazón de Scrum, un periodo de tiempo fijo (generalmente de dos semanas a un mes) donde el equipo se enfoca en alcanzar los objetivos establecidos.  Planificación del  sprint : Aquí el equipo decide qué trabajo se realizará durante el  sprint . Se determina su objetivo y se seleccionan los elementos del  product  backlog  para trabajar. 

32. Daily  scrum: Una reunión diaria de no más de 15 minutos donde el equipo comparte lo que hizo ayer, lo que planea hacer hoy y los obstáculos encontrados. Es un momento clave para la sincronización del equipo.  Revisión del  sprint : Al final del  sprint , el equipo y los  stakeholders   revisan lo que se ha completado y discuten los próximos pasos. Es una oportunidad para obtener  feedback  y hacer ajustes.  Retrospectiva del  sprint : En este evento, el equipo se autoevalúa en términos de qué ha funcionado bien y qué no durante el sprint. Se buscan maneras de mejorar en el próximo  sprint . Es un espacio para la reflexión y el crecimiento colectivo. 

33. Línea temporal de los eventos:

34. 2.3. La práctica de Scrum 2.3.1. Planificación y estimación Ágil En la planificación y estimación Ágil, el equipo evalúa el esfuerzo necesario y determina el trabajo a realizar. A través de distintas técnicas de estimación, el equipo consensúa una estimación del esfuerzo necesario para la ejecución de las tareas para llevar a cabo las historias de usuario del  backlog . Según esta estimación, se decide qué se abordará en el nuevo  sprint  y qué se deja después. Para llevar a cabo la estimación se utilizan métodos participativos como el  planning poker  para estimar la complejidad de las tareas.

35. El  planning poker  es una técnica colaborativa que facilita la estimación del esfuerzo necesario en las tareas de un proyecto Scrum. Comienza con la creación de cartas que representan la carga de trabajo, inspiradas en la secuencia de Fibonacci para reflejar complejidad o tiempo. La secuencia de Fibonacci es una serie numérica donde cada número es la suma de los dos anteriores, comenzando por 0 y 1 (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144…). Esta secuencia se emplea para asignar valores a las tareas, reflejando su complejidad o el tiempo estimado para completarlas. Los números más bajos indican tareas más simples o rápidas, mientras que los más altos señalan mayor complejidad o duración. Durante la reunión, tras la presentación de cada historia de usuario por el  product owner  o  scrum master , el equipo discute y aclara dudas. Luego, el equipo vota a la vez utilizando las cartas para estimar el esfuerzo. Si hay desacuerdo, se debate y se vuelve a votar hasta alcanzar un consenso, permitiendo una planificación precisa del sprint basada en un entendimiento común.

36. 2.3.2. Gestión del  backlog  y el  sprint La gestión del  product backlog  y los  sprints   son un proceso continuo. El  product owner  mantiene y prioriza el   product backlog , en función de las necesidades y el contexto del proyecto: Objetivos estratégicos Mayor entrega de valor temprano Funcionalidades críticas, etc. Durante la planificación del  sprint , el equipo selecciona tareas para trabajar, centrando sus esfuerzos en entregar un incremento valioso y de calidad al final del  sprint . Durante el  sprint,  el equipo de desarrollo lleva a cabo su trabajo sin la interferencia de otros  stakeholders . No está permitido que alguien pueda detener el proceso para pedir un cambio o una nueva tarea. El  scrum master  será el encargado de “proteger” al equipo haciendo de muro de contención frente a los stakeholders externos. Si sucediese algo demasiado grave o crítico, será el  product owner  quien decidirá si debe de detenerse el  sprint .

37. 2.4. Aplicar Scrum en entornos no tecnológicos

38. 3. Combinar Agile con Design Thinking y Lean Startup para generar innovación

39. 3.1. Design Thinking

40. 3.2. Cómo aplicar design thinking . Parte I El  desing thinking  ha derivado en disciplinas como diseño de servicios, diseño de negocios, diseño de experiencias ( customer experience , employee   experience ,  user experience …) y ha alimentado muchas disciplinas y procesos relacionados con el  marketing  y el  branding . Cada una de estas subespecialidades tiene sus propias herramientas. En este apartado hemos hecho una selección y repasaremos las más generalistas y estratégicas.

41. 1. Descubrimiento / empatía / investigación (divergencia) Se busca recopilar la máxima información posible para entender el problema y a los actores que intervienen, tanto el afectado principal (puede ser usuario, cliente o empresa) como  stakeholders  del entorno y cualquier factor influyente del contexto.   Esta fase de inversión en el problema es crítica para el éxito del proyecto.  ¿Cómo ponerlo en práctica? En primer lugar, distingamos entre tipos y fuentes de información.

42. Tipos de información La información cualitativa  se refiere a descripciones detalladas que exploran temas en profundidad sin centrarse en los números. Este tipo de información captura aspectos como opiniones, emociones y experiencias, y es fundamental para comprender los "porqué" y "cómo" detrás de ciertos fenómenos.  La información cuantitativa , por otro lado, se basa en cantidades y se presenta en forma de números y estadísticas. Este tipo de información permite comparaciones y análisis, ofreciendo una visión objetiva y medible de los datos.  Fuentes de información Las fuentes primarias  son aquellas que proporcionan datos originales o información directa, sin interpretación ni modificación. Ejemplos incluyen entrevistas, encuestas, y observaciones directas.  Las fuentes secundarias  interpretan, analizan o resumen la información obtenida de fuentes primarias. Ejemplos de estas son artículos, libros, documentales, entrevistas publicadas, informes y reportes. 

43. La recomendación es combinar los tipos y fuentes de información de la siguiente manera:

44. A continuación, dejamos un pequeño listado de las principales técnicas de investigación, en su mayoría cualitativas. Te recomendamos buscar más información de cómo planificar y ejecutar estas técnicas antes de iniciar un proceso de investigación. Entrevistas con profundidad: Conversaciones detalladas uno a uno para explorar las percepciones, opiniones y experiencias de los participantes sobre un tema específico. Encuestas: Herramienta cuantitativa que utiliza cuestionarios para recoger datos de un grupo grande de personas sobre diversos temas. Focus group : Discusión grupal dirigida para obtener percepciones y opiniones sobre un tema específico. Observación etnográfica: Técnica de investigación cualitativa que implica la inmersión en un entorno o comunidad para observar comportamientos y prácticas en su contexto natural.

45. Service safari: Exploración en campo de servicios para experimentar y analizar la interacción del usuario con diferentes servicios. Shadowing : Seguimiento de una persona durante su jornada para observar de cerca cómo interactúa con productos o servicios en su vida cotidiana. Mystery shopping: Técnica encubierta en la que los investigadores se hacen pasar por clientes para evaluar la calidad del servicio o la experiencia de compra. Desk research : Investigación secundaria que implica la recopilación y análisis de datos existentes, como informes, estudios, documentales y otras fuentes de información.

46. Esta última técnica,  desk research ,  nos puede dar información de fuentes secundarias tanto cualitativas como cuantitativas de cualquier aspecto que estemos estudiando. Hay dos tipos de análisis que es recomendable hacer: Benchmarking  competitivo : Comparación de productos, servicios y procesos de una organización con los de sus competidores más fuertes para identificar áreas de mejora.   Análisis del entorno: Estudio de los factores externos (sociales, tecnológicos, económicos, ambientales y políticos) que pueden afectar a la temática de estudio. 

47. 2. Definición / síntesis (convergencia) No podemos afrontar algo que no está definido. Es el momento de sintetizar la información obtenida en hipótesis, hechos, problemas, oportunidades y retos. El “reto de diseño”, que explicaremos más adelante, es la pieza angular del proceso, pues condensa todo lo aprendido hasta el momento y dispara la ideación y desarrollo de soluciones. Según la técnica de clasificación podemos dividir en: Hallazgos sorprendentes ( insights ). Áreas de oportunidad. Problemas. Dolores, ganancias y motivaciones del usuario. T écnicas y herramientas  Nuevamente, te recomendamos buscar más información, así como plantillas, ejemplos e instrucciones detalladas para cada herramienta. 

48. Herramientas de empatía: Mapa de  stakeholders : Es una herramienta muy simple que permite identificar a los actores que hay en torno al reto, desde aquellos más implicados o afectados a aquellos más alejados pero conectados de algún modo. Tener mapeados a estos actores nos ayudará posteriormente a decidir en quiénes podemos tener un impacto positivo de aportación de valor, o de quiénes dependemos (para conseguir permisos, información, etc.), con quién debemos negociar, a quién preguntar, qué aliados o enemigos podemos tener, etc.  Ficha persona : Es un personaje ficticio con una narrativa de vida que nos ayuda a empatizar con él y salir de nuestras propias lógicas. Esta narrativa, aunque ficticia, es una condensación de todo lo real aprendido durante la investigación.   Lo importante es que la narrativa refleje las casuísticas reales de un perfil de usuarios. Algunos datos en concreto no podrán ser extrapolables (como la edad o lugar de residencia), pero el resto, será la esencia que caracteriza a un colectivo de personas.   El objetivo de esta narrativa es crear un personaje creíble para empatizar, recordarlo y siempre tenerlo en mente durante el proceso o volver a él al plantearnos si vamos por el buen camino. 

49. Mapa de empatía: Complementa la ficha persona profundizando en lo que ve, lo que oye, lo que piensa, lo que dice, lo que hace, etc.  Se puede y debe ampliar con necesidades, motivaciones, dolores o frustraciones, ganancias o satisfacciones, miedos, etc.  Point  of   view : Sirve para sintetizar la información obtenida expresándola desde el usuario, distinguiendo entre la necesidad y la razón subyacente ( insight ).  Customer   journey : Esta herramienta es versátil, nos sirve tanto para hacer síntesis, a modo de diagnóstico ( as is ), como para diseñar ( to be ).  Ilustra los pasos que va dando un usuario en su camino "hacia algo", analizando en cada momento cómo es la experiencia y elementos de contacto. 

50. Herramientas de estrategia de negocio Además de este foco en el usuario, es importante no perder de vista que las personas forman parte de sistemas y entornos sujetos a influencias.  En el área relacionada con negocio encontramos las siguientes herramientas:  Curva de valor DAFO (FODA) PESTEL Fuerzas de Porter Herramienta que compara la oferta de una empresa con la de sus competidores basándose en factores clave que valora el mercado, identificando oportunidades para innovar y diferenciarse. Análisis estratégico que identifica las debilidades, amenazas, fortalezas y oportunidades de una organización, proporcionando una visión interna y externa para la toma de decisiones. Marco que examina las fuerzas políticas, económicas, sociales, tecnológicas, ecológicas y legales que pueden afectar a una empresa o industria, ayudando en la planificación estratégica. Modelo que analiza cinco fuerzas competitivas que modelan cada industria y mercado: rivalidad entre competidores existentes, amenaza de nuevos entrantes, poder de negociación de proveedores y clientes, y amenaza de productos o servicios sustitutos, para entender la dinámica de la competencia y las estrategias corporativas.

51. El reto de diseño La fase de síntesis acaba con la formulación del reto o retos de diseño. El reto de diseño es la piedra angular del proceso, ya que condensa todo el conocimiento y conclusiones obtenidos hasta el momento y dispara la creatividad e ideación. Un reto de diseño se formula empezando por "Cómo podríamos...". A ser posible, debemos centrar el reto en el usuario: "Cómo podríamos conseguir (aliviar los dolores seleccionados) a (usuario para el que diseñamos) para (proporcionar X ganancia). Esta verbalización es bastante poderosa, ya que implica dos aspectos que predisponen a los equipos: Dar por hecho que es posible resolver el reto. Incita a pensar en el cómo, no en "sí o no". Incita a pensar en segunda persona del plural, "nosotros".

52. Ejemplo Ayudando a una empresa aseguradora a mejorar uno de sus productos de seguros. Imaginémonos un seguro de salud.  El mercado más joven, de 18 a 25 años, tiene muy baja aceptación por motivos económicos, ya que no tienen presupuesto, y culturales, debido a que quienes no tienen que lidiar con alguna enfermedad crónica no entienden que el mercado tenga un seguro así.  Posibles maneras de establecer el reto de diseño podrían ser: ¿Cómo podríamos facilitar a jóvenes con bajo poder adquisitivo el acceso al seguro de salud? ¿Cómo podríamos hacer que el seguro de salud fuera más útil y atractivo para personas jóvenes que no sufren de ninguna enfermedad crónica?

53. 3.2. Cómo aplicar design thinking . Parte II 3. Ideación (divergencia y convergencia) Una vez tenemos claro el desafío que afrontaremos y los hechos que configuran el contexto, podemos empezar a buscar soluciones. Dentro de la ideación abordaremos dos momentos:

54. Divergencia  Cuantas más técnicas de pensamiento lateral y más involucración de diferentes perfiles multidisciplinares e incluso de personas ajenas al proyecto o representantes de los usuarios de estudio, más posibilidades de dar con soluciones innovadoras.  Técnicas para una sesión de creatividad.  Recuerda buscar más información sobre cómo aplicarlas si vas a llevar a cabo una sesión de este tipo.  Brainstorming :  Generación colectiva de ideas sin restricciones, donde se promueve la creatividad y la innovación en equipo.  Brainwriting :  Similar al  brainstorming , pero las ideas se escriben individualmente y luego se comparten con el grupo, evitando el sesgo de conformidad.  " What if ..." : Método de pensamiento especulativo que explora escenarios alternativos y soluciones innovadoras mediante preguntas hipotéticas.  "La peor idea para..." : Inversión creativa que anima a pensar en las peores soluciones posibles, estimulando el pensamiento lateral y descubriendo ideas valiosas de manera indirecta.  Técnica   SCAMPER:  Acercamiento creativo que utiliza siete estrategias (sustituir, combinar, adaptar, modificar, poner en otros usos, eliminar, reorganizar) para mejorar productos o servicios existentes. 

55. Convergencia Tras generar un gran listado de ideas posibles llega el momento de aplicar criterios para quedarnos con algunas posibilidades que guíen el proceso. Para las siguientes técnicas de priorización recomendamos dar instrucciones a los participantes para que tengan en mente criterios como: Impacto  que crean que pueden tener cada idea en la resolución del problema. Esfuerzo necesario  para llevarla a cabo. Es decir, tener en cuenta el tiempo, complejidad, inversión y capacidades que requieren.  Factibilidad técnica , descartemos ideas que no son factibles técnicamente.  Viabilidad económica . Pensemos en si la idea tiene potencial de generar ingresos capaces de superar al esfuerzo económico de desarrollarla.  Deseabilidad,  ¿Es deseable para el usuario o cliente? ¿Y para nosotros y la empresa? ¿Y para el planeta y la sociedad?  Dotmocracy   o   Telescoping .  Método de votación que permite a los participantes expresar su preferencia entre opciones usando puntos o " dots ". Facilita la identificación de las ideas más populares o prioritarias.  Dinámica de los 100 $ . Técnica que asigna a cada participante una cantidad simbólica de dinero para "invertir" en las diferentes opciones disponibles, mostrando cuáles son valoradas como más importantes o valiosas. MoSCoW . Método de priorización que clasifica las tareas o requerimientos en cuatro categorías:  Must have  (esenciales),  Should have  (importantes, pero no esenciales),  Could have  (deseables, pero no necesarias), y  Won't have  (no se harán en este ciclo), permitiendo un enfoque claro en las necesidades críticas. 

56. Estas técnicas son muy rápidas e intuitivas de llevar a cabo, pero a veces necesitamos un poco más de rigor a la hora de evaluar y presentar resultados. Para ello podemos llevar a cabo ejercicios más extensos y complicados como un índice ponderado o un  business case . A continuación, podremos conocer una herramienta intermedia que permite, no solo evaluar y priorizar, sino también generar una hoja de ruta para implementar las distintas iniciativas que finalmente se seleccionen. Matriz de priorización Consiste en dibujar una matriz, con dos ejes que representan:  Impacto  Esfuerzo  Si en cada eje distinguimos entre nivel alto y nivel bajo, nos quedan los siguientes 4 cuadrantes: 

57. Alto impacto bajo esfuerzo: Quick wins   o victorias rápidas, ideas de alto impacto y bajo esfuerzo. Lo ideal es acometerlas lo antes posible. Bajo impacto alto esfuerzo: Thankless tasks  o tareas ingratas. Dado que tienen muy poco impacto y conllevan un gran esfuerzo, lo mejor es descartarlas Alto impacto alto esfuerzo: Major projects  o grandes proyectos: son ideas cuya ejecución requiere de una planificación de proyecto con cronograma de fases y tiempos. Bajo impacto o bajo esfuerzo: Fill - ins  o ideas de relleno. Al tener poco impacto y requerir poco esfuerzo, no son especialmente críticas. Pueden agendarse en un plan más amplio, delegarse o quitarles prioridad.

58. A la hora de establecer el nivel de impacto o esfuerzo de cada idea podemos hacerlo de forma intuitiva y consensuada o hacer un análisis más riguroso en el que es posible establecer y puntuar criterios para definir “impacto” y “esfuerzo”. Algunas ideas destacadas son: Impacto : ROI estimado.  Incremento de métricas relacionadas con el problema (ej. índices de satisfacción de clientes, fidelización, etc.).  Grado de alineamiento con objetivos estratégicos.  Esfuerzo Tiempos y plazos.  Presupuestos e inversiones necesarias.  Grado de complejidad técnica. 

59. 4. Implementación / construcción (divergencia y convergencia). En esta fase volvemos a encontrar momentos de divergencia y convergencia. Se suele llamar a esta etapa «prototipado» ya que, una vez llegados a la solución óptima, lo recomendable es construir un prototipo barato y de funcionalidad básica, con el que poder testar si la solución funciona como habíamos previsto. Objetivo El objetivo es hacer tangible de alguna manera la idea con el fin de testarla y obtener aprendizajes con que alimentar una nueva fase de entendimiento y empezar así un ciclo iterativo en el que cada repetición nos lleva a una versión mejorada de la solución.  

60. A partir de aquí es muy efectivo utilizar un enfoque de Lean Startup, ya que se especializa en el ciclo de construcción, experimentación y medición para volver a construir, experimentar y medir. Más adelante veremos cómo Lean Startup da un paso más allá mediante productos mínimos viables, mientras que  design thinking  se queda en el testeo mediante prototipos. A menudo hay confusión entre el término “prototipo” y “producto mínimo viable (MVP)” es que ambas son versiones básicas del producto que sirven para validar y aprender, pero el MVP tiene que ser comercializable y el prototipo no. Un prototipo puede ser una aplicación esbozada en un papel, la representación teatral de un producto o cualquier manera de hacer tangible y experimentable una idea. El primer paso antes de lanzarse hacia un prototipo o MVP es llevar a cabo una conceptualización detallada de la idea que estamos manejando. Design thinking , y en concreto su vertiente más relacionada con la estrategia de negocio, el diseño estratégico, propone algunas herramientas para conceptualizar y diseñar que podrían considerarse prototipos, ya que obligan a construir, aunque sea de modo conceptual. Este ejercicio de conceptualización nos ayuda a detectar errores de planteamiento, barreras o desafíos y a tomar decisiones de calado en la posterior construcción de la solución. Vamos a ver tres herramientas para pasar de la idea a una conceptualización detallada y al diseño de su modelo de negocio y funcionamiento operativo. En otras palabras, qué es, por qué y para quién tiene sentido y cómo funciona.

61. Value   proposition   canvas : El  value proposition canvas  de Alexander Osterwalder es una herramienta para crear propuestas de valor asegurando que realmente solucionan las necesidades de un usuario. Consta de dos partes principales:  el perfil del usuario  y el  mapa de valor .   El perfil del usuario retoma lo trabajado en la ficha persona, el mapa de empatía y el POV. Ayuda a entender y tener presentes las necesidades, tareas y frustraciones del cliente, mientras que el mapa de valor se enfoca en cómo la empresa puede crear valor para el cliente a través de sus productos o servicios.   Se utiliza para identificar el encaje entre lo que el cliente necesita y lo que la empresa ofrece, facilitando un diseño de producto o servicio más centrado en el usuario.   

62. Business  model   canvas : El  business model canvas , también de Alexander Osterwalder, es una herramienta estratégica que proporciona un marco para desarrollar nuevos modelos de negocio o documentar y entender los modelos existentes.   Se compone de nueve bloques de construcción que cubren las áreas clave de una empresa: segmentos de clientes, propuestas de valor, canales, relaciones con clientes, fuentes de ingresos, recursos clave, actividades clave, alianzas clave y estructura de costes.   Permite visualizar, diseñar y reinventar el modelo de negocio de manera integral y cohesiva, promoviendo una comprensión clara de cómo cada elemento interactúa con los demás.  Es muy interesante, para validar el modelo, repasar el canvas después de completar la plantilla identificando qué de todo lo expuesto son asunciones, es decir, hipótesis sin comprobar, para inmediatamente articular experimentos que permitan validar estas asunciones.  En concreto, debemos buscar asunciones relacionadas con unos principios que ya hemos nombrado y que son coordenadas guía de  design thinking :  Deseabilidad:  ¿La solución es deseable por parte de su destinatario? ¿Y del resto de implicados? ¿Y por nosotros mismos? Estas asunciones las encontraremos en la parte derecha superior del  business model canvas , en las secciones de propuesta de valor, relación con clientes, canales y segmentos.  Factibilidad : ¿La solución es factible de implementar y mantener en términos técnicos, de logística, capacidades y recursos? Estas asunciones las encontraremos en la parte izquierda superior del lienzo, en las secciones “socios clave”, “actividades clave” y “recursos clave”.  Viabilidad:  ¿El planteamiento es económicamente viable? ¿El modelo de ingresos puede hacer frente a la estructura de costes resultante? Estas asunciones las encontraremos en la parte inferior del canvas , en “estructura de costes” y “fuentes de ingresos”.  Todo lo que hayamos establecido en esas casillas sobre lo que no tengamos certeza total que va a funcionar bien es una hipótesis para validar mediante experimentación.  Debemos diseñar un experimento por hipótesis, definiendo cómo verificaremos y mediremos que realmente es una hipótesis acertada y recogiendo e implementando el aprendizaje obtenido del experimento. 

63. Service   blueprint : El  service blueprint  es una herramienta de mapeo de procesos que detalla la relación entre los componentes de un servicio, incluyendo las interacciones del cliente, los procesos visibles e invisibles, y los puntos de contacto físicos o digitales.   Su uso permite visualizar la experiencia del servicio desde la perspectiva del cliente, identificando áreas de mejora, cuellos de botella y oportunidades de innovación.   Al desglosar el servicio en sus componentes fundamentales, permite diseñar o rediseñar servicios que mejoren la experiencia del cliente y optimicen la eficiencia operativa. 

64. 3.3. Lean Startup El método Lean Startup popularizado por Eric Ries con su libro “ The Lean Startup” en 2011, combina la esencia de otros métodos como “Desarrollo de Clientes” de Steve Black y “Lean Manufacturing ” de Taiichi Ohno. Lean Startup se centra en minimizar el desperdicio de recursos, validando rápidamente ideas de negocio para desarrollar productos que el mercado realmente necesita mediante un ciclo de “construir - medir - aprender”. Lean Startup se basa en la eficiencia y adaptación rápida a las necesidades del mercado y aborda el desafío de validar ideas de negocio mediante la creación de un producto mínimo viable o MVP ( minimal viable product ). El  leit motive  de Lean Startup refleja de forma muy entendible y práctica su filosofía:   “ Fail soon , fail cheap ” (Fallar temprano, fallar barato)

65. 3.4. Aplicación del Lean Startup Desarrollo de MVP Como hemos visto anteriormente, en Scrum, el MVP es la versión más básica y simplificada (mínimo) del producto, que ofrece la propuesta de valor principal (producto) y que puede ser comercializada, es decir, aun siendo básica, es suficiente como para que alguien pague por ella (viable). El MVP se hace para probar hipótesis clave con el menor esfuerzo posible e impactar en el mercado, generando clientes, ingresos y aprendizajes cuanto antes. Su objetivo es obtener aprendizaje validado sobre las necesidades del cliente, minimizando el riesgo y el gasto innecesario antes de seguir incrementando el producto. El proceso de desarrollo de un MVP pasa por identificar las características esenciales del producto, el valor  core , y lanzar una versión básica para probar en el mercado.

66. Experimentación y aprendizaje  Al igual que la agilidad y las fases de prototipado y testeo de  design thinking , Lean Startup propone un enfoque de prueba y error que se centra en experimentar rápidamente con ideas de producto, validarlas con usuarios reales y aprender de los resultados. Este proceso iterativo ayuda a dirigir el desarrollo del producto hacia lo que realmente demanda el mercado, asegurando el  product-market-fit .  Lean Startup apuesta por una experimentación constante como método para validar ideas y estrategias de negocio.   La experimentación implica probar las hipótesis del negocio que vimos en el  business model canvas  en condiciones reales del mercado, lo que permite validar la viabilidad y la aceptación del producto. Esta práctica es crucial para evitar invertir en ideas que no tienen demanda.  Esta experimentación puede ir desde hacer pruebas de concepto, simplemente preguntando a potenciales clientes sobre el problema que se supone que tienen o sobre qué les parece la solución que estamos planteando, a experimentos más sofisticados como crear una  landing   page  (página web plana de captación de formularios) y una pequeña campaña de  marketing  para medir cuántas personas se interesan en la idea de producto o servicio y entregan sus datos.  El ejemplo más extremo es la preventa, las “ preorder ” o el micromecenazgo . Sistemas como el popularizado por Kickstarter en el que se expone una idea de negocio o producto y aquellas personas interesadas compran por adelantado o invierten en ellas.  Conseguir intenciones de compra (formularios de clientes), o mejor aún, compras efectivas, antes incluso de haber lanzado al producto, son las métricas que mejor nos aseguran el éxito de un proyecto. 

67. Pivotar o perseverar  Un aspecto clave de Lean Startup es decidir entre pivotar (cambiar la estrategia) o perseverar (seguir con el plan actual) basándose en los resultados de las pruebas y el  feedback  de los clientes.  Esta decisión a tiempo es crucial para evitar invertir en el desarrollo de productos que no satisfacen las necesidades del mercado.  Pivotar significa realizar un cambio significativo en la estrategia del producto o del modelo de negocio en respuesta a los aprendizajes obtenidos. Esta decisión se toma cuando los datos indican que la estrategia actual no está funcionando como se esperaba.  Perseverar, por otro lado, significa mantener el curso actual, basado en la validación positiva de las hipótesis del negocio. Esta decisión se toma cuando los datos respaldan la estrategia y el modelo de negocio actuales.  La manera de tomar estas decisiones de pivotar o preservar es a través de los datos.   Para ello se establecen métricas clave o KPI ( key performance indicators ) para evaluar la obtención de resultados y progreso del negocio, así como recoger el  feedback  de los clientes.   Cada proyecto según su naturaleza tendrá sus propios KPI de medición. Los más habituales o recomendables tienen que ver con las tasas de conversión del proceso de venta, tasas relacionadas con la rentabilidad de los clientes y productos, ratios financieras, etc.

68. 3.5. Integración de design thinking , Lean Startup y Agile Recuperamos esta infografía del inicio del curso.

69. Probablemente, la primera vez que la viste te pareció algo difícilmente entendible, pero ahora ya entiendes los conceptos y el ciclo de trabajo que se representa. La integración de estos enfoques permite abordar desafíos complejos de manera holística, combinando la empatía del usuario y la creatividad del  design thinking , la eficiencia y la validación rápida del Lean Startup, y la flexibilidad y adaptabilidad de Agile para escalar el producto.  Design thinking  nos permite profundizar y analizar un problema y generar soluciones innovadoras con foco en el usuario. Lean Startup nos ayudará a convertir rápidamente y de forma económica estas soluciones en productos comercializables. Y por último, un marco de trabajo Ágil nos dará la oportunidad de seguir mejorando e incrementando el producto, siempre maximizando su valor y capacidad de adaptación. 

70. 4. Cuestiones éticas y responsabilidad en el diseño y desarrollo de productos Responsabilidad del diseño Cada producto o servicio impacta a personas y al mundo. Debemos preguntarnos: ¿Qué consecuencias tendrá lo que creamos? Impacto en la salud mental Las redes sociales están relacionadas con el aumento de problemas mentales en jóvenes. El diseño actual muchas veces explota sesgos y mecanismos de adicción. Consecuencias sociales La desinformación y la polarización son efectos negativos comunes. Empresas como Meta y Snap han tenido que responder públicamente por estos daños. Design for Permanence Propuesta de Alicia Chavero: diseñar pensando en el legado. No diseñamos para “otros”; lo que creamos también nos afecta a nosotros y nuestros seres queridos. Cambio de enfoque Del pensamiento extractivo al pensamiento sistémico y ético. Crear con propósito, sentido y responsabilidad más allá del beneficio económico.

71. Vídeo recomendado Te invitamos a ver el vídeo de su intervención completa  “Cómo usar el diseño estratégico para la construcción de producto”Links to an external site. https://www.youtube.com/watch?v=-MGeQziqFXI

72. Referencias Las siguientes referencias te servirán para profundizar en el contenido que hemos visto. Aunque es muy recomendable, su consulta no es obligatoria. Algunas de ellas pueden requerir suscripción previa. Referencias y recursos : Beck,B .;   Beedle , M.; Van Bennekum , A.; Cockburn, A.; Cunningham, W.; Fowler , M.; Grenning , J.;  Highsmith , J.; Hunt, A.; Jeffries, R.; Kern, J.; Marick , B.; Martin, R.; Mellor , S.;  Schwaber , K.; Sutherland, J. and Thomas, D. (2001). Manifesto for Agile Software Development . Retrieved from .  URLLinks to an external site.    Blank , S. and Dorf , B. (2012). The startup owner's manual: The step- by -step guide for   building a great company . K&S Ranch , Inc.  URLLinks to an external site.    Chavero, A. (2023). Cómo usar el diseño estratégico para la construcción de producto.Presentado en La Product Conf , Madrid.  Nonaka, I., and Takeuchi, H. (1986). The new new product development game . Harvard Business  Review .  URLLinks to an external site. .    Ohno, T. (1988). Toyota production system : Beyond large-scale production . Productivity    Press .  URLLinks to an external site. .   Osterwalder, A. and Pigneur, Y. (2010). Business model generation : A handbook for visionaries, game changers , and challengers . John Wiley & Sons .  URLLinks to an external site.    Ries, E. (2011). The lean startup: How today's entrepreneurs use continuous innovation    to create radically successful businesses . Crown Business.  URLLinks to an external site. .  Schumpeter, J. (1942). Capitalism , Socialism and Democracy . Harper & Brothers .  URLLinks to an external site.    Schwaber , K., y Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum:   The Rules of the Game .  URLLinks to an external site. .