Desarrollar productos en tiempo de Internet

El auge de la World Wide Web ha creado uno de los entornos más desafiantes para el desarrollo de productos de la historia reciente. Las necesidades del mercado que un producto debe satisfacer y las tecnologías necesarias para satisfacerlas pueden cambiar radicalmente, incluso cuando el producto se encuentra en fase de desarrollo. En respuesta a estos factores, las empresas han tenido que modificar el proceso tradicional de desarrollo de productos, en el que la implementación del diseño comienza solo una vez que se ha determinado el concepto del producto en su totalidad. En cambio, han sido pioneros en un flexible proceso de desarrollo de productos que permite a los diseñadores seguir definiendo y dando forma a los productos incluso después de que se haya iniciado la implementación. Esta innovación permite a las empresas de Internet incorporar en sus diseños las necesidades de los clientes que cambian rápidamente y las tecnologías en evolución hasta el último momento posible antes de que un producto se introduzca en el mercado.

El desarrollo de productos flexibles se ha hecho realidad sobre todo en el entorno de Internet debido a las turbulencias que allí se encuentran, pero las bases para ello existen en una amplia gama de sectores en los que la necesidad de capacidad de respuesta es primordial. Los desarrolladores de productos de sectores, desde estaciones de trabajo informáticas hasta la banca, se enfrentan cada vez más a entornos dinámicos e impredecibles que se caracterizan por la rápida evolución de las tecnologías, los cambios en los gustos de los clientes y los cambios normativos radicales. En estos sectores, las empresas que han empezado a adoptar enfoques de desarrollo de productos más flexibles están estableciendo nuevos estándares de competencia.

¿Qué implica aumentar la flexibilidad del proceso de desarrollo del producto? Muchas de las empresas que estudiamos han adoptado un conjunto coherente de mecanismos que permiten a los desarrolladores de productos generar y responder a nueva información sobre lo que quieren los clientes y sobre la evolución de la tecnología a lo largo de un proyecto. Estos mecanismos no solo permiten un flujo continuo de información sobre las necesidades de los clientes y las nuevas tecnologías, sino que también reducen el coste y el tiempo que se tarda en integrar esa información en el diseño del producto, en evolución. Permiten a los diseñadores continuamente sentir necesidades del cliente, para probar soluciones técnicas alternativas y integrar los conocimientos adquiridos en un diseño de producto coherente. Este proceso flexible continúa de forma iterativa durante todo el proceso de desarrollo.

Los procesos de desarrollo tradicionales que utilizan muchas empresas están muy estructurados. Un producto futuro se diseña, desarrolla, transfiere a la producción y lanza al mercado en fases secuenciales y claramente articuladas. Estos procesos suelen empezar con la identificación de las necesidades de los usuarios y una evaluación de las distintas posibilidades tecnológicas. A continuación, se crea un conjunto detallado de especificaciones del producto y, una vez aprobadas por la alta dirección, queda grabado en piedra. En ese momento, la atención se centra en la implementación, ya que un equipo integrado funcionalmente traduce el concepto en realidad. Si el trabajo inicial se ha hecho correctamente, los cambios intrínsecamente costosos en las especificaciones del producto se reducen al mínimo. De hecho, el número de cambios de ingeniería se utiliza a menudo como medida de la eficacia de un proyecto: muchos cambios significan un esfuerzo inferior.

Por el contrario, el desarrollo flexible de productos retrasa hasta lo más tarde posible cualquier compromiso con una configuración de diseño final. Por lo tanto, la fase de desarrollo del concepto y la fase de implementación se superponen en lugar de seguirse secuencialmente. Al aceptar la necesidad de cambios y reducir el coste de los mismos, las empresas pueden responder a la nueva información que surge durante el desarrollo de un producto. Los cambios sistémicos en la definición y la dirección básica de un proyecto se gestionan de forma proactiva; los diseñadores comienzan este proceso sin una idea precisa de cómo acabará. (Consulte el gráfico «Dos enfoques del desarrollo de productos»).

Dos enfoques para el desarrollo de productos

La velocidad es un concepto sutil en este modelo. Plazo total de entrega —el tiempo necesario para cumplir los objetivos iniciales del proyecto— es claramente importante, pero

…

Hoy en día, un enfoque de desarrollo rígido y secuencial puede correr el riesgo de crear un producto obsoleto.

Cuando la tecnología, las características del producto y las condiciones competitivas son predecibles o evolucionan lentamente, un proceso de desarrollo tradicional funciona bien. Sin embargo, en entornos empresariales turbulentos, un enfoque secuencial del desarrollo de productos es más que ineficiente; se corre el riesgo de crear un producto obsoleto, uno que no satisfaga las necesidades de los clientes ni utilice las últimas tecnologías. Cuando es probable que aparezcan nuevos competidores y tecnologías de la noche a la mañana, cuando las normas y los reglamentos cambian y cuando toda la base de clientes de una empresa puede cambiarse fácilmente a otros proveedores, las empresas no necesitan un proceso de desarrollo que se resista al cambio, sino que lo acepte.

Un proceso flexible en el trabajo

No todas las empresas interesadas en desarrollar un proceso de desarrollo de productos flexible tendrían que ir a los extremos que hizo Netscape. Pero si analizamos las experiencias de Netscape, podemos ver cómo funciona un proceso altamente flexible. Fundada en 1994, la empresa fue pionera en el navegador web fácil de usar: una interfaz de software que proporciona acceso a la World Wide Web. El navegador web ha transformado Internet de un canal de comunicación para científicos y técnicos a una red que conecta a millones de usuarios comunes en el tiempo y el espacio y, por lo tanto, en una industria por derecho propio.

Pero Netscape no se enfrentó a una tarea fácil al desarrollar su navegador web, Navigator. En la rápida evolución del sector de Internet, muchas tecnologías y aplicaciones alternativas compiten por la atención, y el desarrollo de productos es la pesadilla de un director de proyectos. El principal desafío en el desarrollo de un navegador web es el nivel de complejidad técnica que implica: un programa típico compite en tamaño con una aplicación tradicional de procesamiento de textos u hojas de cálculo, y debe funcionar sin problemas con innumerables plataformas de hardware y software diferentes. El nivel de incertidumbre es tan alto que incluso las decisiones más básicas sobre un producto deben revisarse continuamente a medida que surja nueva información. Y el hecho de que el gigante del sector Microsoft, que ya había desarrollado su propio proceso flexible de desarrollo de productos, estuviera preparando un producto para competir con Navigator no hizo más que aumentar la complejidad y la urgencia del esfuerzo de desarrollo de Netscape.

Netscape lanzó Navigator 2.0 al mercado en enero de 1996 e inmediatamente después comenzó a desarrollar la siguiente versión del navegador web, Navigator 3.0, que se lanzaría en agosto del mismo año. (Consulte el gráfico «El desarrollo de Navigator 3.0: una cronología»). El grupo de desarrollo de Netscape, que incluía personal de ingeniería, marketing y atención al cliente, produjo el primer prototipo rápidamente. El 14 de febrero, apenas seis semanas después del inicio del proyecto, había publicado una versión beta 0 del programa en el sitio web interno de proyectos de la empresa para que el personal de desarrollo la probara. Aunque muchas de las funciones previstas aún no estaban disponibles, el prototipo capturó lo suficiente la esencia del nuevo producto como para generar comentarios significativos de los miembros del grupo de desarrollo. El 22 de febrero, menos de dos semanas después, el equipo presentó una versión actualizada, la beta 1, de nuevo solo para el personal de desarrollo interno. A principios de marzo, cuando se solucionaron algunos errores importantes en el producto, la primera versión pública, la beta 2, apareció en el sitio web de Internet de Netscape. A partir de entonces, se publicaron más lanzamientos públicos cada pocas semanas hasta la fecha oficial de lanzamiento en agosto, y aparecieron mejoras graduales en cada versión beta.

El desarrollo de Navigator 3.0: una cronología

La secuencia de las versiones beta le resultó muy útil a Netscape porque permitió al equipo de desarrollo reaccionar tanto a los comentarios de los usuarios como a los cambios en el mercado mientras el equipo seguía trabajando en el diseño del navegador web. Los usuarios de la versión beta, en general, son más sofisticados que la base de clientes más amplia de Netscape y, por lo tanto, son una valiosa fuente de información. Los más útiles son los desarrolladores de otras compañías de software de Internet, que suelen ser clientes muy vocales. Como muchos de estos clientes utilizan el navegador Navigator como parte del entorno en el que funcionan sus propios productos, suelen ser los primeros en encontrar los errores más complicados, errores que solo se revelan cuando el producto alcanza los límites de su rendimiento en aplicaciones complejas.

Recibir las opiniones de los usuarios fue una de las formas en las que el equipo de Navigator generó nueva información a lo largo del proyecto. Sin embargo, durante el ciclo de desarrollo de siete meses, el equipo también prestó especial atención a los productos de la competencia. Como el mayor y más poderoso desarrollador de software del sector, Microsoft era considerado una amenaza muy grave para la posición dominante de Netscape en aquel entonces en el mercado de los navegadores. El gigante del software acababa de dar un cambio de estrategia drástico y muy público, al volver a centrar sus formidables talentos directamente en Internet. Como resultado, Netscape supervisaba continuamente las últimas versiones beta del producto de la competencia de Microsoft, Explorer, para comparar funciones y formatos. Según la información recopilada, el equipo de Netscape añadía a menudo cambios de formato o funciones a la versión beta actual de su propio producto.

Para responder al flujo constante de nueva información que se incorporaba al proceso de desarrollo, el equipo llevó a cabo exhaustivos experimentos y pruebas. Los subgrupos que trabajaban en funciones individuales pasaron por numerosos ciclos de diseño, construcción y pruebas, añadiendo gradualmente funciones al producto. A medida que se fueron completando las funciones, el equipo las integró en el producto en evolución y, a continuación, realizó pruebas para garantizar que la nueva función no producía interacciones no deseadas con otras partes del sistema. Las denominadas compilaciones del sistema se producían con una frecuencia cada vez mayor a medida que avanzaba el proyecto; se realizaron al menos a diario antes del lanzamiento oficial.

Para facilitar la integración de las enormes cantidades de información generadas durante el proyecto, Netscape creó un sitio web del proyecto en su intranet. El sitio contenía el calendario de desarrollo y las especificaciones del producto, cada una de las cuales se actualizaba a medida que cambiaban las fechas límite o se añadían nuevas funciones. Además, contenía tablones de anuncios a través de los cuales los miembros del equipo podían supervisar la evolución de varias partes del diseño y observar la finalización de funciones específicas y registrar los problemas de la versión existente. Cuando Navigator pasó a las pruebas beta públicas, estas funciones de la intranet se hicieron especialmente valiosas porque entonces había que recibir, clasificar y procesar una cantidad cada vez mayor de información.

Netscape incorporó a su proceso de desarrollo de productos una flexibilidad considerable para responder a los cambios en las demandas del mercado y la tecnología. Y lo que ya es cierto para las empresas de la industria de Internet está pasando a ser cierto para las empresas de otros lugares. Nuestra investigación sobre el sector de ordenadores, estaciones de trabajo y servidores ha demostrado que allí, también, un proceso más flexible se asocia a un mayor rendimiento. En este entorno, las empresas con un tiempo de respuesta más rápido, medido desde la construcción del primer prototipo físico hasta el transporte comercial, superan claramente a las que tienen tiempos de respuesta más lentos. El uso de sofisticadas herramientas de simulación permite a los equipos trabajar con un prototipo virtual durante gran parte del proyecto; de hecho, se crea una superposición significativa entre las fases del concepto y de implementación del diseño.

Según Allen Ward y sus colegas en «La segunda paradoja de los Toyota: cómo retrasar las decisiones puede hacer que los coches mejores sean más rápidos» ( Revisión de la gestión de Sloan, Primavera de 1995), también hay pruebas de que ha surgido un modelo más flexible en la industria de la automoción. El proceso de desarrollo de Toyota le permite retrasar muchas decisiones de diseño hasta más adelante en el ciclo de desarrollo. El equipo de desarrollo crea varios conjuntos de opciones de diseño y, por último, mediante un proceso de eliminación, selecciona solo una para su implementación. Como resultado, Toyota puede responder a las condiciones cambiantes del mercado en una etapa posterior que muchos de sus competidores.

Las bases de un proceso flexible

¿Cómo deberían las empresas crear un proceso de desarrollo flexible? Las experiencias de las principales empresas sugieren que los altos directivos primero deben entender qué es lo que da flexibilidad al proceso. La flexibilidad del desarrollo de productos se basa en la capacidad de gestionar conjuntamente la evolución de un producto y su contexto de aplicación. El objetivo es captar una comprensión profunda de las necesidades de los clientes y las soluciones técnicas alternativas a medida que avanza el proyecto, y luego integrar esos conocimientos en el diseño del producto, en evolución. Cuanto más rápido un proyecto integre esa información, más rápido podrá responder el proyecto a los cambios en el entorno del producto.

Sin embargo, el valor del desarrollo flexible de productos solo es tan bueno como la calidad del proceso que utiliza para generar información sobre la interacción entre las opciones técnicas y las exigencias del mercado. A diferencia de los proyectos de desarrollo tradicionales, que se basan en ráfagas periódicas de información sobre las necesidades de los usuarios, los proyectos en entornos empresariales turbulentos requieren comentarios continuos. Para adquirir y utilizar esta información, el proceso de desarrollo debe ser capaz de detectar las necesidades de los clientes, probar soluciones técnicas alternativas e integrar los conocimientos adquiridos en los mercados y las tecnologías en un producto coherente. (Consulte el gráfico «La estructura de un proceso flexible de desarrollo de productos».)

La estructura de un proceso flexible de desarrollo de productos

A medida que describimos cómo las principales empresas han logrado un proceso de desarrollo más flexible, muchos de los ejemplos que citamos provienen de nuestro trabajo con varias empresas de software que han lanzado recientemente productos o servicios de Internet. Pero tenga en cuenta que este no es el único sector en el que se aplican estas lecciones. También describimos prácticas específicas de otros sectores más tradicionales para ilustrar que los enfoques utilizados no son exclusivos de Internet. De hecho, representan una práctica de vanguardia en una variedad de entornos en los que el cambio es (o se está convirtiendo) en la norma.

