Cómo medir el valor potencial de refactorización

  

Le ganará a la compañía F millones de libras, durante t años a un costo de x días de trabajo por día

Lo que ignora los costos de mantenimiento, los costos de soporte, el costo de ventas / marketing y hace una gran cantidad de suposiciones sobre cómo se tomará la característica en el mercado.

Pero lo que sea; tu pregunta es lo suficientemente clara sobre lo que estás buscando:

  

¿Cómo puedo hacer un caso de negocios para refactorizar?

Lo principal a tener en cuenta es que el tiempo es igual al dinero. Puede ir directamente a "5 desarrolladores 2 semanas = 80 horas * 5 desarrolladores * $ 50 / hr - > $ 20,000" y eso tiene sentido para la gente de negocios. La gente de negocios inteligente notará que a esos 5 desarrolladores se les paga de cualquier manera, con lo cual usted responde que no está gastando / ahorrando los $ 20,000; está utilizando los $ 20,000 de la manera más rentable. De todos modos, en la lista.

• Eficiencia : presumiblemente, puedes hacer más cosas con C # que con VB6. Mejores herramientas, mejores bibliotecas, lo que sea. Las nuevas tecnologías tienden a ser mejores en cosas que las antiguas. Si puedes hacer cosas en menos tiempo, eso significa que estás ahorrando dinero a la empresa.
• Overhead : la codificación no es el único costo del software. Considere lo que sucede cuando sale Windows 2020. ¿Cuánto tiempo y esfuerzo vas a gastar para que la aplicación VB6 funcione en ella? ¿Cuánto más tiempo y esfuerzo es eso que una aplicación de C #? Eso es ahorrar dinero a su empresa.
• Calidad : presumiblemente, puedes hacer cosas con mayor calidad en C # que en VB6 (o con una arquitectura más limpia, o cualquier otra cosa que sea tu objetivo de refactorización). Mayor calidad significa menos errores. Menos errores significa menos costos para solucionarlos, menos costos de atención al cliente para solucionar esos problemas, menos pérdidas de clientes debido a problemas de calidad, mayores ventas debido a una reputación de calidad ... todos los dólares para su compañía.
• Ahorros en recursos humanos : Afrontemos los hechos: nadie quiere trabajar con esa aplicación de mierda VB6. Eso significa que más personas abandonarán la compañía, lo que conllevará el tiempo y el dinero gastado para reemplazarlos. Eso significa que se necesita más tiempo y dinero para contratar nuevos empleados. Lo peor de todo es que tendrás desarrolladores que están totalmente bien cometiendo suicidio profesional al trabajar con esa aplicación VB6. Esos desarrolladores a su vez aceleran la espiral de la muerte de los problemas de calidad. Reducir la facturación y los tiempos de contratación ahorra dinero a su empresa. Mantener a los complacientes y malvados desarrolladores ahorra a su empresa.
• Moral : de manera similar, los programadores que ya están allí odian trabajar en VB6. Lo harán, e incluso podrían hacerlo bien. Pero apesta. Tal vez no para todos, pero sí para algunos. Eso significa más tiempo dedicado a navegar por la web para recuperar la motivación. Significa almuerzos más largos. Significa que hay menos cosas que hacer, mientras que los programadores tardan más en recuperarse del trabajo.
• Capacidad : esto es menos aplicable con refactores de tecnología, pero se aplica a la clase de refactores de arquitectura. Ciertos problemas de código le impiden activamente proporcionar una característica interesante X para ganar toneladas de dinero. Tal vez no puedas escalar. Tal vez usted no puede obtener los datos para hacer informática genial. Tal vez el código sea un nido de ratas tal que es prohibitivamente difícil hacer el trabajo. Lo que sea. A veces estás en ese punto, a veces estás conduciendo directamente hacia ese punto. Es difícil traducirlo a lenguaje de negocios, pero si puede, "este problema nos impide aprovechar las oportunidades X, Y y Z" puede ser poderoso.

En general, todo se reduce a "esto nos ayudará a hacer mejor nuestro trabajo; si hacemos mejor nuestro trabajo, podemos ganarle / ahorrarle más dinero".

La pregunta que debe hacerse es cómo sabe el vendedor que la función le costará a x días de trabajo. Dado que incluso los buenos gerentes de proyectos con años de experiencia profesional no pueden decirlo con frecuencia, tales datos provenientes de un vendedor parecen extremadamente ... especulativos .

Según mi experiencia, los vendedores generalmente no hacen estimaciones, pero adivina cuánto es demasiado para la administración o para el cliente: si la administración está lista para pagar 50 semanas de trabajo, pero rechazará absolutamente 75 semanas hombre, digamos que la función tomará 70 semanas hombre mientras esté listo para renegociar (algo que está fuera de discusión para una estimación real) hasta 55 semanas hombre.

