Cómo construir un roadmap de delivery predecible en 90 días

Acabas de entrar como CTO. O eres founder y por fin aceptaste que “ir viendo cómo va” ya no funciona. Tu equipo no tiene proceso definido, no tiene roadmap, y no hay forma de predecir cuándo algo va a estar listo.

¿Por dónde empiezas?

Después de armar sistemas de delivery en más de 12 empresas en Perú y LATAM, el sweet spot son 90 días. Suficientemente cortos para mantener urgencia, suficientemente largos para construir algo sostenible. Esta es la guía, semana a semana.

Antes de empezar: el assessment honesto

Antes de construir nada, dedica 2 a 3 días a entender qué tienes delante. Habla con cada persona del equipo individualmente. No reuniones grupales —conversaciones privadas. Hazles tres preguntas:

“¿Qué es lo que más te frena hoy?” Los devs te van a decir cosas que jamás dirían frente a su jefe. Respuestas comunes: requerimientos poco claros, demasiadas reuniones, cambio de contexto constante, ambiente de desarrollo roto, code reviews lentos.

“¿Cuándo fue la última vez que el equipo entregó algo a tiempo?” Si nadie se acuerda, el problema es sistémico, no situacional.

“Si pudieras cambiar una cosa de cómo trabaja el equipo, ¿qué sería?” Esto te dice qué está listo para cambiar el equipo. Empezar por lo que el equipo quiere cambiar es mucho más fácil que imponer cambios desde arriba.

Anota todo. Vas a usar estos insights para priorizar qué arreglar primero.

Días 1 a 30: Fundación

El primer mes es para establecer lo básico. No trates de ser sofisticado. La meta es pasar del caos a un ritmo simple y repetible.

Semana 1: Define “done” y arma visibilidad

La mayoría de equipos sin proceso tiene un problema fundamental: nadie está de acuerdo en qué significa “done”. Para un dev, done es “subí el código”. Para otro, “está deployado y testeado”. Para el de producto, “el cliente ya lo puede usar”.

Escribe una definición de done simple y pégala donde todos la vean. Algo como:

“Done significa: código escrito, revisado por un compañero, tests pasando, deployado a producción, y verificado por alguien distinto al dev que lo construyó.”

Después arma un tablero. Jira, Linear, Trello, una pizarra —la herramienta no importa. Lo que importa es que cada pieza de trabajo del equipo esté visible en un solo lugar con un estado claro: To Do, In Progress, In Review, Done.

Semana 2: Establece un ritmo semanal

Introduce dos reuniones y elimina todo lo demás:

Lunes: planning semanal (30 minutos). El equipo mira el tablero, decide en qué trabajar esta semana, y se compromete a un número pequeño de items. Pequeño es la palabra clave —comprométete al 60-70% de lo que crees que puedes hacer. Entregar todo lo comprometido construye confianza. Sobre-comprometerse y fallar la destruye.

Viernes: review semanal (30 minutos). ¿Qué completamos en realidad? ¿Cómo se compara con lo planeado? ¿Qué se atravesó? Una cosa para hacer distinto la próxima semana.

Eso es. Dos reuniones. Una hora total. Todo lo demás se maneja asíncrono o en conversaciones rápidas según se necesite.

Semana 3: Limita el trabajo en progreso

Mira el tablero. Si tu equipo de 5 personas tiene 20 items in progress, ese es tu mayor problema. Nada se está terminando porque todos están haciendo malabares con demasiadas cosas.

Introduce una regla simple: máximo 2 items por persona en progreso a la vez. Cuando algo está bloqueado, la prioridad es desbloquearlo — no empezar otra cosa.

Esto va a sentirse incómodo. Los devs van a decir “pero no puedo hacer nada mientras espero el code review”. La respuesta: “Ayuda a revisar el código de alguien más, o ayuda a desbloquear el item atascado”. El objetivo es terminar trabajo, no empezar trabajo.

Semana 4: Mide tu línea base

Después de tres semanas con el ritmo nuevo, tienes tu primera data real:

• ¿Cuántos items completó el equipo cada semana?
• ¿Cuánto tardaron los items desde que se empezaron hasta done?
• ¿Cuántos items se bloquearon, y por cuánto tiempo?
• ¿Qué tan precisa fue la promesa del lunes vs. la realidad del viernes?

Anota estos números. Esta es tu línea base. Todo lo que viene después es sobre mejorar estos números.

Días 31 a 60: Optimización

La fundación está. Ahora la haces mejor.

Semana 5: Ataca el bloqueo principal

Mira la data del primer mes. ¿Cuál fue la razón más común por la que los items se atascaron? Sospechosos comunes:

Code reviews lentos. Solución: regla de que todos los pull requests se revisan en máximo 4 horas en horario de oficina. Mídelo.

Requerimientos poco claros.Solución: antes de que cualquier item entre a “In Progress” debe tener criterios de aceptación claros en lenguaje simple. Si el dev no entiende cómo se ve “done”, el item regresa a producto.

Problemas de ambiente o deploy. Solución: dedica un dev por una semana a arreglar el pipeline de CI/CD, montar staging decente, o automatizar lo que esté generando fricción. Se siente como tiempo perdido de desarrollo, pero se paga 10x.

Elige el bloqueo más grande y arréglalo esta semana. No trates de atacar tres cosas a la vez.

Semana 6: Introduce updates a stakeholders

