Sí, puedes medir la productividad de los desarrolladores de software (2023)

En comparación con otros negocios críticosEn funciones como ventas u operaciones con clientes, el desarrollo de software siempre está subestimado. La creencia arraigada por muchos en la tecnología es que no es posible hacerlo correctamente y que, en cualquier caso, sólo los ingenieros capacitados tienen el conocimiento suficiente para evaluar el desempeño de sus pares. Sin embargo, ese status quo ya no es sostenible. Ahora que la mayoría de las empresasse están convirtiendo (en un grado u otro) en empresas de software, independientemente de la industria, los líderes deben saber que están desplegando su talento más valioso con el mayor éxito posible.

No se puede negar que medir la productividad de los desarrolladores es difícil. Otras funciones se pueden medir razonablemente bien, algunas incluso con una sola métrica; mientras que en el desarrollo de software, el vínculo entre entradas y salidas es considerablemente menos claro. El desarrollo de software también es un trabajo altamente colaborativo, complejo y creativo y requiere diferentes métricas para diferentes niveles (como sistemas, equipos e individuos). Es más, incluso si existe un compromiso genuino de realizar un seguimiento adecuado de la productividad, las métricas tradicionales pueden requerir sistemas y software configurados para permitir una medición más completa y matizada. Para algunas métricas estándar, es necesario reconfigurar pilas tecnológicas y procesos de desarrollo completos para permitir el seguimiento, y implementar los instrumentos y herramientas necesarios para generar conocimientos significativos puede requerir una inversión significativa a largo plazo. Además, el panorama del desarrollo de software está cambiando rápidamente a medida que las herramientas de IA generativa como Copilot X y ChatGPT tienen el potencial depermitir a los desarrolladores completar tareas hasta dos veces más rápido.

Para ayudar a superar estos desafíos y hacer que esta tarea crítica sea más factible, desarrollamos un enfoque para medir la productividad de los desarrolladores de software que es más fácil de implementar con encuestas o datos existentes (como en herramientas de gestión de trabajos pendientes). Al hacerlo, nos basamos en las métricas de productividad existentes que los líderes de la industria han desarrollado a lo largo de los años, con miras a revelar oportunidades para mejorar el rendimiento.

Este nuevo enfoque se ha implementado en casi 20 empresas tecnológicas, financieras y farmacéuticas, y los resultados iniciales son prometedores. Incluyen las siguientes mejoras:

• Reducción del 20 al 30 por ciento en defectos de producto informados por los clientes
• Mejora del 20 por ciento en las puntuaciones de experiencia de los empleados
• Mejora de 60 puntos porcentuales en los índices de satisfacción del cliente

Aprovechar los conocimientos sobre productividad

Con acceso a conocimientos y datos de productividad más completos, los líderes pueden comenzar a responder preguntas urgentes sobre el talento de ingeniería de software que tanto lucharon por atraer y retener, como las siguientes:

• ¿Cuáles son los impedimentos para que los ingenieros trabajen a su mejor nivel?
• ¿En qué medida la cultura y la organización afectan su capacidad para producir el mejor trabajo?
• ¿Cómo sabemos si estamos utilizando su tiempo en actividades que realmente generan valor?
• ¿Cómo podemos saber si tenemos todo el talento en ingeniería de software que necesitamos?

Entendiendo los fundamentos

Para utilizar un sistema suficientemente matizado para medir la productividad de los desarrolladores, es esencial comprender los tres tipos de métricas que deben rastrearse: las del nivel del sistema, las del equipo y las individuales. A diferencia de una función como las ventas, donde se podría utilizar una métrica a nivel de sistema de los dólares ganados o los acuerdos cerrados para medir el trabajo tanto de los equipos como de los individuos, el desarrollo de software es colaborativo de una manera distintiva que requiere lentes diferentes. Por ejemplo, si bien la frecuencia de implementación es una métrica perfectamente buena para evaluar sistemas o equipos, depende de que todos los miembros del equipo realicen sus respectivas tareas y, por lo tanto, no es una forma útil de realizar un seguimiento del desempeño individual.

