Soft-Skills als Software – Developer – Teil 1 1


Verbreitet die Message!

Das Bild des Software-Entwicklers hat es leider etwas schwer. Was wir eigentlich tun, ist nur für wenige Eingeweihte klar. Manager fragen sich, wofür sie uns eigentlich bezahlen und auch für alle Anderen ist kaum greifbar was vor den Tastaturen vor sich geht. Sind wir Technik-Freaks, die jede Interaktion meiden und uns hinter unserem Bildschirm wegducken? Besteht unser Beruf nur daraus, wie ein immer an den Computer gebundenes Code-Vieh möglichst viel Code auszuspucken und umzusetzen, was Andere uns vorgeben?

Soft-Skills matter

Soft-Skill* ist ein Buzz-Word, dass die “weichen” Skills einer Fachkraft umschreiben soll. Dazu zählen Kommunikations- und Teamfähigkeit, Sozialkompetenz, aber auch persönlichste Dinge wie Selbstvertrauen, Belastbarkeit und Kritikfähigkeit.

Doch als Software-Developer geht es schließlich darum Code zu schreiben und nicht sich auf tolle Art auszudrücken, oder? Müssen wir da wirklich unsere Sozialkompetenz schulen?

Ich bin der Meinung: Ja, absolut. Software-Entwicklung ist ein Themengebiet, das hoch komplexe, abstrakte und technische Inhalte umfasst. Gerade deshalb ist es absolut nötig, sich immer auf das Gegenüber einzustellen, die eigene Arbeit zu erklären und die technischen Bedingungen für das Projekt mit dem Kunden auszuhandeln, denn: Der Developer ist nicht der Entscheider. Der Entscheider ist letztendlich immer der Kunde, der in seiner Not teure, studierte Fachkräfte wie uns bezahlt, weil er in der Zeit der Digitalisierung nicht anders kann.

Man weiß jedoch schon länger, dass es vom Kunden (Stakeholder & Product Owner) kaum erwartbar ist, dass er ein Dokument, wie eine fachliche oder technische Spezifikation, erstellt, aus dem ersichtlich ist, welche Anforderungen und Vorstellungen er genau hat. Es ist auch nicht möglich, in einem einzelnen Treffen, wie einem Kickoff-Meeting alle Spezifikationen (das heißt Vorstellungen und Wünsche) zu klären. Kundenorientierte Software-Entwicklung ist Kommunikation. Und der Kunde hat eine ganz eigene – nicht technisch geprägte – Sicht auf sein Produkt, ganz im Gegensatz zum Developer. Deshalb müssen wir sehr gut darin werden, diese Kommunikationslücke zu schließen.


* Ausschließen möchte ich in diesem Artikel explizit alle methodischen Kompetenzen (Analytische Fähigkeiten, Selbstorganisation) und hier auf Soziale und Selbstkompetenzen eingehen.

Perspektivwechsel und Kommunikation in der richtigen Sprache

Nehmen wir folgendes Szenario an: Eine bereits vorhandene Spring-MVC Anwendung des Kunden soll weiterentwickelt werden und die IT-Abteilung des Kunden stellt die Anforderung javascript-Code möglichst zu vermeiden, weil dieser nicht zu ihrem Technologie Stack passt und die Abteilung die Kompetenzen nicht in ihrem eigenen Team hat. Zusätzlich sieht der “Head of It” javascript als schlecht wartbar an.

Wird nun in einem Meeting vom Kunden gewünscht, dass bei der Benutzung einer Web-Oberfläche nach Eingabe einiger Daten eine Validierung vorgenommen werden soll – beispielsweise beim Verlassen eines Input-Feldes – muss der Software-Entwickler klarstellen, was genau hier gemeint ist. Dem Software-Entwickler ist klar, dass die Validierung sowohl Client-seitig (mittels javascript) als auch Backend-seitig (mittels Java) möglich ist.

Der Software-Entwickler muss hier nun erst einmal nachhaken, wie die Vorstellung der Person aussieht, die diese Anforderung stellt. Es bietet sich an, hier ein Use-Case-Beispiel durchzugehen, und im Detail zu klären, wie die Funktionalität aussehen soll: 

Developer: “Wenn der User dann seine Eingabe in das Länderfeld macht und aus dem Feld heraus klickt, könnten wir in diesem Moment die Eingabe überprüfen und diese rot markieren. Stellen Sie sich das in etwa vor?”.

Fachbereich: “Ähm, ja so wie bei Anwendung XYZ”

