Der Projektmanager verschickt jeden Monat die Statistiken über die Arbeitsstunden, Fehlerbehebungsraten, ist das typisch?

In einigen Ländern könnte dies ohne die Zustimmung der Gewerkschaften sogar illegal sein, daher ist es sehr wichtig, wo Sie sich befinden.

Aber abgesehen vom rechtlichen Aspekt: ​​Dies kann zu unerwünschten Konsequenzen führen:

• Menschen, die zu viel arbeiten und ausbrennen
• Menschen, die so viel Angst davor haben, Fehler zu begehen, dass sie davon abgehalten werden, etwas anderes als das Nötigste zu tun
• die Atmosphäre im Team ruinieren.

Diese Art von Statistiken sind normalerweise ein Warnzeichen dafür, dass ein Softwarepaket stagniert und stirbt. Die anderen 2 Antworten haben viel abgedeckt, aber ich werde ein paar Dinge hinzufügen:

Produktive Entwickler machen Fehler, schlechte Entwickler haben noch nie welche gemacht:

• „Move fast and break things“ hat eine höhere Obergrenze für Produktivität und Forschung. Sie kommen in Ihrem Bereich schneller voran und sind die Ersten, die andere vermarkten. Wenn Sie Angst haben, Dinge kaputt zu machen, werden Ihre Produkte stagnieren.
• Experimentelle neue Funktionen werden niemandem "gehören", da sie befürchten, mit den Fehlern in Verbindung gebracht zu werden, die aus dem aufregenden neuen Bereich stammen.
• Ihre Entwickler lernen aus Fehlern schneller als auf andere Weise. Ein Entwickler, der so vorsichtig ist, dass er keine Fehler macht, lernt nicht annähernd so schnell wie einer, der es versucht, scheitert und wieder aufsteht.
• Wenn Ihr Endziel hochfunktionale, sehr hoch (aber nicht perfekt) zuverlässige Software ist, werden Sie meiner eigenen Erfahrung nach viel langsamer ankommen, wenn Sie beim ersten Mal sorgfältig perfekten Code schreiben, als wenn Sie mittelmäßigen Code schneller schreiben und testen lassen. (Mit "perfekt" zuverlässig meine ich Militär- oder Luft- und Raumfahrtanwendungen - kann keinen Heap-Speicher verwenden, da der Allocator irgendwie zuverlässig ausfallen könnte.)
• Entwickler, die sich mit Codebasis-weiten Refactorings beschäftigen, werden die letzten sein, die jedes Stück Code anfassen, das einen Fehler enthält. Dieses Verhalten wird bestraft, was von überfälligen Refactoring-Arbeiten abhält.

Ja, schlechtes Management ist typisch.

Die hier offensichtliche Kernphilosophie ist etwas, das als „Theorie X“-Management bezeichnet wird. Dh die Entwickler sind faul und machen möglichst keine Arbeit, also müssen sie sehr genau und öffentlich überwacht werden.

Ich sage nicht, dass ein autoritärer Ansatz mit geringem Vertrauen in keiner Branche funktioniert. Aber zumindest in der Software kann man sich nicht zu guten Ergebnissen schikanieren und beschämen. Es ist ein so komplexes Feld, dass man sich zumindest ein bisschen darum kümmern muss. Wenn also die Theorie-X-ler recht haben und die Entwickler alle faul sind, ist es schon geschissen. Und wenn Entwickler tatsächlich selbstmotivierte Menschen sind, die dem Unternehmen helfen möchten, seine Ziele zu erreichen, ist es keine gute Möglichkeit, sie offen respektlos zu behandeln, um sie so zu halten.

Abgesehen von Theorie X, was ist, wenn es diesem Manager gelingt, die Entwickler dazu zu zwingen, genau das zu tun, worum sie gebeten werden? Das wäre immer noch ein schlechtes Ergebnis. Metriken sind nur enge Messungen der Welt und alle haben perverse Ergebnisse. Sie können gespielt werden. Normalerweise haben die Menschen den guten Willen, dies nicht zu tun, im Gegenzug dafür, dass ihre Arbeit auf eine Weise beurteilt wird, die mehr als nur Messungen berücksichtigt. In diesem Fall ist der Preis für schlechte Zahlen eine öffentliche Schande, daher gibt es hier meiner Meinung nach keinen Grund für guten Willen.

Sie haben vielleicht bemerkt, dass das, was das Spielen von Statistiken erzwingt, dies auch zum Gegenteil eines psychologisch sicheren oder gesunden Arbeitsplatzes macht.

Aber tatsächlich sind in diesem Fall die Metriken nicht nur fehlerhaft. Sie sind Müll. Offensichtlich war der Manager zu sehr damit beschäftigt, über detaillierte Wege nachzudenken, um die Entwickler zu überwachen, dass er vergaß, ihnen überhaupt einen Bezug zum tatsächlichen Geschäftswert zu geben. Es braucht also nicht viel Nachdenken, um zu sehen, wo sich die beiden unterscheiden können. Warum sollten Sie zum Beispiel einen wichtigen Fehler beheben, wenn Sie 10 sinnlose beheben könnten? Warum sollten Sie einen wichtigen schnell reparieren, wenn er kleinere Defekte verursachen könnte? Warum würden Sie einen Teamkollegen betreuen? Warum sollten Sie einem Teamkollegen überhaupt helfen, wenn dies Ihre persönliche Produktivität beeinträchtigt? Warum sollten Sie etwas tun, das die Entwicklung in Zukunft besser oder schneller macht, wenn es Sie jetzt ausbremst? Warum sollten Sie etwas Kreatives oder Riskantes tun, wenn es Sie verlangsamt oder Fehler riskiert? Andere Antworten fügen dieser Liste bereits viel mehr hinzu.

