Esta semana, la dirección ejecutiva me encargó que elaborara algunos KPI (indicadores clave de rendimiento) anuales para nuestro equipo de desarrollo para finales de mes. También quieren que los desarrolladores individuales establezcan sus propios KPI personales.
¿Tiene alguna sugerencia de KPI útiles para un equipo formado principalmente por desarrolladores de Rails?
Estoy pensando en cosas como las métricas de calidad del código que ves en los repositorios de Github. Al mismo tiempo, tengo algunas reservas.
Durante el último año, en ausencia de KPI, nuestro equipo ha trabajado con éxito para perfeccionar nuestras prácticas de desarrollo, acelerar la entrega y mejorar la calidad de nuestras aplicaciones, y desarrollar un verdadero espíritu de equipo . Me preocupa que esto interfiera con eso y (para citar un nuevo término que encontré recientemente) se encuentre con la Ley de Goodhart .
En mi investigación preliminar, también encontré esta línea citable sobre el tema:
Si alguna vez hubo una forma determinada de matar la moral en una startup, fue introduciendo KPI y llamándolos KPI.
Seguimos siendo una empresa relativamente pequeña y joven con lo que nos gusta pensar que es un ambiente de inicio.
Estoy preparado para rechazar la iniciativa. Pero pensé que debería darle a la idea una audiencia justa. Enlaces, sugerencias, argumentos en contra de la idea general son bienvenidos. ¡Gracias!
En mi experiencia, su intuición sobre los KPI es acertada. Matará la moral y te perderán el respeto profesionalmente. Parece que la gerencia quiere convertir un ambiente de trabajo atractivo y de poca rotación en un infierno burocrático que chupa el alma.
He pasado por 2 de estos yo mismo. Siempre termina con todos sus tops saliendo dentro de 2 años y eventualmente dejándolo con un montón de personas que aguantarán los KPI porque tienen dificultades para encontrar otros trabajos. Además, incluso los desarrolladores mediocres son lo suficientemente inteligentes como para jugar con cualquier sistema con el que intentes administrarlos. En mi experiencia, esto sucede a menudo después de una adquisición de la nueva empresa matriz o un nuevo equipo ejecutivo.
Dice el adagio que "administrar desarrolladores es como pastorear gatos". Mi mejor consejo al respecto es darles la propiedad y la responsabilidad de un dominio, y orientación sobre cómo priorizar las solicitudes. Sus tops pueden autogestionarse (y probablemente lo prefieran), mientras que sus niveles medio y de entrada pueden necesitar más orientación, pero los KPI no son la respuesta. Esas son cosas del centro de llamadas. Los desarrolladores son creativos. También son buenos en matemáticas, que es un par de rasgos muy raros. Lo peor que puede hacer es administrarlos como un reloj en los trabajadores.
Si es absolutamente necesario medir algo, seleccione algo que a la empresa realmente le deba importar, como el recuento de errores nuevos o la proporción de errores a funciones nuevas.
Durante el último año, en ausencia de KPI, nuestro equipo ha trabajado con éxito para perfeccionar nuestras prácticas de desarrollo, acelerar la entrega y mejorar la calidad de nuestras aplicaciones, y desarrollar un verdadero espíritu de equipo.
Has encontrado algo que funciona para tu equipo. Sigue haciendo eso hasta que no lo haga.
If we are delivering results in a timely manner, why would we need to measure it?¿Entiende cómo se va a utilizar esta información? ¿Los objetivos inmediatos y a largo plazo de la alta dirección? Esta comprensión básica debería ayudarlo a determinar qué métricas monitorear y cómo informarlas.
Por ejemplo, si la gerencia ejecutiva está interesada en el desempeño general del departamento, puede informar la información de tal manera que evite señalar a una sola persona del equipo. Si este es el objetivo, es mucho más probable que obtenga la aceptación de los miembros individuales del equipo.
Sin embargo, si esta información se utilizará a nivel individual en las revisiones de desempeño, para determinar el avance, la compensación o el posible despido; entonces se convierte en una venta mucho más difícil para el equipo.
Dicho esto, las métricas individuales son importantes y pueden ser muy valiosas si se usan correctamente; así que deberías coleccionarlos. Pero en mi experiencia, las métricas de un individuo deben tratarse como confidenciales al igual que el pago, las revisiones de desempeño y los archivos de recursos humanos.
Si bien soy un firme defensor del uso de métricas y KPI para los equipos de desarrollo, hay muchas advertencias que a menudo se pasan por alto. Como resultado, los KPI, independientemente de la métrica que midan, tienden a tomarse como 'oro' cuando, de hecho, son medidas derivadas e inventadas que se ven directamente afectadas por fuerzas externas que a menudo no se miden ni se entienden.
En términos más simples en un entorno de fabricación, si sé que una máquina determinada puede producir 1000 widgets en una hora, esa es una medida concreta y discreta. Hay 1000 tareas repetibles que son exactamente como la tarea anterior. Cada uno un duplicado de los demás.
La conclusión es que el desarrollo de software nunca ha sido una duplicación y replicación exacta de tareas anteriores. Cada tarea, requisito, desarrollador, recurso de control de calidad; casi todos los aspectos varían de una tarea a otra. Tratar las métricas como "talladas en piedra" es como comparar manzanas con naranjas.
romano
teego1967