Es scheint eine schreckliche Idee zu sein. Hier sind einige Dinge, die passieren werden, zusätzlich zu Ihren Entwicklern und Testern, die anfangen, sich und sich selbst dafür zu hassen, dass sie dies einführen:

• Jeder wird sich auf niedrig hängende Früchte konzentrieren . Dies bedeutet, dass die Qualitätssicherung alle möglichen Dinge meldet, die eigentlich in Ordnung sind, aber in der Hoffnung, bezahlt zu werden, als "fehlerhaft" ausgelegt werden können, während die Entwickler ihre ganze Arbeit darauf konzentrieren, sicherzustellen, dass es keine offensichtlichen Fehler gibt und viel weniger darauf, sie zu erstellen Sicher gibt es keine komplexen strukturellen Fehler.
• Einige Leute werden sich zusammenschließen und ein Entwickler wird absichtlich eine Menge Fehler einführen, diese dann an eine bestimmte Qualitätssicherung senden, um sie zu "finden", und dann das Geld aufteilen.
• Einige Ihrer Mitarbeiter werden beleidigt, weil Sie glauben, dass sie ihren Job nur schätzen, wenn sie einen Bonus dafür erhalten. Sie werden wahrscheinlich weniger hart arbeiten und aus diesem Grund mehr Müll produzieren.
• Die Kommunikation zwischen Mitgliedern des Teams wird aufgrund des zunehmenden Antagonismus zusammenbrechen. Es ist jetzt tatsächlich ein Plus für die Entwickler, nicht der Qualitätssicherung zu helfen, ihre Arbeit besser zu machen, da alle Fehler, die unbemerkt in die Produktion gehen, bedeuten, dass sie mehr bezahlt werden.
• Entwickler werden sich nicht mögen, weil jeder Fehler, den ein Entwickler einführt, sie alle Geld kostet.

Das ist mir ein Rätsel. Versuchen Sie niemals, Programmierer und QAs mit Geld zu motivieren, es stellt sich nur als schrecklich heraus. Ihre Jobs basieren auf intrinsischer Motivation.

Schauen Sie sich auch diesen animierten TED-Vortrag über Antrieb und Motivation an, da er viel besser erklärt, warum jedes Setup, bei dem kluge Leute mit Geld motiviert werden, schrecklich scheitern wird:

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

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 wir 100.000 Dollar. Für jeden gefundenen konkreten Fehler erhalten die Tester 5 bis 15 US-Dollar. Was am Ende des Monats / Jahres noch übrig ist, 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-Geschäft wird zu einem Nullsummenspiel.

Ist der Antagonismus eine schlechte Sache? Wie wird sich dies auf die Produktivität und vor allem auf das Unternehmen auswirken? Persönliche Erfahrungen werden sehr geschätzt.

(Ich erschrecke, wenn ich solche "Motivationsschemata" lese.)

Vielleicht definiert der Autor dieser Idee "Produktivität" anders als ich es tun würde.

Das Ziel der meisten Unternehmen, die Software herstellen, 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 aufgewendet werden, um Bonusgeld zu erhalten, und wenig Zeit würde darauf verwendet werden, die Software zu versenden (so verdient das Unternehmen Geld).

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

Wenn Sie der Entwickler wären, wäre es Ihre optimale Strategie, dem Tester die gesamte Software vorzuenthalten, bis überhaupt keine Fehler mehr vorhanden sind oder bis der Tester keine Zeit mehr hat, einen zu finden

Ich habe in einem Unternehmen gearbeitet, das Entwickler eher mit Lob als mit Geld belohnte, und genau diese Strategie verfolgte ein Entwickler. Builds wurden alle 2 Wochen für die Qualitätssicherung freigegeben. Und jeden zweiten Freitag hatten wir ein Full-Team-Meeting, bei dem die Anzahl der Fehler im aktuellen Build bekannt gegeben wurde. Wenn ein Entwickler jemals keine Fehler hatte, wurde dieser Entwickler für seine großartige Arbeit ausgezeichnet und gelobt.

Ein Entwickler hat beschlossen, das System zu spielen. Sie hielt den Build (immer mit vernünftigen Ausreden) bis kurz vor dem wöchentlichen Treffen. Sie veröffentlichte dann den Build, der Fehlerzählungsbericht wurde ausgeführt und "magisch" hatte sie pünktlich zum Meeting eine Fehleranzahl von Null.

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