Detectar el mercado.

El primer elemento de un proceso flexible es detectar las necesidades de los clientes y del mercado. Los proyectos flexibles establecen mecanismos para recibir comentarios continuos del mercado sobre la forma en que el diseño en evolución cumple con los requisitos de los clientes. Lo hacen mediante la creación de vínculos intensivos con la base de clientes, enlaces que van desde una amplia experimentación con muchos clientes hasta experiencias selectivas con algunos usuarios principales. Además, estos clientes no tienen por qué ser ajenos a la empresa: las principales empresas utilizan ampliamente el personal y los recursos internos para ofrecer un banco de pruebas para la evolución de nuevos productos.

Recibir comentarios continuos de los clientes era especialmente importante en Netscape debido a su dramática carrera cara a cara con Microsoft. El lanzamiento generalizado de varias versiones beta por parte de Netscape para toda su base de clientes permitió a los usuarios desempeñar un papel importante en la evolución del diseño del producto. Al mismo tiempo, permitió a Netscape probar un producto técnico extremadamente complejo. Aunque no todos los clientes de Netscape experimentaron realmente con las versiones beta, los usuarios más avanzados del navegador web tuvieron que hacerlo porque ellos mismos creaban productos que tenían que funcionar sin problemas con la versión Navigator. Y sus comentarios claramente tuvieron un impacto: una parte importante del nuevo código, funciones y tecnología que se integraron en la nueva versión se desarrolló solo después de que la primera versión beta saliera a bolsa.

Microsoft, el principal rival de Netscape, tardó en reconocer las oportunidades que ofrecía la World Wide Web. La empresa no empezó a centrarse en el desarrollo de productos de Internet hasta finales de 1995. Sin embargo, cuando Bill Gates y el resto del equipo de alta dirección finalmente reconocieron la necesidad de un cambio estratégico, la experiencia en desarrollo de Microsoft se dio rienda suelta a una velocidad asombrosa. En los seis meses transcurridos desde finales de 1995 hasta mediados de 1996, la empresa pasó de no tener presencia en el mercado crítico de los navegadores a ofrecer un producto que, según varios expertos del sector, era comparable o mejor que el Navigator de Netscape.

Microsoft pudo reaccionar con rapidez porque su proceso de desarrollo de productos actual se basaba en la rápida iteración de prototipos, las primeras versiones beta y un enfoque flexible de la arquitectura y las especificaciones de los productos. (Para obtener una descripción detallada del proceso de desarrollo de Microsoft, consulte Michael A. Cusumano y Richard W. Selby, Secretos de Microsoft [Prensa libre, 1995].) El proceso que siguió Microsoft para desarrollar su Internet Explorer fue similar al de Netscape, pero tenía una orientación más interna. Con más de 18 000 empleados frente a los 1000 de Netscape en ese momento, Microsoft podría probar exhaustivamente las sucesivas versiones beta de Explorer con solo colocarlas en su propia intranet. «Animamos a todos los miembros de Microsoft a jugar con él», explicó un director de programas de Microsoft. «Las pruebas internas significan que lo publicamos a miles de personas que realmente lo hacen. Usamos el producto mucho más que el usuario medio de Internet». Microsoft combinó amplias pruebas internas realizadas por los empleados con versiones beta externas cuidadosamente organizadas, utilizando solo dos o tres, a diferencia de las seis o siete de Netscape. Así, la empresa limitó el riesgo de que las imperfecciones de las primeras versiones pudieran dañar su reputación.

Se puede utilizar una filosofía flexible similar en el desarrollo de los servicios. Pensemos en Yahoo!. Fundada en 1995, la empresa ofrece servicios de búsqueda, directorio y programación para navegar por la World Wide Web. Como proveedor de servicios, la empresa cree que antes de lanzar una nueva oferta al mundo exterior, tiene que ser más sólida que la típica versión beta de un software de Internet. El riesgo de mercado de las pruebas públicas y generalizadas es demasiado alto: los usuarios que prueban un nuevo servicio una vez y tienen una experiencia insatisfactoria con él es poco probable que regresen o, lo que es peor, pueden desertar a la competencia. Además, Yahoo! supone que las empresas de la competencia copiarán las funciones innovadoras de un nuevo servicio una vez que se publique. Estos factores sugieren retrasar las pruebas externas hasta finales del ciclo de desarrollo.

