El administrador del proyecto envía las estadísticas sobre las horas de trabajo, las tasas de corrección de errores todos los meses, ¿es normal?

En algunos países, esto podría incluso ser ilegal sin la aprobación de los sindicatos, por lo que importa mucho dónde se encuentre.

Pero dejando de lado el aspecto legal: esto puede llevar a consecuencias no deseadas:

• gente que trabaja demasiado y se quema
• personas temerosas de cometer errores en la medida en que les impida intentar hacer cualquier cosa menos lo mínimo
• arruinando el ambiente en el equipo.

Este tipo de estadísticas suelen ser una señal de advertencia de que un paquete de software se está estancando y muriendo. Las otras 2 respuestas han cubierto mucho, pero agregaré algunas cosas:

Los desarrolladores productivos cometen errores, los malos desarrolladores nunca han cometido ninguno:

• "Muévete rápido y rompe cosas" tiene un límite superior más alto para la productividad y la investigación. Avanzará más rápido en su campo y será el primero en comercializar en otros. Si tienes miedo de romper cosas, tus productos se estancarán.
• Las nuevas funciones experimentales no serán "propiedad" de alguien por temor a que se las asocie con los errores que provienen del nuevo y emocionante campo.
• Sus desarrolladores aprenden cometiendo errores más rápido que de cualquier otra manera. Un desarrollador que es tan cuidadoso que no comete errores no aprende tan rápido como uno que lo intenta, falla y se levanta de nuevo.
• En mi propia experiencia, si su objetivo final es un software confiable altamente funcional, muy alto (pero no perfecto), llegará mucho más lento escribiendo un código perfecto cuidadosamente la primera vez que escribiendo un código mediocre más rápido y haciéndolo probar. (Con confiabilidad "perfecta" me refiero a aplicaciones militares o aeroespaciales: no se puede usar la memoria de almacenamiento dinámico porque el asignador podría fallar de manera confiable)
• Los desarrolladores que se dedican a refactorizar toda la base del código serán las últimas personas en tocar cada fragmento de código que tenga un error. Estas conductas serán sancionadas, desalentando trabajos de refactorización atrasados.

Sí, la mala gestión es típica.

La filosofía central aparente aquí es algo llamado gestión de "teoría X". Es decir, los desarrolladores son perezosos y no harán ningún trabajo si es posible, por lo que deben ser monitoreados de manera muy precisa y pública.

No estoy diciendo que un enfoque autoritario y de baja confianza nunca funcione en ninguna industria. Pero al menos en el software, uno no puede acosar y avergonzar para obtener buenos resultados. Es un campo lo suficientemente complejo como para que uno necesite que la gente se preocupe al menos un poco. Entonces, si los teóricos tienen razón y los desarrolladores son flojos, ya está jodido. Y si los desarrolladores son, de hecho, personas motivadas deseosas de ayudar a la empresa a lograr sus objetivos, tratarlos de una manera abiertamente irrespetuosa no es una buena manera de mantenerlos así.

Dejando a un lado las cosas de la teoría X, ¿qué pasa si este gerente tiene éxito en obligar a los desarrolladores a hacer exactamente lo que se les pide que hagan? Eso seguiría siendo un mal resultado. Las métricas son solo medidas estrechas del mundo y todas ellas tienen resultados perversos. Se pueden jugar. Por lo general, las personas tienen la buena voluntad de no hacerlo, a cambio de ser juzgados por su trabajo de una manera que tiene en cuenta más que solo mediciones. En este caso, el precio de los malos números es una vergüenza pública, por lo que no creo que haya ninguna razón para la buena voluntad aquí.

Es posible que haya notado que lo que obliga a jugar con las estadísticas también hace que esto sea lo opuesto a un lugar de trabajo psicológicamente seguro o saludable.

