Was tun, wenn sich der Kunde und der Lieferant gegenseitig nicht verstanden und ernst genommen fühlen und sich der Konflikt verhärtet? In diesem Blog erfährst du wie man das Verhältnis vom Kunden zum Lieferanten retten und einen Mehrwert für alle Beteiligten schaffen kann.
Der Magic Round Table
Die Anforderungen sollen vor Beginn eines Projektes von den Kunden anhand eines Anforderungskatalogs der Lieferfirma mitgeteilt werden. Sie spezifiziert diese Anforderungen, dass es die Bedürfnisse vom Business befriedigt. Für Anforderungen gibt es klare Definitionen wie diese formuliert werden sollten: korrekt, eindeutig und verständlich. Um nur einige Merkmale zu nennen. Klingt alles ganz einfach – zumindest in der Theorie. Auch soll der Kunde im Mittelpunkt stehen. Die zwei bekannten Vorgehensmodelle zur agilen Entwicklung «SAFe» oder «Scrum» setzten auf Kundenorientierung, respektive grosse Kundenzufriedenheit. Auch ganz einfach – zumindest in der Theorie. Was jedoch, wenn die Anforderungen vom Kunden nicht korrekt, eindeutig und verständlich formuliert wurden? Und der Kunde sich vom Lieferanten nicht verstanden und mit einbezogen fühlt?
Angetrieben, unsere agile Software-Entwicklung und kundenorientiertes Arbeiten zu verbessern, baten wir die Kunden an einen runden Tisch. Dies, ohne zu wissen wie sie mit unseren Ideen umgehen, und in der Hoffnung, die Wogen mit dem Kunden glätten zu können.
Aus der zu Beginn zurückhaltender und skeptischer Runde, mit Fragen was das Ganze bringen soll, wurde von Termin zu Termin eine engagiertere und lebendigere Truppe. Anforderungen und deren Spezifikationen wurden anregend diskutiert. Das Zusammenarbeiten auf menschlicher Ebene wurde besser und man konnte das Gegenüber dank direkter, offenere und mündlicher Diskussionen plötzlich verstehen und die Gedanken nachvollziehen. Anforderungsverifikation und fachliche Fragen liefen nicht mehr über das Management, sondern über eine direkte Ansprechperson, dem Requirements Engineers. Eskalationen via Management wurden weniger und die Zusammenarbeit machte gegenseitig überraschend viel Freude.
Iterative Anforderungsverifikation und -spezifikation
Um diesen Schwung und Motivation mitnehmen zu können, gemeinsam am Produkt zu arbeiten und nicht jeder für sich im stillen Kämmerchen, entstand mit der zusammengestellten Kunden-Gruppe unsere «User Group». Regelmässige User Group Meetings finden noch immer statt, so dass Meinungen aus mehreren Perspektiven erlangt, Anforderungen verifiziert, Mock-Ups gezeigt und ein gemeinsames Verständnis geschaffen werden kann. Lücken und Inkonsistenzen werden früh erkannt und können rechtzeitig geschlossen werden. Es wurde ein Gremium mit den Kunden geschaffen, mit einer offiziellen Rolle, welche der Requirements Engineer sein kann, der die Fragen bei den Kunden platziert und diese direkt mit ihnen gemeinsam verifiziert und weiter spezifiziert.
Requirements Engineering – mehr als nur Anforderungsanalyse
Die Funktion eines Requirements Engineers besteht nicht nur darin, Anforderungsmanagement und Spezifikationsdokumente sauber zu gestalten, sondern auch die richtigen Stakeholder zu erreichen und mit einzubeziehen. Zwischen den Parteien muss vermittelt und Kompromisse herbeigeführt werden. Mit seiner emphatischen Art und seinem Fingerspitzengefühl ist der Requirements Engineer auch Vermittler und Psychologe. Er kann sehr viel zu einer guten und produktiven Zusammenarbeit mit den Kunden beitragen und ist zuständig dafür, dass zwischen den Beteiligten das Eis gebrochen und keine Mauern, sondern Brücken gebaut werden.
