Foto: Google Gemini · AI-generated
Fragt man, warum ein Dedicated Team mehr wert ist als dieselbe Stundenzahl anders eingekauft, lautet die ehrliche Antwort weder Seniorität noch Prozess. Es ist Wissen über das System.
Eine Entwicklerin, die seit achtzehn Monaten in Ihrem System arbeitet, weiß, welches Modul empfindlich ist, warum dieser eigenartige Workaround existiert und was beim letzten Eingriff in die Abrechnung kaputtging. Sie trifft den ganzen Tag kleine Entscheidungen richtig, ohne nachfragen zu müssen. Dieses Wissen ist das eigentliche Ergebnis einer langen Zusammenarbeit.
Aber genau hier wird meist etwas vorausgesetzt statt gestaltet: Wissen wächst nicht automatisch, nur weil ein Vertrag lange läuft. Es wächst, wenn die Zusammenarbeit dafür gebaut ist — und es ist erstaunlich leicht, eine zu bauen, die das verhindert.
Was dieses Wissen konkret ist
Konkret zu werden lohnt sich, denn “Domänenwissen” ist ein vager Begriff für etwas sehr Bestimmtes.
Es ist zu wissen, dass ein nächtlicher Job um 02:00 Uhr läuft und warum sein Verschieben das Reporting zerstört hat. Es ist zu erinnern, dass ein Kundensegment auf eine Funktion angewiesen ist, die laut Analytics niemand nutzt. Es ist zu wissen, welche Teile des Codes unter Zeitdruck entstanden sind und vorsichtig behandelt gehören — und welche tragfähig genug sind, um darauf aufzubauen.
Nichts davon steht im Ticket. Das meiste steht nirgendwo. Es lebt in Menschen und wird bei jedem Personalwechsel von null neu aufgebaut.
Verantwortung für die unspektakulären Teile erzeugt dieses Wissen
Der schnellste Weg, ein Team flach zu halten, ist, ihm ausschließlich Feature-Tickets zu geben. Jemand anderes betreibt die Pipeline, jemand anderes verantwortet die Umgebungen, jemand anderes wird nachts alarmiert. Das Team liefert Code und lernt nie, wie sich das System in Produktion verhält — dort steckt aber der größte Teil des wichtigen Wissens.
CarLicence ist das Gegenbeispiel. Es ist eine Echtzeit-API für Zulassungsverlängerungen, die Partnerunternehmen in ihre eigenen Websites, Apps, Kassensysteme und sogar Geldautomaten einbinden. Als deren Dedicated Team schreiben wir nicht nur Features: Die Zusammenarbeit umfasst laufende Webentwicklung, Cloud-Infrastruktur und DevOps — CI/CD-Pipelines, Umgebungsverwaltung und Produktions-Monitoring —, damit die Plattform Schritt hält, wenn neue Integrationspartner dazukommen.
Genau dieser Zuschnitt lässt das Wissen wachsen. Ein Team, das die Pipeline betreibt, weiß, warum Deployments so aussehen, wie sie aussehen. Ein Team, das das Monitoring beobachtet, weiß, wie normal aussieht — und nur so erkennt man Abweichungen schnell. Diese Verantwortung an einen Partner zu geben, ist kein Selbstzweck. Es ist der Weg, wie der Partner Fragen beantworten kann, statt nur Tickets zu schließen.
In der Entscheidung sein, nicht hinter ihr
Die zweite Voraussetzung ist Zugang zur Begründung.
Bei Atlikarinca, einem zweiseitigen Marktplatz, haben wir während der gesamten Entwicklung als eingebettete Erweiterung der eigenen Entwicklungskapazität des Startups gearbeitet. Marktplatzprodukte stecken voller Entscheidungen, die nur im Kontext Sinn ergeben: wie Angebote und Verhandlung funktionieren, wozu Bewertungen dienen, wer von Käufer und Verkäufer wann was sieht. Ein Team, das solche Entscheidungen als fertige Spezifikation erhält, setzt sie um. Ein Team, das dabei ist, wenn sie getroffen werden, versteht sie — und bemerkt den Fall, den die Spezifikation vergessen hat.
Dieser Unterschied kostet nichts extra. Es ist eine Frage davon, wer im Gespräch sitzt.
Was wir tun, damit es bleibt
Drei Praktiken, alle unspektakulär:
- Menschen am System halten. Kontinuität ist der ganze Mechanismus. Entwickler zur Auslastungssteuerung zu rotieren, setzt leise genau das zurück, wofür Sie bezahlen.
- Das “Warum” aufschreiben, nicht nur das “Was”. Entscheidungen und ihre Begründung gehören ins Repository, damit Wissen Urlaube, Krankheit und spätere Übergaben überlebt.
- Die operative Verantwortung übernehmen. Pipelines, Umgebungen, Monitoring. Wenn niemand im Team das System je bei einer Störung gesehen hat, kennt das Team das System nicht wirklich.
Der Punkt ist: Ein Dedicated Team ist eine Investition, die sich im zweiten Jahr stärker auszahlt als im ersten — aber nur, wenn sie so aufgesetzt ist, dass Wissen wächst statt sich zurückzusetzen. Wenn Ihr Partner dieses Jahr schon die dritte Besetzung schickt, kaufen Sie kein Dedicated Team. Sie mieten Stunden und bezahlen die Einarbeitung jedes Mal aufs Neue.
Wenn Sie ein Team wollen, das mit jedem Monat wertvoller wird: So arbeiten wir.