Hallo allerseits! Ich heiße Alexander Afenov. Ich bin der Teamleiter des Lamoda Order Processing-Teams. Letztes Jahr habe ich auf der TeamLead Conf 2018 gesprochen. Die Aufzeichnung der Aufführung finden Sie hier .

In meinem Bericht werde ich die Geschichte erzählen, wie ich Teamleiter geworden bin, auf welche Probleme ich gestoßen bin, und ich werde verschiedene Strategien vorstellen, die Ihnen individuell bekannt vorkommen. Ich konzentriere mich jedoch darauf, welche Art von Gewinn sie in dem Komplex erzielen.



Der Bericht wird in drei Teile unterteilt:

1. Im ersten Teil werden wir ein wenig über das Unternehmen und die Funktionen unserer IT sprechen. Dies ist notwendig, um den Kontext zu verstehen, in dem alles passiert.
2. Im zweiten werde ich über meinen Weg in der Firma sprechen.
3. Im dritten - über die verwendeten Methoden, ihre Vor- und Nachteile.

Lamoda als IT-Unternehmen

Lamoda ist vor allem in Russland und der GUS als bedeutender Einzelhändler für modische Kleidung, Schuhe und Accessoires bekannt. Nur wenige Menschen wissen jedoch, dass wir für einen bestimmten Prozentsatz oder einen festen Betrag Dienstleistungen für verschiedene Unternehmen / juristische Personen erbringen.

Lassen Sie mich Ihnen ein gutes Beispiel geben. Angenommen, Sie haben einen Keller zum Nähen von Geldbörsen. Sie haben eine Website für Ihre Produkte erstellt und diese erfolgreich beworben. Jetzt wissen viele Leute über Sie Bescheid, aber trotzdem haben Sie Probleme mit der Lieferung, Lagerung und Kommunikation mit Kunden.

Lamoda kann diese Probleme auf folgende Weise lösen:

1. Stellen Sie die Dienste Ihres Lieferservices bereit.
   
   LM Express ist unser eigener Lieferservice, den wir seit langem selbst entwickeln und automatisieren.
2. Stellen Sie die Kommunikation mit dem Kunden bereit. Dazu haben wir ein eigenes Callcenter.
3. Bewahren Sie die Ware zu Hause auf oder verkaufen Sie sie sogar für Sie (Provision).
4. Marktplatz. Die Produkte der Partner können in unserer mobilen Anwendung auf der Website oder in ihrer mobilen Version angezeigt werden, den Rest erledigen die Partner selbst.

Es stellt sich die Frage: „Wie schaffen Sie es, Ihre Probleme zu lösen und die Bedürfnisse der Partner zu befriedigen?“ Wir haben ein sich veränderndes und entwickelndes Geschäft mit unseren eigenen Bedürfnissen. Wir verbessern, entwickeln und bewegen uns irgendwie vorwärts. Gleichzeitig müssen Sie immer noch die Wunschliste abgleichen, die von außen kommt. Es scheint, dass dies eine eigene IT erfordert und keine kleine.

Wir sprechen auf allen Konferenzen seit 2016 über die Eigenentwicklung. Wir automatisieren alle Prozesse selbst. Dies sind ungefähr hundert verschiedene Dienstleistungen: von der Bearbeitung von Bestellungen und Zahlungen bis zur Arbeit mit Adressobjekten und Geschenkgutscheinen. Unterstützung für all dies bietet ein Team von ca. 300 Mitarbeitern.

Warum spreche ich über unsere IT und ihren Umfang? Weil 300 Leute viele Teams sind. Wenn einige Teams an einem einzigen technologischen Stack arbeiten, versuchen wir, all diese Entwicklungen wiederzuverwenden. Dies können Bundles, Bibliotheken und Praktiken im technischen Bereich sein. Wir versuchen aber auch, erfolgreiche Prozesspraktiken zwischen Teamleitern zu fummeln, und ich werde später darüber sprechen.

Schlüsselthemen

