Wie man die Teameffektivität bewertet

Ein cooles Startup zu Beginn seiner Reise ähnelt Sapsan. Ein kleines Team gewinnt schnell an Dynamik und eilt in die Zukunft, um eine Reihe von Aufgaben in die Produktion zu bringen. Wenn sich das Projekt als vielversprechend herausstellte, wie beispielsweise Skyeng, wird es in einigen Jahren deutlich mehr Teams geben, und es ist möglich, dass es unter ihnen Dampflokomotiven gibt, in denen Sie ständig Brennholz in den Ofen werfen müssen, damit zumindest etwas die Benutzer erreicht.


Schauen Sie sich Alexey Kataevs Vortrag bei Saint TeamLead Conf an oder lesen Sie ihn, wenn Sie nicht wissen, nach welchen formalen Kriterien Sie feststellen können, ob Ihr Team großartig ist . Wenn Sie in der Lage sein möchten, die technische Verschuldung in Stunden zu messen, anstatt mit den Kategorien „ziemlich viel“, „wie viel“, „schrecklich viel“ zu arbeiten. Wenn Ihr Produktmanager glaubt, dass ein Team von drei Personen in einem Monat 60 Aufgaben erledigt, zeigen Sie ihm diesen Artikel. Wenn Ihr Manager die Entwicklung mit Metriken aufgehängt hat und Ihnen vorschlägt, Maßnahmen zu ergreifen, die auf folgenden Ergebnissen basieren: „34% glauben, dass das Team ein Problem mit der Planung hat“, ist dieser Bericht für Sie.



Über den Sprecher: Alexei Kataev ( deusdeorum ) beschäftigt sich seit 15 Jahren mit Webentwicklung. Hat es geschafft, als Backend, Frontend, Fullstack-Entwickler und Teamleiter zu arbeiten. Derzeit an der Rationalisierung der Entwicklungsprozesse bei Skyeng beteiligt . Ist Teamleitern möglicherweise vertraut, wenn sie über die Arbeit eines verteilten Teams sprechen .

Jetzt geben wir endlich das Wort an den Sprecher weiter. Beginnen wir mit dem Kontext und gehen wir schrittweise zum Hauptproblem über.



Ich bin 2015 zu Skyeng gekommen und war einer von fünf Entwicklern - sie waren alle Entwickler im Unternehmen.

Etwas mehr als drei Jahre sind vergangen, und jetzt haben wir 15 Teams - das sind 68 Entwickler .



Alle Entwickler arbeiten remote , sie sind auf der ganzen Welt verstreut.

Schauen wir uns die Probleme an, die unvermeidlich auftreten, wenn ein Unternehmen von 5 auf 68 Mitarbeiter skaliert wird.

Auf dem Bild ist Sergey der Entwicklungsleiter.


Einmal hatten wir ein Team, und es war Sapsan, der in die Zukunft eilte und eine Reihe von Aufgaben in der Produktion übernahm. Aber nicht nur Aufgaben, sondern auch ein bisschen technische Schulden. Dann gab es irgendwann, unerwartet für uns, viel mehr Teams.

Die erste Frage, mit der Sergey konfrontiert ist, ist, ob alle unsere Teams Sapsaner sind oder ob es unter uns Dampfmaschinen gibt , bei denen Sie Brennholz in den Feuerraum werfen müssen.


Diese Frage ist wichtig, da eine solche Situation auftreten kann: Ein Produktmanager oder Unternehmensvertreter wird zu Sergey kommen und sagen, dass wir keine Zeit haben, das Team arbeitet schlecht. Tatsächlich kann das Problem aber nicht nur im Team liegen. Das Problem kann in der Beziehung zwischen dem Team und dem Unternehmen oder im Unternehmen selbst liegen - es setzt möglicherweise keine guten Ziele oder hat zu optimistische Pläne.

Sie müssen verstehen, ob das Team cool ist .


Die zweite Frage sind die Ressourcen des Teams : Wie viele Aufgaben können wir an den Produkten übernehmen? Dieses Problem ist wichtig, da das Produkt für die nahe Zukunft immer viele Pläne hat. Es ist wichtig zu verstehen, ob das Team mit diesen Plänen fertig wird oder ob Sie die Hälfte der Aufgaben wegwerfen müssen. Oder es lohnt sich, noch ein paar Leute einzustellen, um alle Aufgaben zu erledigen.


