Citymobil - ein Leitfaden für Startups zur Erhöhung der Stabilität bei Wachstum. Teil 1

Mit diesem Artikel eröffne ich einen kurzen Zyklus von zwei Artikeln, in denen ich detailliert beschreiben werde, wie wir es geschafft haben, die Stabilität von Citymobil-Diensten über mehrere Monate hinweg mehrmals zu erhöhen. Der Artikel beginnt mit einer Geschichte über unser Geschäft, über eine Aufgabe, über den Grund für das Auftreten der Aufgabe, die Stabilität zu erhöhen, und über Einschränkungen. Citymobil ist ein schnell wachsender Taxi-Aggregator. Im Jahr 2018 stieg die Zahl der erfolgreich abgeschlossenen Reisen um mehr als das 15-fache. In einigen Monaten lag das Wachstum im Vergleich zum Vormonat über 50%.

Das Geschäft wuchs sprunghaft (und wächst immer noch): Die Auslastung der Server, die Größe des Teams und die Häufigkeit von Rollouts haben zugenommen. Gleichzeitig traten neue Bedrohungen für die Stabilität des Dienstes auf. Das Unternehmen stand vor der wichtigsten Aufgabe - das Geschäftswachstum nicht zu stoppen, um die Stabilität zu erhöhen. In diesem Artikel werde ich Ihnen erzählen, wie wir es geschafft haben, diese Aufgabe in kurzer Zeit zu realisieren.

1. Erklärung des Problems: Was genau wollen wir verbessern?

Bevor Sie etwas verbessern, müssen Sie lernen, wie man es misst, um klar zu verstehen, ob es eine Verbesserung gibt. Je näher der gemessene Wert an geschäftsfreundlichen Bedingungen liegt, desto besser. Denn je wahrscheinlicher es ist, dass wir verbessern, was das Unternehmen wirklich braucht. Aus Sicht des Erfolgs ist der wichtigste Parameter für uns die Anzahl der erfolgreich abgeschlossenen Fahrten (im Folgenden kurz - die Anzahl der Fahrten). Genau anhand dieses Parameters bewerten uns Anleger, wenn sie eine Investitionsentscheidung treffen. Je mehr Reisen, desto teurer ist das Unternehmen.

Einige Reisen machen Gewinn, andere Gewinn. Aber alle Reisen sind für uns gleich wichtig, auch unrentabel, weil sie es uns ermöglichen, den Marktanteil zu erhöhen (tatsächlich ist der Verlust von Reisen eine Gebühr für die Erhöhung des Marktanteils). Daher ist jede weitere empfangene Reise gut und jede verlorene Reise schlecht. Alle Reisen sind in Bezug auf den Geschäftserfolg gleich.

Von hier aus haben wir ein verständliches Kriterium für die Messung der Stabilität erhalten: Die Anzahl der verlorenen Fahrten sind Fahrten, die wir aufgrund technischer Probleme eindeutig verloren haben. Ein technisches Problem bedeutet beispielsweise einen Fehler im Code, einen 500. Fehler, einen Absturz der Infrastruktur, eine fehlerhafte Integration in einen Partnerdienst (z. B. Google Maps).

2. Wie zählt man verlorene Reisen?

Verlorene Reisen sind manchmal leicht zu berechnen, manchmal schwierig. Zum Beispiel ist es im Fall einer vollständigen Dienstverweigerung sehr einfach, verlorene Fahrten zu berechnen, wenn überhaupt nichts funktioniert (pah-pah-pah). Wir kennen das Trenddiagramm der Anzahl der Fahrten vor dem Herbst. Wir sehen den Trend dieses Diagramms nach dem Herbst. Wir vervollständigen die Linie zwischen dem Punkt, an dem es einfach begann, und dem Punkt, an dem es endete. Der Bereich des Diagramms der Anzahl der Fahrten unter dieser abgeschlossenen Linie ist verlorene Fahrten.

