En pocas palabras
Marco de Forsgren, Storey y otros (GitHub, Microsoft Research) que mide la productividad combinando satisfacción, rendimiento, actividad, colaboración y eficiencia, en niveles individual, de equipo y de sistema.
Qué problema resuelve
Medir la productividad con líneas de código, commits o tickets cerrados, que se manipulan fácilmente y deterioran la colaboración.
Cuándo utilizarlo
Gerencia de desarrollo que quiere evaluar el efecto de un cambio (herramientas de IA, reorganización, plataforma). Ejemplo: comprobar si un asistente de código mejora el flujo o solo aumenta el volumen de PR.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
Las cinco dimensiones
| Dimensión | Qué capta | Ejemplos de métricas |
|---|---|---|
| Satisfaction and well-being | Satisfacción, bienestar, agotamiento | Encuesta trimestral, eNPS del equipo, riesgo de burnout |
| Performance | Resultado del trabajo, no volumen | Calidad, fiabilidad, incidentes, satisfacción del cliente |
| Activity | Volumen de acciones | PR, despliegues, revisiones (solo como contexto) |
| Communication and collaboration | Cómo fluye la información | Tiempo de primera revisión, calidad del onboarding |
| Efficiency and flow | Avance sin interrupciones ni esperas | Tiempo en espera, interrupciones, lead time |
Niveles
Cada dimensión puede observarse a nivel individual (para la propia reflexión), de equipo y de sistema (flujo entre equipos). La agregación por equipo es la adecuada para decisiones de gestión.
Ejemplo: evaluar un asistente de código con IA
| Dimensión | Métrica | Fuente |
|---|---|---|
| Satisfaction | «Me siento más productivo con la herramienta» (1–5) | Encuesta |
| Performance | Change fail rate y defectos escapados | DORA, incidentes |
| Activity | PR integrados por semana | Git |
| Collaboration | Horas hasta la primera revisión | Git |
| Efficiency | Tiempo de PR abierto a integrado | Git |
Si la actividad sube pero la revisión se alarga y el change fail rate empeora, la herramienta está trasladando trabajo a revisores y a producción.
DevEx: tres palancas
El trabajo posterior de los mismos autores resume la experiencia de desarrollo en tres factores accionables: feedback loops (rapidez de pruebas, builds, revisiones), cognitive load (complejidad, documentación, herramientas) y flow state (bloques sin interrupciones). Son buenos temas para encuestas cortas y frecuentes.
Relación con DORA
DORA mide el rendimiento del sistema de entrega; SPACE amplía la mirada a las personas y la colaboración. Usar ambos evita optimizar el pipeline a costa del equipo.
Antipatrones frecuentes
- Rankings individuales de commits o puntos de historia.
- Solo métricas de actividad: se infla lo medido (ley de Goodhart).
- Encuestas sin acción visible: la participación cae a la segunda edición.
Encuesta trimestral de ejemplo
Respuesta en escala de 1 (totalmente en desacuerdo) a 5 (totalmente de acuerdo), anónima y agregada por equipo:
| Dimensión | Pregunta |
|---|---|
| Satisfaction | Recomendaría mi equipo a una persona amiga como lugar de trabajo |
| Satisfaction | Mi carga de trabajo es sostenible |
| Performance | Confío en que lo que despliego funciona correctamente en producción |
| Collaboration | Recibo revisiones de código útiles y a tiempo |
| Collaboration | Encuentro fácilmente la información que necesito para mi trabajo |
| Efficiency | Puedo dedicar bloques de al menos dos horas sin interrupciones varias veces por semana |
| Efficiency | Las pruebas y el build me dan feedback lo bastante rápido |
| Abierta | ¿Qué es lo que más te frena en tu trabajo diario? |
La pregunta abierta suele ser la más valiosa: agrupa las respuestas por temas y responde con acciones concretas.
Panel inicial por equipo
| Dimensión | Métrica de sistema | Métrica de percepción |
|---|---|---|
| Satisfaction | Rotación voluntaria (trimestral) | Satisfacción y sostenibilidad |
| Performance | Change fail rate, defectos escapados | Confianza en los despliegues |
| Activity | Despliegues por semana (solo contexto) | — |
| Collaboration | Mediana de horas hasta la primera revisión | Calidad de revisiones y documentación |
| Efficiency | Duración del pipeline, tiempo PR abierto → integrado | Tiempo sin interrupciones |
Combinar en cada dimensión una medida de sistema y una de percepción evita conclusiones basadas en una sola fuente.
Presentar los resultados a la dirección
- Mostrar tendencias por equipo, no rankings entre equipos.
- Acompañar cada dato de una interpretación y de una acción propuesta: «el tiempo de primera revisión subió a 26 h → reservamos dos franjas diarias de revisión».
- Traducir a impacto de negocio cuando sea posible: horas recuperadas, lead time, incidentes.
- Informar a los equipos antes que a la dirección y con el mismo contenido.
Ritmo de mejora
- Medir la línea base.
- Elegir una fricción principal por trimestre con los equipos.
- Aplicar el cambio (por ejemplo, paralelizar el pipeline o una política de reuniones).
- Medir de nuevo con la misma metodología.
- Comunicar el resultado, sea bueno o no.
Criterios de implementación
Elige una pregunta concreta antes de elegir métricas. Comunica para qué se usarán los datos y cómo se agregan. Combina datos de sistema con una encuesta breve, repetida con la misma metodología, y comparte los resultados con los equipos.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.