Proceso de desarrollo de producto (plantilla stage-gate)

¿Qué es proceso de desarrollo de producto (plantilla stage-gate)?

Un proceso de desarrollo de producto convierte un flujo de ideas en un número pequeño de productos lanzados, y el trabajo que hace es sobre todo de resta. Cualquier organización sabe generar conceptos; la disciplina está en decidir cuáles se paran, y pararlos lo bastante pronto como para que el dinero no esté ya gastado. Para eso sirve una estructura de fases y puertas (stage-gate). El trabajo se agrupa en fases, cada fase termina en una puerta, y una puerta solo es una puerta si puede decir que no. Sin rama de cancelación no tienes una puerta, tienes una reunión de seguimiento: los proyectos llegan con inercia, nadie quiere ser quien mata uno, y la cartera se llena en silencio de programas medio vivos que consumen capacidad de ingeniería sin llegar nunca a una decisión de lanzamiento.

Esta página mapea el ciclo completo, de la idea a la revisión poslanzamiento, para un equipo de producto multifuncional. Su alcance es a propósito más amplio que el de tres plantillas vecinas. No es el proceso de release de software de /es/templates/proceso-de-release-de-software, que arranca en una build ya cerrada y termina en la monitorización en producción, y tampoco es el árbol de decisión go/no-go, que se mete de lleno en la puerta de preparación para el lanzamiento y la despliega en una docena de preguntas de evidencia. Si tu producto ya está lanzado y lo que gestionas son modificaciones sobre él, el proceso que buscas es el control de cambios en /es/templates/proceso-de-control-de-cambios. Aquí la puerta de lanzamiento es un solo nodo con tres ramas; todo lo anterior, desde el filtrado de la idea hasta un piloto de producción limitado, es la sustancia del diagrama.

La plantilla recorre veinte pasos en cinco carriles (Gestión de producto, Ingeniería / I+D, Diseño, Calidad y Comercial) repartidos en cinco fases: Idea y filtrado, Caso de negocio, Diseño y desarrollo, Validación, y Lanzamiento y revisión. Incluye los bucles que la mayoría de las versiones dibujadas se dejan fuera: una rama de reciclaje que devuelve un caso de negocio flojo para rehacerlo en lugar de cancelarlo, una revisión de diseño no superada que vuelve al diseño de detalle, una decisión «¿Cumple los requisitos?» que devuelve la validación fallida al diseño en vez de dejarla pasar al piloto, y una rama de ampliar el piloto en la puerta 2 para un producto que está casi listo pero todavía no.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles funcionales (Gestión de producto, Ingeniería / I+D, Diseño, Calidad y Comercial) repartidos en cinco fases: Idea y filtrado, Caso de negocio, Diseño y desarrollo, Validación, y Lanzamiento y revisión
• Un filtro antes de gastar nada: la idea se registra en el pipeline y se filtra frente a la estrategia en el carril de Gestión de producto, para descartar los conceptos flojos antes de pedir esfuerzo a cuatro funciones
• Cuatro entradas independientes al caso de negocio, una por función: la viabilidad técnica desde Ingeniería / I+D, el concepto de producto desde Diseño, los requisitos regulatorios desde Calidad y el dimensionamiento de mercado desde Comercial, todas confluyendo en «Elaborar el caso de negocio»
• La puerta 1 con tres salidas con nombre: «Puerta 1: ¿desarrollar o cancelar?» ramifica en Adelante hacia los requisitos y la especificación, Reciclar de vuelta al caso de negocio para rehacerlo, y Cancelar hacia «Idea archivada con su justificación» como final de rechazo
• Dos bucles de retrabajo distintos que vuelven a «Desarrollar el diseño de detalle»: «¿Se supera la revisión de diseño?» regresa por Rehacer antes de intentar la validación, y «¿Cumple los requisitos?» regresa por No después de los ensayos, de modo que un ensayo fallido nunca se cuela en el piloto
• La puerta 2 como decisión de lanzamiento: «Puerta 2: ¿se aprueba el lanzamiento?» ramifica en Lanzar al mercado dentro del carril Comercial, Ampliar piloto de vuelta al piloto de producción limitado, y Cancelar hacia «Lanzamiento detenido en la puerta 2», con una revisión poslanzamiento y el cierre como final del flujo

Cuándo usar esta plantilla

