Über Software-Entwicklung und Menschen.
1994 bekam ich meinen ersten PC, seit Ende 1999 bin ich u.a. als Software-Engineer in der IT-Branche unterwegs, seit 2005 als Freiberufler. Ich habe sehr viele unterschiedliche Unternehmen gesehen, einige US-Konzerne von innen gesehen (Amazon, Yahoo), einige Konzerne aus Deutschland (Allianz, 1&1, SAP) und ein paar kleinere Unternehmen (Verlage, ISPs, Autovermieter, E-Commerce).
Die Art und Weise wie entwickelt wird, wie Technologien eingesetzt und mit Menschen umgegangen wird, unterscheidet sich sehr. Natürlich dominiert in großen deutschen Konzernen eine sehr behördenähnliche Struktur, aber diese habe ich auch schon bei kleineren Unternehmen gesehen.
Was mir aber bis heute am meisten Kopfzerbrechen verursacht, sind die Umstände, die Projekte und Produkte scheitern haben lassen.
Gerade als Freiberufler bin ich sehr oft als Feuerlöscher unterwegs, nicht nur weil die Angestellten selbst keine Zeit haben, sondern weil es auch massive technische Probleme gibt. Die interessante Tatsache ist, dass oftmals ursprünglich ein Mitarbeiter eine sehr gute Entscheidung getroffen hat. Er war mehr oder weniger alleine verantwortlich dafür, damals mit einer neuen Technologie ein Problem zu lösen, ein Team zu formen und weiterzuentwickeln. Fast immer wird diese Person aber verbrannt, man trennt sich von ihr oder sie verlässt das Unternehmen.
Am Ende bleibt das Team übrig und die geschaffene Altlast. Es entsteht ein Vakuum in der Teamführung, oftmals kommt ein Teamleiter aus einem anderen Unternehmensteil oder gar von aussen hinzu, meist ohne die notwendige technische Sachverständnis zu haben. Und die Gründe warum die „Alpha“-Person das Unternehmen verlassen hat/musste, sind auch nicht ausgeräumt.
Häufig war die Organisation nicht reif genug für den eingeschlagenen Kurs. Das Management oder benachbarte Abteilungen konnten oder wollten sich nicht auf die Lösung einlassen, waren auch nicht unbedingt an einem Erfolg interessiert oder haben sogar aktiv daran mitgearbeitet, um diese eine „Alpha“-Person auszuschalten. Die Person selbst hat vermutlich alles gegeben, war nahe am Burnout oder sogar bereits im Burnout und hat daher freiwillig kapituliert oder wurde durch eine selbstverschuldete Blödheit entfernt.
War es klug, ursprünglich auf eine eine solche „Alpha“-Person zu setzen? Vermutlich nicht. Aber was wären die Alternativen gewesen? Technologischer Fortschritt ist enorm fordernd, kein Mensch kann dauerhaft „vorne mitspielen“ und sich mit allen Trends und neuen Konzepten auseinandersetzen, sie evaluieren und dann bewerten, ob eine Nutzung für das eigene Unternehmen sinnvoll erscheint oder nicht.
Fortbildungen im herkömmlichen Sinne sind hier nicht realistisch, es bleibt also alles an der Wissbegierigkeit und dem Einsatz des Einzelnen hängen, welche bei solchen „Alpha“-Leuten zumindest zu Beginn hoch sind. Manche, wie z.B.auch ich, fassen ihren Job eher als Berufung auf, nicht nur als 9-5 Job. Wir sind ständig online, lesen, lernen und programmieren auch in unserer Freizeit neue Dinge. Aber wir tun das, weil es uns Spass macht. Uns bezahlt dafür leider keiner…
Vermutlich sind wir in der Unterzahl, die meisten typischen Entwickler dürften normale Absolventen sein und dies schlicht als Job begreifen. Hier ist kein Verständnis und auch keine vergleichbare Motivation vorhanden, andererseits beuten sie sich vermutlich auch nicht aus sondern halten ihren Job auf Distanz.
Es geht nicht ohne die „Alpha“-Leute, aber es geht nicht auf Dauer mit nur einem „Alpha“-Teamleiter, der womöglich irgendwann nur noch „verrückte“ Entscheidungen trifft. Jeder tut dies mal und das beste Mittel dagegen ist der fachliche Austausch mit anderen Leuten (intern/extern/Bekannte/OpenSource-Community), die fachlich auf der selben Ebene aktiv sind. Hier kann man Ideen und Vorgehensweisen „review“-en, sich in der eigenen Sichtweise bestätigen lassen oder einen anderen Blickwinkel auf das Problem aufzeigen lassen.
Gut, man könnte jetzt meinen: Ein ideales Team besteht dann eben aus ein paar 9-5 Entwicklern und ein paar „Alpha“-Nerds, die als eine Art Architekten/Steuerleute die technologische Richtung vorgeben. Auch das ist kein Patentrezept: Als junger Entwickler hat man beispielsweise keine Erfahrungswerte, weiss nicht was Skalierung bedeutet und wie „nachhaltig“ ein Produkt gebaut werden muss. Man greift gerne nach dem heissesten Buzzword-Scheiss, den es gibt, verkompliziert also die Infrastruktur um bspw. eine fiktive, vollkommen utopische Skalierbarkeit gewährleisten oder andere realitätsferne, gänzlich unbekannte Anforderungen zu erfüllen (was dann aber trotzdem nicht funktioniert).
Um sich gegen „mentale Fallen“ zu schützen, muss das Team möglichst unterschiedlich sein, unterschiedliche akademische, technische Hintergründe und Erfahrungswerte haben. Und sich trotzdem fachlich und menschlich verstehen können und wollen.
Und dann gibt es noch das ultimative psychologische Probleme: Es gibt keine Geschwindigkeitsbegrenzung im Kopf! Man kann sich durchaus in eine Art Rausch programmieren, überabstrahieren, overengineeren, Traumschlösser oder Traumwelten erschaffen und sich kurzzeitig wie ein Gott fühlen. Die Kosten — ausser etwas Arbeitszeit — sind hierfür erst einmal gering. Server und Software sind preiswert oder umsonst.
Aber wirklich jeder Entwickler tendiert dazu, sich damit sein eigenes Grab zu schaufeln. Der Rausch, der Zauber des Anfangs geht schnell vorbei. Was bleibt ist die Komplexität, das schwer zu beherrschende „Monster“, das man geschaffen hat. Tagtäglich kommen neue Anforderungen, die man ursprünglich nicht hatte, man versucht sein „ultimatives System“ anzupassen, baut weiter an.
Die Produktivität nimmt ab, Druck und Zweifel nehmen zu. Das Gefühl am Abend, etwas geschafft zu haben, ist bei „Kopfarbeitern“ prinzipiell nicht besonders ausgeprägt. Die Erfolgserlebnisse werden nun aber immer geringer, Frust und Unzufriedenheit mit dem Kunden (Mangement, Beauftrager, Nutzer der Software) und mit der eigenen Lösung nehmen zu. Manche Alpha-Leute schaffen rechtzeitig den Absprung und wechseln die Stelle. Team-Mitarbeiter, die auf ein fixes Einkommen angewiesen sind (Familie, Alter) , oft aber auch ohne kompetitive Erfahrungen und Skills, sind hingegen an den Job gebunden und können dies nicht. Sie leiden nun noch sehr lange unter den Problemen (Depressionen etc), bis die Unternehmen das ganze System ersetzt. Oder sie irgendwie doch den Absprung schaffen.
Wie kann man solche Szenarien vermeiden? Agile, testgetriebene Entwicklung schon von Anbeginn eines Projektes kann eine „positive Bremsfunktion“ darstellen, die zu Beginn valide Fragen an Anforderungen und Nutzung der zu entwickelnden Lösung stellt. Statt auf Verdacht ein „Hochhaus“ zu bauen, fängt man mit der Mindestlösung an, die aber eine hohe Qualität aufweist. Statt auf Verdacht zu bauen, werden Fragen thematisiert.
Aber auch das nimmt nicht die latente Angst von den Entwicklern, sich selbst irgendwann arbeitslos zu machen. Automatisierung und Tests sichern eine so hohe Qualität und eben Automatisierung — Was kommt, wenn das Projekt „fertig“ ist? Diese Angst ist zwar fast nie berechtigt, trotzdem gilt oft noch das Motto: Ein großes Team ist ein Zeichen der Wichtigkeit und technologischen Güte eines Projektes. Das ist vollkommener Blödsinn, aber ein großes Team sichert ein Grundrauschen in der Organisation, ein Grundrauschen im Zwischenmenschlichen (= „Lead“-Position, Budget- und Personalverantwortung usw.) und eine Verhandlungsposition gegenüber internen Strukturen/Vorgesetzten/Management/Abteilungen. Natürlich zu einem sehr hohen Preis und zu Lasten der Wettbewerbsfähigkeit des Unternehmens.
Sinnvoller wäre es, die Entwickler nach ihrer Leistung, ihrem positiven Beitrag zum Unternehmensziel zu bezahlen. Wer also wenig Kosten verursacht und viel automatisiert, würde eine höhere Entlohnung bzw einen Bonus erhalten. Aber wie soll man das quantifizieren?
Ein Entwickler hat jedenfalls in typischen Organisationen keinen Anreiz, eine Software, eine Architektur, ein Team überschaubar und kompakt zu halten. Big is beautiful. Qualität == Quantität.
Bei US-Startups schaut es anders aus: Hier sind die frühen Entwickler mit Aktienoptionen am Unternehmenserfolg beteiligt. Es gibt zumindest einen finanziellen Anreiz, sich auf das Nötigste zu beschränken, also das typische „Lean Startup“-Modell zu verfolgen. Und das obwohl jedem klar ist, dass die Erfolgsaussichten eines Startups prozentual gering sind. Nachhaltigkeit ist also nicht der Grund, sondern der persönliche Vorteil.
Das könnte man auch auf Freiberufler wie mich übertragen. Eigentlich habe ich keinen Anreiz, besonders schnell und gut zu arbeiten. Ich werde pro Zeiteinheit bezahlt und bekomme keinen Bonus. Je länger ich brauche, desto größer wäre sogar die Wahrscheinlichkeit einen Folgeauftrag zu erhalten. Mein Problem ist es aber, dass ich das ganze eben als Berufung wahrnehme und nicht als 9-5 Job. Ich kann nicht „Dienst nach Vorschrift“ machen, jedenfalls nicht sehr lange. Ich mache das ganze eben auch deshalb, weil es mir Spass macht. Ich will Probleme elegant lösen. Kann oder darf ich das nicht, werde ich mit mir unzufrieden und suche mir dann lieber etwas neues…
Das ist finanziell für mich natürlich nachteilig, aber ich kann mir keine Arbeit vorstellen, die mich dauerhaft unzufrieden macht und bei der ich meine Erfahrung und meine Skills nicht einbringen darf. In der Vergangenheit hatte ich schon solche schlimmen Projekte und habe sie bis zum Ende durchgezogen nur um dann für einige Woche mental komplett mental leer zu sein.
Ich schreibe das gerade zu einer Zeit, in der ich ein sehr interessantes aber auch forderndes Projekt — auch mit Altlasten — bearbeite. Aber weil ich dort beitragen kann, die Probleme dauerhaft zu lösen, weil Vorgesetzte und Team-Mitglieder zumindest bis jetzt auch dem gegenüber sehr offen und interessiert sind, macht es mir sehr viel Freude.