Forward deployed engineer: o modelo em que quem constrói trabalha dentro da sua empresa, e o que ele cobra

O nome descreve um lugar, não uma tecnologia

Um forward deployed engineer é o engenheiro que constrói dentro da empresa do cliente, no sistema dela e ao lado de quem vai usar o que está sendo construído — em vez de receber um documento, sumir por alguns meses e voltar com uma entrega. O nome vem do vocabulário de operações: destacado, na linha de frente, onde a coisa acontece.

A palavra que carrega o sentido é a segunda. Deployed não descreve uma habilidade técnica diferente — descreve onde a pessoa fica. Ela abre o sistema que a empresa usa de verdade, vê o dado real com todos os defeitos que ele tem, e escuta da própria pessoa que executa o processo por que aquele caso é diferente. Não há intermediário reescrevendo o problema no caminho.

Isso muda o que se produz. Num modelo de entrega tradicional, o artefato intermediário é a documentação: alguém traduz o processo em requisito, o requisito vira tarefa, e a construção acontece longe de quem descreveu. No modelo forward deployed, o artefato intermediário é a conversa, e a construção acontece contra o sistema real desde o primeiro dia. O que se perde em previsibilidade de plano se ganha em não construir a coisa errada.

De onde ele veio, e por que reapareceu agora

O cargo ganhou nome nas empresas de software de dados que vendiam para operações complexas — governo, defesa, indústria —, onde o produto só entregava valor depois de ser moldado ao caso do cliente. Reapareceu com a inteligência artificial aplicada pelo mesmo motivo: o que decide se um sistema funciona não está no produto, está no dado e na regra de quem o usa.

A Palantir é a referência mais citada, e o desenho dela é o que consolidou o termo: engenheiros que passam a maior parte do tempo no cliente, construindo em cima da plataforma para o caso concreto daquela operação. Desde então, o mesmo formato passou a aparecer em vagas de empresas de inteligência artificial — quem vende um modelo poderoso descobriu que a distância entre a demonstração e o uso é exatamente o trabalho que alguém precisa fazer dentro da empresa.

A razão de o modelo voltar agora é técnica, e vale entender. Um sistema com IA não falha como um sistema comum. Ele não quebra com erro na tela: ele responde com confiança a partir de um dado que estava desatualizado, ou aplica a regra geral a um caso que a sua empresa trata por exceção. Nenhuma dessas falhas aparece em ambiente de teste com dado de exemplo. Todas aparecem no primeiro contato com a operação de verdade.

O modelo contrário, e o que muda entre os dois

O oposto do forward deployed é a fábrica de software: a empresa descreve o que quer, o fornecedor se afasta para construir e volta com uma entrega. Não é um modelo ruim — é o modelo certo para escopo grande, estável e bem conhecido. Ele cobra quando o escopo é justamente o que ainda não se sabe.

A escolha entre os dois é de fase, não de qualidade. Escopo grande, estável e conhecido — a reescrita de um sistema que já existe, uma integração documentada — cabe bem na fábrica, e o processo dela é mais barato de coordenar. O que não cabe é o projeto em que a pergunta central ainda não tem resposta: como este processo funciona de verdade, e o que fazer com os casos que ninguém contou.

Por que a distância custa

Três coisas nunca chegam num documento de requisitos, e são as três que decidem se o sistema serve: a exceção que ninguém contou, o dado que não está onde o diagrama diz, e a regra que duas pessoas do mesmo time aplicam de formas diferentes. As três aparecem sentando ao lado de quem trabalha, e só assim.

A exceção que ninguém contou. Quem descreve o próprio trabalho descreve o caminho principal — é o que a memória entrega quando alguém pergunta “como funciona?”. As exceções não são omitidas por desatenção: elas são tão automáticas para quem executa que não parecem parte do processo. Elas reaparecem no dia em que o sistema trata como igual um caso que a empresa sempre tratou como diferente.

