Kaizen Schmaizen - Die Kaizen-Methodik bei Aliz

Mehr Geheimnisse hinter der Anwendung mit fünf Millionen Nutzern

In unserem brandneuen Blogpost geht es um die bekannte Kaizen-Methode und was wir in unserem Unternehmen anwenden!

Als ich mich für diese Stelle bei Aliz beworben habe, wurde ich gefragt, ob ich irgendwelche Fragen hätte. Ich antwortete mit: "Also, machen Sie CI/CD?" Alle anderen Unternehmen, bei denen ich mich beworben hatte, hatten mit einem begeisterten Ja geantwortet, klar, absolut; sie hatten das beste CI/CD überhaupt.

Bei Aliz lachten meine Gesprächspartner, etwas verlegen: "Nun, wir haben ein Jenkins", antwortete Gábor. "Es funktioniert, ja, aber es hat ein paar Probleme. Er ist nicht in sehr gutem Zustand."

Ich stellte weitere Fragen, und immer lachten sie und erzählten mir, dass der Prozess oder das Tool, nach dem ich gefragt hatte, zwar vorhanden war, aber einige Probleme aufwies, die sie gerne beheben würden, aber noch nicht dazu gekommen waren.

Das war charmant. Die Ehrlichkeit, vielleicht. Die Professionalität, zuzugeben, dass die Dinge nicht perfekt waren, gefiel mir. Ich habe mit Aliz unterschrieben.

Ich bin Ungarin. Unsere traditionelle Art, mit Problemen, Schwierigkeiten und suboptimalen Prozessen umzugehen, besteht darin, dass wir uns hinsetzen, uns beschweren und nichts dagegen tun.

Fairerweise muss man sagen, dass das nicht nur in Ungarn so ist. Es ist so ziemlich eine menschliche Eigenschaft, dass wir dazu neigen, mit allem, was schlecht ist, einfach zu leben, weil das am einfachsten ist: nichts zu ändern und sich zu beschweren. Jemand hat mir einmal gesagt, dass es drei Möglichkeiten gibt, mit einer Situation umzugehen, die man hasst: Sie akzeptieren, aus ihr aussteigen oder sie ändern. Aber alles ist besser, als nur herumzusitzen und sich zu beschweren. Trotzdem ist es am einfachsten, einfach nur herumzusitzen und sich zu beschweren, nicht wahr?

Am Arbeitsplatz wirkt die Trägheit der Organisation dem Wunsch nach Veränderung entgegen. Selbst wenn wir ein Verfahren haben, das eindeutig nicht mehr funktioniert, wenden wir es weiterhin an, weil es schon immer so gemacht wurde. Und wir sitzen herum und beschweren uns. Schieben es auf das Management oder so. Und das ist Gift, Mann!

Ich habe auch geglaubt, dass es viel Mut und Entschlossenheit erfordert, die Dinge zum Besseren zu verändern. Sogar Heldentum.

Kürzlich habe ich erkannt, dass es nicht so sein muss.

Ich habe bei Aliz unterschrieben und den kranken Jenkins kennengelernt. Es hatte Probleme. Die Instanzen blieben während der Erstellung des Projekts stecken; man musste die Instanz manuell beenden und die Erstellung neu starten. Ich akzeptierte es so, wie es war. Gelegentlich beschwerte ich mich. Aber ich habe nichts dagegen unternommen. Das war schon immer so.

Dann, eines Tages, kam jemand mit dem nötigen Fachwissen dazu, es zu reparieren. Das Team freute sich natürlich, aber es gab kein großes Fest, wie ich es erwartet hätte.

Langsam aber sicher wurde mir klar, dass das Reparieren und Verbessern von Dingen zum Kern der Kultur unseres Teams gehört.

Wir praktizieren sozusagen Kaizen, nur dass es inzwischen so tief verwurzelt ist, dass wir uns dessen nicht einmal bewusst sind. Kaizen? Schlagen Sie es nach. Ich kann es dir nicht erklären; ich kann dir nur sagen, was wir tun.

• Wir lassen Zeremonien ausfallen oder ändern sie, wenn sie nicht funktionieren. Eines Tages rief mich Gábor an und fragte mich nach dem Wert einer Zeremonie, die wir durchgeführt hatten. Ich sagte ihm meine Meinung (dass sie so, wie sie war, ziemlich wertlos war), und er sagte lässig: "Das denke ich auch. Lass uns damit aufhören." Und ich meinte nur: "Moment mal, das können wir einfach so machen?" Einfach so? Es war befreiend und erheiternd.
• Wir steigen aus Prozessen aus, wenn es nötig ist. Im Allgemeinen mag es ein ziemlich guter Prozess sein, aber es kann ein Moment kommen, in dem er zur Belastung wird. Nehmen Sie die Codeüberprüfung. Es funktioniert, aber ich erinnere mich an eine Reihe von dringenden Hotfix-Problemen, bei denen einfach keine Zeit für eine Überprüfung war. Wir ließen es sein und kehrten zu einer Dreier-Mob-Programmierung zurück, die das Vier-Augen-Prinzip erfüllte, das von den Vorschriften und dem gesunden Menschenverstand gefordert wird, aber auch dazu führte, dass der Code viel schneller ausgeliefert wurde.
• Wir führen neue Prozesse bei Bedarf und in kleinen Schritten ein. Es gibt zwar eine Vision, in welche Richtung wir das Team führen möchten, aber wir ziehen es im Allgemeinen vor, in kleinen Schritten darauf hinzuarbeiten, je nach Bedarf.
• Jeder kann Änderungen vorschlagen, und Änderungen werden im Konsens angenommen. Okay, Änderungen kommen eher von den älteren Teammitgliedern, den Architekten. Ihre Argumente haben in Diskussionen oft mehr Gewicht. Aber hey, sie sind eben Architekten, weil sie die Erfahrung und die Vision haben.
• Wir ermutigen dazu, kleinere, nur tangential verwandte Probleme als Teil eines Geschäftsproblems zu beheben. Wenn wir neuen Code schreiben, bringen wir die Dateien, die wir anfassen, auf Vordermann, auch wenn es für das Kernproblem nicht nötig ist, indem wir kleine Dinge modernisieren (z. B. ein altes anonymes Objekt durch ein Lambda ersetzen), kleinere Refactorings durchführen oder Dokumentation hinzufügen. Wir fügen auch gerne neue, allgemein nützliche Test- und Hilfsmethoden hinzu. Es ist schön, wenn man das Projekt sauberer hinterlässt, als man es betreten hat, und es hilft enorm, die technischen Schulden abzutragen.
• Wir akzeptieren nicht blindlings die besten Praktiken der Industrie. Okay, das ist ein wenig umstritten. Wir lehnen die besten Praktiken der Industrie so eifrig ab, dass es mich wahnsinnig macht. Aber das liegt daran, dass wir nach Beweisen für den Wert dieser Praktiken suchen. Wir haben jedoch Teammitglieder, die sich für die besten Praktiken einsetzen und unsere schlimmsten Auswüchse eindämmen.
• Wir ermutigen zum Experimentieren, wenn wir Code schreiben, und wir akzeptieren das Scheitern beim Experimentieren. Experimente sind kostspielig, selbst wenn sie erfolgreich sind. Ihr Nutzen ist nicht sofort erkennbar und oft schwer zu messen. Ein schrittweises Vorgehen ist hilfreich, ebenso wie die Transparenz, die wir dabei walten lassen. Wenn ich mit neuen Dingen experimentiere, teile ich gerne mit, was ich tue, um ein kontinuierliches Feedback zu erhalten. Okay, vielleicht ist es kein Kaizen, nicht wirklich. Vielleicht ist es nur so, dass wir tatsächlich agil sind, im klassischen Sinne. Aber was ist schon ein Name? Wir sind bestrebt, uns ständig zu verbessern, und wir reagieren ziemlich gut auf Veränderungen. Mehr gibt es dazu nicht zu sagen.

Wie Sie sehen, findet sich diese Denkweise auf vielen Ebenen wieder: im alltäglichen Coding und auch im architektonischen und organisatorischen Denken. Und ich bin überzeugt, dass das AODocs-Projekt aufgrund dieser Denkweise so erfolgreich ist, wie es ist. Ich meine, unser Team arbeitet an AODocs, einem riesigen System mit einer zehn Jahre alten Codebasis, aber diese Codebasis sieht nicht aus wie vor zehn Jahren und fühlt sich auch nicht so an, weil wir sie alle ständig modernisieren und erneuern und ständig innovieren.

Wir sind auch ziemlich gut darin, organisch einen einheitlichen Codierungsstil durch Konsens zu schaffen. Wir haben ein Team, das sich so gut wie selbst steuert, selbst wenn eine zentrale Figur durch Urlaub oder Krankheit ausfällt. Es funktioniert alles irgendwie von selbst, und es ist großartig, das zu sehen.

Das soll nicht heißen, dass wir das perfekte Team sind. Wir versuchen immer noch herauszufinden, wie wir unsere Junioren effektiv betreuen können. Wir haben die Planungsphase für Probleme immer noch nicht im Griff: Oft müssen wir den Code nach der Codeüberprüfung überarbeiten, und das ist nicht gerade optimal. Ich bin auch besorgt über unsere "Nicht-erfunden-hier"-Tendenzen. Und unser Freigabeprozess könnte etwas Arbeit vertragen.

CI/CD? Nun... Wir haben natürlich ein Jenkins. Und es ist in viel besserem Zustand als früher.