Sollte Geld als Motivation an Tester und Entwickler gezahlt werden, um Fehler zu entdecken und zu produzieren?

Ich habe eine Idee zur Steigerung der Produktivität in einem Unternehmen gelesen. Es ging so:

Haben Sie einen bestimmten Fonds, das wird ein Bonus sein. Sagen Sie 100.000 Dollar. Für jeden gefundenen konkreten Fehler erhalten die Tester 5 bis 15 US-Dollar. Was am Ende des Monats/Jahres übrig bleibt, geht an die Entwickler.

Theoretisch scheint es eine wunderbare Idee zu sein, obwohl ich nicht sicher bin, wie gut es in der Praxis funktionieren wird. Die offensichtliche Folge davon ist, dass es den Antagonismus zwischen Entwicklern und Testern fördert. Das Bug-Business wird zum Nullsummenspiel.

Ist der Antagonismus etwas Schlechtes? Wie wird es sich auf die Produktivität und vor allem auf die Organisation auswirken? Persönliche Erfahrung wird sehr geschätzt.

(Ich zucke zusammen, wenn ich solche „Motivationsschemata“ lese.)

Vielleicht definiert der Autor dieser Idee „Produktivität“ anders als ich.

Das Ziel der meisten Unternehmen, die Software produzieren, ist es, Geld zu verdienen und vielleicht den Geldbetrag zu maximieren, den sie verdienen. Das Ziel eines Bug-Bounty-Systems ist weniger klar und hat sicherlich nichts mit Produktivität zu tun. Es würde viel Zeit darauf verwendet, Bonusgeld zu erhalten, und wenig Zeit würde darauf verwendet, die Software zu versenden (womit das Unternehmen Geld verdient).

Stellen Sie sich ein Unternehmen mit einem Entwickler und einem Tester vor.

Wenn Sie der Entwickler wären, wäre Ihre optimale Strategie, die gesamte Software vor dem Tester zurückzuhalten, bis überhaupt keine Fehler mehr vorhanden sind oder bis der Zeitplan für den Tester keine Zeit mehr hat, welche zu finden.

Ich habe in einem Unternehmen gearbeitet, das Entwickler eher mit Lob als mit Geld belohnt hat, und das war genau die Strategie, die von einem Entwickler angewendet wurde. Builds wurden alle 2 Wochen an die QA freigegeben. Und jeden zweiten Freitag hatten wir ein Teammeeting, bei dem die Anzahl der Fehler im aktuellen Build bekannt gegeben wurde. Wenn ein Entwickler jemals null Fehler hatte, wurde dieser Entwickler herausgegriffen und für seine großartige Arbeit gelobt.

Ein Entwickler beschloss, das System zu spielen. Sie würde den Bau (immer mit vernünftigen Ausreden) bis kurz vor dem wöchentlichen Treffen aufheben. Dann veröffentlichte sie den Build, der Bericht über die Anzahl der Fehler wurde ausgeführt, und „magischerweise“ hatte sie gerade rechtzeitig für das Meeting eine Fehleranzahl von null.

Obwohl sie eine gute Entwicklerin war, war ihr Code nicht besser als die meisten anderen. Ihre Klugheit bestand darin, das System zu ihrem Vorteil zu manipulieren.

Ich arbeite derzeit in einem Shop, der Entwickler für die Anzahl der Fehler bestraft, die ihrer Arbeit während eines Projekts zugeschrieben werden. Es wird erwartet, dass sie ihre Fehlerzahl gegenüber dem Vorjahr "verbessern". Dies ist Teil ihrer MBOs und Teil dessen, was in ihre jährliche Bonusauszahlung einfließt.

Es überrascht nicht, dass sie lange gebraucht haben, um den ersten testbaren Build für die QA zu erstellen. Und sie baten darum, dass die QA viel Zeit mit dem Testen in der Entwicklungsumgebung verbringt (wo keine Fehlerberichte geschrieben werden können). Sie haben alle Chancen, weniger Fehler im Meldesystem zu produzieren und somit ihren Bonus zu maximieren.

Der Produktmanager hat sogar beschlossen, viele Fehlerberichte in „Verbesserungsanfragen“ umzuwandeln, um Entwickler-MBOs nicht zu beeinträchtigen. Sein Argument war: "Nun, die Entwickler haben diese Funktion noch nicht vollständig entwickelt, also werden sie sie verbessern, wenn sie Zeit haben."

