Extensão de equipa vs equipa dedicada vs gerida: escolhe pela capacidade

A extensão de equipa, um squad dedicado e uma equipa totalmente gerida podem pôr os mesmos engenheiros a trabalhar no teu código. O que muda é quanto da tua própria equipa cada modelo consome: quem escreve os tickets, quem revê o código, quem atende o alerta das 03:00. Escolhe o modelo que a tua capacidade interna consegue sustentar e, depois, escreve o contrato e o primeiro mês de forma a que a divisão do trabalho fique explícita.

As três formas, tal como costumam ser vendidas:

• Extensão de equipa (staff augmentation): um a três engenheiros dentro da tua equipa, sob o teu engineering manager, a trabalhar a partir do teu backlog.
• Squad dedicado (uma equipa dedicada): quatro a seis pessoas com o seu próprio tech lead, programadores e QA. Tu ficas com a direção de produto; eles ficam com a execução de engenharia.
• Equipa totalmente gerida: seis a doze ou mais pessoas, com project manager, tech lead, programadores, QA e DevOps. O parceiro é responsável pela entrega e reporta-te resultados.

Três perguntas que decidem o modelo

Responde-lhes a pensar nas pessoas que tens hoje, com a carga que têm agora.

1. 1Quem escreve e prioriza os tickets? Alguém tem de transformar objetivos em tarefas pequenas o suficiente para terminar em poucos dias, com critérios de aceitação, e decidir a sua ordem.
2. 2Quem revê o código e é dono da arquitetura? Cada alteração precisa de um revisor que conheça o sistema. E alguém tem de recusar um design que vai doer daqui a um ano.
3. 3Quem está de on-call para a produção? Quem lança uma alteração tem de estar contactável quando ela falha, ou saber exatamente quem está.

Depois, lê as respostas:

• As três são tuas, com horas de sobra: extensão de equipa. Estás a acrescentar mãos a um sistema que já funciona.
• Os tickets são teus; a revisão e a arquitetura não: um squad dedicado. O tech lead do parceiro assume a revisão e as decisões técnicas dentro da área do squad.
• Só as prioridades de negócio são tuas: uma equipa totalmente gerida, com resultados, aceitação e on-call escritos no contrato.
• Ninguém é dono das prioridades: nenhum modelo resolve isso. Um project manager pode escrever tickets, mas só alguém do teu lado pode decidir o que importa.

"Com horas de sobra" é a parte que as pessoas saltam. Um engenheiro sénior que já é o gargalo das revisões não consegue absorver mais três autores.

Exemplo prático: as horas que cada modelo tira à tua equipa

Imagina que queres mais quatro engenheiros a escrever código de produto. Os números são ilustrativos; substitui-os pelos teus ao fim do primeiro mês.

Extensão de equipa, quatro engenheiros:

• Code review sénior, cerca de 3 horas por engenheiro: 12 horas.
• Product ownership (refinamento, tickets, responder a perguntas), cerca de 2 horas por engenheiro: 8 horas.
• Gestão (1:1, planeamento, feedback ao parceiro), cerca de 1 hora por engenheiro: 4 horas.
• Total: 24 horas por semana, mais de metade de uma pessoa sénior.

Squad dedicado (tech lead, três programadores, QA):

• Product owner (refinamento, aceitação, a demo): 8 horas.
• Arquitetura (registos de decisão, alterações a interfaces partilhadas): 4 horas.
• Uma hora semanal com o tech lead do parceiro: 1 hora.
• Total: 13 horas por semana.

Equipa totalmente gerida (project manager, tech lead, quatro programadores, QA, DevOps):

• Responsável de negócio (prioridades, aceitação de marcos): 4 horas.
• Revisão de arquitetura e segurança das decisões que tocam nos teus outros sistemas ou dados: 2 horas.
• Governação (relatório semanal, revisão mensal, faturas): 2 horas.
• Total: 8 horas por semana.

O onboarding vem por cima. Para este exemplo, conta com o dobro das horas de revisão e de produto nas semanas um a quatro.

Exemplo prático: o custo mensal de cada modelo

