Diagnóstico y backlog
Cómo evalúo y bajo la deuda técnica
Casi todas las llamadas que empiezan con “creo que tenemos un problema de deuda técnica” en realidad preguntan dos cosas: qué tan grave es, y si puedo confiar en el equipo que lo construyó. Te cuento cómo lo encaro yo.
Punto de partida
Qué miro antes del código
La deuda técnica se detecta mirando cómo se comporta el código: qué es lento de cambiar y qué nadie quiere tocar. Por eso arranco por tres señales, antes de opinar sobre tu stack.
Cómo están los tests
¿Un dev puede hacer un cambio que da miedo y enterarse en noventa segundos si rompió algo? Si la respuesta es “clickeamos por ahí y rezamos”, esa es tu deuda. Todo lo demás sale de ahí.
Acoplamiento y puntos calientes
¿Cuántos archivos tocás para agregar un campo a un formulario? Los archivos que aparecen en uno de cada tres commits son donde tu equipo pierde tiempo, y casi siempre son los mismos.
El pipeline de deploy
¿Cuánto pasa entre “terminé” y “está en producción”? ¿Quién puede hacerlo y qué pasa cuando se rompe? Un deploy lento, manual y de una sola persona me dice más que cualquier diagrama de arquitectura.
Prioridades
Deuda que te cuesta hoy y deuda que puede costar mañana
Cuarenta cosas feas anotadas en una planilla desmoralizan al equipo y no le dicen a nadie por dónde empezar. La mayoría de esa lista está bien, pero lo único que importa es: ¿te está costando plata hoy, o puede costarte algún día?
La que te cuesta hoy
Tiene pulso y se puede medir. El flujo que se rompe cada vez que alguien toca checkout. El servicio que nadie quiere deployar un viernes. La migración a medio terminar que cada feature nueva tiene que esquivar.
La que puede costar mañana
Lo arquitectónico: el monolito que va a doler partir cuando seas tres veces más grande, la base que va a necesitar sharding a una escala que todavía no tenés. Es real, y puede esperar.
El entregable
Un backlog de deuda
Lo que recibís es un mapa. Cada ítem lleva tres cosas, sino es una carta de deseos.
Qué te cuesta hoy
Un número real, en tiempo. “Cada cambio en checkout pone en riesgo el onboarding: unos dos días extra de testing por release.” Si no puedo ponerle un número, no entra en la lista.
Qué cuesta arreglarlo
Con honestidad, incluida la parte donde la estimación es una adivinanza. Doy un rango y digo de qué depende. Después ordeno por la relación entre lo que cuesta hoy y lo que cuesta arreglarlo, y arriba queda lo obvio.
Qué destraba
Pagar deuda que no hace más rápidas a las próximas diez features es un proyecto de vanidad. Si arreglarlo solo deja el código más lindo, esperá.
Casi nunca es “reescribir la arquitectura”. Casi siempre es “dejar la suite de tests abajo de cinco minutos para que la corran” o “borrar la mitad muerta de la migración”.
El método
Bajar la deuda sin frenar el roadmap
El diagnóstico es la mitad barata. Acá es donde el trabajo de deuda se muere: todos coinciden en que el mapa está bien, y después nadie quiere ser el que le dice al board que este trimestre no sale ninguna feature. Por eso la deuda se paga adentro del trabajo de features.
Una porción fija de cada ciclo
“Ordenamos después del lanzamiento” no sobrevivió jamás. Lo que funciona es una porción fija de cada ciclo reservada para el equipo.
Arreglala donde ya estás parado
Los archivos que tu equipo evita suelen ser los mismos a los que el roadmap lo manda una y otra vez. Pagá deuda en el módulo que ya estás tocando.
Envolvela y después reemplazala
Para la cosa grande que nadie quiere tocar, el strangler pattern: ponés una capa nueva adelante del sistema viejo y movés una porción por vez atrás de ella. Nunca hay un día del big bang.
Te vas a dar cuenta de que funciona antes que cualquier gráfico. El cambio que todos temían deja de ser trabajo de dos personas. Alguien deploya un viernes sin avisarle a nadie.
La conversación
Decir la verdad sin hundir al equipo
El entregable no es el mapa. Es un fundador que puede tomar una decisión y un equipo que todavía quiere estar ahí la semana que viene.
Los fundadores quieren una nota: “¿nuestro código está bien o mal?”. No hay respuesta honesta a eso, así que no la doy. Lo replanteo en lo único sobre lo que un negocio puede actuar: qué te está costando, y qué se hace al respecto.
El mejor resultado es un equipo que ya no le tiene miedo a su propia deuda, con una lista corta en la que cree, entregando un poco más rápido cada mes. Para eso me contratan, en general. Solo que inicialmente luce como un problema de código.
Perfil
¿Quién Soy?
Soy Ezequiel Actis Grosso, líder de tecnología con 25 años en software — de Buenos Aires a Miami, y de San Francisco a Sídney, en corporaciones globales y en startups.
En la última década trabajé con founders en Latinoamérica y Estados Unidos — para mejorar el delivery, encontrar product-market fit y escalar sus productos B2B SaaS, sin sobre-ingeniería ni procesos excesivos.
Ezequiel Actis Grosso
CTO Fraccional
- Arquitectura para productos AI en producción
- Due diligence técnica para inversores
- De cero a primer cliente con delivery de MVP
Próximo paso
Una lectura honesta de tu deuda técnica
Te digo qué te está costando velocidad hoy, qué podés ignorar tranquilo y dónde están los arreglos baratos que mueven la aguja, en términos de negocio. A veces alcanza con una tarde.
FAQ
Preguntas frecuentes
¿Qué es un diagnóstico de deuda técnica?
Mide la diferencia entre lo que tu equipo puede entregar hoy y lo que podría entregar antes de que el código lo frenara. Bien hecho, es menos un inventario de cosas feas y más una cuenta: qué te cuesta la deuda por mes, en tiempo.
¿Qué mirás primero al evaluar deuda técnica?
Tres cosas, antes de opinar sobre tu framework: cómo están los tests (si un dev puede hacer un cambio riesgoso y enterarse en noventa segundos), el acoplamiento (cuántos archivos tocás para agregar un campo) y el pipeline de deploy (cuánto tarda, quién puede hacerlo y qué pasa cuando se rompe)."I'm done y el pipeline de deploy (cuánto tarda, quién puede hacerlo y qué pasa cuando se rompe). El historial de git me dice dónde cambia el código, que casi nunca es donde el equipo cree.
¿Cuál es la diferencia entre la deuda que cuesta hoy y la que puede costar mañana?
La que cuesta hoy tiene pulso medible: el servicio que nadie deploya un viernes, la migración a medio terminar que cada feature tiene que esquivar. La que puede costar mañana es arquitectónica: el monolito que va a doler partir cuando seas más grande. La primera se paga ya; la segunda se anota y espera.
¿Cómo leés un código sin que el equipo se sienta auditado?
No le pregunto al código dónde están los muertos: le pregunto a la gente. “Si tuvieras una semana libre para arreglar una sola cosa que no te dejan arreglar, ¿cuál sería?” Todo ingeniero tiene la respuesta lista, y esa lista suele ser mejor que cualquier métrica. El encuadre importa: la deuda es una propiedad del código, y tratarla como un veredicto sobre quien lo escribió mata la conversación.
¿Conviene reescribir todo de cero?
Casi nunca. El código feo que querés tirar es una bitácora: cada condicional raro es un bug de producción que alguien ya arregló. Envuelvo el sistema viejo y lo reemplazo por partes, para que el negocio no se detenga mientras tanto.
¿Cómo se lo contás a los fundadores sin hundir al equipo?
Los fundadores quieren una nota, y no hay respuesta honesta a eso, así que no la doy. Lo replanteo como una decisión de presupuesto: esto es lo que te cuesta la deuda por mes, esto es lo que cuesta arreglarla, y esto es lo que destraba. Nadie queda como el culpable.
¿Cómo se baja la deuda sin frenar las features?
Negándome al trimestre de limpieza. La deuda que necesita su propio sprint necesita un caso de negocio, y esa discusión la pierde contra facturación siempre. En cambio: una porción fija de cada ciclo, aplicada al módulo que el roadmap ya te está haciendo tocar.
¿Cuánto tarda?
Lo de arriba de una buena lista suele ser cuestión de días: dejar la suite de tests abajo de cinco minutos, borrar la mitad muerta de una migración, automatizar el deploy. Lo arquitectónico lleva meses y casi nunca es lo primero.
¿Cuándo no vale la pena medirla?
Antes del product-market fit. En esa etapa el código tiene que ser descartable, porque la mitad se tira cuando descubrís qué estás construyendo en realidad. Medir deuda ahí es optimizar algo que todavía no existe.