Wie man in Big Tech Projekte shippt

Warum Shipping schwierig ist

• Viele Menschen glauben fälschlicherweise, dass „Shipping“ einfach sei, aber der Normalfall ist, dass Releases verzögert oder abgesagt werden oder wegen mangelnder Qualität Probleme verursachen.
• Nur weil der gesamte Code geschrieben oder alle Jira-Tickets abgearbeitet sind, wird nicht automatisch veröffentlicht. Damit ein Release stattfindet, muss jemand die Lead-Rolle übernehmen.
• Das Release muss die höchste Priorität haben. Wenn man sich zu stark auf die User Experience (UX) konzentriert, verzögert sich das Release eher.
• Um ein Projekt erfolgreich zu shippen, braucht es eine technische Führungskraft oder eine DRI (Directly Responsible Individual). Teams mit einer Ingenieurin oder einem Ingenieur in dieser Rolle haben eine höhere Erfolgswahrscheinlichkeit.

Was bedeutet „Shipping“?

• Viele Ingenieurinnen und Ingenieure verstehen unter „Shipping“ einfach das Deployment von Code oder die Aktivierung einer Funktion, aber in großen Tech-Unternehmen wird es anders definiert.
• Ein Release gilt dann als erfolgt, wenn wichtige Personen im Unternehmen glauben, dass es „gelauncht“ wurde. Wenn VP oder CEO nicht zufrieden sind, ist es selbst bei ausgerolltem Code in der Praxis nicht wirklich „gelauncht“.
• Wenn ein Projekt bei den Nutzerinnen und Nutzern ein großer Erfolg ist oder Umsatz bringt, wurde es gelauncht; aber selbst wenn die Reaktionen der Nutzenden schlecht sind, gilt es als gelauncht, solange die Führungsebene zufrieden ist.

Die Bedeutung von Kommunikation

• Man muss klar verstehen, was das Ziel des Projekts ist. Je nach Ziel unterscheiden sich Arbeitsweise und Kommunikationsstrategie.
• Die Unternehmensführung kennt die technischen Details des Projekts kaum. Um Vertrauen zu erhalten, sind daher genaue Einschätzungen, Problemlösung und passende Updates wichtig.
• So erhält man Vertrauen:
• Frühere erfolgreiche Releases sind von Vorteil.
• Man sollte selbstbewusst auftreten.
• Man sollte wie die Mission Control der NASA professionell und prägnant kommunizieren.
• Über tägliche oder wöchentliche Update-Threads sollte man proaktiv informieren.

Probleme bei Production-Deployments lösen

• Die meisten Probleme entstehen durch unerwartete Details. Beispiele sind Probleme mit der Blockgröße in Memcached, Fehler bei der Traffic-Prognose oder sensible Nutzerdaten.
• Um Probleme schnell zu lösen, braucht man ein tiefes technisches Verständnis des Systems.
• Auf erwartbare Probleme muss man schnell reagieren können und klar erklären können, ob ein Problem schwerwiegend ist oder nicht.

Kann es sofort gelauncht werden?

• Es ist wichtig, sich zu fragen, ob man jetzt sofort launchen könnte. Wenn nicht, sollte man überlegen, was sich ändern muss, damit es möglich wird.
• Mit Feature Flags und Staging-Umgebungen sollte man so früh wie möglich Feedback einholen.
• Kurz vor dem Release sollte man technische Arbeit reduzieren und sich darauf vorbereiten, bei Problemen schnell reagieren zu können.

Zusammenfassung

• Shipping ist sehr schwierig und sollte höchste Priorität haben.
• Die Bedeutung eines Releases ist nicht einfach Deployment, sondern dass das Leadership-Team zufrieden ist.
• Das Vertrauen des Leadership-Teams zu gewinnen, ist der Schlüssel zu einem erfolgreichen Release.
• Ein Backup-Plan, mit dem man Probleme antizipieren und bewältigen kann, ist wichtig.
• Kurz vor dem Release sollte man Entwicklungsarbeit reduzieren, um sich auf Problemlösung konzentrieren zu können.
• Man sollte immer die Frage stellen: „Könnten wir jetzt sofort launchen?“
• Man muss die Angst ablegen und Mut haben.

[GN⁺]

Hacker-News-Kommentare

• Die Beobachtung, dass "Shipping" in einem Unternehmen ein soziales Konstrukt ist, ist beeindruckend. Fertig ist ein Projekt dann, wenn wichtige Personen glauben, dass es abgeschlossen ist.
• Dieser Artikel handelt nicht von Software-Deployment, sondern davon, die Führungsebene zufriedenzustellen. Selbst wenn Nutzer es hassen und der Markt es auslacht: Wenn das Management es mag, ist es shipped.
• Wie im Sport ein Sieg alle Probleme löst, löst in der Softwarewelt Shipping alle Probleme. Es gibt kein perfektes Produkt, aber wenn man früh shippt, können Nutzer trotzdem zufrieden sein.
• Manchmal bekommen Engineers, die Probleme lösen, mehr Anerkennung als diejenigen, die Probleme verhindern. Man versucht zwar, Probleme zu vermeiden, aber Führungskräfte erkennen das nicht immer.
• In Großunternehmen muss "Deployment" in einem größeren Kontext verstanden werden und nicht nur als das bloße Realwerden einer Funktion. Manche würden das als unethisch bezeichnen, aber in Großunternehmen ist es eine Art "Spiel".
• Ich habe viele Projekte shipped, aber ohne konkrete Beispiele ist das schwer glaubwürdig. Mit realen Projektbeispielen wäre es leichter zu verstehen gewesen.
• Dieser Artikel ist selbstwerbender Blog-Spam.
• Das deckt sich mit meiner Erfahrung, aber es fehlt an praktischen Ratschlägen. Es braucht konkrete Beispiele dafür, wie man Anerkennung durch die Führung bekommt.
• Das unterscheidet sich von meinen Erfahrungen in Großunternehmen. Auch ohne Unterstützung des Managements gilt etwas als Erfolg, wenn Nutzerfeedback oder Kennzahlen positiv sind. Auch kleine Projekte können wertvoll sein.
• Damit die Behauptung glaubwürdig ist, muss man sie quantitativ und qualitativ untermauern. "In Großunternehmen shippen" ist eine sehr allgemeine Aussage und braucht eine genauere Erklärung.

[signaling]

Ich habe einige eindrucksvolle Kommentare daraus herausgegriffen.

„Manche Leute wollen lediglich einen technischen Bereich aufbauen, der nur für sie selbst da ist, oder sich auf welcher Ebene auch immer von Menschen loben lassen, die über ihnen stehen. So wird nun einmal das ‚Spiel‘ gespielt. Dieses Spiel zu spielen führt letztlich zum Tod einer Organisation, und genau deshalb gibt es überhaupt Unternehmenslebenszyklen. Am Ende zersetzen solche Leute die Organisation von innen, verdrängen Menschen mit echten Meinungen oder solche, die darauf optimiert sind, die Arbeit tatsächlich erledigt zu bekommen.“

„Die Art, das Spiel zu gewinnen, besteht darin, es gar nicht erst zu spielen.“