Allein auf dem Feld ist kein Krieger. Der Weg zu effektiver Teamarbeit

Ein Team ist eine Gruppe von Menschen, die gemeinsam auf ein gemeinsames Ziel hinarbeiten, Aufgaben und Verantwortung für ein bestimmtes Ergebnis unter sich verteilen. Teams werden erstellt, um Aufgaben zu lösen, die eine Person nicht ausführen kann. Ein effektives Team erreicht das Ziel in kürzester Zeit mit minimalen Kosten.

Sammeln Sie ein paar Leute und sagen Sie: "Jetzt sind Sie ein Team, wir warten auf das Ergebnis von Ihnen", es wird nicht funktionieren. Die Menschen müssen sich organisieren, ihnen ein vernünftiges Ziel geben, sie motivieren und Probleme lösen.



Gerade über diese Entschlüsselung des Berichts von Evgeny Fedoreev auf TeamLead Conf . In dem Bericht beschrieb Eugene schrittweise den Prozess der Organisation eines effektiven Entwicklungsteams bei Banki.ru: Einstellung, Kommunikation, Wissensaustausch und Entwicklung von Entwicklern und Testern innerhalb des Teams und der Abteilung.


Über den Redner : Evgeny Fedoreev ( hardj ) ist seit 15 Jahren in der Webentwicklung tätig, 6 davon als Teamleiter. Jetzt leitet er die Entwicklung neuer Projekte bei Banki.ru.

Was ist Banki.ru?

Der Kontext des Unternehmens besteht darin, zu wissen, welche Erfahrungen diskutiert werden. Banki.ru ist das größte unabhängige Finanzportal der Runet mit einem monatlichen Publikum von mehr als 8 Millionen Unique Usern.

Die IT-Abteilung beschäftigt 50-70 Mitarbeiter, aufgeteilt in 7 Entwicklungsteams. Die gesamte Entwicklung erfolgt im eigenen Haus, es gibt keine Remote-Entwickler, sodass keine geeigneten Prozesse und Metriken erforderlich sind.

Die Hauptaufgabe des Entwicklungsteams

Bei der Vorbereitung des Berichts stellte ich den Leuten eine Frage:

- Was ist der Zweck des Entwicklungsteams?
- Entwickeln.
- Was heißt das? Wenn eine Person sitzt, umgestaltet, keine Vorteile bringt, keine geschäftlichen Probleme löst - ist dies auch eine Entwicklung?
- ... Es muss effektiv entwickelt werden.

Entwicklungseffizienz

Das Konzept der Effizienz ist eine Sache für einen Manager und eine andere für einen Entwickler.

Für den Manager ist eine effektive Entwicklung vorhersehbar : Wenn das Veröffentlichungsdatum des Features oder die Frist für die Ausführung der Aufgabe bekannt ist, um einige Geschäftsereignisse durchzuführen.

Für einen Entwickler ist dies die Arbeit mit einer technischen Schuld . Dies ist eines der Probleme seit der Arbeit mit diesen. Schulden, für Refactoring, für Korrekturen und Verbesserungen werden nur sehr wenig Zeit eingeräumt.

Das nächste Leistungskriterium ist die Mindestanzahl von Fehlern. Man könnte schreiben, dass das Kriterium das völlige Fehlen von Fehlern ist, aber wir wissen, dass dies nicht geschieht. Außerdem werden Tester beleidigt, weil sie nicht benötigt werden.

Zukünftige Herausforderungen . Ich habe bewusst keine "nachdenkliche Architektur" geschrieben. Tiefer einzutauchen und Architektur im Voraus zu durchdenken, ist böse, daher sollte die Entwicklung für die Zukunft berührt werden, aber ohne Fanatismus.

Alle anderen Kriterien , die jedes Team hat.

Entwicklungsprozess

