Projektschätzung mit steigenden Anforderungen

Eine Projektschätzung mit einem bestimmten Anforderungssatz vorzunehmen, ist eine Sache.

Was passiert jedoch, wenn der Benutzer plötzlich im laufenden Betrieb Änderungen vornimmt und dem bereits definierten Satz neue Anforderungen hinzufügt? Und ist sogar bis zu einem gewissen Grad verrückt danach, warum das Projekt nicht im ursprünglich geplanten Zeitrahmen abgeschlossen wird.

Wie soll ich mit diesen Situationen umgehen? Das Vorschlagen einiger Methoden und Lesungen könnte hilfreich sein.

Sie müssen dem Kunden klar machen, dass Anforderungsänderungen auch Änderungen im Umfang sind, und die Schätzungen jedes Mal aktualisieren, wenn sich die Anforderungen ändern.

Projektschätzungen werden aus einem bestimmten Grund als Schätzungen bezeichnet . Sie sind keine Versprechen. Wenn der Kunde sie versprechen möchte, ist das ein anderes Geschäft. Sie müssen jetzt viel größere Schätzungen mit einer höheren Erfolgswahrscheinlichkeit unter Verwendung eingefrorener Anforderungen bereitstellen .

Die meisten Projektschätzungen bieten ein bestimmtes Maß an Polsterung, das zwischen 20% und 100% Zeitprämie (oder mehr) gegenüber einer idealen Schätzung liegt. Stellen Sie sicher, dass Ihre Schätzungen diese Polsterung enthalten.

Es gibt agile Methoden, die dem Kunden eine bessere Sichtbarkeit bieten, damit er eine bessere Vorstellung von den damit verbundenen Anstrengungen und den Auswirkungen seiner Änderungen auf die Zeitpläne hat.

Sie müssen die Schätzungen aktualisieren, wenn sie die Anforderungen aktualisieren, und eine definierte Spezifikation dessen haben, was der Client als "erledigt" akzeptiert. "Meine vorherige Schätzung betraf den Funktionsumfang X, Y. Wenn Sie möchten, dass ich Z hinzufüge, schätze ich, dass dies den Liefertermin um ... verlängert", usw.

Sie sollten dem Kunden und dem Management die Auswirkungen auf Zeitplan und Kosten formell mitteilen, wenn Sie die Anforderungen ändern oder neue hinzufügen. Geben Sie Ihr Bestes, um einen formellen Genehmigungsmechanismus einzuführen, damit sie gründlich nachdenken, bevor sie nach etwas Neuem oder einer Änderung fragen. Andernfalls hören Sie immer wieder "Ich möchte, dass Sie XYZ hinzufügen" und später "Habe ich XYZ gesagt, ich meinte ABC".

Stellen Sie sich Ihr Projekt als Dreieck vor (ein PM-Freund von mir hat tatsächlich ein physisches Dreieck erstellt, das er für zusätzlichen Effekt verwendet hat). Die Kanten werden als Zeit , Kosten und Umfang bezeichnet . Sie sagen Ihrem Kunden, dass er die Kontrolle über zwei Seiten haben kann, aber Sie (verantwortlich für die Lieferung) müssen die Kontrolle über mindestens eine Seite haben.

Sie können es also schnell und kostengünstig erledigen - aber dann müssen Sie die Kraft haben, den Umfang zu verringern.

Oder Sie können mehr Funktionen erhalten, aber das kostet entweder mehr Zeit oder mehr Geld.

Lesen Sie mehr unter http://en.wikipedia.org/wiki/Project_triangle

Sie können versuchen, Scrum zu implementieren , eine agile Methode, die je nach Ihrer Situation sehr hilfreich sein kann.

Aus Wikipedia:

Scrum ist ein Prozessgerüst, das eine Reihe von Vorgehensweisen und vordefinierten Rollen enthält. Die Hauptrollen in Scrum sind:

1. der „ScrumMaster“, der die Prozesse verwaltet (normalerweise anstelle eines Projektmanagers)
2. der „Product Owner“, der die Stakeholder und das Unternehmen vertritt
3. das „Team“, eine funktionsübergreifende Gruppe von etwa 7 Personen, die die eigentliche Analyse, das Design, die Implementierung, das Testen usw. durchführen.

Während jedes „Sprints“, normalerweise zwei bis vier Wochen (wobei die Länge vom Team festgelegt wird), erstellt das Team ein potenziell versandfähiges Produktinkrement (z. B. funktionierende und getestete Software). Die Funktionen, die für einen Sprint erforderlich sind, stammen aus dem Produkt „Backlog“, einem priorisierten Satz von Anforderungen an die zu erledigende Arbeit auf hoher Ebene. Welche Backlog-Elemente in den Sprint eingehen, wird während des Sprint-Planungsmeetings festgelegt.

