1. So Nicht!

„Wir hatten den Vertrieb gefragt, unseren Kunden Fragebögen geschickt, die Entwicklung um technische Ideen gebeten und noch ein paar eigene Ideen gehabt. Daraus ist eine lange, lange Liste entstanden. Beim Priorisieren haben wir uns schwer getan, weil uns alles irgendwie gleich wichtig erschien. Außerdem sind es ja oft die Kleinigkeiten, die den entscheidenden Produkterfolg ausmachen – das weiß man ja nie vorher! Anschließend hatten wir lange und nervige Diskussionen mit der Entwicklung. Wir hatten den Eindruck, sie hatten an allem etwas aussetzen und nicht wirklich Lust auf unsere Challenge!

Nach 3 Jahren haben sie uns dann IHR Ergebnis gezeigt. Nach so langer Zeit hatten sich die Anforderungen verändert, das Produkt war ein Flop. So macht das keinen Spaß!“

– RequirementDEVELOPMENT.

DownloadsDownloads

2. Die Kunst des Verzichts.

Bevor wir die Anforderungen an ein konkretes Produkt definieren können brauchen wir strategische Leitplanken. Die Firma Stihl hatte vor Jahren die strategische Orientierung: Wir verkaufen nicht im Baumarkt sondern nur im Fachhandel! Das gab der damaligen Unternehmensphase Klarheit.
Die Unternehmensstrategie mit Mission, Vision und strategischen Leitplanken ist vor allem dann etwas wert, wenn man daraus ableiten kann, was man NICHT tun sollte. Strategie ist die Kunst des Verzichts! Sie ist die Basis für die Marktstrategie mit Zielbranchen und Branchensegmenten und einer klaren Wettbewerbspositionierung. Die Technologiestrategie ist das Futter für neue Möglichkeiten. Aus diesen 3 Dokumenten leitet sich die Produkt-Portfolio-Strategie ab. Wenn dieser Rahmen existiert, kann das Requirements-Dokument daraus logisch abgeleitet werden.

– RequirementDEVELOPMENT.

3. Den Kunden besser verstehen

… als er sich selbst versteht!

Was erwarten wir, wenn wir den Kunden nach seinen Wünschen fragen? Kann ein Kunde wissen, was technologisch alles möglich wäre? Anforderungen, die ein Kunde formulieren kann, beziehen sich oft auf das bestehende Produkt-Portfolio und sind eigentlich eine Reklamation für erwartete – aber noch nicht erfüllte Funktionen. Damit reparieren wir die Vergangenheit aber gestalten keine Zukunft!

Der Sportschuh Hersteller ON hat es gezeigt: Selbst in hart umkämpfen und gesättigten Märkten kann man auch als Newcomer den etablierten Mitbewerbern erhebliche Marktanteile abnehmen.

Mit der Methode CPM analysieren und beobachten wir Kunden und Anwender so systematisch, dass daraus Lösungen entstehen, die den Kunden überraschen und die Wettbewerber zur Nachahmung zwingen – ein doppelter Vorsprung!

– RequirementDEVELOPMENT.

4. Weniger ist mehr.

Ein gutes Requirements Dokument ist vor allen Dingen eins – es ist kurz, prägnant und bringt die Dinge auf den Punkt. Komplexität kommt von alleine! Die genialen Fähigkeiten eines erfolgreichen Unternehmers liegen in der Klarheit. Dabei helfen Metaphern, mit Vergleichen aus der Natur oder anderen Umgebungen. So hilft es dem Entwickler immer wieder aufzutauchen aus der Welt der technischen Details mit einer Unzahl von Möglichkeiten und Restriktionen.

– RequirementDEVELOPMENT.

5. Das WAS nicht das WIE!

Wenn ein Requirements Dokument missbraucht wird, um der technischen Entwicklung Vorgaben zu machen; die F&E zu steuern, anstatt sie zu lenken, dann hat das Produktmanagement seine Rolle nicht wahrgenommen. Technische Vorgaben, die den Weg der Umsetzung, also das “WIE” beschreiben haben in diesem Dokument nichts zu suchen!

Ein gutes Requirements Dokument beschreibt einen Zielzustand aus der Sicht eines glücklichen Kunden. Für die technische Lösung gibt es verschiedene Alternativen und oft führen viele Wege nach Rom.

– RequirementDEVELOPMENT.