Proceso de desarrollo de producto (plantilla stage-gate)

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.