José Manuel Beas
Desarrollo Ágil de Producto para Emprendedores
Introducción Una startup siempre tiene un presupuesto ajustado que debe aprovechar al máximo. No puede permitirse el lujo de
añadir características a un producto que luego no se usen. El método Lean Startup es muy claro al respecto y nos empuja a aprender en cada ciclo de feedback. Las metodologías ágiles encajan como un guante en este ciclo de feedback porque permiten al equipo de desarrollo que incorporen el aprendizaje obtenido con cada nueva versión del producto puesta en las manos de los usuarios. Pero frecuentemente nos encontramos con inconvenientes serios: cómo definimos ese feedback, cómo validamos que lo que el equipo de desarrollo ha construido hace lo que necesitamos, quién es la persona adecuada para hacer esto y, sobre todo, cómo podemos hacerlo aprovechando nuestros recursos al máximo.
Además de responder a esas preguntas, en este capítulo os mostraré las técnicas más usadas por los equipos que desarrollan productos de manera ágil, como la Agile Inception o el User Story Map y cuyo objetivo es ayudarnos a enfocar el desarrollo en un MVP (Producto Mínimo Viable) que valide nuestras hipótesis con el uso más eficiente de nuestros escasos y valiosos recursos.
Definir productos
“de a pocos” Construir software definitivamente no es como construir un edificio. Esta metáfora no vale
1. El software es maleable y el resultado final no es tangible. Aun hoy los planos del edificio, los programas, parece que sólo pueden ser leídos por especialistas y esto dificulta la participación de los usuarios/clientes en la elaboración de los mismos y, lo más importante, en la validación antes de ser construidos.
Para abordar este problema tenemos dos enfoques posibles: comprobar la validez del modelo una vez está construido o participar en la especificación del mismo. En ambos casos resulta obvio que, cuanto más grande es el sistema a modelar/construir, más difícil es especificarlo y también validarlo. Las metodologías ágiles nos ayudan a cambiar de paradigma y comenzar a pensar en cómo construir sistemas en un ciclo iterativo e incremental, es decir, “de a pocos”.
Un producto ágil se construye a partir de un pequeño prototipo, sobre el cuál vamos incorporando más y más funcionalidades, a partir de las expectativas y del aprendizaje obtenido tras la construcción. BUILD/MEASURE/LEARN.
Lean Startup Feedback Loop
Suena conocido2, ¿verdad?
Tras cada ciclo podemos validar nuestras hipótesis. ¿Es así como quiero que mis usuarios usen mi aplicación? ¿Debo seguir gastando dinero en añadir más funcionalidades de este tipo o debo explorar otras posibilidades? Incluso, ¿debo cancelar el proyecto porque éste nunca tendrá éxito?
1 Ver la charla de Glenn Vanderburg en la Lone Star Ruby Conference 2010 titulada “Real Software Engineering” donde, entre otras cosas, explica que el resultado
final de un desarrollo de software no es construir un programa que se pueda ejecutar sino realmente ejecutarlo y obtener los beneficios para los que fue creado.
Desarrollo Ágil de Producto para Emprendedores José Manuel Beas
España Lean Startup 2013 2
Desarrollo Ágil de Producto para Emprendedores
Todo esto suena muy bien pero… efectivamente, es muy difícil. Por una parte es necesario saber construir software, es decir, tener los conocimientos y experiencia necesarios para hacer funcionar las ideas. Pero también es necesario saber definir esas ideas “de a pocos”. Para ello, las metodologías ágiles nos proporcionan herramientas como las Historias de Usuario, pequeños trozos de papel que resumen una funcionalidad de nuestro sistema desde el punto de vista del usuario, con un tamaño muy adecuado para mantener conversaciones muy enfocadas alrededor de la misma y con un criterio acordado por todos sobre cómo decir que está acabada3. Pero
no adelantemos acontecimientos, más adelante profundizaremos sobre las Historias de Usuario y otras técnicas ágiles para definir y construir nuestros productos “de a pocos”.
Un escenario muy frecuente es el de un emprendedor con una idea brillante, innovadora, definitivamente disruptiva, pero sin conocimientos suficientes para llevarla a la práctica. En muchas ocasiones simplemente se trata de construir una web que permita dar a conocer el producto, pero en otras se trata de ofrecer servicios a los clientes. Por ejemplo, una tienda online de empanadas gallegas como ésta no es un mero escaparate sino algo más: un medio para que los clientes compren nuestras empanadas y, más importante aún si cabe, un canal para conversar con ellos y conocerlos mejor.
Lean Startup y Agile tienen en común la importancia que ambos le dan al feedback que obtenemos de los usuarios. En este capítulo me centraré en dos puntos de ese ciclo de feedback. El primero es cuando pasamos de las ideas a un plan de construcción, es decir, cuando incorporamos el aprendizaje en forma de idea que debemos validar. El segundo es cuando damos el visto bueno para que el producto construido pase a estar a disposición de los usuarios y comenzar así la validación por parte del mercado, que es la que realmente nos interesa como emprendedores.
Este artículo se centra en estos puntos del
feedback loop
Sin embargo, no voy a dar por supuesto que el equipo que construye el producto a partir de las ideas es el mismo y, aunque pudiera parecer contradictorio, ni siquiera asumiré que el equipo usa alguna metodología ágil para su construcción. Eso sí, veréis que la consecuencia natural, la que provoca menor rozamiento en nuestro ciclo de trabajo, es que se construya el producto respetando los valores y principios ágiles. Porque todas las metodologías ágiles se basan en el Agile Manifesto y aplican sus principios:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
Desarrollo Ágil de Producto para Emprendedores José Manuel Beas
Desarrollo Ágil de Producto para Emprendedores
Por tanto, cuando un equipo construye software siguiendo estos principios, obtenemos el feedback de los usuarios poniendo a su disposición software funcionando, en un ciclo continuo de entregas frecuentes, incrementando así el valor del software porque incorporamos lo aprendido en las entregas anteriores.
La metáfora del
cañón y el misil Os propongo la siguiente metáfora. Suponed que tenéis que disparar a un objetivo a varios kilómetros de distancia. Apenas lo podéis ver a simple vista y para acertar sólo tenéis una única bala y un cañón. Seguro que, conscientes
de la importancia de realizar bien los cálculos, os tomáis vuestro tiempo, medís las distancias, los ángulos, el peso de la bala, ajustáis bien el cañón, lo dirigís hacia el objetivo y disparáis, confiados en que vuestros cálculos han sido perfectos. Pero no habíais contado con que el viento no era constante ni con que el propio objetivo se desplazaba lentamente hacia el oeste. El resultado… fallo.
Si os dieran una segunda oportunidad, ¿qué mejoraríais en la “gestión del proyecto”? La respuesta más inmediata es complicar el modelo de los cálculos e introducir todas esas nuevas variables para poder ejecutar un disparo aun más preciso. Sin embargo, un agilista respondería que cambiaría el cañón por un misil teledirigido. Así, en vez de realizar unos precisos cálculos iniciales, él lo lanzaría inmediatamente en la dirección del objetivo, sin necesidad de precisar demasiado porque ya sabe que éste se va a mover o que habrá imprevistos que lo desviarán, como el viento, por ejemplo. El misil, sin embargo, cada pocos segundos se encarga de reorientarse a sí mismo, incorporando a su nueva dirección las posibles desviaciones sufridas durante ese intervalo. El resultado, como podéis prever es… éxito.
Esta conocida metáfora de Henrik Kniberg4 nos ayuda a entender la diferencia entre una gestión de un proyecto predictiva y una adaptativa. Las metodologías ágiles se basan en una gestión de proyectos adaptativa como estrategia para incorporar el aprendizaje obtenido tras cada ciclo BUILD/MEASURE/LEARN. Al final de cada ciclo inspeccionaremos, es decir, pondremos el producto en la calle y mediremos, y en función del feedback recibido nos adaptaremos. Igual que el misil.
Pasar de la idea a un plan de construcción
Bien, de entre todas las ideas que tenemos en la cabeza nos decidimos por una y queremos ahora construir el producto que la ponga en la calle, a disposición de nuestros potenciales usuarios. Para ello, lo primero que tenemos que hacer es sacarla de nuestras cabezas y compartirla con el resto del equipo, entendiendo por equipo a todos aquellos que van a participar en la construcción. Así, con una idea compartida por todos será más fácil elaborar un plan que nos permita acercarnos lo más posible a la idea y posteriormente validarla. Ojo, son dos objetivos. No lo olvidemos porque es muy frecuente que nos quedemos en construir algo exactamente como lo que tenemos en la cabeza, sin atender a que, sobre todo, estamos construyendo algo que debe permitirnos validar que nuestra idea es rentable o no. Es lo que Eric Ries denomina el “aprendizaje validado” (o validated learning). A continuación estaremos en condiciones de elaborar un plan de construcción y despliegue para el producto. Observad que he distinguido entre construir y desplegar, es decir, entre hacer que el producto vaya tomando forma dentro y fuera de la cocina. Porque no siempre podemos poner en la calle todo lo que construimos, bien porque no nos permitiera validar ninguna hipótesis o, peor aún, porque nos confundiera al medir los datos. Por ejemplo, suponed que queremos competir con Amazon en la venta de libros online y que nuestro factor diferencial es la facilidad en el proceso de compra. Suponed que nuestra primera versión, el MVP5, sólo fuera una landing page explicando cómo imaginamos que será el proceso de compra cuando esté construido. Obviamente eso no está validando que el producto, una vez construido vaya a ser siquiera posible construirlo, que es una de las hipótesis que debemos validar. Esa página de aterrizaje está validando que la idea es atractiva para un número dado de potenciales usuarios y nos está habilitando para comenzar a recibir feedback. Por otro lado, bien podríamos haber construido algo mucho más elaborado de entrada. Supongamos que hemos construido un proceso de compra
4 H. Kniberg es autor, entre otros, del libro “Scrum y XP desde las trincheras”. Presentó esta metáfora en la Conferencia Agile-Spain en 2010. Éstas son las
diapositivas y el video (min. 23 en adelante).
5 El Minimum Viable Product al que se refiere Eric Ries en los principios del método Lean Startup o del que podéis leer también el artículo “MVP” de Borja Prieto en
Desarrollo Ágil de Producto para Emprendedores José Manuel Beas
España Lean Startup 2013 4
Desarrollo Ágil de Producto para Emprendedores
excelente pero un proceso de registro complicado. El resultado podría ser negativo y nos obligaría a hacer un trabajo añadido de averiguar por qué a los usuarios no les gusta nuestro producto.
Para elaborar el plan os recomiendo realizar una Agile Inception, o cualquier otra dinámica similar, porque ésta está especialmente diseñada para enfocar a todas las personas involucradas en un proyecto hacia un mismo objetivo, reduciendo muchas de las incertidumbres, ayudando a explicitar los riesgos más evidentes, poniendo en común las expectativas de todos y, sobre todo, explicitando qué es lo que NO va a hacer nuestro producto y, por lo tanto, no vamos a gastar dinero en ello.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial6.
Agile Inception Publicada en el libro “The Agile Samurai” y en la conferencia “Agile 2011″, se puede emplear al iniciar cualquier tipo
de proyecto, no sólo de software, aunque brilla especialmente en las fases iniciales de un proyecto de emprendeduría porque facilita la definición del MVP.
La Agile Inception no es una garantía para conseguir el consenso pero ayuda mucho a conseguirlo. De hecho, uno de los resultados que pueden ocurrir al final de la misma es que concluyamos que el proyecto no es viable o demasiado arriesgado para iniciarlo.
Es una reunión muy cara porque requiere de la participación continuada de muchas personas durante mucho tiempo. Ejecutar todas las actividades propuestas requiere cierto reposo porque muchas de ellas buscan la creatividad o la reflexión y puede llevar hasta dos días completos, tras los cuáles los participantes pueden estar exhaustos. La logística (comida, bebida, descanso, etc.) es muy importante para conseguir que todos los participantes puedan aportar en todas las actividades. Para ayudar a que las actividades fluyan es conveniente contar con un facilitador.
El resultado que debemos esperar es un plan de construcción compartido por todos. Los podéis plasmar en el formato que más cómodo os resulte a vosotros. Yo suelo ampliar la Agile Inception un poco más y emplear el User Story Map para salir con un plan porque así he obtenido los mejores resultados. Con él tenemos una visión a largo plazo de cómo creemos que el producto debería ser construido y podremos tomar decisiones sobre cuándo será adecuado ponerlo en la calle. Claro que será la terca realidad la que nos ayude a cambiar esta foto inicial y convertirla en una foto en movimiento que, como veíamos en la metáfora del misil, se adapte mejor a lo que vayamos aprendiendo del mercado.
También os recomiendo la lectura y puesta en práctica de la técnica del Impact Mapping7 de Gojko Adzic. Es una técnica similar a la Agile Inception en la que se prescinde de algunas ceremonias, se pone mucho foco en el ROI de las funcionalidades a desarrollar y se facilitan muchas conversaciones y decisiones para orientar la construcción del producto.
User Story Map Es una técnica descrita por primera vez por Jeff Patton y consiste en representar el product backlog8 en dos
dimensiones en vez de en una. Las tarjetas representan épicas, es decir, historias demasiado grandes y ambiguas como para llamarlas historias de usuario, y se distribuyen horizontalmente según el orden en el que éstas serían usadas por los usuarios para completar un uso normal del mismo. La primera capa se denomina el “walking skeleton” o primera versión que pondremos a disposición de los usuarios para recibir feedback. Haremos crecer el User Story Map [USM] verticalmente añadiendo capas de funcionalidad completa y coherente para los usuarios. Si nuestro “walking skeleton” coincide con el MVP estaremos en disposición de ponerlo en la calle a disposición de los usuarios, pero a veces esto no es deseable y debemos esperar a tener alguna capa más de nuestro producto. En cualquier caso, el USM nos ayuda a trazar un plan de construcción iterativa e incremental de nuestro producto.
6 Del Agile Manifesto. http://agilemanifesto.org
7 En la web http://impactmapping.org podéis encontrar mucha información al respecto. 8 La lista priorizada de funcionalidades de nuestro producto. Puedes leer más aquí.
Desarrollo Ágil de Producto para Emprendedores José Manuel Beas