Cuando se trata de retorno de inversión (ROI), no me complico la vida: mi hipótesis es que los costes de mantenimiento se reducen en una proporción igual a la reducción de la deuda técnica.

Es una hipótesis que puedes encontrar simplista y por lo tanto discutible, pero nuestra ambición no es de conseguir una precisión absoluta – sería pretencioso y poco realista – pero proporcionar los elementos que facilitan la decisión.
Y creo que el management prefiere una hipótesis simple y clara en lugar de una fórmula compleja que no es necesariamente más realista.

Por haber hecho este ejercicio de cálculo y de presentación de ROI en mi vida anterior en editores de software de análisis de código, puedo decirte un secreto:

El ROI final es directamente proporcional a la complejidad de la fórmula:
más complicado el cálculo del ROI, más elevado el retorno de la inversión.

El ROI de los editores de software

En realidad, un proveedor de software tratará de evitar este cálculo cuando puede, pero eso varía según el país. Es algo casi inevitable en los EE.UU., donde el CIO u otro responsable puede ser despedido sin aviso, por lo que es esencial poder justificar cualquier compra de software para evitar cualquier causa de despido. En nuestros países (me refiero en Francia, España, Italia, …) la dimensión financiera no tiene la misma importancia en la compra de software, y el proceso de decisión será más fácil en general. El CIO revisará que:

• El valor para los negocios y los beneficios esperados justifican el precio del software, que se puede considerar razonable y no exorbitante.
• El coste de implementación y de operación será aceptable.
• El tiene ya un presupuesto para esta inversión.

Pero en el caso de que el CIO requiere una estimación del retorno de la inversión, puedes estar seguro de que la fórmula será complicada. ¿Por qué?
Porque el software de análisis de código que se está tratando de vender tiene también una complicada fórmula para calcular la deuda técnica, con el único objetivo de asustar al CIO o a cualquier otro reponsable.

Obviamente, más alta es la deuda técnica, mayor será el retorno de la inversión.
Esto lleva también a una pregunta interesante: la deuda técnica de los vendedores de software.

¿Cuánto tiempo pierdes en la gestión de los bugs encontrados en estos softwares y en retrasos en los proyectos bloqueados por estos bugs? ¿Cuánto vas a gastar en nuevas versiones siempre necesarias, si no forzadas? Si instalas cada nueva versión de cada parche, esto es un coste regular de upgrade. Pero si intentas escaparte saltando de vez en cuando una nueva versión, puedes estar seguro de que la próxima actualización será más complicada, a veces incluso con la obligación de pasar por una o más versiones intermedias, lo que será incluso más caro.

¿Cuando gastas en upgrade del entorno (hardware, sistema operativo, versión de la base de datos, etc.) o porque la nueva versión ya no es compatible con la versión particular de Unix, Windows, JDK, etc. que utilizas? ¿Cuál es el coste si el vendedor decide dejar de mantener este software y te quedas sin remedios o te ves obligado a comprar una otra herramienta?

No son sólo las aplicaciones que vienen con una deuda técnica, sino también el software en el que se invierte. ¿Los proveedores de software incorporan esta deuda técnica en su fórmula de calculo del ROI?

El ROI de nuestro refactoring

Pero volvamos a nuestra fórmula. Quisiera que sea sencilla y, en caso de que me encuentro con objeciones, pues agregaré algunas cosas que dejaré a la valoración de los responsables. Yo prefiero hacerlo así en lugar de incorporar estos elementos en una fórmula compleja, que no será necesariamente más precisa, ya que cualquier desviación en la estimación de cada uno de estos elementos dará lugar a una desviación más amplia en la estimación del retorno de la inversión.

Nuestra deuda técnica total es 1 283 días. Un esfuerzo de 291 días para traer esta deuda técnica a un nivel SQALE de ‘A’ de hecho reducirá esta a 992 (1 283 – 291) días, una disminución de la deuda técnica del 22,7%.

Con una tasa de 18.5 días de trabajo por mes o 225 días por persona al año, y un equipo de 5 personas, la carga total anual para este equipo es 225 días x 5 personas = 1 125 días/hombre.

Un esfuerzo de refactorización de 291 días en un año representa un coste de 291 dias / 1 125 días/hombre o 25,9% del coste de este equipo en 12 meses, y por lo tanto del coste de mantenimiento anual, un poquito más por encima de nuestra estimación de ganancia en mantenibilidad, igual a 22,7%.

Digamos que el retorno de nuestra inversión en un refactoring se produce un poco más después de 1 año, sobre la base de nuestra hipótesis de una reducción de los costes de mantenimiento en una proporción equivalente a la reducción de la deuda técnica.

Obviamente, esto es relativo: si divido por dos la deuda técnica o si la reduzco a nada, no voy a reducir a la mitad el presupuesto de mantenimiento o reducirlo a cero. Pero sigue siendo plausible nuestra hipótesis cuando se trata de proporciones (menos del 25%) tal como las que hemos calculado.
Y aunque este cálculo no es necesariamente muy preciso, lo que necesita un CIO es un orden de magnitud (6 meses, 10 meses, 1 año, 18 meses, etc.). Si el número es superior a los límites de lo razonable, pues ni se va a investigar más adelante cualquier proyecto de refactorización. Si es aceptable, podemos intentar vender los beneficios que se puede conseguir con este proyecto.

