Midiendo si el Desarrollo de software es eficiente 🚀

El estudio de Nicole Forsgren y su equipo

¿Es factible medir la calidad y productividad de un equipo de desarrollo? Esta pregunta es de las más difíciles de responder ya que existen muchas variables y consideraciones que la mayoría de las veces son subjetivas. Algunos dicen que se puede, otros dicen que no.

Muchas empresas suelen medir parámetros asociados a la productividad y eficiencia de los equipos. He visto por ejemplo, número de líneas de código o pull requests por profesional, puntos de historia semanales (velocidad), número de errores reportados, encuestas de satisfacción de clientes, etc. Pero ninguna de dichas métricas se enfoca en los resultados de la empresa, y, por lo tanto, no dicen nada respecto del impacto sobre el negocio. Existe un foco individual o local, cuando realmente debería sería global.

Por el contrario, sí se puede medir la calidad y productividad de un equipo de desarrollo cuando existe un foco en los resultados —entre otras cosas—. Lo que definitivamente es más complejo de medir es el desempeño individual de un ingeniero de desarrollo.

Para abordar lo que llamaríamos un desarrollo de excelencia, tomaré como base el estudio que realizó Nicole Forsgren y su equipo en su libro Accelerate, que encontró 24 capacidades claves que mejoran el rendimiento del desarrollo de software.

Nicole realizó una investigación durante 4 años (2017-2021) para determinar las capacidades y prácticas importantes que aceleraban el desarrollo de software y entregaban valor a sus empresas. La evidencia se basó en la rentabilidad, productividad y valor de mercado de las empresas. Es decir, se correlacionaron esta 24 capacidades con los resultados de la empresa.

A través de rigurosos modelos estadísticos, se estudiaron más de 2000 empresas a través de más de 23.000 respuestas de usuarios. El estudio abarcó desde pequeñas startups, hasta empresas multinacionales con +10.000 empleados. Además se incluyeron empresas de todas las industrias, tanto del borde de la innovación tecnológica, como de sectores financieros regulados o de gobierno.

Midiendo el rendimiento del desarrollo de software

Algo ya hemos hablado de lo complejo que resulta medir el desempeño de un equipo de desarrollo de software. Generalmente las empresas se enfocan en medir la eficiencia y productividad de los equipos, y no en el impacto sobre la empresa. Veamos dos ejemplo comunes: número líneas de código y velocidad.

A diferencia de un escritor de novelas, el escribir más líneas de código no significa que exista un avance. Incluso, una persona podría eliminar líneas de código para simplificar una función o método, lo que sería mucho mejor. ¿No es preferible una solución de 10 líneas de código a una de 500 líneas ? Obviamente que sí. Luego, no podemos medir a los ingenieros de software por el número de líneas que realizan. Por el contrario, deberíamos premiar a aquellos que resuelven un problema con el mínimo código posible.

Por otra parte, el método de gestión ágil —muy de moda actualmente—, promueve la medición de la velocidad de desarrollo a través de los puntos de historia. A cada tarea o requerimiento se le asigna un número de puntos de acuerdo a la dificultad o esfuerzo que representa. Así, podemos medir la capacidad de nuestro equipo, y enfocarnos en como aumentar nuestra velocidad de desarrollo. Como las mismas personas que desarrollan son las que estiman el esfuerzo, éstas tienden a sobre valorar o inflar los history points.

Además, al ser una medición por equipo (local), desincentiva la colaboración con otros equipos de desarrollo.

El mismo estudio de Nicole Forsgren definió 4 variables que determinan el rendimiento del desarrollo de software: (No es parte de este libro validar la metodología o el análisis que utilizó Nicole y su equipo que determinaron como estas 4 variables miden el performance del desarrollo de software de una empresa. Para ello, sugiero remitirse al libro)

- “Lead Time for changes” —Tiempo para habilitar cambios en producción.
- “Deployment Frequency” —Frecuencia de pasos a producción
- “Mean Time to Restore” (MTTR) —Tiempo de reposición del servicio.
- “Change Fail Percentage” — Tasa de error en pasos a producción.

