{"id":1439,"date":"2014-10-28T10:49:41","date_gmt":"2014-10-28T09:49:41","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=1439"},"modified":"2014-11-27T17:13:06","modified_gmt":"2014-11-27T16:13:06","slug":"aplicacion-legacy-deuda-tecnica-roi-refactorizacion","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/aplicacion-legacy-deuda-tecnica-roi-refactorizacion\/","title":{"rendered":"Aplicaci\u00f3n Legacy \u2013 Deuda t\u00e9cnica y ROI de una refactorizaci\u00f3n"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2163\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtRefactoringROI.jpg\" alt=\"Application Legacy - Techncal Debt et le ROI d'un Refactoring\" width=\"261\" height=\"315\" \/><\/a>Cuando se trata de retorno de inversi\u00f3n (ROI), no me complico la vida: mi hip\u00f3tesis es que los costes de mantenimiento se reducen en una proporci\u00f3n igual a la reducci\u00f3n de la deuda t\u00e9cnica.<\/p>\n<p>Es una hip\u00f3tesis que puedes encontrar simplista y por lo tanto discutible, pero nuestra ambici\u00f3n no es de conseguir una precisi\u00f3n absoluta &#8211; ser\u00eda pretencioso y poco realista &#8211; pero proporcionar los elementos que facilitan la decisi\u00f3n.<br \/>\nY creo que el management prefiere una hip\u00f3tesis simple y clara en lugar de una f\u00f3rmula compleja que no es necesariamente m\u00e1s realista.<br \/>\n<!--more--><\/p>\n<p>Por haber hecho este ejercicio de c\u00e1lculo y de presentaci\u00f3n de ROI en mi vida anterior en editores de software de an\u00e1lisis de c\u00f3digo, puedo decirte un secreto:<\/p>\n<p style=\"text-align: center\"><strong><em>El ROI final es directamente proporcional a la complejidad de la f\u00f3rmula:<br \/>\nm\u00e1s complicado el c\u00e1lculo del ROI, m\u00e1s elevado el retorno de la inversi\u00f3n.<\/em><\/strong><\/p>\n<h2>El ROI de los editores de software<\/h2>\n<p>En realidad, un proveedor de software tratar\u00e1 de evitar este c\u00e1lculo cuando puede, pero eso var\u00eda seg\u00fan el pa\u00eds. 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\u00edses (me refiero en Francia, Espa\u00f1a, Italia, &#8230;) la dimensi\u00f3n financiera no tiene la misma importancia en la compra de software, y el proceso de decisi\u00f3n ser\u00e1 m\u00e1s f\u00e1cil en general. El CIO revisar\u00e1 que:<\/p>\n<ul>\n<li>El valor para los negocios y los beneficios esperados justifican el precio del software, que se puede considerar razonable y no exorbitante.<\/li>\n<li>El coste de implementaci\u00f3n y de operaci\u00f3n ser\u00e1 aceptable.<\/li>\n<li>El tiene ya un presupuesto para esta inversi\u00f3n.<\/li>\n<\/ul>\n<p>Pero en el caso de que el CIO requiere una estimaci\u00f3n del retorno de la inversi\u00f3n, puedes estar seguro de que la f\u00f3rmula ser\u00e1 complicada. \u00bfPor qu\u00e9?<br \/>\nPorque el software de an\u00e1lisis de c\u00f3digo que se est\u00e1 tratando de vender tiene tambi\u00e9n una complicada f\u00f3rmula para calcular la deuda t\u00e9cnica, con el \u00fanico objetivo de <a title=\"Deuda t\u00e9cnica \u2013 Dessarolladores vs. marketing\" href=\"http:\/\/qualilogy.com\/es\/deuda-tecnica-dessarolladores-vs-marketing\/\" target=\"_blank\">asustar al CIO o a cualquier otro reponsable<\/a>.<\/p>\n<p>Obviamente, m\u00e1s alta es la deuda t\u00e9cnica, mayor ser\u00e1 el retorno de la inversi\u00f3n.<br \/>\nEsto lleva tambi\u00e9n a una pregunta interesante: la deuda t\u00e9cnica de los vendedores de software.<\/p>\n<p>\u00bfCu\u00e1nto tiempo pierdes en la gesti\u00f3n de los bugs encontrados en estos softwares y en retrasos en los proyectos bloqueados por estos bugs? \u00bfCu\u00e1nto vas a gastar en nuevas versiones siempre necesarias, si no forzadas? Si instalas cada nueva versi\u00f3n de cada parche, esto es un coste regular de upgrade. Pero si intentas escaparte saltando de vez en cuando una nueva versi\u00f3n, puedes estar seguro de que la pr\u00f3xima actualizaci\u00f3n ser\u00e1 m\u00e1s complicada, a veces incluso con la obligaci\u00f3n de pasar por una o m\u00e1s versiones intermedias, lo que ser\u00e1 incluso m\u00e1s caro.<\/p>\n<p>\u00bfCuando gastas en upgrade del entorno (hardware, sistema operativo, versi\u00f3n de la base de datos, etc.) o porque la nueva versi\u00f3n ya no es compatible con la versi\u00f3n particular de Unix, Windows, JDK, etc. que utilizas? \u00bfCu\u00e1l 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?<\/p>\n<p>No son s\u00f3lo las aplicaciones que vienen con una deuda t\u00e9cnica, sino tambi\u00e9n el software en el que se invierte. \u00bfLos proveedores de software incorporan esta deuda t\u00e9cnica en su f\u00f3rmula de calculo del ROI?<\/p>\n<h2>El ROI de nuestro refactoring<\/h2>\n<p>Pero volvamos a nuestra f\u00f3rmula. Quisiera que sea sencilla y, en caso de que me encuentro con objeciones, pues agregar\u00e9 algunas cosas que dejar\u00e9 a la valoraci\u00f3n de los responsables. Yo prefiero hacerlo as\u00ed en lugar de incorporar estos elementos en una f\u00f3rmula compleja, que no ser\u00e1 necesariamente m\u00e1s precisa, ya que cualquier desviaci\u00f3n en la estimaci\u00f3n de cada uno de estos elementos dar\u00e1 lugar a una desviaci\u00f3n m\u00e1s amplia en la estimaci\u00f3n del retorno de la inversi\u00f3n.<\/p>\n<p>Nuestra deuda t\u00e9cnica total es 1 283 d\u00edas. Un esfuerzo de 291 d\u00edas para <a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (II)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-2\/\" target=\"_blank\">traer esta deuda t\u00e9cnica a un nivel SQALE de &#8216;A&#8217;<\/a> de hecho reducir\u00e1 esta a 992 (1 283 &#8211; 291) d\u00edas, una disminuci\u00f3n de la deuda t\u00e9cnica del 22,7%.<\/p>\n<p>Con una tasa de 18.5 d\u00edas de trabajo por mes o 225 d\u00edas por persona al a\u00f1o, y un equipo de 5 personas, la carga total anual para este equipo es 225 d\u00edas x 5 personas = 1 125 d\u00edas\/hombre.<\/p>\n<p>Un esfuerzo de refactorizaci\u00f3n de 291 d\u00edas en un a\u00f1o representa un coste de 291 dias \/ 1 125\u00a0d\u00edas\/hombre o 25,9% del coste de este equipo en 12 meses, y por lo tanto del coste de mantenimiento anual, un poquito m\u00e1s por encima de nuestra estimaci\u00f3n de ganancia en mantenibilidad, igual a 22,7%.<\/p>\n<p>Digamos que el retorno de nuestra inversi\u00f3n en un refactoring se produce un poco m\u00e1s despu\u00e9s de 1 a\u00f1o, sobre la base de nuestra hip\u00f3tesis de una reducci\u00f3n de los costes de mantenimiento en una\u00a0proporci\u00f3n equivalente a la reducci\u00f3n de la deuda t\u00e9cnica.<\/p>\n<p>Obviamente, esto es relativo: si divido por dos la deuda t\u00e9cnica 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\u00f3tesis cuando se trata de proporciones (menos del 25%) tal como las que hemos calculado.<br \/>\nY aunque este c\u00e1lculo no es necesariamente muy preciso, lo que necesita un CIO es un orden de magnitud (6 meses, 10 meses, 1 a\u00f1o, 18 meses, etc.). Si el n\u00famero es superior a los l\u00edmites de lo razonable, pues ni se va a investigar m\u00e1s adelante cualquier proyecto de refactorizaci\u00f3n. Si es aceptable, podemos intentar vender los beneficios que se puede conseguir con este proyecto.<\/p>\n<h2>Vender el ROI<\/h2>\n<p>Cuando hablo con desarrolladores sobre la deuda t\u00e9cnica y la forma de utilizarla para convencer a la direcci\u00f3n que se necesita refactorizaci\u00f3n, la mayor\u00eda de ellos responden con un des\u00e1nimo y una desmotivaci\u00f3n extrema.<\/p>\n<p>\u00ab Mi jefe no est\u00e1 interesado cuando hablo con \u00e9l de corregir los defectos existentes, el impacto en la moral del equipo es terrible. \u00bb<\/p>\n<p>\u00ab 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\u00eda porque quieres aprovechar esta oportunidad para mejorar el c\u00f3digo, comienzan a mirarte de manera sospechosa. Como si yo fuera una diva que quiere divertirse en programar m\u00e1s de lo que se necesita. \u00bb<\/p>\n<p>Los t\u00e9cnicos y los desarrolladores generalmente tienen problemas para encontrar una justificaci\u00f3n que les permite vender la idea de una optimizaci\u00f3n y una mejora del c\u00f3digo, que sea puntual o no, porque la calidad del software no es un objetivo en s\u00ed mismo para los directivos.<\/p>\n<p>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\u00e1ticos nuevos y m\u00e1s amplios, por supuesto que \u00e9l va a pensar que quieres darte un capricho con una customizaci\u00f3n del veh\u00edculo. A menos que puedas demostrar que \u00e9l puede conseguir un beneficio de esta inversion.<\/p>\n<p>El objetivo principal de los managers es: el valor de una inversi\u00f3n para el negocio . Es decir, la business value. \u00bfC\u00f3mo puedes vender el ROI de un proyecto de refactorizaci\u00f3n? Respuesta: con una correcta evaluaci\u00f3n de los impactos en el negocio.<\/p>\n<p><a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (II)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-2\/\" target=\"_blank\">Nuestro plan<\/a>: eliminar los defectos cr\u00edticos (y Blockers), reducir la deuda t\u00e9cnica a un nivel aceptable y asegurarse de que no aumenta.<\/p>\n<p>Este plan de acci\u00f3n se centra casi exclusivamente en la Reliability, pues en la robustez de la aplicaci\u00f3n, y en una reducci\u00f3n de los defectos que afectan primero a los usuarios (y clientes o consumidores), y no en los defectos en Mantenibilidad que podr\u00edan permitir una reducci\u00f3n de los costes de mantenimiento. Sin embargo, menos riesgos de errores significa menos costes de correcciones, y una mayor reducci\u00f3n en los costes de mantenimiento. Tambi\u00e9n sabemos que cuanto m\u00e1s tarde se encuentra un fallo en el ciclo de vida de desarrollo (en producci\u00f3n, por ejemplo), m\u00e1s caro cuesta corregirlo.<\/p>\n<p>Si s\u00f3lo cuesta dos horas para corregir un defecto, pero que eso permite ahorrarnos 2 o 3 d\u00edas de detecci\u00f3n y correcci\u00f3n de un error, no s\u00f3lo su ROI se vuelve mucho m\u00e1s interesante desde el punto de vista financiero, pero desde un punto de vista cualitativo, vas a mejorar la satisfacci\u00f3n del usuario y la imagen de tu departamento TI. Y eso no tiene precio.<\/p>\n<p>Otros puntos que podemos presentar, sin necesariamente intentar cifrarlos para evitar una f\u00f3rmula complicada:<\/p>\n<ul>\n<li>Un control de calidad eficaz: cada vez que un bug se encuentra en QA, se devuelve el c\u00f3digo al desarrollador que debe corregir y volver al control de calidad para unas pruebas m\u00e1s. Menos defectos en el c\u00f3digo 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\u00f3n. Y un planning sin retraso significa un usuario feliz!<\/li>\n<li>Valor para los negocios: un error en producci\u00f3n puede resultar en un rendimiento inferior o hasta una interrupci\u00f3n del sistema, por lo que las operaciones de negocio se vuelven m\u00e1s 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\u00edstica, etc.<\/li>\n<li>Valor para los negocios: gastar menos en el mantenimiento de las aplicaciones permite invertir m\u00e1s en nuevas aplicaciones y apoyar a nuevos negocios y el crecimiento en nuevos mercados.<\/li>\n<li>Mejora de la productividad de los desarrolladores: algunas violaci\u00f3nes de buenas pr\u00e1cticas de programaci\u00f3n afectan el rendimiento de los desarrolladores. Por ejemplo, un c\u00f3digo duplicado significa menos reutilizaci\u00f3n, y m\u00e1s tiempo dedicado a desarrollar un c\u00f3digo &#8230; que ya existe.<\/li>\n<li>Mejor control de los outsourcers: si le haces una auditor\u00eda de calidad cada 6 meses, a tu outsourcer ni le importar\u00e1 la calidad de las aplicaciones ni la deriva de la deuda t\u00e9cnica, o le importar\u00e1 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\u00e1ticamente cada semana. Esto se conoce como el &#8216;efecto radar&#8217;: si tu proveedor sabe que le puedes pillar en cualquier momento, \u00e9l ser\u00e1 mucho m\u00e1s cuidadoso.<\/li>\n<\/ul>\n<p>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\u00e9s, si realmente quieren calcular un ROI que tenga en cuenta estos beneficios, debes entonces o bien hacer suposiciones (n\u00famero de errores encontrados en producci\u00f3n, en QA, tiempo promedio de remediaci\u00f3n, etc.), o emplear cifras usualmente proporcionadas por institutos de investigaci\u00f3n (como el SEI). El resultado no ser\u00e1 necesariamente m\u00e1s exacto que nuestra sencilla estimaci\u00f3n basada en la reducci\u00f3n de la deuda t\u00e9cnica. Aunque muy probablemente superior.<\/p>\n<p>Creo que vamos a hablar de nuevo de ROI en nuestro \u00faltimo caso: la reingenier\u00eda de nuestra aplicaci\u00f3n Legacy. La pr\u00f3xima vez.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Cuando se trata de retorno de inversi\u00f3n (ROI), no me complico la vida: mi hip\u00f3tesis es que los costes de mantenimiento se reducen en una proporci\u00f3n igual a la reducci\u00f3n de la deuda t\u00e9cnica. Es una hip\u00f3tesis que puedes encontrar simplista y por lo tanto discutible, pero nuestra ambici\u00f3n no es de conseguir una precisi\u00f3n [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-1439","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1439"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=1439"}],"version-history":[{"count":18,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1439\/revisions"}],"predecessor-version":[{"id":1537,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1439\/revisions\/1537"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=1439"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=1439"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=1439"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}