El feature de 6 horas que nunca debió construirse

Un gerente nuevo estaba a punto de solicitar una funcionalidad de 6-8 horas de desarrollo para resolver algo que la plataforma ya podía hacer. Mostrarle los reportes existentes, en vivo, evitó el desarrollo innecesario y le dejó un modelo mental más sólido de las herramientas.

La solicitud que parecía razonable

Uno de mis gerentes, todavía familiarizándose con el alcance completo de nuestras herramientas, estaba manejando el onboarding de un cliente nuevo. El cliente había pedido monitoreo en tiempo real de ciertas tareas. Mi gerente, razonablemente, concluyó que necesitábamos un reporte consolidado nuevo — pero ese tipo de reporte estaba diseñado, por arquitectura, para ingesta de datos asíncrona y periódica; correrlo en intervalos cortos arriesgaba perder información. Iba directo a escribir una solicitud de funcionalidad para algo que, en realidad, no hacía falta construir.

Nada se construye hasta no ver lo que ya existe

Me senté con él, caminamos juntos los modelos existentes en una llamada síncrona, corrí una demo en vivo, y le mostré los reportes que la plataforma ya tenía — que respondían exactamente lo que el cliente estaba pidiendo. No dejé que la solicitud avanzara. Me aseguré de que entendiera no solo el qué, sino el porqué: qué reporte está diseñado para qué tipo de patrón de datos, para que no se topara con la misma pared la próxima vez.

El costo que se evitó

El resultado: cerramos la brecha entre lo que se le había prometido al cliente durante el ciclo de venta y lo que realmente podía ver en el producto, sin construir nada innecesario. Esa solicitud de funcionalidad hubiera tomado, conservadoramente, entre 6 y 8 horas entre diseño, construcción, pruebas y documentación — para algo que la plataforma ya podía hacer.

No es una anécdota menor

No es una anécdota menor. La investigación de deuda técnica de Stripe (encuesta a más de 1,000 desarrolladores y 1,000 ejecutivos C-level) encontró que los ingenieros dedican en promedio 17.3 horas por semana — 42% de su semana laboral — a mantenimiento y código innecesario en vez de desarrollo nuevo. McKinsey estima que los CIOs calculan que entre 20% y 40% del valor de su patrimonio tecnológico está atrapado en deuda técnica acumulada. Cada funcionalidad que se construye sin necesitarse de verdad no es un costo aislado — es una contribución directa a ese número.

Lo que me llevo

Lo que me llevo de esa sesión no fue solo haber evitado 6-8 horas de trabajo. Fue que mi gerente salió de ahí con un modelo mental claro del set de herramientas, no solo con la respuesta a un ticket — y esa diferencia se paga sola la siguiente vez que enfrente una solicitud parecida.

Fuentes de datos: Stripe — Developer Coefficient (o encuesta de deuda técnica, más de 1,000 desarrolladores y 1,000 ejecutivos; 17.3 h/semana promedio en mantenimiento y código innecesario); McKinsey 2024 State of Organizations Report (20-40% del patrimonio tecnológico atrapado en deuda técnica).