.png)
.png)
Los equipos de Producto son grupos multifuncionales que combinan product managers, diseñadores, data scientists, redactores... y desarrolladores. Entonces, ¿deberían existir los OKR de Ingeniería si ya tenemos OKR de Producto?
Sí. Los OKR de Ingeniería se centran en la calidad del trabajo, mientras que los OKR de Producto se centran en entregar el valor correcto. Es un planteamiento un poco simplificado, pero pone de relieve las dos caras de la moneda. En muchos casos, necesitará un gran trabajo de desarrollo para mejorar la experiencia de usuario. Pero también hay muchos aspectos específicos de Ingeniería que los objetivos de Producto no cubrirán.
Áreas de enfoque:
Preguntas clave:
¿Qué tan eficiente es nuestro proceso de desarrollo?
¿Qué tan buena es la calidad de nuestras versiones?
¿Estamos generando demasiada deuda técnica?
¿Puede nuestro equipo de desarrollo dar lo mejor de sí?
Cómo escribir OKR para equipos de Ingeniería
Paso 1. Entender la diferencia entre OKR y proyectos
Antes de sumergirse en el proceso de OKR, es esencial entender la diferencia entre los Objetivos, los Resultados Clave y los proyectos:
- Objetivos: ¿qué queremos lograr el próximo trimestre?
- Resultados Clave: ¿cómo vamos a medir el progreso?
- Proyectos/Iniciativas: ¿cuáles son nuestras mejores apuestas para llegar ahí?
Los proyectos se mencionan aquí porque un error común es incluirlos como Resultados Clave. Pero un proyecto es un entregable (Output), no una meta (Outcome).
Un buen Objetivo debe ser inspirador y fácil de entender para cualquier persona de su organización. Puede ser más específico en los Resultados Clave, pero los Objetivos deben dar una idea clara del impacto esperado al final del trimestre.
Un buen Resultado Clave debe ayudarle a medir el progreso hacia su Objetivo. Una buena prueba es preguntarse: «¿haríamos las cosas de forma diferente si este KR se desviara?». Si la respuesta es negativa, entonces necesita refinar su OKR.
Por último, sus proyectos son apuestas que hace para lograr sus OKR. Algunas funcionarán, así que redoble la apuesta. Otras fallarán, y debe estar bien detenerse y pasar a la siguiente idea.
Paso 2. Elija 2-3 áreas de enfoque
El siguiente paso es elegir el enfoque correcto. Un equipo de Ingeniería tendrá varias opciones para elegir:
- Fiabilidad: garantizar que el servicio siempre funcione como se espera.
- Usabilidad: mejorar las funcionalidades existentes para hacer la plataforma intuitiva.
- Funcionalidad: entregar nuevas capacidades.
- Seguridad: mejorar la protección existente, y añadir nuevas salvaguardas para proteger a los clientes.
- Rendimiento: asegurarse de que su aplicación sea responsiva y escalable.
- Velocidad de desarrollo: invertir en su ciclo de desarrollo para lanzamientos más rápidos.
Sin embargo, no intente abarcarlo todo. Deberá aislar 2 o 3 temas para el trimestre y usarlos como punto de partida para sus OKR.
Paso 3. Escriba su plan
Una vez que haya delimitado su enfoque, puede comenzar a escribir sus OKR.
Acuerden 2-3 Objetivos antes de sumergirse en los Resultados Clave. Encontrará algunos ejemplos a continuación, y aquí tiene una guía sobre cómo escribir OKR si está empezando
Ejemplo de OKR para Ingeniería
OKR para reducir la deuda técnica
Abordar la deuda técnica generada por la carrera por lanzar funcionalidades
Reducir un 30% el porcentaje de incidencias etiquetadas como deuda
Migrar el 80% de los proyectos a la nueva librería de UI para reducir la deuda de interfaz
Reducir un 50% la tasa de contactos relacionados con la deuda técnica
OKRs para mejorar la velocidad de desarrollo
Acelerar el desarrollo mediante la automatización
El 100% de los repositorios cuenta con un pipeline de entrega continua
Aumentar la cobertura de código del 30% al 60%
Reducir el tiempo de compilación de 20 a 5 minutos
Reducir el tiempo de ciclo de 8 días a 24 horas
Todos los desarrolladores tienen acceso a una biblioteca de QA con ejemplos de pruebas automatizadas
OKRs para mejorar el rendimiento y la fiabilidad
Construir una infraestructura de clase mundial
Aumentar el Apdex de 0,7 a 0,98
Reducir un 40% el número de incidencias que generaron una alerta
Mejorar las sesiones sin fallos del 75% al 95%
Reducir el tiempo de carga de las páginas principales a menos de 3 segundos
OKRs para mejorar la calidad del código
Demostrar estándares excepcionales en calidad de código
El 100% de los pull requests son revisados por 2 desarrolladores
El 75% de los desarrolladores ha recibido formación en QA
El 100% de los repositorios utiliza linting y análisis estático de código
Reducir un 60% el porcentaje de builds rotos relacionados con QA
OKRs para ofrecer una excelente experiencia de usuario
Mejorar significativamente la experiencia de usuario gracias a un mejor rendimiento
Reducir un 45% el número de excepciones en producción
Reducir el tiempo de arranque en frío de las instancias de clientes de 2 minutos a 10 segundos
Reducir el tiempo de respuesta de la API de 900 ms a 450 ms
Mejorar el NPS de 15 a 35
Haciendo seguimiento de sus OKR
Saber cómo escribir buenos OKR es fundamental, pero sin un buen seguimiento, los OKR se irán desvaneciendo y se perderá el enfoque.
No somos los únicos que lo decimos:
- Peter Kappus escribe que "los check-ins son la parte más importante de los OKR".
- Felipe Castro advierte que no hay que dejar que los OKR se conviertan en propósitos de Año Nuevo.
- Christina Wodtke nos dice que "la cadencia es probablemente lo más importante".
Cuanto más fácil sea para un equipo tener conversaciones semanales sobre sus OKR, mejor los ejecutará. Aquí tiene algunas buenas prácticas para hacer seguimiento de sus OKR.
1. Haga check-ins semanales
Los OKR trimestrales deben seguirse cada semana para ser eficaces. Sin una reflexión continua sobre el progreso, sus OKR no serán muy diferentes de tener KPI.
El proceso de check-in puede automatizarse con una plataforma como Tability, que se encarga de los recordatorios y distribuye las actualizaciones a los equipos.
2. Haga seguimiento de su confianza
Las buenas actualizaciones de progreso deberían ayudar a todos a entender qué tan lejos están de su meta, pero también qué tan confiados están en lograrla. Puede usar un simple código de colores rojo/amarillo/verde para indicar su confianza.
3. Facilite la visualización de las tendencias
Por último, es importante observar las tendencias para evitar falsos positivos. No es raro que un equipo tenga un comienzo fuerte y luego se ralentice a mitad del trimestre. Esto será difícil de ver a menos que pueda observar las tendencias de progreso de cada Resultado clave.
¿Qué otras métricas de Ingeniería puede utilizar?
Ahora que ya tiene buenos objetivos, es momento de elegir algunos resultados clave, y encontrar buenas métricas que funcionen para su equipo puede ser complicado. Por suerte, hemos reunido todas las que puede usar.
Aquí tiene algunas para empezar:
Tiempo de ciclo
El tiempo que se tarda en pasar del código confirmado (commit) al código publicado para los clientes.
Volumen de despliegues
Cuántos despliegues se realizan cada día/semana/mes.
Tasa de apertura/cierre
Número de incidencias abiertas dividido entre el número de incidencias cerradas.
Número de incidencias
Cuántas incidencias ocurrieron en producción, idealmente categorizadas por gravedad.
Cobertura de código
El porcentaje de código que está cubierto por pruebas automatizadas.
Tiempo de compilación
El tiempo promedio que se tarda en completar una compilación. Indica cuánto tiempo le toma a un desarrollador saber si sus cambios rompieron la aplicación.
Tiempo de revisión hasta la fusión (RTMT)
El tiempo que se tarda en completar y fusionar una revisión de código.
¿Tiene un objetivo en mente pero no sabe cómo alcanzarlo?
La IA gratuita de Tability puede crear una estrategia detallada con todos los pasos necesarios para alcanzar sus metas.
Generar su estrategia con IA