Por estas razones, Yahoo! publica las primeras versiones de los nuevos servicios en línea únicamente para uso interno. Dadas las habilidades técnicas y la amplia experiencia de su equipo de desarrollo, estas pruebas revelan cualquier defecto técnico importante del servicio y ofrecen sugerencias adicionales para mejorar la funcionalidad. Solo entonces Yahoo! iniciar una «versión provisional» de la oferta: ¡el servicio se publica en Yahoo! ’ sitio web, pero sin ningún enlace a las partes más frecuentadas del sitio. Como resultado, solo los usuarios más agresivos desde el punto de vista técnico es probable que encuentren y utilicen el servicio en este momento. ¡Yahoo! también pide a algunos de los 30 000 usuarios, que se han ofrecido como voluntarios para hacer pruebas beta, que prueben el nuevo servicio, lo que lo expone a rigurosas pruebas externas sin revelarlo a usuarios poco sofisticados que podrían sentirse frustrados por una versión lenta, incompleta o plagada de errores.

El Netscape, Yahoo! y los ejemplos de Microsoft ilustran varios enfoques para detectar las necesidades de los clientes y el mercado: amplias pruebas con consumidores, amplias pruebas internas y pruebas realizadas por los usuarios principales. Las empresas que adopten un enfoque de desarrollo flexible deberían tener en cuenta las ventajas de cada uno de ellos, así como la posibilidad de utilizar una combinación equilibrada de todos ellos. Sin embargo, es importante hacer hincapié en que estas técnicas no son exclusivas de Internet. Los avances en la tecnología de la información permiten ahora a las empresas detectar las necesidades de los clientes de formas que no eran posibles hace unos años. Las principales empresas de muchos sectores han empezado a utilizar estas nuevas capacidades.

Fiat, por ejemplo, utilizó un enfoque amplio de pruebas externas, similar al de Netscape, para evaluar varios conceptos de automóviles. Un enlace en el sitio web de la empresa dirigía a los clientes a una página destinada a evaluar las necesidades de los usuarios para la próxima generación del Fiat Punto, su coche de mayor volumen, que vende unas 600 000 unidades al año. Se pidió a los clientes que rellenaran una encuesta en la que indicaran sus preferencias en cuanto al diseño de automóviles. Podrían priorizar las cinco consideraciones siguientes: estilo, comodidad, rendimiento, precio y seguridad. Luego se les pidió que describieran lo que más odiaban de un coche y que le sugirieran ideas para nuevas funciones. Luego, el software permitía a los clientes diseñar un coche ellos mismos. Podrían elegir entre una variedad de estilos de carrocería, diseños de ruedas y estilos para la parte delantera y trasera del automóvil. También podrían examinar diferentes tipos de faros, detalles y características. De esta forma, los usuarios podían experimentar con diferentes diseños y ver los resultados inmediatamente en la pantalla. El software capturó los resultados finales y, además, trazó la secuencia que siguieron los clientes al evaluar y seleccionar las opciones. Esta información dio a los diseñadores mucha información sobre la lógica que utilizaban los clientes para evaluar los rasgos, estilos y características con el fin de llegar a una solución de diseño determinada.

Fiat recibió más de 3000 encuestas en un período de tres meses, cada una con unas diez páginas de información detallada. Las ideas sugeridas iban desde inteligentes (un paragüero dentro del coche) hasta importantes (un asiento delantero con un solo banco). Fiat utilizó la información para tomar diversas decisiones de estilo y concepto para el Punto de próxima generación. Y el coste total del ejercicio fue de solo$ 35 000, aproximadamente el coste de organizar unos cuantos grupos focales. Además, los ejecutivos de Fiat afirmaron que las encuestas les proporcionaron exactamente los datos que necesitaban. El perfil de los participantes de la encuesta (personas que marcan tendencias con ingresos altos, que tienen entre 31 y 40 años y que compran coches con frecuencia) fue el segmento objetivo más útil para Fiat.

La división Electro-Motive de General Motors ha adoptado una filosofía similar en su nuevo proceso de desarrollo de productos virtuales. Ese proceso permite a los ingenieros ofrecer a los clientes visitas digitales por las locomotoras de la próxima generación, incluso a medida que avanza su desarrollo. Aunque el sistema GM sigue evolucionando, el objetivo es pasar a un entorno totalmente digital en el que el producto se mueva electrónicamente mediante el diseño conceptual, el análisis, la creación de prototipos y la fabricación y, a lo largo del camino, haga varias paradas en el escritorio del cliente para recibir comentarios.

Probando soluciones técnicas.

Detectar las necesidades de los clientes y del mercado a medida que avanza un proyecto es un elemento de un proceso de desarrollo flexible. Sin embargo, si las empresas quieren permitir que el diseño de un producto evolucione hasta bien entrada la fase de diseño e implementación, también deben adoptar mecanismos que reduzcan el coste de los cambios, aceleren su implementación y pongan a prueba su impacto en el sistema en general. Estos mecanismos permiten a las empresas evaluar y probar soluciones técnicas alternativas a un ritmo rápido: el segundo elemento de un proceso de desarrollo flexible.

Los primeros prototipos y pruebas de tecnologías alternativas son fundamentales para establecer la dirección de un proyecto. Pensemos en NetDynamics, una empresa que desarrolla herramientas sofisticadas para vincular servidores web a bases de datos de gran tamaño. La decisión técnica más importante a la que se enfrentó NetDynamics durante el desarrollo de su segunda versión de producto fue la elección temprana del idioma de su producto. O la empresa podría desarrollar un lenguaje propietario o podría usar Java. En esa época, a principios de 1996, el lenguaje de programación Java había recibido mucha publicidad, pero seguía siendo muy inestable, relativamente inmaduro y se entendía poco. «Sabíamos que Java iba a triunfar», recuerda el ingeniero jefe Yarden Malka, «pero solo estaba disponible en la versión beta 1. Esto significaba que las herramientas de desarrollo que lo acompañaban tenían muchos errores o no existían. Si lo elegimos, sabíamos que también teníamos que desarrollar muchas de nuestras propias herramientas».

El compromiso de NetDynamics con una plataforma abierta tendió a favorecer a Java. Si hubiera un estándar, existente o emergente, debería usarse, y Java parecía ser ese estándar. Sin embargo, para tomar la decisión, los ingenieros de NetDynamics dedicaron un tiempo considerable a experimentar con varias opciones, intentando familiarizarse lo más posible con las ventajas y los riesgos de cada idioma. Empezaron desarrollando prototipos sencillos y, poco a poco, migraron a programas más complejos, intentando evaluar las ventajas que cada uno ofrecería al usuario. Este enfoque «centrado en el usuario» de la creación de prototipos y la experimentación fue fundamental para la elección final y contrasta marcadamente con el enfoque que suelen adoptar las empresas de alta tecnología, en el que las tecnologías suelen evaluarse únicamente en función de las ventajas que ofrecen al equipo de diseño.

A medida que avanza un proyecto, el equipo de diseño debe tener la capacidad de evaluar y probar soluciones de diseño alternativas de forma rápida y económica. ¡Yahoo! puede hacerlo fácilmente por la forma en que ha elegido ofrecer su servicio de Internet. La empresa satisface sus necesidades de procesamiento con muchos ordenadores baratos en lugar de unos cuantos servidores grandes (y caros). La pequeña inversión necesaria para cada máquina permite a Yahoo! para ampliar su capacidad sin problemas y satisfacer la nueva demanda. También significa que Yahoo! puede realizar experimentos fácilmente para probar diferentes opciones de diseño. Según Farzad Nazem, vicepresidente de ingeniería, «la configuración de nuestro sitio web funciona igual que una válvula de grifo. Si queremos probar un nuevo producto o función con varios miles de usuarios, lo promocionamos solo en la página de inicio de unas pocas máquinas. A medida que los usuarios accedan al servicio y alcancemos el volumen requerido, podemos desactivar la promoción en cada máquina. También podemos realizar experimentos comparativos ejecutando varias versiones del mismo servicio en diferentes ordenadores de la red y, a continuación, hacer un seguimiento de los resultados para ver qué versión atrae a más clientes».

Para reducir el coste de probar opciones de diseño alternativas, empresas ajenas a la industria del software invierten cada vez más en nuevas tecnologías para el diseño virtual. Al diseñar y probar los diseños de los productos mediante la simulación, por ejemplo, las empresas obtienen la flexibilidad necesaria para responder a la nueva información y resolver las incertidumbres mediante la exploración rápida de alternativas. El software de diseño asistido por ordenador también ha reducido drásticamente el coste de los cambios de diseño y, al mismo tiempo, ha acelerado la experimentación. En Boeing, por ejemplo, el desarrollo totalmente digital del avión 777 utilizó a un «humano» generado por ordenador que se metía dentro del diseño tridimensional de la pantalla para mostrar lo difícil que sería el acceso al mantenimiento para un mecánico en vivo. Estos modelos informáticos permitían a los ingenieros detectar errores de diseño (por ejemplo, una luz de navegación que habría sido difícil de reparar) que, de otro modo, habrían permanecido sin descubrir hasta que una persona negociara un prototipo físico. Al evitar el tiempo y los costes asociados a la construcción de prototipos físicos en varias etapas, el proceso de desarrollo de Boeing ha adquirido la flexibilidad de evaluar una gama de opciones de diseño más amplia de lo que era posible antes.

Integrar las necesidades de los clientes con las soluciones técnicas.