O dado que não está onde o diagrama diz. O campo existe, tem nome bonito no cadastro, e está preenchido em metade dos registros — ou está preenchido com outra coisa, porque em algum momento alguém passou a usar aquele campo para anotar o que não tinha lugar. Isso não aparece em reunião: aparece na primeira consulta ao banco de dados real.

A regra que cada um aplica diferente. Duas pessoas do mesmo time, com o mesmo caso na tela, decidem diferente — e as duas estão certas dentro do critério que cada uma carrega. Escrever a regra obriga a empresa a escolher uma das duas, e essa escolha é de gestão, não de engenharia. Quanto mais tarde ela aparece, mais caro sai.

Como funciona por dentro

Na prática, quatro coisas definem o modelo: o código nasce no repositório da empresa, o sistema roda na conta de nuvem dela, quem conversa sobre o processo é quem constrói, e o ciclo é curto o bastante para que a pessoa que executa veja o que foi feito enquanto ainda se lembra do que pediu.

O repositório é do cliente desde o primeiro commit. Não é detalhe jurídico: é o que permite que a empresa acompanhe o que está sendo feito, que outro fornecedor consiga continuar, e que a saída seja uma transição em vez de uma migração. Código que nasce do lado de lá e é transferido no fim chega sem histórico — e o histórico é metade da documentação de um sistema.

O sistema roda na conta da empresa. As credenciais são dela, a fatura é dela, e o acesso não depende de ninguém de fora continuar existindo. Isso costuma dar mais trabalho no começo — pedir acesso é sempre mais lento do que abrir uma conta nova — e é exatamente esse trabalho que se está comprando.

O ciclo é curto e a demonstração é a coisa rodando. Em vez de um documento de status, o que se mostra é a tela funcionando com o dado real, e quem assiste é quem vai usar. É o formato que faz a correção chegar cedo: a pessoa que executa reconhece o próprio trabalho na tela e diz o que está errado antes que aquilo vire fundação.

O que a sua empresa precisa dar em troca

O modelo pede quatro coisas do lado do cliente, e a falta de qualquer uma o transforma em fábrica com outro nome: acesso aos sistemas, tempo de quem executa o processo, um decisor disponível para as perguntas que travam, e o dado real em vez do de exemplo.

1. Acesso, e ele começa antes do projeto

   Contas, permissões, chaves de integração, ambiente de teste. Esse relógio quase nunca é o da equipe técnica — passa por segurança, por jurídico, às vezes por um fornecedor terceiro. Comece a pedir na semana da assinatura, e não na primeira reunião de trabalho.

2. Tempo de quem executa o processo hoje

   Algumas horas por semana da pessoa que faz aquilo na mão, não do gestor que descreve o que ela faz. É a fonte de tudo o que não está escrito, e é o insumo mais difícil de conseguir, porque essa pessoa é sempre a mais ocupada do time.

3. Um decisor com poder de escolher

   Quando a construção revela que dois times aplicam a regra diferente, alguém precisa escolher qual vence. Sem essa pessoa disponível, o projeto para de avançar num ponto que parece técnico e não é — e a espera custa o mesmo que o trabalho.

4. O dado real, com os defeitos que ele tem

   Anonimizado quando precisa ser, reduzido quando faz sentido, mas real. Sistema construído contra dado de exemplo funciona contra dado de exemplo; o campo preenchido pela metade e a duplicata que ninguém viu são parte do problema que se contratou para resolver.

Nada disso é gratuito, e é honesto dizer onde o modelo cobra. Ele consome atenção interna: uma empresa que não tem ninguém disponível para conversar sobre o próprio processo tem mais a ganhar com um produto de prateleira, que pede menos e entrega menos. A escolha é entre pagar em atenção agora ou em retrabalho depois.

O que fica quando o projeto acaba

Quatro coisas: o código no repositório da empresa, a infraestrutura no nome dela, a documentação de como subir e operar, e alguém de dentro que acompanhou a construção. Com as quatro, trocar de fornecedor é uma transição. Sem elas, é uma migração — que é um projeto por si, com prazo e orçamento próprios.

