it-swarm.com.de

Mein Chef hat beschlossen, jedem Fehlerbericht ein Feld "Schuldige" hinzuzufügen. Wie kann ich ihn davon überzeugen, dass es eine schlechte Idee ist?

In einem der neuesten "WTF" -Züge entschied mein Chef, dass das Hinzufügen eines "Person To Blame" -Felds zu unserer Fehlerverfolgungsvorlage die Rechenschaftspflicht erhöht (obwohl wir bereits eine Möglichkeit haben, Fehler mit Features/Storys zu verknüpfen). Meine Argumente, dass dies die Moral verringern, den Fingerzeig erhöhen und fehlende/missverstandene Funktionen, die als Fehler gemeldet wurden, nicht berücksichtigen würde, sind ungehört geblieben.

Was sind einige andere starke Argumente gegen diese Praxis, die ich verwenden kann? Gibt es zu diesem Thema etwas, das ich mit dem Team und dem Chef teilen kann?

700
MK_Dev

Sagen Sie ihnen, dass dies nur ein amateurhafter Name für das Feld Root Cause ist, das von Profis verwendet wird (wenn der Issue-Tracker kein dediziertes Feld hat, können Sie Kommentare dafür verwenden).

Durchsuchen Sie das Web nach etwas wie Ursachenanalyse für Softwarefehler, es gibt viele Ressourcen, um diese Argumentation zu rechtfertigen 1 , 2 , , 4 , ....


... eine Grundursache für einen Defekt ist nicht immer ein einzelner Entwickler (was der Hauptpunkt dieses Feldes ist) ...

Genau deshalb ist "Grundursache" professionell, während "Schuldige" amateurhaft ist. Persönliche Verantwortlichkeit ist großartig, aber es gibt Fälle, in denen sie einfach "außerhalb" des Entwicklerteams liegt.

Sagen Sie Ihrem Chef, wenn ein einzelner Entwickler schuld ist. Das Feld für die Grundursache wird diesen ( "- Codierungsfehler von Bob beim Festschreiben definitiv abdecken 1234, von Jim in der Rezension verpasst 567 "). Der Sinn der Verwendung des Begriffs Grundursache Besteht darin, solche Fälle zusammen mit mit Fällen abzudecken, die aus dem Umfang des Entwicklerteams.

Wenn der Fehler beispielsweise durch fehlerhafte Hardware verursacht wurde (wobei die schuldige Person jemand außerhalb des Teams ist, der ihn gekauft und getestet hat), können Sie ihn im Feld "Grundursache" abdecken, während "einzelner Entwickler schuld" einfach kaputt geht der Issue Tracking Flow.

Gleiches gilt für andere Fehler, die von Personen außerhalb des Entwicklerteams verursacht wurden - Testerfehler, Änderungen der Anforderungen und Managemententscheidungen. Wenn das Management beschließt, keine Investitionen in Disaster Recovery-Hardware zu tätigen, ist es einfach nicht sinnvoll, "einen einzelnen Entwickler für einen Stromausfall im Rechenzentrum verantwortlich zu machen".

675
gnat

Ein weiteres wahrscheinliches Ergebnis für eine solche Richtlinie ist, dass Personen keinen Fehler melden, wenn sie glauben, dass sie die "Schuldige" sind, sodass die Anzahl der vom Team gemeldeten Fehler tatsächlich verringert wird.

275

Das Hauptargument, das ich dagegen verwenden würde, ist zu fragen, welches Problem er zu lösen versucht. Es gibt mit ziemlicher Sicherheit bessere Möglichkeiten, das gleiche Problem zu lösen.

Gibt es zum einen wirklich immer nur eine Person, die schuld ist? Wenn ja, machen Sie etwas anderes falsch. Ein guter Prozess erfordert ein Stück Arbeit durch einen Analysten, einen Programmierer, einen Prüfer und einen Tester, bevor er zur Produktion kommt. Wenn Sie nicht alle diese Phasen ausführen, ist dies möglicherweise die Lösung für das Problem, das Ihr Chef zu lösen versucht. Wenn Sie dann sind, welche ist schuld? Es könnte keiner von ihnen sein, es könnte Legacy-Code sein, der schuld ist.

Es ist nicht gut, wenn Leute zurückbeißen und mit den Fingern zeigen und versuchen, eine schwarze Markierung zu vermeiden, die nicht verschwindet, wenn sie erst einmal gesetzt ist. Es löst nichts. Sehr wenige Menschen sind böswillig fahrlässig. Sie müssen eine richtige Retrospektive durchführen, um zu sehen, was schief gelaufen ist und was Sie tun können, um sicherzustellen, dass es nicht wieder schief geht.

Daraus wird deutlich, ob regelmäßig eine Person schuld ist, und dies kann ein anderes Problem sein.

Der Trick, um einen Manager daran zu hindern, Rechenschaftspflicht zu schaffen, besteht darin, frei anzubieten , aber auf eine Weise, die für Sie tatsächlich Sinn macht.

140
pdr

Es gibt mindestens drei Probleme mit diesem Feld.

Der erste ist, dass es nicht gut für die Moral ist, Menschen zu beschuldigen. OK. Aber vielleicht interessiert ihn die Moral nicht und er will schlechte Entwickler entlassen. Schwer zu argumentieren.

Das zweite ist, dass es schwierig sein wird, dieses Feld richtig zu machen, und dass es ziemlich viel Zeit kostet. Es ist komplexer als nur herauszufinden, wer den schlechten Code geschrieben hat. Und alle potenziellen Informationen, die schwer herauszufinden sind, können mit Sandsäcken/Betrug versehen werden. Aber vielleicht ist er bereit, diese Kosten zu bezahlen und die Informationen zu prüfen. Fein.

Das grundlegendere Problem ist, dass dieses Feld keine gute Messgröße für Maßnahmen sein wird. Sicher, er wird ein schönes Ranking haben, dessen Code die meisten Fehler verursacht. Aber raten Sie mal, wer ganz oben auf dieser Liste steht? Wahrscheinlich der Firmengründer oder vielleicht ein Top-Entwickler, der eine sehr niedrige Fehlerrate hat, aber so produktiv ist, dass er einen unverhältnismäßigen Teil des Codes schreibt. Also wird er entweder seinen besten Entwickler entlassen oder ihn so sehr verlangsamen lassen, dass er nicht mehr sein bester Entwickler ist. Und der Typ, der jeden Monat eine Codezeile schreibt - vorzugsweise Kommentare - wird wahrscheinlich für seine geringen Fehlerzahlen belohnt.

Noch ein Software-Metrikfehler.

78
ptyx

Die Hauptursache für einen Feldfehler ist niemals eine einzelne Person. Vollkommen gewissenhafte Menschen werden Fehler machen, und ein Prozess, der erwartet, dass sie unfehlbar sind, ist unvernünftig. Wenn Sie Änderungen an Produktionssystemen vor der Bereitstellung weder manuell noch durch automatisierte Tests überprüfen, sind Fehler unvermeidlich.

Falsch:

Bob vergaß die Eingabe zu überprüfen und das Programm stürzte ab, geteilt durch Null.

Recht:

Code, der für einen Fehler durch Teilen durch Null anfällig ist, wurde vor der Bereitstellung nicht erkannt. Neue Testfälle wurden hinzugefügt, um die ordnungsgemäße Behandlung ungültiger Eingaben zu überprüfen. Der Code wurde korrigiert und alle neuen Testfälle bestehen.

68
kevin cline

Ändern Sie "Person zu beschuldigen" in "Person zu loben"

Die Hauptperson, die die Fehler behebt, erhält ihren Namen.

53
Darknight

Einfache Antwort.

Das Feld "Schuld" wird nur für Sündenböcke und Fingerzeig verwendet, die Moral sinkt, das Teamvertrauen wird zerstört und jeder wird versuchen, Wege zu finden, um zu beweisen, dass etwas nicht seine Schuld ist, anstatt es zu reparieren. Die Leute werden auch eher dazu neigen, über Fehler zu schweigen, anstatt sie zu melden, weil sie nicht möchten, dass ein Kollege in Schwierigkeiten gerät. Es ist völlig kontraproduktiv.

Was ist wichtiger, jemanden für einen ehrlichen Fehler zu schikanieren oder das Problem so schnell wie möglich zu beheben?

Ihr Chef scheint zu glauben, dass Fehler ein Zeichen von Faulheit oder Schlamperei sind. Sie sind nicht. Sie sind eine Tatsache des Lebens. Wie viele Patches veröffentlicht Microsoft Push pro Jahr?

49
GordonM

Wenn Sie ein wenig zivilen Ungehorsam verspüren, lassen Sie das Team zustimmen, für jeden Fehler eine Liste aller Entwickler in diesem Bereich zu erstellen. Wenn das nicht passt, schreibe "Ich bin Spartacus!" stattdessen. Der Punkt ist natürlich, dass Sie alle für alle Fehler verantwortlich sind und nicht glücklich darüber sind, auf die Person hinweisen zu müssen, die einen Fehler verursacht hat.

Eine weitere Option: Mitspielen. Tun Sie nichts Besonderes - machen Sie einfach gute Arbeit und füllen Sie das Feld einige Monate lang so genau wie möglich aus. Erklären Sie dann dem Chef, dass die Zuweisung der Schuld für jeden Fehler alle im Team unglücklich und unangenehm macht. Sagen Sie ihm, dass Sie alle das Gefühl haben, dass es kaum einen Zusammenhang zwischen den verursachten Fehlern und allem anderen gibt (Geschicklichkeit, Anstrengung, Vernunft). (Es ist hilfreich, wenn Sie einige Zahlen eingeben können, die zeigen, dass es wirklich keine Korrelation gibt.)

Gandhian Civil Disobedience: Tragen Sie Ihren Namen in jedes Feld ein (es sei denn, andere Entwickler melden sich und geben ihren Namen für ihre Fehler an), und übernehmen Sie die Schuld für jeden Fehler, unabhängig davon, ob er Ihnen gehört oder nicht. Nichts wird dieses Feld oder die Idee, jemanden zu beschuldigen, nutzloser machen als dies. Wenn Ihr Chef fragt, warum Sie in jedem Bereich so heißen, können Sie erklären: "Weil ich nicht denke, dass Entwicklung ein Schuldspiel ist. Wenn Sie wirklich Leute brauchen, die Schuld und Kreuzigung geben, dann kreuzigen Sie mich für alles und lassen Sie mein Team friedlich arbeiten." . "

44
Caleb

Ich hatte einmal einen Chef, der ein System implementierte, das diesem sehr ähnlich war, und obwohl es nicht programmiert war (es war Druckdesign für eine Tageszeitung), sind das Konzept und die angemessene Reaktion gleich.

Was sie tat, war, anstatt unseren Papierkram ein Feld für die Schuldigen hinzuzufügen, jedem der Designer einen Satz farbiger Aufkleber zu geben. Jeder Designer erhielt einen andersfarbigen Aufkleber und wurde angewiesen, dass für jedes Design, an dem gearbeitet oder sogar berührt wurde , der Aufkleber den Unterlagen dieses Designs hinzugefügt werden muss.

Das erklärte Ziel des Chefs für "die Sticker-Initiative" war es, die Quelle aller Fehler unserer Abteilung zu ermitteln (Fehler in Papierkram, Fehldateien, fehlerhafte Kopien, im Wesentlichen das Druckäquivalent von Fehlern).

Was wir getan haben, war, jedem der anderen Designer ein Viertel unserer Aufkleber zu geben, damit wir alle Farben hatten, und anstatt nur unsere Farbe auf jedes Design zu setzen, haben wir alle vier Designer angebracht 'Farben.

Schreiben Sie nicht einfach Ihren Namen in das Feld [Schuld] - geben Sie den Namen aller Mitglieder des Teams/Projekts ein und stellen Sie sicher, dass das gesamte Team dasselbe tut.

Wir haben zusammen gegen ihre orwellsche Schlamperei gearbeitet und als Ergebnis haben wir uns gegenseitig Fehler aufgefangen und miteinander darüber gesprochen und letztendlich eine signifikante Reduzierung der Fehler erzielt. Sie war eine Sh * t-Managerin, und anstatt zu erkennen, dass ihre Initiative uns vereinte und die Produktivität steigerte, wurde sie völlig verletzt und löste das Aufklebersystem auf und erklärte es für einen Misserfolg und tadelte uns alle förmlich.

32
fifthestei8ht

Das klingt sehr ähnlich, als Scott Adams auf die fehlgeschlagene Weisheit eines Bug Bounty hinwies, als der Pointy Haired Boss in Dilbert. Wally kündigte an, er werde ihm einen neuen Mini Van schreiben.

Dilbert-Comic für den 13.11.1995 aus dem offiziellen Dilbert-Comic-Archiv.

Ich erinnere mich einmal, als beim Skifahren jemand darauf hinwies, dass „nicht fallen“ nicht das Zeichen eines guten Skifahrers war, sondern oft das Zeichen eines Menschen, der nichts probiert (oder überhaupt nicht wirklich Ski fährt).

Fehler können durch schlechte Programmierung und schlechtes Design in den Code eingeführt werden. Sie können aber auch die Folge des Schreibens vieler schwieriger Codes sein. Dinging Leute, die die meisten Bugs produzieren, ist für arme Entwickler genauso wahrscheinlich wie für hochproduktive.

Es hört sich so an, als ob Ihr Chef mit der Anzahl der Fehler frustriert sein könnte. Haben die Leute in Ihrer Gruppe eine Leidenschaft für Qualität? Das Erstellen eines "Was" -Felds für die Ursache anstelle eines "Wer" -Felds könnte produktiver sein. Beispiel: Änderung der Anforderungen, Konstruktionsfehler, Implementierungsfehler usw. Auch dies schlägt fehl, es sei denn, es gibt eine Gruppe, die die Qualität des Produkts verbessert.

20
Mark Hancock

Es wird seinen produktivsten Programmierer bestrafen. Wahrscheinlich sind ein oder zwei Personen die besten Mitarbeiter, die an den meisten Projekten gearbeitet haben. Wenn Sie in einer 10-Personen-Abteilung einen Codierer haben, der nur eine Quelle der Ausgabe ist und 60% des Schnittstellencodes geschrieben hat, sind 60% der Fehler in seinem Code enthalten.

Erklären Sie, dass dieses System den Eindruck erwecken würde, dass die Person, die den meisten Code schreibt, der schlechteste Programmierer ist und die Person, die den geringsten Code schreibt, der beste Programmierer ist.

20
Bill B

Vielleicht sollten Sie es als "Wer ist in der besten Position, um den Fehler zu beheben?" Betrachten. Ein Teil von mir hat auch das Gefühl, du hast es kaputt gemacht, du hast es repariert. Es sollte eine gewisse Rechenschaftspflicht geben.

Ich bin nicht damit einverstanden, eine Punktzahl zu halten. Einige Leute verursachen mehr Fehler, weil sie an komplexeren Teilen des Codes arbeiten. Wenn Codezeilen keine nützliche Metrik sind, bezweifle ich, dass Fehler pro Codezeile besser sind. Der Code wird niemals eingecheckt.

Irgendwann sollte ein Manager wissen, wer seine Arbeit macht und wer nicht und wer es besser macht, weil der Rest des Teams es tut.

19
JeffO

Ihre eigentliche Frage war, wie Sie die Kultur ändern können, bevor Sie das Unternehmen verlassen, indem Sie Ihren Chef davon überzeugen, dass es eine schlechte Idee ist, eine Person in die Schuld für Fehlerberichte aufzunehmen. Aber um die Kultur zu ändern, muss er natürlich wirklich verstehen , warum dies eine schlechte Idee ist.

Dies ist eine große Aufgabe. Neben dem Problem, das Gesicht zu retten, nachdem er seine Meinung geändert hat, gibt es das Grundproblem, dass Menschen, die über Lösungen hauptsächlich in Bezug auf individuelle Schuld nachdenken, normalerweise ziemlich in dieser Denkweise verankert sind.

Sie haben darum gebeten, zu diesem Thema zu schreiben, und Peopleware fällt Ihnen ein. Es ist hoch angesehen und spricht allgemein darüber, wie man Menschen verwaltet, die kreative Arbeit leisten, wenn der Output schwer zu messen ist. Das Problem ist, dass das Lesen nicht viel hilft, Ihr Chef es lesen und zumindest einen Teil davon glauben müsste.

