Libro: El método LEAN STARTUP


 

Título: El método LEAN STARTUP. Cómo crear empresas de éxito utilizando la innovación continua.

Autor: Eric Ries

Editorial: Deusto

Al escribir esta entrada me he dado cuenta de que el autor de este libro es más joven que yo. Y lo escribió hace 4 años. Supongo que empiezo a tener una edad…

En fin, que andaba buscando literatura sobre gestión de proyectos clásica (o tradicional, o incluso folclórica diría a día de hoy) y no pude evitar fijarme en el LEAN del libro. Fan como soy de este tipo de filosofía (o método o principio) desde que la conocí hace ya algunos años, tuve que traérmelo a casa y leerlo en pocos días. Porque el libro en sí, con sus 300 páginas es realmente fácil de leer y el autor facilita mucho la tarea a base de estructuras tópicas y manidas, pero no por ello menos efectivas. En algunos casos sin embargo, tal abuso da la impresión de que lo haya escrito un negro amateur bajo la supervisión de un entusiasta vendemotos.

Volviendo a la reseña, el libro es una especie de manual introductorio al método de gestión empresarial del autor. Este método es, repito, empresarial, por lo que está claramente orientado a la creación y gestión de empresas, en particular empresas de tipo “startup” en su definición de empresa orientada a la innovación y el aprendizaje. A partir de algo de filosofía, técnicas prácticas, consejos y montones de historias bastante personales experimentadas por el autor, el libro nos va vendiendo la receta empresarial de Ries. La verdad es que no me parece un mal libro a pesar del exagerado tono de venta que tiene, pero me parece bastante superficial y con tendencia a exagerar o pintar el panorama mucho más dulce de lo que es. Aun así recomendaría su lectura a cualquier director de proyecto, empresario, emprendedor o aspirante a cualquiera de los puestos anteriores, bajo la advertencia de que se trata de un libro orientado a vender conferencias y consultoría del autor, ni más ni menos. Y lo hace muy bien.

Y lo recomiendo a pesar de todo ese marketing, porque hay algo evidente tras la lectura del texto: todo lo que cuenta este hombre está siendo aplicado desde hace al menos un par de años en Microsoft. Como es un tema que me toca de cerca (llevo años desarrollando en Office 365 entre otras cosas) puede que esté más sensible a este tipo de comparaciones, pero me parece evidente que los chicos de Redmond están siguiendo quizá no este método en particular, pero sí casi todos los consejos y enfoques en él escritos. Eso es interesante por dos razones: La primera es el ver como una empresa monstruosamente grande como Microsoft puede adaptarse a algo tan radical, tan rápido. La segunda cosa interesante es pensar en qué va a pasar a medio y largo plazo siguiendo por esa línea. Lo que resulta evidente es que a Microsoft no le va a pasar como a IBM y va a seguir siendo un actor muy relevante del panorama tecnológico de los usuarios o va a hundirse intentándolo. Sea como sea, va a ser épico.

A continuación algunas notas que me han resultado interesantes del libro y que espero que inviten a alguien más a leerlo (o cualquier otro texto sobre Lean):

 

Recuerde, la planificación es una herramienta que sólo funciona si disponemos de una historia de funcionamiento larga y estable. Aun así, ¿alguno de nosotros cree que el mundo que gira a nuestro alrededor es más estable cada día?


Era un devoto de los métodos de desarrollo de software más recientes (conocidos colectivamente como desarrollo ágil), que prometían contribuir a evitar el despilfarro de recursos en el desarrollo de producto. A pesar de eso, había cometido el mayor despilfarro de todos: había creado un producto que los consumidores se negaban a usar. Esto fue realmente deprimente. [Al respecto de una funcionalidad que se desechó completamente cuando la empresa pivotó, como forma de ilustrar que las técnicas de desarrollo por sí solas no lo son todo]


[…] esto era parte de la gran lucha del desarrollo ágil: los ingenieros acceden a adaptar el producto constantemente a los cambiantes requerimientos de los directivos, pero no se responsabilizan de la calidad de las decisiones.
El sistema ágil es un sistema de desarrollo eficiente desde el punto de vista de quienes desarrollan el producto. Les permite centrarse en crear elementos y en el diseño técnico. Un intento de introducir la necesidad de aprender [esencial para la innovación y la supervivencia de la startup] en este proceso puede dañar la productividad [que no es el fin de una startup].
El Lean manufacturing tuvo problemas similares cuando se introdujo en las fábricas. Los directivos estaban acostumbrados a centrarse en la tasa de utilización de cada máquina. Las fábricas estaban diseñadas para mantener las máquinas trabajando al máximo todo el tiempo que fuera posible [como en cualquier consultora tecnológica del montón española]. Desde la perspectiva de la máquina, esto es eficiente, pero desde el punto de vista de la productividad global de la fábrica a veces es muy ineficiente. Como dicen en la teoría de sistemas, lo que optimiza una parte del sistema necesariamente debilita el sistema en su conjunto.


