~ 7 min de lectura
📐 Métricas IV: DevEx framework
Una nueva forma de medir la productividad de los equipos de desarrollo.
Llegamos al último post sobre métricas (por ahora). Hablaremos de DevEx, un paper bastante reciente que trataré de exponer y resumir de la forma más amena y clara. Además, es uno de los acercamientos a la materia que más interesantes y acertados me parecen.
En este me centro en un nuevo enfoque planteado tanto por los investigadores detrás de DORA y SPACE:
- Margaret-Anne Storey co-autora de SPACE
- Nicole Forsgren fundadora de DORA(DevOps Research and Assessment) y co-autora de Accelerate.
Junto a Abi Noda y Michaela Greiler fundadores de DX, una plataforma para medir y mejorar la experiencia de los desarrolladores.
DevEx no es técnicamente nada nuevo, en realidad, no es más que algo que siempre ha estado ahí, pero no se le ha dado la importancia que merecía. DevEx trata de definir formalmente un framework basado en conceptos que compañías como Google y otras llevan aplicando desde hace años.
👨🎓 ¿Que es DevEx?
DevEx recoge como se sienten los desarrolladores, cómo piensan y cómo valoran su trabajo. En un paper previo(An Actionable Framework for Understanding and Improving Developer Experience), establecieron 25 factores que afectan (positiva o negativamente) a la experiencia del desarrollador, algunos ejemplos: interrupciones, plazos poco realistas, fricción con las herramientas, claridad en las tareas, organización del código, entre otros.
Solemos pensar que lo que afecta la experiencia de desarrollo se encuentra en las herramientas, pero va mucho más allá. Factores humanos, como tener objetivos claros, sentirse psicológicamente seguro en un equipo, impactan mucho en el rendimiento.
Mejorar la experiencia de los desarrolladores no solo afecta a la productividad, además tiene beneficios claros en la satisfacción, compromiso y retención.
En el lado de los aspectos que afetcan negativamente, pueden tener niveles de afectación distintos, desde el nivel de la compañía, pasando por el equipo y al individuo.
DevEx es distinto en cada desarrollador, es necesario conocer el contexto como antigüedad, equipo y funciones, experiencias vitales pasadas, etc.
El enfoque de DevEx va al nivel de personas concretas y de compañía (procesos).
🥉 Tres dimensiones
La imagen de cabecera ilustra las tres dimensiones de DevEx:
- Feedback Loops
- Cognitive Load
- Flow State
Al detalle.
🟣 Feedback Loops
Está demostrado que las organizaciones que optimizan su flujo de valor, analizando el value stream mapping y reduciendo las mermas en la entrega de valor son más eficientes. Equivócate antes para corregir tu rumbo antes. Este bucle rápido, permite a los desarrolladores completar más rápido su trabajo con una fricción mínima. Los bucles lentos provocan frustración, pausas, cambios de tareas continuos. Soltar tareas y tener que volver a ellas pasado un tiempo.
Para mejorar DevEx deben acortarse estos bucles de dos maneras:
- Identificar retrasos en herramientas y tiempos de compilación o pruebas
- Identificar mermas en los procesos utilizando un approach Lean.
- Identificar problemas en las estructuras organizativas para favorecer las interacciones en los equipos.
🧠 Cognitive Load
El cada vez mayor número de herramientas y tecnologías aumenta la carga cognitiva a la que nos enfrentamos los desarrolladores. Esta carga abarca la cantidad de proceso mental que necesita un desarrollador para realizar una tarea. Por ejemplo, tareas muy complejas, tareas que implican un aprendizaje de un nuevo framework o paradigma. Tambíen esta carga se ve afectada por como llega la información para realizar una tarea, desde el idioma, la presentación de la información o la necesidad de interpretar la información para conectarla con el conocimiento propio.
La carga cognitiva obstaculiza la función más importante de un desarrollador en la actualidad: ofrecer valor. Cuando esta carga cognitiva es alta como consecuencia de problemas cómo código o sistemas mal documentados, los desarrolladores deben dedicar tiempo y esfuerzo adicionales para completar las tareas y evitar errores.
La clave es reducir esta carga, para ello:
- Código limpio
- Documentación organizada y código bien documentado
Aquí es importante dedicar esfuerzos a facilitar a los desarrolladores toda la documentación necesaria, simplicidad y claridad en las herramientas y procesos que realizan a diario. Un equipo dedicado a DevEx tiene que proporcionar esas herramientas.
🐬 Flow State
Yo hasta hace poco no había escuchado el concepto de entrar en el flow de desarrollo. Sin embargo cuando lo escuché la primera vez con su explicación, entendí al instante cuándo en mi experiencia laboral he podido entrar en ese flow.
Básicamente se trata de foco, ese estado mental en el que se entra cuando se realiza una actividad y se está inmerso en una sensación de concentración, implicación y gozo o disfrute. Experimentar como desarrollador de esa sensación de forma frecuenta favorece la productividad, la innovación y el crecimiento personal. Factores negativos relacionados con la primera dimensión feedback loops penalizan claramente este estado de flow. Otros aspectos podrían ser: autonomía, claros objetivos de equipo y proyecto, tareas estimulantes y que supongan un desafío.
En esta tercera dimensión, se trata de propiciar las condiciones adecuadas para este estado de flow, como limitar interrupciones, evitar el cambio de tarea y foco, un espacio seguro en el equipo que favorezca la adquisición de retos.
📐 ¿Que medir?
La clave es centrarse en los desarrolladores y sus experiencias en la entrega de software. Esto va desde los sistemas a la percepción del equipo de esos sistemas. Sin olvidarnos de otros factores sociales como la colaboración y la cultura.
Al igual que ocurría con SPACE no debemos ceñirnos a una única dimensión y/o métrica. Usar distintas dimensiones y métricas nos permitirá entender mejor cómo trabajan los equipos/organización y poder tomar medidas acorde.
Para su medida se utilizan las 3 dimensiones:
- Feedback Loops
- Cognitive Load
- Flow State
sobre 3 niveles:
- Percepciones
- Workflows
- KPI’s
👁️ Percepciones vs ⏳ Workflows
Es importante recoger la percepción de los desarrolladores sobre el sistema. De igual manera, debemos recoger los datos objetivos sobre el sistema. Ninguno de los dos niveles debe recogerse en solitario, son complementarios y debemos tener ambas medidas, analizarlas comparativamente para tomar decisiones. Los desarrolladores suelen ser reacios a las métricas o a la mala interpretación de las mismas por parte de managers o clientes. Medir las percepciones de los desarrolladores puede ayudarte a compensar esa negatividad. Además centrarte en las expericencias te ayudará a mantenerte en sintonía con el equipo, siendo consciente y quizá participe de sus problemas o retos del día a día.
🔑 KPI’s
He comentado que la clave es medir aspectos individuales. Pero si nos limitamos a ello, podemos perder de vista la perspectiva global. Es por eso que es importante medir objetivos de alto nivel para servir de guía de las iniciativas de mejora de DevEx.
Se trata de establecer prioridades estratégicas y entender el impacto de las acciones llevadas a cabo. Por ejemplo, reducir reuniones de equipo, mejoran la satisfacción individual al mantener el foco, pero puede penalizar la colaboración con otros equipos lo que puede conllevar una penalización en la satisfacción general de la compañía.
👩🔬 ¿Cómo medir?
Las herramientas principales son:
- Encuestas para la percepción del desarrollador
- Datos en los sistemas
✍️ ¿Cómo diseñar las encuestas?
- Diseña las encuestas con cuidado:
- Desglosa por equipo y persona los resultados
- Compara los resultados con benchmarks
- Mezcla con encuestas transaccionales, en momentos claves.
- Evita la fatiga de las encuestas. Balancea la periodicidad.
🧠 Conclusión
De todos este es el marco que me parece más completo y personalmente más útil. Es más, a medida que investigaba sobre el y leía, más identificado me sentía en momentos concretos a lo largo de mi carrera, tanto en el lado de desarrollador como ahora. En mi opinión es el más moderno y equilibrado. Es el que voy a tomar de referencia a partir de ahora, es el que mejor encaja con mi forma de liderar equipos.
📖 Recursos
📑 📐 Métricas I: Introducción y opinión
📑 📐 Métricas III: SPACE framework
📑 An Actionable Framework for Understanding and Improving Developer Experience