Oder 10 gute Gründe, wieso eine gemeinsame Sprache für die Produktgestaltung essentiell ist.
Stellen Sie sich vor, Sie besprechen die nächste Version Ihres Produktes und jeder versteht etwas anderes. Ich bin sicher, dass Sie davon schon gehört haben. Ansonsten empfehle ich Ihnen die Geschichte von Peter Bichsel «Ein Tisch ist ein Tisch» [1]. Sie handelt von einem Mann, der allen Dingen neue Namen gibt, wodurch er von den anderen nicht mehr verstanden wird. Vielleicht kennen Sie das auch aus eigener Erfahrung und haben Missverständnisse auf Ihrem Vorhaben sogar schon selber erlebt.
Hier ein paar klassische Beispiele aus meiner persönlichen Erfahrung:
- Verzögerungen, weil man mit der Entwicklung nicht zufrieden war und Dinge noch ändern musste, bevor man diese dem Kunden ausliefern konnte («Das haben wir aber nicht so gemeint», «So wollten wir das nicht», «Das geht ja gar nicht»).
- Unzufriedenheit beim Kunden, weil die Lösung nicht seinem Bedürfnis entsprach.
- Grabenkämpfe z.B. zwischen Business und IT: Wer Recht hat, «Fingerpointing» und «Cover my ass» Mentalität
- Einzelkämpfer und Unverständnis anderen Rollen gegenüber («Ja muss ich denn alles selber machen hier», «Keiner weiss, wie’s geht, ausser mir», «Das von den anderen kann man ja nicht brauchen»).
Es muss ja nicht so in extremis enden wie bei Peter Bichsel. Aber um die eigentlichen Ziele wie z.B. Time to Market und kundenzentrierte Produkte erfüllen zu können, ist es nötig, dass sich die Beteiligten verstehen und nicht nur meinen, sich zu verstehen. Zwar hat jede Domäne ihre eigene Sprache, aber genauso wichtig ist es, dass sich ein Produktteam die Sprache des Produktes aneignet und entsprechend kommuniziert. Es gibt meistens noch genug Unbekanntes, welches es zu bewältigen gibt.
Der Fokus liegt hier auf dem alltäglichen Gebrauch der Sprache. Es nützt nichts, wenn zu Beginn einmalig ein Glossar erarbeitet wird, welches dann im Intranet / Archiv verstaubt und niemand mehr weiss, was aktuell gilt. Vielmehr soll das Glossar ein dynamisches Gut sein, welches sich auch mit dem Wissenstand weiterentwickelt und somit lebt.
Häufig wird eine solche Dokumentation zu den Begriffen sehr geschätzt, wenn neue Mitglieder ins Team kommen, aber oft ist es auch von erstaunlichem Nutzen, wenn «alt gediente» Mitglieder die Ausrichtung der momentanen Arbeiten damit überprüfen können. Dabei können folgende Fragen bei der Auswahl der zum jetzigen Zeitpunkt richtigen Arbeiten helfen:
- Sind wir noch auf dem Weg zum eigentlichen Ziel?
- Hat sich die Ausgangslage verändert und müssen unsere «Möbel» - um bei Peter Bichsel zu bleiben - angepasst werden?
Sogar noch mehr: Diese Tätigkeit hilft auch, die Bedeutung der Wörter aktuell zu halten, bereits feine Unstimmigkeiten zu klären und das gemeinsame Verständnis im Produkt-Team somit zu gewährleisten.
„Ich kenne doch das mit dem Projekt-Glossar. Zuerst wird es erstellt und dann schaut es sowieso niemand mehr an, das ist schade für den Aufwand!“
Dies wird sich die eine oder andere Person denken. Ja, auch ich habe das schon erlebt. Aber man vergisst gerne, dass die Arbeit, die Begriffe zu klären, sowieso ansteht und wertvoll ist. Aneinander vorbei zu kommunizieren, kostet schliesslich auch Zeit, meist deutlich mehr als das Klären der Begriffe und es soll schon vorgekommen sein, dass dadurch Lösungen entwickelt wurden, die so niemand wollte.
Finanzfachleute wissen, wie viele verschiedene Umrechnungskurse es gibt. Falls jemand also von einem Umrechnungskurs spricht, muss aus dem Produkt-Kontext klar sein, welcher gemeint ist. Ohne diesen Kontext sind Missverständnisse sehr wahrscheinlich.
- Daher mein Tipp: Schaut auch die Begrifflichkeit in deren Kontext an.
Für mich gilt auch hier: Was hilft, ist zugelassen. Wieso also nicht mal ein Foto einer Klärungsdiskussion anfügen und dies als vollwertiges Artefakt zur Dokumentation anerkennen?
Weiter habe ich sehr gut Erfahrungen damit gemacht, Begriffe und ihre Zusammenhänge grafisch darzustellen. Damit wird auch schnell klar, wenn verschiedene Benutzergruppen Synonyme aber auch Homonyme verwenden, ohne sich dessen bewusst zu sein.
Beispiel: Grafisches Vokabular
Bei einer graphischen Darstellung ist es denn auch sofort ersichtlich, dass mein (Arbeits-) Tisch vor allem Beziehungen zu Werkzeugen hat und daher wohl kaum dasselbe wie der (Ess-) Tisch eines andern Teammitgliedes ist, der dann vor allem Beziehungen zu Geschirr und Besteck hat.
Je weiter Produkt-Teams in ihrer sogenannten Teammaturität sind, desto unterschiedlichere Arbeiten, Verantwortungen aber auch Gestaltungsspielräume werden vom Team übernommen (siehe auch unser Product Engineering Poster ).
Daher erstaunt es auch kaum, dass die daraus resultierenden zusätzlichen Arbeitsbegriffe in der Produktsprache Verwendung finden müssen. Ein Teil des Vokabulars der klassischen Rollen ist somit auch im Produktteam von Belang. Daher muss dieser Teil fürs ganze Team verständlich sein und in der Produktsprache aufgenommen werden.
Die klassische Expertensprache wird ggf. in einer Gilde oder Zunft angewendet. Dort wiederum ist das auch richtig, da sie die gemeinsame Sprache dieser Experten ist.
Wie erlange ich nun die Fähigkeiten, eine solche Produktsprache aktiv mitzugestalten?
Generell sind dies die Skills die u.a. in Requirements Engineering Kursen vermittelt werden. Der Klassiker dabei ist sicherlich der IREB CPRE Foundation Level Kurs.
Mit der grösseren Verbreitung von agilen Methoden gibt es aber auch mehr darauf ausgerichtete Schulungen wie der IREB RE@ Agile Primer derselben bewährten und anerkannten Experten des IREB Komitees oder der iSQI Certified Agile Business Analysis Kurs.
Teammitglieder, welche über diese Skills verfügen, haben oft den Riecher für Missverständnisse und sind daher sehr wertvoll, wenn das Nachfragen geschätzt wird.
Hier noch meine Empfehlung, wie die aktive Anwendung der Produktsprache gefördert werden kann:
- Fundierte RE-Skills sind im Team vorhanden und werden angewendet
- Beziehungen der Geschäftsobjekte werden graphisch dargestellt, um Zusammenhänge aufzuzeigen und Missverständnisse zu vermeiden
- Direkte Kommunikation mit allen Teammitglieder in einer offenen Atmosphäre, welche das Nachfragen zur Klärung von «Selbstverständlichem» fördert
Für Fragen zur Produktgestaltung, zum Vorgehen im Produkt Engineering und auch zur Teammaturität stehen Ihnen die Mitglieder unserer Produkt Engineering-Gilde kompetent Red und Antwort. Dies kann auch gerne als Brown Bag Lunch gestaltet werden. Treten Sie dazu mit uns in Kontakt via Telefon +41 43 288 88 40 oder [email protected]. Wir helfen Ihnen gerne weiter!
Quellen:
[1] «Ein Tisch ist ein Tisch», Kurzgeschichte von Peter Bichsel - nicht nur für Kinder! Erschienen im Buch Kindergeschichten (suhrkamp taschenbuch 2642, ISBN: 978-3-518-39142-6), die zweite Geschichte (siehe https://books.google.ch/books?id=nCs8CgAAQBAJ&lpg=PP1&hl=de&pg=PT4#v=onepage&q&f=false )
