• Author / Uploaded
• Marcos Vallejo

Citation preview

La siguiente obra está disponible a través de Caroli.org con el objetivo de ofrecer contenido para uso en investigaciones y estudios académicos, con el fin exclusivo de futura compra. Está completamente prohibida y totalmente repudiable la venta, o cualquier uso comercial del contenido presente. Usted encuentra este y otros libros y e-books gratuitos en www.caroli.org

Traducción y colaboración Patricia Trejo Traducción María Fernanda Escudero y Freddy Coronel Corrección de estilo Juliana Cury Rodrigues Proyecto gráfico y diagramación del cuerpo y tapa Vanessa Lima Revisión Nicole Haddad Desarrollo de eBook Loope Editora www.loope.com.br

Copyright © 2018 by Paulo Caroli Derechos exclusivos de edición © 2019, Editora Caroli. Avenida Itajaí, 310 – Barrio Petrópolis Porto Alegre, RS, Brasil – 90470-140 www.caroli.org/editora [email protected]

Catalogación en la Publicación (CIP) Angélica Ilacqua CRB-8/7057 Caroli, Paulo

Lean inception: creando conversaciones hacia un producto exitoso / Paulo Caroli; traducción y colaboración Patricia Trejo; traducción María Fernanda Escudero y Freddy Coronel. – São Paulo: Editora Caroli, 2019. Bibliografia ISBN 978-85-94377-09-8 1. Proyecto de producto 2. Planificación de productos 3. Planificación de producción 4. Planificación estratégica I. Título II. Trejo, Patricia III. Escudero, María Fernanda IV. Coronel, Freddy 18-1904

CDD 658.575

Las puntuaciones de catálogo sistemático: 1. Desarrollo de productos: planificación

AGRADEZCO a ThoughtWorks y ThoughtWorkers por inspirarme y utilizar mis actividades de Lean Inception. Estoy convencido de que este increíble contenido solo puede surgir cuando formas parte de un contexto muy específico. Mi agradecimiento especial a ThoughtWorks Brasil, mi país de origen y la cuna de este trabajo. Gracias a los que compartieron sus conocimientos sobre los talleres de inception e hicieron posible este libro. Mi agradecimiento especial a Jeff Patton y Jonathan Rasmusson, de quienes tengo el placer y el privilegio de aprender. Gracias a todos los que leyeron, utilizaron y compartieron sus comentarios sobre Lean Inception. Este contenido evolucionó debido a la gran retroalimentación y las experiencias compartidas. No fue hasta que me enteré del éxito que tuvieron otros facilitadores al aplicar este método que me di cuenta de que me encontraba ante algo especial. Gracias a Martin Fowler por entrenarme y por solicitar este contenido en inglés. Realmente aprecio su apoyo e incentivo al compartir prácticas importantes con nuestra gran comunidad, tales como Lean Inception.

Gracias a mi familia—Carolina, João, Duda y Fernanda—, por el amor y el apoyo que me ha dado mientras sigo leyendo y escribiendo, en búsqueda de aprender y compartir. Mi especial agradecimiento a João Caroli. Todavía recuerdo mi primer viaje después de que naciste. Siempre me ha gustado facilitar inceptions, pero te amo más y no podía estar lejos de ti por más de unos pocos días. Tuve que hacerlas más lean —sencillas— para volver más rápido. ¡Definitivamente me has inspirado!

Prefacio Presentación Lo que encontrarás en este libro Cómo surgió el libro que tienes en tus manos CONSTRUYENDO EL PRODUCTO CORRECTO

Desarrollo de un producto que importa Inception: el comienzo de un proyecto ágil ¿Por qué se llama Lean Inception? ¿Por qué una Lean Inception? La agenda de Lean Inception Producto mínimo viable El origen Incrementos del MVP Hipótesis pequeñas, grandes negocios

Un ejemplo de evolución a través del producto mínimo viable (MVP) Visión amplia, producto mínimo Valioso, usable y factible El factor “guau” Cuidado con romper Legado y bloques organizados Embudo de ventas — AARRR ¡Haz una lean inception! PREPARANDO EL TALLER

El taller (workshop) de Lean Inception Colaboración Diviértete con los “rompehielos” Colocación La sala de guerra Post-its coloridos El rol del facilitador Estacionamiento Las agendas La agenda burn-up Agenda de la semana Checklist para lean inception EJECTUANDO LEAN INCEPTION

Escribiendo la visión del producto

El producto Es/No es/Hace/No hace Aclarando el objetivo Entendiendo los trade-offs Describiendo a las personas Cuadrantes para identificar tipos de personas Creando mapas de empatía Actualiza el entendimiento sobre las personas Brainstorming de las funcionalidades (features) Muéstrame el dinero Funcionalidades, objetivos y personas Entendimiento técnico, de negocio y de experiencia de usuario Verificando el entendimiento con el gráfico del semáforo Tabla de esfuerzo, experiencia de usuario (UX) y valor de negocio Mostrando los viajes de usuario Exhibiendo las funcionalidades en los viajes Secuenciando las funcionalidades El secuenciador de funcionalidades El template del secuenciador Las reglas para cada onda Convergiendo reglas y viajes Identificando los MVP en el secuenciador de funcionalidades Calculando esfuerzo, tiempo y costo Detallando las funcionalidades de muestra en tareas Estimación comparativa

Entendiendo el costo y el tiempo Calculando el promedio de una onda Construyendo el canvas MVP Completando el canvas MVP El secuenciador de funcionalidades y el canvas MVP Foco en la propuesta Minimiza los riesgos con la segmentación de personas Mejora la experiencia en los viajes Reevalúa las funcionalidades del MVP Desarrollo impulsado por hipótesis Conversa sobre el costo y el cronograma La estrategia MVP ANEXOS

Ejemplo de una Lean Inception Kick-off Visión del producto El producto Es/No es/Hace/No hace Entendiendo los objetivos Identificando a las personas Descubriendo las funcionalidades Entendimiento técnico, de negocio y de experiencia de usuario Describiendo los viajes Exponiendo funcionalidades en los viajes

Secuenciando las funcionalidades Construyendo el canvas MVP Glosario Actividades rompehielos Localización geográfica Teléfono visual Uno dos ping cuatro pong Formando triángulos Zip Zap Zoom Desenredarse Piezas complejas Dibujo colaborativo de caras Espalda con espalda Encuentra tu par Referencias bibliográficas Sé un facilitador de Lean Inception Acerca de los traductores Sobre la Editora Caroli

U

na visión ingenua del desarrollo de software ágil es una donde todos se sumergen y comienzan a escribir el código sin pasar por un tiempo previo pensando en qué hacer.

Esta visión, tan errónea como simplista, se basa en un cambio genuino de pensamiento. Antes del ascenso de Agile, la gente seria de software aconsejaba períodos largos de recopilación de requerimientos y arquitectura, donde en un proyecto de cinco años podía pasar un año o dos antes de que se escribiese el código, y ni pensar el tiempo que se tomaba la producción. El mundo ágil ha descartado aquellos largos períodos de análisis previo, pero aún reconocemos que tiene valor establecer un sentido inicial de dirección. El desafío es descubrir cómo podemos hacer esto de forma rápida y eficiente, recordando, a su vez, que nada nos enseña lo que queremos para nuestro producto final como un producto incompleto que se lanza y está en uso. Por lo tanto, debemos compensar el ajuste de la dirección con el conocimiento de que un pensamiento así de anticipado es nuestra mejor opción. En ThoughtWorks, nuestra respuesta ha sido un proceso llamado inception. Reunimos una buena muestra de las personas que se verán afectadas por el producto y tenemos una sesión intensiva para establecer una dirección inicial, utilizando una serie de ejercicios que se centran en la colaboración y la identificación de objetivos generales. No intentamos realizar una especificación detallada, ya que es exactamente este tipo de cosa la que pasa a ser obsoleta tan pronto como el código llega a producción. Pero sí queremos entender qué tipo de resultados estamos esperando, las funcionalidades que creemos conducirán a estos resultados y cómo evaluar la efectividad de nuestro producto.

Con Lean Inception, Paulo ha captado su experiencia en la ejecución de estas inceptions en la última década. En particular, se centra en su trabajo para pulir la inception hasta su esencia, concentrando la actividad en una única, pero muy intensa, semana de trabajo. Paulo comparte cómo lleva a cabo este trabajo a través de la escritura de una visión de producto, captando personas, entendiendo los viajes de usuario y desarrollando funcionalidades de alto nivel. El resultado no es un plan de trabajo detallado, ya que consideramos que este se vuelve rápidamente irrelevante. Es un conjunto guía de objetivos para llevarnos en la dirección correcta. No planifica un producto final, con todas las funcionalidades que nuestros usuarios necesitarán, sino que, en vez, se enfoca en un producto inicial que podemos lanzar y del cual podemos aprender: el mínimo producto viable (MVP). Este producto actúa como punto de partida para evolucionar hacia un producto más rico y capaz, utilizando las lean inceptions para ayudar con cada paso de esta evolución. En este libro, encontrarás la experiencia que Paulo ha cosechado después de seis años de efectuar estas lean inception. Hay un tabla para las actividades de la semana, detalles de los ejercicios que se realizarán y consejos para ayudar al equipo a aprender del lanzamiento del mínimo producto viable (MVP). Los esfuerzos de la semana se resumen en un canvas MVP que actúa como un producto simple y un resumen del trabajo. Empoderado con la experiencia de Paulo, puedes practicar esta técnica y modificarla para que se adapte a tus circunstancias. MARTIN FOWLER Chief Scientist da ThoughtWorks. martinfowler.com

LO QUE ENCONTRARÁS EN ESTE LIBRO De principio a fin, ¡este es un libro corto y práctico! Como su título lo dice: lean1, directo al punto. Por ende, hay que leerlo todo, de inicio a fin. El libro está estructurado en cuatro partes: “Construyendo el producto correcto”, “Preparando el taller” y “Ejecutando Lean Inception”. Al final, están los anexos. CONSTRUYENDO EL PRODUCTO CORRECTO Para comenzar, cuento mi historia con las inceptions y por qué creé el concepto de Lean Inception. Este libro está basado en el concepto de MVP, producto mínimo viable (minimum viable product, en inglés). El capítulo que trata este tema presenta el concepto y su historia, así como mi visión de MVP y de la evolución de los productos lean. PREPARANDO EL TALLER Esta segunda sección explica en detalle el formato de taller colaborativo que te ayudará a entender, alinear y planificar el producto que será construido. Quizás sea el comienzo de un proyecto ágil en una gran empresa o el alineamiento sobre qué construir en una pequeña startup. El estilo colaborativo y dinámico de Lean Inception es el ingrediente secreto del chef en esta receta. EJECUTANDO LEAN INCEPTION Lean Inception es una receta, una secuencia de actividades colaborativas y dinámicas que construirán el canvas MVP, una representación visual de la evolución de un producto lean y del plan de creación. Cada paso de esta receta es detallado siguiendo el orden de los subcapítulos, comenzando con “Escribir la visión de producto” y finalizando en “Construir el canvas MVP”. ANEXOS

Los apéndices pueden ser revisados antes, durante o después de la lectura del libro. El primer apéndice presenta un ejemplo real del entendimiento y la planificación de un producto lean, a partir del resultado de un taller de Lean Inception realizado en un entrenamiento de ocho horas. Después hay un glosario de términos y algunas actividades rompehielos.

CÓMO SURGIÓ EL LIBRO QUE TIENES EN TUS MANOS “The Lean Startup es la guía para la innovación del siglo XXI. Las ideas ahí contenidas ayudarán a crear la próxima revolución industrial”, nos dice Steve Blank2 refiriéndose al libro de Eric Ries The Lean Startup (2011), y concuerdo plenamente con él. Es más, el desarrollo de productos basado en el concepto de producto mínimo viable (MVP) es el pilar principal para esta nueva revolución. Esto porque, como explicita Eric Ries en su libro, el producto mínimo viable es una pieza clave del ciclo construir-medir-aprender, como se muestra en el diagrama de abajo, donde el MVP está representado como el artefacto a ser construido.

Una vez construido, el producto mínimo viable es puesto a prueba para así tener datos que posibilitarán medir su uso y, por lo tanto, generar el aprendizaje deseado. En este sentido, considero el modelo basado en las hipótesis de Jeffrey Taylor, Jeff Gothelf y Josh Seiden sumamente eficiente para describir lo que estamos buscando medir y aprender con el MVP. Por ejemplo, hace tiempo que llevo usando el siguiente modelo:

Hasta ahora todo claro… Sin embargo, ¿cómo saber exactamente qué producto construir? Y es que, si bien en el movimiento de Lean Startup encontré buenas respuestas sobre cómo aprender y medir el uso del producto mínimo viable, sentía que faltaba algo para guiarme sobre “qué construir”. Fue así como surgió Lean Inception. Al experimentar con diferentes actividades de inception y buscar apoyo en Design Thinking, creé una secuencia de actividades para ayudar a un equipo a definir las funcionalidades o features del MVP. A continuación, compartí esa secuencia de actividades —como una receta a ser seguida— con algunos colegas, los cuales me confirmaron su utilidad. Pedí feedback, busqué mejoras, realicé alteraciones, e incluso hice pequeños ajustes en la nomenclatura. Después de compartir con cientos de personas y trabajar con la retroalimentación recibida, surgió —y evolucionó— el taller de Lean Inception:

una secuencia de actividades para la creación de productos de forma lean fuertemente influenciada por Design Thinking y Lean Startup. Desde entonces comencé a escribir entradas en un blog (en 2010), dictar talleres, compartir apuntes, e incluso publiqué un e-book antes de que surgiera la primera edición del libro impreso en portugués, Direto ao ponto, en 2014. Un año después: opiniones, mejoras y la segunda edición de Direto ao ponto. Desde 2015 en adelante comencé a compartir más sobre Lean Inception en inglés y en español (a través de entradas en blogs y e-books). En 2016 comencé a escribir el artículo “Lean Inception” en el sitio web de Martin Fowler3. A partir del feedback del propio Martin y de varios colegas —entre ellos Jonathan Rasmusson y Jeff Patton, quienes influyeron especialmente en mi trabajo con inception, y muchos colegas de ThoughtWorks— mejoré la estructura y el vocabulario del artículo y de Lean Inception. Esto me llevó a publicar el libro Lean Inception en inglés, con una nueva organización y más contenido. El conocimiento de los efectos positivos y el entusiasmo de tantos facilitadores de Lean Inception que compartieron conmigo su impresión, además del excelente trabajo y alianza que hicimos con Patricia Trejo para traducir el texto al español, ¡resultaron en el libro Lean Inception que ahora tienes en tus manos! Y ahora… ¿qué más? Continúo muy involucrado con las lean inception y, al enfocarme en el producto mínimo viable, acabé tocando algunos asuntos relacionados con él, como transformación digital, innovación, emprendimiento, estrategia, entrega continua, DevOps, entre muchos otros. Como puedes ver, existen muchos contenidos ligados a estos términos, pero he querido mantener este libro lean. Sin embargo, podrás encontrar información sobre ellos en mi sitio web, en otros e-books y publicaciones. Revisa las novedades en www.caroli.org. ¡Feliz lectura y bienvenido al grupo de facilitadores de Lean Inception!

1 La metodología Lean fue desarrollada por Taiichi Ohno y Shigeo Shingo (entre 1950-1980) para el sistema de producción de Toyota, con el objetivo de obtener una producción ajustada y sin desperdicios. En inglés significa “magro”, sin grasa. 2 Steve Blank es emprendedor y académico de Emprendimiento en Silicon Valley, California, Estados Unidos. 3 Disponible en: www.martinfowler.com/articles/lean-inception/. Acceso en agosto de 2018.

DESARROLLO DE UN PRODUCTO QUE IMPORTA Los proyectos ágiles hacen énfasis en las entregas rápidas y frecuentes de software de alto valor, de acuerdo con los objetivos del negocio y las necesidades de los usuarios principales. La creación de un producto lean promueve la liberación incremental del producto mínimo viable (MVP), una versión más simple de un producto que puede estar disponible para el negocio. Pero, ¿cómo entender el MVP y comenzar un proyecto ágil lo más rápido posible? ¿Cómo garantizar que el equipo comience la creación del producto con un buen alineamiento inicial y un plan eficaz? He diseñado Lean Inception para responder a estas preguntas. INCEPTION: EL COMIENZO DE UN PROYECTO ÁGIL Un agilismo ingenuo no conlleva trabajo por adelantado, pero en la práctica nos damos cuenta de que tenemos que hacer algo. Para ThoughtWorks4, inception es ese “algo”. Desde que me uní a ThoughtWorks en 2006, me di cuenta de que todos los proyectos ágiles de la compañía comenzaban de manera similar. El equipo del proyecto se reunía durante algunas semanas, realizando muchas actividades antes de comenzar el trabajo de entrega: esto era la inception. La inception de ThoughtWorks fue desarrollada principalmente por Luke Barrett alrededor de 2004. Jonathan Rasmusson (autor de The Agile Samurai) y Jeff Patton (autor de User Story Mapping) trabajaron en ThoughtWorks por un tiempo, y describieron y desarrollaron técnicas de inception en sus libros, de las cuales aprendí mucho. Nuestras inception varían de un proyecto a otro, pero generalmente generan un alineamiento entre el negocio y los trabajadores técnicos, y crean una lista ordenada de historias de usuarios con estimaciones junto a un plan de lanzamiento.

Por mucho tiempo estuve satisfecho de facilitar de esta manera las inception ágiles… hasta el 2011, año en que nació mi hijo. El problema era que, si bien yo era el facilitador inicial, la inception en sí tomaría de dos a cuatro semanas y no podía quedarme fuera de casa por más de una semana. Tuve que hacer inceptions más lean, para hacerlas calzar en una semana. Recuerdo que iba en mi primer viaje después de que nació mi hijo, en un largo vuelo desde São Paulo a San Francisco, cuando leí por primera vez el libro The Lean Startup de Eric Ries. A partir de ahí encontré la excusa perfecta para reducir la duración inicial y regresar a casa después de tan solo una semana. ¿POR QUÉ SE LLAMA LEAN INCEPTION? Este nuevo estilo de inception es definitivamente un cambio desde el inicio de 2006. El equipo ya no escribe ni estima historias de usuarios. Al experimentar con este nuevo estilo, el nombre de inception dio a todos el mensaje errado. Necesitaba un nombre diferente. El nuevo estilo de inception es lean por dos razones: 1.La duración de la inception es más corta, eliminando todo lo que no sea sobre el producto (como arquitectura, proyecto, etc.), lo que hace que sea lean. 2.El resultado final de la inception es la comprensión del producto mínimo viable (MVP), un concepto fundamental en el movimiento Lean Startup. Por lo tanto, el nuevo estilo de inception tenía un nombre claro: Lean Inception. ¿POR QUÉ UNA LEAN INCEPTION? Una lean inception es útil cuando el equipo necesita desarrollar un producto mínimo viable (MVP) iterativamente. Aunque el término a menudo es malentendido, la propiedad central de un MVP es que es algo que construimos para saber si vale la pena seguir construyendo un producto. Por lo que elegimos funciones que se basan en probar nuestras suposiciones de lo que es valioso para

nuestros usuarios. Para esto debemos entender quiénes son nuestros usuarios, qué actividad realizan de tal manera que el producto les dé soporte y cómo medir si es que les resulta útil el producto. Después de facilitar más de trescientas lean inception y acompañar diversos proyectos e iniciativas antes y después del taller, descubrí que es muy valiosa, principalmente, en dos situaciones: 1.Los proyectos grandes encuentran que una lean inception es valiosa para comenzar rápidamente y orientarse para trabajar en un estilo lean. Tal inicio construye iteraciones tempranas diseñadas para descubrir y probar qué características son realmente valoradas por sus usuarios. 2.Las organizaciones más pequeñas (como las startups) usan Lean Inception para tomar una idea que ha sido probada por algunos MVP presoftware y desarrollarla en un producto de software. Este taller es específicamente sobre la comprensión de un producto mínimo viable (MVP) y, por tanto, no sustituye las sesiones de ideación, la investigación de clientes, la revisión de arquitectura o el análisis competitivo. Es una técnica específica que es parte de la comprensión de lo que se necesita para construir un producto exitoso. Exactamente cómo calza con estas otras actividades depende mucho del contexto específico de tu organización y del esfuerzo de desarrollo en el que estás trabajando. LA AGENDA DE LEAN INCEPTION Lean inception consiste en una serie de actividades, generalmente programadas en el curso de una semana. Explicaré cada actividad en la sección del libro llamada “Ejecutando Lean Inception”. LEAN INCEPTION - EJEMPLO DE AGENDA

Este es un ejemplo de agenda, por lo que no se debe considerar como algo fijo. Sin embargo, es bueno tenerlo en mente, ya que es un buen ejemplo de cómo pueden fluir las cosas.

PRODUCTO MÍNIMO VIABLE Una nueva forma de crear y desarrollar productos, entregando solamente el mínimo viable, ha sido fundamental para ayudar a miles de emprendedores a lanzar productos fantásticos. Es cosa de considerar los casos de éxito como iPhone, Facebook, Spotify, Airbnb, EasyTaxi, entre muchos otros. Sus creadores trabajaron de esta forma desde el inicio de los tiempos, cuando aquellos productos aún no eran (mega) famosos. Y es que entregar el mínimo viable te ayudará a llevar a tu producto al mercado de forma mucho más rápida, a minimizar sus gastos y a desarrollar el producto basado en la necesidad real de tus usuarios. La idea de crear solo el mínimo viable de un producto tiene un nombre y un sobrenombre: producto mínimo viable (nombre completo) y MVP (sobrenombre, proveniente de la abreviación en inglés, minimum viable product). Un MVP es la versión más simple de un producto que puede estar disponible para validar un pequeño conjunto de hipótesis sobre el negocio. Básicamente,

nadie quiere desperdiciar tiempo, dinero y esfuerzo construyendo un producto que no va cumplir sus expectativas. Por esta razón se necesita entender y validar la hipótesis acerca del negocio. Un MVP ayuda a validar y aprender de la manera más rápida. A diferencia de los productos creados de la manera tradicional, que usualmente toman mucho tiempo y esfuerzo en prototipos, análisis y elaboración, el objetivo del MVP es solamente validar el primer paso, el mínimo producto, el cual es mucho menos elaborado que la versión final. El MVP se enfoca en el producto mínimo, pero más viable, para verificar si la dirección es la correcta, como también en el conjunto inicial de funcionalidades necesarias para la validación de la hipótesis y para aprender más acerca del negocio. EL ORIGEN La idea del producto mínimo viable (MVP) se relaciona, desde sus orígenes, con las ideas que se volvieron populares gracias al estilo de producción de Toyota. Steve Blank, un emprendedor de Silicon Valley, creó una metodología basada en el desarrollo del cliente. Ese fue el inicio del movimiento Lean Startup, que alcanzó su punto culminante con Eric Ries y su libro que lleva el nombre del movimiento. Si bien Eric Ries popularizó el concepto de MVP desde la publicación de su libro The Lean Startup, la expresión ya se utilizaba varios años antes de que el movimiento apareciera, especialmente entre las startups con sus emprendedores e inversionistas de Silicon Valley. La expresión producto mínimo viable apareció por primera vez en el 2000 en un artículo de Willian Junk, que se titulaba “El equilibrio dinámico entre costo, cronograma, características y calidad en el desarrollo de software”. INCREMENTOS DEL MVP

Utilizar el producto mínimo viable (MVP) no implica que el producto no vaya a evolucionar ni mejorar sus funcionalidades. Por el contrario, la idea detrás del MVP es la mejora del producto guiado y validado por los resultados iniciales. La corrección o confirmación del curso es lo que va a guiar los siguientes incrementos. Estos incrementos son, a su vez, los MVP: nuevos productos mínimos agregados al producto mínimo ya validado que nos permitirán tomar decisiones acerca de la evolución del producto final. El producto ahora es extendido, tal vez con una base de datos con más usuarios, permitiendo la validación de nuevas hipótesis, incluso más elaboradas. Es muy importante comprender que el MVP promueve una creación evolutiva. Por lo tanto, la arquitectura como también las herramientas de construcción del producto deben permitir esta característica de evolución progresiva y continua.

En el 2010, Jez Humble y David Farley publicaron el libro Entrega continua. En este, los autores discuten un proceso de entrega rápido y de bajo costo, que permite la creación de productos de software de manera incremental. Ellos definen Entrega continua como una disciplina del desarrollo de software que promueve entregas más rápidas y frecuentes. A pesar de que el libro de Entrega continua entra en detalles acerca de productos de software y el flujo de trabajo para su creación, la idea esencial de la entrega continua es la misma que Eric Ries recomienda en su libro The Lean Startup: ciclos rápidos para validar las hipótesis. Ciclos rápidos y frecuentes permiten períodos muy pequeños de liberación y con bajos costos de experimentación. Sin embargo, no es fácil implementar este tipo de enfoque y, por lo demás, los creadores de productos al estilo MVP van a necesitar diferentes estructuras y prácticas de aquellas utilizadas tradicionalmente para un producto con un ciclo lento. Este libro se enfoca en actividades de análisis y planeamiento efectivo basadas en el producto mínimo viable (MVP). Entrega continua es una especie de Biblia para entender las herramientas necesarias para la creación y evolución de productos de software. Pero, tal como las técnicas y aprendizajes compartidos por los autores de Entrega continua pueden ser aplicados para otras clases de productos, y no solo para productos de software, lo mismo sucede con el contenido de este libro. HIPÓTESIS PEQUEÑAS, GRANDES NEGOCIOS El producto es construido incrementalmente, con los MVP recién creados y siendo agregados al producto sólido existente. Con los incrementos de MVP, la entrega continua e incremental proporciona un aumento de valor del producto a través del tiempo, mientras el proceso de creación de productos tradicionales no proporcionará un valor sino hasta el final, cuando todo el producto está listo.

Está figura muestra cómo un producto mínimo viable (MVP) ofrece pequeñas validaciones a lo largo del tiempo, mientras que un estilo de creación de producto tradicional solo ofrece una validación de todo el conjunto al final. Ahora bien, no te dejes obnubilar por este ejemplo, porque los productos reales no son tan simples como ir de un paso a otro de forma relativamente similar. Imaginemos otro ejemplo de producto mínimo viable: el MVP para cruzar un río. Una simple solución para cruzar una pequeña corriente es colocar un tronco de madera atravesado de borde a borde. Y esta sencillez lo hace un gran MVP, pues además de permitir cruzar la pequeña corriente del río, es una manera simple de validar la ubicación para construir el puente. Incluso, se podría colocar más de un tronco de madera en diferentes ubicaciones, y así validar cuál tiene un mayor uso. Como se puede ver, el producto mínimo viable promueve una aproximación incremental en la cual solo una pequeña parte de la hipótesis general es tratada al mismo tiempo. Cada una de estas hipótesis es diseñada, creada y preparada para ser añadida al producto, con el objetivo de generar información útil para su propia toma de decisiones, aprendizaje y validación. En esencia, una idea (o grandes hipótesis de negocios) es secuenciada en una serie de hipótesis menores, más simples y, por tanto, más fáciles de entender.

Gracias a ello, las hipótesis simples son elaboradas más rápidamente y consiguen estar disponibles en el producto para el usuario final. Por ejemplo, si hubiese un puente en este lugar, ¿cuántos peatones lo usarían en una semana? En este caso, el usuario final (o quien valide el MVP) proporciona información para la validación de los incrementos del producto. Esta validación es esencial por dos razones: (1) las correcciones y cambios pueden ser realizados en una fase inicial del producto, en vez de aparecer al final de la conceptualización, reduciendo el riesgo del mismo; (2) la complejidad del análisis de la hipótesis se reduce. De esta manera, tanto los creadores del producto como los usuarios finales tienen un acceso temprano a algo funcional y viable, permitiendo que la decisión de los siguientes pasos e incrementos del producto sean basados en el producto mismo, en vez de ser simples hipótesis de otras hipótesis. Este patrón de trabajo, basado en pequeños incrementos del producto y su hipótesis, permite construir productos mucho más elaborados en pequeños pasos, pero bien fundamentados. UN EJEMPLO DE EVOLUCIÓN A TRAVÉS DEL PRODUCTO MÍNIMO VIABLE (MVP) El producto es construido incrementalmente, con los MVP recientemente creados siendo agregados al producto consolidado ya existente. La última liberación de MVP tiene un resultado positivo. Luego el equipo continúa la evolución del plan del MVP creando el siguiente conjunto de características para la próxima liberación del MVP.

Esta figura muestra como un producto mínimo viable proporciona pequeñas validaciones a lo largo del tiempo, mientras que una creación tradicional del producto solo valida el producto final, enfocándose en la última versión del mismo, que en este caso sería una máquina cortacésped con más implementos. Como vemos, la tijera de cortar pasto es la primera versión del MVP. ¿Hay césped que cortar? ¿Hay alguien que pueda manipular un simple aparato de cortar césped? La validación de estas hipótesis conduce a la evolución del producto al siguiente MVP, que esta vez puede ser algo más conveniente: un aparato cortador de césped con un cable. Pero, ¿qué tal si le añadimos ruedas? Y así sucesivamente va evolucionando el producto de un MVP a otro MVP. El feedback más importante y valioso es aquel que contiene una respuesta negativa. ¿Hay césped que cortar? No. En este caso, las tijeras no son necesarias. Ahora bien, un cortacésped eléctrico caro, por bonito y sofisticado que sea, tampoco es necesario. La hipótesis es falsa, por lo que un producto completamente desarrollado habría sido una gran pérdida de tiempo y dinero. Este ejemplo ilustra cómo el producto mínimo viable promueve una aproximación incremental en la cual solo una pequeña parte de la hipótesis general es tratada al mismo tiempo. Cada una de estas hipótesis es diseñada, creada y preparada para ser añadida al producto. En esencia, una idea (o grandes hipótesis de negocios) es secuenciada en una serie de hipótesis menores, más simples y, por tanto, más fáciles de entender. Y vale la pena recordar que, afortunadamente, el software no es como la manufactura. En el mundo del software, un cortacésped puede ser creado agregando ruedas, volante, motor y asiento a una simple tijera de cortar pasto. VISIÓN AMPLIA, PRODUCTO MÍNIMO Es importante que tengas una visión amplia del producto: completo, abarcador, con diversas funcionalidades para muchos tipos de usuarios, cubriendo muchos

objetivos del negocio. Sin embargo, aunque es importante pensar en grande, para ello debes comenzar pequeño. Da un pequeño paso y aprende a partir del mismo. Ese pequeño paso es lo que llamamos el producto mínimo viable (MVP). El MVP sirve para validar hipótesis, para fallar y aprender rápido. En este contexto, menos es más. ¡No desperdicies tiempo, dinero y esfuerzo creando el producto equivocado! En pocas palabras, ¡piensa en grande, comienza pequeño, aprende rápido! Si bien el producto puede satisfacer más de un objetivo de negocio, ser útil para varias personas y tener muchas funcionalidades, un MVP debe validar una hipótesis, comprobar una idea y verificar si se logra lo que era esperado. Es que, como su nombre lo indica, M es de mínimo, por lo que se trabaja una sola hipótesis a la vez, un pequeño aspecto del negocio, para un segmento específico de usuarios, con apenas una o pocas funcionalidades. En la siguiente imagen puedes ver la representación de un producto elaborado a través del producto mínimo viable. Cada cajita es un MVP validado por medio del feedback de uso, del interés del negocio y de las posibilidades técnicas.

Como ves, el producto va creciendo y teniendo más funcionalidades (representadas en la imagen como cajas apiladas). Esto ocurre de MVP en MVP o, mejor aún, de MVP validado en MVP validado. En otras palabras, cada incremento

del producto tiene que ser validado. ¡No agregues al producto algo que no haya sido validado! VALIOSO, USABLE Y FACTIBLE El producto mínimo viable (MVP) está en la intersección entre lo valioso, lo usable y lo factible, representando, respectivamente, por el interés del negocio, la aceptación (y admiración) de los usuarios del producto y lo que es posible construir.

Valioso:personas de negocio piensan en el valor comercial de un producto. Generalmente, esas personas tienen una visión de negocio y piensan en los MVP como un paso a paso incremental para la creación del producto. En este contexto, las personas de negocio influyen en el MVP para que, aun siendo mínimo, alcance el retorno en la inversión esperado (o por lo menos demuestre que está en la dirección deseada para el negocio).