In der folgenden Grafik zeigt die schwarze Linie Fahrten an einem bestimmten Tag und die grüne Linie Fahrten vor einer Woche. Die X-Achse ist die Zeit. Auf der Y-Achse die Anzahl der Fahrten in einem bestimmten Zeitintervall um den Punkt X. Ein klarer Peak ist in Form eines spitzwinkligen Dreiecks zu sehen. Die Fläche dieses Dreiecks ist die Anzahl der verlorenen Fahrten. Dies ist natürlich eine ungefähre Menge, weil Die Grafik schwankt, aber wir verstehen, dass eine Genauigkeit von 10 bis 20% ausreicht, um das Ausmaß des Unfalls für ein Unternehmen abzuschätzen.



Wenn einfach nicht vollständig, sondern teilweise ist (auch pah-pah-pah), ist die Berechnung etwas komplizierter. Wenn zum Beispiel ein Fehler vorliegt, aufgrund dessen 10% der Bestellungen niemals mit dem Auto verteilt werden, wird im Reiseplan ein Fehler angezeigt und anschließend ein Rebound (nach Behebung des Fehlers). In einer ähnlichen Situation sind verlorene Fahrten der Bereich, der oben von der Trendlinie begrenzt wird. von unten - der tatsächliche Zeitplan für die Anzahl der Fahrten, links - die vertikale Linie des Beginns der Ausfallzeit, rechts - die vertikale Linie des Endes der Ausfallzeit.

Die folgende Grafik zeigt, dass der Peak Down nicht so offensichtlich ist, aber das Vorhandensein von Fahrten in der Vorwoche ohne Peak Down hilft zu verstehen, dass ein Peak Down ein Verlust ist. Ein Vergleich der Fahrten für den aktuellen Tag und den gleichen Wochentag mit der Vorwoche macht außerdem deutlich, dass es sich bei der Spitze ganz rechts nicht um verlorene Fahrten handelt, sondern um einen üblichen Fehler zu dieser Tageszeit, weil es korreliert mit der Vorwoche.



Es ist normalerweise schwierig, eine Trendlinie zu erstellen, weil das Sägezahndiagramm. In diesem Fall hilft uns ein wöchentlicher Vergleich. Wenn Sie zwei Linien auf demselben Diagramm zeichnen - die letzte Woche und die aktuelle -, stellt sich heraus, dass beide Plus- oder Minuskurven eine ähnliche Form haben, sich jedoch nur darin unterscheiden, dass eine über der anderen liegt (die übliche aktuelle Woche ist höher als die vorherige, obwohl dies der Fall ist Ausnahmen). Der wöchentliche Vergleich ist wichtig, da jeder Wochentag aufgrund unterschiedlicher Umstände eine andere Zeitplanform hat. Wenn Sie sich das wöchentliche Diagramm ansehen, können Sie verstehen, wo die Trendlinie der heutigen Reisen liegen könnte.

Offensichtlich ist eine verlorene Reise an sich ein viel größeres Problem als nur eine verlorene Reise. Ein Kunde, der auf die eine oder andere Weise abreisen möchte, wird beispielsweise einen wettbewerbsfähigen Service in Anspruch nehmen und anschließend möglicherweise nicht zu uns zurückkehren oder nur dann zurückkehren, wenn ein Wettbewerber ihn enttäuscht, was unwahrscheinlich ist, weil Wettbewerber sind sehr stark. Selbst wenn ein Konkurrent den Kunden enttäuscht, ist der Kunde keine Tatsache, dass er zurückkehren wird, da alles wie in seinem Kopf aussieht, so dass jeder einen schlechten Service hat und es keinen Sinn macht, über Konkurrenten zu springen.

Das heißt, eine verlorene Reise aufgrund technischer Probleme bedeutet in der Tat einige verlorene Reisen.

Um nicht verwirrt zu sein, nennen wir Reisen, die direkt aufgrund eines technischen Problems verloren gegangen sind , primäre verlorene Reisen und Reisen, die durch das Verlassen des Konkurrenten verloren gegangen sind , sekundäre verlorene Reisen .

Um den Gesamtschaden eines Unternehmens aus einer primären verlorenen Reise zu berechnen, müssen Sie im Idealfall wissen, wie viel die sekundäre verlorene Reise verursacht hat. Das heißt, Es ist notwendig, die Anzahl der anfänglich verlorenen Fahrten mit einem bestimmten Koeffizienten K zu multiplizieren, der auf der Grundlage der durchschnittlichen Häufigkeit der Nutzung des Dienstes und der durchschnittlichen Zeit der Rückgabe des Benutzers nach dem Verlassen des Wettbewerbers berechnet werden kann.