Ich arbeite derzeit in einem Geschäft, das Entwickler für die Anzahl der Fehler bestraft, die ihrer Arbeit während eines Projekts zugeschrieben werden. Es wird erwartet, dass sie ihre Fehleranzahl gegenüber dem Vorjahr "verbessern". Dies ist Teil ihrer MBOs und Teil ihrer jährlichen Bonusauszahlung.

Es ist nicht überraschend, dass sie lange gebraucht haben, um den ersten testbaren Build für die Qualitätssicherung zu erstellen. Und sie baten die Qualitätssicherung, viel Zeit mit Tests in der Entwicklungsumgebung zu verbringen (wo keine Fehlerberichte geschrieben werden können). Sie haben jede Chance erhalten, weniger Fehler im Berichtssystem zu erzeugen und damit ihren Bonus zu maximieren.

Der Produktmanager hat sogar beschlossen, viele Fehlerberichte in "Erweiterungsanforderungen" zu ändern, um keine Auswirkungen zu haben Entwickler-MBOs. 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 eine Menge finden Fehler ganz leicht, egal wie gut der Entwickler ist. (Ich mache diese Arbeit seit fast 30 Jahren). Ich würde mich anfangs 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 genommen 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" waren, und die Software würde unweigerlich einige wichtige kritische Fehler aufweisen. Ich kann mir nicht vorstellen, dass das System jemals ausgeliefert wird.

Die Entwickler würden ihre ganze Zeit und Aufmerksamkeit auf neuen Code konzentrieren. Es wäre absolut kein finanzieller Vorteil, 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 US-Dollar! Warum überhaupt knifflige Funktionen hinzufügen?

Beide Teams stritten sich vehement über jeden einzelnen Fehlerbericht und 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 bilden nicht die Grundlage für alles, was ich Produktivität nennen würde.

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

Und dieser letzte Teil ist bedeutsam. Für Wissensarbeiter ist es ein großer Nachteil, häufig Geldprämien an Aufgaben zu knüpfen, die sie für wichtig halten. Wenn Sie die Arten von Funktionsstörungen, die durch diese Art von Anreizsystemen entstehen können, besser verstehen möchten, empfehlen wir Ihnen dringend, Messen und Verwalten der Leistung in Organisationen von Robert D. Austin zu lesen.

Kurz gesagt, das ist eine schreckliche Idee.

Die meisten guten Softwareunternehmen erkennen die Torheit eines solchen Plans und versuchen, sich von solchen Systemen fernzuhalten. Die meisten Softwareunternehmen verstehen, dass die Freigabe von Software ohne Fehler kein realistisches Ziel ist und dass es wichtiger ist, Software rechtzeitig freizugeben.

Dies ist genauso sinnvoll wie die Aufteilung einer Schiffsbesatzung in Teams, diejenigen, die Antriebe ausführen, und diejenigen, die navigieren, in einem Rennen auf demselben Schiff antreten.

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

Ich respektiere auch die Kreativität, die ihre Arbeit von ihnen verlangt. Deshalb denke ich, dass Geld hier der falsche Motivator ist. Studien haben gezeigt, dass Geldanreize die Menschen tatsächlich messbar verlangsamen, wenn ein Job nicht praktisch sinnlos ist.

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

Autonomie - der Wunsch, unser eigenes Leben zu lenken
Meisterschaft - der Drang, besser zu werden oder Fähigkeiten zu entwickeln
und Zweck - die Notwendigkeit zu tun Was wir aus Gründen tun, die größer sind als wir selbst.

Richtig, Entscheidungen, Verbesserungsmöglichkeiten und Teamwork würden besser funktionieren als Geld.

Qualitätssicherung ist ein kreativer Job. Die Aufgabe besteht wirklich darin, darüber nachzudenken, woran die Entwickler nicht gedacht haben. Aus diesem Grund sollte die Qualitätssicherung automatisiert werden. Sobald ein Test gedacht ist, sollte er nicht mehr wie ein Broadway-Stück "durchgeführt" werden. Es sollte automatisiert werden, damit die Qualitätssicherung nicht mehr darüber nachdenken und über den nächsten Test nachdenken kann. Die Qualitätssicherung sollte mit Ihren talentiertesten Entwicklern durchgeführt werden. Weil sie versuchen, Ihr anderes Entwicklerteam zu überdenken.

