👩🏽‍🤝‍👨🏿 ☯️ 😫 "Was tun, wenn dramatische Änderungen in den Prozessen ein Team demotivieren?" Die Erfahrung des Backend-Ingenieurs, der Teamleiter wurde 🤷🏽 🕤 💍

Ich habe 7 Jahre als Backend-Ingenieur bei Miro gearbeitet und bin dann Teamleiter geworden. In den letzten Jahren hat sich unser Engineering-Team verdoppelt, ist verteilt und international geworden, was viele Änderungen mit sich brachte.

Eine davon war die Einführung funktionsübergreifender Teams, die das Problem vollständig lösen konnten, von der Entwicklung der Idee bis zur Veröffentlichung von Funktionen. Dafür mussten die Backend- und Frontend-Ingenieure schnell viel von dem lernen, was wir noch nie zuvor getan hatten: Testen, Arbeiten mit Releases, Durchführen von Scrum-Ritualen - ohne an Geschwindigkeit und Qualität zu verlieren.

Die ersten Schritte in diese Richtung führten zu einer Zunahme der Fehleranzahl, einer Verringerung der Entwicklungsgeschwindigkeit und einer Demotivierung der Teams. In dieser schwierigen Zeit wurde ich nur Teamleiter, und meine persönliche Angst vor dem Scheitern und meine eigene Inkompetenz trugen zum allgemeinen Stress bei.

Infolgedessen haben wir den Sturm gemeistert, die Vorlaufzeit halbiert und die Effektivität funktionsübergreifender Teams erheblich verbessert. Dies wurde größtenteils durch eine Änderung unserer Einstellung zu den laufenden Änderungen, dem Übergang von einer festen Denkweise zu einer Wachstums-Denkweise, unterstützt.

Unten finden Sie ein Video und eine Abschrift meiner Leistung bei Saint TeamLead Conf 2019, in der ich am Beispiel meines Teams über die Prozesse und Tools spreche, die diese Änderungen ermöglicht haben.

Geschichte Nr. 1. Ändern des Entwicklungsprozesses, um die Vorlaufzeit zu verkürzen

Im Jahr 2016 bestand unsere Entwicklung aus 20 Personen und 5 Teams. Die Teams interagierten effektiv miteinander, tauschten schnell Informationen und Erfahrungen aus. Mit dem Wachstum von Mitarbeitern und Teams, der Einführung von CI / CD-Prozessen und Codeüberprüfungen nahm die Anzahl der Abhängigkeiten zwischen Teams zu.

Um beispielsweise ein großes Feature auf einem Produkt zu starten, musste das Team mit 6 weiteren Entwicklungsteams zusammenarbeiten:

Geben Sie Code zur Codeüberprüfung.
Geben Sie dem QS-Test eine Funktion. Bei Bedarf enthält die Qualitätssicherung den Befehl DevOps, um eine spezielle Testumgebung zu erstellen.
Entlasten Sie die Funktion mithilfe des Release-Managers, der für alle Releases im Unternehmen verantwortlich ist.
Schließen Sie zusätzliche Befehle an, wenn während der Freigabe ein Fehler auftritt.

Und dies ohne Berücksichtigung der Abhängigkeiten mit den Teams für Marketing, Design und technischen Support, die auch aktiv an der Einführung von Funktionen beteiligt sind.

Je mehr Abhängigkeiten, desto mehr Vorlaufzeit, dh die Zeit vom Beginn der Entwicklung bis zur Veröffentlichung. Je höher die Vorlaufzeit, desto weniger Wert liefern wir den Benutzern.

Eine große Anzahl von Kommunikationen und eine niedrige Liefergeschwindigkeit demotivieren das Team. Was zu tun ist? Reduzieren Sie Abhängigkeiten und verkürzen Sie die Vorlaufzeit.

Wir versuchen, ein Förderband in der Entwicklung zu bauen

Um dieses Problem zu lösen, haben wir zunächst versucht, ein Förderband zu bauen:

