Seis mitos del desarrollo de productos

La mayoría de los directores de desarrollo de productos siempre están luchando por llevar los proyectos a tiempo y dentro del presupuesto. Nunca tienen suficientes recursos para hacer el trabajo, y sus jefes exigen calendarios y entregables predecibles. Así que los directores presionan a sus equipos para que sean más parsimoniosos, para que redacten planes más detallados y para que reduzcan al mínimo las variaciones de los calendarios y el despilfarro. Pero este enfoque, que puede funcionar bien a la hora de dar la vuelta a las fábricas de bajo rendimiento, en realidad puede perjudicar los esfuerzos de desarrollo de productos.

Aunque muchas empresas tratan el desarrollo de productos como si fuera similar a la fabricación, los dos son profundamente diferentes. En el mundo de la fabricación de objetos físicos, las tareas son repetitivas, las actividades son razonablemente predecibles y los artículos que se crean pueden estar en un solo lugar a la vez. En el desarrollo de productos, muchas tareas son únicas, los requisitos del proyecto cambian constantemente y el resultado -gracias, en parte, al uso generalizado del diseño y la simulación avanzados asistidos por ordenador y a la incorporación de software en los productos físicos- es la información, que puede residir en múltiples lugares al mismo tiempo.

La falta de apreciación de esas diferencias críticas ha dado lugar a varias falacias que socavan la planificación, ejecución y evaluación de los proyectos de desarrollo de productos. Juntos, hemos pasado más de 50 años estudiando y asesorando a las empresas sobre los esfuerzos de desarrollo de productos, y hemos encontrado estos conceptos erróneos -así como otros que surgen por diferentes razones- en una amplia gama de industrias, incluyendo semiconductores, automóviles, electrónica de consumo, dispositivos médicos, software y servicios financieros. En este artículo los expondremos y ofreceremos formas de superar los problemas que crean.

Falacia 1: Una alta utilización de los recursos mejorará el rendimiento.

Tanto en nuestra investigación como en nuestro trabajo de consultoría, hemos visto que la gran mayoría de las empresas se esfuerzan por emplear completamente sus recursos de desarrollo de productos. (Uno de nosotros, Donald, a través de encuestas realizadas en cursos para ejecutivos en el Instituto Tecnológico de California, ha descubierto que el gestor medio de desarrollo de productos mantiene la utilización de la capacidad por encima del 98%). La lógica parece obvia: los proyectos tardan más tiempo cuando la gente no trabaja el 100% del tiempo, y por lo tanto, una organización de desarrollo ocupada será más rápida y eficiente que una que no es tan buena en la utilización de su gente.

Pero en la práctica esa lógica no se sostiene. Hemos visto que la velocidad, la eficiencia y la calidad de los resultados de los proyectos disminuyen inevitablemente cuando los directores llenan por completo los platos de sus empleados de desarrollo de productos, independientemente de lo capacitados que estén esos directores. La alta utilización tiene serios efectos secundarios negativos, que los gerentes subestiman por tres razones:

No tienen en cuenta la variabilidad intrínseca del trabajo de desarrollo.

Muchos aspectos del desarrollo de productos son impredecibles: cuándo llegarán los proyectos, qué tareas individuales requerirán y cuánto tiempo les llevará a los trabajadores que nunca han abordado esas tareas antes. Sin embargo, las empresas están más familiarizadas con procesos repetitivos como la fabricación y el procesamiento de transacciones, donde el trabajo no cambia mucho y las sorpresas son escasas. Estos procesos se comportan de forma ordenada a medida que aumenta la utilización de los recursos. Si se añade un 5% más de trabajo, se tardará un 5% más en completarlo.

Los procesos con alta variabilidad se comportan de forma muy diferente. A medida que aumenta la utilización, los retrasos se alargan drásticamente. (Véase la exposición «La alta utilización provoca retrasos»). Si se añade un 5% más de trabajo, completarlo puede llevar un 100% más de tiempo. Pero poca gente entiende este efecto. En nuestra experiencia con cientos de equipos de desarrollo de productos, hemos comprobado que la mayoría estaban significativamente sobrecomprometidos. Para completar todos los proyectos a tiempo y dentro del presupuesto, algunas organizaciones con las que hemos trabajado habrían necesitado al menos un 50% más de recursos de los que tenían.

Es cierto que parte de la variabilidad es el resultado de una falta de disciplina, y que algunas tareas de desarrollo de productos (como el diseño de componentes para un prototipo de avión o la realización de ensayos clínicos) incluyen un trabajo más repetitivo. Pero incluso si parte del trabajo es predecible, cuando se combina con otro trabajo impredecible, se verán problemas de colas.