Einige glauben das nicht. Einige betrachten die Qualitätssicherung als Müllhalde für weniger talentierte Entwickler. Wenn Sie das getan haben, sind Ihre Prioritäten rückwärts. Fordern Sie Ihre besten Entwickler auf, Ihre Tests zu modernisieren und sicherzustellen, dass die Leute wissen, dass Sie bei der Qualitätssicherung das Beste einsetzen.

Wenn dieses Geld immer noch ein Loch in Ihrer Tasche brennt, verwenden Sie es für Schulungen oder bei Bedarf für Abfindungen Pakete.

Wir machen hier keine sinnlose Arbeit.

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

Das ist schrecklich. Aus all den Gründen in den anderen Antworten und für die Tatsache, dass dieser sehr einfache Test nicht bestanden wird:

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

  Die Produktion funktioniert einwandfrei und das gesamte Geld geht an die DEVS.

• Was ist, wenn alle Ihre Mitarbeiter Mist sind?

  Die Produktion hat gerade gebrannt der Boden wegen der Fehler, aber hey, wen interessiert das, das Geld wird an die DEVS gehen.

Selbst wenn Geld ein Motivator wäre In unserem Geschäft 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 jedes Geld sie jemals verdienen könnte.

Es mag apokryphisch sein, aber ich habe in den 1980er Jahren ein ähnliches Beispiel erhalten, als ich das "Gesetz der unbeabsichtigten Folgen" als Teil eines BPR-Kurses behandelte.

Das Beispiel betraf eine Fabrikproduktionslinie, in der die Die Qualitätskontrollabteilung wurde durch die Anzahl der Ablehnungen motiviert. Die Produktionsabteilung erhielt ähnliche Anreize, je nachdem, wie wenig Ausschuss sie produzierte.

Der Nettoeffekt bestand darin, dass die Qualitätskontrolle mehr Produkte als zuvor ablehnte und die Produktion länger dauerte, um "perfekte" Artikel zu produzieren, sodass die Gesamtproduktion währenddessen zurückging Die Kosten stiegen aufgrund der Anreizzahlungen. Die Qualität wurde nicht beeinträchtigt.

Es funktioniert schlecht. Ich habe es mit Entwicklern und Testern nicht gesehen. Das Justizministerium in Neuseeland belohnte jedoch zu einem bestimmten Zeitpunkt regelmäßige Haftaufseher für jeden Häftling, gegen den sie verstoßen hatten. Es ging von einer Verletzung in einer schlechten Woche bis zu einigen Häftlingen, die 6 Verstöße an einem Tag bekamen und darüber im Gefängnis landeten. Irgendwann wurde ein Aufseher verletzt.

Ich bezweifle, dass es so weit gehen würde, da es nicht die gleiche Menge und weniger flüchtige Menschen sind (würde ich denken), aber es erzeugt schlechtes Blut zwischen den Gruppen, die bereits uneins sind zu ihren Rollen.

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

Sie versuchen, Geld an die letztendlich auf einem Papier angegebene Zahl anzuhängen. Diese Zahl wird kein Geld schaffen. Um die Sache noch schlimmer zu machen, ist die Anzahl, die Sie verwenden möchten, meistens zufällig: Ein Produkt, das nie einen Fehler hatte, hat plötzlich 50, alles Tippfehler in der Dokumentation. Ein Fehler, der die Hervorhebungsfarbe von 200 Elementen durcheinander bringt, wird zu 200 Fehlern. Sobald Sie einige Leute bitten, die Zahl auf magische Weise zu erhöhen, ist diese Zahl eine völlig nutzlose imaginäre Zahl. Und obendrein verschwenden Sie Zehntausende von Dollar an Löhnen mit absolut sinnlosen Treffen, bei denen die Leute darüber streiten, was ein Fehler ist und was nicht.

Wenn Sie Zahlen auf einem Papier mit Boni oder anderen Belohnungen versehen möchten, müssen diese Zahlen direkt mit dem tatsächlichen Geld verknüpft sein, das das Unternehmen verdient. Ein häufiges Beispiel ist, dass der Bonus mit dem Gewinn eines Handelsunternehmens verknüpft ist.

Wie in den "Cupcake" -Kommentaren unter Ihrer Frage vorgeschlagen, können einige Formen der Gamifizierung funktionieren. Wie wäre es, wenn Sie eine Trophäe für den 'Best Bug' vergeben, der in einem bestimmten Zeitraum gefunden wurde und durch Stimmen von beiden Teams zusammen vergeben wird?