Beschreiben Sie alle Phasen und Prozesse.
Einführung von SLA (Service Level Agreement, erforderliche Qualitätsstufe), um die Zeit zu bestimmen, für die die Aufgabe jede Phase durchlaufen muss;
Begradigen Sie die Flüsse, um zu verhindern, dass sich die Aufgabe zur Verbesserung in die vorherigen Phasen zurückzieht.

Leider funktionierte die Pipeline nicht: Ein Fehler führte zu jedem Zeitpunkt zur Unterbrechung der gesamten Kette, während jedes Team gleichzeitig gezwungen war, Probleme aus seinem eigenen Rückstand zu lösen. Zum Beispiel musste die Qualitätssicherung Folgendes auswählen: um einen Fehler in der Pipeline zu beheben oder um Aufgaben zur Verbesserung des Testprozesses auszuführen. Dieses Problem der Priorisierung führte dazu, dass wir entweder Funktionen freigegeben haben, es jedoch nicht geschafft haben, interne Prozesse zu verbessern, oder an der Prozessoptimierung beteiligt waren und keine Zeit hatten, Funktionen freizugeben.

Dann haben wir beschlossen, den Förderer umzubauen, um ihn in jedem Team zu bewegen.

Der Versuch, funktionsübergreifende Teams aufzubauen

Funktionsübergreifende Teams können die Aufgabe von Anfang bis Ende bewältigen: von der Ausarbeitung der Idee bis zur Fertigstellung des fertigen Features für das Produkt. Dafür muss das Team über alle erforderlichen Kompetenzen, Kenntnisse und Prozesse verfügen.

Wir haben beschlossen, ein Experiment in mehreren Teams durchzuführen, bevor wir die Änderungen auf das gesamte Unternehmen übertragen. Mein Team, das sich hauptsächlich mit Aufgaben auf niedriger Ebene befasst, nahm ebenfalls an dem Experiment teil (ich schrieb über eines unserer Arbeitsbeispiele - die Implementierung von ActiveMQ und Hazelcast). Das Team bestand aus 3 Backend-Entwicklern, einem Teilzeit-QS-Ingenieur und mir als Teamleiter.

Wir bestimmen die Abhängigkeiten

Zunächst haben wir die aktuellen Abhängigkeiten ermittelt, die wir entfernen möchten:

Es gibt keinen Vollzeit-QS-Ingenieur, weshalb wir von einigen Tagen bis zu einer Woche auf Tests warten können.
, -.
full-time -, , .

Es gab andere Abhängigkeiten, aber wir haben beschlossen, uns hauptsächlich auf die drei zu konzentrieren. Jetzt mussten wir viel von dem lernen, was der QS-Ingenieur, Scrum-Master und Release-Manager zuvor getan hatte.

Wir lernen, unabhängig zu testen.
Zuvor haben Ingenieure unabhängig voneinander Komponententests geschrieben und die Grundfunktionalität getestet, der Rest hat die Qualitätssicherung überprüft. Jetzt haben wir gelernt, wie man Grenzsituationen unabhängig testet und End-to-End-Tests schreibt, um die Interaktion zwischen Client und Server zu testen.

Lernen, sich selbst freizulassen
Wir waren uns einig, dass wir mindestens einmal pro Woche freigeben wollen. Dazu benötigen wir einen Release Manager im Team. Einer der Backend-Entwickler wurde von selbst.

Wir führen Scrum-Rituale selbst durch
Der externe Scrum Master hatte nicht die Zeit, sich mit allen Teams zu befassen. Deshalb haben wir in unserem Team denjenigen ausgewählt, der sich diese Rolle gewünscht hat. Er musste lernen, wie man selbständig plant, pflegt und retro macht.

Natürlich warf uns niemand auf die Barrikaden. QA, Release Manager und Scrum Master haben ihr Wissen weitergegeben und in schwierigen Fällen beraten.

Erste Ausfälle

Die Ergebnisse des ersten Sprints waren erfolglos. Wir haben wirklich angefangen, Aufgaben viel schneller in die Hauptniederlassung zu bringen, aber wir konnten nicht unabhängig eine einzige Version erstellen. Es stellte sich heraus, dass unsere Prozesse und Skripte dafür nicht bereit waren. Das Freigabeskript konnte nur alle Dienste gleichzeitig freigeben, sodass wir unseren Teil des Dienstes nicht separat freigeben konnten.

