Como montar um squad de TI a partir da demanda, e não do organograma

Comece pela demanda, não pela lista de cargos

Para montar um squad de TI, parta da fila de demandas, e não de uma lista de cargos. Identifique onde o trabalho trava e que tipo de tarefa se repete. Inclua só os perfis que esse trabalho justifica, com a senioridade que a complexidade pede. E revise a composição quando a demanda mudar.

Se você ainda está avaliando se precisa de um time externo, comece por o que é um squad de TI e quando ele faz sentido. Aqui, a decisão de reforçar a equipe já foi tomada. Falta transformar a fila em time.

Um erro frequente nessa etapa é copiar o organograma de outro projeto: front-end, back-end, QA, DevOps, designer. A lista parece completa, mas descreve um time genérico. O trabalho parado na sua área fica de fora.

Quem escreve o termo de referência sente isso primeiro. Cada perfil precisa de uma justificativa, e "todo squad tem" não é justificativa. "A fila tem esse tipo de trabalho, e ele trava nesse ponto" é.

Por isso, antes de pensar em cargo, abra a fila e faça três perguntas:

• Que tipo de trabalho aparece com mais frequência? Tela nova, ajuste de regra, integração, relatório, correção.
• O trabalho é contínuo ou pontual? O que volta todo ciclo pede alguém dedicado. O que aparece uma vez, não.
• Onde o pedido para de andar? É aqui que o perfil que falta costuma aparecer.

Não é preciso contar com precisão. Agrupe os itens por tipo de trabalho e veja quais grupos crescem e quais quase não se mexem.

Onde a fila trava

Entre o pedido e o usuário, o trabalho costuma parar em cinco pontos:

• Teste. O código está pronto, mas ninguém confere antes de publicar, ou a conferência é manual e demora.
• Publicação. Colocar uma versão no ar exige uma janela, um roteiro manual e alguém disponível naquele horário.
• Interface. A regra está clara, mas ninguém desenhou a tela, e o desenvolvedor improvisa.
• Regra de negócio. O pedido chegou incompleto, e o time volta à área demandante várias vezes para entender o que é para fazer.
• Dados. A pergunta é sobre o que já aconteceu, e a resposta depende de cruzar bases que não conversam.

Cada ponto aponta para um perfil diferente.

Os perfis e o trabalho que justifica cada um

Cada perfil abaixo segue a mesma ordem: o trabalho, quem resolve e o sinal de que o perfil está sobrando.

Desenvolvimento: quando separar front-end e back-end

Desenvolvimento é a base de quase todo squad, porque quase toda demanda termina em código. A pergunta que sobra é o formato.

Quando o volume é pequeno e as demandas atravessam as duas camadas, um perfil fullstack resolve. A mesma pessoa ajusta a regra no servidor e a tela que a exibe, sem passar o pedido adiante.

A especialização passa a fazer sentido quando as camadas evoluem em ritmos diferentes. Um exemplo hipotético: um sistema cuja interface está sendo redesenhada enquanto a API quase não muda. Nesse caso, o trabalho de front-end domina a fila, e um especialista nessa camada rende mais do que dois generalistas dividindo a atenção.

Sinal de desperdício: um especialista em back-end que passa os ciclos esperando a interface ficar pronta para ter o que integrar.

DevOps quando a publicação é o gargalo

O trabalho de DevOps aparece quando colocar uma versão no ar é um evento. Publicação manual, ambiente de homologação que não se parece com o de produção, erro que só se descobre quando um usuário liga.

O profissional de DevOps automatiza a esteira de publicação, estabiliza os ambientes e monta a observabilidade: ver o que acontece em produção sem esperar a reclamação.

Sinal de desperdício: a esteira já está automatizada, os ambientes são estáveis, e o perfil continua no time em tempo integral sem trabalho novo de infraestrutura na fila.

QA quando o defeito chega à produção

O trabalho de QA se revela pelo retrabalho. A entrega volta porque quebrou algo que funcionava antes, o mesmo tipo de defeito reaparece a cada versão, e não existe teste automatizado que pegue a regressão.

O profissional de QA define o que precisa ser testado, escreve os testes automatizados e organiza a conferência antes da publicação. Com isso, quem encontra o defeito é o time, antes do usuário.

Sinal de desperdício: testes manuais repetidos a cada ciclo sem que nenhum vire automação. O perfil está lá, mas executa em vez de proteger.

Design quando o usuário trava na tela

O trabalho de design aparece quando o sistema funciona e, mesmo assim, o usuário não consegue usar. Chamados que são dúvida de navegação, formulário abandonado no meio, área demandante pedindo treinamento para uma tela simples.