Sobald Sie diese Zahlen veröffentlicht haben, werden sich die Entwickler mit anderen vergleichen, auch wenn das Management die Entwickler nicht aktiv auf der Grundlage dieser Zahlen belohnt/bestraft. Sie werden versuchen, sich als jemand zu etablieren, der eine geringe Anzahl von Fehlern produziert. Während der PM wahrscheinlich genau darauf hofft, hat es eine Reihe unerwünschter Nebenwirkungen, von denen einige bereits in den anderen Antworten angesprochen wurden.

• Entwickler können argumentieren, warum ein Fehler nicht von ihnen verursacht wurde, sondern von jemand anderem, der ein anderes Stück Code berührt oder ihnen unvollständige Informationen gegeben hat. Sie können sogar richtig sein. Diese Art von Schuldzuweisungen kann schnell die Atmosphäre vergiften, nicht nur innerhalb eines Teams, sondern auch zwischen verschiedenen Teams. Wo die teamübergreifende Zusammenarbeit die Anzahl der Fehler tatsächlich reduzieren könnte, kann diese Initiative den gegenteiligen Effekt haben, sie noch weiter zu isolieren.
• Es kann auch Zeitverschwendung sein, darüber zu diskutieren, ob ein gemeldetes Ticket als Fehler oder als Änderungsanforderung eingestuft werden soll, wenn der Kunde nur möchte, dass die App wie gewünscht funktioniert.
• „Nicht mein Code“-Syndrom . Anstatt einen gemeinsamen Codebesitz zu etablieren, könnte dies dazu führen, dass Entwickler nicht bereit sind, den Code eines anderen Entwicklers anzufassen (z. B. aushelfen, wenn ein Kollege krank ist), sowohl weil sie am Ende für bereits vorhandene Fehler verantwortlich gemacht werden könnten, als auch weil sie mehr sind wahrscheinlich Fehler einführen als ihr abwesender Kollege.
• Defekte verstecken . Meistens ist ein Entwickler die erste Person, die bemerkt, wenn etwas mit seinem Code nicht stimmt. Der übliche Prozess besteht darin, ihn als Fehler zu melden, ihn zu beheben und ihn von der QA überprüfen zu lassen. Wenn das Erstellen von Fehlerberichten bestraft wird, zieht es ein Entwickler möglicherweise vor, ruhig zu bleiben, bis er dazu kommt, das Problem heimlich zu beheben. Das kann die Fehlerbehebung verzögern. Schlimmer noch, das bedeutet, dass niemand nach unbeabsichtigten Nebenwirkungen der fraglichen Fehlerbehebung suchen wird.
• Entwickler als überteuerte Tester . Entwickler werden dazu animiert, jeden Commit zu überprüfen. Das ist vielleicht nicht ganz schlecht, aber bei Problemen mit niedriger Priorität kann es kostspieliger sein, als einfach die Fehler von der QA melden zu lassen.

Es gibt ein Sprichwort, das ich vor vielen Jahren gelernt habe:

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. 

Auch als Gesetz der unbeabsichtigten Folgen bekannt. Wenn ich als Softwareentwickler ein Feature entwickle, gibt es einen Punkt, an dem es als nicht fertig und daher sehr fehlerhaft gilt. Dann kommt ein Punkt, an dem alles fertig ist, aber es gibt noch jede Menge Bugs. Dann reduziere ich die Anzahl der Fehler, dann reduziere ich sie noch weiter auf null.

Während ich die Anzahl der Bugs reduziere, übernehme ich im Grunde die Arbeit der QA – außer dass es ineffizient ist, ihnen Code zu geben, der voller Bugs ist. Effizient wird es, wenn die Anzahl der Fehler so gering ist, dass die Übergabe an die QA besser ist, als selbst nach Fehlern zu suchen. Wenn ich vor der Übergabe alle Fehler finde und behebe , ist das eigentlich ineffizient, weil sie besser darin sind, Fehler zu finden. Wenn ich jetzt nach der Anzahl der Fehler beurteilt werde, die ich produziere, ändert sich die Gleichung für mich. Ineffiziente Arbeit zu leisten, bringt für mich ein besseres Ergebnis. Also raten Sie mal, was ich tun werde.

Es gibt viele Geschichten, in denen QA und Entwickler nach „Anzahl der gefundenen Fehler“ und „Anzahl der behobenen Fehler“ beurteilt wurden. Offensichtlich würde ein Entwickler einen Fehler absichtlich hinzufügen, der QA mitteilen, wo er ist, und wenn die QA den Fehler findet und meldet, ihn in zwei Minuten beheben. Win/Win für zwei Mitarbeiter auf Kosten des Unternehmens.