Die dritte Frage ist, wie viel technische Schulden wir bei uns tragen. Dies ist eine kritische Frage, denn wenn die Menge den Grenzwert überschreitet, kann unser Zug am Ende überhaupt nicht mehr fahren. Wir müssen das Team entlassen, das Projekt von vorne beginnen und wollen dies nicht zulassen.


Schließlich - wie stellen wir sicher, dass alle Teams Sapsaner und keine Züge sind?

1. Wir bestimmen, wie cool unsere Teams sind.

Das erste, was mir in den Sinn kommt, ist natürlich, einige Metriken zu messen! Jetzt erzähle ich Ihnen von unseren Erfahrungen und wie wir uns immer wieder geirrt haben.


Zunächst haben wir versucht, die Geschwindigkeit zu überwachen - wie viele Aufgaben wir für den Sprint ausführen. Es stellte sich jedoch heraus, dass die Hälfte unserer Teams überhaupt keine Sprints hat, sondern Kanban. Und wo es Sprints gibt, werden Aufgaben in Stunden oder in Story-Punkten bewertet. Es gibt immer noch ein paar Teams, die nur die Aufgaben erledigen - sie haben kein Kanban, sie wissen nicht, was Scrum ist.

Dies ist eine Dateninkonsistenz. Wir versuchen, eine Zahl für völlig unterschiedliche Daten zu berechnen. Gleichzeitig ist es sehr teuer, überall Sprints zu machen, damit alle Teams identisch sind. Um eine Metrik zu berechnen, müsste man Prozesse ändern.

Wir dachten, versuchten ein paar weitere Optionen und kamen zu einer einfachen Metrik - der Umsetzung von Plänen . Es ist auch teuer, aber nur Produktpläne müssen identisch und konsistent gemacht werden. Jemand führt sie zu Jira, jemand bei Google Spreadsheets, jemand erstellt Diagramme - die Konvertierung in ein Format ist viel billiger als das Ändern von Prozessen in Teams.

Jedes Quartal sehen wir, ob das Team die Geschäftsanforderungen erfüllt und wie viele geplante Aufgaben erledigt wurden.


Das Zählen der Anzahl der Vorfälle ist ebenfalls fehlgeschlagen.

Wir protokollieren jeden fehlgeschlagenen Rollout oder Fehler, der das Unternehmen beschädigt hat, und post mortem. Sergei kam als Teamleiter zu mir und sagte: „Ihr Team gibt die meisten Stürze zu. Warum so?" Wir dachten, schauten und es stellte sich heraus, dass unser Team das verantwortungsvollste und einzige ist, das alle Stürze protokolliert. Der Rest handelt nach dem Prinzip der schnellen Erhöhung, die nicht als gefallen angesehen wird.

Das Problem ist wiederum Dateninkonsistenz und unzureichende Abtastung. Wir haben Teams, die nur eine Landung haben - es stürzt überhaupt nicht ab. Wir können nicht sagen, dass dieses Team besser ist, weil es ein stabileres Projekt hat.

Das zweite - mein Lieblingsthema - ist kognitive Verzerrung . Kognitive Leichtigkeit ist, wenn wir eine Schlussfolgerung ziehen, die uns einfach erscheint, und sofort anfangen, daran zu glauben. Kritisches Denken schließen wir nicht ein: Wenn es viele Stürze gibt, bedeutet dies ein schlechtes Team.

Wir sind zu genau der gleichen Metrik für die Anzahl der Vorfälle gekommen, haben jedoch nur die Implementierung überarbeitet. Wir haben einen Prozess erstellt, bei dem alle Stürze protokolliert werden . Am Ende eines jeden Monats fragen wir Leute, die nicht daran interessiert sind, Vorfälle zu verbergen - dies sind Qualitätssicherung und Produkte. Dies ist eine vollständige Liste der Probleme, die aufgrund der Schuld des Teams aufgetreten sind. Sie erinnern sich, als wir etwas fallen ließen, und ergänzen diese Liste.


