SOFTWARE-PROJEKTMANAGEMENT · ENTSCHEIDUNGEN VOR DEM STICHTAG
Das Projektboard ist voll. Die Besprechungen sind angesetzt. Niemand ist sich einig, was die erste Version tatsächlich leisten muss.
Ein Softwareprojekt braucht Abstimmung, doch Aktivität ersetzt kein gemeinsames Ergebnis. Ein Stichtag ist hilfreich, wenn das Team versteht, was funktionieren muss, wer bei widersprüchlichen Prioritäten entscheidet und wie das Ergebnis abgenommen wird.
Klären Sie zunächst die Fragen, die sonst später zu kostspieligen Änderungen führen können, bevor Sie noch eine Statusbesprechung ansetzen.
Notieren, was sich verbessern soll
„Wir brauchen eine App“ beschreibt eine mögliche Lösung. „Mitarbeitende erfassen nach jedem Besuch denselben Servicebericht erneut“ beschreibt eine Aufgabe, die Sie untersuchen können. Beobachten Sie den aktuellen Prozess, ermitteln Sie die ausführenden Personen und stellen Sie fest, welche Zeitaufwände, Fehler oder Verzögerungen relevant sind.
Die Discovery-Leitlinien von GOV.UK stellen das Verständnis des Problems vor die Verpflichtung zur Entwicklung. Die Regeln gelten für staatliche Dienstleistungen, aber die Reihenfolge ist auch für Unternehmensprojekte sinnvoll. Die Discovery-Phase kann zeigen, dass ein bestehendes Tool oder eine Prozessänderung ausreicht.
Wählen Sie ein Ergebnis, das Anwender und Budgetverantwortliche erkennen können. Dokumentieren Sie den Ausgangspunkt und die Vergleichsbedingungen. Wenn eine schnellere Berichterstattung wichtig ist, legen Sie fest, welcher Bericht gemeint ist und wie die Genauigkeit gewährleistet wird.
Eine verantwortliche Person für Prioritätsentscheidungen benennen
Ein Team kann Vorschläge von allen sammeln, ohne zu versprechen, sie alle umzusetzen. Führen Sie eine priorisierte Liste und halten Sie die erste nützliche Version klein genug, um sie fertigzustellen. Unterscheiden Sie zwischen dem, was der Betrieb jetzt benötigt, und dem, was später vielleicht gewünscht wird.
Jede neue Anforderung verändert den Plan. Erläutern Sie die Auswirkungen auf Aufwand, Kosten und Version und lassen Sie dann die zuständige Person entscheiden. Machen Sie die Entscheidung sichtbar, damit dieselbe Diskussion nicht das nächste Meeting beansprucht.
Die Der Scrum Guide macht den Product Owner für die Priorisierung des Product Backlogs verantwortlich. Sie müssen nicht alle Scrum-Praktiken übernehmen, um von klarer Prioritätsverantwortung zu profitieren. Ein Ausschuss, in dem jeder Arbeit hinzufügen, aber niemand sie entfernen kann, ist schwer planbar.
| Frage | Nützliche Antwort | Nachweis |
|---|---|---|
| Was muss besser werden? | Ein klar benanntes betriebliches Ergebnis. | Ein Ausgangswert und eine vereinbarte Messgröße. |
| Wer entscheidet über Prioritäten? | Eine Person mit Entscheidungsbefugnis für Umfang und Abwägungen. | Ein gepflegtes Entscheidungs- und Änderungsprotokoll. |
| Was kann die Lieferung blockieren? | Abhängigkeiten mit Zuständigen und Terminen. | Testzugriff, Beispieldaten und Zusagen von Anbietern. |
| Wann ist das Ergebnis akzeptabel? | Beobachtbares Verhalten und Qualitätsbedingungen. | Abgeschlossene Abnahmetests statt einer Fortschrittsprozentzahl. |
| Wer betreibt die Lösung? | Benannte Verantwortliche für Support und Systeme. | Übergabe, Wiederherstellungsplan und Betriebsbudget. |
Die Verbindung testen, bevor Sie den Bildschirm ausarbeiten
Ein Bildschirm kann an einem Tag geändert werden, während der Zugriff auf ein externes System Wochen dauern kann. Ermitteln Sie frühzeitig die Abhängigkeiten: Datenverantwortliche, Testkonten, Anbieter, Geräte, Zahlungsdienstleister und Betriebspersonal, das den Arbeitsablauf freigeben muss.
Testen Sie die riskanteste Verbindung mit einem kleinen funktionierenden Beispiel. Prüfen Sie die tatsächlichen Berechtigungen und das Datenformat. Testen Sie einen abgelehnten Datensatz und legen Sie fest, wer ihn bearbeitet. Die Aussage, ein System „hat eine API“, belegt weder den passenden Zugriff für Ihr Projekt noch die Übereinstimmung seiner Geschäftsregeln.
Die Integrationsseite von Raptool listet Verbindungswege wie Dateien, Datenbanken und Webdienste auf. Nutzen Sie sie als Ausgangspunkt für eine konkrete Demo, nicht als Beleg dafür, dass sich jede Anwendung automatisch verbinden lässt.
Führen Sie ein kurzes Risikoregister, aus dem Maßnahmen folgen. Jedes wichtige Risiko braucht eine zuständige Person, einen nächsten Schritt und einen Zeitpunkt, an dem das Team den Plan anpasst. Ein Dokument, das nur Bedenken festhält, beseitigt keine Blockade.
Festlegen, was „fertig“ bedeutet, solange Änderungen noch günstig sind
Der Scrum Guide beschreibt, wie eine gemeinsame Definition of Done abgeschlossene Arbeit kenntlich macht. Übertragen Sie das für eine Geschäfts-App in konkrete Nachweise: Vereinbarte Funktionen arbeiten, erforderliche Berechtigungen sind geprüft, wichtige Fehler werden behandelt und die vorgesehenen Anwender können ihre Aufgabe erledigen.
Formulieren Sie Abnahmebeispiele vor der Demo. Berücksichtigen Sie normale Arbeit und Ausnahmen. Zeigen Sie den Fortschritt anhand eines nutzbaren Ausschnitts des Arbeitsablaufs statt einer Sammlung unverbundener Bildschirme. Die Person, die die App verwenden wird, sollte an der Bewertung mitwirken.
Eine kurze Entscheidung kann einen langen Neubau verhindern
Angenommen, eine Besprechung mit insgesamt zwei Personenstunden klärt ein missverstandenes Freigabeverfahren, das andernfalls 24 Stunden Nacharbeit erfordern würde. Die Nettodifferenz beträgt 24 − 2 = 22 Stunden, im Wert von €1,320 bei angenommenen €60 pro Stunde.
Dieses Szenario zeigt die Kosten verspäteter Entscheidungen und behauptet nicht, dass jedes Meeting Geld spart. Addieren Sie die Zeit aller Teilnehmenden und prüfen Sie, ob Nacharbeit tatsächlich vermieden wurde.
Sichern Sie die Qualität, wenn der Termin unangenehm nahe rückt. Reduzieren Sie bei Bedarf den Umfang offen und behalten Sie die vereinbarten Prüfungen für den verbleibenden Teil bei. Unfertige Arbeit als „fast fertig“ zu verbergen, schafft ein Problem für die Personen, die die Lösung betreiben müssen.
Der Start ist eine Übergabe
Stimmen Sie Migration, Schulung und Einführung mit den Personen ab, die den Betrieb führen. Halten Sie eine Ausweichlösung bereit und legen Sie fest, was zum Abbruch oder zur Rücknahme der Einführung führen würde. Stellen Sie Support-Kontaktdaten, Zuständigkeiten für Zugriffe und Wiederherstellungsanweisungen vor der ersten arbeitsreichen Schicht bereit.
Planen Sie Budget für Wartung und Änderungen ein. Legen Sie einen Termin fest, an dem Sie das ursprüngliche Ergebnis überprüfen, nachdem die Anwender mit dem System gearbeitet haben. Eine Lieferung überzeugt mehr, wenn das Unternehmen nachweisen kann, dass die App die Aufgabe verbessert hat, für die sie entwickelt wurde.
Gutes Projektmanagement macht Entscheidungen so klar, dass das Team nützliche Software liefern kann. Ein voller Kalender belegt nicht, dass diese Entscheidungen getroffen wurden.
Fragen, die der Entscheidung zugrunde liegen
Was sollte ein Softwareprojekt vor der Entwicklung klären?
Das betriebliche Ergebnis, die Entscheidungsbefugnis, der Umfang der ersten Version, wichtige Abhängigkeiten und überprüfbare Abnahmekriterien.
Verlangt dieser Artikel, dass jedes Team Scrum verwendet?
Nein. Der Scrum Guide dient als Quelle für die Prioritätsverantwortung und eine gemeinsame Definition of Done. Die praktischen Empfehlungen lassen sich auch mit anderen Vorgehensweisen bewerten.
Wann ist das Projekt abgeschlossen?
Vereinbaren Sie vorab das gewünschte Verhalten, Qualitätsprüfungen und die betriebliche Übergabe. Überprüfen Sie das angestrebte Geschäftsergebnis, nachdem die Anwender mit der Version gearbeitet haben.
Quellen und Umfang
Recherche im Oktober 2026 geprüft. Quellen stehen direkt neben den Fakten. Rechenbeispiele dienen der Veranschaulichung und sind weder Kundenergebnisse noch Anbieterangebote. Screenshots zeigen veröffentlichtes Plattformmaterial; Gerätefotos sind Katalogreferenzen und keine Kompatibilitätszertifizierung.
