Wie gehe ich mit häufigen Anforderungsänderungen um?

Ich habe es mit einer (meiner Meinung nach) ziemlich stressigen Situation an meinem derzeitigen Arbeitsplatz zu tun.

Wir haben begonnen, ein neues Projekt zu entwickeln, einige Anforderungen zu erhalten, es zu implementieren und dann jemandem zu zeigen, dass Sie einen "Unternehmensberater" anrufen können (eine Person, die die Geschäftsanforderungen kennt, das Programm jedoch nicht verwendet). Diese Person soll die Anwendung aus Kundensicht bewerten, testen usw.

So sieht der 'Prozess' aus:

1. Der Unternehmensberater spricht abends ein oder zwei Stunden lang mit meinem Chef über Windows Messenger
2. Am nächsten Tag erhalte ich eine E-Mail mit einer Kopie dieses Gesprächs. Ich soll Aufgaben daraus auswählen, gemeldete Fehler überprüfen (die oft keine Fehler sind, nur schlechte Tests und das Vergessen früherer Einrichtungen).
3. Ich implementiere Änderungen, die Implementierung wird akzeptiert und in ein oder zwei Wochen stellt sich heraus, dass sie nicht wollen (sie haben mit einem potenziellen Kunden gesprochen, der 5 Minuten lang Software gesehen hat und er Änderungen vorgeschlagen hat) - ich muss neue Änderungen vornehmen

Versteh mich nicht falsch, ich verstehe, dass sich manchmal die Anforderungen ändern. Was mich aufregt, ist, wie oft die Änderungen an meinem Arbeitsplatz auftreten und wie einfach es für das Management ist, zwei neue Anforderungen oder manchmal grundlegende Änderungen an vorhandenen Funktionen zu stellen.

Gleichzeitig arbeiten wir an engen Fristen und ich habe den Eindruck, dass wir, anstatt mit unserer Software voranzukommen, Kreise führen.

Ich bitte Sie um Rat, wie Sie mit dieser Situation umgehen sollen. Ist das eine normale Situation und ich bin nur überempfindlich?

Wenn möglich, nehmen Sie das Gespräch, das Sie per E-Mail erhalten, in ein Anforderungsdokument. Listen Sie die Aufgaben auf, die Sie daraus ableiten können, und ordnen Sie sie nach Ihrer Priorität. Weisen Sie jeder Aufgabe eine Schätzung zu. Fragen Sie dann, welche Funktionen sie für die nächste Version benötigen.

Erzwingen Sie grundsätzlich eine Art Rückkopplungsschleife, in der das Management weiß, was Sie erstellen werden. Schreiben Sie Ihre eigenen Anforderungsdokumente, bis sie die Nachricht erhalten.

Story Cards

Ich denke, Ihre Situation ist gut geeignet, um User Stories einzuführen . Sie sind sehr hilfreich, um Ihrem Manager eine fortlaufende, interaktive Möglichkeit zu bieten, Prioritäten zu setzen, und er kann sie sogar wegwerfen, wenn er eine Woche später auf die Idee zurückkommt und feststellt, dass sie nicht funktioniert.

In der realen Welt ändern sich die Anforderungen routinemäßig. Auf der positiven Seite erfahren Sie davon, bevor Sie die Software fertig erstellen und ausliefern - Sie haben einen engen Feedback-Zyklus vom direkten Benutzer der Software, was wirklich großartig ist.

Das größte Problem scheint hier die sehr ad-hoc Art und Weise zu sein, wie Änderungen verwaltet werden. Sie haben das, was Agile / Scrum als "Product Owner" betrachten, der Feedback gibt, aber der Prozess ist schlecht dokumentiert und schlecht durchdacht.

Sie möchten sich wahrscheinlich die Modelle in Scrum und ihre Ansicht darüber ansehen, was ein effektiver Produktbesitzer ist, um Sie über Ihre nächsten Schritte zu informieren.

Anstelle dieses Ad-hoc-Prozesses sollten Sie sich also in eine Welt begeben, in der Sie eine engere und nützlichere Beziehung zum "Unternehmensberater" haben und in der alle über die Ergebnisse der von ihnen diskutierten Änderungen auf derselben Seite sind .

Ihr aktueller Prozess macht es diesen Menschen zu einfach, Ideen zu entwickeln, ohne Rücksicht auf die Ressourcen und das Geld, die dadurch verbraucht werden. Wenn sie all diese Funktionen nutzen möchten, müssen sie etwas "Skin im Spiel" haben.

Nehmen Sie diese E-Mail der Konversation und fügen Sie sie in eine Art Feature- / Bug-Tracking-Anwendung ein, auch wenn es sich nur um eine Tabelle handelt. Senden Sie die neuen Ergänzungen an den Unternehmensberater zurück und bitten Sie ihn, jeden Artikel abzumelden oder Korrekturen vorzunehmen. Zusammen mit der Abmeldung sollten sie Prioritäten setzen (Welche möchten Sie zuerst?).

Senden Sie ihnen nach der Genehmigung Ihren Zeitplan zurück, wann die Elemente zum Testen fertiggestellt werden, und veranlassen Sie sie, sich auf einen Zeitpunkt für die Prüfung / Genehmigung des Abschlusses festzulegen.

Ich weiß, dass das Erstellen dieser Art von Dokumentation nicht der Grund ist, warum Sie Programmierer geworden sind, aber Sie können entweder riskieren, diese Listen wegzuwerfen oder Ihren hart verdienten Code weiter wegzuwerfen.

Zurückschieben. Die Verantwortlichen müssen sehen, wie viel diese Anfragen kosten.

Anforderungsänderungen sind nicht immer schlecht. Der Schlüssel ist, sich an Ihren Kunden zu erinnern. Wahrscheinlich ist Ihr Chef in diesem Fall Ihr Kunde. Sie müssen Ihren Chef darüber informieren, dass diese ständigen Anforderungsänderungen Ihre Fähigkeit einschränken, das für ihn nützlichste Produkt herzustellen. Es ist durchaus möglich, dass das Unternehmen davon profitiert, dass Sie ständig auf Änderungen reagieren. Wenn ja, ist das ihr Geschäftsmodell, und Sie machen nichts falsch, obwohl ich in diesem Fall empfehle, für die Hügel zu laufen!

Menschen, die mit Anforderungsänderungen frustriert sind, werden häufig danach bewertet, wie gut sie mit jeder Änderung umgehen. Diese Metrik der "Anzahl der ausreichend behandelten Änderungen" ist wahrscheinlich die Ursache für Ihre wirklichen Probleme. Besprechen Sie mit Ihrem Chef bessere Messdaten. Wenn ich ständig wechselnden Anforderungen gegenüberstehe, bemühe ich mich, Inhalte zu schreiben, mit denen ich mich an sich ständig ändernde Anforderungen anpassen kann. Anstatt jeden Tag eine Simulation durchzuführen und die Daten zu analysieren, werde ich Tools schreiben, die das Ausführen der Simulation und die Analyse der Daten billiger machen und die Belohnungen im Laufe der Zeit ernten. Wenn das noch zu verrückt ist, könnte ich sogar ein Werkzeug schreiben, um Werkzeuge zu schreiben!

Ihr Prozess kann von einigen agilen Prinzipien profitieren, z. B. von Iterationen. Ich denke, eine Woche ist angemessen mit solch schnellen Veränderungen, die Sie beschreiben. 2 Wochen könnten irgendwann besser funktionieren.

Sobald wichtige Anforderungen identifiziert wurden, lassen Sie die Person, die in der Project OwnerRolle ist, diese abmelden und sperren Sie sie für einen Zeitraum von einer Woche, während Sie sie erstellen. Weisen Sie genug Arbeit für sich selbst zu, wo Sie beschäftigt sein werden, und teilen Sie den Befugnissen Ihre Zuweisung mit. Wenn Sie also pro Woche Arbeit mit 16 Punkten produzieren können und 16 Arbeitspunkte haben, sind Sie für diese Woche voll ausgelastet. (Das Punktekonzept stammt aus einem agilen Arbeitsstrom)

Wenn sich Mitte der Woche Änderungen ergeben, sprechen Sie diese magischen Worte aus:

Ich kann [diese neue Funktion], [diese neue Änderung], [usw.] ausführen, aber was möchten Sie nicht tun ?

Das heißt, Sie sind eine begrenzte Ressource, Sie können nur so viel Arbeit aufnehmen. Wenn ein neuer Arbeitsgegenstand eingeht, dürfen Sie die begrenzte Ressource sein, die Sie sind, und dem neuen Gegenstand Punkte zuweisen und andere Gegenstände anstelle dieser neuen eingehenden Änderung löschen / ändern. Priorisieren Sie Ihre Iterationsliste zusammen mit dem Projektbesitzer neu, und Sie sollten besser mit Änderungen umgehen können.

Wenn sich die Anforderungen häufiger ändern, müssen Sie möglicherweise mehr Stabilität in Ihrer Umgebung aushandeln.

Der Ausdruck "Anforderungsänderung" wird manchmal von IT-Mitarbeitern missbraucht. Was Sie beschreiben, ist in der Tat eine Änderung der Anforderungen, aber dies kann daran liegen, dass eine oder mehrere der folgenden Ursachen vorliegen (ich weiß nicht genug über Ihren Fall, daher kann Folgendes zutreffen oder nicht):

1. Das Bestreben des Managements, den Endbenutzer so schnell wie möglich glücklich zu machen und schnelle Fortschritte zu zeigen.

2. Fehlende detaillierte Analyse. Denken Sie daran, dass Analysten Fragen stellen müssen, warum nicht nur was. Die Analysten müssen mit dem Endbenutzer über eine "Lösung" "nachdenken" und nicht nur Bestellungen entgegennehmen.

3. Fehlen eines formalen Prozesses zur Überprüfung und Bestätigung der Anforderungen, gefolgt von der Genehmigung.

4. Wenn Sie die falsche Person bitten, eine oder mehrere Rollen auszuführen, sind sie nicht unbedingt für Business Analyst- oder Systems Analyst-Rollen geschult.

5. Eingeschränktes Prototyping.

6. Die Annahme / Angst, dass es schnell gehen muss und wenn nicht seine IT schuld ist.

Wenn man nicht alle oben genannten Punkte richtig anspricht, ist die Beziehung zwischen der IT und dem Unternehmen / Endbenutzer stressig. Bitte beachten Sie, dass dies nicht bedeutet, dass der obige Punkt schlüssig ist. Es gibt andere Faktoren, die zu Stresssituationen führen, die Ihrer Situation ähneln, aber ich denke, diese Liste sollte Sie in Schwung bringen.

Ich denke, Sie sollten dies aus einigen Richtungen angehen:

1. Lassen Sie alle Beteiligten (einschließlich des gesamten Entwicklungsteams) (offline / online) mit dem Unternehmensberater zusammentreffen und versuchen Sie, die Domäne, die Vision und anschließend die Brainstorming-Anforderungen gemeinsam zu verstehen.

2. Formalisieren Sie Anforderungen / User Stories und bewerten Sie sie jeweils:
   a. Priorität (Dringlichkeit / Wichtigkeit)
   b. Fälligkeit (wie gut definiert - von der Mehrheit der Anteilseigner verstanden und vereinbart *)
   c. Komplexität (grobe Schätzung)
   
   Berücksichtigen Sie bei der Auswahl der Anforderung / Benutzerstory, an der als Nächstes gearbeitet werden soll, alle drei Faktoren. Wenn die Anforderung eine geringe Laufzeit hat, fügen Sie ihr eine Forschungsmission hinzu, in der Sie alle Beteiligten kontaktieren, die Gründe für die Anforderung untersuchen und die Anforderung besser definieren (Anwendungsfälle schreiben und / oder Drahtgitter erstellen und präsentieren), bevor Sie handeln darauf.

3. Denken Sie beim Entwerfen vor jeder Implementierung ein paar Schritte voraus - entwerfen Sie eine flexible Architektur, die Platz für Änderungen bietet.

4. Versuchen Sie, einen agilen Entwicklungsprozess anzupassen, z. B. SCRUM oder Kanban. Auf diese Weise erhalten Sie ein Toolkit für die Entwicklung eines Produkts mit sich ändernden Anforderungen.

Sie sollten auch in Betracht ziehen, die Moderatoren zu bitten, diese Frage auf PM.stackexchange.com zu verschieben (indem Sie sie markieren), da diese Frage zwar hier passt, dort aber besser passt.

(*) Stakeholder für Vereinbarung: Geschäft, Marketing, Projektmanagement, Entwicklung und Qualitätssicherung.