O mesmo cenário, com números inventados para a aritmética ser legível, e não orçamentos: uma tarifa fixa de 8.000 € por mês para cada função externa e 80 € por hora do tempo das tuas pessoas, com custo total (salário, contribuições da entidade empregadora, benefícios, equipamento e custos gerais, a dividir pelas horas trabalhadas). Um mês tem 4,3 semanas.

• Extensão de equipa: 4 × 8.000 € = 32.000 € faturados, mais 24 h × 4,3 × 80 € = 8.256 € de tempo interno. Cerca de 40.300 €, por quatro engenheiros a escrever código.
• Squad dedicado: 5 × 8.000 € = 40.000 €, mais 13 h × 4,3 × 80 € = 4.472 €. Cerca de 44.500 €, por três programadores, um lead que também programa e QA.
• Equipa totalmente gerida: 8 × 8.000 € = 64.000 €, mais 8 h × 4,3 × 80 € = 2.752 €. Cerca de 66.750 €, por quatro programadores e todas as funções à volta deles.

No papel, a extensão ganha. O problema são as 24 horas: saem das tuas pessoas mais séniores, e 80 € não refletem o que essas pessoas construiriam nesse tempo. Se os teus engenheiros séniores já enchem a semana com revisões e incidentes, as 12 horas de revisão saem do roadmap ou nunca acontecem. É com código por rever que a dívida técnica começa a acumular-se. Nesse caso, os 4.200 € extra por mês do squad pagam um tech lead que faça a revisão.

Uma equipa gerida inclui funções que, de outra forma, terias de assegurar tu (gestão de projeto, QA, releases e infraestrutura), por isso compara-a com o que essas funções te custam internamente. Para os custos que uma tabela de preços esconde, lê os custos escondidos do desenvolvimento offshore barato.

Quem faz o quê em cada modelo

Põe esta divisão por escrito no statement of work; se não estiver escrita, cada lado assume que é o outro que trata dela.

Extensão de equipa:

• Backlog e decisões técnicas: teus.
• Code review: nos dois sentidos. Os teus engenheiros reveem as alterações deles, e eles reveem as tuas.
• QA e releases: o teu processo e o teu pipeline; escrevem testes como toda a gente.
• On-call: entram na tua rotação só se o contrato o disser e o pagar.
• Recrutamento e substituição: o parceiro procura candidatos; tu entrevistas e aprovas cada um.
• Gestão de pessoas: a direção do dia a dia é tua. Carreira, salário e avaliação de desempenho ficam com o parceiro enquanto entidade empregadora.

Squad dedicado:

• Backlog: o teu product owner define as prioridades; o tech lead decompõe os itens e estima-os.
• Decisões técnicas: o tech lead, dentro da área do squad. Alterações a interfaces partilhadas ou modelos de dados passam pela tua revisão de arquitetura.
• Code review: dentro do squad; os teus engenheiros reveem o que atravessa a fronteira.
• QA: o engenheiro de QA do squad, face a critérios de aceitação que o teu product owner valida.
• Releases: o squad, através do teu pipeline e segundo as tuas regras de alteração.
• On-call: o squad cobre os seus próprios serviços no seu horário de trabalho, com um caminho de escalamento escrito para lá disso.
• Recrutamento, substituição e gestão de pessoas: o parceiro; tu entrevistas pelo menos o tech lead.

Equipa totalmente gerida:

• Backlog: tu defines prioridades e marcos; o project manager do parceiro transforma-os num plano.
• Decisões técnicas: o parceiro, com registos de decisão que podes ler e o teu veto sobre tudo o que toque nos teus outros sistemas, dados ou segurança.
• Code review, QA e releases: o parceiro, face aos critérios de aceitação do contrato, para ambientes que são teus, com o teu direito de auditar qualquer alteração.
• On-call: o parceiro, com tempos de resposta escritos no contrato.
• Recrutamento, substituição e gestão de pessoas: o parceiro, dentro dos prazos do contrato.

Cláusulas do contrato que mudam com o modelo

As verificações gerais a um parceiro (triagem, referências, certificações, duração do contrato) estão em como avaliar um parceiro nearshore na Europa. As cláusulas abaixo são aquelas cuja resposta certa depende do modelo. Leva-as para a negociação como perguntas; os valores são exemplos.