Usable:toda y cualquier funcionalidad debe ser elaborada según las necesidades, los deseos y las limitaciones de los usuarios. Algo usable está basado en una comprensión explícita de las personas, sus tareas y de los ambientes en que están insertos. Factible:la solución propuesta para satisfacer el negocio y a los usuarios solo tiene sentido si es ejecutable, si existe la tecnología y el conocimiento para su elaboración. No tiene sentido definir un MVP si no se sabe cómo será construido. EL FACTOR “GUAU” El factor “guau” es aquello que diferencia tu producto en el mercado, que conquista a los usuarios y los transforma en ávidos promotores de tu producto. Aquello que literalmente hace que las personas digan “¡guau!”. Pensemos en el iPhone cuando recién fue lanzado. Tenía el factor “guau”. Sus usuarios decían: “¡Guau! Una pantalla touch completa... ¡Mira qué genial!”. O bien, en las primeras personas que pidieron taxi a través de un sitio: “Guau, fue solo colocar mi dirección, dar clic en OK y el taxi llegó”. Si el factor “guau” es importante para un producto exitoso, para un MVP ¡es aún más importante! Basta ver el ejemplo del iPhone 1, el producto mínimo viable del iPhone. El iPhone 1 no tenía aplicaciones de terceros (y la plataforma de aplicaciones tampoco estaba lista). Tampoco tenía integrado el GPS y las llamadas eran peores que en los teléfonos del momento. Sin embargo, el iPhone 1 tenía el factor “guau”. Las personas lo usaban y daban feedback. Sus usuarios —los early adopters— eran los principales promotores del producto. Gracias a ello, las personas hicieron fila para el lanzamiento del iPhone 2, del iPhone 3, y así sucesivamente. Todo debido al factor “guau”, que transforma a los usuarios en promotores, generando expectativa y deseo para el próximo incremento. Lo mismo debe suceder con los MVP. Cada uno de ellos debe contar con los factores: factible, valioso, usable y “guau”.

La ilustración de arriba reitera la importancia de esos cuatro factores —factible, valioso, usable y “guau”— en cada producto mínimo viable (MVP). El MVP es una delgada porción del producto, conteniendo cada uno de esos factores. Por tanto, no se debe pensar el MVP como una capa del producto (la figura de la izquierda), donde primero se entrega lo que es factible para después elaborar de manera sucesiva los otros factores, y solo al final buscar el factor “guau”. Muy por el contrario, hay que construir el MVP como se representa en el lado derecho de la imagen: una delgada porción de la visión del todo que contempla simultáneamente los cuatro factores (factible, valioso, usable y “guau”). Entregar un producto mínimo viable no implica que vaya a ser malo, simplón o incompetente. No hay que confundir inconcluso con malo, simple con simplón, incompleto con incompetente. El MVP debe ser factible (de ser construido), fácilmente utilizable, generar mucho valor y ser increíble (¡guau!). Otro ejemplo de MVP con factor “guau” es Facebook. Al comienzo era necesario captar el interés de los usuarios, y para ello utilizaron el primer MVP. En las imágenes siguientes puedes ver el inicio de Facebook o, mejor dicho, el inicio de The Facebook. El inicio de Facebook ilustra la idea de una delgada porción de MVP. Puedes ver cómo siendo un producto simple, inconcluso e incompleto, aun así, era factible,

usable, tenía valor y era increíble. ¡Guau! Los usuarios querían más.

Reproducciones de pantallas de apertura y perfil de usuario de Facebook, en 2004.

CUIDADO CON ROMPER Los juicios iniciales sobre algo difícilmente cambian. La primera impresión es muy importante, y por ello quieres dejar una buena impresión de tu producto, de tu MVP. En pocas palabras, necesitas el factor “guau”. Y, de alguna forma, también quieres evitar lo opuesto: una falla que deje marcas. “Errar es aprender rápido”. Ten mucha cautela al usar esta frase. Después de todo, existen errores y errores, y nadie quiere un gran error, aquel que no tiene reparo y deja al cliente con una pésima impresión. Prefiero la frase “validar y aprender rápido”. Cuando se crea un MVP es para ayudar a validar algo, no para que el usuario se “quiebre” debido a un error del producto. Consideremos nuevamente el ejemplo del puente de madera. El MVP sirvió para validar si alguien atravesaría el riachuelo mediante una viga de madera. Este MVP también ayudó a identificar el mejor lugar para colocar esa viga de madera, ese puente. Pero el producto siguió evolucionando, y gracias a ello logramos validar cada MVP, cada hipótesis: ¿aquellos transeúntes en bicicleta o motocicleta también usarían ese puente de madera?, ¿y los vehículos de cuatro ruedas? Así, el puente fue evolucionando de MVP en MVP... ¡Hasta que se cayó! El puente de madera soporta el peso de los coches, pero no el de un camión y, por eso, ¡se cayó! Si hubieses proyectado y construido de forma tradicional, ya considerando todos los vehículos de la región, tal vez habrías construido desde un inicio un puente de hormigón y, de esta manera, el puente no se habría caído. Qué escenario más difícil, ¿no es así? Esta argumentación encubre los beneficios de trabajar con el Producto Mínimo Viable. Sin embargo, recuerda que el MVP tiene un V, de viable. El producto es mínimamente viable para algo. Un puente de madera que no soporta cinco toneladas no puede recibir ningún vehículo con más de cinco toneladas.

Sin embargo, colocar una placa que diga “peso máximo: cinco toneladas” no es suficiente. En su lugar se podría incluir una balanza antes del puente capaz de identificar un camión mayor a cinco toneladas. O, mejor aún, una balanza y una barrera que se cierre al identificar un vehículo con un peso mayor al permitido. Dos funcionalidades que, de haber sido agregadas al MVP, habrían evitado ese error. Ahora bien, si pasan dos camiones de tres toneladas al mismo tiempo, el puente se va a caer de todas maneras. Ante esta complejidad, ¿percibes la dificultad técnica? Y no solo la dificultad técnica, sino también de usabilidad y lo que supone el negocio. No trataré aquí la solución a este desafío. Este ejemplo es una metáfora útil para que reflexiones sobre tu producto mínimo viable. Es fundamental tener en consideración que las funcionalidades que previenen que se caiga el puente deben formar parte del MVP desde sus orígenes. Si no están contempladas estas funciones mínimas en el MVP, el producto liberado no es viable y, por tanto, sus usuarios no deberían haber sido expuestos a él. Necesitas validar tu MVP, ¡sin dejar que se caiga el puente! LEGADO Y BLOQUES ORGANIZADOS A veces, el producto es una nueva versión de algún legado, algo ya existente, pero que requiere mejoras. O bien el producto evolucionó tan rápido que su arquitectura, su estructura interna requiere ser organizada (y bien elaborada). Generalmente, productos en esta categoría son representados como bloques y capas lógicamente apiladas. El producto mínimo viable, aunque incompleto desde el punto de vista del producto final, debe respetar los bloques y capas que representan la estructura del producto.

Conforme se ilustra en la figura anterior, el producto mínimo viable no debe ser elaborado bloque a bloque hasta componer todo el producto, sino que debes elaborar tu MVP como se presenta en la imagen del lado derecho de la figura. Respeta la arquitectura, pero construye el MVP de extremo a extremo, con una experiencia completa. Es decir, el producto no es construido bloque a bloque, sino de MVP a MVP, de forma que los arquitectos de bloques (las personas técnicas que deciden las partes internas del producto) amplíen la estructura del producto conforme a la evolución del mismo. EMBUDO DE VENTAS — AARRR El embudo de ventas es una representación del flujo y de la cantidad de personas en tu proceso de venta, desde la adquisición hasta las referencias. AARRR (o métricas para piratas) es un acrónimo de métricas del embudo creado por Dave McClure para comprender y satisfacer mejor a los consumidores de tu producto o servicio. Las cinco métricas —Adquisición, Activación, Retención, Retorno (ingreso) y Referencia, que forman el acrónimo AARRR— representan las interacciones del cliente con tu producto. Según Dave, una startup exitosa es capaz de optimizar cada una de esas cinco métricas. Él recomienda que estas métricas se coloquen y analicen de forma separada.

» Adquisición: número de personas que adquirieron tu producto o servicio » Activación: número de personas que tuvieron una buena experiencia inicial » Retención: número de personas que volvieron para saber más » Retorno (ingreso): Número de personas comprometidas en actividades que generan ingreso » Referencia: número de personas que recomendaron tu producto o servicio a otros usuarios Un producto mínimo viable debe validar todas las etapas del embudo de ventas simultáneamente. La imagen de la derecha demuestra este caso, donde el MVP valida todo el embudo de ventas.

Cuidado con insistir en un negocio que no genera ganancias, un falso positivo. Un falso positivo es un producto que tiene un buen inicio, pero que nunca se convierte en un buen negocio con bastante retorno y recomendación. Este escenario está ilustrado en la imagen de la izquierda, donde un MVP contempla solamente una etapa del embudo de ventas. ¡HAZ UNA LEAN INCEPTION! Pero no es nada fácil elaborar un MVP. Como nos dice H. L. Mencken, “Para cada problema complejo, hay una respuesta clara, simple y errada”.

Para elaborar un producto mínimo viable se deben tener muchos factores en cuenta: tener una visión amplia del producto y del negocio, validar una hipótesis, hacer los incrementos, que sea factible, usable, valioso y “guau”, tener bloques que encajen adecuadamente, utilizar el embudo de ventas, etc. Pero no desesperes… este libro comparte años de experiencia ayudando a grupos de personas a alinear el MVP, de forma colaborativa y con sus diferentes perspectivas. Eso es lo que sucede en una lean inception. 4 Consultoría global en tecnología de la información (TI) que tiene como foco el desarrollo de software ágil.

EL TALLER (WORKSHOP) DE LEAN INCEPTION En solo una semana de trabajo colaborativo el equipo logrará entender los objetivos del producto, los principales usuarios y el alcance funcional a alto nivel, de tal manera que se pueda estimar la duración del proyecto e identificar una estrategia de lanzamiento incremental de los MVP. Durante una lean inception, se realizan actividades y dinámicas para definir objetivos, estrategias y el alcance del producto, así como para mapear y priorizar las características deseables a ser entregadas gradualmente, construyendo los MVP. El objetivo principal del taller es hacer que el equipo descubra y comprenda colectivamente lo que va a ser desarrollado. Al final, el equipo debería estar más integrado y con una visión más clara del camino a seguir. Lean Inception es una técnica para entender y planificar una entrega incremental de los MVP. Esta técnica organiza las ideas y funcionalidades en un modelo que busca entender la finalidad principal del producto, considerando los viajes de los usuarios y la entrega de valor de forma incremental. Como un libro de recetas, con una secuencia de actividades rápidas y eficaces, la técnica va a permitir que el equipo: » Describa la visión del producto » Priorice los objetivos del producto » Describa los principales usuarios, sus perfiles y sus necesidades » Entienda las principales funcionalidades » Comprenda los niveles de incertidumbre, esfuerzo y valor de negocio por funcionalidad » Describa los viajes más importantes de los usuarios » Cree un plan de entrega incremental del producto, impulsado por el concepto de MVP

A continuación, vamos a explorar los conceptos fundamentales de Lean Inception y, en la próxima sección, se tratará en detalle las actividades que tienen como objetivo cada uno de los propósitos recién mencionados.

COLABORACIÓN La colaboración es el acto de trabajar juntos para realizar una tarea y alcanzar objetivos comunes. El éxito de una inception está directamente relacionado con la capacidad del grupo de colaborar efectivamente en cada actividad descrita en este libro. Una inception propone un proceso colaborativo de descubrimiento y esclarecimiento en el que las personas involucradas trabajan juntas en una secuencia de actividades para conocer las opciones y elaborar los MVP. Las actividades presentadas en los capítulos que siguen representan métodos estructurados de colaboración, buscando un ambiente creativo, donde se comparte el conocimiento, hay aprendizaje y construcción de consenso. Las actividades buscan aumentar el éxito de los equipos, a medida que ellos se involucran en detallar y resolver cada paso hacia la construcción del MVP. DIVIÉRTETE CON LOS “ROMPEHIELOS” Nunca subestimes el poder de la diversión. A través de la diversión y de la risa, los niveles de estrés disminuyen significativamente y estarás mucho más abierto a trabajar con otras personas. Cuando se está feliz y relajado, hay una mayor apertura a intentar cosas nuevas y así aumentar la participación en este taller que es altamente interactivo: la lean inception. Las personas altamente involucradas, participativas y que se están divirtiendo, son más efectivas en las actividades colaborativas. Teniendo esto en mente, se necesita romper el hielo o elevar el estado de ánimo de los participantes. En este

sentido, los rompehielos ayudan a crear un ambiente amigable y a poner a las personas más cómodas para participar de las actividades de Lean Inception. Los rompehielos son actividades rápidas y divertidas que pueden ser ejecutadas para precalentar al equipo y promover la interacción del grupo. Son excelentes actividades para comenzar cualquier tipo de reunión de equipo. Son todavía más valiosas para los estados iniciales de construcción del equipo cuando las personas se conocen poco, lo que típicamente ocurre en la mayoría de las lean inception. Debes seleccionar una actividad rompehielos específica para el momento en cuestión. En los primeros días, recomiendo actividades que se enfoquen en compartir información, tales como nombres y pasatiempos. Para después del almuerzo, recomiendo seleccionar rompehielos para despertar a las personas. Y, finalmente, utiliza los rompehielos con mensajes simples, tales como “los sistemas complejos son más difíciles de manejar”, “si alineamos las fuerzas resulta más fácil alcanzar el objetivo” o “documentación escrita no es suficiente”. Además de ser divertidas y energéticas, las actividades rompehielos ayudan a transmitir mensajes importantes. A continuación, un ejemplo de rompehielos que es bueno para compartir nombres. En el anexo “Actividades rompehielos”, puedes encontrar más actividades de este tipo y algunas ideas. Paulo Puntual

Esta es una actividad corta para ayudar a los miembros del equipo a recordar los nombres de cada uno. El paso a paso de la actividad: 1.Solicítales a los participantes que piensen en un adjetivo que inicie con la misma letra de su nombre. 2.Forma un círculo y pide a cada participante que diga su nombre con el adjetivo, por turnos. Por ejemplo: “Hola, ¡yo soy Paulo Puntual!”.

3.Luego de que todos los participantes hayan hablado, pídeles ir en sentido horario diciendo el nombre y adjetivo de la persona a su lado. 4.Luego de unos pocos turnos, pide a los participantes repetir el paso tres, pero ahora en sentido antihorario. Además de compartir algunas risas y romper el hielo, esta actividad ayudará al equipo a asociar los nombres de las personas con un adjetivo, haciendo así más fácil el recordarlos.

COLOCACIÓN No subestimes el valor de la interacción cara a cara. Tecnologías innovadoras, como la videoconferencia y los documentos compartidos, facilitan el trabajo remoto entre las personas. Sin embargo, la interacción cara a cara durante la inception facilita el arduo trabajo en las actividades, garantizando que todos estén presentes y participando activamente. Cuando todos están en la misma sala, el nivel de participación aumenta. No puedes simplemente sentarte en una esquina y darle la espalda a la reunión para hacer otra tarea. Las reuniones cara a cara tienden a ser más cortas y eficientes que las reuniones remotas. El entendimiento es mejor y los malentendidos se resuelven. Las expresiones faciales y corporales se suman a la comunicación escrita y verbal. En general, las reuniones cara a cara ayudan al equipo a llegar al punto, ¡directo al punto! La secuencia de actividades para alcanzar el producto mínimo viable es extensa. La colaboración y los resultados obtenidos son positivamente sorprendentes cuando todos están físicamente en un mismo ambiente. Haz todo lo posible para tener a todos los involucrados en un mismo ambiente, interactuando cara a cara durante la inception. LA SALA DE GUERRA

Mantén una misma sala reservada para el equipo durante el intenso período de inception. Esta es comúnmente llamada “sala de guerra” o, en inglés, war room. La sala debe permitir que todo el equipo esté cómodo. Debe tener una mesa y paredes despejadas, una pizarra, papelógrafos, post-its de colores, papel y bolígrafos para todos. Una sala de guerra provee un ambiente para las actividades colaborativas. También evita cualquier pérdida de tiempo cuando las personas deben trasladarse de una sala a otra. Toda la información que ha sido creada permanece en un mismo lugar. Es importante mantener la información en una misma sala, ya que esto evita transportarla o generar documentación prematura. Todos pueden y deben hacer anotaciones a mano (tarjetas, post-its, papelógrafos, pizarra, etc.) y colocarlas en la pared y la mesa, de forma que estén visibles para todos.

POST-ITS COLORIDOS Haz las anotaciones en post-its o tarjetas coloridas. Escribe y colócalas en una mesa o en una pared. Reúne a las personas a su alrededor. Habla sobre las anotaciones. Escribe un poco más. Agrúpalas. Sepáralas. Rómpelas y escríbelas de nuevo. Haz uso de colores. Reorganízalas. La colaboración generada a partir de algo tan simple no puede ser emulada por cualquier alternativa digital.

No hay sustituto para la acción de escribir, reescribir, agrupar o rasgar post-its de colores. Esto promueve la interacción de las personas y ayuda en el proceso creativo de experimentación, donde el camino está siendo construido sin miedo a intentar, equivocarse o rehacer. En cambio, cuando la información se va al computador, nunca regresa al papel. Esto reduce la interacción entre las personas, pues no hay nada sobre la mesa o en las paredes, visible para todos y que pueda ser fácilmente rasgado, reagrupado o reescrito.