Wir haben einen Teil der Prozesse verdreht und am Ende des zweiten Sprints die Aufgaben aus dem ersten Sprint in das Release aufgenommen. Es ging jedoch wieder etwas schief. Die Hälfte der veröffentlichten Funktionen enthielt kritische Fehler, daher haben wir beschlossen, die Version zurückzusetzen. Und sie standen vor einem neuen Problem: Unser Backend-Entwickler und Teilzeit-Release-Manager im Team lernte das Release, lernte aber immer noch nicht, die Änderungen zurückzusetzen. Daher brauchten wir die Hilfe eines externen Release Managers.

All dies führte zur Demotivierung des Teams: Wir scheitern beim zweiten Sprint in Folge, geben Funktionen mit kritischen Fehlern frei - das Gefühl, dass wir alleine nichts tun können.

Geschichte Nr. 2. Eine neue Rolle und Angst vor Fehlern

Zu Beginn des Experiments mit funktionsübergreifenden Teams meldete sich Max, einer der Backend-Ingenieure, freiwillig als Scrum Master. Nach dem ersten Sprint kam er jedoch auf mich zu und sagte, dass er kein Scrum Master mehr sein wollte. Nach Max kam Andrei, ein anderer Ingenieur, und sagte, er würde nicht testen: "Ich bin ein Entwickler, kein Tester." Als Teamleiter war es mir wichtig, die Ursachen beider Fehler zu verstehen.

In der Regel ist einer der vier Gründe, die mit jedem von ihnen zusammenarbeiten können, der Eckpfeiler der Entscheidung, die Aufgabe abzulehnen:

   → , , .
(, , ) → , .
  , → : , .
   → .

Max verstand den Wert, den der Scrum Master für das Team bringt, hatte jedoch Angst, die schwierigen Aufgaben der Moderation von Meetings nicht zu bewältigen. Er stimmte einer neuen Rolle zu, wusste wenig über die Arbeit des Scrum Masters und gab sich keinen vollständigen Überblick über die Fähigkeiten, die er dafür benötigen würde. Max hatte Angst, dass er nicht damit fertig werden könnte, er würde die Zeit des Teams verschwenden und in den Augen seiner Kollegen inkompetent aussehen.

In der Situation mit Andrei stellte sich heraus, dass er seinen Code selbst getestet hatte und sicher war, dass alles in Ordnung war. Für alle Fälle gab ich jedoch eine Qualitätssicherung zur Überprüfung und er fand 5 Fehler im Code. Dies wurde mehrmals wiederholt, was Andrei demotivierte, und er beschloss, keine Tests mehr durchzuführen.

Ich war mit den Situationen von Max und Andrei gut vertraut. Ich selbst habe mich kürzlich von einem erfahrenen Backend-Ingenieur zu einem unerfahrenen Teamleiter entwickelt. Und genau wie ich befürchtet hatte, dass ich die Aufgaben nicht bewältigen könnte, würde ich die Erwartungen nicht erfüllen und im Allgemeinen gehörte die Teamführung nicht mir.

Installation auf Wachstum und Installation auf einem bestimmten

Als ich Teamleiter wurde, wurde mir empfohlen, das Buch „ Flexibles Bewusstsein “ von Carol Dweck, Professorin an der Stanford University, zu lesen . Kurz gesagt, es werden zwei Arten des Denkens beschrieben:

Feste Denkweise - der Glaube, dass Intelligenz und Fähigkeiten ein für alle Mal festgelegt sind, ist unmöglich zu beeinflussen, und Misserfolg weist auf einen Mangel an Talent hin. Menschen mit einem solchen Denken versuchen, keine komplexen Aufgaben zu übernehmen, um nicht die Motivation und das Vertrauen in sich selbst zu verlieren.
Wachstumssinn ist die Überzeugung, dass Intelligenz und Fähigkeiten im Laufe des Lebens verbessert werden können, wenn Anstrengungen unternommen werden, um dies zu tun. Das Scheitern ist ein Grund, etwas zu lernen, daher versuchen Menschen mit dieser Art des Denkens ständig, aus ihrer Komfortzone herauszukommen und komplexe Aufgaben zu übernehmen.