• O que pagas. A extensão e os squads são faturados por tempo: pagas por pessoas, ao mês. Uma equipa gerida também pode ser faturada por resultados (marcos, um âmbito fechado). Isso passa o risco de entrega para o parceiro, mas só funciona com critérios de aceitação precisos o suficiente para resolver um desacordo.
• Aceitação. Quem aprova um entregável, face a quê, em quantos dias úteis e o que acontece se ninguém responder. Indispensável para faturação por resultados, útil para um squad.
• Prazo de substituição. Dias úteis até ser apresentado um candidato de substituição (exemplo: dez), e se a pessoa que sai e a que entra se sobrepõem, e a cargo de quem (exemplo: duas semanas, faturadas uma só vez). Dá ao tech lead do squad uma cláusula própria.
• Pré-aviso e redução. O pré-aviso para retirar uma pessoa ou terminar a colaboração, e se podes reduzir uma função de cada vez. Uma equipa gerida precisa de mais tempo, porque primeiro o conhecimento tem de mudar de mãos.
• Transferência de conhecimento e saída. O que tem de existir sempre, e não só no fim: repositórios na tua organização desde o primeiro dia, registos de decisão, um runbook por cada serviço que o parceiro opera, infraestrutura como código e um inventário de contas. À saída: uma passagem de testemunho com pessoas identificadas e um teste de que a tua equipa faz deploy e restauro sem ajuda.
• Cessão da propriedade intelectual. Tudo o que é produzido ao abrigo do contrato é-te cedido: código, documentação e configuração, incluindo o trabalho de terceiros contratados pelo parceiro.
• Obrigações de segurança. Acesso só através do teu fornecedor de identidade com MFA, funções de menor privilégio, nenhuma conta partilhada, dispositivos do parceiro que cumpram a tua política de dispositivos, remoção de acessos num prazo definido (exemplo: no mesmo dia útil) confirmada por escrito, e notificação de incidentes num número definido de horas.
• Dados pessoais. Se as pessoas do parceiro conseguem chegar a dados pessoais (bases de dados de produção, logs, tickets de suporte), tratam-nos por tua conta, e o artigo 28 do RGPD exige um contrato escrito com o subcontratante: tratamento apenas segundo as tuas instruções documentadas, confidencialidade, medidas de segurança, a tua autorização prévia por escrito antes de recorrer a outro subcontratante, e apagamento ou devolução dos dados no fim do serviço.

Não tens a certeza de que modelo a tua equipa consegue sustentar? Pede uma avaliação gratuita do modelo de equipa: vemos quem é dono do teu backlog, quantas horas de revisão os teus engenheiros séniores têm de facto e quem assegura hoje o on-call, e depois recomendamos um modelo e entregamos-te um esboço de contrato para ele.

Primeiro dia: acessos à medida do modelo

O onboarding, o acordo de trabalho e o plano da primeira semana estão em como criar e gerir uma equipa de engenharia remota. O que muda com o modelo é aquilo em que cada pessoa pode mexer.

• Contas através do teu fornecedor de identidade. Uma conta nominativa por engenheiro no teu diretório, MFA obrigatório e todas as ferramentas com início de sessão através dele. Assim, desativar uma conta deve retirar o acesso em todo o lado.
• Nenhuma credencial partilhada. Nada de logins de equipa nem de chaves coladas no chat. Os segredos vêm do teu gestor de segredos, limitados por ambiente.
• Funções nos repositórios por modelo. Engenheiros de extensão: permissões de programador, sem admin. Squad: o tech lead mantém os repositórios do squad. Equipa gerida: admin nos repositórios que lhe pertencem, que continuam na tua organização. A proteção de branches e a revisão obrigatória aplicam-se a todos.
• Funções na cloud por modelo. Extensão e squad: acesso de leitura à produção, deploys só através do pipeline, acesso elevado só durante o on-call. Equipa gerida: permissões operacionais nos ambientes que opera, com registos de auditoria que podes ler.
• Grupos, não indivíduos. Atribui as funções a um grupo por equipa, por exemplo partner-squad-billing, para que acrescentar ou retirar uma pessoa seja uma única alteração revisível.
• Testa a saída no primeiro dia. Desativa uma conta de teste nesse grupo e confirma que perde os repositórios, a consola da cloud, o chat e quaisquer chaves ou tokens que tenha criado. Mais vale encontrar agora a ferramenta que fica fora do single sign-on do que no último dia de alguém.
• Um primeiro ticket entregue na primeira semana. Pequeno e real, através do pipeline completo: a prova de que o acesso funciona de ponta a ponta.