EL ROL DEL FACILITADOR Los talleres bien orquestados tienen algo en común: (1) alguien pensó en su estructura y (2) alguien los facilita. El resto del libro trata sobre una adecuada estructura para llevar a cabo una inception. Mientras que en esta sección comparto algunas reflexiones acerca del rol del facilitador. El rol del facilitador durante el taller de inception está enfocado en brindar una guía “liderando la discusión” de los participantes durante el taller. Para ello, el facilitador es una persona con mucha familiaridad y experiencia con el formato del taller, su naturaleza colaborativa y la secuencia de actividades que se llevarán a cabo. Pero ojo, el hecho de liderar la discusión no implica que el facilitador sea el participante principal, sino que más bien sirve como guía para propiciar el flujo de ideas y conversaciones activas entre todos los involucrados en el taller. Consecuentemente, el trabajo del facilitador se enfoca principalmente en lograr que los participantes del taller tomen responsabilidad, liderazgo y colaboración a lo largo de todas las actividades planificadas. ¿Y cómo lo logra? Aquí se presentan algunas características del trabajo del facilitador durante el taller: » El facilitador tendrá un mayor nivel de participación cuando explica el proceso de inception, introduce las actividades y también cuando responde dudas y preguntas respecto a lo que se espera durante el taller y sus actividades. » Durante las diversas discusiones que se llevarán a cabo, el facilitador debe tomar una posición completamente neutral, sin intervenir en absoluto durante la toma de decisiones. Por el contrario, el facilitador se centra en ayudar al grupo a seguir las actividades, identificar sus necesidades, solucionar sus problemas asociados y tomar decisiones al respecto.

» Para lograr lo anterior, el facilitador les da estructura a las actividades y a las interacciones de los participantes, de tal manera que puedan llegar a los resultados esperados en cada actividad de manera efectiva. » Durante todo el proceso de inception, utiliza diversas técnicas para dar fluidez a las conversaciones y cerrarlas alcanzando los resultados esperados (por ejemplo, un brainstorming5 o utilizar la técnica Pomodoro6). » Finalmente, el facilitador domina el uso de todo lo necesario en el taller: postits, papelógrafos, marcadores y, además, tiene una especial habilidad para organizar espacios, moviendo las sillas y dejando espacio en las paredes. En otras palabras, el objetivo del facilitador es brindar apoyo a los participantes para que ellos puedan desempeñarse de forma excepcional en cada actividad e interacción planificada para el taller, enfocándose en el proceso y en el contenido, y asegurándose de que este último sea generado de acuerdo a las expectativas y metas. Puedes ver algunas otras técnicas de facilitación para Lean Inception en www.caroli.org/ tecnicas-de-facilitacion-lean-inception.

ESTACIONAMIENTO El estacionamiento ayuda a archivar momentáneamente cualquier tema, idea o pregunta que sea planteada durante una actividad en una inception, para no discutirlas en ese momento específico. Es una herramienta esencial para el facilitador, pues proporciona una manera educada de decir “Sí, te escuché y vamos a revisar esto después”. “Estacionamiento” (parking lot, en inglés) es un término comúnmente utilizado para estos fines. Alguna vez utilicé el término en inglés y le pedí a un colega que escribiera el término en un papelógrafo. Mi colega entendió el concepto y

lo escribió en portugués: Parque em lote. Desde entonces utilizo el término en portugués, ahora bautizado como “parque-em-lote”. El facilitador debe introducir el concepto de estacionamiento al inicio de la lean inception, o apenas un tema comience a desviar la atención o a desviar al equipo del objetivo. Para ello debes escribir “estacionamiento” en un papelógrafo y colocarlo en una pared en la sala de guerra. Si el tema en discusión todavía no ha sido escrito en un post-it, escríbelo en uno y colócalo en la sección de estacionamiento. Asegúrate de explicar brevemente el concepto de estacionamiento y luego regresa a la actividad que estabas ejecutando. Es importante ser muy asertivo con los participantes de la lean inception sobre este término: “La conversación estaba desviando el foco, y no es parte del alcance de la actividad en cuestión, es por ello que aquel tema fue derivado al estacionamiento”. Es igualmente importante oír y respetar las opiniones, ideas y pensamientos de los participantes; por lo tanto, el estacionamiento debe ser utilizado conforme a lo prometido y ser visitado posteriormente: “Este tema está estacionado por ahora, pero vamos a retomarlo más tarde”. De hecho, al final de cada día de inception, se deben dedicar diez minutos a revisar los temas en el estacionamiento. De esta forma, una de estas dos acciones es tomada por cada tema: (1) el tema es removido del estacionamiento (o el tema ya fue abordado y no necesita ser tratado más) o (2) el tema permanece en el estacionamiento para una próxima revisión. La última revisión debe ocurrir al final de la inception. En esa última validación es muy importante aclarar todos los temas remanentes y compartir con todos lo que va a suceder con ellos.

LAS AGENDAS

LA AGENDA BURN-UP La agenda burn-up ayuda con la administración del tiempo y el alcance de una lean inception. Tener una agenda visible para todos refuerza el compromiso y genera confianza en la gestión del tiempo y en el progreso de la lean inception. Es una herramienta simple y eficaz para planificar y facilitar el taller. Las agendas burn-up7 surgieron en intensos talleres de brainstorming (lluvia de ideas), como inceptions y sesiones de ideación. A pesar de que los talleres realizan brainstorming de amplia discusión, normalmente tienen un límite de tiempo y deben cubrir varios temas y actividades para lograr el resultado deseado. Lean inception es un taller colaborativo con sesiones de brainstorming y mucha conversación que generalmente sucede a lo largo de la semana. Por eso es esencial controlar el tiempo y el progreso del mismo. Las personas facilitadoras de Lean Inception crean y explican la agenda burn-up en las primeras horas del primer día del taller.

Aquí está el paso a paso para crear la agenda burn-up de Lean Inception:

1.Dibuja en una pizarra o en una hoja A3 un gráfico XY conforme se ve en la ilustración de arriba. 2.Anota en post-its separados las actividades de la lean inception (ejemplo: visión de producto, Es/No es/Hace/No hace, personas, brainstorming de funcionalidades, revisión, viajes, secuenciador y canvas MVP). 3.Coloca las actividades de abajo para arriba en el eje Y (la primera es visión de producto, seguida por Es/No es/Hace/No hace, y así sucesivamente). 4.Anota en post-its separados los bloques de tiempo de tu lean inception (como generalmente dura una semana, los bloques de tiempo son definidos como: lunes en la mañana, lunes en la tarde, martes en la mañana, etc.). 5.Coloca los bloques de tiempo en el eje X. 6.Dibuja una flecha (vertical, para arriba) en otro post-it y colócalo al inicio del tiempo (lunes en la mañana). 7.Explica al grupo como usar la agenda burn-up. Encuentra el cartel de la agenda burn-up y los demás carteles para Lean Inception en: www.caroli.org/carteles-lean-inception. Hay dos movimientos básicos para los post-its, y ambos son movimientos horizontales: (1) para actualizar el “reloj”: el post-it con la flecha que marca la hora actual debe ser movido para la derecha, hasta la posición que efectivamente representa la hora actual. (2) Para indicar el término de una actividad: el post-it de la actividad correspondiente debe ser movido para la derecha, hasta colocarlo en el bloque de tiempo en que se llevó a cabo. El mecanismo de movimiento de los post-its permite identificar, de inmediato, un desvío en la duración esperada de las actividades de la lean inception, y un posible atraso del taller. Una vez constatado, el problema debe ser discutido y se deben tomar acciones correctivas (hacer paralelamente actividades, reducir

conversaciones, hacer más uso del parking lot, etc.) lo antes posible y no cuando sea muy tarde. AGENDA DE LA SEMANA La agenda burn-up provee una buena estructura para secuenciar las sesiones y actividades abiertas de brainstorming, acompañando el progreso general y el tiempo.

Sugiero que se utilice la agenda burn-up. Sin embargo, algunas personas, especialmente aquellas que no van a estar totalmente dedicadas al taller, necesitan tener un idea de la semana. Por tal motivo comparto la plantilla de la agenda para Lean Inception (también disponible en www.caroli.org/plantilla-age nda-lean-inception). LEAN INCEPTION - EJEMPLO DE AGENDA

El modelo de la agenda planificada presenta dos tipos de sesiones (presentadas en colores diferentes en la ilustración anterior), que corresponden a los niveles de participación: las partes interesadas (stakeholders) y los miembros activos. » Stakeholder es cualquier persona impactada por el proyecto. Son personas altamente interesadas en el direccionamiento y en el resultado de la lean inception, pero que no tienen tiempo para participar de todas las sesiones, por ejemplo: patrocinadores, usuarios finales, jurídico, ventas y marketing. » Miembro activo es cualquier persona directamente involucrada en la compresión e implementación del producto. Son las personas que deben participar activamente en todas las sesiones del taller, por ejemplo: encargado de producto (product owners), desarrolladores, jefes de proyecto o experiencia de usuario.

Es de notar que en la agenda las actividades de kick-off y showcase del taller están marcadas en negro, respectivamente al inicio y al final de la semana. En el mundo ideal, todas las personas estarán presentes en la sala de guerra durante la semana. Sin embargo, raramente tenemos la disponibilidad de agenda de los stakeholders. El mínimo necesario es que participen de las sesiones de kick-off y showcase, donde son presentadas, respectivamente, las expectativas para la semana y el resultado obtenido por el equipo dedicado al taller. Los demás días se realiza una secuencia de actividades internas.

✓Checklist para lean inception La lista a continuación está pensada para ayudar en el proceso de planificación del taller de inception. Por favor, asegúrate de tener todos los ítems programados antes de iniciar el taller: ( )Participantes seleccionados e invitados (interesados y miembros activos) ( )Facilitador con experiencia ( )Reserva de sala (mantener la misma sala durante el período de la inception) ( )Papelógrafos, tarjetas, post-its de colores, papel A4 y bolígrafos para todos. ( )Coffee break

5 La lluvia de ideas o brainstorming, en inglés, es una técnica de creatividad de grupo, que consiste en dejar la mayor libertad a los miembros del grupo para generar el mayor número de ideas en relación al proyecto, sin restricciones. 6 La técnica Pomodoro es un método de administración del tiempo desarrollada por Francesco Cirillo. 7 Lee más sobre agenda burn-up en www.caroli.org/la-agenda-burnup.

ESCRIBIENDO LA VISIÓN DEL PRODUCTO Con un buen entendimiento de la visión del producto, se puede establecer cuál es la primera pieza del rompecabezas del negocio y cómo va a encajar. Se debe decidir cuáles son las características del producto sobre las que se va a trazar el camino inicial y cuál va a ser su estrategia. En algún lugar entre la idea y el lanzamiento, la visión del producto ayuda a trazar el camino inicial. Aquello define la esencia del valor del negocio y debe reflejar un mensaje claro y convincente para tus clientes. Esta actividad te ayudará a definir colaborativamente la visión del producto. Escribiendo la visión del producto8 Para [cliente final], quien [el problema que necesita ser resuelto], el [nombre del producto] es un [categoría del producto] que [beneficio clave, razón para comprarlo]. A diferencia de [alternativa de la competencia], nuestro producto [diferencia clave].

El paso a paso de la actividad

1.Escribe la plantilla de la visión del producto en una pizarra o un papelógrafo de una manera visible para todo el equipo. 2 Divide el equipo en grupos pequeños y pide a cada grupo que llene uno de los espacios en blanco de la plantilla (o más de uno, dependiendo del tamaño del equipo). 3.Reúne los resultados de cada equipo formando una sola frase.

En esta actividad es muy común que el resultado sea una frase sin sentido. Por ello, luego de ejecutar el tercer paso, es importante que el equipo trabaje unido para formar una frase homogénea, usando y alternando los resultados previos si es necesario.

EL PRODUCTO ES/NO ES/HACE/NO HACE A veces es más fácil describir algo a través de qué es o qué no es. La actividad Es/No es/Hace/No hace ayuda a definir el producto de esta forma, preguntando específicamente cada aspecto positivo y negativo acerca de lo que es o hace el producto. El paso a paso de la actividad

1.Divide un papelógrafo en blanco en cuatro áreas (Es/No es/Hace/No hace). 2.Escribe el nombre del producto sobre los cuadrantes. 3.Pide a cada participante que describa el producto en post-its y los coloque en el área correspondiente. 4.Lee y agrupa las notas similares. El producto es... El producto no es... El producto hace... El producto no hace...

Esta actividad ayuda a explicar el producto. Generalmente, luego de dicha actividad los participantes tendrán una visión más consensuada acerca de lo que el producto hace, así como lo que el producto no hace. Las decisiones estratégicas pueden ser clarificadas, como cosas que nunca hará el producto o aquellas otras que aún no debe hacer. CONSEJO: una vez, en un taller, me preguntaron la diferencia entre “es” y “hace”. Una participante del taller — Aurineide Cavalcante — dio una respuesta simple y eficaz: “si describes el producto con un sustantivo o adjetivo, coloca el post-it en “es”; pero si utilizas un verbo, indicando una acción, colócalo en “hace”. Por ejemplo, “seguro” y “aplicación móvil” en el cuadrante “es”, “reserva cancha” y “conecta jugadores” en el cuadrante “hace”.

Aprendí esta actividad de Rafael Sabbagh9, cuando la utilizó para definir uno de los roles del Scrum10 durante uno de sus entrenamientos. Adapté esta actividad para ayudar a definir el producto, y ha obtenido excelentes resultados.

ACLARANDO EL OBJETIVO Cada miembro del equipo debe compartir lo que entiende como objetivos del producto y los varios puntos de vista deben ser discutidos para lograr un consenso de lo que es realmente importante. Esta actividad ayuda a plantear y aclarar estos objetivos. El paso a paso de la actividad

1.Pide a cada miembro del equipo escribir, individualmente, tres respuestas a la siguiente pregunta: “Si tuvieras que definir este producto con tres objetivos para sus usuarios, ¿cuáles serían?”. 2.Solicita a los participantes compartir lo que escribieron en un papelógrafo, agrupando los objetivos similares. 3.Pide al equipo volver a escribir el objetivo, ahora colectivamente. En esta ocasión, estará claro que algunos de los objetivos listados no representan los objetivos principales del producto y, por tanto, deben ser descartados. De esta manera estará claro para el equipo cuál es el foco del producto.

ENTENDIENDO LOS TRADE-OFFS Trade-off o solución de compromiso es un acuerdo en el cual se deja algo fuera para priorizar otra cosa que se desea más. Un producto lean refleja decisiones de un equipo en relación a los trade-offs. La actividad “Entendiendo los trade-offs” ayuda a construir y documentar un entendimiento común acerca de los acuerdos de un producto lean. Muchas decisiones y conversaciones son basadas en visiones individuales y premisas entre

alternativas. Algunos ejemplos: ¿qué es más valioso, la seguridad o la usabilidad? ¿Y qué tal entre desempeño y seguridad? ¿O usabilidad y desempeño? Esta actividad promueve una conversación abierta y colaborativa sobre los trade-offs. Los acuerdos claros evitan malos entendidos y ayudan a tomar decisiones rápidamente. El paso a paso de la actividad

1.Describe todas las categorías que son relevantes para el producto en post-its (por ejemplo: seguridad, usabilidad, escalabilidad). 2.Pon las categorías en un papelógrafo en blanco como título de las filas. A continuación, dibuja una línea horizontal para cada categoría. 3.Dibuja líneas verticales (el mismo número de líneas horizontales). 4.Escribe, encabezando cada columna, números del uno en delante (de izquierda a derecha), donde el uno indica mayor importancia, el dos menos, y así sucesivamente. 5.Pide a los participantes marcar sus iniciales en varios post-its y poner uno en cada línea. La única restricción es que cada columna debe tener un post-it con sus iniciales (por ejemplo: solo una de las categorías debe ser marcada como la más importante). 6.Iguala los acuerdos. Con un post-it de diferente color (post-it de color rojo intenso en la imagen), haz una marca en cada categoría, desde la menos a la más importante. Esta marca debe ser relativamente fácil dado que se considera los post-it con los votos de todos.

DESCRIBIENDO A LAS PERSONAS Para identificar efectivamente las funcionalidades de un producto, es importante tener en mente los usuarios y sus objetivos. La manera usualmente utilizada para representar estos usuarios es por medio de personas11.

Una persona representa a un usuario del sistema, describiendo no solo su papel, sino también sus necesidades específicas, creando una representación realista de los usuarios, que ayuda al equipo a describir funcionalidades desde el punto de vista de quien interactuará con el producto final. CUADRANTES PARA IDENTIFICAR TIPOS DE PERSONAS La siguiente actividad es utilizada para describir los tipos de personas. La actividad es simple, ilustrativa, divertida y rápida.

El paso a paso de la actividad

