¡Deja de usar las métricas de desarrollo!

Gestiona el mejor equipo de la empresa: el tiempo de ciclo más rápido, la mayor precisión de planificación y la menor cantidad de reelaboración. Su equipo tiene el tiempo de revisión más bajo, la mayor cantidad de implementaciones semanales y la mejor proporción de errores/KLOC. Y luego alguien de alto nivel cierra tu proyecto, ¿qué acaba de pasar?
La paradoja de salida
Como desarrollador junior, me enseñaron que fusionar pequeños cambios con frecuencia es clave para generar valor rápidamente. Como gerente junior de ingeniería, me dijeron que el seguimiento y la optimización de las métricas eran vitales para el trabajo del gerente. El primer resultado de Google me señaló un montón de términos y siglas, y estas fueron mis primeras introducciones a las métricas de desarrollo.

Las métricas de desarrollo son esencialmente un conjunto de métricas que ayudan a los equipos de ingeniería a rastrear su velocidad (movimiento rápido) y calidad (sin romper cosas). Se pueden utilizar diferentes métricas para medir estos atributos. Tiempo de ciclo, conteo de relaciones públicas o velocidad de seguimiento de problemas cerrados. Para realizar un seguimiento de la calidad, supervise el recuento de defectos, el tiempo medio de resolución o la cantidad de implementaciones que causan fallas. Cada una de estas métricas proporcionará información diferente sobre el atributo que inspecciona. Algunas métricas también ayudan a analizar los atributos de proxy. Realice un seguimiento del retrabajo para analizar la eficiencia, lo que afecta la velocidad. La precisión de la planificación es un buen indicador de la previsibilidad, que permite tanto la velocidad como la calidad y tiene valor por sí misma.
El problema con todas las métricas anteriores es que si bien hacen un excelente trabajo al medir la eficiencia, por lo general no son suficientes para medir el éxito. La razón principal es que están completamente desconectados de los KPI comerciales (indicadores clave de rendimiento, otro nombre elegante para las métricas). Esta desconexión a menudo conduce a una comunicación ineficaz entre las organizaciones de la empresa, principalmente producto e ingeniería. Después de todo, la organización del producto (y el resto del negocio) no se preocupan solo por la velocidad o la calidad, ya que estos rastrean la producción . La organización del producto generalmente se preocupa por el resultado : ¿qué ingresos produjo nuestra nueva función? ¿Cuántos nuevos usuarios atrajimos?

Como nuevo gerente de ingeniería, esto fue desconcertante para mí. Por un lado, estaba claro que seguir midiendo a mi equipo en función de las métricas de desarrollo sobre las métricas comerciales conduciría a una desalineación con el equipo de producto. Por otro lado, me parecía injusto medir a mi equipo en base a métricas de negocio: ¿Cómo pueden impactarlos? ¿Es nuestro trabajo? ¿Estaré pisando los dedos de los pies de la organización del producto?
Medir lo que importa
Di un salto de fe e intenté usar métricas comerciales como mi estrella polar. A medida que pasaba el tiempo, condujo a mejores resultados.
Primero, simplificó la comunicación. es más fácil para la contraparte de su producto entender por qué es esencial priorizar la actualización de la base de datos cuando lo expresa en términos de KPI compartido que se verá perjudicado. Solo porque está claro para usted que si no prioriza la actualización de la base de datos, las siguientes historias de usuario tardarán el doble y tendrá que dedicar tiempo al mantenimiento, lo que retrasará el lanzamiento de la función hasta el punto en que ganó. Si no tiene suficiente tiempo para alcanzar el objetivo de uso que estableció como KPI, no significa que esté claro para la contraparte de su producto. Quiero decir, eso es un montón de saltos; ¿Por qué no empezar con el que importa? (no, no es la actualización de DB)

En segundo lugar, medir a mi equipo en función de las métricas comerciales me hizo ver que podemos impactarlos bastante:
- Podemos identificar características en las que podemos construir el 80% del valor del usuario por el 20% del esfuerzo. Esto puede liberar recursos para ayudar a mover nuestros KPI aún más rápido. Para hacer eso, el equipo debe comprender claramente los objetivos comerciales, las necesidades del usuario y el impulso para mejorarlos.
- Podemos usar los KPI para guiar qué deuda tecnológica debemos acumular: ¿Estamos tratando de obtener nuestros primeros usuarios de funciones y la falla de funciones es una opción? Lancemos lo más rápido posible y preocupémonos por la deuda tecnológica más tarde. ¿Estamos tratando de mejorar la retención de una gran base de clientes? Aseguremos una alta calidad para este.
- Podemos sugerir soluciones a los puntos débiles que el producto ni siquiera sabía que tenían solución, en función de un nuevo avance tecnológico o un ángulo de ingeniería innovador.
- Podemos (por molesto que sea) usar los KPI para comprender que no tiene sentido buscar una solución tecnológica genial específica que queremos implementar porque el problema en sí no es crucial para el negocio.