No sirve de nada saber lo que los clientes quieren en un producto en desarrollo si el equipo de desarrollo no puede integrar esa información con las soluciones técnicas disponibles. Como resultado, todas las organizaciones de las que hablamos han establecido mecanismos de integración dinámicos. Algunas de ellas se basan en conceptos bien entendidos, como el uso de equipos dedicados, un enfoque adoptado por Netscape, NetDynamics y Microsoft. Otros son menos tradicionales. Las tres empresas, por ejemplo, utilizan sus intranets para integrar las tareas, sincronizar los cambios de diseño y recopilar la información de los clientes a medida que los proyectos evolucionan. De este modo, los equipos de proyectos pueden realizar un seguimiento de la evolución de las relaciones entre las tareas, los cronogramas y los cambios de diseño de forma dinámica. Estos mecanismos de integración son esenciales para gestionar un proceso flexible, dadas las numerosas rondas de experimentación y la amplia gama de información que se genera. Sin una forma de captar e integrar el conocimiento, el proceso de desarrollo puede convertirse rápidamente en un caos, ya que los cambios de diseño ad hoc generan una gran cantidad de retrabajos debido a interacciones imprevistas con otros componentes del sistema.

En el mundo de Internet, los mecanismos de integración los dicta la naturaleza del producto: el software. Cada uno de los proyectos que describimos adoptó sofisticadas herramientas de integración del diseño para guardar la versión maestra del producto emergente. Cuando los miembros del equipo se pusieron a trabajar en los componentes individuales, comprobaron el código de esa parte del sistema. Cuando terminaron, tuvieron que realizar una serie de pruebas para asegurarse de que el componente no creaba interacciones problemáticas con el resto del sistema. Solo entonces podrían comprobar el nuevo componente. Al final de cada día, cuando se habían registrado todos los componentes nuevos, los ingenieros ejecutaban el programa. Había que corregir cualquier problema que se produjera antes de poder integrar el nuevo código de forma permanente.

Se encuentran enfoques similares en proyectos fuera del mundo de Internet, donde los nuevos sistemas de información permiten a las empresas compartir conocimientos de forma más eficaz. En Silicon Graphics, uno de los principales fabricantes de estaciones de trabajo y servidores, un nuevo proceso de introducción de productos utiliza ampliamente la intranet de la empresa para coordinar las actividades de desarrollo. Los gerentes e ingenieros de todo el mundo, que responden a diario a los problemas de los clientes actuales, aportan su opinión durante la fase de generación del concepto. Además, los usuarios principales de los segmentos de aplicaciones objetivo (denominados clientes «faro») están vinculados directamente con los equipos de desarrollo, lo que permite a los equipos obtener una orientación rápida y eficaz sobre las decisiones críticas a medida que el proyecto evoluciona. La intranet también se utiliza para integrar las tareas de diseño a diario. Los ingenieros de proyectos trabajan a partir de un conjunto de software compartido que simula el diseño del hardware. Al igual que en los proyectos de Internet, cuando los miembros del equipo quieren hacer un cambio, comprueban el código correspondiente, realizan las mejoras de diseño deseadas, lo comprueban para detectar errores e interacciones imprevistas y, a continuación, lo vuelven a comprobar.

Estos enfoques no se limitan a los productos de alta tecnología. Booz Allen & Hamilton, una consultora de gestión, aborda el problema de integrar una base de conocimientos diversa y dispersa geográficamente mediante su intranet. La intranet permite al personal consultor localizar y ponerse en contacto rápidamente con expertos del sector con habilidades específicas e identificar estudios anteriores que sean relevantes para los proyectos actuales. De esta forma, la experiencia colectiva de la organización está disponible para todos los empleados en línea. La intranet también permite a la empresa desarrollar su capital intelectual. En la consultoría de gestión, el desarrollo de nuevos productos consiste en desarrollar nuevos marcos, mejores prácticas del sector, puntos de referencia de rendimiento y otra información que se pueda aplicar en todos los proyectos. Al tener estos productos en línea durante el desarrollo y posteriormente, Booz Allen puede integrar nueva información y experiencias en su base de conocimientos.

Sin embargo, integrarse en la empresa no siempre es suficiente. En algunos casos, la capacidad de integrar los conocimientos en las redes de organizaciones también puede ser importante. Para las empresas de software de Internet, dada la novedad y la complejidad inherentes a sus productos y la rapidez de sus ciclos de desarrollo, ninguna organización puede investigar, crear y comercializar productos por sí sola. En cambio, aprovechan las posibilidades técnicas que van más allá de los límites de cualquier empresa individual; esas tecnologías se pueden integrar en sus propios productos principales. (Los usuarios de Internet estarán familiarizados con los applets de Java y los complementos de los navegadores web). Sin embargo, hacerlo significa que, así como las tecnologías deben integrarse sin problemas en un producto, la organización también debe adaptarse a un elenco cambiante de actores. Las empresas que describimos han creado alianzas con desarrolladores de terceros, han participado en proyectos de desarrollo conjuntos y se han esforzado por fomentar arquitecturas de productos abiertas y diseños modulares. Y esas disposiciones no son exclusivas del software. Los fabricantes de estaciones de trabajo como Sun, Hewlett-Packard y Silicon Graphics suelen realizar esfuerzos de desarrollo conjuntos con otras empresas de hardware (como Siemens, Intel, Fujitsu, Toshiba y NEC) para aprovechar el rendimiento de sus sistemas.

