Cuantificación del valor de refactorización en términos comerciales [duplicado]

He tenido algunos éxitos al explicar estas ventajas:

1. Menos errores en el futuro (incluso el personal de ventas sabe que los errores son malos).
2. Más fácil, más rápido y más barato para solucionar errores en el futuro.
3. Es más fácil, rápido y económico realizar mejoras en el producto.
4. Es más fácil, rápido y económico agregar funciones completamente nuevas al producto.
5. Integración más fácil, rápida y económica con sistemas de terceros.
6. Cuanto antes pueda comenzar a refactorizar, menor será la deuda técnica que llevará y mejor será el producto (1-5 será más fácil).

He tenido un éxito limitado con términos como deuda técnica, algunas personas comerciales lo consiguen, algunos piensan que solo son personas tecnológicas que tratan de justificar sus propias cosas, todo depende de la persona a la que intenta explicárselo. .

Una estrategia que funciona bien (siempre y cuando no permita que la deuda técnica se acumule demasiado) está pagando poco a poco haciendo refactorizaciones pequeñas y medianas al comienzo de la próxima mejora / característica / cambio que los vendedores quieren.
Haz que sea parte de su solicitud, "seguro, podemos hacerlo, sin embargo, deberemos mejorar esta parte del sistema para que sea compatible con esta nueva función".

Si puede obtener métricas reales de cuánto tiempo se ahorrará haciendo refactorizaciones, entonces, personalmente, he encontrado que una doble estimación funciona mejor, ya que todas las personas comerciales saben que las estadísticas pueden ser manipuladas y las estadísticas de desarrollo (dependiendo de la persona) puede ser vista como egoísta.
Por doble estimación me refiero a que "seguro, la característica X tardará 3 días si arreglamos el subsistema Y, de lo contrario, está buscando X + Z días para solucionarlo. Además, reducirá nuestras llamadas de soporte y realizará las característica W más rápido para agregar. "

Si a las personas les gustan las métricas, entonces combine el tiempo dedicado a las llamadas de soporte técnico sobre la característica / producto X con mi doble estimación, de esta manera podría generar un gráfico / hoja de cálculo / costos para mostrar el costo de la característica X en función del soporte continuo Llamadas con una reducción estimada de refactorizaciones.
Con el tiempo, podría generar cifras reales para la característica X antes y después de la refactorización.

La obtención de cifras reales para los costos de desarrollo es más complicada, ya que cada función solo se implementa una vez (¡con suerte!) una idea es hacer un seguimiento de cuánto demoran las refactorizaciones y producir un gráfico de doble estimación agregando los costos de refactorización como " Lo que habría costado sin una refactorización ", que es de esperar que sea más alto que su estimación real, esto debería hacer que el ahorro de tiempo / costo sea muy obvio.

Básicamente, con un código base limpiador casi todo se puede hacer más rápido y, por lo tanto, más barato de lo que podría ser, lo que brinda un valor extra y un mejor retorno de la inversión para los comerciales.

Me parece muy buena la respuesta de SteB (que he votado). Me gustaría elaborar un punto en su respuesta (como un ejemplo que podría aplicarse también a otros puntos).

  

Más fácil, más rápido y más económico de realizar mejoras en el producto.

¿Cómo convencer a la gerencia de esto?

Supongamos que acaba de tener la versión 1 del producto X.

Ya sabes que la característica Y está planeada para la versión 2 y la característica Z es casi seguramente necesaria para la versión 3.

Luego puedes hacer un presupuesto (realizar una sesión de aseo con cartas de póker) y luego ir a tus gerentes y decir:

• Con el código actual, la función Y tomará 8 semanas, la función Z tomará 6 semanas.
• Con el código refactorizado, la característica Y tomará 4 semanas, la característica Z tomará 2 semanas. La refactorización tomará 2 semanas.

Así que tienes los siguientes escenarios:

1. Versión 2 con la característica Y. La característica Y cuesta 8 semanas sin refactorización, 6 semanas con refactorización.
2. Versión 2 y 3, con ambas características Y y Z. Las características Y y Z cuestan 12 semanas sin refactorización y 8 semanas con refactorización.

Por supuesto, esto es solo un boceto, pero OMI. Si puede realizar un análisis similar, podría tener más posibilidades de convencerlo de su gestión: significa que tiene una idea concreta de los beneficios de su refactorización, aunque solo sea una estimación. .

NOTA : si te resulta difícil realizar un análisis similar, pregúntate qué posibilidades hay de que no lo necesites.

