Parece que tus problemas son más generales.
El problema de refactorización es tanto un síntoma como un alivio potencial de parte del problema.
El líder de software y el equipo asignan el tiempo del equipo
Desde mi experiencia, creo que puede estar encontrando un problema que llamo "todos son administradores de software". Los gerentes de producto, gerentes de proyecto y, a veces, ingenieros y probadores de sistemas pueden ser conocidos por tratar de microgestionar a desarrolladores que probablemente ya tengan un administrador de software experimentado. Incluso puede tener algunos miembros en su equipo que creen que su rol es administrar.
Si usted es el administrador de software, haga asignaciones para la refactorización que desea, o mejor aún, haga que su equipo le proponga la refactorización para su aprobación. Para no microgestión, es posible que tenga pautas sobre la edad / autor / tamaño / contexto del código que se refactorizará que se puede refactorizar libremente frente a la necesidad de aprobación. Si un miembro de su equipo quiere refactorizar masivamente cuatro grandes clases de código antiguo complejo que no escribió y que no forman parte de su función, su desviación de dos semanas es su problema, por lo que necesita una oportunidad para decir que no.
Puede escabullirse, pero creo que es mejor construir sus estimaciones cuidadosamente con tiempo para el análisis, diseño, codificación, múltiples formas de prueba (al menos unidad e integración), refactorización y riesgo como se juzga históricamente y por la falta de experiencia o claridad asociada con la tarea. Si ha sido demasiado abierto sobre el funcionamiento de su equipo (o tiene miembros de su equipo que lo son), puede ser conveniente restringir los canales de comunicación para que lo atraviesen y discutan recursos y resultados, no métodos.
Las primeras elecciones de proyectos crean un círculo vicioso para la refactorización
El mantenimiento del software es difícil. Es doblemente difícil si otros miembros de la organización toman decisiones a su cargo. Esto está mal, pero no es nuevo. Ha sido abordado por Barry Boehm, uno de nuestros grandes escritores de software que presenta un modelo de gestión que describe como Theory W.
http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf
A menudo, los desarrolladores de software se ven obligados a producir bajo el enfoque de gestión de Theory-X que dice que los trabajadores son básicamente perezosos y no funcionarán a menos que sean sometidos. Boehm resume y contrasta su modelo propuesto de la siguiente manera:
"En lugar de caracterizar a un gerente como un autócrata (Teoría X), un entrenador (Teoría Y) o un facilitador (Teoría Z), la Teoría W caracteriza el papel principal de un gerente como negociador entre sus diversos grupos y un paquete de soluciones de proyectos con condiciones ganadoras para todas las partes. Más allá de esto, el gerente también establece metas, monitorea el progreso hacia las metas y es un activista en la búsqueda de conflictos cotidianos del proyecto ganar-perder o perder-perder, enfrentándolos, y transformándolos en situaciones de ganar-ganar ".
Rápido y sucio a menudo es simplemente sucio
Boehm continúa señalando la razón por la cual las cosas son tan miserables para los desarrolladores del equipo de mantenimiento.
"La construcción de un producto rápido y descuidado puede ser una" ganancia "a corto plazo y de bajo costo para el desarrollador de software y el cliente, pero será una" pérdida "para el usuario y el mantenedor". Tenga en cuenta que en el modelo de Boehm, el cliente es más un administrador de contratos en lugar de un usuario final. En la mayoría de las empresas, piense en el gerente de producto como un sustituto del cliente, o tal vez como la persona que compra el producto para su lista de características.
Mi solución sería no liberar al equipo de desarrollo original (o al menos al líder original) hasta que el código se refactorice para al menos cumplir con los estándares de codificación.
Para el cliente, creo que es razonable contar con el gerente de producto como un sustituto del cliente, y el grupo de personas recompensado por entregar algo rápido y sucio ciertamente puede expandirse, por lo que existe una gran cantidad de personas para hacer las cosas de manera incorrecta.
La refactorización no es negociable
Por favor, no retroceda de su rol como administrador de software. Debe tener autoridad y discreción para usar el tiempo de su equipo en el proceso y las mejoras del producto. En ese rol, es posible que deba negociar sus elecciones para que su equipo sea más profesional. Sin embargo, con respecto al proceso, no negocies con el marketing, porque en mi experiencia, ese es un juego perdedor. Negociar con la gerencia de ingeniería. Muestra que tienes visión. La creación de un equipo de software profesional es una extensión de su rol, y es mucho más probable que sea visto como un beneficio mutuo.