Está a funcionar? Lê-o no teu histórico de git

O teu histórico de git já regista quando o trabalho começou e quando chegou ao branch principal. O script abaixo recebe um ficheiro com os endereços de email do parceiro e indica:

• Merges por semana ISO que contêm commits deles.
• Mediana de horas entre o primeiro commit de um branch e o seu merge: lead time até ao merge, não até à produção.
• Mediana de horas entre o último commit de um branch e o seu merge: uma aproximação de quanto tempo o trabalho terminado espera pela revisão e pela aprovação.
• Diretórios de primeiro nível que só o parceiro alterou no período: o que terias de reaprender se a colaboração terminasse.

Recebe endereços, não um domínio, porque os engenheiros que iniciam sessão através do teu fornecedor de identidade podem fazer commits com um endereço do teu domínio. Faz commit de um .mailmap para que os endereços de cada pessoa se resolvam num só, e põe na lista os canónicos.

#!/usr/bin/env bash
# Usage: team-metrics.sh REPO BRANCH SINCE AUTHORS_FILE
#   e.g. team-metrics.sh ~/src/app main "12 weeks ago" partner-authors.txt
# AUTHORS_FILE: one email address per line, for everyone on the partner's team.
set -euo pipefail
export LC_ALL=C   # dot as decimal separator, byte-order sort
repo=$1 branch=$2 since=$3 authors_file=$4

author_args=(--fixed-strings)
while IFS= read -r email || [ -n "$email" ]; do
  if [ -n "$email" ]; then author_args+=(--author="$email"); fi
done < "$authors_file"
[ "${#author_args[@]}" -gt 1 ] || { echo "No addresses in $authors_file" >&2; exit 1; }

median() {
  sort -n | awk '{ v[NR] = $1 }
    END { if (!NR) print "n/a"; else if (NR % 2) print v[(NR + 1) / 2];
          else print (v[NR / 2] + v[NR / 2 + 1]) / 2 }'
}

# 1. Every merge into BRANCH that contains at least one commit from the team:
#    ISO week, hours from the branch's first commit to the merge (lead time to merge),
#    hours from its last commit to the merge (a proxy for the review and approval wait).
merges=$(mktemp)
git -C "$repo" log "$branch" --first-parent --merges --since="$since" \
  --date=format:'%G-W%V' --format='%H %ct %cd' |
while read -r merge merged_at week; do
  [ -n "$(git -C "$repo" log -1 --format=%H "${author_args[@]}" "$merge^1..$merge^2")" ] || continue
  first=$(git -C "$repo" log --format=%at "$merge^1..$merge^2" | awk 'NR == 1 || $1 < m { m = $1 } END { print m }')
  last=$(git -C "$repo" log -1 --format=%ct "$merge^2")
  echo "$week $(( (merged_at - first) / 3600 )) $(( (merged_at - last) / 3600 ))"
done > "$merges"

echo "Merges per week with the team's commits:"
cut -d' ' -f1 "$merges" | sort | uniq -c
echo "Median hours, first commit to merge: $(cut -d' ' -f2 "$merges" | median)"
echo "Median hours, last commit to merge:  $(cut -d' ' -f3 "$merges" | median)"
rm -f "$merges"

# 2. Top-level directories that only the team changed in the window: what you
#    would have to relearn if the engagement ended tomorrow.
echo "Directories changed only by the team (file changes, directory):"
git -C "$repo" log "$branch" --no-merges --since="$since" --format='author:%aE' --name-only |
awk -v list="$authors_file" '
  BEGIN { while ((getline line < list) > 0) if (line != "") team[tolower(line)] = 1 }
  /^author:/ { ours = (tolower(substr($0, 8)) in team); next }
  NF { n = split($0, part, "/"); dir = (n > 1 ? part[1] "/" : "./")
       if (ours) t[dir]++; else o[dir]++ }
  END { for (dir in t) if (!(dir in o)) print t[dir], dir }' | sort -rn

A parte dos tempos precisa de merge commits; se a tua plataforma faz squash ou rebase no merge, vai buscar os tempos de revisão à API de merge requests dela. Corre-o todos os meses e compara com a tua própria equipa no mesmo repositório, nunca com o benchmark de outra empresa.

Sinais de que o modelo está a falhar

Os números mostram que algo mudou; estes sinais mostram que parte se partiu.

Extensão de equipa:

• A mediana do último commit até ao merge não para de subir: os teus revisores são o gargalo, e a verificação de capacidade falhou.
• Todas as perguntas vão para as mesmas duas pessoas, e o rendimento delas cai.
• Os tickets chegam meio escritos e são reescritos durante o standup.

Squad dedicado:

• Os teus engenheiros voltam a rever a maioria das alterações do squad. Ou não confiam na revisão do tech lead, ou não deviam confiar.
• Os diretórios em que só o squad mexe não param de crescer, sem aparecerem registos de decisão novos.
• As demos mostram trabalho terminado que o teu product owner nunca pediu.

Equipa totalmente gerida:

• Os relatórios descrevem atividade (tickets fechados, horas registadas) em vez dos resultados do contrato.
• A aceitação dos marcos atrasa-se, porque os critérios de aceitação nunca foram acordados.
• Ninguém sabe dizer quem atende um alerta às 03:00 de um serviço operado pelo parceiro, ou o runbook já não corresponde à produção.

Mudar de modelo

Cada mudança tem pré-condições; verifica-as antes de o contrato mudar.

De extensão para squad, normalmente porque os teus engenheiros séniores não conseguem acompanhar as revisões:

• Dá ao squad uma área delimitada (um serviço, uma linha de produto, um conjunto de diretórios) com interfaces escritas para o resto.
• Entrevista tu o tech lead: essa pessoa passa a tomar decisões que antes tomavas tu.
• Passa os engenheiros da extensão para o squad sempre que puderes; são eles que têm o contexto.
• Acorda que alterações continuam a passar pela tua revisão de arquitetura.

De squad para equipa gerida, normalmente porque queres que a área seja operada, e não só construída:

• Põe por escrito os critérios de aceitação e os níveis de serviço: a partir de agora aceitas resultados em vez de supervisionares trabalho.
• Passa e ensaia o on-call e os runbooks, incluindo o teu caminho de escalamento.
• Mantém os repositórios, as contas de cloud e os pipelines na tua organização. O parceiro opera-os; tu és o dono.

De volta à extensão ou para dentro de casa, normalmente porque contrataste ou a área está concluída:

• Corre o relatório de diretórios: tudo aquilo em que só o parceiro mexeu precisa de um responsável identificado do teu lado.
• Põe os teus engenheiros a fazer os próximos releases e um restauro enquanto o parceiro ainda pode ajudar.
• Reduz uma função de cada vez, com o tech lead no fim.

Avaliação gratuita do modelo de equipa

Se estás prestes a trazer engenheiros externos, ou se uma colaboração está a render abaixo do esperado, a nossa área de equipas dedicadas revê a tua situação sem custos. A avaliação cobre:

• Capacidade: quem escreve e prioriza os teus tickets, quantas horas de revisão os teus engenheiros séniores têm e quem assegura hoje o on-call.
• Adequação do modelo: que modelo a tua equipa consegue sustentar hoje e o que tem de estar pronto antes do seguinte.
• Esboço de contrato: faturação, aceitação, substituição e pré-aviso, saída, propriedade intelectual e acessos, redigido para o teu caso.

Recebes por escrito uma lista de conclusões, um modelo recomendado e um esboço de contrato, sem qualquer compromisso. Pede a tua avaliação gratuita do modelo de equipa, ou vê como trabalham as nossas equipas de engenharia nearshore a partir de Portugal.