Welche Probleme der Teamführung können mit Hilfe des Spiels gelöst werden

Hallo allerseits! Mein Name ist Jewgeni Rtischschew, in Sbertekh arbeite ich als Leiter der Entwicklung von IT-Systemen an den Projekten des Unified Frontal Systems. Am 24. September sprach ich auf der Konferenz Saint Teamlead Conf 2018 in St. Petersburg. In meinem Bericht ging es um das Spiel im Team, das meine Kopfschmerzen als Führungskraft erheblich linderte und mir Motivation und Disziplin verlieh. Das Publikum nahm das Thema sehr herzlich an und stellte viele interessante und wertvolle Fragen.

Es schien mir, dass einige Punkte im Bericht übersehen wurden. Deshalb habe ich mich in dem Artikel entschlossen, noch einmal über mein Experiment zu sprechen und die Ergebnisse zu teilen. Wer noch nicht an der Konferenz teilgenommen hat und eine Geschichte über ein alternatives Tool für eine schnelle Leistungsüberprüfung, die Führung eines Teams durch ein Spiel, eine stärkere Beteiligung an der Produktentwicklung und die Kombination der Konzepte "Gamification" und Bürokratie in großen Unternehmen lesen möchte - willkommen .

Intro

Als nächstes wird es ein konsequentes Geschichtenerzählen über mein Werden als Teamleiter geben, über bewusste Probleme und gemachte Fehler. Ich werde es nicht verbergen - die Lösung besteht darin, ein spezielles Teamspiel einzuführen. Wenn Sie also nicht den Wunsch und das Interesse haben, 10 bis 15 Minuten Ihrer kostbaren Zeit zu verbringen, können Sie zum Abschnitt "Jetzt wird jeder MotC abbauen" springen und direkt über die Essenz des Spiels, Fehlkalkulationen in Balance und Anpassung lesen sowie was daraus wurde.

Probleme und Schmerzen

Als ich nach Sberteh kam, startete ein neues internes Programm, und es war notwendig, schnell ein mobiles Entwicklungsteam zusammenzustellen. Einen Monat nach meiner Abreise kündigte mein Manager (der mich anstellte) und alle seine Aufgaben und Probleme wurden meine. Ehrlich gesagt hatte ich vorher ein Jahr lang wenig Erfahrung in der Leitung eines Zwei-Personen-Teams. Es war eher wie technisches Mentoring und Mentoring neuer Entwickler. Das Team wurde schnell auf 11 Personen erweitert. Ich habe es völlig vermieden, Code zu schreiben, Architektur zu entwickeln und andere schwierige Aufgaben zu erledigen. Ich wurde anfällig für Emotionen und meine Managementprinzipien entsprachen dem Situationsmanagement. Ich musste längerfristig aussehen, Leute im Team entwickeln, neue Führungskräfte erziehen, diejenigen markieren und ermutigen, die gut ziehen können, und auch „böse Jungs“ und faule Leute identifizieren und bestrafen.

Ich sah einen Ausweg in der Einführung von Elementen des regulären Managements. Das heißt, brauchte ein System mit transparenten Regeln für Belohnungen und Bestrafungen. Gleichzeitig wollte ich wirklich nicht alles auf reduzieren
alltägliche Methoden, deren Reaktion sich immer als das Gegenteil herausstellt.



Zuerst habe ich beschlossen, eine Liste von bedingten Problemen zu erstellen, oder besser gesagt, die Dinge, die ich tun würde
wollte sich als Team verbessern. Zum Beispiel wollte ich, dass die Jungs nicht zu spät zum Aufstehen kommen, sich darauf vorbereiten, einander genau zuhören und bei der Lösung von Problemen helfen. Viele Leute mögen keine Stand-Ups oder täglich, weil Betrachten Sie es als Verschwendung von Arbeitszeit.

Der erste Schritt bestand darin, die Sprache zu ändern, die wir bei der agilen Zeremonie sprachen - wir begannen, einen Stand-up auf Englisch durchzuführen. Die Entscheidung ging mit einem Knall einher: Viele bereiteten den Text im Voraus vor, die Dauer wurde verkürzt (Englisch war lakonisch und alle versuchten, sich nur auf das Wesentliche zu konzentrieren).

Und dann wurde mir klar, dass ich experimentieren musste

