top of page

Muchos equipos, muchas herramientas, pocas decisiones claras

  • hace 2 días
  • 3 Min. de lectura

A medida que las organizaciones crecen, también crece la complejidad de coordinar el trabajo entre equipos técnicos. Nuevas aplicaciones, nuevos servicios, nuevas plataformas y más personas participando en el desarrollo y operación de los sistemas.

Para gestionar esta complejidad, muchas empresas adoptan herramientas de colaboración técnica como Jira, Confluence y otras plataformas del ecosistema Atlassian. Estas herramientas permiten registrar tareas, documentar procesos y coordinar proyectos entre múltiples equipos.


En teoría, el resultado debería ser mayor claridad.

En la práctica, muchas organizaciones descubren algo distinto.

Más herramientas no siempre significa mejores decisiones.

Esto ocurrió en una empresa del sector financiero que había expandido rápidamente su plataforma digital. En pocos años, la organización pasó de tener un equipo de desarrollo centralizado a contar con múltiples equipos distribuidos que trabajaban en distintos componentes del sistema.


Cada equipo gestionaba su backlog en Jira. Cada área documentaba procesos en Confluence. Cada proyecto generaba decenas de tickets, comentarios y archivos asociados.

La información estaba en todas partes.


Pero la claridad no.

Cuando surgían problemas operativos o decisiones arquitectónicas importantes, los equipos se encontraban revisando decenas de tickets y documentos intentando reconstruir el contexto de una decisión.

¿Quién decidió adoptar esa arquitectura de microservicios?

¿Quién aprobó dividir una base de datos en varios servicios independientes?

¿Quién definió los límites entre equipos responsables de cada componente?

Las respuestas no estaban claras.


La organización tenía mucha actividad registrada, pero pocas decisiones documentadas de forma explícita.


Este problema se hizo evidente cuando la empresa inició un proyecto para modernizar su infraestructura tecnológica. El objetivo era migrar parte de sus aplicaciones hacia una arquitectura basada en contenedores ejecutándose sobre Kubernetes.


El proyecto involucraba a múltiples equipos: desarrollo, infraestructura, seguridad, operaciones y arquitectura empresarial.


Cada equipo creó nuevos proyectos en Jira para gestionar sus tareas.

El número de tickets creció rápidamente.


Pero cuando surgían decisiones técnicas críticas como definir políticas de networking entre microservicios o establecer modelos de observabilidad nadie tenía claro dónde debían registrarse esas decisiones.


Algunas se discutían en reuniones. Otras quedaban en comentarios dentro de tickets. Otras simplemente se implementaban sin quedar documentadas.


Con el tiempo, la falta de claridad comenzó a generar problemas operativos.

Equipos distintos tomaban decisiones contradictorias sobre componentes del sistema. Algunos servicios utilizaban herramientas de monitoreo diferentes. Otros implementaban modelos de autenticación distintos.


La arquitectura tecnológica comenzaba a fragmentarse.


La empresa decidió entonces rediseñar su modelo de coordinación técnica.

El primer cambio fue distinguir entre gestión de tareas y gestión de decisiones.


Jira continuó utilizándose para gestionar trabajo operativo: desarrollo de funcionalidades, corrección de errores y planificación de sprints.


Pero las decisiones arquitectónicas comenzaron a documentarse mediante Architecture Decision Records (ADR) almacenados en Confluence y vinculados a los proyectos técnicos.

Cada decisión importante debía incluir:

  • Contexto técnico del problema

  • Alternativas evaluadas

  • Justificación de la decisión

  • Impacto en otros sistemas


Este enfoque permitió que los equipos entendieran no solo qué se estaba haciendo, sino por qué se estaba haciendo.


El segundo cambio fue establecer mecanismos claros de coordinación entre equipos técnicos.


Se definieron espacios específicos dentro de Confluence para documentar estándares técnicos, patrones arquitectónicos y políticas operativas.

Esto permitió reducir la fragmentación tecnológica y alinear decisiones entre diferentes áreas.


Finalmente, se integraron las herramientas del ecosistema Atlassian para mejorar la trazabilidad entre decisiones y ejecución.

Los ADR documentados en Confluence se vinculaban a proyectos y tickets en Jira, permitiendo rastrear cómo una decisión técnica se traducía en tareas concretas dentro del sistema.


El resultado fue una organización más coherente.

Los equipos continuaron trabajando de forma autónoma, pero ahora dentro de un marco donde las decisiones técnicas eran visibles, documentadas y comprensibles para toda la organización.


La experiencia dejó una conclusión clara.


Las herramientas de gestión de proyectos ayudan a coordinar actividad, pero no reemplazan la necesidad de diseñar un modelo de gobernanza técnica.

Cuando las decisiones arquitectónicas no se documentan, las organizaciones terminan acumulando deuda técnica y fragmentación operativa.


En AIT LATAM ayudamos a las organizaciones a diseñar modelos de coordinación técnica que combinan herramientas colaborativas con marcos claros de decisión, permitiendo que equipos grandes operen con coherencia incluso en entornos tecnológicos complejos.

Porque en sistemas empresariales, el problema rara vez es la falta de trabajo.

El problema es la falta de claridad sobre qué decisiones están guiando ese trabajo.


 
 
 

Comentarios


bottom of page