Los últimos meses del año tienen un ritmo particular en telecomunicaciones. Y este año más que nunca.
Cuando el Mundial de Fútbol está en el calendario, todo el sector sabe que hay una fecha que no se mueve: antes de que empiece, todo tiene que estar en producción. Lo que no llegue a tiempo espera hasta después — y “después” significa llegar a fin de año con el pipeline acumulado encima.
El resultado es lo de siempre, pero más apretado: cambios que compiten por las mismas ventanas, upgrades que dependen de que otro proyecto termine primero, migraciones coordinadas entre varios países con freezes distintos y equipos locales con sus propios calendarios — el mismo tipo de fricción que describí al pasar de equipo local en Chile a coordinación desde Europa. De repente estás mirando un pipeline donde todo es urgente, todo tiene dependencias, y en unos días tienes que presentarle al management el estado real — sin alarmar, pero sin esconder nada tampoco.
El problema no es la cantidad de trabajo. El problema es la visibilidad. ¿Qué va primero? ¿Qué bloquea a qué? ¿Dónde hay conflicto de capacidad? Antes de responder cualquiera de esas preguntas, primero hay que construir la imagen. Y eso tomaba días.
1. 🔍 El problema que vive entre las herramientas
Las herramientas no faltan. Jira para gestionar tareas, planners para organizar el trabajo, documentación que en teoría está al día. El problema es que ninguna te dice qué pasa en el tiempo — y en operaciones complejas, eso es exactamente lo que necesitas saber.
Jira te dice qué existe. No cuándo va, en qué orden, qué depende de qué. No entiende que si tienes proyectos activos en el backoffice que atiende los servicios locales, no puedes tener en paralelo un upgrade complejo de otro componente — porque si algo falla en producción, nadie sabrá de dónde vino el problema. Eso no es un detalle menor. En producción, la trazabilidad lo es todo.
Coordinar iniciativas en varios países, con plataformas distintas y equipos locales con sus propios ritmos y prioridades, requiere una vista que ningún producto del mercado da. No una lista de tareas — una lectura real de qué está en vuelo, qué bloquea qué, dónde hay riesgo real y cómo comunicarlo hacia arriba sin alarmar y sin ocultar nada.
Y luego están los runbooks. Un runbook es básicamente el manual paso a paso que se ejecuta durante una ventana de mantenimiento — lo que hace el equipo técnico para implementar un cambio de forma controlada. El problema es que con el tiempo se multiplican: versiones por país, actualizaciones numeradas, variantes por plataforma. Cientos de Excel que nadie sabe con certeza si están vigentes. Cada ventana empieza buscando el archivo correcto. Es un dolor que lleva años sin resolverse y que tiene consecuencias reales cuando algo sale mal.
2. 🛠️ Lo que construí — y cómo funciona
Lo que construí tiene dos partes que funcionan juntas: un portal de equipo y un planner.
El portal conecta con Jira y da visibilidad por proyecto — desde el EPIC hasta el task de implementación, con avance, planning y estado. Pero va más allá de una vista de Jira. Cada tarea de implementación tiene su runbook asociado, versionado, sin Excel. Hay una sección de aprendizajes donde queda registrado lo que antes se perdía en chats y correos. Y se puede exportar un resumen ejecutivo con blockers y próximas acciones, listo para compartir.
El planner es donde organizo todo en el tiempo. Trabajo con chain templates — básicamente una cadena de tareas que define todo lo que tiene que pasar para que algo esté entregado. Un upgrade sigue su secuencia: preprod, DR, prod batch 1, prod batch 2. Una migración tiene la suya. Puedo ver varios proyectos del mismo país en el mismo timeline, mover fechas arrastrando, y Jira se actualiza solo.
Construí todo esto con Claude — igual que hice con NeuraPRO — aplicando la misma lógica: entender bien el problema antes de empezar a construir.
Imagen ilustrativa con datos de ejemplo. No muestra información operativa real ni compromete datos privados de ningún mercado.
Y encima de todo esto, Claude. Un EPIC en Jira puede tener decenas de tareas, fases, dependencias y criterios de aceptación. Antes, estructurar todo eso en un proyecto tomaba horas. Ahora con Claude integrado directamente en Jira, puedo tomar un EPIC, analizarlo y transformarlo en chains y tasks organizados — con su jerarquía, sus fases y su estructura lista. Yo reviso, ajusto lo que no cuadra con la realidad del equipo, y ejecuto.
Desde ahí, esa estructura pasa al planner. El equipo puede ver el trabajo distribuido en el tiempo, empezar a priorizar, identificar conflictos y hablar de riesgos reales — no de fechas puestas en un calendario sin contexto.
Hoy lo uso yo como technical project manager del equipo. Primero quiero sacarle el máximo provecho en esta etapa — hay mucho en el pipeline y es el momento de probar y ajustar. La siguiente fase es abrirlo al equipo con accesos por rol: que cada ingeniero tenga visibilidad de sus tareas, sus runbooks y su progreso, sin que todo tenga que pasar por una sola persona.
Un ejemplo real
En un mercado teníamos tres proyectos críticos corriendo al mismo tiempo: dos upgrades de plataforma y una migración. Tres EPICs en Jira, el mismo país, el mismo periodo.
El management no preguntaba si había ventana disponible. Preguntaba qué va primero y qué tiene más impacto en producción si algo sale mal.
En el planner los tres aparecen como chain templates del mismo país, en el mismo timeline. Ahí se ve lo que Jira no muestra: un ingeniero asignado a tareas en distintos proyectos el mismo día, un ambiente de backup que choca con otra actividad, o una operación compleja calendarizada antes de que las etapas previas estén validadas. Sin esa visibilidad, si algo falla en producción no sabes de dónde vino.
La lógica para ordenarlos fue simple: primero preprod para los tres, luego validación con los equipos, después DR dejando al menos una semana entre cadenas, y el orden de producción definido según cómo salió cada uno en las etapas anteriores. Si algo falla, hay trazabilidad clara.
Cuando el problema es de capacidad de una persona, filtro por responsable y lo veo de inmediato. Para el reporte al management, exporto desde el portal — fechas, riesgo, estado por proyecto — sin armar una presentación desde cero.
3. ⚡ Lo que cambió
Sí, ahorro tiempo. Pero eso no es lo principal.
Antes mucha energía se iba en construir la imagen: sacar datos de Jira, cruzar información de distintas fuentes, intentar visualizar en algún lado qué proyectos están en vuelo, en qué estado, quién tiene qué, y cuándo choca con qué. Eso no es gestionar un programa — es ensamblado. Y cuando tardas días en armarlo, ya está desactualizado.
Ahora ese tiempo existe para lo que importa: ¿este proyecto va antes o después? ¿El equipo tiene capacidad real ese sprint o solo fechas puestas en el calendario? ¿El riesgo que estamos viendo en una iniciativa tiene relación con algo que ya ocurrió en otro mercado?
Como program manager, el valor no está en saber dónde está cada tarea. Está en entender cómo se relacionan, qué bloquea qué, y poder comunicarlo con claridad — al equipo y hacia arriba. Para eso necesitas la imagen completa, siempre actualizada. Antes eso era un trabajo en sí mismo. Ahora es el punto de partida.
4. 🤔 Lo que me queda dando vueltas
La herramienta existe, funciona, sigue mejorando. Pero hay dos cosas que no puedo ignorar.
La primera: el mismo razonamiento que usé aquí funciona en cualquier industria donde haya procesos y coordinación. Una ferretería mediana. Una farmacia. Una panadería con varios locales. No las grandes empresas con equipos de IT — las que tienen algo de tecnología pero no saben por dónde empezar con IA. Con un grupo pequeño de personas que sepan manejar la IA, que piensen bien y hayan trabajado bajo presión, creo que se puede hacer bastante. El límite no es técnico.
La segunda es más incómoda: en dos o tres años, en ciertos puntos de la cadena va a haber cada vez menos personas necesarias. No como predicción — como algo que ya está pasando. Lo que construí yo en semanas, antes necesitaba un equipo y varios meses.
El tema no es si automatizar. Es en qué punto sigue siendo necesario que haya alguien mirando — y cómo se decide eso. Hoy cada uno lo va resolviendo como puede. En algún momento eso va a tener estructura: roles, políticas, responsabilidades definidas.
Lo que sí veo desde adentro es que la industria todavía está esperando que esto se resuelva solo. Muy poca acción real. El management en muchos casos sigue en modo de observación, sin terminar de entender que el momento de experimentar ya pasó — estamos en el momento de construir. Y quienes no empezaron a hacerlo van a llegar tarde a esa conversación.
✍️ Claudio desde ViaMind
“Atrévete a imaginar, crear y transformar.”
También disponible en inglés: When Jira Is Not Enough: How I Built My Own AI Planning System.
POST DESTACADOS
SOBRE MI
Ecosistema ViaMind
- ViaMind — El núcleo de ideas, tecnología y estrategia.
- NeuraPRO — Software práctico para gestionar operaciones reales.