1.Solicita al equipo que se divida en pares o tríos y entrégales la siguiente plantilla de personas a cada grupo.

2.Pide a cada grupo que cree una persona, utilizando la plantilla como referencia. 3.Solicite a los participantes que presenten sus personas a todo el equipo. 4.Pide al equipo que cambie los grupos y repita los pasos 1 al 3. La plantilla presentada fue creada por Natalia Arsand, excelente user experience designer (UX) y colega de trabajo en ThoughtWorks Brasil. Al final de la actividad, un conjunto de personas debe haber sido creado y los diferentes tipos de usuarios del sistema deben estar descritos. Las partes interesadas (stakeholders), que conocen los objetivos del proyecto, deben participar activamente en la actividad, auxiliando al equipo en la creación de las personas y sugiriendo cambios en sus descripciones, según sea necesario. CREANDO MAPAS DE EMPATÍA El mapa de empatía es una plantilla visual para identificación y visualización de una persona. Creado originalmente para análisis de segmentos de consumidores,

el mapa de empatía es una excelente herramienta para clasificar, explorar y entender los diferentes tipos de personas. El mapa de empatía fue originalmente descrito por Dave Gray como uno de los métodos de XPLANE12 para comprender a los usuarios, clientes y otros involucrados en el negocio. Se hizo aún más conocido desde que fue destacado en el libro Business Model Generation como una herramienta para descubrir ideas sobre los clientes13. El mapa representa cuatro áreas principales, las cuales forman la frase:

¿QUÉ ____________ (VEO / PIENSO / OIGO / HABLO)? Además de estas cuatro áreas principales, la versión original cuenta con dos zonas para esa persona: el dolor (pain, en inglés) y la ganancia (gain, en inglés).

Siempre que he utilizado el mapa de empatía para identificación de personas, utilizo sus cuatro áreas principales: veo, oigo, pienso y hablo. Pero, a veces, utilizo las áreas de dolor y ganancia, como está descrito originalmente; sin embargo, algunas veces altero estas otras áreas, como, por ejemplo: lo que yo hago, lo que yo no hago, mis amigos y mis enemigos, mis hobbies. El paso a paso de la actividad

1.Elige una persona para ser analizada. 2.Diseña una plantilla del mapa, con la persona representada en el centro de la plantilla. 3.Describe las áreas para esa persona. 4.Repita los pasos 2 y 3 para las siguientes personas.

ACTUALIZA EL ENTENDIMIENTO SOBRE LAS PERSONAS

Es importante destacar que el resultado de la actividad de definir la persona no debe ser definitivo, y que una construcción inicial puede ser actualizada conforme el producto evoluciona. La actividad es realizada basándose en el conocimiento, en las encuestas y en los datos previos sobre los usuarios del producto. Generalmente, las empresas grandes tienen conocimiento y datos sobre sus usuarios. Si no fuese el caso, existirán hipótesis sobre los usuarios del producto y ellas estarán explicitadas en la actividad de describir las personas. Con el feedback del producto obtendremos más compresión sobre las personas. Incluso, más encuestas pueden ser realizadas para adquirir un mejor entendimiento de los usuarios. Dado que el conocimiento aumentó, rehaz la actividad de persona, actualizando la representación de los usuarios. Samantha Rosa, una amiga UX (user experience designer), compartió un ejemplo de ello. Durante una lean inception, su equipo siguió los pasos de la actividad presentada y creó las personas, pero después de liberar el producto para clientes reales, percibieron que una de las personas descritas no estaba de acuerdo con la realidad. Entonces realizaron de nuevo la actividad para actualizarla, y repensaron el producto.

BRAINSTORMING DE LAS FUNCIONALIDADES (FEATURES) Una funcionalidad es una descripción de una acción o interacción de un usuario con el producto. Por ejemplo, imprimir una factura, consultar una declaración detallada, compartir con los amigos de Facebook. La descripción de una funcionalidad debe ser lo más simple posible. El usuario está intentando hacer una cosa y el producto debe tener una funcionalidad para eso. ¿Cuál funcionalidad sería esa?

Dado que ya tenemos a las personas y a los principales objetivos del producto, la siguiente pregunta ayuda con el descubrimiento de las funcionalidades:

¿Qué necesita tener el producto para cumplir con las necesidades de la persona? ¿Qué funcionalidades debemos construir para poder alcanzar aquel objetivo? La siguiente actividad es utilizada para el brainstorming de las funcionalidades. Es importante notar que esta actividad depende de la lista de objetivos y personas, que deben ser artefactos ya elaborados en actividades anteriores. El paso a paso de la actividad

1.Solicita al equipo que coloque los objetivos sobre una mesa o en una pared, en orden de prioridades, de izquierda a derecha, como títulos de columnas. 2.Pide al equipo que coloque las personas en el mismo espacio, en orden de prioridades, de arriba hacia abajo, como títulos de las filas. 3.Promueve un brainstorming de ideas de funcionalidades. La discusión debe ser guiada para que se descubra qué funcionalidades son necesarias para atender los objetivos y las personas. Una pregunta que ayuda en este proceso es: ¿Qué debe tener el producto para cumplir con las necesidades de la persona? ¿Qué funcionalidades debemos construir para alcanzar este objetivo? El equipo debe guiarse a través del artefacto creado repitiendo las preguntas de arriba para cada combinación de persona y objetivo, comenzando con los de más

alta prioridad. De este modo, las candidatas a funcionalidades con mayor prioridad surgirán primero. Este libro describe mi experiencia con Lean Inception para productos digitales. Por lo que llamé a la actividad como Brainstorming de funcionalidades (del producto digital o del MVP). Pero en algunas instancias, cambié el nombre de la actividad, por ejemplo: Brainstorming de actividades o Brainstorming de ideas. Aquello ocurrió en los casos en que el contexto de Lean Inception no era para la creación de un producto digital, sino para la alineación de las personas para construir algo (no necesariamente un producto). MUÉSTRAME EL DINERO El control de tiempo es esencial para todas las actividades, pero esta actividad requiere atención especial. En el caso de que un gran número de objetivos y personas sean seleccionados en los pasos 1 y 2, un sinnúmero de funcionalidades podría ser planteado por el equipo. Esto será contraproducente y puede llevar al equipo a gastar mucho tiempo conversando sobre funcionalidades que no serán parte de los primeros MVP. Para evitar este escenario, es altamente recomendable que el número de objetivos y personas sea limitado (por ejemplo, los tres o cuatro principales objetivos y personas).

Si tuviésemos un presupuesto muy reducido y pudiésemos trabajar en apenas un objetivo, ¿cuál sería?

La pregunta de arriba ayuda al grupo a priorizar objetivos y personas. Repite la pregunta algunas veces para los objetivos y luego para personas. Más allá de la priorización, ayudará con el foco en la validación y en la evolución del producto a través del MVP. Una forma más lúdica y colaborativa de priorizar objetivos y/o personas es pensar en dinero. Para ello se realiza la siguiente actividad. El paso a paso de la actividad

1.Divide a los participantes en grupos pequeños. 2.Distribuye cinco post-its con el signo “$” para cada grupo (usar un color de post-it por grupo). .3Instruye al grupo a colocar los signos “$” donde cree que se debe invertir más dinero (sea para entender mejor la necesidad de la persona o en alcanzar un objetivo). 4.Conversen sobre el resultado (de la opción de redistribuir los “$”). 5.Prioricen los ítems con más “$”.

FUNCIONALIDADES, OBJETIVOS Y PERSONAS

Aunque el canvas es similar a una matriz, no necesariamente habrá una funcionalidad para cada intersección. Puede haber múltiples funcionalidades para que una persona alcance un objetivo específico, así como es posible que haya personas que no necesitan de una funcionalidad para un determinado objetivo. En caso que se identifiquen funcionalidades que no atienden las necesidades de ninguna persona, entonces deben ser descartadas o repensadas, pues su valor no está claramente asociado a un usuario.

ENTENDIMIENTO TÉCNICO, DE NEGOCIO Y DE EXPERIENCIA DE USUARIO La actividad anterior logró alistar muchas funcionalidades, pero necesitamos invertir más tiempo para entender las funcionalidades en detalle. Para desarrollar este entendimiento evaluamos las funcionalidades en términos de esfuerzo, valor de negocio, experiencia de usuario y certeza. Para el esfuerzo, valor de negocio y experiencia de usuario, anotamos las funcionalidades utilizando marcas en una escala de uno, dos o tres.

Evaluar la incertidumbre es un poco más complejo. “Sé exactamente lo que quiero de este ítem de trabajo y sé exactamente cómo hacerlo”. ¡Es increíble cuando eso ocurre! Sin embargo, no siempre es así. Debido a ello es que se necesita verificar, para cada funcionalidad, cuál es el nivel de certeza que se puede tener de ella. El gráfico del semáforo nos ayudará con aquello.

Clasificamos cada funcionalidad combinando el nivel de certeza técnica (qué tan bien el equipo de desarrollo entiende cómo construir la funcionalidad), de confianza en el UX (user experience) y por el entendimiento de negocio (qué tan bien la gente de negocios concuerda sobre qué entra en la funcionalidad). De esta manera, cada funcionalidad recibe una posición correlativa al nivel de certidumbre. Si una funcionalidad queda en la parte inferior izquierda del gráfico (marcada con una “X”), considera descartarla o invierte más tiempo en aclararla. Este gráfico recibe el nombre de “gráfico del semáforo”, ya que sus colores son los mismos que los de un semáforo: verde, puedes seguir tranquilo; amarillo, presta atención pues tal vez tengas que parar antes de continuar; rojo, para y espera antes de seguir. Al terminar la revisión del esfuerzo, valor del negocio, experiencia de usuario y certeza, todas las funcionalidades estarán evaluadas y analizadas. Por ejemplo, la funcionalidad “registrar dirección favorita” puede tener un esfuerzo medio, valor de UX alto, valor de negocio bajo y nivel de certeza alto.

Cada funcionalidad debe pasar por la revisión técnica, de UX y de negocio. Para ello, cada funcionalidad debe ser primero mapeada en el gráfico del semáforo y, en seguida, debe recibir marcas según la tabla que mide el esfuerzo, la experiencia del usuario (UX) y del valor del negocio. En el gráfico del semáforo, la funcionalidad recibe un color; en la tabla, recibe marcas de valor y esfuerzo. Cada color representa un nivel de confianza o certeza de la funcionalidad; mientras que las marcas de esfuerzo, valor de negocio y valor de UX en la tabla, varían en una escala de una, dos o tres veces comparativamente, por ejemplo: $, $$ y $$$. El color y la marca van ayudar al equipo en las actividades siguientes para priorizar, estimar y planificar. A continuación, se presenta un ejemplo de funcionalidades después que pasaran por el gráfico del semáforo y por la tabla de esfuerzo, UX y negocio.

El proceso de evaluar cada funcionalidad con el gráfico y la tabla genera más resultados que simplemente los colores y marcas en cada tarjeta. Se llevan a cabo importantes conversaciones, algunas decisiones son firmadas, se definen premisas y se describen incertidumbres. En otras palabras, las personas discuten y hacen anotaciones sobre cada funcionalidad en cuestión. Es muy importante guardar las anotaciones generadas durante estas actividades, pues sirven para complementar la descripción de la funcionalidad. Luego, debes solicitar a los participantes hacer anotaciones en post-its y pegarlos detrás de la tarjeta. Así, las actividades continúan de manera rápida y dinámica, pero manteniendo las anotaciones importantes.

VERIFICANDO EL ENTENDIMIENTO CON EL GRÁFICO DEL SEMÁFORO Esta actividad tiene el objetivo de discutir cómo se siente el equipo en relación a la compresión técnica, de UX y del negocio para cada funcionalidad. A partir de esta actividad, nuevas notas serán tomadas, y las discordancias y dudas se harán más evidentes. El paso a paso de la actividad

1.Crea un gráfico donde el eje de las X represente la certeza técnica (cómo hacer) y el eje de las Y represente el conocimiento sobre el entendimiento de UX y del negocio, sobre lo que se requiere (qué hacer). 2.Solicita a un miembro del equipo que lea una funcionalidad en voz alta y que la coloque en el gráfico de acuerdo a la comprensión que tiene de ella, respondiendo a las siguientes preguntas para cada eje. » Eje X: ¿Qué tan seguro estás de cómo realizar esta funcionalidad?

» Eje Y: ¿Qué tan seguro estás sobre qué es lo que esperan el negocio y/o los usuarios de esta funcionalidad? 3.Pregunta al equipo si todos comparten esta opinión. Si alguien no está de acuerdo, el equipo debe discutir los requisitos y la tecnología involucrados de forma que haya un consenso sobre la funcionalidad. Todo lo que sea mencionado y que ayude a alcanzar una mejor comprensión debe ser anotado en la funcionalidad. 4.Anota en la funcionalidad el nivel de comprensión. Por ejemplo, la figura anterior muestra funcionalidades en post-its con su respectivo nivel de comprensión: verde ( ), amarillo ( ) o rojo ( ), indicando respectivamente un nivel alto, medio o bajo de comprensión. 5.Para cada funcionalidad identificada anteriormente, repetir los pasos 2 al 4. En el eje X, el objetivo es verificar la comprensión del equipo en relación a los desafíos técnicos, las dependencias y los requisitos de infraestructura. ¿Hiciste esto antes? ¿Sabes cómo hacerlo? La respuesta “sí” indica alto nivel de confianza sobre cómo hacerlo. “Más o menos”, “tal vez” o “creo que sí” indican nivel medio; mientras que “no” indica nivel bajo. En el eje Y, la idea es verificar la claridad de lo que es la funcionalidad, sea del punto de vista del negocio o de quien va usarlo. ¿Sabes lo que el negocio y/o usuario quiere(n) de ese ítem de trabajo? La respuesta “sí” indica alto nivel de confianza sobre qué hacer. “Más o menos”, “tal vez” o “creo que sí” indican nivel medio; mientras que “no” indica nivel bajo. Al final de la actividad, las funcionalidades en tarjetas rojas con una X representan riesgos altísimos para el proyecto. Normalmente, el equipo las divide en bloques de trabajo más pequeños o las descarta. Evítalas a toda costa. Intenta aclararlas antes de comenzar a trabajar. Solamente continúa con funcionalidades que estén en tarjetas verdes o amarillas.

TABLA DE ESFUERZO, EXPERIENCIA DE USUARIO (UX) Y VALOR DE NEGOCIO Esta actividad tiene el objetivo de discutir cómo el equipo entiende el esfuerzo para completar una funcionalidad, así como también el valor de negocio y la experiencia de usuario asociada a cada funcionalidad. A partir de esta actividad, nuevas marcas son agregadas a cada funcionalidad. El paso a paso de la actividad

1.Crea una tabla que muestre una escala de uno a tres para el esfuerzo técnico (o nivel de trabajo que se necesita efectuar), el valor de experiencia de usuario (cuánto irán a amarlo los usuarios) y el valor de negocio (cuál es el retorno o ahorro que va a significar). 2.Pide a un miembro del equipo leer una funcionalidad en voz alta y colocarla en cada fila de la tabla de acuerdo con su comprensión de ella (esfuerzo, valor para el negocio y valor de UX), respondiendo la siguiente pregunta para cada fila de la tabla: » ¿Cuánto trabajo (esfuerzo) necesitamos para crear esta funcionalidad? Marca con una E, EE o EEE, para indicar, respectivamente, un esfuerzo bajo, medio o alto. » ¿Cuánto valor para el negocio vamos a generar con esta funcionalidad? Marca con el signo $, $$ o $$$, para indicar un valor alto, muy alto o altísimo, respectivamente. » ¿Cuánto amarán los usuarios esta funcionalidad? Marca con uno, dos o tres corazones, para indicar una baja, media o alta aprobación, respectivamente. 3.Pregunta al equipo si todos comparten esta opinión. Si alguien no está de acuerdo, el equipo debe discutir los requisitos y la tecnología involucrados de forma que haya un consenso sobre la funcionalidad. Todo lo que sea mencionado y que ayude a alcanzar una mejor comprensión debe ser anotado y anexado a la funcionalidad.

Anota en la funcionalidad el nivel de esfuerzo, experiencia de usuario y valor de 4. negocio. 5.Para cada funcionalidad identificada anteriormente, repetir los pasos 2 al 4.

ESCALA DE VALOR DE NEGOCIO Las marcas $, $$ y $$$ indican, respectivamente, valor de negocio alto, muy alto y altísimo. Cuando comencé a usar esta gráfica de valor de negocio, estas marcas eran utilizadas para indicar valor de negocio bajo, medio o alto. Sin embargo, raramente una persona de negocio respondía que una funcionalidad tenía un valor de negocio bajo (o medio). El cambio en la escala ayudó para que el resultado representase el valor de negocio comparativo entre las diferentes funcionalidades.