Es gibt auch Probleme mit Umfragen. Es scheint ein super-universelles Werkzeug zu sein - wir werden alle (Produkte, Teamleiter, Kunden) befragen, welche Probleme wir in Teams haben. Entsprechend ihren Antworten werden wir Diagramme erstellen und alles herausfinden. Aber es gibt viele Probleme.

Erstens, wenn Sie geschlossene Fragen stellen, können aus diesen Daten keine Schlussfolgerungen gezogen werden. Zum Beispiel fragen wir: "Hat das Team ein Problem mit der Planung?" und 34% sagen, dass es gibt - und was tun? Wenn Sie offene Fragen stellen: "Was sind die Probleme im Team mit der Infrastruktur?" - Sie erhalten leere Antworten, weil jeder zu faul ist, um etwas zu schreiben. Aus diesen Daten können keine Schlussfolgerungen gezogen werden .

Wir haben diese Idee entwickelt - zuerst führen wir Umfragen als Screening durch und dann Interviews, um zu verstehen, was genau das Problem ist. Wir werden etwas später über das Interview sprechen.

Ich habe drei Beispiele gegeben, tatsächlich haben wir Dutzende von Metriken ausprobiert .

Jetzt verwenden wir nur:

• Erfüllung von Plänen.
• Die Anzahl der Vorfälle.
• Umfragen + Interviews.

Ich täusche, wenn ich sage, dass wir diese einfachen Dinge sogar in allen Teams messen, weil das teuerste die Implementierung ist . Besonders wenn es 15 verschiedene Teams gibt, wenn das Produkt sagt: "Ja, wir brauchen es überhaupt nicht! Wir müssten unsere Aufgabe ausrollen, jetzt ist es nicht mehr so ​​weit! “ Es ist sehr schwierig, es so zu machen, dass in allen Teams eine Zahl gemessen wird.

Das Interview

Lassen Sie uns einen kurzen Exkurs über das Interview mit den Entwicklern machen . Ich las mehrere Artikel, ging durch den Lebensmittelkurs. Es gibt viel über Benutzerforschung und Kundenentwicklung. Ich habe von dort aus mehrere Übungen gemacht, und sie sind sehr gut in die Kommunikation mit den Entwicklern gefallen.

Wenn Sie herausfinden möchten, welche Probleme das Team hat, sollten Sie zunächst gezielte Fragen schreiben, auf die Sie nach einer Antwort suchen. Das heißt, Sie werfen nicht nur 30 Fragen, sondern wählen 2-3 Fragen aus , auf die Sie eine Antwort suchen. Zum Beispiel: Hat das Team Infrastrukturprobleme? wie die Kommunikation zwischen Unternehmen und Team hergestellt wird.

In diesem Fall sollten die Fragen lauten:

• Öffnen . Die Antwort auf die Frage: "Gibt es ein Problem?" "Ja!" "Er wird dir nichts sagen."
• Neutral Eine Frage zu einem Problem ist eine schlechte Frage. Fragen Sie besser: "Erzählen Sie mir von dem Planungsprozess in Ihrem Team." Eine Person spricht über den Prozess, und Sie beginnen bereits, ihm tiefere Fragen zu stellen.

Ein weiterer sehr guter Ansatz ist die Priorisierung . Sie haben verschiedene Aspekte des Teamlebens. Sie fragen den Mitarbeiter, welche seiner Meinung nach die coolsten sind und gleich bleiben sollen und welche vielleicht verbessert werden sollten.

Es gibt einen anderen Ansatz, den ich aus dem Kapitel über Interviews im Buch „Who. Lösen Sie Ihr Problem Nummer eins "- stellen Sie Fragen wie diese:" Wenn ich ein Produkt fragen würde, was denken Sie, welche Probleme würde er nennen? " Dies zwingt den Entwickler, das Gesamtbild und nicht von seiner Position aus zu betrachten, um alle Probleme zu erkennen.

2. Bewerten Sie die Ressourcen

Lassen Sie uns nun über die Bewertung von Ressourcen sprechen.

Beginnen wir mit dem Ansatz des Produkts - da er normalerweise die Ressourcen seines Teams bewertet. Es gibt 3 Personen, 20 Arbeitstage im Monat - wir multiplizieren Personen mit Tagen, wir erhalten 60 Aufgaben.



