La deuda técnica es el costo acumulado de cada atajo, y los dueños de negocio rara vez la valoran bien. De dónde viene, cómo saber si ya es crítica y cómo presentarla como inversión.
La deuda técnica es el costo acumulado de cada atajo y de cada decisión de "lo arreglamos después". Los desarrolladores la entienden por intuición. Los dueños de negocio rara vez la valoran bien, y esa es la brecha que queremos cerrar aquí.
La respuesta corta es que la deuda técnica casi siempre cuesta más de lo que cuesta pagarla, y que se presenta mejor como una inversión para quitar fricción del crecimiento que como "arreglar problemas". Así se piensa en términos de negocio.
¿De dónde viene la deuda técnica?
Se acumula desde tres fuentes.
Deuda deliberada. Decisiones tomadas a conciencia para lanzar más rápido, sabiendo que la implementación no es la ideal. "Lo refactorizamos después del lanzamiento" es un contrato de deuda. La pregunta es si la pagas a tiempo o la dejas acumular intereses.
Deuda accidental. Código que era razonable cuando se escribió y se volvió un pasivo conforme el negocio evolucionó.
Deuda heredada. Lo que recibes cuando adquieres una base de código existente, o cuando el desarrollador original de un sistema crítico ya no está disponible.
¿Cómo saber si tu deuda ya es crítica?
- Las nuevas funciones tardan mucho más de lo esperado
- Los despliegues son eventos estresantes que requieren varias personas en espera
- Tu equipo tiene miedo de tocar ciertas partes del código
- Las integraciones de terceros se rompen con frecuencia y de formas inesperadas
- Llevas más de seis meses "planeando una reescritura"
¿Cómo presentar la inversión?
No presentes la inversión técnica como "arreglar problemas". Preséntala como "eliminar fricción del crecimiento". Cada limitación técnica que frena a un desarrollador también frena la capacidad del negocio que ese desarrollador intenta construir. El cálculo de ROI debe incluir las horas de mantenimiento ahorradas y, además, el valor de entregar funciones más rápido.