Breakpoint Wilson: Dem Kunden unsichtbare Dinge beschreiben

Richtige Kommunikation mit dem Kunden – so geht’s
Kommentare

Wie erklärt man seinen Kunden, was man in der Softwareentwicklung tut, wenn das meiste davon unter der Haube verborgen und somit für Außenstehende unsichtbar ist?

Was wir oft verkennen, ist, dass Softwareentwicklung (und daher die Kommunikation mit dem Kunden) unheimlich abstrakt ist. Dinge die wir produzieren, sind für unsere Kunden zunächst nämlich unsichtbar. In der Tat besteht unsere Aufgabe nicht darin, dass wir Programmcode produzieren; sollte das bisher deine Meinung oder die deines Vorgesetzten sein, dann müssten wir uns alle zusammen mal dringend eine ruhige Minute nehmen, um darüber zu sprechen.

Quelltext ist lediglich der Rohstoff unseres Produkts. Je weniger wir davon brauchen und dennoch zufriedenstellend ans Ziel gelangen, desto besser. Auch sonst unterscheidet sich Softwareentwicklung stark von anderen Dienstleistungen.

Greifbare Ergebnisse

Wenn der Schreiner ein Möbelstück aufbereitet und verbessert, ist das für den Kunden unmittelbar ersichtlich: der Schreiner hobelt und poliert das Holz auf. Er bestreicht das Schmuckstück sogar nochmal sorgfältig mit einem angenehm nach Nadelholz duftendem Öl.

Ohne ein Experte zu sein sieht der Kunde anschließend direkt, dass der Stuhl solide ist, dass er sich beim nächsten Mal ruhigen Gewissens auf statt durch den Stuhl setzen kann. Eine starke Kommunikation ist hier also nicht notwendig. Das Ergebnis kann buchstäblich für sich selbst sprechen. Mit Software klappt das leider nicht.

Software benötigt Fürsprecher

Softwareentwicklung ist wie Mathe: Unheimlich interessant, aber ohne Anwendungskontext relativ irrelevant.

Wenn wir in der Softwareentwicklung Werkstück zum Polieren bekommen, nennen wir das Refactoring: wir arbeiten das gute Stück nach bestem Wissen und Gewissen wieder auf. Wir finden Soll-Bruchstellen, optimieren Teile und ölen mit Hingebung das Schriftbild. Analysen und Refactorings machen vielen Softwareentwicklern sogar richtig Spaß! Doch in der Regel werden wir beauftragt, Features zu entwickeln, damit lösen wir die Herausforderungen unserer Kunden. Das ist unsere hauptsächliche Aufgabe, und genauso wird ein Kunde es bewerten.

Softwareentwicklung ist vergleichbar mit Mathematik: Unheimlich interessant! Bloß: ohne Anwendungskontext sind beide gleichsam relativ irrelevant. Bei Informatik und Mathematik auf hohem, wissenschaftlichen Niveau sieht das eventuell nochmal etwas anders aus. Der Vergleich wird trotzdem klar: Wo kein Kunde mit Herausforderungen, da kein bezahlter Auftrag zur Softwareentwicklung.

API Summit 2017

Moderne Web APIs mit Node.js – volle Power im Backend

mit Manuel Rauber (Thinktecture), Sven Kölpin (Open Knowledge)

API First mit Swagger & Co.

mit Thilo Frotscher (Freiberufler)

Kommunikation als Bringschuld

Wir erzählen unserem Kunden also mit stolzer geschwellter Brust, was wir alles Tolles getan haben. Von den Standards, die wir alle eingehalten haben, den verrückten neuen Bibliotheken, und bis zu welchem Level wir die Datenbank normalisiert haben. Doch am Ende läuft es oftmals auf dieselben Kunden-Reaktionen hinaus: „Das lief vorher doch auch!“, „Können wir was sehen?“ oder „Können wir nicht lieber noch ein Feature machen?“.

Wie unverschämt, nicht wahr? Wie können Kunden nur unser Genie nicht erkennen? Die harte Arbeit nicht wertschätzen?

Ganz einfach: Weil es unsere Aufgabe ist, es dem Kunden auf eine für Ihn verständliche Weise zu vermitteln! Denn würde er das alles von vornherein verstehen, dann wäre er selbst vermutlich auch Experte in der Softwareentwicklung und bräuchte uns dafür gar nicht.

Kunden unsichtbare Dinge beschreiben

Die virtuelle Natur unserer Arbeit stellt uns vor besondere Herausforderungen in der Kommunikation.

Nun ist der Titel dieses Breakpoints „Kunden unsichtbare Dinge beschreiben“. Es geht diesmal also eigentlich gar nicht um Refactoring – es geht darum, weshalb gute Kommunikation in der Softwareentwicklung so wichtig ist; wie wir den Wert unserer Arbeit der Welt kommunizieren. Warum es sogar unsere Pflicht gegenüber dem Kunden ist, ihm dabei zu helfen zu verstehen, was er braucht. Warum das, was wir tun, gut für ihn ist.