Wir formulieren Problembereiche

Die Tendenz zum systemischen Denken sagte mir, dass es notwendig ist, zuerst Probleme zu formulieren, genauer gesagt die Dinge, die ich verbessern möchte, um etwas zu tun. Dann ich
skizzierte die Hauptbereiche.

Rangliste der Teammitglieder

Unser Unternehmen hat eine Reihe von Noten - dies sind bestimmte Ebenen, die ihre formalen Verantwortlichkeiten, Privilegien und Gehaltsgabeln haben. Die tatsächliche Ausrichtung der Kräfte unterscheidet sich häufig aus offensichtlichen Gründen von der formalen: Die Anzahl der offenen Stellen und ihre Noten sind begrenzt, alle Jungs kamen zu unterschiedlichen Zeiten und unter unterschiedlichen Bedingungen ins Team, jemand zeigte in kurzer Zeit ein starkes Wachstum usw. Das Upgrade-Verfahren ist komplex, selten genug und Sie müssen gut darauf vorbereitet sein, d. H. nominieren Sie objektiv diejenigen Menschen, die es verdienen. Bei dem ersten derartigen Verfahren habe ich mich sehr geirrt: Da es für mich schwierig war, mich an alle Verdienste oder Misserfolge einzelner Männer zu erinnern, ging ich von meiner subjektiven Meinung aus, vielleicht an einigen Stellen aufgrund meiner eigenen Disposition. Und das ist falsch.

Fehler in solchen Situationen sind sehr schwer zu beheben. Und ich habe mich zum ersten Mal geirrt (eine Minute Geständnis). Aber negative Erfahrungen sind ein guter Lehrer. Mir wurde klar, dass wir ein klares Werkzeug brauchen - einen einfachen Indikator, um alle Erfolge und Misserfolge eines Menschen zu sehen, in welchen Bereichen er wächst. Informationen sollten immer zugänglich und relevant sein, und es ist in Ordnung, öffentlich zu sein. Dann haben alle Teammitglieder bei den nächsten Änderungen weniger Fragen.

Unterstützung bei der Produktentwicklung

Als ich ankam, arbeitete das Unternehmen nach dem Wasserfallmodell - tatsächlich war die Bank der Kunde und das Team von Sberbank-Technologies der interne Auftragnehmer. Ein Jahr später wechselte das Unternehmen zu großen Agile-Teams, die dezentralisiert wurden und sich auf die Entwicklung ihrer eigenen Produkte konzentrierten (die Submodule eines großen sein könnten
Systeme). Auf den Schultern des Produktbesitzers eines solchen Teams gab es neben dem linearen Management und dem Servicearchitekten (im Fall eines technischen Produkts) auch eine neue Funktion - das Produktmanagement, d. H. die Bildung seiner Vision, eine strategische Karte der Entwicklung, Detaillierung und Priorisierung von Aufgaben sowie die Verantwortung für den Zeitpunkt der Umsetzung.

Und ich als Eigentümer des Produkts wollte wirklich, dass die Teammitglieder nicht nur ihre Aufgaben erfüllen, sondern auch das Produkt wachsen lassen, neue Ideen einbringen, einen Teil meiner Verantwortung und Kopfschmerzen wegnehmen. Beispielsweise wurde viel Zeit darauf verwendet, Anforderungen zu sammeln, zu entwickeln und in bestimmte logische und sequentielle Aufgaben zu zerlegen. Ein weiteres Problem war die Produktunterstützung und die Kommunikation mit den Benutzern. Unser Produkt ist eine interne Bibliothek für die Entwicklung mobiler iOS-Anwendungen (dazu gibt es bereits eine ganze Reihe von Artikeln über Habr). Und unsere Kunden sind andere Anwendungsteams. Irgendwann erreichte die Anzahl unserer Benutzer ungefähr 120 Entwickler, Designer und Manager. Und ich hatte nicht einmal 12 Stunden am Tag Zeit, um mit allen zu kommunizieren. Ich wollte wirklich, dass das Team dabei aktiv hilft.

Planungsgenauigkeit und Zeitkillerbestimmung

