Directo Alp Unto

Lean Inception Creando conversaciones hacia un producto exitoso Paulo Caroli, María Fernanda Escudero, Freddy Coronel and Patricia Trejo This book is for sale at http://leanpub.com/directoalpunto This version was published on 2018-11-14

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. © 2015 - 2018 Paulo Caroli, María Fernanda Escudero, Freddy Coronel and Patricia Trejo

Contents Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i

Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . .

iii

Como leer este libro . . . . . . . . . . . Construyendo el producto correcto . Preparando el taller . . . . . . . . . Ejecutando la Incepción Lean . . . . Anexos . . . . . . . . . . . . . . . . .

. . . . .

v v v vi vi

Construyendo el producto correcto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

Desarrollo de producto que importa . . . . . . . La Incepción, el comienzo de un proyecto ágil ¿Por qué se llama Incepción Lean? . . . . . . . ¿Por qué una Incepción Lean? . . . . . . . . . La agenda de la Incepción Lean . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2 2 3 4 6

Producto Mínimo Viable . . . . . . . . . . . . Origen . . . . . . . . . . . . . . . . . . . . . Incrementos del MVP . . . . . . . . . . . . Hipótesis pequeñas, grandes negocios . . . Un ejemplo de evolución a través de MVP Visión amplia, producto mínimo . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

7 8 9 10 13 14

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

CONTENTS

Valioso, Usable y Factible . . . El factor WUAU . . . . . . . . Cuidado de no romper . . . . . Legado y bloques organizados Embudo de ventas - AARRR . ¡Haga una Incepción Lean! . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

16 17 21 23 24 26

. . El taller de Incepción Lean . . . . . . . . . . Directo al Punto, la técnica . . . . . . . . . . Colaboración . . . . . . . . . . . . . . . . . . Diviértase con los Rompe-hielos . . . . . . . Colocación . . . . . . . . . . . . . . . . . . . La sala de guerra . . . . . . . . . . . . . . . . Post-its coloridos . . . . . . . . . . . . . . . . La agenda Burn-up . . . . . . . . . . . . . . . Espacios de tiempo fijo y la agenda burn-up El rol del facilitador . . . . . . . . . . . . . . Estacionamiento . . . . . . . . . . . . . . . . Checklist para la Incepción . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

27

. . .

41

. . . .

. . . .

42 44 47 48

Describiendo las Personas . . . . . . . . . . . . . . . . . . . Cuadrantes para identificar tipos de personas . . . . . . Creando Mapas de Empatía . . . . . . . . . . . . . . . . .

51 52 54

Descubriendo las Funcionalidades . . . . . . . . . . . . . .

58

Preparando el workshop

Ejecutando la Incepci�n Lean Escribiendo la Visión del Producto . . . . El producto Es - No es - Hace - No hace Aclarando el objetivo . . . . . . . . . . Entendiendo los trade-offs . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

27 28 29 29 31 32 33 34 35 36 38 40

CONTENTS

Entendimiento Técnico, de Negocio y de Experiencia de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . Certidumbre Técnica y Conocimiento de Negocio . . . . Esfuerzo, Experiencia de Usuario y Valor de Negocio . .

62 69 72

Presentando las Jornadas de Usuario . . . . . . . . . . . . .

76

Exponiendo Funcionalidades en las Jornadas . . . . . . . .

82

Secuenciando las Funcionalidades . . . . . . . . . . . . . . El Secuenciador de Funcionalidades . . . . . . . . . . . . Las Ondas del Secuenciador de Funcionalidades . . . . . Las reglas para cada onda . . . . . . . . . . . . . . . . . . Convergiendo reglas y jornadas . . . . . . . . . . . . . . Identificando MVPs en el Secuenciador de Funcionalidades

87 88 90 91 92 95

Calculando esfuerzo, tiempo y costo . . . . . . . . . . . Detallaando las funcionalidades de muestra en tareas Estimación comparativa . . . . . . . . . . . . . . . . . Entendiendo el Costo y el tiempo . . . . . . . . . . . Calculando el promedio de una onda . . . . . . . . .

. . . . .

. . . . .

99 100 103 106 108

Construyendo el MVP Canvas . . . . . . . . . . . . . . . Completando el MVP Canvas . . . . . . . . . . . . . . El secuenciador de funcionalidades y el MVP Canvas Segmentos de Personas . . . . . . . . . . . . . . . . . Funcionalidades . . . . . . . . . . . . . . . . . . . . . . Jornadas . . . . . . . . . . . . . . . . . . . . . . . . . . Desarrollo Impulsado por Hipótesis . . . . . . . . . . Visión del MVP, Costo y Programación . . . . . . . . La estrategia MVP . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

112 112 114 116 117 117 118 119 120

Anexo

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Anexo A - Ejemplo de una Incepción Lean . . . . . . . . . 124

CONTENTS

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . 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 las jornadas . . . . . . . . . . . . . . . . . . Exponiendo funcionalidades en las jornadas . . . . . . . Secuenciando las funcionalidades . . . . . . . . . . . . . Construyendo el MVP Canvas . . . . . . . . . . . . . . . Anexo B - Glosario . . . . . . . . . . . . . . . . . . . . . . Visión del Producto . . . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . Personas . . . . . . . . . . . . . . . . . . . . . . . . . . Funcionalidad . . . . . . . . . . . . . . . . . . . . . . . Valor de Experiencia de Usuario de la funcionalidad Jornada . . . . . . . . . . . . . . . . . . . . . . . . . . MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

125 125 125 127 129 129 131 132 138 140 142 145 147 147 147 147 148 149 149 150

Anexos C - Niveles de Competencia del Facilitador . . . . 151 Anexo D - La agenda Burn-up Los ejes de la agenda . . . . Los temas de la agenda . . Los intervalos de tiempo . . El objetivo y el ritmo . . . . La línea del alcance . . . . . Verificando el progresso . . Escogiendo . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

153 154 155 156 156 157 158 160

Anexo E - Actividades Rompe-hielo . . . . . . . . . . . . . 161 Paulo Puntual . . . . . . . . . . . . . . . . . . . . . . . . . 161

CONTENTS

Localización Geográfica . . . . Teléfono Visual . . . . . . . . . Uno Dos Ping Cuatro Pong . . Formando Triángulos . . . . . Zip Zap Zoom . . . . . . . . . . Desenredarse . . . . . . . . . . Batalla de Globos . . . . . . . . Piezas Complejas . . . . . . . . Dibujo Colaborativo de Caras . De Espaldas . . . . . . . . . . . Encuentre Su Par . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

163 164 165 166 168 170 171 172 173 175 176

Acerca del autor . . . . . . . . . . . . . . . . . . . . . . . . . 178 Acerca del los tradutores . . Patricia Trejo . . . . . . . María Fernanda Escudero Freddy Coronel . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

179 179 180 180

Sobre la Editora Caroli . . . . . . . . . . . . . . . . . . . . . 181 WIP (Writing In Progress) . . . . . . . . . . . . . . . . . . 181

Prefacio La visión ingenua del desarrollo de software ágil es que todos simplemente se sumergen y comienzan a escribir código sin pasar tiempo al principio pensando en qué hacer. Esa visión, aunque es tan errónea como simplista, se basa en un cambio genuíno de pensamiento. Antes del ascenso de Agile, la gente seria de software aconsejaba períodos largos de recopilación de requerimientos y arquitectura, donde un proyecto de cinco años podría pasar un año o dos antes de que se haya escrito el código, y mucho menos lanzado en producción. El mundo ágil ha descartado aquellos largos períodos de análisis previo, pero aún reconocemos que tiene valor establecer um sentido inicial de dirección. El desafío es descubrir cómo podemos hacer esto rápida y eficientemente, a la vez que recordamos que nada nos enseña lo que queremos más que un producto incompleto que se lanza y está en uso. Por lo tanto, debemos equilibrar el establecimiento de la dirección con el conocimiento de que ese pensamiento inicial es lo más tentativo. En ThoughtWorks, nuestra respuesta ha sido un proceso llamado Incepción. Nos reunimos juntos 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 captura de objetivos amplios. No intentamos tener una especificación detallada, ya que es exactamente el tipo de cosa que se convierte en fuera de fecha tan pronto como el código llega a producción. Pero 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 la Lean Inception, Paulo ha capturado su experiencia en la ejecución de estas Incepciones en la última década. En particular,

Prefacio

ii

se centra en su trabajo para pulir la Incepción hasta su esencia, concentrando la actividad en una única, pero muy intensa, semana de trabajo. Paulo comparte cómo hace este trabajo, a través de la escritura de una visión de producto, capturando personas, entendiendo las jornadas del usuario y desarrollando funcionalidades de alto nivel. El resultado no es un plan de trabajo detallado, ya que encontramos que se vuelve irrelevante rápidamente. 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, en cambio, se enfoca en un producto inicial que podemos lanzar y del cual aprender: el Mínimo Producto Viable. Este producto actúa como punto de partida para evolucionar un producto de una forma más rica y más capaz, y de nuevo podemos utilizar Incepciones Lean 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 Incepciones Lean. Hay un calendario para la actividad de la semana, detalles de los ejercicios que serán hechos, y consejos para ayudar al equipo a aprender del lanzamiento del mínimo producto viable. Los esfuerzos de la semana se resumen en un MVP Canvas que actúa como salida y resumen del trabajo. Armado con la experiencia de Paulo, puede practicar esta técnica y evolucionarla para adaptarse a sus circunstancias. –Martin Fowler martinfowler.com

Agradecimientos Gracias, ThoughtWorks y ThoughtWorkers por inspirarme y utilizar mis actividades de Incepción Lean. Realmente creo que este increíble contenido surgió de un contexto muy específico del que formas parte. 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 Incepción e hicieron posible este trabajo. Mi agradecimiento especial a Jeff Patton y Jonathan Rasmusson, con quienes tengo el placer y el privilegio de aprender. Gracias, a todos los que leyeron, usaron y compartieron sus comentarios sobre la Incepción Lean. Este contenido evolucionó debido a la gran retroalimentación y las experiencias compartidas. Solo me di cuenta de que esto era algo especial una vez que supe de su éxito cuando lo aplicaron otros facilitadores. Gracias a Martin Fowler por entrenarme y preguntar por este contenido en inglés. Realmente aprecio su apoyo e incentivo al compartir prácticas importantes con nuestra gran comunidad, como la Incepción Lean. Gracias a Patrick Sarnacke por la revisión detallada de los contenidos de este libro. Realmente aprecio sus contribuciones desde 2008, el año en que comenzó a aprender y a mejorar el brasileñoinglés. Gracias a mi familia por el amor y el apoyo mientras sigo leyendo y escribiendo, en la 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 incepciones, pero te quiero más y no podía estar lejos por más de unos pocos días. Tuve que hacerlas más sencillas para volver más rápido.

Agradecimientos

¡Definitivamente me has inspirado!

iv

Como leer este libro ¡De principio a fin! Este es un libro corto y práctico, como su título lo dice: Directo al Punto. Por ende, usted debe leer todo, de inicio a fin. El libro está estructurado en cuatro partes: Construyendo el producto correcto, Preparando el taller, Ejecutando la Incepción Lean y Anexos.

Construyendo el producto correcto Para comenzar, cuento mi historia con incepciones y por qué creé el concepto de Incepción Lean. Este libro está basado en el concepto de MVP, abreviación de Producto Mínimo Viable (Minimum Viable Product en inglés). El capítulo destinado para ello presenta el concepto y su historia, así como mi visión de MVP y de la evolución de productos lean.

Preparando el taller Esta sección explica en detalle el formato de taller colaborativo que le ayudará a entender, alinear y planificar el producto que será construído. Probablemente sea el comienzo de un proyecto ágil en una gran empresa, o el alineamiento sobre qué construir en una pequeña start-up. El estilo colaborativo y dinámico de la Incepción Lean es el ingrediente secreto del chef en esta receta.

vi

Como leer este libro

Ejecutando la Incepción Lean Directo al Punto 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 siguiente el orden de los capítulos, comenzando en el capítulo 4 - Escribir la Visión de Producto, y finalizando en el capítulo 12 - Construir el Canvas MVP.

Anexos Un libro con el título Directo al Punto, obliga al autor a hacer uso de anexos. Considero que todo el contenido del libro esencial. Sin embargo, es aquí en los Anexos en donde puede encontrar lo que fue siendo sumado en el tiempo basado en el feedback de los lectores. El Anexo A trae un ejemplo real de la comprensión y planificación de un producto lean a partir de la receta Directo al Punto aplicada en una Incepción súper lean: ¡realizada en apenas seis horas!. Algunos lectores me relataron que primero leyeron este anexo (disponible en mi blog y en la revista InfoQ) y después leyeron el libro desde el principio. Los Anexos B, C, D y E proporcionan, respectivamente, el glosario de los términos del libro, una clasificación de los niveles de competencia del facilitador, un desglose sobre la agenda burn-up y algunas actividades para romper el hielo. Feliz lectura y sea bienvenido al grupo de facilitadores de Directo al Punto.

Construyendo el producto correcto

Desarrollo de producto que importa Los proyectos ágiles hacen énfasis en la entrega temprana y continua de software con 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 de MVP Producto Mínimo Viable o 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 la Incepción Lean para responder a estas preguntas.

La Incepción, el comienzo de un proyecto ágil El agilismo tradicional no tiene un trabajo previo, pero en la práctica nos damos cuenta de que tenemos que hacer algo. Para ThoughtWorks, la Incepción es ese “algo”. Desde que me uní a ThoughtWorks en 2006, me di cuenta de que todos los proyectos ágiles de la compañía comenzaron de manera similar. El equipo del proyecto se reunía durante algunas semanas, realizando muchas

Desarrollo de producto que importa

3

actividades antes de comenzar el trabajo de entrega: aquello fue la incoación. La Incepción 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 incoación en sus libros, de las cuales aprendí mucho. Nuestras increpaciones varían de un proyecto a otro, pero generalmente generan una alineamiento entre el negocio y las personas técnicas, y crean una lista ordenada de historias de usuarios con estimaciones junto a un plan de lanzamiento. Y estuve muy satisfecho al facilitar estas incepciones ágiles de esta forma hasta 2011, el año en que nació mi hijo. El asunto es que yo fui el facilitador inicial, pero la incepción tomaría de dos a cuatro semanas. Y no podía quedarme fuera de casa por más de una semana. Tuve que hacer las incepciones más lean, para de alguna manera hacerlas calzar en una semana. Iba en mi primer viaje después de que nació mi hijo. En un largo vuelo desde São Paulo a San Francisco, leí el libro 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 una semana.

¿Por qué se llama Incepción Lean? Este nuevo estilo de incepción es definitivamente un cambio desde el inicio de 2006. El equipo ya no escribe ni estima historias de ¹The Agile Samurai: How Agile Masters Deliver Great Software, by Jonathan Rasmusson, Pragmatic Bookshelf, 2010. ²User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton (Author) and Peter Economy (Editor), O’Reilly Media, 2014 ³RIES, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing, 2011.

Desarrollo de producto que importa

4

usuarios. Al experimentar con este nuevo estilo, el nombre de incepción dio a todos el mensaje errado. Necesitaba un nombre diferente. El nuevo estilo de incepción es lean por dos razones: 1. La duración de la incepción es más corta, eliminando todo lo que no fuera sobre el producto (como arquitectura, proyecto, etc.), lo que hace que sea lean. 2. El resultado final de la incepción es la comprensión del MVP, un concepto principal del movimiento Lean StartUp. Por lo tanto, el nuevo estilo de incepción tenía un nombre principal claro: La Incepción Lean.

¿Por qué una Incepción Lean? Una incepción lean es útil cuando el equipo necesita desarrollar un MVP iterativamente. Aunque el término a menudo se malinterpretado, 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 hacen tal que el producto les da soporte y cómo medir si es que les resulta útil el producto.

Desarrollo de producto que importa

5

únetenos en una incepción lean

Hemos encontrado que el taller es valioso en dos circunstancias principales: • Los proyectos grandes encuentran que una incepción lean 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. • Las organizaciones más pequeñas (como las startups) usan incepciones lean para tomar una idea que ha sido probada por algunos MVPs pre-software y evolucionarla en un producto de software. Este taller es específicamente sobre la comprensión de un MVP, 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

Desarrollo de producto que importa

6

estas otras actividades depende mucho del contexto específico de su organización y del esfuerzo de desarrollo en el que está trabajando.

