“Irgendwas mit Menschen”

von Beni

Ich vermute, wenn ich damals bei der Berufsberatung beim Arbeitsamt gesagt hätte, ich will “irgendwas mit Menschen” machen (statt “ich mag Mathe – was soll ich studieren”), hätte man mir nicht zum Informatikstudium geraten. Auch wer sich heutzutage für ein Studium oder einen Beruf entscheidet und gerne “irgendwas mit Menschen” machen möchte denkt vermutlich nicht gerade an Softwareentwicklung. Aber meine Erfahrung nach mittlerweile fast einem Jahrzehnt als Entwickler ist, dass die Interaktion mit Menschen – neben dem Programmieren – genau das ist, worauf es dabei ankommt.

Dabei meine ich nicht, dass man es auf Stackoverflow oder via Twitter mit anderen Menschen zu tun hat. Ich meine auch nicht das Gespräch an der Kaffeemaschine oder das Meeting mit dem Chef. Sondern tatsächlich Arbeit mit Menschen in Person von Angesicht zu Angesicht – direkte Kommunikation also, mit deren Qualität auch die Qualität des Arbeitsergebnisses steht und fällt.

“Wie kann das sein, wenn Entwickler doch hauptsächlich Code schreiben”, mag sich der ein oder andere jetzt fragen. Aber wer denkt, dass Softwareentwicklung sich nur auf Schreiben von Code beschränkt, hat da etwas grundsätzliches nicht verstanden. Natürlich schreiben Softwareentwickler auch Code – aber gerade im professionellen Umfeld tun sie das nur in den allerseltensten Fällen allein und im Reinraum.

Denn wenn mit Softwareentwicklung Geld verdient werden soll, ist es normalerweise nicht der Entwickler, der sich ausdenkt, was er als nächstes Entwickeln soll, sondern der Auftraggeber – sei es der Fachbereich in der eigenen Firma oder beim Kunden. Klar – ein gewisser Teil (je nachdem ob man eher agil oder eher wasserfallig unterwegs ist) ist in einer Art Spezifikation verschriftlicht. Oft ist es aber so, dass derjenige, der die Spezifikation schreibt, eine andere (domänenspezifische) Sprache spricht als der Entwickler. Das bedeutet, dass Unklarheiten und Missverständnisse normal sind, wenn man nur mit dem Dokument arbeitet. Hier ist es dann extrem wichtig, die Anforderungen direkt mit demjenigen zu diskutieren, der sie gestellt hat. Und genau hier kommt es darauf an, so kommunizieren zu können, dass die beiden Welten “Fachbereich” und “Entwicklung” einander auch verstehen. Scrum versucht diesem Umstand Rechnung zu tragen durch die Rolle des “Product Owner”, der viel unmittelbarer in den Entwicklungsprozess eingebunden ist. Beim Extreme Programming wird der “Onsite Customer” gefordert, um das Projekt zum erfolgreichen Abschluss bringen zu können.

Üblicherweise ist es dann ein Team das die Anforderungen umsetzt, da die Anforderungen meist zu umfangreich sind um von einer Person abgearbeitet werden zu können. Da gibt es dann außer den Entwicklern noch Tester, Projektleiter, Scum Master und Product Owner, manchmal auch Designer und Konzepter. Hier hat man es mit allen Beteiligten mehr oder weniger zu tun. Der Projektleiter muss in der Lage sein zu verstehen, wo das Projekt steht und der Entwickler muss ihm vermitteln können, warum “Kann man schon was sehen?” manchmal eine ziemlich dumme Frage ist. Entwickler und Tester können gemeinsam vor dem gleichen Bildschirm sitzend viel schneller ein komplexe Fehlerreproduktion durchführen als über ein Ticket-System. Der Scrum Master muss das Problem verstehen, das den Entwickler am Weiterarbeiten hindert, bevor er sich an dessen Beseitigung machen kann. Design und Konzept sollten eng mit der Entwicklung zusammenarbeiten, um frühzeitig die Realisierbarkeit der Entwürfe prüfen zu können.

Das alles geht natürlich umso effizienter, je kürzer die Kommunikationswege sind und natürlich auch je besser die Beteiligten in der Lage sind, miteinander zu kommunizieren. Und natürlich müssen sich auch die Entwickler untereinander austauschen – zum KnowHow-Aufbau, wie Anforderungen umgesetzt werden sollen, wo es sowas ähnliches im System schon gibt oder beim Pair Programming.

Ich kenne fast kein Projekt, in dem nicht Pair Programming zumindest punktuell nutzbringend eingesetzt werden konnte. Pair Programming bedeutet, dass tatsächlich zwei Entwickler gemeinsam am gleichen Bildschirm eine Anforderung umsetzen oder ein Problem lösen. Das heißt bei dieser Art der Zusammenarbeit hat man es nicht nur ab und zu zur Abstimmung mit einem anderen Menschen zu tun, sondern man sitzt im Zweifelsfalle den ganzen Tag gemeinsam vor dem Rechner und diskutiert Lösungen, Vorgehensweisen und Probleme. Vorzugsweise nicht immer mit der gleichen Person sondern möglichst oft mit unterschiedlichen Paaren. Für meine Begriffe ist das die Königsdisziplin in Sachen “irgendwas mit Menschen”.

Das sind zwar noch längst nicht alle Aspekte, wo man bei der Softwareentwicklung “irgendwas mit Menschen” macht, aber das soll mal genügen, um hier anhand von ein paar Beispielen verdeutlichen, dass das Klischee vom “Kellerentwickler”, der alleine vor sich hinprogrammiert einen völlig falschen Hinweis darauf gibt, welcher Typ Mensch als Entwickler geeignet sein könnte – und dass der Umgang mit Menschen ein zentraler und extrem wichtiger Bestandteil der professionellen Softwareentwicklung ist.

Thematisch verwandte Artikel: