domingo, 12 de enero de 2014

Por que leer Lean Startup, de Eric Ries


Hace unos días termine de leer el libro "Lean Startup" de Eric Ries. Es un libro que busca transmitir una filosofía de management no tradicional, basada en los aprendizajes de metodologías de origen japones como Lean y Just In Time.
No es un libro para que lean solo aquellos que quieran comenzar su propia empresa - o startup, sino que lo primero que hace es hacer entender que todos somos emprendedores, ya sea iniciando nuestro propio emprendimiento independiente, o trabajando en una gran empresa multinacional.
Es un libro realmente muy interesante, que no se queda solo con la teoría, sino que muestra como llevarlas a la práctica y nos deja algunos casos donde su implantación fue un éxito.
En los próximos párrafos, voy a transmitir algunos de los conceptos que, segun mi opinión, son los mas importantes, y por los cuales recomiendo invertir el tiempo en leerlos del propio autor.
En primer lugar, los 5 principios de Lean Startup:

  1. Los emprendedores están en todos lados. O sea, no importa que trabajemos por nuestra cuenta o en una multinacional, todos los que trabajamos para crear nuevos productos y servicios somos emprendedores.
  2. El entrepreneurship es management. El "emprendedorismo" es una nueva disciplina, que debe existir en toda compañía.
  3. Aprendizaje validado. Las startups existen para aprender como generar un negocio sustentable. Esto se logra realizando experimentos, midiendo y aprendiendo.
  4. Build-Measure-Learn (Hacer-Medir-Aprender). Este es el ciclo de aprendizaje continuo que se debe llevar adelante, para realmente esforzarse en el producto indicado.
  5. Contabilidad de la innovación. No nos debemos olvidar de demostrar el progreso, priorizar y gestionar nuestros esfuerzos en la innovación.
Un punto que me pareció muy importante - y que es parte del core del libro, viene del principio 4 y 3. Lo mas importante es aprender, no importa si lo que produzcamos tiene éxito o no en el mercado al que apuntamos. Debemos "perdonar el error la primera vez, y asegurarnos de que no vuelva a suceder". Esto se logra realizando un MVP - Minimun Viable Product, creado en base a hipótesis iniciales, el cual nos permita - mediante mediciones de valor- validar dichas hipotesis, y nos brinde información para seguir en el camino planteado, o cambiar la ruta hacia un nuevo obejtivo, manteniendo la visión mientras sea necesario. Esta forma de trabajar asegura que vamos a usar nuestra capacidad - muchas veces escasa - en desarrollar el producto que realmente se requiere.

Nombre en el párrafo anterior que, para crear un MVP - el cual debe servir para validar lo que queremos, y tiene que ser lo mas simple posible-, es necesario tener hipótesis que el mismo siga. Estas hipótesis marcan como el producto se supone que creará valor, y como irá creciendo una vez establecido. Debemos tener claro estos dos puntos, y establecer una manera clara de medir la innovación y el aprendizaje generado mediante métricas base asociadas a cada hipótesis o assumption, que permita demostrar claramente y de manera no ambigua como se crea valor, y como se va creciendo. Si las métricas están bien definidas (y no son vanity metrics-enfocadas en un aspecto parcial del problema), nos va a permitir establecer cuando perseverar, o cuando cambiar el rumbo.

Debemos definir bien las métricas asociadas a nuestras hipotesis, teniendo en cuenta la regla de las tres A, para que las mismas sean:
  • Accionables. O sea, que deben demostrar claramente una causa y efecto.
  • Accesibles. Los datos deben ser accedidos por todos los involucrados en el producto, de la manera mas simple posible.
  • Auditables. Se debe poder tracear la información que generó las métricas, para defender cuando decimos que el proyecto va bien, o va mal y debemos cambiar el rumbo.
Volviendo a que el MVP sea lo mas simple posible. Es importante asegurarnos que vayamos avanzando en el desarrollo deproducto de a pasos cortos (small batches), que produzcan iteraciones de creación-medición-aprendizaje. Por eso, debemos ir planificando mejoras pequeñas, pero medibles y que nos permitan aprender y definir los siguientes pasos.

Algunas otras prácticas o herramientas que me parecieron interesantes:
  • Enfocarnos en tener un MVP simple, y validarlo con usuarios finales, en un ambiente real, aunque cuidado. Lo mas adecuado es realizar estas validaciones midiéndolas por poblaciones de usuarios (cohortes), lo que nos permitirá tener una visión mas acabada de nuestra situación.
  • Tener al aprendizaje sobre nuestro producto como primer objetivo, y dejar para una segunda instancia la optimización. Para un ingeniero o diseñador este punto es muy difícil, pero es vital mantenerlo en práctica.
  • Realizar pruebas de diferentes versiones de productos a diferentes poblaciones, comparando las métricas entre los diferentes grupos de clientes. Pueden ser mediante tests A/B, pruebas green-blue servers, etc.
  • Técnicas como continuous integration y continuous deployment permiten acelerar el ciclo de creación-medición-aprendizaje, mediante la automatización, que lleva a la eliminación de desperdicios (tiempos muertos), y el foco en esforzarse para crear valor en lugar de realizar tareas repetitivas.
  • KANBAN nos permite tener siempre visible la capacidad de nuestros equipos, y el flujo de actividades, haciendo mas simple encontrar puntos de mejora y aumentar la productividad general.
  • Debemos generar una organización adaptativa, que evolucione constantemente y no se quede congelada. Una herramienta para lograr esto, es ejecutar el ciclo de "5 porque" (five whys) cuando nos encontramos con un problema, para llegar a la raiz del mismo. Muchas veces, un problema que parece técnico - solución simple y superficial, en realidad esta dada por un problema sistémico y asociado a personas.
Esto fue solo un resumen de lo que a mi me parece mas importante del libro, pero es muy recomendable meterse a lleno, leerlo e implementar sus prácticas (Algo que voy a hacer, y luego comentar mis aprendizajes).


0 comentarios:

Publicar un comentario