Developer: “Gut, um es so zu gestalten gibt es zwei Wege: Wir können das direkt im Browser umsetzen oder erst nach einer Abfrage an den Server. Letzteres hat ein Neu-Laden der Seite zu Folge. Das bedeutet, dass man nach einem Input relativ lange warten muss und die Seite kurze Zeit pausiert. Ich bevorzuge deshalb die erstere Variante, da es hier keinen Refresh gibt und dieser die Usability und Performance sehr einschränkt. Dafür müssten wir jedoch javascript in irgendeiner Form verwenden.”

IT-Abteilung: “Wir wollen Javascript vermeiden.”

Die IT-Abteilung diskutiert nun mit dem Fachbereich die Vor- und Nachteile beider Ansätze. 

Wir als beratende Developer können Kompromisse für beide Seiten – die beide unsere Kunden sind – anbieten: Wir können vorschlagen, nur minimale technische Validierung auf javascript Ebene durchzuführen und eine größere Validierung mit Business-Logik Anteilen im Backend durchzuführen. Zusätzlich können wir anbieten, Out-Of-The-Box Lösungen wie Angular zu verwenden, oder den Code mit Javascript-Testframeworks (wie Jasmine) durchzutesten und klar machen, dass diese Lösungen durchaus wartbar sind.

Aus meiner Sicht ist hier der Developer gefordert sein Wissen zu benutzen, um eventuelle Probleme zu erkennen und kurz und knapp auf den Punkt zu bringen. Der Developer ist in der Verantwortung sicher zu stellen, dass der User das Produkt annimmt. Gleichzeitig muss er aber seinen Kunden zufrieden stellen. Deshalb ist es seine Verantwortung mit seinen Usern bzw. dessen Vertretern in Kontakt zu treten und mit ihm für den User das beste Produkt auszuhandeln. Dies erfordert Einfühlungsvermögen und Fingerspitzengefühl. (siehe Scrum, User Stories)

Noch einmal: Dem Kunden ist vollkommen egal, was Backend- und Frontendseitig passiert – er weiß wahrscheinlich nicht einmal genau, was das ist. Dem Kunden sind an dieser Stelle eher andere Dinge wichtig, wie bspw. Performance, Maintanability und Usability. Mit diesem Augenmerk muss also kommuniziert werden!

Und mit den Kollegen?

Ein weiterer entscheidener Perspektivwechsel tritt auch auf, wenn man statt mit dem Fachbereich mit den eigenen Kollegen (im Entwicklungsteam) spricht. In einem (guten) Software-Entwicklungs-Teams sind Kompetenzen unter Spezialisten verteilt. In meiner Vorstellung sehe ich mein Team spaßhaft wie ein Team aus Superhelden: “Mr. Persistence” ist der Datenbank-Held , “Service-Man” der Backend-Profi, “Goodlucks” der Frontend-Experte und “Dr. Brain” der Allrounder, der den Master-Plan im Blick hat. 

Team-intern sollte man diese durch die Kompetenzen der anderen geprägten Sichten immer im Auge behalten. So wird ein Datenbank-Experte vielleicht oben geschildertes Problem nicht wahrnehmen, jedoch aber einen sehr genauen Blick auf die Datenmodellierung und den Datenfluss werfen. Von Developer zu Developer kann es oft passieren, dass man versucht Unwissen zu verschleiern – schließlich haben wir alle studiert und sind fähige Entwickler, richtig?
Nun ja, wir sind besonders dann richtig gut, wenn wir direkt heraus sagen können, was wir nicht verstehen, nachhaken und uns festbeißen, bis wir verstehen was der andere meint.

Software-Entwicklung ist sehr abstrakt und extrem umfangreich, deshalb ist es keine Schande etwas nicht zu wissen – schade ist jedoch, wenn man gehemmt ist, das auch zuzugeben.

In diesem Kontext sollte man schauen, dass man nicht die Spezialitäten seiner eigenen Vertiefung und seines eigenen Erfahrungsschatzes vorraussetzt. Stattdessen ist es sehr fruchtbar, eigene Sichten zu erklären, zu erklären was genau man verstanden hat, Fragen zu stellen und sich zu bemühen, die andere Perspektive zu hören. Die Frage: “Verstehst du, was ich damit meine?” wirkt ebenfalls Wunder.

Keine Arroganz gegenüber Fachfremden

Eine Krankheit unter Developern ist leider eine gewisse Arroganz (The Clean Coder). Arroganz meint hier die Einstellung, dass die eigene Sicht, die eigenen Bedürfnisse und die eigene Wahrheit mehr wiegt als die der anderen. 

