Es como dijo Gandhi cuando se le preguntó si su táctica funcionaría con alguien como Hitler. Él dijo: "Sería difícil". Pero creo que hay un argumento justo de que la respuesta realmente es "No". Lamentablemente, no creo que se pueda hacer lo que intentas hacer. No es que trate de ser pesimista, sino que trato de ser honesto.
El problema para mí no es que los gerentes necesiten convencer. Los mejores ya entienden que la deuda puede ser mortal si no se gestiona. Pero ya sea que lo entiendan o no, ya sean buenos gerentes o malos, todos enfrentan la presión de cumplir, y sus jefes juzgan esa entrega contra una fecha. La calidad solo importa si es extremadamente mala, en cuyo caso es culpa de los desarrolladores, o extremadamente buena, en cuyo caso es la brillantez de la administración lo que lo hizo posible. La calidad solo necesita ser "suficientemente buena".
Creo que me gusta lo que dijo Renesis en su respuesta, porque es uno de los pocos que entiende que la gerencia piensa de manera muy diferente a la ingeniería. Y creo que todos hemos visto la progresión de las empresas para convertirse en fechas y más proyectos gestionados en lugar de centrados en el cliente y la calidad. Con esto, me refiero a compañías típicas, no a las realmente firmes que tienen las agallas para decir "Se hará cuando esté hecho" (como Apple Computer o id Software, y sí, entiendo que a veces las personas no están en libertad para tomar ese enfoque).
Pero aquí está la cosa: las empresas que adoptan el enfoque de calidad primero ... ¿qué notas sobre ellas? Así es, están a cargo de ingenieros, no de vendedores, vendedores, gerentes de proyectos o contadores. Piense en HP, Apple, id, Google, Microsoft e IBM. Todo comenzó y fue exitoso por ingenieros, no por vendedores, aunque los vendedores ciertamente jugaron un papel, y estoy seguro de que muchos debatirían si Microsoft está asociado con la calidad :). Y de esos, los que fueron cuesta abajo se alejaron del liderazgo impulsado por la ingeniería. Sin embargo, hay una gran cantidad de argumentos en esa declaración, ya que hay muchas compañías técnicas que finalmente fracasaron debido a la incapacidad de adaptarse a los tiempos cambiantes y administrar su propio crecimiento. No veo el liderazgo basado en ingeniería como la causa de esos fracasos, para mí eso ' Es un problema de habilidades y perspicacia comercial que son independientes de que alguien sea desarrollador o contador. Sin embargo, en términos generales, creo que hay una dedicación en la ingeniería a los rigores de la responsabilidad y la disciplina que beneficia a las empresas donde la ingeniería es un componente.
En serio, mira a tu alrededor. Falta el liderazgo de TI. El enfoque siempre está en el costo y el tiempo, y rara vez en la calidad, siempre que sea lo suficientemente bueno. Los líderes de TI rara vez se reportan al CEO, ahora siempre es el CFO. TI está atrapado en el soporte de producción y está cada vez más en deuda con los gerentes de proyecto cuyo enfoque está en trozos más pequeños, más digeribles y medibles, no en cambios significativos de valor revolucionario (no es que esto sea necesariamente incorrecto; dividir y conquistar es algo bueno, pero la visión necesita estar allí para el panorama general).
Lamento tomar tanto tiempo en esta publicación, pero al final creo que su pregunta, sobre cómo hacer que la administración se preocupe por la deuda técnica, a menudo se resuelve mejor al encontrar el líder correcto, en lugar de cambiar el existente. Explicar la deuda técnica a los pensadores estándar significa cambiar el enfoque al dinero y al costo, como dijo Renesis, y creo que eso pierde mucho en la traducción; incluso si tuvieras éxito en ello, solo importaría si el líder líder de la compañía lo comprara. Convencer a su gerente intermedio de que haga lo correcto probablemente solo lo despedirá.