Da das Problem hier eher Menschen als Fehlerberichte betrifft, gehört es seltsamerweise möglicherweise eher zum Arbeitsplatz als zu Programmierern. Der Erfolg von Softwareprojekten ist jedoch in der Regel stark auf die soziale Interaktion des Menschen zurückzuführen. Daher beziehen sich die tatsächlichen Antworten häufig hauptsächlich auf Dinge, die über Software hinausgehen.

Mein einziger anderer, halb ernster Vorschlag ist zu sagen (oder einen Kollegen davon zu überzeugen, zu sagen, da Sie vorhaben zu gehen), dass Sie dazu bereit sind Übernehmen Sie die volle Verantwortung für den Erfolg des Projekts, und Ihr Name sollte immer im Feld stehen, denn selbst wenn jemand anderes den Fehler direkt gemacht hat, haben Sie angenommen Verantwortung dafür, dass jeder im Team Qualitätsarbeit leistet.

Es ist natürlich Unsinn, wie könnte man das jemals belegen, aber einige Leute (besonders Leute, die große Schuld haben) essen dieses Zeug wirklich auf. Ronald Reagan übernahm jedes Mal öffentlich persönliche Verantwortung, wenn ein Mitglied seiner Regierung in einen Skandal verwickelt war (und es gab einige), und es funktionierte politisch jedes Mal ziemlich gut. Das Beste für Sie ist, dass die Verantwortung im Allgemeinen keine tatsächlichen Konsequenzen hat. Sie denken nur, dass Sie ein aufrechter Typ sind, der die Verantwortung übernimmt.

Oder vielleicht geht es nicht so. Es macht für mich überhaupt keinen Sinn, daher fällt es mir schwer vorherzusagen, wann es funktionieren wird, aber ich habe gesehen, wie es funktioniert, wenn es anscheinend nichts damit zu tun hat (am Arbeitsplatz, nicht nur am Beispiel von Reagan).

19
psr

Es ist seltsam, dass dies zuvor noch niemand erwähnt hat: Das Hinzufügen einer solchen Funktionalität zum Bug-Tracker würde die Mitarbeiter dazu motivieren, versuchen Sie, das System zu spielen.

Dies ist ein häufiges Problem bei Ansätzen wie der Frage, die unter anderem gestellt wurden (Bezahlen nach Anzahl der Codezeilen, Bezahlen nach Anzahl der Fehler). Dies wird viele dazu ermutigen, sich darauf zu konzentrieren, eine gute Punktzahl zu erzielen, anstatt Probleme im Zusammenhang mit der Software zu lösen, an der sie arbeiten.

Wenn Sie beispielsweise versuchen, einen Fehlerbericht mit einem Wortlaut einzureichen, um die eigene Schuld zu verringern und ihn jemand anderem zu übertragen, kann dies dazu führen, dass Entwickler die Ursache des Problems missverstehen (oder dass die Arbeit einem anderen Entwickler übertragen wird, der diesen Abschnitt von nicht kennt Ein Code, der so gut ist wie derjenige, der am meisten daran gearbeitet hat und der die Hauptursache für den Fehler war. Dies führt zu mehr Zeit und Mühe, um das Problem zu beheben.

19
vsz

Die Leute machen sich nicht an die Arbeit, um Fehler zu machen, und es ist lächerlich, eine Strategie zu entwickeln, um gezielt die Schuld für das zu geben, was menschliches Versagen gewesen sein kann oder nicht.

Zumindest wäre eine "verantwortliche Partei", die beauftragt ist, das Problem zu übernehmen und zu "beheben" oder einen Plan auszuarbeiten, um ähnliche Ereignisse zu verfolgen und/oder zu verhindern, gut. Manchmal ist die Lösung nichts anderes als zusätzliches Training. Ich habe für eine Reihe von Unternehmen gearbeitet, in denen dies Teil Ihrer Stellenbeschreibung war, um eine Ausbildung zum Thema "Unternehmen bezahlt/Unternehmenszeit" zu erhalten. Ein Ort baute sogar ein ganzes "Ausbildungszentrum", das das örtliche College gelegentlich für seine Kurse zu Industrietechnologien "ausleiht".

Ich habe in den letzten 20 Jahren in einer Fertigungsumgebung gearbeitet, in der Programmierfehler nicht nur Fehler verursachen, sondern Dinge physisch zerstören und/oder schlimmer noch, Menschen verletzen. Eine Konstante in jedem Bereich der Fertigung, die stark ist, ist jedoch, dass unter keinen Umständen jemand schuld ist. Weil es ein Defekt im System ist, schlicht und einfach - nicht ein Defekt in den Menschen. Betrachten Sie es so - die Verwendung der Rechtschreibprüfung - ein hochwirksames Werkzeug für diejenigen, die im Bereich der Textvirtuosität weniger Glück haben oder vielleicht nur für diejenigen, die etwas überarbeitet sind ... aber keineswegs eine Methode der Schuld oder Rechenschaftspflicht.

Eine Arbeitsumgebung, egal welcher Art oder zu welchem ​​Zweck sie dient, ist ein System. Ein System aus einzelnen Komponenten, das, wenn es richtig "in Einklang" ist, in völliger Harmonie funktioniert - oder einem Anschein davon.

Vorgeschlagene Lektüre Ihres Chefs: Die 7 Gewohnheiten hochwirksamer Menschen

Es hört sich so an, als könnte er ein wenig Demut gebrauchen, wenn nicht sogar eine Realitätsprüfung. Er ist genauso ein Teil des Teams wie alle anderen, und er muss das erkennen - oder es wird einfach nicht funktionieren, und am Ende wird er die Tasche trotzdem halten.

Empfohlene Lektüre und/oder Recherche von Ihrer Seite:

Schauen Sie sich 5 Gründe an, warum Analyse, Ursachenanalyse ... alles, was Sie in eine bessere Position versetzt, um eine Lösung anzubieten, kein Problem . Und Ihre Meinungsverschiedenheit mit Ihrem Chef ist genau das, ein Problem, keine Lösung. Bieten Sie ihm etwas Besseres an, etwas, das Sinn macht, und seien Sie sogar bereit, ihm zu erlauben, die Idee zu würdigen.

Im Moment scheint es nicht so, als wäre er bereit, irgendetwas zu reparieren, weil er nicht genau weiß, was kaputt ist, wenn überhaupt etwas kaputt ist - außer seiner "Ich bin der Boss" -Mentalität.

Viel Glück! Ich hoffe, Sie schaffen es auf eine Weise, die für alle akzeptabel ist, besonders in diesen Zeiten.

EDIT: Persönlich, aus eigener Erfahrung ... "Mach weiter, beschuldige mich. Weil ich es sicher reparieren werde und wenn es wieder passiert, wer wird da sein, um den Tag zu retten? Ja, du habe es erraten ... ich mit einem großen alten Grinsen. "

14
tahwos

Aus Gründen der Verantwortlichkeit möchte ich kein person to blame - Feld, sondern ein Person who knows the code - oder ein person who can fix - Feld, damit ich weiß, wohin ich das Support-Ticket senden soll.

Dies würde den Prozess beschleunigen, der den Fehler selbst behebt, und Rechenschaftspflicht geben, ähnlich wie zwei Fliegen mit einer Klappe zu schlagen. Ich würde dies persönlich zu ihm bringen und ihn entscheiden lassen, ob dies dazu beitragen würde, die Moral und Rechenschaftspflicht zu erhöhen, ohne dass sich jemand als gescheitert fühlt. Extreme Tests erfassen nicht alle Fehler, da sonst keine Fehler gemeldet werden.

10
Malachi

Wenn mein Chef das tun würde, würde Folgendes in genau dieser Reihenfolge passieren:

1) Ich würde sofort nach einem neuen Job suchen.

