Advertisement
28 May, 2023

Emprendedores Logo

×

Si un proyecto sale mal en tu empresa, así deberías hacerle la autopsia

Cualquier lanzamiento de productos o de servicios que realice tu empresa debería llevar a cabo una autopsia del proceso tanto si tiene éxito como si no. Para buscar ineficiencias y, en el caso de que el producto no funcione en el mercado, saber ya si el problema es interno o externo a tu empresa. La ingeniería informática lleva tiempo realizando análisis postmortem. Esto es lo que puedes aplicar de su experiencia a tu empresa.

Si un proyecto sale mal en tu empresa, así deberías hacerle la autopsia

En ocasiones te vas a encontrar con que vas a lanzar al mercado un producto o un servicio bueno y no va a funcionar. En lugar de dejarlo estar y de lamentarnos, debes plantearte autopsias de producto y de servicio para ver por qué mueren. ¿El producto no era bueno? ¿O el consumidor no lo llegó a conocer? ¿O no llegó a probarlo? ¿O lo probó y no le gustó? ¿O lo probó y le gustó, pero lo probaron pocas personas? ¿Falló el canal de distribución? ¿Nos equivocamos en el precio? ¿Hubo alguna variación en el producto en el proceso de lanzamiento? Hay que averiguar bien la causa de que algo no se venda.

Es importante saber por qué ha muerto un producto. Si tienes fracasos, pero no le dedicas tiempo a analizarlos, te pueden volver a pasar por los mismos motivos. Curiosamente, en muchas organizaciones hay una inercia generalizada a llevar adelante los proyectos modificando un producto todo lo que sea necesario para que no muera por el camino, y, al final, el producto sufre tantísimas modificaciones que lo que termina llegando al mercado está desvirtuado y en la mayoría de los casos es lógico que no funcione.

Hay oportunidades entre los ‘muertos’. Piensa que has dedicado tiempo y esfuerzo en innovar: recursos humanos, económicos y tecnológicos. Si el producto no ha muerto porque no fuera bueno, merece una segunda oportunidad. Eso sí, esta vez sin cometer los errores que acabaron con su vida en primer lugar.

Por todo esto es importante llevar a cabo análisis postmortem de proyectos, una práctica habitual en ingeniería informática donde se realiza el análisis postmortem del código antes incluso de saber si el producto va a funcionar para analizar: se recaba información sobre el proceso y en cuanto se lanza. Hemos extraído del libro de Jack Ganssle El arte de diseñar en embebido las mejores ideas para hacer un análisis postmortem de proyectos para cualquier negocio:

1. En cuanto lances un nuevo producto o servicio, programa en el calendario la autopsia a una semana vista. Básicamente porque el equipo va a tener la información más fresca. Si esperas a que el producto no funcione en el mercado, el equipo puede estar en un nuevo proyecto y haber olvidado un pequeño fallo que puede haber sido el causante del fracaso en el mercado.

2. Se debe reunir todo el equipo que ha trabajado en el desarrollo del producto. No es un análisis de jefes, sino de todo el equipo. Todos tienen peso en el desarrollo.

3. El proceso necesita un coordinador. No se trata de que sea siempre el mismo para todos los análisis postmortem de la empresa. Lo bueno es que vaya rotando la plantilla. De la misma manera, tampoco es una función de jefes. Además, no es una sesión para criticar las cosas que han ido mal, sino para detectar dónde ha habido escollos, dónde se hubiera necesitado apoyo, qué se podría haber hecho de forma diferente. Se trata de identificar problemas que se puedan solucionar.

4. Una vez identificados los problemas, selecciona 3 o 4 y centraros en ellos. La empresa debe aprender de sus errores, pero también tiene seguir funcionando, así que de todos los escollos que han ido surgiendo para preparar un producto o para diseñar y poner en el mercado un servicio, tenéis que elegir cuáles son verdaderamente problemas que pueden tener un efecto sobre el producto en el mercado y cuáles son los que verdaderamente tenéis que solucionar para posteriores lanzamientos.

5. Los problemas se resuelven con soluciones concretas. Si, por ejemplo, hay un fallo de comunicación, la solución no es: resolver los problemas de comunicación, sino: para evitar que A se salte a B a la hora de informar sobre cambios el desarrollo del proyecto, todo el equipo debe colgar en esta herramienta X los cambios en el proyecto. Lo que queremos decir con esto es que hay que planificar las soluciones.

6. Las conclusiones se presentan por escrito en una reunión final y se incorporan a una biblioteca de autopsias. Las conclusiones de la reunión se ponen por escrito y pasan a la galería de autopsias, un manual de consulta que se debe revisar antes de afrontar un nuevo desarrollo y que debe estar al alcance de cualquier empleado.