Bevor eine Anwendung entwickelt oder weiterentwickelt wird, fehlen oft noch Details: Geschäftsregeln müssen bestätigt werden, Integrationen sind nicht dokumentiert oder es bestehen Zweifel an der Datenqualität. Dennoch müssen Produkt, Business und Technologie entscheiden, ob sie fortfahren, mit welchem Team und in welcher Reihenfolge. In diesem Kontext bedeutet ein PHP-Projekt trotz Unsicherheit zu schätzen nicht, eine exakte Zahl zu erraten, sondern eine begründete Prognose, ihre Grenzen und die nötigen Erkenntnisse zu präsentieren, um sie zu verbessern.
Eine Schätzung dient dazu, Entscheidungen zu unterstützen und Arbeit zu koordinieren. Sie ist nicht automatisch eine unveränderliche Verpflichtung hinsichtlich Umfang, Termin und Kosten. Wer diese Begriffe unterscheidet, kann planen, ohne Risiken zu verschleiern, und Änderungen anhand konkreter Informationen besprechen.
Warum eine einzelne Zahl Unsicherheit verbergen kann
Eine Angabe wie „zwölf Wochen“ wirkt einfach, sagt aber nicht aus, was enthalten ist, wovon die Arbeit Dritter abhängt oder welche Annahmen zugrunde liegen. Zwei Teams können dieselbe Dauer nennen und dabei unterschiedliche Arbeiten kalkulieren: Das eine könnte Tests, Migration und Deployment einschließen, das andere nur die Entwicklung von Funktionen. Ohne eine explizite Grundlage lässt sich anhand der Zahl weder ein Angebot mit einem anderen vergleichen noch eine Abweichung diagnostizieren.
Außerdem sollten Aufwand und Dauer getrennt betrachtet werden. Der Aufwand beschreibt die Arbeit des Teams; die Kalenderdauer berücksichtigt Reihenfolge, Verfügbarkeit, Reviews, Wartezeiten und Abhängigkeiten. Mehr Personen verkürzen die Dauer nicht immer: Sie können den Koordinationsaufwand erhöhen oder eine Wartezeit auf den Zugriff zu einem externen System nicht beheben.
Gib die Prognose daher als Bandbreite an, solange die Informationen keine höhere Genauigkeit rechtfertigen. Die Bandbreite muss begründet sein: Welche Szenarien bildet sie ab, welche Unsicherheiten vergrößern sie und welche Bedingungen würden eine Annäherung an einen der beiden Grenzwerte ermöglichen? Eine Bandbreite ohne Begründung ersetzt lediglich eine willkürliche Zahl durch zwei.
Bekannten Umfang, offene Fragen und Abhängigkeiten trennen
Erstelle vor der Kalkulation eine Schätzgrundlage, die die Unterschiede zwischen verstandener und noch zu untersuchender Arbeit sichtbar macht. Eine kurze Bestandsaufnahme kann jeden Punkt wie folgt einordnen:
- Bekannt: vereinbartes und überprüfbares Verhalten, etwa das Hinzufügen eines validierten Feldes zu einem vorhandenen Formular.
- Zu klären: ausstehende fachliche Entscheidungen, etwa wer einen Antrag unter welchen Bedingungen genehmigen darf.
- Abhängigkeit: Zugriff, Antwort oder Lieferung, die von einem anderen Team, Anbieter oder System gesteuert wird.
- Technisches Risiko: etwas, dessen Machbarkeit oder Aufwand unbekannt ist, etwa die Migration von Daten mit uneinheitlichen Formaten.
Untersuche bei einer PHP-Anwendung auch den bestehenden Kontext: Code-Struktur, Testabdeckung und Nutzen der Tests, Version und Abhängigkeiten der Umgebung, Datenmodell, Integrationen, Authentifizierung, Berechtigungen und Deployment-Prozess. Es muss nicht angenommen werden, dass alles in schlechtem Zustand ist; es sollte jedoch klar sein, was überprüft wurde und was lediglich angenommen wird.
Dokumentiere Annahmen zusammen mit ihren Auswirkungen. Zum Beispiel: „Es wird davon ausgegangen, dass der externe Dienst eine Testumgebung und aktuelle Dokumentation bereitstellt; andernfalls muss der Vertrag untersucht werden, bevor sich die Integration schätzen lässt.“ So bleibt eine Annahme keine versteckte Bedingung. Halte außerdem fest, wer sie bestätigen kann und wann.
Bandbreiten nach Phasen erstellen und ihren Umfang erläutern
Teile die Arbeit in Abschnitte auf, die Entscheidungen unterstützen. Eine mögliche Ausgangsstruktur umfasst Analyse, Implementierung, Validierung und Produktivsetzung. Nicht jede Initiative benötigt dieselben Phasen, und sie müssen nicht als voneinander isolierte Blöcke ausgeführt werden: Ziel ist es, unterschiedliche Arbeitsarten zu trennen und ihre Ergebnisse klar zu benennen.
Gib für jeden Abschnitt das erwartete Ergebnis, den geschätzten Aufwand, die wichtigsten offenen Fragen und die Abhängigkeiten an. Eine Integration kann beispielsweise die Analyse des Vertrags, die Implementierung, Tests mit echten oder simulierten Antworten, Fehlerbehandlung und Observability umfassen. Deckt die Bandbreite nur den Kommunikationscode ab, sag das ausdrücklich; stelle sie nicht als vollständige Integration dar.
Berechne Bandbreiten, die den verfügbaren Erkenntnissen entsprechen. Wenn der Umfang definiert ist und das Team das System kennt, kann die Spanne enger sein. Fehlen Anforderungen oder ist die Technologie unbekannt, verwende eine größere Spanne und erläutere die Gründe. Vermeide einen pauschalen prozentualen Risikopuffer, der nicht mit konkreten Risiken verknüpft ist: Er kann ein falsches Gefühl der Absicherung vermitteln und erklärt nicht, wie sich die Unsicherheit verringern lässt.
Lege Arbeiten offen, die oft nicht berücksichtigt werden, sofern sie nicht vereinbart sind: Datenaufbereitung, Sicherheitsprüfung, Barrierefreiheit, Monitoring, Dokumentation, Schulung oder Koordination mit anderen Teams. Nicht immer muss jeder Punkt enthalten sein, aber die Entscheidung darüber sollte sichtbar getroffen werden. Um die Dauer zu vermitteln, zeige auch die Reihenfolge der Aktivitäten und externe Wartezeiten, die den Zeitplan beeinflussen könnten.
Durch Analyse oder ein Pilotprojekt Erkenntnisse gewinnen
Wenn eine Unsicherheit Kosten oder Machbarkeit stark beeinflusst, kann es sinnvoller sein, zunächst Untersuchungen anzustellen, bevor ein detaillierter Plan verbindlich zugesagt wird. Eine klar begrenzte Analysephase kann Code und Architektur prüfen, Benutzerabläufe klären, Integrationen bestätigen und eine technische Hypothese testen. Sie sollte klar definierte Fragen, Aktivitäten, eine geplante Dauer und Ergebnisse haben, zum Beispiel ausstehende Entscheidungen, aktualisierte Risiken und eine überarbeitete Schätzung.
Ein Pilotprojekt kann Erkenntnisse liefern, wenn sich ein repräsentativer Teil des Ablaufs mit echten Benutzern oder Systemen testen lässt. Ein Pilot ist keine Demonstration, die für sich genommen beweist, dass das Produkt betriebsbereit ist. Lege fest, was bewertet wird, wie die Ergebnisse gemessen werden und welche Qualitäts-, Sicherheits- und Supportkontrollen vor einer Ausweitung des Umfangs erforderlich sind. Wird die Hypothese nicht bestätigt, sollte vorab vereinbart werden, welche Entscheidung dann getroffen wird.
Analyse und Pilot verursachen Kosten und können ebenfalls Probleme aufdecken; sie garantieren nicht, dass die Unsicherheit verschwindet. Wähle je nach Fragestellung: Eine Überprüfung kann ausreichen, um Anforderungen zu klären, während eine technisch unbekannte Integration möglicherweise einen begrenzten Test erfordert. Wenn sich weitere Untersuchungen vorerst nicht lohnen, dokumentiere das Risiko und plane eine Überprüfung, sobald neue Erkenntnisse vorliegen oder sich die Auswirkungen ändern.
Den Plan überprüfen, ohne jede Änderung zur Krise zu machen
Eine Schätzung zu überprüfen bedeutet nicht, dass die vorherige nutzlos war. Es bedeutet, dass sich die verfügbaren Informationen geändert haben. Lege Überprüfungspunkte fest – zum Beispiel nach Abschluss der Analyse oder nach der Validierung einer Abhängigkeit – und vergleiche die gewonnenen Erkenntnisse mit den ursprünglichen Annahmen.
Beschreibe bei einer Änderung, was sich geändert hat: Umfang, Annahme, Abhängigkeit, Qualitätsanforderung oder Systembedingung. Erläutere anschließend die Auswirkungen auf die Arbeit und den Zeitplan und zeige Handlungsoptionen auf. Der Umfang kann reduziert oder verschoben, ein späterer Termin akzeptiert, in weitere Untersuchungen investiert oder das Risiko mit einem Maßnahmenplan übernommen werden. So geht es im Gespräch um Entscheidungen und Folgen, statt eine alte Zahl zu verteidigen.
Anzeichen dafür, dass der Plan bereits vor dem vorgesehenen Meilenstein überprüft werden sollte, sind widersprüchliche Anforderungen, verspäteter Zugriff auf Umgebungen, andere als erwartete Daten, Tests, die strukturelle Probleme aufdecken, oder eine unbeantwortete externe Abhängigkeit. Wenn Aufgaben regelmäßig mehr Aufwand als geplant erfordern, untersuche die Ursache – etwa nicht berücksichtigte Komplexität oder Unterbrechungen –, statt automatisch dieselbe Anpassung auf alle noch offenen Arbeiten anzuwenden.
Kurze Vorlage zur Kommunikation einer Schätzung
Eine praktische Zusammenfassung kann auf eine Seite passen und folgende Felder enthalten:
- Ziel und Umfang: welches Ergebnis angestrebt wird und was nicht enthalten ist.
- Aufwands- und Zeitbandbreite: verwendete Einheiten, eingeschlossene Phasen und der Unterschied zwischen Arbeit und Kalenderdauer.
- Annahmen: Bedingungen, auf denen die Schätzung beruht, und Möglichkeiten, sie zu bestätigen.
- Unsicherheiten und Abhängigkeiten: Auswirkungen, Verantwortliche und das nächste erkennbare Prüfsignal.
- Vertrauensgrad: begründete Einschätzung mit den Faktoren, die sie einschränken; keine erfundene statistische Genauigkeit.
- Nächster Schritt: Entscheidung, Untersuchung oder Lieferung, die eine Überprüfung des Plans ermöglicht, sowie der Termin oder die Bedingung für die Überprüfung.
Zum Beispiel lässt sich kommunizieren, dass die Bandbreite eine erste Implementierungsphase unter bestimmten Annahmen abdeckt, die externe Integration noch nicht validiert ist und der Plan nach dem Zugriff auf die Testumgebung überprüft wird. Das Beispiel legt keine allgemeingültige Dauer fest, sondern zeigt, wie sich eine Prognose mit überprüfbaren Bedingungen verknüpfen lässt.
Die Qualität einer ersten Schätzung bemisst sich nicht daran, wie eng ihre Bandbreite ist, sondern daran, wie hilfreich sie bei der Wahl des nächsten Schritts ist. Bei einem PHP-Projekt hilft es, bekannte Arbeiten von offenen Fragen zu trennen, Abhängigkeiten zu beschreiben und zu vereinbaren, wie der Plan aktualisiert wird. So lassen sich fundierte Entscheidungen treffen, bevor alle Anforderungen abschließend geklärt sind.
