Guter Kunde, schlechter Kunde – Product Owners Glück und Leid in agilen Zeiten
Das richtige Paradigma
Wenn wir nur so gut Software und Systeme wie Häuser bauen könnten. Nein, wie ein gut gepflegter Garten- so sollten wir entwickeln. Halt, unsere Systeme sollen schon wachsen, aber die sollen auch gleich verkaufbar sein, also einen Wert stiften. Also besser, erst einmal einen Roller entwickeln, dann ein Motorrad und dann ein Auto. So sind doch erfolgreiche Produkte entstanden. Oder?
Die Quadratur des Kreises
Es kommt der Quadratur eines Kreises gleich, wenn man nach einer Metapher für seine System- und Softwareentwicklung sucht. Der Kreis denn man selber macht, der wird aber immer einmalig bleiben. So einmalig wie die Nutzer und Anwender, oder die Käufer und Berater, die oft stellvertretend für Nutzer, Anwender, Administratoren und Customizer, um nur ein paar der üblichen Stakeholder aus dem nahen Produktnutzungsumfeld zu nennen, stehen.
Oft subsumiert man diese Gattung von Stakeholdern unter der Begrifflichkeit “Kunde” und der modernen Auffassung vieler Management Consulting Agenturen nach, ist dieser “Kunde” der Schlüssel zum Erfolg. Ja, diese “Voice of the Customer” verstehen und ihm dann ein Produkt kredenzen, das passt. Blöd nur, so erzählt man sich hinter vorgehaltener Hand, dass auf den Wegen durch die Produktentwicklung auf einmal diese “Voice” leiser wird, falsch verstanden wird, übertönt wird!
Aber dem Product-Owner-Ingenieur ist nichts zu schwör!
Agil werden hilft, andere machen es und sind unisono erfolgreich. Naja, manche sind erfolgreicher damit, schneller zu erkennen, dass sie nicht erfolgreich sein werden. Das ist schon mal besser, aber wenn man immer nur schnell erkennt, dass es so dann doch nicht geht…Prototyping ist halt nicht alles. (siehe dazu gegen-das-nicht-verstehen-scrum-richtig-agil-machen/ )
OK, jetzt kommen wir darauf, es muss doch auch an diesen Anforderungen liegen, die “Voices” des Kunden kommen nicht durch. Oder kommen durch und sind- falsch! Klar, das zermürbt das technologisch versierteste Team, wenn immer am Markt vorbei entwickelt wird.
An die richtigen Anforderungen kommen
Aber Abhilfe ist unterwegs. Wir zertifizieren uns alle zum Requirements Engineer. Gar nicht schlecht, weil es bleibt was hängen, das Anforderungsmanagement klappt, die Requirements werden mittels Frontloading und professionellen Tools beachtet!
Sind wir jetzt im Entwicklerparadies angelangt? Bester Prozess, beste Tools, die Entwicklungsmanschaft ist fit.
Ernüchterung tritt ein als erkannt wird, bzw. nicht wahrgenommen werden möchte, dass das Produkt jetzt nicht unbedingt so den erwarteten Einschlag bringt, bzw. Fehlermeldungen und Erweiterungswünsche in einer Fülle eintreffen, die einfach keine ausschweifenden Zufriedenheitsgefühle aufkommen lassen wollen.
Richtige Anforderungen – von schlechten Kunden
Liebe Produkt Manager, Product Owner, Kunden-Projektleiter, Anforderungsmanager auf Fach- und Entwicklungsseite. Tritt der obige Fall ein, so müssen wir ein wenig vor unserer eigenen Haustür kehren.
Trotz verfügbarer Methoden-Berater-Armada und halbjährlich neuem Methoden-Rüsseltier, das durch die Unternehmensdörfer getrieben wird, ist es das alte Kennen-, Können- und Anwenden-Spiel, das gespielt werden möchte, um zufriedenheitserzeugende Produkte an seinen Kunden bzw. seinen Markt bringen zu können.
Da die Menschheit seit Jahrtausenden Projekte betreibt, große, wie den Gizhe Pyramidenbau und kleine, wie die Ein-Mann-App- Entwicklung, können wir uns aus einer großen gefüllten Schatztruhe von Methoden und Techniken bedienen. Es gibt schon seit langem ein paar ziemlich schlaue Vorgehensweisen, die sich so oder so in allen halbwegs vernünftigen Vorgehensweisen wiederfinden lassen.
Eine möchte ich hier herausstellen, und dabei geht es mir vor allem um den Problemfall “schlechter Kunde”. Wir definieren hier “schlechter Kunde” als einen, der jetzt nicht gerade partnerschaftlich denkt, der gerne mal eigene Probleme in die Schuhe seines Auftragnehmers schiebt, der keine ethischen Probleme damit hat, sich bei Projektproblemen auf den hohen Sockel zu stellen und über die Unfähigkeit seines Auftragnehmers lauthals zu lamentieren. Neben dieser doch seltenen und leicht erkennbaren Kategorie gibt es auch etwas kompliziertere Spielarten. Diese könnte man als “Wolf im Schafspelz” , “150% Forderer” und den “All inklusive Forderer” bezeichnen.
Methode “Pflichtenheft” aus dem Ärmel ziehen
Wir müssen in diesem Fall die Methode “Pflichtenheft” aus dem Ärmel ziehen und anwenden. Es wäre fatal, würden wir in diesem Fall die Muster “Lastenheft ist gleich Pflichtenheft” oder “gemeinsames Anforderungsdokument” anwenden. Diese sind prinzipiel sowieso kaum empfehlenswert, außer man hat eine wirklich außergewöhnlich gute Kooperation und vertraut sich blind.
Das “Pflichtenheft” Muster wird helfen, dass wir auf Augenhöhe Verhandlungsposition beziehen. Selbst wenn wir große Teile aus dem Lastenheft, also dem kundenverantworteten Anforderungstopf, in unser Pflichtenheft übernehmen, ist es “OK”. Das Pflichtenheft ist der von uns in der Auftragnehmer- und Zuliefererrolle verantwortete Spiegel zum Lastenheft. Dieser verpflichtende Anforderungsschatz hat das eigentliche Vertragsgewicht. Allen seinen zum Kunden sichtbaren Teilen und den nur uns sichtbar gemachten internen Teilen, widmen wir unsere Entwicklungsanstrengung. Vorrausgesetzt die Hausaufgaben sind gemacht, Anforderungen wurde abgeleitet, bewertet und abgestimmt.
Eine Pflichtenheft-Kultur schaffen
Die Methode “Pflichtenheft” ist ein altes Kulturgut, es hat gesundende Wirkung auf den Entwicklungsprozess. Es kann in jeder Situation in einer Entwicklung eingesetzt werden, selbst wenn es anscheinend keine erkennbaren Grenzen gibt, Auftragnehmerrolle und Auftraggeberrolle sich nicht herausschälen wollen, kann man beide Anforderungsebenen aufbauen und durch geschicktes verantwortlich machen, die Früchte eines gut gelebten Anforderungsmanagements im Produkt ernten.
Im besten Fall wird aus dem “schlechten Kunden” dann doch noch ein Guter.
Bilder aus: "Karl Valentin beim Nervenarzt" (https://www.youtube.com/watch?v=QTToQ4Gpm3o)
Kategorien
Tags
Andreas Kreß
Kontaktieren Sie Andreas KreßThe Software Engineer Andreas Kreß has served in roles like start-up product owner and requirements team manager at critical customer projects in the tech industries. He is the inventor of a widely used SCADA tool and helped set up methods and engineering tool environments from Y2K IT projects over large federal fiscal software standardization programs to automotive autonomous driving components development. He is a connoisseur of many intimate secrets of the art of developing systems. His focus is on the more far-reaching methods and tools in regulated and security-oriented systems engineering.