Hacer que la productividad de la ingeniería se centre en las personas

Medir la productividad del equipo de entrega puede ser un tema divisivo. Especialmente para las personas que están siendo «medidas».

Un ejemplo de ello es el reciente artículo de McKinsey, que ha tocado un poco la fibra sensible de la comunidad de desarrolladores.

Si bien los líderes tecnológicos necesitan comprender la productividad del equipo, también es importante reconocer que su gente, sus objetivos y sus proyectos son únicos. Si somos demasiado científicos y nos guiamos demasiado por los procesos al evaluar la productividad, corremos el riesgo de medir lo incorrecto y alcanzar el resultado equivocado.

Como dijo una vez Albert Einstein: “No todo lo que cuenta se puede contar y no todo lo que se puede contar cuenta”.

Es más que líneas de código…

La ingeniería de software tiene una larga (y no muy gloriosa) historia de intentos de medir la productividad. Dígale a un equipo que se está evaluando la frecuencia de implementación y ellos estarán felices de producir código para usted día y noche. ¿Pero esto nos acerca más al valor comercial real que el proyecto busca generar? Probablemente no.

Las líneas de código de ejemplo y las métricas más científicas actuales no siempre reflejan la complejidad de un proyecto. Quizás el equipo esté trabajando en algo completamente nuevo, superando límites y encontrando soluciones a problemas complejos. En este caso, no se desplegarán en producción cinco veces al día. Estarán experimentando, fallando y comenzando de nuevo.

¿Qué detiene el progreso?

Si tienes un equipo inteligente y motivado, siempre he creído que la medición debería consistir en identificar qué previene productividad de la ingeniería.

Como hemos hablado antes, un buen punto de partida es el nivel alto: ¿comprenden todos su misión? A partir de aquí, profundizará en lo que podría impedir que su gente sea productiva. ¿Tiene el equipo un trabajo pendiente saludable que haya sido planificado y discutido con todas las partes interesadas? ¿Tienen los individuos autonomía para elegir con qué sistemas, herramientas y tecnologías trabajan? ¿Están siendo frenados por otros departamentos, por la falta de acceso a infraestructura o por presupuestos limitados?

En última instancia, los equipos rara vez son «improductivos» sin una razón. El objetivo de este tipo de análisis es descubrir las limitaciones que enfrenta y abordarlas. Luego, los equipos de todos estarán capacitados para hacer su mejor trabajo.

Encontrar el flujo

Creo firmemente en darles a los equipos las herramientas para el éxito y luego dejarles seguir adelante a su manera. Pero también vale la pena registrarse de vez en cuando. Por eso, un burndown puede ser un gran indicador del progreso de un sprint o de un proyecto.

Los gráficos de evolución (y hay muchos diferentes) nos dicen mucho sobre el flujo de trabajo y cómo están trabajando realmente nuestros equipos.

Una pendiente pronunciada por encima del punto de referencia, por ejemplo, podría indicar que el equipo ha abarcado más de lo que puede abarcar; tal vez no está desglosando su trabajo de manera efectiva y necesita revisar el plan del proyecto. Por otra parte, aunque adelantarse a lo previsto puede mirar bueno, puede que ser bien. Si las cosas progresan más rápido de lo esperado, es posible que el trabajo no se esté entregando según las especificaciones y que los equipos estén cerrando tickets habiendo entregado solo una pequeña parte de lo solicitado. De cualquier manera, cualquier desviación es motivo de una mirada más cercana.

Los gráficos de evolución son excelentes para visualizar el progreso y enormemente útiles para gestionar tanto las cargas de trabajo como las expectativas. También son excelentes para mantener a los equipos enfocados en el objetivo final. Sin embargo, más que nada de esto, señalan si los equipos necesitan apoyo, sin complicar demasiado las cosas.

Mantenlo simple

No soy reacio a la medición. Ciertamente tiene un propósito. Sin embargo, los intentos de medir la productividad de forma 100% objetiva o científica pueden ser un poco impredecibles.

La ingeniería de software no es una línea de producción y los ingenieros de software no deberían sentir que están trabajando en una. Y así como contar líneas de código no funcionaba en los viejos tiempos (y ciertamente no inspiraba pensamiento innovador ni resolución de problemas), no estoy seguro de que la respuesta sea ser más granular con las métricas actuales. Podría obstaculizar que los equipos logren la única medida que realmente cuenta: valor para el negocio.

Según nuestra experiencia, es importante mantener las cosas simples, identificar y eliminar los obstáculos desde el comienzo del proyecto. Entonces confíe en su gente para cumplir. ¡Funciona para nosotros!

Si desea conversar más sobre cualquier tema cubierto en este blog, solo avísenos.