Finalmente, cada empresario se enfrenta a un reto primordial en el proceso de desarrollar un producto de éxito: decidir cuándo pivotar y cuándo perseverar. […] Debido a la metodología científica subyacente del método Lean Startup, a menudo se tiene una idea errónea, al pensar que este método ofrece una fórmula clínica rígida para tomar decisiones sobre pivotar o perseverar. Esto no es verdad. No hay forma de eliminar el factor humano, la visión, la intuición, el juicio, de la práctica del emprendedor, y tampoco sería deseable.


La medida real de la pista [tiempo/dinero, vida] es cuantos pivotes le quedan a una startup: el número de oportunidades que tiene para hacer un cambio fundamental en su estrategia de negocio. Medir la pista a través de los pivotes en lugar de mediante el tiempo sugiere otra manera de extender la pista [al margen de conseguir dinero y recortar costes]: llegar a cada pivote más rápidamente.


[Sobre un ejercicio de llenado y envío de sobres, la multitarea, la eficiencia, el tamaño de los lotes de trabajo y lo contra-intuitivo] ¿Por qué llenando un sobre cada vez se consigue hacer el trabajo más rápidamente a pesar de que parece que debería ser más lento? Porque nuestra intuición no tiene en cuenta el trabajo extra que se requiere para almacenar, amontonar y mover grandes pilas de sobres medio completados cuando se hace de la otra forma. Parece más eficiente repetir la misma tarea una y otra vez, en parte porque esperamos que cada vez haremos esta tarea más rápidamente. Desgraciadamente, en un trabajo orientado al proceso como este, el resultado individual no es tan importante como el resultado general de todo el sistema.
Incluso si la cantidad de tiempo que requiere cada proceso fuera la misma, el enfoque de producción de los lotes pequeños seguiría siendo mejor, también por razones no intuitivas. Por ejemplo, imagínese que los boletines no cupiesen en los sobres. Con el enfoque de los lotes grandes no lo descubriríamos hasta llegar al final del proceso. Con los pequeños se descubre inmediatamente. ¿Qué pasa si los sobres son defectuosos y no cierran bien? [Fail fast de manual]


Los cinco porqués [una técnica de análisis de problemas] requieren un entorno de confianza mutua. En situaciones en que esto no existe, la complejidad de esta técnica puede ser abrumadora. [Para una versión más simple en ese tipo de entornos] Pido a los equipos que adopten estas simples reglas: 1 Ser tolerantes con los errores la primera vez. 2 No permitir que se cometa dos veces el mismo error.
La primera regla anima a la gente a acostumbrarse a ser compasiva con los errores de los demás. Recuerde que la mayoría de los errores están causados por sistemas defectuosos, no por malas personas. La segunda regla lleva a que el equipo empiece a realizar inversiones proporcionales de prevención.


[Acerca de una empresa que cambió su forma de trabajo a lo largo de 3 años] Pasar a una forma de trabajar multifuncional no fue sencillo. Algunos miembros de los equipos eran escépticos. Por ejemplo, algunos directores de producto sentían que era una pérdida de tiempo que los ingenieros dedicaran tiempo a los consumidores. Los directores de producto pensaban que su trabajo era descubrir el problema del cliente y definir qué debían crear. Por lo tanto, la reacción al cambio de algunos directores de producto fue: “¿Cuál es mi trabajo? ¿Qué se supone que estoy haciendo?”. De forma similar, algunos ingenieros simplemente querían que les dijeran qué tenían que hacer; no querían hablar con los consumidores. Como es típico en el caso del desarrollo de lotes grandes, ambos grupos deseaban sacrificar la capacidad de aprender del equipo [y por tanto ser más competitivos] para trabajar de forma más “eficiente” [ver el caso de los sobres].


Aquellos que ven la adopción del método Lean Startup como un conjunto definido de pasos no tendrán éxito.

Anuncios