Pero, de hecho, en este caso las métricas no solo son defectuosas. son basura Claramente, el gerente estaba demasiado ocupado pensando en formas detalladas de vigilar a los desarrolladores que se olvidaron de darles alguna relación con el valor comercial real. Por lo tanto, no se necesita una gran cantidad de pensamiento para ver dónde pueden diferir los dos. Por ejemplo, ¿por qué corregiría un error importante cuando podría corregir 10 sin sentido? ¿Por qué arreglaría uno importante rápidamente cuando podría causar defectos menores? ¿Por qué serías el mentor de un compañero de equipo? ¿Por qué incluso ayudaría a un compañero de equipo si dañara su productividad personal? ¿Por qué haría algo que mejorara o acelerara el desarrollo en el futuro si ahora lo ralentiza? ¿Por qué haría algo creativo o arriesgado si lo ralentiza o corre el riesgo de fallar? Otras respuestas ya agregan mucho más a esta lista.

Una vez que publique estos números, incluso si la gerencia no recompensa/castiga activamente a los desarrolladores en función de estos números, los desarrolladores se compararán con otros. Van a tratar de establecerse como alguien que produce un bajo número de defectos. Si bien eso es probablemente exactamente lo que espera el PM, tiene una serie de efectos secundarios indeseables, algunos de los cuales ya se mencionaron en las otras respuestas.

• Los desarrolladores pueden argumentar por qué un error no fue causado por ellos sino por otra persona que tocó otra pieza de código o que les dio información incompleta. Incluso pueden ser correctos. Este tipo de "juego de culpas " puede envenenar rápidamente la atmósfera, no solo dentro de un equipo determinado, sino también entre diferentes equipos. Donde la colaboración entre equipos en realidad podría reducir la cantidad de errores, esta iniciativa puede tener el efecto opuesto de aislarlos aún más.
• También puede ser una pérdida de tiempo discutir si un ticket informado debe clasificarse como un error o una solicitud de cambio cuando todo lo que el cliente quiere es que la aplicación funcione como lo solicitó.
• Síndrome de "no es mi código" . En lugar de establecer una propiedad de código compartida, esto podría llevar a que los desarrolladores no estén dispuestos a tocar el código de otro desarrollador (por ejemplo, ayudar cuando un colega está enfermo), porque podrían terminar siendo culpados por errores preexistentes y porque son más propensos a introducir errores que su colega ausente.
• Ocultar defectos . Muchas veces, un desarrollador será la primera persona que se dé cuenta cuando algo esté mal con su código. El proceso habitual es informarlo como un error, corregirlo y hacer que el control de calidad verifique la corrección. Si se penaliza la creación de informes de errores, es posible que un desarrollador prefiera permanecer en silencio hasta que lo arregle en secreto. Eso puede retrasar la corrección del error. Peor aún, eso significa que nadie verificará los efectos secundarios no deseados de la corrección de errores en cuestión.
• Desarrolladores como probadores caros . Se incentiva a los desarrolladores para que verifiquen dos veces cada compromiso. Esto puede no ser del todo malo, pero para problemas de baja prioridad puede ser más costoso que simplemente hacer que el control de calidad informe los errores.

Hay un dicho que aprendí hace muchos años:

If you work a lot, you make a lot of mistakes.
If you work less, you make fewer mistakes.
If you don't work at all, you make no mistakes. 
If you make no mistakes, you get promoted. 

También conocida como la ley de las consecuencias no deseadas. Como desarrollador de software, cuando desarrollo una característica, hay un punto en el que no se considera terminado, por lo tanto, tiene muchos errores. Luego llega un punto en el que todo está terminado, pero todavía hay muchos errores. Luego reduzco el número de errores, luego los reduzco aún más a cero.

Mientras reduzco la cantidad de errores, básicamente hago el trabajo de control de calidad, excepto que entregarles un código que está lleno de errores es ineficiente. Se vuelve eficiente cuando el número de errores es tan bajo que entregarlo al control de calidad es mejor que buscar los errores yo mismo. Si encuentro y soluciono todos los errores antes de entregar, eso es realmente ineficiente, porque son mejores para encontrar errores. Ahora bien, si soy juzgado por la cantidad de errores que produzco, la ecuación cambia para mí. Hacer un trabajo ineficiente me da un mejor resultado. Así que adivina lo que haré.

Hay muchas historias en las que se juzgó a los desarrolladores y al control de calidad según la "cantidad de errores encontrados" y la "cantidad de errores corregidos". Es obvio que un desarrollador agregaría un error intencionalmente, le diría a QA dónde está y, cuando QA encuentre e informe el error, lo solucione en dos minutos. Ganar/ganar para dos empleados a expensas de la empresa.