Antwort.

Historisch wurde die Aufwandsschätzung auf Expertenschätzungen oder Analogien zu früheren Projekten basiert. Unter Bedingungen von begrenzter Zeit und Informationen muss der Systemanalytiker mit hochrangigen, verschwommenen Anforderungen arbeiten und sieht sich häufig mit Unvollständigkeit und überhöhten Erwartungen konfrontiert.

Problem: Ungewissheit führt zu Risiken der Unterschätzung, Konflikten mit dem Auftraggeber und dem technischen Team sowie zu Budgetüberschreitungen. Die Schätzung ist sehr kompliziert aufgrund von Änderungen der ursprünglichen Eingaben nach Vertragsunterzeichnung.

Lösung:

Nutzung von Techniken zur Dekomposition von Anforderungen und schnellen Schätzungen (Planning Poker, T-Shirt-Größe)
Identifizieren und Dokumentieren aller Annahmen und Einschränkungen
Führen eines Protokolls der Fragen und unbekannten Bereiche
Risikopuffer einplanen (Ungewissheitskoeffizienten/Puffer)
Am wichtigsten ist es, die Abnahmekriterien (Done) und Begrenzungen festzulegen.

Schlüsselfunktionen:

Kurze Artefakte: High-Level-Szenarien, User Stories, C4-Diagramme
Visualisierung der Hauptwertströme
Fokus auf Prototypen und Wireframes, um schneller zu einer Einigung zu kommen.

Fangfragen.

Kann man eine Schätzung vornehmen, ohne die Qualität zu gefährden, wenn die Anforderungen noch nicht vollständig geklärt sind?

Nein, jede Schätzung in diesem Stadium muss als vorläufig gekennzeichnet werden mit der Festlegung der Risiken und Reserven. Andernfalls wird die Verantwortung für Budgetüberschreitungen auf den Ausführenden fallen.

Sollte man nur die Objekte in die Schätzung einbeziehen, die vom Auftraggeber klar definiert wurden?

Nein. Alles, was nicht definiert ist, wird über "Puffer für Ungewissheit" oder spezielle Story Points für zukünftig zu klärende Punkte geschätzt; es ist wichtig zu vermerken: „Andere Anforderungen liegen außerhalb der Schätzung“.

Muss der Systemanalytiker an der Erstellung der TCO (Total Cost of Ownership) teilnehmen?

Ja, der Analyst erstellt die Ausgangsdaten - Liste der Anforderungen, Szenarien, Risikobereiche, Einschränkungen, was kritisch für die korrekte Berechnung der TCO ist.

Typische Fehler und Anti-Patterns

Effort-Schätzung des Projekts "ins Blaue hinein", ohne Berücksichtigung unbekannter Bereiche
Ignorieren möglicher Änderungen nach Projektstart
Keine schriftliche Festlegung von Annahmen und Einschränkungen

Beispiel aus dem Leben

Negativer Fall: Der Systemanalytiker hat die Anforderungen vom Manager „wie sie sind“ akzeptiert, schnell geschätzt, ohne in die Details einzutauchen und die Einschränkungen und versteckten Bereiche zu überprüfen.

Vorteile:

Schnell, bequem für den Auftraggeber

Nachteile:

Budgetüberschreitung, Unzufriedenheit des Auftraggebers und des Teams
Refactoring von Lösungen und die Fristen "brennen" von Anfang an.

Positiver Fall: Der Analyst führte eine Workshopsitzung mit den wichtigsten Stakeholdern durch, kristallisierte sogar allgemeine Anforderungen heraus, erstellte eine Karte der Unsicherheitsbereiche, gab Annahmen an und führte Reserven ein.