Letztens dachte ich noch, ich wüsste, was ein Kunde ist. „Das weiß doch jeder“, dachte ich. Und das obwohl ich es eigentlich besser hätte wissen müssen.
„Ein Kunde ist jemand, der einkauft!“, behauptet ein kleiner, naseweiser Christian in meinem Kopf. Und das stimmt auch. Irgendwie. Aber ganz so einfach ist es nicht. Ja, wenn ich im Supermarkt an der Kasse stehe, bin ich wohl ein Kunde. Aber wenn ich nach Hause gegangen bin, bin ich dann immer noch Kunde? Oder wenn ich vor dem Laden stehe und mir überlege, rein zu gehen? Vielleicht bin ich dann ja nur ein potenzieller Kunde oder ein Interessent? Ändert sich die Aussage, wenn ich eine Kundenkarte hab? Und was, wenn ich zwar noch nie hier, aber schon mal in der Filiale im Nachbarort eingekauft hab?
Offensichtlich ist die Frage, was ein Kunde genau ist, doch nicht so leicht zu beantworten. Und das hätte ich eigentlich wissen müssen, denn vor gar nicht allzu langer Zeit hab ich vier einstündige Workshops abgehalten, um genau solche Begriffe zu klären und zu definieren.
Kommunikation ist wahrscheinlich das Schwierigste an der Softwareentwicklung. Technik ist selten der Grund, dass Projekte scheitern. Meist sind das eher Missverständnisse, fehlende Absprachen, unausgesprochene, falsche Annahmen und Ähnliches. Und Begriffe spielen dabei eine nicht unwichtige Rolle. Wenn ich „Kunde“ sage und mein Gegenüber versteht etwas anderes darunter als ich, haben wir schon das erste Missverständnis, das zu einem größeren Problem heranwachsen kann, wenn wir es nicht auflösen.
Solche Missverständnisse gibt es andauernd und meist erkennen und korrigieren wir sie schnell. Wir können also trotz gewisser Unsauberkeit bei Begriffen miteinander kommunizieren. Meistens fällt uns das noch nicht einmal auf. Es gibt nur eben ein gewisses Risiko, dass man ein Missverständnis zu spät bemerkt. Zum zweiten machen dauernde kleine Missverständnisse, die man einen Satz oder zwei später wieder korrigiert, Kommunikation anstrengend und unproduktiv.
Im konkreten Fall hatten wir in einem Projekt, einen Service neu entwickelt und ein externes System, sowie einen verwandten Service angebunden. Diverse Stakeholder waren involviert. Dabei prallten diverse Begriffswelten aufeinander. Unsere Fachseite hatte bestehende Begriffe aus ihrer Arbeit. Unser Service sollte einen anderen Service ablösen, der natürlich auch gewisse Begriffe mitbrachte. Das externe System kam mit ganzen Satz an etablierten Konzepten, der andere interne Service hatte seine verwandten Konzepte und die EBI lieferte uns Daten, die unser Service einlesen musste und selbstverständlich hatten die EBI-Kollegen da auch wieder ihre ganz eigen Sprache.
Insgesamt ist nichts Schlimmes passiert. Das Projekt wurde erfolgreich abgeschlossen. Alle waren erstmal zufrieden. Es war aber offensichtlich, dass die ganzen uneinheitlichen Begriffe, die Arbeit nicht gerade erleichterten. Also machte ich mich daran, das Ganze etwas aufzuräumen.
Meetings im Allgemeinen und Workshops im Speziellen stehen und fallen mit der Vorbereitung. Ich wusste also, wenn ich einfach nur zu einem Meeting einlade und sage „lasst uns mal Begriffe klären“, werden wir zwar sehr lange, sehr intensiv reden, aber es würde nicht viel dabei raus kommen. Ich durchforstete also den Code, die Doku, die Schnittstelle und die Emails. Am Ende hatte ich einen ganzen Stapel an bunten PostIts. Das hat mich etwa einen halben Tag gekostet.
Um einen Begriff wirklich zu verstehen, braucht man i.d.R. zwei Dinge: eine Definition und ein Beispiel. Zum einen gibt es Leute, die eher knallharte Definitionen brauchen und es gewohnt sind in abstrakten Konzepten zu denken. Und es gibt natürlich auch die anderen, die sich mit Definitionen schwer tun und immer konkrete Beisiele brauchen. Der kleine naseweise Christian in meinem Kopf will schon zu einem Kurzvortrag zu abstract vs. concrete ansetzen, aber ich lasse ihn nicht. Es gibt zum anderen nämlich noch einen zweiten, womöglich gewichtigeren Grund: Mit den Beispielen können wir überprüfen, ob wir die Definition richtig verstanden haben.
Ich hatte also drei verschiedenfarbige Zettelarten in meinem Stapel: Begriffe, Definitionen und Beispiele. Nicht immer war alles vorhanden und genau das zeigte ein gewisses Problem: Manchmal gab es ein Konzept und mehrere Begriffe dazu und manchmal gab es Begriffe, die je nach Kontext etwas anderes bedeuteten. „Homonyme und Synonyme“ wirft gleich der kleine naseweise Christian in meinem Kopf ein. Und ja, genau solche gab es zuhauf. Außerdem gab es noch Konzepte, zu denen es noch keinen etablierten Begriff gab und Begriffe, die gar keine klare Bedeutung hatten.
Der nächste Schritt war dann die Begriffe zu clustern, denn manche Begriffe kann man nur im Kontext anderer Begriffe diskutieren. Oder man sollte das zumindest. Dann also alle relevanten Stakeholder eingeladen, kurz Motivation und Ziel erklärt und dann ging es los. Ich klebte also immer einen Cluster von zwei, drei, maximal vielleicht vier Begriffen bzw. Konzepten an die Wand und schon hatten wir Fokus zum diskutieren.
Synonyme aufzulösen, ist recht einfach. Normalerweise wird einer der Begriffe zum neuen Standard auserkoren und die Synonyme sind dann ab sofort deprecated und sollten nicht mehr verwendet werden. Wir sind ja hier nicht in einem Deutsch-Aufsatz, sondern wir wollen eine klare unmissverständliche Sprache und Synonyme sind da kontraproduktiv. Niemand soll sich überlegen müssen, ob „Rang“ und „Priorität“ jetzt das selbe sind oder nicht.
Homonyme sind schon schwieriger. Manchmal ist eine Definition (bzw. das eine Konzept) klar überlegen, d.h. viel weiter verbreitet. Dann kann das zweite, weniger wichtige Konzept einen neuen Begriff erhalten. Im Zweifel muss man aber beide Begriffe abschaffen und zwei neue unverbrauchte finden, um Unklarheiten auszuschließen. Letztendlich sollen Begriffe ja leicht richtig und schwer falsch zu verwenden sein.
Wenn man sowohl deutsche als auch englische Begriffe braucht (etwa weil der Code und vielleicht auch die Doku auf Englisch sind, während die generelle Unternehmenssprache eher Deutsch ist), braucht man natürlich auch für vielleicht nicht alle, aber doch viele Begriffe, eine kanonische Übersetzung. Auch hier bewahrheitet sich mal wieder, dass Begriffe kompliziert sind: Manchmal ist die englische Übersetzung doch nicht so klar wie gedacht. Besser also nochmal nachschlagen, selbst, wenn man meint, die Übersetzung zu kennen. Ich weiß zwar nicht mehr, bei welchem Begriff das so war, aber auch hier bin ich in die ein oder andere Übersetzungsfalle getappt, vor der mich nur das Nachschlagen bewahrt hat.
Wenn wir uns schon hinsetzen und Begriffe klären, dann möchte man das am liebsten ein für alle Mal für das ganze Unternehmen, für die ganze Softwarelandschaft tun. Und ja, das wäre schön, wenn das immer ginge. Auf jeden Fall sollte man danach streben, dass Entwickler und Fachseite die selben Begriffe verwenden. Aber je größer die Firma, je mehr Teams es gibt, desto schwieriger ist es, wirklich alles zu vereinheitlichen. Ab einer gewissen Größe ist das nicht mehr den Aufwand wert und vielleicht ist es auch gar nicht hilfreich
Um beim Supermarkt-Beispiel von oben zu bleiben: Für die Kassiererin ist ein Kunde nicht das selbe wie für die Marketing-Abteilung, die die Werbeprospekte druckt. Und die Leute, die Kundenkarten ausgeben haben wieder einen anderen Blickwinkel. Und das ist OK. Man muss nur klar definieren, wofür die Begriffswelt, das Domänenmodell, gilt und wofür nicht. Man definiert einen Bounded Context, den man klar absteckt und den man möglichst so definiert, dass die Schnittstelle zu anderen Kontexten schmal sind. „Guck dir mal Domain-Driven Design an!“, rät mir der kleine, naseweise Christian in meinem Kopf.
Resultat meines Workshops (oder eher meiner Workshops, denn es waren letztendlich vier einstündige Termine) war ein Glossar mit allen neuen Begriffen, Definitionen und Beispielen, allen alten Begriffen samt der Beschreibung, welche man in Zukunft verwenden soll, ein Diagramm, dass die Beziehung zwischen den wichtigsten Begriffen verdeutlicht und vor allem das Commitment aller Stakeholder, dass wir in Zukunft diese neuen Begriffe verwenden wollen, und die alten langsam aus dem Code rausrefactoren und im allgemeinen Sprachgebrauch nicht mehr verwenden wollen.
„Hast du gut gemacht!“, lobt mich der kleine, naseweise Christian in meinem Kopf und klopft mir virtuell auf die Schulter. Fast schon hätte ich mich über das Lob gefreut, aber dann setzt er hinzu: „War ja auch nicht so schwer. Das nächste mal suchen wir uns eine weniger triviale Aufgabe aus, nicht?“ *seufz* Ich glaube, das mit dem Loben muss ich dem kleinen naseweisen Christian in meinem Kopf noch beibringen.