Möglicherweise sagen Sie: „Die Kompetenzmatrix? Wirklich? " Höchstwahrscheinlich haben Sie bereits etwas über dieses Tool gehört und sogar Schlussfolgerungen gezogen, warum Sie es nicht verwenden möchten. Vielleicht war es einfach nicht vorher oder wie das mörderische Argument "so historisch passiert ...".

In der Tat ist dies ein völlig logisches und kein neues Werkzeug, das sehr nützlich sein kann. Und Sie können es auf ganz unterschiedliche Weise implementieren, was wir Ihnen in praktischen Fällen von zwei verschiedenen Teams beweisen wollen - technischer Support und Entwicklung. Anhand dieser Informationen können Sie selbst die Arbeitskosten abschätzen (sie können sehr unterschiedlich sein) und einen für Sie geeigneteren Weg in diese Richtung finden.

Und was die Drachen damit zu tun haben, werden wir unter dem Schnitt erklären.



Dieser Artikel basiert auf unserem mit Konstantin Kaftan auf TeamLead Conf . Konstantin Timlid, Abteilung für technischen Support von IPONWEB, und ich sind der technische Redakteur des Entwicklungsteams von IPONWEB, das sich mit Wissensmanagement befasst.

Die Geschichte basiert auf IPONWEB-praktischen Fällen. Lernen Sie das Unternehmen also zunächst ein wenig kennen, damit Sie verstehen, ob dieses Material in Ihrer Nähe ist.

Unsere Personalabteilung gab auf Anfrage nach einem coolen Marketingbild, das über unsere Sphäre berichtet, Folgendes:


In der Tat entwickelt IPONWEB Plattformen für Kunden, die Online-Werbung betreiben. Wir arbeiten am Modell von Software as a Service (oder vielmehr Platform as a Service). Wir haben viele Komponenten: HTTP-Server, Vorhersagealgorithmus, Benutzeroberfläche, Berichterstellung. Geschäftslogik für ca. 50 in Lua geschriebene Projekte.

Wir haben auch das Flaggschiff BidSwitch, das als Spin-off begann. Wir sind mehr an der Integration von Partnern (nachfrageseitig, angebotsseitig) interessiert, daher haben wir viele Protokolle. Dies ist das gleiche Projekt auf dem gleichen Stapel, aber es ist groß genug, es hat Besonderheiten und eine spezielle technische Support-Linie, die Konstantin leitet.

Warum haben wir den Namen "Dragons Live Here" gewählt, was bedeutet das? So bezeichneten mittelalterliche Karten früher Orte, an denen nicht bekannt ist, was passiert - wie Terra Incognita. Es gibt zwei Geschichten darüber. Das erste betrifft die Struktur der Fähigkeiten und Fertigkeiten, über die das Team verfügt, und je größer das Team, desto mehr Terra Incognita gibt es; und etwas später über die zweite sprechen.

Wie sind wir hierher gekommen?

So kam es, dass wir (Svetlana und Konstantin) uns bei der Arbeit nicht oft überschneiden und dass wir nur auf der Konferenzwebsite Bewerbungen zu demselben Thema eingereicht haben. Dann beschlossen wir, uns zu vereinen - es schien uns, dass dies für alle interessanter sein würde.

Teamprofile

Konstantins technisches Support- Team:

• Mitarbeiterzahl: 10-12 Personen.
• Timlid-Abstand: kurz - alles ist für einander sichtbar.
• Eine Reihe von Fähigkeiten: eine sehr unterschiedliche Reihe von Fähigkeiten, Kompetenzen, Arbeitsinstrumenten - dies liegt an der Tatsache, dass wir die Möglichkeit haben, neue Aufgaben von Kollegen anderer Teams und Abteilungen für uns zu übernehmen.
• Arbeitsstil: Aufgaben von Kollegen stehlen. Dies geschieht zum einen, um die Support-Routine zu verwässern. Daher ist es nicht sehr interessant, Tag für Tag dieselbe Art von Anfragen zu analysieren. Zweitens, um zu sehen, wer was bekommt, und um die Richtung der Entwicklung zu skizzieren.

Mein Lua-Entwicklungsteam :

