Equipe interna ou terceirizar o desenvolvimento de software?

O sistema virou peça central da operação. Pedidos, estoque, faturamento e atendimento passam por ele, e a lista de melhorias não para de crescer. Em algum momento, alguém na diretoria pergunta: "não seria melhor ter nossa própria equipe de desenvolvimento?". Outro responde que contratar programador é difícil e caro. Um terceiro lembra do fornecedor que sumiu e deixou o código sem documentação.

A conversa costuma travar porque cada pessoa está comparando coisas diferentes. Uma pensa em salário, outra em controle, outra em risco. E quase ninguém coloca na mesa a fase da empresa, o tipo de trabalho que existe pela frente e o que acontece quando a pessoa-chave pede demissão.

A resposta curta: time interno faz sentido quando o software é o produto ou o diferencial central e existe trabalho contínuo para justificar uma equipe completa; terceirizar faz sentido quando a empresa precisa de competências variadas, velocidade para começar e não quer gerir uma área de tecnologia; e o modelo híbrido, com dono do produto dentro de casa e execução externa, é o que melhor atende a maioria das pequenas e médias empresas. O resto deste texto mostra como chegar à resposta certa para o seu caso.

A decisão que vai além do custo

Comparar salário de desenvolvedor com valor de contrato de fornecedor parece objetivo, mas deixa de fora quase tudo o que pesa. Os fatores que realmente decidem são estes:

• Volume e continuidade do trabalho. Existe demanda constante pelos próximos anos ou um projeto grande seguido de ajustes esporádicos?
• Amplitude de competências. Um sistema moderno exige back-end, front-end, banco de dados, infraestrutura em nuvem, segurança e, às vezes, aplicativo. Uma pessoa raramente cobre tudo bem.
• Capacidade de gestão técnica. Quem vai contratar, avaliar, revisar código e decidir arquitetura? Se ninguém na empresa faz isso hoje, a equipe interna começa sem liderança.
• Concentração de conhecimento. Onde fica o entendimento do sistema se alguém sair?
• Fase da empresa. Validar uma ideia, escalar uma operação e manter um sistema maduro pedem estruturas diferentes.

Custo entra na conta, claro. Mas ele precisa ser o custo total: recrutamento, tempo de adaptação, ferramentas, gestão, férias, substituições e o atraso de um projeto parado enquanto a vaga fica aberta.

O que exige montar um time interno

Montar uma equipe própria não é contratar um programador. É criar uma área, com papéis, processo e ferramentas.

Os papéis mínimos

Um time que consegue manter e evoluir um sistema de negócio, com segurança, precisa cobrir:

• Liderança técnica: decide arquitetura, revisa código, define padrões e responde pela saúde do sistema.
• Desenvolvimento: pelo menos duas pessoas, para que o conhecimento não fique em uma cabeça só e haja revisão cruzada.
• Produto: alguém que traduz a necessidade do negócio em prioridade e critério de aceite.
• Infraestrutura e operação: publicação de versões, backup, monitoramento, atualizações de segurança. Pode ser parte do trabalho de quem desenvolve, mas precisa ter dono.
• Qualidade: testes automatizados e validação antes de cada publicação.

Uma pessoa sozinha pode acumular vários papéis por um tempo. O problema é quando ela tira férias, adoece ou vai embora.

O processo e as ferramentas

Além das pessoas, o time interno precisa de repositório de código, ambientes separados de teste e produção, rotina de publicação, controle de acesso, gestão de tarefas e práticas de revisão. Nada disso é exótico, mas alguém precisa montar e manter. Empresas que contratam o primeiro desenvolvedor sem essa estrutura costumam descobrir, meses depois, que o sistema só roda no computador dele.

O tempo até a produtividade

Mesmo um profissional experiente leva um tempo para entender o domínio, as regras do negócio e o código existente antes de entregar com autonomia. Esse período varia muito com a complexidade do sistema e a qualidade da documentação, e precisa estar no planejamento.

Contratação e retenção de desenvolvedores

Contratar bem é a parte mais difícil para quem não é empresa de tecnologia.

Avaliar sem saber avaliar. Se ninguém na empresa programa, como saber se o candidato é bom? Entrevista de comportamento não revela se a pessoa escreve código sustentável. Muitas empresas acabam contratando quem fala com mais segurança, o que não é a mesma coisa.

Concorrência por talento. O desenvolvedor experiente pode trabalhar remotamente para empresas de qualquer lugar, inclusive de fora do país. A empresa compete não só com o vizinho, mas com quem oferece desafios técnicos maiores e uma equipe de pares para aprender.

