Kurze Antwort: länger.

Längere Antwort: länger als du denkst, länger als du geplant hast, und genau dann fertig, wenn du aufgehört hast, daran zu glauben.

Die Schätzung

Es beginnt immer mit demselben Moment. Du schaust auf eine Aufgabe, lässt sie kurz auf dich wirken, und dein Gehirn – dieses treue, chronisch optimistische Organ – sagt: ach, das ist doch nicht so wild.

Manchmal sagt es womöglich: das ist eine Sache von einer Stunde.

Dein Gehirn lügt dich in diesem Moment nicht an. Es schätzt das, was es sieht. Das Problem ist, dass es nur sieht, was du dir vorstellst. Und du stellst dir vor, wie das aussieht, wenn es funktioniert – nicht wie das aussieht, während es noch nicht funktioniert.

Das ist der Unterschied zwischen dem Film und den Dreharbeiten.

Was du dir vorstellst

Du willst, sagen wir, automatisch Aufgaben erstellen lassen, wenn ein Deal in deinem CRM gewonnen wird. Im Kopf sieht das so aus: Deal gewinnt. System erkennt das. Tasks erscheinen. Alle sind glücklich.

Elegant. Schlank. Eine Stunde, vielleicht zwei.

Was du dir nicht vorstellst: dass der interne Stage-Identifier deines CRMs nicht “Closed Won” heißt, sondern irgendetwas wie dealstage_7_final_v2_legacy oder nur ’ne ID wie 45892547234 ist, und dass du das erst rausfindest, nachdem du eine Stunde lang Webhooks abgefangen hast, die nichts ausgelöst haben.

Du stellst dir nicht vor, dass du lokale Webhook-Tests brauchst, für die du erst ein Tool einrichten musst, das eine öffentliche URL simuliert, für das du dann wiederum einen Account brauchst, der nach 30 Minuten abläuft.

Du stellst dir nicht vor, dass der Deal in deinem Testsystem dreimal auf “gewonnen” gesetzt wird, weil du testest – und dein System daraufhin pflichtbewusst zwölf Tasks erstellt, von denen du jetzt weißt, dass du auch eine Deduplizierungslogik brauchst.

Du hast das alles nicht vergessen. Es war schlicht nicht in deiner Vorstellung enthalten. Das ist der Kern des Problems, und er lässt sich meiner Meinung nach nicht wegtrainieren, nur ehrlicher benennen.

Die zwei Todsünden der Zeitschätzung

Erste Todsünde: Vertrautheit mit Einfachheit verwechseln.

Du hast schon mal eine API angebunden. Also weißt du, wie das geht. Das stimmt auch. Aber diese API, mit diesem Authentifizierungsmechanismus, in dieser Kombination mit jenem System, für diesen spezifischen Use Case – das hast du noch nicht gemacht. Die Vertrautheit beruhigt dich in dem Moment, in dem du eigentlich wachsam sein solltest. Das ist in etwa so, als würdest du sagen: ich war schon mal in einem fremden Land, also finde ich mich auch in diesem anderen fremden Land sofort zurecht. Mag sein. Muss aber nicht.

Zweite Todsünde: sequenziell schätzen, obwohl Arbeit nicht sequenziell ist.

Schritt 1: 20 Minuten. Schritt 2: 30 Minuten. Schritt 3: fertig. Total: 50 Minuten, plus zehn Minuten für Kaffee.

Was dieser Plan nicht vorsieht: dass Schritt 1 eine Annahme enthält, die sich in Schritt 2 als schlicht falsch herausstellt. Woraufhin es keinen Schritt 2 gibt, sondern einen Schritt 1b, der nicht im Plan stand, und einen anschließenden Schritt 1c, bei dem du kurz überlegst, ob du das alles vielleicht anders angehen solltest.

Planabweichungen sind keine Ausnahmen. Sie sind der Normalfall. Nur der Plan weiß das nicht.

Was wirklich hilft – und was nicht

Was nicht hilft: einfach pauschal “das Dreifache einplanen und auf die nächst höhere Einheit aufrunden”. Das ist kein System, das ist Sicherheitsabstand ohne Verständnis. Und es löst das eigentliche Problem nicht – es kaschiert es nur, bis der Zeitpuffer aufgebraucht ist.

Was hilft: beim Schätzen nicht fragen “wie lange dauert das?”, sondern “was weiß ich hier eigentlich noch nicht?”

Das klingt nach derselben Frage in anderen Worten. Ist es nicht. Die erste Frage produziert eine Zahl. Die zweite produziert eine Liste – und auf dieser Liste stehen genau die Dinge, die deine Schätzung später zur Makulatur machen werden.

Konkret bedeutet das: bevor irgendetwas gebaut wird, den riskantesten Teil isolieren und zuerst anfassen. Nicht den einfachsten. Den, bei dem du am wenigsten weißt. Einen, der einen kleinen, schnellen Proof of Concept verlangt, der nur diesen einen Schritt löst – und zeigt, ob die Annahme dahinter trägt.

Das fühlt sich ineffizient an, weil man “noch nichts Richtiges baut”. Tatsächlich ist es das Effizienteste, was man tun kann – denn es stellt das Scheitern nach vorne, wo es billig ist, statt nach hinten, wo es teuer ist.

Die eigentliche Frage

“Wie lange dauert das?” ist die falsche Frage. Oder zumindest die zweitbeste.

Die bessere Frage ist: Was nehme ich bei dieser Schätzung an, ohne es zu wissen?

Und dann, ganz pragmatisch: Wie schnell kann ich aufhören, das anzunehmen?

Das klingt nach einer kleinen semantischen Verschiebung. Es ist eine ziemlich große praktische.

Wer diese Frage konsequent stellt, wird nicht plötzlich fehlerfreie Zeitschätzungen produzieren. Aber er wird früher wissen, wo er falsch liegt – und das ist, realistisch betrachtet, das Beste, was man erreichen kann.

Die Aufgabe dauert übrigens meistens nicht länger als gedacht. Man fängt nur später an, sie wirklich zu verstehen.

Und ja, dieser Post hat länger gedauert als geplant. Es war das Bild.

Quelle Foto: https://pixabay.com/de/photos/programmierung-code-code-editor-3652497/