Ein Geschäft entsteht immer dort, wo jemand etwas sucht, was jemand anderes bieten kann.

In seiner einfachsten Form sieht der Interessent etwas, das jemand anders besitzt. Dann klärt man die harten Fakten.
Besteht Verkaufsinteresse? Wie hoch soll der Preis sein? Ist der Besitzer auch Eigentümer oder sonstwie berechtigt den Gegenstand zu verkaufen?

“Am Markt” ist es aber sehr viel schwerer, genau den Kunden für ein fertiges Produkt zu finden oder genau den Lieferanten für eine bestimmte Lücke einer Lösung.
Zumindest, wenn man einen 100%-Anspruch verfolgt und das Zielbild mit klaren Kanten versieht.

In einem etablierten Markt mag das noch halbwegs funktionieren. Fortentwicklung entsteht aber immer dort, wo nur “Grundzüge” existieren und konkrete Ausgestaltung bisher nicht existierende Lösungsbestandteile enthält. “One off” wie es im englischen so schön heißt. Zu Deutsch: “Einzelanfertigung”.
In einem Umfeld mit hohem Anteil an Unbekanntem ist es deutlich leichter, Anforderungen abstrakt zu formulieren und schlicht zu fordern, dass diese Teile einer Lösung “zum Rest” passen müssen.
Dabei lässt sich jeweils verhandeln, ob noch weitere Details geschaffen oder verändert werden sollen bzw. müssen – also wie sehr “der Rest” angepasst werden muss um zum Lösungsbaustein zu passen.

Beispiel:
Der Auftraggeber fordert, dass eine Webseite auf “Mobilgeräten” angezeigt werden muss. Unreflektiert nehmen beide Seiten darunter “SmartPhones” an.
Als ein Entwickler die erstellte Seite in einer hohen Auflösung ansieht entsteht die Frage, ob auch Tablets gemeint seien, Notebooks beachtet werden sollen und Detachables (Surface Book etc.) mitberücksichtigt werden sollen.
Wenn der Auftraggeber dies von vornherein ausschließt und nur Auflösungen von 300 bis 600 und von 400 bis 1000 zulässt, stellt sich die Frage nicht.
Contraints werden nur Stylesheets für “kleine Bildschirme”, “lange” Signallaufzeiten und “niedrige” Übertragungskapazitäten abdecken.

Wie komme ich nun an den Punkt, dass beide Seiten im Grundsatz verstehen, worum es geht?
Gemeint ist hier nicht die eigentliche Aufgabe, sondern vielmehr das Vorgehen, um eine beiderseits akzeptable Lösung zu erzielen.

Agilität ist die Fähigkeit, sich an wechselnde Umweltbedingungen anpassen zu können. Und das so schnell und so passend wie nur irgend möglich.
Das gilt es zu entlohnen.

Aber wie?
“Wenn ich wenig Zeit habe muss ich spielen” – sagt Jan Fischbach.
Also erst einmal einen Workshop mit dem “customer prospect” gemacht.

Los geht’s “BoR – Bunch of Requirements”

Im Zusammenspiel der Parteien gibt es die zwei Parteien, die sehr überschaubare Funktionen haben. Kunde und Lieferant. Der eine braucht, der andere liefert.
Damit beide Parteien zu wahren Partnern werden, bietet sich auch noch ein Moderator an, der jenseits der Lösungsinhalte den Rahmen für das Vorgehen bereitstellt.

Also gibt es die folgenden

Rollen

• Kunde/Auftraggeber puzzelt und sucht dafür die passenden Teile
• Lieferant/en (Vertrieb der Zulieferer) kann benötigte Teile der Spezifikation/Anforderung entsprechend liefern
• Moderator/Spielleiter/Schiedsrichter/Zeitnehmer/Dokumentar hält das fest, was passiert und bringt die Spieler ggf. zurück in die Spur

Das Spielfeld/1 – Puzzle

Zunächst geht es darum, das “übliche” Vorgehen zu verstehen. Dazu wird der Kunde ein Kinder-Puzzle mit 100 Teilen zusammensetzen. 100 Teile entsprechen 100% einer Lösung. Für Erwachsene ein solches Puzzle innerhalb weniger Minuten lösbar – sofern man alle Teile hat.

