Als IT-Freiberufler habe ich nun schon mehrere Dutzend Organisationen „von innen“ sehen und erleben können und stoße dabei immer wieder auf die gleichen Probleme.
Meine Kunden beauftragen mich meist in Krisen-Situationen, also wenn bereits sehr viel Zeit und Ressourcen investiert wurden, „trotz dessen„ aber das erwartete Ergebnis nicht eintrat. Die häufigsten Gründe sind:
1. Mangelhafte Planung
Es wurden sich zu wenige Gedanken gemacht, bevor das Projekt in die Umsetzungsphase ging. Trotzdem wurde vorab ein Gesamtaufwand geschätzt.
Dies passiert meist aus zwei Gründen:
Das Management fordert das Entwicklungsteam auf, eine Zahl zu nennen und verbindet das mit „Management-Druck“. Das Team selbst ist nicht in der Lage diesem Druck stand zu halten, zuerst eine Klärung und Festlegung bei offenen Punkten zu erreichen und nennt dann eine substanzlose Schätzung um dem akuten Druck zu entgehen. Das führt zu Aussagen wie „Auf Schätzungen aus der IT-Abteilung schlage ich eh immer 50% Risikozuschlag drauf, die kriegen nie etwas in-time und in-budget hin“ o.ä.
Ein weiterer Grund für zu optimistische Schätzungen ist politisch bedingt: Auch wenn der Auftraggeber nicht in der Lage ist, seine Anforderungen umfassend zu dokumentieren, so hat er doch ein Budget zu vergeben, dass man gerne erhalten möchte. Ohne Budget ist die Finanzierung/Existenz des Entwicklungs-Teams gefährdet, also werden zwangsweise auch Projekte in Kauf genommen, die schon vor dem ersten Tag zum Scheitern verurteilt sind oder zumindest die in sie gesetzten Erwartungen verfehlen werden.
2. Fehlende Kenntnisse
Einerseits bin ich regelmäßig erschrocken, über wie wenig Kenntnisse in der Branche tätige Entwickler verfügen, andererseits verändert sich die erforderlichen Kenntnisse auch extrem schnell. Selten gleicht eine Aufgabe der anderen und Werkzeuge wechseln monatlich oder wöchentlich. Der zwingend notwendige Aufwand sich in neue Technologien einzuarbeiten unterscheidet sich von Entwickler zu Entwickler dramatisch, nicht nur durch Intelligenz und Motivation sondern auch schlicht durch den Tiefgang. Schliesslich ist ein syntaktisch korrektes Programm noch lange kein Beweis für eine saubere Arbeit oder das Verständnis einer Programmiersprache oder gar eines komplexen Frameworks. Weiterbildung kommt oft zu kurz und passiert „on the project“ — diese Zeit ist schwer abschätzbar, muss aber in der Beschätzung eines Projekts berücksichtigt werden.
3. Externe technische und „kulturelle“ Faktoren
Ein überschaubares Projekt wird dadurch zu einem Problem, dass es in eine größere Einheit integriert werden muss. Das kann eine System/Serverlandschaft sein oder ein oder mehrere wichtige, externe Dienste (API). So können die erforderlichen eigenen Anforderungen womöglich im Zeitplan umgesetzt werden, externe Komponenten verhindern aber den Release innerhalb des Zeitplans oder sabotieren das Projekt erfolgreich.
Neben technischen können es aber auch „kulturelle“ Gründe sein, also Vorgehensweisen, Regelungen, andere unternehmens- oder abteilungspolitische Gründe. Diese sind vom Entwickler-Team nicht abschätz- oder lösbar und müssen vom Auftraggeber gelöst werden. Passiert dies nicht frühzeitig, nämlich bereits in der Planungsphase, sind Konflikte und Mehraufwände in der Umsetzungsphase so gut wie vorprogrammiert.
4. Entwickler-Fehler
Das ist ein sehr weites Feld und pauschal nur schwer zu beschreiben. Ich möchte hier nicht auf prinzipielle geistig-technische Fähigkeiten, die ein Software-Entwickler benötigt, eingehen. Ein typischer Fehler, zu dem jeder Entwickler neigt ist Overengineering. Mit falschen, meist zu ambitionierten Annahmen bezüglich der zu erwartenden Leistungsfähigkeit, neigen Entwickler dazu, eine eigene und meist überkomplexe Lösung zu entwickeln. Dabei könnten realistischere, pragmatischere Lösungen, welche bereits als quelloffene Software am Markt verfügbar sind, Probleme viel schneller und nachhaltiger lösen.
Schnell passiert es, dass man an einem „Nebenkriegsschauplatz“ Unmengen an Hirnschmalz und Zeit verbrennt, ohne das dem ein messbarer, relevanter Nutzen gegenübersteht. Im Gegenteil: Quelloffene Bibliotheken um gängige Anforderungen zu lösen, sind oftmals weit verbreitet und weit getestet. Idealerweise gibt es eine aktive OpenSource-Community bei der viele Entwickler-Augen die Architektur und den Code gelesen, verstanden und ggf. Bugs entfernt haben.
Es ist viel günstiger, sich solcher OpenSource-Software zu bedienen, sie zu verbessern, anzupassen und diese Verbesserungen wieder der Community bereitzustellen, anstatt beispielsweise das 2342-igste Webframework zu entwickeln. „Das Rad neu erfinden zu wollen“ ist leider sehr verbreitet.
Ein Kollege von mir brachte es sehr treffend auf den Punkt: „Entwickler wollen entwickeln.“ — Das kann auch kontraproduktiv sein.
Oft sind sich Entwickler nicht im klaren darüber, für welche Dimensionen ihre Software benötigt wird und vergleichen ihren Einsatzzweck gerne mit dem nächsten Facebook oder Amazon. Ein Vergleich welcher in 99.9% der Fällen nicht zutrifft aber vom Management so natürlich nicht bestritten oder kommuniziert wird, getreu dem Motto: Größenwahnsinn ist Motivation — Mittelmaß ist Schwäche!
5. Änderungen während der Umsetzung
Über zehn Jahre nach Veröffentlichung des Agilen Manifests sind agile Workflows noch immer nicht ausreichend weit verbreitet. Anstatt also beispielsweise in Sprints dem Ziel inkrementell näher zu kommen, folgt einer mehr oder weniger ausreichenden Planungsphase die Phase der Entwicklung. Durch Rückfragen oder neue Wünsche des Kunden wird während der Entwicklung oftmals der Scope, also das Projektziel, massiv verändert. Dies führt zu mehr Aufwänden und Qualitätsproblemen und kann Projekte schlimmstenfalls vollständig zum Scheitern bringen.
Agile Methoden sehen hier vor, dass über einen überschaubaren Zeitraum geplant wird (1-3 Wochen) und regelmäßige Kommunikation aller Beteiligter inklusive Vertreter des Kunden/Auftraggebers stattfinden. Letzteres ist existenziell für diese Vorgehensweise aber auch sehr häufig ein Problem: Der Kunde/Auftraggeber kann oder will niemanden für diese Meetings bereitstellen oder diese Person ist nicht in der Lage oder befugt, zeitnah Entscheidungen einzuholen oder selbst zu treffen.
Regelmäßig sage ich Kunden, dass Software-Entwicklung kein Produkt sondern ein Prozess ist: Änderungen werden kommen, externe Bedingungen ändern sich zwangsläufig. Schon vor Beginn muss klar sein, dass die Sicht in die Zukunft sehr begrenzt ist und damit auch die Beschätzbarkeit. Offene, verlässliche, faire Kommunikation zwischen Entwicklung und Auftraggeber ist existenziell um in solch einer fragilen Umgebung bestehen zu können und Probleme frühzeitig zu lösen, bevor es zu einem Knall kommt.
Ich bin deshalb immer wieder erstaunt, wie Kunden und Freiberufler-Kollegen allen Ernstes Festpreise für Projekte vereinbaren: Am Ende gibt es mindestens einen Verlierer, wobei der Freiberufler üblicherweise, wenn es kritisch wird, am längeren Hebel sitzt und dann schnelle aber qualitativ miese Resultate abliefert. Der Kunde glaubt trotzdem, mit einer Pauschale ein Risiko begrenzt zu haben, muss dann aber mit einem qualitativ schlechten Resultat leben — das gelingt selten, insbesondere wenn das Geschäftsmodell des Kunden auf dieser Software aufsetzt. Tja, am falschen Ende gespart!
6. Arbeitsumgebung / Personalführung
Mehrere Studien verdeutlichen, wie schädlich Großraumbüros für die geistige Leistungsfähigkeit und Motivation sind. Man wird hier laufend unbewusst abgelenkt, kommt nur schwer in „den Flow„. Jeder klar denkende Mensch sollte nachvollziehen können, dass ein Großraumbüro die Kommunikation möglicherweise verbessert, aber dafür bei jedem Gespräch, bei jedem Telefonat, bei jedem Wort auch die Unbeteiligten ablenkt. Wer hier am Büro spart, bezahlt mit geringerer Produktivität, höherer Fehlerrate, mehr Stress und geringerer Leistung der Mitarbeiter.
Gerade in Konzernen ist oft die Vorgabe des Arbeitsmaterials sehr strikt: Es gibt nur eine Entwicklungsplattform/Hardware-Lieferant und Angestellte müssen diese benützen. Es gibt aber nicht *das* Universalgerät, das Universalbetriebssystem oder den Universal-Editor. Entwickler haben unterschiedliche technische Hintergründe und Fähigkeiten, eine Gleichmacherei verschenkt dieses Leistungs- und Innovationspotential.
Geistige Arbeit ermüdet, ist nicht beliebig verlängerbar und auch nicht jederzeit auf Abruf zu leisten. Arbeitszeitliche Flexibilität ist ein Muss. Einige Entwickler müssen aber auch vor sich selbst geschützt werden, weil diese sonst 14 Stunden am Tag vor dem Rechner sitzen und Zeit vertrödeln.
Wenn ein Unternehmen sich dafür entscheidet, nicht die Arbeitszeit sondern die Leistung zu bewerten — und diese ausschliesslich an relevanten Ergebnissen, nicht an gebauten Elfenbeintürmchen und Abstraktionsmonstern bewertet — lösen sich wahrscheinlich viele Probleme von alleine auf: Es würde zielführender entwickelt, weil Mitarbeiter dadurch früher nach Hause kämen oder einen finanziellen Vorteil erhielten.
Wenige Unternehmen in Deutschland sind dazu Willens und in der Lage: Wenn ein Entwickler bereits „nach 6 Stunden“ fertig ist, wird er so lange mit Arbeit zugeschüttet, bis er wieder nach 10 Stunden fertig ist und nach ein paar Monaten und Jahren um Burn-Out landet. Das haben viele Entwickler bereits selbst erlebt oder miterlebt. Findet also keine Honorierung von nützlicher Leistung statt, hält man „den Ball flach“ und schindet Zeit wo es nur geht um sich nicht selbst zu schaden („Job security“).
–
Die Probleme kommen Ihnen bekannt vor?
Sie brauchen Unterstützung für Ihre Software-Projekte?