• Mitarbeiterzahl: 40 Personen, aber die Anzahl ändert sich ständig;
• Distanz zum Teamleiter: lang genug aufgrund der Besonderheiten der Managementstruktur im Unternehmen (es handelt sich um eine Matrix). Das heißt, der Teamleiter sieht nicht jeden Entwickler täglich und weiß nicht genau, was seine täglichen Aufgaben sind.
• Fähigkeiten: mehr oder weniger einheitlich. Entwickler schreiben Geschäftslogik in Lua, aber gleichzeitig betreten sie alle die Geschäftseinheit, d. H. in einer Vereinigung von Projekten, zum Beispiel, ob sie Anzeigenflächen verkaufen oder Anzeigen als Werbetreibende kaufen.
• Arbeitsstil: spezifische Aufgaben, Busfaktor. Oft konzentriert sich das Wissen auf die Köpfe von Einzelpersonen, nicht das gesamte Team ist austauschbar.

Befehlsbeschreibungen sind erforderlich, um zu verdeutlichen, wie sich unsere Matriximplementierungen unterscheiden. Wir werden versuchen zu beschreiben, wie verschiedene Teams dazu gekommen sind, was als Ergebnis passiert ist, da die Teamstrukturen, Botschaften, Ziele, Auslöser und Endergebnisse etwas unterschiedlich waren.

Ziele und Auslöser

Im technischen Support-Team:

• Wer macht was? Es war notwendig herauszufinden, wann alles zu viel wurde und nicht mehr in meinen Kopf passte, wer was tat, wer und was in der Lage war und auf welcher Ebene.
• Welche Spezialisten fehlen? Infolgedessen, wer fehlt, um die Aufgaben zu erledigen, wer muss geschult werden.
• Welche Kompetenzen sind für alle gemeinsam und notwendig? Die Hauptsache ist, in der Auswahlphase zu verstehen, was gemeinsam und obligatorisch ist, was für die Personalabteilung im Profil des idealen Kandidaten geschrieben werden muss.

Im Entwicklungsteam waren die Ziele und Auslöser leicht unterschiedlich. Der erste Anreiz war genau das Wissensmanagement, denn wie bereits erwähnt, haben wir ein sehr spezifisches Geschäft - Ad Tech. Die Wahrscheinlichkeit, dass jemand mit vorgefertigtem Wissen kommt, ist recht gering, und gleichzeitig ist für einen Entwickler das Wissen über geschäftliche Besonderheiten sehr wichtig.

Im Dev Team war es notwendig:

• Beschleunigen Sie Onboarding-Anfänger . Die langfristige Einbeziehung von Entwicklern in das Projekt ist ein großer Schmerz. Das Onboarding dauerte ungefähr sechs Monate, dh mehr als eine Testphase, was bedeutet, dass wir den Entwickler auf eigene Kosten schulen werden.
• Verstehen Sie die Struktur des Wissens, bewerten Sie Wissenslücken , finden Sie weiße Flecken, skizzieren Sie einen Trainingsplan, skizzieren Sie individuelle Wachstumspfade.
• Aufgrund der Matrixstruktur ist es notwendig, Entwickler gleichmäßiger auf Geschäftsbereiche und Aufgaben zu verteilen und niemanden zu beleidigen. Senden Sie also nicht alle Senioren zu einer Geschäftseinheit.

Es gab auch ein Nebenziel - den Prozess der Leistungsüberprüfung transparenter und verständlicher zu machen, um Ziele in einem einzigen Koordinatensystem zu formulieren.

Leistungsbeurteilung

Leistungsbeurteilung ist unser Unternehmensstandard. Einmal alle N Monate wird mit jedem Mitarbeiter in Anwesenheit des Mitarbeiters, seines Teamleiters, eine Leistungsüberprüfung durchgeführt, wobei eine Personalabteilung oder ein Notar als Schiedsrichter fungiert. Bei der Leistungsüberprüfung untersuchen wir, was der Mitarbeiter mit den gestellten Aufgaben gemacht hat, was er nicht erfolgreich war, wenn er nicht erfolgreich war, warum, was wir sonst noch erreichen möchten, was wir anbieten können. Danach werden neue Ziele und Vorgaben festgelegt, die nächste Frist wird festgelegt.