Also verteilen wir die Teile, die zur vollständigen Lösungen fehlen auf ein oder mehrere Lieferanten (“Gegenspieler”). Es sollten 10 bis 20 Teile sein. Je mehr es sind, je länger zieht sich die Endphase bis zur Vervollständigung hin.
Es sollten mindestens 2 Teile pro Person sein. Je ein einfaches Teil (Kante/Ecke) und mindestens eines aus der Mitte. “Himmel”-Teile sind nicht so gut geeignet, da sie nur wenige beschreibbare Motivdetails aufweisen.
Der Kunde sollte das Puzzle selbst nicht kennen und auch nicht wissen, welcher Lieferant welches fehlende Teil hat.

Der Kunde puzzelt das Bild zusammen. Jemand dokumentiert die eingesetzten Teile in 30 Sek Intervallen.

Dokumentation im Chart 30-60-90-120-150 Sek.

Zum Ende der verfügbaren Teile wird es immer schwerer, die passenden Teile zu finden.
Irgendwann ist der Punkt erreicht, dass alle verfügbaren Teile eingesetzt sind und dennoch Lücken bleiben. Je nach Anzahl der “verteilten” Puzzle-Teile.

Nun muss der Kunde “genau” beschreiben, wie das fehlende Teil aussieht. Das ist die Spezifikation.
Er fragt nun die “Lieferanten” ab, ob sie ein Teil am Lager haben, das dieser Beschreibung entspricht. Stellen wir es uns wie eine Ausschreibung vor. Wer will, kann auch eine Bieterphase mit Preisfindung einbauen. Das kann zu interessanten Ergebnissen führen 🙂
Es wird sowohl nach Form (Schnittstellen) als auch nach Motivdetails (Funktionen) gefragt.

Man kann es nun auf die Spitze treiben und bis 100% (alle Teile) weiterspielen. Durch die mühsame Interaktion zwischen Auftraggeber (Puzzler) und seinen Lieferanten ziehen sich die letzten 10% länger hin als das puzzeln der ersten 90%. Und ganz sicher viel länger als der Auftraggeber in spe “intuitiv” angenommen hat.
Das ist der Zustand, der erfahren werden soll.

Nun ist der Boden bereitet, für den wichtigen Teil.

Das Spielfeld/2 – bspw. Business Model Canvas

Nun wird das Vorgehen vorgestellt, über das der Anbieter (“Lieferant”) mit seinem Kunden in Dialog treten möchte, damit beide Seite ein Verständnis füreinander entwickeln können.

Das kann bspw. das gemeinsame erarbeiten einer Geschäftsmodell-Leinwand sein. Wenn der Lieferant das Geschäft des Kunden verstanden hat, dann kann er “im Sinne des Kunden” Lösungskomponenten einbringen, selbst wenn diese Komponenten noch nicht existieren.

Und gemerkt? Für diesen Teil gibt es keine Vorgabe.

Das wird so gemacht, wie der jeweilige Verwender mit seinen Kunden idealerweise interagiert oder es zukünftig tun möchte.
Es geht “nur” darum, den Kunden dorthin zu führen, wo die Partnerschaft entsteht.

Feedback

Dieser Spielerische Einstieg über das Puzzle soll das Eis brechen und Boden bereiten. Wenn es auch anders möglich ist … bitte.

Ihr habt Ideen, Vorschläge, Erfahrungen, wie Ihr Euren Ansatz verkauft? Ich nehme das gern mit auf.

Wenn Ihr es selbst ausprobieren möchtet und unsicher seid, wie es nun wirklich läuft: einfach Kontakt aufnehmen.

Am Ende des Tages

Natürlich geht auch Wasserfall – bspw. im V-Modell. So richtig schön mit Grobkonzept, Feinkonzept und IT-Konzept. 12 bis 18 Monate Spec-Phase.
Dauert länger, kostet mehr und das Ergebnis ist keineswegs “sicher”.

Wenn es das ist, was der Kunde will und er dafür gute Gründe hat, dann gilt es zu überlegen, ob der Kunde zum Lieferanten passt.
Auch ein Ergebnis. Im Zweifel deutlich kostengünstiger zu erreichen als mit Water-Scrum-Fall und ein paar verkorksten Zwischen-Releases.