Contratar engenheiros ou trazer um parceiro técnico: como calcular os dois caminhos

Você tem a ideia de um terminal de trading, orçamento para ele e nenhum time de engenharia. A pergunta que vem em seguida quase sempre é enquadrada como comparação de preço: quanto custa contratar engenheiros e quanto custa uma empresa construir a coisa e entregá-la.

Esse enquadramento esconde a decisão. Os dois caminhos terminam em código que roda. A diferença é quando existe a primeira versão utilizável, quem entende o sistema um ano depois, o que acontece quando uma pessoa-chave sai e o que você tem na mão se o trabalho parar.

Os dois caminhos produzem código; a diferença é onde mora o conhecimento

Um terminal de trading não é um sistema só. É um caminho de dados de mercado, um caminho de entrada de ordens, checagens de risco pré-negociação, conectividade com venues ou corretoras, estado de posição e de conta, uma tela que precisa continuar redesenhando enquanto o book se mexe e um back office que reconcilia tudo isso depois do fechamento.

Quando você contrata, não está comprando esse sistema. Está construindo a organização que vai produzi-lo, e o conhecimento de como ele funciona começa do zero e se acumula dentro da cabeça das pessoas que você emprega. Isso é um ativo enquanto elas ficam e é todo o risco quando elas não ficam.

Quando você contrata um parceiro, está comprando um sistema mais um histórico de decisões que já existe em outro lugar. O conhecimento começa mais alto e, no primeiro dia, fica fora da sua empresa. Se ele vai entrar algum dia é cláusula de contrato e prática de trabalho, não algo que acontece sozinho.

Vale ser concreto sobre o que significa conhecimento do sistema aqui, porque não é o código-fonte:

• Por que o esquema de sequenciamento é o que é, e qual falha ele rejeita que um esquema mais simples aceita
• Quais comportamentos de venue a camada de conectividade contorna, e de qual incidente cada contorno saiu
• A ordem em que as checagens de risco rodam, e o que o sistema faz quando uma delas não responde a tempo
• O procedimento de recuperação quando o feed de dados de mercado abre um gap e o book precisa ser reconstruído no meio da sessão
• Quais testes são estruturais e quais apenas parecem cobertura
• Qual é o caminho de deploy em uma manhã volátil, e quem tem permissão para executá-lo

Nada disso mora em um repositório por padrão. Mora em uma pessoa até que um processo obrigue a colocar por escrito, seja essa pessoa um funcionário seu ou um engenheiro do parceiro.

A primeira versão utilizável se decide antes do primeiro commit

O caminho da contratação tem uma fila na frente que o orçamento não elimina. Você escreve uma vaga que consegue defender tecnicamente, busca candidatos em um mercado em que engenheiros de trading são escassos, entrevista competências que ninguém dentro da sua empresa ainda sabe avaliar, espera os avisos prévios e, depois, passa o primeiro trecho vendo um time novo discutir uma arquitetura em vez de construí-la.

O caminho do parceiro começa no escopo, e não na busca por pessoas, e é daí que vem a diferença de tempo. O que ele não elimina é o trabalho que só você pode fazer: decidir para que serve o terminal, quais instrumentos e venues importam primeiro e quem são os primeiros usuários.

E parte do cronograma não pertence a nenhum dos dois caminhos. Estes itens correm no próprio ritmo, não importa quem escreve o código:

• Onboarding em corretora ou venue, e a papelada que vem atrás disso
• Testes de conformidade no ambiente de teste da venue, em janelas que a venue agenda e você não
• Licenciamento de dados de mercado, que decide o que você pode exibir e para quem pode redistribuir
• Sincronização de relógio, trilhas de auditoria e a guarda de registros que o seu regulador exigir
• Os primeiros usuários aceitarem rotear ordens reais por um sistema novo
• As suas próprias decisões de produto, especialmente as duas que se contradizem

Então a comparação honesta não é uma corrida entre duas datas de entrega. É a pergunta de qual caminho coloca menos coisas fora do seu controle na frente do trabalho, e qual deles começa mais cedo as partes que você controla.