No entienden cómo las colas afectan al rendimiento económico.

Una alta utilización de los recursos crea inevitablemente colas de proyectos. Cuando el trabajo parcialmente completado se queda inactivo, esperando a que la capacidad esté disponible, la duración del proyecto global crecerá. Las colas también retrasan la retroalimentación, haciendo que los desarrolladores sigan caminos improductivos durante más tiempo. Hacen que a las empresas les resulte difícil ajustarse a las necesidades cambiantes del mercado y detectar los puntos débiles de su producto antes de que sea demasiado tarde. Irónicamente, estos problemas son precisamente los que los directivos piensan que una alta utilización permitirá a sus equipos evitar.

Incluso cuando los directivos saben que están creando colas, rara vez se dan cuenta del coste económico. Aunque ese coste puede cuantificarse, hemos comprobado que la gran mayoría de las empresas no lo calculan. Los directivos deben sopesar los costes de las colas con los costes de la capacidad infrautilizada para encontrar el equilibrio adecuado.

En el desarrollo de productos, el inventario de trabajo en curso es predominantemente invisible.

Las colas de fabricación consisten en cosas físicas, y cuando el inventario de una fábrica se duplica, es obvio. Este no es el caso en el desarrollo de productos, donde el inventario consiste en gran medida en información, como la documentación del diseño, los procedimientos y resultados de las pruebas y las instrucciones para construir prototipos. Cuando el inventario se duplica en un proceso de ingeniería, no hay señales físicas. Además, como las normas contables exigen que la mayor parte del inventario de R&D se lleve a valor cero, los estados financieros no dan ninguna indicación de los graves excesos de inventario en el desarrollo de productos.

Es muy difícil luchar contra un problema que no se puede ver ni medir. Consideremos la situación de una importante empresa farmacéutica. Hace varios años, su recién nombrado director de descubrimiento de fármacos se enfrentó a un dilema de gestión. Al igual que otros altos ejecutivos que dirigen grandes organizaciones de I+D, intentaba encontrar formas de hacer que sus científicos fueran más innovadores. Quería que experimentaran más con nuevos compuestos químicos que pudieran generar nuevos fármacos prometedores y, al mismo tiempo, que eliminaran los candidatos poco prometedores lo antes posible. Los experimentos con organismos vivos, sin embargo, eran responsabilidad de la experimentación con animales, un departamento que no estaba bajo su control y que se gestionaba como un centro de costes. Se evaluaba en función de la eficiencia con la que se utilizaban los recursos de experimentación, lo que naturalmente conducía a una alta utilización. En consecuencia, los científicos dedicados al descubrimiento de fármacos tenían que esperar de tres a cuatro meses los resultados de pruebas que tardaban poco más de una semana en realizarse. La organización de pruebas «bien gestionada» impedía el progreso de la unidad de descubrimiento.

La solución obvia a estos problemas es proporcionar un colchón de capacidad en los procesos que son muy variables. Algunas empresas lo han entendido desde hace tiempo. Durante décadas, 3M ha programado a los desarrolladores de productos al 85% de su capacidad. Y Google es famoso por su «20% de tiempo» (que permite a los ingenieros trabajar un día a la semana en lo que quieran, una práctica que significa que hay capacidad extra disponible si un proyecto se retrasa). Sin embargo, según nuestra experiencia, este tipo de solución es bastante difícil de aplicar. Como veremos, pocas organizaciones pueden resistirse a la tentación de utilizar hasta la última capacidad disponible. Los gestores inician reflexivamente más trabajo cada vez que ven que hay tiempo ocioso.

Pero hay otras soluciones viables:

Cambiar los sistemas de gestión-control.

En el caso de la empresa farmacéutica, esto podría implicar la adopción de medidas para alinear los objetivos de la unidad de experimentación animal con los de la unidad de descubrimiento. La empresa podría, por ejemplo, recompensar los ensayos con animales por la rapidez de las respuestas (midiendo el tiempo desde la solicitud hasta la finalización de la prueba) en lugar de la utilización de los recursos.

Aumentar la capacidad de forma selectiva.

Añadir recursos adicionales a las áreas en las que las tasas de utilización son del 70% o superiores puede reducir significativamente el tiempo de espera. Si la empresa farmacéutica hiciera esto en las pruebas con animales, obtendría información sobre nuevos compuestos químicos mucho más rápido. En los entornos en los que las pruebas se llevan a cabo con modelado y simulación por ordenador, el aumento de la capacidad suele ser relativamente barato, ya que sólo implica la compra de equipos informáticos y licencias de software adicionales.

Limitar el número de proyectos activos.

Si la empresa farmacéutica no pudiera aumentar la capacidad de las pruebas con animales, aún podría reducir la tasa de utilización reduciendo el número de proyectos activos que exploran nuevos compuestos químicos. La disciplina de poner un límite duro a lo que entra en una línea de desarrollo de productos a menudo resulta en un enfoque más claro y prioridades más claras.

Haga que el inventario de trabajo en proceso sea más fácil de ver.

Un método es utilizar tableros de control visual. Estos pueden adoptar varias formas, pero la clave es tener algún tipo de ficha física, como una nota Post-it, que represente el trabajo de desarrollo (véase la exposición «Tablero de control típico del trabajo en proceso»). Un tablero de control debe mostrar todo el trabajo activo y mostrar en qué estado se encuentra cada parte del proyecto. Debe estar en el centro del proceso de gestión del equipo. Los equipos pueden celebrar reuniones diarias de 15 minutos en torno a estos tableros para coordinar los esfuerzos y mantener el trabajo en movimiento.

Falacia 2: Procesar el trabajo en grandes lotes mejora la economía del proceso de desarrollo.

Una segunda causa de las colas en el desarrollo de productos es el tamaño de los lotes. Digamos que un nuevo producto está compuesto por 200 componentes. Podrías optar por diseñar y construir las 200 piezas antes de probar cualquiera de ellas. Si, en cambio, diseñara y construyera sólo 20 componentes antes de empezar las pruebas, el tamaño del lote sería un 90% menor. Eso tendría un profundo efecto en el tiempo de espera, porque la cola media en un proceso es directamente proporcional al tamaño del lote.

La reducción del tamaño de los lotes es un principio crítico de la fabricación ajustada. Los lotes pequeños permiten a los fabricantes recortar el trabajo en proceso y acelerar la retroalimentación, lo que, a su vez, mejora los tiempos de ciclo, la calidad y la eficiencia. Los lotes pequeños tienen una utilidad aún mayor en el desarrollo de productos, pero pocos desarrolladores se dan cuenta del poder de este método.

Una razón es la naturaleza de su flujo de trabajo. De nuevo, como la información que están produciendo es en su mayoría invisible para ellos, los tamaños de los lotes también lo son. En segundo lugar, los desarrolladores parecen tener una predisposición inherente a utilizar lotes grandes, posiblemente porque creen erróneamente que los lotes grandes producen economías de escala.

En un proceso bien gestionado, el tamaño del lote equilibrará los costes de transacción y de mantenimiento (véase la exposición «Cómo determinar el tamaño óptimo del lote»). Es similar a la compra de huevos en el supermercado. Si compra una provisión para 12 meses en un solo viaje, su coste de transacción es bajo, pero la mayoría de los huevos se estropearán, lo que aumentará su coste de mantenimiento. Si compra una provisión de un día cada vez, su deterioro será bajo, pero sus costes de transacción serán altos. Intuitivamente, se intenta alcanzar un equilibrio entre ambos.

Las empresas que entienden cómo funciona esto han explotado los avances informáticos para reducir el tamaño de los lotes, a menudo con resultados sorprendentes. Algunas empresas de software que solían probar grandes lotes de código cada 90 días ahora prueban lotes mucho más pequeños varias veces al día. Un fabricante de periféricos informáticos que utilizó un enfoque similar con su grupo de software redujo el tiempo de ciclo en las pruebas de software en un 95% (de 48 meses a 2,5 meses), mejoró la eficiencia en un 220% y disminuyó los defectos en un 33%. El ahorro de costes fue el doble de lo que la empresa esperaba. Aunque esos resultados fueron excepcionales, hemos comprobado que la reducción del tamaño de los lotes mejora significativamente la mayoría de los proyectos de desarrollo. Del mismo modo, las herramientas informáticas de modelado y simulación han reducido drásticamente el tamaño óptimo de los lotes de experimentación y pruebas en las empresas que desarrollan productos físicos.

Falacia 3: Nuestro plan de desarrollo es genial; sólo tenemos que ceñirnos a él.

En todo nuestro trabajo de consultoría e investigación, nunca nos hemos encontrado con un solo proyecto de desarrollo de productos cuyos requisitos se mantuvieran estables a lo largo del proceso de diseño. Sin embargo, muchas organizaciones tienen una fe desmesurada en sus planes. Atribuyen las desviaciones a una mala gestión y ejecución y, para minimizarlas, hacen un seguimiento minucioso de cada paso con respecto a los objetivos e hitos intermedios. Esta forma de pensar está bien para actividades muy repetitivas en procesos de fabricación establecidos. Pero puede dar lugar a malos resultados en la innovación de productos, donde se generan nuevas ideas a diario y las condiciones cambian constantemente.

Un estudio clásico sobre la resolución de problemas técnicos realizado por Thomas Allen del MIT pone de manifiesto la naturaleza fluida del trabajo de desarrollo. Descubrió que los ingenieros que desarrollaban un subsistema aeroespacial concebían y evaluaban una serie de alternativas de diseño antes de seleccionar una que consideraban la mejor. Por el camino, sus preferencias cambiaban con frecuencia, a medida que probaban y perfeccionaban las soluciones técnicas que competían entre sí. Esto es típico en los proyectos de innovación: Las pruebas y la experimentación revelan lo que funciona y lo que no, y las suposiciones iniciales sobre los costes y el valor pueden ser desmentidas.

Definir las necesidades de los clientes también puede ser difícil al principio de un proyecto de desarrollo de productos. Si se piensa en ello, no es sorprendente: No es fácil que los clientes especifiquen con precisión sus necesidades para soluciones que aún no existen. De hecho, la familiaridad con los atributos de los productos existentes puede interferir en la capacidad de una persona para expresar su necesidad de un producto nuevo. Las preferencias de los clientes también pueden cambiar bruscamente durante el transcurso de un proyecto de desarrollo, a medida que los competidores introducen nuevas ofertas y surgen nuevas tendencias.

Por todas estas razones, ceñirse al plan original -por muy excelente que sea su concepción y por muy hábil que sea su ejecución- puede ser una receta para el desastre. Esto no quiere decir que no creamos en la planificación. El desarrollo de productos es un conjunto de actividades complejas que requieren una cuidadosa coordinación y atención al más mínimo detalle. Sin embargo, el plan debe tratarse como una hipótesis inicial que se revisa constantemente a medida que se desarrollan las pruebas, cambian los supuestos económicos y se reevalúa la oportunidad. (Véase «The Value Captor’s Process», de Rita Gunther McGrath y Thomas Keil, HBR mayo de 2007.)

Falacia 4: Cuanto antes se inicie el proyecto, antes se terminará.

Como ya hemos comentado, los tiempos muertos son un anatema para los directivos. Tienden a aprovechar cualquier tiempo muerto iniciando un nuevo proyecto. Incluso si la tarea no puede completarse porque la gente tiene que volver a otro proyecto, los gerentes razonan que todo lo que se logre en el nuevo proyecto es trabajo que no tendrá que hacerse más tarde. Esta forma de pensar lleva a las empresas a iniciar más proyectos de los que pueden perseguir enérgicamente, diluyendo los recursos.

Esta dilución es peligrosa. Si una empresa se embarca en un proyecto antes de tener los recursos necesarios para seguir adelante, se tropezará lentamente con el proceso de desarrollo. Eso es problemático porque el trabajo de desarrollo de productos es muy perecedero: Las suposiciones sobre las tecnologías y el mercado pueden quedar rápidamente obsoletas. Cuanto más lento avance un proyecto, mayor será la probabilidad de tener que reorientarlo. De hecho, una rama del ejército descubrió que sus excesos de costes y plazos eran exponencialmente proporcionales (a la cuarta potencia) a la duración de un proyecto. En otras palabras, cuando el cronograma original de un proyecto se duplicaba, los sobrecostes y los plazos se multiplicaban por 16.

La importancia de reducir la cantidad de trabajo en proceso se hace evidente cuando observamos una de las fórmulas clásicas de la teoría de colas: La Ley de Little. Simplemente establece que, en promedio, el tiempo de ciclo es proporcional al tamaño de la cola dividido por la tasa de procesamiento. Así, si hay 20 personas delante de usted en la cola de Starbucks y el camarero sirve a cinco personas por minuto, usted será atendido en cuatro minutos. Se puede acortar el tiempo del ciclo aumentando la tasa de procesamiento o reduciendo el número de trabajos en curso. En la mayorÃa de los entornos, esta última es la única opción práctica.

Para algunos desarrolladores de productos, la solución ha sido controlar rigurosamente el ritmo al que empiezan a trabajar. Lo hacen coincidir con el ritmo al que realmente se completa el trabajo; gestionan cuidadosamente el número de proyectos en proceso; se aseguran de que una vez que se lanza un proyecto, cuenta con el personal adecuado hasta que se completa; y resisten la tentación de robar recursos de un proyecto en curso para meter otros nuevos.

