Softwareprojekte mit losen Anforderungen

Wenn die Anforderungen lose definiert sind, sollte regelmäßig und häufig funktionierende Software an den Kunden geliefert werden. Wireframes und Prototypen können helfen, aber nicht so sehr im Vergleich zu funktionalen Systemen. Mit funktionierender Software meine ich nicht, alles zu bauen, sondern mich zunächst auf die Teile zu konzentrieren, die dem Kunden den größten Mehrwert bieten. Lassen Sie den Kunden mit dem spielen, was Sie für ihn erstellt haben. Dadurch werden auch die Anforderungen für den Kunden selbst geklärt und er weiß mehr darüber, was er braucht, anstatt was er will.

Zunächst müssen Sie sicher sein, dass Sie das Projekt in den Griff bekommen. Ein lose definiertes Projekt wird lose geliefert, also ändern Sie den Ausgangszustand so schnell wie möglich, indem Sie:

1. Stellen Sie sicher, dass Sie die Stakeholder und Personen kennen, die von dem Projekt profitieren werden. Bringen Sie sie dazu, sich darüber im Klaren zu sein, was sie wollen oder wie sie aus dem Projekt Nutzen ziehen werden.
2. Erstellen Sie eine Architektur-/Designskizze, um die Zustimmung von Stakeholdern und dem Entwicklungsteam zu erhalten. Lassen Sie es nicht verschwommen, nutzen Sie die Lösungsansicht, um die Diskussion über die Auswirkungen bestimmter Entscheidungen voranzutreiben.
3. Legen Sie ein vorläufiges Budget und einen Zeitplan fest. Sie können sie später ändern, aber verwenden Sie diese, um zu sagen: „Mit diesen Einschränkungen müssen wir anfangen, den Umfang einzuschränken“, und verwenden Sie dies, um Diskussionen darüber anzuregen, was am wichtigsten ist.

Um die Dinge während des Fortschritts auf Kurs zu halten, gewöhnen Sie sich an zu sagen: „Wir wollen diese Funktion/Komponente in dieser Version fertig nennen (vor dem nächsten Statusbericht) und suchen nach abschließendem Feedback/Kommentaren.“ Es hilft wirklich, a Periodischer Veröffentlichungsplan, bei dem das Produkt am Ende jeder Veröffentlichungsperiode "potenziell veröffentlichbar" ist (z. B. Scrum)

Unterteilen Sie das Projekt in „Dinge, die wir kennen und zu deren Entwicklung wir uns bis zu einem bestimmten Datum verpflichten können“ und „Dinge, die wir nicht gut genug kennen, um einen anderen Umfang zu haben als die Anzahl der Veröffentlichungen, die wir für die Fertigstellung budgetieren sollten“. Auf diese Weise werden Sie es immer tun ein Projekt haben, das Sie steuern/überwachen und darüber Bericht erstatten können. Behalten Sie genügend Arbeit in dem gut definierten Teil des Projekts, um das Team zu puffern, während Sie und vielleicht ein technischer Leiter daran arbeiten, den anderen Teil zu definieren.

Ich würde zuerst herausfinden, was "auf dem richtigen Weg" bedeutet. Gibt es ein Mindestfeature, das bis zu einem bestimmten Datum geliefert werden muss? Ein Geschäftsergebnis, das erreicht werden muss? Wenn dies der Fall ist, sollte dies dazu beitragen, einen Fokus und eine Vision für das Projekt bereitzustellen. Wenn es etwas Kleines gibt, das früh geliefert werden kann, ist dies eine großartige Möglichkeit, die Lieferfähigkeit des Teams zu beweisen, das Vertrauen der Stakeholder zu gewinnen und Zeit für später zu gewinnen.