Otra dimensión fundamental que hay que reconocer es lo que las distintas métricas dicen y lo que no dicen. Por ejemplo, medir la frecuencia de implementación o el tiempo de espera para los cambios puede brindarle una visión clara de ciertos resultados, pero no de si una organización de ingeniería está optimizada. Y si bien métricas como los puntos de la historia completados o las interrupciones pueden ayudar a determinar la optimización, requieren más investigación para identificar mejoras que podrían ser beneficiosas.

Al construir nuestro conjunto de métricas, buscamos ampliar los dos conjuntos de métricas ya desarrollados por la industria del software. La primera son las métricas DORA, que llevan el nombre del equipo de investigación y evaluación de DevOps de Google. Estos son lo más cerca que tiene el sector tecnológico de un estándar y son excelentes para medir resultados. Cuando una métrica DORA arroja un resultado deficiente, es una señal para investigar qué salió mal, lo que a menudo puede implicar una investigación prolongada. Por ejemplo, si una métrica como la frecuencia de implementación aumenta o disminuye, puede haber múltiples causas. Determinar cuáles son y cómo resolverlos a menudo no es sencillo.

El segundo conjunto de medidas desarrolladas por la industria son las métricas SPACE (satisfacción y bienestar, rendimiento, actividad, comunicación y colaboración, y eficiencia y flujo), que GitHub y Microsoft Research desarrollaron para aumentar las métricas de DORA. Al adoptar una perspectiva individual, particularmente en torno al bienestar de los desarrolladores, las métricas de SPACE son excelentes para aclarar si una organización de ingeniería está optimizada. Por ejemplo, un aumento en las interrupciones que experimentan los desarrolladores indica una necesidad de optimización.

Además de estas métricas ya poderosas, nuestro enfoque busca identificar qué se puede hacer para mejorar la forma en que se entregan los productos y cuánto valen esas mejoras, sin la necesidad de una instrumentación pesada. Complementar las métricas de DORA y SPACE con métricas centradas en las oportunidades puede crear una visión de extremo a extremo de la productividad de los desarrolladores de software (Anexo 1).

1

Estas métricas de productividad centradas en las oportunidades utilizan algunas lentes diferentes para generar una visión matizada de la compleja gama de actividades involucradas en el desarrollo de productos de software.

Tiempo empleado en el bucle interior/exterior.Para identificar áreas específicas de mejora, es útil pensar que las actividades involucradas en el desarrollo de software están organizadas en dos ciclos (Anexo 2). Un bucle interno comprende actividades directamente relacionadas con la creación del producto: codificación, construcción y pruebas unitarias. Un bucle externo comprende otras tareas que los desarrolladores deben realizar para llevar su código a producción: integración, pruebas de integración, lanzamiento e implementación. Tanto desde el punto de vista de la productividad como de la experiencia personal, es deseable maximizar la cantidad de tiempo que los desarrolladores pasan en el circuito interno: la creación de productos genera valor directamente.yes lo que a la mayoría de los desarrolladores les entusiasma hacer. La mayoría de los desarrolladores consideran que las actividades del bucle externo son tareas necesarias pero generalmente insatisfactorias. Dedicar tiempo a mejores herramientas y automatización para el bucle externo permite a los desarrolladores dedicar más tiempo a las actividades del bucle interno.

2

Las principales empresas de tecnología pretenden que los desarrolladores dediquen hasta el 70 por ciento de su tiempo a actividades de bucle interno. Por ejemplo, una empresa que anteriormente había completado una transformación ágil exitosa se enteró de que sus desarrolladores, en lugar de codificar, dedicaban demasiado tiempo a tareas de bajo valor agregado, como aprovisionar infraestructura, ejecutar pruebas unitarias manuales y administrar datos de prueba. Armado con esa información, lanzó una serie de nuevas herramientas y proyectos de automatización para ayudar con esas tareas a lo largo del ciclo de vida del desarrollo de software.

El creciente alcance del software empresarial

Explora la colección

