project management - software - ¿Cómo vender los beneficios del "buen código" a la gerencia?
project management software (20)
Trabajo para una compañía muy pequeña (~ 70 en total con 10 programadores reales) con una aplicación relativamente grande (1M LOC en C ++) que necesita un poco de TLC serio. Debido al tamaño de la empresa, nos vemos impulsados principalmente por lo que podemos vender a los clientes que literalmente no tienen tiempo para el mantenimiento del código, salvo corregir los errores que hacen que las cosas fallen, y no siempre corregirlas bien. ¡Al parecer, así es como la empresa ha trabajado durante los últimos 10 años!
¿Cómo convenzo a la gerencia de que lo que están haciendo les está costando dinero / tiempo / productividad? ¿Qué tipos de estrategias de mantenimiento activo existen? ¿Cuáles son buenas para las pequeñas empresas con escasos recursos?
¿Puedes mostrar que los costos de soporte están aumentando? Ya sea en términos de la cantidad de incidentes de soporte o el% de tiempo que los desarrolladores gastan en soporte.
Intente identificar refactorizaciones manejables que mejoren las cosas, y luego muestre cómo se habrían evitado los errores recientes.
Siempre habrá una tensión difícil entre lo que se necesita hacer para mantener fluidas las nuevas ventas y lo que se necesita hacer a largo plazo para mejorar la ''infraestructura'' del software. Demostrar que la amortización del trabajo de ''infraestructura'' ocurre a corto plazo es la forma más fácil de ponerlo en el radar de la administración.
A veces, usar una analogía puede ayudar a los no entusiastas a entender.
La mejor analogía de por qué es importante la refacturación de códigos, el mantenimiento, etc., que he encontrado es esta. Se toma de una publicación en Slashdot :
Todos echaron una gran cena y luego dejaron los platos por unos días. O peor aún, tenía un compañero de cuarto que sí. Resulta que esto apesta, porque si solo quieres prepararte un pequeño desayuno, entonces es más difícil de cocinar. Tienes que sacar una sartén y un chip de un plato para comenzar. Y cocinar es el doble de trabajo porque tienes que cambiar el desorden solo para llegar al mostrador, y luego cambiarlo de nuevo para llegar a la estufa.
Luego, cuando hayas terminado, seguro que no te lavarás adecuadamente; el fregadero ya está lleno de platos. Así que simplemente tiras tus platos a la cima de la pila, diciendo que llegarás "más tarde". Por supuesto, ese montículo cada vez mayor de platos confusos es la analogía del mundo real de la mitad de las bases de código que he visto. Y las reescrituras gigantes que inevitablemente siguen son como derribar tu cocina y construir una nueva porque esa es la forma más barata de salir del desastre.
En cambio, los buenos chefs trabajan limpios. Ellos limpian a medida que avanzan. Siempre. No porque sean unos fanáticos tensos, sino porque si no lo hacen, el caos los ralentiza y los hace más descuidados, lo que eventualmente da como resultado un grupo gigante, con todos sus colegas gritándoles.
Básicamente: mejor código = menos mantenimiento. Menos mantenimiento = más tiempo para que los desarrolladores desarrollen nuevas funciones. Nuevas funciones = más ingresos.
Además: mejor código = menor curva de aprendizaje para los nuevos desarrolladores.
Descubrí que solo hay tres formas de vender mantenimiento a la administración:
- Hazlo sin pedirlo, pero transfiéralo a un desarrollo de funciones
- Pregúntalo, pero di que es necesario permitir una función o clase de características en particular
- Convencerlos de que recuperarán el tiempo invertido en mantenimiento a través de un desarrollo de funciones más rápido después.
En resumen: la gestión habla de características, no de código.
Dudo que sus jefes comprendan alguna vez la verdadera naturaleza de cómo el código limpio ganará más dinero a su empresa a menos que trabaje para una empresa donde la gerencia media y superior ha trabajado activamente en muchas compañías de software de diferentes tamaños como programadores. No se moleste en darles razones de programador, el simplemente no entenderá. En cambio, tienes que darles resultados.
Mi consejo es encontrar un proyecto que sea lo suficientemente pequeño como para no estar completamente cargados por el código heredado, y seleccionar una metodología que creas que ayudará a limpiar tu sistema, y simplemente hazlo. Haga un seguimiento de sus cambios, documente cómo las diferencias en su proceso son una mejora, y luego monitoree sus resultados a medida que viajan a través del sistema. Al final, si realmente ha contribuido positivamente a las líneas de código, y sus contribuciones rutinariamente pasan las pruebas sin problemas mientras sus compañeros de trabajo no lo hacen, la gente lo escuchará.
Una vez que vean los beneficios de las soluciones, prestarán más atención a los problemas.
El concepto de "deuda técnica" (o "deuda de ingeniería") puede tener sentido para los empresarios. Explique que cada vez que hace algo rápido y sucio, incurre en "deuda" y, por lo tanto, paga "intereses" cada vez que realiza un cambio más adelante. Es por eso que, por ejemplo, agregar un pequeño campo a un formulario puede llevar cuatro semanas en una base de código llena de deudas.
Luego explique que puede pagar esa deuda mediante refacturación (o cualquier término que desee utilizar para la limpieza), y luego los pagos de intereses en curso disminuirán.
Obviamente, como cualquier metáfora o analogía, puede forzarse, pero al usar la terminología comercial / financiera puede cosquillear sus cerebros de manera más efectiva de lo que programmerese lo hará.
En todos mis años, cada vez que trato de decirle a los gerentes y al equipo que el código en el que estamos trabajando es una mierda , recibí bastantes reacciones violentas. (No usé el trabajo apesta). Huelga decir que sus compañías están en el negocio de hacer dinero, y en su opinión, si no está roto, no lo arregle. Y, podrías empeorar las cosas.
Sin embargo, logré reescribir algo esperando la oportunidad de surgir. Algunas características nuevas deben agregarse, y el código se ha descuidado durante un par de años, y apenas se ha compilado. Lo vendí a mi jefe de equipo y gerente, ya que sería un mejor retorno de la inversión para agregar aún más cosas en el futuro. Es decir, fue más rápido para mí reescribir la cosa, y agregar sus nuevas características, que averiguar cómo funcionaba la anterior y atascar una solución allí.
Es posible que desee considerar que las prioridades de su empresa no son conducentes a la producción de código estelar.
Si ese no es el caso, haga propuestas específicas y venda sus propuestas en función de los méritos de la idea específica, ya que reflejan los objetivos de la organización.
Esto depende del modelo comercial en el que su tienda esté trabajando. Si está haciendo el próximo gran videojuego, el próximo gran IDE, o el próximo gran sistema de CRM para alguna compañía, el mérito de limpiar una base de código puede ser evaluado de maneras muy diferentes.
Solo he realizado el desarrollo del servicio y, por lo tanto, no puedo hablar para justificar la limpieza del código bajo ningún otro modelo comercial, pero aquí está mi $ 0.02 para el desarrollo del servicio:
Si está desarrollando servicios para alguna empresa externa, es muy difícil vender un esfuerzo de limpieza. "¿Quieres decir que escribiste un código malo para nosotros? ¿Y ahora quieres más dinero para limpiarlo?" es una pregunta que ninguna tienda quiere estar en la posición de responder. Como desarrolladores, no siempre nos damos cuenta de cuánto les está costando el tiempo a los clientes y están muy centrados en vincular el costo con el valor comercial directo.
Por lo tanto, una forma en la que me gustaría que se realice la limpieza del código en este escenario es describir la limpieza como "modificaciones de requisitos previos" a alguna orden de cambio o solicitud de función. Esto permite que la empresa vincule los costos de limpieza a algún valor directo, que es el cambio o la característica, y les permite utilizar un análisis de costo-beneficio común con el que están familiarizados. Esto le permite tiempo para realizar una limpieza, pero tenga cuidado con el alcance. Abrir latas de gusanos cuando tienes una semana para hacer la limpieza puede ser un asunto arriesgado. Probablemente su propuesta NO dijo: "Reescribiremos la aplicación y luego implementamos su función". Haga un manejo de riesgo y expectativas con su cliente y sea honesto y ético.
Quizás alguien más podría responder a esto bajo diferentes modelos comerciales de desarrollo de software ...
Lo más probable es que entiendan las concesiones y acepten los riesgos. Creo que la sugerencia de volver a factorizar a medida que avanza es probablemente su única esperanza.
Si son una empresa pequeña, como sugiere, estarán mucho más interesados en seguir en el negocio que con un buen código. Los otros 60 no desarrolladores probablemente tengan inconvenientes similares (me gustaría que la hoja de balance / los informes de flujo de caja / presupuestación / presupuesto de marketing / leads de ventas / estacionamiento fuera mejor). Todos se pusieron en posición de decidir con los trabajos de la gente real y los medios de subsistencia en la línea (cuestionario incluido) terminarían tomando el atasco hoy. Es lo correcto cuando eres una empresa pequeña.
Si tiene mucha suerte, encontrará un oído técnico comprensivo en la sala de juntas, por lo que al menos tendrá a alguien que comprenda su dolor y le dé suficiente espacio para eliminar parte del código realmente malo como un proyecto paralelo o durante una lanzamiento de error importante. Esa persona probablemente no necesitará mucha convicción.
Los desarrolladores escriben código, no administradores. Estoy seguro de que su gestión nunca les dijo a los desarrolladores que escribieran un código de mierda. Creo que debes convencer a los otros 9 desarrolladores de que todo código nuevo que se escriba necesita cumplir con una barra de mayor calidad.
Dudo que alguna vez logre que el gerente se vaya y reescriba grandes porciones de código porque cree que la calidad apesta. Sin embargo, debería poder eliminar a los desarrolladores de su compañero de trabajo y al menos ponerlos en el camino correcto.
Con el apoyo de otros desarrolladores, puede convencer a los gerentes de que asignen tiempo libre para la limpieza.
Mi experiencia ha sido que vender un proyecto de "Limpiar la base de código" siempre fallará. Sugeriría uno de los siguientes:
1. Comience asignando tiempo para mantenimiento menor junto con todo el trabajo futuro en sus estimaciones. Puede usar el argumento de que, mientras agregue una función a un módulo existente, podrá mejorarla en ese momento, ya que es más familiar. Asegúrese de expresar los beneficios de la mejora a lo largo del tiempo, y que es más barato en el tiempo que el proyecto "Limpiar la base de códigos".
2. Comience asignando tiempo para mantenimiento menor junto con todo el trabajo futuro pero no se lo digas a nadie. Si alguien se da cuenta, solo dígales que necesitaba refactorizar el módulo en cuestión para completar la función que está agregando.
Otro pensamiento ...
Algo que puede querer hacer es mantener meticulosas estadísticas de errores organizadas por componente de código. De esta forma, puede probar o refutar que la falta de calidad en la base de códigos está generando más errores en el producto entregado. Si ve un aumento constante en el número de errores reportados por mes para componentes particulares, puede ponerlo en un gráfico y dejar que continúe su aumento en el futuro, para demostrarle a la gerencia que eventualmente la mitad de su equipo estará ocupado simplemente manteniendo ese un componente.
Si envía un informe de estadísticas de errores cada semana o mes, esto también ayudará a su equipo, porque se sentirá obligado a analizar qué causó el error y a actuar en consecuencia.
Primero, recomendaría ver si puede hacer un ganar-ganar. Con esto, descubra las lagunas en las que el software no satisface las necesidades de la empresa (por ejemplo, limita el tipo de negocios, o los empleados tienen muchas entradas dobles, o hay una falta de buenos informes a nivel de gestión). ) - y unir un sistema de revisión con él.
Costar dinero puede ser de varias maneras:
1) Falta de datos procesables. Si los informes son lentos (hasta el punto de dejar de ser válidos), inexactos o inexistentes, esa es un área que tendrá más sentido para los gerentes.
2) Si se está produciendo el ingreso manual de material o entradas repetitivas y podría automatizarse, determine cuántos empleados se verán afectados por él, cuán a menudo lo hacen y calcule su costo para la empresa. Luego puede derivar la pérdida como la suma (para cada persona) del tiempo perdido * el costo de la persona.
3) Identifique las áreas de costo de oportunidad, por ejemplo, donde el personal o la administración son limitados. Encuentre escenarios en los que los clientes no estén contentos y no hayan regresado debido a la falta de flexibilidad en el sistema.
Sin saber mucho más sobre la compañía, mi mejor opción es que no hay nada que puedas hacer.
La forma en que lo dices es que ni siquiera son conscientes de que tienen un problema y menos aún de intentar resolverlo. Lo más probable es que te vean como alguien que BUSCA un problema donde no creen que exista.
Diez años de "experiencia" son mucho para luchar. Desde su punto de vista, tienen un producto, funciona, seguro que hay problemas, mantenimiento constante y problemas con los clientes, pero ¿nadie puede discutir los resultados? ¿Pueden ellos? Además, todos tienen estos problemas, ¿verdad?
Tal vez tengas más suerte que yo, pero en menos lo están buscando, no creo que puedas lograr que lo vean.
Utilice uno de sus "paradigmas" favoritos: panorama general
Este es un término que la mayoría de ellos entienden, ya que todos se ven a sí mismos como personas de tipo "Big Picture". Acepte el hecho de que hacer las cosas mal puede , en algunas circunstancias, ganar más dinero a corto plazo, pero a largo plazo (o "gran imagen") cuesta más mantener, vender y redesplegar código incorrecto y valdría las horas-hombre por encima de hacerlo bien .
es decir: "Debe mirar la ''Gran imagen'' y ver que estamos perdiendo dinero haciendo las cosas de la manera incorrecta:
Venderlo en términos de cómo ayuda a cumplir los objetivos comerciales.
No diga "Si hacemos esto, significa que una vez que identificamos un error podemos gestionarlo más rápido". En cambio, póngalo en una perspectiva que las personas que realmente no se preocupan por el aspecto técnico comprenderán y comprenderán. Diga algo como "Si lo hacemos de esta manera, podemos aumentar nuestros ingresos generales y también proporcionar mejores productos".
Si puede hacer eso, significa que las personas que toman las decisiones más importantes generalmente serán más receptivas.
La metáfora de la deuda técnica me pareció muy útil cuando trato de convencer a personas no técnicas para que pongan dinero para apoyar la mejora de la base de códigos. La idea básica es que producir más funciones dejando que la calidad del código sufra es como obtener un préstamo para aprovechar una oportunidad: puede hacerlo, pero si nunca paga el préstamo, los intereses lo invadirán. . Del mismo modo, si nunca resuelve los problemas de calidad, su progreso será menor y menor, hasta el momento en que la aplicación deba descartarse
Un código mejor es más fácil de mantener pero, lo que es más importante, también es más fácil de mantener por alguien que no sea el autor original .
Los estándares de codificación permiten a los desarrolladores ser más "intercambiables": esto es bueno para los desarrolladores ya que los codificadores héroes de un producto rara vez pueden trabajar en otra cosa.
He estado allí; te sientes realmente necesitado e importante para el negocio durante un año más o menos, pero pronto empiezas a preguntarte por qué siempre te pasan por alto para promocionar y nunca trabajas en las cosas nuevas e interesantes.
Como empresa, quiere flexibilidad y seguridad, quiere seguir trabajando si su desarrollador estrella gana la lotería o finalmente decide que está cansado de trabajar en lo mismo durante cinco años. Desea poder escalar rápidamente si entra la gran oportunidad.
Un código bien escrito, bien comentado, que cumpla con los estándares y probado en unidades cuesta más para escribir, pero tiene mucho más valor para el negocio.
¿El gerente de cualquier empresa desea apostar su éxito a un desarrollador o equipo pequeño que se quede a largo plazo? En caso afirmativo (¿están locos?), Entonces argumentan que los desarrolladores cambian de compañía cada 2 a 5 años y que su conjunto de habilidades es 100% transferible.
Su base de código de 10 años probablemente demore varios meses antes de que los nuevos desarrolladores puedan contribuir con nada. Cada vez que pierdes un desarrollador, en realidad estás perdiendo seis meses de su tiempo (sin mencionar el reclutamiento). Si tu equipo está mal integrado, puedes perder mucho más ya que todos los demás se toman semanas para solucionar pequeños problemas en el código de salida porque no tienen idea de cómo funciona.
Hay una gran cantidad de investigaciones sobre cómo construir nuevos proyectos que no tienen estos problemas (yo uso una variante Agile personalizada) pero no tanto para cambiar a mitad de camino.
Por lo general, no puede convencerlos con una simple discusión. Prácticamente lo único que funciona es "mostrarles" escribiendo un código limpio y bien documentado (posiblemente mediante la refactorización de pequeños fragmentos mientras se corrigen errores) y el seguimiento de cuánto tiempo les lleva a los desarrolladores corregir nuevos errores en "limpio" y "desordenado" código.
Esto requiere un buen sistema de seguimiento de fallas, incluso entradas de horas de trabajo, etc., antes de que pueda hacer una tabla de la reducción en los tiempos de "corrección de errores" y / o la reducción en "nuevos errores" en los módulos de códigos limpios.
Es un largo camino para azada con seguridad. :-)