Softwareentwicklung

de.buildblog.reflect – Die Kunst der egoreduzierten Softwarentwicklung II

Wie im vorherigen Teil angedeutet, gibt es da gewisse Probleme mit dem Ego des Programmierers, oder genauer mit Ego eines jeden Menschen. Bevor wir uns näher mit der Frage befassen, wie man das Problem nun reduzieren kann, sollten wir uns die Arbeitsumgebung des Entwicklers ansehen. Kurz: Der Programmierer und sein Team. Willkommen im fünften Teil meiner Serie über allgemeine Softwareentwicklung.

Der demokratisch organisierte Haufen

Langsam ist genau das Wort der Wahl. Der Demokratiehaufen verschwendet die meiste Zeit damit zu reden. Gerne auch über belangloses Zeug. Alles wird bis ins letze ausdisskutiert. Das schlägt nunmal auf die Performance. Dafür kann sich am Ende natürlich keiner beschweren. Außer vielleicht über den Informationsüberfluss. Allerdings will ich hier keineswegs behaupten der demokratisch organisierte Haufen hätte keine Daseinsberechtigung. Im Gegenteil. Denn der Punkt, dass sich am Ende keiner beschweren kann, ist ein großartiger Vorzug, der zu sehr ungeahnten Produktivitätsgewinnen führen kann. Die Akzeptanz von Projektzielen wird allein durch die Teilnahme an Zielbildungsprozess derart gesteigert, dass sich die ewige Rumdisskutiererei lohnen kann. Jedenfalls dann, wenn man sich nicht in Details verliert. Wenn die Disskussion sich um jede noch so kleine Klammersetzung dreht liegt das Problem mit hoher wahrscheinlichkeit an einer anderen Stelle. Es gibt nunmal Menschen, die sich nicht miteinander verstehen. Und damit alle beteiligten ihren Spaß daran haben streitet man sich um zu Streiten. Das Ego, als Selbstzweck. “Vermeiden”, heißt hier die Devise. Jedem vernunftbegabten Menschen - und programmierer sind darin eigentlich recht gut – sollte es möglich sein das einzusehen.

Mein Führer ich kann wieder laufen

Es gibt Leute die der Ansicht sind ein Team braucht eine straffe Struktur. Einer hält das Zepter in der Hand und diesem wird Folge geleistet. Wenn einer die Befehle gibt hat das durchaus seine Vorzüge. Ein Ansprechpartner, eine klare Ansage, keine Disskussion aber auch keine Verantwortung. Meiner Meinung nach ist Verantwortungslosigkeit, im Sinne, diese nach oben wegzudelegieren, Verantwortungslos, im Sinne Scheiße zu bauen. Es verspricht ein angenehmes Leben und sonst nichts. Daraus könnte man einen eigenen Programmierer Stereotypen bauen. Dieses Modell hat einen weiteren entscheidenden Nachteil: der Führer scheidet definitiv aus der Entwicklungsarbeit aus. Er hat ohnehin keine Zeit dafür. Es gilt Aufgaben zu deligieren über ALLES informiert zu sein, soziale Probleme aus dem Weg zu räumen und dafür zu sorgen, dass keiner pennt.

Dummerweise wird der “Führer” hin und wieder in die Verlegenheit geraten, oder je nach Menschenschlag, den Genuss kommen jemandem auf den Schlipps zu treten. Das kann sich als äußerst schädlich für das Projekt erweisen. In einem Team ist es von unschätzbarem Wert, wenn sich die Mitglieder aufeinander verlassen können, womit wir wieder bei den Vorzügen, des demokratisch organisierten Haufens sind. Wo jeder an der Zielsetzung beteiligt ist, wird der Einzelne eher bereit sein für das “große Ganze” einzustehen und letzlich auch eventuelle Fehler einzugestehen.

Doppelspitzen

Gerne. Aber nur dann, wenn diese sich entweder einig, oder die Kompetenzen klar aufgeteilt sind. Arbeitsaufträge ohne klare Richtung machen keinem Spaß. Weder der Doppelspitze von der sich jeweils ein Teil ignoriert oder hintergangen fühlt, noch den Befehlsempfängern die letzlich nicht wissen was sie mit welcher Priorität zu tun haben.

One Man Show

Die One Man Show ist häfig vor allem eines. Eine Show. Insbesondere, wenn es um Projekte geht, die ein einzelner nicht allein bewältigen kann sind die einzelnen darauf angewiesen zuverlässige Informationen zu erhalten. Die kann sich etwas schwierig gestalten, wenn jeder versucht, oder versuchen muss, selbst besonders gut da zu stehen. Tritt dieses Problem auf, wird die einzelarbeit zum Problem. Daher ist besonders in diesen fällen auf eine klare Arbeitsteilung zu achten. Und wenn jemand die Aufgabe hat für eine anständige Datenbankstruktur zu sorgen, dann bedeutet das eben auch, dass die Anderen genau so lange warten, bis diese fertig ist. Jedenfalls, wenn sie auf die Struktur angewiesen sind.

Leute Durchschleppen

Wenn man nicht gerade ein überaus sozialer Mensch ist, hat man da einfach keinen Bock drauf. In der Schule lässt sich das nie vermeiden. Im Entwicklungsteam schon. Wenn mehrere Menschen von einem Teammitglied abhängen bleibt nicht anderes übrig als dieses auszutasuchen, oder zur Schadensbegrenzung gleich komplett zu streichen, falls kein Ersatz vorhanden ist.

Motivationsgedöhns

Lobet den Herrn. Oder den Programmierer. Menschen sind geil auf sowas. Jemand der nicht gelobt wird, hat keinen Spaß an seiner Arbeit. Es ist ein schwerer Fehler einen Menschen unter Vernachlässigung seiner Menschlichkeit als “Humankapital” kalkulieren zu wollen. Ich halte es nicht für sonderlich erwähnenswert, dass Wertschätzung in der Arbeit und im Leben allgemein eines der höchsten Güter überhaupt ist. Diese Wertschätzung sinkt üblicherweise wenn Leute durchgeschleppt werden. Oder Anders gesagt: “Wir loben einen unbeteiligten” und setzen jene herab, die das Lob verdient und gebraucht hätten. Soetwas sollte man zu vermeiden wissen.

Sobald sich im Team zumindest ein kleiner Teil als Gruppe in ihrer Gesamtheit versteht sorgt der Sozialdarwinismus ohnehin für das Ausscheiden derer, die sich nicht in die Gruppe integrieren lassen. Jedenfalls in der Theorie. Zunächsteinmal führt das zum rapiden Abschwung in der Leistung der betroffenen.

Mit der Frage wie man denn jetzt genau einen Programmierer motiviert haben sich schon viele andere Menschen beschäftigt. Darüber hinaus ist das Thema umfangreich genug, um einen eigenen mehrteiligen Artikel darüber zu schreiben. Vielleicht später.

Soviel zu einem minimalistischen überblick über mögliche Arbeitsweisen im Team. Ich erhebe hier in aller Deutlichkeit keinerlrei Anspruch auf Vollständigkeit. Es geht lediglich darum aufzuzeigen, dass es unterschiedliche Arten von Gruppen gibt und Arbeitsweisen gibt.

Fortsetzung folgt…

© 2009 buildblog.