Cómo terminé construyendo la herramienta que necesitaba para liderar un proyecto

Hay un momento en la carrera de cualquier ingeniero que empieza a liderar equipos donde se da cuenta de algo incómodo: las hojas de cálculo ya no alcanzan, los tableros genéricos no reflejan cómo trabaja realmente tu equipo, y las herramientas comerciales están diseñadas para "cualquier equipo", no para el tuyo. Ese fue exactamente el punto de partida de este proyecto.

Necesitaba coordinar un equipo con roles bien distintos entre sí —desarrolladores, DBA, QA, soporte de infraestructura, seguridad de la información, practicantes en formación— y necesitaba hacerlo con visibilidad real: quién está bloqueado, por qué, desde cuándo, y qué le está costando eso al proyecto. Nada de lo que probé encajaba del todo. Así que hice lo que probablemente haría cualquier ingeniero terco: construí mi propia herramienta.

Lo que no esperaba es que esa herramienta terminaría siendo, a la vez, el lugar donde gestiono el trabajo y la prueba viviente de que sé construir software real, de punta a punta.

El reto de liderar sin perder el control

Liderar un equipo pequeño y heterogéneo tiene una tensión constante: necesitas suficiente estructura para que nada se caiga entre las grietas, pero no tanta burocracia que ahogue a la gente que solo quiere avanzar. Esa tensión terminó definiendo casi todas las decisiones de producto de la herramienta.

Por ejemplo: no todos los roles deberían ver lo mismo. Un coordinador necesita visión completa; un desarrollador necesita ver su carga de trabajo sin ruido; y en algún momento necesité un tercer perfil que no encajaba en ninguno de los dos: alguien que solo necesita ver todo —para auditar, reportar o simplemente entender el estado del proyecto— sin ningún riesgo de que toque algo por accidente. Ese fue el origen de un rol de solo lectura que terminé diseñando con un principio de "denegar por defecto": en vez de auditar manualmente cada botón de la aplicación para asegurarme de que ese perfil no pudiera crear o borrar nada, bloqueé toda escritura a nivel global y fui abriendo únicamente las excepciones necesarias (como que la persona pudiera gestionar su propio perfil). Es un enfoque más lento de diseñar, pero muchísimo más difícil de vulnerar por descuido.

También aprendí, de la forma difícil, que los impedimentos reales de un proyecto —esperar a que TI entregue un servidor, por ejemplo— no deberían vivir en un chat de WhatsApp o en la memoria de alguien. Terminé modelando los impedimentos como una entidad de primera clase en la herramienta: quién lo reportó, cuándo, qué tipo de bloqueo es, y una barra en el cronograma que literalmente se sigue alargando mientras el bloqueo sigue activo. Es una forma honesta de decir "esto no se ha movido" sin que nadie tenga que estar recordándolo en una reunión.

Diseñar en contexto, no copiar arquitecturas de otros

Cuando empecé a usar esta misma herramienta para llevar un proyecto de verdad —una solución de gestión financiera para un cliente, con cálculos, auditoría inmutable y datos sensibles de por medio— tuve que tomar una decisión de arquitectura que pone a prueba el ego de cualquier desarrollador: ¿arquitectura hexagonal, con todas sus capas de abstracción, o algo más simple?

La respuesta honesta fue: ni lo uno ni lo otro por moda, sino lo que el contexto real pedía. Un desarrollador solo, en las primeras etapas de un proyecto, con una única fuente de datos de origen. Elegí una arquitectura por capas pragmática —API, servicios, repositorios, modelos— con una regla de dependencia clara y, lo más importante, dejé documentado por escrito cuándo esa decisión dejaría de tener sentido: si el motor de cálculo llegara a necesitar múltiples fuentes de ingesta intercambiables, o si aislar el dominio al cien por ciento se volviera crítico para las pruebas. Documentar el "por qué no" es tan importante como documentar el "por qué sí": es lo que te permite revisar una decisión técnica sin tener que adivinar qué estabas pensando seis meses atrás.

Esa misma disciplina de "diseñar para el contexto, no para la teoría" se repitió una y otra vez: elegir un identificador de usuario flexible en vez de forzar un correo corporativo que ni siquiera existía todavía, o decidir que la autenticación de doble factor fuera autocontenida con TOTP —compatible con Microsoft Authenticator, Google Authenticator o Authy— en vez de esperar meses a que TI habilitara un inicio de sesión corporativo centralizado que todavía no estaba definido. Avanzar con lo que sí puedes controlar, dejando explícitamente anotado lo que depende de terceros.

Lo que se construyó

Con el tiempo, la herramienta creció mucho más allá de un tablero Kanban:

• Gestión jerárquica completa de épicas, historias de usuario, tareas y subtareas, con dependencias entre tareas, tareas recurrentes y una vista de mapa para visualizar cómo se conecta todo.
• Motor de agenda automático de un solo recurso que reparte el trabajo estimado en bloques de jornada laboral, respeta fines de semana, y se puede volver a calcular cuando se inserta trabajo nuevo en medio del backlog.
• Control de acceso granular por rol y por área, incluyendo permisos cruzados explícitos cuando alguien necesita asignar trabajo fuera de su área habitual, y ahora también autenticación de doble factor con códigos de respaldo de un solo uso para cuando alguien pierde el teléfono.
• Trazabilidad completa: un log de auditoría de cada cambio relevante, evidencias adjuntas por tarea, comentarios y observaciones versionadas, e impedimentos formales con su propio ciclo de vida.
• Reportes reales, no cosméticos: exportación a Excel y PDF, un daily standup con análisis asistido por IA, y un informe ejecutivo pensado para alguien que no necesita —ni quiere— entrar a ver el tablero.
• Pipeline de despliegue real: contenedores Docker, Nginx como proxy inverso con TLS automático, y un servidor compartido donde conviven varios proyectos con su propia base de datos, sus propias credenciales y su propia llave de despliegue, cada uno aislado del resto.

Cuando la herramienta se convierte en la prueba

La parte que más disfruté de todo esto fue el momento en que la herramienta dejó de ser "el proyecto" y se convirtió en el lugar donde documento otro proyecto real, para un cliente real, con las mismas exigencias de seguridad y trazabilidad que cualquier producto financiero exige. Ahí encontré algo que no esperaba: los errores que cometí en un proyecto se volvieron lecciones documentadas que evité repetir en el otro. Por ejemplo, entendí de la forma difícil que ciertas inicializaciones de una aplicación web nunca se ejecutan cuando el proceso arranca bajo un servidor de producción real en vez de correrlo directamente, y esa lección, ya documentada, me permitió evitar exactamente el mismo error semanas después, en un proyecto completamente distinto, antes de que causara un solo minuto de indisponibilidad.

Eso es, para mí, la diferencia entre acumular código y acumular criterio.

El beneficio real

Al final, el beneficio no fue "tener un tablero bonito". Fue poder mostrarle a mi equipo y a los interesados del proyecto algo concreto en cada punto del camino: qué se prometió, qué se entregó, qué está bloqueado y por qué, y quién es responsable de cada pieza, incluso cuando la infraestructura "oficial" todavía no estaba lista y tuve que desplegar un ambiente temporal solo para poder demostrar avances mientras esa entrega seguía pendiente.

Cumplir metas, en un proyecto real, casi nunca es una línea recta. Es una sucesión de decisiones pequeñas y honestas sobre qué construir, qué posponer, y qué documentar para no volver a discutirlo dos veces. Esta herramienta terminó siendo, sin planearlo así al principio, la forma más honesta que encontré de llevar esa cuenta.