Punto de referencia del índice de velocidad del desarrollador.El Developer Velocity Index (DVI) es una encuesta que mide la tecnología, las prácticas laborales y la habilitación organizacional de una empresa y los compara con sus pares. Esta comparación ayuda a descubrir áreas de oportunidad específicas, ya sea en la gestión de trabajos pendientes, pruebas o seguridad y cumplimiento.1 Para leer más sobre la encuesta DVI de McKinsey, consulte Shivam Srivastava, Kartik Trehan, Dilip Wagle y Jane Wang, “Developer speed: How software excelence fuels business performance”, McKinsey, 20 de abril de 2020; y Chandra Gnanasambandam, Neha Jindal, Shivam Srivastava y Dilip Wagle, “La velocidad de los desarrolladores en el trabajo: lecciones clave de los líderes de la industria”, McKinsey, 22 de febrero de 2021.Por ejemplo, una empresa, muy conocida por su destreza tecnológica y sus desarrolladores estrella, buscó definir prácticas laborales estándar más cuidadosamente para la colaboración entre equipos después de descubrir una gran cantidad de insatisfacción, retrabajo e ineficiencia reportadas por los desarrolladores.

Análisis de contribución.Evaluar las contribuciones de los individuos al trabajo pendiente de un equipo (comenzando con datos de herramientas de gestión de trabajos pendientes como Jira y normalizando los datos utilizando un algoritmo patentado para tener en cuenta los matices) puede ayudar a sacar a la luz tendencias que inhiben la optimización de la capacidad de ese equipo. Este tipo de conocimiento puede permitir a los líderes de equipo gestionar expectativas claras de resultados y, como resultado, mejorar el rendimiento. Además, puede ayudar a identificar oportunidades para mejorar las habilidades o la capacitación individual y repensar la distribución de roles dentro de un equipo (por ejemplo, si un evaluador de control de calidad tiene suficiente trabajo que hacer). Por ejemplo, una empresa descubrió que sus desarrolladores más talentosos dedicaban demasiado tiempo a actividades no relacionadas con la codificación, como sesiones de diseño o gestión de interdependencias entre equipos. En respuesta, la empresa cambió su modelo operativo y aclaró funciones y responsabilidades para permitir que los desarrolladores de mayor valor hagan lo que mejor saben hacer: codificar. Otra empresa, después de descubrir una contribución relativamente baja de desarrolladores nuevos en la organización, reexaminó su programa de incorporación y tutoría personal.

Puntuación de capacidad del talento.Basado en mapas de capacidad estándar de la industria, este puntaje es un resumen de los conocimientos, habilidades y habilidades individuales de una organización específica. Idealmente, las organizaciones deberían aspirar a una distribución de competencia “diamante”, con la mayoría de los desarrolladores en el rango medio de competencia.2Klemens Hjartar, Peter Jacobs, Eric Lamarre y Lars Vinter, “Es hora de restablecer el modelo de talento de TI”, MIT Sloan Management Review, 5 de marzo de 2020.Esto puede hacer surgir oportunidades de capacitación y mejora de habilidades y, en casos extremos, exigir un replanteamiento de la estrategia de talento. Por ejemplo, una empresa encontró una mayor concentración de sus desarrolladores en la capacidad "novata" de lo ideal. Implementaron viajes de aprendizaje personalizados basados ​​en brechas específicas y pudieron mover al 30 por ciento de sus desarrolladores al siguiente nivel de experiencia en seis meses.

Evitar errores en las métricas

Por muy valiosos que puedan ser, los datos de productividad de los desarrolladores pueden ser perjudiciales para las organizaciones si se utilizan incorrectamente, por lo que es importante evitar ciertos errores. En nuestro trabajo vemos que se producen dos tipos principales de errores: el mal uso de las métricas y la incapacidad de superar viejas mentalidades.

El mal uso es más común cuando las empresas intentan emplear medidas demasiado simples, como líneas de código producidas o número de confirmaciones de código (cuando los desarrolladores envían su código a un sistema de control de versiones). Estas métricas simples no sólo no logran generar ideas verdaderamente útiles, sino que también pueden tener consecuencias no deseadas, como que los líderes hagan concesiones inapropiadas. Por ejemplo, optimizar el tiempo de entrega o la frecuencia de implementación puede hacer que la calidad se vea afectada. Centrarse en una sola métrica o en un conjunto de métricas demasiado simple también puede incentivar fácilmente malas prácticas; en el caso de medir los compromisos, por ejemplo, los desarrolladores pueden enviar cambios más pequeños con mayor frecuencia mientras buscan jugar con el sistema.