O que cada caminho faz quando uma pessoa-chave sai

Faça a mesma pergunta aos dois caminhos. Se o engenheiro que escreveu o handler de dados de mercado parar de trabalhar na segunda-feira, o que acontece na terça, e o que acontece no trimestre seguinte.

Em um time pequeno que você contratou, a resposta costuma depender de um nome. Times iniciais concentram conhecimento por construção: uma pessoa cuida do hot path, outra cuida da conectividade, e o roadmap se reorganiza silenciosamente em torno de quem ainda está lá. Em um arranjo com parceiro, depende de mais de um engenheiro de lá ter lido o código, e de o seu contrato dizer isso.

Nenhuma das duas estruturas é segura por si só. Um parceiro com um único engenheiro na sua conta está exposto do mesmo jeito que um time interno de duas pessoas, e a defesa é idêntica nos dois casos: conhecimento escrito enquanto é criado, em vez de reconstruído depois.

• Uma nota de design por subsistema dizendo o que ele faz, o que ele deliberadamente se recusa a fazer e o que o quebra
• Registros de decisão com as alternativas consideradas, guardados no repositório ao lado do código que explicam
• Testes que reproduzem uma sessão capturada, para que uma falha seja reproduzida exatamente em vez de discutida
• Pelo menos duas pessoas que já integraram mudanças em cada caminho crítico - uma regra de equipe, não de documentação
• Um runbook para cada incidente que realmente aconteceu, escrito na semana em que aconteceu
• Um caminho de deploy e rollback que qualquer engenheiro de plantão consegue executar sem acordar alguém para pedir uma senha

O handover é um entregável com teste de aceitação, não um e-mail no fim

A palavra handover cobre dois eventos muito diferentes. Um é a transferência de arquivos. O outro é a transferência da capacidade de seguir em frente sem as pessoas que construíram o sistema, e só o segundo vale o que se paga.

Escreva o segundo no escopo como uma lista de artefatos, cada um com um teste de aceitação. Uma lista razoável se parece com esta:

• Repositórios com o histórico completo, não um arquivo do estado final - o histórico é onde está o raciocínio
• Um build que um engenheiro novo reproduz em uma máquina limpa a partir dos passos escritos, sem nenhuma configuração local não documentada
• Infraestrutura descrita como código, junto com os ambientes que ela produz e as diferenças entre eles
• Segredos sob a sua guarda, com um procedimento de rotação que já foi executado pelo menos uma vez, e não apenas descrito
• Runbooks de deploy e de rollback, executados pelo seu lado enquanto o parceiro observa e não diz nada
• Monitoramento, limiares de alerta e uma linha por alerta explicando o que ele significa e o que fazer a respeito
• Especificações de protocolo e de mensagens para cada conexão externa, incluindo os campos que você usa e os que ignora
• A suíte de testes, mais uma demonstração de testes falhando de propósito, para você ver o que eles pegam
• Um período determinado em que os seus engenheiros fazem as mudanças e o parceiro apenas as revisa

Um handover que nunca foi ensaiado é um plano, não um entregável. Ensaie no meio da construção, não depois da última fatura, e o ensaio é simples: os seus engenheiros publicam uma mudança e fazem rollback enquanto quem escreveu o sistema observa.

A propriedade é uma questão separada do handover, e se resolve no contrato antes de o trabalho começar, em vez de ser descoberta no fim. A nossa resposta cabe em uma frase, e não a encurtamos em nenhuma versão de nenhum documento.

Três formatos ficam entre as duas respostas

A pergunta costuma ser colocada como um binário - contratar um time ou entregar tudo para outra pessoa. Na prática, a maioria dos projetos fica entre esses polos, e essa posição pode mudar conforme o sistema amadurece.

Três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. É assim que descrevemos o nosso lado, e a diferença entre os três não é a fatura - é quem assume o plano, quem assume as prioridades e quem responde pelo resultado.