Wenn ich "durch den Fehler" bezahlt würde, könnte ich ziemlich leicht eine Menge Fehler finden, egal wie gut der Entwickler ist. (Ich mache diese Arbeit seit fast 30 Jahren). Ich würde mich zunächst auf die niedrig hängenden Früchte konzentrieren und alles überspringen, was überhaupt zeitaufwändig war. Meine Fehlerberichte wären minimal und nicht sehr hilfreich - im Grunde alles, was nötig war, um den Fehlerbericht in das System einzugeben und das Geld zu bekommen.

Das Ergebnis wären viele oberflächliche Fehlerberichte, die "gerade greifbar genug" seien, und die Software würde unweigerlich mit einigen großen kritischen Fehlern zurückbleiben. Ich kann mir nicht vorstellen, dass das System jemals ausgeliefert wird.

Die Entwickler würden ihre ganze Zeit und Aufmerksamkeit auf neuen Code richten. Es würde absolut keinen finanziellen Vorteil bringen, bereits gefundene Fehler zu beheben. Und sie würden einen Anreiz erhalten, winzige, unbedeutende Veröffentlichungen zu produzieren. Wenn sie eine Veröffentlichung produzieren, die nur eine einzige Zeile perfekten Codes enthält, erhalten sie einen Bonus von 100.000 $! Warum überhaupt knifflige Funktionen hinzufügen?

Beide Teams stritten sich vehement über jeden einzelnen Fehlerbericht und darüber, ob es sich wirklich um einen „greifbaren“ Fehler handelte oder nicht. (Das ist ein schöner und unscharfer Begriff. Ich würde gerne hören, wie ein Team versucht, ihn konkret zu definieren). Diese Art von Argumenten bereitet nicht die Bühne für etwas, das ich Produktivität nennen würde.

Und weder Tester noch Entwickler würden Zeit für etwas anderes aufwenden. Keine Besprechungen, keine Dokumentation, kein Kundensupport, keine Hilfe für andere, keine Vorbereitung für den Versand. Hey, wenn es wichtig wäre, wäre Bargeld damit verbunden, oder?

Und dieser letzte Teil ist bedeutsam. Für Wissensarbeiter ist es oft ein großer Hemmschuh, Geldprämien an Aufgaben zu knüpfen, die sie für wichtig halten. Wenn Sie ein besseres Verständnis der Arten von Funktionsstörungen wünschen, die durch diese Art von Anreizsystemen entstehen können, empfehle ich Ihnen dringend, „ Measuring and Managing Performance in Organizations“ von Robert D. Austin zu lesen.

Kurz gesagt, das ist eine schreckliche Idee.

Die meisten guten Softwarefirmen erkennen die Torheit eines solchen Plans und versuchen, sich von dieser Art von System fernzuhalten. Die meisten Softwareunternehmen verstehen, dass die Veröffentlichung von Software ohne Fehler kein realistisches Ziel ist und dass es wichtiger ist, Software zeitnah zu veröffentlichen.

Es scheint eine schreckliche Idee zu sein. Hier sind ein paar Dinge, die passieren werden, zusätzlich dazu, dass Ihre Entwickler und Tester anfangen, sich und Sie selbst dafür zu hassen, dass Sie dies eingeführt haben:

• Jeder wird sich auf niedrig hängende Früchte konzentrieren. Das bedeutet, dass die Qualitätssicherung damit beginnt, alle möglichen Dinge zu melden, die eigentlich in Ordnung sind, aber als „fehlerhaft“ ausgelegt werden könnten, in der Hoffnung, dafür bezahlt zu werden, während die Entwickler ihre ganze Arbeit darauf konzentrieren werden, sicherzustellen, dass es keine offensichtlichen Fehler gibt, und viel weniger auf die Erstellung sicher, dass es keine komplexen, strukturellen Fehler gibt.
• Einige Leute werden sich zusammenschließen und ein Entwickler wird absichtlich eine Menge Fehler einführen, sie dann an eine bestimmte QA schicken, um sie zu "finden", und dann das Geld teilen.
• Einige Ihrer Mitarbeiter werden beleidigt sein, weil Sie denken, dass sie ihren Job nur schätzen, wenn sie dafür einen Bonus bekommen. Sie werden wahrscheinlich weniger hart arbeiten und deswegen mehr Müll produzieren.
• Die Kommunikation zwischen den Teammitgliedern wird aufgrund des erhöhten Antagonismus zusammenbrechen. Es ist jetzt tatsächlich ein Pluspunkt für die Entwickler, der Qualitätssicherung nicht dabei zu helfen, ihre Arbeit besser zu machen, denn alle Fehler, die unbemerkt in die Produktion gelangen, bedeuten, dass sie mehr bezahlt werden.
• Entwickler werden sich gegenseitig nicht mögen, weil jeder Fehler, den ein Entwickler einführt, sie alle Geld kosten wird.

Das ist nur aus der Spitze meines Kopfes. Versuchen Sie niemals, Programmierer und QAs mit Geld zu motivieren, es endet nur schrecklich. Ihre Jobs basieren auf intrinsischer Motivation.

Schauen Sie sich bitte auch diesen animierten TED-Vortrag über Antrieb und Motivation an, da er viel besser erklärt, warum jede Einrichtung, bei der es darum geht, kluge Leute mit Geld zu motivieren, schrecklich scheitern wird:

https://www.youtube.com/watch?v=u6XAPnuFjJc

Das macht genauso viel Sinn, wie wenn die Besatzung eines Schiffes in Teams aufgeteilt wird, diejenigen, die den Antrieb übernehmen, und diejenigen, die navigieren, die auf demselben Schiff in einem Rennen gegeneinander antreten.

Ich weigere mich, eine antagonistische Beziehung zu meinen Testern zu haben. Ich schätze sie. Sie machen mich zu einem besseren Programmierer.

Ich respektiere auch die Kreativität, die ihre Arbeit von ihnen verlangt. Deshalb halte ich Geld hier für den falschen Motivator. Studien haben gezeigt , dass Bargeldanreize die Menschen tatsächlich messbar verlangsamen, es sei denn, ein Job ist praktisch sinnlos.

Kreative Arbeit wird nicht am besten durch Geld motiviert. Seine besten Motivatoren sind:

Autonomie – der Wunsch, unser eigenes Leben zu lenken
Beherrschung – der Drang, besser zu werden oder Fähigkeiten
und Ziele zu entwickeln – die Notwendigkeit, das, was wir tun, aus Gründen zu tun, die größer sind als wir selbst

Das ist richtig, Entscheidungen, Möglichkeiten zur Verbesserung und Teamarbeit würden besser funktionieren als Geld.

QA ist ein kreativer Job. Die Aufgabe besteht wirklich darin, an das zu denken, woran die Entwickler nicht gedacht haben. Aus diesem Grund sollte QA automatisiert werden. Einmal an einen Test gedacht, sollte er nicht wie ein Broadway-Stück immer wieder „aufgeführt“ werden. Es sollte automatisiert werden, damit die QA aufhören kann, darüber nachzudenken, und über den nächsten Test nachdenken kann. QA sollte mit Ihren talentiertesten Entwicklern besetzt sein. Weil sie versuchen, Ihr anderes Entwicklerteam zu übertreffen.

Manche glauben das nicht. Einige halten QA für eine Müllhalde für weniger talentierte Entwickler. Wenn Sie das getan haben, sind Ihre Prioritäten rückwärts gerichtet. Fordern Sie Ihre besten Entwickler heraus, Ihre Tests zu modernisieren, und stellen Sie sicher, dass die Leute wissen, dass Sie bei der Qualitätssicherung am besten sind.

Wenn dieses Geld immer noch ein Loch in Ihre Tasche brennt, verwenden Sie es für Schulungen oder, wenn nötig, Abfindungspakete.

Wir machen hier keine sinnlose Arbeit.

Haben Sie einen bestimmten Fonds, das wird ein Bonus sein. Sagen Sie 100.000 Dollar. Für jeden gefundenen konkreten Fehler erhalten die Tester 5 bis 15 US-Dollar. Was am Ende des Monats/Jahres übrig bleibt, geht an die Entwickler.

Das ist schrecklich. Aus all den Gründen in den anderen Antworten und für die Tatsache, dass es diesen sehr einfachen Test nicht besteht:

• Was ist, wenn alle Ihre Mitarbeiter großartig sind und keine Fehler gefunden werden?

  Die Produktion funktioniert einwandfrei und das Geld geht komplett an die DEVS

• Was ist, wenn alle Ihre Mitarbeiter Mist sind?

  Die Produktion ist wegen der Bugs einfach niedergebrannt, aber hey, wen interessiert das, das Geld geht an die DEVS.

