Pasé gran parte de mi carrera en el mundo de la Integración Continua (CI) y la Entrega Continua (CD) (hola Atlassian Bamboo, hola Bitbucket Pipelines 👋). Algo que tuve claro cuando construimos Tability es que tendríamos que tomar prestadas algunas ideas de Ingeniería para resolver el problema de los OKR.
Espera, ¿cuál es el problema con los OKR?
Te recomiendo mucho el libro de Christina Wodtke, Radical Focus, ya que ilustra uno de los errores más comunes de los OKR: la gente se olvida.
Así es como suele ir la historia. Un equipo ha crecido más allá del punto en que los fundadores pueden seguirlo todo. Empiezan a buscar una mejor manera de organizar el trabajo. Oyen hablar o leen sobre los OKR. ¡Les encanta! Definen el primer conjunto de OKR y lo ponen todo en una hoja de cálculo. Todos están entusiasmados. Empiezan a trabajar en las prioridades principales.
Un mes después: nadie recuerda cuáles eran los OKR, y todos vuelven a ir en direcciones diferentes. Pusieron todo su esfuerzo en la planificación y se olvidaron de definir una forma de hacer seguimiento del progreso.
Ojos que no ven, corazón que no siente.
El trabajo es, paradójicamente, un poderoso generador de distracciones. Cada proyecto parece ir sumando un conjunto de funciones adicionales, convirtiéndose en un calamar gigante que tiene al equipo como rehén. Cada semana produce decenas de llamadas, cientos de correos, que te roban la atención de tus prioridades principales. Cada tarea tiene sus propias incógnitas desconocidas que te arrastran por la madriguera del conejo.
Así que, volviendo a nuestros OKR, están condenados al fracaso a menos que tengamos algún tipo de marco de trabajo que los sostenga. No porque al equipo no le importe, sino porque no tendrá tiempo de pensar en ello — a menos que se lo recordemos.
Los principios de CI/CD al rescate
Aquí tienes una definición de Integración Continua tomada del sitio web de Martin Fowler.
La Integración Continua es una práctica de desarrollo de software en la que los miembros de un equipo integran su trabajo con frecuencia, normalmente cada persona integra al menos una vez al día, lo que lleva a múltiples integraciones por día. Cada integración se verifica mediante una compilación automatizada (incluidas pruebas) para detectar errores de integración lo antes posible. Muchos equipos descubren que este enfoque reduce significativamente los problemas de integración y permite a un equipo desarrollar software cohesionado con mayor rapidez.
Vale — esto es súper técnico. Así que no se trata tanto de habilitar la CI en tus hojas de cálculo, sino más bien de entender por qué es un enfoque popular en el desarrollo de software.
Los equipos de producto de todo el mundo han adoptado el CI/CD porque se dieron cuenta de que las iteraciones rápidas producen resultados mucho mejores que hacer una planificación grandiosa con un enfoque en cascada para la entrega. Revisar el progreso de forma temprana y frecuente reduce el coste de equivocarse y te permite validar tu dirección obteniendo feedback de tus clientes.
Las cosas se vuelven aún más interesantes cuando miras los 5 principios de la Entrega Continua publicados por Jez Humble:
- Construir la calidad desde el principio
- Trabajar en lotes pequeños
- Los ordenadores realizan tareas repetitivas, las personas resuelven problemas
- Perseguir sin descanso la mejora continua
- Todos son responsables
Creo firmemente que puedes y debes aplicar estos principios al proceso de los OKR.
Los 5 principios de los OKR
Construir la calidad desde el principio
«Es mucho más barato arreglar problemas y defectos si los encontramos de inmediato»
No esperes hasta el final del trimestre para darte cuenta de que uno de tus Resultados Clave se ha descarrilado. Un ritmo diario para los OKR es demasiado, pero deberías revisar el progreso de tus Resultados Clave cada semana (idealmente un lunes, para retomar el ritmo tras el fin de semana). Ponte al día con cualquier KR que lleve en rojo más de 2 semanas.
Trabajar en lotes pequeños
«Reduce el tiempo que se tarda en obtener feedback sobre nuestro trabajo, facilita el triaje y la resolución de problemas, aumenta la eficiencia y la motivación, y evita que caigamos en la falacia del coste hundido.»
Frases como «no podemos medir el progreso hasta el próximo mes» son señales de alarma. El trabajo realizado para avanzar en los Resultados Clave debería empezar a generar impacto en cuestión de semanas, no de meses. No apuestes por los grandes golpes de efecto. Haz todo lo posible por conseguir un progreso incremental a lo largo del trimestre.
Los ordenadores realizan tareas repetitivas, las personas resuelven problemas
«El objetivo es que los ordenadores realicen tareas simples y repetitivas, como las pruebas de regresión, para que los humanos puedan centrarse en resolver problemas»
Este es un relato de advertencia contra el exceso de automatización en los OKR. He visto casos en los que los equipos querían que el progreso de los Resultados Clave se actualizara automáticamente mediante scripts o integraciones, sin ninguna intervención humana.
Esto acaba con los beneficios de los OKR, ya que se pierde la parte de resolución de problemas. El valor de los OKR proviene de (1) que la gente recuerde las prioridades principales, y (2) que la gente piense activamente en la brecha entre dónde está y dónde se supone que debería estar.
La automatización total de los OKR elimina el toque humano. Los ordenadores deberían ayudarte a recopilar los datos, pero solo tu equipo puede interpretarlos y usarlos para tomar decisiones críticas.
Perseguir sin descanso la mejora continua
«No trates la transformación como un proyecto que se emprende y luego se completa para volver a la actividad habitual.»
Creo que los OKR sufren un poco por su historia. Es un proceso que a menudo se asocia con la alta dirección y las grandes empresas, y suena mucho a jerga de estrategia. Eso puede hacer que sea difícil de vender para algunos equipos que lo ven como otra forma de microgestión (¡y a veces tienen razón!).
Los OKR deberían empoderar a los equipos y fomentar la innovación de abajo hacia arriba — pero necesitas tener la cultura adecuada. Significa crear espacio para que la gente pruebe y falle, y significa invertir en las herramientas y procesos adecuados para que tu equipo pueda crecer.
Todos son responsables
«Todos trabajan juntos para lograr los objetivos a nivel organizacional, en lugar de optimizar lo que es mejor para su propio equipo o departamento.»
Los OKR tratan ante todo de alineación. El objetivo es crear una estrella polar compartida y definir un lenguaje común para describir cómo se ve el éxito.
Esto también es por lo que los OKR deberían basarse en el equipo y no en las personas. Se trata de hacer lo que es mejor para los clientes y el negocio, no lo que es bueno para cada miembro de la organización.
Qué significa esto en la práctica
Revisa el progreso cada semana
En un flujo normal de Entrega Continua, querrías que el código se integrara todos los días. Eso sería demasiado para los OKR, y una cadencia semanal es más que suficiente.
Actualiza el progreso de los Resultados Clave el lunes, y luego deja que el equipo se concentre en el trabajo durante la semana. Tendrán el contexto adecuado en mente y deberían poder avanzar algo antes de la próxima reunión de OKR.
Usa estados rojo/amarillo/verde para indicar tu nivel de confianza
Necesitas una forma sencilla de entender cuándo las cosas se están descarrilando. En el software ocurre cuando la compilación se pone en rojo. Puedes obtener resultados similares usando semáforos para indicar tu nivel de confianza en cada uno de los Resultados Clave.
¡Asegúrate de conservar el historial de tus check-ins! No reemplaces los valores existentes en tu hoja de cálculo, ya que eso te impedirá ver las tendencias.
Haz que tus KR sean medibles
Evita los Resultados Clave binarios (está lanzado/no lanzado) o las afirmaciones vagas (a los usuarios les encanta nuestro producto). Si quieres que tu equipo sea eficaz, necesitarás formas concretas de medir el progreso.
- Está lanzado -> Pasamos de 0 a 350 usuarios activos semanales
- A los usuarios les encanta nuestro producto -> Aumentamos nuestro NPS de 20 a 60
3 rojos = todos manos a la obra
La Integración Continua exige que la compilación se arregle en cuanto se rompe. Con los OKR hay que ser un poco más flexible, ya que el progreso puede fluctuar, pero te recomiendo tener una conversación seria en la tercera actualización en rojo.
No siempre se tratará de conseguir que el equipo lo deje todo para centrarse en un solo objetivo. A veces te darás cuenta de que quizás fuiste demasiado ambicioso, o de que era el KR equivocado desde el principio. Pero — tienes que tener esa conversación para que todos estén en la misma página.
¡Mantenlo ligero!
La Entrega Continua solo es posible si desplegar código a producción es pan comido. Lo mismo ocurre con actualizar los OKR.
Si se siente como una tarea pesada o le lleva horas a la gente actualizar sus KR, entonces dejarán de hacerlo. Y si dejan de actualizar sus KR, pronto se olvidarán de ellos. Volverías a la casilla de salida.
Por supuesto, este es el final del artículo donde te digo que construimos Tability precisamente para eso. Así que, pruébalo, ¡es gratis para 5 usuarios!
.jpg)
.png)