Isolamento técnico. Um desenvolvedor sozinho numa empresa de distribuição ou de serviços não tem com quem discutir decisões nem quem revise o trabalho dele. Bons profissionais costumam sair por isso, não só por remuneração.

Rotatividade. Cada saída leva conhecimento embora. Se o sistema não tem testes, documentação e padrões, a pessoa seguinte começa quase do zero e herda decisões que não entende.

Nada disso impede a equipe interna. Significa que ela precisa de liderança técnica desde o início e de um plano de carreira minimamente crível. Essa liderança pode vir de um CTO contratado ou CTO as a service.

Terceirizar: o que fica com quem

Terceirizar não é entregar o problema e esquecer. É dividir responsabilidades de forma explícita. Quando essa divisão fica vaga, os problemas clássicos aparecem: fornecedor que decide sozinho o que é prioridade, código que ninguém da empresa consegue acessar, dependência total de uma única pessoa do outro lado. O risco cresce quando o contratado é um profissional sozinho, tema de freelancer ou software house. Outra escolha é entre alocação de desenvolvedores ou squad gerenciado.

Uma divisão saudável costuma ser esta:

Dois pontos merecem atenção especial. Primeiro, o repositório, a conta de nuvem e os domínios devem estar no nome da sua empresa, com o fornecedor acessando por permissão. Segundo, o contrato precisa prever cessão de direitos sobre o código e entregáveis de transição, para que a troca de fornecedor ou a internalização seja possível; os detalhes estão em propriedade do código-fonte no contrato. Para comparar fornecedores com critérios verificáveis, veja como escolher uma software house.

Quando terceirizar costuma ser a melhor escolha

• A empresa precisa começar rápido e não tem liderança técnica para montar uma equipe.
• O trabalho exige várias especialidades ao mesmo tempo, mas nenhuma em tempo integral.
• O volume de demanda oscila: picos em projetos, períodos mais calmos de ajustes.
• O software apoia a operação, mas não é o produto que a empresa vende.

Conhecimento do negócio e continuidade

O argumento mais forte a favor do time interno é o conhecimento do negócio. Quem está dentro da empresa sabe por que o desconto de determinado cliente é calculado de um jeito diferente, conhece o gerente de logística que reclama do relatório e entende o que muda no fechamento do mês.

Esse argumento é real, mas tem duas ressalvas.

A primeira: conhecimento de negócio pode e deve ser transferido para o fornecedor, desde que exista uma relação de longo prazo e acesso às pessoas certas. Um parceiro que atende a mesma empresa por anos acumula esse entendimento. O que destrói o conhecimento é trocar de fornecedor a cada projeto ou contratar por entrega isolada.

A segunda: conhecimento que está só na cabeça das pessoas é um risco, seja dentro ou fora da empresa. O desenvolvedor interno que sabe tudo e não documenta nada cria a mesma dependência que um fornecedor fechado. A proteção é a mesma nos dois casos: código organizado, testes automatizados, decisões registradas e mais de uma pessoa conhecendo cada parte crítica.

Continuidade também depende de como o trabalho depois do lançamento é organizado. Sistemas vivos precisam de manutenção evolutiva constante, e não só de correção de erros. Se essa rotina não está definida, nenhum dos modelos funciona bem.

Modelo híbrido: produto interno, execução externa

Para boa parte das pequenas e médias empresas, a decisão não é binária. O arranjo que costuma funcionar melhor separa quem decide de quem executa.

Dentro de casa fica:

• um responsável pelo produto, que conhece o negócio, define prioridades e valida as entregas;
• a titularidade de tudo: código, contas, dados e documentação;
• em empresas maiores, uma liderança técnica que acompanha o fornecedor e participa das decisões de arquitetura.

Com o parceiro externo fica:

• a execução do desenvolvimento, com equipe multidisciplinar;
• a infraestrutura, a publicação de versões e o monitoramento;
• a sustentação, com níveis de atendimento combinados por escrito.

O responsável pelo produto não precisa programar. Precisa entender a operação, ter autoridade para decidir e reservar tempo para acompanhar o trabalho. Sem essa pessoa, o modelo híbrido vira terceirização sem dono, e o fornecedor passa a decidir o que é prioridade.

Esse arranjo também permite internalizar aos poucos. A empresa pode começar com tudo externo, contratar um responsável de produto, depois uma liderança técnica e, mais adiante, desenvolvedores que assumem partes do sistema, com o parceiro ajudando na transição. Isso é muito mais seguro do que tentar montar uma equipe inteira de uma vez.

Critérios para decidir: um roteiro prático

Responda às perguntas abaixo com a diretoria e a pessoa que mais usa o sistema.

1. O software é o que a empresa vende ou o que sustenta a operação? Se é o produto, a tendência é internalizar o núcleo ao longo do tempo. Se sustenta a operação, terceirizar ou o modelo híbrido costumam bastar.
2. Existe demanda contínua para ocupar uma equipe inteira pelos próximos anos? Se a resposta é "talvez", comece externo e reavalie.
3. Há alguém capaz de liderar tecnicamente uma equipe? Se não, a primeira contratação interna deve ser essa, não um desenvolvedor júnior.
4. Quantas especialidades o sistema exige? Quanto maior a variedade, mais caro e lento é cobrir tudo internamente.
5. Quem vai ser o dono do produto? Esse papel deve ficar dentro da empresa em qualquer modelo.
6. O código, as contas e a documentação estão sob controle da empresa hoje? Se não, resolva isso antes de qualquer mudança de modelo.
7. Qual o impacto de o sistema parar? Operações críticas exigem plantão, monitoramento e substituição de pessoas, o que pesa contra uma equipe interna pequena.

Um resumo para orientar a conversa:

Nenhuma linha da tabela é regra. Ela serve para começar a discussão com os pés no chão.

Sinais de que é hora de mudar o modelo

O modelo certo hoje pode não ser o certo daqui a alguns anos. Fique atento a estes sinais.

Na terceirização:

• o fornecedor decide prioridades porque ninguém na empresa assume esse papel;
• cada mudança pequena vira orçamento e espera longa;
• a empresa não tem acesso direto ao código nem às contas de nuvem;
• o volume de demanda cresceu tanto que justificaria pessoas dedicadas dentro de casa.

No time interno:

• uma ou duas pessoas concentram todo o conhecimento e não conseguem tirar férias;
• a equipe passa mais tempo apagando incêndio do que evoluindo o sistema;
• projetos novos ficam parados porque falta uma especialidade específica;
• a saída de alguém deixa partes do sistema sem dono.

Em qualquer modelo:

• não existe acordo claro sobre tempo de resposta quando o sistema cai. Nesse caso, o ponto de partida é definir um SLA de suporte e sustentação por escrito, seja com o fornecedor, seja com a própria equipe.

Mudar de modelo exige transição planejada: documentação, período de convivência entre quem sai e quem entra, e acesso garantido a tudo. Trocar de uma vez, sem sobreposição, é a forma mais comum de perder conhecimento.

Perguntas frequentes

Quantos desenvolvedores são necessários para montar uma equipe interna?

Um só não basta. Uma equipe interna capaz de manter e evoluir um sistema de negócio precisa cobrir liderança técnica, pelo menos duas pessoas desenvolvendo, produto, infraestrutura e qualidade. Uma pessoa pode acumular papéis por um tempo, mas férias, doença ou saída deixam o sistema sem dono e o conhecimento concentrado numa só cabeça.

Terceirizar o desenvolvimento significa perder o controle do sistema?

Não, desde que as responsabilidades sejam explícitas. Ao terceirizar o desenvolvimento, a empresa deve manter um dono do produto interno, ser titular do repositório, da conta de nuvem e dos domínios, e garantir no contrato a cessão de direitos sobre o código e entregáveis de transição. Assim o controle continua dentro de casa.

É possível internalizar a equipe depois de começar terceirizando?

Sim, e costuma ser o caminho mais seguro. A empresa começa com execução externa, contrata um responsável de produto, depois uma liderança técnica e, mais adiante, desenvolvedores que assumem partes do sistema. Internalizar aos poucos, com o parceiro apoiando a transição e um período de convivência, evita perder conhecimento.

Qual deve ser a primeira contratação de uma área de tecnologia?

Quando ninguém na empresa lidera tecnicamente, a primeira contratação de uma área de tecnologia deve ser uma liderança técnica, e não um desenvolvedor júnior. Essa pessoa define arquitetura, padrões e processo de revisão e consegue avaliar os próximos contratados. Essa liderança também pode vir de um CTO as a service.

Como a Pervian Tech trabalha parcerias de longo prazo

Na Pervian Tech, começamos entendendo como a empresa decide e quem vai ser o dono do produto do lado do cliente. Depois desenhamos o modelo junto: execução completa, apoio a uma equipe interna existente ou transição gradual para internalizar. Em todos os casos, o repositório, a nuvem e a documentação ficam no nome do cliente desde o primeiro dia, e as decisões de arquitetura de software são registradas para que qualquer equipe, nossa ou sua, consiga continuar o trabalho.

Cada parceria é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito em que avaliamos o sistema, a demanda e a estrutura que a empresa tem hoje. Mais textos sobre o tema estão em contratação de software. Se você está decidindo entre montar um time ou contratar fora, conte como está a situação hoje.