Selbst wenn Geld ein Motivator in unserem Geschäft wäre, wäre dies schrecklich falsch.

Nehmen Sie das Geld und stellen Sie jemanden ein, der wirklich gut darin ist, Spezifikationen zu schreiben und Projekte mit überschaubaren Fristen zu planen. Sowohl DEV als auch QA werden viel glücklicher sein, als Geld sie jemals machen könnte.

Es mag apokryphisch sein, aber mir wurde in den 1980er Jahren ein ähnliches Beispiel gegeben, als ich das „Gesetz der unbeabsichtigten Folgen“ als Teil eines BPR-Kurses behandelte.

Das Beispiel betraf eine Fabrikproduktionslinie, bei der die Qualitätskontrollabteilung durch die Anzahl der Ausschussware motiviert wurde. Die Produktionsabteilung erhielt einen ähnlichen Anreiz, je nachdem, wie wenig Ausschuss sie produzierte.

Der Nettoeffekt war, dass die Qualitätskontrolle mehr Produkte als zuvor zurückwies und die Produktion länger dauerte, um „perfekte“ Artikel herzustellen, sodass die Gesamtleistung zurückging, während die Kosten aufgrund der Anreizzahlungen stiegen. Qualität war unbeeinflusst.

Es funktioniert schlecht. Ich habe es nicht mit Entwicklern und Testern gesehen. Aber das Justizministerium in Neuseeland belohnte an einem Punkt regelmäßige Gefängniswärter für jeden Häftling, den sie verletzten. Es ging von einem Verstoß in einer schlechten Woche bis zu 6 Verstößen an einem Tag bei einigen Häftlingen, die deswegen im Gefängnis landeten. Schließlich wurde ein Wärter verletzt.

Ich bezweifle, dass es so weit gehen würde, da es nicht die gleiche Menge und weniger flüchtige Leute sind (glaube ich), aber es züchtet böses Blut zwischen den Gruppen, die aufgrund ihrer Rollen bereits uneins sind.

Andere Antworten haben bereits ausreichend erklärt, dass Ihre Idee ein schlechtes TM ist. Ich werde das also nicht weiter wiederholen und stattdessen erwähnen, was Sie ändern müssten, um die Idee zu verbessern.

Sie versuchen, Geld an das anzuheften, was letztendlich eine Zahl auf einem Papier ist. Diese Nummer bringt kein Geld. Erschwerend kommt hinzu, dass die Anzahl, die Sie verwenden möchten, meist zufällig ist: Ein Produkt, das nie Fehler hatte, hat plötzlich 50, alles Tippfehler in der Dokumentation. Ein Fehler, der die Hervorhebungsfarbe von 200 Gegenständen durcheinander bringt, wird zu 200 Fehlern. Sobald Sie einige Leute bitten, die Zahl auf magische Weise nach oben zu bringen, ist diese Zahl eine völlig nutzlose imaginäre Zahl. Und obendrein verschwenden Sie Zehntausende von Dollar an Löhnen mit absolut sinnlosen Meetings, bei denen die Leute streiten, was ein Fehler ist und was nicht.

Wenn Sie Boni oder andere Belohnungen an Zahlen auf einem Papier anhängen möchten, müssen diese Zahlen direkt mit dem tatsächlich vom Unternehmen verdienten Geld verknüpft sein - ein gängiges Beispiel ist die Verknüpfung von Boni mit dem Gewinn in einem Handelsunternehmen.

Wie in den „Cupcake“-Kommentaren unter Ihrer Frage angedeutet wurde, können einige Formen der Gamifizierung funktionieren. Wie wäre es mit der Vergabe einer Trophäe für den „Best Bug“, der in einem bestimmten Zeitraum gefunden wurde, vergeben durch die Stimmen beider Teams zusammen ?

In einer gesunden Entwicklungsumgebung gibt es zwischen Testern und Entwicklern eine gemeinsame „Ehrfurcht“ vor Menschen (normalerweise den Testern), die diese lästigen Fehler finden, die nur unter bestimmten Bedingungen reproduziert werden können, vor diesem sporadischen Fehler, der Sie seit Monaten belästigt, vor irgendetwas sehr einfach, dass ein Entwickler übersehen hat usw. ^*

Die Trophäe sollte etwas ganz Einfaches sein, denn es geht nicht um den inneren Wert: ein kleines Schild, ein Cupcake, eine Tafel Schokolade.

^{* Im letzten Beispiel geht es nicht darum, einen Fehler zu finden, sondern einen Fehler zu verursachen. In diesem Fall bedeutet der Preis freundlichen Spott. Dafür braucht man eine Kultur, in der die Kollegen erkennen, dass jeder Fehler macht.}

Ich denke, das Ergebnis wäre nachteilig. Beides widerspricht dem gesunden Menschenverstand beim Entwickeln und Testen.
Null gefundene Fehler bedeuten nicht, dass die Software gut ist. Es könnte zu komplex zum Testen sein oder die QA könnte einige Tests überspringen. Selbst null gefundene Fehler, ein umfangreicher Testprozess und eine hervorragende Codequalität bedeuten nicht, dass das Produkt gut ist. Wenn die Anforderungen durcheinander gebracht wurden, kann die Software für den Kunden schrecklich sein.

Gegen dieses System zu spielen, könnte extrem einfach sein.
Für Entwickler: späte Builds. Für Tester: Konzentration auf triviale Bugs.
Bei späten Builds ist ein frühes Testen unmöglich. Wenig Zeit zum Testen und Freude über viele Bugs? Tester konzentrieren sich auf triviale Fehler, wie falsch geschriebene Bezeichnungen oder einige unkritische Fälle.
Wenn Sie wissen möchten, ob das Produkt gut ist, fragen Sie einfach Ihren Kunden.

Um es kurz zu machen. Entwickler und Tester arbeiten am selben Boot - Ihrem Unternehmen.

Es ist leicht, Entwickler für einen von ihnen produzierten Fehler zu kritisieren, aber es ist schwer, sie für Fehler zu belohnen, die sie nicht produziert haben.

Wenn der Fehler es bis zum endgültigen Build geschafft hat und der Kunde ihn gemeldet hat, wer war schuld? Entwickler für das Schreiben des Fehlers oder Tester dafür, dass er ihn nicht gefunden hat?

Dies führt standardmäßig zu Spannungen zwischen Entwicklern und Testern. Ihre Idee bringt zusätzliche Spannung zwischen die beiden. Das willst du wirklich nicht.

Wenn Sie einen freundlichen Arbeitsbereich haben und das Einfangen von Fehlern belohnen möchten, teilen Sie das Budget fair auf, erstellen Sie eine Liste von Entwicklern und für jeden Fehler soll der Entwickler 1 $ an die Bank zahlen. Organisieren Sie die Weihnachtsfeier und nutzen Sie die Bank, um das ganze Team zu belohnen. Sorgen Sie dafür, dass es mehr Spaß macht als Belohnung/Bestrafung und dass es niemand (zu) ernst nimmt. Belohnen Sie sowohl die „Schlechtsten“ als auch die „Besten“ unter den Entwicklern und Testern.

Ehrlich gesagt erscheint der Anreiz bestenfalls nutzlos und schlimmstenfalls schädlich. Wenn Sie ein engagiertes QA-Team haben, haben Sie bereits Mittel zur Verfügung gestellt, um Fehler zu finden, da dies ein großer Teil ihrer Stellenbeschreibung sein wird. Es wird nicht viel zusätzlichen Antagonismus zwischen den beiden geben, da es mehr in Richtung der Politik selbst geben wird. Wenn Sie sich wirklich Sorgen um das Problem machen, um Geld auf Ihre derzeitigen Mitarbeiter mit angehängten Bedingungen zu werfen, wäre es besser, jemanden dort einzustellen, wo Sie ihn brauchen, entweder in der QA oder in der Entwicklung.

Wo dies wirklich schief gehen könnte, ist, dass Sie auf der Entwicklerseite einen Rückgang der Veröffentlichungen sehen werden, weil Sie befürchten, dass sie aufgrund neuer Fehler weniger bezahlt werden, und auf der QA-Seite könnten Sie viel längere Überprüfungsphasen sehen, weil Tester welche wollen Zulage. Ich sage nicht, dass dies passieren wird, sondern dass es eine Möglichkeit ist.

Niemand möchte Fehler in seinem Endprodukt haben, aber die werden passieren. Als Manager gibt es viel bessere Möglichkeiten, um sicherzustellen, dass weniger Fehler im Code vorhanden sind, z. B. realistische Ziele und Zeitpläne zu haben und Erleichterungen für eine bessere Entwicklung wie Codeüberprüfungen zu ermöglichen.