Beispiele für durchgeführte Kostenvoranschläge

So bewerten Sie eine Anmeldefunktion: der verborgene Umfang – Passwortzurücksetzung, 2FA, Föderation, Ratenbegrenzung, Sitzungen – und die Fragen, die geklärt werden müssen, bevor überhaupt abgestimmt wird.

So schätzen Sie den Aufwand für eine SSO-Integration ein: Der Aufwand liegt nicht in Ihrem Code, sondern in den Besonderheiten des Identitätsanbieters. Die Fragen, die Sie klären sollten, bevor Sie eine Zahl festlegen.

So schätzen Sie den Aufwand für eine Zahlungsintegration ein: Sandbox vs. Live-Umgebung, Rückerstattungen, Webhooks, Idempotenz, PCI-Geltungsbereich. Das Gespräch, das geführt werden muss, bevor konkrete Zahlen feststehen.

Wie man eine Suchfunktion einschätzt: Relevanz, Ranking, Facettierung und die Frage, wem der Index gehört. Die Fragen, die aus dem einfachen „Eine Suchleiste hinzufügen“ eine fundierte Einschätzung machen.

Wie man ein Benachrichtigungssystem einschätzt: Kanäle, Einstellungen, Dublettenbereinigung und Zustellgarantien. Warum aus dem „Versenden einer E-Mail“ still und leise ein sechswöchiges Projekt wird.

So schätzen Sie einen Datei-Upload ein: Größenbeschränkungen, Virenprüfung, Wiederaufnahme der Übertragung, Speicherung und Aufbewahrung. Das Ziehen und Ablegen ist der einfache Teil; die eigentliche Herausforderung liegt dahinter.

So erstellen Sie ein Dashboard: Datenquellen, Aktualisierungshäufigkeit, Zeitzonen, Detailansichten, Zugriffsrechte. Das Diagramm selbst ist einfach; die dahinterliegende Datenpipeline macht die eigentliche Arbeit aus.

Wie man einen unzuverlässigen Test einschätzt: Warum es zwei Schätzungen sind und nicht nur eine, und warum ein Zeitrahmen besser ist als eine Diskussion über Punkte, wenn die Antwort davon abhängt, was Sie herausfinden.

So schätzen Sie einen Fehler ein, der sich nicht reproduzieren lässt: Sie können nicht den Aufwand für die Behebung abschätzen, sondern nur den für die Suche. So legen Sie ein Zeitlimit für die Untersuchung fest, anstatt über eine Story abzustimmen, die niemand einsehen kann.

Wie lässt sich ein Leistungsrückgang einschätzen: Der Großteil der Arbeit besteht in der Diagnose, nicht in der Behebung. Wie lässt sich das Ausmaß einschätzen, wenn die Ursache unbekannt ist und ein SLO auf dem Spiel steht?

Wie man einen vom Kunden gemeldeten Fehler einschätzt: Der Umfang richtet sich nach der Beschreibung im Ticket. Wie man eine einzeilige Korrektur von einer Lösung unterscheidet, die den gesamten Sprint in Anspruch nimmt.

So schätzen Sie den Aufwand für eine Datenbankmigration ein: Nachvervollständigung, Sperrdauer, Rollout und Rollback. „Eine Spalte hinzufügen“ entspricht einer Zeile SQL; die Schätzung bezieht sich auf die Sekunde.

So schätzen Sie den Aufwand für eine Datenmigration ein: Datenübertragung zwischen Systemen, Abgleich und Umstellung. Die Transformation dauert eine Stunde; die Bereinigung erstreckt sich über ein Quartal.

So schätzen Sie den Aufwand für ein Framework-Upgrade ein: Warum eine Erhöhung der Hauptversionsnummer ein Projekt und kein Ticket ist – und wie Sie es in Stories aufteilen, deren Umfang Sie tatsächlich einschätzen können.

So schätzen Sie den Aufwand für ein Dependency-Upgrade ein: Der „Long-Tail“-Anstieg, hinter dem sich N Spitzenwerte in einem Ticket verbergen. Lesen Sie zunächst die Changelogs und schätzen Sie dann den Aufwand für das, was Sie gefunden haben.

So schätzen Sie den Aufwand für eine CI/CD-Umstellung ein: Da es für die Pipeline-Arbeiten keine Demo gibt, unterteilen Sie das Projekt in Teile, die gestrichen werden können. Das vierteljährliche Projekt, das im Backlog als Refactoring versteckt ist.

Wie man den Wechsel zu einer API eines Drittanbieters einschätzt: semantische Lücken, Parallelbetrieb und die Annahmen, die in den Eigenheiten des bisherigen Anbieters verankert sind. Die neue API sieht lediglich identisch aus.

So planen Sie die schrittweise Einführung einer Ratenbegrenzung: Grenzwerte, Testphasen, Kundenkommunikation. Die Programmierung dauert einen halben Tag; die Festlegung von Grenzwerten, über die sich niemand beschwert, ist die eigentliche Arbeit.

So schätzen Sie den Umfang einer Änderung am Design-System ein: Token-Einführung, Auslaufpfade, Codemod-Abdeckung und die 200 Aufrufstellen, die die alte Komponente verwenden. Schätzen Sie den Umfang der nachgelagerten Auswirkungen ab.

So schätzen Sie den Aufwand für eine Barrierefreiheitskorrektur ein: A11y-Probleme sind Funktionen, die Sie beim ersten Mal nicht implementiert haben. Warum Sie den Umfang der Problemgruppe und nicht den Einzelfall einschätzen sollten.

So planen Sie die Einführung eines Feature-Flags: schrittweise Prozentsätze, Kill-Switches, Gating-Kennzahlen und die Aufräumarbeiten, die niemand einplant. Ein Flag ist ein kleines Produkt, kein Deployment.

Wie man einen Forschungs-Spike einschätzt: Ein Spike ist ein zeitlich begrenzter Arbeitsabschnitt mit einem zu erbringenden Ergebnis, keine Story. Wie man verhindert, dass er sich unbemerkt zu der Arbeit entwickelt, die ursprünglich im Umfang vorgesehen war.

Wie man einen Prototyp einschätzt: Es handelt sich um ein Ergebnis, das zum Lernen und nicht zum Einsatz gedacht ist. Wie lässt sich verhindern, dass aus dem „Wegwerfprodukt“ der Produktionscode wird, den niemand eingeplant hat?

Wie man ein ML-Experiment einschätzt: Es handelt sich um Forschung mit technischem Bezug – das Modell ist einfach, die Arbeit liegt in den Daten. Wie man ein Budget festlegt, nicht eine Prognose.