Kommunikation ist nicht zu verwechseln mit reiner Wellen-Modulation auf Sauerstoff: Quatschen. Auch nicht zu verwechseln mit kilometerlangen Management Protokollen: Faseln. Wir wollen Ergebnisse und Konzepte, die stofflich niemals existiert haben, in die Vorstellungskraft anderer Menschen transportieren. Die virtuelle Natur unserer Arbeit stellt uns dabei vor eine besondere Herausforderung. Im strukturierten Wesen unserer Arbeit hingegen liegt die Chance zu einer guten Kommunikation.

Optische Dokumentation

Ich verspreche, ich werde umgehend ein paar Euro in das Phrasenschwein werfen, aber es ist in der Tat so: Ein Bild sagt mehr als tausend Worte.

Menschen lesen nicht. Oder zumindest nicht besonders gerne. Die Tatsache, dass du den Breakpoint bisher hierhin gelesen hast widerspricht dieser Behauptung zwar, und trotzdem wirst du das kennen: Im Alltag liest kaum jemand aufmerksam Texte, die er oder sie nicht wirklich spannend findet. Es bleibt bei der schieren Masse E-Mails und sonstiger Kommunikation auch kaum genügend Zeit, alles aufmerksam zu lesen; der innere Schweinehund möchte viel lieber Katzen-Videos auf YouTube jagen.

Gerade bei abstrakten Themen lohnt es sich also, auf grafische Dokumentation zu setzen – Zusammenhänge können so unmittelbar nachvollzogen werden. Außerdem erkennen wir selbst relativ schnell, wenn die Dokumentation mittlerweile veraltet ist. Entwickler kostet es dann weniger Selbstüberwindung „mal eben“ ein paar Kästchen neu zu verbinden, anstatt sich einen gut leserlichen Text aus den Fingern zu saugen. Denn das Einzige, was für viele Menschen noch unangenehmer scheint als zu lesen, ist selbst zu schreiben. Kästchen ziehen können wir in der Regel alle gleichgut – und es macht sogar richtig Spaß!

Breakpoint Wilson: Kommunikation – Systemarchitektur-Diagramm

Backups? Failover? Systemarchitektur-Diagramme helfen dem Kunden, die Komplexität seiner Landschaft zu verstehen, potentielle Fehlerquellen und deren Lösungen selbst zu erkennen.

Mehr als Kästchen ziehen

Dabei muss es nicht immer ein sauberes und sehr exaktes UML-Diagram sein. Diese Notation ist vor allem etwas für uns, die Experten. Vereinfachte Entity-Relationship-Diagramme oder ähnliche Plots ähneln oftmals der Domäne, also dem Geschäft des Kunden; dort kennt er sich aus. Außerdem fällt Kunden hier erstaunlich oft selbst auf, dass ihr vermeintlich einfaches Geschäftsmodell mittlerweile doch zu einem recht umfangreichen Prozessgeflecht geworden ist. Das erzeugt erfahrungsgemäß Verständnis für die technische Komplexität, in der wir softwareentwickelnde Menschen uns oftmals wiederfinden. Ansonsten gilt nämlich immer noch in den Köpfen vieler Menschen, dass Computer alles und dazu noch alles ganz einfach können.

Noch besser als selbst Kästchen zu ziehen, ist es natürlich, wenn wir Wege finden, Belege und Dokumentationen automatisch zu generieren. Für die gängigsten Sprachen lassen sich in der Regel relativ schnell Analyse-Werkzeuge finden, die Ihr Ergebnis grafisch dokumentieren. Der Output ist je nach Projektgröße immer noch ziemlich Abstrakt. In der Regel kommt es dem Kunden sowieso nur darauf an, einen groben Überblick über Mengen und Zusammenhänge zu bekommen – mit den tiefen, technischen Details vertraut er uns schließlich. Nun können wir auf dieser Grundlage dem Kunden weitere Informationen an die Hand geben, so dass unsere Entscheidung besser nachvollziehen kann und entsprechenden Aufwänden zustimmt. Beispielsweise wenn es darum geht, warum ein Versionswechsel des Frameworks schwieriger wird als man vermuten mag.

Breakpoint Wilson: Kommunikation – Dependency Wheel

Automatisch generiertes Dependency Wheel einer komplexen Angular-1-Anwendung: Hohe „Fadendichte“ verdeutlicht in der Regel schnell, wo Handlungsbedarf herrscht und sich Aufwände verstecken.

So lassen sich auch technische Schulden einfach in menschlich verständlicher Bildsprache ausdrücken: Menschen können sehr gut Chaos von Struktur unterscheiden. Menschen verstehen in der Regel auch, was daran geknüpft ist. Handelt es sich Beispielsweise um ein zentrales Element mit vielen Verbindungen, liegt es nahe, dass Änderungen oder Wegfall dieses Elements entsprechenden Aufwand bedeuten werden.

tl;dr

Höhlenmenschen entwickelten Sprache und Kommunikation vermutlich dadurch, dass sie auf Dinge zeigten und Geräusche dazu machten. Dinge, auf die man leider nicht mehr zeigen konnte, wurden als Höhlenmalerei aufbereitet – dann konnte man wieder darauf zeigen.

In der Softwareentwicklung können wir in der Regel auf nichts zeigen, und unsere Geräusche verstehen nur andere Softwareentwickler. Nehmen wir uns also ein Beispiel an unseren Vorfahren und beginnen zu Gunsten aller Beteiligten, mehr grafisch zu dokumentieren.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -