Hace unos días luego de un post de Nadia Zapata (1), Jose Luis Lee exponia un problema común al momento de escribir OKR (2) y que el compartía en su post (3), y es confundir un Key Result (kr) con una tarea, justo en esa misma dirección quisiera poner otro granito de arena, de algo que he compartido en otros escenarios y aporta (desde mi punto de vista) a evitar en e problema
un OKR mal planteado podría ser
Obj2. Investigar y mejorar la satisfacción del cliente (4) |
Podríamos decir, que este problema se podría observar en el kr2, kr3 y kr4, pues se observan que son acciones pero tal como están redactadas no se conectan bien con el objetivo.
Una forma de evitar esto es
ver los kr como criterios de aceptación similar a como lo hacemos con las historias de usuarioDe esta manera nos enfocamos en satisfacer el enunciado del objetivo (ver 5 y 6) y no caer en el error de identificar las tareas.
Basado en esta sugerencia el OKR quedaría
Obj2. Investigar y mejorar la satisfacción del cliente (4) |
Nota:
hasta acá este compartir.
Saludos ágiles
Jorge Abad
Aclaraciones, Notas, Comentarios y Referencias
- Diapositivas de Nadia Zapata sobre OKR compartidas en el Ágiles 2019
- Para más información de OKR ver http://www.lecciones-aprendidas.info/2019/10/un-ejemplo-de-okr.html
- Me equivoqué con mis ejemplos de OKRs - de Jose Luis Lee
- tomado de https://okrexamples.co/support-customer_service-okr-examples
- http://www.lecciones-aprendidas.info/2013/06/la-magia-de-las-historias-de-usuario.html
- Reconozco que este ejemplo es fácil entender por las personas de tecnología que están habituadas a trabajar con las historias de usuario, pero ayuda que al momento de facilitar o explicar el concepto, identificando claramente cuando un kr tiene sabor de tarea y cuando a sí tiene sabor a resultado.
- Porque deberíamos intentar implementar OKRs en una Transformación Agile
- http://www.lecciones-aprendidas.info/2013/11/como-es-una-historia-de-usuario-un.html
No hay comentarios.:
Publicar un comentario