Unsere Story Points-Indikatoren (im Folgenden als SP bezeichnet) sprangen lange Zeit stark von Sprint zu Sprint. Jedes Mal trat eine ähnliche Situation entweder aufgrund von Fehlern aus dem PROM oder auf
Einige ungeplante, überaus wichtige Aufgaben direkt von der Führung. Die Jungs beschwerten sich regelmäßig und waren selbst unzufrieden, weil sie nicht verstehen konnten, wo die Zeit vergangen war, ob die neu erhaltene Aufgabe wichtiger war als der Sprint, welchen Wert sie für das Produkt bringen würde. Zusätzliche Komplexität und der allgemein akzeptierte Ansatz zur Bewertung von Fehlern in 0 SP - ich habe immer zum Sprint beigetragen
eine bestimmte Anzahl von Fehlern, damit sie gegen kritische ausgetauscht werden können, die direkt während des Sprints eingetroffen sind.

Etwas Frisches und Neues

Nach zwei Jahren Arbeit an einem Produkt und im selben Team werden die Menschen langsam müde, ihre Augen verlieren ihren verrückten Glanz und die Produktivität sinkt.
Die Lösung, die erfunden werden musste, bestand darin, das Licht wieder und ein wenig anzuzünden
das Team aufmuntern.

Ein bisschen über das Team

Ich möchte etwas mehr über das Team sprechen: den Eigentümer des Produkts, den Analysten (auch bekannt als Scrum Master) und 9 iOS-Entwickler. Verstehst du jetzt, warum ich das Kräfteverhältnis in einem so homogenen Team so gut verstehen wollte?



Einige soziale Daten: Wir hatten zwei Mädchen und das Alter der Teilnehmer war in
Bereich von 22 bis 33. Bereiche von Interesse waren unterschiedlich, aber wir haben versucht, zu arrangieren
Allgemeine Teamaktivitäten: regelmäßige Brettspiele, Mini-Firmenveranstaltungen,
gemeinsame Reisen zu Konferenzen usw.

Jetzt bauen alle MotC ab

Ich hatte schon immer ein großes Interesse an der Spielebranche. Als Kind baute ich ganze Welten aus Legowürfeln, zeichnete einfache Brettspiele auf ein Stück Papier, wurde süchtig nach 3D Max und lernte dann einfache Werkzeuge zum Erstellen von Computerspielen - wie Dark Basic oder Game Factory. Ich habe viel Zeit in MMO verbracht und aus dem seltsamsten heraus habe ich meine eigene Version des Spiels Diablo 2 im Karteneditor für Warcraft 3 erstellt (es war sogar im lokalen Netzwerk der Stadt erfolgreich).

Wie Sie verstehen, wollte ich noch einmal eine Spielwelt schaffen und eintauchen
Teammitglieder in Echtzeit Herausforderung



Spiele an sich enthalten eine sehr nützliche Grundlage, nämlich: Wettbewerb, Punkte und Bewertungen, Regeln und Verstöße, Einzel- und Teamleistungen. Spiele infizieren sich mit Aufregung (was in unserem Fall der Beteiligung ähnelt) und lehren auch die Bitterkeit der Niederlage und die Freuden des Sieges.

Das einzige, was noch übrig bleibt, ist, eine Einstellung zu wählen, Mechaniken und Regeln zu entwickeln, das Gleichgewicht auszugleichen und auch an der bedingten Viralität zu arbeiten.


Der Löwenanteil meines Berichts über Saint Teamlead Conf war nur der Erstellung des Spiels und der Vervollständigung aller erforderlichen Punkte (Gameplay, Gleichgewichtsprobleme, Psychologie von 4 Spielertypen usw.) gewidmet. Ich werde nicht alle diese Informationen in Text übersetzen - ich hoffe, dass interessierte Leser sechs Monate warten, bis olegbunin die Einträge veröffentlicht (oder mich privat schreibt). Sie können auch die Konferenz der Teamleiter am 2. November anhören.

Wie bekomme ich MotC?

Kurz gesagt, Sie können virtuelle Münzen erhalten, um bestimmte Aktionen auszuführen:
1. Sprintaufgaben schließen. Dies ist wichtig und muss gefördert werden, da dies den geschäftlichen Wert bringt. 1 Story Point brachte 1,2 MotC. Warum ist nicht der gleiche Wert? Ja, es ist ganz einfach: Erstens sagt die magische Zahl bereits aus, dass es einen Koeffizienten gibt, und nachdem Sie dessen Vorhandensein angezeigt haben, können Sie ihn jederzeit sorgfältig ändern (um die Balance anzupassen). Plus MotC - Ganzzahl, d.h. Dies ist auch ein zusätzlicher Anreiz, um eine größere Anzahl von Story-Punkten zu schließen. Für 3 bekommst du 3 Motc und für 5 schon 6.

