Entwickler einstellen oder technischen Partner holen: beide Wege durchrechnen

Sie haben die Idee für ein Trading-Terminal, ein Budget dafür und kein Entwicklungsteam. Die Frage danach wird fast immer als Preisvergleich gestellt: Was kostet es, Entwickler einzustellen, und was kostet es, eine Firma das Ding bauen und übergeben zu lassen.

Diese Rahmung verdeckt die Entscheidung. Beide Wege enden mit Code, der läuft. Sie unterscheiden sich darin, wann die erste nutzbare Version existiert, wer das System ein Jahr später versteht, was passiert, wenn eine Schlüsselperson geht, und was Sie in der Hand halten, wenn die Arbeit aufhört.

Beide Wege erzeugen Code; sie unterscheiden sich darin, wo das Wissen liegt

Ein Trading-Terminal ist nicht ein System. Es ist ein Marktdatenpfad, ein Order-Entry-Pfad, Pre-Trade-Risk-Checks, Konnektivität zu Venues oder Brokern, Positions- und Kontozustand, ein Bildschirm, der weiter neu zeichnen muss, während sich das Buch bewegt, und ein Back Office, das nach Handelsschluss alles abgleicht.

Wenn Sie einstellen, kaufen Sie dieses System nicht. Sie bauen die Organisation, die es hervorbringen wird, und das Wissen darüber, wie es funktioniert, startet bei null und sammelt sich in den Köpfen der Menschen, die Sie beschäftigen. Das ist ein Aktivposten, solange sie bleiben, und es ist das ganze Risiko, wenn sie es nicht tun.

Wenn Sie einen Partner beauftragen, kaufen Sie ein System plus eine Entscheidungshistorie, die anderswo bereits existiert. Das Wissen startet höher und sitzt am ersten Tag außerhalb Ihres Unternehmens. Ob es je nach innen wandert, ist eine Vertragsklausel und eine Arbeitspraxis, nichts, was von allein passiert.

Es hilft, konkret zu sagen, was Wissen über das System hier bedeutet, denn es ist nicht der Quellcode:

• Warum das Sequenzierungsschema genau dieses ist und welchen Fehlerfall es abweist, den ein einfacheres Schema durchlässt
• Welche Eigenheiten eines Venue die Konnektivitätsschicht umgeht und aus welchem Vorfall jeder Workaround entstanden ist
• Die Reihenfolge, in der die Risk-Checks laufen, und was das System tut, wenn einer nicht rechtzeitig antwortet
• Die Recovery-Prozedur, wenn der Marktdaten-Feed ein Gap hat und das Buch mitten in der Session neu aufgebaut werden muss
• Welche Tests tragend sind und welche nur wie Abdeckung aussehen
• Wie der Deploy-Pfad an einem volatilen Morgen aussieht und wer ihn ausführen darf

Nichts davon liegt von allein in einem Repository. Es liegt in einem Menschen, bis ein Prozess es ins Geschriebene zwingt - ob dieser Mensch Ihr Angestellter ist oder ein Entwickler des Partners.

Die erste nutzbare Version entscheidet sich vor dem ersten Commit

Vor dem Einstellungsweg liegt eine Warteschlange, die Budget nicht auflöst. Sie schreiben eine Rolle, die Sie fachlich vertreten können, suchen in einem Markt, in dem Trading-Entwickler rar sind, führen Interviews zu Fähigkeiten, die im eigenen Haus noch niemand beurteilen kann, sitzen Kündigungsfristen aus und sehen dann auf der ersten Strecke zu, wie ein neues Team über eine Architektur streitet, statt eine zu bauen.

Der Partnerweg beginnt beim Scope statt bei der Suche, und daher kommt der Zeitunterschied. Was er nicht abnimmt, ist die Arbeit, die nur Sie tun können: wofür das Terminal da ist, welche Instrumente und Venues zuerst zählen und wer die ersten Nutzer sind.

Und ein Teil des Zeitplans gehört zu keinem der beiden Wege. Diese Posten laufen im eigenen Tempo, egal wer den Code schreibt:

• Onboarding bei Broker oder Venue und der Papierkram dahinter
• Conformance-Tests in der Testumgebung des Venue, in Fenstern, die das Venue plant und nicht Sie
• Marktdaten-Lizenzierung, die entscheidet, was Sie anzeigen und an wen Sie weiterverteilen dürfen
• Uhrensynchronisation, Audit-Trails und die Aufzeichnungspflichten, die Ihr Regulator erwartet
• Die Bereitschaft der ersten Nutzer, echte Orders durch ein neues System zu leiten
• Ihre eigenen Produktentscheidungen, besonders die zwei, die einander widersprechen

Der ehrliche Vergleich ist also kein Rennen zwischen zwei Lieferterminen. Es ist die Frage, welcher Weg weniger Dinge vor die Arbeit stellt, die Sie nicht beeinflussen können, und welcher die beeinflussbaren Teile früher beginnt.

Was jeder Weg tut, wenn eine Schlüsselperson geht

Stellen Sie beiden Wegen dieselbe Frage. Wenn der Entwickler, der den Marktdaten-Handler geschrieben hat, am Montag aufhört: Was passiert am Dienstag, und was passiert im Quartal danach.

In einem kleinen Team, das Sie eingestellt haben, hängt die Antwort meist an einem Namen. Frühe Teams bündeln Wissen von Natur aus: Eine Person besitzt den Hot Path, eine andere die Konnektivität, und die Roadmap ordnet sich still um denjenigen herum, der noch da ist. Bei einem Partner hängt es davon ab, ob dort mehr als ein Entwickler den Code gelesen hat, und davon, ob Ihr Vertrag das festhält.

Keine der beiden Strukturen ist für sich sicher. Ein Partner mit einem einzigen Entwickler auf Ihrem Account ist genauso exponiert wie ein zweiköpfiges Inhouse-Team, und die Absicherung ist in beiden Fällen dieselbe: Wissen wird aufgeschrieben, während es entsteht, statt später rekonstruiert.

• Eine Design-Notiz je Subsystem: was es tut, was es bewusst nicht tut und woran es zerbricht
• Entscheidungsprotokolle mit den geprüften Alternativen, im Repository neben dem Code, den sie erklären
• Tests, die eine aufgezeichnete Session wieder abspielen, sodass ein Fehler exakt reproduziert statt bestritten wird
• Mindestens zwei Personen, die Änderungen an jedem kritischen Pfad gemergt haben - eine Personalregel, keine Dokumentationsregel
• Ein Runbook für jeden Vorfall, der tatsächlich passiert ist, geschrieben in der Woche, in der er passiert ist
• Ein Deploy- und Rollback-Pfad, den jeder Entwickler im Bereitschaftsdienst ausführen kann, ohne jemanden für ein Passwort zu wecken

Die Übergabe ist ein Liefergegenstand mit Abnahmetest, keine E-Mail am Ende

Das Wort Übergabe deckt zwei sehr verschiedene Ereignisse ab. Das eine ist eine Übergabe von Dateien. Das andere ist die Übergabe der Fähigkeit, ohne die Erbauer weiterzumachen, und nur das zweite ist das Geld wert.

Schreiben Sie das zweite in den Scope, als Liste von Artefakten mit je einem Abnahmetest daran. Eine vernünftige Liste sieht so aus:

• Repositories mit ihrer vollen Historie, kein Archiv des Endzustands - in der Historie steckt die Begründung
• Ein Build, den ein neuer Entwickler auf einer sauberen Maschine anhand der schriftlichen Schritte reproduziert, ohne undokumentiertes lokales Setup
• Infrastruktur als Code beschrieben, zusammen mit den Umgebungen, die daraus entstehen, und den Unterschieden zwischen ihnen
• Secrets in Ihrer Hand, mit einer Rotationsprozedur, die mindestens einmal ausgeführt und nicht nur beschrieben wurde
• Deployment- und Rollback-Runbooks, ausgeführt von Ihrer Seite, während der Partner zusieht und nichts sagt
• Monitoring, Alert-Schwellen und eine Zeile je Alert, die erklärt, was er bedeutet und was zu tun ist
• Protokoll- und Nachrichtenspezifikationen für jede externe Verbindung, samt der Felder, die Sie nutzen, und derer, die Sie ignorieren
• Die Testsuite, dazu eine Vorführung absichtlich fehlschlagender Tests, damit Sie sehen, was sie fangen
• Ein benannter Zeitraum, in dem Ihre Entwickler die Änderungen machen und der Partner sie nur reviewt

Eine Übergabe, die nie geprobt wurde, ist ein Plan und kein Liefergegenstand. Proben Sie sie mitten im Build, nicht nach der Schlussrechnung, und die Probe ist einfach: Ihre Entwickler deployen eine Änderung und rollen sie zurück, während die Leute zusehen, die das System geschrieben haben.

Eigentum ist eine eigene Frage neben der Übergabe, und sie wird im Vertrag geklärt, bevor die Arbeit beginnt, statt am Ende entdeckt zu werden. Unsere eigene Antwort ist ein Satz, und wir kürzen ihn in keiner Fassung keines Dokuments.

Zwischen den beiden Antworten liegen drei Formate

Die Frage wird meist binär gestellt - ein Team einstellen oder die ganze Sache abgeben. In der Praxis liegen die meisten Projekte zwischen diesen Polen, und die Position darf sich verschieben, während das System reift.

Drei Formate: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. So beschreiben wir unsere eigene Seite davon, und der Unterschied zwischen den dreien ist nicht die Rechnung - es ist, wer den Plan hält, wer die Prioritäten hält und wer für das Ergebnis geradesteht.