Unter der Annahme, dass sich der K- Koeffizient im Laufe der Zeit nicht wesentlich ändert, um den Trend des Reiseverlusts zu verstehen, reicht es aus, die primären verlorenen Reisen zu berücksichtigen und ihre Anzahl zu verringern, da das Verhältnis der primären verlorenen Reisen von Periode zu Periode das gleiche ist wie das Verhältnis der sekundären verlorenen Reisen von Periode zu Periode Zeitraum. Beispiel: Wenn wir im letzten Monat 1000 Primärfahrten verloren haben, haben wir bei Sekundärfahrten 1000 * K und insgesamt 1000 * (1+ K ) verloren. Wenn wir im laufenden Monat 500 Primärfahrten verloren haben, dann haben wir Sekundärfahrten 500 * K verloren , und insgesamt haben wir 500 * (1+ K ) verloren. In diesem Fall begannen wir, unabhängig vom Wert des Koeffizienten K, Fahrten zu verlieren, die 1000 * (1+ K ) / (500 * (1+ K )) = 2 mal weniger waren.

Selbst wenn sich der Koeffizient K mit der Zeit ändert, d.h. ist eine Funktion der Zeit K (t), dann sind wir immer noch daran interessiert, die Anzahl der primären verlorenen Fahrten zu reduzieren. Denn wenn K (t) mit der Zeit wächst, sind wir umso mehr verpflichtet, Anstrengungen zu unternehmen, um weniger Primärfahrten zu verlieren, weil Der Schaden durch den Verlust eines jeden ist immer höher. Wenn andererseits K (t) mit der Zeit abnimmt, bedeutet dies, dass die Benutzer uns aus irgendeinem Grund trotz des schlechten Service immer loyaler werden, was bedeutet, dass wir einfach ihre Erwartungen erfüllen müssen!

Insgesamt: Wir kämpfen für einen konstanten Rückgang der primären verlorenen Reisen.

3. Ok, wir betrachten die verlorenen Reisen. Was weiter?

Mit einem verständlichen Instrument zur Messung verlorener Fahrten wenden wir uns dem interessantesten Teil zu - wie geht das, um Verluste zu reduzieren? Und ohne das aktuelle Wachstum zu verlangsamen! Da uns subjektiv der Löwenanteil der technischen Probleme, die zum Verlust von Reisen führen, mit dem Backend zusammenhängt, haben wir uns entschlossen, zunächst den Backend-Entwicklungsprozess zu berücksichtigen. Mit Blick auf die Zukunft werde ich sagen, dass es so gekommen ist - das Backend ist zum Hauptschlachtfeld für verlorene Reisen geworden.

4. Wie der Prozess funktioniert

Probleme treten normalerweise aufgrund von Code-Rolling und anderen manuellen Aktionen auf. Dienste, die sich nie ändern und nie berühren, schlagen manchmal auch fehl, aber diese Ausnahme ist nur eine Bestätigungsregel.

Die lustigste Ausnahme dieser Art war meiner Erfahrung nach der folgende Service. Als ich 2006 bei RBC arbeitete (Gott, wie alt bin ich!), Gab es bei einem der Mail-Dienste von RBC ein Gateway, über das der gesamte Datenverkehr geleitet und IP-Adressen auf schwarze Liste überprüft wurden. Der Dienst funktionierte unter FreeBSD und es funktionierte ordnungsgemäß. Aber eines Tages hörte er auf zu arbeiten. Ratet mal warum? Auf dieser Maschine ist eine Festplatte zusammengebrochen (fehlerhafte Blöcke haben sich angesammelt, angesammelt und angesammelt). 3 Jahre vor der Verweigerung des Dienstes im Dienst zusammengebrochen (!). Und alles lebte mit einer verstreuten Scheibe. Und dann beschloss der "Frach", aus irgendeinem Grund, den ihr die Motive von Phryakhov nicht kannten, sich plötzlich einer zerfallenden Scheibe zuzuwenden und schließlich einzufrieren. Ich bin sicher, Linux würde das nicht tun. Dies ist jedoch ein separater Holivar.

Zusammenfassend sind die Probleme auf manuelle Eingriffe zurückzuführen. Einmal in meiner Kindheit, im Alter von 10-12 Jahren, hörte ich auf einer meiner Reisen in den Wald von meinem Vater einen Satz, an den ich mich mein ganzes Leben lang erinnerte: "Damit das Feuer nicht erlischt, musst du es einfach nicht berühren." Ich denke, viele von uns erinnern sich an die Momente, als wir Brennholz in ein bereits brennendes Feuer warfen und es aus einem unbekannten Grund ausging.

Fazit: Probleme entstehen durch manuelle Aktionen einer Person, zum Beispiel durch das Werfen von Brennholz in ein bereits gut brennendes Feuer, das Sauerstoff abschneidet und ein Feuer löscht, oder durch das Ausrollen von Code mit Fehlern in der Produktion. Um die Ursache von Problemen bei Diensten zu verstehen, müssen Sie daher genau wissen, wie der Roll-out erfolgt und wie der Entwicklungsprozess funktioniert.

Der Prozess konzentrierte sich voll und ganz auf die rasche Entwicklung und war wie folgt organisiert:

• 20-30 Veröffentlichungen pro Tag;
• Entwickler rollen sich aus;
• Schnelltests in einer Testumgebung durch den Entwickler;
• minimale automatisierte / Unit-Tests, minimale Bewertungen.

Entwickler unter den schwierigsten Bedingungen, ohne abgedeckte Bereiche angesichts der Qualitätssicherung, mit einem riesigen Strom von produktiven Aufgaben und Experimenten, die für das Geschäft wichtig sind, arbeiteten so konzentriert und koordiniert wie möglich, lösten komplexe Probleme auf einfache Weise und ließen den Code nicht wachsen, gut verstandene Geschäftsprobleme , sehr verantwortungsbewusst gegenüber Änderungen, rollte den Leerlauf schnell zurück. Citymobil ist hier nicht einzigartig. Vor 8 Jahren gab es in Mail.ru Mail, als ich dort zur Arbeit kam, eine ähnliche Situation. Außerdem haben wir Mail.ru Cloud schnell und einfach ohne Knicks gestartet. Und schon später Prozesse geändert, um mehr Stabilität zu erreichen.

Sicherlich haben Sie das selbst bemerkt: Wenn niemand Ihren Rücken bedeckt, wenn nur Sie mit der Produktion allein sind, wenn eine große Last der Verantwortung zerquetscht - Sie wirken Wunder. Ich selbst hatte eine solche Erfahrung (noch mehr Hardcore). Es war einmal im letzten Jahrhundert (Schätzung, das Internet war bereits im letzten Jahrhundert, ich bin überrascht, wenn ich mich erinnere), ich habe als einziger Entwickler des Mail-Dienstes newmail.ru gearbeitet, ihn selbst bereitgestellt und auch die Produktion selbst getestet zu dir selbst durch if (!strcmp(username, “danikin”)) { … some new code… } :-) Daher ist diese Situation in meiner Nähe.

Ich war nicht überrascht, wenn ich wusste, dass mit einem so einfachen Ansatz „auf dem Knie“ viele Start-ups begannen, sowohl erfolgreich als auch erfolglos, aber angetrieben von derselben Leidenschaft - Fokus auf schnelles Geschäftswachstum und Markteroberung.

Warum war der Prozess speziell in Citymobil? Anfangs gab es nur wenige Entwickler. Sie arbeiteten lange Zeit im Unternehmen und hatten ein gutes Verständnis für Code und Geschäft. Rollouts fanden mehrmals am Tag statt. Fehler waren äußerst selten. Der Prozess funktionierte perfekt unter diesen Bedingungen.

5. Warum hat ein guter Prozess die Stabilität bedroht?

Mit zunehmenden Investitionen in das Projekt haben wir unsere Produktpläne aggressiver gestaltet und viele Entwickler eingestellt. Die Anzahl der Rollouts in der Produktion nahm zu, aber ihre Qualität sollte sinken, da sich die neuen Leute unter Kampfbedingungen mit dem System und der Essenz des Geschäfts befassten. Mit zunehmender Anzahl der Entwickler begann die Stabilität nicht einmal linear, sondern quadratisch zu sinken (die Anzahl der Rollouts nahm linear zu, und die Qualität des durchschnittlichen Rollouts fiel ebenfalls linear ab; "linear" * "linear" == "quadratisch").