Sobald die Vision festgelegt ist, erarbeiten Sie, welche Aspekte davon am wenigsten bekannt sind. Gibt es Teile der Benutzeroberfläche, die sich niemand richtig vorstellen kann? Noch nie erprobte Architektur? Programmieren Sie den Rest fest und erhalten Sie so schnell wie möglich Feedback zu diesen riskanten Aspekten. Aziz' Vorschläge für regelmäßige Präsentationen sind der beste Weg, den ich gefunden habe, um dies zu tun. Denken Sie daran, dass verschiedene Bereiche des Projekts unterschiedliche Interessengruppen haben werden, also zeigen Sie den Architekten beispielsweise alle architektonischen Erkenntnisse; Benutzeroberflächen für die Benutzer; Business-Funktionalität an die Abteilungen, die sich darum kümmern.

Anstatt mich auf den Wert zu konzentrieren, konzentriere ich mich eher auf das Risiko (wobei ich mich daran erinnere, dass Bereiche mit geringem oder begrenztem Wissen dazu neigen, eine Reihe von Risiken zu bergen, von denen Sie noch nicht einmal wissen), und liefere dann das kleinste wertvolle Ding, das ein bringt Unterschied. Dies kann wiederholt und schrittweise erfolgen, bis eine größere Vision erreicht ist.

In Bezug auf eine Methodik bietet Steve McConnells Rapid Development eine Tabelle, die zeigt, welche Methodiken für Projekte mit bestimmten Eigenschaften auf Projektebene geeignet sind. Bei Projekten mit „schlecht verstandenen Anforderungen“ werden Spirale, evolutionäres Prototyping und die Verwendung von COTS-Software am besten bewertet. Modifizierte Wasserfälle und evolutionäre Lieferung scheinen ebenfalls geeignet zu sein, aber nicht so sehr. Wie Sie bemerken, sind dies Methoden, die sowohl dem Kunden als auch dem Management einen hohen Einblick in die Arbeit des Entwicklungsteams bieten, „Kurskorrekturen“ mitten im Projekt ermöglichen und das Risikomanagement unterstützen sollen .

Es gibt jedoch eine Reihe von Kriterien, die McConnell zur Auswahl einer Methodik verwendet. Dazu gehören ein Verständnis der Anforderungen und der Architektur, der gewünschten Zuverlässigkeit, des Risikomanagements, der Verwendung eines vordefinierten Zeitplans, der Höhe des Overheads, der Kundensichtbarkeit und so weiter.

Wenn Sie eine Kopie von Rapid Development zur Verfügung haben, finden Sie die Tabelle, auf die ich verweise, auf den Seiten 156-157. Wahrscheinlich interessieren Sie sich für den größten Teil (wenn nicht alles) von Kapitel 7, in dem es um die Lebenszyklusplanung geht. Kapitel 6, in dem McConnells Auffassung von Rapid Development erörtert wird, könnte ebenfalls von Interesse sein.

Wenn Sie Softwareprojekte verwalten, empfehle ich Ihnen nicht nur dieses Buch, sondern auch McConnells Software Project Survival Guide . Beide Bücher waren (und sind immer noch) Pflichtlektüre in dem Softwareprozess- und Projektmanagementkurs, an dem ich teilgenommen habe, und werden hoch bewertet, wenn es um SE-Prozessbücher geht. Sie konzentrieren sich auch auf "Best Practices", die für eine große Anzahl von Projekten gelten.

Ein locker definiertes Projekt mit Anforderungen ist ein Rezept für Ärger.

Ihre Aufgabe als PM sollte es sein, die Anforderungen zu verschärfen.

• Meilensteine ​​definieren
• Definieren Sie, was von jedem Meilenstein geliefert wird

Der nächste Meilenstein oder 2 (oder 3) muss konkret sein; die zukünftigen können lockerer definiert werden, bis sie in der Pipeline nach oben rücken, dann müssen die klar definiert werden.

Es ist nicht möglich, etwas zu schaffen, das lose definiert ist . Definiere es und verfolge es.

Ich glaube immer noch, dass es nicht realistisch ist, in einem locker definierten Projekt ein gutes Tracking zu haben.

Obwohl ich glaube, dass die anderen Antworten den besten Weg bieten, um das Problem zu umgehen, möchte ich den Beteiligten dennoch klar machen, dass wir ohne klare Projektmeilensteine ​​keine klaren Fristen haben können. Es würde ihnen die Schuld für alle Verzögerungen geben, die (irgendwann) auftreten werden.