¿Imposible de cuantificar? ¿Se puede monitorear y optimizar con precisión la productividad de los desarrolladores a lo largo del tiempo? ¿Y esto sin provocar efectos perversos? El tema, lejos de ser realmente nuevo (la metodología Function Point se remonta a 1979), está regresando desde que McKinsey se interesó por el tema. en un publicación de blogLa empresa estadounidense cree que el consenso actual, basado en la observación de que no es posible medir el rendimiento de los desarrolladores de extremo a extremo, ya no es sostenible, en un momento en el que el desarrollo interfiere en el negocio principal de muchas organizaciones.
"Otras funciones pueden evaluarse razonablemente bien, algunas incluso con una sola medición, mientras que en el desarrollo de software el vínculo entre los recursos utilizados y los resultados obtenidos es mucho menos claro", lamentan los analistas de McKinsey, que reconocen, sin embargo, que el desarrollo de software es un Trabajo altamente colaborativo, complejo y creativo que requiere múltiples acciones en diferentes niveles (sistemas, equipos e individuos). Sin olvidar que herramientas de IA generativa, como ChatGPT o Copilot X, están revolucionando las prácticas, mejorando la productividad en determinadas tareas (el mismo McKinsey publicó un estudio sobre el tema, mostrando notablemente avances muy significativos en documentación y escritura de código).
Crear una descripción general de la productividad
Evidentemente, si los consultores de McKinsey ponen la pluma sobre el papel es porque tienen una metodología que proponer. Un “nuevo enfoque” ya desplegado en casi una veintena de empresas tecnológicas, financieras y farmacéuticas, aseguran. “Los primeros resultados son prometedores”, indica la firma, que destaca una reducción del 20 al 30% en los defectos reportados por los clientes de estas organizaciones.
La metodología construida por McKinsey pretende ser complementaria de otros dos enfoques, el de Google (Dora) y el de GitHub y Microsoft Research (Space). Para los consultores, el primero proporciona una buena visión general de los resultados obtenidos por los equipos de desarrollo, mientras que el segundo arroja luz sobre la eficacia de una organización. “Además de estas medidas ya poderosas, nuestro enfoque busca identificar qué se puede hacer para mejorar la forma en que se entregan los productos y el valor de esas mejoras, sin la necesidad de una instrumentación pesada, escriben los consultores. Al complementar las métricas de Dora y Space con métricas centradas en las oportunidades, es posible crear una visión holística de la productividad de los desarrolladores de software. »
Desglose de habilidades de diamante
McKinsey propone en particular tres medidas adicionales. En primer lugar, la medición del tiempo del 'bucle interno' en relación con el tiempo del 'bucle externo', es decir, el tiempo dedicado a crear el producto de software en comparación con el tiempo dedicado a poner el código en producción (integración, pruebas de integración, gestión de versiones, lanzamiento a producción). . Los consultores indican que las empresas tecnológicas apuntan a una proporción de 70/30 en este tiempo compartido. A continuación, McKinsey aconseja observar el Índice de velocidad del desarrollador, que compara la base tecnológica, las prácticas laborales y la estructura organizativa de una empresa con puntos de referencia que le permiten compararse con otras organizaciones. "Esta comparación ayuda a resaltar áreas de oportunidad específicas, ya sea en la gestión de trabajos pendientes, pruebas, seguridad o cumplimiento", escribe McKinsey. Finalmente, estos últimos ofrecen dos métricas más ligadas a los individuos: el análisis de contribución -que mide la contribución de cada persona al progreso del backlog- y la puntuación de la capacidad de habilidades. "Lo ideal es que las organizaciones aspiren a una distribución de habilidades 'diamante', con la mayoría de los desarrolladores en el medio del rango", dice la firma.
Este conjunto de indicadores debería ayudar a la dirección general a salir del efecto de caja negra que a menudo rodea a los equipos de desarrollo de software. Incluso si los consultores dicen ser conscientes de posibles abusos, como el mal uso de los indicadores. Pero, para McKinsey, este efecto perverso se encuentra sobre todo en organizaciones que favorecen KPI demasiado simplistas, como el número de líneas de código producidas o el número de confirmaciones. Para la sociedad estadounidense, las medidas de productividad también enfrentan dificultades relacionadas con el cambio de mentalidad. "Para beneficiarse verdaderamente de las métricas de productividad, los gerentes y desarrolladores deben ir más allá de la creencia de que los ejecutivos no pueden comprender las complejidades de la ingeniería de software o que es demasiado compleja para medirla", escriben los consultores. En otras palabras, ya es hora de que se desplieguen medidas financieras en este universo.
“Medir significa cambiar comportamientos”
No en vano, esta irrupción de la consultora en el campo de la ingeniería informática fue más que bien recibida por los expertos del sector. Kent Beck, ingeniero de software y creador de la metodología ágil de programación extrema, lo llama análisis "absurdo e ingenuo" que ignora la dinámica de los equipos de ingeniería de software exitosos. Y mencionar su experiencia en Facebook donde trabajó durante 7 años y que implementó “el tipo de enfoques que recomienda McKinsey”. Por un resultado desastroso, según él. “Porque ahora la gente está jugando con el sistema”, observa. ¡Comenzamos a medir y fomentar - con dinero y estatus - cambios de medidas! Pero estas medidas conducen a cambios de comportamiento. »
Con Gegerly Orosz, ingeniero con 15 años de experiencia en desarrollo y autor de la carta especializada El ingeniero pragmáticoKent Beck escribió dos artículos para señalar los límites del enfoque de McKinsey, así como los objetivos de la empresa de investigación. Para ambos autores, el artículo de este último fue escrito por "una razón: los CEO y CFO están cada vez más frustrados porque los CTO levantan las manos y dicen que la ingeniería de software es demasiado". Es complejo de evaluar, mientras que los equipos de ventas son monitoreados mediante medidas individuales y cuotas a alcanzar, al igual que los equipos de reclutamiento. Los gerentes de ingeniería no pueden evitar la pregunta de cómo medir la productividad de los desarrolladores hoy en día. Si intentan hacer esto, corren el riesgo de que el CEO o el CFO recurran a McKinsey, quien traerá su marco personalizado, lo implementará (incluso si el CTO protesta) y comenzará a informar sobre las métricas diseñadas por McKinsey ". En otras palabras, la empresa se dirige a sus clientes habituales, sin preocuparse demasiado por las consecuencias reales.
McKinsey se centra en el esfuerzo y la entrega del producto
Porque, para Gegerly Orosz y Kent Beck, el modelo propuesto por la famosa firma “seguramente hará más daño que bien” a las organizaciones que lo adopten y a su cultura de ingeniería. Para demostrar los límites del enfoque sugerido, los dos ingenieros distinguen por supuesto el esfuerzo realizado por los equipos de desarrollo (planificación, codificación, etc.), la producción de estos (principalmente las funcionalidades), los resultados obtenidos (el cambio de usuario o comportamiento del cliente tras el despliegue de nuevas funcionalidades) y, finalmente, el valor creado (al que llaman impacto).
Sin embargo, precisamente los indicadores propuestos por McKinsey se centran en el esfuerzo y la producción del producto, denuncian los dos ingenieros. “Los únicos interesados en estos indicadores son aquellos que los recopilan”, bromean Gegerly Orosz y Kent Beck. A los clientes no les importa. A los líderes no les importa. Los inversores tampoco. En segundo lugar, y lo que es más importante, recopilar y medir estos KPI interfiere con las métricas que realmente interesan a las personas en el proceso, como la rentabilidad. ¿Por qué McKinsey está añadiendo indicadores para medir el esfuerzo? ¡Una razón es que es lo más fácil de medir! Pero este enfoque ignora una verdad clave: el mismo acto de medir cambia la forma en que trabajan los desarrolladores, porque luego intentan "jugar" con el sistema. »
Demostración a través del absurdo
Y recomendar a los CIO y líderes empresariales que se centren en indicadores centrados en resultados (qué características cambian en el comportamiento del usuario) y en impacto (el valor creado). Según lo propuesto por las metodologías Dora y Space que McKinsey pretende completar. Aunque este tipo de KPI también puede tener efectos perversos, como ellos mismos señalan, recomendando que los CTO permanezcan atentos a los cambios en el comportamiento de los equipos de desarrollo. Para ambos ingenieros, el impacto gratificante alienta a los ingenieros de software a comprender el negocio de la empresa y ayudarla a alcanzar sus objetivos. “¿Es menos valioso ofrecer una versión que reduce los costos en 2 millones de dólares al año a través de un simple cambio de configuración que entregar una versión que requiere 5 meses de ingeniería para reducirlos en 500.000 dólares? », ilustran Gegerly Orosz y Kent Beck en una forma de demostración a través del absurdo. Y desaire a McKinsey.
Otras noticias que te pueden interesar