¿Algún consejo sobre cómo 'vender' la necesidad de lidiar con la deuda técnica a las partes interesadas no técnicas?

Puede abordarlo destacando los aumentos en los costos de desarrollo causados ​​por la deuda técnica. Ese es un problema al que también nos enfrentamos ahora mismo. Las empresas solicitan cada vez más funciones que necesitan cuando mi equipo realmente quiere eliminar la deuda técnica.

Subrayamos que con menos deuda técnica, las nuevas funciones se pueden enviar mucho más rápido, y más rápido significa más barato. Y más barato, posiblemente con una mayor calidad, siempre ayuda mucho con personas no técnicas :)

Es un poco como detenerse a cortar leña para afilar el hacha.

Adopte un enfoque más proactivo para hacer frente a la deuda técnica

En uno de mis proyectos anteriores, teníamos una parte importante de un sitio que funcionaba con datos anuales recopilados por la empresa. Desafortunadamente, la base de datos se diseñó de tal manera que los datos de cada año irán a una base de datos separada. Cuando llegó el momento de lanzar los datos del año en curso, necesitó mucho trabajo por parte del equipo de desarrollo, así como pruebas exhaustivas.

Nuestro equipo de desarrollo calculó cuánto esfuerzo se necesitará para realizar cambios en la arquitectura y el código base. Luego, también estimamos el ahorro de tiempo cada año como resultado del cambio. Luego nos sentamos con el equipo comercial y obtuvimos la aprobación para el esfuerzo único de pagar esta deuda técnica.

Me gusta este enfoque más proactivo defendido por Steve McConnell: Cómo categorizar y comunicar la deuda técnica

1. Incluso en el momento de asumir la deuda técnica, el equipo de desarrollo debe estimar el esfuerzo para hacer el trabajo de la manera correcta, así como el atajo. Si la empresa elige el atajo, cree un ticket de error para la deuda técnica de inmediato y colóquelo en la cartera de pedidos.
2. Cuando la deuda tiene más de 6 meses, se eleva a severidad 1 y debe eliminarse lo antes posible.

También puede probar su otra sugerencia: cuando la velocidad comience a disminuir, vea si se debe a demasiada deuda. Luego dedique una iteración para reducir la deuda técnica con la expectativa de que la velocidad aumente.

Por analogía, le está pidiendo a la gente que reemplace un automóvil que funciona perfectamente bien porque sabe que en algún momento el costo de mantener el automóvil existente no valdrá la pena. Debe proporcionarles estimaciones bien pensadas de cuándo será ese momento. En otras palabras, la única forma de convencerlos es presentar un caso comercial claro y justificable. Si no puede documentar cuáles son los beneficios en dólares, simplemente está nadando contra la corriente.

Para ser honesto, no he visto muchas personas en las tiendas de TI dispuestas a comprometerse a reducir su presupuesto de mantenimiento de sistemas en $X por año si se les da $Y para actualizar sus sistemas. La mayoría lo posiciona como un costo de hacer negocios o argumenta que se está reduciendo el riesgo de catástrofe. Todo esto puede ser cierto, pero no es un argumento convincente porque huele (como dices) a niños que quieren juguetes. Desde la perspectiva de un PM, también me parece una buena manera de salirse con la suya sin pensar en el lado de los beneficios de la ecuación, lo que me resulta molesto.

Las partes interesadas no técnicas solo necesitan saber cuánto trabajo se necesita para agregar la nueva función. Al igual que las pruebas unitarias, la refactorización debe incluirse en la estimación para agregar la nueva función. Es parte del proceso de desarrollo.

Si puede agrupar funciones que se benefician de la refactorización, el trabajo adicional se puede distribuir en el grupo y no se asigna a ningún elemento individual. Esto suele ser más apetecible.

Aquí está el problema: muchas veces las partes interesadas me han preguntado por qué un cambio llevará más tiempo que la última vez que hicimos un cambio similar. Bien: ¡las partes interesadas no son tontas y están prestando atención! Mi respuesta es: "Hemos superado el diseño original. Según la cantidad de cambios anteriores relacionados con esta nueva función, necesitamos implementar un nuevo diseño. Esto nos permitirá agregar esta nueva función y admitirla en producción".

Lo que está buscando es una analogía que les ayude a comprender el problema en términos sencillos y cotidianos.

Recomiendo encarecidamente el video que enlazo a continuación, que muestra a un mecánico agregando características a un automóvil de una manera completamente desorganizada hasta el punto de que, por ejemplo, agregar un GPS hará que el automóvil no pueda girar a la derecha.

https://www.youtube.com/watch?v=u5reSgbrVrM

A Ward Cunningham originalmente se le ocurrió la metáfora de la deuda técnica para "vender" la noción de que los costos de refactorizar el código "por adelantado" superan significativamente los costos de tener que dedicar tiempo "en el futuro" a construir funciones adicionales en una base de código con acceso restringido. extensibilidad. Usó la metáfora de la "deuda" en ese momento porque las personas a las que estaba tratando de convencer eran tipos de finanzas y quería conectarse con ellos en un idioma que pudieran entender.

Si necesita “vender” la misma idea fundamental pero la metáfora de la deuda técnica no funciona, presumiblemente se debe a que las personas a las que intenta convencer no son especialistas en finanzas. En este caso, vale la pena buscar una nueva metáfora con la que su grupo objetivo pueda relacionarse fácilmente.

Aquí hay una idea simple de cómo crear una metáfora diferente:

Un chico joven, llamémosle Mike, consigue su primer trabajo remunerado y decide que es hora de mudarse de la casa de sus padres a su primer piso. Para empezar, Mike toma una habitación espaciosa pero sencilla donde puede dormir y guardar sus cosas, pero donde necesita usar un baño compartido con otros inquilinos del bloque.

Después de su primer aumento de sueldo, Mike decide que sería bueno tener un poco más de comodidad al tener su propio lavabo en lugar de usar el que está al final del pasillo. Llama a alguien para que lo ayude a implementar esto y, aunque le aconsejan que es una buena práctica construir un baño cerrado donde se pueda instalar el lavabo, se decide por la opción menos costosa de instalarlo junto a su cama.

El tiempo pasa y Mike obtiene un ascenso en el trabajo, momento en el que comienza a pensar: “¡Esto de la comodidad y la privacidad es genial! ¡Creo que también me daré una ducha aquí! Entonces llama al chico del lavabo y comienza a discutir las opciones. Ahora, el chico del lavabo nuevamente ofrece algunas alternativas de menor y mayor costo, pero esta vez insiste bastante en que la opción de mayor costo de construir un baño independiente es lo correcto porque le dará a Mike la opción de instalar un inodoro y una bañera en el futuro. Mike piensa largo y tendido sobre esto: además del costo de construir el baño, también está el costo de mover su lavabo allí. Y ni siquiera está seguro de si realmente va a querer un inodoro o una bañera de todos modos.

Esta historia tiene un final feliz. La alternativa (menos final feliz) ve a Mike optar por instalar su nueva ducha junto a su televisor y luego se ve obligado a cambiar tanto el lavabo como la ducha a su baño de todos modos.

En esta metáfora, el tipo del lavabo (es decir, el equipo de desarrollo) recomienda la creación de un baño independiente, así como la reubicación de los servicios existentes (es decir, una refactorización de la configuración existente) para preparar la instalación de un inodoro o una bañera (es decir, desarrollo de características futuras).

Es un ejemplo bastante doméstico, pero espero que te ayude a pensar en otros más aplicables a tu dominio.