Squads gerenciados ou time próprio: como decidir

Uma rede de clínicas decidiu criar um aplicativo para agendamento e acompanhamento de pacientes. O diretor de operações fez as contas: contratar um líder técnico, três desenvolvedores, um designer e um analista de qualidade levaria de quatro a seis meses só de recrutamento, isso se tudo desse certo. O conselho queria a primeira versão no ar antes disso. A pergunta que chegou à mesa foi direta: montamos o time ou contratamos um?

Não existe resposta universal. Existe a resposta certa para o momento, o orçamento e o papel que o software vai ter no negócio.

O que é um squad gerenciado

Um squad é um time multidisciplinar, pequeno e autônomo, responsável por uma parte do produto de ponta a ponta. O termo ficou conhecido a partir de 2012, quando Henrik Kniberg e Anders Ivarsson descreveram a organização de times de engenharia do Spotify. No squad gerenciado, uma consultoria entrega esse time completo (desenvolvedores, qualidade, design, liderança técnica) e cuida da gestão do dia a dia, focado em objetivos definidos com a empresa.

Um time próprio, por outro lado, é contratado, liderado e desenvolvido pela empresa. O conhecimento fica em casa e o time se dedica só ao seu produto.

Quando o time próprio faz sentido

• O software é o negócio: ou é central para a vantagem competitiva, e vai evoluir por anos.
• Conhecimento estratégico: regras de negócio, dados e decisões de arquitetura que a empresa quer dominar internamente.
• Estrutura para liderar: a empresa tem ou vai contratar liderança técnica capaz de atrair, desenvolver e reter desenvolvedores.
• Horizonte longo: o investimento em recrutamento e formação se paga ao longo do tempo.

Quando o squad gerenciado faz sentido

• Prazo: a primeira entrega precisa acontecer antes do tempo que levaria para montar um time.
• Escopo definido: um projeto com começo, meio e fim, como uma migração, uma integração ou um novo módulo.
• Sem estrutura técnica: a empresa ainda não tem liderança de tecnologia para contratar e gerir desenvolvedores.
• Demanda variável: o volume de trabalho sobe e desce, e o time precisa acompanhar.

O que a engenharia de software ensina sobre essa decisão

Adicionar gente não acelera na mesma proporção

Em 1975, Fred Brooks escreveu em O Mítico Homem-Mês uma frase que virou lei: adicionar pessoas a um projeto de software atrasado o atrasa ainda mais. Novas pessoas precisam aprender o contexto, e a comunicação cresce com o tamanho do time. Isso vale para os dois modelos: um squad que chega a um projeto em andamento, ou contratações feitas às pressas no meio do caminho, precisam de tempo para render.

A estrutura do time vira a estrutura do sistema

A lei de Conway, formulada por Melvin Conway em 1968, diz que as organizações projetam sistemas que copiam as suas estruturas de comunicação. Se o squad externo trabalha isolado do resto da empresa, o software tende a refletir esse isolamento. O livro Team Topologies, de Matthew Skelton e Manuel Pais (2019), aprofunda a ideia e recomenda desenhar os times, internos ou externos, a partir dos fluxos de valor do produto e da carga cognitiva que cada time consegue absorver.

Meça o que importa

O programa de pesquisa DORA, resumido no livro Accelerate (Forsgren, Humble e Kim, 2018), identificou quatro métricas que se associam ao bom desempenho de times de software: frequência de deploy, tempo entre o código pronto e a produção, taxa de falhas em mudanças e tempo para restaurar o serviço. Elas servem para acompanhar qualquer um dos dois modelos, e são uma boa base para o contrato com um squad externo.

Os dois modelos lado a lado

Sobre o custo, a comparação justa é entre custo total e custo total. O salário de um desenvolvedor CLT é só o começo: encargos, provisões e benefícios podem aproximar o custo mensal do dobro do salário, e ainda há recrutamento, equipamentos, ferramentas e o tempo de gestão.

Cuidados ao contratar um squad

1. 01

   Defina objetivos, não só tarefas

   O que precisa estar pronto e como o resultado será medido.

2. 02

   Garanta acesso ao código e à documentação

   O repositório é da empresa desde o primeiro dia.

3. 03

   Tenha um responsável interno

   Alguém da empresa que prioriza, decide e conhece o negócio.

4. 04

   Planeje a saída desde o início

   Como o conhecimento será transferido, para um time interno ou para outro fornecedor.

Os dois podem conviver

Muitas empresas começam com um squad para acelerar a primeira versão e, em paralelo, contratam o time interno que vai assumir o produto. O squad entrega enquanto o time é formado e, no fim, ajuda na transição. Na rede de clínicas do início deste artigo, esse costuma ser o caminho mais equilibrado: aplicativo no prazo e conhecimento em casa no médio prazo.

A pergunta não é “terceirizar ou não”. É quanto do conhecimento do produto a empresa precisa ter dentro de casa, e em quanto tempo.

Perguntas frequentes

Quantas pessoas tem um squad?

Em geral, entre cinco e dez. A ideia é um time pequeno o suficiente para se comunicar sem burocracia e completo o suficiente para entregar uma parte do produto de ponta a ponta. A composição varia conforme o objetivo: desenvolvedores, qualidade, design, produto e uma liderança técnica.

Quem é dono do código desenvolvido pelo squad?

Deve ser a empresa contratante, e isso precisa estar no contrato, junto com o acesso ao repositório desde o primeiro dia e a documentação. Não é um detalhe: é o que garante que o conhecimento não fica preso ao fornecedor.

Squad gerenciado é o mesmo que fábrica de software?

Não exatamente. Na fábrica de software, o fornecedor recebe um escopo fechado e entrega o resultado, com pouca interação no caminho. No squad gerenciado, o time trabalha de forma contínua e próxima ao negócio, com prioridades que podem mudar ao longo do projeto.

Conteúdo informativo, preparado para ajudar no dia a dia de quem contrata e lidera pessoas. Não substitui a orientação de um advogado, contador ou especialista para o caso da sua empresa.