Un roadmap técnico que alguien más quiera leer
El trabajo técnico que no se explica en el lenguaje del negocio no se prioriza: se pospone. Un roadmap técnico no es una lista de tareas de ingeniería, es el argumento de por qué esas tareas compran algo que a la empresa le importa.
Casi todo equipo de ingeniería tiene una lista de cosas que «habría que hacer»: migrar aquello, partir ese servicio, subir la cobertura, cambiar la base. Casi ninguna entra al plan del trimestre.
No es porque al negocio no le importe la calidad. Es porque esa lista está escrita en un idioma que no permite compararla con nada. «Migrar a la versión nueva del framework» no compite contra «lanzar el checkout nuevo», y en una discusión de prioridades lo que no compite, pierde.
Lo que un roadmap técnico no es
Tres formas habituales de escribirlo, y por qué las tres fallan:
| Forma | Cómo se ve | Por qué falla |
|---|---|---|
| Lista de deseos | Veinte ítems sin orden ni fecha | No dice qué pasa si no se hace nada, así que nunca es urgente |
| Plan de tareas | «Sprint 3: partir el módulo de pagos» | Habla de cómo, no de para qué: sólo lo entiende quien ya está adentro |
| Documento de queja | Un inventario de todo lo que está mal | Pide permiso para arreglar el pasado en vez de proponer algo para el futuro |
La plantilla
Esta estructura entra en una página y sirve tanto para presentarlo como para revisarlo tres meses después.
Plantilla
Roadmap técnico de un trimestre
El objetivo del negocio al que sirve
Qué quiere lograr la empresa en este período, escrito con las palabras de la empresa. Por ejemplo: sostener el crecimiento de clientes sin sumar gente al equipo de soporte.
Si no se puede completar sin inventar, hay que ir a buscarlo antes de seguir: sin esta línea el resto es opinión.
Dónde estamos hoy
Dos o tres hechos medibles, no adjetivos. Tiempo de despliegue, incidentes por mes, tiempo de respuesta, horas de trabajo manual, costo de infraestructura por cliente.
Números que ya existen, aunque sean feos. Un diagnóstico sin datos se discute; uno con datos se atiende.
Las tres apuestas del período
Para cada una: qué capacidad habilita, qué deja de pasar, cuánto cuesta en tiempo de equipo y cómo sabremos que funcionó.
Tres, no diez. Un roadmap con diez prioridades no tiene ninguna.
Lo que NO vamos a hacer
Lo que queda explícitamente afuera este período y por qué. Incluye lo que otros van a pedir y la respuesta ya pensada.
Es la sección que más discusiones ahorra y la que casi nadie escribe.
Riesgos y dependencias
Qué puede hacer que esto no salga: una decisión de otro equipo, una contratación, una migración de un proveedor. Con nombre y fecha de cuándo hay que resolverlo.
Un riesgo escrito antes es una conversación; descubierto después, es una excusa.
Cómo se revisa
Cuándo lo volvemos a mirar y qué evidencia nos haría cambiarlo.
Un roadmap que no se revisa se vuelve folclore en seis semanas.
Traducir, sin mentir
La parte difícil es la tercera sección. Traducir no es disfrazar trabajo técnico con palabras lindas: es decir cuál es la consecuencia observable.
| Escrito para ingeniería | Escrito para decidir | Qué cambió |
|---|---|---|
| Migrar a la versión nueva del framework | Dejar de depender de una versión sin parches de seguridad antes de la auditoría de septiembre | Aparece una fecha externa y un riesgo concreto |
| Subir la cobertura de tests al 80 % | Bajar de tres a menos de uno los incidentes por despliegue, para poder publicar varias veces por semana | Aparece la capacidad que se gana, no la métrica intermedia |
| Partir el monolito | Que los equipos de pagos y de catálogo puedan publicar sin coordinarse, hoy bloqueados entre sí dos días por semana | Aparece el costo actual, medido en tiempo perdido |
| Mejorar el monitoreo | Enterarnos de una caída por una alerta y no por un cliente; hoy el 70 % de los incidentes los reporta soporte | Aparece quién sufre hoy el problema |
Antes de seguir, predecí
Presentarlo sin que se vuelva una lista de pedidos
La conversación, en orden
- Empezá por el objetivo de ellos. Los primeros treinta segundos tienen que ser sobre el negocio, no sobre ingeniería. Lo que sigue se escucha distinto.
- Mostrá el hoy con números. Dos o tres, no una tabla. El objetivo es que nadie discuta el diagnóstico.
- Proponé tres apuestas, con su costo. El costo en semanas de equipo es parte de la propuesta: sin él, estás pidiendo un cheque en blanco.
- Ofrecé el recorte vos mismo. «Si sólo entran dos, sacaría esta y por qué.» Quien trae el plan B conserva el control de la decisión.
- Cerrá con la revisión. Cuándo lo miramos de nuevo y qué evidencia lo cambiaría.
En la práctica
Cierre
Autoevaluación
¿Lo entendiste?
Práctica