Natürlich ist die Welt nicht in Schwarz und Weiß unterteilt, in verschiedenen Situationen kann dieselbe Person von einer anderen Art des Denkens dominiert werden. Zum Beispiel kann eine Person denken, dass Programmieren eine Fähigkeit ist, die jede Person lernen kann, aber gleichzeitig glaubt sie, dass köstliches Kochen ein Talent ist, das der Natur innewohnt, und dies kann nicht gelernt werden.

Das gesamte Programm befindet sich auf der Carol Duque-Website.

Dieser Ansatz beschreibt die Einstellung einer Person zu den Veränderungen, die stattfinden.

Menschen mit einer vorherrschenden festen Denkweise (Einstellung als selbstverständlich)
: « , ».
, . , , .

Growth mindset ( )

, , .
, .
, .

Dieser Ansatz hat mir geholfen, meine Einstellung zu Fehlern zu ändern. Aus diesem Grund habe ich mich entschlossen, über die Herangehensweise an das Team zu sprechen, da dies uns ein einziges Koordinatensystem geben, uns lehren könnte, Änderungen anders zu behandeln und die Angst vor Fehlern zu verringern. Wie bei jedem Tool funktioniert die Wachstumsorientierung zur Lösung spezifischer Probleme. Deshalb habe ich in 1: 1-Meetings darüber gesprochen, um allen die Informationen zu geben, die ihm speziell zur Lösung seiner Situation nützlich wären.

Außerdem erzählte ich allen im Team von meinem eigenen Beispiel für die Arbeit mit Einstellungen zum Zeitpunkt des Rollenwechsels vom Ingenieur zum Teamleiter. Dies trug zum Rest des Selbstbewusstseins bei ("Ich war nicht der einzige, dem dies begegnet ist", "diese Situation kann wirklich geändert werden").

Fortsetzung der Geschichte Nummer 2

Ein Experiment reduziert Erwartungen und Stress. Nachdem wir den Ansatz mit Growth & Fixed Mindset besprochen hatten, vereinbarten wir mit Max, ein Experiment zu starten, in dem er eine neue Rolle als Scrum Master ausprobieren wird. Das Wort "Experiment" reduziert den Stress gut. Im Experiment ist es nicht beängstigend, Fehler zu machen, aber es ist wichtig, an den Fehlern zu arbeiten und eine nützliche Erfahrung zu machen. In gleicher Weise sprachen wir mit dem Team über die neue Rolle von Max, was die Erwartungen des Teams senkte.

Talent ist Erfahrung.Als Andrei über seine Weigerung sprach, zu testen, ließ er den Satz fallen: "Ich bin talentiert im Programmieren." Es stellte sich heraus, dass Andrei das Programmieren und Testen als angeborene Talente betrachtete. Er hatte den ersten, aber nicht den zweiten. Wir begannen, Andrei's Erfahrung zu diskutieren und stellten fest, dass Andrei durch schlaflose Nächte auf der Suche nach Fehlern programmierte, Tage des Eintauchens in die Projekte anderer Leute, Zehntausende von Codezeilen selbst schrieb. Es stellt sich heraus, dass seine Programmierkenntnisse kein Talent sind, sondern eine Erfahrung, zu der er lange und zielgerichtet gegangen ist. Wenn wir etwas lernen, vergessen wir oft die ersten Schritte in diese Richtung.

Persönliche OKRs.Um unsere Fortschritte auch mit einem geringen Fortschritt sichtbar zu machen, haben wir uns mit dem Team darauf geeinigt, den Fortschritt jedes Trainings zu verfolgen. Dies hilft nicht nur, den zurückgelegten Weg zu sehen, sondern auch zu verstehen, wie viel mehr Sie benötigen, um zum beabsichtigten Ziel zu gelangen.