Ich bin seit 2015 im Unternehmen. Drei Tage nach meiner Anstellung war eine Neujahrsparty geplant, zu der ich nicht gehen wollte. Meine Priorität war es, für eine Probezeit zu bleiben und über meine Aufgaben nachzudenken.

Die Firmenveranstaltung in Lamoda ist ein Themenurlaub, auf den sich jeder gerne vorbereitet. Deshalb kam der Architekt meiner Abteilung am Tag X in einem Frack zur Arbeit bei der Parade. Zu dieser Zeit war unser Team mit der Auftragsabwicklung beschäftigt. Es war ein Monolith auf dem alten Zend1- Framework. Was habe ich beobachtet? Die Jungs bereiteten eine Zwangsfreigabe vor und wollten etwas reparieren. Nachdem wir sichergestellt hatten, dass alles in Ordnung war, packten wir zusammen und machten Urlaub.

Und hier sitze ich. Die Veröffentlichung ging mit einem Hotfix in Produktion, und vor mir steht ein wunderschöner 50-Zoll-Fernseher mit einer Art Armaturenbrett. Auf dem Dashboard befand sich eine Grafik mit der Aufschrift „Rabbit MQ-Probleme“. Es scheint, dass etwas kaputt ist, wenn Daten darauf sind. Ich weiß jedoch nicht, wo ich suchen soll, um diese Hypothese zu testen.

Sie können sich wahrscheinlich eine Art von Protokollen ansehen. Ich bin jedoch erst am dritten Arbeitstag und weiß nicht, wo sie sind. Ich denke, ich kann einen Link zum Grafana-Board finden. Vielleicht lohnt es sich, die Quelle der Metriken durchzusehen und dort zu graben? Ja, aber es ist zu holprig. Ich möchte, dass dies irgendwie dokumentiert wird. Und wieder stellt sich die Frage: Wer sind all diese Leute, die herumsitzen? Zwei oder drei Stockwerke, auf denen die IT verteilt ist. Jeder tut etwas und ich weiß nicht, mit wem ich kommunizieren soll, wenn etwas schief gelaufen ist. Es gibt keine Pivot-Tabelle, an die klar ist, an wen ich mich wenden kann, wenn ich feststelle, dass die Version fehlerhaft ist. Oder vielleicht ist eine Person im Dienst, aber ich weiß es einfach nicht?
* (natürlich war er) *

Es gab noch andere Fragen. Die erste und lächerlichste, auf die wir wiederholt zurückkommen werden: „Wo ist die Dokumentation?“. Die Antwort ist einfach: gleichzeitig überall, überall und in den Köpfen erfahrener Mitarbeiter. Da alle zur Firmenfeier abgereist sind, ich aber nicht weiß, wo sich die Docks befinden, klang die Antwort für mich "nirgendwo". Ich hatte eine Readme-Datei, auf der ich das Projekt auf meinem Laptop ausrollte. Das war aber nicht genug. Ich wollte Antworten auf viele andere Fragen bekommen. Was sind beispielsweise die grundlegenden Verhaltensregeln für einen Entwickler?

Lassen Sie mich erklären: Ich habe beschlossen, den Zugriff auf das Kampfsystem anzufordern, um die Benutzeroberfläche aufzurufen. Es wäre sehr nützlich für mich, da meine Aufgabe für den Testzeitraum darin bestand, das Autorisierungssystem zu überarbeiten, und ich wollte Knöpfe drücken und mich am Produktionsstand anmelden. Ich warf eine Anfrage an den Sicherheitsdienst, auf die ich schnell eine kurze Antwort erhielt: "Nein, wir werden keinen Zugang gewähren." Es stellte sich heraus, dass nur echte Benutzer Zugriff auf das Kampfsystem erhalten: Lagerarbeiter, ein Callcenter und so weiter. Da ich zuvor in der Telekommunikation gearbeitet hatte, gewöhnte ich mich daran, dass ich Lese- und Schreibzugriff auf die Produktionsstätten verschiedener Mobilfunkbetreiber hatte. Und hier ist es unmöglich. Es gibt ein Protokoll.

