Junio de 2024. Un cliente de e-commerce llama en pánico a las 22h: su web debía entregarse antes del Black Friday, el rediseño gráfico sigue en la revisión número cuatro y el desarrollador front-end está de vacaciones hasta el 2 de diciembre. El planning original consistía en dos columnas de Excel montadas en una hora durante el kick-off. Básicamente, no existía.
Todo jefe de proyecto en una agencia ha vivido esto al menos una vez. Y sin embargo, seguimos tratando la retroplanificación como un trámite administrativo en lugar de la columna vertebral del proyecto. Error fatal.
Por qué la mayoría de los plannings no sirven para nada
La mayoría de los plannings en agencia comparten el mismo defecto: se construyen de izquierda a derecha, desde el inicio del proyecto hasta la fecha límite, apilando tareas de forma optimista. Es exactamente al revés de lo que debería hacerse. Un verdadero retroplanning parte de la fecha de entrega y retrocede en el tiempo. Se fija el deadline contractual no negociable, luego se restan los tiempos de validación y corrección, las fases de producción, los briefs y talleres. Lo que queda es la fecha de inicio real. A menudo, esa fecha ya ha pasado cuando se hace el ejercicio con honestidad.
"Empezamos a construir nuestros plannings hacia atrás hace 18 meses. El porcentaje de proyectos entregados a tiempo pasó del 41% al 78%. Solo cambiando la dirección de lectura del planning." - Responsable de producción, agencia digital de 12 personas, Lyon
Los 4 errores clásicos y cómo corregirlos
Primer error: no integrar los tiempos de validación del cliente. Los ciclos de aprobación representan de media entre el 30 y el 40% de la duración total de un proyecto web. Los olvidamos sistemáticamente. Segundo error: la asignación teórica de ETP. Escribes "desarrollo front: 5 días", pero ese desarrollador está al 60% en otro proyecto. Los 5 días se convierten en 12 días naturales. Trabajar en días naturales y no en días-hombre evita esta trampa.
Tercer error: ningún margen de seguridad. Añadir un 15-20% de buffer a cada fase no es trampa, es realismo. Cuarto error, el que más me irrita: el retroplanning nunca se actualiza. Se crea en el kick-off, se valida y se olvida en una carpeta de Drive hasta que alguien da la alarma. Un planning que no se actualiza cada semana es un documento muerto.
Método en 5 pasos para construir un retroplanning sólido
Paso 1: fijar la fecha ancla. El go-live contractual, no negociable. Todo parte de ahí. Paso 2: desglosar en hitos macro. Primero las grandes fases, no las tareas granulares. Cada hito tiene su propio deadline calculado hacia atrás desde la entrega. Paso 3: mapear las dependencias. El SEO técnico no puede empezar antes de que la arquitectura esté validada. Materializar estas dependencias en la herramienta elegida, ya sea Notion, Asana o Clynt, evita los descubrimientos tardíos y catastróficos.
Paso 4: asignar recursos en días naturales reales, teniendo en cuenta vacaciones, formaciones y proyectos en paralelo. Paso 5: compartir y formalizar. Un cliente que ha aprobado el planning al inicio no puede alegar que el plazo era "irreal" tres semanas antes de la entrega.
Retroplanning y metodologías Agile: ¿contradicción o complemento?
Existe el mito de que el retroplanning es anticuado e incompatible con Scrum o Kanban. Es una confusión. El retroplanning fija los hitos contractuales macro. Los sprints Agile organizan la producción dentro de esos hitos. Conviven perfectamente. En un cliente retail en 2023, el equipo técnico trabajaba en sprints de dos semanas, pero el retroplanning macro con la beta y el go-live estaba permanentemente visible en Slack. Cero sorpresas para el cliente, y el equipo siempre supo qué story points debían aterrizar en cada sprint.
Qué hacer cuando el planning se descarrila
Siempre pasa. La cuestión no es evitarlo al 100%, sino detectarlo pronto. Con un retraso de más de 3 días en un hito intermedio, hay tres opciones: reducir el scope a MVP, añadir recursos si el margen presupuestario lo permite, o renegociar la fecha con el cliente presentando los hechos. La peor opción: esperar recuperar el retraso en un sprint final. Nunca funciona.
FAQ
¿Cuál es la diferencia entre un retroplanning y un diagrama de Gantt clásico?
El Gantt clásico se construye de izquierda a derecha. El retroplanning parte de la fecha de entrega y retrocede en el tiempo para calcular los hitos. Esta inversión obliga a confrontar los plazos reales desde el diseño, eliminando el optimismo ingenuo de los plannings tradicionales.
¿Cómo gestionar los retrasos imprevisibles en las validaciones del cliente?
Incluye ventanas de validación contractuales en tu retroplanning: por ejemplo, el cliente dispone de 5 días hábiles para validar cada entregable. Si la validación supera ese plazo, la fecha de entrega final se desplaza automáticamente el mismo número de días. Formaliza este principio en el contrato o al menos en el pedido.
¿Cuántos hitos intermedios debe tener un proyecto de rediseño web?
Para un rediseño estándar de 2 a 4 meses, planifica de 5 a 7 hitos: kick-off, validación de arquitectura y wireframes, validación de identidad visual, pruebas internas, aceptación del cliente, correcciones finales, go-live. Con menos de 5 hitos, el seguimiento es demasiado grueso para detectar retrasos a tiempo.
¿Debe compartirse el retroplanning completo con el cliente?
No necesariamente. Comparte la versión de hitos macro para alinear expectativas y fijar fechas de validación. La versión operativa detallada con la asignación de recursos internos suele quedarse en casa. El cliente no necesita saber que Jean-Baptiste está al 60% en su proyecto y al 40% en otro.