Recruter des ingénieurs ou prendre un partenaire technique : chiffrer les deux voies

Vous avez l'idée d'un terminal de trading, un budget pour le faire, et pas d'équipe d'ingénierie. La question qui suit est presque toujours posée comme une comparaison de prix : combien coûte le recrutement d'ingénieurs, et combien coûte le fait de confier la construction à une société qui vous la remet ensuite.

Ce cadrage cache la décision. Les deux voies finissent par du code qui tourne. Elles diffèrent par le moment où existe la première version utilisable, par qui comprend le système un an plus tard, par ce qui se passe quand une personne clé part, et par ce que vous détenez si le travail s'arrête.

Les deux voies produisent du code ; ce qui diffère, c'est où vit la connaissance

Un terminal de trading n'est pas un système. C'est un chemin de données de marché, un chemin de saisie d'ordres, des contrôles de risque pre-trade, la connectivité aux places de marché ou aux brokers, l'état des positions et des comptes, un écran qui doit continuer à se redessiner pendant que le carnet bouge, et un back office qui réconcilie tout cela après la clôture.

Quand vous recrutez, vous n'achetez pas ce système. Vous construisez l'organisation qui le produira, et la connaissance de son fonctionnement part de zéro et s'accumule dans la tête des gens que vous employez. C'est un actif tant qu'ils restent, et c'est tout le risque quand ils partent.

Quand vous contractez avec un partenaire, vous achetez un système plus un historique de décisions qui existe déjà ailleurs. La connaissance démarre plus haut et se trouve hors de votre entreprise dès le premier jour. Qu'elle entre un jour à l'intérieur est une clause de contrat et une pratique de travail, pas quelque chose qui arrive tout seul.

Il vaut mieux être concret sur ce que veut dire ici la connaissance du système, car ce n'est pas le code source :

• Pourquoi le schéma de séquencement est celui-là, et quelle panne il rejette qu'un schéma plus simple accepte
• Quels comportements de place de marché la couche de connectivité contourne, et de quel incident est sorti chaque contournement
• L'ordre dans lequel s'exécutent les contrôles de risque, et ce que fait le système quand l'un d'eux ne répond pas à temps
• La procédure de reprise quand le flux de données de marché fait un gap et que le carnet doit être reconstruit en pleine séance
• Quels tests sont porteurs et lesquels ne font que ressembler à de la couverture
• Ce qu'est le chemin de déploiement un matin agité, et qui a le droit de l'exécuter

Rien de tout cela ne vit dans un dépôt par défaut. Cela vit dans une personne jusqu'à ce qu'un processus le force à l'écrit, que cette personne soit votre salarié ou un ingénieur du partenaire.

La première version utilisable se décide avant le premier commit

La voie du recrutement a devant elle une file d'attente que le budget n'enlève pas. Vous rédigez un poste que vous pouvez défendre techniquement, vous sourcez sur un marché où les ingénieurs de trading sont rares, vous faites passer des entretiens sur des compétences que personne chez vous ne sait encore évaluer, vous attendez les préavis, puis vous passez la première période à regarder une nouvelle équipe débattre d'une architecture au lieu d'en construire une.

La voie du partenaire commence au périmètre plutôt qu'au sourcing, et c'est de là que vient l'écart de temps. Ce qu'elle n'enlève pas, c'est le travail que vous seul pouvez faire : décider à quoi sert le terminal, quels instruments et quelles places de marché comptent d'abord, et qui sont les premiers utilisateurs.

Et une partie du calendrier n'appartient à aucune des deux voies. Ces éléments avancent à leur propre rythme, peu importe qui écrit le code :

• L'onboarding chez un broker ou une place de marché, et la paperasse qui va avec
• Les tests de conformité dans l'environnement de test de la place de marché, dans des fenêtres que la place planifie et vous non
• Les licences de données de marché, qui décident de ce que vous avez le droit d'afficher et à qui vous pouvez le redistribuer
• La synchronisation d'horloge, les pistes d'audit et la conservation des enregistrements qu'exige votre régulateur
• Des premiers utilisateurs prêts à router de vrais ordres à travers un système qui est neuf
• Vos propres décisions produit, en particulier les deux qui se contredisent

La comparaison honnête n'est donc pas une course entre deux dates de livraison. C'est la question de savoir quelle voie met le moins de choses hors de votre influence devant le travail, et laquelle démarre plus tôt les parties que vous pouvez influencer.

Ce que fait chaque voie quand une personne clé part

Posez la même question aux deux voies. Si l'ingénieur qui a écrit le handler de données de marché arrête lundi, que se passe-t-il mardi, et que se passe-t-il le trimestre suivant.

Dans une petite équipe que vous avez recrutée, la réponse tient en général à un seul nom. Les équipes du début concentrent la connaissance par construction : une personne possède le hot path, une autre la connectivité, et la roadmap se réorganise discrètement autour de qui est encore là. Chez un partenaire, cela dépend de si plus d'un ingénieur y a lu le code, et de si votre contrat le dit.

Aucune des deux structures n'est sûre en soi. Un partenaire avec un seul ingénieur sur votre compte est exposé exactement comme une équipe interne de deux personnes, et la défense est la même dans les deux cas : une connaissance écrite au moment où elle se crée, plutôt que reconstruite après coup.

• Une note de conception par sous-système disant ce qu'il fait, ce qu'il refuse délibérément de faire, et ce qui le casse
• Des décisions consignées avec les alternatives envisagées, gardées dans le dépôt à côté du code qu'elles expliquent
• Des tests qui rejouent une session capturée, pour qu'une panne soit reproduite exactement au lieu d'être débattue
• Au moins deux personnes ayant mergé des changements sur chaque chemin critique - une règle d'effectif, pas une règle de documentation
• Un runbook pour chaque incident réellement survenu, écrit la semaine où il est survenu
• Un chemin de déploiement et de rollback que n'importe quel ingénieur d'astreinte peut exécuter sans réveiller quelqu'un pour un mot de passe

La passation est un livrable avec un test de recette, pas un e-mail à la fin

Le mot passation recouvre deux événements très différents. L'un est un transfert de fichiers. L'autre est un transfert de la capacité à continuer sans les gens qui ont construit le système, et seul le second vaut d'être payé.

Écrivez le second dans le périmètre sous forme d'une liste d'artefacts, avec un test de recette attaché à chacun. Une liste raisonnable ressemble à ceci :

• Les dépôts avec tout leur historique, pas une archive de l'état final - l'historique est là où se trouve le raisonnement
• Un build qu'un nouvel ingénieur reproduit sur une machine vierge à partir des étapes écrites, sans configuration locale non documentée
• L'infrastructure décrite comme du code, avec les environnements qu'elle produit et la façon dont ils diffèrent
• Les secrets détenus par vous, avec une procédure de rotation qui a été exécutée au moins une fois plutôt que décrite
• Des runbooks de déploiement et de rollback, exécutés par votre camp pendant que le partenaire regarde sans rien dire
• La supervision, les seuils d'alerte, et une ligne par alerte expliquant ce qu'elle signifie et quoi faire
• Les spécifications de protocole et de messages pour chaque connexion externe, y compris les champs que vous utilisez et ceux que vous ignorez
• La suite de tests, plus une démonstration de tests qu'on fait échouer exprès, pour que vous voyiez ce qu'ils attrapent
• Une période nommée pendant laquelle vos ingénieurs font les changements et le partenaire se contente de les relire

Une passation jamais répétée est un plan, pas un livrable. Répétez-la au milieu du projet, pas après la dernière facture, et la répétition est simple : vos ingénieurs déploient un changement puis le rollback pendant que ceux qui ont écrit le système regardent.

La propriété est une question distincte de la passation, et elle se règle dans le contrat avant le début du travail plutôt qu'elle ne se découvre à la fin. Notre propre réponse tient en une phrase, et nous ne la raccourcissons dans aucune version d'aucun document.

Trois formats se glissent entre les deux réponses

La question est en général posée en binaire - recruter une équipe ou confier le tout à quelqu'un d'autre. En pratique, la plupart des projets se situent entre ces deux pôles, et cette position a le droit de changer à mesure que le système mûrit.

