Vom 23. bis 24. September fand in St. Petersburg die
Saint TeamLead Conf 2019 statt. Flant nahm aktiv daran teil: Igor Tsupko (unser Direktor für das Unbekannte) hielt ein Treffen ab, bei dem die Teilnehmer verstanden, wie man geheimes Wissen innerhalb der Organisation findet und preisgibt, und Sergey Goncharuk (Projektmanager) hielt eine Präsentation „Management eines verteilten Teams in Multiprojektion. " Traditionell veröffentlichen wir eine Überprüfung des Berichts und
seines Videos (~ 37 Minuten).
"Verteiltes Team" und "Multiprojekt"
In einem verteilten Team verstehen verschiedene Unternehmen sehr unterschiedliche Dinge - zum Beispiel ein Filialnetz oder ein Büro und Remote-Mitarbeiter ... Aber in unserem Fall gibt es kein Büro im eigentlichen Sinne.
Jetzt haben wir mehr als 80 Mitarbeiter, die in mehr als 20 Städten Russlands und darüber hinaus leben. Die meisten von uns sehen sich nur 2 Tage im Jahr am „Flanta“ -Geburtstag „live“.
Den Rest der Zeit, in der wir in Moskau, Samara, Tjumen, Nischni Nowgorod oder einer anderen Stadt leben, arbeiten wir mit Vogelgezwitscher oder dem Geruch von Kaffee. Anstatt einen Platz zu mieten, investieren wir Geld in etwas wirklich Nützliches. Und da jeder remote arbeitet, haben wir keine Unterteilung in „Zweige“ oder „Kasten“.
Und vor allem - wir stellen trotz aller Grenzen die Besten ein! Das ist es, was "Verteilung" in unserem Verständnis bedeutet.
Lassen Sie uns nun mit Multi-Design umgehen, aber für den Anfang ist es wichtig, ein wenig in das Flanta-Gerät einzutauchen.
Wir sind ein Ingenieurbüro, wir haben viele Ingenieure. Das Team besteht aus fünf bis sieben Ingenieuren unter Anleitung des Teamleiters und Managers. Es gibt mehrere solcher Teams, und jedes Team hat seine eigenen Projekte.
Ein Projekt ist für uns eine Kundeninfrastruktur für ein Produkt oder ein Entwicklungsteam. Das heißt, das Projekt hat klare Grenzen, aber es gibt keine Einschränkungen für Wachstum und Entwicklung!
Jedes Projekt hat seine eigenen Bedürfnisse, die dem Team irgendwie vermittelt werden müssen.
Dies erfolgt durch den Manager. Dies sind die Grundlagen von "Multi-Design".
Nachdem wir nun ein gemeinsames Verständnis der Begriffe aus dem Titel des Berichts haben, lautet die Frage: Was ist erforderlich, um sicherzustellen, dass unter solchen Bedingungen alles nicht nur funktioniert, sondern auch gut funktioniert?
Der Teammanager ist für die Lösung dieses Problems verantwortlich. Ein „Übersetzer“ vom Kunden zum Ingenieur zu sein, ist eine seiner Schlüsselkompetenzen. Die zweite ist die Organisation einer konstruktiven Kommunikation innerhalb des Teams und mit Kunden. Und die dritte Kernkompetenz besteht darin, ein Gleichgewicht zwischen dem Arbeitsfluss und den tatsächlichen Fähigkeiten der Ingenieure zu finden:
Wir werden jede Kompetenz genauer analysieren.
1. Broadcast-Erwartungen
Sogar derselbe Kunde kann widersprüchliche Erwartungen haben. Zum Beispiel erfordert das Geschäft eines Kunden, dass die geldproduzierende Produktion stabil ist. Außerdem wurde es ständig mit neuen Funktionen aufgefüllt, die zur Umsatzsteigerung beitragen.
Nun, wenn ein Unfall passiert (das Unternehmen ist bereit für den Unfall), wird er so schnell wie möglich beseitigt. Das klingt sehr vorhersehbar, oder?
Dieser Client hat aber auch Entwickler. Und ihre Erwartungen sind, wie sich herausstellt, völlig anders! Für Entwicklerentwickler ist die Produktion wichtiger (schließlich drängt das Geschäft auch auf sie), und sie erwarten auch, dass ihre Anfragen sofort gehört und gestellt werden (normalerweise wird dies durch den Satz "Immerhin gibt es 5 Minuten Arbeit" beschrieben).
Das einzige, was sowohl Unternehmen als auch Entwickler in ihren Anforderungen vereint, ist, dass beide erwarten, dass die geplanten Aufgaben genau und pünktlich erledigt werden.
Schauen wir uns das Bild als Ganzes an ... Ja, es ist sofort voll von sich gegenseitig ausschließenden Absätzen!
- Durch das Hinzufügen neuer Funktionen werden immer neue Fehlerquellen hinzugefügt. Babah! Und die Produktion ist nach der Veröffentlichung am Freitag instabil.
- Unsere Ingenieure haben tagsüber so schnell wie möglich alles erledigt, was die Entwickler verlangten, und die geplanten Aufgaben blieben deshalb unberührt.
- Oder hier ist die Geschichte: Welchem Stabilitätsumfeld sollte mehr Aufmerksamkeit geschenkt werden? Wir haben die Entwicklung stabilisiert, indem wir dafür Ressourcen bereitgestellt haben, aber nach einem weiteren Roll-out begann die Produktion zu sinken!
- Ein häufiger Fall: Die Produktion brach zusammen und das gesamte Team reparierte sie. Gleichzeitig gibt es natürlich keine Fortschritte bei geplanten Aufgaben, und selbst Entwickler aus Indien haben bereits im Chat auf den Chat in russischer Sprache umgestellt, da sie nicht auf eine Antwort warten können.
Und wir verstehen, dass die Anforderungen selbst widersprüchlich sind, was bedeutet, dass es unmöglich ist, sie direkt zu übertragen.
2. Kommunikation
Es gibt wirklich Probleme bei der Übertragung von Erwartungen. Na vielleicht ist dann zumindest bei der Kommunikation alles einfacher?
Um miteinander und mit Kunden zu kommunizieren, verwenden wir Slack für Text und Google Meet für Besprechungen und Gelegenheiten, bei denen es leichter gesagt als geschrieben ist. Aber in einem Chat erhalten wir oft Nachrichten, die keine nützliche Bedeutung haben oder so viele Fehler enthalten, dass es schwierig ist, die Bedeutung zu erkennen!
Warum achten wir darauf? Tatsache ist, dass wir beispielsweise erst im Juli 2019 1993 Anfragen von Kunden bei Slack erhalten haben, die eine obligatorische Antwort erfordern. Und natürlich nimmt mit der Zunahme der Anzahl der Kunden ein stetiger Trend in der Zunahme der Anzahl solcher Anfragen zu. Im Juli haben wir ungefähr 165 technische Stunden für die Reaktion auf solche Anrufe aufgewendet. Aber für jeden Aufruf war es auch notwendig, etwas zu tun!
Es tut uns sehr leid, wenn die Zeit der Ingenieure verschwendet wird, die in geplante Aufgaben, Reaktionen auf andere Anrufe oder sogar zur Reparatur von Unfällen investiert werden könnte.
Das Problem mit Chatrooms ist offensichtlich, aber Videokonferenzen haben wahrscheinlich keine Probleme?
Wir haben oben gesagt, dass wir Google Meet für tägliche Team-Rallyes verwenden und den Rest der Zeit die Aufgaben erledigen, die wir bei der Rallye erledigt haben. Jeden Tag verbringen wir ungefähr eine Stunde mit Rallyes. Wir versuchen, mindestens sieben Stunden am Tag für die direkte Arbeit aufzuwenden, dh es verbleiben noch 6 Stunden, um die Aufgaben zu erledigen. Unsere Aufgaben sind jedoch sehr unterschiedlich lang.
Es stellt sich also heraus, dass wir in einer Stunde der Rallye mehrere kleine, aber wahrscheinlich wichtige Aufgaben für unsere Kunden erledigen könnten. Und wir müssen verstehen, ob Wachtreffen wirklich benötigt werden oder ob es besser ist, diesmal zu arbeiten?
Wenn Sie versuchen, die Kommunikationsprobleme zusammenzuführen, stellen wir fest, dass der Chat zu nutzlosen Unterbrechungen führt und regelmäßige Kundgebungen die Arbeitszeit „verschlingen“.
Effektive Kommunikation ist nicht eigenständig.
3. Planung
Nun, wir müssen Probleme in Bezug auf Kommunikation und Rundfunkerwartungen lösen, aber bei der Planung gibt es wahrscheinlich keine Fallstricke? Lass es uns herausfinden.
Jeden Tag werden viele neue Aufgaben erstellt. Ich möchte, dass wir Aufgaben so schnell schließen, wie sie wachsen. Aber im Leben ist ein Ideal selten erreichbar. Erstens bricht manchmal etwas in der Infrastruktur. Zweitens gibt es immer einige kleine Dinge, die sofort einfacher zu erledigen sind. Drittens gibt es Aufgaben, die wir bei einer Team-Rallye gelöst haben:
Und manchmal kommt es vor, dass es aufgrund von Unfällen und dem Ziehen an Kleinigkeiten überhaupt nicht möglich ist, zu den geplanten zu gelangen! Gleichzeitig kommen neue Aufgaben nicht auf - alle versprochenen Fristen sind gebrochen.
Unser Rezept
Aber bei all den Problemen mit der Übersetzung von Erwartungen, mit Kommunikation und Planung, der Methode, Kegel zu stopfen, haben wir es geschafft, wie es uns scheint, die richtige Antwort zu bekommen.
Einer der wichtigsten Geschäftsprozesse, die alle drei Kernkompetenzen betreffen, ist ein Teammeeting. Und wir gingen davon aus, dass wir mit zwanzig Prozent des Aufwands 80% des Ergebnisses erzielen können, wenn wir ein Teammeeting effektiv gestalten? Wir haben diese Theorie getestet.
Wie Sie sich erinnern, haben wir ein Team, das unsere Projekte betreut. Und sie hat eine bestimmte Liste von Anforderungen aus diesen Projekten. Jede Anforderung ist jedoch in der Regel nur eine in einer Kette miteinander verbundener Aufgaben. Und so in jedem Projekt! Und bevor wir eine neue Aufgabe übernehmen, müssen wir verstehen, ob wir die vorherige Phase abgeschlossen haben?
Gestern wurde Aufgabe A-1 von Egor, Aufgabe B-1 - Semyon und Aufgabe B-1 - Jeanne ausgeführt. Aber wie können wir alle Ingenieure so tief in alle Projekte eintauchen, dass es Yegor gelingt, Aufgabe B und Semyon zwei kleine Aufgaben A und B zu bewältigen? „Warum all diese Schwierigkeiten?“ - Du fragst. Ja, Tatsache ist, dass Zhanna heute im Urlaub geplante Aufgaben nicht erfüllen wird!
Unser Fokus liegt auf vielen ähnlichen Aufgaben. Im Durchschnitt erhalten wir jeden Arbeitstag etwa 25 neue Aufgaben für jedes Team. Und da es viele Aufgaben gibt, sind die Verbindungen zwischen ihnen verwirrt und es gibt kein Verständnis dafür, ob alle Aufgaben des vorherigen Tages erledigt wurden. Um all dies zu enträtseln, brauchen wir eine Team-Rallye und jeden Arbeitstag, sonst können wir diesen Fluss nicht verwalten.
Angesichts des Volumenvolumens lohnt es sich, sich im Voraus auf die Rallye vorzubereiten. Während der Schulung können wir ohne Ingenieure nicht verstehen, welche Aufgaben vollständig erledigt wurden und welche nicht. Und natürlich können wir kein Wissen von Ingenieur zu Ingenieur übertragen. Wir sind jedoch eindeutig in der Lage, die Prioritäten für die Übernahme neuer Aufgaben festzulegen.
Aufgabenpriorisierung
Worauf basieren wir bei der Priorisierung von Aufgaben? Erstens haben wir mit dem Kunden strategische Vereinbarungen über die Ziele, die erreicht werden müssen. Zweitens aktualisieren wir einmal pro Woche die taktischen Pläne für ein Online-Meeting mit dem Kunden. Die Vorbereitungsbedürfnisse des Kunden werden vom Manager bestätigt, und die technische Notwendigkeit und das Verfahren für die Erledigung der einen oder anderen Aufgabe sind die Teamleiter. Richtig, auf der Grundlage der
Parität der Meinungen des Teamleiters und Managers wird eine Liste der Aufgaben für den Tag erstellt.
Kultur der Teambesprechungen
Sobald wir die Liste der Aufgaben für den Tag festgelegt haben, um zu klären, was getan wurde, und um unsere Kollegen in die Details einzutauchen, beginnen wir eine Teambesprechung, bei der jeder Ingenieur detailliert mitteilen muss, was er gestern getan hat, und das gesamte Team sollte die vorgenommenen Änderungen hören und vor allem verstehen. Das ist aber leichter gesagt als getan.
Wir haben eine Reihe von kulturellen Merkmalen der Rallye vorgestellt, die es uns ermöglichten, das gewünschte Ergebnis zu erzielen:
Zu Beginn der Rallye, während sich alle versammeln, verbringen wir 10-15 Minuten damit, über das Leben zu sprechen. Über Neuigkeiten und Ereignisse, die nichts mit Arbeit zu tun haben, über Hobbys von Kollegen. So werden Ingenieure, die in verschiedenen Städten sind und sich fast nie sehen, Freunde oder sogar Freunde. Und
diese 10-15 Minuten pro Tag helfen dem Team, mehr Einheit zu schaffen .
Nach dem Teambuilding-Gespräch fahren wir mit dem inhaltlichen Teil fort. Gehen wir ein wenig zurück.
Erinnerst du dich an diese Illustration? Tatsache ist, dass weder Semyon noch Yegor wissen, welche Aufgaben und Projekte sie heute ausführen werden, bevor die Rallye beginnt. Aus einer Reihe von Gründen: Urlaub, Geschäftsreisen, Krankheit, Dienst usw. - Die Aufgabe kann jeden Tag den Ausführenden wechseln, bis sie vollständig gelöst ist. Und jeder Ingenieur versteht, dass ihm heute eine Aufgabe zugewiesen werden kann,
dh alle Ingenieure sind bereits anfangs
daran interessiert, sich mit den Details jeder Aufgabe zu befassen .
Bei der Rallye analysieren wir die Blockaden, die das gesamte Team verursacht hat. Wir bestehen darauf, dass das gesamte Team an der Lösung des Rednerproblems beteiligt ist. Deshalb
motivieren wir uns
, in Aufgaben einzutauchen und diese gemeinsam zu lösen .
Wenn das Team im Büro arbeitet, erfolgt die informelle Kommunikation häufig „am Kühler“. In einem verteilten Team besteht jedoch die Notwendigkeit einer solchen Kommunikation. Deshalb läuft das Gespräch während einer Diskussion über Aufgaben oft irgendwo in die falsche Richtung. Aber wir stoppen jegliche Ablenkung. Wie genau? Das schaffen wir ganz einfach: Schließlich gibt es eine speziell für abstrakte Gespräche vorgesehene Zeit, und jetzt ist es Arbeitszeit. Daher reicht schon das übliche mündliche „Lasst uns auf den Punkt kommen“ aus, damit jeder zur Geschäftsagenda zurückkehrt. Indem wir Ablenkungen beim Parsen von Aufgaben stoppen,
richten wir
das Team für die Arbeit ein .
Wir versuchen, die Berichtszeit jedes Ingenieurs zu kontrollieren. Manchmal brauchen wir eine lange und detaillierte Geschichte über die Aufgabe, um in die Details einzutauchen. In den meisten Fällen
versuchen wir
jedoch, die Rallye nicht zu verlängern .
Effektive Rallyes - eine Silberkugel?
Dank der Vorbereitung auf die Rallye auf der Grundlage der Parität der Meinungen des Teamleiters und des Managers und unserer kulturellen Merkmale der Rallye haben wir sie wirklich effektiv gemacht. Aber haben Sie es geschafft, 80% aller Kompetenzen zu schließen? Nicht wirklich.
Wir haben gute Arbeit mit den Sendeerwartungen geleistet, aber es gab immer noch Probleme mit nicht informativen Chat-Nachrichten in der Kommunikation, und es gab Planungsunterbrechungen, die uns daran hinderten, geplante Aufgaben effektiv auszuführen.
Ja, aber nicht informative Chat-Nachrichten sind auch Unterbrechungen. Und wir müssen einen Mechanismus finden, der uns hilft, Interrupts aller Art effizient zu handhaben.
Unterbrechungen bekämpfen
Wir dachten, was ist, wenn wir eine separate Person haben, die ein Team, das an geplanten Aufgaben aus dem Interrupt-Fluss arbeitet, mit uns „abdeckt“?
Die Idee ist nicht neu und im Allgemeinen gut, aber wer genau wird es tun? Wir haben zwei Möglichkeiten in Betracht gezogen: einen solchen Service zu finden und einzustellen oder vorhandene Ingenieure einzusetzen. Die Suche nach neuen Mitarbeitern erforderte Zeit und finanzielle Ressourcen, und vorhandene Ingenieure wurden bereits „im Kampf getestet“ und in alle Projekte des Teams vertieft. Daher wurde die Möglichkeit, neue Mitarbeiter einzustellen, abgelehnt.
Es bleibt zu entscheiden, wie ein solcher Service von den derzeitigen Ingenieuren organisiert werden soll. Hier war die Lösung an der Oberfläche: Sie haben einfach nach einem Zeitplan Dienst geleistet, mit einer Rotation von Ingenieuren aus dem Team. Wir behalten den Dienstplan in Google Kalender bei und richten in Slack Benachrichtigungen darüber ein, wer heute im Dienst ist.
Es scheint, dass jetzt alles in Ordnung sein sollte? Hurra? Nein, eigentlich bleibt das Problem bestehen. Denken Sie daran, etwas früher haben wir gesagt, dass wir allein in Slack fast 2.000 Treffer pro Monat erzielen, was ungefähr 16 Treffern pro Tag für jedes Team entspricht. Zusätzlich zu Slack muss die Telefonzentrale Nachrichten von Überwachungssystemen verarbeiten und an dem Tag, an dem sie:
- 112 - von Prometheus;
- 16 - vom Okmeter;
- 25 - von externen Blackbox-Überwachungssystemen;
- 14 - aus verschiedenen benutzerdefinierten Skripten;
- und sogar 2 Anrufe von Kunden.
Dies sind 198 Unterbrechungen pro Tag aus verschiedenen Quellen! Tatsächlich gibt es aber noch mehr Quellen:
- Fast jeder Kunde hat einen Prometheus;
- und Okmeter ist auf jedem Client installiert;
- Aber benutzerdefinierte Skripte, sogar ein Client kann so viele haben, wie Sie möchten ...
Damit jeder Ingenieur aus dem Team ohne Magie und Superkräfte damit umgehen kann, haben wir Warnungen von allen Interrupt-Quellen an einem Ort gesammelt. Wir haben dieses Tool Madison genannt, und jede Nachricht darin ist ein Vorfall.
Aber Madison sammelt nur Vorfälle und behält ein Vermögen darüber. Aber wir müssen verstehen, welche Art von Vorfall zuerst zu nehmen ist, dh Triage durchzuführen, eine klare Reihenfolge der Verarbeitung und Eskalation zu haben, damit er in einer stressigen Situation leicht durchgeführt werden kann.
Wir haben auch ein solches Instrument geschaffen - es heißt Polk:
Polk ist der Arbeitsplatz des diensthabenden Ingenieurs. Es ermöglicht der Telefonzentrale, sich nur auf Vorfälle zu konzentrieren, nicht durch geplante Aufgaben abgelenkt zu werden, Vorfälle aus allen Quellen an einem Ort zu empfangen, hilft bei der Bestimmung der Kritikalität eines Vorfalls anhand eines vorgegebenen Schweregrads, verfügt über eine Reihe klar definierter Status und einen Verarbeitungsalgorithmus, der die Bewegung dieser Status bestimmt.
Technische und kulturelle Merkmale des Chats
Hervorragend: Jetzt schließt der Mitarbeiter, der mit einem so leistungsstarken Tool ausgestattet ist, das Team wirklich vor Unterbrechungen. Aber selbst mit solchen Werkzeugen ist die Uhr anstrengend und nutzlose Unterbrechungen fügen dem Feuer nur Treibstoff hinzu.
Um nutzlose Chat-Unterbrechungen zu bekämpfen, können wir eine kleine Reihe technischer Tools verwenden, aber die Hauptlösung für dieses Problem liegt definitiv in der kulturellen Ebene.
Aus technischer Sicht haben wir bei Slack Informationen zu Projekten ausgetauscht und einen separaten Kanal für die Kommunikation mit Vertretern der Kunden sowie für jedes Projekt einen Kanal für Ingenieure eingerichtet, auf dem die Arbeiten besprochen werden können. Wir haben auch den
@flant Bot geschrieben. Wenn Polk darauf
@flant , wird automatisch ein Vorfall erstellt, den der Duty Officer verarbeitet.
Darüber hinaus haben wir Kunden empfohlen,
@flant und
@channel (ein Ereignis, das alle Channel-Mitglieder benachrichtigt) und
@here (ein Ereignis, das alle Channel-Mitglieder online benachrichtigt) zu verwenden, um es nur in den seltenen und außergewöhnlichen Fällen zu verwenden, in denen Sie wirklich nicht ohne sie
@here können (Zum Beispiel, wenn der
@flant Bot nicht verfügbar ist).
Am ersten Tag unserer Zusammenarbeit mit dem Kunden veröffentlichen wir detaillierte Anweisungen zur Interaktion im Kanal. Und beim ersten regulären Treffen werden wir auf jeden Fall die Interaktion diskutieren, einschließlich des Unterschieds zwischen
@channel ,
@here und
@flant .
Insbesondere konzentrieren wir uns auf die Tatsache, dass der Aufruf von
@flant für uns in erster
@flant eine Aktion mit einer obligatorischen Reaktion ist und
@channel und
@here für den größten Teil des Teams nur eine Unterbrechung ist, die ebenfalls adresslos ist und ignoriert werden kann während das gesamte Team von der Lösung geplanter Aufgaben abgelenkt wird, auch für dieses Projekt.
Aber neue Kollegen kommen von Kunden zum Chat, die den Bot nicht kennen. Andere vergessen es einfach. In diesem Fall erinnern wir uns sanft an seine Existenz.
Für die Kommunikation zwischen Ingenieuren verwenden wir dieselben Regeln für
@channelund
@here : Verwenden Sie sie nur, wenn dies unbedingt erforderlich ist. Und dennoch bestehen wir darauf, die Regel "Sag nicht nur" Hallo "im Chat - formuliere sofort einen Gedanken" einzuhalten. Diese Regel ist ein Muss für alle Anfänger. Diejenigen, die es vergessen haben, werden daran erinnert - falls erforderlich, eingesetzt.
Insgesamt: Mit der Einführung von Schichten und der Korrektur von Kommunikationsproblemen im Chat haben wir die meisten nutzlosen Unterbrechungen und den Einfluss von Unterbrechungen auf die Ausführung geplanter Aufgaben bewältigt.
Aufschub und Blockierung
Wir haben überprüft, wie sich unsere Indikatoren danach verbessert haben: Sie wurden zwar deutlich besser, aber es gab immer noch ein Problem bei der Planung.
Wenn die Teamrallye vorbei ist, ist es Zeit zu arbeiten. Aber oft neigen Ingenieure, insbesondere diejenigen, die remote arbeiten, dazu, zu zögern. Oder stoßen Sie während der Arbeit auf ein Problem und gehen Sie im Kreis, um es zu lösen.
Versuchen wir, mit Aufschub umzugehen. Wie kann man es überwinden? Es gibt zu viele Aufgaben in Redmine (unserem Task-Tracker) - Sie müssen sich auf diejenigen konzentrieren, die heute in Arbeit sind. Und selbst unter ihnen müssen Sie verstehen, welche Aufgaben zuerst zu erledigen sind, dh Prioritäten zu bestimmen. Und im Idealfall, wenn Sie ungefähr die Zeit planen, die wir für jede Aufgabe bereit sind ...
Wir haben ein Tool entwickelt, mit dem sich all dies lösen lässt, und es Ford genannt:
Darin erhält der Ingenieur eine Aufgabe für den Arbeitstag in Form von Karten, die in Prioritätsreihenfolge angeordnet sind. Für alle geplanten Aufgaben geben wir die ungefähre Zeit an, die der Ingenieur bei der Lösung einhalten muss. Der Ingenieur berücksichtigt die Zeit, die er für die Lösung des Problems aufgewendet hat. Und wenn die Zeit ungefähr gleich ist, das Problem aber nicht gelöst ist, ist dies ein Hinweis darauf, dass der Ingenieur eine Sackgasse erreicht hat.
Was kann man damit machen? Zusätzlich zu der Priorität, in der sich die Karten befinden,
Wir haben auch Prioritätskategorien eingeführt und diese mit Farben hervorgehoben:
- Das graue Feld wird für normale, geplante Aufgaben verwendet.
- Grünes Feld - für Aufgaben, die am aktuellen Tag nur gestartet werden sollen, wenn Aufgaben in allen anderen Feldern beendet sind;
- Das gelbe Feld steht für Aufgaben, die plötzlich während des Tages ungeplant aufgetreten sind.
- Rotes Feld - für Aufgaben, die vor dem Ende des aktuellen Arbeitstages gelöst werden müssen.
Wenn ein Ingenieur durch eine Aufgabe in grauen und grünen Feldern blockiert wird, muss er nur die nächste Aufgabe starten und das Schloss bei der nächsten Teambesprechung auflösen.
Es ist jedoch offensichtlich, dass Sie, wenn ein Ingenieur durch Aufgaben in den gelben oder roten Zonen blockiert ist, nicht auf das nächste Meeting warten sollten: Sie müssen das Team im entsprechenden Kanal um Hilfe bitten, damit die Ingenieure über das Projekt kommunizieren können, in dem die Aufgabe festgelegt ist. Und gemäß unserer Kultur werden Teamingenieure oder Teamleiter definitiv zur Rettung kommen.
Es ist erwähnenswert, dass Fords Fähigkeiten viel breiter sind und wir nur die „Spitze des Eisbergs“ berührt haben, die Sie mit anderen offenen Werkzeugen implementieren können.
Zusammenfassung
Es stellt sich heraus, dass wir Ford als technische Lösung und einfache Regeln in der Teamkultur verwenden, um Aufschub und Blockierung zu bekämpfen.
Haben uns diese Tools geholfen? Ja! Aber aus irgendeinem Grund nicht 100%?
Tatsache ist, dass sich die Welt verändert und vorwärts bewegt. Und wir ändern uns auch unter diesen Bedingungen und streben nach dem Ideal, aber wie Sie wissen, ist es unerreichbar.
Über das Erreichen von Idealen und die Rolle des Managers
Alle großartigen Dinge, die die Menschheit während ihres gesamten Bestehens geschaffen hat, wurden von Teams von Fachleuten getan, die coole Manager hatten.
Wir, Flant, sind auch ein Team von Fachleuten. Und es wäre cool, wenn es mehr coole Manager in unserem Team gäbe. Kommen Sie zu uns, um zu arbeiten und unsere Prozesse zu verbessern:
Videos und Folien
Video von der Aufführung (~ 38 Minuten):
Präsentation des Berichts:
PS
Lesen Sie auch in unserem Blog: