Software-Development: Make or Buy?

Weil immer mehr digitale Angebote geschaffen werden müssen, ist die „Nachfrage“ nach Developern enorm gestiegen. Ich erlebe oft, dass grössere Unternehmen mit dem Gedanken spielen für ihre Plattform-Projekte anstatt auf externe Dienstleister zu setzen, interne Teams aufzubauen. Das kann, muss aber nicht gut gehen. Eigentlich geht es recht oft schief, ironischerweise realisieren das aber die wenigsten Entscheidungsträger im Management. Meist weil sie von Software-Entwicklung schlicht zu wenig Ahnung haben.


(Lesedauer 4 Minuten)

In der Theorie ist die Sache klar: Es ist günstiger, direkter und damit einfacher ein internes Team von Software-Entwicklern auf ein Projekt anzusetzen. Die Lohnkosten sind in der Regel 50% des Preises, den man einem externen Dienstleister bezahlen müsste. Die Teams sind jederzeit greifbar und Change Requests gibt es auch keine.

Der Traum vom eigenen Team endet im „Endless Storming“

Die Realität sieht leider allzu oft nicht so toll aus: Da In-House Development in Grossfirmen bei wirklich hochkarätigen Entwicklern verschrien ist (weil altmodische, mühsame Kultur, Alphatier-Dominanz etc) findet sich meist nur die B-Auswahl. Also die, die entweder nicht sehr gut sind oder die, die einfach nur wegen eines hohen Gehalts kommen (was, nebenbei, etwa gleich schlimm ist).

Die perfekte Zutat zu so einem Team ist dann in der Regel ein Product Owner der viel Ahnung von nichts hat. Also zwar selber so gut wie keine Development-Erfahrung hat, sich aber für die ideale Besetzung hält. Meist denken solche Leute auch, dass sie grossartige Motivatoren sind. In Tat und Wahrheit stehen sie den wenigen fähigen Leuten aber bildlich gesprochen nur im Weg rum.

Diese Mischung führt dazu, dass ein Team nie über die Storming-Phase hinauskommt. Und da die Frustration und die permanente Abwerberei von Developern zu einer hohen Flukuation führen verharrt das Team auch dort.

Dass dabei Deliverables produziert werden die zwischen Unbrauchbar und Mangelhaft rangieren versteht sich von selbst. Oder, eher seltener, ist die Qualität ok aber es dauert einfach unendlich lange. „Real Artists Ship“ gilt auch für Teams.

Natürlich ist mein Beispiel ad absurdum überzeichnet. Im Kern stimmt es aber: Leider haben viele „Kundenteams“ genau solche Probleme.

Nearshoring for the win. #NOT

Regelrechte Schadenfreude kommt bei mir mittlerweile auf, wenn Firmenvertreter groß verkünden, sie würden ein externes Development-Team im Ausland „an den Start bringen.“ Ich kann es jeweils in meinen Kalender eintragen: 18 Monate später bereuen sie das Unterfangen. Nicht unbedingt finanziell, denn gerade Developer im Osten arbeiten nach wie vor zu sehr günstigen Konditionen. Aber meist sind die Resultate sehr dürftig. Das heißt nicht, dass es dort keine sehr guten Developer geben würde. Meist aber zieht es die Fähigsten über Lang oder Kurz nach Europa oder Amerika.

“There are no shortcuts to places worth going”

Meine Erfahrung mit verschiedenen Nearshoring Teams zeigt, dass es durchaus klappen kann. Aber man muss sich eben darum kümmern. Das heisst alle zwei Wochen vor Ort sein, sich engagieren, sich um die Leute kümmern, sie einbinden. Und gemeinsam das Produkt weiterentwickeln. Die naive Vorstellung man könne einfach ein Konzept runterschicken und bekäme ein fertiges Produkt „zum Testen“ ist völliger Quatsch.

Der Killer CTO

Aber es gibt sie schon auch, die Kundenteams die funktionieren. Aus meiner Sicht benötigt man für den Aufbau eines internen Dev-Teams vor allem eines; einen wirklich exzellenten CTO. Viele werden jetzt denken, ein exzellenter CTO muss ein Genie sein. Jemand der intuitiv Lösungen konzipiert und wahnsinnig schnell und gut programmieren kann. Ich glaube das ist falsch.