Natürlich übertreibe ich, ein normales Produkt wird dies als 60 Tage Entwicklung multiplizieren. Dies ist aber auch falsch. Niemand wird jemals Aufgaben für 60 Tage in 60 Tagen ausführen. Sogar Scrum empfiehlt Ihnen, den Fokusfaktor zu berücksichtigen und mit einer bestimmten magischen Zahl zu multiplizieren, z. B. 0,2. Tatsächlich werden wir von Iteration zu Iteration 12, dann 17 und dann 10 Aufgaben ausführen. Ich denke, das ist eine sehr grobe Einschätzung.

Ich habe meinen eigenen Ansatz zur Bewertung von Ressourcen. Zunächst betrachten wir die gesamte Ressource des Teams in Arbeitsstunden. Wir multiplizieren Stunden mit Entwicklern, wir nehmen Urlaub und freie Tage weg. Angenommen, Sie erhalten 750. Aber nicht jede Entwicklung ist die Entwicklung selbst.


Oben sind reale Daten am Beispiel eines der Befehle dargestellt:

• 36,9% der für die Kommunikation aufgewendeten Zeit entfallen auf Besprechungen, Diskussionen, technische Überprüfungen, Codeüberprüfungen usw.
• 63,1% - direkt zur Lösung von Problemen.

Kann das Produkt auf diese 63,1% zählen? Nein, das kann es nicht, denn Produktaufgaben sind nur ein Teil. Es gibt immer noch eine Quote (ca. 20%) für die Behebung von Fehlern und das Refactoring . Dies ist, was der Timlid verteilt, und das Produkt zählt nicht mehr auf diese Zeit.


Auch von den Produktaufgaben sind nicht alle Aufgaben diejenigen, die das Produkt geplant hat. Es gibt Produktaufgaben anderer Teams, die wegen der Veröffentlichung um dringende Hilfe bitten. Wir schätzen ungefähr 8–10% der Aufgaben, die von anderen Teams kommen .


Und jetzt haben wir 287 Stunden! Alles wäre cool, wenn wir immer in unsere Noten passen würden. In diesem Team wurde jedoch der durchschnittliche Mehraufwand gezählt - 1,51, dh die Aufgabe dauerte im Durchschnitt eineinhalb Mal länger als angenommen.


Insgesamt verbleiben noch 750 Stunden, um die Hauptaufgaben zu erledigen . Dies ist natürlich eine Annäherung, aber diese Formel enthält Variablen, die geändert werden können. Wenn Sie beispielsweise einen Monat für das Refactoring verwenden, können Sie diesen Wert ersetzen und herausfinden, worauf Sie zählen können.

Ich habe mich den ganzen Tag dem gewidmet - ich habe Aufgaben übernommen, in Excel die durchschnittliche Zeit berechnet, analysiert - ich habe viel Zeit verbracht und beschlossen, dass ich es nie wieder tun würde. Ich brauche dafür einen schnellen Ansatz, um es nicht jedes Mal mit meinen Händen zu tun.

Mir wurde ein Plugin für Jira und EazyBI empfohlen . Dies ist ein super kompliziertes Werkzeug, oder ich hatte nicht genug Fähigkeiten, aber in der Mitte habe ich aufgegeben.

Ich habe einen Weg gefunden, schnell Berichte zu erstellen.


Laden Sie die Daten von Ihrem Task-Tracker in ein beliebiges DBMS hoch (PostgreSQL für uns), und bitten Sie den Analysten, alles zu berechnen. Wir haben es Dima, und er hat alles in 2 Stunden berechnet.


Gleichzeitig gab er eine Reihe zusätzlicher Daten heraus - Überstunden für Entwickler, Überstunden für Aufgabentypen, einige Faktoren, erzählte uns von seinen Erkenntnissen und neuen Hypothesen - lustig und skalierbar: Sie können sie sofort in allen Teams verwenden.

So erhöhen Sie die Ressource

Nun geht es darum, wie Sie ein Team beschleunigen können - erhöhen Sie seine Ressourcen, ohne die Anzahl der Entwickler zu erhöhen.

