Descubrí que si puedes proporcionar números válidos, es más probable que los gerentes actúen. (Si pueden entender la lógica y el costo / beneficio).
En mi humilde opinión, para hacer un caso convincente, necesitarías lo siguiente para mostrar lo malo que es:
- número de incidencias de soporte registradas para los problemas
- tiempo empleado en horas manteniendo / ayudando de banda el código incorrecto / haciendo soporte
arreglos
- costo de tiempo basado en la tarifa por hora de las personas que realizan el mantenimiento / banda
ayudas / soporte
- alguna manera de demostrar cuán críticos son estos elementos para la misión
negocio
Y para justificar la refactorización, necesitarás:
- tiempo estimado para refactorizar e implementar cada uno de los 3 principales
cosas malas
- costo estimado para la implementación (las mismas tarifas por hora que se usaron anteriormente)
Con estos, puede justificar el ahorro de tiempo si la refactorización toma mucho menos que el tiempo de soporte para 3 incidentes para cada uno de los 3 elementos principales. Puede argumentar que esta menor cantidad de tiempo invertido se
- ser menos que n más incidentes de soporte
- no habrá más de estos incidentes por estas cosas (¡YA MEJOR!)
Sin embargo, la parte más difícil de esta venta será responder a la siguiente pregunta, ya que muchas personas no asignan tiempo en el presupuesto para todo el apoyo que estás haciendo:
¿Cuánto tiempo más tendré que esperar a que termine el proyecto actual Y mientras está gastando tiempo trabajando en estos problemas con X ????? (a pesar de los tiempos de soporte actuales, que no se puede predecir y programar en los diagramas de Gantt)
Esto depende mucho de lo bien que se comunique con los tomadores de decisiones y de cómo entienden la situación.
DEFINITIVAMENTE, creo que vale la pena hacerlo, por lo que tiene la práctica de construir el caso con las métricas y ahorrarse tiempo, incluso si no lo hacen. Desafortunadamente, no todos son fáciles de convencer, a pesar de los datos. ¡BUENA SUERTE!