Ein Mitarbeiter, der viel weiß, weiß wie und ist bereit, jedes Feuer auf seiner Wiese zu löschen, natürlich gut gemacht. Aber wenn dieser Held in den Urlaub geht oder gar aufgibt, kommen schwere Zeiten. Es stellt sich heraus, dass es wichtig ist, nicht nur viel zu wissen, sondern auch dieses Wissen teilen zu können.
Aleksey Troshin (
morroz ) ist seit fast 20 Jahren im Beruf und seit 2002 als Projekt- und Produktmanager tätig. Während dieser Zeit arbeitete er in verschiedenen Unternehmen, leitete Teams von 2 bis 150 Personen und leitet jetzt die Entwicklung bei FINAM. Hier baute Alex ein System auf, das nicht nur hilft, Wissen zu verbreiten, sondern auch Entwickler motiviert, in die richtige Geschäfts- und Teamrichtung zu wachsen. Das System wird jedoch nicht in allen Teams eingesetzt. Warum? Dies und die verwendeten Ansätze erfahren wir unter dem Schnitt.
Der Artikel basiert auf einem Bericht von Aleksey Troshin über Saint TeamLead Conf, in dem dargelegt wird, wie Wissen in FINAM verbreitet wird: Wie die Stärke und das Können der Jedi zunehmen, wie die Padawans trainiert werden und was auf der dunklen Seite der Macht geschieht (wo würde es ohne sie sein).Produkte und FINAM IT Team
Zunächst werde ich einige unserer Produkte erläutern, um den Kontext des Unternehmens zu bestimmen.
Website Finam.ru - Website Nr. 1 zu Finanzthemen mit vielen verschiedenen Abschnitten mit Finanzinformationen sowie nützlichen Diensten, z. B. einem Online-Aktiengeschäft. Sie können zum Beispiel eine Aktie von Apple kaufen und sie jemandem zum Geburtstag schenken.
Die Handelsplattform FinamTrade , die auch für Anfänger einen Null-Kommissionssatz bietet.
Comon.ru - ein System zur automatischen Wiederholung von Transaktionen von professionellen Händlern - eine Lösung für Anfängeranleger und diejenigen, die nicht genug Freizeit haben, um ihr eigenes Anlageportfolio zu erstellen.
Soziales Netzwerk für Händler und vieles mehr .
FINAM IT besteht aus 150 Personen, die in 25 Teams aufgeteilt sind. Entwicklung ist nur intern, wir ziehen für unsere Bedürfnisse fast keine Drittunternehmen an. Das Titelbild zeigt perfekt, wie alles bei uns arrangiert ist. Die Zusammensetzung der Teams kann unterschiedlich sein: Einige Teams haben einen Product Owner, aber es gibt keine Tester, andere haben Tester, aber es gibt keinen Product Owner, aber es gibt Analysten.
In der Entwicklung verwenden wir verschiedene Technologie-Stacks:
- Frontend: React.js, VUE.js.
- Sprachen: C #, PHP, C ++, Java, Mobile.
- Datenbanken: MSSQL, PostgreSQL, Oracle.
- Plattformen: SharePoint, 1C, Diasoft, MS CRM und mehr.
Als ich zum ersten Mal ins Unternehmen kam, haben wir versucht, Teams, Produkte und Beziehungen zu zeichnen. Das Ergebnis war ein so komplexes Schema, dass die Kreise die Produkte anzeigen, die wir entwickeln:
Ich habe anhand der Farbe gezeigt, dass die Teams unterschiedlich organisiert sind. Einige machen ein Produkt, andere machen mehrere Produkte. Und es gibt Produkte, die von mehreren Teams gleichzeitig entwickelt werden (z. B. ein internes Backoffice).
Ich werde meine Geschichte an den Beispielen von zwei Teams leiten. Ich werde sie unter bestimmten Bedingungen Team 1 und Team 2 nennen.
Team 1
Das erste Team entwickelte ein internes Informationssystem. Anfangs sah es so aus:
- Ein Mitarbeiter war Experte für die aktuelle Version der Plattform. Es bestand die Aufgabe, diese Plattform auf neue Schienen zu verlagern, da die alte Version nicht mehr unterstützt wurde.
- Wir haben einen neuen Mitarbeiter eingestellt, der Experte für die neue Version der Plattform war. Er war an der Portierung aller Funktionen auf diese neue Version beteiligt.
Team 2
Das zweite Team entwickelte mehrere interne Systeme:
- Ein Mitarbeiter ist Experte in einem System.
- Ein anderer Mitarbeiter ist Experte für andere Systeme.
- Und einige Systeme wurden von beiden Mitarbeitern gemeinsam entwickelt.
Über Experten
Es ist kein Zufall, dass das Wort „Experte“ im obigen Text hervorgehoben wird. Ich möchte klären, wer der Experte im Rahmen dieses Gesprächs ist. Als Meister aus Star Wars verfügt dieser Mensch über die Power: Tiefe Kompetenz in seinem Fachgebiet, in der Technologie, im Produkt. Dies ist in der Regel praktisch für ein Unternehmen, da es einen Einstiegspunkt gibt: Experten werden gefragt, wie es zu tun ist oder wann es getan wird, ob es sich um neue Aufgaben handelt, oder sie stellen Fragen, ob etwas kaputt gegangen ist oder nicht richtig funktioniert.
Ich stelle mir einen solchen Experten als Jedi-Meister aus dem Film "Star Wars" vor - er kann alles (naja oder fast alles).
Aber der Jedi-Experte hat seine Nachteile:
- Er muss für eine lange Zeit "erzogen" werden, damit er diese Kraft akzeptiert.
- Wenn er in den Urlaub fährt, heißt es immer: "Was machen wir alle?"
Um den Einfluss dieser Minuspunkte zu überwinden, haben wir ein System zur Pflege von Kompetenzmatrizen entwickelt, auf das ich später eingehen werde. Ich stelle fest, dass wir es nicht in allen Teams implementiert haben, sondern nur dort, wo es Probleme gab. Am schlimmsten war es in kleinen Teams.
Unser Hauptschmerz war die Frage "Was passiert, wenn dem Experten etwas passiert, wie bei Meister Yoda auf dem Bild unten?"
Und Sie haben wahrscheinlich auch von dem Konzept des Busfaktors gehört.
Busfaktor
Der Busfaktor ist ein Maß für die Informationskonzentration zwischen einzelnen Projektmitgliedern.
In der Definition aus Wikipedia steht, dass dieser Faktor die Anzahl der Projektteilnehmer bestimmt, nach deren Verlust das Projekt von den verbleibenden Teilnehmern nicht abgeschlossen werden kann. Konventionell bedeutet dies, wie viele Personen den Bus bewegen müssen, damit bei dem Projekt eine irreparable Katastrophe eintritt.
Wenn Sie einen Experten haben, ist der Bus-Faktor gleich eins, das heißt, alle Risiken des Projekts liegen in der Hand einer Person, und das ist schlecht.
Ein Beispiel aus der Geschichte: 2010 gab es in der Nähe von Smolensk einen Flugzeugabsturz, bei dem 96 Menschen starben, darunter die oberste Führung Polens. Nach diesem Ereignis wurde in Polen eine Regel verabschiedet - die vier obersten Staatsoberhäupter (Präsident, Ministerpräsident, Senatssprecher, Sprecher des Sejm) sollten unter keinen Umständen zusammen fliegen. Dies ist ein Schutzfaktor gegen den Busfaktor.
Wie Sie wissen, waren die Experten in den Teams 1 und 2 nicht austauschbar, was zu potenziellen Problemen führte. Es musste etwas unternommen werden, um den Busfaktor zu erhöhen und die Kompetenzen der Jedi-Experten zu erweitern. Wir haben die folgenden Schritte unternommen.
Schritt 1. Erhöhen Sie den Busfaktor
Der Jedi sollte nicht allein sein. Daher ist es notwendig, die Jedi zu trainieren und zu trainieren, damit es mehr von ihnen gibt.
Ich werde klarstellen, dass der
Jedi eine Rolle ist, keine Kompetenz . Jedi kann aufgezogen werden. Die zweite Rolle (in Bezug auf Star Wars) ist
Padawan , ein Schüler der Jedi. Er strebt nach der Fülle des Wissens des Jedi und ersetzt ihn, wenn er im Urlaub ist. Außerdem kann es mehr als einen Padawan geben - wenn das Team groß ist, können wir mehrere Padawans gleichzeitig kultivieren. Trotzdem bleibt der Jedi der Hauptentscheidungsträger.
Wenn wir entscheiden, wer ein Jedi wird, einigen wir uns auf die Padawans, verteilen die Rollen und visualisieren sie in der Verwaltungstabelle:
Hier sind die horizontalen Produkte, Bereiche oder Module. Wenn das Produkt beispielsweise 1C ist, kann es sich um „Gehalt und Personal“, „Buchhaltung“ oder andere Module handeln. Die vertikalen Spalten geben die Mitarbeiter an. An der Kreuzung geben wir die Rollen ein - wer ist der Jedi, wer ist der Padawan? Dies führt zu einer klaren Verteilung.
Wir haben uns auf einige Regeln geeinigt, um mit dem Vertrieb zu beginnen.
Verteilungsregeln, Teil 1:- Ein Produkt, Bereich oder Modul - ein Jedi . Wir erinnern uns, dass wir die Bequemlichkeit eines One-Stop-Shops beibehalten möchten, der fachkundig und verantwortungsbewusst ist.
- Mindestens ein Padawan . Hier geht es nur um den Bus-Faktor, je mehr es gibt, desto besser.
- Die Gleichverteilung der Jedi . Um die Mitarbeiter nicht zu überlasten, aus Fairness.
Es scheint, dass alles logisch verteilt war, und es stellte sich heraus, wie folgt:
Im ersten Team, das an einem Produkt arbeitete, arbeitete eine Person am alten Produkt (Sunset), die andere am neuen (Sunset 2.0). In der "eigenen" Version des Produkts wurde der Mitarbeiter als Jedi angesehen, in der "fremden" Version als Padawan, Schüler eines anderen Mitarbeiters.
Im zweiten Team waren zunächst neu angekommene Mitarbeiter in Padawans eingeschrieben, weil sie noch nichts über sie wussten. Und dann ist es ähnlich wie bei Sudoku - wir versuchen, ungefähr die gleiche Anzahl von Jedi und Padawan in Zeilen und Spalten zu erhalten.
Schritt 2. Kontrollieren Sie den Wissensaustausch
Aber wie kann man überprüfen, ob der Padawan zu einem Jedi heranwächst, der die ganze Macht des Wissens besitzt?
Wir reparieren Wissen
Dazu korrigieren wir das Wissen unserer Produkte: Machen Sie eine Liste aller Kenntnisse und stellen Sie sie in eine Tabelle. Für jedes Produkt auf einer separaten Confluence-Seite schreiben wir einfach das Wissen auf, aus dem das Produkt besteht, und zerlegen es. Das Zerlegen von Wissen kann auf verschiedene Arten erfolgen, und ich erinnere mich, dass diese Tabellen unter der Seite mit der Verteilung der Jedi und Padawans gezeichnet sind. Beispiel: Für Team 1 eine Seite für Sunset-Kenntnisse und eine andere Seite für Sunset 2.0-Kenntnisse.
Weiter einige Screenshots aus unserem Confluence mit Beispielen zur Zersetzung.
Nach Produktmodulen. Zum Beispiel hat eines der Produkte separate Softwaremodule: Kredite, Einlagen, Währungskontrolle - wir haben sie nur bemalt und angefangen, mit ihnen zu arbeiten.
Nach Funktionalität. Hier haben wir die Wissenseinheiten auf die Seiten und Abschnitte des Systems gemalt.
Für technisches Wissen. Einige Produkte haben wir einfach nach den technischen Kenntnissen des Teams ausgelegt.
Sie können auf andere Weise zersetzen, die Hauptsache ist, dass Sie das Wissen über Ihr Produkt in eine größere Anzahl atomarer Elemente aufsprühen können.
Dokumentation hinzufügen
Nachdem wir die Wissenslisten detailliert hatten, fügten wir der Tabelle die Spalte "Dokumentation" hinzu und füllten sie schrittweise aus - jede Wissenszeile hat eine eigene Seite mit einer Beschreibung.
Ich muss sofort sagen, dass dies kein schneller Prozess ist, es hat mehrere Monate gedauert, aber im Laufe der Zeit wurde die Liste der Dokumentationen gefüllt, und am Ende haben wir in allen Wissensgebieten über das Produkt eine Art Dokumentation geschrieben.
Bewertungen hinzufügen
Weiter rechts neben der Spalte "Dokumentation" haben wir für jedes Teammitglied eine Spalte hinzugefügt und bewertet, inwieweit jeder Mitarbeiter über dieses Wissen verfügt.
Ich werde die Bewertungen entziffern:
- 1 - wenn Sie diesen Wissensbereich nicht gesehen oder berührt haben.
- 2 - etwas gesehen oder gehört, weiß wo es ist. Zum Beispiel habe ich die Dokumentation gelesen, um Zugriff auf den Server oder das Repository gebeten.
- 3 - gesehen, berührt, kann tun. Zum Beispiel habe ich einen Fehler in diesem Teil des Codes ausgeschlossen und etwas mit meinen Händen überprüft.
- 4 - mehr als einmal gearbeitet, können andere erzählen.
In der ersten Version hatten wir fünf Klassen - die Schule lehrte uns, von 1 bis 5 zu zählen. Dann stellte sich heraus, dass das Vier-Punkte-System ausreichte, und wir blieben stehen.
Bei der Bewertung eines Wissensüberblicks können wir Kontrollfragen stellen. Eines der Teams, das Neulinge in das Projekt einführt, hat ein einstündiges Video, das Sie ansehen und Fragen auf der Checkliste beantworten müssen. Wenn eine Person nicht alle Fragen beantwortet hat, wird angenommen, dass sie nichts verstanden hat. Das Video muss überprüft werden, da es alle Antworten enthält.
Schritt 3. Visualisieren Sie es
Im dritten Schritt stellte sich die Frage: Wie sehe ich als Manager sofort und klar, wie sich das Wissen im Team aufbaut?
Wir haben den aktuellen Zustand visualisiert, indem wir die Quadrate der Jedi und Padawans in verschiedenen Farben bemalt haben: Grün - das Training ist abgeschlossen, grau - im Lernprozess, rot - hat nicht angefangen zu lernen. Am Anfang normalerweise viel Rot, aber am Ende sollte jeder "grün werden".
Zuerst spielten wir eine Ampel und dachten, dass es zwischen Rot und Grün Gelb geben sollte, aber es stellte sich heraus, dass die hellgelbe Farbe uns von der Essenz ablenkte. Deshalb haben wir es aufgegeben und sind grau geworden. Eigentlich geht es darum, Rot so schnell wie möglich loszuwerden. Bild mit einem Beispiel einer Ampel:
Danach haben wir unsere Regeln weiter verfeinert.
Verteilungsregeln, Teil 2:- Die Jedi müssen zuerst "grün werden". Das heißt, wir konzentrieren uns darauf, die Jedi zu pumpen. Der verantwortliche Chef sollte so schnell wie möglich kompetent werden. Vor allem, wenn dies ein neuer Mitarbeiter ist.
- Mindestens ein Padawan muss grün sein und das Training vollständig abgeschlossen haben. Aber er hat es vielleicht nicht eilig, Jedis Wissen einzuholen, die Hauptsache ist, nicht aufzuhören.
- Der Rest der Padawans befindet sich möglicherweise im Lernprozess. Unsere Aufgabe ist es nicht zu vergessen, Wissen zu „schmieren“, um sicherzustellen, dass sich die Wissensbereiche der Mitarbeiter überschneiden und die Abdeckung maximal ist.
Anforderungen differenzieren
Für die erste Phase der Einführung des Systems, in der die Beschreibung und Digitalisierung von Wissen gerade erst beginnt, gibt es bewährte Verfahren: die Anforderungen für Jedi und Padawan zu trennen.
Erinnern wir uns an die Schätzungen: Padawan erhält eine grüne Markierung für die „Drei“, wenn er mindestens etwas in diesem Bereich getan hat, und der Jedi sollte für die „Vier“ perfekt im selben Bereich ausgerichtet sein. Es ist auch schlecht für den Jedi (rote Farbe), wenn kein Zugang gewährt wird, keine Dokumentation geschrieben wird usw., dh seine untere Schwelle ist "zwei". Dieser Ansatz ist in der folgenden Tabelle dargestellt.
Dies war genug, um loszulegen. Im nächsten Schritt können Sie die Messlatte höher legen und sagen, dass jetzt alle Zahlen gleich sein sollten.
Und jetzt sind unsere Teller bemalt und alles wurde interessanter und verständlicher:
Wir gingen anderthalb Jahre zu ein paar grünen Bildern. Wir versammelten uns langsam mit den Teamleitern, alle zwei Wochen oder einen Monat, schauten zu, was passierte, und aktualisierten ständig etwas.
Als wir neue Funktionen hinzufügten, erschienen rote Würfel. Dann überprüften wir beim nächsten Timlid-Treffen, ob sie rot blieben. Wenn ja, dann begannen sie herauszufinden, warum in zwei Wochen das Training nicht fortgeschritten war. Wenn das Rot weg ist, bleiben die grauen Quadrate, wir haben sie regelmäßig überprüft. Die Ergebnisse der Teambesprechung wurden in Confluence auf Checklisten festgehalten, in denen der Status vermerkt wurde. Zum Beispiel: „Mitarbeiter 1 - Stufe 10 von 20“. Wenn sich diese Werte innerhalb von zwei Wochen nicht änderten, schauten sie nach dem Grund.
Jeder neue Mitarbeiter ist immer in der roten Zone, er muss so schnell wie möglich geschult und gepumpt werden. Aber wie?
Schritt 4. Wissen und Fähigkeiten fördern
Ausfüllen: Ausfüllen der Dokumentation
Wir haben verstanden, dass wir uns bemühen sollten, sicherzustellen, dass eine Zeile der zerlegten Tabelle des Produkts einem Wissen entspricht (eine Seite der Dokumentation).
Die unvollständige Beschreibung ist nur in dieser Tabelle sichtbar. Dies bedeutet, dass die Wissensbereiche in der linken Spalte zu detailliert sind, und auf der rechten Seite befindet sich wahrscheinlich ein großes Dokumentationsblatt, das schwer zu lesen und schwer zu erlernen ist. Das heißt, sie haben eine Seite der Dokumentation gelesen und 5 Wissenszeilen auf einmal gepumpt - es ist unlogisch, es irgendwie zu verstehen. Es ist besser, wenn eine Zeile einer Seite in Confluence entspricht. Es ist einfacher, das Kontrollkästchen (Nummer) zu aktivieren, damit alle Seiten gelesen und gelernt werden.
Wir verwenden zwei Füllmethoden:
- Schreiben aus dem Speicher (Expertenmethode). Wer weiß, wie man etwas macht, setzt sich und beginnt, seine Schritte aufzuzeichnen, indem er zum Beispiel die Beschreibung mit Screenshots ergänzt.
- Die zweite Methode - Forschung - die ich sehe, dann schreibe ich. Auf diese Weise haben wir es verwendet, als wir mit einem System arbeiteten, an das sich niemand erinnerte, was damit zu tun war. Der Mitarbeiter hat sich hingesetzt, um alles zu verstehen und aufzuschreiben, was er in Schritten getan hat: Hier müssen Sie Rechte beantragen und dann einen Brief schreiben usw. Daher wurde die Dokumentation für den von ihm untersuchten Teil ausgefüllt.
Es kommt vor, dass die Interessen der Entwickler in Bezug auf die Eigenentwicklung nicht mit den Bedürfnissen des Unternehmens übereinstimmen. Hier können Sie mit den Quoten spielen. Sie benötigen beispielsweise eine Verbesserung der Analysefähigkeiten, was bedeutet, dass wir für die Analyse einen Koeffizienten von 0,5 festlegen. Es wird deutlich, dass man dort schneller "grün werden" kann. Aber wo die Mitarbeiter selbst mehr interessiert sind, aber nicht das Team, sind die Chancen größer. In diesen Abschnitten dauert das Pumpen länger.
Neben der Arbeit mit Dokumenten führen wir Fachgespräche. Die Dokumentation ist jedoch grundlegend. Ich glaube, das ist der beste Weg, um alle Prozesse zu kontrollieren. In der Dokumentation ist alles in den Regalen angeordnet, ein vollständiges Bild ist sichtbar und Sie können die Verbreitung und Anhäufung von Wissen beeinflussen.
Wir haben also alles dokumentiert, was wir brauchen. Der nächste Schritt ist die Aktualisierung.
Aktualisierung
Es ist sehr gut, wenn alle Teammitglieder das Recht haben, die Dokumentation zu bearbeiten. Dann kann jeder Mitarbeiter, der sich mit der Dokumentation vertraut macht und liest, wie etwas zu tun ist, irgendwo stolpern und es sofort korrigieren. Beispielsweise hat sich der Servername geändert oder etwas anderes, ein Mitarbeiter kann die Dokumentation sofort ändern. Somit erfolgt eine
automatische Aktualisierung und Ergänzung des Wissens .
Wenn Ihr Team in Ihrem Confluence-Bereich diese Änderungen abonniert hat, erhält es Benachrichtigungen darüber, was hinzugefügt, geändert oder verbessert wurde, da es in Atlassian Confluence Folgendes gibt:
- Verlauf der Seitenänderungen - Sie können immer sehen, was und wann sich geändert hat.
- Abonnieren Sie Benachrichtigungen zu Seitenaktualisierungen.
- Löschen Sie durch den Papierkorb.
Günstigerweise erfolgt eine Löschung über den Warenkorb. Wenn jemand versehentlich auf "Seite löschen" klickt, geht diese immer noch nicht verloren. Sie können es wiederherstellen und herausfinden, warum jemand versucht hat, dieses Wissen aus Ihrem Bereich zu entfernen.
Die meisten unserer Teams haben kein separates Verfahren zur Überprüfung der Dokumentation. In einem der Teams war die Verbreitung von Wissen ein großer Schmerz, der Teamleiter vergaß dies zu tun. Dann begannen wir dort alle sechs Monate eine Überprüfung. Wir haben eine neue Seite erstellt und von vorne begonnen, das Datum der Überprüfung wurde festgelegt.
Das Hauptkriterium für die Qualität des Wissensaustauschs ist für mich die Abreise eines Mitarbeiters in den Urlaub. Wenn jemand in den Urlaub fährt und niemand mir schreibt, nicht anruft und nichts fragt, dann denke ich, dass in diesem Team alles in Ordnung ist.
Und wenn es vor der Urlaubsplanung Diskussionen gibt, „was würden wir ohne ihn tun“, ist dies für mich eine Gelegenheit, in einem persönlichen Gespräch mit dem Teamleiter zu besprechen, was mit dem Wissenstransfer in seinem Team passiert.
Sie müssen verstehen, dass es in der Dokumentation nicht immer darum geht, etwas zu lesen oder zu lernen. Oft müssen Sie etwas tun: Zugriff anfordern, das Programm installieren, etwas im Programm öffnen. Während dieser Aktionen findet eine Aktualisierung statt. , , . , , , . .
Verwenden Sie
?
. . , 4 , . , , - . , , . , , . , .
, . : « , . , ».
, — , . «», , . , : « , . ».
. , , 1, 2, 3, 4 . , , . . , , 1, 2, 3, 4. .
« »KPI, : « - KPI , - - , ». , , , , . — .
— , , .
Bus factor: , . , bus- , , , . : , . , . , , . , , . . : «, . - , ».
, , . () . , , . ( ). . , — . .
. , , . , . , . .
Schlussfolgerungen
, , , .
« ! ». . !
TeamLead Conf 2020 , . , «», . , . , , , telegram- . 10 11 !