|
Hola {{nombre}},
Los OKR tienen fama de herramienta de dirección. Y en muchas organizaciones lo son, en el peor sentido: los define el liderazgo arriba del todo, bajan como cascada y el equipo los recibe como una lista de objetivos que nadie le preguntó si eran alcanzables.
Cuando los OKR funcionan a nivel de equipo, el cambio principal es de pregunta: el equipo deja de preguntarse "¿qué tenemos que hacer?" y empieza a preguntarse "¿qué tenemos que conseguir?".
En la práctica, eso se nota en cuatro sitios:
- El backlog se prioriza contra un resultado, no contra una lista de funcionalidades.
- Las conversaciones de refinement incluyen "¿esto mueve el key result?"
- El equipo puede decir que no a peticiones que no conectan con el objetivo — con argumento, no con resistencia.
- La retrospectiva tiene un criterio real: ¿aprendimos algo sobre el resultado que buscábamos?
Lo que suele fallar cuando los equipos lo intentan solos:
|
Objetivos escritos como tareas grandes
"Lanzar la nueva versión del módulo de pagos" no es un objetivo OKR. Es una tarea grande. Un objetivo describe un estado deseado: "Que los usuarios completen el pago sin abandonar el proceso".
|
|
Key Results que miden outputs, no outcomes
"Completar 5 historias de usuario" mide lo que haces, no lo que cambia. Un KR bien formulado mide algo que cambia en el mundo cuando el trabajo funciona: "Tasa de abandono en checkout por debajo del 15%".
|
El jueves que viene: IA en equipos técnicos — lo que ya es útil sin el hype, y lo que todavía falla.
— Alex
ITNOVE · Consultoría Agile, OKR e IA
|