Wir haben bei Banki.ru mit dem Aufbau von Entwicklungsprozessen begonnen, nachdem das Unternehmen begonnen hatte, sich zu entwickeln und zu wachsen. Neue Partner und Projekte erschienen, und 6-9 Backend-Entwickler reichten nicht aus. Wir sind zu dem Schluss gekommen, dass wir den Entwicklungsprozess aufbauen und für eine effektive Arbeit formalisieren müssen.

Anfangs hatten wir 3 Teams mit jeweils 3 Backend-Entwicklern und einem Manager, der für Teile der Site verantwortlich war. Neben ihrer Arbeit setzten und verbanden Backend-Entwickler noch jQuery-Plugins, da sich zu diesem Zeitpunkt nur wenige Leute im Frontend befanden.



Wir haben zwei Front-End-Entwickler und zwei weitere Tester benötigt, um ohne Fehler zu leben, und dachten, dass diese Konfiguration ausreichen würde.

In einer idealen Welt sollte der Entwicklungsprozess so aussehen.

• Der Projektmanager legt die Aufgabe im Backend-Team ab und führt sie aus.
• Wenn eine Überarbeitung erforderlich ist, senden sie die Aufgabe an das Front-End-Team.
• Nach der Verfeinerung gibt das Frontend es an die Qualitätssicherung weiter.
• Keine Bugs? - In Produktion.

Wir haben vorgeschlagen, dass die Welt nicht perfekt ist und die Qualitätssicherung Aufgaben zurückgibt, da in jeder Entwicklung Fehler vorhanden sind, und zwei weitere Pfeile hinzugefügt.



Nachdem wir das Schema aktualisiert hatten, entschieden wir, dass alles cool war und begannen daran zu arbeiten - wir führten eine Sprintplanung durch und die Backend-Teams selbst nahmen die Aufgaben in den Plan auf. Sie arbeiteten 2 Monate lang und stellten fest, dass etwas nicht stimmte.

Unser Schema hat sich verändert. Aufgaben springen wie ein Ball in einem Ping-Pong: von der Qualitätssicherung nach vorne und hinten zu den Entwicklern und erreichen sogar Manager.



Pfeile nehmen viel Zeit in Anspruch - der Prozess der Bereitstellung einer Aufgabe zur Bekämpfung von Servern ist zu lang. Das passte nicht zu uns. Wir wollten die Anzahl der Pfeile minimieren, damit die Aufgaben schneller erledigt werden.

Wie kann ich die Lieferzeit verkürzen?

Das erste, was mir in den Sinn kam, war eine Frage zu stellen, warum wir Aufgaben zurückgeben . Warum verstehen Backend, Frontend und QA das Problem unterschiedlich? Warum sind die Ansichten unterschiedlich? Wir kamen zu dem Schluss, dass wir den Schuldigen im Projektmanager gefunden haben, dass er die Aufgaben nicht vollständig beschrieben hat, und forderten PM auf, die Aufgaben ausführlicher zu beschreiben, damit jeder verstehen kann, was gemeint ist.

Wir hatten drei Backend-Teams geplant. Wir haben Tester und Front-End-Entwickler in die Planung einbezogen , aber für 3 Teams gab es nur 2 Front-End-Entwickler und 2 Tester. Oft gelang es ihnen nicht, sie anzurufen, weil jemand arbeiten musste.

Wir haben die Aufgaben getrennt in Frontend und Backend unterteilt , um sie parallel zur Entwicklung einzureichen , schneller zu testen und nicht auf die gesamte Kette zu warten.

Wir haben alle Lösungen ausprobiert. Infolgedessen wurde die Zeit verkürzt, aber wir waren trotzdem nicht glücklich.

Wir überlegten, was wir als nächstes tun sollten. Es gibt viele Unternehmen und Praktiken auf dem Markt, und wir begannen zu studieren, zu beobachten, zu graben und zum Feature-Team zu gelangen.

Feature-Team

In diesem Fall verfügt das Team über alle Mitarbeiter, um die Aufgabe zu erledigen:

• Backend-Entwickler.
• Front-End-Entwickler.
• QS-Entwickler.

Es gibt auch Verbindungen zwischen ihnen, Aufgaben springen und Tischtennis spielen, aber die Verbindungen sind viel kürzer und dauern weniger Zeit. Das gesamte Team nimmt an der Planung teil, sie interessiert sich für das Ergebnis und erstellt ein einziges Bild: Was zu tun ist und wie die Aufgabe in kurzer Zeit in den Kampfmodus gebracht werden kann.

In diesem Moment wechselten wir zu Agile und Scrum: Wir luden Trainer und Trainer ein, hielten Meisterkurse im Unternehmen ab und starteten den klassischen Scrum - zweiwöchige Sprints, Bewertung, Planung und Pflege. Jetzt gehen die Aufgaben schneller in den Kampfmodus, aber es sind viele Probleme aufgetreten.

Probleme mit dem Feature-Team

Zu diesem Zeitpunkt hatten wir 6 Probleme.

• Busfaktor .
• Lange Planung . Für die Planung haben wir einen halben Tag oder mehr eingeplant: Wir haben die Aufgaben erledigt, sind zum Mittagessen gegangen und haben dann wieder sortiert. Als die Planung endete, konnte niemand arbeiten und wollte nicht - der Tag war verloren.
• Nicht geschlossene Sprints . Dies ist ein schwerwiegender Schmerz - die meisten Aufgaben in den Sprints erreichten nicht die Spalte „Fertig“.
• Die unterschiedliche Art der Aufgaben der Teams .
• Die Entstehung neuer Teams .
• Erfahrungsaustausch zwischen Teams .

Es gibt Probleme, wir werden es lösen.

Busfaktor

Anfangs bestand jedes Team aus einem Front-End-Entwickler, einem Tester und drei Back-End-Entwicklern. Wir haben zusätzliche Front-End-Entwickler eingestellt - die Rollen wurden dupliziert .

Einführung wöchentlicher Treffen in den Richtungen . Front-End-Entwickler trafen sich jede Woche separat und diskutierten neue Technologien, Problemlösungen und einigten sich auf gemeinsame Praktiken und Ansätze. Die Tester versammelten sich auch, berieten sich, entschieden, wie sie testen sollten, diskutierten über Autotests.

Front-End-Entwickler haben eine befehlsübergreifende Codeüberprüfung eingeführt , bei der ein Entwickler ein Problem in einem Team löst und es anderen Teams zur Überprüfung zur Verfügung stellt. Nach mindestens zwei Anweisungen wird die Aufgabe getestet.

Autotests wurden hinzugefügt . Es gab einen Tester im Team und es war nicht möglich, ihn zu duplizieren, da es für eine solche Menge keine Aufgaben gab. Wir haben uns auf die Hilfe eines Testers eines anderen Teams geeinigt: Er kümmert sich um die Aufgaben des benachbarten Teams und ersetzt den Mitarbeiter, der in den Urlaub fährt. Dies verlängerte die Zeit leicht, aber die Aufgaben wurden getestet.

Lange Planung

Wir haben Planungsaufgaben analysiert. Zum Zeitpunkt der Sprints arbeiteten und codierten alle, und bei der Planung fast beim ersten Öffnen von Aufgaben und beim Herausfinden, was zu tun ist, klärten die Tester die „Definition von erledigt“, um zu verstehen, wie die Aufgabe zu testen ist.

Der Prozess war zeitaufwändig. Wir haben uns entschlossen, die Aufgaben vor der Planung zu zerlegen : Wir haben den Entwicklern vorgeschlagen, die Aufgabe in ihrer Freizeit zu betrachten und Fragen zu stellen, damit sie auf die Planung vorbereitet werden können.

Wir haben die Manager eingeladen , die Aufgaben detaillierter zu beschreiben , aber nicht zu ausführlich , um nicht in eine Menge Dokumentation zu graben.

Wir haben bewusst eine zusätzliche Pflegestunde und keine Freizeit vorgesehen. Sie versammelten sich als Team, diskutierten Aufgaben und bereiteten sich auf die Planung vor.

Nicht geschlossene Sprints

Das ist ein Schmerz. Vielleicht schließt sie jemand, aber bei uns zu dieser Zeit - nein.

Wir haben beschlossen, die Sprintkapazität von 10 Arbeitstagen auf 8 zu reduzieren . Wir dachten, wir würden 8 Tage einplanen und die Tester für 2 Tage verlassen.

In Wirklichkeit stellte sich heraus, dass ein Entwickler, der weniger Aufgaben sieht, diese langsam ausführt. 20% weniger Aufgaben im Sprint gaben nichts.

Zu Beginn des Sprints machte der Tester, solange noch Zeit ist, Testfälle. Theoretisch hat der Tester zu Beginn des Sprints, während die Entwickler arbeiten, keine Aufgaben. Wir waren uns einig, dass der Tester zu diesem Zeitpunkt alle Aufgaben durchlaufen, Testfälle erstellen kann. Wenn die Aufgabe zum Testen kommt, führt er sie für die vorbereiteten Testfälle aus und verkürzt die Testzeit. Weltweit hat dies nicht geholfen, obwohl die Zeit leicht verkürzt wurde.

Das Reduzieren der Sprintkapazität und das Laden des Testers haben nicht geholfen, und wir haben uns überlegt, wie wir das Problem lösen können. In diesem Moment fiel uns ein Buch über das Ziel und verschiedene Praktiken von Maxim Dorofeev auf . Wir erkannten, dass das Schieben des "nicht schiebbaren" nicht funktionieren würde und begannen, einen Sprint aus einem Engpass heraus zu planen - aus Tests . Bei der Planung nahm der Tester eine Bewertung vor, die Sprintkapazität wurde von ihm berechnet und die Aufgabe wurde für den Tester gesprintet.

Klasse! Wir gingen zu den Managern, um diese Idee zu verkaufen:

- Wir haben uns entschieden, von Testern zu planen. Sprints werden geschlossen, es wird cool!
- Warten Sie, was werden kostenlose Entwickler in diesem Moment tun? Es wird weniger Aufgaben geben, sie werden Freizeit haben!
- Möchten Sie, dass die Sprints geschlossen werden, die Entwicklung vorhersehbar ist oder das Hauptziel der Menschen erreicht wird?
- Nein, es ist immer noch eine vorhersehbare Entwicklung. Lassen Sie uns Sprints schließen.

Nach dem Dialog begann ein Team auf neue Weise zu arbeiten. Das Schema zeigte seine Überlebensfähigkeit, wir arbeiteten daran, schlossen Sprints und die Entwickler hatten Zeit.

Es stellte sich heraus, dass Entwickler viele Dinge tun können, wenn sie frei sind.

Nämlich: mit denen zu arbeiten. Schulden . Das Team hat immer eine gemeinsame Technologie. Schulden gegenüber der Abteilung. Diese Aufgaben können übernommen und getestet werden. In der Regel diese. Schulden sind System-Refactoring. Für diese Aufgaben sind Regressionstests erforderlich, und der Teamtester sollte dies nicht immer tun. Die Testabteilung identifizierte spezielle Tester, die die Regression durchführten, einschließlich des Leiters der Testabteilung. Aufgaben für die. Die Schulden wurden anderen Mitarbeitern zum Testen gegeben und unsere Tester haben nicht gelitten.

Analysieren Sie Aufgaben aus dem Backlog und klären Sie die Anforderungen . Wenn der Entwickler keine Aufgaben hatte, schaute er sich den Rückstand an und klärte die Anforderungen. Zum Zeitpunkt der Planung sind die Aufgaben vollständig beschrieben, alle Fragen gestellt und Entscheidungen getroffen. Es bleibt die Details zu klären und das war's - der Tester bewertet und die Aufgabe ist weg.

Helfen Sie anderen Teams . In diesem Moment übten wir immer noch, anderen Teams zu helfen, in denen ich in Schwierigkeiten war, jemand im Urlaub war oder krank wurde und das Projekt in Flammen stand. Separate private Aufgaben können von anderen Teams übernommen und unterstützt werden.

Darüber hinaus gibt es immer Urlaub, Schulung, Teilnahme an Konferenzen, die auch Zeit brauchen, um sich vorzubereiten. Wenn ein Mitarbeiter die Möglichkeit hat, etwas zu studieren, Habr zu lesen, während der Arbeitszeit ein Video über die Arbeit anzusehen, steigt die Loyalität. Wir haben dieses Problem gelöst und alle haben sich wohlgefühlt.

Unterschiedliche Art der Aufgaben für Teams

Wir haben Produktteams, die etwas Neues machen. Sie haben zwei Wochen Planung, Sprints, lange Projekte und werden in 1-2 Monaten oder länger veröffentlicht.

Wir haben Marketingteams, die reaktiver arbeiten: Die Aufgabe ist erledigt, die Aufgabe ist erledigt. Nehmen wir an, die Verkaufsabteilung hat die Landung verkauft - Sie müssen sie schnell erledigen. Diese Teams arbeiteten anfangs auch an Scrum- und zweiwöchigen Sprints, aber es stellte sich heraus, dass die Aufgaben am Ende des Sprints völlig anders waren als zu Beginn. Die Unzufriedenheit des Teams, ständiger Ansturm, Sprints hören nicht auf - die Situation ist unangenehm.

Wir haben uns entschlossen, mit PM und Business zu sprechen:

- Leute, wir haben Agile, Scrum, Sprints, Prozesse - lasst uns keine neuen Aufgaben einwerfen, aber wir werden uns vorhersehbar entwickeln.
- Schauen Sie, wir verkaufen eine Landung, es muss in 3 Tagen erfolgen. Dafür werden wir eine Million bezahlt. Welche Prozesse? Geld muss auch verdient werden!

Eine Million hat uns überzeugt. Wir begannen weiter zu denken.

Wir haben beschlossen, die Sprints auf eine Woche zu reduzieren, damit wir schneller reagieren können. Es hat auch nicht funktioniert, weil es überhaupt nicht funktioniert hat, in diesem Moment für dieses Team zu planen.
Dann beschlossen wir, keine Sprints zu planen, sondern an Kanban statt an Scrum zu arbeiten : Die Aufgabe kam, ging an die Arbeit, wurde freigegeben. Es hat funktioniert. Das Team arbeitete produktiver, weil es zunächst verstand, dass es keine Planung gab, sondern nur Aufgaben, die ausgeführt werden mussten.

Um die Prozesse im Team zu verbessern und Feedback zu erhalten, haben wir alle zwei Wochen begonnen, Retrospektiven durchzuführen: Das Team versammelte sich, diskutierte, was gut lief, was nicht, welche Vor- und Nachteile und arbeitete damit.

Die Entstehung neuer Teams

In diesem Moment begannen wir zu wachsen, neue Teams erschienen: Wir bekamen Teamleiter, Entwickler, das Team wuchs und die Leute hatten sich noch nicht aneinander gewöhnt. Wir reden in dieser Zeit nicht über Planung - die Leute sehen unseren Code zum ersten Mal und es kann schlecht sein, zum Beispiel haben wir eine kleine Bitrix. Damit musste etwas getan werden.

Es war möglich, dasselbe Kanban zu verwenden, damit Entwickler Aufgaben ausführen können, aber dies ist ein Produktteam, das unterrichtet werden muss. Wir haben uns entschieden - lassen Sie sie lernen, Aufgaben zu planen und zu bewerten, aber reduzieren Sie den Sprint auf 1 Woche .

Wir werden die Zeit in 1-2 Monaten auf 2 Wochen verlängern, wenn sich das Team daran gewöhnt, in die allgemeine Produktarbeit eintritt, Prozesse etabliert und Entwickler in der Lage sind, Aufgaben normal zu bewerten.

Erfahrungsaustausch zwischen Teams

Innerhalb des Teams kommunizieren Entwickler und Tester miteinander und tauschen Erfahrungen aus. Diese Erfahrungen werden jedoch nicht aktualisiert, da das Team "in sich selbst kocht". Neue Erfahrungen können nirgendwo herkommen.

Wir begannen zu überlegen, was wir damit anfangen sollten, und führten wöchentliche Teambesprechungen ein. Der Zweck der Besprechungen besteht darin, Erfahrungen durch Teamleiter von einem Team auf ein anderes zu übertragen.

Die ersten Treffen waren wie folgt:

- Hallo, mein Name ist Eugene, wir schneiden jetzt die Nachrichten.
- Cool!

Nächstes Treffen:

- Hallo, mein Name ist immer noch Eugene, wir schneiden weiterhin die Nachrichten.
- Ok.

Es passiert nichts Außergewöhnliches.

Drittes Treffen: Hallo ... und trotzdem.

Wir haben erkannt, dass wir das Format ändern müssen. Lesen Sie Bücher über Besprechungen und
eine feste Agenda eingeführt.

Jetzt haben wir eine Wiki-Seite mit Daten für die Timlid-Meetings, auf der wir Probleme und Aufgaben zur Diskussion während der Woche skizzieren.

Die Vorteile dieser Entscheidung

• Timlids bereiten sich auf das Treffen vor, weil sie die Tagesordnung kennen und verstehen, was besprochen wird.
• Die Wiki-Seite steht allen Entwicklern zur Verfügung. Jeder Mitarbeiter kann das Diskussionsthema lernen, am Prozess teilnehmen und seine Fragen stellen. Nach dem Treffen legen wir die Entscheidung in den Kommentaren fest, die ebenfalls verfügbar sind.
• Wenn ein Problem nach 1-2 Monaten nicht gelöst wurde, können Sie im Besprechungsarchiv sehen, wie die Diskussion über das Problem entschieden wurde, und das Team oder den Teamleiter wegen eines Fehlers treten.

Das Format der Treffen gefiel uns und wir begannen, sie regelmäßig abzuhalten.

Wir haben eine befehlsübergreifende Codeüberprüfung eingeführt . Dies ist eine Art Erfahrungsaustausch, den Front-End-Entwickler und spätere Leute aus den Backends bereits praktiziert haben. Es ist nicht erforderlich, den gesamten Code einer befehlsübergreifenden Codeüberprüfung zu unterziehen. Es reichen nur wichtige Dinge aus, z. B. gemeinsam genutzte Bibliotheken oder allgemeine Codeteile. Für die Codeüberprüfung haben wir nur interessierte Teams ausgewählt, es gab keine obligatorische Genehmigung.
Es gibt Situationen, in denen ein benachbartes Team, das sich mit Banken befasst, die Funktionalität verfeinern möchte - Felder hinzufügen und wir uns mit Krediten befassen. Sie können ein anderes Team fragen, aber es hat seinen eigenen Plan und es ist nicht klar, wann es die Anfrage erfüllen wird, aber Sie können nicht warten. In dieser Situation helfen wir dem benachbarten Team, aber bei der Codeüberprüfung geben wir ein anderes.

Es kommt vor, dass Entwickler aufgefordert werden, in eine andere Richtung zu wechseln oder die Technologie zu ändern. Zum Beispiel haben wir einen Mitarbeiter, der sich seit einem Jahr mit Kreditkarten beschäftigt und darum bittet, den Bereich zu ändern, während ein anderer die Technologie von der Benutzeroberfläche auf Symfony ändern möchte. Nach Vereinbarung werden wir den Übergang von Entwicklern zwischen Teams arrangieren.

Einige Unternehmen üben freitags Meetings: Menschen treffen sich, um Erfahrungen auszutauschen, etwas zu diskutieren und zu sprechen. Wir haben auch beschlossen, Freitagsversammlungen zu organisieren - wir haben eine Seite im Wiki gestartet, auf der jeder, der sprechen möchte, das Thema seines Berichts schreibt.

Alles war cool. Bei Versammlungen sprachen die Teams darüber, was sie taten und was es Neues gab. Zum Beispiel wusste bei einem der Teams, die wir missverstanden hatten, niemand, was sie tat. Bei einem Freitagsmeeting sprach das Team über ihre Arbeit, zeigte Analysen und jeder verstand die Bedeutung ihrer Arbeit. Frontend-Entwickler sprachen über den Ablauf der Assembly, diskutierten allgemeine technische Themen, z. B. die Verwendung des Debuggers in PHPStorm und die Bereitstellung.

Und dann endeten die Entwicklungsthemen, wir wechselten zu psychologischen und die Geschichte begann zu verblassen. Wie kann man Entwickler weiter dazu anregen, etwas zu erzählen?

Und dann haben wir uns an KPI erinnert! Lassen Sie uns jedem Entwickler beibringen, am Freitag sechs Monate lang zu sprechen und in seine KPI 2-Berichte aufzunehmen. Wir fanden die Idee cool und jeder würde sich melden.

Es stellte sich heraus, dass die Entwickler nach der Einführung von KPI keine Berichte mehr erstellten. Negative Erscheinungen traten bei Pflichtleistungen auf. Die Programmierer beschlossen, die 100% ige KPI-Implementierung zu opfern, nur um keine freiwilligen Pflichtberichte zu erstellen.

Schlussfolgerungen

Während wir Probleme mit der Effizienz lösten, entwickelte sich das Unternehmen und es entstanden neue Projekte, und wir mussten uns anpassen. Das haben wir daraus verstanden.

• Passen Sie sich den Änderungen an und konzentrieren Sie sich nicht auf das, was akzeptiert wird. Sehen Sie sich die Änderungen an und wählen Sie die Best Practices für die Arbeit mit dem Team aus. Wenn Entwickler nicht an Scrum arbeiten können, arbeiten Sie an Kanban, damit alle glücklich und glücklich sind.
• Prozesse ständig überwachen und ändern . Als Teamleiter müssen Sie die Prozesse im Team steuern. Der Regisseur ist nicht mehr dazu bereit, und die Entwickler sind noch nicht dazu bereit.Sehen Sie, was passiert, verbessern Sie die Situation. Niemand außer Ihnen wird dies tun, und dann werden Sie ein Team aufbauen, das seine Funktionen effektiv ausführt.

Prinzipien eines effektiven Teams

Jedes Teammitglied ist ein unabhängiger Mitarbeiter .

Wir bringen den Menschen bei, die Aufgabe zu erledigen. Wenn eine Person beispielsweise nicht genügend Anforderungen oder Zugriffe hat, möchten wir, dass sie diese Daten selbst finden kann: Gehen Sie zu den Administratoren, zu PM, fragen Sie nach einem Benutzernamen oder Passwort.

Die Aufgabe sollte von einer Person erledigt werden - wenn Sie sie auf sich genommen haben, müssen Sie sie beenden.

, :
— . — , PM.
PM .
— , ? — PM , .

, , .

. .

, . Jira Slack, , , . Scrum-, .

, .

.

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

— ?
— !
— !
— , iMessage!

, - : , .

, : , , , 2 , .

« » .

— , , .

. , «», — , , . , , , . , , .
. , .

TeamLead Conf , 25 26 , . , , .