En agosto del 2023, McKinsey publicó Yes, You can measure software developer productivity que a muchos en la comunidad de desarrollo de software les hizo ruido. Tras leer varias criticas y comentarios interesantes, me motivaron a profundizar en el tema para formarme una opinión al respecto.

Según McKinsey, han desarrollado una metodología para medir la productividad de los desarrolladores de software, desafiando la creencia de que solo ingenieros experimentados son capaces de evaluar el rendimiento de sus pares.

Para aquellos de nosotros que trabajamos en el desarrollo, es relevante estar al tanto de estas tendencias y sus limitaciones, porque:

  • La mejora continua nos hace mas competitivos.
  • Estamos descubriendo el verdadero impacto de nuevas herramientas, como la IA.
  • La situación macroeconómica nos insta a ser más eficientes.

Antecedentes

El artículo de McKinsey se basa en dos productos de investigaciones académicas: DORA y SPACE.

DevOps Research and Assessment (DORA) es un programa de investigación de Google que busca comprender las capacidades que impulsan el rendimiento en la entrega y operaciones de software. DORA ayuda a los equipos a aplicar mejor esas capacidades, lo que conduce a un mejor rendimiento organizacional. El rendimiento puede evaluarse según cuatro métricas:

  1. Tiempo de ejecución para cambios (Lead time for changes): Intervalo de tiempo desde que se cambia código hasta que se ejecuta correctamente en producción.
  2. Frecuencia de despliegue (Deployment frequency): Indica con que regularidad se despliega código en producción o se libera para los usuarios finales.
  3. Tasa de fallos en cambios (Change failure rate): Representa el porcentaje de cambios en producción o liberados a los usuarios finales que resultan en un servicio degradado y posteriormente requieren una solución.
  4. Tiempo para restaurar el servicio (Time to restore service): Es la duración habitual para restaurar el servicio cuando ocurre un incidente o defecto que afecta a los usuarios.

Mientras que DORA tiene como objetivo mejorar y optimizar los procesos de DevOps, SPACE (2021) es un marco de trabajo que proporciona una visión integral de la productividad y bienestar en el lugar de trabajo para ayudar a las organizaciones a mejorar la satisfacción y rendimiento de sus equipos.

Las dimensiones que propone SPACE medir, y que por sus iníciales en inglés le dan su nombre, son:

  • Satisfacción y bienestar (Satisfaction and wellbeing): Cómo se sienten los desarrolladores con su trabajo, equipo, herramientas o cultura. El bienestar se refiere a cuán saludables y felices están, y cómo su trabajo impacta en ello.
  • Rendimiento (Performance): Eficacia y resultado del trabajo de desarrollo. Aquí se incluyen métricas DORA como la tasa de fallos en cambios, el tiempo para restaurar el servicio y la frecuencia de despliegue para nuevas funcionalidades.
  • Actividad (Activity): Volumen y tipo de actividad que llevan a cabo los desarrolladores. La métrica de frecuencia de despliegue de DORA puede también entrar en esta categoría.
  • Comunicación y colaboración (Communication and collaboration): Cómo se comunican y trabajan juntos las personas y los equipos. Incluye métricas relacionadas con herramientas de colaboración, frecuencia y calidad de la comunicación y eficacia de las reuniones de equipo.
  • Eficiencia y flujo (Efficiency and flow): Es la capacidad de completar el trabajo o progresar en él, ya sea individualmente o a través de un sistema. Mide aspectos como el tiempo dedicado a las distintas tareas, la facilidad para entrar en un estado de fluidez y en qué medida el entorno de trabajo favorece el trabajo eficiente y sin interrupciones.

SPACE se caracteriza por su énfasis en la retroalimentación directa de las personas. Propone utilizar encuestas y entrevistas para obtener una comprensión más profunda de cómo se sienten los colaboradores respecto a su trabajo y el entorno laboral, fomentando una cultura de participación y mejora continua.

El planteamiento de McKinsey

McKinsey propone complementar los modelos DORA y SPACE con cuatro métricas para crear una visión completa de la productividad de los desarrolladores de software:

  1. Tiempo dedicado al ciclo interno/externo (Inner/outer loop time spent): El ciclo interno comprende actividades directamente relacionadas con la creación del producto, como el desarrollo y pruebas unitarias. El ciclo externo abarca otras tareas que los desarrolladores deben abordar, como las pruebas de integración, reuniones de trabajo y despliegues a escala. Es deseable maximizar el tiempo que ocupan los desarrolladores en el ciclo interno y minimizar el tiempo en el ciclo externo.
  2. Comparativa del índice de velocidad del desarrollador (Developer Velocity Index benchmark): Se sustenta en Developer Velocity: How software excellence fuels business performance (2020) que propone un índice para medir la tecnología, prácticas de trabajo y capacitación en una organización. La comparativa con organizaciones homólogas tiene como propósito revelar áreas de oportunidad especificas.
  3. Análisis de contribución (Contribution analysis): Evaluar la contribución de cada persona al backlog puede revelar tendencias que impiden aprovechar al máximo la capacidad del equipo. Con esta información los lideres pueden establecer expectativas claras para la producción y mejorar el rendimiento como resultado. Además, ayuda a identificar oportunidades para el desarrollo de habilidades o replantear la distribución de roles en el equipo.
  4. Puntuación de capacidades del talento (Talent capability score): Es un resumen del conocimiento, habilidades y capacidades individuales de un equipo basado en estándares de la industria. Puede revelar oportunidades para el desarrollo de habilidades o, en casos extremos, una revisión de la estrategia de talento.

McKinsey organiza estos indicadores junto a los de DORA y SPACE en una matriz, clasificándolos por nivel (individual, equipo u organizacional) y enfoque (resultados, optimizaciones y oportunidades).

Mi perspectiva

Es positivo que McKinsey y las industrias tradicionales a las que va dirigido el artículo se involucren en comprender el proceso de desarrollo de software.

Considero que McKinsey comenzó correctamente al basarse en investigaciones revisadas por pares como DORA y SPACE. Sin embargo, proponer cuatro métricas nuevas y concluir que se puede medir la productividad de los desarrolladores de software es exagerado.

En mi opinión, sería más coherente seguir la dirección propuesta en DevEx: What Actually Drives Productivity (2023) y centrarse en los desarrolladores y sus experiencias.

DevEx resume la experiencia de desarrollo en tres dimensiones que encapsulan las posibles fricciones de los desarrolladores:

  1. Circuitos de retroalimentación (Feedback loops): Las tareas de desarrollo dependen de la retroalimentación tanto de herramientas como de personas. Una pronta retroalimentación permite a los desarrolladores completar su trabajo rápidamente con una fricción mínima.
  2. Carga cognitiva (Cognitive load): Se refiere a la cantidad de procesamiento mental requerido para que un desarrollador realice una tarea. Una alta carga cognitiva impide a los desarrolladores enfocarse en su responsabilidad mas importante que es aportar valor a los clientes. Las organizaciones deben apuntar a reducir la carga cognitiva reduciendo obstáculos innecesarios en el proceso de desarrollo.
  3. Estado de fluidez (Flow state): Es el estado mental en el que una persona que realiza una actividad está totalmente inmersa con una sensación de concentración, inmersión y satisfacción. Las organizaciones deben poner foco en minimizar interrupciones y evitar el trabajo no planificado junto con una cultura de equipo positiva que brinde a los desarrolladores autonomía y oportunidades para trabajar en retos satisfactorios.

Medir la experiencia del desarrollador requiere capturar las percepciones de los desarrolladores además de datos objetivos sobre los sistemas y procesos de ingeniería. Los desarrolladores proporcionan señales directas mientras que los datos objetivos ofrecen información sobre areas de fricción y recomendaciones para mejorar.

Me parece más sensato enfocarse en las experiencias de los desarrolladores para comprender los verdaderos desafíos a los que se enfrentan y contrarrestar las percepciones negativas sobre la medición de la productividad.

Citando a Martin Fowler en Cannot Measure Productivity (2003):

Hay quienes afirman que “si no se puede medir, no se puede gestionar”. Eso es una excusa. Las empresas gestionan aspectos cuyo valor no pueden medir. ¿Cómo medir la productividad de los abogados de una empresa, de su departamento de marketing o de una institución educativa? No se puede, pero es necesario gestionarlos.

Si bien la academia y la industria han avanzado mucho en 20 años, y disponemos de más herramientas para gestionar los equipos de desarrollo de software, pensar que el problema podría completamente resuelto y que ahora podemos medir la productividad de los desarrolladores es prematuro.

Por último, en cuanto a las críticas a la propuesta de McKinsey, las perspectivas de Kent Beck y Gergely Orosz en Measuring developer productivity? A response to McKinsey (2023) me resultaron más completas y convincentes (aunque con algunas reservas).