Poner a prueba la flexibilidad

En conjunto, las bases de un proceso flexible de desarrollo de productos permiten a la empresa responder a los cambios en los mercados y las tecnologías durante el ciclo de desarrollo. Hemos encontrado un ejemplo sorprendente de cómo eso se hace en un entorno que está lo más lejos posible del típico mundo de la alta tecnología: la Copa América. En 1995, un pequeño equipo de Nueva Zelanda dominó las carreras de principio a fin. El esfuerzo del equipo de Nueva Zelanda demuestra cómo los mecanismos que hemos descrito se pueden combinar para lograr un efecto drástico en un proceso flexible.

Un enfoque flexible permite a las empresas responder a los cambios en los mercados y las tecnologías durante el ciclo de desarrollo.

El equipo de Nueva Zelanda reclutó a Doug Peterson, que había formado parte del equipo ganador de la Copa América en 1992, como diseñador principal. También reclutó a un equipo de simulación experimentado para utilizar un software de diseño avanzado. Aunque la amplia experiencia de Peterson impulsó el diseño conceptual inicial, una vez que se construyeron los yates del equipo, el énfasis pasó a centrarse en evaluar los cambios de diseño mediante miles de iteraciones de diseño simuladas por ordenador. Las simulaciones se realizaron en una pequeña red de estaciones de trabajo ubicadas a pocos metros del muelle. Para garantizar una rápida retroalimentación sobre el rendimiento de los cambios de diseño, el equipo construyó dos barcos. Cada día, a uno de ellos se le hacía un cambio de diseño para evaluarlo; luego, los dos barcos competían entre sí para evaluar el impacto del cambio.

El flexible proceso del equipo neozelandés detectó las «necesidades del mercado» a través del programa de pruebas para dos barcos, que generaba comentarios cada día sobre cómo el diseño en evolución se adaptaba al entorno de las carreras. Probó diseños alternativos a través de un programa de simulación dirigido por uno de los diseñadores de yates más experimentados del mundo. E integró el conocimiento al hacer que la información resultante estuviera disponible localmente. Por lo tanto, la tripulación, el equipo de diseño y la dirección pudieron hacer sugerencias para el diseño, ver el impacto de los posibles cambios y saber qué esperar cuando esos cambios se probaran en el agua.

El barco estadounidense al que se enfrentó el equipo de Nueva Zelanda en la última regata había sido diseñado con los últimos superordenadores con el apoyo de grandes y adineradas corporaciones. Aunque el equipo estadounidense pudo probar una enorme cantidad de diseños experimentales, los ordenadores estaban ubicados a cientos de kilómetros del muelle. Como resultado, hubo retrasos importantes entre la presentación de detalles de un diseño y la recepción de comentarios sobre los resultados. Además, el equipo solo tenía un barco en el que probar los cambios de diseño; dadas las diferentes condiciones del mar y el viento, tardó mucho más que su rival en comprobar el impacto de un cambio.

El enfoque del equipo de Nueva Zelanda tenía mejores mecanismos que su rival estadounidense para detectar, probar e integrar lo que había aprendido. Su proceso flexible creó un yate de diseño superior, que muchos observadores creían que estaba una generación por delante de los barcos de la competencia. Como comentó Paul Cayard, patrón del oponente del equipo neozelandés en la última carrera: «He librado algunas batallas cuesta arriba en mi vida. Pero nunca había participado en una carrera en la que sintiera que tenía tan poco control sobre el resultado. Es la mayor discrepancia en la velocidad del barco que he visto en mi vida».

Mediante un proceso de desarrollo flexible, el equipo de Nueva Zelanda creó un yate superior y derrotó a su oponente estadounidense.

Hemos visto un patrón similar en muchos de los entornos que hemos estudiado. Las organizaciones que han adoptado un proceso de desarrollo de productos flexible han empezado a transformar los mismos sectores que las obligaron a adoptarlo. Han implementado estrategias que las empresas que se aferran a los enfoques tradicionales no pueden seguir. Es casi seguro que los competidores sin procesos de desarrollo flexibles descubrirán que sus industrias crecen cada vez más turbulentas en apariencia. Y en un entorno así, sus productos y servicios siempre parecen estar un paso por detrás de los de sus rivales más flexibles.