Außerdem bin ich auf viele andere Bedingungen und Einschränkungen gestoßen, von denen mir der Teamleiter erzählt hat. In den frühen Tagen widmete er mir viele verschiedene faszinierende Momente. Es gab so viele dieser Informationen, dass nicht alles in Erinnerung bleiben und aufgeschrieben werden konnte.

Die folgenden Fragen, die mich interessieren, betreffen eine langfristige Perspektive. Wie und wo soll man zum Beispiel wachsen?

Warum ist das wichtig? Weil ich mich von Anfang an irgendwie benehmen muss. Ich kam zur Position des mittleren PHP-Entwicklers. Was soll ich als nächstes tun, um die Erwartungen zu übertreffen und in Zukunft eine höhere Note zu erhalten, zum Beispiel Senior? Und noch eine Frage: "Was wird von mir in meiner aktuellen Klasse erwartet?" Das heißt, wie viel sollte ich in Prozesse wie Codeüberprüfung, Releases, Pflicht involviert sein?

Alle Fragen, die ich jetzt aufgelistet habe, wurden von unserem Teamleiter beantwortet. Die letzten beiden, strategischeren, wurden über das Leistungsüberprüfungssystem beantwortet. Ich werde Ihnen mehr darüber erzählen.

Leistungsbeurteilung

Alle 6 Monate führt eine Person eine sogenannte Selbstprüfung durch. Er spricht über die coolen Dinge, die er in der vorgegebenen Zeit geschafft hat. Es gibt jedoch eine Falle. Dies hängt mit der Tatsache zusammen, dass Menschen diese Erfolge normalerweise bei der Selbstüberprüfung angeben, die sie subjektiv als solche betrachten. In Bezug auf das Geschäft zu denken ist ungewöhnlich, und selbst wenn das Routineprojekt es dem Unternehmen ermöglichte, eine Menge Geld zu verdienen, ist er für den Entwickler möglicherweise keine Herausforderung oder kein Interesse. Es besteht die Gefahr, dass bei einer solchen Überprüfung dieses Projekt nicht angezeigt wird.

Der nächste Schritt ist ein Peer Review. Es folgt eine Reihe von Aufträgen, bei denen Teamleiter, Abteilungsleiter, Tankstellen und gegebenenfalls der Personalleiter miteinander kommunizieren. Dann eine Nachricht über die Ergebnisse.

Was sind die möglichen Ergebnisse?

Die erste Option: Eine Person hat es geschafft, sich in sechs Monaten schlechter zu machen als vor Arbeitsbeginn. Es scheint Zeit zu sein, sich zu verabschieden. Das passiert extrem selten, aber wir werden realistisch sein - es passiert.

Eine andere Option ist eine Zwei. Etwas scheint zu fehlen. Es kann Geschwindigkeit, Vorhersehbarkeit und Ausdauer geben. Etwas muss verbessert werden.

Drei - was sie erwartet hatten, haben sie verstanden. Eine Person arbeitet in einem angemessenen Tempo und entspricht in jeder Hinsicht ihrer Note.

Vier - mehr als vereinbart. Kandidat für Beförderung / Gehalt.

Fünf - Wollwolf. Es scheint an der Zeit zu sein, zu erhöhen, Boni zu geben und so weiter.

Ich habe selbst mehrere Iterationen einer solchen Überprüfung durchlaufen. Zuvor fand es vierteljährlich statt, was nicht sehr praktisch war, da 3 Monate lang nicht immer die Möglichkeit besteht, sich zu beweisen. Jetzt erfolgt die Überprüfung alle sechs Monate.

Also bin ich zuerst als Senior Developer bei Senior aufgewachsen. Dann entschied mein Teamleiter, dass er jetzt mehr mit Technologie arbeiten möchte und wechselte in die Position eines technischen Teams (Architekten), und ich wurde ein Teamleiter.

Und was dann? Ich muss etwas tun, um es irgendwie zu meistern.

