Software Engineering Guide
1.0

View in English

1.0 Einführung in Teil 1: Menschen

Software wird von Menschen gebaut, und Menschen werden durch Kultur, Struktur und Prozess organisiert. Bevor wir also über Code, Architektur oder Werkzeuge sprechen, betrachtet dieser Teil das menschliche System, das all das hervorbringt: die gemeinsamen Werte, nach denen ein Team lebt, die Art, wie es sich in Teams aufteilt, wie es Karrieren fördert, wie es sich im Alltag koordiniert und wie es Entscheidungen trifft und festhält. Alles andere im Buch ruht auf diesen Grundlagen. Eine brillante Architektur, gebaut von einer ängstlichen, zersplitterten oder vergesslichen Organisation, wird den Kontakt mit der Realität nicht überstehen.

Für große Teams hören diese Grundlagen auf, intuitiv zu sein, und werden strukturell. Praktiken, die sich unter acht Menschen in einem Raum durch bloße Nähe verbreiten, zerfallen unter achthundert Menschen, verteilt über den Globus. Man muss also Kultur explizit machen, Teamgrenzen absichtlich gestalten, Wachstumserwartungen schriftlich festhalten, Koordination von Flurgesprächen zu dauerhaften Dokumenten verlagern und Entscheidungen festhalten, damit ihre Begründung die Menschen überdauert, die sie getroffen haben.

Unternehmen und Behörden spüren jeden dieser Drücke mit voller Wucht. Sie arbeiten in großem Maßstab, unter Prüfung und Aufsicht, über lange Zeiträume und mit einer Mischung aus Festangestellten, Auftragnehmern und Zulieferern. Ein System, das Sie heute bauen, läuft vielleicht ein Jahrzehnt lang, gepflegt von Menschen, die Sie nie getroffen haben. In diesen Umgebungen sind die Grundlagen dieses Teils keine weichen Fähigkeiten oder nette Extras. Sie sind der Mechanismus des institutionellen Gedächtnisses, der Rechenschaftspflicht und des Risikomanagements.

Kapitel in diesem Teil

  • 1.1 Werte der Softwaretechnik: Die gemeinsamen Überzeugungen und alltäglichen Verhaltensweisen, die tatsächlich bestimmen, wie Software gebaut wird, zentriert auf psychologische Sicherheit, schuldfreies Lernen, klare Verantwortlichkeit, eine Schreibkultur und ein nachhaltiges Arbeitstempo.

  • 1.2 Teamtopologien und Organisationsdesign: Wie die Aufteilung von Menschen in Teams die Software formt, die sie bauen können (Conways Gesetz: Organisationen erzeugen Systeme, die ihre eigenen Kommunikationsstrukturen widerspiegeln), unter Nutzung von stream-ausgerichteten, Plattform-, Enabling- und Complicated-Subsystem-Teams, um die kognitive Last zu minimieren und teamübergreifende Abhängigkeiten zu reduzieren.

  • 1.3 Rollen, Karrierepfade und Wachstum: Der Aufbau expliziter, kalibrierter Karriererahmen mit parallelen Laufbahnen für Einzelbeitragende und Führungskräfte, damit Einstufung, Beförderung, Einstellung und Vergütung im großen Maßstab fair, konsistent und begründbar sind.

  • 1.4 Arbeitsweisen: Wie Teams sich im Alltag koordinieren, planen und liefern, wobei Prinzipien gegenüber Ritualen bevorzugt und standardmäßig asynchrone, dokumentationsorientierte, ergebnisfokussierte Praktiken gewählt werden, die über Zeitzonen und gemischte Belegschaften hinweg skalieren.

  • 1.5 Entscheidungsfindung und Governance: Das Abwägen von Teamautonomie gegen organisatorische Ausrichtung durch ausgebaute Pfade, angemessen dimensionierte Prüfung, das Denken in umkehrbar versus unumkehrbar und die Verwaltung von technischen Schulden als Portfolio.

  • 1.6 Entscheidungsprotokolle: Wie man Entscheidungsprotokolle schreibt, speichert und pflegt, am häufigsten Architekturentscheidungsprotokolle (ADRs), damit die Begründung einer Wahl Personalwechsel übersteht und Prüfungen genügt, und wie man Entscheidungen auffindbar und sogar testbar macht.

  • 1.7 Technische Standards und Ausnahmen: Wie eine Organisation ihre technischen Standards verfasst, veröffentlicht, durchsetzt und weiterentwickelt, und wie sie Abweichungen durch einen geregelten, dokumentierten Ausnahmeprozess (Waiver) handhabt, damit Standards glaubwürdig bleiben, ohne starr zu werden.

  • 1.8 Einstellung, Vorstellungsgespräche und Onboarding: Der bewusste Aufbau des Teams durch inklusive Personalsuche, strukturierte und kalibrierte Interviews, die Verzerrungen reduzieren, und einen echten Onboarding-Plan, der neue Ingenieurinnen und Ingenieure schnell produktiv macht und ihnen ein Gefühl der Zugehörigkeit gibt, statt sie ins kalte Wasser zu werfen.

  • 1.9 Verteiltes und Remote-Arbeiten: Das Arbeiten über Standorte und Zeitzonen hinweg, indem standardmäßig auf asynchrone, schriftliche, dokumentationsorientierte Zusammenarbeit gesetzt wird, bewusste Überlappung und Übergaben gestaltet werden und Menschen nach Ergebnissen statt nach Stunden oder Sichtbarkeit beurteilt werden.

  • 1.10 Ingenieurseffektivität und Entwicklerproduktivität: Das Messen und Verbessern, wie effektiv Ingenieurinnen und Ingenieure ihre beste Arbeit leisten können, mithilfe mehrdimensionaler Rahmenwerke (SPACE und Entwicklererfahrung) statt einzelner manipulierbarer Zahlen, und das Beseitigen von Reibung und mühsamer Routinearbeit, die Teams ausbremst.

  • 1.11 Technisches Management: Das Handwerk, Ingenieurinnen und Ingenieure zu führen, statt der Karriereleiter selbst: der Eins-zu-eins-, Feedback- und Coaching-Kreislauf, Delegation, menschliches Leistungsmanagement, und daran gemessen zu werden, ein Multiplikator des Teams zu sein statt an der eigenen Leistung.

  • 1.12 Vielfalt, Gerechtigkeit, Inklusion und Zugehörigkeit: Der Aufbau eines Teams, in dem Unterschiedlichkeit vorhanden ist, fair behandelt, aktiv einbezogen und zum Gefühl der Zugehörigkeit gebracht wird, weil inklusive Teams bessere Software bauen und weil es richtig ist, mit ehrlicher Messung und ohne Alibifunktion.

  • 1.13 Mentoring, Coaching und Wissensaustausch: Das absichtliche Wachsen von Menschen und Verbreiten von Fachwissen durch Mentoring, Coaching und Sponsoring, Communities of Practice, interne Vorträge, Pairing und Dokumentation als Lehrmittel, damit Wissen jeden Einzelnen überdauert und das Bus-Faktor-Risiko niedrig bleibt.