2) Jedes Mal, wenn ein Fehler mit einer schuldigen Person gemeldet wird, erscheint dort der Name meines Chefs und ein Kommentar, warum ein schlechter Prozess im Team dafür verantwortlich ist. Und CC das an seinen Chef (vorzugsweise in einer Charge). Haben Sie Unit-Tests? Wenn nicht, bedeutet dies, dass der Entwicklungsprozess unterbrochen ist, also der Fehler. Haben Sie ständige automatisierte Integrationstests mit allen externen Systemen? Dann ist der Entwicklungsprozess unterbrochen, also der Fehler. Haben Sie die Möglichkeit, jede Umgebung in der Produktion per Skript identisch zu machen, um menschliches Versagen nicht zuzulassen? Dann ist der Entwicklungsprozess unterbrochen, also der Fehler. Ist ein Entwickler schrecklich? Dann ist das Einstellungskriterium schlecht, also die Schuld des Chefs. Machen alle Entwickler dumme Fehler aufgrund mangelnder Ruhe, weil sie 12 Stunden am Tag arbeiten? Dann ist der Entwicklungsprozess unterbrochen. Wie Sie sehen können, sind 100% der Fehler die Schuld des Chefs.

Als Randnotiz: Jeder gute Entwicklungsmanager weiß, was ich oben geschrieben habe. Und agile Strategien sollen den Chef oder seine/ihre Kollegen darauf hinweisen, warum der Entwickler langsamer wird: Schauen Sie, wir verbringen 50% unserer Zeit damit, Fehler zu beheben. Schauen wir uns Strategien an, um sie zu reduzieren, damit wir 40% der Zeit damit verbringen können, Fehler zu beheben, und dann dieses Problem erneut zu betrachten und es auf 30% zu bringen. usw.

Leider klingt es so, als hätten Sie wegen des Feldes keinen guten Manager. Ich schlage daher vor, (1) zu tun und es nicht dem Manager vorzulegen (außer bei Ihrem Exit-Interview).

9
Dmitriy Likhten

Sagen Sie ihm, "Schuld" ist negativ. Ändern Sie es in "Person to fix", dann wird es zumindest positiv gerahmt, und der gleiche Job wird immer noch erledigt. Wie können Menschen arbeiten, wenn sie "beschuldigt" werden?!

9
José

Wenn Sie Agile ausführen und es sich so anhört, als wären Sie aus dem Kommentar Features/Stories . Die schuldige Person ist die QS-Person, die den Fehler durchgelassen hat, oder der Product Owner/Kunde, der die Funktion/Story als vollständig mit dem akzeptiert hat Fehler darin.

Ich habe damals gesetzt, hier ist meine Einstellung dazu.

Dies ist so, als würde man einen Schriftsetzer für Rechtschreibfehler und andere Dinge verantwortlich machen, die ein Korrektor hätte finden, aber übersehen sollen. Der Schriftsetzer hat die Rechtschreibfehler gemacht, aber der Korrektor hat sie verpasst, so dass der Korrektor für den Fehler beim Drucken verantwortlich ist, nicht die Person, die den Fehler überhaupt gemacht hat.

In einer agilen Umgebung liegt es in der Verantwortung der QS-Personen, Fehler (Bugs) zu erkennen, und es liegt in der Verantwortung der Product Owners, Dinge nicht zu akzeptieren, die nicht korrekt sind. Dies sind zwei Ebenen von Korrekturlesern, die die Entwickler vor den Dingen schützen sollten, die veröffentlicht werden. Nur so sollte alles als Fehler in einem Fehler klassifiziert werden Agile Umgebung.

8
user7519

Es sieht so aus, als ob Ihr Chef kein tiefes Verständnis für Software hat und vielleicht auch nicht beabsichtigt. Er hat also eine andere Sprache, eine andere Kultur.

Einen Job für ein Problem wie dieses zu kündigen, bevor man überhaupt versucht, eine Lösung zu finden, ist nur ein Quitter. Beenden ist Beenden. Hör nicht auf, bis er dich sicherstellt, dass du dich nie verstehen kannst. Um sicherzugehen, sollten Sie es zuerst versuchen.

Da er unsere Sprache nicht kennt und der Chef ist, würde der erste Schritt hier darin bestehen, mit ihm in seiner Sprache zu sprechen. Was meine ich mit Sprache? Denken wir gemeinsam:

Wir Software-Leute, die meisten von uns lieben unsere Arbeit, wir haben eine tiefe Verbindung zu dem, was wir tun. Sonst funktioniert es nicht und man kann nicht lange in diesem Geschäft weitermachen, ohne es zu lieben oder vollständig zu sein ... Sie füllen die Lücken ...

Er sieht die Dinge jedoch ganz anders. Während die meisten von uns begeistert sind, dass das Ding besser funktioniert (nein, auch wenn es manchmal sehr stressig ist, wir lieben Probleme, geben Sie es einfach zu!), Betrachtet er es als Misserfolg, als Maß für das Sein erfolglos. Als erstes sollte er verstehen wollen, dass Fehler gut sind. Bugs bringt Kunden dazu, das Unternehmen zu lieben. (Dies ist seine Sprache.) Wenn ein Kunde einen Fehler meldet oder wenn wir selbst einen finden, nachdem er behoben wurde, ist er viel besser als die Situation, in der er nie aufgetreten ist. Fehler schaffen Kundenbindung (ich meine es ernst!), Fehler schaffen eine gute Entschuldigung für die Kommunikation zwischen dem Verbraucher und dem Hersteller der Software.

Um den Gewinn von Fehlern zu steigern, sollten Sie anbieten, Fehlerberichte noch offener zu gestalten. Mit jedem Fehlerbericht und seiner schnellen, sauberen und guten Lösung spüren und sehen Kunden, dass "Wow, diese Leute sind großartig! Sie arbeiten wirklich hart. Sehen Sie sich diese Dinge an, die sie lösen. Wir waren uns nicht einmal bewusst, dass Software so komplex ist Ding!" bla bla und bla ...

Machen Sie Ihren Schritt, sprechen Sie in seiner Sprache. Fehler sind großartig für ein Softwareunternehmen, kein Problem. Sie verdienen uns ihren Lebensunterhalt.

Für Teamethik, Effizienz oder jede Art von Gespräch, die Sie führen würden, funktioniert dies möglicherweise umgekehrt. Wenn Sie aufhören möchten, wird er denken: "Aha, meine Lösung hat vom ersten Tag an funktioniert! Schlechte Links haben bereits begonnen, sich von selbst zu lösen, bevor sie aufgedeckt werden!" Er glaubt an seine Idee, die bösen Jungs in der Firma zu finden, und es ist sehr schwierig, ihn anders zu überzeugen. Besonders wenn du einer dieser bösen Jungs sein könntest!

Konzentrieren Sie sich also auf sein eigentliches Problem: Bugs. Zeigen Sie ihm, dass Fehler sehr nützlich sein können. Ohne Probleme ist eine Beziehung langweilig. Alles, was dich nicht umbringt, macht dich stärker. Jeder Fehler ist eine großartige Gelegenheit, um die Kundenzufriedenheit zu steigern.

Dies ist nur eine Sache, die Sie sagen können. Denken Sie an seine Bedenken und Sie werden viele andere Elemente finden, die Sie Ihrer Liste hinzufügen können. Der GOLDENE SCHLÜSSEL soll eine Alternative bieten, anstatt mit seiner Idee zu kämpfen!

8
hasanyasin

Ich denke, Ihr Manager versucht, ein Problem mit der falschen Lösung zu lösen. Ich denke, vielleicht gibt es ein Problem, dass zu viele Fehler veröffentlicht werden und Ihr Manager möchte, dass die Entwickler mehr Eigenverantwortung und Verantwortlichkeit für den von ihnen geschriebenen Code übernehmen.

Die Verwendung einer testgetriebenen Entwicklung und die Einrichtung eines kontinuierlichen Integrationsservers (wie Jenkins ) helfen, dieses Problem zu lösen, ohne das "Schuldspiel" einzuführen. Ein Continuous Integration Server ist dafür wichtig, denn wenn jemand Code festschreibt, der den Build "bricht", geht eine E-Mail an das Team, in der die schuldige Person angezeigt wird. Da dieser Code nicht für eine Produktionsumgebung freigegeben wurde, ist diese Art der Schuld proaktiver und ermutigender (und macht Spaß!).

Das Ergebnis ist, dass Entwickler mehr Eigenverantwortung übernehmen, sich sicherer fühlen und weniger Fehler im Produktionscode auftreten.

7
Andrew

Weisen Sie darauf hin, dass, wenn der Fehler einer einzelnen Person dazu führt, dass ein Fehler in der Produktion endet, etwas mit Ihrer Methodik oder Ihrer allgemeinen Art der Softwareentwicklung nicht stimmt. Weisen Sie darauf hin, dass es in der Verantwortung des gesamten Teams liegt, zu verhindern, dass Fehler in die Produktion gelangen.