2. Behebung von Mängeln. Da es in SP keine Auswertung gibt, lass es in MotC sein. Unterschiedliche Kritikalitätsebenen hatten in Bezug auf die MotC ein unterschiedliches Gewicht. Um die Korrektur von Fehlern zu fördern (die nicht alle Entwickler wünschen), bringt ein geschlossener Fehler immer eine gebrochene Anzahl von Münzen mit, die abgerundet werden könnten, wenn ein weiterer Fehler nicht geschlossen wird.

3. Korrektur von nicht gedruckten Aufgaben. Neben Fehlern gab es noch andere dringende Aufgaben: Der Build-Server fiel aus, UI-Tests fielen aus, eine dringende und wichtige Aufgabe kam vom Management und vieles mehr. Für sie erhielt die Person nun MotC und kompensierte damit den SP-Mangel im Sprint.

4. Bewertungen und Ränge. Es wurden bereits 4 Kategorien erfunden: SP-Champion, Beitragsmaximierer (maximale MotC-Anzahl), Sprint-Held und Team-Auszeichnung. Das Prinzip der ersten beiden sollte meiner Meinung nach aus dem Namen klar hervorgehen, der Rest ist interessanter. Der Held des Sprints wurde von einem Team ausgewählt, das über Retro abstimmte. Dies war eine der ehrenwertesten Auszeichnungen im Team, sowohl in Bezug auf die Anzahl der Mot als auch in Bezug auf Prestige und Bedeutung. Das Vorhandensein eines Teampreises ist der Schlüssel, weil Es zeigt, dass nicht nur das persönliche Ergebnis wichtig ist, sondern auch das Gesamtergebnis des gesamten Teams. Es wurden drei Abstufungen erfunden: regulärer Sprint, Top-Sprint und fehlgeschlagener Sprint. Der Sprint wurde als normal angesehen. Wenn mehr als 78% des Sprint-Rückstands geschlossen wurden, wenn er 100% betrug, ist dies der Top-Sprint. Im Top-Sprint erhielt das gesamte Team eine großzügige Steigerung. Aber die Münze hatte eine Kehrseite - dies ist ein fehlgeschlagener Sprint.

Minen Negative MotC

MotCs sind wichtig. Daher war es möglich, Münzen mit einem negativen Wert zu erhalten. Was für ein Verdienst führte dazu:

1. Sprint fehlgeschlagen. Bei einer Leistung von weniger als 78% des Sprint-Rückstands erhielt das gesamte Team einen negativen Abbau.
2. Defekt öffnen. Wenn es einen eindeutigen Defekt in der Infusionsaufgabe gab, wurde die negative MotC von dem Entwickler, der die Pull-Anfrage injiziert hatte, sowie seinen Überprüfern verdient.
3. 3. Ein zusätzliches finanziertes System wurde auch erfunden, um zu spät zu einem Aufstehen oder zur Unaufmerksamkeit gegenüber Kollegen zu kommen. Sie handelte nach dem Prinzip "3 in einer Reihe". 3 identische Symbole sind zu einem neuen zusammengebrochen, bei dem ein negativer Abbau stattgefunden hat. Es gab eine Amnestie-Regel: Bei mehr als 25 MotC im Sprint führte der Zusammenbruch nicht zu einem negativen Bergbau, aber die Abzeichen wurden nicht zurückgesetzt.

Wie kann ich MotC ausgeben?

Ja Ja. Die Bedeutung von Münzen liegt nicht nur in persönlichen Bewertungen, sondern auch in der Tatsache, dass sie ausgegeben werden könnten. Hierzu wurde eine Aktivierungsfunktion erfunden. Es konnten nur positive Münzen aktiviert werden. Es gab ein ganzes Geschäft, in dem es Waren und deren Wert gab. Zur Kontrolle war ihre Anzahl begrenzt.

Was war im Laden?