Das erste, worauf Sie stoßen, sind dieselben Fragen, über die wir zuvor gesprochen haben, nur jetzt auf einer etwas anderen Ebene. Das heißt, es ist immer noch nicht klar: Wo ist diese Dokumentation? Jetzt muss ich irgendwie mit anderen Abteilungen kommunizieren, mit anderen Leads, Architekten und jemand anderem kommunizieren und auf einer höheren Ebene denken. Aber auf dieser Ebene der Dokumentation wahrscheinlich auch nicht.

Ein weiterer Punkt sind die gleichen „Grundregeln“. Was kann ich tun?

Ich denke, ich kann die Aufgaben nachverfolgen und eine Codeüberprüfung durchführen. Vielleicht habe ich jetzt die Macht, Prozesse zu ändern, irgendwie mit Menschen zu kommunizieren.

Wie und wo soll man wachsen? Diese Frage verschwindet nicht, denn dann möchten Sie vielleicht Abteilungsleiter werden (Gruppenleiter).

Nun, die Frage - was von mir erwartet wird - erscheint mir auch ziemlich verständlich.

Und jetzt müssen Sie in der Lage sein, all diese Fragen nicht nur für sich selbst, sondern für das gesamte Team zu beantworten. In meinem Fall wurde das Team fast von Grund auf neu eingestellt. Es stellt sich heraus, dass ich für fünf oder sieben Personen alles sagen, erklären, Ziele setzen muss. Es braucht Zeit und Mühe. Solche Dinge müssen geplant und durchdacht werden. Was ist die Verantwortung des Teamleiters?

Was soll ein Team führen?

Zuallererst ist es die Arbeit mit Aufgaben : ihre Formulierung, Anpassung, Beschreibung der Person, die die Aufgabe unter der Note erhält. Zum Beispiel würde ich für einen Junior lieber eine sehr detaillierte Beschreibung machen und von ihm erwarten, dass er den richtigen Code und die richtigen Tests schreibt. Als Senior werde ich ein technisches oder geschäftliches Ziel mitteilen, und er kann selbst entscheiden, wie es erreicht werden soll. In jedem Fall braucht das alles Zeit.

Natürlich müssen Sie eine Codeüberprüfung durchführen, wenn dabei Konflikte auftreten. Überwachen Sie, was passiert, und verschieben Sie Aufgaben nach Status. Ich führe auch regelmäßig die Aufgaben eines Release Engineers aus. Sie müssen oft darüber nachdenken, wie sich unsere Bereitstellung auf alle anderen auswirkt. Der Service, den ich mache, ist die Auftragsabwicklung. Es ist mit fast allen Lamoda-Systemen verbunden und kann dementsprechend viele Geschäftsprozesse während seiner Veröffentlichung beeinflussen.

Ein weiterer Punkt ist die damit verbundene Überwachung, Warnung und Verschiebung . Wenn ein Geschäftsfeature angezeigt wurde, müssen Sie es überwachen, neue Metriken einführen, Benachrichtigungen auflegen, den Support-Service informieren usw. Dies sind alles architektonische Probleme. Ich habe derzeit keinen engagierten Architekten in meiner Abteilung. Ich führe seine Aufgaben in den Fällen aus, in denen Sie eine bestimmte Lösung im Rahmen einer bestimmten Aufgabe / eines bestimmten Projekts benötigen.

Ich muss immer noch auf die Kommunikation achten . Dies schließt persönliche Treffen ein, die ungefähr alle zwei Wochen mit jedem Entwickler stattfinden. Rückblicke, Planung, Kommunikation mit Managern und anderen Abteilungen. Trotzdem wäre es schön, nicht zu faulen.

Viele sagen, dass es nach 10 Jahren Entwicklung großartig wäre, ein Verhältnis von Management zu Entwicklung von etwa 80 zu 20 zu erreichen. Auch dies ist nicht immer erreichbar. Infolgedessen verlieren Sie unweigerlich Fachwissen und fallen aus den aktuellen Trends heraus. Es ist notwendig, weiter zu wachsen.

Es gibt mögliche Strategien, wie Sie in Bezug auf Ihre Position wachsen können. Im nächsten Abschnitt werden wir darüber sprechen, wie die Rollenrotation in einem Team zur Erhöhung des Busfaktors beiträgt.

Rollendrehung

Ich werde diejenigen, die es nicht wissen, auf den neuesten Stand bringen und Ihnen sagen, was der Busfaktor ist.

Der Busfaktor ist eine Zahl, die angibt, dass die Arbeit am Projekt unterbrochen wird, wenn eine bestimmte Anzahl von Entwicklern einen Bus anklopft. Es kann sich auf verschiedenen Ebenen manifestieren. Beispielsweise kann es ein Busfaktor für ein bestimmtes komplexes Systemelement sein.

Angenommen, wir haben einen Fall, in dem wir ein bestimmtes Berichtssystem regeln müssen. Der Entwickler hat dafür 5 Tage gebraucht. Der Fehler war kompliziert, aber behoben und alles war in Ordnung. Dann tritt im selben Modul ein weiteres Problem auf, und derselbe Entwickler befindet sich im Krankenstand. Dies bedeutet, dass die nächste Person die gleiche Zeit damit verbringen sollte, das Problem zu lösen. Sie müssen es von Grund auf neu herausfinden, da es keine Dokumentation gibt (haha).

Was weiter diskutiert wird, sind genau die Strategien zur Erhöhung des Busfaktors. Und sie werden in einem recht angenehmen Bild mit allen früheren Aufgaben des Teamleiters zusammenkommen, über die ich gesprochen habe.

Neben der Dokumentation sind echte Erfahrungen erforderlich. Das heißt, Sie benötigen ein Team, das es bereits geschafft hat, verschiedene Teile des Systems zu berühren, und jetzt bereit ist, alle Aufgaben zu erledigen. Aber wenn das Team gerade erst zusammengekommen ist, wird das alles nicht von Grund auf neu kommen. Mein Hauptziel ist es zu erklären, wie es möglich ist, verschiedene Ansätze zu kombinieren, um Probleme sowohl mit Dokumentation als auch mit Erfahrung zu lösen.

Support-Ingenieur

Jeder hat von virtuellen Entwicklern gehört. Wir werden jedoch nicht über VR-Kits und nicht über Personen an einem entfernten Standort sprechen, sondern über die Rolle eines Support-Ingenieurs.

Wer ist Supportingenieur?

Wir haben einen Mann, der einen Support-Rückstand analysiert. Er kam zur Arbeit, er hat keine einzige Aufgabe. Er eröffnete einen Rückstand für die Unterstützung im Task-Tracker (Jira) und dort Aufgaben nach Kritikalität sortiert. Er nahm das Wichtigste und beginnt zu reparieren. Nachdem alle Probleme gelöst sind, schreibt er auf, warum es kaputt gegangen ist und wie man es in Zukunft vermeiden kann. Wenn er keinen anderen Support hat (das ist lustig, weil der Support nie endet), dann schaut er sich den technischen Rückstand an, der bereits ziemlich groß ist.

Eine kleine Ablenkung: Wir sprechen von einem System von anderthalbhunderttausend Zeilen auf dem alten Zend 1- Framework. Der vorherige Teamarchitekt hat einmal gesagt, dass wir nach unserem System eine Schuld dieser Größe haben - dies ist keine technische Schuld, sondern eine technische Hypothek. Daher der Titel des Berichts.

Wenn nichts zu tun ist, kann der Support-Techniker von dort aus eine nicht priorisierte Aufgabe übernehmen. Es ist nicht schade, das Programm zu beenden und zum neu erscheinenden Support zurückzukehren. Dies passiert normalerweise. Und er tut dies nicht länger als eine Woche, weil es ein direkter Weg zur Frustration wäre. Wenn Sie während der gesamten zweiwöchigen Iteration nur mit der Rechenunterstützung beschäftigt sind, wird dies Sie stark demotivieren. Sie reparieren, reparieren, reparieren und es gibt kein Ende. Aus diesem Grund übertragen wir jede Woche die Rolle eines Support-Ingenieurs auf die nächste Person.

Ingenieur freigeben

