Errores que se cometen al medir la productividad de los desarrolladores

• Errores que se cometen con frecuencia al medir la productividad de los desarrolladores
• Problemas al medir los insumos
  • Depender de insumos o del esfuerzo, como las ‘horas de trabajo’, fomenta comportamientos equivocados
  • Por ejemplo, si la cultura de una empresa valora y recompensa el tiempo pasado frente a la pantalla, los desarrolladores pueden volcar su tiempo en eso, pero es difícil garantizar la calidad del trabajo
  • En entornos más tóxicos, esto puede degenerar en una competencia por ‘llegar más temprano y salir más tarde que todos’
• Problemas al medir los resultados
  • Los peores indicadores, como las líneas de código o la cantidad de commits, pertenecen a esta categoría
  • Los desarrolladores pueden escribir grandes volúmenes de líneas de código muy rápido, así que medir eso es fácil
  • Todos los indicadores de resultados deben entenderse según el contexto
• Problemas al medir resultados e impacto
  • El reto de estos dos indicadores es determinar ‘cuánta responsabilidad tiene el equipo de DevOps’
  • Al medir el aumento de ingresos del negocio, es imposible atribuirlo únicamente a la responsabilidad de los desarrolladores

[yangeok]

Qué fuerte. Creo que puede haber una diferencia entre la perspectiva del gerente y la de quienes están en la operación diaria,,

[nullvana]

Parece justo la parte donde se necesita un LLM.

[savvykang]

Como el texto no propone una alternativa, hay un aspecto en el que se diluye el sentido que intenta transmitir. Estoy de acuerdo con la afirmación de que la cantidad de entregables debe excluirse de la medición de resultados, pero no puedo estar de acuerdo con que las horas de trabajo deban excluirse por completo de la medición de insumos, porque eso no encaja con la realidad. Sea como sea, mientras se realiza trabajo del conocimiento el tiempo transcurre, así que creo que el tiempo necesariamente debe considerarse en la toma de decisiones.

Pienso que es más fácil de entender y más eficiente hablar de la productividad de los desarrolladores después de medir indicadores adelantados como progreso total = (número de requisitos cumplidos / horas de trabajo)

[wonderer]

Últimamente tiendo a ver este tipo de textos de forma algo crítica, porque creo que la conclusión a la que termina llegando la gente después de leerlos es elegir no gestionar nada en absoluto. No importa con qué métrica se gestione, al final surgen problemas parecidos. Además, cuando una métrica se utiliza para la competencia o la comparación entre personas o equipos, aparecen efectos secundarios. Por eso, no se debe gestionar solo con una métrica; es necesario gestionar en conjunto métricas complementarias entre sí, y creo que deben usarse para ayudar a que el equipo mejore por sí mismo.

[vbmania]

¿Qué opinan de medirlo por la cantidad de PR de unidades significativas que se suben?

[nin12]

De hecho, en una gran empresa nacional miden el desempeño por la cantidad de líneas de código escritas, buaa buaa

[sexycode]

Jaja, yo también lo he visto.
Se la pasaba subiendo commits en los que cambiaba el nombre de las variables... jaja

[wonderer]

Supongo que es un entorno donde no se hacen revisiones de código, ¿no?

[sexycode]

Jaja, es que los revisores de código también tienen que pasar por revisión de código.
Se están ayudando mutuamente...

[ddaemiri]

jajajaja ay Dios...

[bichi]

hello hell world ;)

[neidn]

¿Es esta la famosa medición de productividad por LOC de la que tanto se habla? temblor temblor temblor