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
Jira existe. Los runbooks existen. La documentación existe — o debería. El problema nunca fue la falta de herramientas. Fue que ninguna te decía qué pasa en el tiempo.
Jira te dice qué existe. No te dice cuándo va, en qué orden, qué depende de qué, si hay dos cambios peleando por la misma ventana en el mismo país. Un planner genérico te deja mover tareas. Pero no entiende que si hay cambios en el backoffice que atiende los servicios locales, no puedes tener en paralelo un upgrade complejo de un componente de video — porque si algo falla, nadie sabrá quién fue el culpable.
Cuando tienes que coordinar upgrades en varios países, plataformas distintas, equipos locales con sus propios tiempos, y encima tienes que reportar con una vista honesta de riesgos — no una lista de tareas, sino una lectura real de lo que está pasando — necesitas algo que no viene empaquetado en ningún producto del mercado.
Y el otro dolor que nadie nombra: los runbooks. Cientos de Excel con versiones distintas, actualizaciones numeradas, variantes por país. El runbook del país A en versión 3, el del país B en versión 1 con modificaciones locales, el del país C que nadie sabe si está actualizado. Cada ventana de mantenimiento empieza buscando el archivo correcto. Ese es un problema real, y lleva años sin resolverse.
2. 🛠️ Lo que construí — y cómo funciona
Usando la experiencia que fui acumulando en otros proyectos personales — entre ellos NeuraPRO — y con Claude como herramienta de construcción, desarrollé dos piezas que hoy funcionan integradas: un portal de equipo y un planner. Se llega al planner desde el portal, pero cada uno tiene su propio rol.
El portal da visibilidad por proyecto. Conectado a Jira, muestra la estructura completa desde el EPIC hasta el task de implementación — porcentaje de avance, planning, estado. Pero no es solo una vista de Jira. Tiene una sección de runbooks donde cada tarea de implementación tiene su propio runbook estandarizado, versionado, sin Excel. Tiene una sección de aprendizajes donde queda registrado lo que antes se perdía en chats y correos. Y permite exportar un resumen ejecutivo del proyecto — blockers, estado, próximas acciones — listo para un reporte sin tener que armarlo desde cero.
El planner es donde vive la planificación en el tiempo. La lógica central son los chain templates: una cadena de tareas que representa todo lo que tiene que pasar para que algo se considere entregado. Un upgrade tiene su secuencia — preprod, DR, prod batch 1, prod batch 2. Una migración tiene la suya. Puedo filtrar por país, por ambiente, por tipo de cambio. Si tengo un upgrade para el país X y otro upgrade distinto para el mismo país semanas después, los veo en el mismo timeline y manejo la separación y las dependencias sin perder el hilo. Arrastro una cadena en el calendario, las tareas se ajustan solas — release, sprint, responsable — y se refleja automáticamente en Jira.
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. Le pido que analice un EPIC, que genere la estructura en fases con parents e hijos lista para crear en el proyecto. Yo reviso, ajusto lo que no cuadra con la realidad del equipo, y ejecuto. Lo que antes tomaba horas ahora toma minutos.
Hoy lo uso yo como TPM. La idea es primero sacarle el máximo provecho en esta etapa — tenemos mucho en el pipeline — y en una siguiente fase abrirlo al equipo con accesos por rol: cada ingeniero con visibilidad de lo que le corresponde, sin que todo pase por una sola persona.
Un ejemplo real del pipeline
En un mercado (sin nombre) teníamos tres críticas a la vez: upgrade plataforma 1, upgrade plataforma 2 y migración DRM — tres EPICs en Jira. El management no preguntaba si había ventana; preguntaba qué va primero, qué impacta más en prod y cómo alinear network, services, main y backup.
En el planner las tres son chain templates del mismo país. Ahí se ve lo que Jira no muestra: un ingeniero con dos tareas el mismo día, un backup que choca con otra actividad, o la operación más compleja ejecutada antes y bloqueando el resto sin poder atribuir un fallo.
La regla es simple: preprod para las tres → validación con los equipos → DR con los upgrades (una semana entre cadenas) → runbook mejorado → el upgrade que mejor salió → DRM → la operación más compleja al final. Si algo falla, sabemos de dónde vino.
Cuando el problema es una persona, filtro por responsable. Para network y services, exporto desde el portal main, backup, fechas y riesgo — sin armar slides desde cero.
3. ⚡ Lo que cambió de verdad
Sí, ahorro tiempo. Pero eso no es lo principal.
Antes, gran parte de la semana se iba en armar el cuadro para que otros pudieran decidir: sacar datos de Jira, cruzarlos con correos, revisar runbooks en Excel, dibujar un timeline en PowerPoint y rezar para que siguiera vigente el día de la reunión. Eso no es liderar un cambio en producción. Es ensamblar información — la misma distinción que comenté en No estudié para ser PM. Y si te demoras tres días en armarlo, cuando presentas el pipeline ya cambió.
Ahora llego a la reunión con la imagen hecha — o la actualizo en minutos. El tiempo se va en otra cosa:
- ¿Este cambio va antes o después del otro?
- ¿Esa semana hay capacidad y ventana de verdad, o solo hay fechas puestas en el calendario?
- ¿Lo que estamos viendo en un país tiene que ver con algo que ya pasó en otro mercado el mes pasado?
El trabajo duro no desapareció: siguen siendo muchos países, muchas actividades y mucha coordinación. La herramienta no lo simplifica. Cambia el tipo de problema. Dejas de pelear por ver qué está pasando y pasas a pelear por decidir qué hacer — que es para lo que un TPM debería estar contratado.
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.