La agenda de la Incepción Lean La incepción lean consiste de una serie de actividades, generalmente programadas en el curso de una semana. Explicaré cada actividad en la sección del libro llamada [Ejecutando la Incepción Lean] (#actividades).

ejemplo de agenda semanal

Este es un ejemplo deagenda, por favor no lo trate como algo fijo, pero déjelo como un buen ejemplo de cómo pueden fluir las cosas.

Producto Mínimo Viable Una nueva forma de crear y evolucionar productos, entregando solamente el mínimo viable ha sido fundamental para ayudar a miles de emprendedores a lanzar productos fantásticos. Vea 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. Los beneficios de entregar el mínimo viable le ayudará a llevar su producto al mercado de forma mucho más rápida, a minimizar sus gasto y a evolucionar su producto basado en la necesidad real de sus usuarios. La excelente idea de crear sólo el mínimo viable de su 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, usted no quiere desperdiciar tiempo, dinero y esfuerzo construyendo un producto que no va cubrir sus expectativas. Por esa razón 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 para 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. El

8

Producto Mínimo Viable

conjunto inicial de funcionalidades necesarias para la validación de la hipótesis y para aprender más acerca del negocio.

Origen La idea del MVP está originalmente conectada a las ideas que se volvieron populares con el estilo de manufactura de Toyota ⁴ ⁵ ⁶. Steve Blank, un emprendedor de Silicon Valley, creó una metodología ⁷ basada en el desarrollo del cliente. Ese fue el inicio de un 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 MVP desde la publicación de su libro “Lean StartUp”, la expresión estuvo en uso por 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”. ⁴WOMACK, James P.; JONES, Daniel T., and ROOS, Daniel. The Machine That Changed the World: The Story of Lean Production– Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Ind. Free Press; Reprint, 2007. ⁵OHNO, Taiichi. Toyota Production System. Productivity Press, 1988. ⁶WOMACK, James P.; JONES, Daniel T.. Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated. Free Press; 2nd edition, 2003. ⁷BLANK, Steve G. The four steps to the epiphany: successful strategies for products that win. K & S Ranch; 5th edition, 2013. ⁸RIES, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing, 2011. ⁹WILLIAN, S. Junk. The Dynamic Balance Between Cost, Schedule, Features, and Quality in Software Development Projects, Computer Science Dept., University of Idaho, SEPM-001, 2000.

Producto Mínimo Viable

9

Incrementos del MVP El MVP no significa que el producto no va 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 MVP: nuevos productos mínimos agregados al producto mínimo ya validado. Una vez más, productos mínimos pero viables para 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 libro 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 más 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 Lean StartUp: ciclos rápidos para validar las hipótesis. Ciclos rápidos y frecuentes, permiten periodos muy pequeños de liberación y con bajos costos de experimentación. Pero no es fácil de implementar este tipo de enfoque. Y los creadores de productos ¹⁰HUMBLE, Jez and FARLEY, David. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley, 2010.

Producto Mínimo Viable

10

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 basado en MVP. La Entrega Continua es una Biblia para entender las herramientas necesarias para la creación y evolución de productos de software. Pero aún más, las técnicas y aprendizajes compartidos por los autores de Entrega Continua son aplicadas para otras clases de productos, no solo productos de software. Lo mismo aplica para este libro.

Hipótesis pequeñas, grandes negocios El producto es construido incrementalmente, con los MVPs recién creados y siendo agregados al sólido producto existente. Con los incrementos de MVP, la entrega continua e incremental proporciona un incremento de valor de producto a través del tiempo, mientras el proceso de creación para productos tradicionales no proporciona un valor sino hasta el final, cuando todo el producto está listo.

Producto Mínimo Viable

11

MVP: ¿necesita llegar más alto? para subir, use la escalera o espere (la construcción) del elevador

Está figura muestra como un MVP ofrece pequeñas validaciones a lo largo del tiempo, mientras que un estilo tradicional de creación de producto solo ofrece una validación de todo al final. Pero, por favor no se deje atrapar por este ejemplo, porque los productos reales no son tan simples como ir de un paso a otro de forma relativamente similar. La siguiente imagen ofrece otro ejemplo de MVP: 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 esto lo hace un gran MVP. Además de permitir cruzar la pequeña corriente del río, es una simple manera de validar la ubicación para construir el puente. Quizás colocar más de un tronco de madera en diferentes ubicaciones, y validar cual tiene un mayor uso.

12

Producto Mínimo Viable

Un puente muy simple

MVP 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 secuencializada en una serie de hipótesis menores, más simples y, luego, más fáciles de entender. El resultado es: 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 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 producto; (2) la complejidad del análisis de la hipótesis se reduce. Los creadores del producto y los usuarios finales tienen un acceso temprano a algo funcional y viable. Así, la decisión de los siguientes pasos e incrementos del producto son basados en el producto mismo, en vez de que sean hipótesis de otras hipótesis. Y este patrón de trabajo en pequeños incrementos del producto y su

13

Producto Mínimo Viable

hipótesis permite construir productos mucho más elaborados, con pequeños pasos pero bien fundamentados.

Un ejemplo de evolución a través de MVP El producto es construido incrementalmente, con los MVP recientemente creados siendo agregados al producto consolidado existente. El último release de MVP es un resultado positivo. Luego el equipo continua la evolución del plan del MVP creando el siguiente conjunto de características para el siguiente release del MVP.

MVPs para cortar césped

Esta figura muestra como un MVP proporciona pequeñas validaciones a lo largo del tiempo, mientras que una creación tradicional del producto sólo valida el producto final. Productos tradicionales se enfocarían en la versión final, por ejemplo, la bonita podadora (MVP 8) en la parte inferior derecha de la figura. 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 en el siguiente MVP. Quizá, algo más

Producto Mínimo Viable

14

conveniente: un aparato cortador de césped con un cable. ¿Qué tal añadirle ruedas? Y así sucesivamente, evolucionando el producto de un MVP a otro MVP. Lo más importante y valioso del feedback es una respuesta negativa. ¿Hay césped que cortar? No. En este caso, las tijeras no serán usadas. A propósito, una bonita y cara podadora no podrá ser usada tampoco. Su hipótesis es falsa, así que un producto completamente desarrollado ¡podría haber sido una gran pérdida de tiempo y dinero!. Este ejemplo ilustra cómo MVP 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 secuencializada en una serie de hipótesis menores, más simples y, luego, más fáciles de entender. Y vale la pena recordar que, felizmente, coproductos de software no son manufactura. En el mundo del software, un tractor de cortar pasto puede ser creado a través de la suma de ruedas, volante, motor y asiento en una tijera de cortar pasto.

Visión amplia, producto mínimo Es importante tener una visión más amplia del producto: completo, abarcador, con diversas funcionalidades para muchos tipos de usuarios, atendiendo muchos objetivos del negocio. ¡Piense en grande, comience pequeño, aprenda rápido!

Es extremadamente importante tener una visión amplia, pensar en grande. Pero para ello, debe comenzar pequeño. Dé un pequeño paso y aprenda a partir del mismo. Ese paso es el MVP.

Producto Mínimo Viable

15

El MVP sirve para validar hipótesis, para fallar y aprender rápido. En ese contexto, menos es más. ¡No desperdicie tiempo, dinero y esfuerzo creando el producto equivocado! El producto puede atender más de un objetivo de negocio, atender varias personas, tener muchas funcionalidades. Sin embargo, un MVP debe validar una hipótesis, comprobar una idea, y verificar si se logra lo que era esperado. M es de mínimo, por eso, muy probablemente, hay sólo una hipótesis, sólo un pequeño aspecto de negocio, para un segmento específico de usuarios, con apenas una o pocas funcionalidades. Vea en la siguiente imagen la representación de un producto elaborado a través de MVP. Cada cajita es un MVP validado por medio del feedback de uso, del interés del negocio y de las posibilidades técnicas.

MVP y la creación evolutiva del producto; caja sobre caja

El producto va crecer y tener más funcionalidades (representadas en la imagen como cajas apiladas). Eso ocurre de MVP en MVP. O mejor aún, de MVP validado en MVP validado. O sea, cada incremento del producto tiene que ser validado. ¡No agregue al producto algo que no haya sido validado!

Producto Mínimo Viable

16

Valioso, Usable y Factible El MVP está en la intersección entre lo valioso, lo usable y lo factible, representando respectivamente, el interés del negocio, la aceptación (y admiración) de los usuarios del producto, y de lo que es posible construir.

MVP, la intersección entre valioso, usable y factible

• 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 MVPs como un paso a paso incremental para la creación del producto. En este contexto, las personas de negocio influencian el MVP para que, aún siendo mínimo, alcance el retorno en la inversión esperando (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

Producto Mínimo Viable

17

están insertos. • Factible — La solución propuesta para atender el negocio y a los usuarios sólo hace sentido si es ejecutable, si existe la tecnología y el conocimiento para su elaboración. No hace sentido definir un MVP si no se sabe cómo será construido.

El factor WUAU El factor WUAU es aquello que diferencia su producto en el mercado, aquello que conquista a sus usuarios y los transforma en ávidos promotores de su producto. Aquello que literalmente hace que las personas digan “¡WUAU!”. Piense en el iPhone cuando recién fue lanzado. Tenía el factor WUAU. sus usuarios decían: “¡WUAU! Una pantalla completa touch… ¡mira que genial!”.

Steve Jobs mostrando el iPhone1

FUENTE DE LA IMAGEN: http://www.t3.com/features/a-briefhistory-of-the-iphone Piense en las primeras personas que pidieron taxi a través de un

Producto Mínimo Viable

18

sitio¹¹. Ellas decían: “WUAU, fue sólo colocar mi dirección, dar click en OK y el taxi llegó”. El factor WUAU es importante para un producto exitoso. Para un MVP, ¡es aún más importante! Vea el ejemplo del iPhone1, el MVP del iPhone. El iPhone 1 no tenía aplicaciones de terceros (y la plataforma de aplicaciones tampoco estaba lista). El iPhone 1 no tenía integración con GPS y las llamadas era peores que en los teléfonos del momento. Las personas hicieron fila para el lanzamiento del iPhone 2, del iPhone 3, y así sucesivamente ¹². Eso por causa del factor WUAU, que transforma usuarios en promotores, generando expectativa y deseo para el próximo incremento. Así debe ser con los MVPs. Cada MVP debe tener los factores: factible, valioso, usable y WUAU.

El MVP es factible, valioso, usable y WUAU ¹¹MVPs no mundo real: o caso do EasyTaxi, por Paulo Caroli, artículo en InfoQ Brasil (2015), Disponible en: https://www.infoq.com/br/articles/mvp-easy-taxi. Acceso al 8 de agosto de 2018. ¹²How Long People Waited to Be First in Line to Buy Apple Products, por Dino Grandoni, artículo en theAtlantic.com (2011), Disponible en: https://www.theatlantic.com/technology/archive/2011/10/how-long-people-waited-befirst-line-buy-apple-products/337087/ , Acceso al 11 de agosto de 2018.

Producto Mínimo Viable

19

La ilustración de arriba reitera la importancia de esos cuatro factores — factible, valioso, usable y WUAU — en cada MVP. El MVP es una delgada faja del producto, conteniendo cada uno de esos factores. No piense en el MVP como una capa de producto (la figura de la izquierda); es decir, por ejemplo, primero entregando lo que es factible, para después elaborar otro factor, después otro y al final buscar el factor WUAU. Construya el MVP conforme se demuestra en el lado derecho de la imagen, una delgada faja de la visión del todo, que contempla los cuatro factores: factible, valioso, usable y WUAU. No por entregar un MVP es que el producto sea malo, simplón, incompetente. No confunda inconcluso con malo, simple con simplón, incompleto con incompetente. El MVP debe ser factible (de ser construido), fácilmente usable, generar mucho valor y ser increíble-¡WUAU!

El MVP debe ser factible (de ser construido), fácilmente usable, generar mucho valor y ser increíble¡WUAU!

Otro ejemplo de MVP con factor WUAU es Facebook. Al comienzo era necesario que usted fuera allá, el MVP. Vea en las imágenes siguientes el inicio de Facebook, o mejor dicho, el inicio de TheFacebook.

20

Producto Mínimo Viable

Sea bienvenido a TheFacebook

Su perfil en TheFacebook

FUENTE DE LAS IMÁGENES: post Facebook Design 2004-2011

Producto Mínimo Viable

21

[Screenshots] en DevilsWorkshop.org en 2013¹³. El inicio de Facebook ilustra la idea de una delgada faja, de MVP. Vea como era simple, inconcluso, incompleto. Entretanto, era factible, usable, tenía valor y era increíble. ¡WUAU, los usuarios querían más!

Cuidado de no romper Los juicios iniciales sobre algo difícilmente pueden deshacerse. La primera impresión es muy importante. Usted quiere dejar una buena impresión de su producto, de su MVP. Usted quiere el factor WUAU. Y, de alguna forma, quiere evitar lo opuesto: una falla que va a dejar marcas. Errar es aprender rápido. Tenga mucha cautela al usar esta frase. Existen errores y errores. Nadie quiere un gran error, aquel que no tiene reparo y deja a su cliente con una pésima impresión. Validar y aprender rápido. Yo prefiero esa frase. En ese caso, usted va crear un MVP que le ayude a validar algo, pero que no deje al usuario “quebrarse” en un error de su producto. Considere 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 evolucionó. Y usted validó cada MVP, cada hipótesis: ¿Será que aquellos transeúntes en bicicleta o motocicleta también usarían ese puente de madera? ¿Y los vehículos de cuatro ruedas? Y el puente evolucionó, de MVP en MVP… ¹³Facebook Design 2004-2011 [Screenshots], por sauravjit, post en DevilsWorkshop.org (2013), Disponible en: http://devilsworkshop.org/facebook-design-20042011-timeline-screenshots/ , Acceso al 13 de agosto de 2018.

22

Producto Mínimo Viable

el puente cayó

¡Hasta que el puente se cayó! Si usted hubiese proyectado y construido de forma tradicional, ya considerando todos los vehículos de la región, tal vez hubiese construido un puente de concreto y el camión de la imagen no estaría en esa situación. Que escenario más complejo. Ese argumento encubre los beneficios de trabajar con MVP. Sin embargo, note que el MVP tiene una V. V de viable. El producto mínimo viable para algo. Un puente de madera que no soporta cinco toneladas no puede recibir ningún vehículo con un peso mayor a cinco toneladas. Colocar una placa “Peso máximo 5 toneladas” no es suficiente. Una balanza antes del puente puede identificar un camión mayor a cinco toneladas. Tal vez una balanza y una barrera que se cierre al identificar un vehículo con un peso mayor al permitido. Dos funcionalidades que, de haber agregarse al MVP, evitarían ese error. Pero el puente igual se va a caer en caso de que pasen dos camiones de tres toneladas pasaran al mismo tiempo. ¿Usted percibe la dificultad técnica? Y no solo la dificultad técnica, sino también de usabilidad y la que envuelve al negocio. No voy a discutir aquí la solución para este desafío: aliado si los vehículos pesados también requieren y consiguen usar el puente sin que se caigan. Este ejemplo es una metáfora para ayudarlo con la reflexión sobre su producto, de su MVP. Son parte del MVP las funcionalidades que no van a dejar que se

23

Producto Mínimo Viable

caiga el puente. Si se cae, no era un MVP. Era menos que eso, puesto que no era viable, y sus usuarios no deberían haber sido expuestos a ello. Usted requiere validar su MVP, ¡sin dejar que se caiga el puente!

Legado y bloques organizados A veces, el nuevo producto es una nueva versión de algún legado, algo ya existente, pero que requiere mejoras. O 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 MVP, aunque incompleto desde el punto de vista del producto final, debe respetar los bloques y capas que representan la estructura del producto.

MVP y bloques organizados

Conforme se ilustra en la figura anterior, el MVP no debe ser elaborado bloque a bloque hasta componer todo el producto. Elabore el MVP conforme se presenta en la imagen del lado derecho de la

Producto Mínimo Viable

24

figura. Respete la arquitectura, pero construya el MVP de punta a punta, 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ían la estructura del producto conforme 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 su proceso de venta, desde la adquisición hasta la referencia. AARRR (o métricas pirata) es un acrónimo de métricas del embudo creado por Dave McClure¹⁴ para comprender y atender mejor a los consumidores de su producto o servicio. Las cinco métricas - Adquisición, Activación, Retención, Retorno (ingreso) y Recomendación, que forman el acrónimo AARRR — representan las interacciones de su cliente con su producto. Según Dave, una startup exitosa es capaz de optimizar cada una de esas cinco métricas. Él recomienda que usted coloque y analice esas métricas de forma separada. • Adquisición: Número de personas que visitaron su 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 ¹⁴Métricas pirata – AARRR, por Dave McClure, artículo en wikipedia.org , Disponible en http://pt.wikipedia.org/wiki/AARRR , Acceso al 13 de agosto de 2018.

25

Producto Mínimo Viable

• Recomendación: Número de personas que recomendaron su producto o servicio a otros usuarios

métricas pirata - AARRR

Un MVP debe validar todas las etapas del embudo de ventas. La imagen de la derecha demuestra esa intención, en que el MVP prueba todo el embudo de ventas. Cuidado de no insistir en un negocio que no genera conversión, un falso positivo.

Falto Positivo es algo que presenta un buen inicio, pero que nunca se convierte en un buen negocio con mucho retorno y mucha recomendación.

Ese escenario está ilustrado en la imagen en la izquierda, en que un MVP contempla solamente una etapa del embudo de ventas.

Producto Mínimo Viable

26

¡Haga una Incepción Lean! “Para cada problema complejo, hay una respuesta clara, simple y errada.” — H. L. Mencken Pero no es nada fácil elaborar un MVP. Tener una visión amplia del producto y del negocio; validar una hipótesis; los incrementos; que sea factible, usable, valioso y WUAU; bloques que encajen adecuadamente; embudo de ventas; etc. Este libro comparte años de experiencia ayudando grupos de personas a alinear el MVP, de forma colaborativa y con sus diferentes perspectivas. Y eso sucede en una Incepción Lean.

Preparando el workshop El taller de Incepción Lean En una única semana de trabajo colaborativo, el equipo va a entender los objetivos del producto, los principales usuarios, y el alcance funcional a alto nivel de forma tal que la duración del proyecto pueda ser estimada y una estrategia de lanzamiento incremental de MVPs pueda ser identificada.

Colaboración durante una Incepción Lean

Durante una Incepción Lean, se ejecutan actividades y dinámicas para definir objetivos, estrategias y el alcance del producto, así como para mapear y priorizar las características deseables para que sean entregadas gradualmente, construyendo los MVPs. El objetivo

28 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.

Directo al Punto, la técnica Directo al Punto es una técnica para entender y planificar una entrega incremental de MVPs. La técnica organiza ideas y funcionalidades en un modelo que busca entender la finalidad principal del producto, considerando las jornadas de los usuarios para realizar las entregas 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 • Priorize 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 las jornadas más importantes de los usuarios • Cree un plan de entrega incremental del producto, impulsado por el concepto de MVP • Estime el esfuerzo por muestreo • Calcule los costos y especifique fechas en el cronograma de entrega • Construya los MVP Canvas

29

Colaboración Colaboración es un acto de trabajar juntos para hacer una tarea y alcanzar objetivos comunes. El éxito de una Incepción está directamente relacionado con la capacidad del grupo a colaborar efectivamente en cada actividad descrita en este libro. Una Incepción propone un proceso colaborativo de descubrimiento y esclarecimiento en el que las personas involucradas trabajan juntas en una secuencia de actividades para comprender opciones y elaborar MVPs. 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értase con los Rompe-hielos Nunca subestime 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 usted estará mucho más abierto a trabajar con otras personas. Cuando usted está feliz y relajado, usted está mucho más abierto para intentar cosas nuevas y así aumentar su participación en este taller que es altamente interactivo: la Incepción Lean. Las personas altamente involucradas, participativas y que se están divirtiendo, son más efectivas en las actividades colaborativas. Teniendo eso en mente, usted necesita romper el hielo o elevar el estado de ánimo de los participantes. Los rompe-hielos ayudan a crear un ambiente amigable y a poner a las personas más cómodas para participar de las actividades de la Incepción Lean. Los rompe-hielos son actividades rápidas y divertidas que pueden ser ejecutadas para precalentar al equipo y promover la interacción

30 del grupo. Son excelentes actividades para comenzar cualquier tipo de reunión del equipo. Son todavía más valiosas para los estados iniciales de la construcción de equipo cuando las personas se conocen poco, lo que típicamente ocurre en la mayoría de Incepciones Lean. Usted debe seleccionar una actividad rompe-hielo 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. Después del almuerzo, usted debe seleccionar rompehielos para despertar a las personas. Y, finalmente, usted debe utilizar los rompe-hielos 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 rompe-hielo ayudan a transmitir mensajes importantes. A continuación, un ejemplo de rompe-hielo que es bueno para compartir nombres. En el Anexo A - Rompe-hielos, puede 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. Paso a paso de la actividad 1. Solicite a los participantes pensar en un adjetivo que inicie con la misma letra de su nombre. 2. Forme un circulo y pida a cada participante decir su nombre con el adjetivo, en turnos (”Hola, yo soy Paulo Puntual!”). 3. Luego de que todos los participantes hablan, pídales ir en sentido horario diciendo el nombre y adjetivo para la persona a su lado.

31 4. Luego de unos pocos turnos, pida a los participantes repetir el paso 3 ahora en sentido anti horario. Además de compartir algunas risas y romper el hielo, esta actividad también ayudará al equipo a asociar los nombres de las personas con un adjetivo, haciendo más fácil recordarlos.

Colocación No subestime 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 incepción facilita el arduo trabajo en las actividades, garantizando que todos estarán presentes y participando activamente. Cuando todos están en la misma sala, el nivel de participación aumenta. Usted no puede simplemente sentarse 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 MVP es extensa. La colaboración y los resultados obtenidos son positivamente sorprendentes cuando todos están físicamente en un mismo ambiente. Haga todo lo posible para tener a todos los involucrados en un mismo ambiente, interactuando cara a cara durante la Incepción.

32

La sala de guerra Mantenga una misma sala reservada para el equipo durante el intenso período de la Incepción. Ésta es comúnmente llamada Sala de Guerra o en inglés war room.

ejemplo de una sala de guerra durante una incepción

La sala debe permitir que todo el equipo esté cómodo. Debe tener una mesa y paredes con espacio limpio. La sala también debe tener pizarra, papelógrafos, post-its de colores, papel y bolígrafos para todos.

una sala de guerra preparada para una Incepción

Una sala de guerra provee un ambiente para las actividades co-

33 laborativas. 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.

todo listo para comenzar

Es importante mantener la información en una misma sala. 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 Haga las anotaciones en post-its o tarjetas coloridas. Escriba y colóquelos en una mesa o en una pared. Reúna a las personas a su alrededor. Hable sobre las anotaciones. Escriba un poco más. Agrúpelas. Sepárelas. Rómpalas y escríbalas de nuevo. Haga uso de colores. Reorganícelas. La colaboración generada a partir de algo tan simple no puede ser igualada 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, en el que el camino está siendo construido, sin miedo a intentar, equivocarse o rehacer. 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 rescrito.

34

La agenda Burn-up Una agenda burn-up (más detalles en los anexos) ayuda con la gestión del tiempo y el alcance del taller de Incepción. Tener una agenda visible para todos construye confianza en la gestión del tiempo y en el progreso de las actividades como un todo. Es una herramienta simple y eficaz para planear y facilitar el taller, y para llegar directo al punto.

ejemplo de una agenda burn-up

En el eje vertical está la cantidad de tópicos o actividades que serán realizadas (de abajo hacia arriba) durante todo el taller. En el eje horizontal se representa el tiempo, normalmente medido en horas o días.

35

Espacios de tiempo fijo y la agenda burn-up La agenda burn-up provee un buen marco para secuencias sesiones y actividades de intercambio de ideas mientras se hace un seguimiento del progreso general y del tiempo. Sin embargo, considere que algunas personas, especialmente las que no van a estar dedicadas al taller de Incepción, necesitan tener un entendimiento de la semana. Por este motivo comparto una plantilla de agenda para este taller (disponible en http://caroli.org/diretoaoponto).

ejemplo de agenda planeada

El modelo de agenda de planificación representa dos tipos de sesiones (en colores naranja y azul), que corresponden a los niveles de participación: interesados o miembros activos. • Interesado es cualquier persona impactada por el proyecto. Son personas altamente interesadas en la dirección y resultado de la Incepción, a pesar de que no tienen tiempo para participar en todas las sesiones. Los interesados pueden ser: patrocinadores, usuarios finales, personal jurídico, ventas y marketing. • Miembro activo es cualquier persona directamente involucrada en la comprensión e implementación del producto. Estas son las personas que deben participar activamente en

36 todas las sesiones del taller. Puede incluir: Product Owners, desarrolladores, testers, jefes de proyecto y experiencia de usuario. Note que en la agenda de planificación tanto las actividades de inicio como en la presentación del resultado del taller están marcadas de color naranjo, respectivamente, al principio y al final de la semana. En el mundo ideal, todos estarán presentes en la sala de guerra durante la semana. Sin embargo, raramente tenemos disponibilidad de agenda de los interesados. El mínimo necesario es que los interesados participen de las sesiones de inicio y en la presentación final, donde son respectivamente, presentadas las expectativas del negocio para la semana, así como el resultado obtenido por el equipo dedicado en el taller. Los demás días son ocupados por una secuencia de actividades intensas, seguidas por periodos de consolidación. Las actividades a ser seguidas, deben estar listadas en la agenda burn-up.

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 cubre una buena estructura para llevar a cabo una Incepción. Mientras que esta sección descubre algunas reflexiones acerca del rol del facilitador de la Incepción. El rol del facilitador durante el taller de incepción 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 más bien constituye un guía

37 para propiciar el flujo de ideas y conversaciones activas entre todos los involucrados en el taller. Consecuentemente, el trabajo del facilitador se enfoca mucho 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 vocal cuando explica el proceso de Incepción, 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 desiciones. Por el contrario, el enfoque que el facilitador toma durante las discusiones se centra en ayudar al grupo a seguir las actividades, identificar sus necesidades, solventar sus problemas asociados y tomar decisiones al respecto. • Para lograr lo anterior, el facilitador brinda 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 Incepción, utiliza diversas técnicas para dar fluidez a las conversaciones y cerrarlas alcanzando los resultados esperados (por ejemplo, una lluvias de ideas ¹⁵ y técnicas pomodoro ¹⁶). • Finalmente, el facilitador domina el uso de todo lo necesario en el taller: post-its, papelográfos, marcadores, y además, tiene especial habilidad organizando espacios, moviendo sillas, y acomodando espacio en las paredes. ¹⁵Brainstorming, a group creativity technique, Wikipedia, https://en.wikipedia.org/wiki/Brainstorming ¹⁶The Pomodoro Technique is a time management method, by Francesco Cirillo, Wikipedia, https://en.wikipedia.org/wiki/Pomodoro_Technique

38 En otras palabras, el objetivo del facilitador es brindar soporte 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.

Estacionamiento El estacionamiento ayuda a archivar momentáneamente cualquier tema, idea o pregunta que sea levantada durante una actividad en una Incepción, para no discutirlas en ese momento específico. Es una herramienta esencial para el facilitador, pues proporciona una manera educada de decir “Si, 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 pedí a un colega escribir 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.

39

El Estacionamiento

El facilitador debe introducir el concepto de Estacionamiento al inicio de la Incepción Lean, o tan pronto un primer tema comience a desviar la atención o a desviar al equipo del objetivo. Escriba Estacionamiento en un papelógrafo y colóquelo 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íbalo en un post-it y colóquelo en el Estacionamiento. Asegúrese de explicar brevemente el concepto de Estacionamiento y retorne a la actividad que estaba ejecutando. Es importante ser muy asertivo con los participantes de la Incepción Lean sobre el Estacionamiento: 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 al Estacionamiento.

Es igualmente importante oír y respetar las opiniones, ideas y

40 pensamientos de los participantes, por lo tanto, el Estacionamiento debe ser utilizado conforme lo ofrecido, 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 la incepción, usted debe usar 10 minutos para 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 Incepción. En esa última validación es muy importante aclarar todos los temas remanentes y compartir con todos lo que va a suceder con ellos.

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

Ejecutando la Incepci�n Lean

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.

entendiendo el rompecabezas del negocio

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 sus clientes. Esta actividad lo ayudará a definir colaborativamente la visión del producto.

Escribiendo la Visión del Producto

43

Escribiendo la Visión del Producto

Para [cliente final], quién [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].  Plantilla ”La visión del Producto”, descrita en el libro Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customer, por Geoffrey A. Moore (1999).

Paso a paso de la actividad 1. Escriba la plantilla de la visión del producto en una pizarra o

Escribiendo la Visión del Producto

44

un papelógrafo de una manera visible para todo el equipo. 2. Divida el equipo en grupos pequeños y pida 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úna los resultados de cada equipo formando una sola frase.

visión del producto – ejemplo

En esta actividad es muy común que el resultado sea una frase sin sentido. Es decir, 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 no es ese algo. 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.

Escribiendo la Visión del Producto

45

El producto Es - No es - Hace - No hace

Paso a paso de la actividad: 1. Divida un papelógrafo en blanco en cuatro áreas (Es / No es / Hace / No hace). 2. Escriba el nombre del producto sobre los cuadrantes. 3. Pida a cada participante que describa el producto, en post-its y los coloque en el área correspondiente. 4. Lea y agrupe las notas similares.

Escribiendo la Visión del Producto

46

El producto es… El producto no es… El producto hace… El producto no hace…

un ejemplo del resultado

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. Aprendí esta actividad de Rafael Sabbagh, cuando la utilizó para definir uno de los roles del Scrum ¹⁷ durante uno de sus entrenamientos. Adapté esta actividad para ayudar a definir el producto, y ha conseguido excelentes resultados. ¹⁷Sabbagh, Rafael (2013) Scrum: Gestão ágil para projetos de sucesso; Casa do Código; http://www.casadocodigo.com.br/products/livro-scrum

Escribiendo la Visión del Producto

47

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 levantar y aclarar estos objetivos. Paso a paso de la actividad: 1. Pida 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. Pida a los participantes compartir lo que escribieron en un papelógrafo, agrupando los objetivos similares. 3. Pida 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. A continuación, una secuencia de fotos de ejemplo de los pasos 2 y 3. En la primera foto, los objetivos son agrupados por similitud. En la segunda, los objetivos son escritos de nuevo (en post-its rosados). Note que algunos de los objetivos fueron descartados (en la esquina superior derecha).

Escribiendo la Visión del Producto

48

objetivos del proyecto

objetivos re-escritos

Entendiendo los trade-offs Trade-off 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

Escribiendo la Visión del Producto

49

entre desempeño y seguridad? ¿o usabilidad y desempeño? Esta actividad promueve a una conversación abierta y colaborativa sobre los trade-offs. Los acuerdos claros evitan malos entendidos y ayudan a tomar decisiones rápidamente.

ejemplo del resultado – acuerdos de un producto lean

Paso a paso de la actividad: 1. Describa todas las categorías que son relevantes para el producto en post-its (por ejemplo: seguridad, usabilidad, escalabilidad). 2. Ponga las categorías en un papelógrafo en blanco como título de las líneas. A continuación, dibuje una línea horizontal para cada categoría. 3. Dibuje líneas verticales (el mismo número de línea horizontales). Escriba “más” (importante) sobre la línea que se encuentra más a la izquierda y “menos” sobre la línea que está más a la derecha. 4. Pida a los participantes marcar sus iniciales en varios post-its y poner un post-it en cada línea. La restricción: cada columna

Escribiendo la Visión del Producto

50

debe tener un post-it con sus iniciales (por ejemplo: sólo una de las categorías debe ser marcada como la más importante). 5. Iguale los acuerdos. Con un post-it de diferente color (post-it de color verde en la foto), haga 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.

otro ejemplo del resultado – Acuerdo del Producto lean

Describiendo 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 personas ¹⁸.

Personas

Una persona representa un usuario del sistema, describiendo no solo su papel, sino también sus necesidades específicas, creando una ¹⁸Personas Pragmáticas, por Jeff Patton, artículo http://www.stickyminds.com/article/pragmatic-personas

en

StickyMinds,

2010.

Describiendo las Personas

52

representación realista de los usuarios, que ayuda al equipo a describir funcionalidades desde el punto de vista de quién 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. Paso a paso de la actividad: 1. Solicite al equipo que se divida en pares o tríos y entrégueles la siguiente plantilla de personas a cada grupo. 2. Solicite 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. Solicite al equipo que cambie los grupos y repita los pasos 1 al 3.

plantilla para identificar personas (en hoja de papel A4)

Describiendo las Personas

53

Al final de la actividad, un conjunto de personas debe haber sido creado y los diferentes tipos de usuarios del sistema deben estar descritos. Los interesados que conocen los objetivos del proyecto deben participar activamente de la actividad, auxiliando al equipo en la creación de las personas y sugiriendo cambios en sus descripciones, según sea necesario.

ejemplo de personas - resultado de la actividad

Describiendo las Personas

54

otro ejemplo de personas - resultado de la actividad

La plantilla presentada fue creada por por Natalia Arsand, excelente User eXperience designer y colega de trabajo en ThoughtWorks Brasil.

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 XPLANE ¹⁹ para comprender 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 ¹⁹XPLANE, una empresa de visual thinking, fundada en 1993 por Dave Gray. http://xplane.com/

55

Describiendo las Personas

como una herramienta para descubrir ideas sobre los clientes ²⁰. El mapa representa cuatro áreas principales, las cuáles forman la frase: ¿lo que yo ____ (veo / pienso / oigo / hablo)? Además de estas cuatro áreas principales, la versión original cuenta con dos zonas, el dolor (“pain”, en Inglés) y ganancias (“gain”, en Inglés), para esa persona.

mapa de empatía - plantilla

Siempre que apliqué el Mapa de Empatía para identificación de personas, utilicé sus cuatro áreas principales, veo, oigo, pienso y hablo. Pero a veces, utilizo las áreas de dolores y ganancias, como está descrito originalmente; sin embargo, algunas veces altero estas otras áreas, como por ejemplo: lo que yo hago, o lo que yo no hago, mis amigos y mis enemigos, mis hobbies. Paso a paso de la actividad: 1. Elija una persona para ser analizada. 2. Diseñe una plantilla del mapa, con la persona representada en el centro de la plantilla. 3. Describa las áreas para esa persona. ²⁰Osterwalder, A., Pigneur, Y., Business Model Generation, A Handbook for Visionaries, Game Changers, and Challengers (Amsterdam: OSF, 2009)

56

Describiendo las Personas

4. Repita los pasos 2 y 3 para las siguientes personas. Abajo encontrará algunos ejemplos de Mapas de Empatía.

mapa de empatía – ejemplo 1

57

Describiendo las Personas

mapa de empatía – ejemplo 2

Descubriendo las Funcionalidades Funcionalidad es una descripción de una acción o interacción de un usuario con el producto. Por ejemplo: imprimir una documento de cobro, consultar un extracto detallado, compartir con los amigos de Facebook.

Funcionalidades

La descripción de una funcionalidad debe ser lo más simple posible. El usuario está intentando hacer una cosa. El producto debe tener una funcionalidad para eso. ¿Cuál funcionalidad es esa?. Dado que ya tenemos las personas y los principales objetivos del producto, la siguiente pregunta ayuda con el descubrimiento de las funcionalidades: ”¿Qué necesita tener el producto para que la persona alcance aquel objetivo?” La siguiente actividad es utilizada para descubrir las funcionalidades. Note que esta actividad depende de la lista de objetivos y personas, que ya deben ser artefactos elaborados en actividades anteriores:

Descubriendo las Funcionalidades

59

Paso a paso de la actividad: 1. Solicite que el equipo coloque los objetivos sobre una mesa o en una pared, en orden de prioridades, de izquierda a derecha, como títulos de columnas. 2. Solicite que el equipo coloque las personas en el mismo espacio, en orden de prioridades, de arriba hacia abajo, como títulos de las filas. 3. Promueva una lluvia de ideas de funcionalidades. La discusión debe ser guiada para que se descubran qué funcionalidades son necesarias para atender los objetivos y las personas. Una pregunta que ayuda en este proceso es:

¿Qué necesita tener el producto para cumplir las necesidades de la persona? ¿Qué funcionalidades debemos construir para poder alcanzar aquel objetivo?

El equipo debe guiarse a través del artefacto creado, repitiendo la pregunta de arriba para cada combinación de persona y objetivo, comenzando con los de más alta prioridad. De ese modo, las candidatas a funcionalidades con mayor prioridad surgirán primero. 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ían ser levantadas por el equipo. Esto será contraproducente y puede llevar al equipo a gastar mucho tiempo hablando sobre funcionalidades que no serán parte de los primeros MVPs. Para evitar este escenario, es altamente recomendable que el número de objetivos y personas sea limitado (como los tres o cuatro principales objetivos y personas).

Descubriendo las Funcionalidades

60

si tuviéramos un presupuesto muy corto y pudiésemos trabajar en apenas un objetivo, ¿cuál sería ese?

La pregunta de arriba ayuda al grupo a priorizar objetivos y personas. Repita la pregunta para los objetivos y para las personas. Esto ayudará a priorizar enfocado en la evolución del producto a través de los MVPs.

Ejemplo de resultado: funcionalidades, objetivos y personas, en azul, naranja y verde, respectivamente

Ejemplo de resultado: funcionalidad, objetivos y personas, en azul, rosado y hoja blanca respectivamente

Descubriendo las Funcionalidades

61

Ejemplo de resultado: funcionalidad, objetivos y personas, respectivamente en amarillo-claro, amarillo-oscuro y hoja blanca, respectivamente

Aunque la imagen es similar a una matriz, no necesariamente habrá una funcionalidad para cada intersección. Puede haber múltiples funcionalidades para que una persona pueda alcanzar un objetivo específico, así como es posible que hayan personas que no necesiten una funcionalidad para determinado objetivo. En el caso de que se identifiquen objetivos y funcionalidades que no cubran las necesidades de ninguna persona, estos deben ser descartados o repensados, pues su valor no está claramente asociado a un usuario.

Entendimiento Técnico, de Negocio y de Experiencia de Usuario La actividad anterior logró listar muchas funcionalidades, pero necesitamos utilizar 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 e incertidumbre. Para el esfuerzo, valor de negocio y experiencia de usuario, anotamos las funcionalidades utilizando marcas en una escala de uno, dos o tres.

ranking de esfuerzo, valor y experiencia de usuario

Evaluar la incertidumbre es un poco más complejo. Calificamos una funcionalidad por su certeza técnica (cuán bien el equipo de desarrollo entiende cómo construir la funcionalidad) y el entendimiento de negocio (cuán bien el equipo de negocio entiende qué es lo que va en esa funcionalidad). Luego, usamos ambas calificaciones y las combinamos en una tabla para ver el nivel de incertidumbre: rojo (alto), amarillo (medio) y verde (bajo). Si la funcionalidad cae en la parte de abajo y a la izquierda de la tabla (marcado con una “X”), entonces la funcionalidad no es propicia para el MVP.

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

63

evaluando incertidumbre

Todas las funcionalidades son anotadas con el resultado de su análisis. En el caso de este ejemplo, la funcionalidad “estimar precio” posee un esfuerzo medio, alto valor de negocio e incertidumbre media.

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

64

funcionalidad de ejemplo

Cada funcionalidad debe pasar por la misma revisión técnica y de negocio. Para ello, cada funcionalidad debe ser evaluada y pasar por el gráfico presentado en una actividad (Entendimiento técnico y de negocio), e inmediatamente después, debe ser evaluada y pasar por el gráfico mostrado en la otra actividad (Esfuerzo, Experiencia de Usuario y Valor de Negocio). Es decir, las actividades de Entendimiento Técnico o Entendimiento de Negocio así como la de Esfuerzo, Experiencia de Usuario y Valor de Negocio deben ser realizadas en conjunto.

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

gráficos de ambas actividades

65

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

66

gráficos lado a lado

En la primera actividad, se asigna un color a la funcionalidad, en la segunda se añaden marcaciones de valor y esfuerzo. El color representa el nivel de incertidumbre de la funcionalidad: rojo para un nivel alto, amarillo para un nivel medio y verde para un nivel bajo. En cuanto a las marcaciones de valor de negocio y esfuerzo, varían en una escala de uno, dos o tres veces (comparativamente), por ejemplo, E, EE, y EEE. El color y la marcación va a ayudar al equipo en las actividades subsecuentes para priorizar, estimar y planificar. A continuación, dos ejemplos de funcionalidades antes de que pasen por las actividades de Entendimiento Técnico y Entendimiento de Negocio y Esfuerzo y Valor de Negocio.

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

Ejemplo 1: Funcionalidades antes de las actividades

Ejemplo 1: Funcionalidades después de las actividades

Ejemplo 2: Funcionalidades antes de las actividades

67

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

68

Ejemplo 2: Funcionalidades después de las actividades

El proceso de hacer pasar cada funcionalidad por estos dos gráficos genera mucho más que sólo colores y marcas en cada tarjeta. Suceden conversaciones técnicas importantes acerca de una funcionalidad, tales como: arquitectura, requerimientos multifuncionales y complejidad. Se definen supuestos. Se describen incertidumbres. Como es usual en este tipo de actividades, la conversación y el entendimiento que genera para los involucrados es mucho más que el resultado final de la actividad. Muchas de aquellas conversaciones contienen información extra acerca de la funcionalidad que pueden ser necesarias posteriormente. Pueden ser importantes y no queremos perderlas, por lo que anotamos todo lo referente a la funcionalidad en post-its, y los pegamos detrás de la tarjeta que contiene aquella funcionalidad.

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

69

ejemplo de notas detrás de una tarjeta de funcionalidad

Certidumbre Técnica y Conocimiento de Negocio Esta actividad tiene el objetivo de discutir cómo se siente el equipo en relación al entendimiento técnico y al entendimiento 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. Paso a paso de la actividad:

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

70

plantilla para la actividad

1. Cree un gráfico donde el eje de las X represente el entendimiento técnico (cómo hacer) y el eje de las Y represente el entendimiento sobre los requisitos de negocio (qué hacer). 2. Solicite a un miembro del equipo que lea una funcionalidad en voz alta y coloque en el gráfico de acuerdo con su entendimiento sobre esta funcionalidad (técnico y de negocio). 3. Pregunte 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. Anote en la funcionalidad, el nivel de entendimiento. Por ejemplo, la figura abajo muestra funcionalidades en post-its, con su respectivo nivel de entendimiento, verde, amarillo o

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

71

rojo, indicando respectivamente un nivel alto, medio o bajo de entendimiento. 5. Para cada funcionalidad identificada anteriormente, repita los pasos 2 al 4. En el eje X, el objetivo es verificar el entendimiento del equipo con relación a los desafíos técnicos, a las dependencias y a los requisitos de infraestructura. En el eje Y, la propuesta es verificar la claridad sobre el objetivo de cada funcionalidad, el beneficio para el negocio y lo que debe ser hecho. Al final de esta actividad, todas las funcionalidades estarán categorizadas de acuerdo a su certidumbre técnica y de negocio. Cada funcionalidad es colocada en una tarjeta - verde, amarillas o roja, representando los niveles de entendimiento alto, medio o bajo, respectivamente.

ejemplo 1

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

72

ejemplo 2

ejemplo 3

Al final de la actividad, las funcionalidades marcadas con un tarjeta roja con una X representan riegos altísimos para el proyecto. Normalmente, el equipo decide dividirlas en piezas más pequeñas de trabajo y con menor riesgo.

Esfuerzo, Experiencia de Usuario 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

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

73

valor de negocio y la experiencia de usuario asociada a cada funcionalidad. A partir de esta actividad, nuevas marcas son agregadas a cada funcionalidad. Paso a paso de la actividad:

plantilla para la actividad

1. Cree 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 amarlo los usuarios) y el valor de negocio (cuál es el retorno o ahorro que va a significar). 2. Pida a un miembro del equipo que lea una funcionalidad en voz alta y que la coloque en el gráfico de acuerdo a su entendimiento sobre ella (esfuerzo, experiencia de usuario y valor de negocio). 3. Pregunte 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. 4. Anote en la funcionalidad el nivel de esfuerzo, experiencia de usuario y valor de negocio. Por ejemplo, la figura de abajo muestra las funcionalidades en tarjetas, a las cuáles se les añadieron marcas de $, $$ o $$$, respectivamente, para valor de negocio alto, muy alto y altísimo. Así como E, EE o EEE, respectivamente para nivel de esfuerzo bajo, medio o alto; y uno, dos o tres corazones para indicar un nivel de amor bajo, medio o alto del usuario.

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

74

5. Para cada funcionalidad identificada anteriormente, repita los pasos 2 al 4.

ejemplo 1

En la conversación de esfuerzo técnico, el objetivo es verificar la comprensión del equipo según la dificultad y el trabajo que será necesario para completar dicha funcionalidad. En la conversación de valor de negocio, la propuesta es verificar el valor, el Retorno de la Inversión (ROI) de la funcionalidad, una medida del negocio sobre cuánto vale dicha funcionalidad. En la conversación de experiencia de usuario, la idea es verificar cuánto esperan los usuarios o cuánto les encantará una funcionalidad. A continuación se detallan algunas funcionalidades (el texto está borroso para efectos de confidencialidad) categorizadas de acuerdo con el nivel de esfuerzo, valor de usuario y de negocio. Tenga en cuenta que el color de la tarjeta representa los niveles de comprensión, de acuerdo con la actividad Entendimiento Técnico x Entendimiento de Negocio.

Entendimiento Técnico, de Negocio y de Experiencia de Usuario

75

ejemplo 2

Al final de la actividad, las funcionalidades estarán marcadas con el entendimiento relacionado al esfuerzo y el valor para los usuarios y el negocio. Aquellas marcas ayudaran al equipo en actividades tales como: priorización, estimación y planificación. Escala de valor de negocio Las marcas $ , $$ y $$$, respectivamente, indican el valor de negocio, alto, valor de negocio muy alto y valor de negocio altísimo. Cuando comencé a usar esta gráfica de valor de negocio, estas marcas fueron usadas para indicar valor de negocio bajo, medio o alto. Pero 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.

Presentando las Jornadas de Usuario La Jornada de Usuario 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 la jornada, el equipo levanta preguntas y opiniones alternativas acerca de los deseos del usuario y de las capacidades del producto.

Jornada de Usuario

Paso a paso de la actividad: 1. Selecciones una persona.

Presentando las Jornadas de Usuario

77

2. Identifique el objetivo de esa persona. 3. Escriba la persona y su objetivo en un post-it y colóquelo en la parte superior izquierda de un papelógrafo (para que pueda moverse posteriormente). 4. Decida el punto de inicio (preguntas de ayuda: ¿cómo comienza la persona su día?, ¿qué gatillo su deseo para alcanzar su objetivo?), escriba el punto de partida en un post-it y sitúelo en el papelógrafo. 5. Describa cada paso posterior en un post-it y sitúelo a continuación en el papelógrafo. Continúe agregando pasos hasta que la persona alcanza su objetivo. Cuestionamientos, acuerdos y desacuerdos, conducirán la conversación a la construcción de la jornada. Tal vez resulte más de una opción de jornada. Por ejemplo, la jornada optimista, la realista, la pesimista, la 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 en algunas jornadas. Las jornadas priorizadas complementarán y ayudarán en la búsqueda del MVP. El nivel de detalle de una jornada no debe ser muy alto, ni muy bajo. Al mismo tiempo que una jornada 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 y sin los detalles más profundos. En la imagen abajo se pueden observar varias jornadas de usuario en una misma mesa. Note que las personas están identificadas con el post-it azul en el lado izquierdo y sus jornadas están de izquierda a derecha. En estas jornadas, los post-its naranja identifican acciones que no involucran al sistema, mientras que los post-its rosados identifican acciones que involucran al sistema. Pequeñas flechas fueron marcadas conectando el siguiente paso.

Presentando las Jornadas de Usuario

78

varias jornadas

La descripción de un jornada está basada en una persona. Identifique un escenario para esa persona y describa el paso a paso para lograr un objetivo. Preguntas simples ayudan con el inicio de la descripción de las jornadas. Algunos ejemplos: D: ¿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 usted necesita para describir las jornadas de usuario. Sugiero escribir y reescribir. Pero comience, no se detenga esperando una visión que no ven. Después de tener algo descrito, puede cambiarlo. Si hace sentido, combine algunos pasos muy detallados en uno solo o divida un paso poco detallado en pasos más pequeños. No hay una fórmula mágica para esto. Lo importante es que las jornadas sean descritas. Aquí hay un ejemplo de una Jornada de Usuario (a partir del [Anexo A - Ejemplo de una Incepción Lean] (#ejemplo-incepcion)):

Presentando las Jornadas de Usuario

Gordito bueno con la pelota: invita amigos a un partido Se despierta temprano para ir al trabajo. exagera en el desayuno. llega al trabajo a las 9 am. durante una reunión decide realizar alguna actividad física. en el almuerzo convence a un amigo del trabajo para jugar al fútbol al final del día. llama y reserva un bloque. abre la aplicación móvil Easy-Ball. registra el partido a las 8:00 pm de ese mismo día. coloca la información de la cancha. envía la invitación a los amigos.

ejemplo de jornada de usuario 1

79

Presentando las Jornadas de Usuario

80

ejemplo de jornada de usuario 2

La siguiente foto muestra varias jornadas de usuario en una misma mesa, con mucha gente mirándolas. Las personas y los objetivos (post-its rosados) están a la izquierda del papelógrafo, y sus jornadas van de izquierda a derecha (cada paso está en un post-it amarillo).

Presentando las Jornadas de Usuario

otro ejemplo de equipo verificando jornadas

otro equipo mirando varias jornadas de usuario

81

Exponiendo Funcionalidades en las Jornadas Las jornadas aclaran como será la interacción con el producto. Si usted siguió el orden descrito en este libro, las jornadas deben estar descritas (como una secuencia de pasos) y las funcionalidades deben estar disponibles (en tarjetas de colores). Esta actividad describe como juntarlas, revaluando y verificando todo el análisis hasta este momento. Paso a paso de la actividad:

jornada y funcionalidades, lado a lado

1. Coloque las jornadas principales y las funcionalidades visibles, si es posible, lado a lado, conforme se muestra en la foto a continuación. 2. Siguiendo la jornada, busque las funcionalidades necesarias para cada paso. La secuencia de abajo muestra un ejemplo de como las funcionalidades son mapeadas en la jornada.

Exponiendo Funcionalidades en las Jornadas

mapeando funcionalidades para una jornada - momento 1

mapeando funcionalidades para una jornada – momento 2

mapeando funcionalidades para una jornada - momento 3

83

Exponiendo Funcionalidades en las Jornadas

84

Abajo, otro ejemplo en el que las funcionalidades son adicionadas a las jornadas de los usuarios. En esta secuencia, la primera foto muestra varias jornadas de usuarios en una misma mesa. Note que en esta foto las personas están identificadas con post-it (azul) en el lado izquierdo y sus jornadas siguen de izquierda a derecha. En estas jornadas, los post-its naranja identifican acciones que no involucran al producto, mientras que los post-its rosados identifican acciones que involucran al producto.

Foto 1 de 2: las jornadas

En un segundo instante, los participantes colocan en las jornadas las funcionalidades previamente identificadas. Note en la foto de abajo que las jornadas ahora cuentan con las funcionalidades en tarjetas de colores y con marcaciones, identificando el esfuerzo y valor (vea el capítulo Descubriendo las Funcionalidades).

Exponiendo Funcionalidades en las Jornadas

85

Foto 2 de 2: las jornadas con funcionalidades

La siguiente imagen presenta otro ejemplo de mateo de funcionalidades en una jornada. En el momento de la escena de la foto, una persona está leyendo la jornada de usuario, mientras que las otras tres están mirando las funcionalidades utilizadas en aquella jornada. Se agregaron a la jornada pequeños post-it con identificadores de las funcionalidades (p.ej. 29, 30, 31, 32).

Exponiendo Funcionalidades en las Jornadas

86

otro ejemplo

Al final de esta actividad, dos cosas debieran de ocurrir: (1) pueden haber sido identificadas algunas funcionalidades faltantes, y (2) algunas funcionalidades no fueron mapeadas en ninguna jornada. Para (1) usted debe crear la tarjeta de la funcionalidad con los colores y las marcas identificando incertidumbre, esfuerzo y valor de negocio. (2) Aquellas funcionalidades deben ser aclaradas (y documentadas), pero el equipo no debe seguir con ellas, manteniendo el foco en los ítems prioritarios por jornada.

Secuenciando las Funcionalidades “¿Esta funcionalidad es importante?”

Siempre he tenido la misma respuesta cuando pregunto esto. Por lo tanto, no lo hago más. 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 forma las funcionalidades son priorizadas en relación a otras. Esta pregunta es muy útil y debe ser utilizada, pero necesita de un punto de partida. Previamente, usted identificó a la persona más importante, así como también la jornada de usuario más prioritaria. Éste si es el mejor punto de partida: la primera funcionalidad de esta jornada. Tal vez más de una funcionalidad esté en la jornada o en las jornadas que pueden crearse de forma simultánea. Entonces, en un escenario tal, sí debe preguntarse 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 adicionados a las funcionalidades. Como por ejemplo: valor de negocio ($, $$ o $$$), esfuerzo (E, EE o EEE) y la identificación

Secuenciando las Funcionalidades

88

del nivel de incertidumbre (tarjeta de color verde, amarillo y rojo, identificando, respectivamente, nivel de incertidumbre bajo, medio o alto). Estos parámetros le 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 subsecuentes.

El Secuenciador de Funcionalidades El propósito del 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 usted tiene un mapa de las funcionalidades ya integradas en las jornadas de usuario, usted está en posición de trabajar su primer MVP y su siguientes iteraciones. Aquello se lograr a través de la definición del Secuenciador de Funcionalidades. Paso a paso de la actividad: 1. Cree la plantilla del Secuenciador de Funcionalidades (generalmente un papelógrafo con líneas numeradas; el alto de la línea debe ser tal que quepa una tarjeta de funcionalidad, el ancho de la línea tal que quepan tres tarjetas de funcionalidades). 2. Explique las reglas del secuenciador de funcionalidades. 3. Recuerde a todos acerca del 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.

Secuenciando las Funcionalidades

89

5. El resultado muestra las funcionalidades para cada integración del MVP.

Nuestro objetivo con un MVP es aprender de cada iteración a través de la construcción de un MVP que nos permitirá probar si nuestro caso de negocio es efectivo.

ejemplo de secuenciador de funcionalidades resultante

Secuenciando las Funcionalidades

90

otro ejemplo de secuenciador de funcionalidades resultante

Las Ondas del Secuenciador de Funcionalidades Usted debe planificar una secuencia de ondas para agrupar las funcionalidades de manera que lo ayude a organizar el orden de producción, algo fácil de entender. Una onda después de otra, en secuencia. Dibuje en un papelógrafo o en una pizarra blanca una plantilla con las ondas: el Secuenciador de Funcionalidades.

Secuenciando las Funcionalidades

91

plantilla de secuenciador de funcionalidades

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 3 funcionalidades. • Regla 2: Una onda no puede contener más de una funcionalidad roja. • Regla 3: Una onda debe tener al menos una funcionalidad verde (baja incertidumbre). • Regla 4: La suma del esfuerzo de las funcionalidades no puede sobrepasar 5 Es. • Regla 5: La suma del valor de las funcionalidades no puede ser menor a 4 $s. • Regla 6: Una onda tiene que contener un mínimo de 2 funcionalidades.

Secuenciando las Funcionalidades

92

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. Las reglas 5 y 6 garantizan el enfoque constante en la entrega de alto valor para el negocio.

Convergiendo reglas y jornadas Las reglas simples son agregadas a la plantilla del Secuenciador de Funcionalidades. Ahora, basta buscar la primera funcionalidad de la primera jornada. Luego usted debe buscar la próxima. Respetando las reglas, usted decide si tal funcionalidad entra en la onda ’n’ o en la ‘n+1’. Si tiene dudas entre dos funcionalidades que respetan las reglas, basta responder a la pregunta: “¿Cuál de estas dos funcionalidades es más prioritaria?”. Abajo, una secuencia con dos fotos. La primera muestra una mano en busca de una funcionalidad en la mesa donde están mapeadas las jornadas y las funcionalidades. La segunda foto, la misma mano coloca una funcionalidad en el Secuenciador de Funcionalidades, respetando las reglas.

Secuenciando las Funcionalidades

buscando funcionalidades

colocando funcionalidades en el Secuenciador de Funcionalidades

93

Secuenciando las Funcionalidades

94

¿Duplicar o utilizar el mismo post-it/tarjeta? Una funcionalidad con sus marcaciones está ubicada en una plantilla (por ejemplo, en una jornada). Usted debe estar atento a buscar la tarjeta y colocarla en otra plantilla: 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 la jornada y en el Secuenciador de Funcionalidades. En este momento, usted se pregunta: ¿Duplico o utilizo la misma tarjeta?. Mi sugerencia: Tome una foto antes de hacer cualquier cosa. Considere 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).

Abajo una foto típica de un equipo utilizando el Secuenciador de Funcionalidades. Note el compromiso del equipo y cómo este se posiciona frente al secuenciador de funcionalidades. En este momento todos están bien alineados en relación a las principales jornadas y sus funcionalidades (con sus marcas de incertidumbre, valor de negocio y esfuerzo).

Secuenciando las Funcionalidades

95

equipo utilizando el Secuenciador de Funcionalidades

otro equipo usando el Secuenciador de Funcionalidades

Identificando MVPs en el Secuenciador de Funcionalidades Ha llegado el momento de entender los incrementos y la creación evolutiva de su producto. Las actividades hasta ahora aclararán y priorizarán cada aspecto del producto.

Secuenciando las Funcionalidades

96

Los pequeños bloques del producto, las funcionalidades, ahora están ordenadas lógicamente en el Secuenciador de Funcionalidades. Además de eso, usted los entiende y los visualiza para las jornadas de usuario. Navegando en la plantilla del Secuenciador de Funcionalidades con sus ondas y funcionalidades, usted va a identificar los incrementos del MVP. Cada vez que la combinación de funcionalidades alcanza una versión simple del producto que puede ser disponibilizado, nombre esa combinación. Por ejemplo: “MVP 1”, “MVP 2”, “MVP 3”. Abajo se presentan dos ejemplos de los resultados después de este paso de identificación de MVPs (en post-its naranja) en el Secuenciador de Funcionalidades.

un ejemplo de MVP en el Secuenciador de Funcionalidades

Secuenciando las Funcionalidades

97

otro ejemplo de MVP en el Secuenciador de Funcionalidades

Las ondas no tendrán necesariamente una relación de uno a uno con los MVPs. Note que este fue un caso de ejemplo de MVP en el Secuenciador de Funcionalidades presentado anteriormente. La intención es ejercitar la planificación y la secuencialidad de las funcionalidades en ondas para entregar valor lo más rápido posible, mientras se respetan las dependencias entre las funcionalidades y las reglas del Secuenciador de Funcionalidades. A continuación, un ejemplo ilustrativo de un Secuenciador de Funcionalidades. En ella tenemos dos MVPs y trece funcionalidades. El MVP 1 está compuesto por las features F1, F2, F3, F4, F5 y F6. El MVP 2 está compuesto por las funcionalidades F7, F8, F9, F10,F11, F12 y F13.

Secuenciando las Funcionalidades

Secuenciador de Funcionalidades ilustrativo

98

Calculando esfuerzo, tiempo y costo La mayoría de las empresas que conozco siempre están muy interesadas en responder dos preguntas simples y precisas: ¿Qué están 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 un artefacto impresionante que se genera en la Incepción Lean. Muchos interesados estarán realmente satisfechos en el momento que se les responde tan importante pregunta. Pero, ¿cuándo estará listo? Algunas personas le preguntarán aquello. ¿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 su caso, usted tiene mucha suerte y puede obviar este capítulo; en caso contrario, en este capítulo, voy a compartir con usted cómo he ayudado a muchos equipo 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 MVPs 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. Luego, se detallarán las funcionalidades, se efectúa la suma de los números y se calcula el promedio para cada onda.

Calculando esfuerzo, tiempo y costo

100

Detallaando las funcionalidades de muestra en tareas El tamaño de las ondas es similar. Luego, escoja dos o tres ondas y utilícelas 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. Paso a paso de la actividad: 1. Escoja dos o tres ondas a ser detalladas. 2. Seleccione una funcionalidad de una de las ondas de muestra. 3. Describa, en otras tarjetas, las tareas más pequeñas para la funcionalidad seleccionada. 4. Vuelva al paso 2 y seleccione otra funcionalidad hasta que haya detallado todas las funcionalidades de las ondas de muestra.

Calculando esfuerzo, tiempo y costo

101

ondas para el muestreo

Al seleccionar las ondas de muestra (paso 1), recuerde que en este momento usted está interesado en la estimación de la totalidad y el tamaño promedio de una onda, y no en el detalle del trabajo en si. 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 características). 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 ²¹ [Ken] utilizan a menudo historias de usuario [ CohnStories] [^HelmHistorias] como aquellas piezas más pequeñas. Otros equipos ²¹Sabbagh, Rafael (2013) Scrum: Gestão ágil para projetos de sucesso; Casa do Código; http://www.casadocodigo.com.br/products/livro-scrum

Calculando esfuerzo, tiempo y costo

102

prefieren llamar a las piezas más pequeñas de tareas y describirlas sin un formato predefinido. En el resto de este capítulo, voy a llamar de tareas a las piezas más pequeñas de una funcionalidad. Generalmente recomiendo a los equipos a ser muy específicos al crear estas tarjetas de tareas, ya que esto ayudará a la actividad actual a no preocuparse por la documentarlas de manera perfecta, lo cual será hecho posteriormente y no durante la Incepción Lean. Durante el paso 3, haga una marca tanto en la tarjeta de la funcionalidad, como en sus tareas. Por ejemplo, marque con F1 a todas las tareas de la funcionalidad 1, F2 para las tareas de la funcionalidad 2, y así sucesivamente. Esto es hecho para evitar confusiones y la mezcla de funcionalidades requeridas con sus tareas.

muestra de funcionalidad con sus tareas

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

Calculando esfuerzo, tiempo y costo

103

Estimación comparativa La siguiente actividad es muy simple, pero es esencial para entender el esfuerzo relativo de las tareas. Paso a paso de la actividad: 1. Escriba las siguientes tallas de camisetas en post-its: pequeño, mediano y grande. 2. Coloque 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. Seleccione dos tareas y luego haga la siguiente pregunta: ¿Cómo se compara el trabajo para hacer esta tarea (en esfuerzo) con esta otra? ¿pequeña?, ¿mediana?, ¿grande? 4. Coloque ambas tareas en el papelógrafo, con sus posiciones relativas que indica cómo se comparan a nivel de esfuerzo (pequeño, medio o grande). Coloque una al lado de la otra, si ambas requieren el mismo nivel de esfuerzo; o coloque una debajo de la otra, lo que indica que una requiere más esfuerzo que la otra. 5. Defina los límites entre tallas y reposiciones las tareas para dejar claras sus tallas. En caso de ser necesario, considere crear una talla de camiseta extra (por ejemplo extra pequeña o extra grande). 6. Mientras aún haya tareas a ser comparadas, colóquelas en la pizarra de acuerdo al nivel de esfuerzo y repita los pasos 3 y 4.

Calculando esfuerzo, tiempo y costo

104

funcionalidad de muestra con sus tareas con tamaños

Al final de esta actividad, todos las tareas estarán asociadas a una talla de camiseta: Pequeño, Medio 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.

Calculando esfuerzo, tiempo y costo

105

detallando las funcionalidades de muestra en tareas y estimación comparativa

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 azules con marcas S, M y L, respectivamente para Pequeño, Medio, Grande).

resultado de la muestra

Las dos imágenes previas son bastante similares. La diferencia es la talla XS (extra-small) que fue agregada debido a conversaciones sostenidas durante la actividad de estimación comparativa.

Calculando esfuerzo, tiempo y costo

106

Entendiendo el Costo y el tiempo Esta actividad es esencial para generar números para calcular costos y tiempo para cada onda, así como para todo el Secuenciador de Funcionalidades. Luego, usted podrá responder la pregunta: ¿Cuándo estará listo?. Paso a paso de la actividad: 1. Seleccione una tarea pequeña, y pregunte cuánto tiempo le toma a una persona para completarla. 2. Seleccione dos o tres tareas más del mismo tamaño y repita la pregunta. 3. Calcule el tiempo promedio y anótelo. 4. Repita los pasos anteriores para tareas de diferentes tamaños.

ejemplo del resultado

Al costado izquierdo de la imagen pueden observarse las tallas de camiseta (post-it amarillos) con el tiempo promedio (post-it azules) debajo de ellas. Los promedios son: 3 días para tamaño Grande, 1 y 1/2 día para talla Mediana, y 1/2 días para Pequeña. Al final de esta actividad, todas las tareas tendrán una estimación de tiempo y costo. Por ejemplo, se obtuvieron los siguientes resultados

Calculando esfuerzo, tiempo y costo

107

en un ejercicio de 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 de tiempo influirán en el resultado final. Así que sea muy enfático en relación a la pregunta. Si es posible, pida comparar con trabajos anteriores, y tratar de entender la motivación y la capacidad de las personas que responden a esta pregunta. A los desarrolladores no les gusta responder a esta pregunta: ¿Cuánto tiempo le toma a una persona completar una tarea?

Por eso 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 tarea, deberán reescribirla y considerar dividirla en pedazos más pequeños. Otra forma de hacer tal pregunta es ponerla en plural: Considere un par de desarrolladores. Uno conoce más acerca del negocio, y el otro conoce menos. Uno es más sénior, el otro es un poco más júnior. Uno tiene más experiencia en la tecnología, el otro es principiante. ¿Cuánto tiempo les toma al par de desarrolladores 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 esfuerzo, tiempo y costo

108

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 linea de la plantilla del MVP. Por lo tanto, llegamos a un esfuerzo promedio para cada onda, definido por persona y por unidad de tiempo. Las siguientes fotos muestran 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.

ondas y funcionalidades para la muestra

Note en la foto anterior que las ondas 2, 3 y 4 han sido seleccionadas como muestra. Luego, las funcionalidades detalladas en tareas fueron: F4, F5 (onda 2), F5, F6, F7 (onda 3), y F9, F10 y F11 (onda 4).

Calculando esfuerzo, tiempo y costo

109

promediando

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 tareas fue: 1/4 de día (Pequeño), 1/2 día (Medio), 2 días (Grande) o 5 días (Extra Grande). Realizando la sumatoria de las tareas por características y luego por onda, el equipo alcanzó valores de 11 días, 11 días y medio 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 10.5 días por pareja de desarrolladores por onda. A continuación se muestra otro ejemplo para otro equipo.

Calculando esfuerzo, tiempo y costo

110

ejemplo de resultado

La imagen muestra otro resultado de la Incepción Lean para dos ondas de muestra: 9 semanas y 14 semanas. Después de verificar este resultado, el principal interesado dijo: “Entonces, cada onda toma aproximadamente 12 semanas de un desarrollador. Si tenemos seis desarrolladores en este equipo, pareciera que podemos entregar una onda cada dos semanas (12 semanas de desarrollo por 6 desarrolladores), o una onda por Sprint, de acuerdo a su terminología de Scrum.” Luego continuó: “Dado que nuestro MVP está completo en la onda 5… creo que tendré que ajustar un poco la planificación”. A continuación se muestra un ejemplo más de otro equipo.

Calculando esfuerzo, tiempo y costo

111

otro ejemplo de resultado

En esta foto, el promedio resultante fue 20 unidades. Tenga en cuenta el cálculo en el post-it rosado a la derecha, con tres ondas de muestra. En este equipo, la unidad utilizada fue de un par de desarrolladores por día. Con esta información, es fácil calcular el esfuerzo, el tiempo y el costo de cada onda. Podemos elegir trabajar con un par de desarrolladores, y entregar una onda de funcionalidades en un mes (o 20 días hábiles). Otra opción sería la de duplicar el costo mensual y dos parejas de desarrolladores entregan aproximadamente dos ondas por mes.

Construyendo el MVP Canvas Por fin, alcanzamos la cima de la Incepción Lean: el MVP Canvas. En él, vamos a detallar el MVP y sus funcionalidades respecto a las perspectivas de Design Thinking y Lean Startup. El MVP Canvas fue concebido como una actividad de la Incepción Lean, y es la última actividad de Directo al Punto. Sin embargo, se puede usar de forma separada independientemente de la secuencia de Directo al Punto. Pero enfatizo que es muy importante alinear a los participantes sobre la visión del producto, los objetivos, las personas, las funcionalidades, las jornadas y la secuencia de funcionalidades que comprende cada MVP. Eso ayuda a completar el MVP Canvas. Una hora. Ese es el tiempo aproximado para llenar el MVP Canvas si ha seguido las actividades de la Incepción Lean de Directo al Punto como se describió en los capítulos anteriores. Una hora trabajando en el MVP Canvas le 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 el Directo al Punto necesitará más tiempo y mucha más conversación para crear un MVP Canvas.

Completando el MVP Canvas Teniendo en cuenta que el equipo ya ha discutido qué es lo que compone el MVP y ya ha hablado sobre lo que esperan de él, ahora es el momento de poner todo en papel. Mejor aún, defina

113

Construyendo el MVP Canvas

el pensamiento esencial acerca del MVP en una sola hoja de papel: el MVP Canvas.

MVP Canvas

** Paso a paso de la actividad: ** 1. Imprima el MVP Canvas [^CanvasMVP] o dibújelo en papelógrafo. 2. Elija el MVP que va a ser elaborado. 3. Complete cada una de las siete secciones del MVP Canvas. El MVP Canvas está dividido en siete secciones. Las preguntas a responder en cada una de ellas: 1. Segmentos de Personas - ¿Para quién es este MVP? ¿En qué plataforma estará disponible? 2. Visión del MVP - ¿Cuál es la visión de este MVP? 3. Resultado esperado - ¿Qué aprendizaje o resultado buscamos en este MVP? 4. Jornadas de Usuario - ¿Qué jornadas se mejorarán con este MVP?

Construyendo el MVP Canvas

114

5. Funcionalidades - ¿Qué estamos construyendo en este MVP? ¿Qué acciones se van a simplificar o mejorar 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 Programación - ¿Cuál es el costo esperado y la fecha de vencimiento de este MVP? ¿Hay alguna restricción de programa?

El secuenciador de funcionalidades y el MVP Canvas El secuenciador de funciones ayuda en la organización y visualización de funcionalidades. El secuenciador 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.

el Secuenciador de Funcionalidades y el MVP Canvas

Además de mostrar las tarjetas de funcionalidades ordenadas, el secuenciador muestra claramente la agrupación de funcionalidades para cada MVP. Esto se representa por post-its en el secuenciador, delimitando el MVP1, el MVP2 y así sucesivamente.

Construyendo el MVP Canvas

115

Ejemplo: MVP1 Canvas y MVP2 Canvas al lado del Secuenciador de Funcionalidades

Si utilizó el secuenciador de funcionalidades y marcó uno, dos o tres MVP, le sugiero que imprima tres MVP Canvas y complete uno para cada MVP identificado en el secuenciador. Sin embargo, si utilizó el secuenciador y hay demasiados MVP, también sugiero que imprima tres plantillas y sólo complete los primeros tres MVP. El hecho es que estamos trabajando con MVP y no queremos ir demasiado lejos. 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 la Incepción Lean primero piensan de una manera más amplia para luego tratar de determinar la secuencia de los entregables mínimos y viables. Y, 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

Construyendo el MVP Canvas

116

ellos. Sin embargo, no te dejes engañar. El aprendizaje del MVP1 y posteriormente del MVP2 traerá algunas nuevas explicaciones. El equipo tendrá que volver a pensar el producto y los próximos MVP con sus funcionalidades. Construir un MVP Canvas y ponerlo en el armario sería un desperdicio. Construya uno, dos, pero no más de tres. La imagen en el ejemplo es real; ese equipo solo construyó dos MVP Canvas para los dos primeros MVP. Siga el ejemplo de ellos. Sólo construya un nuevo MVP Canvas cuando esté cerca de trabajar en aquel MVP, teniendo en cuenta los conocimientos adquiridos hasta el momento.

Segmentos de Personas Los participantes de la Incepción Lean de Directo al Punto ya piensan en el MVP y sus funcionalidades. También realizaron la actividad sobre personas y, probablemente, hicieron consideraciones sobre ellos para decidir sobre el MVP. Pero, a medida que completan la sección de personas y plataformas en el MVP Canvas, estarán demostrando sus decisiones de inmediato. Al llenar el MVP Canvas, la pregunta sobre las personas es diferente de la reflexión sobre las personas en el comienzo de la Incepción. 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

117

Construyendo el MVP Canvas

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 sólo se lanzará a otra plataforma después de verificar el resultado esperado.

Funcionalidades ¿Qué características incluyen este MVP?

La sección de funcionalidades debe responder esta pregunta. El secuenciador de funcionalidades es un excelente punto de partida para responder a la pregunta. Eche otro vistazo a las funcionalidades enumeradas para el MVP: ¿Son realmente el mínimo? ¿Van a hacer que el producto sea viable? ¿Podríamos crear algo aún más simple? ¿Nos hemos perdido algo esencial para este MVP?

Jornadas ¿Qué jornadas se cumplirán o mejorarán con este MVP?

La sección de jornada debe responder esta pregunta. Si el grupo pasó por la Incepción Lean de Directo al Punto, las jornadas seguirán siendo visibles y mostrarán las personas, sus objetivos y las funcionalidades asignadas a ellos. Pero incluso si el grupo

Construyendo el MVP Canvas

118

no tiene las jornadas visibles, la pregunta debe hacerse y la información sobre las jornadas mejoradas debe responderse en el MVP Canvas.

Desarrollo Impulsado por Hipótesis Diseño centrado en el usuario. Eso es lo que queremos. Para crear el MVP, debemos considerar a los usuarios y sus jornadas. Deberíamos trabajar en las acciones que mejoran o simplifican sus vidas. Pero eso no es todo. Debemos describir las hipótesis del negocio. Debemos entender si estamos realmente avanzando, si realmente estamos alcanzando los resultados deseados o aprendiendo. Después de definir las funcionalidades del MVP, debemos conectarlo a los resultados esperados y a las hipótesis de negocio. El siguiente modelo ayuda con dicha declaración: Creemos que … visión de MVP logrará … resultado esperado. Sabremos que esto sucedió en base a … métricas para validar las hipótesis de negocio.

Este modelo es una adaptación del modelo de Jeff Gothelf de desarrollo orientado a hipótesis ²². El equipo debe completar este modelo, porque si no lo hacen no sabrán qué esperar del MVP o no sabrán cómo medirlo. En ambos escenarios, el producto está a la deriva, sin dirección. ²²Lean UX: Applying Lean Principles to Improve User Experience, by Jeff Gothelf and Josh Seiden, O’Reilly Media, 2013

Construyendo el MVP Canvas

119

No cree funcionalidades para un producto si no puede describir qué esperar como resultado y cómo medir dicho resultado. 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. Este poderoso modelo para decisiones basadas en hipótesis se incluye en el MVP Canvas, en las secciones: resultado esperado y métricas para validar las hipótesis de negocio.

Visión del MVP, Costo y Programación Además de los ciclos de Lean Startup y Design Thinking, el MVP Canvas debe mostrar claramente la dirección del negocio. Para esto, debe responder a estas dos preguntas sobre el negocio: ¿Cuál es la visión de este MVP? ¿Cuál es el costo y el programa de este MVP?

La sección Visión del MVP y la sección Costo y Programación deben responder estas preguntas. El capítulo anterior muestra un cálculo por muestra para ayudar a comprender el esfuerzo, el tiempo y el costo asociados a la creación de las funcionalidades del MVP. Además del costo de crear, ¿qué otros costos están asociados al MVP? Por ejemplo: ¿Tenemos una campaña de marketing para este trabajo? ¿Algún otro costo? Considere las respuestas a estas preguntas para detallar el presupuesto del MVP. A veces, la pregunta del programa se combina con la del costo. Si este no es su caso, haga caso omiso de esta pregunta. Pero si este es

Construyendo el MVP Canvas

120

el caso, defínalo claramente. Nuevamente, el cálculo por muestra presentado en el capítulo anterior ayuda a comprender el tiempo para crear las funcionalidades del MVP. Además de esos, ¿qué más se necesita para el MVP? ¿Hay alguna responsabilidad externa? ¿Hay una fecha o un período de tiempo para que suceda? Considere las respuestas a estas preguntas al crear el cronograma del MVP.

La estrategia MVP El MVP Canvas 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 visión del MVP, las hipótesis de negocio con sus métricas, las personas y sus jornadas, las funcionalidades y cuánto cuesta 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?

Construyendo el MVP Canvas

121

MVP Canvas 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: usuariojornada-acción, que nos brinda un enfoque de Design Thinking, centrándonos en el aprendizaje de las personas y sus jornadas.

construir bra aprender o aprender para construir

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

Construyendo el MVP Canvas

122

MVP Canvas y el ciclo usuario-jornada-acción

Mientras completamos el MVP Canvas, colocamos dos ciclos uno al lado del otro: el ciclo construir-medir-aprender de Lean Startup, y el ciclo de usuario-jornada-acción de Design Thinking. ![MVP Canvas = aprende a construir + construir para aprender] (images/canvas-mvp-dois-loops.jpg) Los ciclos se superponen en la sección de funcionalidades: ¿Qué funcionalidades se van a construir para este MVP? Tenga 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 el centro del canvas, representando su punto central.

Anexo

Anexo A - Ejemplo de una Incepción Lean “Me gustaría ver un ejemplo completo de una Incepción Lean”. Este fue un pedido recurrente que recibí de lectores de este libro. Imagino que será más fácil leer este libro a quien ha participado en un taller, o en una Incepción Lean al estilo de Directo al Punto. Por más que un libro explique los ingredientes de la receta, y los pasos de cada actividad, entiendo que algunos lectores piden 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 vengo a compartir en este capítulo. Por motivos de confidencialidad de las empresas que me contrataron para facilitar dichas Incepciones Lean, no puedo compartir el resultado de las actividades para sus productos. Muchos de estos productos comenzaron como lean, con sus MVPs incrementales, y hoy en día son productos únicos en sus áreas de actividad. 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 Incepción Lean en una gran conferencia. Y como este taller tuvo más de 20 participantes, la idea del producto fue concebida y compartida con todos los participantes. Como el taller fue de de 8 horas, la agenda semanal típica de una incepción lean fue comprimida con el fin de encajar en unas pocas horas. La agenda burn-up fue esencial para mantener a todos alineados en lo rápido con que tendríamos que seguir el ritmo de la Incepción Lean. 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

Anexo A - Ejemplo de una Incepción Lean

125

cantidad de artefactos generados: personas, jornadas y funcionalidades. El propósito era alcanzar el mínimo necesario para cada actividad con el fin de demostrar la técnica de Directo al Punto, y simular el ambiente colaborativo de una Incepción Lean.

Introducción El día comenzó con un rompe-hielos. 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.

Kick-off En lugar de un kick-off típico, generalmente realizado por interesados hablando sobre un producto o idea a ser concebida durante la Incepción Lean, 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 de producto para el taller.

Visión del producto El producto más votado fue una aplicación para jugadores aficionados. Aquellas personas que les gusta jugar fútbol con sus amigos del trabajo, el gimnasio, o cualquier grupo que esté interesado en un partido de fútbol. También tenían la idea de producto relacionado a entrega de pizzas, o algo similar. Y uno más que no recuerdo. A continuación una foto de un grupo mientras escribía su visión del producto.

Anexo A - Ejemplo de una Incepción Lean

126

![escribiendo la visión del producto] (images/qcon-escrevendo-visao.jpg) Para Aficionados Que tienen dificultad para encontrar partidos de fútbol Easy-Ball Es una aplicación móvil Que facilita el encontrar juegos de fútbol A diferencia 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. Abajo una foto de la misma.

visión del Producto: Easy-Ball

Anexo A - Ejemplo de una Incepción Lean

127

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 MVPs 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 aclarar más sobre la idea del producto, centrándose en el MVP y a 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 geo-localización es muy interesante Esta aplicación no crea equipos, gestiona pagos u organiza campeonatos

A continuación se muestra una imagen del resultado de esta actividad. ![Easy-Ball: Es - No es - Hace - No hace] (images/qcon-easy-bolae-nao-e.jpg) Sigue la transcripción de los textos en la foto de los post-its: El producto es… • • • •

app app móvil multiplataforma facilitador para organizar partidos

Anexo A - Ejemplo de una Incepción Lean

• gratuito • gratuito El producto no es… • • • • •

FB, Twitter, WhatsApp sitio sitio no es un chat Messenger (chat)

El producto Hace… • • • • • • • • •

marca los Juegos (agenda) cuadra agendas lista de partidos encuentra próximos partidos localización geográfica advertencias sobre ocurrencias notifica a los usuarios ranquea usuarios guarda Reputación

El producto No hace… • • • • • • • • •

organiza juegos establece tiempos de orden de pedido organiza juegos y equipos crear equipos gestiona los pagos el pago en línea por el partido organizar juegos privados organiza campeonatos campeonatos

128

Anexo A - Ejemplo de una Incepción Lean

129

Entendiendo los objetivos Después de las actividades Visión del Producto y El producto Es No es - Hace - No hace realizamos una actividad para aclarar el objetivo del producto. En este momento solicitamos a todos los participantes a compartir 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 con el poco tiempo, todos los participantes tomaron parte en los grupos que crearon personas mientras se divertían con sus descripciones, dibujos y apodos. Abajo una foto de un grupo de participantes que describen una persona.

Anexo A - Ejemplo de una Incepción Lean

130

Participantes usando la plantilla para identificar las Personas

Para crear las personas, los 20 participantes se dividieron en tres grupos más pequeños. Cada grupo creó dos o tres personas, y los 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. Sigue la transcripción del texto de la persona más votada: un gordito bueno con la pelota Nombre • Gordito bueno con la pelota Perfil • 28 años • casado • jugador frustrado

Anexo A - Ejemplo de una Incepción Lean

131

• trabaja en un banco • graduado Comportamiento • • • • •

bueno para quejarse competitivo asiduo 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 y en los fines de semana

Descubriendo las funcionalidades Después de haber cubierto el producto, los objetivos y las personas, llegó la hora de pensar y dejar que aparezcan las funcionalidades (características previstas para el producto lean). Para eso utilizamos la actividad Descubriendo las funcionalidades. La foto de abajo muestra la actividad en marcha. ![Descubriendo las funcionalidades] (images/qcon-features.jpg) Des-Cubrir. Las funcionalidades son descubiertas. Han aparecido varias veces en conversaciones anteriores. Ahora es realmente el momento para ellas ser des-cu-bier-tas. Tenga en cuenta que los objetivos están como título de las columnas; mientras que las personas están como título de las filas. Esto forma un gran cuadro para descubrir las funcionalidades. Y con

Anexo A - Ejemplo de una Incepción Lean

132

esto, el facilitador puede promover una lluvia de ideas acerca de aquellas funcionalidades: *”¿Qué necesita tener el producto para que una persona alcance un objetivo?”** Con esta pregunta, la discusión se guía para que sepan qué características son necesarias para alcanzar los objetivos de las Personas. Se anotan en un post-it y se colocan en el cuadro. La pregunta se repite para cada combinación de persona y objetivo, lo que da prioridad a los objetivos principales y personas clave. Sigue la transcripción de las funcionalidades de los post-it: • • • • • • • • • • • • • • • • •

consulta de partidos con geolocalización consulta de partidos sin Geolocalización clasificación canchas rankear un jugador detalles del partido (lugar, fecha y hora) ranking de jugadores (visualizar) detalles financieros del partido registro del partido registro de jugadores invitar amigo para el partido filtro detallado módulo de notificaciones confirmación de asistencia notificación de partido confirmado notificación de partido cancelado cancelar presencia 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 comprender las

Anexo A - Ejemplo de una Incepción Lean

133

mismas en detalle, tomando notas y hablando de incertidumbre, esfuerzo y valor para el negocio. Sin embargo, estas conversaciones e información más detallada es muy útil para una mejor comprensión y planificación para crear productos lean. Las actividades y gráficos de Comprensión Técnica y Comprensión de Negocio y Esfuerzo, Experiencia de Usuario y Valor de Negocio buscan dicha información de forma rápida y eficiente.

Anexo A - Ejemplo de una Incepción Lean

134

gráficos de Entendimiento Técnico, de Negocio y de Experiencia de Usuario

Cada funcionalidad pasa a través del gráfico y de la tabla, y por lo tanto gana marcas de niveles de incertidumbre, esfuerzo, experiencia de usuario y de valor de negocio. En el gráfico la funcionalidad recibe un color. En la tabla, la funcionalidad recibe marcas de experiencia de usuario, valor de negocio y esfuerzo

Anexo A - Ejemplo de una Incepción Lean

135

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 Google lib para la geolocalización, y (2) se asume que sólo funcionarán con los dispositivos móviles más modernos. A continuación una foto con el resultado de esta actividad, ahora con las funcionalidades y sus marcas en el cuadro de objetivos, personas y características.

Resultado del entendimiento técnico y de negocio

En esta foto, la función del color de la tarjeta representa el nivel de incertidumbre: rojo para un alto nivel de incertidumbre, amarillo para un medio y verde para bajo. Mientras que las marcas de experiencia de usuario, valor de negocio varían en una escala de uno, dos o tres veces comparativamente; es decir: • uno, dos o tres corazones para un valor de experiencia de usuario baja, media y alta, respectivamente, • $, $$, $$$, para alto, muy alto y altísimo valor de negocio respectivamente, • y E, EE, y EEE para bajo, medio y alto esfuerzo respectivamente.

136

Anexo A - Ejemplo de una Incepción Lean

Los colores y marcas características ayudaron a los participantes en las actividades posteriores a priorizar, estimación y planificar el MVP. Sigue la transcripción de los post-it de funcionalidades, ahora con sus niveles de incertidumbre, el esfuerzo y el valor del negocio. Funcionalidad Incertidumbre Esfuerzo consulta media de partidos con geolocalización consulta baja de partidos sin geolocalización clasificación baja canchas rankear alta un jugador detalles baja del partido (lugar, fecha y hora)

Exp Valor Usuario Neg

media

alta

altísima

baja

alta

muy alta

baja

media

alta

media

baja

alta

baja

media

muy alta

137

Anexo A - Ejemplo de una Incepción Lean

Funcionalidad Incertidumbre Esfuerzo ranking media de jugadores (visualizar) detalles baja financieros del partido registro baja del partido registro baja de jugadores invitar media amigo para el partido filtro baja detallado módulo alta de notificaciones confirmación baja de asistencia

Exp Valor Usuario Neg

media

baja

alta

baja

alta

muy alta

baja

baja

media

baja

baja

alta

media

alta

muy alta

media

baja

muy alta

alta

alta

alta

baja

altísima

altísima

138

Anexo A - Ejemplo de una Incepción Lean

Funcionalidad Incertidumbre Esfuerzo notificación baja de partido confirmado baja notificación de partido cancelado cancelar baja asistencia cancelar baja partido

Exp Valor Usuario Neg

media

alta

altísima

media

alta

altísima

baja

alta

altísima

media

media

altísima

Describiendo las jornadas En este punto volvemos a la perspectiva de las personas. Ahora se centra en sus jornadas, el paso a paso que lleva a cabo para lograr un objetivo. Los participantes se dividieron en grupos nuevamente. Cada grupo seleccionó una persona, e identificó los principales escenarios para que tal persona alcance sus objetivos principales. El paso a paso de cada escenario fue descrito con los post-it colocados en un papelógrafo. Las siguientes preguntas ayudaron con el comienzo de la descripción de las jornadas: • ¿Cuál es el objetivo que tal persona quiere alcanzar?

Anexo A - Ejemplo de una Incepción Lean

139

• ¿Cómo comienza su día? • ¿Qué hace después de eso para alcanzar su objetivo? A continuación una foto de un grupo que describe una jornada mientras compara funciones de otras aplicaciones móviles. ![Grupo describiendo el paso a paso de una jornada] (images/qconjornada.jpg) Los siguientes son dos ejemplos de jornadas: Gordito bueno con la pelota: invita amigos a un partido se despierta temprano para ir al trabajo exagera en el desayuno llega al trabajo a las 9 am durante una reunión decide realizar alguna actividad física en el almuerzo convence a un amigo del trabajo para jugar al fútbol al final del día llama y reserva una cancha abre la aplicación móvil Easy-Ball registra el partido a las 8:00 pm de ese mismo día coloca la información de la cancha envía la invitación a los amigos Amigo: acepta la invitación al partido se despierta tarde para el trabajo come una barra de cereal en el metro llega al trabajo a las 9:30 am va al gimnasio en la hora del almuerzo durante una reunión, recibe una notificación de Easy-Ball verifica la información del partido comprueba la clasificación de canchas confirma su asistencia al partido deja la reunión y va a otra reunión a las 5:14 pm recibe la confirmación del partido

Anexo A - Ejemplo de una Incepción Lean

140

Amigo: acepta la invitación al partido

Exponiendo funcionalidades en las jornadas Tenga en cuenta que algunos de los pasos que se describen en las jornadas representan diferentes puntos de contacto con el producto, caracterizando una interacción con esta. Este es el momento de revisar todos los análisis hasta ahora, comparando estos puntos de contacto con el producto y con las funcionalidades y su información. La foto de abajo muestra dos cosas: (1) se busca la tarjeta de la funcionalidad, y (2) se ubica junto al paso de una jornada.

Colocando una funcionalidad en el paso de la jornada

Nótese en la foto de las jornadas, ahora con las funcionalidades en tarjetas de color y marcas que identifican esfuerzo y valor.

141

Anexo A - Ejemplo de una Incepción Lean

Las jornadas, ahora con las funcionalidades

Sigue el ejemplo de jornada anterior, ahora con funcionalidades en algunos pasos. ** Amigo del trabajo: acepta la invitación al partido** Paso

Funcionalidad

se despierta tarde para el trabajo come una barra de cereal en el metro llega al trabajo a las 9:30 am va al gimnasio en la hora del almuerzo durante una reunión, recibe una notificación de Easy-Ball verifica la información del partido comprueba la clasificación de canchas

módulo de notificaciones detalle del partido (lugar, hora y fecha) clasificación de canchas

142

Anexo A - Ejemplo de una Incepción Lean

Paso

Funcionalidad

confirma su asistencia al partido deja la reunión y va a otra reunión a las 5:14 pm recibe la confirmación del partido

confirmación de asistencia notificación de partido confirmado

Secuenciando las funcionalidades Ahora es momento de construir el Secuenciador de Funcionalidades. Este es el momento en que se coloca todo el análisis hasta la fecha (producto, personas, funcionalidades y jornadas) en un papelógrafo en base a reglas simples y esenciales para organizar y visualizar las funcionalidades y su relación con los MVP. Como facilitador, describí las reglas del Secuenciador de Funcionalidades, y dejé que los participantes organizaran a voluntad las funcionalidades en el secuenciador. La foto de abajo muestra a todos los participantes involucrados buscando las funcionalidades en las jornadas y colocándolas en el papelógrafo.

Anexo A - Ejemplo de una Incepción Lean

143

Buscando funcionalidades en las jornadas para el Secuenciador de Funcionalidades

Si bien los participantes eligieron y ordenaron a las funcionalidades en el Secuenciador de Funcionalidades, escribí en algunos post-its: MVP1, MVP2, MVP3, y así sucesivamente. Entonces les pregunté a ellos “cuándo una composición de funcionalidades alcanza una versión simple del producto para podría estar disponible”. Al identificar lo anterior, se coloca un post-it al lado derecho del papelógrafo para identificar las funcionalidades de ese MVP. Abajo, la foto con el resultado del Secuenciador de Funcionalidades.

144

Anexo A - Ejemplo de una Incepción Lean

Canvas del MVP de Easy-Ball

A continuación la transcripción del Secuenciador de Funcionalidades de Easy-Ball presentado en la foto, con sus MVPs identificados y sus funcionalidades. Funcionalidad

Onda

MVP

registro del partido registro del jugador consulta de partidos sin geolocalización confirmación de asistencia detalles del partido (lugar, hora y fecha) cancelar asistencia cancelar partido módulo de notificaciones notificación de partido confirmado notificación de partido cancelado detalles financieros del partido invitar a un amigo al partido ranking de jugadores (visualización)

1 1 1

1 1 1

2 2

2 2

2 3 3 4 4 4 5 5

2 3 3 3 3 3 4 4

Anexo A - Ejemplo de una Incepción Lean

145

Construyendo el MVP Canvas Luego de decidir los MVP en el Secuenciador de Funcionalidades, es hora de detallar el primer MVP. Para esto, usamos el MVP Canvas. A continuación se muestra la imagen con el resultado del MVP Canvas para MVP1.

MVP Canvas para el MVP1 de Easy-Ball

A continuación, la transcripción del MVP Canvas para el MVP1 de Easy-Ball presentada en la imagen, con sus notas traducidas para cada uno de los siete bloques del canvas. Visión del MVP MVP1: anuncio de un juego de fútbol en Android Segmentos de Personas • El aficionado • El dueño del equipo incompleto • Sólo Android Jornadas de Usuario • Un aficionado registra un juego • El jugador se registra y busca un juego Funcionalidades

Anexo A - Ejemplo de una Incepción Lean

• Registrar jugador • Registrar partido de fútbol • Consulta de partido de fútbol sin Geolocalización Resultados esperados • 200 usuarios en un mes • 50 partidos en el primer mes • 300 descargas en un mes Métricas para la validación de hipótesis de negocio • Número de usuarios registrados en la base de datos • Número de coincidencias registradas en la base de datos • Número de descargas de aplicaciones en Play Store Costos y Programación • 1 onda • 2 semanas • USD $5,600.00

146

Anexo B - Glosario A continuación una lista breve de términos utilizados en este libro. Cada uno de los conceptos será explorado en detalle en los capítulos. Sin embargo, creo necesario aclarar, a alto nivel, estos términos desde el principio. Esta lista de términos debe estar visible durante el taller de Incepción. Sugiero que imprima este glosario y lo coloque en la pared de la sala de guerra.

Visión del Producto La visión del producto es una breve descripción de adónde quiere llevar su idea de producto.

Objetivos Un objetivo es un resultado deseado previsto para el producto. Comprender los objetivos del producto sirve como una herramienta eficaz para establecer un acuerdo de lo que el producto debe tener para cumplir la visión del producto.

Personas Una persona representa un usuario del sistema, describiendo no solo su rol, sino también sus necesidades específicas. Esto crea una

148

Anexo B - Glosario

representación realista de los usuarios, ayudando al equipo a describir funcionalidades desde el punto de vista de quién interactuará con el producto final.

Funcionalidad Funcionalidad es la descripción de una acción o interacción de un usuario con el producto. Por ejemplo: imprimir un recibo, ver detalles, e invitar a amigos de Facebook.

Certidumbre Técnica de la Funcionalidad El entendimiento de la funcionalidad de acuerdo con los desafíos técnicos y los requisitos de infraestructura. ¿Lo ha hecho antes? ¿sabe cómo hacerlo? un “sí” muy firme indica un elevado nivel de entendimiento técnico.

Entendimiento de Negocio de la Funcionalidad La claridad del objetivo de la Funcionalidad, el beneficio para el negocio y lo que debe ser hecho. ¿Qué hacer? Una respuesta directa y clara indica un alto nivel de concordancia.

Nivel de Incertidumbre de la Funcionalidad El nivel de incertidumbre de la funcionalidad se refiere al grado en que una funcionalidad es incierta, a partir del punto de vista del entendimiento de negocio y del entendimiento técnico. Aquello es indicado por el color de la tarjeta, el color puede ser verde, amarillo o rojo, indicando nivel bajo, medio o alto de incertidumbre, respectivamente.

149

Anexo B - Glosario

Esfuerzo de la Funcionalidad El nivel de trabajo que necesita ser hecho para la funcionalidad. El entendimiento del equipo de acuerdo con la dificultad del trabajo que va a ser necesario para completar la funcionalidad en cuestión.

Valor de Negocio de la Funcionalidad El valor de negocio, o ROI (Return On Investment) asociado a la funcionalidad, es una medida de negocio sobre el valor previsto para tal Funcionalidad. ¿Cuál es el retorno de la inversión o el ahorro que la Funcionalidad va a traer?

Valor de Experiencia de Usuario de la funcionalidad El valor de experiencia de usuario, es el valor esperado de la funcionalidad para los usuarios, una medida por parte de los usuarios sobre cuánto desean esta funcionalidad. ¿Cuál es el valor percibido (en corazones) que una funcionalidad aportará a los usuarios?

Jornada La jornada de usuario describe la trayectoria de un usuario a través de una secuencia de pasos dados para lograr un objetivo. Algunos de estos pasos representan diferentes puntos de contacto con el producto, representando la interacción del usuario con el producto.

150

Anexo B - Glosario

MVP El Mínimo Producto Viable, en inglés Minimum Viable Product (MVP), es la versión más simple de un producto que puede estar disponible para el negocio. El MVP determina cuáles son las funcionalidades esenciales para que se tenga el mínimo producto funcional que pueda agregar valor al negocio (producto mínimo) y que pueda ser efectivamente utilizado y validado por el usuario final (producto viable).

Anexos C - Niveles de Competencia del Facilitador Este libro ofrece una receta, una secuencia de actividades a ser seguidas para alcanzar la comprensión y la planificación para construir el MVP de un producto. Al igual que un libro de recetas de cocina, este depende del dominio del chef. En otras palabras, la ejecución de esta receta está en las manos de nuestro chef o del facilitador de la Incepción. La figura abajo identifica seis niveles de competencia para el facilitador de la Incepción. Esta clasificación sirve para alinear las expectativas y para mostrar la importancia de las capacidades del facilitador de aplicar las técnicas descritas en este libro, así como para identificar el nivel del facilitador asignado para una Incepción.

Anexos C - Niveles de Competencia del Facilitador

152

niveles de competencia del facilitador

1. Facilitador Principiante Personas que están participando del taller de Incepción por primera vez. 2. Facilitador Intermedio Personas que ya han participado pero todavía no han facilitado ninguna actividad durante el taller de Incepción. 3. Facilitador Aprendiz Personas que ya han participado y han facilitado una o más actividades realizadas en el taller de Incepción. 4. Facilitador Personas que ya facilitaron un taller de Incepción y se siente seguros de hacerlo. 5. Facilitador Avanzado Personas que ya facilitaron por lo menos cinco talleres de Incepción y se sienten seguras de ser coach de Facilitadores Aprendices. 6. Facilitador Evangelista Personas que ya facilitaron más de diez talleres de Incepción y actualmente están compartiendo las técnicas para el público interesado en talleres de Incepción.

Anexo D - La agenda Burn-up La agenda burn-up hace un seguimiento del progreso a lo largo de los temas que se tienen planificados para el taller. Se puede usar para cualquier reunión, pero es especialmente útil para los talleres en que se debe controlar el tiempo en base a una lista de temas a cubrir. Las agendas burn-up surgieron en talleres de lluvia de ideas muy intensos, como Incepciones y sesiones de ideación. Aunque en estos talleres se realizan amplias discusiones, normalmente ellos tienen un límite de tiempo y deben cubrir varios tópicos y actividades, para conseguir el resultado deseado.

Anexo D - La agenda Burn-up

154

agenda burn-up a las 8:00 am

Los ejes de la agenda El eje vertical es la cantidad de temas o actividades que serán realizadas, está medido en unidades personalizadas para la agenda específica de la Incepción. El eje horizontal representa el tiempo, normalmente medido en horas o días.

155

Anexo D - La agenda Burn-up

los ejes de la agenda

Los temas de la agenda Los temas y actividades que serán realizadas deben ser agrupados de forma que sus duraciones sean semejantes. Por ejemplo, si su agenda tiene cinco temas y usted espera que los temas 1 y 2 lleven media hora cada una y los temas 3 y 4 llevan una hora cada uno y el tema 5 tomará dos horas, entonces usted debe considerar tener los temas agrupados de la siguiente forma: • • • • •

Tema 1 & 2 Tema 3 Tema 4 Team 5.1 Tema 5.2

Anexo D - La agenda Burn-up

156

Note que de esta forma, cada grupo tiene una expectativa de duración semejante. Tenga en cuenta que, a pesar del tiempo real (sea 10 minutos, media hora o dos horas), lo más importante es que una agrupación de temas tenga expectativas similares sobre la cantidad de tiempo necesario. Otro aspecto importante es que los temas sigan un orden cronológico: primero vamos a cubrir esto, después vamos a cubrir aquello y así en adelante. La secuencia de los temas y actividades debe estar claramente definida.

Los intervalos de tiempo Los intervalos de tiempo en el eje horizontal deben ser simétricos, comenzando en el inicio del taller y terminando en el final esperado del taller. En los ejemplos de las figuras anteriores, el intervalo era de media hora. La unidad de los intervalos de tiempo (minutos, horas o días) debe estar relacionada con la duración esperada de los temas. Considere que usted está construyendo una agenda para un taller de cinco días con diez temas. Usar intervalos de tiempo en base en horas sería muy pequeño; en ese caso, intervalos de un día o medio día serían más apropiados.

El objetivo y el ritmo La ventaja de la agenda burn-up es el claro entendimiento del objetivo, el punto en el que la línea del alcance se une con la línea de tiempo. El objetivo es mostrado

157

Anexo D - La agenda Burn-up

el ritmo planeado

Al diseñar una línea diagonal a partir del punto de partida (el punto donde los ejes se encuentran) para el resultado esperado, usted tiene una indicación clara del ritmo del taller. En la figura, este ritmo está representado como la línea diagonal rosa (planeado).

La línea del alcance Una información importante de la agenda burn-up es la línea del alcance, la línea horizontal encima del último tópico planeado. Esta línea define claramente cuando nuevos temas fueron añadidos o removidos durante la Incepción. También permite visualizar la intersección de esta línea horizontal con la línea vertical, que representa el fin del taller. Todo lo que se va a discutir debe ser un tema. Si nuevos temas

Anexo D - La agenda Burn-up

158

surgen, estos deben ser añadidos a la lista de temas y la línea del alcance debe ser ajustada. De esta forma, la nueva línea permite identificar fácilmente cuando los temas están siendo añadidos, lo que afectará el tiempo de finalización de la Incepción. Si bien estos temas pueden ser importantes de discutir, el acto de añadir un nuevo tema es una señal importante de que el tiempo restante de la Incepción debe ser repensado. La línea del alcance también permite identificar dónde se han removido temas para cumplir con un plazo fijo. Nuevamente, es importante entender como quitar un tema de la agenda va a afectar los otros temas y es algo que necesita y debe ser claramente discutido con todos.

Verificando el progresso De tanto en tanto, usted debe verificar la cantidad de temas abordados y la cantidad total de temas planificados. La distancia entre las líneas horizontales marcando el tema actualmente en discusión y el último a ser discutido indica de cantidad de temas restantes.

159

Anexo D - La agenda Burn-up

dos líneas

Cuando las dos líneas se encuentran, la agenda planeada estará completa. La distancia entre esas líneas es una medida poderosa de qué tan cerca está usted de completar la agenda planificada. Verificar regularmente el progreso es una parte importante de la gestión del tiempo. Hay dos movimientos básicos sobre la agenda, ambos son movimientos horizontales: (1) el tiempo cambió; el postit con una gran flecha que representa la hora actual debe ser movido hacia la derecha a la posición que representa la hora actual, y (2) una discusión sobre un tema de la agenda ha terminado; su post-it se debe mover a la derecha de la hora actual. Este mecanismo de movimiento permite identificar de inmediato un desvío en la duración esperada para los temas de la agenda. Una vez verificado este problema, debe ser discutido y las acciones correctivas deben ser tomadas incluso en un estado inicial y no cuando sea demasiado tarde.

Anexo D - La agenda Burn-up

160

Escogiendo Considere la agenda burn-up que se muestra en la siguiente imagen. Son las 10:00 horas, estamos en la mitad del taller y apenas cuatro de diez temas han sido discutidos. El burn-up deja eso muy claro.

el ritmo planeado versus el actual

Diseñe una línea a partir del punto de partida hasta el último tema abordado y enseguida, extiéndala hasta alcanzar la línea de fin de la Incepción. Esta línea representa el ritmo real. A partir de ella, la planificación de la agenda es cuestionada. ¿Qué hacer ahora?, ¿aceptar el ritmo actual y reducir el alcance (remover temas de la incepción)?, ¿añadir más tiempo a la incepción?, ¿acelerar el ritmo para los próximos temas?.

Anexo E - Actividades Rompe-hielo Los rompe-hielos son actividades que sirven para promover la interacción del grupo. Son un buen comienzo para cualquier reunión de equipo y son muy valiosas para las fases iniciales de formación de equipos e Incepciones Lean. Una actividad llamada Paulo Puntual, fue descrita en el capítulo Incepción Lean. Este anexo trae otras nueve actividades, completando una decena de actividades para romper el hielo que puede utilizar en su Incepción Lean. Estas actividades fueron extraídas del libro Fun Restrospectives ²³.

Paulo Puntual Esta es una actividad rápida para ayudar a los miembros del equipo a recordar los nombres de los demás. Cómo funciona 1. Pídales a los participantes que piensen en un adjetivo que comienza con la misma letra que su nombre. 2. Forme un círculo y pida a cada participante que diga su nombre con el adjetivo, por turnos (”¡Hola, soy Paulo Puntual!”). 3. Después de que todos los participantes hablen, pídales que vayan en el sentido de las agujas del reloj diciendo el nombre y el adjetivo de la persona que está a su lado. ²³CAROLI, Paulo e CAETANO, Tainã; Fun Retrospectives, Activities and ideas for making agile retrospectives more engaging, LeanPub, www.FunRetrospectives.com, 2014

Anexo E - Actividades Rompe-hielo

162

4. Después de algunos turnos, pida a los participantes que repitan el paso 3 en sentido antihorario.

Actividad Paulo Puntual

Además de compartir algunas risas y romper el hielo, esta actividad también ayudará al equipo a asociar los nombres de las personas

Anexo E - Actividades Rompe-hielo

163

con algún adjetivo, por lo que es más fácil recordarlos.

Localización Geográfica Esta actividad es excelente para quebrar el hielo y también ayuda a los miembros del equipo a conocer un poco más sobre cada uno. Cómo funciona 1. Explique a los participantes que cada uno será una localización geográfica (por ejemplo, su país, ciudad o barrio). 2. Muestre donde está el Norte y el Sur en la sala. 3. Pida a cada participante que vaya al lugar de la sala donde él o ella se localizan para hacer un mapa lo más realista posible. 4. Después de que todos estén en sus lugares, pida a un voluntario que diseñe un mapa representando la sala.

Actividad Localización Geográfica

Anexo E - Actividades Rompe-hielo

164

Teléfono Visual Teléfono visual es un excelente energizante para dejar a todos enganchados y promover una discusión sobre comunicación y sus interpretaciones. Cómo funciona 1. Divida el grupo en sub-grupos de tres personas (uno o dos grupos pueden tener cuatro personas). 2. Coloque tres post-its y un bolígrafo en frente de cada persona. 3. Pida a cada uno que escriba una frase (en el post-it), y entonces coloque un post-it en blanco encima del primero (en este punto, sólo el autor de la frase la conoce). 4. Todo el mundo pasa el post-it para el lado, en el sentido horario. 5. Cada participante lee la frase del post-it que le ha tocado y crea un diseño representando la frase (en un post-it en blanco). 6. Todo el mundo pasa el post-it para el lado en el sentido horario. 7. En un nuevo post-it, cada persona escribe una frase sobre el diseño que le ha tocado y coloca encima del conjunto de post-its (ahora el conjunto tiene tres post-its: uno con la frase original, uno con el diseño y uno con una nueva frase). 8. Todos pasan los post-its para el lado en el sentido horario (para los grupos de tres personas, el conjunto debe parar frente al autor de la primera frase). 9. Abra el conjunto de post-its para que todos puedan ver las frases y sus diseños respectivos.

Anexo E - Actividades Rompe-hielo

165

Actividad Teléfono Visual

Normalmente, los participantes ríen y se divierten comparando los diseños y las frases. Este es un excelente energizante con un mensaje sutil sobre la comunicación (visual y escrita), el contexto y las interpretaciones. Esta es la adaptación de una actividad que aprendimos en un taller de UX (User eXperience), de mis amigos queridos Natalia Arsand, Glauber Ramos, Juliana Dorneles y Gabriel Albo. Ellos aprendieron en el taller de IDEO, Human Centered Design.

Uno Dos Ping Cuatro Pong Esta es una actividad corta para comenzar una reunión con un buen clima y dejar a los participantes enganchados. Cómo funciona 1. Pida a los participantes que formen un círculo. 2. Los participantes deben decidir en que sentido seguir (horario o anti-horario).

Anexo E - Actividades Rompe-hielo

166

3. Alguien comienza diciendo cualquier número positivo que no sea múltiplo de 3 o 5. 4. La siguiente persona, siguiendo la dirección elegida por todos, mentalmente aumenta 1 al número. Entonces: Si el número no es múltiplo de 3 o 5: dice el número Si el número es múltiplo de 3: dice ping y aplaude Si el número es múltiplo de 5: dice pong y salta

Actividad Uno Dos Ping Cuatro Pong

Para grupos grandes es recomendable remover una persona del grupo si se equivoca o acusa a alguien de haber equivocado erróneamente. Luego, todos estarán riendo y apoyando a los que permanecen en el círculo.

Formando Triángulos Esta actividad es un excelente energizante con un mensaje muy valioso, es muy útil para comenzar una conversación acerca de

Anexo E - Actividades Rompe-hielo

167

equipos auto-organizados. Cómo funciona Esta actividad está divida en dos partes. Primera parte 1. Pida a los miembros del grupo que caminen individualmente en direcciones aleatorias. 2. Después de un tiempo, diga la palabra mágica “triángulo”: cada miembro del grupo tendrá que encontrar a otras dos personas y formar un triángulo equilátero (cada uno es un vértice del triángulo y debe apuntar el brazo en dirección a las otras dos personas representando los otros vértices del triángulo; cada persona es un vértice en solo un triángulo). 3. Mida cuanto tiempo le tomó a cada grupo formar los triángulos.

Actividad Formando Triángulos

Segunda parte 1. Seleccione una persona para ser el organizador del grupo. 2. Pida a los miembros del grupo que caminen en una dirección cualquiera.

Anexo E - Actividades Rompe-hielo

168

3. Después de un tiempo, diga la palabra mágica “triángulo”: el organizador del grupo tiene que formar triángulos equiláteros con todos los miembros del grupo (incluyéndose a él mismo en uno de los triángulos). 4. Mida cuanto tiempo le tomó a cada grupo formar los triángulos. La primera parte muestra un grupo auto-organizado; la segunda muestra un grupo guiado por un organizador (u orientador del grupo). Normalmente, la formación del triángulo auto-organizado es más rápida que la otra opción y el equipo se siente más enganchado en la actividad. Esta actividad fue hecho por Heitor Roriz²⁴, un colega y coach de equipos. Felicitaciones a él por aplicar una actividad divertida para promover la discusión sobre un concepto esencial para los equipos ágiles bien logrados: auto-organización.

Zip Zap Zoom Este es un buen inicio para reuniones, especialmente para nuevos equipos. Trae energía a la sala y la dinámica de la actividad ayuda a los participantes a recordar los nombres de los otros. Cómo funciona 1. Pida al equipo que forme un círculo y que cada participante cierre sus manos mientras señala con su dedo índice. 2. Explique los comandos Zip / Zap / Zoom. 3. Pida a un participante que haga el primer movimiento, diciendo los comandos y escogiendo la dirección inicial (horario o anti-horario). ²⁴https://twitter.com/hroriz

Anexo E - Actividades Rompe-hielo

169

Los comandos: Cada participante debe, en su turno, dar un comando verbalmente, apuntando para un receptor. El comando verbal debe ser uno de los siguientes: • Zip: apunte a la persona exactamente a su lado, manteniendo la dirección anterior. • Zap: apunte a la persona exactamente a su lado, cambiando la dirección anterior. • Zoom: apunte a cualquier persona en el círculo, diciendo su nombre. El receptor debe decidir la dirección para el próximo movimiento en su turno. Cuando un participante ejecute un comando incorrectamente (o un comando que no existe, o apunte para una dirección errada en un comando zip/zap), él/ella debe salir del círculo.

Zip Zap Zoom

Anexo E - Actividades Rompe-hielo

170

Esta actividad no es solamente un buen energizante, sino además ayuda a que los participantes se enfoquen y puedan recordar los nombres unos de otros.

Desenredarse Desenredarse es un excelente energizarte para generar movimiento en las personas. Permite pasar un mensaje muy interesante acerca de hallar una solución en una situación complicada. Cómo funciona 1. Pida al grupo que forme un círculo. 2. Pida a todo el mundo que coloque las manos arriba. 3. Dé las instrucciones para enredarse. “Con su mano derecha, busque la mano izquierda de alguien. Con su mano izquierda, busque la mano derecha de alguien. Usted no puede buscar las manos de las personas que están a su lado.” 4. Pida al grupo que se desenrede sin soltarse las manos e intente formar un círculo.

Actividad Desenredarse

El grupo se soltará las manos, se alternará para encontrar una salida, ya sea formando uno o más círculos. Algunas veces, es imposible desenredarse. En este escenario, pida al grupo que remueva

Anexo E - Actividades Rompe-hielo

171

una persona. Las manos que continúen libres deben conectarse con la persona que queda en el grupo enredado. El tamaño del grupo: por lo menos seis personas, hasta cualquier número. Para grupos muy grandes, separe en grupos pequeños, con aproximadamente 12 personas cada uno.

Batalla de Globos La Batalla de Globos es un gran energizante para que todos se muevan mientras se crea una situación para presentar algunos conceptos como estrategia de equipo, trabajo en equipo, colaboración, asociación y situaciones de ganar-ganar. Cómo funciona 1. Instruya a todos para que ate un globo a su pie izquierdo (necesitará globos y cuerdas para todos los participantes). 2. Divida el grupo grande en varios grupos más pequeños. 3. Instruya a todos sobre la misión del equipo y la duración del juego: • “Todos los equipos tienen el mismo objetivo: proteger los globos del equipo. El juego dura 3 minutos. Al final contaremos y anunciaremos el equipo con el mayor número de globos completos”. * 4. Diga ¡AHORA! y cuente 3 minutos.

Anexo E - Actividades Rompe-hielo

172

Actividad Batalla de Globos

Por lo general, los participantes se divertirán mucho. Muchas personas pueden correr y atacar los globos de otras personas. Al final del juego puede tener conversaciones sobre el trabajo en equipo, la estrategia del equipo, la percepción de la responsabilidad y nuestro favorito: la naturaleza humana competitiva, que a veces funciona en contra de una situación de ganar-ganar. Por ejemplo, si nadie se mueve y ataca los globos de otras personas, cada equipo logra el objetivo de proteger los globos del equipo, y cada equipo termina con el mayor número de globos completos. Lo más interesante, es que nunca hemos visto u oído sobre este resultado.

Piezas Complejas Piezas complejas es un excelente energizante para hacer que las personas se integren mientras conversan sobre sistemas complejos y piezas interconectadas. Cómo funciona 1. Todos se colocan de pie y caminando.

Anexo E - Actividades Rompe-hielo

173

2. Cada persona piensa en otras dos personas. 3. Sin decir nombres, cada persona debe quedarse distante de las dos personas en las que pensó. Eso debe tomar un minuto mientras las personas se mueven. 4. Después de que todos paren, pida a la persona más alta del grupo ir a una esquina de la sala. 5. Pida a todos que encuentren sus distancias iguales nuevamente.

Actividad Piezas Complejas

Aprendí esta actividad con Bethlem Migot. Ella la usaba como energizante durante un taller de análisis. La actividad dejó a todos energizados antes de tener una breve conversación sobre sistemas complejos, cambios y requerimientos interconectados. Esta actividad funciona mejor en grupos de diez a treinta personas.

Dibujo Colaborativo de Caras El dibujo colaborativo de caras es una actividad interactiva divertida que ayuda con la memorización del nombre. Cómo funciona 1. Entregue a cada participante un papel de Carta o A4 de EE. UU. Y un bolígrafo.

Anexo E - Actividades Rompe-hielo

174

2. Indique a los participantes que escriban su nombre en la parte inferior del papel. 3. Pídales a todos que caminen aleatoriamente por la sala hasta que pronuncie la palabra “detener”. 4. Cada persona debe emparejarse con alguien cercano. 5. Indique a la pareja que intercambie papeles. 6. Todos deberían atraer la mirada de la otra persona. 7. Indique a las parejas que intercambien papeles nuevamente (ahora cada persona debe tener el papel con su nombre de nuevo). 8. Repita los pasos 3 a 7 para todas las partes de la cara (ojos, nariz, orejas, mentón, cabello, vello facial y accesorios). A continuación hay dos fotos de esta actividad. El primero muestra el paso 3 en el que todos caminan aleatoriamente esperando el comando de detención. La segunda foto muestra el resultado final: un dibujo facial colaborativo.

participantes caminando

175

Anexo E - Actividades Rompe-hielo

resultado

De Espaldas De espaldas es una actividad energética y divertida que transmite un mensaje fuerte y simple sobre el trabajo colaborativo.

Actividad De Espaldas

Cómo funciona 1. Diga a los participantes que encuentre un par con altura y peso parecidos al suyo. 2. Pida a todos que se sienten en el piso, con su par de espaldas uno al otro. 3. Pida a los pares que entrelacen los brazos cuando estén de espaldas. 4. Diga a todos que el objetivo es quedar de pie, manteniendo brazos y espaldas juntos.

Anexo E - Actividades Rompe-hielo

176

Esta actividad es muy divertida y hará que las personas rían. Normalmente, pocos pares conseguirán quedar en pie rápidamente, la mayoría tendrán dificultadas. Considere no hacer esta actividad si percibe que algún participante no es capaz de quedar en pie o no le gustaría sentarse en el piso.

Encuentre Su Par Encuentre su Par es un energizarte muy divertido para mover las personas y hacerlas reír. Cómo funciona 1. Cuente el número de participantes (un número par de participantes es necesario, entonces decida si usted participará o no de acuerdo al número de personas). 2. Divida el número de participantes en dos para decidir cuántos animales existirán (si fueran 20 participantes, entonces existirán 10 animales diferentes). 3. Para cada animal, escriba el nombre en post-its. 4. Distribuya los post-its para los participantes y dígales que no lo muestren a nadie. 5. Pida a todos caminar por la sala. 6. Diga a todos que se cubran los ojos con las manos y hagan el sonido de su animal para intentar descubrir en donde está su par.

Anexo E - Actividades Rompe-hielo

177

post-its preparados para la actividad

Aprendí esta actividad con Bethelm Migot. Confieso que me demoré un poco para usarla y decidí intentar después de verla siendo usada tantas veces y percibir que a las personas les gustaba. Recomiendo tener cuidado con ciertas culturas y tener certeza de los participantes están acostumbrados a los energizantes.

Acerca del autor Principal Consultant en ThoughtWorks Brasil y co-fundador de AgileBrazil, Paulo Caroli tiene más de veinte años de experiencia en desarrollo de software, trabajando en varias empresas en Brasil, India, USA y Latinoamérica. En 2000, descubrió Extreme Programming y desde entonces ha centrado su experiencia en procesos y prácticas Ágil & Lean. Se unió a ThoughtWorks en 2006 y ha ocupado posiciones de Agile Coach, Trainer y Project Manager. Recibió una Licenciatura en Ciencias de la Computación y una Maestría en Ingeniería de Software, ambas de PUC-Río. Paulo es autor de: “Lean Inception: How to Align People and Build the Right Product”; y “Fun Retrospectives: Activities and Ideas for Making Agile Retrospectives More Engaging”.

Paulo Caroli

Sigue a Paulo Caroli en su sitio web y en redes sociales:

Acerca del los tradutores Este libro es traído a ustedes gracias al trabajo de estos excelentes profesionales, especialistas en esta área de conocimiento.

Patricia Trejo Patricia Trejo es actualmente Senior Consultant en ThoughtWorks, empresa a la que pertenece desde 2016. Ingeniero Civil Informático, Magíster en Ciencias de la Ingeniería Informática e Ingeniero Civil Industrial y con más de diez años de la industria de desarrollo de software, Patricia se ha desempeñado como Analista de Negocio y Project Manager en diversos proyectos, contextos e industrias. Actualmente se desempeña como Project Manager y está dedicada a la utilización de prácticas ágiles y lean en el desarrollo de proyectos y productos de software.

Acerca del los tradutores

180

María Fernanda Escudero María Fernanda (Mafer) ha trabajado en la Industria de Desarrollo de Software por casi 20 años, la mayoría como Líder de Proyecto / Project Manager / Program Manager. Ella ha estado usando Fun Retrospectives (Versión en inglés) desde 2013 para desarrollar habilidades y capacidades en sus equipos para proyectos en Sudamérica y Centroamérica. Se unió a ThoughtWorks hace dos años como Gerente de Proyecto y hace un par de meses, fue ascendida a Jefa de Operaciones de ThoughtWorks Ecuador.

Freddy Coronel Freddy se unió a Thoughtworks en 2015, como nuevo Project Manager. Utiliza todas las herramientas que puede con los equipos para hacer su experiencia lo mejor posible. Le gustan los deportes, especialmente el ciclismo de montaña, por lo que siempre lo encontrarás tratando de escalar “montañas” con su bicicleta, él cree que es una especie de analogía en la vida, el trabajo y los proyectos, y disfruta cada momento de ellos.

Sobre la Editora Caroli Para los lectores y autores que buscan y comparten conocimiento de forma ágil, la Editora Caroli es una editora-boutique - todos los libros son escritos, leídos, editados y/o revisados por Paulo Caroli - que auxilia en la producción, divulgación y distribución de libros y e-books. A diferencia de las editoriales tradicionales, la Editora Caroli da acceso al conocimiento en su esencia, ofreciendo el texto de las nuevas obras vía e-books gratuitos, además de apoyar eventos y entidades de enseñanza, regalándolos en forma de libros impresos. En www.caroli.org usted encuentra este y otros contenidos de calidad. Disfrute, pues, los libros y los e-books en WIP están disponibles gratuitamente.

WIP (Writing In Progress) La Editora Caroli presenta una nueva propuesta de trabajo, acercando a los autores con sus lectores desde el inicio de la generación del contenido. ¿Por qué esperar que el autor termine de escribir para ver si el contenido es bueno? En el mundo actual eso ya no tiene sentido. La Editora Caroli promueve el intercambio (gratuito siempre que sea posible) del WIP a través de formatos e-book (pdf, mobi y epub). De esta manera, los lectores tienen acceso rápido a las nuevas ideas, y pueden formar parte de la evolución de la obra. Para los autores, esta es una forma efectiva de retroalimentación y motivación para la generación de contenido.