A los desarrolladores de software con talento les molesta la idea de ser controlados de forma exhaustiva. He aquí siete maneras de alinear los equipos de desarrollo y los objetivos del negocio sin hacer que los programadores se sientan incómodos.
Me han preguntado varias veces este año sobre la medición de la productividad, la calidad y los resultados de los desarrolladores de software, especialmente cuando el liderazgo promueve modelos de trabajo híbridos.
Pero esta es la realidad a la que se enfrentan las organizaciones tecnológicas cuando es difícil contratar y retener a grandes desarrolladores de software: a los desarrolladores de software con talento les molesta la idea de ser controlados de forma exhaustiva y muchos dejarán los trabajos en los que haya una cultura de microgestión.
Pedir a un desarrollador que se ponga a las órdenes de un director sin experiencia en el desarrollo de software puede despertar el temor a la burocracia de los procesos.
Algunos desarrolladores de software ágiles, que abrazan los extremos de los principios de autoorganización, quieren una autonomía total y pueden rebelarse ante cualquier señal de intentos de liderazgo para medir la productividad, la calidad u otras consideraciones de rendimiento.
Si los desarrolladores de software detestan la microgestión, muchos tienen un mayor desprecio por las revisiones de rendimiento anuales. Los desarrolladores se fijan objetivos de rendimiento en tiempo real y pretenden mejorar la velocidad, la frecuencia de despliegue de código, los tiempos de ciclo y otros indicadores clave de rendimiento.
Los equipos de Scrum discuten su rendimiento al final de cada sprint, por lo que los comentarios de las revisiones de rendimiento anuales y trimestrales pueden parecer superfluos o irrelevantes.
Pero también existe la realidad práctica de que las organizaciones requieren métodos para reconocer si los equipos ágiles y los desarrolladores de software cumplen o superan los objetivos de rendimiento, desarrollo y negocio. ¿Cómo pueden los gerentes obtener lo que necesitan sin hacer que los programadores se sientan incómodos?
Lo que sigue son siete prácticas recomendadas que se alinean con los principios de agilidad, scrum, devops y el ciclo de vida del desarrollo de software y que podrían aplicarse a la revisión de los desarrolladores de software. No las escribo como objetivos SMART (específicos, medibles, alcanzables, relevantes y limitados en el tiempo), pero los líderes deberían adoptar los relevantes como tales, en función de la forma de trabajo ágil de la organización y los objetivos de negocio.
Algunos de ellos sólo pueden ser relevantes a nivel de equipo, mientras que los directivos podrían utilizar otros para medir a sus subordinados directos.
Definir objetivos y resultados clave que estén alineados con los objetivos empresariales y técnicos
La definición de objetivos y resultados clave (OKR) es un debate que los propietarios de productos, los directores de desarrollo y los arquitectos pueden mantener con sus equipos para alinearse con los criterios de éxito medibles. Lo ideal es una colaboración entre los líderes y el equipo, en la que los líderes definen el objetivo y todo el equipo discute, debate y decide los resultados clave.Una de las mejores prácticas es definir los OKR con una cadencia significativa. Si es demasiado frecuente, la sobrecarga de definir y medir los OKR puede ser costosa; si es demasiado infrecuente, los equipos pueden perder de vista los objetivos. Dos ejemplos:
El objetivo de “mejorar la fiabilidad de la aplicación” puede incluir resultados como la reducción del tiempo de respuesta de la página, la mejora de la disponibilidad de la app o la reducción de las tasas de error en un porcentaje significativo.
El objetivo de “mejorar la fiabilidad del despliegue” puede incluir resultados como el aumento de la automatización de las pruebas o la reducción del tiempo de construcción en porcentajes significativos.
Cumplir con los compromisos de sprint y lanzamiento de forma consistente
Scrum se ejecuta sobre una base de cadencias y el cumplimiento de los compromisos, por lo que el cumplimiento de los plazos es una forma de medir la disciplina de un equipo y la alineación con las normas. No espero que los equipos cumplan perfectamente con los compromisos de cada sprint, pero los líderes pueden establecer una barra alta y baja de expectativas agregadas a través de varios sprints. Para los equipos que realizan lanzamientos en cadencias definidas (diariamente, semanalmente, cada cuatro sprints, etc.), recomiendo revisar si los equipos lanzan en el plazo previsto y cumplen con los puntos de referencia de calidad. Cumplir con la fecha de lanzamiento pero provocar cortes, incidentes de seguridad o problemas de producción significativos son problemas evidentes.
Conseguir que los propietarios del producto y las partes interesadas estén satisfechos
El manifiesto ágil identifica “la colaboración con el cliente por encima de la negociación del contrato” como un valor fundamental. Aunque no debemos exigir a los desarrolladores ágiles que realicen entregas impecables (en tiempo, alcance y costo, el proverbial triángulo de hierro), podemos intentar captar métricas independientes de satisfacción del cliente. Una encuesta de satisfacción es una herramienta que las grandes organizaciones de desarrollo pueden utilizar para captar la opinión de los desarrolladores y equipos ágiles. Algunas preguntas podrían cubrir:
La colaboración a la hora de plantear problemas y documentar soluciones.
Entrega en el ámbito y satisfacción de los resultados.
La calidad de la retroalimentación al planear y estimar las características.
La clave es hacer llegar los comentarios de los clientes a los desarrolladores y equipos ágiles para que puedan reflexionar sobre los resultados desde la perspectiva del cliente y mejorar el rendimiento.
Cuantificar las revisiones por pares del diseño, la documentación y la facilidad de uso
Pregunte a un desarrollador lo fácil que es utilizar las API de otro equipo, actualizar el código de otro desarrollador o aprender una nueva arquitectura de aplicación a partir de la documentación disponible. Desgraciadamente, es poco probable que obtenga una respuesta positiva o un desarrollador contento, sobre todo si trabaja con código heredado o en una arquitectura monolítica.
Entonces, ¿cómo determinar si los desarrolladores están haciendo un mejor trabajo hoy en día en el desarrollo de código mantenible, documentación útil y microservicios fáciles de consumir? ¿Cómo se puede medir este progreso o retroceso?
Aunque puede haber herramientas o análisis para obtener estas métricas, creo que el enfoque más sencillo es crear un proceso de revisión por pares. Los compañeros pueden comentar la legibilidad del código al revisar una solicitud de extracción, proporcionar calificaciones sobre la documentación y responder a las encuestas al integrar microservicios o API.
Las revisiones por pares deben complementar los comentarios de las herramientas de revisión de código y análisis de calidad que pueden proporcionar comentarios granulares en tiempo real sobre la calidad del código, la seguridad y los problemas relacionados.
Seleccione indicadores clave de rendimiento no negociables para devops
Los propietarios de los productos y los compañeros proporcionan información importante, pero los directores también deben asegurarse de que los desarrolladores y los equipos de desarrollo revisen y respondan a la información operativa. La retroalimentación debe incluir detalles sobre la ingeniería de fiabilidad del sitio, las prácticas de seguridad y la capacidad de respuesta a los incidentes, solicitudes y otros tickets de la gestión de servicios de TI (ITSM).
Los equipos de desarrollo, ITSM e infoseguridad tienen KPIs muy maduros, y los líderes deben seleccionar un número significativo y manejable para que los equipos de desarrollo de software se centren en ellos. Para los equipos de desarrollo que trabajan en aplicaciones nativas de la nube, recomiendo definir los objetivos de nivel de servicio y utilizarlos para gestionar los presupuestos de errores. Para otros grupos de desarrollo, la medición de las reducciones en las tasas de fracaso de los cambios y el tiempo medio de recuperación de los incidentes fueron los principales KPI en esta investigación.
Demostrar los impactos del aprendizaje, la experimentación y la tutoría
Hoy en día, más empresas reconocen la importancia de apoyar el aprendizaje continuo, promover entornos seguros para la experimentación e inscribir a los participantes en programas de tutoría. Si bien todos estos objetivos son importantes, los directivos deben revisar cómo los desarrolladores ponen en práctica estas directrices y en qué aspectos tienen impacto en el negocio. Los directivos deben ayudar a los desarrolladores a crear un plan de desarrollo profesional y proporcionarles información sobre cómo su aprendizaje, tutoría y participación en experimentos y pruebas de concepto se alinean con los objetivos profesionales del empleado.
Pedir a los desarrolladores que propongan metas y objetivos de la vida laboral
En el informe sobre el sentimiento de los tecnólogos de Dice 2021, el 36% de los encuestados calificó su agotamiento con un cuatro o un cinco en una escala de cinco puntos, y el 48% informó de que es probable que cambie de empleador.
No creo que los CIO, CTO, líderes de entrega y gerentes de desarrollo de software quieran ver a sus desarrolladores de software quemarse y unirse a la gran resignación. Así que, aunque sugiero varias formas de gestionar a los desarrolladores de software, los líderes deben ser empáticos con el entorno de trabajo actual y con la situación personal de cada desarrollador.
Una forma de lograr el equilibrio es trabajar con recursos humanos en la definición de metas y objetivos de la vida laboral. Los desarrolladores deben personalizar estos objetivos, y la organización y los directivos deben mantenerlos confidenciales. Un objetivo de vida laboral puede crear el equilibrio que muchos desarrolladores necesitan hoy en día para sentirse apoyados.
En última instancia, la gestión y la medición del rendimiento requieren conversaciones frecuentes entre el director y el empleado. ¿Estamos de acuerdo con los objetivos y los criterios de éxito? ¿Entendemos las normas y las limitaciones? Incluso cuando las métricas proporcionan indicadores, a menudo es la discusión y las acciones de seguimiento las que conducen a la mejora del rendimiento. Así es como trabaja la gente.