• Por un lado, tienes estimaciones hechas por expertos de TI que dicen algo como:

    

  Según esta auditoría específica, estamos desperdiciando $ 8 000 por día usando una tecnología obsoleta en comparación con proyectos similares de tamaño similar que utilizan tecnologías más nuevas. También parece que tomará de 50 a 80 semanas-hombre para migrar todo el código base; Durante este tiempo, no habría nuevas características lanzadas. También existe un riesgo del 10% de que la migración de un componente específico resulte en 20-30 semanas de trabajo adicionales.

• Por otra parte, tiene suposiciones hechas por vendedores, en función de su influencia al negociar con la persona que necesitan para convencer.

Se trata de cuán influyente eres en tu empresa. La comunicación es clave aquí, y aquí es donde los vendedores generalmente se ganan a los profesionales de TI cuando se trata de explicar los beneficios de una característica a la administración (o un cliente).

Tenga en cuenta que si en el pasado sus estimaciones fueron bastante precisas, ganará reputación e influencia. Si sus estimaciones fueran siempre erróneas, la administración probablemente ignoraría sus propuestas.

En cuanto a las estimaciones, es extremadamente difícil hacer una valiosa aquí, ya que hay una gran cantidad de parámetros a tener en cuenta. Entre otros:

• ¿Sabe realmente cuán hábil es su equipo en C # en comparación con VB6? ¿Se basa en mediciones reales o solo en suposiciones?

• ¿Este equipo ha desarrollado grandes proyectos en C #? ¿Conocen las herramientas que deben usar (IDE, depuradores, perfiladores, etc.)? ¿Necesita licencias adicionales (que, en el mundo de Microsoft, significan miles de dólares por máquina)?

• ¿El proyecto actual es totalmente claro y puede garantizar que no habrá sorpresas al migrar? ¿Es sencillo reescribir todo , cada característica, o habrá sorpresas?

• ¿Tiene la infraestructura que admite C #? ¿Qué pasa con la integración continua? ¿Qué pasa con su servidor de compilación? ¿Guías de estilo? ¿Damas estáticas?

• En producción, ¿los servidores (si se trata de una aplicación web) o las PC de los clientes (si se trata de una aplicación de escritorio) pueden ejecutar la versión de .NET Framework que esperan usar?

Pero lo más importante es saber por qué , ¿quieres reescribir todo? ¿Cuál es el problema que está tratando de resolver a través de una reescritura? ¿Una pérdida de productividad? ¿Como lo mides? ¿Cómo muestra esta pérdida de productividad a la gerencia?

