Webdesign TYPO3 Duisburg Produktiv Killer Quelle Infoworld
In meiner Artikelreihe zu einer Präsentation über Produktivkiller bei Programmierern geht es heute um „Non programmer as manager„. Ich gehe einmal davon aus, daß es sich hier um die administrative Leitung einer Entwicklungsabteilung handelt. Auch hier kann man einen Vergleich mit einer Fußball Mannschaft machen. Selten ist ein Trainer nicht auch selber Spieler gewesen. Das ist auch nötig. Als Wasserball Spieler fand ich das auch bei Trainern sehr wichtig. Genau so sehe ich das auch im Developer Team. Aber bitte nicht auf der Position eines Managers. Hier ist ein Programmierer häufig zu verbohrt und kann nicht so gut über den Tellerrand blicken.
Es gibt für diese Teamaufstellung die Möglichkeit eine Struktur zu fahren, in der die technische Leitung auf andere Positionen delegiert wird. Hier gibt es dann den Lead Developer, der eine Art Vorarbeiter Position einnimmt. Genau in diesem Moment gibt es natürlich die hervorragende Möglichkeit ein Team in seinen Stärken zu erweitern und die neue Fachkompetenz des Managers zu nutzen. So zeigt sich immer wieder in der Praxis, daß Entwickler grundsätzlich Aufwände viel zu gering einschätzen. Später gibt es noch Artikel zu dem Thema „Macho Developers“ und „Cowboy Developers„. Kurz gesagt hat das auf der einen Seite sicherlich mit persönlicher Profilierung und auf der anderen Seite mit fehlender Selbstkritik zu tun. Aber hier ist auch ein Gruppendruck nicht zu unterschätzen und das Marketing läßt sich auch sehr gerne anlügen. Zurück zum Thema. Manager haben neben Führungsaufgaben für das Personal natürlich auch die wichtige Aufgabe Projekte in ihrer Ganzheit zu erfassen, zu verkaufen und umzusetzen. Dafür bekommen Sie natürlich Unterstützung durch Projektmanager und anderen Mitarbeitern. Und hier kann natürlich ein Nicht-Coder-Blickwinkel auch sehr viel Licht in dunkle Ecken bringen. Rücksprachen mit Entwicklern müssen in dieser Struktur stärker sein. Bei Coder Managern natürlich die Rücksprachen mit den anderen Abteilungen. Coder Manager verstärken oft eine falsche Zeiteinschätzung und unterschätzen auch andere Einflüsse, die das Projekt insgesamt beeinflussen. Sie haben ein ausgeprägteres In-Abteilungen-Insel denken. Weil sie von der Nerdinsel kommen. Hier sind die Stärken eines Nicht-Programmier-Managers gefragt.
Aber genau das kann auch völlig nach hinten losgehen. Wer Entwicklungsprozesse nicht kennt, am besten aus eigenen Erfahrungen, kann nur sehr schwer in laufende Prozesse eingreifen, ohne Schaden anzurichten. Und es ist hier das Potential gegeben keine Ahnung zu haben und sich dann einen Bären aufbinden zu lassen. Ein Non-Programmer-Manager muß also gute Lead Developer haben. Angenommen es wird entschieden eine neue Internetseite auf deutscher Sprache zu erst auszurollen. Und die Entwickler machen sich an die Arbeit, natürlich ohne fertigen Content und Seitenstruktur. Kurz vor Livestellung wird vom Marketing in einem Redlight Meeting entschieden, daß doch erst die Version für Russland zu Testzwecken online geht. Man hätte sich überlegt, daß man mit den Erfahrungen aus dem russischen Markt viel für Deutschland ableiten könnte und so natürlich Marktführer in Deutschland wird. „ist schon entschieden und von oben abgesegnet“ ist dann die Message, die einem jeden Dialog verwehrt. In dem Fall damals hatte das auch etwas mit Machtgehabe unter den Abteilungen zu tun. „Sind ja nur ein paar andere Grafiken, mehrsprachig ist die Seite ja eh schon“. Programmierer als Manager mit einem Schuß Cowboy und Macho in sich stimmen dem auch bedenkenlos ohne Rücksprachen zu halten zu. Das ist ja nur eine Tabellenrelation. Nicht-Programmierer-Manager hingegen können hier über den technischen Tellerrand schauen und Probleme in Textlängen, Zahlungsmethoden und SEO erkennen. Abgesehen davon, daß man auch die Reaktionen im russischen Web in Form von Kommentaren nur schwer auswerten kann.
Nun kann man natürlich sagen, daß das Probleme von anderen Abteilung sind. Natürlich ist es leicht möglich, mit der russischen Sprache zu starten. Das ist ein Problem der Designer, wenn Headlines in Teasern und Buttons auf einmal 30% länger sind und auch die sprechenden URLs kann zwar keiner lesen, wird aber schon richtig sein. Hauptsache die Links gehen und das tun sie ja auch. Aber technisch wird im Bezug auf SEO, URL, Formulare etc. auch nicht alles nur durch das hinzufügen oder die Freischaltung einer Fahne passieren. Die erste Sprache im System ist die Base Language. Davon kommt man nicht mehr weg. Das ist auch sehr ungünstig.
Das Beispiel ist ein Paradebeispiel für eine komplett falsche Herangehensweise in dem vereinbarten Projektablauf. Die falsche Entscheidung kommt vom Marketing, daß hat bei der Gelegenheit einfach mal für die Technik entschieden und die „bahnbrechende Idee“ des russischen Testmarktes donnerstags mittags aus Langeweile ausgedacht. Man muß ja auch mal was entscheiden 😉
Wenn man sich dann die Arbeit der Programmierer anschaut, wird sich auch hier zeigen, daß sie an manchen Stellen in der Applikation nur den Fall „deutsch“ nutzen, da Prio 1 in dem gesamten Projekt der Relaunch Termin ist. Das traut sich natürlich keiner zu sagen. Mit dem Daumen wir 1 Tag länger eingeschätzt.
An diesem Beispiel kann man sicher viele Artikel der Blogreihe zu Produktivität von Programmierern ausmachen. Bleibt festzuhalten, daß es zu einem Projekt mehrere Ansichten oder Blickwinkel gibt, aus denen man hier ein Projekt betrachten kann. Gerade dieser Facetten Reichtum kann den entscheiden Mehrwert eines professionellen Teams bilden.
Fazit zu „Nicht Programmierer Managern in Entwicklerteams“
Entwicklerteams bestehen zu 100% aus Entwicklern. Wenn der Kopf der Abteilung auch noch einer ist, dann hat man eine völlig eigenständige Nerd Insel im Unternehmen geschaffen, aus deren Sicht alle anderen Abteilungen keine Ahnung haben. Langfristig wird das ein Unternehmen schwer belasten und kann es sogar zerstören. Ein Non-Programmer-Blickwinkeln ist also in der Teamstruktur einer Entwicklungsabteilung enorm wichtig. Hier muß aber die Verbindung zu den Entwicklern hergestellt werden. Das kann durch den Manager direkt passieren ist aber eher unwahrscheinlich. Ich finde weitere Blickwinkel sehr gut und befürworte „Non programmer managers“ gegenüber Entwicklern. Natürlich ist das ganze sehr personenabhängig.
Die Geschichte mit dem russischen Testmarkt ist leider nicht vollständig ausgedacht. Die Probleme, die daraus an den verschiedensten Stellen resultierten, haben enorm viel Anstrengung und Geld gekostet. Durch die Einnahmeverluste wurde am Ende das gesamte Projekt gefährdet. Es wurden viele Leute entlassen und der Frust zwischen den einzelnen Abteilungen bildet immer noch große Gräben in der Unternehmensstruktur. Die Leute, die für die Entscheidungen verantwortlich waren haben das Unternehmen verlassen, aber nichts daraus gelernt. Schuld waren für jeden Beteiligten die anderen und natürlich die Technik. Deren „Kein Problem“ Coder Manager hat dem Wahnsinn den letzten Segen gegeben und die Segel voll in Richtung Untergang gesetzt. Hier hätte viel mehr Verantwortung übernommen werden müssen.
