Unterm Strich teurer:
Warum Softwareprojekte mit Outsourcing-Entwickler:innen oftmals scheitern.
Und worauf Sie achten sollten, damit es klappt.
Klingt verlockend: “Gut ausgebildete und erfahrene Softwareentwickler in Indien entwickeln Angular, React, NodeJS oder Laravel für 20$ die Stunde. Mit deutschem Ansprechpartner.” So oder so ähnlich klingen die E-Mails, die ich als Empfänger der info@-Adresse fast jeden Tag erhalte. Mittlerweile landen alle E-Mails direkt im Papierkorb.
Aber zugegeben: Wir haben es auch schon probiert! Die Vorstellung einer verlängerten Werkbank war einfach zu verlockend. Und erst die möglichen Margen! Wie es gelaufen ist: viele Überstunden für mich, verbranntes Geld für den Kunden und eine Menge Frust bei allen. Woran scheitert es? Warum ist – wie in unserem Fall – die Software am Ende nicht erfolgreich? Und überhaupt:
Wann bezeichnet man eine Software als “erfolgreich”?
Ungefähr jede Softwarebude hat sich mit dieser Frage schon beschäftigt. Und mindestens einen Blog-Beitrag dazu geschrieben, was bei Software wichtig ist. Ja, Wartbarkeit, Performance, Usability, Sicherheit etc. können wir auch. Aber da wir konsequent die Costumer-first Perspektive einnehmen wollen, versuche ich es auch hier aus Sicht der Kunden. Wichtig also: Die Software soll …
… alle Funktionen haben. Der Kunde hat (hoffentlich!) eine genaue Vorstellung davon, was die Software können soll. Und genau das soll sie am Ende auch können. Ohne Diskussion und ohne Abstriche.
… zuverlässig sein. Bugs mag niemand. Kein:e Entwickler:in und kein Kunde. Trotzdem gibt es sie. Das ist okay, sollte sich aber in einem verträglichen Rahmen bewegen. Vor allem aber muss auf schwerwiegende Bugs schnell reagiert werden können.
… pünktlich zur anvisierten Deadline fertig sein und möglichst wenig kosten – sowohl in der initialen Entwicklung als auch in der Wartung.
Das Gute hierbei: Diese Kundenziele decken sich ziemlich exakt mit den Zielen der Softwareentwickler:innen. Aber:
Was braucht man, um diese Ziele zu erreichen?
Durch die Erfahrung aus zahlreichen Kundenprojekten können wir die Sollbruchstellen bzw. kritischen Erfolgsfaktoren mittlerweile recht gut zusammenfassen. Unsere Top-3:
1. Eine tragfähige Architektur
Nur, wenn das Softwareprojekt von Anfang an gut geplant ist, kann es auch erfolgreich werden. Was nützen uns die agilsten Methoden, wenn bei Anforderungsänderung die gesamte Architektur zusammenbricht? Klingt logisch, aber genau hieran hapert es oft in der Praxis.
2. Gutes Requirements Engineering
Jede:r sollte das tun, was er oder sie am besten kann. Die Entwickler:innen sollten entwickeln; und sich nicht mit der Interpretation von Anforderungen beschäftigen müssen. Denn wenn die Anforderungen von Anfang an klar und gut dokumentiert sind, ist die Gefahr eines scheiternden Projekts so gut wie ausgeschlossen. Im besten Fall landet bei den Entwickler:innen also ein komplett dokumentiertes und in Epics, Stories und Arbeitspakete aufgeteiltes JIRA-Projekt. Nach einem kurzen Refinement der Anforderungen können sie direkt loslegen.
3. Hervorragende Quality-Gates
Die Qualität des Quellcodes und der umgesetzten Anforderungen muss ständig und systematisch überprüft werden. Auf der einen Seite natürlich durch Build- und Test-Server, Code-Analyse-Tools und interne manuelle Code Reviews. Auf der anderen Seite aber auch zum Kunden hin: Der oder die Projektmanager:in sollte in jedem Sprint genau überprüfen, ob die Anforderungen auf optimale Weise für den Kunden umgesetzt wurden. Wenn nicht, werden Runden gedreht. Heißt: Ein geschultes und kompetentes Argusauge ist unerlässlich.
Erfolgreiche Software braucht also mehr als nur Programmierer:innen. Erfolgreiche Software braucht fähige Projektleiter:innen, die dem Kunden jede noch so kleine Anforderung entlocken und diese (unmissver-)verständlich sowohl für Auftraggeber als auch Coder zu Papier bringen. Erfolgreiche Software braucht erfahrene Architekt:innen, die Technologien und Methoden von Anfang an tragfähig definieren. Erfolgreiche Software braucht motivierte Tester:innen, die gewillt sind, jeden noch so kleinen Fehler zu finden und zu dokumentieren. Diese dürfen auch gerne mal etwas pingelig sein. Nervt vielleicht hier und da, dafür ist das Resultat umso entspannter. Und dann braucht’s natürlich auch die guten Programmierer:innen. Wo auch immer diese dann sitzen.
Nur etwa 30 Prozent des gesamten Entwicklungsaufwandes wird durch Programmierer:innen erledigt.
Diesen Satz würde ich mittlerweile ohne mit der Wimper zu zucken unterschreiben. Und damit schlagen wir den Bogen zurück zum Outsourcing. Die Teams, die das Softwareprojekt übernehmen, bestehen meistens aus Programmierer:innen. “Nur” aus Programmierer:innen. Alle anderen essentiellen oben genannten Positionen fehlen und werden daher notdürftig durch die Programmierer:innen selbst ausgefüllt. Was daraus logischerweise folgt – folgen muss –, ist klar: schlecht definierte Anforderungen, fehlendes Qualitätsmanagement, und mit ausführlichem Testing wird es auch nicht immer so genau genommen. Weil es sich hierbei um andere Kompetenzen handelt. Sie würden ja auch nicht von einem Formel-1-Piloten erwarten, dass er sein Auto selbst zusammenbaut.
Klar, ich habe auch schon gute outgesourcte Softwareentwicklungen erlebt. Aber nur dann, wenn auf Seiten der Auftraggeber das nötige Team vorhanden war: Fähige Projektmanager:innen, erfahrene Architekt:innen und eine Menge Tester:innen, die sich um Software Reviews gekümmert haben. Dann läuft’s super! Wenn es dieses aber ohnehin braucht, empfiehlt sich – nicht zuletzt mit Blick auf die Transaktionskosten – die Frage:
Wenn schon 70 % der Arbeit im eigenen Team liegen, warum dann nicht für die restlichen 30 % auf eigene Entwickler:innen setzen?
Denn ein Restrisiko, sollte man das Coder-Team abroad nicht schon extrem gut kennen, bleibt. Zudem ist der Zugriff bei Problemen durch die räumliche Distanz erschwert. Auch wir mussten schon mehrfach die “Bug-Feuerwehr” für nicht funktionale Software aus dem Ausland spielen. Und nicht selten stellt sich leider heraus, dass eine komplette Neuentwicklung unumgänglich ist, da dies für den Kunden unterm Strich viel günstiger ist, als vielschichtige Löcher zu stopfen. Und so greift leider oftmals das ausgelutschte Sprichwort: “Wer billig kauft, kauft zweimal.”
Fragen? Kommentare? Anregungen?
Dann schreib uns eine Nachricht.
