Als Manager eines 20-köpfigen Software-Engineering-Teams möchte ich gerne etwas Spaß bei der Arbeit einbringen. Dies dient hauptsächlich dazu, eine gute Teamsynergie, Spaß, Motivation und gegenseitige Kommunikation in ein Team zu bringen, dem all dies fehlt.
Ich selbst habe Gamification- Videos wie die Radarkamera-Lotterie durchgesehen und war inspiriert, so etwas in meinem Team auszuprobieren. dh positives Verhalten zu belohnen, anstatt Menschen mit vielen Parametern zu zwingen, sie zu bewerten.
Was ich gerne vorstellen möchte, ist ein System, mit dem ich diese Art der Anerkennung von positivem Verhalten auf unterhaltsame Weise ankurbeln kann. Zum Beispiel würde ich zunächst damit beginnen, allen Ingenieuren einen Startpunkt von Punkten zuzuweisen, sagen wir jeweils 100, und sie müssen Punkte ausgeben und auch Punkte von anderen verdienen, indem sie anderen helfen, kommunizieren oder motivieren.
Als einfacher Fall kann ein Entwickler beispielsweise eine E-Mail mit einer Frage senden, um ihm oder ihr zu helfen, die Frage, die er dem Kunden stellen wird, neu zu formulieren, und wird einen Wert festlegen, dh jedem 10 Punkte geben wer hilft.
Helfen Sie mit, diese E-Mail zu lesen, die ich an den Kunden über die Dashboard-Funktion sende. 10 Punkte werden an denjenigen vergeben, der mir dabei hilft. Mit freundlichen Grüßen -O
Ich möchte, dass all dies innerhalb eines E-Mail-Systems ausgetauscht wird, aber es macht mir nichts aus, wenn dies durch eine vorhandene Weblösung erreicht werden kann. Der wichtige Teil ist das lustige Element, die Punkte einzutauschen und sie mir am Ende des Monats wieder einzulösen, um eine Art Geschenk oder einen Essensgutschein zu erhalten. Ich weiß, dass die Idee zu einem eigenen Projekt wird, da alle anderen Fälle behandelt werden müssen.
Hat jemand ein solches System an seinem Arbeitsplatz eingeführt? Welche Systeme werden verwendet oder kommen dem nahe, was ich erreichen möchte?
Aus Sicht eines Lesers bin ich möglicherweise nicht klar, also zögern Sie nicht, mich nach weiteren Informationen zu fragen. Danke im Voraus.
Gamification ist von Natur aus wettbewerbsorientiert, was im Gegensatz zum Konzept „Erfolg oder Misserfolg als Team“ steht, das vielen agilen Methoden zugrunde liegt. Das bedeutet nicht, dass es eine schlechte Idee ist; es bedeutet nur, dass es nicht gut für die Verwendung mit Frameworks wie Scrum oder Extreme Programming geeignet ist. Ihr Kilometerstand kann mit anderen Methoden variieren.
Laut einem Wikipedia-Artikel über Gamification-Techniken (Hervorhebung von mir):
Gamification-Techniken streben danach, die natürlichen Wünsche der Menschen nach Wettbewerb, [persönlicher] Leistung, Status , Selbstdarstellung, Altruismus und Abschluss zu nutzen.
Das kann ganz gesund sein, aber Konkurrenz- oder Statusstreben widerspricht der selbstorganisierenden, teambasierten Struktur von Scrum. Abgesehen davon ist es sicherlich möglich , ein Punktesystem zu strukturieren, das Zusammenarbeit, Mentoring, Wissensaustausch, Schwärmen und Pair-Programming belohnt, aber meiner persönlichen Erfahrung nach habe ich festgestellt, dass Teams, die diese Ziele verfolgen, die Praktiken oft als ihre eigenen empfinden eigene Belohnung.
Anstatt individuelle Leistungen zu fördern, konzentriere ich mich eher auf teambasierte Belohnungen. Besonders beim Übergang von Command-and-Control zu Agilität habe ich es oft als hilfreich empfunden, das Team mit Mittagessen oder Pizzapartys für Dinge wie Totpunktschätzungen oder das Ausschwärmen einer späten Geschichte mit „alle Mann an Deck“ zu belohnen um innerhalb des aktuellen Sprints fertig zu werden.
Es ist wichtig, keine Anreize für falsches Verhalten zu schaffen, wie z. B. das Auffüllen von Schätzungen oder das Verschwören von Minderleistung unter der Teaming-Rubrik. Dies wird jedoch im Allgemeinen durch routinemäßige, ehrliche Retrospektiven erledigt, die eine Bewertung der Metriken selbst beinhalten.
Wie bei jeder anderen Projektmanagementkontrolle variiert der Nutzen der Technik zwischen den Teams und zwischen den Unternehmenskulturen. Sie werden in der Regel auch das bekommen, was Sie messen. Stellen Sie also sicher, dass die Spielregeln mit Ihren beabsichtigten Zielen übereinstimmen, und überprüfen Sie kontinuierlich, ob die Steuerung wie vorgesehen funktioniert.
Wenn Sie kein Scrum-Shop sind oder keine Retrospektiven durchführen, benötigen Sie möglicherweise andere Kontrollen, um Ihre Gamification-Kontrollen zu überwachen. Das bedeutet nicht, dass es sich nicht lohnt, es zu tun, aber es bedeutet , dass das Problem wahrscheinlich komplexer ist, als es oberflächlich erscheint.
Wie immer beim Projektmanagement kann Ihre Laufleistung variieren.
Robert Austin hat ein kurzes, niederschmetterndes kleines Buch geschrieben, Measurement and Managing Performance in Organizations , das sauber demonstriert, warum und wie die meisten persönlichen Messsysteme dazu verdammt sind, entweder bestenfalls verzerrend oder schlimmstenfalls aktiv dysfunktional zu sein.
Das Problem ist, dass Sie die persönliche Messung einführen. Unter ausgewählten Umständen kann das sehr gut funktionieren. Besteht jedoch auch nur der Verdacht einer Andeutung einer Chance, dass damit jemals eine Belohnung oder Bestrafung verbunden sein wird, wird das System ausgetrickst. Wenn das System gespielt wird, haben Sie jetzt zwei Probleme.
Erstens sind alle aus dem System abgeleiteten Informationen irreführend. Es sagt Ihnen Dinge, die nicht wahr sind; wenn Sie danach handeln, können Sie kostspielige Fehler machen.
Zweitens verfälschen Sie den Arbeitsmix, der erledigt wird. "Was gemessen wird, wird getan". Wenn Sie nicht alle wichtigen Dimensionen messen können (Austin nennt das „Total Supervision“), verzerren Sie die Arbeitsmischung. Die Einführung neuer Metriken behebt dies nicht, da in der Praxis jede Mischung entweder auf die „wahren“ Metriken zusammenbricht, die das Management eindeutig bevorzugt; oder es wird eine Indexmetrik erzeugt, die selbst maximiert werden kann, indem die Aktivität an die Gewichtungen in der Indexmetrikfunktion angepasst wird.
Es gibt auch, wie CodeGnome betonte, das Problem des Wettbewerbs. Insofern irgendein System ein Nullsummenspiel einrichtet (ich gewinne, muss ein anderer verlieren), schafft es einen rationalen Hemmschuh für die Zusammenarbeit zwischen Spielern. Aber Software ist in der Regel ein kooperatives Unternehmen.
Der Einsatz von Teamanreizen löst das Nullsummenproblem, löst aber nicht die Probleme irreführender Informationen und verzerrter Bemühungen.
donnerstagsgeek
Todd A. Jacobs
Eine Welt
Eine Welt
Mike Petty