In einer gesunden Entwicklungsumgebung herrscht eine gemeinsame Ehrfurcht 'zwischen Testern und Entwicklern über Leute (normalerweise die Tester), die diese lästigen Fehler finden, die nur unter bestimmten Bedingungen reproduziert werden können, über diesen zeitweiligen Fehler, der Sie seit Monaten belästigt, über etwas sehr Einfaches, das ein Entwickler übersehen hat usw. ^{* sup>}

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

^{* In diesem letzten Beispiel geht es nicht darum, einen Fehler zu finden, sondern einen Fehler zu verursachen. In diesem Fall bedeutet der Preis freundliche Verspottung. Dafür brauchen Sie eine Kultur, in der Ihre Kollegen erkennen, dass jeder Fehler macht. Sup>}

Ich denke, das Ergebnis wäre nachteilig. Es widerspricht sowohl dem gesunden Menschenverstand beim Entwickeln als auch beim Testen.
Keine gefundenen Fehler bedeuten nicht, dass Software gut ist. Das Testen könnte zu komplex sein oder die Qualitätssicherung könnte einige Tests überspringen. Selbst keine gefundenen Fehler, umfangreicher Testprozess und gute Codequalität bedeutet nicht, dass das Produkt gut ist. Wenn die Anforderungen durcheinander gebracht wurden, kann die Software für den Client schrecklich sein.

Das Spielen gegen dieses System kann extrem einfach sein.
Für Entwickler: späte Builds. Für Tester: Konzentration auf triviale Fehler.
Bei späten Builds ist ein frühes Testen unmöglich. Wenig Zeit zum Testen und zur Befriedigung der Anzahl der Fehler? Tester konzentrieren sich auf triviale Fehler wie falsch geschriebene Etiketten oder einige unkritische Fälle.
Wenn Sie wissen möchten, ob das Produkt gut ist, fragen Sie einfach Ihren Kunden.

Lange Rede, kurzer Sinn. Entwickler und Tester arbeiten an demselben Boot - Ihrem Unternehmen.

Es ist leicht, Entwickler für einen Fehler zu kritisieren, den sie produzieren, aber es ist schwierig, sie für Fehler zu belohnen, die sie nicht produziert haben.

Wenn der Fehler den endgültigen Build erreicht hat und der Kunde ihn gemeldet hat, wer sollte dafür verantwortlich gemacht werden? Entwickler, um den Fehler zu schreiben, oder Tester, um ihn nicht zu erkennen?

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

Wenn Sie einen freundlichen Arbeitsbereich haben und das Auffangen von Fehlern belohnen möchten, teilen Sie das Budget fair auf alle auf, erstellen Sie eine Liste der Entwickler, und für jeden Fehler zahlt der Entwickler 1 US-Dollar an die Bank. Organisieren Sie die Weihnachtsfeier und nutzen Sie die Bank, um das gesamte Team zu belohnen. Stellen Sie sicher, es macht mehr Spaß als Belohnung / Bestrafung und niemand nimmt es (zu) ernst. Belohnen Sie sowohl die "schlechtesten" als auch die "besten" unter Entwicklern und Testern.

Ehrlich gesagt scheint der Anreiz bestenfalls nutzlos und schlimmer noch schädlich zu sein. Wenn Sie ein engagiertes QS-Team haben, haben Sie bereits Mittel für die Suche nach Fehlern bereitgestellt, da dies einen großen Teil der Stellenbeschreibung ausmacht. Es wird nicht viel zusätzlichen Gegensatz zwischen den beiden geben, da es mehr in Richtung der Politik selbst geben wird. Wenn Sie sich tatsächlich Sorgen über das Problem machen, dass Ihre derzeitigen Mitarbeiter viel Geld mit Bedingungen verdienen, ist es besser, jemanden einzustellen, bei dem Sie ihn entweder in der Qualitätssicherung oder in der Entwicklungsabteilung benötigen.

Wo könnte das wirklich hingehen? Falsch ist auf der Entwicklerseite, dass Sie einen Rückgang der Veröffentlichungen sehen, aus Angst, dass sie aufgrund neuer Fehler weniger bezahlt werden, und auf der QA-Seite könnten Sie viel längere Überprüfungsphasen sehen, weil Tester zusätzliche Bezahlung wünschen. Nicht zu sagen, dass dies passieren wird , nur dass es eine Möglichkeit ist.

Niemand möchte Fehler in seinem Endprodukt, aber das wird 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, und eine bessere Entwicklung wie Codeüberprüfungen zu ermöglichen.