Un roadmap con solo fechas de lanzamiento no es un roadmap: es una lista de deseos con orden cronológico. Y es, con diferencia, el formato más habitual en los laboratorios de I+D que no tienen un sistema detrás.
La razón de por qué no basta es sencilla de explicar y difícil de aceptar: un roadmap solo de fechas asume que la capacidad para cumplirlas está garantizada. Casi nunca lo está.
Lo que falta en la mayoría de roadmaps
Comercial pide seis lanzamientos para el trimestre. Dirección los aprueba, porque cada uno por separado es razonable y tiene sentido de negocio. Nadie, en esa reunión, ha mirado si el laboratorio tiene capacidad para los seis a la vez, ni si dos de ellos compiten por el mismo recurso crítico —la única estufa de estabilidad, el único técnico con experiencia en un tipo de producto concreto—.
El resultado habitual: los seis avanzan a medias durante el trimestre, ninguno con la atención que necesitaría, y en la revisión de resultados aparece la frase de siempre —«estamos saturados»— sin que nadie pueda decir con precisión por qué ni cuánto.
Qué debería llevar un roadmap de laboratorio, además de fechas
Fase de cada proyecto, no solo su fecha final. Saber si algo está en briefing, en ensayo, en validación o esperando aprobación de cliente permite ver de un vistazo dónde está realmente el trimestre, no solo dónde debería estar según el plan original.
Carga estimada por proyecto, aunque sea aproximada. No hace falta precisión de cronómetro: basta con saber si un proyecto es de baja, media o alta demanda de horas de laboratorio para poder sumar el trimestre entero y compararlo con la capacidad disponible.
Prioridad relativa entre proyectos, para el día —siempre llega— en que algo nuevo se cuela y hay que decidir qué cede paso. Sin prioridad explícita, esa decisión se toma con la urgencia del momento y casi siempre gana quien grita más fuerte, no el proyecto que más valor aporta.
Dependencias entre proyectos, cuando existen. Dos lanzamientos que comparten una misma base semielaborada, o que dependen de la misma aprobación regulatoria, no son independientes en el calendario aunque lo parezcan en la lista.
El roadmap no sustituye la planificación fina
Vale la pena ser precisos sobre qué resuelve un roadmap trimestral y qué no. No sustituye la planificación detallada de lotes piloto, que trabaja con semanas y con recursos concretos. El roadmap es la capa de arriba: dice qué está en juego y con qué prioridad relativa; la planificación fina dice, dentro de eso, qué se hace cada semana. Confundir los dos niveles —intentar planificar el trimestre entero con el mismo nivel de detalle que una semana— es tan poco práctico como quedarse solo con las fechas de lanzamiento.
Revisarlo, no solo escribirlo
Un roadmap trimestral que se escribe el primer día y no se vuelve a mirar hasta el cierre no es mejor que no tener roadmap: es una fotografía vieja que nadie usa para decidir nada. El valor está en revisarlo con la cadencia que tenga sentido para el equipo —quincenal suele funcionar bien— y actualizar fase, carga y prioridad según avanza la realidad, no según el plan de hace diez semanas.
La pregunta que un buen roadmap responde en diez segundos
«Si entra un proyecto nuevo urgente esta semana, ¿qué cede paso?»
Si la respuesta exige convocar una reunión para averiguarlo, el roadmap no está cumpliendo su función, por bonito que se vea. Si la respuesta está a la vista —qué proyecto tiene menor prioridad relativa, en qué fase está, cuánta carga liberaría pausarlo—, entonces el roadmap ha hecho su trabajo: convertir una decisión de negocio en una consulta de treinta segundos, en vez de en una discusión de una hora sin datos encima de la mesa.