Una vez que haya demostrado que está desperdiciando, digamos, $ 8 000 por día debido al VB6 (lo que significa que ahorrará $ 8 000 por día una vez que migre a C #), ¿cómo explica el beneficio de tener cada nuevo? ¿Desarrollo de características y enfoque en una reescritura completa? ¿Cuál es el beneficio en comparación con la reescritura progresiva en la que migra sus componentes en trozos pequeños uno por uno, mientras envía nuevas funciones?

En primer lugar, debe estimar el costo de desarrollo de la re-factorización como lo haría con la solicitud de características impulsada por las ventas.

Esto puede ser difícil de obtener con precisión si es un trabajo grande pero, suponiendo que tenga suficiente experiencia en las 2 tecnologías, debería ser factible.

En segundo lugar, necesita una estimación del costo de no re-factoring. Si estuvieras haciendo las estimaciones por mí, esperaría algún nivel de métricas. Por ejemplo, la diferencia entre el costo de desarrollo promedio para el código VB y el código C # en un trimestre. O algo así. Obviamente, dependerá de la precisión con la que rastree esto.

Con estos 2 números, puede estimar el período de recuperación que le dará la re-factorización, es decir, en qué momento pasará la re-factorización de un costo neto a una ganancia neta.

Solo puedo adivinar cuán persuasivo sería cualquier resultado dado. Sin embargo, si es menos de un año, probablemente será bastante fuerte, mucho más de 2 años, entonces es posible que tengas problemas.

Además, probablemente vale la pena agregar otras dimensiones para ayudar a construir su caso. Una que he usado en el pasado es ver si alguna de las entrevistas de salida mencionó la tecnología como conductor. Si es así, puede argumentar que la re-factorización retendrá al personal (la contratación y capacitación son muy caras).

Obviamente, puedes argumentar estas cosas sin evidencia de apoyo, pero encuentro que puede hacer una gran diferencia en el impacto del caso.

El valor de la refactorización aparece de varias maneras diferentes.

Le ayuda a realizar otros cambios más adelante, por lo que los X días que tomaría esa función ahora tardarían 2 / 3X días en completarse. Para utilizar la terminología ágil aumenta la velocidad.

El cambio explícito enumerado ayudaría con el tiempo, ya que ya no necesitaría mantener a los desarrolladores con experiencia en VB6, solo aquellos con experiencia en C #.

También ayuda en otras formas menos tangibles, como la retención y el reclutamiento de personal. ¿Un trabajo haciendo C # y VB6 sería más o menos atractivo que un trabajo haciendo solo C #? ¿Sería más o menos probable que acepte un trabajo o permanezca en un trabajo basado en una buena base de códigos o en una pésima?

Creo que el punto que faltan las otras respuestas es que necesitas medir el costo de refactorización contra la pérdida de ingresos por no refactorizar.

Refactorizar por cambiar el código es una pérdida de tiempo. Necesita aportar valor a la tabla. En este contexto, no me refiero a pasar una hora refactorizando una clase problemática, sino a la refactorización principal, como cambiar a un idioma CLR diferente como lo usó en su ejemplo.

• Si seguimos haciendo lo que estamos haciendo, ¿nos estamos perdiendo algo? ¿Hay un diseño viejo y sucio en el lugar que nos está impidiendo darnos cuenta del valor? Por ejemplo, si deseamos agregar una característica, es tan difícil que podría tardar, por ejemplo. ¿100 horas para implementar, frente a 50 horas para refactorizar y 25 horas para implementar en contra del nuevo diseño?

• ¿El código existente conlleva deuda técnica que nos está costando dinero? ¿Este código antiguo es la fuente de errores? ¿Terminamos trabajando gratis para solucionar problemas debido a eso? A nadie le gusta regalar lucrativas horas facturables gratis.

• ¿El costo de refactorizar es igual o menor que el costo de no refactorizar?

• ¿Es posible amortizar el costo haciendo que un pequeño equipo de rockstars refactorice el código que causa más problemas? ¿Podemos difundir el refactor a través de lanzamientos? Hay pequeñas ineficiencias en todas partes: ¿podemos "llenar los vacíos" para hablar con este trabajo adicional?

Beneficios de tener un sistema refactorizado

Usted hace un caso de negocios para refactorizar comparando los beneficios de negocio entre hacer y no hacerlo. Significa una reducción de los costos reales actuales o un aumento en la entrada de efectivo real en el futuro.

Los principales elementos del presupuesto afectados por la refactorización son los siguientes:

• Costos de mantenimiento: si el sistema actual es un frágil montón de espaguetis, y es observable en la práctica que corregir errores pequeños (tanto en el desarrollo como en las operaciones) requiere una gran cantidad de horas-hombre, entonces se puede esperar que Los costos de dicho mantenimiento serán menores para un sistema "debidamente rediseñado". Observe cuáles son sus costos anuales de mantenimiento puro y cómo podrían cambiar de manera realista después de la reescritura.

• Costo de agregar nuevas funciones: una vez más, si el diseño y la estructura actuales del sistema hacen innecesario el tiempo necesario para escribir nuevas funciones, entonces una reescritura puede proporcionar ahorros. Eche un vistazo a su presupuesto planificado para nuevas características, pero sea realista: si afirma que verá una mejora del 50%, entonces espere desarrollar realmente características en x meses-hombre que antes tardaron 2 * x meses-hombre en realizarse; tales promesas pueden ser difíciles de cumplir.

• Impacto de la calidad del software en las ventas: si el sistema actual causa con frecuencia problemas visibles para el cliente, por ejemplo. Los accidentes o el tiempo de inactividad a pesar del esfuerzo de mantenimiento adecuado, entonces una reescritura puede ser una solución. SI este es un problema importante, entonces el mismo personal de ventas puede cuantificar el valor de una 'característica' llamada 'producto más estable'.

Si los tres puntos anteriores no alcanzan el costo esperado de reescritura (y más; el costo de oportunidad de gastar x días de desarrollo en no características es igual al valor de esas características, que es mayor que el costo puro de los x días de desarrollo) entonces me temo que ya está, los ahorros esperados no justifican la reescritura.

Además, si su hoja de ruta no muestra la necesidad de "tanto como puede proporcionar" nuevas características, entonces los ahorros deberían estar en una forma 'que solía llevar a 10 personas a hacer todo lo necesario , pero después de la reescritura podremos hacer lo mismo con solo 6 personas '. Si puede "vender" más proyectos de desarrollo que los que tienen los desarrolladores, la mejora de la eficiencia le permite desarrollar más cosas, pero si la empresa con los recursos actuales ya puede desarrollar todas las cosas que aportan un valor adicional, entonces el único beneficio financiero Puede venir de pagar menos personas o tener personas más baratas.

El valor de la refactorización se puede medir así: la nueva característica x actualmente costará 5 devs 2 semanas. Si reformulamos el componente anterior, el costo de las nuevas funciones se reducirá en un 20% estimado. Así que la nueva característica x solo costará 4 devs en 2 semanas.

La refactorización es una inversión para reducir el costo de desarrollos futuros. Si no puede presentar ese argumento para su refactorización, es probable que no haya un caso comercial para ello.