Trois formats : prestation complète, équipe dédiée, ou ingénieurs intégrés à votre équipe. C'est ainsi que nous décrivons notre propre côté, et la différence entre les trois n'est pas la facture - c'est qui tient le plan, qui tient les priorités, et qui répond du résultat.

• Prestation complète : le partenaire tient le plan, l'enchaînement et le résultat ; vous tenez les décisions produit et la recette. Cela convient à une première version au périmètre définissable, sans équipe à gérer pour l'instant
• Équipe dédiée : votre backlog et vos priorités, leurs gens sur votre produit et rien d'autre. Cela convient au stade où le périmètre bouge plus vite qu'un plan figé ne le tolère
• Ingénieurs intégrés à votre équipe : votre processus, votre code review, leurs spécialistes sur les chemins où une erreur coûte cher - le chemin d'ordre, la connectivité aux places de marché, la procédure de reprise
• Les trois sont des étapes plutôt que des options exclusives. Un projet peut démarrer en prestation complète et finir avec deux ingénieurs dans une équipe que vous avez recrutée pendant que le système s'écrivait

Ce dernier point dissout l'essentiel de la question de départ. La meilleure version de la voie partenaire prévoit votre propre équipe dès le début : vous recrutez face à un système qui existe déjà, vos entretiens sont éclairés par le code que le candidat maintiendra, et la première chose que lit un nouvel arrivant est une décision consignée plutôt qu'un dépôt vide.

Chiffrez les deux voies, y compris ce qui n'apparaît sur aucune facture

La comparaison des tarifs est le chiffre le moins utile de cette décision, parce que les deux voies vous facturent dans des unités différentes. Mettez les deux listes côte à côte et chiffrez-les honnêtement.

La voie du recrutement vous facture :

• Le temps de recrutement, et le coût d'une mauvaise embauche sur un marché de spécialistes où la mauvaise embauche se découvre tard
• Les charges patronales, le matériel, les licences, et les abonnements aux données de marché dont un environnement de développement a besoin avant de produire quoi que ce soit
• L'attention managériale - quelqu'un doit diriger l'équipe, et au début ce quelqu'un, c'est en général vous
• La première décision d'architecture prise deux fois, dont une fois de travers, ce qui est le prix normal d'une équipe qui apprend un domaine sur votre projet
• Une capacité qui survit au projet, quand une équipe dimensionnée pour la construction est plus grande que ce qu'exige la maintenance
• Une charge permanente qui court, que la roadmap soit claire ce trimestre ou non

La voie du partenaire vous facture :

• Un tarif qui embarque des spécialistes que vous n'occuperiez jamais à plein temps seul, comme un ingénieur qui a déjà débogué un protocole au niveau session
• La coordination par-dessus une frontière, qui est un vrai travail et se paie en spécifications écrites plutôt qu'en conversations de couloir
• Une dépendance qui dure exactement tant que la passation reste non testée
• Le risque que des composants réutilisables soient porteurs d'une manière que personne n'a écrite, et c'est pourquoi la clause de propriété se lit avant la signature
• Le coût de la spécification : un partenaire n'est jamais plus précis que les décisions que vous lui transmettez

Chiffrez ensuite les sorties, car les deux voies en ont une. La voie du recrutement se termine en réduisant une équipe que vous avez bâtie, et la connaissance s'en va dans ces têtes-là. La voie du partenaire se termine par une passation que vous avez répétée ou non, et la distance entre ces deux fins, c'est le risque de la voie.

Avant de signer quoi que ce soit, passez les deux options par une seule question : si tout s'arrêtait vendredi, que détiendrions-nous encore lundi. Répondez en artefacts - dépôts, environnements reproductibles, documentation, et gens capables de reconstruire le système à partir de tout cela - parce que les intentions ne survivent pas à un départ, et les artefacts si.

Ce qu'amBrain peut étayer publiquement : nous construisons des logiciels à Erevan, en Arménie, depuis 2019, avec les hot paths écrits en Rust, nous avons construit le terminal de trading Spectre Trade, et une mini-bourse que nous avons construite tourne en production en colocation MOEX. Si vous pesez un recrutement contre un partenaire pour votre propre terminal, emmenez la liste de passation ci-dessus dans la première conversation et demandez à celui qui est en face, nous compris, d'y répondre ligne par ligne.