A decisão já foi tomada. O produto precisa evoluir mais rápido do que os dois desenvolvedores internos conseguem entregar, contratar CLT levaria quatro meses entre processo seletivo e adaptação, e a diretoria aprovou trazer um time de fora. Até aí, tudo racional.
O que tira o sono do gestor vem depois: como conduzir seis pessoas que não são funcionárias, não sentam na sua sala e respondem a outro empregador. Quem diz o que elas fazem na segunda-feira? Como saber se estão produzindo ou apenas ocupadas? E se o time interno achar que veio gente de fora tomar o lugar deles?
A tese deste texto é que squad externo dá errado por motivos de gestão, quase nunca por motivos técnicos. As empresas em que funciona não contrataram desenvolvedores melhores: definiram com clareza quem decide o quê, prepararam a entrada e trataram o time de fora como time, não como fornecedor de horas.
O que é um squad externo?
Squad externo é um time completo e estável, contratado de uma empresa parceira, que passa a trabalhar de forma contínua no seu produto seguindo as suas prioridades. Ele costuma reunir os perfis necessários para entregar valor de ponta a ponta, como desenvolvimento, qualidade e liderança técnica, e permanece com você por meses ou anos, não por uma entrega isolada.
Duas palavras dessa definição fazem todo o trabalho. Completo significa que o time não depende de você fornecer as peças que faltam para conseguir entregar algo utilizável. Estável significa que as mesmas pessoas continuam no seu produto, acumulando conhecimento do seu negócio, em vez de rodarem entre clientes a cada mês.
O contrato normalmente é por capacidade mensal, não por entregável fechado. Você não compra uma lista de funcionalidades com prazo assinado: você compra a capacidade contínua de um time e decide, a cada ciclo, no que ele vai trabalhar. É uma diferença sutil no papel e enorme na prática, porque muda quem carrega a responsabilidade por priorizar.
Qual a diferença entre contratar um squad e alocar um profissional avulso?
Já tratamos do modelo de alocação de desenvolvedores em detalhe, então vale focar no que muda quando são seis pessoas em vez de uma.
Alocar um profissional é somar capacidade a um time que já existe e já funciona. Ele entra na estrutura da sua empresa, segue os processos que você já tem e responde ao seu líder técnico. Se a sua operação não tem processo, ele herda a falta de processo.
Contratar um squad é diferente: você recebe capacidade e também estrutura. O time chega com os próprios ritos, o próprio jeito de estimar e alguém que responde pela organização interna do trabalho. Isso é vantagem para quem não tem liderança técnica sobrando, e é fonte de atrito para quem já tem um jeito consolidado de trabalhar e não quer mexer nele.
A regra prática: se a sua dor é falta de braços em um time que já roda bem, aloque profissionais. Se a sua dor é que não existe time capaz de tocar aquela frente sozinho, contrate o squad. Escolher errado aqui gera meses de fricção que nenhuma das partes consegue nomear.
Quem manda no squad e quem decide as prioridades?
Esta é a pergunta que mais causa estrago quando fica sem resposta explícita, e a divisão que funciona é conhecida: a prioridade é sempre sua, a execução é sempre deles.
Na prática, isso significa que a sua empresa define o que é mais importante fazer agora e por quê, com base no negócio. O squad define como fazer, quanto tempo leva, quem faz o quê e que caminho técnico seguir. Quando o cliente invade o como, o time perde a capacidade de responder pelo resultado. Quando o squad invade o o quê, o produto começa a ser guiado por conveniência técnica em vez de valor de negócio.
Para isso funcionar, uma pessoa da sua empresa precisa ter nome e sobrenome como responsável pelo produto. Não um comitê, não três diretores que aparecem em semanas alternadas. Alguém que conheça o negócio, tenha autonomia para decidir e esteja disponível algumas horas por semana para responder dúvidas. Squads que ficam bloqueados esperando decisão são o desperdício mais caro e mais comum desse modelo.
O que a sua empresa precisa entregar na primeira semana?
O tempo até o time produzir depende quase inteiramente da qualidade dessa preparação. O que precisa estar pronto no primeiro dia:
- Acessos liberados. Repositório de código, ambientes, ferramenta de tarefas, sistemas de terceiros necessários. Parece óbvio, mas acesso pendente é a causa número um de primeira semana perdida.
- Contexto de negócio, não só de sistema. Quem é o cliente, como a empresa ganha dinheiro, o que dá errado hoje. Um time que entende o negócio questiona pedidos ruins; um time que só recebe especificação executa pedidos ruins com eficiência.
- Ponto focal definido e avisado. A pessoa responsável pelo produto precisa saber que é ela e ter a agenda ajustada para isso.
- Uma primeira entrega pequena e real. Algo que vá para produção em duas semanas. Serve para testar todo o caminho, do acesso ao deploy, quando ainda dá tempo de corrigir o que estiver travado.
- Combinado com o time interno. Explique antes por que o squad veio e o que muda para cada um. Silêncio da liderança nesse momento vira boato de substituição.
Empresas que chegam nesse nível de preparo costumam ter o squad entregando em produção na segunda ou terceira semana. As que não preparam nada levam de seis a oito semanas para o mesmo ponto, pagando o time cheio durante toda a espera.
Como é o dia a dia e quais ritos realmente importam?
Existe uma indústria inteira de cerimônias, e a maior parte delas você pode ignorar. Três encontros dão conta da gestão de um squad externo na maioria das empresas de médio porte.
O primeiro é uma conversa curta diária, de quinze minutos, em que o time alinha o que está travado. Você não precisa participar todo dia, mas o seu ponto focal deveria estar acessível logo depois dela, porque é ali que os bloqueios aparecem.
O segundo é a demonstração quinzenal do que ficou pronto, rodando de verdade, não em apresentação de slides. Esse é o rito inegociável: é o único momento em que você verifica progresso com os próprios olhos, em vez de acreditar em porcentagem de conclusão.
O terceiro é o planejamento do ciclo seguinte, em que você repriorizar a fila com base no que viu. Reordenar prioridades a cada duas semanas é a maior vantagem operacional desse modelo em relação a um projeto de escopo fechado, e é justamente o que muita empresa deixa de usar por medo de parecer indecisa.
Quais sinais mostram, em 30 dias, se está funcionando?
Trinta dias é tempo suficiente para ler a relação, desde que você olhe para as coisas certas. Sinais de que está no caminho: existe coisa nova rodando em produção, o time faz perguntas de negócio e não só de especificação, os problemas chegam até você antes de virarem crise, e a estimativa da segunda quinzena bateu mais com a realidade do que a da primeira.
Sinais de alerta: a demonstração é sempre sobre trabalho interno que o usuário não vê, o time só responde exatamente o que foi pedido sem apontar problemas, tudo depende de uma pessoa do squad, e você descobre os atrasos na reunião em vez de antes dela. Nenhum desses sinais é sentença, mas todos exigem conversa direta na semana em que aparecem.
Vale combinar desde o início alguns indicadores simples de acompanhamento, no espírito do que discutimos ao falar de SLA e indicadores de fornecedor de TI. Frequência de entregas em produção, previsibilidade das estimativas e tempo de resposta a problemas críticos dizem mais sobre a saúde da parceria do que qualquer relatório de horas trabalhadas.
Squad externo funciona quando a empresa continua sendo dona do produto
O erro mais caro que vemos não é escolher o parceiro errado: é terceirizar a decisão junto com a execução. Squad externo entrega bem quando alguém de dentro continua respondendo pelo rumo do produto, pelas prioridades e pelo contexto de negócio. Quando esse papel fica vago, o time de fora passa a decidir por conta, e aí a empresa realmente perde o controle que temia perder.
A decisão entre montar time próprio, terceirizar ou combinar os dois modelos merece uma análise específica do seu momento, que aprofundamos ao comparar time de TI interno e terceirizado.
Na DevCore, montamos squads dedicados que se integram à operação do cliente com esse desenho de responsabilidades, dentro do nosso modelo de squad as a service. Se você precisa acelerar o produto sem abrir vagas CLT, converse com o nosso time e vamos desenhar o formato que faz sentido para o seu contexto.
Perguntas frequentes sobre squad externo
Qual o tamanho mínimo de um squad para valer a pena?
Na prática, três a quatro pessoas com perfis complementares. Abaixo disso, você está alocando profissionais, não contratando um time, e é melhor tratar a contratação assim. Acima de sete ou oito, o próprio squad começa a precisar de coordenação interna e costuma render mais dividido em dois times menores com frentes distintas.
E se eu quiser trazer o desenvolvimento para dentro de casa depois?
É um objetivo legítimo e deve ser dito no início, não no fim. Combine desde a assinatura que o código, a documentação e os acessos são da sua empresa, e inclua no contrato um período de transição com o time interno acompanhando. Parceria saudável não depende de dependência técnica.
O squad externo pode trabalhar junto com o meu time interno no mesmo produto?
Pode, e costuma ser o melhor arranjo, desde que a divisão seja por frente de trabalho e não por etapa. Dois times cuidando de módulos diferentes funcionam bem. Um time que só escreve e outro que só revisa geram fila, ressentimento e ninguém responsável pelo resultado final.