Überprüfen Sie anhand eines dieser beiden Argumente, ob Sie Ihren Chef davon überzeugen können, dass es irreführend wäre, das Feld "Wen schuld" als Einzelauswahlfeld zu haben. und deshalb muss sichergestellt werden, dass das Feld "Wen schuld" ein Mehrfachauswahlfeld ist. Sobald Sie dies erreicht haben, stellen Sie sicher, dass für jeden Fehler der Name eines jeden im Feld ist. Ihr Chef wird irgendwann feststellen, dass jede Berichterstattung auf dem Feld zwecklos ist.

Um dem Chef etwas Anerkennung zu schenken, ist das Konzept der "Schuldzuweisung" bereits in Tools wie SVN integriert, und eine angemessene Verwendung der Daten kann für Entwickler konstruktiv sein in "Herausfinden, mit wem Sie sprechen sollen" beim Debuggen, z. B.: http://www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Obwohl ich der obigen Antwort von gnat zustimme, dass ein Root Cause Feld eine gute Sache ist, ist dies nicht die gleiche Information und "denormalisiert" das Feld zu Weisen Sie der betroffenen Quelle manchmal die vorherigen Entwicklernamen zu, und manchmal hat eine technische Beschreibung (z. B. "nicht auf 10000 Benutzer skaliert") nur das Wasser trüb. Ich würde mich dafür einsetzen, dass ein Feld für die Grundursache eine technische Beschreibung enthält (z. B. selbst wenn ein klarer Programmiererfehler vorliegt, lassen Sie Details wie "IndexOutOfRange-Ausnahme" erfassen when fooData = 999 ") Dies kann möglicherweise ein nützliches Feedback liefern, wenn es massenhaft überprüft wird, und es können einige Korrekturmaßnahmen ergriffen werden, um ganze Klassen von Problemen mit Architektur- oder Framework-Änderungen zu lösen (z. B. Verbesserung benutzerdefinierter Containerklassen, Ausnahmebehandlung auf oberster Ebene )

Das Hinzufügen eines Feldes Person to Blame kann jedoch eindeutig eine sehr schlechte und destruktive Nachricht an ein Softwareteam senden, das das Management herausgreifen und bestrafen möchte Entwickler, die am häufigsten Code brechen. Ich vermute, dass der Manager glaubt, dass diese öffentliche Kontrolle dazu führen wird, dass Entwickler vorsichtiger und selbstregulierender sind, um zu vermeiden, dass ihre Namen auf diese "Mauer der Schande" fallen, und versteht nicht, warum Entwickler sich dadurch bedroht fühlen würden, insbesondere wenn sie hinzugefügt werden generisch zu jedem Fehlerbericht.

Die Probleme beim Hinzufügen dieses Felds als Fehlerfeld/potenzielle Metrik lassen sich leicht aufzählen:

  1. Fehler sind sehr unterschiedlich schwer zu beheben, und eine einfache Statistik der Fehleranzahl/des Entwicklers wird dies nicht widerspiegeln.
  2. Entwickler sind sehr unterschiedlich in der Fähigkeit "" "" "" "" "" ""
  3. Viele Softwaresysteme verfügen über Komponenten, die umgestaltet werden müssen. Das Umgestalten von Legacy-Komponenten (insbesondere wenn die Legacy-Basis keine/begrenzte Unit-Test-Funktionen hat) führt jedoch zunächst zu Fehlern. Entwickler werden wahrscheinlich von dieser "guten" Aktivität abgehalten, wenn mit der Erzeugung neuer Fehler ein Stigma/eine Angst verbunden ist (auch wenn diese trivial zu beheben sind und das Ergebnis letztendlich zu einer wesentlichen Verbesserung des Systems führt).
  4. Tester können eine sehr variable Anzahl von Fehlern einreichen, die sich auf dasselbe Problem beziehen, was zu stark verzerrten Fehlerzahlen/Entwicklern führt, sofern keine detailliertere Analyse durchgeführt wird.

Das ist nur die Spitze des Eisbergs. Kombinieren Sie diese mit dem Fingerzeig, wer welches API-Verhalten erwartet hat, falsche erwartete Ergebnisse in Tests und "früher in der Kette" -Probleme mit falschen/fehlenden Anforderungen, und es sollte offensichtlich sein, dass eine solche Metrik als wertlos zum Scheitern verurteilt ist (es sei denn das Ziel ist es, die Moral zu schädigen und einen Massenexodus zu verursachen.)

Zurück zum Standpunkt des Chefs ist es in Ordnung, dass er/sie herausfinden möchte, ob es Entwickler gibt, die wiederholt Code brechen, und versuchen soll, etwas (hoffentlich Konstruktives) dagegen zu tun. Der Versuch, diese Informationen durch Hinzufügen eines Felds zu Fehlerberichten abzurufen, liefert aus den oben genannten Gründen keine aussagekräftigen Informationen. Nach meiner Erfahrung können diese Informationen erlernt werden, indem sie mit dem Team verbunden werden, an den meisten Teambesprechungen teilnehmen, (sorgfältig) Informationen integrieren, die in gelegentlichen Einzelgesprächen mit Teammitgliedern erlernt wurden, und sich mit den Subsystemen vertraut machen den Code (auch wenn sie keinen Code lesen können.)

6
holtavolt

Lass es einfach gehen. Ihr Chef wird selbst feststellen, dass dies ein Problem verursacht, wenn dies der Fall ist.