• Vais a implantar por primera vez un proceso de fases y puertas y necesitáis una única imagen acordada de las fases, las puertas y quién es dueño de cada una, antes de que se convierta en un paquete de plantillas y una tanda de convocatorias
• Los proyectos de vuestra cartera no paran nunca: no se cancela nada formalmente, la capacidad se reparte entre demasiados programas vivos y nadie puede señalar la decisión que autorizó cada uno
• Se empieza a desarrollar antes de que exista el caso de negocio, o la especificación se escribe después del diseño, y hace falta enseñar el orden previsto a quien hace el trabajo
• Estáis alineando el proceso con un sistema de gestión de la calidad (la ISO 9001 trata el diseño y desarrollo en el apartado 8.3 y espera que la planificación, las revisiones, la verificación y la validación se realicen y se registren) y necesitáis el flujo antes de redactar el procedimiento
• Los traspasos entre producto, ingeniería, diseño, calidad y comercial son el cuello de botella real, y queréis ver qué función retiene el trabajo en cada fase en lugar de discutirlo después de una fecha de lanzamiento incumplida

Cómo funciona

1. Renombra los carriles con tus funciones reales

   Sustituye Gestión de producto, Ingeniería / I+D, Diseño, Calidad y Comercial por las funciones que realmente tienes. Los equipos de hardware suelen partir Ingeniería en mecánica, electrónica e ingeniería de fabricación; los equipos de software a menudo no tienen un carril de Calidad separado y deberían plegar la validación dentro de ingeniería en vez de dejar una banda vacía. Fusiona cualquier carril al que no puedas poner un responsable con nombre y apellidos, y limita el número de carriles a lo que quepa en una pantalla.

2. Escribe los criterios de la puerta antes de la primera revisión

   Una puerta sin criterios escritos se convierte en una presentación. Para la puerta 1, indica qué debe contener el caso de negocio y qué umbrales lo convierten en un Adelante: el tamaño de mercado que consideráis que merece la pena, las preguntas de viabilidad que hay que responder en vez de suponer y el alcance regulatorio. Para la puerta 2, indica qué evidencia del piloto se exige. Acordad ambos mientras no haya nada esperando en la puerta, porque los criterios negociados el mismo día los escribe quien más interés tiene en un Adelante.

3. Decide qué significan de verdad Reciclar y Ampliar piloto

   Las dos ramas blandas son por donde se pudren los procesos de fases y puertas. Reciclar en la puerta 1 debe llevar una lista concreta de qué tiene que cambiar, un responsable y una fecha de vuelta; si no, es una cancelación que nadie quiso decir en voz alta. Ampliar piloto en la puerta 2 debe nombrar qué se está aprendiendo, cuánto dura la ampliación y qué criterio la termina. Registra ambas contra el proyecto y no en un acta, y cuenta con qué frecuencia se usan: una puerta que solo recicla no está decidiendo nada.

4. Mantén separadas la revisión de diseño y la validación

   Responden a preguntas distintas. La revisión de diseño pregunta si el diseño y el prototipo cumplen la especificación acordada al inicio del desarrollo, y es una comprobación entre pares y partes interesadas sobre el diseño en sí. Los ensayos de validación preguntan si el producto terminado cubre la necesidad del usuario y los requisitos regulatorios en condiciones reales. Mantenerlas separadas es lo que da sentido a los dos bucles de retrabajo del diagrama: uno caza un problema de diseño antes de gastar en unidades de ensayo, el otro caza un problema de requisitos antes de gastar en un piloto.

5. Define el piloto y sus criterios de salida

   «Ejecutar un piloto de producción limitado» significa algo distinto en cada organización: un lote de preserie, un lanzamiento suave en una región, una cohorte de acceso anticipado. Deja escrito cuál es, el volumen o el número de clientes, qué se está midiendo (rendimiento, tasa de defectos, carga de soporte, activación) y cuánto dura antes de convocar la puerta 2. Un piloto sin final definido es la forma en que las fechas de lanzamiento se retrasan sin que nadie haya tomado ninguna decisión.

6. Pon nombre a los dueños de cada puerta y registra las decisiones

   Para cada puerta, nombra a la persona que tiene la última palabra y al grupo que debe estar presente. Un único responsable por puerta funciona mejor que un comité que decide por ausencia de objeciones. Recoge el resultado, la fecha, los criterios aplicados y la justificación, sobre todo en una cancelación, porque una cancelación sin registrar reaparece como la misma idea seis meses después. Si trabajáis con un sistema de gestión de la calidad, ese registro es además la evidencia de que las revisiones se hicieron.

7. Publícalo y revísalo después de cada lanzamiento

   Comparte el diagrama donde ocurre el trabajo, junto a las plantillas de puerta y no en una carpeta de políticas, y consigue el visto bueno de los responsables de cada carril. Después de cada lanzamiento, recorred el flujo con el equipo: qué puerta se saltó, qué bucle se tomó y por qué, y si la revisión poslanzamiento se hizo de verdad o se la llevó por delante el siguiente proyecto. Conserva las versiones anteriores para poder demostrar cuándo cambió el proceso y qué lo motivó.

Preguntas frecuentes

¿Cuáles son las fases de un proceso de desarrollo de producto?

