Deuda Monetaria aplicada al Desarrollo del Software
Qué se puede aprender sobre la deuda de diseño y las malas implementaciones.
Deuda Monetaria aplicada al Desarrollo del Software
La deuda de diseño es una metáfora habitual en informática para referirse a las posibles consecuencias de una mala implementación técnica del software. Los informáticos utilizan el término para recalcar a los gestores y otras partes interesadas de los proyectos de software que posponer las medidas para garantizar y mejorar la calidad técnica no acelera el desarrollo del software, sino que lo ralentiza, cuanto más tiempo, más.
Este concepto es similar al de "deuda monetaria", tal como explicó Eric Allman: si la deuda técnica no se paga, puede acumular 'intereses', lo que va dificultando la implementación de cambios.
La deuda de diseño se diferencia de los antipatrones en que la decisión de incurrir en deuda de diseño también puede tomarse conscientemente y tras sopesar los pros y los contras, mientras que los antipatrones son siempre resultado de la pereza y la falta de profesionalidad.
Normalmente, una combinación de los siguientes factores conduce a la deuda técnica:
Presión técnica, cuando el cliente presiona a los participantes en el proyecto para que entreguen nuevas funcionalidades rápidamente y antes de que se complete el saneamiento técnico. Esta presión puede ejercerse, por ejemplo, mediante un rápido lanzamiento del producto.
Procesos inadecuados de garantía de calidad, si no hay procesos de garantía de calidad en un proyecto (o no están implantados) que midan continuamente la deuda técnica e inicien medidas de mejora.
Conocimientos técnicos insuficientes para tomar decisiones técnicas que no aumenten la deuda técnica e, idealmente, incluso la reduzcan.
Comunicación insuficiente de las soluciones técnicas elegidas y su trasfondo. La comunicación puede adoptar muchas formas, por ejemplo, código autoexplicativo, documentación, diagramas, vídeos, etc.
El desarrollo paralelo en diferentes ramas (por ejemplo, ramas de características) conduce a un mayor esfuerzo de fusión y, por tanto, a la deuda técnica.
Refactorización diferida, cuando se sigue implementando funcionalidad en partes del código que requieren mejoras sin implementarlas primero. Cuanto más se retrasen estas refactorizaciones necesarias, más costosas resultarán tanto ellas como la implementación de la funcionalidad.
Cómo posicionar el tratamiento de la deuda de diseño como una propuesta de valor
Para vender realmente la idea, tienes que entender el lenguaje de la estrategia empresarial.
He aquí cómo puedes posicionar la deuda de diseño (o técnica) de forma que resuene entre los jefes de producto:
Velocidad del desarrollador. Destaca cómo la deuda de diseño está mermando la productividad. Preséntala como un obstáculo que impide que el equipo envíe funciones con rapidez y eficacia.
Tiempo de comercialización. Muestra cómo abordar la deuda técnica o de diseño conducirá a ciclos de lanzamiento más rápidos, lo que está directamente relacionado con el crecimiento del negocio y la retención de clientes.
Experiencia del cliente. Relaciona la deuda técnica con los puntos de dolor de los usuarios, ya sea el rendimiento lento, los errores frecuentes o el tiempo de inactividad. Haz hincapié en que la reducción de la deuda conducirá a una experiencia del producto más fluida y fiable.
Escalabilidad a largo plazo. Para las empresas que desean escalar, la deuda técnica puede ser una bomba de relojería. Plantea tu argumento en torno a cómo abordarla ahora evitará costosas repeticiones y garantizará que el producto pueda escalar con la demanda.
Al enmarcar la deuda técnica en términos de estos impulsores de valor, cambias la conversación de «necesidades de ingeniería» a «resultados empresariales», facilitando que tu PM vea por qué debe priorizarse.
Normalmente, en los proyectos de desarrollo de software se incurre en las siguientes deudas técnicas (con cuidado o sin él, intencionada o accidentalmente):
Documentación técnica y funcional del software retrasada o no actualizada
Falta de infraestructura técnica, como gestión de versiones, copia de seguridad de datos, herramientas de compilación, integración continua
Aplazamiento, omisión o aplicación inadecuada de pruebas automatizadas de módulos y pruebas de regresión
Falta de normas de codificación y de propiedad del código
Incumplimiento de las notas TODO, FIXME o XXX en el código
Descuido de las repeticiones de código y otros olores de código
Uso de antipatrones de programación
Ignorar las advertencias del compilador y los resultados del análisis estático del código
Descuido a la hora de corregir código y diseños demasiado grandes o complejos
Definición o implementación incorrecta de la arquitectura debido al acoplamiento estrecho, la referencia circular a componentes o la falta de interfaces y front-ends adecuados
Ahora que hemos aprendido a relacionar la deuda de diseño con el valor, pasemos a un marco específico.
La Clave para Convencer al Jefe de Producto
La clave reside en posicionarla como una propuesta de valor directamente vinculada a los resultados empresariales. Y... ¿cómo hacerlo? Aquí tienes un proceso de 5 pasos que te ayudará con esto.
Paso 1: Alineación con la estrategia empresarial
Antes de dirigirte a tu PM, profundiza en los objetivos del producto y de la empresa.
Pregúntate...
¿Cuál es la estrategia empresarial global? (por ejemplo, crecimiento, satisfacción del cliente, entrada en nuevos mercados; si no lo sabes, pregúntaselo a tu jefe, a tu PM o a la estrategia de la empresa).
¿Cómo afecta actualmente a estos objetivos la creciente deuda técnica?
¿Cómo podría afectar la deuda técnica a estos objetivos en el futuro?
¿Cómo influye la velocidad de los desarrolladores en la hoja de ruta del producto y en la cadencia de publicación?
Ejemplo: si tu empresa está escalando rápidamente, subraya cómo la deuda técnica está obstaculizando la capacidad del equipo para entregar características rápidamente.
Ejemplo 2: si la atención se centra en la retención de clientes, muestra cómo la deuda técnica está dando lugar a errores que perjudican la experiencia del usuario.
Ejemplo 3: enmárcalo como que los costes de soporte aumentan, la carga operativa aumenta. Eso cuesta tiempo y dinero y podría evitarse si dedicáramos tiempo a resolver la deuda técnica.
Paso 2: Cuantificar el problema
Es más probable que los PM prioricen el trabajo si ven los números. Y punto. Así que asegúrate de reunir los datos que respalden tu argumento.
He aquí algunos ejemplos:
Tiempo perdido. Calcula cuánto tiempo se dedica a la corrección de errores, soluciones manuales o extinción de incendios debido a la deuda técnica. No hace falta que seas exacto al 100%.
Tiempo de ciclo. Mide el tiempo que se tarda en pasar de la confirmación del código al despliegue. Destaca las áreas en las que la deuda técnica está causando retrasos.
Problemas de producción. Registra el número de incidentes, errores o problemas de rendimiento relacionados con la deuda técnica. Simplemente cuéntalos. Luego haz un balance de cuánto tiempo y dinero cuestan.
¿No estás seguro de cómo estimar o cuantificar el problema?
Utiliza estas reglas empíricas para empezar:
Para un verdadero swag, me gusta utilizar 1 Desarrollador = 250k / año
Entonces 1 Sprint de Desarrollador (2 semanas) = ~10k USD
Si un error lleva 1 Sprint de Desarrollador, eso son 10k USD en coste de oportunidad
Si la deuda técnica te ralentiza y hace que necesites el doble de Sprints de Desarrollador para sacar una nueva y brillante función, eso significa que el coste de no eliminar la deuda técnica ahora ralentizará efectivamente la entrega futura en el doble de tiempo y en ~20.000 USD más de coste.
Utiliza métricas para trazar una imagen clara de cómo la deuda técnica está erosionando la velocidad de los desarrolladores y afectando a los resultados finales.
Paso 3: Relaciona la deuda de diseño con el valor empresarial
Aquí es donde estableces la conexión entre la deuda técnica y los resultados empresariales.
Sitúa tu argumento de forma que muestre a tu PM cómo la reducción de la deuda técnica conducirá a.
Tiempo de comercialización más rápido → un código más limpio y una deuda reducida conducen a lanzamientos de características más rápidos.
Mejor experiencia del cliente → menos errores, mejor rendimiento y sistemas más fiables.
Mayor eficiencia del equipo → menos tiempo dedicado a la repetición de tareas significa más tiempo dedicado a crear nuevas funciones.
Ejemplo: Al abordar esta deuda técnica, podríamos reducir el tiempo de nuestro ciclo de lanzamiento en un 30%, lo que nos permitiría ofrecer funciones más rápidamente y mejorar la satisfacción del cliente.
¡Utiliza las reglas empíricas que acabas de aprender!
Recuerda, estimaciones en servilletas de papel → NO estimaciones.
Paso 4: Solución
Ahora que has expuesto el problema, ofrece una solución. Divide la deuda técnica en partes manejables y presenta un plan por fases.
Haz que les resulte fácil decir SÍ.
Ejemplo:
Fase 1: Refactorizar la capa API para reducir la complejidad del código y desacoplar la lógica.
↳ Resultado esperado: tiempo de resolución de errores un 20% más rápido.
Fase 2: Abordar los cuellos de botella de rendimiento en la base de datos.
↳ Resultado esperado: Reducción del 15% en los tiempos de carga de las páginas.
Fase 3: Mejorar la cobertura de las pruebas automatizadas.
↳ Resultado esperado: Reducción del 30% de los incidentes de producción.
Si quieres engrasar aún más las ruedas, divide el trabajo en una Epopeya e Historias para abordar la deuda.
Cuantifica las historias con antelación para que tu PM sepa exactamente cuánto costará y cómo lo incluirá en la hoja de ruta.
Paso 5: Propuesta
Por último, aborda la conversación desde la empatía y formula tu propuesta en el lenguaje que ellos entiendan.
Utiliza un formato que resuene más y que sea capaz de presentarlo de la mejor manera. Pueden ser diapositivas, documentación o cualquier otra cosa.
Preséntalo de un modo que puedan entender fácilmente, para que les resulte fácil decir «sí» y enmarcar tu petición como una asociación.
Ejemplo: Entiendo que estamos centrados en ofrecer funciones clave este trimestre, y creo que abordar esta área específica de deuda técnica puede ayudarnos a ofrecer esas funciones más rápidamente y con menos problemas. Asignar algunos recursos y tiempo a esto mejorará enormemente nuestra capacidad de ofrecer valor a los clientes, más rápidamente.
Fomenta en ellos esa empatía hacia ti (y también hacia los futuros ingenieros que tengan que trabajar en el código base).
Por qué funciona este proceso
El proceso que he esbozado funciona porque habla de lo que más importa a los gestores de producto: aportar valor.
Al alinear la deuda técnica con la estrategia empresarial, cuantificar el impacto en la velocidad de los desarrolladores y proponer resultados claros y mensurables, consigues un argumento convincente difícil de ignorar.
Y si lo empaquetas bien (escribiendo la(s) Epopeya(s), las Historias, haciendo las estimaciones y hablando su idioma) optimizarás tus posibilidades de éxito.
Alguna sugerencia?
¡Encontrar el equilibrio adecuado entre deuda de diseño y nuevas funciones es clave!
Los técnicos superiores están aquí para aportar tanto valor empresarial como sea posible, y eso no sólo significa trabajar en nuevas funciones. Con la velocidad a la que cambian las cosas en ese sector, poder hacer ajustes con confianza es también un gran beneficio para el negocio.
Por eso es importante mitigar la deuda técnica, de diseño, y dedicar tiempo a resolverla. Y una vez que sepas que resolver una deuda de diseño concreta te beneficiaría en términos de poder lanzar nuevas funciones más rápidamente.
Para ti debería ser una obviedad pasar a la acción. Asegúrate de preparar un caso para ello, y haz que sea lo más fácil posible decir ¡SÍ!
Un jefe de Producto me dijo que si su jefe del departamento de tecnología siguiera este plan, le resultaría MUCHO más fácil y probable dar prioridad a la deuda de diseño (en el artículo se explica lo que es para los que no tengan tanta “sapienza” tecnológica). Siempre hay algo que languidece en el backlog, me dijo, por lo que contar con técnicos superiores (como los ingenieros) que aboguen activamente con una justificación basada en el valor sería increíblemente útil.
Est artículo es una visión general sobre cómo persuadir a tu organización para que dedique recursos a la deuda de diseño, redactado por un especialista.