> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2024/essay-collection-informal-talks.md). # Essaysammlung — Verschiedene Gedanken Vor dem Jahreswechsel habe ich den Aufbau von A/B-Plattformen untersucht. Die Einzelheiten stehen unter [Problemfeld A/B-Tests](https://km.sankuai.com/collabpage/2103469706). 1. Wo wir heute stehen. Im Reifegradmodell für Experimente befindet sich Jingwan ungefähr in der Phase des Gehens, die übrigen Geschäftsbereiche noch in der Phase des Krabbelns. Krabbeln ist bereits die erste Stufe dieses Modells. Was davor liegt, würde ich als Erwachen oder erste Einsicht bezeichnen. In der Krabbelphase geht es darum, die grundlegenden Voraussetzungen für Experimente zu schaffen, vor allem Werkzeuge und grundlegende datenwissenschaftliche Fähigkeiten. 2. Die fortgeschritteneren A/B-Plattformen im Unternehmen. Mit Horizon von der Tuan-Plattform und der A/B-Plattform der Lieferabwicklung habe ich mich eingehender ausgetauscht. Beide befinden sich ungefähr in der Phase des Laufens. Ihre Entwicklung zielt darauf, Experimente in größerem Maßstab leichter zugänglich zu machen und belastbare Ergebnisse zu gewährleisten. Experimentierende sollen nicht einen Großteil ihrer Zeit darauf verwenden müssen, ihren Versuchsplan zu begründen. Auch sollen menschliche Einflüsse die Aussagekraft nicht beeinträchtigen. Dafür wurden datenwissenschaftliche Rollen eingeführt. Schon die Kennzahlen zeigen, dass der gesamte Ablauf betrachtet wird: Anbindung, Zuteilung, Durchführung und Entscheidung. Beispiele sind der Anteil neuer Experimente, deren Objektivität sich beurteilen lässt, und der Anteil objektiv belastbarer Ergebnisse bei wichtigen Experimenten. 3. **Was sich aus der Entwicklung der A/B-Plattform für die Lieferabwicklung lernen lässt. Diese Informationen stammen aus meinem Gespräch mit einem ihrer Kernmitglieder. Für mich ist das ein typisches Beispiel dafür, wie Technik dem Geschäft dient. Die konkrete Beziehung zwischen Technik und Geschäft wird fortlaufend weiterentwickelt. Besonders wertvoll sind dabei Menschen und Denkweisen, die beides verbinden.** In einem solchen Spezialgebiet kann die Geschäftsseite ihre Probleme oft nicht klar beschreiben, manchmal erkennt sie sie nicht einmal. Wer ihr gut helfen will, muss das eigene Fachgebiet verlassen, an die operative Front gehen, das Geschäft verstehen und die Perspektive wechseln. Die Abwicklung ist der Kern des Liefergeschäfts; ihre Effizienz ist daher entscheidend. Das mehrseitige LBS-Modell erfordert viele Experimente mit Algorithmen und Strategien. Entsprechend groß ist der Bedarf an einer leistungsfähigen A/B-Plattform. Anfangs waren Plattform und Geschäft lose gekoppelt, mit der für Plattformen typischen Leichtigkeit und Flexibilität. 2022 wechselte das Team zu einem vollständig betreuten Dienst mit klarem Fokus auf die Lieferabwicklung. Die Geschäftsseite muss nur ihren Bedarf nennen. Versuchsplanung, Durchführung und Auswertung liegen vollständig beim Datenteam. Angeboten werden nicht nur Fähigkeiten, sondern Lösungen, einschließlich Werkzeugen und Methoden. Angesichts besonders anspruchsvoller Geschäftsprobleme begann die Lieferabwicklung auch früh, mit der Forschung zusammenzuarbeiten. Die A/B-Plattform bietet drei Stufen der Öffnung: vollständige Betreuung, teilweise Betreuung und Zugang zur Analyse-Engine. Dahinter stehen drei Formen: einheitliche Verwaltung durch die Plattform, offene Funktionen für Versuchsplanung und -bewertung sowie Zugang zu einzelnen elementaren Analysemethoden. *** Beim Rückblick auf unsere Komponentenbibliothek habe ich kürzlich versucht, eine ziemlich unbestimmte Frage zu beantworten: Wie wird daraus eine Bibliothek mit großer Lebenskraft? Komponentenbibliotheken sind so verbreitet, dass das Thema meist klar und leicht verständlich wirkt. Tatsächlich gibt es nur wenige, die beliebt, gut benutzbar und langlebig sind. Besonders selten ist Langlebigkeit. Ich versuche, die Frage aus zwei Blickwinkeln zu beantworten. **Echte Probleme innerhalb eines klaren Geltungsbereichs lösen und ein positives Verhältnis von Nutzen zu Aufwand wahren.** Auf der Ebene des angestrebten Nutzens muss man die tatsächlichen Probleme finden, gründlich untersuchen und wirksam lösen. Dabei kommt es darauf an, für welchen Geltungsbereich man arbeitet. Je nach Umfang unterscheiden sich Kosten und sinnvolle Lösungen. Eine Komponentenbibliothek für ganz Meituan, für Finanzdienstleistungen oder für ein einzelnes Team kann jeweils einen anderen Zweck haben. Bei Projekten mit begrenztem Wirkungspotenzial muss man das Verhältnis von Nutzen zu Aufwand ständig im Blick behalten. Sonst können die Wartungskosten unbemerkt den tatsächlichen Wert übersteigen. Mittel- bis langfristig wird das korrigiert. Kürzlich bedauerten viele, dass YAPI, ein angenehmer zu bedienendes Werkzeug zum Mocken von Schnittstellen, nicht mehr gepflegt wird, während PAPI weiterhin die offizielle erste Empfehlung bleibt. Unabhängig von den organisatorischen Unterschieden vermute ich, dass die Wartungskosten von YAPI inzwischen höher waren als sein zusätzlicher Nutzen für Entwickler. Ich habe dafür keine Daten. Dass die meisten Projekte nicht zu YAPI gewechselt sind, spricht aber dafür, dass der zusätzliche Bedienkomfort gering war und nicht einmal die Migrationskosten aufwog. **Probleme auf der richtigen Abstraktionsebene lösen.** Erst aus dem Kern eines Problems und seinem Geltungsbereich ergibt sich das eigentliche Problem. Eine Komponentenbibliothek ist bereits eine bestimmte Lösung. Auf einer höheren Ebene muss sie nicht die beste sein. Mit zunehmender Abstraktion lassen sich Lösungen grob in Implementierung, Bibliothek, Framework und Standard einteilen. Eine Komponentenbibliothek liegt auf der zweiten Ebene. Darin sehe ich den Grund, weshalb MTD nicht funktioniert hat. In der Community gibt es das Projekt [A Global Design System](https://component-odyssey.com/articles). Es will Designern und Entwicklern weltweit universelle Komponenten bereitstellen. Tatsächlich ist es keine Komponentenbibliothek, sondern ein System, allerdings auch kein Designsystem wie Material Design. Bei einem solchen Projekt ist nicht entscheidend, ob es sich am Ende durchsetzt. Wichtiger ist, zu lernen, wie man eine Fragestellung auf einer hohen Abstraktionsebene erkundet. *** Die technischen Aufgaben eines Geschäftsteams lassen sich in zwei große Gruppen einteilen. Die erste löst die jeweils drängenden Probleme. Dafür müssen Kräfte gebündelt und die Probleme einzeln angegangen werden, häufig in Form besonderer technischer Initiativen. Die zweite erfordert langfristigen Aufbau und Betrieb, etwa Komponentenbibliotheken und andere technische Infrastruktur. Diese Arbeit verlangt kontinuierliche Pflege und langen Atem. Uns fehlt dafür noch ein geeignetes Betriebsmodell. Ein solches Modell könnte zugleich einen Teil der wichtigen Frage beantworten, wie Infrastruktur lebendig und entwicklungsfähig bleibt. Mit wachsendem Team und einer solideren technischen Grundlage muss sich unser Schwerpunkt schrittweise von einzelnen Kampagnen zu dauerhaften Mechanismen verschieben. Unsere Infrastruktur hat den Weg von null zu eins hinter sich. Nun müssen wir lernen, von eins bis unendlich weiterzugehen. Das heutige Betriebsmodell ist eher geschlossen und hängt deshalb von einzelnen Personen ab. Die Bereitschaft zu Beiträgen aus dem Team ist gering; vieles setzt administrative Anweisungen voraus. Mein Ansatz ist, von reifen Open-Source-Projekten zu lernen und eine offene, dauerhaft tragfähige Arbeitsweise aufzubauen, die die Kreativität des Teams freisetzt. Ein Entwurf steht unter [Arbeitsgruppenmodell — Working Group](https://km.sankuai.com/collabpage/2610619313). Er übernimmt das Konzept der Working Group und führt Mechanismen wie RFCs und Mitgliedschaft ein. Zugleich habe ich sie an unsere Teamgröße angepasst, um Offenheit und Effizienz auszubalancieren. Wer dazu Gedanken hat, ist eingeladen, Rückmeldung zu geben. *** Durch die jüngsten geschäftlichen Änderungen am Kontobuch stellt sich sowohl im Frontend als auch im Backend die Frage, ob die Architektur noch passt. Die Angemessenheit der Architektur wirkt sich unmittelbar auf die Qualität aus. Das war der Ausgangspunkt für die Überarbeitung der Geschäftskarte. Dazu einige Gedanken über die fachliche Architektur im Frontend. 1. Architektur hat im Frontend und im Backend nicht denselben Stellenwert. Über die Gestaltung fachlicher Frontend-Architektur besteht noch wenig Konsens. Häufiger sprechen wir über die Auswahl von Frameworks und Werkzeugketten. Ein wesentlicher Grund könnte sein, dass Frontends seltener an architektonische Grenzen stoßen. Die Engpässe, die aus Entscheidungen zur fachlichen Architektur entstehen, treten bei vielen Projekten während ihrer gesamten Lebensdauer nie auf. Ein mit einem üblichen Projektgerüst erzeugtes Standardprojekt kann bereits die höchsten Anforderungen des Geschäfts erfüllen. 2. Was ist eine Architekturentscheidung, und was nicht? Architektur entsteht durch Kommunikation, Analyse und Schlussfolgerungen, nicht allein durch die Auswahl von Werkzeugen. Wer nur auf die abschließend gelieferte Verzeichnisstruktur und Dokumentation schaut, übersieht leicht wichtige Konzepte wie Isolation und Wiederverwendung, Zustandsverwaltung und Abhängigkeitsumkehr. Sie sind für die tatsächliche Qualität und die Unterstützung fachlicher Anforderungen oft entscheidender. Die ECS-Architektur in Spielen löst beispielsweise Wartbarkeitsprobleme eines bestimmten Fachgebiets. 3. Müssen Frontend- und Backend-Architektur getrennt werden, oder genügt ein gemeinsames Architekturteam? Die Frage ist weitreichend. Die Systemstruktur spiegelt von selbst wider, wie das Team kommuniziert; auf das Conway-Gesetz gehe ich hier nicht weiter ein. Zwei Punkte sind dennoch wichtig. Erstens wird die Gesamtarchitektur das Frontend nach und nach stärker berücksichtigen. Wir befinden uns noch in einer Phase, in der eine kleine Sprachgemeinschaft der Mehrheit ihre Arbeit verständlich machen muss. Bei Qualität und Effizienz wird das Frontend bereits einbezogen, auch wenn die Prüfung zur Beherrschung technischer Risiken noch wie eine praxisferne Informatikprüfung wirkt. Vielleicht ist die Architektur nicht mehr weit davon entfernt. Zweitens können Frontend und Backend voneinander lernen. Frontend-Teams können von Backend-Ansätzen wie DDD profitieren, um fachliche Probleme besser zu verstehen. Backend-Teams können sich die schnelle Prototypenentwicklung und das Denken in Komponenten als Diensten aus dem Frontend aneignen. 4. Eine Pflichtlektüre zum Verständnis von Frontend-Architektur ist [What is Frontend Architecture?](https://ducin.dev/what-is-frontend-architecture). Es lohnt sich, den Autor Tomasz Ducin zu diesem Thema weiterzuverfolgen. *** Über physikalische Grenzen, technische Grenzen und die Grenzen des Nutzererlebnisses. Ich versuche damit eine Frage zu beantworten, die mir letzte Woche aufgefallen ist: Auf welcher Ebene sprechen wir von Optimierung, und innerhalb welcher Grenzen optimieren wir? Physikalische Grenzen zu kennen bedeutet, die grundlegenden Beschränkungen zu verstehen. Das hilft, in komplexen Innovationsprozessen nüchtern zu bleiben und Ressourcen sinnvoller einzusetzen. Noch heute arbeiten manche Hobbyforscher an einem Perpetuum mobile. Carnot zeigte bereits im 19. Jahrhundert, dass der Wirkungsgrad einer Wärmekraftmaschine eine theoretische Obergrenze hat. Der Versuch ist also zwangsläufig vergeblich. Auch heute glauben viele, die Weiterentwicklung von KI werde irgendwann alle Probleme lösen und Menschen ersetzen. Turing konnte diese Frage schon im 20. Jahrhundert klar beantworten. Es gibt viele Probleme auf der Welt. Nur ein kleiner Teil davon sind mathematische Probleme, davon ist wiederum nur ein Teil lösbar, davon ein Teil mit einer Turingmaschine berechenbar und davon ein Teil auf heutigen Computern umsetzbar. Die Probleme, die KI lösen kann, bilden nur eine Teilmenge davon. Physikalische Grenzen lassen sich nahezu unmöglich widerlegen. Bei mathematischen Grenzen ist das vollständig unmöglich, denn Mathematik beruht streng auf Logik und nicht auf experimenteller Beobachtung. Technische Grenzen geben der Ingenieurarbeit Richtung und machen sie effizienter. Innerhalb bekannter physikalischer Grenzen kann man mehrere Dimensionen optimieren, die Leistung steigern und das technische Optimum suchen. Eine DVD mit blauem statt rotem Licht nutzt etwa die kürzere Wellenlänge, um mehr Daten zu speichern. Auch die Entwicklung von 2G bis 6G hat die von Shannon bestimmte theoretische Kanalkapazität bei gegebener Bandbreite und gegebenem Signal-Rausch-Verhältnis nicht überschritten. Jede Generation optimiert technisch das Spektrum, die Codierung und Modulation sowie die Netzarchitektur. Das Moore’sche Gesetz wirkt weiterhin. Während wir uns den physikalischen Grenzen von Silizium nähern, lässt sich die Leistung noch durch bessere Gehäuse- und Verbindungstechniken wie 3D-Stapelung sowie durch Architekturverbesserungen wie SoCs und heterogenes Rechnen steigern. Bei den Grenzen des Nutzererlebnisses muss man erkennen, dass es sich um ein unendliches Spiel handelt. Das Erlebnis bewegt sich im Zusammenspiel mit diesen Grenzen. Menschliche Bedürfnisse, Erwartungen und Vorstellungskraft entwickeln sich laufend weiter. Egal, wie weit die Technik voranschreitet: Verbesserungen an entscheidenden Nutzungsmomenten, den MOTs, und an menschlichen Faktoren werden nie abgeschlossen sein. Deshalb gibt es auch keinen technischen Entwicklungsstand, ab dem eine bestimmte Art der Optimierung grundsätzlich unnötig wird. *** Ich habe ein Buch gelesen, dessen chinesischer Titel „Liquidität ist König“ bedeutet. Umsatz ist Eitelkeit, Gewinn ist Vernunft, doch Liquidität ist entscheidend. Das gilt besonders heute, in einer Zeit, in der um einen weitgehend bestehenden Markt gekämpft wird und Effizienz zählt. Wettbewerb bedeutet nicht mehr bloß, den Umfang auszuweiten und Wachstum zu verfolgen, sondern Effizienzreserven gründlich zu erschließen. Das Buch erklärt diese Logik anhand der Gewichtskontrolle. 1. Kleinere Teller benutzen. Sparsam sein und die Betriebskosten auf einen vernünftigen, begrenzten Ressourcenrahmen beschränken. Nach der Faustregel des Parkinson-Gesetzes wächst die Nachfrage nach etwas mit seinem Angebot. Deshalb löst der Ausbau von Straßen Staus nie dauerhaft: Es kommen immer weitere Fahrer, die die zusätzlichen Spuren füllen. 2. Erst Gemüse, dann Kohlenhydrate essen. Die klassische Rechnungsformel „Umsatz − Kosten = Gewinn“ wird zu „Umsatz − Gewinn = Kosten“. Zuerst wird der Gewinn beiseitegelegt, danach entscheidet man, wie das übrige Geld ausgegeben wird. Die Grundlage dafür ist der Primäreffekt. 3. Versuchungen beseitigen und das wegräumen, was man nicht essen sollte. Den vorgesehenen Gewinn, die Erträge der Eigentümer und die Steuern auf ein separates Konto legen, auf das man möglichst nicht zu bequem zugreifen kann. 4. Kleine, häufige Mahlzeiten statt großer Schwankungen. Zweimal im Monat den Kontostand prüfen und aus dem verfügbaren Geld auf die Geschäftslage schließen. Das ist die einfachste Form der Buchführung anhand des Bankguthabens. Dabei musste ich an Apples Neugestaltung des Weckers im Rahmen der Schlafverwaltung denken. Ich weiß nicht mehr, mit welcher iOS-Version sie eingeführt wurde. Beim üblichen Wecker steht die Frage im Vordergrund, wann man geweckt werden soll. Apples Schlafwecker richtet die Aufmerksamkeit zuerst auf die gewünschte Schlafdauer. Davon ausgehend passt man die Schlafens- und Aufstehzeit an. Hier wird eine veränderte Denkweise im Produktdesign sichtbar. Der Ansatz „Gewinn zuerst“ sollte sich auch in unserem kleinen Kontobuch entsprechend zeigen. *** Die Ausweitung des Traffics nach der Überarbeitung des Checkouts in einem teilweise überlagerten Fenster blieb lange ungeklärt. Jetzt ist es Zeit, das Problem direkt anzugehen. Diese Sache zehrt seit fast einem Jahr am Willen des Teams. Wenn ich mich ihr erneut stelle, habe ich zwei Möglichkeiten: Ich löse sie selbst, oder ich führe Menschen dabei, sie zu lösen. Aus Sicht guter Führung erwartet die Organisation wohl Letzteres. Um ein Team durch eine solche Aufgabe zu führen, muss ich der Reihe nach Haltung, Menschen, Ziel und Strategie klären. Zuerst muss ich meine eigene Denkweise neu ausrichten. Mit welcher Einstellung und inneren Haltung begegnen wir derselben Herausforderung? Ich muss eine neue Sicht gewinnen und sie dem Team vermitteln. Passend dazu bin ich auf das neue Buch *Reframe Your Brain* gestoßen. Reframing bedeutet, den Rahmen neu zu setzen und die Realität bewusst als eine neue Geschichte zu deuten, die einem mehr hilft. Es ist eine Neuprogrammierung des Gehirns, ähnlich wie bei einem FPGA-Chip. In der Psychologie gibt es das verwandte Konzept der kognitiven Umstrukturierung. Bei einer Situation, Erfahrung, einem Gedanken oder Gefühl erkennt man zunächst, wie man es selbst betrachtet. Dann hinterfragt man diese Sicht und nimmt eine andere ein. Man kann Schwierigkeiten etwa als Herausforderungen sehen, Herausforderungen als Abenteuer und das Abenteuer schließlich als Spiel. Das Buch beschreibt viele solcher Techniken. Besonders wichtig ist der Wechsel von einer passiven zu einer aktiven Haltung. Jerry sagte mir vor einigen Jahren etwas Ähnliches: weg von „Was soll ich tun?“ und hin zu „Was will ich tun?“. Noch einen Schritt weiter geht der Wechsel von „Ich möchte etwas tun“ zu „Ich entscheide mich, es zu tun“. Eine Entscheidung ist uneingeschränkt aktiv und eine Verpflichtung sich selbst gegenüber. Wer etwas nur tun möchte, verliert diesen Wunsch vielleicht, wenn sich die Bedingungen ändern. Wer sich entschieden hat, sucht dagegen jeden möglichen Weg, es zu schaffen, und lässt sich durch nichts aufhalten. Ist diese geistige Umdeutung bloß Selbstberuhigung, eine Art eingebildeter Sieg? Das ist ähnlich wie der Unterschied zwischen Marketing und einem Schneeballsystem. Oberflächlich verkaufen beide etwas. Entscheidend ist, wer am Ende tatsächlichen Wert schafft. Bei einer neuen Deutung geht es nicht darum, ob sie richtig ist, sondern ob sie wirkt. Manche Deutungen sind nicht richtig, können einem aber trotzdem helfen. *** Bei einer Checkout-Anbindung in der vergangenen Woche musste ein Geschäftsteam wegen Beschränkungen des Plattformcontainers auf einen anderen Checkout-Produkttyp wechseln. Das verursachte erheblichen Abstimmungsaufwand. Wir nahmen den Fall zum Anlass, die Auswirkungen früherer Containerwechsel auf das Geschäft entlang einer Zeitachse zu ordnen. Dabei traten die Kernprobleme hervor. Wie es in tianges Signatur heißt, sollte man „bei der Standardisierung möglichst vermeiden, die Gegenstände zu abstrakt, die Vorgaben zu simpel und die Abläufe zu mechanisch zu behandeln“. Für mich ist der zu abstrakte Blick auf die Gegenstände das größte Problem. Finanzdienstleistungen sind womöglich der größte Nutzer standardisierter Container. Dennoch habe ich bei den vielen technischen Entscheidungen der Vergangenheit nie erlebt, dass man von sich aus unsere Kollegen an der operativen Front befragt hätte. Ein pragmatischer Entwurf entsteht erst, wenn man sich tief auf das Geschäft einlässt. Technische Produkte und Standards einer Plattform decken normalerweise 90 Prozent der Fälle gut ab. Die schwierigsten verbleibenden zehn Prozent entstehen meist durch Dinge, von denen die Entwickler des Entwurfs nichts wussten. Die Geschäftsseite muss die Lücken dann durch eine schlechtere Nutzererfahrung oder zusätzliche Kosten ausgleichen. Gerade diese letzten zehn Prozent bestimmen unsere Wahrnehmung und Bewertung der Plattformarbeit. Auf einem Weg von hundert Einheiten ist man nach neunzig erst halb fertig. Das erinnert an Six Sigma in der Qualitätskontrolle: Um ein hohes Ergebnisniveau zu erreichen, muss die Prozessfähigkeit sechs Standardabweichungen entsprechen. Es geht darum, die letzten schwer erkennbaren Entwurfsfehler zu beseitigen. Erst die Aufmerksamkeit für Randfälle und deren Lösung bringen deutliche Qualitätsgewinne oder Wettbewerbsvorteile. Das sollten auch wir uns zu Herzen nehmen, gerade bei unserer Arbeit an Standards und Governance.