Um etwas zu beschleunigen, müssen Sie es zuerst messen. Wir zählen normalerweise zwei Metriken:

1. Erste zusammenfassende Bewertung der Aufgaben für die Iteration in Stunden. Zum Beispiel haben wir Aufgaben für 100 Stunden pro Woche eingeführt.
   
2. Und manchmal ist die durchschnittliche Rollzeit die Zeit ab dem Zeitpunkt, an dem die Aufgabe entwickelt wurde, bevor sie in Produktion geht. Dies ist eine eher geschäftliche Kennzahl und für das Produkt interessant, nicht für den Entwickler.
   

Ich werde nicht müde, dem Bot Arseny zu erzählen, den ich über das Wochenende geschrieben habe. Jede Woche veröffentlicht er eine Übersicht - wie viele Aufgaben haben wir ausgerollt.



Hier gibt es zwei interessante Dinge:

1. Was ich als Beobachter-Effekt bezeichne - wenn wir einen Indikator bewerten, ändern wir ihn bereits. Sobald wir diesen Bot verwendet haben, haben wir die Anzahl der Aufgaben erhöht, die wir während der Iteration ausführen.
   
2. Die Metrik sollte motivierend sein . Ich habe zunächst gezeigt, wie weit wir keine Zeit zum Sprinten haben. Es stellte sich heraus, dass wir um 10%, um 20% nicht pünktlich waren. Dies motiviert überhaupt nicht, es wird keinen Beobachter-Effekt geben.
   

Geschwindigkeit ist eine nacheilende Metrik, die wir nicht direkt beeinflussen können. Es zeigt etwas, aber es gibt Metriken, die beeinflussen, welche wir die Geschwindigkeit beeinflussen können. Meiner Meinung nach gibt es zwei Hauptpunkte:

1. Die Genauigkeit der Bewertungsaufgaben.
Hier wurde uns erneut von unserem beauftragten Analysten Dima geholfen, der die tatsächliche Zeit der Aufgabe in Abhängigkeit von der anfänglichen Einschätzung berechnete.


Das sind echte Daten. Oben sehen Sie eine Grafik der tatsächlichen Zeit, um die Aufgabe zu erledigen, und unten unsere Schätzung.

Joel Spolsky behauptet, dass 16 Stunden pro Aufgabe das Limit sind. Für uns ist klar, dass nach 12 Stunden die Bewertung keinen Sinn ergibt, die Varianz dort zu groß ist. Wir haben Soft-Limit wirklich eingeführt und versuchen, die Aufgaben nicht länger als 12 Stunden zu bewerten. Danach entweder Zersetzung oder zusätzliche Forschung.

2. Zeitverschwendung, wenn Entwickler Zeit für etwas aufwenden, für das sie es möglicherweise nicht ausgeben.
In einem unserer Teams wurden bis zu 50% der Zeit für die Kommunikation aufgewendet. Wir begannen zu analysieren und zu verstehen, was der Grund war. Es stellte sich heraus, dass das Problem in den Prozessen liegt: Alle Kunden schrieben direkt an die Entwickler und stellten Fragen. Wir haben die Prozesse ein wenig geändert, diese Zeit verkürzt und die Geschwindigkeitsanzeigen verbessert.

In Ihrem Fall handelt es sich nicht unbedingt um Kommunikation. Beispielsweise ist es möglicherweise Zeit für die Bereitstellung oder die Infrastruktur. Voraussetzung dafür ist jedoch, dass alle Entwickler Zeit protokollieren müssen. Wenn niemand Ihre Zeit in Jira protokolliert, ist die Implementierung natürlich sehr teuer.

3. Umgang mit technischen Schulden

Wenn ich "technische Pflicht" sage, stelle ich es mir als etwas Unscharfes vor - ist nicht klar, wie es gemessen werden kann?


Wenn ich Ihnen sage, dass wir in einem der Teams genau 648 Stunden technischen Dienst haben, werden Sie mir nicht glauben. Aber ich werde Ihnen den Algorithmus sagen, an dem wir ihn messen.