• Vollständige Umsetzung: Der Partner hält Plan, Reihenfolge und Ergebnis; Sie halten Produktentscheidungen und Abnahme. Passt zu einer ersten Version mit einem Scope, den Sie definieren können, und ohne Team, das schon zu führen wäre
• Ein dediziertes Team: Ihr Backlog und Ihre Prioritäten, deren Leute arbeiten an Ihrem Produkt und an nichts anderem. Passt zu der Phase, in der sich der Scope schneller bewegt, als ein fester Plan verträgt
• In Ihr Team eingebettete Entwickler: Ihr Prozess, Ihr Code Review, deren Spezialisten auf den Pfaden, wo ein Fehler teuer ist - der Order-Pfad, die Venue-Konnektivität, die Recovery-Prozedur
• Die drei sind Stufen und keine sich ausschließenden Optionen. Ein Projekt kann als vollständige Umsetzung beginnen und mit zwei Entwicklern in einem Team enden, das Sie eingestellt haben, während das System geschrieben wurde

Dieser letzte Punkt löst den größten Teil der ursprünglichen Frage auf. Die stärkste Variante des Partnerwegs plant von Anfang an Ihr eigenes Team mit: Sie stellen gegen ein System ein, das bereits existiert, Ihre Interviews orientieren sich am Code, den der Kandidat pflegen wird, und das Erste, was eine neue Kraft liest, ist ein Entscheidungsprotokoll statt eines leeren Repositorys.

Beide Wege durchrechnen, auch die Posten ohne Rechnung

Ein Satzvergleich ist die am wenigsten nützliche Zahl in dieser Entscheidung, weil die beiden Wege in unterschiedlichen Einheiten abrechnen. Legen Sie beide Listen nebeneinander und rechnen Sie sie ehrlich durch.

Der Einstellungsweg berechnet Ihnen:

• Recruiting-Zeit und die Kosten einer Fehlbesetzung in einem Spezialistenmarkt, in dem eine Fehlbesetzung spät auffällt
• Arbeitgeberkosten, Ausstattung, Lizenzen und die Marktdaten-Subscriptions, die eine Entwicklungsumgebung braucht, bevor sie irgendetwas produziert
• Führungsaufmerksamkeit - jemand muss das Team führen, und am Anfang sind das meist Sie
• Die erste Architekturentscheidung, zweimal getroffen, einmal falsch - der normale Preis dafür, dass ein Team die Domäne an Ihrem Projekt lernt
• Kapazität, die den Build überdauert, wenn ein für den Bau dimensioniertes Team größer ist, als die Wartung braucht
• Eine laufende Verpflichtung, die weiterläuft, ob die Roadmap dieses Quartal klar ist oder nicht

Der Partnerweg berechnet Ihnen:

• Ein Satz, der Spezialisten mitträgt, die Sie allein nie in Vollzeit auslasten würden - etwa einen Entwickler, der schon einmal ein Protokoll auf Session-Ebene debuggt hat
• Koordination über eine Grenze hinweg - echte Arbeit, die in geschriebenen Spezifikationen bezahlt wird statt in Flurgesprächen
• Eine Abhängigkeit, die genau so lange dauert, wie die Übergabe ungetestet bleibt
• Das Risiko, dass wiederverwendbare Komponenten auf eine Weise tragend sind, die niemand aufgeschrieben hat - deshalb wird die Eigentumsklausel vor der Unterschrift gelesen
• Die Kosten des Spezifizierens: Ein Partner ist nur so genau wie die Entscheidungen, die Sie übergeben

Rechnen Sie dann die Ausstiege durch, denn beide Wege haben einen. Der Einstellungsweg endet damit, ein aufgebautes Team zu verkleinern, und das Wissen geht in diesen Köpfen hinaus. Der Partnerweg endet mit einer Übergabe, die Sie entweder geprobt haben oder nicht, und der Abstand zwischen diesen beiden Enden ist das Risiko des Weges.

Bevor Sie etwas unterschreiben, prüfen Sie beide Optionen mit einer Frage: Wenn das hier am Freitag aufhört, was halten wir am Montag noch in der Hand. Beantworten Sie sie in Artefakten - Repositories, reproduzierbare Umgebungen, Dokumentation und Menschen, die das System daraus wieder aufbauen können -, denn Absichten überleben einen Weggang nicht, Artefakte schon.

Was amBrain öffentlich belegen kann: Wir bauen seit 2019 von Jerewan, Armenien, aus Software, mit Hot Paths in Rust, wir haben das Trading-Terminal Spectre Trade gebaut, und eine von uns gebaute Mini-Börse läuft in Produktion in der MOEX-Kolokation. Wenn Sie für ein eigenes Terminal zwischen Einstellen und Partner abwägen, nehmen Sie die Übergabeliste von oben ins erste Gespräch mit und bitten Sie Ihr Gegenüber - uns eingeschlossen - darum, sie Zeile für Zeile zu beantworten.