Developer sind oft in einer Position, in der sie mit Menschen sprechen, die keine Vorstellung davon haben, wie ihre Arbeit aussieht, aber gleichzeitig mehrere große Probleme gleichzeitig lösen wollen. Beispielsweise muss ein ganzer Workflow abgebildet werden, ohne diesen zu unterbrechen und das effizienter als zuvor, mit gleichen uralten Datenquellen und Quellsystemen. Dabei soll die Lösung gut aussehen und bessere Usability bieten.

Die Kommunikation zu Fach-Fremden läuft oft ernüchternd ab: Nach einiger Erklärung der Rahmenbedingungen und dem vorsichtigen Umschiffen der schlimmsten Fachbegriffe werden Entscheider-Augen leer und trüb, aus ihrem Mund ertönt ein schwaches, gedankenverlorenes “Hm” nach jedem Satz. Am Ende vieler offener Diskussionspunkte kommt die Frage, ob man die Buttons auch in grün anzeigen könne..


Üblicherweise muss man seinem Gegenüber als Software-Entwickler subjektiv empfunden unglaublich viel erklären. Dinge, die in unserer Welt selbstverständlich sind, sind für den anderen “Neuland”. Das liegt aber sicherlich nicht daran, dass alle Nicht-Developer Idioten sind, sondern dass unsere Tätigkeit sehr abstrakt und die Lernkurve flach ist. Es braucht einiges an Rundumwissen – fast schon eine IT-Intuition – um ein Grundverständnis aufzubauen. 

Oft wirkt es für uns, als ob die Fachfremden ganz eigene für uns merkwürdige Gedankenstrukturen, Anforderungen und Probleme haben. Gleichzeitig haben die Vertreter des Fachbereichs meist überhaupt keine Vorstellung davon, was genau wir eigentlich tun und wie unsere Gedankenstrukturen aussehen. Diese Kombination führt oft dazu, dass sich die Kommunikation anfühlt als säße man in einem dunklen Raum und würde versuchen in zwei unterschiedlichen Sprachen miteinander zu kommunizieren.

Es ist sehr einfach, arrogant über andere hinweg zu gehen – zum Erfolg im Sinne einer gelungenen Kommunikation führt dies jedoch nicht. Und wie oben erläutert gilt: Erfolgreiche Kommunikation bedeutet erfolgreiche Projekte. Es braucht Geduld und den Willen dazu, die Kommunikationslücke zu schließen sowie die bequeme Position der Arroganz loszulassen. Software-Entwicklung geschieht nicht um seiner Selbst Willen, sondern immer, um die ganz speziellen Probleme und Schmerzen unserer Kunden zu lösen.

Zwischenfazit

Ich habe in diesem Artikel beleuchtet, warum es gerade als Software-Developer entscheidend ist gute Soft-Skills zu besitzen und bin auf die Fähigkeit des Perspektivwechsels und Kommunikation in der richtigen Sprache eingegangen und habe motiviert etwaige Arroganz zu überdenken und mit Einfühlungsvermögen und Berufs-Ethos zu ersetzen.

Hier noch einmal eine stichpunktartige Zusammenfassung:

  • es existiert eine große Kommunikationslücke zwischen Developern und Nicht-Developern
  • deshalb kann es eine Spezifikation, bei der eine Kommunikation minimiert wird, nicht geben
  • der Developer ist der Dienstleister, deshalb muss er sich bemühen die Kommunikationslücke zu überbrücken
  • dafür ist ein Perspektivwechsel nötig:
    • vermeide Fachbegriffe, von denen du nicht 100% sicher bist, dass dein Gegenüber sie versteht, wie du sie verstehst
    • erkenne die Bedürfnisse und Nöte der Person, mit der du kommunizierst und gehe auf diese ein
    • wiederhole was du verstanden hast und frage nach, wenn du etwas nicht verstanden hast
    • erläutere Use-Cases aus Nutzer-Sicht
  • auch Developer haben unterschiedliche Spezialisierungen, vermeide nur deine Spezialisierung anzuerkennen
  • erkenne Arroganz als Bequemlichkeit an und lege sie mit Geduld und Einfühlungsvermögen ab

Im Nächsten Artikel erfahrt ihr weitere Soft-Skills sowie wichtige Referenzen zu besserer Kommunikation.

Verbreitet die Message!

Schreiben Sie einen Kommentar

Ein Gedanke zu “Soft-Skills als Software – Developer – Teil 1