Wie diese Kapitel zusammenhängen

Diese Kapitel bilden einen durchgehenden roten Faden. Werte definieren, was einer Organisation wichtig ist. Struktur und Rollen bestimmen, wer die Arbeit macht und wie diese Menschen wachsen. Arbeitsweisen regeln, wie Menschen sich koordinieren. Governance und Entscheidungsprotokolle bewahren die Begründung hinter ihren Entscheidungen. Die Abhängigkeiten verlaufen in dieser Reihenfolge. Die Schreibkultur und psychologische Sicherheit aus Kapitel 1.1 sind Voraussetzungen für die ehrliche Kalibrierung in Kapitel 1.3, die dokumentationsorientierte Zusammenarbeit in Kapitel 1.4 und die dauerhaften Entscheidungsprotokolle in Kapitel 1.6. Die in Kapitel 1.2 gestalteten Teamgrenzen sind Ihr Haupthebel für die Skalierung der Koordination in Kapitel 1.4, das offen bevorzugt, den Koordinationsbedarf zu senken, statt schwerere Rahmenwerke hinzuzufügen. Die Kapitel 1.5 und 1.6 bilden ein bewusstes Paar: Das erste legt die Governance-Philosophie fest, das zweite macht daraus eine dauerhafte Praxis.

Die Reichweite dieses Teils erstreckt sich über das ganze Buch. Die Teamtopologien aus Kapitel 1.2 prägen das Plattform-Engineering in Kapitel 8.4 und die Zuverlässigkeitsverantwortung in Kapitel 9.1. Die hier eingeführten Entscheidungsprotokolle tauchen überall dort wieder auf, wo bedeutsame Entscheidungen getroffen werden, von den Architekturgrundlagen in Kapitel 3.1 bis zu Eigenbau-versus-Kauf und Beschaffung in Kapitel 10.3, und ihre Absicherung durch Fitnessfunktionen verbindet sich mit den Delivery-Pipelines aus Kapitel 8.1. Das schuldfreie Lernen aus Kapitel 1.1 untermauert das Incident-Management in Kapitel 9.3, und die begründbare, dokumentierte Entscheidungsfindung, die in diesem ganzen Teil etabliert wird, ist genau das, worauf die Risiko-, Audit- und Assurance-Arbeit in Kapitel 10.2 angewiesen ist. Stimmen die Grundlagen, wird der Rest des Buches weit leichter anwendbar.