Abzeichen für Projektteammitglieder zur Motivation

Wenn dies ein Projekt ist, für dessen Arbeit derzeit Leute bezahlt werden: ABSOLUT NICHT!

Zuallererst sollten die Ziele des Projekts klar und offensichtlich sein, und bei einem Softwareprojekt können diese Ziele bereits kompliziert sein. Liefern Sie rechtzeitig gründliche Designs ein, stellen Sie den Code pünktlich mit so wenigen Fehlern wie möglich fertig, integrieren Sie Feedback aus Codeüberprüfungen, beheben Sie die Unit-Tests, die Sie bei der Arbeit an dieser neuen Funktion abgebrochen haben, lassen Sie neue Unit-Tests rechtzeitig durchführen, erhalten Sie Dokumentations-/Dokumentationsnotizen pünktlich erledigt.

Wollen Sie jetzt noch ein paar „schwammige“ Ziele hinzufügen, die Sie in Nr. 3 erwähnt haben? „Objektivieren“? Wenn Sie dafür ein Abzeichen vorschlagen, bevor Sie Ihren ersten Sprint beenden, werden Sie es bereuen, jemals auf diese Idee gekommen zu sein. Die Leute werden argumentieren, dass ihre Objektivierung besser ist als die Objektivierung eines anderen. Dafür wird jede Menge Zeit verschwendet. Und im schlimmsten Fall: Die Leute werden anfangen, persönlich zu werden, weil jemand ihre Objektivierung nicht mochte. Ziele wie „Organisation“ und „Standardisierung“ sind ebenso unscharf.

Sie haben bereits genug Ziele. Lassen Sie Ihre Entwickler allein, um diese zu erreichen. Sie möchten nicht, dass die Leute Zeit damit verbringen, Abzeichen zu jagen (für die Ihre Organisation keine Anerkennung erhält). Sie wollen, dass sie versuchen, echte Ziele zu erreichen.

StackExchange kann diese Abzeichen verwenden, da wir dafür nicht bezahlt werden. Und wenn es nicht getan wird, verliert nur StackExchange (obwohl sicherlich die Gemeinschaften von dieser Ansammlung von Wissen und Menschen profitieren). StackExchange verfügt auch über einen automatisierten Prozess zur Vergabe von Badges. Wie automatisieren Sie die Vergabe des „Gestaltungs“-Abzeichens? Du kannst nicht. Sie werden also viel Zeit damit verbringen müssen, es manuell zu tun.

Entwickler sind berüchtigt dafür, jedes System zu spielen, das Sie ihnen vorsetzen. Das Spielen von Systemen führt oft zu Energieverschwendung und verfehlt den Sinn (eigentliche Ziele). Ihre aktuellen Ziele sind wichtig und hart genug. Sorgen Sie dafür, dass sich Ihre Mitarbeiter auf sie konzentrieren.

Es gibt bereits viele Theorien und Studien zum Thema Motivation. Extrinsische Motivatoren wie Abzeichen, Auszeichnungen und Geld wurden untersucht, und ich glaube, die Ergebnisse zeigen, dass sie bestenfalls marginal sind, nichts bewirken oder vielleicht sogar die Motivation verringern. Die stärksten Motivatoren sind intrinsisch und sind Beherrschung, Zweck und Autonomie.

Folge der Wissenschaft....

Ist es eine gute Idee?

Wie bei fast allem: Es hängt alles von Ihrem Team ab.

Einige mögen sehr empfänglich sein, andere absolut nicht. Wenn wir von einem internen Team sprechen, würde es meiner Meinung nach leichter mit Leuten funktionieren, die Ihnen bereits vertrauen und die einen gewissen Sinn für Humor haben, da sie mit etwas fertig werden müssen, das nicht korporativ und daher unpersönlich aussieht auf den ersten Blick für manche vielleicht „unprofessionell“. Ich persönlich hatte dieses Problem, als ich versuchte, einige andere lustige, aber ernsthafte Artefakte zur „sozialen Verbesserung“ hinzuzufügen, und mich zurückzog, als ich merkte, dass das Team nicht aufgeschlossen war und es eher als ein Spiel betrachtete, das ich spielen wollte, als als ein wirklich nützliches PM-Praxis.