La primera métrica —Lead Time for changes—, es bastante común en la metodología “Lean”, y corresponde al tiempo desde que el cliente realiza un requerimiento, hasta que éste es satisfecho. Sin embargo, para el desarrollo de software, no se considerará toda la etapa de diseño, construcción y validación del requerimiento, sino sólo la etapa posterior, es decir, la de implementación, pruebas —o testing—, compilación y la subida al ambiente de producción. (Básicamente desde que se "empuja" el nuevo commit hasta que éste llega a producción)

La siguiente variable, “Deployment Frequency”, corresponde a la frecuencia con que nuevas características de software pasan al ambiente productivo. Una mayor frecuencia es mejor, dado que implica tener una retroalimentación más rápida de los clientes sobre la nueva funcionalidad recién implementada, y a la vez nos permitirá corregir el curso del desarrollo en caso de tener algún desvío.

Luego está el “Mean Time to Restore”, que es el tiempo promedio que toma a los equipos restaurar un servicio caído o con falla. Hoy en día, todas las aplicaciones de software moderno —desde Google para abajo— fallan en algún momento. Es inevitable. Luego, esta métrica permite medir el tiempo de respuesta de los equipos frente a un incidente.

Por último está el “Change Fail Percentage”, que es el porcentaje de falla de los pasos a producción. No sólo aplica a errores en los cambios del software, sino también es común presenciar fallas cuando se realizan cambios a la configuración de la infraestructura.
Bajo estás 4 variables, el equipo que realizó el estudio encontró los siguientes resultados (2017) para los distintos tipos de empresas:

Así, podemos agrupar claramente a las empresas sobre el rendimiento del desarrollo de software y su impacto en el valor de la empresa. Si no está claro, en el grupo de empresas de alto rendimiento están Amazon, Apple, Google, Meta, Netflix, Spotify, etc, pero lo más importante, también están pequeñas startups, empresas de gobierno, empresas antiguas. Es es decir, un desarrollo de alto impacto no depende tanto de los recursos de la empresa o del conocimiento de los equipos, sino más bien de si las condiciones y capacidades se pueden desenvolver adecuadamente.

El impacto del desarrollo de software en los resultados de la empresa

Bueno, todo el análisis de métricas que estamos viendo tiene un sólo sentido: ¿Cuánto afecta al desempeño de la empresa? El mismo estudio les preguntó a los encuestados que evaluaran el desempeño de la empresa en 3 dimensiones: rentabilidad, participación de mercado y productividad. Esta escala se ha utilizado en múltiples estudios para medir el rendimiento de las empresas, y está altamente correlacionado con las métricas de Retorno de la Inversión o ROI —Return Over Investment—.

En paralelo, también se abordó como impactaba un mejor rendimiento del desarrollo de software para alcanzar los objetivos de la empresa; objetivos que muchas veces no tienen relación con la rentabilidad o las ventas —para el caso de las empresas sin fines de lucro—.
Hoy en día cualquier tipo de empresa —privada, pública, sin fines de lucro—, depende de la tecnología para cumplir su misión y dar valor a los clientes de forma rápida, confiable y segura. Entonces, independiente de los objetivos de la empresa, el cómo funciona su proceso de desarrollo tecnológico será un buen predictor del desempeño de la empresa.

Luego, el hecho de que el rendimiento en el desarrollo de software incide directamente en el rendimiento de la empresa, es un fuerte argumento para no externalizar el desarrollo de software que sea estratégico para la empresa, sino que por el contrario, se deberán incorporar las capacidades en el corazón de la organización.

Similarmente, todas las herramientas y aplicaciones no estratégicas podrán ser adquiridas bajo la modalidad SaaS, como las herramientas de ofimática, sistemas de pago de remuneraciones, mesa de ayuda, etc.

En definitiva, es clave distinguir qué sistemas son estratégicos para la empresa, ya que ellos deberán ser gestionados con equipo “in-house”, y no con terceros.