Estoy con el comentario de @maple_shaft arriba:

No escriba código incorrecto , incluso al hacer prototipos. Piense en su código prototipo como un enfoque de balas trazadoras. Algo que se convertirá en el producto final, incluso si aún no está allí.

No es necesario que explique o justifique la refactorización a la administración; debe ser una parte continua del proceso. Al igual que no explica por qué está haciendo una estructura de herencia específica, utilizando un marco específico, etc. Estos son detalles técnicos. Sus clientes solo se preocupan por el resultado, ya sean de administración o de clientes finales.

Lo que quiere evitar es tiempos de inactividad prolongados donde "nada" sucede en lo que respecta al mundo exterior. P.ej. no desea escribir una gran cantidad de código incorrecto, luego tómese 3 semanas para refactorizarlo y hacerlo bueno. En primer lugar, no funcionará muy bien; y, en segundo lugar, podría sentirse tentado a explicar que ahora se está tomando el tiempo para refactorizar. Lo que para un extraño sonará como si estuvieras tomando algún tipo de vacaciones geek.

Refactorea temprano . Si ves que algo está mal, y sería un poco doloroso hacerlo bien: hazlo. Anexo a eso: si no está seguro de que algo está mal o no sabe cómo mejorarlo, déjelo solo hasta que lo haga.

He estado allí muchas veces.

Hay algunas maneras de manejarlo, aunque no es fácil.

Casi lo has dicho tú mismo: solo les importa que hagas lo más rápido posible. Muestre a las partes interesadas un caso de negocios en el que una ronda de refactorización de X meses reducirá el tiempo necesario para desarrollar nuevas rondas, y trate de calcular el retorno de la inversión (ROI), el retorno de la inversión, después de aproximadamente un año, para la refactorización.

O, si esto es muy difícil, hay otros argumentos económicos que podrían ayudar - "Dado que estamos ejecutando un prototipo en producción, necesitamos contratar a dos ingenieros más para mantenerlo. Este costo se puede evitar si asumimos Un proyecto de refactorización ".

Si tiene centros de costos internos, etc., asegúrese de que las personas operativas que apoyan esta aplicación cobren más por ella que las aplicaciones similares "dignas de producción".

Si su equipo tiene algún control, podría ser posible incluir una refactorización en las nuevas fases de desarrollo de características. Supongamos que desean introducir jerarquías complejas en un modelo de datos ya de mierda. Incluya la refactorización como un requisito de tecnología para realizar cambios en el modelo de datos. Un caso similar: si le pide a su plomero que cambie el radiador, si el tubo está demasiado oxidado para que funcione correctamente, es probable que lo haga. Cambia eso también, ya que es su profesión saber qué hacer. Lo mismo (debería) va para los desarrolladores de software.

Si golpeas la pared, reúne estadísticas para tus argumentos. Etiquete cada error / problema operativo que se haya reportado y que podría haberse evitado con un código digno de producción. Luego, puede mostrar un caso de negocios al reducir los errores con tantos y tantos%, y aumentar el tiempo de actividad / estabilidad en otro%.

Sin embargo, siempre existe el hecho de que el desarrollador de software desea hacer la mejor solución posible, cuando solo lo hará "lo suficientemente bueno". Si no puede inventar argumentos económicos para refactorizar, probablemente no valga la pena y no debería hacerse.

Poner un prototipo en producción es peor que un proyecto de diseño deficiente porque muchos tomadores de decisiones creen que es mejor de lo que realmente es. A lo largo del proceso de creación del prototipo, recordó a todos que "Esto es no está listo para la producción ". Las probabilidades de llegar a este punto eran bajas porque no estaban seguros de que:

• Se podría construir.
• Cualquiera iba a necesitarlo / usarlo realmente.

No te concentres en "Te lo dije" , pero deja en claro que no podrás mantener el cronograma del prototipo ni puedes usar ninguna de esas métricas para determinar cómo Cuánto tiempo tomará crear funciones listas para la producción. Verán la función del producto, pero les recuerdan problemas como:

• Es posible que no pueda manejar un mayor número de usuarios
• El manejo de errores no es suficiente para el usuario típico
• No puede acomodar muchas de las funciones recién solicitadas.
• Hay poca o ninguna prueba