Cinco fases cubren la mayoría de las organizaciones de producto. Primera, idea y filtrado: registrar la idea y contrastarla con la estrategia antes de que ninguna función comprometa esfuerzo. Segunda, caso de negocio: evaluar la viabilidad técnica, esbozar el concepto, identificar los requisitos regulatorios y dimensionar el mercado, y después reunir las cuatro entradas en un único caso que se lleva a la puerta 1. Tercera, diseño y desarrollo: acordar requisitos y especificación, desarrollar el diseño de detalle, construir un prototipo funcional y celebrar la revisión de diseño. Cuarta, validación: planificar y ejecutar los ensayos de validación contra la especificación y, una vez superados, ejecutar un piloto de producción limitado. Quinta, lanzamiento y revisión: tomar la decisión de lanzamiento en la puerta 2, lanzar al mercado y, por último, hacer la revisión poslanzamiento y cerrar el proyecto.

¿Qué es un proceso stage-gate y qué puede decidir una puerta?

Un proceso de fases y puertas agrupa el trabajo de desarrollo en fases y coloca un punto de decisión entre cada una, de modo que la financiación y el esfuerzo se liberan por tramos y no todos al principio. Los resultados clásicos de una puerta son seguir, cancelar, aparcar y reciclar: pasar a la fase siguiente, parar el proyecto, dejarlo en espera por capacidad o prioridad, o devolverlo para rehacer la fase actual antes de decidir. Esta plantilla muestra Adelante, Reciclar y Cancelar en la puerta 1, y Lanzar, Ampliar piloto y Cancelar en la puerta 2. Si vuestras puertas nunca producen otra cosa que un Adelante, no son puertas, y la gestión de cartera que se supone que aportan no está ocurriendo.

¿Qué diferencia hay entre una revisión de diseño y los ensayos de validación?

Una revisión de diseño comprueba el diseño contra sus entradas: si el diseño de detalle y el prototipo cumplen la especificación acordada al inicio del desarrollo y si los riesgos abiertos están entendidos. Los ensayos de validación comprueban el producto contra la necesidad: si funciona para el usuario, en condiciones realistas, frente a los requisitos, incluidos los regulatorios. La verificación es la primera pregunta y la validación la segunda, y las normas de gestión de la calidad las tratan como actividades separadas por buenos motivos. En este diagrama son dos decisiones con dos caminos de retorno distintos hacia el diseño de detalle, porque un fallo de diseño detectado en la revisión sale muchísimo más barato que ese mismo fallo detectado cuando ya se han fabricado unidades de ensayo.

¿En qué se diferencia esto de un proceso de release de software o de un árbol de decisión go/no-go?

En el alcance. Este diagrama cubre el ciclo de desarrollo completo, desde que una idea entra en el pipeline hasta la revisión poslanzamiento, y trata cada decisión de lanzamiento como un único nodo con puerta. El proceso de release de software en /es/templates/proceso-de-release-de-software empieza mucho más tarde, en una build ya cerrada, y detalla el corte de rama, las puertas de pruebas, la preproducción, el despliegue, la reversión y los hotfix. El árbol de decisión go/no-go va en la dirección contraria y expande una sola puerta en una docena de preguntas de evidencia con cinco salidas con nombre. Usa esta página para definir el ciclo y cualquiera de las otras para la parte que necesites en más detalle.

¿Quién debe ser dueño de cada decisión de puerta?

Una única persona con nombre por puerta, con las funciones que aportan asistiendo como evidencia y no como votos. La puerta 1 suele recaer en quien es dueño de la cartera y del presupuesto (un director de producto, un director general o el comité de dirección en una organización pequeña), porque es una decisión sobre dónde va la capacidad de desarrollo. La puerta 2 es una decisión de preparación además de comercial, así que su responsable necesita autoridad para retener un lanzamiento cuando la calidad o el suministro no están listos, no solo para aprobarlo. Escribid los derechos de decisión antes de la primera puerta: una puerta sin asignar acaba decidiéndola quien sea más sénior en la sala ese día.

¿Cuántas puertas debería tener un proceso de desarrollo de producto?

Menos de las que crees, y solo donde exista una decisión real. Aquí se muestran dos porque marcan los dos puntos en que da un salto el gasto comprometido: la puerta 1 autoriza el desarrollo y la puerta 2 autoriza el lanzamiento y todo el coste de producción, marketing y soporte que viene detrás. Los programas grandes o más regulados suelen añadir una puerta entre el concepto y el diseño de detalle, y otra antes de empezar la validación. La prueba útil es si la puerta podría razonablemente devolver algo distinto de un Adelante. Si una revisión no ha parado ni cambiado nunca un proyecto, elimínala o muévela a donde de verdad se compromete el dinero.