MOSTRANDO LOS VIAJES DE USUARIO El viaje de usuario (o user journey, en inglés) describe el camino recorrido por un usuario a través de una secuencia de pasos necesarios para alcanzar un objetivo. Algunos de estos pasos representan diferentes puntos de contacto con el producto, demostrando cómo el usuario interactúa con él. A medida que construimos el viaje, el equipo plantea preguntas y opiniones alternativas acerca de los deseos del usuario y de las capacidades del producto. El paso a paso de la actividad

1.Selecciona una persona. 2.Identifica el objetivo de esa persona. 3.Escribe la persona y su objetivo en un post-it y colócalo en la parte superior izquierda de un papelógrafo (para que pueda moverse posteriormente).

4.Decide el punto de inicio (preguntas útiles: ¿cómo comienza la persona su día?, ¿qué gatilló su deseo de alcanzar su objetivo?). Escribe el punto de partida en un post-it y sitúalo en el papelógrafo. 5.Describe cada paso posterior en un post-it y ponlo a continuación (de manera sucesiva) en el papelógrafo. Continúa agregando pasos hasta que la persona alcanza su objetivo. Preguntas, acuerdos y desacuerdos serán los protagonistas en la discusión sobre la construcción del viaje. Quizás puede surgir más de una opción de viaje. Por ejemplo, el viaje optimista, el realista, el pesimista, el principal, el caso excepcional 1, el caso excepcional 2, etc. Las opciones forzarán la priorización y la definición clara del objetivo y, con esto, el foco será más claro en algunos viajes. Los viajes priorizados complementarán y ayudarán en la búsqueda del producto mínimo viable (MVP). El nivel de detalle de un viaje no debe ser muy alto, ni muy bajo. Al mismo tiempo que un viaje proporciona un paso a paso de la interacción del usuario, debe ser una síntesis, un nivel más elevado y simplificado del flujo, sin información redundante ni los detalles más profundos. A continuación, se puede ver un ejemplo de un viaje de usuario. Pon atención al dibujo de la persona al lado de un coche que se encuentra en la esquina superior izquierda de la hoja, y su viaje descrito con post-it de izquierda a derecha y de arriba abajo. En el viaje en cuestión, cada post-it representa un paso en el camino de la persona para alcanzar su objetivo (descrito en el último post-it). Pequeñas flechas conectan un paso al siguiente.

Preguntas simples nos ayudan con el inicio de la descripción de los viajes. Algunos ejemplos:

¿Cuál es el objetivo que la persona quiere alcanzar? ¿Cómo él/ella comienza su día? ¿Qué hace antes de eso? ¿Qué hace después de eso? Una conversación, un post-it y un bolígrafo. Eso es lo que necesitas para describir los viajes de usuario. Te sugiero escribir y reescribir. Lo importante es que comiences: no te detengas esperando una revelación que no vendrá. Después de tener algo descrito puedes cambiarlo. Si hace sentido, combina algunos pasos muy detallados en uno solo o divide un paso poco detallado en pasos más pequeños. No hay una fórmula mágica para esto. Lo importante es que los viajes sean descritos. Aquí hay un ejemplo de un viaje de usuario. FANÁTICO DEL FÚTBOL: INVITA AMIGOS A UN PARTIDO » Se despierta temprano para ir al trabajo. » Toma un gran desayuno. » Llega al trabajo a las 9:00 a.m. » Durante una reunión decide realizar alguna actividad física. » En el almuerzo convence a un amigo del trabajo para jugar al fútbol después del trabajo. » Llama y reserva una cancha » Abre la aplicación móvil Easy-ball. » Registra el partido a las 8:00 p.m. de ese mismo día » Coloca la información de la cancha » Envía la invitación a los amigos.

EXHIBIENDO LAS FUNCIONALIDADES EN LOS VIAJES

Los viajes aclaran cómo será la interacción con el producto. Si seguiste el orden sugerido en este libro, los viajes deben estar descritos (como una secuencia de pasos) y las funcionalidades deben estar disponibles (en tarjetas de colores). Esta actividad describe cómo juntarlos, revaluando y verificando todo el análisis hasta este momento. El paso a paso de la actividad

1.Coloca los viajes principales y las funcionalidades visibles, si es posible, lado a lado, conforme se muestra en la foto a continuación. 2.Siguiendo el viaje, busca las funcionalidades necesarias para cada paso. La secuencia de abajo muestra un ejemplo de cómo las funcionalidades son mapeadas en el viaje. 3.Luego de que una persona lee el paso a paso del viaje, las personas del grupo de funcionalidades verifican si hay alguna funcionalidad que sirva o mejore el viaje del usuario. 4.Cuando se identifica una “combinación” (de una funcionalidad en un viaje), pon un identificador a la funcionalidad, anótalo en un post-it pequeño y colócalo en el paso del viaje al que corresponda. 5.Repite los pasos anteriores para todas los viajes. En el momento en que la persona que esté leyendo el viaje sea interrumpida por su colega diciendo, “¡Tienes una funcionalidad en este paso!”, ambos, el viaje y la funcionalidad, deben ser marcados indicando ese match. Si el viaje no tuviese un identificador, entonces asígnale un identificador, como por ejemplo “V1”. Haz lo mismo para la funcionalidad. Anota el identificador del viaje en la tarjeta de la funcionalidad, y el identificador de la funcionalidad en el respectivo paso del viaje. De esta forma todas los viajes y las funcionalidades tendrán marcas indicando sus asociaciones.

La siguiente imagen muestra otro ejemplo de mapeo de funcionalidades para un viaje. En el momento de la foto, una persona estaba leyendo el viaje de usuario, mientras que otras tres personas estaban buscando funcionalidades necesarias para ese viaje.

Es importante notar que en la foto el viaje está sobre la mesa y las funcionalidades en la pared. La foto muestra el momento exacto en que una de las personas sentadas apunta y dice: “Ahí tienes una funcionalidad para este paso”. En la secuencia, el identificador de la funcionalidad fue anotado en el paso del viaje y el identificador del viaje fue anotado en la tarjeta de la funcionalidad. Al final de esta actividad, dos cosas deberían ocurrir: (1) pueden haber sido identificadas algunas funcionalidades faltantes, y (2) algunas funcionalidades no fueron mapeadas en ningún viaje. En el escenario (1) se debe crear la tarjeta de la funcionalidad faltante con los colores y las marcas identificando incertidumbre, esfuerzo y valor de negocio. En el escenario (2) aquellas funcionalidades deben ser aclaradas (y documentadas),

pero el equipo no debe seguir con ellas, manteniendo el foco en los ítems prioritarios por viaje.

SECUENCIANDO LAS FUNCIONALIDADES “¿Esta funcionalidad es importante?”. Siempre he obtenido la misma respuesta cuando hago esta pregunta y, por lo tanto, ya no la hago. La pregunta más relevante para ayudar a planificar el orden en que deben crearse las funcionalidades es la siguiente: “¿Cuál de estas dos funcionalidades es la más prioritaria?”. De esta manera las funcionalidades son priorizadas en relación unas a otras. Esta pregunta es muy útil y debe ser utilizada, pero necesita de un punto de partida. Previamente, identificaste a la persona más importante, así como también el viaje de usuario más prioritario. Este sí es el mejor punto de partida: la primera funcionalidad de este viaje. Tal vez encontremos más de una funcionalidad en el viaje o en los viajes que pueden crearse de forma simultánea. Ante este escenario se debe preguntar cuál de las dos funcionalidades en cuestión es la de más alta prioridad.

Felizmente, en las etapas anteriores algunos parámetros ya fueron agregados a las funcionalidades, como, por ejemplo, el valor de negocio ($, $$ o $$$), esfuerzo (E, EE o EEE), experiencia de usuario y la identificación del nivel de certeza (tarjeta de color verde, amarillo y rojo). Estos parámetros nos van a ayudar con la planificación de las funcionalidades y sus prioridades.

Entonces, ¿cuál es la combinación mínima de funcionalidades que deben estar disponibles para validar un pequeño conjunto de hipótesis sobre el negocio? Ahora es hora de visualizar y conceptualizar el primer MVP y sus incrementos subsiguientes. EL SECUENCIADOR DE FUNCIONALIDADES El propósito del producto mínimo viable (MVP) es crear algo que pueda ser usado para validar un conjunto pequeño de supuestos acerca del producto y su rol en el negocio. Ahora que tienes un mapa de las funcionalidades ya integradas en los viajes de usuario, estás en posición de trabajar tu primer MVP y sus siguientes iteraciones. Aquello se logra a través de la definición del “secuenciador de funcionalidades”.

Nuestro objetivo con un producto mínimo viable es aprender de cada iteración a través de la construcción de un MVP que nos permitirá probar si nuestro caso de negocios es efectivo. EL TEMPLATE DEL SECUENCIADOR Se debe planificar una secuencia de ondas para agrupar las funcionalidades de tal manera que sea útil para organizar el orden de producción, algo fácil de entender. Una onda después de otra, en secuencia. Dibuja en un papelógrafo o en una pizarra blanca una plantilla con las ondas: el “secuenciador de funcionalidades”. SECUENCIADOR 1 2 3 4 5

La intención es ejecutar lo más pronto posible, en las primeras ondas, aquello que es más impactante. Y seguir trabajando en las funcionalidades del secuenciador de onda en onda. LAS REGLAS PARA CADA ONDA Las funcionalidades serán agregadas a cada onda. A continuación, las seis reglas para añadir funcionalidades en las ondas. Estas reglas fueron definidas después de aplicar un sinnúmero de veces esta forma de planificación y priorización. » Regla 1: una onda puede contener un máximo de tres funcionalidades. » Regla 2: una onda no puede contener más de una funcionalidad roja. » Regla 3: una onda no puede contener tres funcionalidades amarillas o rojas.

Regla 4: la suma del esfuerzo de las funcionalidades no puede sobrepasar las » cinco “E”. » Regla 5: la suma del valor de las funcionalidades no puede ser menor a cuatro “$” y cuatro corazones. » Regla 6: si una funcionalidad depende de otra, esa otra debe estar en una onda anterior. La regla 1 limita el número de funcionalidades que están siendo trabajadas al mismo tiempo. Eso evita la acumulación de funcionalidades parcialmente completadas, aumentando el enfoque en pocas funcionalidades priorizadas por onda. Las reglas 2, 3 y 4 evitan un período de trabajo desequilibrado con mucha incertidumbre o mucho esfuerzo. La regla 5 garantiza el enfoque constante en la entrega de alto valor para el negocio y para los usuarios. La regla 6 evita problemas de dependencia entre las funcionalidades. El paso a paso de la actividad

1.Crea la plantilla del secuenciador (generalmente un papelógrafo con filas numeradas. El alto de la fila debe ser tal que quepa una tarjeta de funcionalidad, en el ancho de la fila deben caber tres tarjetas de funcionalidades). 2.Explica las reglas del secuenciador. 3.Recuerda a todos el objetivo de la actividad: definir la secuencia en la cual entregaremos las funcionalidades del producto. 4.Todos colocan las funcionalidades en el secuenciador, moviéndolas para explorar las diferentes opciones, hasta que alcancemos un acuerdo. 5.El resultado muestra las funcionalidades para cada iteración del MVP.

CONVERGIENDO REGLAS Y VIAJES

Las reglas simples son agregadas a la plantilla del secuenciador de funcionalidades. Basta con buscar la primera funcionalidad del primer viaje, luego se debe buscar la próxima. Respetando las reglas, se decide si tal funcionalidad entra en la onda “n” o en la “n+1”. Si tienes dudas entre dos funcionalidades que respetan las reglas, basta responder a la pregunta: “¿Cuál de estas dos funcionalidades es más prioritaria?”. Abajo hay una imagen para ejemplificar la forma de colocar la funcionalidad en el secuenciador de funcionalidades, respetando las reglas.

¿DUPLICAR O UTILIZAR EL MISMO POST-IT/TARJETA?

Una funcionalidad con sus marcaciones está ubicada en una plantilla (por ejemplo, en un viaje). Debes estar atento a buscar la tarjeta y colocarla en otra plantilla: en el secuenciador de funcionalidades. Además de la información descrita en la tarjeta, su posición en la plantilla contiene más información. Tal es el caso de la funcionalidad con el viaje y en el secuenciador de funcionalidades. A estas alturas, te preguntarás: ¿duplico o utilizo la misma tarjeta? Mi sugerencia es que tomes una foto antes de hacer cualquier cosa. Considera duplicar la tarjeta siempre que esto no vuelva más lenta la actividad o más confuso el ambiente (por un sinnúmero de papeles de colores). Generalmente, todo el equipo estará bastante ocupado decidiendo el orden de las funcionalidades en el secuenciador. En este momento, todos debieran estar bien alineados en relación a los principales viajes y sus funcionalidades (con sus marcas de nivel de confianza, valor de negocio, valor de UX y esfuerzo). Es común que todos se queden en torno al secuenciador (en la pared o en una mesa) conversando y explorando posibles opciones, hasta alinear y decidir el orden de creación y liberación de las funcionalidades. IDENTIFICANDO LOS MVP EN EL SECUENCIADOR DE FUNCIONALIDADES Ha llegado el momento de entender los incrementos y la creación evolutiva de tu producto. Hasta ahora, las actividades han aclarado y priorizado cada aspecto del producto. Los pequeños bloques del mismo —las funcionalidades— están ahora ordenadas lógicamente en el secuenciador de funcionalidades. Por lo demás, las entiendes y las visualizas para los viajes de usuario. Será navegando por la plantilla del secuenciador de funcionalidades con sus ondas y funcionalidades, que vas a identificar los incrementos del producto mínimo viable (MVP).

Cada vez que la combinación de funcionalidades alcanza una versión simple del producto que puede hacerse disponible, nombra esa combinación. Por ejemplo: “MVP1”, “MVP2”, “MVP3”. Abajo se presentan dos ejemplos de los resultados después de este paso de identificación de los MVP (en post-its naranja) en el secuenciador de funcionalidades.

A continuación, un ejemplo ilustrativo de un secuenciador de funcionalidades. En ella tenemos dos MVP y trece funcionalidades. El MVP1 está compuesto por las funcionalidades F1 hasta la F5. El MVP2 está compuesto por las funcionalidades F6 hasta la F13.

¿Por qué MVP2? Como ya sabes, el MVP es el producto mínimo viable, pero después de él tenemos incrementos del producto. Independientemente de llamar al próximo incremento “MVP2” o algún otro nombre, lo más importante es seguir creando el producto a partir de la validación de la hipótesis.

CALCULANDO ESFUERZO, TIEMPO Y COSTO La mayoría de las empresas que conozco siempre están muy interesadas en encontrar la respuesta a dos preguntas simples y directas: ¿qué estás construyendo? y ¿cuándo estará listo? El secuenciador de funcionalidades responde la primera pregunta (¿qué estamos construyendo?), ya que presenta el primer MVP y las siguientes iteraciones. Es realmente un artefacto increíble generado en la Lean Inception. Muchos stakeholders estarán realmente satisfechos en el momento en que les respondas esta pregunta tan importante. Sin embargo, “¿cuándo estará listo?”, algunos preguntarán. ¿Cuándo estará listo el MVP? ¿Y el siguiente? ¿Y todas las funcionalidades que están en el secuenciador de funcionalidades? Si este no es tu caso, tienes mucha suerte y puedes obviar este capítulo; pero si lo es, puede interesarte seguir leyendo, ya que comparto cómo he ayudado a muchos equipos a responder esta pregunta.

La secuencia de actividades hasta este momento, así como las reglas del secuenciador de funcionalidades, generan ondas de tamaño similar. Esto simplifica la estimación del producto con sus MVP, ya que nos permite utilizar un tamaño promedio de onda basado en un muestreo más pequeño. En lugar de detallar cada onda con sus funcionalidades en relación al esfuerzo, tiempo y costo, solamente se seleccionarán unas pocas ondas. A continuación, se detallan las funcionalidades, se efectúa la suma de los números y se calcula el promedio para cada onda. DETALLANDO LAS FUNCIONALIDADES DE MUESTRA EN TAREAS El tamaño de las ondas es similar. Escoge dos o tres ondas y utilízalas para generar información detallada de esfuerzo, tiempo y costo. Dos o tres ondas son suficientes para tener una buena idea de los parámetros y generar una media efectiva. El paso a paso de la actividad

1.Escoge dos o tres ondas a ser detalladas. 2.Selecciona una funcionalidad de una de las ondas de muestra. 3.Describe, en otras tarjetas, las tareas (o piezas) más pequeñas para la funcionalidad seleccionada. 4.Vuelve al paso 2 y selecciona otra funcionalidad hasta que hayas detallado todas las funcionalidades de las ondas de muestra. Al seleccionar las ondas de muestra (paso 1), recuerda que en este momento estás interesado en la estimación de la totalidad y el tamaño promedio de una onda, y no en el detalle del trabajo en sí. Por lo tanto, las ondas a ser elegidas deben proporcionar una buena combinación del nivel de riesgo (marcado por el

color de las tarjetas), así como una buena variación en la suma de los niveles de esfuerzo (marcado con “E” en las funcionalidades).