Los miembros no técnicos de la alta gerencia no comprenderán el concepto de refactorización. Lo tienen en su cabeza: esto "funciona" y no liberarán ese pensamiento durante toda la duración del proyecto, no importa cuántas veces le digas algo a la contrayente. Solo vas a tener que hacerlo parte de tus especificaciones. Los gerentes técnicos pueden estar bajo una fuerte presión de tiempo y pueden intentar eliminar muchas de estas tareas de las especificaciones del proyecto. "¿Por qué estamos trabajando en características que ya están completadas?" Algunos de los otros usuarios proporcionan algunas formas de explicar por qué este no es el caso.

Buena suerte

Me gusta responder esto a través de analogías no técnicas.

Algunos ejemplos:

Puedes construir fácilmente casas de hasta 5 pisos de altura con ladrillos. Usted puede agregar fácilmente en un solo piso. ¡Pero intente ir a 20 o 30 pisos y de repente bam! Los azulejos están explotando porque necesitas una mejor infraestructura como vigas de acero. Resulta que la infraestructura es importante y está bien hecha lo antes posible mediante la "refactorización" de la inicial ...

Usted conduce su gar. ¡Todo lo que necesita para funcionar es gas! Bueno, eso y ... el aceite cambia frecuentemente. Ah, y con poca frecuencia, llantas nuevas, y ocasionalmente otros fluidos y piezas. Resulta que el mantenimiento es parte de ser un propietario responsable de un automóvil ...

¿Puedes siquiera definir inequívocamente qué es la refactorización? La fusión de dos procedimientos es probablemente refactorización. Pero ¿qué pasa con cambiar el nombre de un objeto? ¿Un método? ¿Una variable pública? ¿Una variable privada? ¿Qué pasa si cambias la implementación de un método sin cambiar su firma? ¿Qué pasa si ese cambio lo hace lento para un cierto tipo de entrada que a su vez provoca un cambio en una parte distante del código? Supongo que lo que estoy diciendo es que necesitas una definición realmente clara de lo que estás tratando de medir antes de poder elegir una o varias formas de medirla.

Esto también es difícil porque no ve de inmediato el beneficio de la refactorización. Digamos que usted convirtió 5 objetos con 12 métodos en 3 objetos con 5 métodos. Le ahorrará mucho tiempo en el futuro, pero duplicó el tiempo que tardó en entregar la función actual. Así que es una pérdida a corto plazo para el negocio por una ganancia hipotética a largo plazo. La refactorización a veces incluso empeora las cosas, aunque a menudo las mejora.

Supongamos que refactorizar significa que un cambio en una parte del código requiere que usted cambie otra parte del código de tal manera que la funcionalidad de todo el programa se conserve (más o menos), pero la forma en que Trabaja internamente es diferente. Entonces, por definición, el usuario final generalmente no verá el efecto de la refactorización (a menos que mejore el rendimiento o permita una simplificación de la interfaz de usuario que aún proporciona la misma funcionalidad de línea de base al usuario).

Por lo tanto, tiene que medir las cosas a largo plazo para mostrar un impacto positivo y, por definición, es un impacto indirecto. Pensé en esto todo el día de hoy y me recordó a un estudio publicado en la revista Time hace unos años sobre lo que hace que la gente viva más tiempo. En lugar de preguntarle a la gente cuánto fumaban o bebían bebidas carbonatadas o lo que fuera, observaron las poblaciones de mayor vida en el planeta y analizaron cientos (o miles) de dieta, estilo de vida y factores ambientales para determinar cuáles eran comunes entre aquellos en los que estaban De larga vida y poco frecuente para las personas en general.

Lamento no poder pensar en una métrica que se pueda medir cada mes y mostrar con un pequeño gráfico cómo se está refactorizando mejor que nunca, o correlacionar directamente la refactorización con los resultados de su empresa. Pero creo que usted (o un departamento de CS en una universidad afiliada) podría observar las características de los equipos de software exitosos para ver si la refactorización es algo que los distinga o no. Yo sospecharía que lo haría, pero estaría extremadamente interesado en ver un estudio. Tal vez alguien más en este foro pueda apuntar a un estudio de este tipo?

He estado en esas posiciones (supongo que todos lo hemos hecho).

Muy a menudo, esta es una respuesta muy efectiva:

  

Me has pagado durante un año para desarrollar este proyecto. Si mañana me atropella un autobús, ¿quieres pagarle a alguien por dos años más?   ¿Cómo desentrañar el lío que dejé atrás? ¿No es mejor que me pagues durante tres meses, para que el próximo jugador esté al día en un mes?

Importante: asegúrate de no obtener el arranque cuando te escuchan que pasaste un año escribiendo un código desordenado, para que puedas obtener un prototipo a tiempo ...