Es war offensichtlich, dass es unmöglich war, den Prozess in dieser Form zu belassen. Es wurde einfach nicht unter neuen Bedingungen eingesperrt. Es war jedoch notwendig, dies unbeschadet der Markteinführungszeit zu ändern, dh unter Beibehaltung von 20 bis 30 Veröffentlichungen pro Tag (und mit einer Erhöhung ihrer Anzahl im Verhältnis zur Größe des Teams). In der Tat wurde in einer großen Anzahl von Veröffentlichungen der springende Punkt angesprochen. Wir sind schnell gewachsen, haben viele Experimente durchgeführt, ihre Ergebnisse schnell ausgewertet und neue Experimente durchgeführt. Wir haben schnell Produkt- und Geschäftshypothesen getestet, sie untersucht und neue Hypothesen aufgestellt, die wir erneut schnell getestet haben usw. Wir wollten diese Rate auf keinen Fall reduzieren. Darüber hinaus wollten sie es erhöhen und die Geschwindigkeit der Einstellung von Entwicklern erhöhen. Das heißt, Unsere auf das Unternehmenswachstum ausgerichteten Maßnahmen stellten eine Bedrohung für die Stabilität dar, aber wir wollten diese Maßnahmen in keiner Weise korrigieren.

6. Ok, die Aufgabe ist klar, der Prozess ist klar. Was weiter?

Mit Erfahrung in Mail.ru Mail und Mail.ru Cloud, wo Stabilität ab einem bestimmten Punkt im Vordergrund stand, wo einmal wöchentlich Rollouts durchgeführt wurden, die ausführlich in Funktionalität und Testfällen beschrieben wurden, wird alles mit Auto- und Unit-Tests abgedeckt. Der Code wird mindestens einmal überprüft, und manchmal bin ich dreimal auf eine völlig neue Situation gestoßen.

Es scheint, dass alles einfach ist: Wiederholen Sie den Vorgang in Citymobil wie in Mail oder Cloud und erhöhen Sie die Stabilität des Dienstes. Aber wie in diesem obszönen Witz gibt es Nuancen: a) Rollouts in Mail / Cloud werden einmal pro Woche und nicht 30 Mal am Tag durchgeführt, und in Citymobil wollten wir nicht die Häufigkeit von Veröffentlichungen opfern, b) in Mail / Cloud den gesamten Code Durch Auto- / Unit-Tests abgedeckt, und in Citymobil hatten wir keine Zeit und Ressourcen dafür. Alle Kräfte der Backend-Entwicklung waren dem Testen von Hypothesen und Produktverbesserungen gewidmet. Gleichzeitig gab es auch bei hohen Einstellungsgeschwindigkeiten nicht genügend Backend-Entwickler (besonderer Dank an HR Citymobil - dies sind die besten HR-Mitarbeiter der Welt! Ich denke, es wird einen separaten Artikel über unseren HR-Prozess geben), das heißt, es gab keine Möglichkeit, sich auf strenge Tests und Überprüfungen einzulassen ohne langsamer zu werden.

7. Wenn Sie nicht wissen, was Sie tun sollen, lernen Sie aus Fehlern

Was haben wir also magisch in Citymobil gemacht? Wir haben uns entschlossen, aus Fehlern zu lernen. Die Methode zur Verbesserung des Service durch Lernen aus Fehlern ist so alt wie die Welt. Wenn das System gut funktioniert, ist es gut. Wenn das System mit Fehlern arbeitet, ist dies auch gut, da Sie aus diesen Fehlern lernen können. Das klingt einfach. Zu tun ... ist auch einfach. Die Hauptsache ist, ein Ziel zu setzen.

Wie haben wir studiert? Wir begannen damit, Informationen über jeden größeren und kleineren Unfall gewissenhaft aufzuzeichnen. Ehrlich gesagt wollte ich das zunächst nicht wirklich tun, weil ich auf ein Wunder hoffte und dachte, dass die Unfälle von selbst aufhören würden. Natürlich hörte nichts auf. Neue Realitäten forderten rücksichtslos Veränderungen.

Wir haben begonnen, alle Unfälle in einer gemeinsamen Google-Tabelle zu protokollieren. Für jeden Unfall wurden folgende Kurzinformationen bereitgestellt:

• Datum, Uhrzeit, Dauer;
• Grundursache
• was sie getan haben, um das Problem zu lösen;
• Auswirkungen auf das Geschäft (Anzahl der verlorenen Reisen, andere Auswirkungen);
• Schlussfolgerungen.

Für schwere Unfälle haben wir separate große Dateien mit detaillierten minutengenauen Beschreibungen vom Beginn des Unfalls bis zum Zeitpunkt der Fertigstellung erstellt: Was wir getan haben, welche Entscheidungen wir getroffen haben (normalerweise werden solche Beschreibungen als Post-Mortem-Analyse bezeichnet). Und in der allgemeinen Tabelle haben wir Links zu solchen Obduktionen hinzugefügt.

Der Zweck dieser Datei war einer: Schlussfolgerungen zu ziehen, deren Umsetzung die Reiseverluste verringern wird. Darüber hinaus war es sehr wichtig, die „Grundursache“ und die „Schlussfolgerungen“ genau zu formulieren. Diese Worte sind an sich verständlich. Aber jeder versteht auf seine Weise.

8. Ein Beispiel für einen Fehler, bei dem sie gelernt haben

Die Hauptursache ist die Beseitigung, die ähnliche Unfälle in Zukunft verhindern wird. Und die Schlussfolgerungen sind, wie die Grundursache beseitigt werden kann (oder die Wahrscheinlichkeit ihres Auftretens verringert werden kann).

Die Grundursache ist immer tiefer als es scheint. Schlussfolgerungen sind immer komplizierter als sie scheinen. Um sich nicht zu beruhigen und nicht bei dem zu verweilen, was zu sein scheint, muss man immer mit der angeblich gefundenen Grundursache unzufrieden sein und immer mit den angeblichen Schlussfolgerungen unzufrieden sein. Diese Unzufriedenheit schafft Eifer für weitere Analysen.

Lassen Sie mich ein Beispiel geben: Den Code ausgerollt - alles fiel, rollte zurück - alles funktionierte. Was ist die Grundursache? Roll out , sagst du. Wenn sie nicht wäre, würde es keinen Unfall geben. Was ist die Schlussfolgerung: Nicht ausrollen? Schlechte Schlussfolgerung (schädlich für das Geschäft, um genau zu sein). Das heißt, dies ist höchstwahrscheinlich nicht die Grundursache, Sie müssen tiefer graben. Roll out mit einem Bug . Die Grundursache? Sagen wir mal. Wie kann ich das beheben? Durch Tests sagst du. Welche Tests? Zum Beispiel eine vollständige Regression aller Funktionen. Dies ist eine gute Schlussfolgerung, denken Sie daran. Aber die Stabilität muss hier und jetzt verbessert werden, während es keine vollständige Regression gibt. Müssen noch tiefer graben. Rollout mit einem Fehler, der aufgrund der Tatsache aufgetreten ist, dass wir das Drucken in einer Tabelle in der Datenbank debuggt, sie über alle Maßen geladen haben und die Datenbank unter Last kaputt gegangen ist . Das ist schon interessanter. Es wird sofort klar, dass selbst ein vollständiger Regressionstest Sie nicht vor diesem Problem bewahren wird. Schließlich hat die Testbasis nicht die gleiche Last wie die Produktion.

Was ist die Hauptursache für dieses Problem, wenn Sie noch tiefer graben? Um dies herauszufinden, haben wir mit dem Entwickler gesprochen. Es stellte sich heraus, dass er daran gewöhnt war, dass die Basis mit den Lasten fertig wird. Aber unter den Bedingungen des schnellen Wachstums des Projekts wurde die Basis gestern verwaltet, aber heute ist sie nicht mehr da. Nur wenige von uns haben an Projekten gearbeitet, die von Monat zu Monat um 50% wachsen. Zum Beispiel ist dies für mich das erste derartige Projekt. Nachdem Sie sich in ein solches Projekt gestürzt haben, werden Sie sich neuer Realitäten bewusst. Bis Sie zum ersten Mal auf etwas stoßen, werden Sie nie wissen, was passiert.