Im Support-Team ist dieser Zeitraum recht kurz, da es keine großen, zeitlich begrenzten Projekte gibt - dies sind 3, maximal 4 Monate. Das Entwicklungsteam hat halbjährliche Überprüfungszyklen. Bisher waren die Fristen länger, einfach weil Entwickler eine Roadmap besser skizzieren können. In einigen anderen Entwicklungsteams erfolgt die Überprüfung der Front-End-Leistung beispielsweise auch alle 3-4 Monate. Vielleicht hat das Intervall nichts mit der Entwicklung oder Unterstützung des Teams zu tun, aber es ist bei uns passiert.

Warum brauchen Sie eine Kompetenzmatrix?

Vor einem Jahr erlebte unser Unternehmen eine Phase intensiven Wachstums, es gab mehr Mitarbeiter, mehr Werkzeuge, mehr Aufgaben, mehr. An einem Punkt wurde klar, dass es ohne die richtigen Dokumente schwierig ist zu verstehen, was geschah. Und wir haben eine Lösung für die Systematisierung von Informationen gefunden: über Aufgaben; Werkzeuge und Fähigkeiten; Mitarbeiter.

Warum brauchst du das alles? Sie werden etwas über unsere praktischen Fälle erfahren, haben aber möglicherweise eine vernünftige Frage: Wie können Sie verstehen, dass ich sie brauche?

Wenn Sie ähnliche Probleme haben wie oben angegeben, das heißt, Sie verstehen nicht den gesamten Aufgabenpool Ihrer Entwickler, führen zu lange neue Mitarbeiter ein und andere Probleme, die bereits erwähnt wurden, dann benötigen Sie diese wahrscheinlich.

Wo soll ich anfangen?

Wo wir anfangen sollen, erkennen wir an unserem Beispiel.

Im technischen Support-Team haben wir: die Aufgaben identifiziert, mit denen wir beschäftigt sind; zerlegte Aufgaben in separate Manipulationen; herausgefunden, welche Tools ein Mitarbeiter kennen sollte, um in einem bestimmten Sektor zu arbeiten.

Unten finden Sie ein leicht vereinfachtes Beispiel.


Das Team hat Mitarbeiter Batman, Joker, Flash und Ivanov sowie Standardaufgaben:

• allgemeine Verkehrsdiagnose;
• Diagnose des Geschäftsverkehrs;
• Bereitstellungsüberwachung;
• Testen der Integration neuer Partner, sowohl DSP als auch SSP, sowohl Käufer als auch Verkäufer.

Von den Werkzeugen, die wir haben:

• Mit uSIicer können Sie sehr detaillierte Handelszahlen abrufen.
• Graphit liefert Systemstatusdaten in Echtzeit.
• Google BigQuery (BQ) - unsere Protokolle leben dort;
• Grafana, mit dem Sie Metriken aus Graphite aggregieren können, ist es bequem, bei Bedarf Warnungen darauf zu setzen.
• Ul-Anpassungen in der Admin-Oberfläche, mit denen Sie die Verkehrsparameter für einen bestimmten Partner, ein Handelspaar, ein Rechenzentrum usw. ändern können.

Dann haben wir herausgefunden, wer was und in welchem ​​Umfang weiß.


2 - ein Experte, der unterrichten kann; 1 - bedeutet, dass eine Person mehr oder weniger weiß; leere Zellen stattdessen, um niemanden zu beleidigen.

Wir fassen in einer Tabelle zusammen:


Die Werkzeuge, die für eine bestimmte Aufgabe nicht benötigt werden, sind grau hervorgehoben. Für die allgemeine Diagnose müssen wir beispielsweise BQ und Grafana nicht kennen. Das Ergebnis war ein ziemlich interessantes Bild.

Nezhdanchiki (Unterstützung)

Mehrere unerwartete Menschen tauchten auf, die zum Verständnis beitrugen:

• Welche der Kollegen sollten welche Fähigkeiten erwerben, um sie für neue Aufgaben zu gewinnen? (Geben Sie die Richtung der Entwicklung an);
• Wo können bei Verlust des Mitarbeiters Probleme auftreten?
• Wie angemessen ist das Gehalt des Mitarbeiters für seinen Aufgabenpool?
• Wie gut ist das Team besetzt und geschult?

Wir werden später auf jeden der Punkte eingehen.

Gehen wir zurück zum Tisch.



Formal ist Batman mit der allgemeinen Diagnose beschäftigt. Die Tabelle zeigt, dass der Joker ihn bei Bedarf gut ersetzen wird, da er immer noch ein Experte für UI ist - warum nicht? Das heißt, Batman ist hier austauschbar.

Der Joker ist im Allgemeinen gut gemacht - er ist fast überall versiert, außer vielleicht, um die Überwachung einzusetzen, aber dies kann gelehrt werden.



Es ist bekannt, dass der Joker seine Freizeit etwas exzentrisch verbringt und jederzeit arbeitslos werden kann. Was wird dann passieren? Dann wird mit der Diagnose des Deal-Verkehrs alles traurig.

Darüber hinaus haben wir keinen BQ-Experten! Das heißt, es ist dringend notwendig, jemanden hochzuziehen, um zu trainieren. Zum Beispiel können Sie Batman BQ und Ivanov - Graphite unterrichten.



Selbst mit einem solch vereinfachten Bewertungssystem können Sie für jeden Mitarbeiter einen bestimmten Betrag erhalten, um zu verstehen, wie kompetent und versiert er ist. Diese Schätzungen warfen ein weiteres Unerwartetes.

Zwei weitere interessante Dinge sind die Gesamtmenge des Teams und seine durchschnittliche Punktzahl. Genau genommen sind diese Zahlen allein nicht besonders interessant - die Dynamik ihrer Veränderungen von Monat zu Monat ist interessant. Wenn aus irgendeinem Grund die Gesamtzahl zu sinken begann, ging höchstwahrscheinlich jemand und ein schwacher Mitarbeiter kam - ein Problem mit der Konfiguration. Sie müssen sich an die Personalabteilung wenden. Wenn der Durchschnitt zu sinken beginnt, bedeutet dies, dass etwas mit dem Training nicht stimmt - der Teamleiter und nur der Teamleiter sind schuld.

Es ist wichtig, dass es sich in diesem Fall um ein Team-Lead-Tool handelt, das den Mitarbeitern nicht angezeigt wird, da die Bewertungen subjektiv sind.

Entwicklerteam

Im Dev Team ist alles etwas demokratischer, oder wir haben unsere Aufgabe nur kompliziert. Die Liste der Fähigkeiten im Entwicklungsteam ist größer, obwohl die Einheitlichkeit der Aufgaben wahrscheinlich höher ist.

Wir haben Ratschläge von 4 erfahrenen Entwicklern (einschließlich Teamleiter und Spezialist für Wissensmanagement) gesammelt, Brainstorming durchgeführt und Aufgaben und Fähigkeiten analysiert. Wir gingen einfach Schritt für Schritt und auf unsere persönlichen Gefühle zu, aber mehrere Leute analysierten die Aufgaben, legten sie auf Fähigkeiten und bildeten eine Liste.

Zuerst war es eine Liste, dann wurde sie in universellere Fähigkeiten strukturiert, einschließlich Codierung und separater Geschäftsfähigkeiten, da dies für unsere Entwickler ein wichtiger Teil ist. Und aus dieser Liste von Fähigkeiten bildete sich bereits die Matrix.

Die erste Iteration der Matrix enthielt nicht die sogenannten Soft Skills, dh was nicht als Hard Skills bezeichnet werden kann. Dies hängt mit der täglichen Arbeit zusammen und ist sogar Teil kritischer Fähigkeiten, einschließlich: Planung; Kommunikation mit dem Team; die Fähigkeit, den Entwicklungsprozess in Minigruppen oder selbst zu verwalten; Fähigkeit, Anforderungen beispielsweise während einer Codeüberprüfung zu formulieren.

Wir haben nicht alle diese Fähigkeiten sofort aufgenommen, weil wir nicht verstanden haben, wie man sie genau bewertet.

In der zweiten Iteration betraten sie das Bewertungssystem:

• Zerlegung von Aufgaben und allem, was damit zusammenhängt;
• Dokumentation und selbstdokumentierender Code
• die Fähigkeit, mit dem Projektmanager zu kommunizieren, dh zu verstehen, was er sagt, und die notwendigen Fragen der Reihe nach zu stellen;
• die Fähigkeit, Kommentare zu Codeüberprüfungen usw. korrekt zu formulieren

Übrigens über Soft Skills zur Unterstützung. Tatsache ist, dass die Soft Skills im Entwicklungsteam eine separate Bewertung erfordern. Es sind jedoch persönliche Eigenschaften erforderlich , die nur für den Entwickler für das Support-Team wünschenswert sind. Wenn eine Person eingestellt wurde, hat sie diese standardmäßig bereits.

In der Entwicklung haben wir das Konzept der "Soft Skills" aufgegeben und es als universelle Fähigkeiten bezeichnet. Dazu gehören beispielsweise keine Kenntnisse der englischen Sprache oder die Tatsache, dass Sie Ihr Team nicht wütend machen - dies beschreibt nicht den Charakter einer Person, da es nur näher an Soft Skills liegt. Wir bewerten Fähigkeiten irgendwo am Rande und haben uns deshalb einen solchen Namen ausgedacht - universelle Fähigkeiten .

Als die Liste der Fähigkeiten fertig war, bewerteten wir sie anhand einer kontinuierlichen Umfrage. Wir haben eine echte Prüfung durchgeführt, bei der einige der Fragen eine eindeutige Antwort vorschlugen und einige Arbeitssituationen diskutierten: "Was soll ich tun, wenn jemand etwas verzögert oder nicht tut?", "Wie würden Sie diese oder jene Funktionalität im Projekt implementieren?" . Dies hat uns sehr geholfen, da ich in diesem Teil der Fragen mit einer großen Anzahl von Entwicklern sprechen konnte.

Dann haben wir die Entwickler für jede Fähigkeit auf einer Skala von 1 bis 3 bewertet.

Die Fähigkeiten, die wir mit Hilfe der ersten Umfrage nicht beurteilen konnten, haben wir mit Hilfe von Peers (Peers) bewertet, dh sie haben darum gebeten, Kollegen zu bewerten. Zu dieser Zeit hatten wir keine Gruppenleiter, sonst hätten sie es tun können.

Diese Matrix sieht ungefähr so ​​aus.



Natürlich war es nicht möglich, alles ins Bild zu bringen, daher sind einige Dinge, zum Beispiel Korrelationen und das Profil der Entwickler, hier nicht klar. Trotzdem können Sie grob bewerten, was passiert, und sehen, wie klar es ist und was Sie messen können.

Farben entsprechen der Note. Es wurden die gleichen Metriken wie im Support-Team abgeleitet - insgesamt und verschiedene durchschnittliche Fähigkeiten.

Achten wir auf Dev8. Aus der Tabelle geht hervor, dass dies der erste Kündigungskandidat ist. Aber erstens hat er spezifisches Wissen in einer der Positionen, also brauchen wir ihn. Noch wichtiger ist jedoch, dass dieser Tisch kein Brennwerkzeug ist . Ich werde auch darüber erzählen, wir haben nicht alles dafür angefangen.

Durchschnittliche Fähigkeiten - Dies ist die Arbeit, deren Ergebnisse einen Plan zur Verbesserung der Fähigkeiten bilden sollten. Das heißt, wenn die Entwickler etwas nicht wissen, ist dies nicht ihr Problem. Dies bedeutet, dass wir ihnen nicht genügend Informationen gegeben haben und im Allgemeinen das Wissen über einige der Fähigkeiten im Unternehmen im Allgemeinen nicht ausreicht. Sie müssen entweder eine Dokumentation schreiben oder einen Spielplatz einrichten, damit sie üben können, oder einen externen Kurs kaufen, damit sie lernen, eine Sitzung zum Wissensaustausch durchführen, sie senden, um voneinander zu lernen, eine Weile zusammenarbeiten, Beziehen Sie die Person in ein anderes Projekt ein. Es kann verschiedene Optionen für den Wissensaustausch geben. Das Fazit ist, dass Sie zuerst ein Ereignis abhalten und erst dann über die Dynamik sprechen müssen.

Es ist wichtig zu beachten, dass nicht alle Entwickler einige Fähigkeiten benötigen, da unser Unternehmen eine Matrixstruktur hat. Sie erhalten sie, wenn sie die mit dieser Fertigkeit verbundene Aufgabe abgeschlossen haben. Andernfalls macht es keinen Sinn, insbesondere wenn die Fertigkeit nicht in der kritischen Liste enthalten ist. Zum Beispiel gibt es in einigen Teilen der Projekte kein uPredict, dies ist keine kritische Fähigkeit. Im Allgemeinen half uns dieser Ansatz zu formulieren, welche Fähigkeiten der Schlüssel sind und welche nicht und was ein Spezialist aufholen kann, wenn er eine solche praktische Aufgabe hat.