Seien wir stumpf, Sie haben eine Meinung und er auch. Er ist Ihr Manager und seine Meinung ist diejenige, die gewinnt.

Ja, Sie können wegen dieses Problems in den Krieg ziehen, aber ist es das wirklich wert? Ich bezweifle, dass es länger als 3 Monate dauert, bevor es nicht mehr verwendet wird.

Aber dies aktiv zu sabotieren oder darüber zu schreien, verbraucht nur politisches Kapital, das besser gespart wird, um nach dieser zusätzlichen Freizeit, der nächsten Erhöhung, Beförderung oder wenn eine wirklich kritische Designentscheidung getroffen werden soll.

In diesem Moment, wenn es wirklich darauf ankommt, möchten Sie nicht, dass sich der Chef daran erinnert, dass Sie die Person waren, die seine Idee für "Schuldige" aktiv sabotiert hat.

Respektieren Sie das Büro, auch wenn Sie die Entscheidung nicht respektieren.

Speichern Sie den Stress und das Stampfen des Tisches für Entscheidungen, die viel länger dauern werden.

6
Pat

Sagen Sie Ihrem Chef, dass die Entwicklung in einem Team soziale Fähigkeiten erfordert. Er könnte sogar nicken.

Das Problem ist jedoch, dass Entwickler damit extrem schlecht umgehen können. Das Hinzufügen von Tools, die darauf hindeuten, dass Schuldzuweisungen wichtiger sind als eine ordnungsgemäße Problemanalyse, ist kontraproduktiv.

Stattdessen brauchen Sie Anreize zur Verbesserung der sozialen Fähigkeiten, und die Kommunikationsinfrastruktur, über die Sie verfügen, sollte dies unterstützen. Zum Beispiel positiv prägen: Nennen Sie eine Person, die für ein Ticket verantwortlich ist und sich darum kümmert.

Beginnen Sie auch mit Codeüberprüfungen, damit Sie voneinander lernen können. Das erspart später die Schuld.

5
hakre

Senden Sie ihm diese E-Mail SO Frage. Wenn er für Vernunft offen ist, bieten die Kommentare hier eine Überprüfung der Vernunft für seine Argumentation. Wenn er nicht vernünftig ist, ist es unwahrscheinlich, dass Sie ihn mit sinnvollen Gründen überzeugen. Außerdem kann er die Gründe außerhalb eines Gesprächs lesen (was manchmal überzeugender sein kann, weil die Motivation, in der Hitze eines Gesprächs "richtig" zu sein, nicht mehr besteht).

Sie können auch versuchen, es umzudrehen. Das Feld könnte "mögliche Schritte sein, um das Auftreten eines ähnlichen Fehlers zu vermeiden" oder etwas kürzeres in diesem Sinne. Dann könnten Sie Lösungen bündeln und darüber abstimmen, welche implementiert werden sollen, um Ihren Arbeitsplatz zu verbessern. Möglicherweise ist ein lösungsorientierter Ansatz produktiver und wird wahrscheinlich besser angenommen (vorausgesetzt, die Überprüfung der Vorschläge wird tatsächlich durchgeführt).

2
Homer6

Ich sehe hier zwei Möglichkeiten: Er möchte Menschen bestrafen können, die Fehler machen, oder er hat es einfach nicht durchdacht. Lassen Sie ihn wissen, dass die Wahrnehmung für alle sein wird, dass er diejenigen bestrafen will, die Fehler machen. Fragen Sie ihn, ob dies die Kultur ist, die er fördern möchte.

mein Chef hat entschieden, dass das Hinzufügen eines Feldes "Person To Blame" zu unserer Fehlerverfolgungsvorlage die Verantwortlichkeit erhöht

Nach meiner Erfahrung wollen die Führungskräfte, wenn sie "die Menschen rechenschaftspflichtiger machen" wollen, in der Lage sein, die Bestrafung für das Scheitern zu fordern. Ob es darum geht, arme Darsteller zu entlassen oder sie einfach in der jährlichen Gehaltsüberprüfung ("Entschuldigung, Bob, Sie hatten 17 Fehler als Ihre Schuld markiert, und das ist über dem Grenzwert von 15"), es ist eine Bestrafung.

Er wird wahrscheinlich sagen "Oh nein, das wollen wir nicht", also fragen Sie ihn, wie diese Daten verwendet werden. Erinnern Sie ihn daran, dass Sie einer Datenbank keine Datenpunkte hinzufügen, es sei denn, Sie werden sie verwenden. Möchte er entweder nach einem bestimmten Kriterium auswählen ("Zeige mir alle offenen Fehler im Subsystem für die Berichterstellung"), damit Sie an Dingen arbeiten können, oder um aggregierte Daten abrufen zu können ("Welches Subsystem hatte die meisten." Bugs "), damit Sie eine Post-Mortem-Analyse durchführen können. Stellt er sich eine Art Tote Board of Failure vor, in der Menschen öffentlich gedemütigt werden können?

Also was hat er vor? Will er sagen können "Zeig mir alle Fehler, die Bob schuld sind?" Warum? Oder will er sagen können "Zeig mir, wer die meiste Zeit schuld ist?" Warum? Der erste ist nicht sinnvoll und der zweite ist nur strafbar. Oder die dritte Option ist, dass er keinen wirklichen Grund hat.

Ich gebe zu, es besteht die Möglichkeit, dass er nach Programmierern im Team sucht, die Hilfe bei der Verbesserung ihrer Fähigkeiten benötigen. In diesem Fall gibt es bessere Möglichkeiten, diese Informationen zu erfassen, ohne dass eine Kultur des Fingerzeigens entsteht.

1
Andy Lester