¿Qué es la deuda técnica (y tienes demasiada?)
Al comienzo de mi carrera como recién nombrado jefe asociado de producto, cuando escuché por primera vez sobre la deuda técnica (también conocida como deuda tech), no estaba muy seguro de lo que significaba. Graciosamente, pensé que se refería a un préstamo que habíamos solicitado para adquirir un software de terceros, y usé el término erróneamente con confianza durante dos o tres semanas. ¡Imagina mi vergüenza cuando mis ingenieros me apartaron después de la reunión diaria para corregirme amablemente!
Así que, para ahorrarnos a todos un poco de sonrojo en el trabajo y ayudarnos a ganar credibilidad entre los ingenieros, vamos a profundizar en qué es la deuda técnica y por qué, como jefes de producto, debemos preocuparnos por ella.
¿Qué es la deuda técnica y cuándo es un problema?
El desarrollo de software consiste en equilibrar la amplitud de la funcionalidad del producto con un código de alta calidad. En el camino, a veces tomamos atajos para acelerar el proceso de desarrollo—estos atajos se llaman deuda técnica o deuda tech.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
¿Cuándo es buena idea asumir deuda técnica y cuándo se convierte en una bomba de tiempo? Para responder a esta pregunta, primero analizaremos la historia de la deuda tech.
¿Qué es la deuda técnica?
Ward Cunningham, la persona que acuñó el término, compara la deuda técnica con la deuda financiera: está bien pedir prestado contra la velocidad y estabilidad futuras, pero debemos pagar la deuda eventualmente. Es un concepto que todo equipo de desarrollo debe comprender, y que todo jefe de producto debe considerar al tomar decisiones sobre el producto.
La deuda tech nos ayuda a lanzar productos antes de lo previsto y a llevar productos a las manos de los clientes más rápido. Pero, debemos eventualmente “pagar la deuda” invirtiendo en la calidad de nuestra base de código.
Idealmente, deberíamos decidir activamente si queremos aprovechar la deuda técnica o evitarla. Al igual que con la deuda financiera, ¡no queremos sorprendernos luego con un coste imprevisto!
Una definición simplificada de deuda técnica
La deuda técnica (también llamada deuda de código en algunos equipos), se refiere al coste implícito del trabajo futuro necesario cuando eliges un atajo a corto plazo en lugar de una mejor solución que tomaría más tiempo. Es como pagar intereses en un préstamo: el coste de la deuda técnica aumenta con el tiempo.
Una analogía que suelo usar es el afeitado de una barba. Si tengo prisa y me afeito rápidamente, probablemente no será el afeitado más limpio, y tendré que volver después para arreglarlo.
El tiempo y el esfuerzo necesarios para ambos afeitados—el inicial y el retoque posterior—serán mayores en total que si me hubiera afeitado bien desde el principio.
¡Pero a veces, cuando se nos acaba el tiempo, tenemos que comprometernos con el afeitado rápido!
Comparación entre deuda financiera y deuda técnica
Para ilustrar este concepto, profundicemos un poco más en la comparación entre deuda financiera y deuda técnica. Al final, los jefes de producto deben entender tanto los conceptos financieros empresariales como los conceptos técnicos de codificación.
Ventajas de la deuda financiera: La deuda financiera permite apalancamiento. Pedir dinero prestado puede proporcionar el capital necesario para invertir en oportunidades de crecimiento. Además, la deuda financiera permite acceso inmediato a recursos o activos sin necesidad de un pago inicial.
Desventajas de la deuda financiera: La deuda financiera tiene muchos tipos de costos. Los pagos de intereses pueden acumularse con el tiempo, reduciendo la rentabilidad general. Además, no gestionar adecuadamente la deuda financiera puede ocasionar inestabilidad económica.
Además, la deuda puede restringir la flexibilidad y evitar que tomemos ciertos caminos en el futuro. E incumplir obligaciones financieras puede dañar la reputación de la organización.
Ventajas de la deuda técnica: La deuda técnica permite un desarrollo inicial más rápido del producto, ayudando a cumplir plazos ajustados o aprovechar oportunidades de mercado. Y, al igual que el apalancamiento financiero, asumir deuda técnica puede reducir los costos iniciales de desarrollo.
Desventajas de la deuda técnica: Así como los intereses se acumulan en la deuda financiera, la deuda técnica se multiplica a medida que se construyen más características o cambios sobre los atajos existentes, haciendo que el desarrollo futuro sea más complejo y costoso. Además, la deuda técnica a menudo resulta en una calidad de código inferior, lo que conduce a mayores costos de mantenimiento con el tiempo.
La deuda técnica puede dificultar la capacidad de un producto para adaptarse a los cambios en el mercado o para incorporar nuevas funcionalidades. Y la deuda técnica no resuelta puede llevar a fallos del sistema, vulnerabilidades de seguridad o problemas de rendimiento, afectando la viabilidad del producto.
¿Qué significa esto para nosotros? Bien, tanto para la deuda financiera como para la técnica, la meta no es evitar la deuda por completo. En cambio, la administración prudente es la clave.
Aunque cierto nivel de deuda puede ser estratégico para el crecimiento, debemos monitorear y gestionar cuidadosamente la deuda para minimizar consecuencias negativas a largo plazo.
Ejemplos de deuda técnica
En el ámbito de la ingeniería de software, los equipos de desarrollo se encuentran regularmente con deuda técnica. Vamos a comentar algunos de los ejemplos más comunes.
Código legado
Algunos equipos pueden recurrir a código heredado obsoleto para lanzar una funcionalidad rápidamente. Esto puede aportar funcionalidad inmediata, pero podría requerir una refactorización sustancial más adelante, especialmente a medida que se agregan nuevas características. Al igual que un antiguo manuscrito, el código heredado ha sido traspasado por generaciones de desarrolladores, acumulando el peso de la historia.
Aunque pudo haber cumplido su propósito admirablemente en su época, el tiempo acaba por erosionar su adaptabilidad y mantenibilidad. ¡Las caídas del sistema y los errores en producción suelen surgir cuando dependemos demasiado del código heredado!
Codificación rígida
La codificación rígida hace referencia a la práctica de incrustar valores o constantes específicas directamente en el código en lugar de utilizar ajustes configurables.
Aunque este enfoque puede ofrecer un desarrollo más rápido a corto plazo, a menudo conduce a complicaciones más adelante. Imagina un escenario donde un valor codificado rígidamente, como una ruta de archivo o un umbral de tiempo de espera, deba cambiarse en toda una base de código considerable. Esto rápidamente puede volverse una tarea que consume mucho tiempo y propensa a errores, poniendo en riesgo la mantenibilidad y flexibilidad del software.
Para evitar este inconveniente, los desarrolladores deben optar por opciones configurables, mejorando la adaptabilidad de su código.
Duplicación de código
La duplicación de código ocurre cuando fragmentos de código similares o idénticos aparecen en varios lugares del proyecto. Al principio, puede parecer un atajo conveniente que ahorra tiempo durante el desarrollo. Sin embargo, a medida que el software evoluciona y cambian los requisitos, mantener la coherencia y realizar actualizaciones se convierte en una tarea compleja.
La duplicación de código no solo incrementa el riesgo de introducir errores, sino que también multiplica el esfuerzo necesario para futuras mejoras y correcciones de errores. La búsqueda de la reutilización del código y la eliminación del redundante son principios fundamentales para contrarrestar este problema.
Falta de documentación
La documentación sirve como el hilo conductor que ilumina el camino para los desarrolladores actuales y futuros. La ausencia de documentación completa es como emprender un viaje complejo sin un mapa. Puede comenzar con la falta de comentarios en línea que expliquen el motivo detrás de ciertas decisiones de código o escalar hasta la ausencia de guías de usuario y documentación de arquitectura del sistema.
Aunque la fase inicial de desarrollo puede avanzar sin contratiempos, las consecuencias a largo plazo pueden ser graves. Depurar se convierte en una tarea críptica, la transferencia de conocimiento entre miembros del equipo resulta difícil y escalar el proyecto se asemeja a navegar un laberinto a oscuras. Adoptar una documentación exhaustiva es el faro que ilumina el camino en el desarrollo de software.
Falta de pruebas automatizadas
La ausencia de pruebas automatizadas es comparable a navegar un barco sin comprobar antes si tiene fugas. Las pruebas automatizadas (incluyendo pruebas unitarias, de integración y de regresión) son los guardianes vigilantes de la calidad y estabilidad del código.
Cuando se omiten, las consecuencias pueden no ser evidentes de inmediato. Al principio el desarrollo puede avanzar rápido y el software puede parecer funcional. Sin embargo, a medida que la base de código se expande y evoluciona, comienzan a surgir problemas imprevistos. Los errores de regresión, donde características previamente funcionales se rompen tras nuevos cambios, se vuelven algo común.
Sin pruebas automatizadas que sirvan de red de seguridad, el equipo de desarrollo debe recurrir a pruebas manuales, un proceso laborioso y propenso a errores. Adoptar las pruebas automatizadas desde el principio garantiza un rumbo estable en el turbulento mar del desarrollo de software.
¿Cuál es el papel de la deuda técnica en Ágil?
¡Ah, el desarrollo Ágil! Sus metodologías scrum y los principios del manifiesto Ágil abrazan el cambio y la velocidad. Pero, ¿dónde encaja la deuda técnica? Al fin y al cabo, la deuda técnica no se menciona específicamente en los documentos fundacionales de Ágil.
Bueno, aquí tienes una analogía de Star Wars: el Halcón Milenario pasaba por un mantenimiento continuo por parte de Han Solo y Chewbacca para mantenerlo en óptimas condiciones para sus aventuras. De manera similar, un equipo ágil de producto gestiona la deuda técnica para mantener la calidad del software y permitir hazañas heroicas a sus clientes.
Cómo usar y gestionar la deuda técnica
En los equipos ágiles existe el entendimiento de que a veces se incurrirá en algo de deuda técnica para satisfacer rápidamente las necesidades del negocio. Recuerda que incurrir en esto no siempre es algo negativo. Martin Fowler, líder de opinión en el desarrollo de software Ágil, señala que se trata de equilibrar compensaciones. Es posible que aceptes algo de deuda al principio del ciclo de vida de un producto de software para validar un concepto o llegar más rápido al mercado.
La clave es cómo gestionar la deuda técnica. La deuda técnica debe documentarse en el backlog, priorizarse y abordarse en futuros sprints. Para que esto ocurra, los gestores de producto deben apoyarse en una sólida gestión de proyectos, y necesitan tener una buena comprensión de la cantidad de deuda técnica asumida hasta el momento.
¿Cuándo es un problema la deuda técnica?
Cuando los interesados no son conscientes de la deuda técnica o cuando el proceso de desarrollo depende en gran medida de soluciones temporales, es cuando deberían sonar las alarmas. ¿Por qué?
- Es Invisible: Sin métricas o revisiones de código regulares, pueden surgir vulnerabilidades ocultas.
- Afecta la Experiencia del Usuario: Si los problemas subyacentes comienzan a afectar la funcionalidad, no es solo un problema del desarrollador; es un problema del negocio.
- Dificulta Las Nuevas Funcionalidades: Los programadores atrapados en mal código son menos productivos y la creatividad disminuye.
- No Está en la Hoja de Ruta: Los equipos deben estar al tanto y tener una estrategia clara frente a la deuda técnica. No dudes en apoyarte en webinars y recursos externos para establecer un plan de acción.
Cómo Medir la Deuda Técnica
Utilizando herramientas como prácticas DevOps y automatización, los equipos pueden vigilar su base de código y monitorear la deuda técnica que se ha acumulado hasta ahora. A continuación, he reunido doce formas distintas de rastrear la deuda técnica.
¡No tienes que usar todas! En su lugar, piensa en esta lista como un punto de partida. Elige una o dos para implementar en el próximo mes, y luego ve aumentando poco a poco el nivel de sofisticación de tu equipo para rastrear y resolver la deuda técnica.
1) Análisis Estático de Código: Herramientas como SonarQube, ESLint o FindBugs pueden analizar automáticamente el código en busca de diversos problemas, como la complejidad del código, malos olores de código y posibles errores. Ofrecen métricas cuantitativas sobre la calidad del código y la deuda técnica en función de reglas y umbrales predefinidos.
2) Cobertura de Código: Podemos evaluar qué parte de la base de código está cubierta por pruebas automatizadas midiendo la cobertura de código con herramientas como JaCoCo o Istanbul. Baja cobertura puede indicar falta de pruebas y posible deuda técnica.
3) Revisiones de Código entre Pares: Realizar revisiones de código entre pares permite a los desarrolladores identificar y discutir posibles elementos de deuda técnica. Además, dos cabezas piensan mejor que una; ¡es una excelente manera de evitar malos patrones de código! Los equipos pueden usar listas de verificación o guías para evaluar la calidad del código y documentar los problemas encontrados. El número y gravedad de los problemas identificados en las revisiones puede servir como una medida cualitativa de la deuda técnica.
4) Inspecciones Manuales de Código: Los desarrolladores y equipos pueden realizar inspecciones manuales o recorridos para identificar áreas del código que se puedan beneficiar de refactorización. Este proceso a menudo involucra a desarrolladores experimentados revisando el código y documentando problemas, ya que suelen tener la mejor percepción sobre la deuda de diseño técnico.
5) Backlog de Deuda Técnica: Mantener un backlog de producto o una lista de elementos identificados de deuda técnica es una práctica común. Cada elemento del backlog debe incluir una descripción, una evaluación de impacto y una calificación de prioridad. El tamaño y la prioridad de los elementos en el backlog brindan una medida cualitativa de la deuda técnica.
6) Seguimiento de Errores e Incidencias: Analizar el proceso de triage de errores puede revelar la frecuencia y severidad de los problemas relacionados con deuda técnica. Una gran cantidad de reportes de bugs o la recurrencia frecuente de los mismos pueden indicar una deuda técnica subyacente.
7) Estimación y Puntos de Historia: Al planificar nuevo trabajo o historias de usuario, los equipos de desarrollo pueden estimar el esfuerzo necesario para abordar los elementos de deuda técnica. Esta estimación de esfuerzo, a menudo en forma de puntos de historia en metodologías ágiles, cuantifica el trabajo requerido para resolver la deuda técnica.
8) Métricas de Complejidad de Código: Métricas como complejidad ciclomática, líneas de código y cambios frecuentes pueden proporcionar información sobre la complejidad y la mantenibilidad de la base de código. Una mayor complejidad y cambios excesivos en ciertas áreas del código pueden indicar deuda técnica.
9) Retroalimentación de Usuarios: La retroalimentación de los usuarios y las solicitudes de soporte pueden destacar indirectamente la deuda técnica. Las quejas frecuentes de los usuarios sobre el rendimiento, la fiabilidad o el comportamiento inesperado del sistema pueden señalar problemas subyacentes que deben solucionarse.
10) Métricas de Pruebas Automatizadas: Monitorear métricas relacionadas con las pruebas automatizadas, como el tiempo de ejecución de pruebas, índices de fallos de pruebas y tests inestables, puede ayudar a evaluar la salud de la infraestructura de pruebas e identificar áreas impactadas por la deuda técnica.
11) Encuestas y Entrevistas: Realizar encuestas y entrevistas a los equipos de desarrollo puede aportar información cualitativa sobre el nivel percibido de deuda técnica y su impacto en la productividad y la calidad del código. Además, recoger comentarios de los interesados puede ayudar a identificar dónde podría ser necesario retrabajo.
12) Cuadrante de deuda técnica: Una herramienta especialmente útil es el cuadrante de deuda técnica presentado por Martin Fowler. Categoriza las causas de la deuda técnica en deliberadas vs. inadvertidas y temerarias vs. prudentes, ayudando a los equipos a entender los compromisos.
Además de estas doce formas de medir la deuda técnica, ¡no dudes en utilizar herramientas de gestión de productos para ayudar a tu equipo a hacer seguimiento y resolver la deuda técnica!
Saldar la deuda técnica
Hemos hablado mucho sobre cómo incurrir en deuda técnica, pero aún no hemos cubierto cómo saldarla. Como responsables de producto, es nuestro deber guiar a nuestros equipos para decidir cuándo pagar la deuda y cuándo incurrir en deuda técnica adicional.
Pagamos la deuda técnica cuando los ingenieros actualizan la base de código para abordar elementos previamente identificados de deuda técnica. Esto puede incluir rediseñar funcionalidades para que sean más eficientes, implementar pruebas automatizadas o proporcionar documentación detallada sobre el código.
Una de las mejores formas de reducirla es reservar tiempo en cada sprint para fortalecer la base de código y disminuir la deuda. Piensa en esto como pagar las cuotas mensuales de una hipoteca: ¡cuanto más rápido paguemos, menos intereses tendremos que abonar en total!
Una buena regla general es la regla del 80/20. Es decir, dedica alrededor del 80% del tiempo de cada sprint al desarrollo de nuevas funcionalidades, y el 20% a priorizar inversiones y mejoras técnicas.
Al planificar la reducción de la deuda técnica, considera integrarla debidamente en tu hoja de ruta de producto.
Reflexiones finales sobre la deuda técnica
En resumen, la gestión de la deuda técnica no es solo una tarea de los desarrolladores. Los responsables de producto, los equipos Ágiles y las partes interesadas del negocio tienen un papel que desempeñar.
¿El objetivo final? Entregar un producto de software de alta calidad que cumpla los objetivos del negocio sin acumular una deuda insostenible.
Así que, ya sea que te sumerjas en las profundidades del desarrollo de software o simplemente estés intentando entender por qué tu equipo de desarrollo sigue hablando de refactoring, comprender y gestionar la deuda técnica es la brújula que necesitas.
Y tanto si estás comenzando tu carrera en producto como si ya eres un veterano experimentado en gestión de productos, casi siempre te beneficiarás de profundizar en el conocimiento de la jerga técnica.
¡Espero que evites cometer el mismo error que yo cometí al principio de mi carrera—no confíes únicamente en las pistas del contexto para adivinar conceptos técnicos desconocidos!
En su lugar, tómate el tiempo para investigar, consultar guías externas como esta y pasar tiempo con tus ingenieros para reforzar conocimientos valiosos.
Para más consejos y guías sobre gestión de productos, ¡no olvides suscribirte a nuestro boletín!
