Mitos del desarrollo de producto (3)

por Antonio Matarranz en 22 octubre 2016

Una aplicación “extrema” de técnicas provenientes de los procesos de fabricación al desarrollo de productos ha generado falacias que perjudican la innovación. Con la tendencia a enfoques más ágiles estamos llegando a un justo término medio.

En esta tercera y última parte del post (ver la primera y la segunda) seguimos desgranando las falacias sobre el desarrollo de productos que Stefan Thomke y Donald Reinertsen describen en “Six Myths of Product Development” y proponemos algunas ideas para contrarrestarlas:

Mito 5: Nuestro plan de desarrollo es genial: sólo tenemos que ajustarnos a él

Experimentación No existe ningún producto cuyos requisitos no cambien durante el proyecto de desarrollo. Bien sea debido a que nuestra comprensión de las necesidades de los clientes va evolucionando o a cambios en la tecnología o el entorno competitivo, estos cambios son inevitables. Y sin embargo muchas empresas ponen una extraordinaria fe en sus planes, hasta el punto de monitorizar cada fase en relación a ciertos objetivos e hitos intermedios y de atribuir cualquier desviación a una mala gestión y ejecución. Pero este pensamiento, que puede resultar adecuado en entornos conocidos actividades repetitivas, lleva a resultados pobres en la innovación de producto, donde cada día se generan nuevos insights y las condiciones cambian continuamente.

Por esa razón, una adherencia excesiva al plan original, por muy bien concebido que esté y por excelente que sea la ejecución, es una receta para el desastre. Pero eso no quiere decir que no creamos en los planes, sino que estos deben ser considerados como hipótesis que se revisan constantemente a medida que la evidencia va apareciendo, las asunciones cambian y la oportunidad se reevalúa. Como más de una vez hemos dicho por aquí, “los planes son inútiles pero la planificación es indispensable”.

Mito 6: Tendremos más éxito si lo hacemos bien la primera vez

Muchos proyectos de desarrollo de producto fracasan porque en la empresa se sigue aplicando una cultura de “hacer las cosas bien a la primera” que insufla en los equipos un sesgo hacia las soluciones de bajo riesgo (incluso si los clientes no las consideran una mejora significativa sobre lo que existe actualmente) y que genera escasos incentivos para perseguir soluciones innovadoras. Para evitar errores los equipos siguen un proceso lineal (p.ej., Stage-Gate) en el que cada etapa se somete a escrutinio en “puertas” de revisión. El inconveniente es que estos procesos retrasan el feedback de las pruebas hasta que ya se ha incurrido en cuantiosas inversiones y los costes de responder a nuevas informaciones son muy altos.

Una cierta tolerancia a “hacerlo mal la primera vez” puede ser una mejor estrategia con tal se itere rápida y frecuentemente y se pueda aprender de los fallos a bajo coste. Los avances en las tecnologías de simulación y prototipado rápido han hecho que funcionar de esta manera sea mucho más fácil y menos caro. Experimentar con muchas ideas diferentes es crucial en los proyectos de innovación. Cuando se experimenta rápida y frecuentemente muchos conceptos nuevos se caen, obviamente. Pero estos fallos tempranos son deseables porque permiten a los equipos eliminar rápidamente las opciones pobres y enfocarse en las alternativas más prometedoras. Los experimentos que resultan en fallo no son necesariamente fracasos si permiten aprender y generar nueva información que era imposible de prever. Pero crear este tipo de entorno no es fácil: no es habitual que un equipo sea recompensado por revelar pronto fallos en un proyecto que llevan a terminarlo – incluso aunque la consiguiente reasignación de recursos beneficie a la empresa. El ejemplo clásico de implantación de este tipo de cultura y organización fue Thomas A. Edison, que desplegó sus laboratorios alrededor del concepto de la experimentación rápida y para quien la medida del éxito era “el número de experimentos que pueden encajarse en 24 horas”.

Propuestas para superar estas falacias

Algunas nociones procedentes del mundo de la fabricación (por ejemplo, la idea de que unos lotes más pequeños pueden mejorar los tiempos de ciclo, la calidad y la eficiencia) funcionan perfectamente en desarrollo de productos. Pero eso no nos puede llevan a aplicar esas ideas sin tener en cuenta la diferencias esenciales entre ambas actividades. Cuando el desarrollo de productos está “roto”, optimizar el proceso no es la solución porque sólo nos lleva a desarrollar malos productos… de manera más eficiente.

En su artículo, Thomke y Reinertsen proponen las siguientes líneas maestras –muchas de ellas ligadas a unos procesos más ágiles/lean- para superar las anteriores falacias sobre el desarrollo de productos:

Hacer que las colas y los flujos de información sean visibles
Cuantificar el coste de los retrasos e incorporarlo en las decisiones
Introducir recursos disponibles allí donde la utilización sea más alta
Mover el foco de los sistemas de control desde la eficiencia hacia los tiempos de respuesta
Reducir los costes de transacción para permitir tamaños de lote menores y feedbak más rápido
Experimentar con lotes más pequeños: siempre se puede volver a lotes más grandes si esto no funciona
Tratar el plan de desarrollo como hipótesis que van a evolucionar a medida que se dispone de nueva información
Empezar los proyectos únicamente cuando podemos comprometer completamente los recursos necesarios
Buscar la simplicidad: preguntarse qué características se pueden eliminar, no cuáles se pueden añadir
Experimentar pronto, rápidamente y frecuentemente, con modelos por ordenador y prototipos físicos, en entornos controlados y en el mundo real
Poner énfasis en procesos de diseño con solapamientos e iterativos, no lineales
Enfocarse en el feedback rápido, no en el éxito a la primera.