Warum wir die schwierigste Stelle zuerst bauen

In fast jedem Kickoff gibt es diesen Moment: Jemand zeigt auf das Dashboard im Entwurf und sagt, damit könne man doch anfangen, das sei „schnell gemacht". Meistens stimmt das sogar. Und meistens ist es trotzdem die falsche Entscheidung.

Warum die Reihenfolge zählt

Ein Projekt ist nicht eine Liste von Aufgaben, die man in beliebiger Folge abarbeitet. Es ist eine Liste von Annahmen, von denen sich einige als falsch herausstellen werden. Die Reihenfolge, in der ihr baut, entscheidet, wann ihr das merkt.

Wer mit dem Einfachen beginnt, sammelt drei Monate lang sichtbaren Fortschritt und stößt danach auf die Schnittstelle, die anders funktioniert als dokumentiert. Wer mit dem Schwierigen beginnt, hat drei Wochen lang wenig zu zeigen — und danach ein Projekt ohne Sprengsatz.

Fortschritt, der die riskanteste Annahme nicht berührt, ist kein Fortschritt. Er ist Vorschuss.

Risiko schlägt Reihenfolge im Backlog

Wir sortieren Tickets nicht nach Wert allein, sondern nach Wert und Unbekanntheit. Zwei Fragen genügen meistens: Wie viele offene Fragen hängen an dieser Stelle, und wie viel anderes hängt von ihr ab?

// Die Reihenfolge, in der wir Tickets schneiden:
const order = backlog
  .map(withRisk)                       // wie unbekannt ist die Stelle?
  .sort((a, b) => b.risk - a.risk)      // unbekanntestes zuerst
  .filter((t) => t.value > 0);

function withRisk(ticket) {
  const unknowns = ticket.openQuestions.length;
  const blast    = ticket.dependents.length;
  return { ...ticket, risk: unknowns * 2 + blast };
}

Das ist bewusst grob. Es geht nicht um eine Kennzahl, sondern darum, das Gespräch zu erzwingen: Was wissen wir hier wirklich nicht?

Wie das in der Praxis aussieht

Bei einem Kundenportal für einen Energieversorger war die riskanteste Stelle nicht das Portal, sondern der nächtliche Abgleich mit dem Abrechnungssystem. Wir haben zwei Wochen nur daran gearbeitet, bevor eine einzige Seite stand.

1. Annahme benennen. „Der Export liefert alle Verträge in einem Lauf." Aufschreiben, damit sie prüfbar wird.
2. Kleinsten Test bauen. Kein Feature — ein Skript, das die Annahme trifft oder bricht.
3. Ergebnis teilen. Auch und gerade, wenn es unbequem ist. In Woche zwei ist eine falsche Annahme eine Notiz, in Woche zwanzig ein Change Request.

Die drei üblichen Einwände

„Wir brauchen früh etwas zum Zeigen"

Verständlich, und lösbar: Ein Klickprototyp entsteht in Tagen und zeigt mehr als drei fertig gebaute Screens. Nur sollte er nicht mit dem verwechselt werden, was in Produktion läuft.

„Das Schwierige klärt sich später von selbst"

Tut es nicht. Es wird später nur teurer, weil dann Code daran hängt, den jemand geschrieben hat, während die Annahme noch galt.

„So sehen wir wochenlang keinen Fortschritt"

Ihr seht anderen Fortschritt: beantwortete Fragen. Wir machen den sichtbar, indem wir die offenen Annahmen als Liste führen und durchstreichen, was geklärt ist.

Was ihr davon habt

Projekte, die so laufen, haben langweilige Endphasen. Keine Woche vor dem Launch, in der jemand entdeckt, dass die Schnittstelle keine Stornos kann. Das ist der ganze Trick — und es ist unbequem genug, dass die meisten es nicht machen.