El Costo del Trabajo Invisible

El trabajo invisible es cualquier esfuerzo que el equipo está dedicando que no se rastrea en un sistema compartido. Es más común de lo que la mayoría de los equipos admiten, y toma formas predecibles:

• Decisiones en hilos de Slack. Un hilo de 40 mensajes entre dos ingenieros resuelve una pregunta de diseño, pero la decisión nunca llega al ticket o a la descripción del PR. Seis meses después, alguien revierte la decisión porque no sabía que se había tomado.
• Tareas de "yo simplemente lo hago". Un ingeniero nota una prueba inestable, pasa dos horas arreglándola y nunca crea un ticket. El trabajo sucedió, el tiempo se gastó, pero el plan de capacidad del equipo no lo refleja — y nadie aprende de la corrección.
• Proyectos paralelos y spikes. Trabajo exploratorio que vive en una rama local, nunca se revisa y o muere silenciosamente o aparece como un PR sorpresa tres semanas después.
• Hotfixes sin documentar. Un problema de producción se parchea a las 11 PM con un commit directo a main. Sin ticket, sin post-mortem, sin registro de que la corrección existe o por qué fue necesaria. El siguiente ingeniero que toque ese código no tiene idea de qué están protegiendo las tres líneas misteriosas.

Ninguno de estos es malicioso. Los ingenieros hacen trabajo invisible porque la fricción de rastrearlo se siente más alta que el costo de simplemente hacerlo. Y para cualquier instancia individual, tienen razón — crear un ticket para una corrección de 20 minutos se siente como sobrecarga.

El problema no es ninguna instancia individual. El problema es el patrón.

El trabajo invisible no se mantiene barato. Se acumula de tres maneras que se vuelven más costosas con el tiempo.

El costo de onboarding aumenta. Cada decisión que vive en la cabeza de alguien en lugar de en un ticket o un documento es una decisión que un nuevo miembro del equipo no puede encontrar. Un equipo con seis meses de trabajo invisible requiere una descarga verbal de varias semanas para incorporar a alguien — y esa descarga está incompleta, porque las personas que la dan han olvidado la mitad de lo que hicieron. Los equipos con altas cargas de trabajo invisible reportan rutinariamente tiempos de onboarding de 4–8 semanas para trabajo que debería tomar 2.

El trabajo se duplica. Cuando el ingeniero A no sabe que el ingeniero B ya resolvió el mismo problema el mes pasado, el ingeniero A lo resuelve de nuevo. En un equipo de 10 personas, esto sucede más a menudo de lo que nadie se da cuenta — particularmente con trabajo de infraestructura, funciones de utilidad y cambios de configuración que viven fuera del código base del producto principal.

El contexto se evapora. El código sin un rastro de tickets es código sin un "por qué". El siguiente ingeniero que lo lee ve qué se hizo pero no por qué se hizo, lo que significa que no puede cambiarlo de manera segura. O lo deja solo (acumulando deuda técnica) o lo cambia y rompe la suposición que el autor original estaba protegiendo (creando un bug). Ambos resultados son costosos, y ambos son prevenibles con una descripción de ticket de un párrafo escrita en el momento del trabajo.

La acumulación es lo que hace peligroso al trabajo invisible. Un solo hotfix sin documentar cuesta cinco minutos de pérdida de contexto. Un año de hotfixes sin documentar cuesta semanas de arqueología cada vez que alguien toca esa parte del sistema.