Sie haben ein kleines Entwicklerteam gefunden. Die Leute sind Ihnen sympathisch, die Schätzung wirkt vernünftig und der Preis liegt bei einem Bruchteil dessen, was eine große Agentur verlangen würde. Jetzt kommt der Vertrag. Und irgendwo im Hinterkopf meldet sich eine leise Frage: Was passiert, wenn genau dieser Entwickler ausfällt?
Die kurze Antwort: Ob er Urlaub hat, krank wird oder kündigt, Ihr Projekt darf deshalb nicht stehen bleiben. Und der Grund dafür muss sich überprüfen lassen, ein Versprechen reicht nicht. Bei uns liegt er darin, wie wir Projekte besetzen. Ich bin vom ersten Tag an in jedem Projekt dabei, als CTO, Architekt und Projektleiter. Wir bemühen uns, dass ein zweiter Entwickler jede Änderung prüft, bevor sie in den Code übernommen wird. Jedes Projekt hat eine Dokumentation, mit der ein Neuer anfangen kann. Und in den meisten Verträgen stehen die Namen der Leute, die daran arbeiten.
Was wir nicht anbieten, ist ein Ersatzentwickler innerhalb von 48 Stunden. Wer so etwas anbietet, verkauft meiner Meinung nach das Falsche. Warum, erkläre ich weiter unten.
Warum „Was, wenn der Entwickler ausfällt?“ genau die richtige Frage ist: der Bus-Faktor
In der Softwareentwicklung gibt es dafür einen eigenen Begriff, den Bus-Faktor: die Zahl der Personen, die aus einem Projekt verschwinden müssten, bevor es zum Stillstand kommt. Die düstere Version des Gedankens ist, dass jemand vom Bus überfahren wird. Viel häufiger wird er schlicht abgeworben. Ein Bus-Faktor von 1 heißt, dass alles an einer einzigen Person hängt, an ihrem Kopfmonopol, wie man im Deutschen manchmal sagt.
Wie verbreitet das ist, hat eine Studie von Avelino und Kollegen aus dem Jahr 2016 an 133 populären Open-Source-Projekten auf GitHub untersucht. Bei 34 % lag der Bus-Faktor bei 1, bei 65 % bei höchstens 2. Im Netz kursiert für die erste Zahl übrigens häufig 46 %. Das ist falsch, in der Studie stehen 34 %.
Was passiert, wenn der schlimmste Fall eintritt, zeigt eine spätere Arbeit desselben Erstautors aus dem Jahr 2019. Sie betrachtete 315 Projekte, in denen sämtliche Schlüsselentwickler gegangen waren. Nur 41 % dieser Projekte überlebten. Auch das nur, weil neue Leute die Arbeit übernahmen. Gesprochen wird über dieses Risiko trotzdem kaum. In einer Umfrage von Forschern bei JetBrains und der Universität Bilkent unter 269 Softwareingenieuren aus dem Jahr 2022 gaben 63 % an, im vergangenen Jahr an mindestens einem Projekt gearbeitet zu haben, bei dem sie ein hohes Risiko sahen, dass der Bus-Faktor auf null fällt. Nur 19 % hatten je in einem Projekt gearbeitet, in dem ihnen jemand den Bus-Faktor genannt hatte.
Eine Einschränkung gehört dazu: Diese Zahlen stammen aus Open-Source-Projekten und aus großen Unternehmen. Teams in unserer Größe hat niemand untersucht. Der Mechanismus ist aber bei jeder Größe derselbe. Und der richtige Moment, danach zu fragen, ist der vor der Unterschrift.
Wie wir ein Projekt besetzen
Wir sind zu fünft und ich bin einer davon. Zwei Entwickler arbeiten am Backend, einer am Frontend, dazu kommen ein Testingenieur, der alles prüft, was wir ausliefern, und jemand für das Design. Ich selbst bin in jedem Projekt als CTO, Architekt und Projektleiter dabei. Mehr als drei Projekte gleichzeitig nehmen wir nicht an.
Unser kleinstes Projekt hat einen einzigen Entwickler. Auf dem Papier sieht das nach Bus-Faktor 1 aus. Wäre dieser Entwickler allein, wäre es das auch. Das ist es aber nicht, weil der Mensch, der das System entworfen hat, mit im Projekt sitzt.
Für Probleme, die nicht zu unserer täglichen Arbeit gehören, holen wir externe Berater dazu, etwa für komplexe Zahlungsabwicklungen mit Stripe oder anspruchsvolle Telefonie und Nachrichtenfunktionen mit Twilio. Das sind immer dieselben Leute, mit denen wir seit Langem zusammenarbeiten. Nicht einfach die, die gerade Zeit haben.
Wo das Wissen liegt, damit es nicht mit einer Person das Projekt verlässt
Wissen, das nur in einem Kopf steckt, geht mit diesem Kopf. Bei uns liegt es an fünf Stellen. Die erste ist das Review: Wir bemühen uns, dass jede Änderung von einem zweiten Entwickler geprüft wird. Eine Untersuchung von Bacchelli und Bird bei Microsoft aus dem Jahr 2013 kam zu dem Ergebnis, dass solche Reviews weniger mit dem Finden von Fehlern zu tun haben als erwartet und mehr mit der Weitergabe von Wissen. Wer prüft, versteht hinterher Code, den er nicht selbst geschrieben hat. Genau das wollen Sie an dem Tag, an dem jemand plötzlich fehlt.
Die zweite Stelle ist das Repository, also der Ort, an dem der Code liegt. Dort finden sich eine ausführliche README, die Datei, die einem Entwickler erklärt, wie er das Projekt installiert und startet, eine TODO-Liste und ein schriftlicher Stand der laufenden und abgeschlossenen Aufgaben. Wer neu dazukommt, sieht so, was erledigt ist und was noch fehlt, ohne den Abwesenden fragen zu müssen.
Die dritte Stelle ist der Code selbst. Für das Frontend haben wir keinen zweiten Entwickler, deshalb setzen wir dort auf Struktur, nämlich auf die SOLID-Prinzipien, fünf Entwurfsregeln, nach denen jedes Codestück genau eine Aufgabe hat und sich ein Teil ändern lässt, ohne den Rest zu beschädigen. Ein Fremder findet sich in solchem Code schneller zurecht. Eine zweite Person ersetzt das trotzdem nicht. Darauf komme ich weiter unten zurück.
Die vierte Stelle ist der Vertrag. In den meisten unserer Verträge stehen die Namen der Beteiligten, nicht in allen, denn das hängt davon ab, was der Kunde wünscht. Wenn Sie Namen im Vertrag haben möchten, fragen Sie danach.
Die fünfte Stelle sind die Konten. Am liebsten liegen Code, Server und Konten bei Drittanbietern auf Ihrem Namen und Sie geben uns Zugriff. In der Praxis haben viele Kunden niemanden, der Hosting, Repositories und externe Dienste einrichten könnte, also laufen sie oft über unsere Firmenkonten. Das ist bequem. Es ist aber auch eine Abhängigkeit von uns. Die sollten Sie vom ersten Tag an kennen. Mein Rat, egal bei wem die Konten liegen: Lassen Sie sich eine schriftliche Liste aller Konten geben, auf denen Ihr Produkt läuft.
Urlaub, Krankheit, Kündigung: drei Fälle, drei Antworten
Ausfall ist nicht gleich Ausfall. Jeder dieser drei Fälle verlangt etwas anderes.
Geplanter Urlaub
Nach serbischem Arbeitsrecht stehen jedem Beschäftigten mindestens 20 Arbeitstage Jahresurlaub zu, wobei der erste Teil mindestens zwei zusammenhängende Wochen umfassen muss. Diese Abwesenheit ist also sicher und vorhersehbar. Wir planen sie intern ein. Das ist unser Planungsproblem, nicht Ihres.
Für Leser in Westeuropa ein Hinweis am Rande: Unsere Feiertage sind andere. Das orthodoxe Osterfest fällt 2027 auf den 2. Mai und damit direkt auf die serbischen Feiertage am 1. und 2. Mai. Das westliche Ostern liegt fünf Wochen früher, am 28. März 2027.
Plötzlicher Ausfall
Eine schwere Erkrankung mitten im Projekt hatten wir bisher nicht. Am nächsten kommt eine Situation, die wir tatsächlich erlebt haben: Ein Kunde bat darum, dass einer unserer Entwickler sofort aufhört, an seinem Projekt zu arbeiten. Ohne Frist, ohne Übergabewoche. Jedes Mal, wenn das vorkam, habe ich die Verantwortung selbst übernommen und weitergemacht. Dafür ist der Architekt in jedem Projekt da. Wer einspringt, muss das System nicht bei null kennenlernen, weil ich es entworfen habe.
Kündigung
Bisher hat niemand Conimex IT mitten in einem Projekt verlassen. Noch nicht. Wenn es passiert, braucht der Nachfolger Zeit: nach unserer Erfahrung rund drei Monate, bis er ein mittelgroßes Projekt vollständig beherrscht. Die Forschung landet im selben Bereich: Zhou und Mockus stellten 2010 fest, dass sich die Produktivität neuer Entwickler bei kleinen und mittleren Projekten nach wenigen Monaten einpendelt, bei großen erst nach bis zu einem Jahr.
Warum wir Entwickler nicht rotieren lassen und 48 Stunden das falsche Versprechen sind
Hier widerspreche ich einem großen Teil der Branche. Große Agenturen schieben ihre Entwickler ständig zwischen Projekten hin und her. Bezahlen müssen das die kleinen und mittleren Kunden. Ihre Klage lautet: ein Entwickler nach dem anderen im selben Projekt, jeder Wechsel hat die Arbeit gebremst und am Ende war das Produkt schlechter.
Deshalb beeindruckt mich ein Ersatz innerhalb von 48 Stunden nicht. Der Ersatz ist in zwei Tagen da. Das Verständnis kommt nach etwa drei Monaten.
Fred Brooks hat das schon 1975 in einem Satz zusammengefasst, der als Brooks’sches Gesetz bekannt ist: „Adding manpower to a late software project makes it later.“ Wer einem verspäteten Softwareprojekt zusätzliche Leute gibt, verzögert es also nur noch weiter. Ein Projekt, das ständig Leute austauscht, kommt aus der Einarbeitung nie heraus.
Was ein Team unserer Größe nicht leisten kann
Im Frontend liegt unser Bus-Faktor bei 1. SOLID und ein Architekt im Projekt verkürzen die Übernahme, aber wenn unser Frontendentwickler ausfällt, wird die Arbeit am Frontend langsamer, bis er zurück ist oder jemand anderes den Code gelernt hat.
Eine ständige Rufbereitschaft rund um die Uhr (24/7), also jemanden, der jederzeit bereitsteht, wenn ein System ausfällt, bieten wir nicht. Googles SRE-Buch, ein Handbuch für den Betrieb von Produktivsystemen, nennt mindestens 8 Ingenieure als Untergrenze für eine tragfähige Rufbereitschaft an einem einzigen Standort. Das sind mehr Leute, als unser ganzes Team hat: Wir sind 5. Wenn Sie jede Nacht jemanden brauchen, der um 3 Uhr nachts auf einen Alarm reagiert, brauchen Sie ein größeres Team oder einen spezialisierten Betriebsdienstleister.
Wir können uns auch nicht im nächsten Monat verdoppeln. Wer zum Monatsersten 10 Entwickler braucht, ist bei uns an der falschen Adresse. Darüber nachdenken würden wir nur, wenn sich der Kunde auf eine längere Zusammenarbeit festlegt.
Und solange niemand tatsächlich gekündigt hat, ist unsere Antwort auf diesen Fall ein Plan und keine Erfolgsbilanz.
Sieben Fragen, die Sie jedem Entwicklerteam vor der Unterschrift stellen sollten
Diese Fragen funktionieren bei jedem Anbieter, egal wie groß. Unsere eigenen Antworten stehen jeweils dahinter.
- Wer außer dem Entwickler kennt meinen Code noch? Ich, als Architekt in jedem Projekt. Im Backend sind es zwei Entwickler. Im Frontend ist es einer. Das ist unsere Schwachstelle.
- Wird jede Änderung von jemand anderem geprüft? Wir bemühen uns, dass es wirklich jede ist.
- Wo liegen Code, Server und Konten? Idealerweise auf Ihrem Namen. Wenn Ihnen lieber ist, dass wir alles einrichten, auf unserem. In beiden Fällen sollten Sie wissen, welches von beiden gilt.
- Stehen die Namen der Beteiligten im Vertrag? In der Regel ja. Wenn Sie es möchten, stehen sie drin.
- Wie oft ziehen Sie Entwickler von einem Projekt ab und setzen sie in einem anderen ein? So selten wie möglich. Diese Rotation ist genau das, wogegen wir argumentieren.
- Wie lange braucht ein neuer Entwickler, um ein Projekt zu übernehmen? Rund drei Monate, bis er ein mittelgroßes Projekt vollständig beherrscht.
- Was können Sie nicht abdecken? Eine ständige Rufbereitschaft rund um die Uhr und eine Verdopplung des Teams auf kurze Sicht.
Welches Team zu Ihrem Projekt passt
Brauchen Sie eine Rufbereitschaft rund um die Uhr oder 10 Entwickler ab nächstem Monat, sind Sie bei einem größeren Anbieter besser aufgehoben. Das sagen wir Ihnen schon im ersten Gespräch.
Bauen Sie dagegen ein einzelnes Produkt und möchten Sie, dass dieselben Leute vom ersten Commit bis zum Launch daran arbeiten, dann ist ein kleines Team mit einem Architekten in jedem Projekt die sicherere Wahl. Nicht die riskantere.
Sind Sie eine Bank, eine Versicherung oder ein anderes Finanzunternehmen, kommt noch etwas hinzu. Der Digital Operational Resilience Act (DORA), die EU-Verordnung über die digitale operationale Resilienz im Finanzsektor, gilt seit dem 17. Januar 2025 und verlangt schon heute Exitstrategien für IT-Dienstleister, die kritische Funktionen unterstützen. Fragen Sie danach, ganz gleich, wie groß das Team ist.
Bevor Sie unterschreiben, reden wir über die Besetzung
Wir entwickeln individuelle Web- und Mobilprodukte mit Laravel, React und React Native. Wir sitzen in Belgrad und arbeiten zu denselben Zeiten wie der Großteil Europas.
Bevor Sie etwas unterschreiben, sagen wir Ihnen, wer nach Rolle an Ihrem Projekt arbeiten würde, wer den Code dieser Leute prüft und auf wessen Namen Ihre Konten laufen würden. Schreiben Sie uns an [email protected].