Wir versammeln uns einmal im Quartal als ganzes Team (wir nennen es ein Refactoring-Treffen) und entwickeln Karten: Welche Krücken (unsere und andere) haben die Leute im Code gesehen, zweifelhafte Entscheidungen und andere schlechte Dinge, zum Beispiel alte Versionen von Bibliotheken - alles. Nachdem wir ein paar dieser Karten generiert haben, schreiben wir für jede eine Auflösung - was damit zu tun ist. Vielleicht tun Sie nichts, weil es überhaupt keine technische Aufgabe ist oder Sie die Bibliotheksversion, den Refactor usw. aktualisieren müssen. Als nächstes erstellen wir Tickets in Jira, wo wir schreiben: "Das ist das Problem - das ist seine Lösung."

Und hier haben wir 150 Tickets in Jira - was machen wir damit?



Danach führen wir eine Umfrage durch, die für einen Entwickler 10 Minuten dauert. Jeder Entwickler gibt eine Bewertung von 1 bis 5, wobei 1 - "Eines Tages werden wir es im nächsten Leben tun" und 5 - "Wir müssen es jetzt tun, es verlangsamt uns wirklich." Wir fügen diese Bewertung direkt dem Ticket in Jira hinzu. Wir haben ein benutzerdefiniertes Feld erstellt, das als "Refactoring Priority" bezeichnet wird, und dadurch erhalten wir eine priorisierte Liste unserer technischen Schulden und Probleme. Nachdem wir die ersten 10 bis 20 bewertet und dann den Schwanz mit der Durchschnittsbewertung multipliziert haben (wir sind zu faul, um alle 150 Tickets zu bewerten), erhalten wir innerhalb von Stunden technische Schulden .

Warum brauchen wir das? Wir führen diese Bewertung einmal im Quartal durch. Wenn wir im ersten Quartal 700 Stunden hatten und dann zum Beispiel 800 Stunden, dann ist alles in Ordnung. Und wenn es 1400 wurde, bedeutet dies, dass es eine Bedrohung gibt und es notwendig ist, die Quote für das Refactoring zu erhöhen - stimmen Sie dem Geschäft zu, dass wir jetzt den ganzen Monat oder 40% aller Zeiten refactorieren werden.

Nun, wir haben das Problem der technischen Schulden gelöst, es ist unter Verschluss.


Aber lassen Sie uns über die Gründe sprechen, die zu seinem Auftreten geführt haben. Dies ist meistens eine schlechte Codeüberprüfung.

Schlechte Codeüberprüfung

Einer der Hauptgründe für eine schlechte Codeüberprüfung ist der Busfaktor. Wir haben gelernt, den Busfaktor zu formalisieren . Wir nehmen ein Team, schreiben eine Liste der Bereiche auf, die für dieses Team relevant sind, zum Beispiel für ein Plattformteam: Videokommunikation, Synchronisation von Übungen, Werkzeuge. Jeder Entwickler gibt eine Bewertung von 1 bis 3:

• 1 - "Ich verstehe nicht, was es ist, ich habe es ein paar Mal gehört."
• 2 - "Ich kann Aufgaben aus diesem Bereich erledigen."
• 3 - "Ich bin ein super Experte auf diesem Gebiet."

, , , .

bus-factor' ?

, , . , , , -, , -, . - , . - , . Eines Tages werden wir schreiben.


code review, . , review code review. pull requests, code review . , , - , review. - — , — , code review .

. — , .

4.

. , , cross review . -, : , , , . , . , .

, Google Suite : , , , .

— - .


-, . , , Continuous Integration ..

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

:

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

Bonus

, .

• QA- — 10 , .
• , - Skyeng - . — , , .
• open source, , .

Telegram (@ax8080) facebook , .

Ich erinnere Sie daran, dass Call for Papers auf der TeamLead Conf 2019-Konferenz für Teamleiter, die vom 25. bis 26. Februar in Moskau stattfinden wird, bereits geöffnet ist. Hier finden Sie eine Zusammenfassung der Einreichung eines Berichts und der Teilnahmebedingungen. Dies ist ein Link zum Antragsformular.

Und bleib bei uns! Wir werden weiterhin Artikel und Videos über das Management von Entwicklungsteams veröffentlichen. Im Newsletter werden wir mehrere Wochen lang eine Auswahl nützlicher Materialien sammeln und über Konferenznachrichten schreiben.