Tun andere das?

Nun, nicht gerade Abzeichen , aber in die gleiche Richtung und sicherlich beeindruckender ;) Schauen Sie sich zum Beispiel die Swords and Shields Ceremony bei Blizzard an.

Metriken

• Codierung: Dies ist keine Metrik (was genau messen Sie?).
• Commitment: Dies ist eine schlechte Metrik, Quantität bedeutet nicht Qualität, und bei Software ist es normalerweise das Gegenteil.
• Aufgaben rechtzeitig erledigen: möglich, aber auch im Rahmen des Umfangs und so, dass die Fertigstellung nicht auf so schreckliche Weise erfolgt ist, dass sie später Fehler aufwirft…
• …

Eigentlich höre ich hier auf. Darauf wurde bereits eingegangen .

Sie müssen beachten, dass das gesamte SE-Reputations- und Abzeichensystem auf einer Gemeinschaft von Menschen beruht, die Dinge bewerten . Die einzige Automatisierung, die stattfindet, ist das Zählen von Punktzahlen und das Zuordnen von Badges zu dieser Punktzahl.

Für Tester dürfte es etwas einfacher sein. Die Menge der entdeckten Fehler, möglicherweise gewichtet nach Schweregrad, könnte eine einfache Metrik sein. Sie können auch die Zeit vor dem Bericht als weitere Metrik betrachten.

Philosophische Überlegungen

Ein solches System ist einfach ein Reputationsmodell und damit ein Weg, die menschliche Vertrauenszuschreibung zu vereinfachen . Damit ein solches System jedoch funktioniert, muss es Ereignisse genau abbilden, die Mitmenschen als beeindruckend oder zumindest in gewisser Weise als gut anerkennen würden.

Und ich fürchte, genau hier stoßen Sie an die Grenze der Automatisierung. Nach dieser genauen Definition können automatisch berechenbare Metriken nicht berechnen, wie gut kreative Arbeit ist. Computer sind sehr gut darin, Dinge zu berechnen, nicht wirklich, um kreative Arbeit zu bewerten. Und Programmieren ist kreative Arbeit.

Daher glaube ich nicht, dass ein solches System tatsächlich nachhaltig wäre, um Beiträge zu verlangen, da es schnell Zweifel darüber aufkommen lassen würde, welche Metrik verwendet wird. Alles andere als die Bewertung durch Mitmenschen wird höchstwahrscheinlich von anderen Programmierern missachtet, wodurch die eigentliche Absicht, die Reputation zu verbessern , zunichte gemacht wird . Es könnte sogar den gegenteiligen Effekt haben, abhängig von den verwendeten Metriken ( „Gold Contributor? huh, dieser Typ hat höchstwahrscheinlich 30 beschissene Commits gemacht …“ ).

Also, lassen Sie uns schließen. Das Hinzufügen eines Badge-Systems ist ein cooles Goodie, das eine solche Bewertung vereinfacht, indem es diskrete Schritte zu einem kontinuierlichen Bewertungsspektrum hinzufügt, aber damit es eine Bedeutung hat, müssen Sie sicherstellen, dass die Art und Weise, wie sie zugeschrieben werden, einvernehmlich ist. Dafür denke ich, dass die einzig gültige Metrik die Peer-Bewertung ist . Dies ist nur bei Projekten mit einer soliden Community zuverlässig zu erreichen.

Daher würde ich raten, zweimal darüber nachzudenken, bevor Sie dieses Belohnungssystem ausprobieren, da es ziemlich leicht missachtet werden könnte, wodurch Sie Anstrengungen verschwenden und dumm dastehen oder sogar eine Gegenreaktion auslösen, wenn eine Teilmenge der Bevölkerung davon überzeugt ist, aber keine andere, wodurch Ihre Community segmentiert wird / Team.

Betrachtet man dies von der Seite eines Programmierers, gibt es einige Dinge, die getan werden können, und einige potenzielle schlechte Dinge, die lauern.

