Klare, abgestimmte Anforderungen stehen in engem Zusammenhang mit erfolgreichem Projektabschluss. Kleine Teams können während der Initiierungsphase eines Projekts auf mehrere Hindernisse bei der Entwicklung und Verwaltung von Anforderungen stoßen. Nehmen Sie für die Zwecke dieser Frage an, dass das Projektteam die Arbeit an die Stakeholder „verkauft“ (denn wenn das Projektteam bei den Stakeholdern angestellt oder anderweitig in einer langfristigen Beziehung zu ihnen steht, ist das Leben einfacher, und wir sind es Versuche, Techniken zur Überwindung der Hindernisse zu untersuchen, nicht Techniken zur Umgehung der Hindernisse.
Stellen Sie sich also vor, Sie sind der PM eines kleinen Teams, das versucht, einen neuen Kunden davon zu überzeugen, dass Sie das Projekt abschließen können. Sie und der Kunde haben sich auf die funktionalen Anforderungen geeinigt, aber Sie wissen, dass andere Projektteams diese funktionalen Anforderungen erfüllen können. Wie ermitteln Sie die weichen Anforderungen und überzeugen den Kunden davon, dass Sie diese Anforderungen (über)erfüllen können? (Jeder bekommt als erste Antwort „Marketing“, es ist zu einfach.)
Diese Frage ist inspiriert von einem Kommentar von @mark Phillips hier
Die kurze Antwort für mich ist, immer User Stories zu haben. Ich habe einen Hintergrund als Softwareentwickler, viele Produktmanager haben keinen Hintergrund in der Entwicklung und können nicht in Einheiten der Entwicklungsarbeit denken. Sie können jedoch mit uns zusammenarbeiten, um zu definieren, wer die Endbenutzer sind und was sie mit dem Endprodukt tun werden. Sobald wir eine Liste wahrscheinlicher Benutzer erstellt haben, können wir die Arten von Interaktionen ausarbeiten, die diese „Benutzer“ mit dem Produkt haben werden. Jeder "Benutzer" hat eine Rolle zu spielen und hat daher einen anderen Satz von Merkmalen/Funktionalitäten, die er benötigt. Der schwierige Teil besteht dann darin, die Überschneidungen zwischen diesen "Benutzern" zu finden und daraus harte Anforderungen zu erstellen. Es wird jedoch viele weiche Anforderungen geben, die nicht in definierbare Arbeitseinheiten passen und dann als Richtlinien für die Haptik des Produkts verwendet werden können.
Der Hauptvorteil davon bestand für mich darin, testbare Szenarien zu erhalten. Je besser wir die Art der Interaktion des Benutzers mit dem Produkt in menschlichen ("weichen") Begriffen beschreiben können, desto einfacher ist es, eine gute Liste positiver und negativer Testfälle zu erstellen.
Ein Verständnis für die menschliche Interaktion und eine gute Geschichte darüber, wie das Produkt auf seinem Weg getestet wird, war schon immer der Schlüssel, um Unterstützung von außerhalb der Entwicklungs-/Engineering-Abteilung zu erhalten.
Es gibt kein Rezept, um einen Kunden davon zu überzeugen, dass Sie seine weichen Anforderungen erfüllen können. Es kommt auf Beziehungen und Persönlichkeiten an. Manche Leute "klicken" miteinander, andere nicht.
Es kann frustrierend sein, besonders für ein kleines, hungriges Team, zu denken, dass es einige Jobs gibt, die sie wegen der weichen Seite nicht bekommen werden. Aber die Alternative besteht darin, Zeit und Geld für kostenlose Arbeit aufzuwenden und zu versuchen, dem Kunden zu „helfen“, Gegenstände aufzudecken, die immateriell sind. Es mag den Anschein haben, als würde der Kunde ein gutes Geschäft machen, da Sie für ihn strategische Beratung kostenlos durchführen. Aber wenn der Kunde nicht danach gefragt hat, ist es wahrscheinlich, dass er keinen Wert darin sieht und daher den Wert dessen, was Sie tun, nicht sieht/versteht.
Es gibt Leute, die die weiche Seite schätzen, die Sie auf den Tisch bringen. Es gibt Menschen, die Sie und Ihr Team „verstehen“ und mit denen das Team klickt. Verbringen Sie Ihre Zeit damit, diese Kunden zu finden, anstatt zu versuchen, diejenigen, die nicht klicken, von Ihrem Wert zu überzeugen.
MCW