Falacia 5: Cuantas más características pongamos en un producto, más les gustará a los clientes.

Los equipos de desarrollo de productos parecen creer que añadir características crea valor para los clientes y restarlas destruye el valor. Esta actitud explica por qué los productos son tan complicados: Los mandos a distancia parecen imposibles de usar, los ordenadores tardan horas en configurarse, los coches tienen tantos interruptores y mandos que parecen cabinas de avión, e incluso la humilde tostadora viene ahora con un manual y pantallas LCD.

Las empresas que desafían la creencia de que más es mejor crean productos que son elegantes en su simplicidad. Bang & Olufsen, el fabricante danés de productos de audio, televisores y teléfonos, entiende que los clientes no quieren necesariamente toquetear el ecualizador, el balance y otros controles para encontrar la combinación óptima de ajustes para escuchar música. Sus altavoces de gama alta realizan automáticamente los ajustes necesarios para reproducir una canción con la mayor fidelidad posible al original. Lo único que queda para que los usuarios seleccionen es el volumen.

Conseguir que las empresas asuman y apliquen el principio de que menos puede ser más es difícil porque requiere un esfuerzo adicional en dos áreas del desarrollo de productos:

Definir el problema.

Articular el problema que los desarrolladores tratarán de resolver es la parte más infravalorada del proceso de innovación. Demasiadas empresas le dedican muy poco tiempo. Pero esta fase es importante porque es donde los equipos desarrollan una clara comprensión de cuáles son sus objetivos y generan hipótesis que pueden ser probadas y refinadas a través de experimentos. La calidad del planteamiento del problema marca la diferencia en la capacidad de un equipo para centrarse en las pocas características que realmente importan.

Cuando Walt Disney planificó Disneylandia, no se apresuró a añadir más características (atracciones, tipos de comida, cantidad de aparcamiento) que las que tenían otros parques de atracciones. Más bien, empezó por plantearse una pregunta mucho más amplia: ¿Cómo podía Disneylandia ofrecer a los visitantes una experiencia mágica? Sin duda, la respuesta no llegó de la noche a la mañana, sino que requirió una investigación minuciosa, una experimentación constante y un conocimiento profundo de lo que significaba «mágico» para Disney y sus clientes. IDEO y otras empresas tienen fases dedicadas en las que se sumergen completamente en el contexto en el que se utilizará el producto o servicio previsto. Sus desarrolladores leen todo lo interesante sobre los mercados, observan y entrevistan a los futuros usuarios, investigan las ofertas que competirán con el nuevo producto y sintetizan todo lo que han aprendido en imágenes, modelos y diagramas. El resultado es una visión profunda de los clientes que se pone a prueba, se mejora o se abandona a lo largo del proceso de desarrollo iterativo.

Determinar qué ocultar u omitir.

Los equipos suelen tener la tentación de presumir produciendo soluciones técnicas brillantes que asombran a sus compañeros y a la dirección. Pero a menudo los clientes prefieren un producto que simplemente funcione sin esfuerzo. Desde el punto de vista del cliente, las mejores soluciones resuelven un problema de la forma más sencilla y ocultan el trabajo del que los desarrolladores están tan orgullosos.

Una empresa que ha entendido esto es Apple. Es conocida por muchas cosas -productos innovadores, diseños elegantes y marketing inteligente-, pero quizá su mayor fortaleza sea su capacidad para llegar al corazón de un problema. (Véase «Las verdaderas lecciones de liderazgo de Steve Jobs», de Walter Isaacson, en nuestro número de abril). Como explicó una vez el difunto Steve Jobs: «Cuando empiezas a analizar un problema y parece realmente sencillo, no comprendes realmente la complejidad del problema. Y tus soluciones están demasiado simplificadas. Luego te metes en el problema y ves que es realmente complicado. Y se te ocurren todas estas soluciones enrevesadas ….. Ahí es donde la mayoría de la gente se detiene». Pero Apple no. Sigue trabajando. «La persona realmente genial seguirá adelante», dijo Jobs, «y encontrará… el principio clave subyacente del problema y dará con una solución hermosa y elegante que funcione».

Determinar qué características omitir es tan importante como -y quizás más- averiguar cuáles incluir. Por desgracia, muchas empresas, en un esfuerzo por ser innovadoras, lanzan todas las campanas y silbatos posibles sin considerar plenamente factores importantes como el valor para los clientes y la facilidad de uso. Cuando estas empresas omiten alguna funcionalidad prevista, suele ser porque necesitan recortar costes o se han retrasado en el calendario o porque el equipo ha fallado de alguna otra manera.