Zuerst die schlechten Dinge - Sie wollen schlechte Praktiken nicht fördern. Was mir aufgefallen ist, war "Anzahl der Commits". In der Tat ist es schlecht, alles als nur einen Commit einzureichen, aber es ist genauso schlecht, einen Commit pro Datei einzureichen (oder einen Commit, um den Kommentar zu ändern, einen anderen Commit, um den Code zu ändern). Im Idealfall werden Commits mit einer logischen Gruppierung durchgeführt – wenn es ein Commit ist, ist es eines, wenn es 20 sind, sind es zwanzig. Aber zu versuchen, eine „ideale“ Anzahl von Commits zu finden, ist Torheit.

In ähnlicher Weise habe ich gesehen, wie Ziele für das Melden von Fehlern schlecht wurden. Wenn man eine bestimmte Anzahl von Fehlern belohnt (oder verlangt), dann findet man statt „dieser Fehler tritt unter diesen Umständen auf“ „dieser Fehler tritt unter diesen Umständen auf Seite A auf“, „dieser Fehler tritt unter diesen Umständen auf Umständen auf Seite B", ... "dieser Fehler tritt unter diesen Umständen auf Seite Z auf". Und es werden Dutzende weitere Fehler gemeldet, die niemandem helfen (es hat Zeit verschwendet, Zeit des Melders und der Person, die die zusätzlichen Fehler priorisieren muss, und der Person, die sie beheben muss, und der Person, die schließen muss Sie).

Das Messen von geschriebenen Codezeilen ist ebenfalls eine fehlerhafte Metrik. Stellen Sie sich vor, Bill Atkison schreibt -2000 Codezeilen

Als das Lisa-Team 1982 darauf drängte, seine Software fertigzustellen, forderten Projektmanager von den Programmierern, wöchentliche Formulare einzureichen, in denen die Anzahl der von ihnen geschriebenen Codezeilen gemeldet wurde. Bill Atkinson fand das albern. Für die Woche, in der er die Regionsberechnungsroutinen von QuickDraw so umgeschrieben hatte, dass sie sechsmal schneller und 2000 Zeilen kürzer waren, trug er „-2000“ in das Formular ein. Nach ein paar weiteren Wochen forderten ihn die Manager nicht mehr auf, das Formular auszufüllen, und er kam gerne nach. (aus Computer History auf QuickDraw )

Sehen Sie sich für eine mögliche Lösung das Jenkins Continuous Integration Game Plugin an, bei dem der Build-Server die statischen Analyseinformationen eines Builds untersucht und Punkte für eine Reihe von Dingen (Codestil, Codierungspraktiken, Komponententests, Compiler-Warnungen) vergibt (oder subtrahiert). Beachten Sie, dass all diese Dinge programmatisch sind und keine menschliche Interaktion oder Beurteilung beinhalten.

Trotzdem ist es interessant zu sehen, wie ich auf der Registerkarte „Lokal erstelltes CI-Spiel“ abschneide. Aber ich "spiele" es nicht. Ich bemühe mich, guten Code zu schreiben, weil ich will, dass es guter Code ist, nicht weil ich Punkte oder ein Abzeichen bekommen würde.

Ich würde die Idee mit Ihrem Team teilen und sie nach ihrer Meinung fragen.

Sie können dies auf verschiedene Weise tun:

• Bitten Sie Ihr Team, Ideen darüber auszutauschen, wie die Arbeit gamifiziert werden kann; schlagen Sie dann Ihre Idee vor

• Fragen Sie Ihr Team direkt, was es von Ihrer Idee hält

• Bitten Sie um Erlaubnis, ein 30-Tage-Experiment durchzuführen, um zu sehen, wie es funktioniert
• ...

Tatsache ist, dass keiner von uns das jemals zuvor versucht hat. Vor allem in Ihrem Team. Es ist alles Vermutung. Aber wenn Ihr Team offen dafür ist, neue Dinge auszuprobieren – machen Sie es und seien Sie der Erste, der die Idee bei der Arbeit ausprobiert, und teilen Sie Ihre Erkenntnisse.