Para beneficiarse verdaderamente de la medición de la productividad, tanto los líderes como los desarrolladores deben superar la noción obsoleta de que los líderes “no pueden” comprender las complejidades de la ingeniería de software, o que la ingeniería es demasiado compleja para medirla. La importancia del talento en ingeniería para el éxito de una empresa y laferoz competencia por el talento desarrollador en los últimos años, subraya la necesidad de reconocer que el desarrollo de software, como tantas otras cosas, requiere mejorar la medición. Además, atraer y retener a los mejores talentos en desarrollo de software depende en gran medida de proporcionar un lugar de trabajo y herramientas que permitan a los ingenieros hacer su mejor trabajo y fomenten su creatividad. Medir la productividad a nivel de sistema permite a los empleadores ver puntos de fricción ocultos que impiden ese trabajo y la creatividad.

Empezando

La mecánica de construir una iniciativa de productividad para desarrolladores puede parecer desalentadora, pero no hay mejor momento que el presente para comenzar a sentar las bases. Los factores que impulsan la necesidad de elevar la conversación sobre la productividad de los desarrolladores de software a los líderes de nivel C superan los impedimentos para hacerlo.

El aumento del trabajo remoto y su popularidad entre los desarrolladores es un factor primordial. Los desarrolladores han trabajado durante mucho tiempo en equipos ágiles, colaborando en el mismo espacio físico, y algunos líderes tecnológicos creen que ese tipo de trabajo en equipo en persona es esencial para el trabajo. Sin embargo, las herramientas digitales que son tan fundamentales para su trabajo facilitaron el cambio al trabajo remoto durante los cierres pandémicos y, como en la mayoría de los sectores, este cambio es difícil de deshacer. A medida que el trabajo remoto e híbrido se convierta cada vez más en la norma, las organizaciones necesitarán confiar en mediciones amplias y objetivas para mantener la confianza en estos nuevos acuerdos de trabajo y garantizar que estén mejorando constantemente la función que podría determinar fácilmente su éxito o fracaso futuro. El hecho de que los mercados ahora estén poniendo mayor énfasis en el crecimiento eficiente y el retorno de la inversión solo hace que sea más importante que nunca saber cómo pueden optimizar el desempeño de su valioso talento de ingeniería.

Otro impulsor clave de esta necesidad de mayor visibilidad son los rápidos avances en las herramientas habilitadas para IA, especialmente los modelos de lenguaje grande como la IA generativa. Estos ya están cambiando rápidamente la forma en que se realiza el trabajo, lo que significa que medir la productividad de los desarrolladores de software es sólo un primer paso para comprender cómo se implementan estos valiosos recursos.

Pero a pesar de lo crítica que se está volviendo la productividad de los desarrolladores, las empresas no deberían sentir que tienen que embarcarse en una revisión masiva y dramática casi de la noche a la mañana. En cambio, pueden comenzar el proceso con una serie de pasos clave:

Aprende lo básico.Todos los líderes de la C-suite que no sean ingenieros o que hayan estado en la gerencia durante mucho tiempo necesitarán una introducción al proceso de desarrollo de software y cómo está evolucionando.

Evalúe sus sistemas.Debido a que la productividad de los desarrolladores generalmente no se ha medido al nivel necesario para identificar oportunidades de mejora, las pilas de tecnología de la mayoría de las empresas requerirán una reconfiguración potencialmente extensa. Por ejemplo, para medir la cobertura de la prueba (el grado en que las áreas de código se han probado adecuadamente), un equipo de desarrollo necesita equipar su base de código con una herramienta que pueda rastrear el código ejecutado durante una ejecución de prueba.

Construye un plan.Como ocurre con la mayoría de las iniciativas de análisis, perderse en montañas de datos es un riesgo. Es importante comenzar con un área que sepa que resultará en un camino claro hacia la mejora, como la identificación de puntos de fricción y cuellos de botella. Sea explícito sobre el alcance de dicho plan, ya que incluso los mejores enfoques, por muy completos que sean, no serán una solución milagrosa.

Recuerde que medir la productividad es contextual.El punto es observar un sistema completo y comprender cómo puede funcionar mejor mejorando el entorno de desarrollo a nivel de sistema, equipo o individuo.

Independientemente del enfoque específico, lo ideal es que medir la productividad genere transparencia e información sobre áreas clave de mejora. Sólo entonces las organizaciones podrán crear iniciativas específicas para impulsar el impacto tanto en la productividad como en la experiencia de los desarrolladores, un impacto que beneficiará tanto a esas personas como a la empresa en su conjunto.