Wissen, ob es sich lohnt, zu retten oder neu zu bauen.

Es ist die teuerste Frage überhaupt, weil man in zwei Richtungen falsch liegen kann. Neu zu bauen, was sich hätte retten lassen, kostet Monate. Zu retten, was neu gebaut werden musste, kostet Jahre.

Was wirklich passiert

Was du bekommst

Die Ursachen, nicht die Symptome — und die Wege, die offenbleiben

Den tatsächlichen Zustand des Produkts, warum es dort gelandet ist, und die Wege, die offenbleiben: verwerfen und neu bauen, das Alte neben dem Neuen behalten und Nutzer:innen mit einer Mischung bedienen, oder Stück für Stück retten. Jeder mit eigener Zeit, eigenen Kosten und dem, was er bedeutet, während das Produkt weiterläuft.

Der schnellste Weg ist nicht immer der, den man gehen sollte. Welcher es ist, hängt von Dingen ab, die wir über den Code wissen, und von Dingen, die ihr über das Produkt wisst: Diese Entscheidung fällt dort, gemeinsam, mit den Zahlen auf dem Tisch.

Was es von dir braucht

Zugang zu dem, was da ist, so wie es ist

Auch wenn es in schlechtem Zustand ist, nicht dokumentiert wurde oder die Person, die es geschrieben hat, nicht mehr da ist. Das ist der Normalfall, nicht die Ausnahme.

Was es nicht ist

Kein Prozess, der stillsteht

Das Produkt bedient weiter Kund:innen, während es untersucht wird. Jeder Plan, der mit „wir schalten es ab und schauen mal“ beginnt, ist kein Plan.

Starter

Die Türen.

Build, Scale und Rescue sind langfristige Verpflichtungen, und bevor du sie eingehst, ist es normal, Klarheit haben zu wollen.

Starter sind ein Weg, ohne Verpflichtung zu beginnen: Sie dauern wenige Wochen, kosten wenig und enden mit etwas in der Hand, das auch dann wertvoll ist, wenn du danach mit anderen arbeitest. Drei geben dir eine Antwort, bevor du startest: einen Plan, eine Prüfung, ein Audit. Der vierte, der Dry Run, zeigt dir, wie wir an einem echten Teil deines Projekts arbeiten.

Wie wir von dort aus arbeiten

  1. Vorher

    Du entscheidest, wofür Kapazität eingesetzt wird

    Jede Aufgabe wird beschrieben, technisch und in der Oberfläche entworfen, nach Aufwand geschätzt und bleibt liegen, bis du sie freigibst. So siehst du, was entsteht, bevor Zeit dafür aufgewendet wird. Du gibst keine Rechnung frei: Du entscheidest, wohin die Zeit geht, die du bereits gekauft hast.

  2. Jeden Tag

    Du siehst die Pipeline in Bewegung

    Du hast Zugang zu dem Tool, in dem die Aufgaben leben: ihrem Status, dem zweiwöchigen Sprint, zu dem sie gehören, und ob sie vor oder hinter dem Plan liegen. Keine Monatszusammenfassung — dieselbe Ansicht, die wir nutzen.

  3. Währenddessen

    Niemand veröffentlicht den eigenen Code

    Wer schreibt, gibt nicht frei. Jede Änderung geht durch eine:n zweite:n Techniker:in, bevor sie irgendwohin gelangt.

  4. Vor dem Release

    Eine Umgebung, in der du es testen kannst

    Die Arbeit kommt an einen Ort, an dem du sie vor der Produktion sehen kannst. Wenn sie nicht deinen Erwartungen entspricht, geht sie zurück.

  5. Immer

    Code und Server bleiben deine

    Keine technische Bindung, die dich zum Bleiben zwingt.

Die Methode im Detail