3 tipos principales de deuda técnica y cómo gestionarlos

Los 3 tipos principales de deuda técnica son: diseño deliberado, accidental/obsoleto y putrefacción.

Así como la deuda financiera inteligente puede ayudarlo a alcanzar los principales objetivos de la vida más rápido, no toda la deuda técnica es mala, y administrarla bien puede generar enormes beneficios para su empresa.

Esto es particularmente cierto para las empresas de rápido crecimiento, que tienen una necesidad crítica de enviar productos temprano y con frecuencia para determinar el ajuste del producto/mercado, satisfacer las necesidades de los clientes y aprovechar las oportunidades emergentes. Pero al igual que la deuda financiera, debe ser inteligente al incurrir en deuda tecnológica. A largo plazo, la deuda acumulada puede reducir la velocidad de envío, causar problemas de moral a los desarrolladores o incluso hundir su negocio por completo.

Dag Liodden ha estado administrando la deuda técnica durante más de 14 años, más recientemente como cofundador y director de tecnología de la empresa de tecnología publicitaria Tapad , a la que ayudó a guiar hacia una adquisición de $ 360 millones. Si bien no existe una solución única para todos, Dag descubrió que clasificar la deuda en categorías ayuda a comunicar y abordar los problemas de deuda tecnológica en los equipos y entre ellos. Compartió los tres tipos principales de deuda tecnológica y su estrategia para abordar cada uno con FirstMark .

Dag Liodden hablando en la Cumbre CTO anual de FirstMark

1. Deuda técnica deliberada

A menudo, los ingenieros sabrán que existe la forma correcta de hacer algo y la forma rápida de hacerlo, dice Dag. En muchos casos, la forma rápida es la forma correcta (para evitar el exceso de ingeniería), pero a veces el equipo intencionalmente hará algo de la manera "incorrecta" porque necesita entregar rápidamente el producto al mercado.

"A veces contraemos deliberadamente deuda tecnológica para reducir el tiempo de comercialización".

Al tomar esta ruta, considere no solo cuánto tiempo ahorrará al lanzar una función, sino también cuánto se necesitará para pagar la deuda explícitamente contraída. Asegúrese de que las partes interesadas sean conscientes de que esto inevitablemente ralentizará otros lanzamientos de funciones más adelante.

Cómo abordarlo: la implementación ágil de su equipo puede no estar de acuerdo, pero Dag descubrió que generalmente tiene sentido rastrear este tipo de deuda tecnológica en la cartera de pedidos cuando se pospone deliberadamente el trabajo que debe completarse. Si no se realiza un seguimiento específico, es poco probable que se pague y se convertirá en una deuda de diseño accidental con el tiempo. Los propietarios de productos y las partes interesadas deben ser responsables de la acumulación de este tipo de deuda a medida que se incurre en decisiones comerciales.

2. Deuda de tecnología de diseño accidental/obsoleta

Al diseñar sistemas de software, el equipo de Dag intenta equilibrar la previsión y la preparación de sus diseños para el futuro con simplicidad y entrega rápida. Este es un equilibrio complicado, advierte, y nadie lo hace bien siempre. A medida que los sistemas evolucionan y los requisitos cambian, es posible que se dé cuenta de que su diseño tiene fallas o que la nueva funcionalidad se ha vuelto difícil y lenta de implementar. Un buen diseño original a menudo será más fácil de refactorizar de forma incremental, pero a veces es posible que tenga que morder la bala y hacer una refactorización más significativa.

Cómo abordarlo: Cómo refactorizar significativamente bien un sistema es un tema enorme en sí mismo, pero es completamente natural que esto deba suceder de vez en cuando (más o menos cada dos años cuando el sistema está en un estado "estable"). De lo contrario, podría aplicar una ingeniería excesiva al sistema en primer lugar e incurrir en ralentizaciones innecesarias todo el tiempo. Los líderes de equipo/tecnología y los propietarios de productos deben ser responsables de garantizar que se reserve tiempo para resolver este tipo de deuda tecnológica, ya que se incurre en decisiones de diseño y requisitos que cambian con frecuencia.

3. Deuda técnica de la podredumbre de bits

La deuda tecnológica de Bit Rot ocurre con el tiempo. Un componente o sistema se convierte lentamente en una complejidad innecesaria a través de muchos cambios incrementales, a menudo exacerbados cuando trabajan en él varias personas que podrían no comprender completamente el diseño original. Los síntomas son, entre otros, programación copy-paste y cargo-cult.

Cómo abordarlo: este es quizás el único tipo de deuda tecnológica que debe tratar de evitar constantemente, dice Dag, mediante la refactorización continua. Los equipos fuertes se tomarán el tiempo para comprender el diseño del sistema en el que están trabajando (incluso si no lo diseñaron originalmente), mejorarán gradualmente el diseño y limpiarán el código defectuoso en el camino. El equipo de desarrollo debe ser responsable de evitar la deuda tecnológica bit rot, ya que la incurren los desarrolladores individuales.

Si bien la categorización de la deuda tecnológica no hará que sea fácil de manejar por arte de magia, puede permitir conversaciones más productivas y fortalecer a su equipo. La deuda tecnológica siempre existirá y debería existir en los sistemas. Es esencial que intente comprender cómo la deuda está ralentizando a su equipo y equilibre los esfuerzos de ofrecer funciones a corto plazo con el aumento de la productividad general a medio y largo plazo.

Para obtener más lecciones comerciales tácticas de expertos de la industria tecnológica, suscríbase al boletín FirstMark .