Si tuviera que liderar el desarrollo de un producto de software, probablemente se preguntó: ¿cómo ayudar al equipo a moverse más rápido? ¿Y cómo sabes qué tan rápido te mueves?
Parece lógico utilizar métricas para responder a estas preguntas. Después de todo, los hemos estado utilizando durante mucho tiempo y con éxito para los propios productos de software. Hay métricas de rendimiento, carga en servidores de producción, tiempo de actividad. También hay métricas de productos basadas en el comportamiento del usuario, como conversión y retención. El beneficio de las métricas no es solo una comprensión más clara del estado actual, sino, lo que es más importante, proporcionar comentarios. Realiza un cambio para mejorar algo y puede ver por las métricas cuánta mejora (o deterioro) obtiene. La sabiduría popular de programación dice: toda optimización del rendimiento del programa debe comenzar con la medición, y eso tiene mucho sentido.
Dado que podemos aplicar con éxito métricas a los propios productos de software, ¿por qué no aplicarlas a la velocidad de desarrollo de esos productos? En este caso, podríamos probar algunas mejoras en los procesos y ver visualmente si ayudan a avanzar más rápido. Y también se simplificaría el problema de determinar un salario justo para los programadores. ¿Qué métricas podrías usar?
No tenemos buenas métricas para esto.
La velocidad de desarrollo es la cantidad de trabajo completado por unidad de tiempo. Podemos medir el tiempo, aquí todo es sencillo. Pero, ¿cómo medir la cantidad de trabajo realizado? Los intentos de hacer esto comenzaron hace muchas décadas, con el nacimiento de la propia industria de la programación. Sin embargo, cada vez que se utilizaba la métrica como objetivo de mejora, algo saldría mal. Por ejemplo:
- . , , , . , , , ;
- . , , ;
- . . , , . , , ;
- . , . , , , ;
- . , , , — , ;
- … .
Los desarrolladores son ingeniosos y creativos, y se especializan en resolver problemas complejos. Cualquiera que sea la métrica que les dé, encontrarán la forma más fácil de mejorar su rendimiento, pero lo más probable es que no tenga nada que ver con el volumen real y la calidad del trabajo realizado. ¿Utilizarán estos métodos de "trampa"? No necesariamente, depende de su situación particular, incluido el grado de incentivo que cree. Pero ciertamente se darán cuenta de que evaluar su productividad tiene poco que ver con el valor. Esto no solo desmotiva, sino que también distrae del trabajo real.
¿Pero por qué?
¿Por qué las métricas funcionan muy bien para mejorar las propiedades de los productos de software, pero no para medir el trabajo realizado por los programadores? ¿Quizás esto sea una especie de conspiración de programadores? De hecho, si miramos más allá del desarrollo de software, veremos otros ejemplos, en algunos de los cuales las métricas funcionan bien y en otros no.
Los ejemplos en los que las métricas funcionan bien son la fabricación o las ventas en masa. Que haya producción y venta de tazas. Puede medir el volumen de producción: la cantidad de tazas por unidad de tiempo, su calidad (porcentaje de desperdicio), el costo de una taza. En ventas: volumen de ventas, margen. Estas métricas se utilizan con bastante éxito en la gestión. Por ejemplo, al gerente de producción se le puede asignar la tarea de reducir la tasa de desperdicio mientras se mantiene el precio de costo, y al gerente de ventas, aumentar las ventas mientras se mantiene el precio. Las mejoras en estas métricas beneficiarán al negocio, por lo que pueden considerarse indicadores del desempeño de las personas que son responsables de la misma.
Un ejemplo de cuándo las métricas no funcionan es la evaluación del desempeño científico. Los científicos realizan investigaciones que luego se publican como artículos científicos. Esta área también tiene sus propias métricas numéricas: el número de artículos, el número de citas, la importancia estadística de los resultados, etc. ¿Es posible decir que un científico que publicó 10 artículos científicos trajo al mundo el doble de beneficios que un científico que publicó 5 artículos? Es poco probable, porque el valor de su trabajo puede ser muy diferente y, al mismo tiempo, incluso a nivel subjetivo, puede ser difícil entender qué trabajo fue más valioso. El problema de "engañar" las citas y publicaciones es ampliamente conocido en la comunidad científica, por lo que, lamentablemente, no se consideran indicadores confiables de valor. También está el problema de manipular la significación estadística .
Dos criterios principales
Independientemente del contexto, las métricas que funcionan bien tienen dos cosas en común:
- Relación directa (no indirecta) con el valor;
- Precisión, es decir, la métrica se basa en medir el número de algunas unidades de valor y estas unidades son iguales entre sí;
Veamos nuevamente los ejemplos que vimos anteriormente: las
métricas para la producción en masa y las ventas cumplen con ambos criterios. En la producción de tazas, el valor es el producto: las propias tazas. La conexión es directa, la empresa necesita producir tazas. Y dado que la producción es en masa, entonces las unidades de valor (círculos) son iguales entre sí. Si hablamos de ventas, entonces las unidades de valor son el dinero. El propósito de la empresa es obtener ganancias, por lo que la relación con el valor es, nuevamente, directa. Y dado que cada dólar ganado es igual a otro, podemos construir métricas precisas.
En la evaluación de trabajos científicos, estos criterios no se pueden cumplir. No podemos encontrar una unidad de medida que determine directamente el valor del trabajo científico, porque todos los trabajos científicos son únicos. No puede ser de otra manera, partiendo simplemente de la esencia misma de la ciencia, para descubrir nuevos conocimientos. No tiene sentido que un científico escriba otro trabajo científico que repita exactamente otro. Cada trabajo científico debe aportar algo nuevo.
Dado que no podemos encontrar métricas que midan directamente el valor del trabajo científico, nos quedamos solo con las indirectas, por ejemplo, el número de publicaciones y citas. El problema con las métricas indirectas es que se correlacionan mal con el valor y tienden a ser fácilmente "engañadas". Si comienza a usar una métrica de este tipo como meta, entonces usted mismo crea un incentivo para terminarla artificialmente.
Volver a medir la productividad del programador
¿Qué teníamos ahí? Líneas de código, número de confirmaciones, tareas, puntuación de la tarea en horas o storypoints ... Si intentas comparar estas métricas con dos criterios principales, verás que ninguna de ellas las cumple:
- No existe una relación directa con el valor. No proporcionamos a nuestros clientes líneas de código, horas de trabajo o puntos de historia. A los usuarios no les importa cuántas confirmaciones realizamos o cuántas tareas cerramos;
- No son precisos. Los compromisos de compromiso son diferentes, una línea de código no es igual a otra, las tareas también son diferentes y las horas de trabajo y los puntos de historia se estiman subjetivamente, por lo que también serán diferentes.
Por lo tanto, no es sorprendente que ninguna de estas métricas funcione; todas son indirectas e imprecisas.
¿Por qué no existen métricas que estén directamente relacionadas con el valor del trabajo de un programador? Por las mismas razones por las que los científicos no los tienen. Los programadores, como los científicos, crean constantemente cosas nuevas. No escriben exactamente el mismo código una y otra vez, eso no tiene sentido. El código escrito previamente se puede reutilizar de diferentes maneras, separar en un módulo o biblioteca separada, bueno, o simplemente copiar, en el peor de los casos. Por tanto, cada jornada laboral para los programadores es única. Incluso si resuelven problemas similares, los resuelven cada vez en un contexto diferente, en nuevas condiciones.
El trabajo de los programadores es una producción por pieza, no una producción en masa. No producen los mismos resultados repetibles, por lo que no existe una línea de base para la medición. Las métricas que funcionan tan bien en la producción o las ventas en masa no funcionan aquí.
¿No hay algo más moderno, basado en la investigación?
Por supuesto, hoy nadie habla seriamente de medir el trabajo de un programador por líneas de código. Debe haber algunas métricas más modernas basadas en la investigación, ¿verdad?
Hay algunos. En su libro de 2018 "Accelerate", los autores citan los resultados de un estudio de 2,000 organizaciones de diferentes industrias. Los autores intentaron averiguar qué métricas medirían el rendimiento:
Fuente: Nicole Forsgren, Jez Humble y Gene Kim, "Midiendo el rendimiento", en Accelerate: La ciencia detrás de DevOps: Creación y escalado de organizaciones tecnológicas de alto rendimiento
Aquí hay cuatro métricas. Veamos cuáles están relacionados con el valor y se pueden medir con precisión:
- . , . , . . . . , , . , . , — ;
- Lead time — , . , , . , , , — ;
- (MTTR) — , , , . . -, . , MTTR . -, , . , — ;
- , . , . , , , . Linux, “ — ”. SaaS- . , — - , , - . , . , — . , — .
En pocas palabras: ninguna de estas cuatro métricas es precisa y no siempre tienen una relación clara con el valor del cliente. ¿Existe la posibilidad de "hacer trampa" en este caso? Por supuesto. Realice cambios triviales de bajo riesgo con la mayor frecuencia posible, y todas las métricas, excepto el tiempo de entrega, se verán geniales.
En cuanto al tiempo de entrega, incluso si omitimos el hecho (importante) de que es inexacto, el énfasis en él conducirá a la priorización de los deseos más simples del cliente y a empujar hacia el rincón más alejado de todo lo que el cliente claramente no pidió, generalmente se trata de refactorizaciones, pruebas y cualquier mejora que no hubiera pensado en sí mismo.
Por lo tanto, no recomendaría usar estas métricas como objetivos.
¿Pero quizás encontremos nuevas métricas?
Por supuesto, puede decir: “Espere, si aún no se han encontrado métricas adecuadas, ¡esto no significa que no pueda haber ninguna! Somos gente inteligente, nos esforzaremos y se nos ocurrirá algo ”. Por desgracia, me temo que no lo hará. Hay una razón fundamental por la que no existen buenas métricas en esta área. Como dijimos anteriormente, los buenos cumplirían dos criterios principales:
- Relación directa (no indirecta) con el valor;
- La precisión, es decir, la métrica se basa en medir el número de algunas unidades de valor, y estas unidades son iguales.
No podemos medir con precisión el valor directo, porque todos los resultados del trabajo de los programadores son diferentes, nunca producen nada exactamente igual. Se trata de una producción de piezas para tareas únicas y no repetitivas. Y como no hay nada repetitivo, tampoco hay base para la comparación y la medición. Solo nos quedan los apoderados, pero dado que están mal relacionados con el valor y son propensos a hacer trampa, confiar en ellos es perjudicial.
¿Puede mejorar áreas para las que no existen buenas métricas?
Las métricas son excelentes porque brindan retroalimentación. Realiza algunos cambios en el proceso y puede ver claramente si condujeron a mejoras o no. Si no hay métricas, la retroalimentación se vuelve menos obvia e incluso puede parecer que se está moviendo a ciegas. Hay un dicho famoso atribuido a Peter Drucker:
No puedes controlar lo que no puedes medir.
Solo que esto no es cierto. Según el Instituto Drucker, Peter Drucker no estaba realmente bajo la ilusión de que se pudiera encontrar una métrica para cualquier actividad, y nunca dijo esas palabras . No todo lo que es valioso se puede medir y no todo lo que se puede medir es valioso.
La complejidad de las métricas no significa que no se pueda mejorar nada. Algunas empresas lanzan software mucho más rápido que otras y sin sacrificar la calidad. Esto significa que existen algunas diferencias significativas y, por lo tanto, deberían ser posibles mejoras.
Resumen
Es posible y necesario mejorar su producto de software utilizando métricas. El rendimiento, la carga, el tiempo de actividad o las métricas del producto, como la conversión y la retención de clientes, son sus amigos.
Sin embargo, no debe intentar acelerar el proceso de desarrollo con la ayuda de métricas, debido a la falta de métricas adecuadas. Se han inventado muchos indicadores en esta área, pero, desafortunadamente, todos son indirectos o imprecisos, y más a menudo ambos a la vez, por lo que al intentar usarlos como metas, solo se obtiene daño.
Pero no se desanime, ¡hay esperanza! La falta de buenas métricas para la velocidad de desarrollo es triste, pero eso no significa que las mejoras de velocidad sean imposibles. Cómo es posible. Sí, solo tenemos evaluaciones cualitativas subjetivas para retroalimentación. Sin embargo, hay suficientes para implementar mejoras y comprender si tienen algún efecto. Por ejemplo, una de las cosas que se puede mejorar es la comunicación entre los desarrolladores y la administración . El enlace anterior proporciona ejemplos de cómo mejorar la comunicación y por qué vale la pena centrarse en él.
Eso es todo, escribe en los comentarios lo que piensas. Despliegues felices, incluso los viernes.