Vender el ROI

Cuando hablo con desarrolladores sobre la deuda técnica y la forma de utilizarla para convencer a la dirección que se necesita refactorización, la mayoría de ellos responden con un desánimo y una desmotivación extrema.

« Mi jefe no está interesado cuando hablo con él de corregir los defectos existentes, el impacto en la moral del equipo es terrible. »

« Los managers solamente piensan a corto plazo: si se tarda una hora para implementar un requerimiento, es un beneficio inmediato. Si dices que necesitas un día porque quieres aprovechar esta oportunidad para mejorar el código, comienzan a mirarte de manera sospechosa. Como si yo fuera una diva que quiere divertirse en programar más de lo que se necesita. »

Los técnicos y los desarrolladores generalmente tienen problemas para encontrar una justificación que les permite vender la idea de una optimización y una mejora del código, que sea puntual o no, porque la calidad del software no es un objetivo en sí mismo para los directivos.

Imaginamos que tienes que restaurar un viejo coche para alguien que espera venderlo a un buen precio, una vez que acabas con las reparaciones. Si propones comprar llantas nuevas y costosas y neumáticos nuevos y más amplios, por supuesto que él va a pensar que quieres darte un capricho con una customización del vehículo. A menos que puedas demostrar que él puede conseguir un beneficio de esta inversion.

El objetivo principal de los managers es: el valor de una inversión para el negocio . Es decir, la business value. ¿Cómo puedes vender el ROI de un proyecto de refactorización? Respuesta: con una correcta evaluación de los impactos en el negocio.

Nuestro plan: eliminar los defectos críticos (y Blockers), reducir la deuda técnica a un nivel aceptable y asegurarse de que no aumenta.

Este plan de acción se centra casi exclusivamente en la Reliability, pues en la robustez de la aplicación, y en una reducción de los defectos que afectan primero a los usuarios (y clientes o consumidores), y no en los defectos en Mantenibilidad que podrían permitir una reducción de los costes de mantenimiento. Sin embargo, menos riesgos de errores significa menos costes de correcciones, y una mayor reducción en los costes de mantenimiento. También sabemos que cuanto más tarde se encuentra un fallo en el ciclo de vida de desarrollo (en producción, por ejemplo), más caro cuesta corregirlo.

Si sólo cuesta dos horas para corregir un defecto, pero que eso permite ahorrarnos 2 o 3 días de detección y corrección de un error, no sólo su ROI se vuelve mucho más interesante desde el punto de vista financiero, pero desde un punto de vista cualitativo, vas a mejorar la satisfacción del usuario y la imagen de tu departamento TI. Y eso no tiene precio.

Otros puntos que podemos presentar, sin necesariamente intentar cifrarlos para evitar una fórmula complicada:

• Un control de calidad eficaz: cada vez que un bug se encuentra en QA, se devuelve el código al desarrollador que debe corregir y volver al control de calidad para unas pruebas más. Menos defectos en el código significa menos ciclos de ida y vuelta en la fase de pruebas. Por lo tanto, menores costes, y cumplimiento de los presupuestos y de la planificación. Y un planning sin retraso significa un usuario feliz!
• Valor para los negocios: un error en producción puede resultar en un rendimiento inferior o hasta una interrupción del sistema, por lo que las operaciones de negocio se vuelven más largas y lentas, y en una mayor carga de trabajo para los usuarios, y en clientes descontentos. Todo esto puede afectar las ventas, y por supuesto la eficacia de los departamentos de marketing, comercial, logística, etc.
• Valor para los negocios: gastar menos en el mantenimiento de las aplicaciones permite invertir más en nuevas aplicaciones y apoyar a nuevos negocios y el crecimiento en nuevos mercados.
• Mejora de la productividad de los desarrolladores: algunas violaciónes de buenas prácticas de programación afectan el rendimiento de los desarrolladores. Por ejemplo, un código duplicado significa menos reutilización, y más tiempo dedicado a desarrollar un código … que ya existe.
• Mejor control de los outsourcers: si le haces una auditoría de calidad cada 6 meses, a tu outsourcer ni le importará la calidad de las aplicaciones ni la deriva de la deuda técnica, o le importará solamente una vez cada 6 meses, cuando ya es demasiado tarde. Si pones una herramienta como SonarQube con el plugin SQALE, puedes realizar estos controles automáticamente cada semana. Esto se conoce como el ‘efecto radar’: si tu proveedor sabe que le puedes pillar en cualquier momento, él será mucho más cuidadoso.

Estos son los puntos que son intuitivamente comprensibles por los managers, con un valor para la empresa, el negocio y el departamento de TI. Después, si realmente quieren calcular un ROI que tenga en cuenta estos beneficios, debes entonces o bien hacer suposiciones (número de errores encontrados en producción, en QA, tiempo promedio de remediación, etc.), o emplear cifras usualmente proporcionadas por institutos de investigación (como el SEI). El resultado no será necesariamente más exacto que nuestra sencilla estimación basada en la reducción de la deuda técnica. Aunque muy probablemente superior.

Creo que vamos a hablar de nuevo de ROI en nuestro último caso: la reingeniería de nuestra aplicación Legacy. La próxima vez.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.