1. Die Möglichkeit, die Arbeit vorzeitig zu verlassen oder später wiederzukommen. Der wichtigste Hodovichok.
2. Tag der Fernarbeit.
3. Möglichkeit der vorrangigen Aufgabenauswahl bei der Planung.
4. LinkedIn Empfehlung.
5. Auswahl eines Moduls für die Entwicklung auf Swift. Der gesamte Code war in Objective-C und die Jungs würden sich wirklich gerne in Swift entwickeln.
6. Konferenztickets (falls verfügbar).

Es gab andere Positionen, aber hier ist die wichtigste Regel, die Möglichkeit ihres Kaufs zu garantieren, da sonst das Vertrauen untergraben wird.

Korrekturen während des Spiels

Während des Experiments wurden an bestimmten Stellen Probleme des primären Gleichgewichts bemerkbar.
Was für?

1. Vorbildspieler. Zusätzlich zu den Entwicklern gab es einen Analysten im Team, und seine Fähigkeit, MotC zu erhalten, war sehr eingeschränkt, weil Der Löwenanteil der Aufgaben für Storypoints wurde für die Entwicklung geschärft. Zu den Funktionen des Analysten gehörte auch ein Teil der Verwaltungsaufgaben, deren ständige Überwachung teuer war. Die Lösung bestand darin, das Konzept des "privilegierten Bergbaus" einzuführen, d.h. Eine bestimmte Anzahl von MotCs wird automatisch für die Erfüllung der täglichen Aufgaben gutgeschrieben. Es ist interessant, dass in Zukunft ein weiteres Ungleichgewicht festgestellt wurde: In Abwesenheit eines Analytikers (z. B. Urlaub) übernahm jemand seine Aufgaben und nahm somit an der Produktion für den privilegierten Bergbau teil.

2. Abschreibung von Aufgaben. Mit der Zeit werden bestimmte sich wiederholende Aufgaben leichter zu erledigen. Zum Beispiel hatten wir ein Verfahren zum Freigeben einer neuen Version des Frameworks (unseres Produkts), das ungefähr 1,5 bis 2 Stunden reine Zeit in Anspruch nahm. Mit der Entwicklung von DevOps wurde der Zeitaufwand auf 30 Minuten reduziert. Dementsprechend ist die Vergütung in MotC gesunken. Oder es gab regelmäßig Aufgaben zur Erstellung neuer Formen von Berichten oder Status. Es ist schwierig, dies zum ersten Mal zu tun, aber es ist einfacher, es zu wiederholen - daher nahm die Schätzung in Münzen ab. Das Team hat solche Anpassungen angemessen wahrgenommen.

3. Doppelte Punkte für Mängel. Ein Beispiel, um zu zeigen, dass es in jedem Team unvorhergesehene Situationen gibt und die Regeln "abgestimmt" werden müssen. Wir haben lange Zeit auf automatischer Kaskadenzusammenführung gesessen (d. H. Beim Einfügen von Hotfix wurden automatische Zusammenführungen in den vorherigen Release-Versionen angezeigt und entwickelt). Irgendwann haben wir uns entschlossen, diese bösartige Praxis zu beenden, da ständig Zusammenführungskonflikte bei der Entwicklung hängen bleiben, und sind zu der Idee übergegangen, Aufgaben für alle Versionen zu duplizieren, in die Sie Änderungen hochladen möchten. Dies führte zur Entstehung mehrerer ähnlicher Aufgaben in JIRA:



Infolgedessen konnte der Spieler formell gemäß den Regeln schnell 2-3 Aufgaben annehmen und erledigen und 2-3x Münzen erhalten. Ich musste Korrekturen für solche Aufgaben einführen, weil ihre Komplexität abnahm (aber sicherlich nicht auf Null aufgrund möglicher Konflikte aufgrund von Änderungen in einzelnen Zweigen).

4. Die Idee, für die Arbeit mit Benutzern zu belohnen. Ich wollte die Jungs wirklich dazu zwingen, unseren Verbrauchern zu helfen (und das sind ungefähr 100 Anwendungsentwickler, voller dummer und sich wiederholender Fragen). Wir haben verschiedene Ansätze ausprobiert: Teilnehmer ernennen, eine detaillierte Wissensbasis pflegen, eine Community von Experten aufbauen und sie ermutigen. Es ergab sich jedoch eine einfache Lösung: 1 Mal pro Tag habe ich schnell den Support-Chat in Slack durchgesehen und den aktivsten Beratern des Teams eine kleine, aber angenehme Belohnung in Form von MotC gegeben. Jungs bewertet