Auf Unternehmensebene haben wir OKRs, daher haben wir beschlossen, diese für das Niveau des persönlichen Trainings anzuwenden. Die Bedingungen waren wie folgt:

Wir fügen persönlichen OKRs nur das hinzu, was bei der aktuellen Arbeit hilft.
Die wichtigsten Ergebnisse sollten jederzeit messbar sein und helfen, die Frage zu beantworten: „Wie weit bin ich im Vergleich zur letzten Woche vorangekommen?
Jedes Schlüsselergebnis enthält eine Liste von Initiativen, mit denen es erreicht werden kann.
(, ), , ;
OKRs 1:1.

Implementierung persönlicher OKRs für das Quartal
Einige Wochen nach dem Start der Initiative stellten wir fest, dass nichts passierte. Es stellte sich heraus, dass wir auf unserem eigenen Rechen standen - unsere eigenen Erwartungen überbewertet. Das Team war besorgt, dass es notwendig war, lange Zeit ideale OKRs zu erstellen, und das war eine Betäubung.

Dann waren wir uns einig, dass wir dies als eine der Iterationen betrachten würden. OKRs können immer überprüft und verfeinert werden. Dies ist nicht in Stein gemeißelt, sondern nur die Richtung, die Sie entwickeln möchten. Dies half, die Initiative als interessantes Spiel wahrzunehmen, und die Dinge gingen.

Als Beispiel für OKRs von Andrey

Bonus haben wir vereinbart, persönliche OKRs innerhalb des Teams zu teilen. Es hilft, voneinander zu lernen und funktioniert wie ein öffentliches Engagement.

Fortsetzung der Geschichte Nummer 1

Dank einer veränderten Einstellung begannen wir im Nachhinein, nach den Ursachen für Schwierigkeiten in uns selbst und nicht außerhalb zu suchen. Jetzt gab es keine Ausreden, die früher hätten klingen können: "Also ist der Prozess aufgebaut, was kann ich tun." Wir begannen, Prozesse zu verfeinern, die nicht zu uns passten. Das Team bekam ein Gefühl der Eigenverantwortung für die laufenden Prozesse.

Dies ermöglichte es uns, eine kleine Anzahl von Aufgaben stabil umzusetzen. Es war zwar halb so viel wie zuvor, aber wir haben es völlig unabhängig und ohne Fehler zum Verkauf gebracht.

All dies trug zu unserem Selbstvertrauen bei. Nach einiger Zeit automatisierte Andrey unabhängig komplexe Testfälle. Roma, der für die Veröffentlichungen verantwortlich ist, hat den Prozess so optimiert, dass jedes Teammitglied nun unabhängig freigeben kann.

Basierend auf den Ergebnissen des Quartals konnten wir die Vorlaufzeit aufgrund der Verringerung der Abhängigkeiten, der Erhöhung der Kompetenzen im Team und der Änderung der Einstellung zu Schwierigkeiten und Fehlern um das Zweifache reduzieren.

Unsere Produktivität wird nicht nur von den Kenntnissen und Fähigkeiten beeinflusst, die wir jetzt besitzen, sondern auch davon, wie wir mit Veränderungen im Unternehmen umgehen. Manchmal können neue Prozesse demotiviert werden, und zu komplexe Aufgaben können das Selbstvertrauen untergraben. Aber damit können Sie sowohl für sich selbst als auch auf der Ebene des gesamten Teams arbeiten.

Meinem Team wurde geholfen, mit den Veränderungen und der Einstellung zu Fehlern in der Denkweise von Growth & Fixed umzugehen. Wir behandeln es als ein Arbeitsinstrument, das bestimmte Probleme löst. Natürlich hat sich die Installation in wenigen Wochen und Monaten nicht geändert. Durch die Änderung der Einstellung zu bestimmten Situationen konnten wir uns im Quartal in Bezug auf die täglichen Arbeitsaufgaben und -schwierigkeiten deutlich weiterentwickeln.

"Was tun, wenn dramatische Änderungen in den Prozessen ein Team demotivieren?" Die Erfahrung des Backend-Ingenieurs, der Teamleiter wurde