¿Cómo medir el éxito?
Después de cambiar a métricas que son importantes para el negocio, la contraparte de mi producto y yo tuvimos que elegir un marco para medirlas. En Epsagon, usamos el marco OKR . No entraré en detalles, ya que hay muchos recursos excelentes para implementar los OKR disponibles en línea. La esencia es que este es un marco excelente para organizaciones medianas y grandes, generalmente en la fase posterior al ajuste del producto al mercado. Ayuda a alinear diferentes equipos, grupos y organizaciones dentro de la empresa hacia los mismos objetivos basados en resultados.
En Epsagon, teníamos OKR para cada equipo de producto, y eran los objetivos de los ingenieros, el producto y las personas de diseño que formaban el equipo de producto. Una vez implementado, tuvimos una mejor colaboración entre el producto y la ingeniería. Menos discusiones sobre requisitos y más cooperación para resolver problemas. También notamos que el aumento de la autonomía causado por el establecimiento de objetivos sobre las tareas aumentó la innovación y la propiedad sobre los resultados. Los equipos establecieron la hoja de ruta y las soluciones provinieron tanto de la ingeniería como del producto.
La desventaja de esta metodología es que requiere un poco de esfuerzo en la implementación y también requiere que pueda establecer sus objetivos durante períodos de meses. Esto suele ser difícil para las pequeñas empresas emergentes, especialmente antes de que el producto encaje en el mercado. Para las etapas anteriores, está bien trabajar con una métrica principal y seguir siendo impulsado por un objetivo comercial mientras se mantiene lo suficientemente ágil como para cambiar sus objetivos y enfocarse en la granularidad de semanas o días.
Ya sea que su equipo sea grande o pequeño, tenga una misión o prioridades contrapuestas, siempre que mida lo que importa, tendrá más posibilidades de éxito. El "cómo" es solo una optimización.
La comunicación es clave
Una vez que establecemos los KPI comerciales, el siguiente paso es seguir adelante. En mi experiencia, hay dos aspectos críticos para comunicar e implementar este cambio. El primero es la consistencia: no es suficiente establecer esas métricas y revisarlas tres meses después para descubrir que no alcanzamos nuestras metas. Como líderes, es nuestro trabajo monitorear constantemente estas métricas y asegurarnos de que su estado y hoja de ruta para mejorarlas siempre se comuniquen a todo nuestro equipo.
El segundo aspecto es el compromiso: es tentador volver a los viejos hábitos de medir a las personas utilizando métricas de desarrollo para optimizarlas. Esto enviará un mensaje equivocado a su equipo, insinuando que si bien dice que le importan los KPI comerciales, lo que realmente le importa son las métricas de desarrollo. Asegúrese de cambiar sus hábitos para reflejar sus prioridades: celebre los resultados comerciales, elimine las funciones que no son imprescindibles en lugar de forzar los plazos y encienda las alarmas cuando los KPI comerciales estén bajos. Todavía puede usar métricas de desarrollo como indicadores; solo recuerde vincularlos con su efecto en los KPI comerciales.

¿Están obsoletas las métricas de desarrollo?
A pesar del título de cebo de clics de este artículo, la respuesta es no, solo deben usarse correctamente. Por un lado, las métricas de desarrollo son herramientas poderosas para solucionar problemas con las métricas de su negocio. Por ejemplo, una disminución en la retención de usuarios puede explicarse por un aumento en el número de defectos. En este caso, puede usar la métrica de desarrollo como indicador principal: en lugar de esperar a que disminuya la retención, debe monitorear el recuento de defectos para evitar que disminuya (similar a cómo monitorearía el uso de la CPU para evitar el recuento de errores de API 5xx). de aumentar y causar daño real a sus usuarios). Otro caso de uso son las métricas de desarrollo como un indicador principal de la experiencia y satisfacción del desarrollador (que, a su vez, afecta la retención del desarrollador).
Sin embargo, lo más importante que debe recordar es que nunca debe optimizar las métricas de desarrollo. Siempre debe optimizar las métricas comerciales y usar la optimización de las métricas de desarrollo solo como una herramienta para alcanzar ese objetivo. Y, por supuesto, solo debe establecer, rastrear u optimizar los objetivos de métricas de desarrollo después de tener una idea clara del resultado comercial que está tratando de lograr y los KPI comerciales que está tratando de alcanzar. Las grandes estadísticas de ingeniería no salvarán su proyecto si no tiene valor.
¿Que sigue?
Si lidera una organización de ingeniería, cambiar a optimizar los resultados comerciales sobre las métricas de desarrollo mejorará las posibilidades de su equipo de crear un impacto real para el negocio. Si está comprometido a convertirse en un líder orientado a los resultados, le insto a que se haga estas preguntas:
- ¿Sé qué resultados comerciales se esperan de mí?
- ¿Estoy haciendo todo lo posible para optimizar estos resultados?
- ¿Cómo estoy rastreando el éxito? ¿Cuáles son los criterios para levantar una bandera o cambiar mis planes?
- ¿Mi equipo conoce los objetivos comerciales y la hoja de ruta para alcanzarlos? ¿Cuál es su aporte al respecto?
- ¿Cuál de mis KPI comerciales se puede mejorar al mejorar qué métricas de desarrollo?