¿Hay herramientas decentes disponibles para medir el desempeño de los empleados desarrolladores de software? Tal vez algo con un sistema de recompensa incorporado? (Gamificación)

Experimentamos mucho este concepto en Espeo Software. Incluso comencé una plataforma personalizada para la gamificación (GetBadges – plataforma de gamificación para desarrolladores de software). Resulta que las estadísticas más importantes para medir son la satisfacción del cliente (si externaliza a los desarrolladores a los clientes) y las revisiones de código (en términos de calidad). Ninguna medición de rendimiento individual es perfecta, pero las reseñas de los clientes y otros desarrolladores le brindan la mayor cantidad de ideas sobre la calidad de su trabajo.

También hay algunas medidas más directas que puede ver (prefiera más confirmaciones pequeñas, ya que son más fáciles de entender y deshacer, los buenos desarrolladores generalmente no vuelven a abrir sus tickets por QA a menudo, la construcción suele ser más estable cuando los desarrolladores se preocupan por su proceso de liberación).

Considere el factor humano, no lo convierta en una carrera de la muerte y recuerde que una buena gamificación debería ser una opción para aquellos desarrolladores que no les gusta jugar.

Hay 2 problemas con esta pregunta:

1. Se basa en la desconfianza de los empleados y la necesidad de controlar la producción de las personas. Este es un claro ejemplo de sistemas push. Los métodos de gestión modernos deberían centrarse en los resultados y permitir que las personas tomen el trabajo.
2. En segundo lugar, cuando nos enfocamos en el desempeño de los individuos, con o sin gamificación, conduciremos el comportamiento incorrecto. También obtendremos una imagen falsa. Si tomamos los 5 mejores artistas y sacamos el resto, ¿tendremos el sistema más efectivo? En lugar de enfocarse en el desempeño individual, enfóquese en construir los equipos más efectivos. Queremos que las personas sean recompensadas por colaborar y cultivar el conocimiento. No por mantener sus cartas cerca de su cofre.

Cuanto mejor obtengo, menos líneas de código escribo.

La contribución más beneficiosa que puede hacer un desarrollador es eliminar líneas de código seleccionando las arquitecturas y diseños correctos. Mi sólida experiencia es que pasar un 10% más de tiempo considerando el código que vas a escribir y las alternativas cosechan dividendos al menos un orden de magnitud mayor que aumentar la cantidad de líneas de código que escribes en un 10%.

De hecho, iría tan lejos como para decir que hay una relación inversa: esas líneas de código adicionales del 10% que resultan de pasar más rápido del análisis y el diseño a la codificación tienen un valor negativo. Lo digo desde la perspectiva del costo del software heredado. En primer lugar, solo un componente relativamente menor del costo de una línea de software es el costo de escribirlo. La mayor parte del costo está en el mantenimiento, la depuración, el análisis y el aumento de la complejidad.

Por lo tanto, es probable que cualquier métrica que recompense en función de las líneas de código escritas produzca un efecto inverso al deseado. Obtendrá más líneas de código, pero menos productividad.

Entonces hay dos problemas con esto:

1. Cualquier desarrollador de software que valga la pena es realmente bueno en las métricas de juego. Básicamente, lo que termina es cambiar su comportamiento para que la métrica sea mejor, no necesariamente el producto.
2. La actividad no es necesariamente igual a la productividad.

Dicho esto, qué se puede hacer para medir si son productivos. Es enfocarse en las diferentes partes que se necesitan y ver en cuáles se destacan. Algunos desarrolladores cambian las funciones más rápido, así que asegurémonos de que sus errores sean bajos y que a sus compañeros de trabajo no les resulte imposible seguir su código. Si esas condiciones coinciden, entonces él es un miembro productivo del equipo.

Hay mucho sobre este tema en torno a mi publicación favorita:
bliki: CannotMeasureProductivity

No bajes por esa madriguera de conejo. Cada herramienta tiene lagunas y no hará felices a sus ingenieros. ¿Por qué no hablas con tus desarrolladores y discutes objetivos específicos y entregables para el final del año / trimestre?