• Entrega completa: o parceiro assume o plano, a ordem das etapas e o resultado; você assume as decisões de produto e o aceite. Serve a uma primeira versão com escopo que você consegue definir e sem time para gerenciar ainda
• Time dedicado: o seu backlog e as suas prioridades, com as pessoas do parceiro trabalhando no seu produto e em nada mais. Serve à fase em que o escopo muda mais rápido do que um plano fixo tolera
• Engenheiros embarcados no seu time: o seu processo, o seu code review, os especialistas do parceiro nos caminhos em que um erro sai caro - o caminho da ordem, a conectividade com venues, o procedimento de recuperação
• Os três são etapas, não opções excludentes. Um projeto pode começar como entrega completa e terminar com dois engenheiros dentro de um time que você contratou enquanto o sistema era escrito

Esse último ponto dissolve boa parte da pergunta original. A versão mais forte do caminho com parceiro já planeja o seu próprio time desde o início: você contrata tendo um sistema que já existe, as suas entrevistas são guiadas pelo código que a pessoa vai manter, e a primeira coisa que alguém recém-contratado lê é um registro de decisão, e não um repositório em branco.

Faça as contas dos dois caminhos, inclusive do que nunca aparece na fatura

A comparação de taxa horária é o número menos útil desta decisão, porque os dois caminhos cobram de você em unidades diferentes. Coloque as duas listas lado a lado e faça as contas com honestidade.

O caminho da contratação cobra de você:

• Tempo de recrutamento e o custo de uma contratação errada em um mercado de especialistas, onde o erro é descoberto tarde
• Encargos de empregador, equipamentos, licenças e as assinaturas de dados de mercado que um ambiente de desenvolvimento consome antes de produzir qualquer coisa
• Atenção de gestão - alguém precisa tocar o time, e no começo esse alguém costuma ser você
• A primeira decisão de arquitetura tomada duas vezes, uma delas errada, que é o preço normal de um time aprendendo o domínio no seu projeto
• Capacidade que sobrevive ao projeto, quando um time dimensionado para construir é maior do que a manutenção exige
• Uma obrigação permanente que segue existindo esteja o roadmap claro ou não neste trimestre

O caminho do parceiro cobra de você:

• Uma taxa que carrega especialistas que você nunca manteria ocupados em tempo integral sozinho, como um engenheiro que já depurou um protocolo em nível de sessão
• Coordenação através de uma fronteira, que é trabalho de verdade e se paga em especificações escritas, não em conversa de corredor
• Uma dependência que dura exatamente enquanto o handover continuar sem teste
• O risco de componentes reutilizáveis serem estruturais de maneiras que ninguém escreveu, e é por isso que a cláusula de propriedade precisa ser lida antes da assinatura
• O custo de especificar: um parceiro é tão preciso quanto as decisões que você entrega

Depois faça as contas das saídas, porque os dois caminhos têm uma. O caminho da contratação termina reduzindo um time que você montou, e o conhecimento sai junto naquelas cabeças. O caminho do parceiro termina com um handover que você ensaiou ou não ensaiou, e a distância entre esses dois finais é o risco do caminho.

Antes de assinar qualquer coisa, passe as duas opções por uma pergunta: se isto parasse na sexta-feira, o que ainda teríamos na mão na segunda. Responda em artefatos - repositórios, ambientes reproduzíveis, documentação e pessoas capazes de reconstruir o sistema a partir deles - porque intenções não sobrevivem a uma saída e artefatos sobrevivem.

O que a amBrain pode sustentar publicamente: construímos software desde 2019 a partir de Yerevan, Armênia, com os hot paths escritos em Rust, construímos o terminal de trading Spectre Trade, e uma mini-exchange que construímos roda em produção na colocation da MOEX. Se você está pesando contratação contra parceiro para um terminal seu, leve a lista de handover acima para a primeira conversa e peça a quem estiver do outro lado da mesa, nós inclusive, que a responda linha por linha.