Ejemplo de hoja de ruta tecnológica: un plan Now, Next, Later para un equipo de plataforma

Las hojas de ruta tecnológicas suelen fallar de una de dos maneras. Algunas son diagramas de Gantt con fechas que nadie se cree y que se redibujan cada trimestre. Otras son una exportación del backlog con un título encima. Ninguna les dice a los equipos que dependen de ti qué está pasando ahora, qué viene después y qué no has decidido todavía.

Los equipos de plataforma lo tienen más difícil que la mayoría. Sus plazos suelen fijarlos otros, como el fin del soporte de una versión de Kubernetes o de PostgreSQL. Sus clientes son otros equipos de ingeniería, cada uno con su petición. Y su trabajo está lleno de migraciones largas que pasan meses casi terminadas.

Este artículo construye una hoja de ruta tecnológica para un equipo de plataforma en formato Now, Next, Later (ahora, después, más adelante), explica de dónde viene el formato y por qué encaja con el trabajo tecnológico, y cuenta cómo gestionarla para que siga siendo honesta.

Por qué Now, Next, Later

El formato viene de ProdPad. En The Birth of the Modern Roadmap, la cofundadora Janna Bastow cuenta cómo, hacia finales de 2012, su cofundador Simon Cast dibujó tres columnas en una servilleta: Current, Near term y Future. Las columnas eran horizontes temporales, y la idea detrás era la certeza: el trabajo de la primera columna es claro y cercano, y el de la última tiene un alcance difuso. Lo incorporaron a ProdPad como la hoja de ruta Now-Next-Later.

Las columnas hablan de certeza, no de trimestres del calendario. Un elemento se mueve a la izquierda cuando sabes lo suficiente para comprometerte con él, no cuando termina un trimestre.

Qué hace diferente a una hoja de ruta tecnológica

Plazos externos. El software que operas tiene una ventana de soporte, y esa ventana fija el orden de tu trabajo. El proyecto Kubernetes mantiene las tres versiones menores más recientes, y cada una recibe alrededor de un año de parches. Por eso las actualizaciones son un elemento recurrente de la hoja de ruta, no un proyecto puntual, y saltarse versiones menores no está soportado en clústeres kubeadm, así que pasar de 1.35 a 1.37 supone dos actualizaciones. PostgreSQL da soporte a cada versión mayor durante cinco años; después se publica una última versión menor y la versión llega al fin de su vida útil.

Clientes internos. Los equipos alineados al flujo planifican en función de lo que entregará la plataforma. Necesitan saber qué está comprometido y qué no, y eso es justo lo que dicen las columnas.

Colas largas. Una migración terminada al 90 % todavía deja una base de datos o un servicio en la versión antigua. Muestra el avance como lo que queda por migrar, no como una fecha.

Dependencias. El trabajo de plataforma a menudo se apoya en otro trabajo de plataforma. Una plantilla de servicio que incluye trazado no puede publicarse antes de que el trazado funcione.

Escribe resultados, no proyectos

Escribe cada elemento como el resultado que quieres, para que cualquiera sepa cuándo está hecho:

Añade la medida a la descripción del elemento: servicios que exportan trazas, clústeres en una versión con soporte, bases de datos que siguen en la versión 15.

El ejemplo: la hoja de ruta de un equipo de plataforma

El ejemplo está fechado en octubre de 2026, así que los plazos son los reales de las páginas de versiones de Kubernetes y PostgreSQL.

• Now. Traces everywhere, el despliegue de OpenTelemetry, está hecho en un tercio aproximadamente y en riesgo porque el equipo necesita otra ingeniera. Kubernetes 1.37 está en curso: Kubernetes 1.35 llega al fin de su vida útil el 28 de febrero de 2027, dentro de la ventana Next, así que la actualización tiene que hacerse ahora.
• Next. Golden path, una plantilla de servicio con CI/CD, trazado y paneles integrados, espera al trazado. Off PostgreSQL 15 es una actualización mayor a la versión 18 con pg_upgrade, antes del fin de vida de la versión 15 el 11 de noviembre de 2027.
• Later. Dos problemas que explorar: hacer visible el coste en la nube por equipo y conseguir que el checkout sobreviva a la caída de una región. Ninguno tiene todavía responsable ni solución.

Cómo leerlo:

• Las columnas son certeza, no trimestres. De izquierda a derecha, el trabajo pasa de comprometido a probable y a todavía no decidido.
• Cada tarjeta es un resultado con responsable, estado y barra de progreso. Los elementos de Later aún no tienen responsable; son problemas, no planes.
• La insignia de dependencia muestra que el trazado bloquea el Golden path, porque la plantilla viene con el trazado activado.
• Los hitos son plazos externos, colocados en la columna en la que caen. El soporte de Kubernetes 1.35 termina durante Next, así que su actualización está en Now. El soporte de PostgreSQL 15 termina en Later, así que su actualización empieza en Next y deja tiempo para la cola larga.
• La insignia de estado explica el riesgo: al trazado le falta personal.

Cómo gestionarla

• Revísala con un ritmo fijo, por ejemplo cada dos semanas, con los líderes de los equipos a los que das servicio. Mueve elementos solo en la revisión, para que la hoja de ruta no cambie bajo los pies de la gente.
• Mantén Now pequeño. Pon solo aquello para lo que el equipo tiene personal. Si algo nuevo entra en Now, otra cosa sale.
• Pasa de Later a Next solo lo que esté definido: un enunciado del problema, una medida de terminado, un responsable y un tamaño aproximado.
• Usa fechas solo para plazos externos. Las estimaciones internas van en la descripción del elemento como rangos, no en la hoja de ruta como promesas.
• Muestra los elementos terminados una vez, en la siguiente revisión, y luego archívalos. La hoja de ruta trata de lo que tienes por delante.
• Enlaza los elementos con los detalles: el documento de diseño, el seguimiento de la migración, el diagrama de arquitectura. Los artículos sobre el diagrama de pipeline de CI/CD y el diagrama de arquitectura de Kubernetes muestran cómo pueden ser esas imágenes.

Errores comunes

• Una lista de funciones con fechas. Oculta la incertidumbre hasta que una fecha se retrasa, y entonces todos se enteran a la vez.
• Todo en Now. Si hay diez elementos en curso, ninguno lo está de verdad.
• Sin responsables. Un elemento sin responsable en Now o Next es un deseo.
• Dependencias ocultas. Si un elemento necesita otro, dibújalo. Si no, el segundo empieza y se atasca.
• Actualizaciones que solo aparecen cuando son urgentes. Pon en la hoja de ruta cada ventana de soporte de la que dependes como un hito el mismo día en que adoptas la versión.
• Una hoja de ruta que nadie mira. Tenla donde la gente ya trabaja e insértala en tu documentación en lugar de pegar una captura de pantalla que se queda desactualizada.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama, o parte de la plantilla de hoja de ruta Now / Next / Later.
2. Del pack Hoja de ruta, añade tres marcos Trimestre y llámalos Now, Next y Later.
3. Añade una Épica por cada resultado y define su título, responsable, estado y avance.
4. Añade un Hito por cada plazo externo, con su fecha, en la columna en la que cae.
5. Añade una insignia Dependencia entre dos épicas cuando una bloquea a la otra, y conéctalas con conexiones discontinuas.
6. Añade una insignia Estado del proyecto para un riesgo, y una Nota del pack Básico con las reglas de cada columna.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué diferencia hay entre una hoja de ruta tecnológica y una hoja de ruta de producto? Una hoja de ruta de producto trata de lo que reciben los clientes. Una hoja de ruta tecnológica trata de las capacidades, actualizaciones y migraciones que lo hacen posible, y sus clientes suelen ser otros equipos de ingeniería. El formato puede ser el mismo.

¿Debe tener fechas una hoja de ruta tecnológica? Solo donde la fecha es real: un fin de soporte, un contrato o una normativa. Todo lo demás va en columnas de certeza.

¿Hasta dónde debe llegar Later? No hay un horizonte fijo. Later contiene problemas, así que mantén la columna lo bastante corta para que cada elemento siga mereciendo una conversación en la siguiente revisión.

¿Cómo muestro el avance de una migración larga? Cuenta lo que queda por migrar, como clústeres, servicios o bases de datos, y actualiza el número en cada revisión. Un porcentaje sin recuento oculta la cola larga.

¿Quién debe ver la hoja de ruta de la plataforma? Todos los que dependen de la plataforma. Compártela con los equipos a los que das servicio y revísala con sus líderes, para que puedan planificar en función de lo comprometido.

Empieza gratis — un puesto, sin tarjeta de crédito.