Deute tècnic en empreses: com resoldre el llegat sense aturar el negoci

Com identificar i quantificar el deute tècnic

• Senyals de deute tècnic crític: temps d'onboarding de nous desenvolupadors superior a 3 setmanes, més del 30% de l'sprint dedicat a bugs i no a features, tests manuals perquè el codi no és testable, i pedaços sobre pedaços que ningú entén.
• Quantificació en euros: calcula el cost d'oportunitat. Si un desenvolupament de 2 setmanes tarda 6 per deute tècnic, el cost és 4 setmanes × cost de l'equip.
• Eines d'anàlisi: SonarQube per a deute tècnic quantificat en codi, Datadog o similar per a tracking d'incidències de producció derivades de codi legacy, i entrevistes estructurades amb l'equip.
• Prioritza per impacte: no tot el deute tècnic és igual. El que bloqueja noves funcionalitats és P1; el que alenteix però no bloqueja és P2; el cosmètic o arquitectònic sense impacte en rendiment és P3.

Refactorització vs. reescriptura: com decidir

• Refactorització: quan el codi existent és funcional però desordenat, té tests (o es poden escriure), i l'arquitectura general és correcta. Més segur, més lent, sense risc de segona estimació optimista.
• Reescriptura: quan l'arquitectura és fonamentalment incorrecta, el codi no és testable per disseny, o l'stack tecnològic ha quedat obsolet i no pot evolucionar.
• Regla de Joel Spolsky: mai llencis tot i comencis de zero tret que sigui absolutament inevitable. El programari existent, per lleig que sigui, conté dècades de coneixement de negoci implícit.
• L'enfocament híbrid més efectiu: strangler fig pattern — anar envoltant el sistema legacy amb mòduls nous que progressivament reemplacen funcionalitat.

Estratègies per resoldre el deute sense aturar el negoci

• Reserva del 20-30% de la capacitat de l'equip per a deute tècnic en cada sprint. No un sprint dedicat cada 3 mesos — un percentatge constant.
• Defineix el 'Boy Scout Rule': l'equip es compromet a deixar sempre el codi una mica millor de com el va trobar.
• Estableix 'Definition of Done' amb criteris tècnics: cap tiquet es tanca sense cobertura de tests, sense documentació bàsica i sense revisió de codi.
• Comunica a la direcció en termes de negoci: no 'refactoritzarem el mòdul de comandes' sinó 'reduirem el temps d'afegir noves integracions de 6 setmanes a 2 setmanes'.

Com prevenir l'acumulació futura de deute tècnic

• Arquitectura modular des de l'inici: els sistemes ben desacoblats envelleixen molt millor.
• Tests des de l'inici: el codi sense tests és deute tècnic des del dia u.
• Code review obligatori: els problemes tècnics detectats en review costen un 10% del que costaran quan estiguin en producció.
• Revisió tècnica trimestral: programa una sessió cada 3 mesos per revisar l'estat tècnic del sistema i planificar el deute del trimestre següent.

Recursos relacionats