Qué es la deuda técnica y cuánto le está costando a tu empresa
La deuda técnica es el sobrecoste que pagas cada mes por los atajos que se tomaron al construir tu software: código escrito con prisa, versiones sin actualizar, pruebas que nunca se hicieron y decisiones que tenían sentido cuando erais cuatro personas y hoy ya no. El término lo acuñó el programador Ward Cunningham en 1992 con una metáfora financiera muy precisa: puedes pedir prestado tiempo para entregar antes, pero devuelves intereses en forma de cada cambio futuro, que cuesta más y rompe más cosas. No es un problema técnico para que lo resuelvan los técnicos: es una partida de gasto que aparece en tu cuenta de resultados disfrazada de «esto tarda mucho».
Por qué aparece incluso cuando todo se hizo bien
Hay deuda deliberada y deuda heredada, y conviene distinguirlas porque se tratan distinto.
- Deliberada y consciente: decides salir al mercado en ocho semanas sabiendo que esa parte habrá que rehacerla. Es una decisión legítima, siempre que quede anotada.
- Por desgaste: el software no se estropea, pero su entorno cambia. Las dependencias envejecen, los sistemas operativos móviles cambian cada año y lo que ayer era estándar hoy está descatalogado.
- Por crecimiento: lo que funcionaba con 200 pedidos al día se arrastra con 5.000. La arquitectura era correcta para el tamaño de entonces.
- Por rotación: cada equipo que pasa deja su estilo. Sin documentación ni criterios comunes, acabas con tres formas distintas de hacer lo mismo.
- Accidental: simplemente no se sabía hacer mejor en ese momento.
Solo la primera se puede evitar. Las demás se gestionan, igual que gestionas el mantenimiento de una nave o de una flota de vehículos.
Las señales que ve alguien que no es técnico
No hace falta leer código para detectarla. Estos síntomas son bastante fiables:
- Todo tarda más que antes. Un cambio que hace dos años era de dos días ahora se presupuesta en dos semanas, y nadie sabe explicar por qué.
- Cada mejora rompe otra cosa. Tocas facturación y se cae el buscador.
- Solo una persona sabe tocar cierta parte. Cuando esa persona está de vacaciones, ese módulo se congela.
- Las subidas a producción dan miedo y se hacen los viernes por la noche o directamente se posponen.
- Hay tareas manuales que compensan al software: alguien exporta un Excel cada mañana porque «el sistema no lo saca».
- Tu proveedor evita ciertas peticiones o te propone rehacerlo todo ante cualquier cambio mediano.
Cómo poner un número a lo que te cuesta
La deuda técnica se vuelve accionable cuando la traduces a euros. No necesitas una auditoría de seis cifras: con los datos que ya tienes puedes estimarla.
- Sobrecoste de desarrollo: compara lo que cuesta hoy una funcionalidad media con lo que costaba hace dos años. Si el mismo tipo de cambio pasó de 20 a 35 horas, ese 75 % extra multiplicado por los cambios anuales es dinero real.
- Horas de personas compensando al sistema: suma las horas mensuales que tu equipo dedica a copiar datos entre sistemas, corregir errores repetidos o rehacer informes a mano, y multiplícalas por su coste hora.
- Incidencias: cuántas al mes, cuánto se tarda en resolverlas y qué facturación se pierde mientras algo está caído.
- Coste de oportunidad: qué mejora comercial llevas un año sin lanzar porque «con el sistema actual no se puede».
La suma de esas cuatro partidas suele sorprender a la dirección. Y es la cifra que convierte una conversación técnica en una decisión de inversión.
Qué deuda conviene pagar y cuál no
No toda la deuda hay que devolverla. La regla es pagar primero la que está en el camino de lo que quieres hacer en los próximos doce meses.
| Tipo de deuda | Ejemplo | Qué hacer |
|---|---|---|
| De seguridad | Dependencias con vulnerabilidades conocidas, versiones sin soporte | Corregir siempre y cuanto antes |
| De cumplimiento | Tratamiento de datos que no encaja con el RGPD, accesibilidad pendiente | Planificar con fecha, no es opcional |
| En zona caliente | El módulo que tocas cada mes y que siempre da problemas | Refactorizar por partes, con pruebas |
| En zona fría | Un módulo feo que nadie toca desde hace tres años y funciona | Dejarlo como está y documentarlo |
| Cosmética | Estilos de código inconsistentes sin impacto funcional | Arreglarlo solo al pasar por ahí |
Ese criterio —seguridad y cumplimiento primero, después lo que tocas a menudo— evita el error más caro: reescribirlo todo para acabar con los mismos problemas en un código nuevo.
Cómo reducirla sin parar el negocio
Parar seis meses para «limpiar» no es viable casi nunca, y además es arriesgado. Lo que funciona es una estrategia continua:
- Reserva capacidad fija: un porcentaje estable de cada ciclo de trabajo dedicado a deuda, acordado por escrito con tu proveedor o tu equipo. Si no está reservado, siempre gana la funcionalidad urgente.
- Regla del campamento: cada vez que se toca un área, se deja algo mejor de como estaba.
- Red de pruebas antes de tocar: escribir pruebas automáticas sobre lo que ya funciona es la inversión que permite cambiar sin miedo.
- Actualizaciones periódicas de dependencias y versiones, en pequeño y a menudo, en lugar de un salto gigante cada cuatro años.
- Sustitución por trozos: reemplazar módulo a módulo, dejando el resto en funcionamiento, en vez de un cambio total el mismo día.
- Documentar decisiones: una página por decisión importante ahorra semanas al siguiente equipo.
Un caso que se repite en muchas empresas
Una distribuidora con veinte empleados nos describía así su situación: cambiar la tarifa de un proveedor en su sistema de pedidos requería avisar con una semana de antelación, y aun así fallaba alguna referencia. Mientras tanto, dos personas de administración dedicaban cada mañana hora y media a cuadrar a mano los precios entre el sistema de pedidos y la contabilidad. Nadie lo llamaba deuda técnica: lo llamaban «así trabajamos aquí».
Al ponerle números, esas tres horas diarias eran el equivalente a casi media jornada completa al año, sin contar los errores de facturación que generaban. Actualizar solo el módulo de tarifas costaba bastante menos que un año de ese trabajo manual, y además desbloqueaba la promoción mensual que llevaban dos años sin poder lanzar. La conversación dejó de ser técnica en cuanto apareció la cifra.
Cómo hablarlo con tu proveedor o tu equipo
Pide que la deuda se haga visible: una lista priorizada de puntos débiles, con el impacto de cada uno en tiempo y riesgo, y una propuesta de orden. Pregunta también qué parte de la última entrega ha generado deuda nueva y por qué. Un proveedor serio responde a eso sin ponerse a la defensiva.
Y ten cuidado con dos discursos opuestos e igualmente sospechosos. El de «hay que rehacerlo todo desde cero» sin haber medido nada, y el de «esto no se toca» que convierte tu software en una caja negra que solo entiende una persona. Entre ambos está el trabajo real: medir, priorizar y avanzar por partes.
El resumen: es una decisión de negocio, no un capricho técnico
La deuda técnica no se elimina, se administra. Detéctala por sus síntomas —todo tarda más, todo se rompe, nadie quiere tocarlo—, ponle un número sumando sobrecostes, horas manuales, incidencias y oportunidades perdidas, y decide qué pagas primero: siempre seguridad y cumplimiento, después lo que tocas cada mes. Reserva capacidad fija para ello y exige que sea visible en cada entrega. Una empresa que gestiona su deuda técnica entrega cambios en días en lugar de en meses, y esa velocidad se nota en las ventas. Si quieres saber cuánta deuda arrastra tu aplicación y qué conviene abordar primero, escríbenos y la revisamos contigo antes de que decidas nada.
Artículos relacionados
Preguntas frecuentes sobre
Cómo mejorar mi negocio con la metodología Anticompetencia
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.