Design também entra quando há interface nova, em especial em serviço ao cidadão, cujo usuário não recebe treinamento nenhum. A acessibilidade eMAG e WCAG começa no protótipo, porque corrigir depois custa uma tela refeita.

Sinal de desperdício: um designer num squad cuja fila é quase toda manutenção de API e integração, sem tela nova à vista.

Dados quando a pergunta é sobre o que já aconteceu

O trabalho de dados aparece quando a área quer entender o passado, e não registrar o presente. Relatório gerencial montado na mão todo mês, indicador que cada setor calcula de um jeito, base de um sistema que precisa cruzar com a de outro.

O perfil de dados ou BI integra as bases e entrega painéis que respondem à pergunta sem ninguém exportando planilha.

Sinal de desperdício: um especialista em dados num squad que está construindo um sistema do zero, antes de haver qualquer dado para analisar.

Product owner quando ninguém decide a prioridade

O trabalho do product owner aparece quando o time tem capacidade, mas não sabe o que fazer primeiro. Pedidos chegam por vários canais, a prioridade muda conforme quem ligou por último, e requisitos chegam incompletos.

O PO organiza a fila, transforma pedido solto em requisito executável e define quando a entrega está pronta. Quando a dificuldade está em detalhar o pedido, vale também revisar como é feito o levantamento de requisitos.

Sinal de desperdício: o órgão já tem um gestor que prioriza a fila e responde pelo aceite, e o PO do squad passa a repetir esse papel.

Quando um perfil vira desperdício

Os sinais de cada perfil têm algo em comum: o perfil ficou depois que o trabalho acabou, ou entrou antes de ele existir. Nos dois casos, a competência é real, mas a fila não tem trabalho para ela.

Isso não obriga o perfil a sair. Ele pode atuar de forma parcial ou pontual: entra quando há uma tela nova a desenhar, uma mudança de infraestrutura a fazer, um ciclo de redefinição de prioridades. Fora disso, ocupa um lugar que outro perfil usaria melhor.

Perfil sem demanda é custo, não reforço.

Senioridade: onde ela faz diferença

Depois dos perfis, falta decidir onde a experiência pesa.

A senioridade faz diferença onde o trabalho exige julgamento:

• Decisões de arquitetura, que vão ser difíceis de desfazer depois.
• Ambientes sem documentação, em que é preciso entender um sistema lendo o código e conversando com quem usa.
• Integrações com serviços de governo, que costumam ter regras próprias de autenticação, formato e disponibilidade.
• Liderança técnica, em que alguém precisa revisar o trabalho dos outros e responder pelas escolhas do time.

Pesa menos em tarefa bem especificada e repetitiva, com caminho traçado e risco baixo.

Um time só de seniores paga por julgamento em tarefa que não exige julgamento. Um time sem nenhum sênior deixa sem dono a decisão cara. Coloque a experiência onde a decisão pesa e deixe o trabalho previsível com quem executa bem dentro de um padrão já definido.

Quando reduzir ou trocar a composição

Se o squad nasce da demanda, a composição muda quando a demanda muda de natureza.

Um time que começou construindo um sistema passa, com o tempo, a trabalhar na evolução dele, com ajustes de regra e melhorias pontuais. A interface que estava sendo desenhada fica pronta, e a fila passa a ser dominada por relatórios e integração de bases. Em cada caso, o perfil que era central pode virar secundário, e outro pode passar a fazer falta.

O momento natural para essa conversa é a revisão ao fim de cada ciclo de entrega. Se o mesmo tipo de trabalho fica sem dono por vários ciclos, ou se um perfil passa ciclos sem tarefa da própria especialidade, a composição pede revisão.

Dois pontos do contrato pesam nessa decisão. O primeiro é a forma de medir a entrega. O segundo é a escolha entre alocação e fábrica de software, porque quem coordena o time define quem pode propor a mudança.

E, às vezes, a revisão mostra que o problema já não é de time. Se o que resta é uma solução específica, com começo e fim claros, a área talvez precise de um sistema sob medida, e não de um squad rodando indefinidamente.

Na Evo Tech, o squad começa pela fila que a área já tem: cada perfil de desenvolvimento, DevOps, QA, design, produto ou dados entra pelo trabalho que vai fazer, e a composição muda quando a demanda muda. Nossos profissionais já atuaram em órgãos do setor público federal e em organismos internacionais. Conheça os perfis e as modalidades do Squad de TI da Evo Tech.