Cada día, los desarrolladores se enfrentan a numerosos problemas técnicos. En un mundo ideal, los resolverían todos a la vez para garantizar que el producto funcione correctamente. Los «OKRs de ingeniería» específicos ayudan a los equipos de ingeniería a mantener el control y a centrarse en lo esencial del desarrollo de producto.
Los OKRs de ingeniería son Objetivos y Resultados clave trimestrales que centran a los equipos de ingeniería en la calidad de su trabajo técnico: funcionalidad, rendimiento, usabilidad, fiabilidad, seguridad y velocidad de desarrollo. Traducen la estrategia en resultados de ingeniería medibles sin renunciar a la profundidad técnica.
En este artículo te explicamos por qué los OKRs para equipos de ingeniería son útiles y cómo escribir buenos OKRs de ingeniería, con consejos y ejemplos concretos incluidos.
- Ingeniería vs. producto: los OKRs de ingeniería miden la calidad del trabajo técnico; los OKRs de producto miden el valor para el cliente. Necesitas ambos y a menudo se solapan.
- Seis áreas de enfoque entre las que elegir: funcionalidad, rendimiento, usabilidad, fiabilidad, seguridad y velocidad de desarrollo. Elige dos o tres por ciclo, no las seis.
- Cuatro pasos para escribirlos: entiende el marco, reúne la información de partida (visión, hoja de ruta, feedback de los usuarios), selecciona las áreas de enfoque y, por último, formula el Objetivo y los Resultados clave.
- Combina outcomes y outputs: los KRs de outcome puro son el ideal, pero empezar con KRs orientados al output suele ser lo más práctico para el trabajo de ingeniería y los equipos que empiezan.
Lo que vas a encontrar:
- ¿Por qué usar OKRs en los equipos de ingeniería?
- OKRs de ingeniería vs. OKRs de producto
- Cómo escribir buenos OKRs de ingeniería
- 25 ejemplos de OKRs de ingeniería
- Conclusión: mejorar el trabajo de ingeniería con OKRs
¿Por qué usar OKRs en los equipos de ingeniería?
Para que los equipos de ingeniería tengan éxito, necesitan compartir una misma idea de lo que significa el éxito. Las métricas elegidas deben ser relevantes para el negocio y, a la vez, fáciles de entender para el equipo.
Los OKRs ayudan a los equipos de ingeniería a tener claridad sobre lo que quieren lograr a corto y medio plazo. Siempre se elaboran de forma colaborativa, en equipo, y garantizan que los objetivos de ingeniería estén alineados con la estrategia de negocio y que todo el mundo reme en la misma dirección.
💡 Recordatorio: OKR (abreviatura de «Objectives and Key Results») es un marco ágil para formular e implementar objetivos estratégicos en las empresas que consta de tres elementos centrales:
- Objetivos: ¿qué quiero lograr?
- Resultados clave: ¿cómo sé que he alcanzado el objetivo?
- Iniciativas: ¿cómo consigo el objetivo?
Por lo general, se formulan de 2 a 4 Objetivos por equipo y de 2 a 4 Resultados clave orientados a resultados por Objetivo. El output se plasma después en las iniciativas (= actividades concretas). Encontrarás más conceptos básicos en nuestra guía de OKR.
Así, los OKRs ayudan a centrarse en lo importante dentro del desarrollo de producto. Ofrecen una versión resumida de la estrategia global para cada equipo de desarrollo y conectan las prioridades a corto y medio plazo con el «porqué» general. De este modo, los equipos de desarrollo se mantienen enfocados en las tareas que de verdad hacen avanzar el negocio.
Además, nuestro mundo cambia a una velocidad vertiginosa. Los OKRs aportan datos en tiempo real sobre los cambios del entorno y hacen visibles tanto el progreso como los retos. Esto mantiene ágiles a los equipos de desarrollo, capaces de reaccionar rápido ante las nuevas condiciones de un ciclo de OKR al siguiente.
OKRs de ingeniería vs. OKRs de producto
En general, los OKRs de ingeniería se parecen a menudo a los OKRs de producto, es decir, los OKRs de todo el equipo de producto multidisciplinar formado por product managers, desarrolladores, diseñadores, redactores y muchos más. Sin embargo, hay una diferencia pequeña pero sutil: los OKRs de ingeniería se centran en la calidad del trabajo (técnico), mientras que los OKRs de producto se centran en el valor añadido para el cliente. Es una simplificación algo generalizada, pero muestra las dos caras de la misma moneda.
Algunas preguntas que sirven de guía para los OKRs de ingeniería son:
- ¿Cómo de eficiente es nuestro proceso de desarrollo?
- ¿Qué calidad tienen los lanzamientos?
- ¿Puede nuestro equipo de desarrollo dar lo mejor de sí?
En conjunto, pues, los OKRs de los equipos de desarrollo y de producto están estrechamente relacionados. En algunos casos incluso se solapan. Sin embargo, hay cuestiones específicas del desarrollo que no quedan reflejadas en los OKRs de producto. Se trata sobre todo de asuntos técnicos que no afectan a todo el equipo de producto, pero que son cruciales para llevar el producto a buen puerto.
Resolver retos técnicos con OKRs
Los equipos de desarrollo (sobre todo en el desarrollo de software) se enfrentan a menudo a retos técnicos complejos en su día a día. Los OKRs de ingeniería ayudan a superarlos aportando foco. Alinean a todos los miembros del equipo hacia los mismos objetivos. Cuando surgen problemas, los OKRs marcan una dirección clara para resolverlos. También sirven de orientación para tomar decisiones y ayudan a priorizar las mejoras técnicas.
Así, los recursos de desarrollo pueden concentrarse y aprovecharse de forma más eficiente en las funciones y productos que contribuyen a los objetivos estratégicos de la empresa.
Cómo escribir buenos OKRs de ingeniería
Definir OKRs para los equipos de ingeniería puede ser complicado. Los OKRs tienen que alinearse con los objetivos de negocio y, a la vez, ser lo bastante específicos como para que todo el equipo sepa qué se espera de él. La clave está en traducir la forma de trabajar del desarrollo, bastante orientada al output, en OKRs orientados al outcome. El énfasis aquí está en «orientados». Los equipos de ingeniería deberían tratar de centrarse en los outcomes según el marco OKR, pero no por sistema. Para algunos equipos o temas puede tener más sentido formular OKRs orientados al output.
En general, unos buenos OKRs de ingeniería se pueden formular en cuatro pasos, que veremos a continuación:
- Entender el método OKR
- Reunir la información de partida
- Seleccionar las áreas de enfoque
- Formular los OKRs
1. Entender el método OKR
En el primer paso deben estar claros los fundamentos del marco. Quien quiera crear OKRs de ingeniería debería haber interiorizado antes:
- qué significan la gestión ágil y una mentalidad ágil.
- cómo se estructura en general el marco OKR y en qué se diferencian los Objetivos, los Resultados clave y las iniciativas. Aquí vale la pena echar un vistazo a nuestra guía de OKR.
- cuál es la diferencia entre output y outcome. Si esto no queda claro, es habitual acabar midiendo mal el éxito de los OKRs y trabajar sin orientación a resultados (para saber más, consulta nuestro artículo sobre los errores más comunes con los OKRs).
- qué es un ciclo de OKR y cómo funciona. Esto incluye conocer los distintos eventos que tienen lugar dentro de un ciclo, es decir, la sesión de planificación de OKR, los check-ins periódicos, la revisión de OKR y la retrospectiva de OKR.
💡 Consejo: un ciclo de OKR suele durar tres meses, aunque no hay una regla fija al respecto. Los equipos de desarrollo deberían elegir siempre la duración del ciclo en función de sus necesidades y dependencias concretas (por ejemplo, el calendario del año fiscal o la planificación de los proyectos).
2. Reunir la información de partida
Los OKRs para equipos de ingeniería nunca deberían salir de la nada. Al contrario: tienen que partir de una pregunta. ¿Cómo se ve el éxito de nuestro producto al final del ciclo desde la perspectiva de ingeniería? Para responder lo mejor posible a esta pregunta con OKRs inspiradores y orientados a resultados, hace falta cierta información de partida.
Entre otras cosas:
- Los OKRs generales de la empresa o los OKRs de otros departamentos y equipos.
- La visión y la misión de la empresa
- La visión y la estrategia de producto
- Los conjuntos de OKRs existentes (si los hay)
- Las hojas de ruta de desarrollo de producto
- Información sobre el feedback de los usuarios (por ejemplo, problemas o soluciones ya conocidos)
No siempre es necesario tener toda la información. La lista sirve más bien como orientación sobre el grado de claridad que conviene tener para formular buenos OKRs. Si falta alguna pieza del puzle, los equipos pueden crear igualmente los OKRs del ciclo actual y completar la información más adelante. Al fin y al cabo, trabajar con OKRs implica también ir mejorando el propio proceso de forma continua.
3. Seleccionar las áreas de enfoque
¿Tienes claros los fundamentos y cuentas con toda la información necesaria? Entonces el siguiente paso es elegir el tema adecuado en el que centrarte. Para los ingenieros (de software) resultan especialmente importantes:
- Funcionalidad: entregar nuevas capacidades o desarrollar nuevas funciones.
- Rendimiento: garantizar que un producto o servicio funciona correctamente y es escalable.
- Usabilidad: mejorar las funciones existentes y hacer que los productos o servicios actuales sean más intuitivos para mejorar la experiencia de usuario.
- Fiabilidad: garantizar que un producto o servicio funciona siempre de forma fiable y según lo esperado.
- Seguridad: reforzar la protección e introducir nuevas medidas para que los datos de los usuarios estén siempre seguros y protegidos.
- Velocidad de desarrollo: optimizar el ciclo de desarrollo y lanzar nuevas funciones o productos con mayor rapidez.
Es imposible trabajar en todos los temas a la vez. Por eso, los equipos de ingeniería deberían elegir siempre solo dos o tres áreas de enfoque para los OKRs de cada ciclo. Para averiguar qué temas son los más importantes para el próximo ciclo, puede ayudarte plantearte las siguientes preguntas:
- ¿Cuáles son los objetivos estratégicos de negocio que queremos alcanzar? ¿Cómo podemos contribuir a ellos?
- ¿Hay problemas técnicos o brechas de seguridad que haya que abordar con urgencia?
- ¿Qué necesidades de los clientes u oportunidades de mercado deberíamos tener en cuenta o podemos atender (de forma más eficaz)?
- ¿Hay nuevas tecnologías o herramientas que podamos aprovechar?
- ¿Existen problemas o cuellos de botella en el proceso de desarrollo que deberíamos solucionar?
4. Formular los OKRs
Una vez definidas las prioridades temáticas, el siguiente paso es formular los OKRs. Suele ser la parte más difícil, en la que fracasan muchos equipos. Como base, los OKRs se rigen por esta regla:
Conseguiremos [Objetivo], medido a través de [Resultados clave].
Un Objetivo siempre debería responder a la pregunta de qué quieres lograr. Cada Resultado clave describe entonces cómo reconocer que se ha alcanzado el Objetivo. Por eso, los Objetivos deberían formularse siempre de forma cualitativa, fácil de entender e inspiradora. Los Resultados clave deben ser medibles, orientados a resultados y SMART.
Hemos resumido todos los criterios para unos buenos Objetivos y Resultados clave, además de consejos concretos de redacción, en nuestro artículo «Cómo escribir OKRs: consejos para Objetivos y Resultados clave realmente buenos». Las reglas y los consejos del artículo se aplican a todo tipo de OKRs. Para los equipos de ingeniería (y quienes empiezan con los OKRs), puede ser mejor formular primero los llamados OKRs comprometidos, es decir, OKRs que se deben alcanzar al 100 por cien (más sobre esto en nuestro artículo sobre los OKRs aspiracionales vs. comprometidos).
Además: al formular sus OKRs, los equipos de ingeniería deberían tener presente la diferencia entre outcomes y outputs. Ahora bien, eso no significa que todos los OKRs de ingeniería tengan que formularse forzosamente como outcomes. Los OKRs también funcionan con Resultados clave orientados al output, aunque entonces tienen un enfoque distinto. Según lo que quieras conseguir con los OKRs, a veces tiene sentido centrarse al principio en Resultados clave orientados al output e incorporar los outcomes más adelante o solo para determinados temas.
💡 Consejo: además de dar con la redacción adecuada, a los equipos de ingeniería también puede costarles encontrar las métricas correctas para los Resultados clave. Para empezar, hemos reunido algunas sugerencias:
- Tiempo de desarrollo
- Tiempo de respuesta de la aplicación
- Número de errores críticos
- Tasa de uso de las nuevas funciones
- Tiempo de lanzamiento al mercado de las nuevas versiones
25 ejemplos de OKRs de ingeniería
Para ayudarte a empezar, aquí tienes algunos ejemplos de OKRs de ingeniería.
💡 Nota: siempre recomendamos que escribas tus propios OKRs. Aun así, estos ejemplos pueden ser una buena fuente de inspiración. En nuestra web encontrarás muchos más ejemplos de OKRs de otras áreas como ventas, marketing y recursos humanos.
⚙️ Funcionalidad
📈 Rendimiento
⛵️ Usabilidad
🤝 Fiabilidad
🔒 Seguridad (de datos)
💻 Velocidad de desarrollo
Mejora el trabajo de ingeniería con OKRs
Los OKRs de ingeniería ayudan a definir objetivos claros para los equipos de ingeniería que se alinean con la estrategia de negocio. Así, los equipos pueden centrarse en lo importante y responder a los cambios mientras mejoran la calidad de su trabajo de ingeniería. Los OKRs de ingeniería siempre responden a la pregunta: ¿cómo se ve el éxito de nuestro producto al final del ciclo desde la perspectiva del desarrollo? Tanto los OKRs orientados al outcome como los orientados al output pueden ser útiles, según las necesidades y los objetivos del equipo.
Así te ayuda Mooncamp
Un software de OKR como Mooncamp facilita que los equipos de desarrollo creen OKRs y mantengan el control durante el desarrollo de producto:
- Aporta transparencia y alineación dentro del equipo o la empresa.
- Facilita una mejor colaboración y funciona como punto central de comunicación.
- Es mucho más fácil gestionar los OKRs en un software de OKR que en hojas de Excel o herramientas mal integradas.
- Garantiza que todo el mundo haga seguimiento de sus OKRs mediante check-ins integrados y recordatorios periódicos.
- Ofrece visibilidad del progreso en todo momento y permite filtrar y analizar los datos con facilidad.