Der Entwickler schlug sofort die richtige Lösung für die Ursache des Sturzes vor: Debuggen Sie das Drucken in einer Datei, schreiben Sie die Datei offline per Cron in die Datenbank in einem Stream mit Slips. Wenn zu viel Debug gedruckt wird, legt sich die Datenbank nicht hin, sondern nur die Debug-Informationen werden außerhalb der Zeit angezeigt. Offensichtlich hat dieser Entwickler bereits aus seinem Fehler gelernt und wird ihn in Zukunft nicht wiederholen. Aber auch andere Entwickler müssen sich darüber informieren. Wie? Ich muss es ihnen sagen. Wie kann man es hören lassen? Erzählen Sie ihnen die ganze Geschichte von Anfang bis Ende, erklären Sie, wozu sie geführt hat, und schlagen Sie sofort vor, wie es geht, hören Sie sich ihre Fragen an und beantworten Sie sie.

9. Was können Sie noch aus diesem Fehler lernen oder was Sie tun und was nicht?

Also analysieren wir diesen Unfall weiter. Das Unternehmen wächst rasant, neue Mitarbeiter kommen. Wie werden sie aus diesem Fehler lernen? Sagen Sie es jedem neuen Mitarbeiter? Offensichtlich wird es immer mehr Fehler geben - wie kann jeder daraus lernen? Die Antwort liegt auf der Hand: Holen Sie sich eine Do's & Don'ts-Datei (lesen Sie als "Doos and Donts")! In einer freien Übersetzung ins Russische bedeutet die Redewendung "was gut und was schlecht ist". In dieser Datei schreiben wir alle Schlussfolgerungen zum Thema Entwicklung. Wir zeigen die Datei allen neuen Mitarbeitern und zeigen sie jedes Mal, wenn die Datei aktualisiert wird, im allgemeinen Chat der Entwickler. Wir bitten alle, sie erneut zu lesen (um sowohl das alte als auch das neue Wissen aufzufrischen).

Sie werden sagen, dass nicht jeder sorgfältig lesen wird. Sie werden sagen, dass viele nach dem Lesen sofort vergessen werden. Und Sie werden beide Male Recht haben. Aber Sie werden nicht leugnen, dass jemand etwas im Kopf hat. Und das ist schon gut. Nach den Erfahrungen von Citymobil nehmen die Entwickler diese Datei sehr ernst, und Fälle, in denen einige Lektionen vergessen wurden, waren äußerst selten. Übrigens kann die Tatsache, dass die Lektion vergessen wurde, als Problem angesehen werden, und daraus kann eine Schlussfolgerung gezogen werden, dh die Details zu verstehen und zu verstehen, wie der Prozess für die Zukunft geändert werden kann. Sehr oft führt ein solches Graben zu einer genaueren und klareren Formulierung von Do's & Don'ts.

Schlussfolgerung aus dem oben beschriebenen Unfall: Erstellen Sie eine Do's & Don'ts-Datei, schreiben Sie das Gelernte hinein, zeigen Sie die Datei dem gesamten Team und bitten Sie alle Neulinge, sie zu studieren.

Aus den allgemeinen Ratschlägen, die wir bei der Analyse von Unfällen verstanden haben: Verwenden Sie nicht den Ausdruck „menschlicher Faktor“. Sobald Sie dies sagen, verstehen sie es alle sofort, so dass nichts getan werden muss, Schlussfolgerungen nicht benötigt werden, Menschen sich geirrt haben, sich geirrt haben und sich irren werden. Anstatt diesen Satz auszusprechen, ist es daher notwendig, eine spezifische Schlussfolgerung zu ziehen. Fazit - Dies ist zumindest ein kleiner, aber kleiner Schritt zur Änderung des Prozesses, zur Verbesserung der Überwachung und zur Verbesserung der automatischen Werkzeuge. Aus so kleinen Schritten wird der Stoff des stabilen Service genäht!

10. Anstelle eines Nachworts

Im zweiten Teil werde ich Ihnen die Arten von Unfällen nach den Erfahrungen von Citymobil erläutern und die Details der einzelnen Arten von Unfällen erläutern. Außerdem werde ich Ihnen erläutern, welche Schlussfolgerungen wir aus den Unfällen gezogen haben und wie wir den Prozess geändert haben, der die Automatisierung eingeführt hat. Das interessanteste im zweiten Teil! Bleib dran!