Ein weiterer wichtiger Punkt bei der Einstufung. Wir haben anfangs einen Fehler gemacht, der mehr provozierte, als der Widerstand des Teams sein konnte - wir haben den Wert der Bewertungen 1, 2 und 3 nicht verbalisiert. Sie waren auf der Ebene der Intuition in unseren Köpfen, aber wir konnten nicht antworten, warum ein Entwickler 1 bekam. und die zweite - 2. Die Entwickler teilten die Ergebnisse der Verbreitung miteinander und dies provozierte Konflikte. Im Gegensatz zur Selbsthilfegruppe haben wir auf Anfrage persönliche Bewertungen gemeldet, jedoch keine Fremden.

Sie müssen dies klar definieren und an alle weitergeben, zum Beispiel, dass in Lua-Wissen die Punktzahl lautet:

• 1 - bedeutet, dass der Entwickler alle grundlegenden Operatoren kennt, mit Datenstrukturen arbeitet und Funktionsklassen schreibt;
• 2 - weiß, wie man Code in Bibliotheken organisiert, arbeitet während des gesamten Projekts konsistent mit ihnen und weiß, was Metatabellen sind;
• 3 - kennt die Besonderheiten des Unternehmens und der Projekte, zum Beispiel die Coroutinen (die Besonderheiten der Funktionsweise unseres Servers mit Lua), die Funktionsweise von C ++ - Code mit Lua-Code, die auferlegten Einschränkungen, die Interpretation, den kompilierten Code und die Funktionsweise unseres JIT-Compilers.

Sie können also jede Fertigkeit zerlegen, denn irgendwo auf der Ebene der Intuition haben Sie sie bereits.

Hinweis für sich selbst:

• Verbalisieren Sie das Bewertungssystem, auch wenn Sie es niemandem zeigen.
• Versuchen Sie in den frühesten Phasen, erfahrene Entwickler einzubeziehen. Sie wissen, wer den größten Widerstand hat, nehmen Sie ihn sofort in die Arbeit auf. Entfernen Sie alle Einwände im Voraus, wie dies im Verkauf der Fall ist.

Wie zu implementieren

Als die primäre Matrix fertig war, haben wir im Entwicklungsteam Metriken angehängt . Grundsätzlich war es der Prozentsatz der maximalen Skill-Bewertungen, mit dem Sie dem Entwickler eine Note geben können.

Zusätzlich zur Bewertung der individuellen Fähigkeiten mussten wir Entwickler bewerten. Wir hatten die Klassen A, B und C - so etwas wie Junior, Middle, Senior. Bei IT Junior, Middle, Senior ist es bereits zu bedeutungsvoll, in das unter anderem Berufserfahrung investiert wird. , . A, B C — . « » .

— .

, . , , , , .

, - , , . , , . , - — , , , .

, . , , . , . .

performance review . , 1 2, ( ) .

— performance review , .

(Dev Team)

. , , . , , , . . 5-6 2-3. . -, , . ( ) .

, , . . , , , . , , . , , playground, .

, , . , , , , . . . -, .

. , - : « ? ?».

, , , — , , , . .

Fälle

, . - , , .



, CI, . , . , 8.



, , , , , -. .

, — -. .


:

• 4 , .. ;
• 1 , ;
• 0,5 HR-, , , .

Und alle! 30 . , , , , , , .

Entwicklerteam

. : ( ) 3-4 . , :

• , — 3-4 ( 4 ) — , .
• , , , , — 6 .
• . . , senior'. 2 knowledge- 2 .
• — ( 3-4 ). , 100 , .
• — 2 . , .

, - , - . .

, .

— , .

, - , . , , , , . : , , ..


Support - easy medium, Dev Team — medium.

, , . , . , , , .

.

• , , .

, , . ( ), . performance review, .

, , — . .

• . , , , , .
• , - — . . , , .

, HR, , -, , -, , , -, HR - . HR , , .

• , .

-. . , , . , . — - , — . .

• Don't try this at home — - , :)

, .

, , KnowledgeConf 2019 26 .

, ( , , , , ) ( ).

. , , , . .