Es geht nicht um Methoden, sondern um die Kommunikation mit einem Kunden.

Ich hatte viele Situationen, in denen Kunden einem nicht abgeschlossenen Projekt ständig neue Funktionen hinzufügen wollten, und war überrascht, warum dies die Gesamtkosten und Verzögerungen erhöhen würde. Da der Kontext und die Persönlichkeit dieser Kunden unterschiedlich sind, waren unterschiedliche Ansätze erforderlich, aber ich kann versuchen, einige Richtlinien und Ratschläge zu isolieren:

• Stellen Sie sicher, dass ein Kunde Zugriff auf die allgemeinen Informationen hat, die erforderlich sind, um zu verstehen, warum sich eine Änderung einer Anforderung sowohl auf die Kosten als auch auf die Verzögerung auswirken kann . Mit anderen Worten, veröffentlichen Sie einige Artikel über diese Dinge und erklären Sie, was eine nicht-technische Person möglicherweise überhaupt nicht weiß.

Zum Beispiel ist es für die meisten Menschen völlig seltsam, dass eine Änderung, die sie für winzig halten, einen großen Einfluss auf das Projekt haben und sehr teuer sein kann (siehe Beispiel in meiner Frage ). Wenn sie darum bitten, einige Änderungen vorzunehmen, und jedes Mal, wenn Sie ihnen sagen, ohne etwas zu erklären, dass sie Tausende von Dollar zahlen müssten, wenn sie dies kostenlos oder für ein paar Dutzend Dollar erwartet hätten, würden sie wahrscheinlich denken, dass Sie gerecht sind ihr Geld stehlen. Dies gilt insbesondere, da einige unethische Programmierer und Softwareunternehmen nicht wartbare Produkte entwickeln (Sie können also nicht verlangen, dass sie später von einem normalen Entwickler geändert werden) und Sie dann bitten, für jede Änderung zu viel zu bezahlen.

• Stellen Sie sicher, dass ein Kunde verstanden hat , warum sich die gewünschte Änderung auf die Kosten auswirkt . Dazu können Sie ihr die Links zu Ihren Artikeln geben (siehe vorherigen Punkt) oder einfach auf nicht technische Weise zusammenfassen, was erforderlich ist, um eine angeforderte Änderung vorzunehmen.

Solche Erklärungen sind auch eine gute Idee, da sie Ihrem Kunden ein besseres Verständnis des Produkts und der Änderung ermöglichen. In einigen Fällen sagten einige meiner Kunden, dass die von ihnen gewünschte Änderung nicht zu klug sei und dass sie dies auf andere Weise tun würden. Sie können auch Dinge vorschlagen. Es wird von einigen Kunden sehr geschätzt (Warnung: andere hassen es) und zeigt, dass Sie wissen, wovon Sie sprechen (im Vergleich zu dem Code-Affen, der die Anforderungen nur in Code übersetzt, ohne zu viel über die möglichen Ansätze nachzudenken). .

• Stellen Sie sicher, dass ein Kunde nicht tun kann, was er will, es sei denn, er ist sich wirklich sicher. Für einige Leute besteht die einzige Möglichkeit darin, die Anforderungen endgültig zu sperren, bevor mit dem Codieren begonnen wird . Andernfalls ist es eine Katastrophe und das Projekt wird niemals enden . Für andere ist es nur eine gute Idee, niemals ein nicht abgeschlossenes Projekt zu sehen (im Allgemeinen haben meine Kunden sehr früh Live-Zugriff auf das nicht abgeschlossene Produkt, sodass sie auch frühzeitig Kommentare / Anpassungen vornehmen können).

Zum Beispiel hatte ich einen Kunden, der nach dem Senden der "endgültigen" Anforderungen durchschnittlich zehn Mails pro Tag mit zehn Anforderungsänderungen aufgrund geringfügiger Änderungen verschickte ("Können Sie die Rahmenbreite der mittleren Zone auf der Startseite ändern?" von drei auf sechs Pixel? ") zu den Änderungen, die das gesamte Projekt betrafen (nach zwei Monaten Entwicklung, eine Woche vor der Veröffentlichung:" Schließlich halte ich ASP.NET für eine schlechte Idee. Könnten Sie bitte zu PHP wechseln? " ).

Daher mussten wir für diesen Kunden alle Anforderungen sperren, bevor wir Code schreiben konnten. Es wurde im Vertrag geschrieben. Vor der endgültigen Veröffentlichung wurden keine Änderungen akzeptiert.

Schließlich war es nicht so schlimm, da wir seltsamerweise sehr gut organisiert sein durften: Das Projekt wurde gemäß den alten Anforderungen veröffentlicht, und einige Tage später starteten wir die nächste Version von Grund auf mit einem völlig anderen Set von Anforderungen.