Der perfekte CTO muss vor allem mit Developern umgehen können. Er muss sie auf natürliche Weise motivieren können, er muss beliebt sein, er muss blitzschnell wirkliche Qualität erkennen können (eine Eigenschaft die einen ganz allgemein weit bringt), er muss sich für Nicht-Technisches interessieren und er muss gleichzeitig viele Probleme parallel lösen können. Und ja, natürlich muss er selber ein eher überdurchschnittlicher Developer sein.Das ist eine Kombination von Fähigkeiten die sich nur ganz, ganz selten auf eine Person vereint.

Wenn Sie also mit dem Gedanken spielen ein eigenes Team aufzubauen, suchen Sie also primär nach diesem CTO. Wenn Sie ihn haben, und dafür sehr wahrscheinlich eine lächerlich hohe Entlöhnung leisten müssen, wird schlagartig alles einfacher. Das hohe Gehalt wird sich bereits dann relativieren wenn Sie weitere Team-Mitglieder akquirieren. Anstatt technisch unterqualifizierten Recruitern eine Provision zahlen zu müssen, bringt Ihr CTO das Kernteam vom letzten Arbeitgeber einfach mit. Das ist schlecht für die alte Firma aber gut für Sie. Ein solches Team findet schnell wieder zu einander und vermag seine Kultur weiteren Neuzugängen schnell vermitteln. Das Team liefert schnell und verringert damit die Time to Market.

Alternative Modelle: Team & Method

Eine Alternative zum Aufbau eines eigenen Teams bildet die Möglichkeit ein solches zu kaufen. Nur wenige Dienstleister bieten das an, darunter zum bei wir bei AOE. Das ist kein Bodyleasing oder Outsourcing sondern der Dienstleister stellt über einen Budget-Retainer ein erfahrenes Team zu Verfügung. Der Dienstleister verkommt dabei jedoch nicht zum reinen Rechnungssteller sondern entwickelt das Team weiter, kümmert sich um Know-How Transfers aus anderen Teams und sorgt dafür, dass Velocity und Qualität hoch bleiben.

Für Sie als Kunden und Product Owner fühlt sich das an wie ein eigenes Team. Einfach ohne den Hassle die ein eigenes Team mit sich bringen kann: interne Auseinandersetzungen, Fluktuationen, zum einen gewissen Grad Krankheitsausfälle, Weiterbildungsausfälle, etc.

Das übernimmt der Dienstleister für Sie und da er damit langjährige Erfahrung hat und dem Team auch ein räumliches Umfeld bietet, indem es sich weiterentwickeln kann, fallen nicht einmal Personalinfrastrukturkosten an.

Ich habe letzten Monat Vollkosten- und Vergleichsrechnungen dazu gemacht. Diese zeigen, dass, Qualität und Time to Market mit eingerechnet, das Team & Method Modell auch kostenmäßig vorne liegt.

Hybrides Modell? Ja, bitte.

Natürlich können auch beide Modelle, also Team & Method und eigenes Team kombiniert werden. Zum Beispiel so: Um einen schnellen Start zu ermöglichen, erarbeitet man mit einem Dienstleister-Team die Grundlagen für eine Plattform und rekrutiert in aller Ruhe neue Developer. Idealerweise lässt man diese durch das zugekaufte Team „testen“ und gewährleistet so, dass Qualitätsverständnis, Skillset und Kultur aufeinander passen.

Auf diese Weise kann ein internes Team „angesetzt“ werden. Wird das ursprüngliche Team, bestehend aus internen und externen Developern dann zu groß, entstehen einfach zwei Teams. Idealerweise trennt man dann diese auf interne und externe Mitarbeiter auf.

So kommt man ganz nebenbei zu einem guten internen Team, ohne in dessen Aufbauzeit auf qualitativ hochstehende Leistung verzichten zu müssen. Und darum geht es im Grunde genommen ja.

Artikel auf Social Media teilen:

Schreibe einen Kommentar

Deine E-Mail Adresse wird nicht veröffentlicht. Bitte mache folgende Angaben: Dein Name, Deine E-Mail Adresse und Dein Kommentar.