Im Allgemeinen ist ein Spiel ein lebendiger Prozess, der sich auf dem Weg ändern muss. Die Hauptsache ist, sich von Anfang an zu versichern und sich die Möglichkeit für organische Manöver zu lassen. Das Ändern der Spielmechanik kann bei den Spielern zu Ressentiments führen. Anfangs hatte ich Angst, dass ich das Gleichgewicht zwischen Bergbau und den Kosten für „Preise“ nicht richtig berechnen könnte - daher gab ich sofort an, dass ihre Anzahl im Geschäft begrenzt ist und so weit wie möglich aufgefüllt wird. Wie Sie wissen, wird der Angebotsmarkt von einem Monopol kontrolliert, das immer ein Defizit oder eine Inflation deklarieren kann!

Ergebnisse und Beobachtungen

Das gesamte Experiment dauerte 9 Sprints (4 Monate). Insgesamt wurden 968 MotCs ausgegeben und 262 wurden ausgegeben. Es gab 3 Top-Sprints, dieselbe Person wurde viermal zum Helden des Sprints, die Verteilung der MotC im Team sah folgendermaßen aus:

	MotC	MotC +
Spieler 1	104	86
Spieler 2	203	203
Spieler 3	148	128
Spieler 4	65	47
Spieler 5	172	92
Spieler 6	58	40
Spieler 7	68	68
Spieler 8	95	77
Spieler 9	55	55

Hier ist es - der einzige Indikator, den ich so erstellen wollte.

Übrigens wurde die gesamte Datenbank in Numbers (xls für MacOS) gespeichert und einmal pro Woche (zum Zeitpunkt der Ausgabe von MotC for Retro) an die Teilnehmer gesendet. Es gab 5 Seiten mit übergreifenden Formeln: Bergbaugeschichte, Kaufhistorie, Angebotsgeschäft, Bergbaudetails und Übersichtstabelle.

Auf der Konferenz wurde mir eine Frage gestellt - es hat nicht viel Zeit gekostet, sie durchzuführen.
Die Antwort ist nein. Im Gegenteil, ich verbrachte weniger Zeit damit, Aufgaben bei JIRA in einzurichten
jede Kleinigkeit und mit einem Notizbuch zu synchronisieren, in das ich regelmäßig schrieb
alle delegierten Aufgaben. Die Tabelle mit dem Namen "Detailing" war gerecht
eine neue Art von Notizbuch, in das ich Anweisungen schreiben konnte und wann sie ausgeführt wurden
Nimm die Belohnung auf. Unten sehen Sie ein Beispiel für einen Sprint pro Spieler:

MotC	Bergbau
1	Vorschlag für Problem X.
1	Helfen Sie Makov beim Aktualisieren des Bibliothekssymbols für eine Demo
2	Vorbereiten eines Repositorys mit Boilerplate für IP (Demo für Handbücher)
2	Vorbereiten eines XSD-Schemas für ein Beispiel einer IP sowie Boilerplate Beratung
3	Fehlerverschluss
16	Konvertieren Sie 14 SP
4	Maximizer SP

Als das Experiment endete, fragte ich die Jungs - alle waren mit den Innovationen zufrieden und bestätigten, dass es frisch und aufregend war.


Das Ergebnis ist eine Win-Win-Situation. Es ist für mich einfacher geworden, die Entwicklung zu managen, die Jungs haben neue Möglichkeiten und den Geist der Herausforderung. Einige Leute haben für sich neue Entwicklungswege und Möglichkeiten gefunden, das Produkt zu nutzen. Gleichzeitig versuchte das gesamte Team gemeinsam, bis zum Ende des Sprints ein Top-Ergebnis zu erzielen.

Ich versuche nicht zu beweisen, dass dies die richtige Managementoption oder ein ideales Werkzeug ist. Dies ist nur ein Beispiel dafür, wie ich meinen Managementstil diversifizieren und ein Team auf eine gute Weise „aufmuntern“ kann. , , , . Performance Review .

!

PS Facebook LinkedIn , - 2 .