La pieza más pequeña (paso 3) debe ser algo que tenga sentido para cada equipo. Los equipos de desarrollo de software que siguen la metodología Scrum utilizan a menudo las historias de usuario como aquellas piezas más pequeñas. Otros equipos prefieren llamar a las piezas más pequeñas “tareas” y describirlas sin un formato predefinido. En el resto de este capítulo, llamaré a las piezas más pequeñas de una funcionalidad “tareas”. Generalmente recomiendo a los equipos ser muy específicos a la hora de crear estas tarjetas de tareas, ya que esto ayudará a la actividad. Sin embargo, no hay que preocuparse de documentarlas perfectamente, ya que esto debiera realizarse posteriormente y no durante la lean inception. Durante el paso 3, haz una marca de identificación tanto en las tarjetas de funcionalidad, como en las tarjetas de tarea. Por ejemplo, marca con F1 a todas las tareas de la funcionalidad 1, F2 a las tareas de la funcionalidad 2, y así sucesivamente. Esto se hace para evitar confusiones y la mezcla de funcionalidades requeridas con sus tareas.

Al final de esta actividad, las funcionalidades seleccionadas como muestra serán detalladas con sus diversas tareas.

ESTIMACIÓN COMPARATIVA La siguiente actividad es muy simple, pero es esencial para entender el esfuerzo relativo de las tareas. El paso a paso de la actividad

1.Escribe las siguientes tallas de camisetas en post-its: pequeña, mediana y grande. 2.Coloca los post-it en un papelógrafo, una pared, una pizarra, una mesa o en el suelo, dejando la talla “pequeña” en la esquina superior izquierda y la talla “grande” en la esquina inferior izquierda. 3.Selecciona dos tareas y luego haz la siguiente pregunta: ¿cómo se compara esta tarea (en cuanto a esfuerzo) con esta otra? ¿Ambas pequeñas? ¿Una pequeña la otra mediana? ¿Grande? 4.Coloca ambas tareas en el papelógrafo, con sus relativas posiciones indicando cómo se comparan en cuanto al nivel de esfuerzo (pequeño, medio o grande). Coloca una al lado de la otra, si ambas requieren el mismo nivel de esfuerzo; o bien pon una debajo de la otra, indicando que una requiere más esfuerzo que la otra. 5.Define los límites entre tallas y vuelve a posicionar las tareas para dejar claras sus tallas. En caso de ser necesario, considera crear una talla de camiseta extra como, por ejemplo, extra pequeña (XS) o extra grande (XL). 6.Mientras haya tareas por ser comparadas, colócalas en la pizarra de acuerdo al nivel de esfuerzo y repite los pasos 3 y 4.

Al final de esta actividad, todas las tareas estarán asociadas a una talla de camiseta: pequeña, mediana o grande. Las dos actividades anteriores (“detallando las funcionalidades de muestra en tareas y “estimación comparativa”) pueden ser hechas al mismo tiempo, tal como se presenta en la siguiente imagen.

En ella, las tareas (en tarjetas blancas) son colocadas debajo de su respectiva funcionalidad de muestra, y cerca de tareas de tamaño similar (post-it rojos con marcas S, M o L, respectivamente para pequeña, mediana o grande). ENTENDIENDO EL COSTO Y EL TIEMPO Esta actividad es esencial para generar números para calcular los costos y el tiempo para cada onda, así como para todo el secuenciador de funcionalidades. Luego de esto, podrás responder la pregunta: ¿cuándo estará listo? El paso a paso de la actividad

1.Selecciona una tarea pequeña y pregunta cuánto tiempo le toma a una persona completarla. 2.Escoge dos o tres tareas más del mismo tamaño y repite la pregunta. 3.Calcula el tiempo promedio y anótalo. 4.Repite los pasos anteriores para tareas de diferentes tamaños. Al final de esta actividad, todas las tareas tendrán una estimación de tiempo y costo. Por ejemplo, se obtuvieron los siguientes resultados durante esta actividad: medio día para tareas pequeñas, dos días para tareas medianas, cuatro días para las tareas grandes y ocho días para las tareas extra grandes. Las respuestas sobre el tiempo influirán en el resultado final. Por ello, sé enfático en relación a esta pregunta. Si es posible, pide comparaciones con trabajos anteriores, y trata de entender la motivación y la capacidad de las personas que responden a esta pregunta. A los desarrolladores no les gusta responder a la pregunta “¿cuánto tiempo es necesario para completar dicha tarea?”. Por esto es muy importante que todo el mundo se sienta cómodo con la descripción de la tarea. Si hay algún malestar en

relación a una de ellas, deberán reescribirla y considerar dividirla en bloques más pequeños. Otra forma de hacer esta pregunta es formularla en plural:

Consideremos un par de desarrolladores. Uno conoce más acerca del negocio y el otro conoce menos. Uno es mayor, el otro es más joven. Uno tiene más experiencia en la tecnología en cuestión, el otro es un principiante. ¿Cuánto tiempo se demoran el par de desarrolladores en completar dicha tarea? En mi experiencia, las personas se sienten más cómodas dando este tipo de respuestas, cuando se considera el desarrollo en parejas que trabajan juntas para completar una tarea. CALCULANDO EL PROMEDIO DE UNA ONDA A partir del entendimiento del esfuerzo en la actividad anterior, le agregamos el tiempo estimado para cada tarea de cada funcionalidad. Luego, le sumamos la duración estimada por funcionalidad en cada fila de la plantilla del secuenciador. Por lo tanto, llegamos a un esfuerzo promedio para cada onda, definido por persona y por unidad de tiempo. La ilustración a seguir muestra cómo se llevó a cabo el cálculo por parte de un equipo. Las imágenes muestran, respectivamente, las ondas elegidas como muestra y el cálculo realizado para obtener el tiempo promedio estimado por onda.

Esta foto muestra los cálculos realizados para obtener el promedio de tiempo estimado por onda. Cada tarea se estimó en días por pareja de desarrolladores. En la foto, cada línea muestra la suma del tiempo estimado para las tareas de una funcionalidad. La medida de tiempo estimado para cada tarea fue: 1/4 de día (pequeño), 1/2 día (medio), dos días (grande) o cinco días (extra grande). Realizando la sumatoria de las tareas por funcionalidades y luego por onda, el equipo alcanzó valores de 11 días, 11 ½ días y 9 días, respectivamente, para las ondas 2, 3 y 4. Por lo tanto, el promedio que se utilizó para este equipo fue de diez días por pareja de desarrolladores por onda. A continuación, se muestran los resultados de otro equipo:

La imagen muestra el resultado de una lean inception para dos ondas de muestra: nueve semanas y catorce semanas. Después de verificar este resultado, el principal stakeholder dijo: “Entonces, cada onda toma aproximadamente doce semanas de un desarrollador. Si tenemos seis desarrolladores en este equipo, pareciera que podemos entregar una onda cada dos semanas (doce semanas de desarrollo efectuada por seis desarrolladores), o una onda por sprint14, de acuerdo a su terminología de Scrum”. Luego agregó: “Ya que nuestro MVP está completo en la onda cinco… creo que tendré que ajustar un poco la planificación”.

CONSTRUYENDO EL CANVAS MVP Por fin alcanzamos la cumbre de Lean Inception: el canvas MVP. En él, vamos a detallar el producto mínimo viable (MVP) y sus funcionalidades respecto a las perspectivas de Design Thinking y Lean Startup. El canvas MVP fue concebido como una actividad Lean Inception, y es la última actividad del taller de Lean Inception. Sin embargo, se puede usar de forma separada, independiente de la secuencia de Lean Inception. Sin embargo, quisiera enfatizar que es muy importante alinear a los participantes sobre la visión del producto, los objetivos, las personas, las funcionalidades, los viajes y la secuencia de funcionalidades que abarca cada MVP, pues esto ayuda a completar el canvas MVP. Una hora. Este es el tiempo aproximado para completar el canvas MVP si se han seguido las actividades de Lean Inception como se describió en los capítulos anteriores. Una hora trabajando en el canvas MVP proporcionará un buen nivel de detalle y mucha discusión para cada cuadrante del canvas. Por otro lado, un equipo que no haya seguido paso a paso la lean inception necesitará más tiempo y mucha más conversación para crear un MVP Canvas. COMPLETANDO EL CANVAS MVP

Teniendo en cuenta que el equipo ya ha discutido qué es lo que compone el MVP y ya ha conversado sobre lo que esperan de él, ahora es el momento de poner todo en papel. Mejor aún, define el pensamiento esencial acerca del MVP en una sola hoja de papel: el canvas MVP.

El paso a paso de la actividad

1.Imprime el canvas MVP15 o dibújalo en papelógrafo. 2.Elige el MVP que va a ser elaborado. 3.Completa cada una de las siete secciones del canvas MVP. El MVP Canvas está dividido en siete secciones. Las preguntas a responder en cada una de ellas: 1.Propuesta o visión del MVP – ¿Cuál es la propuesta de este MVP? 2.Segmentos de personas – ¿Para quién es este MVP? ¿En qué plataforma estará disponible? 3.Viajes de usuario – ¿Qué viajes se mejorarán con este MVP?

Funcionalidades – ¿Qué estamos construyendo en este MVP? ¿Qué acciones se 4. van a simplificar o mejorar en este MVP? 5.Resultado esperado – ¿Qué aprendizaje o resultado buscamos en este MVP? 6.Métricas para la validación de hipótesis de negocio – ¿Cómo podemos medir los resultados de este MVP? 7.Costo y cronograma – ¿Cuál es el costo esperado y la fecha de entrega y validación de este MVP? ¿Hay alguna restricción de tiempo? EL SECUENCIADOR DE FUNCIONALIDADES Y EL CANVAS MVP El secuenciador de funcionalidades ayuda en la organización y visualización de funcionalidades. Este organiza y planifica la entrega del producto más allá del primer MVP, representando claramente la secuencia de liberación de las funcionalidades del producto. Además de mostrar las tarjetas de funcionalidades ordenadas, el secuenciador muestra claramente la agrupación de funcionalidades para cada MVP. Esto es representado en los post-its del secuenciador, delimitando el MVP1, el MVP2 y así sucesivamente. Si utilizaste el secuenciador de funcionalidades y marcaste uno, dos o tres MVP, te sugiero que imprimas tres canvas MVP y completes uno por cada MVP identificado en el secuenciador. Sin embargo, si utilizaste el secuenciador y hay demasiados MVP, también sugiero que imprimas tres plantillas y solamente completes los primeros tres MVP. La realidad es que estamos trabajando con los MVP y no queremos extralimitarnos. Tal vez el secuenciador de funciones tiene demasiadas funcionalidades y, al ordenarlas y agruparlas, pueden aparecer algunos MVP. Esto sucede porque, en general, los participantes de una lean inception primero piensan de una manera más amplia, para luego tratar de determinar la secuencia de los entregables mínimos y viables. El secuenciador de funcionalidades demuestra

claramente el pensamiento colectivo sobre la evolución del producto a través de los MVP. Pero el secuenciador es solo un mapeo, un plan que creamos de acuerdo con el entendimiento actual. Y esta secuencia se crea suponiendo que los primeros MVP logran lo que esperamos de ellos. Sin embargo, no te dejes engañar. El aprendizaje del MVP1 y posteriormente del MVP2 portará algunas nuevas explicaciones. El equipo tendrá que volver a pensar el producto y los próximos MVP con sus funcionalidades. Construir un canvas MVP y ponerlo en el armario sería un desperdicio. Construye uno o dos, pero no más de tres. La imagen del ejemplo es real: ese equipo construyó solo un canvas MVP para el primer MVP. Sigue el ejemplo de ellos. Solo construye un nuevo canvas MVP cuando estés cerca de trabajar en aquel MVP, teniendo en cuenta los conocimientos adquiridos hasta el momento.

Canvas MVP al lado del secuenciador de funcionalidades FOCO EN LA PROPUESTA Cuanto más focalizado esté el MVP, mejor. Este debe validar una necesidad para un segmento de personas y una hipótesis de negocio, y estas generalmente están relacionadas. En algunos contextos, sin embargo, el MVP es más amplio. Sea cual sea el escenario, sé claro sobre la propuesta del MVP.

Pregúntate hasta tener certeza: ¿cuál es la propuesta de este MVP? Un ejemplo de propuesta de MVP: validar si los residentes del barrio Madureira llamarían taxis a través del sitio web. Esta propuesta es muy similar a la historia de EasyTaxi en 2011: “la aplicación comenzó con un MVP ‘conserje’. El equipo de fundadores dejó a disposición una página en internet para que los usuarios ingresaran manualmente la dirección en la que estaban, y cuando daban un clic en el botón ‘llamar mi taxi’ se generaba un e-mail para los socios. Ellos, cuando recibían el mensaje, llamaban a sus cooperativas pidiendo un taxi para esa dirección. ¡Bingo! Con esto, ¡todo comenzó! Los fundadores habían validado una hipótesis básica: muchas personas estaban dispuestas a usar un servicio que llamara taxis por ellas”.

MINIMIZA LOS RIESGOS CON LA SEGMENTACIÓN DE PERSONAS Los participantes de la lean inception ya pensaron en el MVP y sus funcionalidades. También realizaron la actividad sobre personas y, probablemente, hicieron consideraciones sobre ellas para decidir sobre el MVP.

Sin embargo, a medida que van completando la sección de personas y plataformas en el canvas MVP, estarán demostrando sus decisiones de inmediato. Al llenar el canvas MVP, la pregunta sobre las personas es diferente de la reflexión sobre las personas en el comienzo de la inception. Ya no estamos hablando de las personas del producto como un todo, estamos siendo más específicos.

¿Para quién es este MVP específico? ¿En qué plataforma estará disponible? Al responder estas preguntas, el grupo debe deliberar sobre el lanzamiento de MVP y cómo minimizar sus riesgos. Por ejemplo, el grupo puede decidir que un MVP estará restringido a un grupo de personas más pequeño y que el mismo conjunto de funcionalidades solo se lanzará para un grupo más grande después de verificar el resultado esperado. La misma lógica se aplica a la plataforma. Por ejemplo, el grupo puede decidir que un MVP se restringe a una plataforma móvil específica y que el mismo conjunto de funcionalidades solo se lanzará a otra plataforma después de verificar el resultado esperado. MEJORA LA EXPERIENCIA EN LOS VIAJES Si el grupo siguió las actividades de Lean Inception, los viajes debieran estar visibles. En ellos se puede ver el paso a paso del segmento de persona hasta alcanzar sus objetivos. E incluso si el grupo no tiene los viajes visibles, la siguiente pregunta debe ser respondida en el bloque viajes:

¿Cuáles viajes serán cumplidos o mejorados con este MVP? El viaje mapea la experiencia que entregas a tus usuarios. La respuesta a esta pregunta presenta, claramente, qué es lo que tu producto está proveyendo en el MVP. Durante el proceso de completar el canvas MVP, la conversación sobre los viajes debe estar más focalizada de lo que estuvo en la actividad “Mostrando los viajes de usuario” de Lean Inception. En esta instancia, solamente se reevalúan y anotan los viajes de las personas segmentadas que han sido cumplidos o mejorados en el MVP. Si tuvieses dificultad en describir al menos un viaje, reevalúalo, pues quizás tu MVP realmente no contempla nada para nadie (es menos que el mínimo viable). Si describes muchos, también reevalúa, pues quizás tu MVP es demasiado amplio (recuerda que la “M” de MVP significa mínimo, no máximo). No debes cumplir todos los viajes. Aquellos se irán cumpliendo a medida que el producto evolucione. REEVALÚA LAS FUNCIONALIDADES DEL MVP El secuenciador presenta la lista de funcionalidades para el MVP, comienza por ahí. A continuación, verifica los bloques que ya fueron completados: propuesta del MVP, segmentos de personas y viajes. Reevalúa la lista y haz las siguientes preguntas sobre las funcionalidades: » ¿Son realmente el mínimo? » ¿Van a conseguir un producto viable?

» ¿Podríamos crear algo aún más simple? » ¿Olvidamos de incluir algo esencial para el MVP? Conversa, haz los ajustes y las alteraciones necesarias. Al final, relee todo el bloque de funcionalidades y verifica si las siguientes preguntas están siendo respondidas:

¿Qué vamos a construir en este MVP? ¿Qué acciones serán simplificadas o mejoradas en este MVP? DESARROLLO IMPULSADO POR HIPÓTESIS Lo que queremos es un diseño centrado en el usuario. Para crear el MVP, debemos considerar a los usuarios y sus viajes. Deberíamos trabajar en las acciones que mejoran o simplifican sus vidas. Pero eso no es todo. También debemos describir las hipótesis del negocio para entender si estamos realmente avanzando, si realmente estamos alcanzando los resultados deseados o aprendiendo. Luego de definir las funcionalidades del MVP, debemos relacionarlas con los resultados esperados y las hipótesis de negocio. El siguiente modelo ayuda con dicha declaración:

Este modelo es una adaptación del modelo de Jeff Gothelf de desarrollo orientado a la hipótesis. El equipo debe completar este modelo, porque si no lo hace no se sabrá qué esperar del MVP o no se sabrá cómo medirlo. En ambos escenarios, el producto está a la deriva, sin dirección. Este poderoso modelo para decisiones basadas en hipótesis se incluye en el canvas MVP, en las secciones resultado esperado y métricas para validar las hipótesis de negocio.

¿Qué aprendizaje o resultado estamos buscando en este MVP? ¿Cómo podemos medir esto? Importante: no crees funcionalidades para un producto si no sabes describir lo que esperas como resultado ni cómo medirlo. Es importante resaltar que el aprendizaje también es un resultado. Pero, para aprender debemos, al menos, declarar esto: el resultado esperado es aprender. Luego intentamos recolectar datos para alcanzar el aprendizaje deseado. CONVERSA SOBRE EL COSTO Y EL CRONOGRAMA

Inevitablemente, luego de responder “¿cuál es el MVP?” (pregunta que estará muy bien respondida en los seis primeros bloques del canvas MVP), nos preguntaremos “¿cuándo?” y “¿cuánto?”.

¿Cuál es el costo y el cronograma para este MVP? En el canvas MVP, esta pregunta es dejada a propósito para el final, ya que debe ser respondida después de que los otros bloques sean completados. Es importante que todos participen de este momento, conversen y respondan esta pregunta. Estimar es un asunto delicado, y es necesario servirse de muchas técnicas y contar con muchas personas alertando sobre el problema de las estimaciones. Como dice Ron Jeffries, uno de los precursores de Extreme Programming, “las estimaciones son difíciles cuando los requisitos son vagos, y parece que siempre lo son. [...] Incluso con requisitos claros —y parece que nunca lo son— es casi imposible saber cuánto tiempo se va demorar”. Anteriormente, en este libro se presentó un cálculo por muestreo para ayudar en la comprensión del esfuerzo, tiempo y costo asociado a la creación de funcionalidades del MVP. Además del costo de la creación, ¿qué otros costos están asociados al MVP? Por ejemplo, ¿tenemos alguna campaña de marketing asociada al trabajo? ¿algún otro gasto? Considera las respuestas de todas las preguntas que surjan para detallar el costo del MVP.

Muchas veces la pregunta sobre el cronograma está asociada a la pregunta de costo. Una vez más, será el cálculo por muestreo, presentado anteriormente, el que nos ayude a la comprensión del tiempo necesario para crear las funcionalidades del MVP. Ahora bien, además de aquellas, ¿qué más es necesario para el MVP? ¿Algún trabajo de infraestructura antes de comenzar el MVP? ¿existe alguna dependencia externa? ¿Se tiene alguna fecha o tiempo para que aquello acontezca? Considere las respuestas de todas las preguntas que surgieran para crear el cronograma del MVP. LA ESTRATEGIA MVP El canvas MVP es una herramienta para validar ideas de productos. Es una pizarra visual que ayuda a un grupo de personas a alinearse y definir la estrategia del MVP. El canvas tiene elementos que describen la propuesta o visión del MVP, las hipótesis de negocio con sus métricas, las personas y sus viajes, las funcionalidades, cuánto cuestan estas y cuánto tiempo lleva crearlas. A partir de Lean Startup, tenemos el ciclo construir-medir-aprender. Este ciclo está representado por las secciones funcionalidades, resultados esperados y métricas para la validación de hipótesis, que responden a las siguientes preguntas: ¿qué vamos a construir en este MVP? ¿Cómo mediremos los resultados de este MVP? ¿Qué aprendizaje o resultados buscamos en este MVP?

Canvas MVP y el ciclo construir-medir-aprender El ciclo construir-medir-aprender parece ser directo, pero es difícil ponerlo en práctica debido a la combinación de un enfoque de experimentación (construir para aprender) con una mentalidad de diseño (aprender a construir). Para ayudar a comprender y construir el MVP, complementamos este ciclo con otro: usuarioviaje-acción, que nos brinda un enfoque de Design Thinking, centrándonos en el aprendizaje de las personas y sus viajes.

Construir para aprender o aprender para construir

¿Para quién es este MVP? ¿Qué viaje mejorará en este MVP? ¿Qué acción se simplificará o mejorará en este MVP? La respuesta a estas tres preguntas completa el ciclo usuario-viaje-acción.

Canvas MVP y el ciclo usuario-viaje-acción Mientras completamos el canvas MVP, colocamos dos ciclos, uno al lado del otro: el ciclo construir-medir-aprender de Lean Startup, y el ciclo de usuario-viajeacción de Design Thinking.

Canvas MVP = aprender para construir + construir para aprender Los ciclos se superponen en la sección de funcionalidades: ¿qué funcionalidades se van a construir para este MVP? Ten en cuenta que esta pregunta se puede expresar de dos maneras diferentes: (1) ¿qué vamos a construir en este MVP? y (2) ¿qué acciones van a simplificarse o mejorarse en este MVP? Construir, de Lean Startup, o acción, de Design Thinking. Ambos se refieren a las funcionalidades del MVP disponibles para sus usuarios. Por tal razón, la sección de funcionalidades está en medio del canvas, representando su punto central.

“Las grandes cosas se hacen por una serie de pequeñas cosas reunidas.” Vincent Van Gogh Muchas gracias por haberme acompañado en este viaje por Lean Inception, espero que marque la diferencia en tus negocios y que tu producto mínimo viable (MVP) sea todo un éxito. 8 Plantilla “La visión del producto”, descrita en el libro Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, de Geoffrey A. Moore (1999).

Sabbagh, Rafael (2013). Scrum: Gestão ágil para projetos de sucesso, Casa do Código, www.casadocodigo.com. 9 br/products/livro-scrum. 10Sutherland, Jeff (2014). Scrum: The Art of Doing Twice the Work in Half the Time, Crown Business. 11 Patton, Jeff (2010). “Personas pragmáticas”, StickyMinds, www.stickyminds.com/article/pragmatic-persona s. 12Empresa de visual thinking, fundada en 1993 por Dave Gray. 13 Osterwalder, A., Pigneur, Y. (2009). Business Model Generation, A Handbook for Visionaries, Game Changers, and Challengers, OSF, Amsterdam. 14Intervalo prefijado durante el cual se crea un incremento del producto utilizable, potencialmente entregable. 15 Artículo sobre el canvas MVP (incluye archivo para impresión) por Paulo Caroli (2018). Disponible en: www.caroli.org/el-canvas-mvp. Acceso en septiembre de 2018.

EJEMPLO DE UNA LEAN INCEPTION “Me gustaría ver un ejemplo completo de una lean inception”. Este es un pedido recurrente que he recibido de los lectores de este libro. Imagino que será más fácil leer este libro para quien ha participado en un taller, o en una inception al estilo lean. Por más que un libro explique los ingredientes de la receta y los pasos de cada actividad, entiendo que algunos lectores pidan un ejemplo completo. Es como seguir una receta para hacer un brownie especial de chocolate después de haber experimentado un brownie de chocolate tan especial. Y esto es lo que quiero compartir en este capítulo. Por motivos de confidencialidad de las empresas que me contrataron para facilitar dichas lean inception, no puedo compartir el resultado de las actividades para sus productos. Muchos de estos productos comenzaron como lean, con sus MVP incrementales, y hoy en día son productos únicos en sus áreas de acción. Por esta razón, he seleccionado un ejemplo real, muy ilustrativo, y que puede ser compartido. Este producto lean se diseñó para un taller de Lean Inception en una gran conferencia, y como este taller tuvo más de veinte participantes, la idea del producto fue concebida y compartida con todos los participantes. Como el taller fue de ocho horas, la agenda semanal típica de una lean inception fue comprimida con el fin de encajar en unas pocas horas. La agenda burn-up fue esencial para mantener a todos alineados en la rapidez con que tendríamos que seguir el ritmo de la lean inception. Reitero que el contenido y las fotos que vienen son solo un ejemplo ilustrativo logrado en un día, así que probablemente se redujo la cantidad de artefactos generados: personas, viajes y funcionalidades. El propósito era alcanzar el mínimo necesario para cada actividad con el fin de demostrar la técnica de Lean Inception, y simular el ambiente colaborativo de una lean inception.

KICK-OFF El día comenzó con un rompehielos. He utilizado Zip Zap Zoom. Duró menos de diez minutos, y fue útil para compartir los nombres. Empezamos el día con mucha energía y nos reímos mucho. En lugar de un kick-off típico, generalmente realizado por stakeholders hablando sobre un producto o idea a ser concebida durante la lean inception, el kick-off de un taller de simulación tiene otro estilo. Pregunté a los participantes qué ideas tenían de producto y que quisieran explorar como un ejemplo del taller durante el día. Se presentaron tres ideas de productos, y luego todos los participantes votaron a favor de la idea que querían utilizar como un ejemplo para el taller. VISIÓN DEL PRODUCTO El producto más votado fue una aplicación para aficionados del fútbol. Personas que les gusta jugar con sus amigos de trabajo, del gimnasio o con algún grupo de colegas dispuestos a coordinar un partido. Para ayudar a las tres personas que propusieron ideas y describir sus ideas, fomentar la participación de todos y proveer una votación con un buen entendimiento de las mismas, utilizamos una plantilla de visión de producto para cada idea. En grupos de siete personas, quienes propusieron las ideas y otros participantes describieron la visión de cada producto. Para aficionados Que tienen dificultad para encontrar partidos de fútbol Easy-ball Es una aplicación móvil Que facilita el encontrar partidos de fútbol En lugar del boca a boca Nuestro producto maximiza las posibilidades de encontrar un partido de fútbol

Este es el resultado de visión del producto para la idea de la aplicación para aficionados. Las siguientes actividades en este capítulo se relacionan con el producto Easy-ball. Tales actividades ayudan a la comprensión del producto lean, los MVP que serán construidos para la creación y validación de esta aplicación móvil. EL PRODUCTO ES/NO ES/HACE/NO HACE A continuación, se realizó la actividad “Es/No es/Hace/No hace” para ayudar con la definición de Easy-ball. Esta actividad ayudó a clarificar más la idea del producto, centrándose en el MVP y en eliminar el exceso de funcionalidades iniciales. En este momento surgieron conversaciones importantes como: » Esta aplicación será gratuita » Va a tener un sitio en línea » La geolocalización es muy interesante » Esta aplicación no crea equipos, gestiona pagos u organiza campeonatos Y el resultado logrado fue el siguiente: » El producto es: app, app móvil, multiplataforma, facilitador para organizar partidos, gratuito. » El producto no es: FB, twitter, whatsapp, sitio, no es un chat, messenger (chat). » El producto hace: programa los partidos (agenda), agenda canchas, lista de partidos, encuentra partidos cercanos, geolocalización, notificaciones sobre eventos, notifica a los usuarios, rankea usuarios, guarda reputación. » El producto no hace: organiza partidos, define partidos a pedido, organiza partidos y equipos, arma equipos, gestiona los pagos, provee pago en línea del partido, agenda juegos privados, organiza campeonatos, provee campeonatos. ENTENDIENDO LOS OBJETIVOS

Después de las actividades de visión del producto y “Es/No es/Hace/No hace” realizamos una actividad para aclarar el objetivo del producto. En este momento solicitamos a todos los participantes que compartieran el conocimiento que tenían de los tres objetivos principales del producto. Cada participante escribió tres post-its. Al recoger los post-its y ponerlos en grupos de afinidad, se identificaron tres objetivos principales para el producto: » Búsqueda de partidos » Divulgación de partidos » Opciones de partidos IDENTIFICANDO A LAS PERSONAS Después de una buena comprensión del producto, era el momento de cambiar el enfoque y conseguir un buen entendimiento con respecto a las personas, los usuarios del sistema. Para ello, se utiliza la plantilla de los cuadrantes para identificar los tipos de personas. Con esta plantilla, creamos alias para cada tipo de persona, describimos sus respectivos perfiles, sus características de comportamiento y sus necesidades específicas. Incluso teniendo poco tiempo, todos los participantes participaron en los grupos de creación de personas mientras se divertían con sus descripciones, dibujos y apodos. Para crear a las personas, los veinte participantes se dividieron en tres grupos más pequeños. Cada grupo creó dos o tres personas, y las presentaron a todos los participantes. Luego, las personas duplicadas (o muy parecidas) fueron descartadas, y todos los participantes votaron por las primeras cuatro personas mas importantes para el producto. Esta fue la persona más votada: fanático del fútbol. » Nombre: Fanático del fútbol » Perfil: 28 años, casado, jugador frustrado, trabaja en un banco y está graduado

» Comportamiento: bueno para quejarse, competitivo, activo, exigente, pasa horas en las redes sociales » Necesidades: jugar cada semana con cualquier persona y en cualquier lugar, pero busca partidos de un buen nivel, jugar en la noche los fines de semana DESCUBRIENDO LAS FUNCIONALIDADES Después de haber desarrollado el producto, los objetivos y las personas, llegó la hora de pensar nuevas funcionalidades (características previstas para el producto lean). Para eso utilizamos la actividad “Descubriendo las funcionalidades”. Los objetivos estaban presentados como encabezados de columnas, y las personas como encabezados de filas, lo cual conforma el tablero para el brainstorming de funcionalidades. Y, con ello, el facilitador puede promover la actividad. ¿Qué es lo que debe tener el producto para cubrir las necesidades de la persona? ¿Cuáles funcionalidades debemos construir para cumplir el objetivo del producto? Con estas preguntas, la discusión es guiada para descubrir las funcionalidades que son necesarias para alcanzar los objetivos y las personas. Son anotadas en post-its y colocadas en el tablero. Las preguntas se repiten para cada combinación de persona y objetivo y, con ello, son priorizados los principales objetivos y las principales personas. Sigue a continuación el resultado de la actividad: » Revisar si hay partidos con geolocalización » Revisar si hay partidos sin geolocalización » Ranking de canchas » Rankear un jugador » Detalles del partido (lugar, fecha y hora) » Ranking de jugadores (visualización)

» Detalles financieros del partido » Registro del jugador » Registro del partido » Invita a un amigo al partido » Filtro detallado » Módulo de notificaciones » Confirmación de asistencia (RSVP) » Notificación de partido confirmado » Notificación de partido cancelado » Cancelar asistencia » Cancelar partido ENTENDIMIENTO TÉCNICO, DE NEGOCIO Y DE EXPERIENCIA DE USUARIO Las funcionalidades fueron descubiertas, pero fueron aceptadas sin cuestionamientos, sin perder mucho tiempo en comprenderlas en detalle, tomando notas y hablando de las certezas, el esfuerzo y valor para el negocio. Sin embargo, estas conversaciones e información más detallada son muy útiles para una mejor comprensión y planificación a la hora de crear productos lean. Las actividades y gráficos de comprensión técnica, de negocio y esfuerzo; experiencia de usuario y valor de negocio, buscan dicha información de forma rápida y eficiente.

Cada funcionalidad pasa a través del gráfico y de la tabla, y, por lo tanto, gana marcas de niveles de certeza, esfuerzo, experiencia de usuario y de valor de negocio. En el gráfico del semáforo la funcionalidad recibe un color. En la tabla, la funcionalidad recibe marcas de experiencia de usuario, valor de negocio y esfuerzo técnico. Además de estas marcas, cualquier información adicional acerca de la funcionalidad se escribe en el post-it y se coloca en la parte posterior de la tarjeta de la funcionalidad. Algunos ejemplos de esas anotaciones son: (1) utilizar API de Google para la geolocalización, y (2) se asume que solo funcionarán con los dispositivos móviles más modernos.

Durante la actividad, se definió que color de la tarjeta representa el nivel de certeza: rojo para un bajo nivel de certeza, amarillo para un medio y verde para alto. Mientras que las marcas de experiencia de usuario, valor técnico y valor de negocio varían en una escala de uno, dos o tres veces comparativamente. Los colores y marcas características ayudaron a los participantes en las actividades posteriores a priorizar, estimar y planificar el MVP. FUNCIONALIDAD

CERTEZA

ESFUERZO

VALOR UX

VALOR NEGOCIO

REVISAR PARTIDOS CON GEOLOCALIZACIÓN

AMARILLO

EE