Ich kenne die Managementtheorie dazu nicht, aber ich wäre äußerst vorsichtig, Abzeichen auf die von Ihnen beschriebene Weise einzuführen. Wenn ich ein Team zusammenstelle, um ein Produkt zu liefern, möchte ich, dass jeder das beste Gesamtteamergebnis erzielt – was auch immer das bedeutet – anstatt als Einzelpersonen zu konkurrieren und sich möglicherweise gegenseitig zu untergraben / nicht zu helfen.

Die einzige Möglichkeit, wie ich mir vorstellen könnte, dass ein solches System funktioniert, wäre, dass die Leute Abzeichen vom Rest des Teams erhalten, und nicht, indem sie willkürliche Ziele mit unklarem Wert erreichen. Vielleicht wäre es ein Verdienst, ein „Hilfreich“-Abzeichen oder eine „Großartiger Beitrag“-Auszeichnung oder ein „Problemlöser“-Zertifikat zu erhalten – aber machen Sie es nicht zu einem Wettbewerb. Teams ziehen an einem Strang – Spieler können um die Mitgliedschaft im Team konkurrieren, aber wenn sie erst einmal dabei sind, sollten sie füreinander arbeiten.

Vorsichtig sein! Es gibt eine feine, subjektive Grenze zwischen Motivieren und Manipulieren. Wenn Ihr Team entscheidet, dass dies letzteres ist, können Sie sein Vertrauen möglicherweise nicht zurückgewinnen.

Sind Sie sicher, dass Sie nicht tatsächlich versuchen, sie zu manipulieren? Es klingt irgendwie so, als würden Sie nicht glauben, dass sie ohne mehr Motivation gute Arbeit leisten werden. Aber dass ihnen imaginäre Belohnungen diese Motivation liefern. Basierend auf Metriken zur Projektqualität, die Sie entwickeln möchten. Was impliziert, dass Sie glauben, dass Sie die Projektqualität besser messen können als Ihr Team (warum sonst versuchen, ihr Verhalten zu ändern, wenn sie besser als Sie wissen, wie ihr Verhalten sein sollte?).

Entschuldigung, aber wenn ich Sie wäre, würde ich hoffen, dass mein Team diese Frage nicht gefunden hat.

Die in anderen Antworten angegebenen Gründe, dass dies eine schlechte Idee ist, sind größtenteils wahr, aber ich denke, sie verfehlen das Gesamtbild. Das größte Problem bei einem solchen Ansatz ist, dass Sie das Team als eine Gruppe von Einzelpersonen und nicht als Team behandeln. Sie wollen Teamauszeichnungen erteilen? Genial. Aber Sie sollten Ihr Team niemals absichtlich so aufteilen.

Ich habe immer noch das Gefühl, dass jedes Spielsystem den Fokus von der Entwicklung weg verlagert und einen starken Individualismus innerhalb der Organisation einführt . Gamification wurde in Anwendungen eingeführt, um das Spiel zu nutzen, um die Kunden zu halten. Sie kehren teilweise wegen des Spielerlebnisses zu Ihren Diensten zurück .

Nehmen wir zum Beispiel Diablo 3. Das Erhalten von Abzeichen bringt Sie dem endgültigen Ziel nicht näher, und um einige davon zu erhalten, müssen die Spieler viele unnötige Aktivitäten ausführen, und es ist immer noch eine Einzelaufgabe. Zurück zur Softwareentwicklung: Was verhindert das Erscheinen unnötiger Kommentare, Commits, Refactorings und Features?

Sie können Belohnungen für gemeinsame Aktivitäten haben, um das Problem der Solo-Erfolge zu lösen, aber diese waren wirklich schwer zu verfolgen, und Sie brauchen auf jeden Fall einen Wildhüter. Oder zwei.

Ich bin nicht dafür, solche Dinge einzusetzen, um die Leute zu motivieren und die Projekte voranzubringen. Gamification kann jedoch bestimmte Teile wie Wissensaustausch (z. B. FedEx-Beispiel ) und Bildung (z . B. Codeschool ) verbessern.