Para este punto, tu equipo lleva un mes entregando con ritmo predecible. Es momento de hacerlo visible al resto de la empresa.

Empieza con un email semanal de un párrafo a stakeholders (CEO, producto, ventas, gerencia general —quien sea que le importe lo que entrega ingeniería). Formato:

“Esta semana completamos: (lista). La próxima semana planeamos: (lista). Una cosa que deben saber: (riesgo o bloqueo, si aplica).”

Corto. Factual. Consistente. Esto construye confianza más rápido que cualquier dashboard o reporte detallado. Los stakeholders empiezan a sentir que saben qué está pasando sin tener que preguntar.

Semana 7: Refina la planificación con data

Ya tienes 6 semanas de data de throughput. Úsala para planear mejor:

• “Hemos completado en promedio 7 items por semana en las últimas 6 semanas.”
• “Nuestra tasa de completación ha estado entre 5 y 9 items por semana.”
• “Los items que tocan el sistema de pagos toman 2-3x más que el promedio.”

Usa estos patrones para hacer compromisos más inteligentes. Si sabes que items de pagos toman más, presupuéstalo. Si tu throughput es 7 por semana, comprométete a 6 y entrega 7 —underpromise, overdeliver.

Semana 8: Agrega una retrospectiva ligera

Ahora que el equipo tiene ritmo, agrega una retro de 30 minutos cada 2 semanas. No una sesión de quejas —una conversación estructurada:

• ¿Qué dice la data de las últimas 2 semanas?
• Una cosa que funcionó bien (sigue haciéndola).
• Una cosa para probar diferente (experimento de 2 semanas).

Una mejora por retro. Después de 4 retros has hecho 4 cambios concretos, cada uno validado con data.

Días 61 a 90: Escalar

El sistema funciona. Ahora lo haces resiliente y planeas el futuro.

Semana 9: Construye un roadmap de 90 días

Ya tienes data suficiente para hacer predicciones creíbles. Siéntate con el equipo de producto y liderazgo:

• “Nuestro equipo completa unos 7 items por semana.”
• “Estos son los 40 items en el backlog, priorizados.”
• “A nuestro ritmo actual, podemos completar unos 28 items al mes.”
• “Esto es lo que podemos entregar realísticamente en los próximos 90 días.”

No es una promesa esculpida en piedra —es un forecast basado en data real. Actualízalo cada mes a medida que entra data nueva y las prioridades cambian.

Semana 10: Documenta el sistema

Escribe cómo trabaja el equipo. No un documento de proceso de 50 páginas —una sola hoja:

• Nuestro ritmo semanal (planning lunes, review viernes).
• Cómo trackeamos el trabajo (tablero, estados, qué significa “done”).
• Nuestros límites de WIP (2 por persona).
• Cómo manejamos trabajo no planeado (evaluamos urgencia, hacemos trade-off contra lo planeado).
• Cómo nos comunicamos con stakeholders (email semanal).
• Cómo mejoramos (retro cada 2 semanas, un experimento a la vez).

Este documento hace dos cosas: hace que el sistema sobreviva cambios de equipo (gente nueva lo lee el día uno), y hace explícitas las reglas implícitas para que nadie tenga que adivinar.

Semana 11: Planifica para sostenibilidad

El mayor riesgo en este punto es la regresión. El equipo vuelve a los hábitos viejos cuando las cosas se ponen estresantes. Para prevenirlo:

Protege el ritmo.Las reuniones de planning y review semanales son no-negociables. No se cancelan por trabajo “urgente”. No se saltan porque “todos están muy ocupados”. Son la fundación —todo lo demás depende de ellas.

Sigue midiendo. El momento en que dejas de medir tasas de completación y cycle times, pierdes visibilidad. Haz que la revisión de data sea 2 minutos del meeting semanal, no un esfuerzo aparte.

Celebra la consistencia. Cuando el equipo cumpla su compromiso 3 semanas seguidas, reconócelo. Cuando el throughput mejore, señálalo. La gente repite los comportamientos que se reconocen.

Semana 12: Revisa y planifica los próximos 90 días

Compara dónde estás ahora vs. dónde empezaste:

• Tasa de completación semana 1 vs. semana 12.
• Cycle time promedio entonces vs. ahora.
• Items bloqueados más de 2 días entonces vs. ahora.
• Satisfacción de stakeholders entonces vs. ahora (sólo pregúntales).

La mayoría de equipos ven una mejora del 40-60% en predictibilidad de delivery en 90 días. No porque trabajaron más duro, sino porque construyeron un sistema que hace los problemas visibles temprano y crea ritmo consistente.

Después planifica los próximos 90 días. ¿Qué quieres mejorar? ¿Cycle times más rápidos? ¿Mejor estimación? ¿Deploys automatizados? ¿Métricas más sofisticadas?

Los primeros 90 días construyen el motor. Todo lo que viene después es afinarlo.

No tienes que hacer esto solo

Construir un sistema de delivery desde cero mientras también manejas un equipo y entregas producto es duro. Esencialmente estás reconstruyendo el avión mientras vuela.

Si quieres ayuda para acelerar este proceso —alguien que lo ha hecho una docena de veces y puede guiar a tu equipo en la transición— los primeros 90 días marcan la trayectoria de todo lo que viene después. Hacerlos bien importa.

Agenda un diagnóstico gratuito de 30 minutos. Vemos en qué semana del roadmap está tu equipo y por dónde empezar. Sin compromiso, sin venta dura.