A documentação que importa não é o manual bonito. É o runbook: como se sobe o sistema do zero, o que fazer quando ele para, quais são as senhas e onde elas moram, que serviço externo ele depende e o que acontece se esse serviço cair. Um documento que outra pessoa consiga seguir sem ligar para ninguém — e o teste dele é literalmente esse.

A quarta é a que mais se esquece. Um sistema que ninguém de dentro acompanhou nascer é um sistema que a empresa tem e não conhece: ele funciona até o dia em que precisa mudar, e nesse dia toda mudança volta a ser um projeto externo. Nomear alguém para acompanhar não é fiscalização — é o que transforma a entrega em capacidade instalada.

O que se diz por aí e não se confirma

Três afirmações circulam sobre o modelo forward deployed sem apuração que as sustente, e as três confundem onde a pessoa trabalha com o que ela é contratada para fazer. A diferença entre os dois é o que separa este modelo de uma alocação de mão de obra.

Este guia também não traz estatística de mercado, e a ausência é decisão: os números que circulam sobre taxa de fracasso de projetos de software e sobre economia de custo com terceirização não passaram no critério da Kapstan — estudo nomeado, instituição, amostra, data de campo e endereço primário conferido na publicação.

As perguntas que se fazem antes de assinar

Cinco perguntas por escrito separam uma proposta forward deployed de uma proposta de fábrica com vocabulário emprestado. Nenhuma delas é sobre tecnologia, e um “não” em qualquer uma não é impedimento — é preço.

1. O repositório é meu, na minha conta, desde o primeiro dia?

   E não “no fim do projeto”. A diferença aparece no dia em que a relação termina mal: com o histórico do lado de cá, outro time continua; sem ele, recomeça.

2. Em que conta o sistema vai rodar, e no nome de quem está a fatura?

   Infraestrutura no nome do fornecedor é uma dependência que só aparece quando você quer sair. Se por algum motivo ela precisar começar assim, combine por escrito a data em que passa para o seu nome.

3. Quem conversa comigo sobre o processo é quem escreve o código?

   É a pergunta que identifica o modelo. Se há uma camada de conta entre você e quem constrói, o custo da tradução volta como retrabalho, e o prazo já o inclui.

4. O que vocês precisam de mim, e quando?

   Uma proposta honesta responde isso sem hesitar: quantas horas de quem executa, que acessos, e quem decide o que ninguém decidiu. Fornecedor que diz não precisar de nada está prometendo construir sem descobrir o que não está escrito.

5. O que existe no fim para que outra pessoa continue?

   Documentação de como subir, de como operar e de o que fazer quando quebra, mais alguém de dentro que acompanhou. Peça o índice desse documento na proposta — quem já entregou isso antes tem um.

O vocabulário mínimo

Cinco termos aparecem em toda conversa sobre este modelo e quase nunca são definidos por quem os usa. Eles estão aqui com o sentido que este guia lhes dá, e é o mesmo que os outros textos desta série usam.

Forward deployed

O modelo em que quem constrói trabalha dentro da empresa do cliente, no sistema dela e ao lado de quem usa. O nome descreve o lugar de trabalho, e não uma tecnologia ou uma senioridade.

Fábrica de software

O modelo em que o cliente descreve o que quer, o fornecedor constrói longe e volta com a entrega. Vence em escopo grande, estável e bem conhecido; cobra quando o escopo é justamente o que ainda não se sabe.

Alocação

Contratar tempo de uma pessoa para trabalhar sob a coordenação do cliente, sem escopo próprio. O que se compra é disponibilidade; quem responde pelo resultado é quem coordena — ou seja, a sua empresa.

Runbook

O documento de operação de um sistema: como subir do zero, o que fazer quando ele para, onde moram as credenciais e de que serviços externos ele depende. O teste dele é alguém de fora conseguir seguir sem telefonar para ninguém.

Transição

A passagem de um sistema para outro time quando código, infraestrutura e documentação já estão do lado do cliente. É o oposto de migração, que é reconstruir em outro lugar o que não veio junto — e essa é um projeto com prazo e orçamento próprios.

Perguntas frequentes