Ein persönliches Beispiel. Mit der Agile Trophy habe ich 2010 versucht, Menschen zu mehr Agilität zu motivieren . Ich habe sie an den Kollegen überreicht bekommen, der unter der Woche den wertvollsten Beitrag zu unserer agilen Arbeitsweise geleistet hat. Die Zeremonie hat Spaß gemacht – wir haben sie während des wöchentlichen Mitarbeitertreffens gemacht – die Person, die die Trophäe bekommen hat, war stolz darauf, aber nicht alle haben gespielt. Zum Teil, weil sie sich nicht um meine blöde Trophäe kümmerten, oder ihnen die Regeln nicht gefielen, oder weil sie es schwer fanden, sie zu bekommen (ich habe die Trophäe nicht für einen guten Kommentar während eines täglichen Standup-Meetings ausgegeben). Die Idee war ziemlich schnell tot, brachte die Projekte nicht voran, und kaum jemand erinnert sich daran, aber es hat Spaß gemacht :-)

Im Gegensatz zu Kent denke ich, dass dies eine interessante Idee ist, die funktionieren könnte. Der Vorbehalt ist, dass Sie dieses Tool in andere HR-Praktiken integrieren müssen. Dies könnte dann in Boni, Werbeaktionen usw. einfließen. Beispielsweise kann ein Entwickler das Ziel haben, im Durchschnitt über ein Jahr X Bronze-Abzeichen pro Projekt zu erreichen. Diese Ziele müssen erfüllt werden, um einen Bonus von A % zu erhalten, aber wenn Sie Holen Sie sich Ihren X-Bronze-Durchschnitt pro Projekt und Y-Silber, und Ihr Bonus steigt.

Das Fazit ist meiner Meinung nach, dass Sie einen soliden, integrierten Plan für die Umsetzung mit sehr klaren Standards und der Zustimmung der Unternehmensleitung benötigen. Die Verwendung einer Population von unverbundenen Anreizen ist ein Rezept für Verwirrung und Katastrophe.

Es ist eine interessante Idee, und ich konnte sehen, wie es zunächst eine gute Idee zu sein schien. Aber ich würde davon abraten. Zum Teil, weil ich denke, dass es auf einer grundlegend fehlerhaften Grundlage basiert. Ich weiß für mich, die Abzeichen bieten überhaupt keine Motivation. Sie sind einfach ein Nebenprodukt des Versuchs, Fragen so zu beantworten, wie andere es hilfreich finden. Mein Ranking motiviert mich, da es bedeutet, dass ich Wert biete.

Das zweite Problem ist, dass die Idee, na ja, sorry, aber ein wenig "Grundschule" erscheint. Sie sprechen hier (vermutlich) von einem Team aus Erwachsenen und Profis. Ich bezweifle die Notwendigkeit, auf diese Weise zu motivieren. Es ist fast das Gegenteil des Spiels, das Kent erwähnt hat – Sie spielen das Team, um es zu motivieren? Ist das wirklich notwendig?

Nein, ich verstehe, warum Sie vielleicht in diese Richtung gehen, aber wenn Sie das Gefühl haben, dass es wirklich notwendig ist, dann haben Sie meiner Meinung nach ein größeres Problem. Sie müssen sich ansehen, „warum“ Sie der Meinung sind, dass eine Motivation so notwendig ist, und dieses Problem ansprechen. Warum braucht Ihr Team zusätzliche Motivation, um seine Arbeit außerhalb der bestehenden Situation zu erledigen?

Der Softwareentwicklungsprozess ist eine Teamarbeit, und die Messung der Produktivität einzelner Personen anhand einiger objektiver Ziele könnte der Teambindung/-dynamik entgegenwirken. Ich schlage vor, wenn Sie Einzelpersonen belohnen möchten, machen Sie es zu einer jährlichen Aktivität, die auf Beiträgen zum Projekt basiert, die einen signifikanten Unterschied gemacht haben.

100 Check-Ins mit nutzlosem Code will man nicht belohnen, aber 1 Check-In, der die Leistung der Software verbessert hat, sollte belohnt werden.

Wir hatten Übung, um die Produktivität von Einzelpersonen zu messen und dann Gehaltserhöhungen mit dieser Produktivitätszahl zu gewähren, und das war für uns kontraproduktiv. Die Menschen hörten auf, miteinander zu kooperieren, da die Hilfe für andere ihre Produktivität steigern würde.