Es gibt eine andere virtuelle Position, die zum Entladen des Teamleiters sehr praktisch ist - dies ist ein Release-Ingenieur. Er bereitet Releases für vorgeplante Fixversionen vor, sammelt Zweige, bereitet Builds vor und führt alle Tests durch. Wenn die Tests automatisch ausgeführt werden, wird einfach das Ergebnis gesteuert. Wählen Sie in seinem Verantwortungsbereich, wie schön es ist, ohne Ausfallzeiten und Spezialeffekte für Systeme zu rollen, die von uns abhängen.

Es kommt vor, dass wir vor der Bereitstellung Kommunikation mit anderen Teams benötigen, um sie vor Änderungen zu warnen. Infolgedessen rollt der Release-Ingenieur alles aus und prüft, ob etwas auseinandergeblasen ist. Wir verwenden dafür Sentry , Prometheus , Icinga , schauen uns Elastic mit Kibana an . Der Release-Ingenieur entscheidet, was zu tun ist, wenn etwas schief geht. Das heißt, es liegt in seiner Verantwortung, zu entscheiden, ob ein Hotfix benötigt wird oder ob wir alle pleite sind, Geld verlieren und einen Rollback durchführen müssen. Die Entscheidung zum Rollback wird nur als letztes Mittel getroffen, aber dies geschieht auch.

Er (Release Engineer) zeichnet die auftretenden Probleme auf. Wenn etwas riss, wäre es großartig, aus Ihren Fehlern zu lernen. Dazu gibt er das Veröffentlichungsdatum und die Fehler an, die zu dem Problem geführt haben. Auf diese Weise kann der nächste Release-Techniker häufig auftretende Probleme untersuchen und vermeiden. Ja, er macht das nicht länger als eine Woche hintereinander, weil das Sammeln einer Veröffentlichung teuer ist.

Wenn die Version groß ist, vergeht ein halber Tag leicht und es ist sehr schwierig, rechtzeitig eine Pause einzulegen, um zu Ihren Aufgaben zu wechseln. Sie haben beispielsweise eine Montage gestartet, die 20 Minuten dauert. Während der Montage können Sie rauchen oder über das Leben nachdenken. Wenn Sie jedoch zur Aufgabe zurückgekehrt sind und die Montage erfolgreich war, müssen Sie erneut wechseln. Im Allgemeinen ist dies ein ziemlich trostloser Prozess, der sich aus der normalen Entwicklung zurückzieht und nicht zulässt, dass er in den Stream gelangt. Aus diesem Grund ist der Release Engineer in der nächsten Woche eine andere Person.

Tekhlid

Eine weitere interessantere virtuelle Position ist der technische Leiter.

Ein Architekt (manchmal so genannt) tritt in den Kampf ein, wenn eine große wichtige Aufgabe vorliegt oder ein neues Projekt gestartet wird. Dies bedeutet, dass er die Verantwortung für das Design, die Entwicklung und den Start übernimmt. Er hat das Recht, mit dem Teamleiter und Teammanager zu kommunizieren, technische Entscheidungen zu treffen und die Verpflichtung zur Dokumentation zu übertragen. Wenn zu Beginn Müll auftritt, werden alle aufgetretenen Probleme und ihre Ursachen auf dieselbe Weise wie bei einem Release-Ingenieur oder Support-Ingenieur aufgezeichnet.

Schlussfolgerungen

Was bekommen wir als Ergebnis?

Die Rotation von Rollen in einem Team über einen längeren Zeitraum (mindestens sechs Monate) ermöglicht es selbst einem unerfahrenen Junior, die Fähigkeit zu erlangen, mit einer Vielzahl von Teilen des Systems und Arten von Aufgaben zu arbeiten.

Am Anfang habe ich darüber gesprochen, dass Dokumentation und echte Erfahrung bei der Lösung typischer Probleme helfen können. Nachdem Sie die beschriebenen Vorgehensweisen angewendet haben, ist es keine Tatsache, dass Sie das Dokumentationsproblem lösen, sondern dass alle Teilnehmer des Entwicklungsteams qualitativ hochwertige und vielfältige Erfahrungen sammeln. Durch eine lange Rotation der virtuellen Rollen kann eine Person als Support-Ingenieur eine Vielzahl von Teilen des Systems berühren. Als Release-Ingenieur lernt er, schnell zu implementieren, zu kommunizieren, zu beobachten und Entscheidungen zu treffen. Wenn er die Rolle eines technischen Experten hat, bereitet er sich darauf vor, größere und wichtigere Projekte unabhängig voranzutreiben.

Von diesem Moment an kann und sollte der Teamleiter seine Aufgaben an Untergebene delegieren, denn wenn Sie sich erinnern, hat der Teamleiter die Aufgabe, sich nicht selbst auszusetzen und irgendwo zu wachsen.

Dank solcher Praktiken wird es möglich, endlich jemandem einen Teil seiner Arbeit zu geben. Zum Beispiel Releases. Dies sind 4-8 Stunden pro Woche, die von Zeit zu Zeit plötzlich freigegeben werden. Jetzt können Sie sie für die Entwicklung, das Lesen von Artikeln und das Lösen anderer Probleme ausgeben. Ein großer Fehler wäre, es nicht im Kalender zu veröffentlichen und es für weniger nützliche Besprechungen auszugeben. Obwohl dies in der Regel passiert :) Jetzt kann sich der Teamleiter freuen, da er die Möglichkeit hat, weniger nervös zu sein und seinen Mitarbeitern einen Teil seiner Arbeit anzuvertrauen. Wenn ihm etwas passiert, werden die Projekte nicht aufstehen.

Infolgedessen erhöhen wir den Busfaktor der Teamführung. Das Team kann seinerseits sicher sein, dass jeder von ihnen bereit ist, ein Stück Arbeit zu übernehmen und sich darum zu kümmern, wenn mit dem Teamleiter etwas schief gelaufen ist.

Natürlich gibt es Einschränkungen. Dieser Ansatz ist nicht möglich, wenn Sie alles alleine machen (Personenabteilung).Wenn ein Paar einer Person untergeordnet ist, besteht bereits die Möglichkeit, die Uhr zu drehen und loszulassen. Drei Partner und mehr ist noch besser.

In meinem Fall gibt es 5 Entwickler, von denen drei virtuelle Rollen untereinander teilen. Die anderen beiden beschäftigen sich einfach mit der Entwicklung, neuen Funktionen. Sie sind nicht an Releases, Support usw. beteiligt.

Ein weiterer wichtiger Faktor ist die Zeit. Sie müssen so lange durchhalten, bis die Rotation der Rollen den richtigen Effekt hat und Sie ein Team bereit machen, Aufgaben auszuführen, die normalerweise in der Kompetenz des Teamleiters liegen. Das Problem ist, dass wir Zeit als eine sehr erschwingliche und aufgefüllte Ressource nutzen. Das stimmt aber überhaupt nicht. Sie können davon ausgehen, dass der Entwickler in sechs Monaten oder einem Jahr irgendwie „selbst schwingt“, die nötige Erfahrung sammelt und bereit für den Dienst und etwas anderes ist. Dies kann jedoch nicht geschehen und geschieht in der Regel nicht, wenn die Situation dem Zufall überlassen wird. Der Aufgabenfluss kann so sein, dass er keine externe Motivation hat, sich richtig zu entwickeln. Und es sind abwechselnde virtuelle Rollen, die die Chance bieten, dass Sie Ihren Teammitgliedern helfen können, sich umfassend zu entwickeln und weiter in die nächsten Klassen aufzusteigen.

Am Ende läuft alles auf ein ganz bestimmtes Zitat hinaus: „Die Aufgabe des Führers ist es, mehr Führer zu haben und nicht diejenigen, die dem Führer blind folgen . “ Ich glaube, dass Sie mit diesen Tools ein Team von Teamleitern für eine Minute aufbauen können. Auf diese Weise können Sie einen Berufs- und Karriereplan erstellen. Dies gibt dem Unternehmen, dem Team und dem Projekt die Möglichkeit, bequem zu existieren. Endlich können Sie endlich ruhig in den Urlaub fahren.