Terceirização de desenvolvimento de software geralmente é apresentado como uma simples decisão de capacidade: escolher um fornecedor, adicionar desenvolvedores e começar a enviar recursos. Na prática, a parte difícil é determinar se uma equipe externa pode trabalhar de forma segura e eficaz dentro do seu ambiente de engenharia existente.
Um portfólio sofisticado pode demonstrar que uma empresa concluiu projetos, mas não informa como seus desenvolvedores revisam o código, respondem a incidentes de produção, gerenciam o acesso, testam alterações ou documentam decisões arquitetônicas.
Antes de assinar um contrato de longo prazo, avalie a equipe por meio de um pequeno e controlado envolvimento técnico. Este artigo apresenta uma estrutura focada no desenvolvedor para avaliar uma equipe de software terceirizada e inclui um script Node.js para transformar os resultados em uma pontuação repetível.
1. Defina primeiro o problema de engenharia
Não comece perguntando quantos desenvolvedores um fornecedor pode fornecer. Comece documentando o problema técnico que a equipe deverá resolver.
Seu resumo deve explicar:
- A pilha de tecnologia existente
- A arquitetura atual do aplicativo
- Requisitos importantes de segurança ou conformidade
- Tráfego esperado e restrições de desempenho
- Processos de teste e implantação
- Dívida técnica conhecida
- Horário de trabalho necessário e sobreposição de comunicação
- As responsabilidades que devem permanecer internas
Separe os requisitos essenciais das preferências. Se os serviços de produção forem executados em Node.js e PostgreSQL, experiência relevante com essas tecnologias poderá ser essencial. A experiência com uma ferramenta específica de gerenciamento de projetos é provavelmente apenas uma preferência.
Você também deve definir o que significa sucesso. “Melhorar a aplicação” é difícil de medir. “Reduzir o tempo médio de resposta da API em 20% sem alterar o comportamento existente do cliente” dá à equipe uma meta técnica clara.
2. Avalie os desenvolvedores, não apenas a apresentação de vendas
As pessoas que participam de uma chamada introdutória de vendas podem não ser os desenvolvedores designados para o seu projeto. Peça para conhecer o líder técnico proposto e pelo menos um engenheiro que executaria o trabalho.
Aproveite a reunião para discutir um problema realista da sua aplicação. Bons candidatos técnicos devem fazer perguntas sobre as restrições antes de sugerir uma solução.
Por exemplo, se você perguntar como eles melhorariam um endpoint lento, preste atenção se eles investigam:
- Desempenho de consulta de banco de dados
- Índices ausentes
- Solicitações de rede repetidas
- Oportunidades de cache
- Tamanho da carga útil
- Perfil em nível de aplicativo
- Objetivos de nível de serviço existentes
Uma recomendação imediata para reescrever o serviço ou alterar as estruturas pode indicar que a equipe está escolhendo ferramentas familiares em vez de investigar o problema real.
Evite confiar inteiramente em quebra-cabeças de algoritmos. Eles revelam pouco sobre como alguém lê uma base de código desconhecida, analisa uma solicitação pull, diagnostica um incidente ou explica um comprometimento técnico.
3. Use um pequeno teste técnico pago
Um teste pago é mais informativo do que várias entrevistas. Dê à equipe uma tarefa limitada que se assemelhe ao trabalho que ela realizaria após a contratação, mas que não exponha sistemas críticos.
As tarefas de teste adequadas incluem:
- Adicionando validação a um endpoint de API existente
- Melhorando uma consulta lenta ao banco de dados
- Escrevendo testes para um serviço não testado
- Corrigindo um problema de acessibilidade em um componente
- Documentando um pequeno subsistema
- Adicionando log estruturado a um caminho de solicitação
A tarefa deve ter um limite claro e um resultado esperado. Não deve ser um trabalho gratuito disfarçado ou uma solicitação para construir um recurso de produção completo sem pagamento.
Durante o teste, avalie mais do que se o código é executado. Revise como os desenvolvedores:
- Esclareça requisitos incertos
- Divida o trabalho
- Confirmações de estrutura
- Explique as decisões de implementação
- Escreva e atualize testes
- Responder aos comentários de avaliação
- Documente os riscos restantes
O processo de trabalho geralmente fornece evidências mais úteis do que o recurso finalizado.
4. Revise o processo de pull request da equipe
A revisão de código é um dos indicadores mais claros de maturidade da engenharia. Peça à equipe para demonstrar como prepara e analisa uma solicitação pull.
Uma solicitação pull útil deve explicar:
- Que problema a mudança resolve
- Por que a abordagem selecionada foi usada
- Quais alternativas foram consideradas
- Como a mudança foi testada
- Se são necessárias configurações ou migrações de banco de dados
- O que pode dar errado durante a implantação
- Como a mudança pode ser revertida
Solicitações pull grandes são difíceis de revisar e têm maior probabilidade de ocultar alterações não relacionadas. Procure dar preferência a envios pequenos e focados com commits descritivos.
Os revisores devem abordar correção, capacidade de manutenção, segurança, testes e efeitos operacionais. Os comentários de formatação têm valor, mas muitos problemas de estilo devem ser tratados automaticamente por formatadores e linters.
Guia do SitePoint para processo e documentação fornece ideias adicionais para tornar as práticas de desenvolvimento visíveis e repetíveis.
5. Inspecione as práticas de teste
Uma afirmação como “seguimos as melhores práticas” não é suficiente. Peça aos desenvolvedores que expliquem o que eles testam e por quê.
Uma estratégia de teste equilibrada normalmente inclui:
- Testes unitários para lógica isolada
- Testes de integração para limites de banco de dados e serviços
- Testes de contrato para integrações importantes
- Testes completos para jornadas críticas de usuários
- Análise estática e linting
- Verificações de segurança e dependência
A qualidade do teste é mais importante do que a porcentagem bruta de cobertura. Um projeto pode relatar alta cobertura e não testar caminhos de erro, regras de autorização, simultaneidade ou comportamento de integração.
Pergunte o que acontece quando um teste falha intermitentemente. Uma equipe madura investiga ou isola o problema. Ele não simplesmente executa novamente o pipeline até que ele passe.
O teste também deve mostrar se os desenvolvedores atualizam os testes quando os requisitos mudam. Os testes fazem parte da implementação, não uma fase separada concluída após a conclusão de toda a codificação.
6. Examine a segurança e os controles de acesso
Os desenvolvedores externos devem receber apenas o acesso necessário para o trabalho que lhes foi atribuído. Eles não devem receber automaticamente acesso irrestrito ao banco de dados de produção, credenciais de administrador compartilhadas ou chaves de nuvem de longa duração.
Um processo de integração mais seguro oferece:
- Contas individuais
- Permissões baseadas em funções
- Autenticação multifator
- Ambientes separados de desenvolvimento e preparação
- Segredos gerenciados
- Atividade administrativa registrada
- Acesso limitado no tempo, quando apropriado
- Um procedimento de desligamento documentado
Pergunte como a equipe lida com os segredos durante o desenvolvimento local. As credenciais não devem aparecer no código-fonte, nas mensagens de bate-papo, nas capturas de tela ou nos arquivos de configuração compartilhados.
A responsabilidade pela segurança deve permanecer no código do aplicativo. Autenticação, autorização, validação e registro de auditoria não podem depender inteiramente das instruções do desenvolvedor ou da política da equipe.
7. Discuta a arquitetura por meio de decisões
Peça ao líder técnico proposto para revisar um pequeno cenário arquitetônico. O objetivo não é descobrir se a solução preferida deles corresponde à sua. É para ver se eles conseguem explicar as compensações.
Suponha que um aplicativo precise processar arquivos carregados de forma assíncrona. Uma discussão cuidadosa pode abranger:
- Uploads diretos versus uploads com proxy de servidor
- Armazenamento de objetos privados
- Filas de trabalho
- Validação de tipo de arquivo
- Repetir comportamento
- Idempotência
- Verificação de malware
- Atualizações de status
- Recuperação de falhas
- Regras de retenção
Seja cauteloso quando cada problema for resolvido com uma tecnologia moderna. Uma fila de mensagens, um microsserviço, um fluxo de eventos ou uma função sem servidor podem ser apropriados, mas também criam custos operacionais.
A recomendação mais forte é geralmente o projeto mais simples que satisfaça os requisitos conhecidos e deixe um caminho claro para alterações futuras.
8. Teste de comunicação e documentação
O trabalho distribuído aumenta a importância da comunicação escrita. Uma equipe deve ser capaz de progredir sem exigir que todos os participantes participem de reuniões contínuas.
Durante o teste, inspecione a qualidade de:
- Descrições de tarefas
- Perguntas técnicas
- Resumos de solicitação pull
- Notas de arquitetura
- Atualizações de status
- Relatórios de incidentes
- Documentação de transferência
Uma atualização de status útil descreve o trabalho concluído, o trabalho atual, os bloqueadores, os riscos e as decisões que exigem informações. “Trabalhar na API” não fornece aos proprietários do projeto informações suficientes para responder.
A sobreposição de fuso horário deve ser deliberada. Alguma colaboração em tempo real é valiosa, mas exigir que uma equipe distribuída permaneça on-line durante todo o dia de trabalho de outra região pode reduzir a produtividade e a retenção.
9. Defina a propriedade antes do início do desenvolvimento
Um contrato deve especificar mais do que taxas de faturamento e datas de entrega. A propriedade da engenharia também deve ser clara.
Decida quem é responsável por:
- Aprovação de arquitetura
- Implantações de produção
- Avaliações de segurança
- Migrações de banco de dados
- Resposta a incidentes
- Atualizações de dependência
- Monitoramento e alertas
- Documentação técnica
- Transferência de propriedade intelectual
- Removendo o acesso quando o envolvimento termina
Sua organização deve manter o controle dos repositórios de código-fonte, contas de nuvem, domínios, credenciais de produção, sistemas de monitoramento e pipelines de implantação.
Evite uma situação em que apenas a equipe externa entenda como o aplicativo é construído ou operado. Exigir documentação e transferência de conhecimento ao longo do projeto em vez de solicitá-los apenas antes do término do contrato.
10. Meça os resultados, não a atividade
Horas trabalhadas, tickets fechados e linhas de código não medem de forma confiável o valor da engenharia. Eles podem encorajar trabalho desnecessário e desencorajar os desenvolvedores de simplificarem o sistema.
Em vez disso, use um pequeno conjunto de indicadores orientados para resultados:
- Prazo de entrega para alterações aprovadas
- Frequência de implantação
- Alterar taxa de falha
- Tempo necessário para restaurar o serviço
- Taxa de defeitos escapados
- Tempo de revisão da solicitação pull
- Confiabilidade em relação aos objetivos de serviço acordados
- Conclusão da documentação e transferência de conhecimento
As métricas requerem contexto. A taxa de falhas de alterações pode aumentar temporariamente enquanto uma equipe melhora a frequência de implantação e revela problemas anteriormente ocultos. Use medidas para orientar as conversas em vez de classificar desenvolvedores individuais.
Você pode tornar a avaliação mais consistente pontuando todos os candidatos de acordo com os mesmos critérios. O seguinte script Node.js calcula um resultado ponderado e identifica áreas que requerem revisão adicional:
const categories = {
technicalTrial: 0.25,
codeReview: 0.15,
testing: 0.15,
security: 0.15,
architecture: 0.10,
communication: 0.10,
documentation: 0.10
};
function evaluateTeam(scores) {
const missing = Object.keys(categories).filter(
category => typeof scores(category) !== "number"
);
if (missing.length > 0) {
throw new Error(
`Missing scores: ${missing.join(", ")}`
);
}
for (const (category, score) of Object.entries(scores)) {
if (score < 0 || score > 5) {
throw new RangeError(
`${category} must be scored from 0 to 5`
);
}
}
const weightedScore = Object.entries(categories)
.reduce((total, (category, weight)) => {
return total + scores(category) * weight;
}, 0);
const risks = Object.entries(scores)
.filter(((, score)) => score < 3)
.map(((category, score)) => ({
category,
score
}));
return {
score: Number(weightedScore.toFixed(2)),
maximumScore: 5,
recommendation:
weightedScore >= 4
? "Strong candidate"
: weightedScore >= 3
? "Continue with a limited engagement"
: "Resolve major concerns before hiring",
risks
};
}
const result = evaluateTeam({
technicalTrial: 4.2,
codeReview: 4,
testing: 3.5,
security: 2.5,
architecture: 4,
communication: 4.5,
documentation: 3
});
console.log(JSON.stringify(result, null, 2));
Os pesos devem refletir os riscos reais do projeto. Uma aplicação financeira pode atribuir mais peso à segurança, enquanto um protótipo inicial pode enfatizar a velocidade de entrega e a comunicação.
Não use a pontuação total como uma decisão automática de contratação. Uma pontuação de segurança baixa não deve ser ocultada por fortes habilidades de comunicação ou apresentação. Trate cada pontuação abaixo do limite aceitável como uma questão separada que deve ser investigada.
Considerações Finais
A escolha de uma equipe de desenvolvimento terceirizada é uma decisão de engenharia, não apenas uma decisão de compra. Portfólios e descrições de empresas podem ajudar a criar uma lista inicial, mas não podem substituir evidências de trabalho técnico real.
Defina o problema, conheça os desenvolvedores, execute uma avaliação paga, inspecione suas práticas de revisão e teste de código, verifique os controles de acesso e esclareça a propriedade antes de conceder acesso a sistemas importantes.
Uma equipe externa capacitada deve tornar o seu trabalho compreensível. O seu código, decisões, documentação e práticas operacionais devem permanecer úteis mesmo após o término do trabalho.
