Como Escolher um Profissional ou Parceiro de Tecnologia
Um roteiro objetivo para avaliar profissionais e empresas de tecnologia por diagnóstico, segurança, arquitetura, comunicação, operação e evidências.
Escolher um profissional ou parceiro de tecnologia não deveria depender apenas da linguagem de programação listada no currículo ou do menor orçamento. A contratação correta precisa combinar entendimento do negócio, capacidade técnica, segurança, comunicação e responsabilidade pela operação depois da entrega.
Este roteiro ajuda empresas a comparar propostas de forma objetiva, inclusive quando não possuem uma liderança técnica interna.
Comece definindo o problema
Antes de entrevistar fornecedores, registre o cenário em uma página:
- qual processo ou resultado precisa mudar;
- quem é afetado;
- quais sistemas e dados estão envolvidos;
- quais restrições de prazo, orçamento e conformidade existem;
- como o sucesso será medido;
- o que está explicitamente fora do escopo.
Esse documento não precisa antecipar a solução. Sua função é permitir que os candidatos façam perguntas melhores. Um parceiro que propõe tecnologia antes de entender o problema está assumindo riscos que depois aparecem como mudança de escopo.
Sete critérios para avaliar
1. Qualidade do diagnóstico
Observe se o profissional investiga usuários, processo atual, integrações, segurança e impacto operacional. Perguntas sobre exceções e falhas são tão importantes quanto perguntas sobre o fluxo ideal.
2. Clareza das alternativas
Uma boa proposta explica opções e concessões. Pode ser mais adequado configurar um produto existente, integrar ferramentas ou desenvolver algo sob medida. Desconfie de respostas em que toda necessidade leva à mesma tecnologia.
3. Evidência técnica
Peça exemplos de decisões, documentação, testes ou arquitetura, respeitando a confidencialidade de clientes anteriores. O objetivo não é obter código de terceiros, mas entender como a pessoa raciocina, valida e registra o trabalho.
4. Segurança incorporada ao processo
Segurança não deve aparecer como atividade opcional no final. O NIST SSDF recomenda integrar práticas de desenvolvimento seguro ao ciclo de software. Pergunte sobre revisão de dependências, segredos, autenticação, autorização, testes, registro de vulnerabilidades e resposta a incidentes.
5. Comunicação e governança
Defina quem decide, como riscos são apresentados, qual a frequência de acompanhamento e onde ficam documentos. O parceiro deve traduzir consequências técnicas sem esconder incerteza atrás de jargão.
6. Capacidade de operar
Entrega não termina no deploy. Verifique monitoramento, backup, recuperação, suporte, atualização de dependências, documentação e transferência de conhecimento. Um sistema sem responsável operacional acumula risco silenciosamente.
7. Aderência comercial
Compare escopo, premissas, propriedade intelectual, licenças, ambientes, suporte, forma de cobrança e critérios de aceite. Preço sem essas condições não é comparável.
Perguntas para a entrevista
- Como vocês validariam se vale construir ou comprar?
- Quais informações ainda faltam para estimar?
- Quais são os três maiores riscos deste projeto?
- Como mudanças de escopo são tratadas?
- Que testes e evidências acompanham cada entrega?
- Como acessos e segredos são controlados?
- Como o sistema será monitorado em produção?
- Quem mantém a solução se a equipe mudar?
- Como ocorre a documentação e a passagem de conhecimento?
- O que pode fazer o projeto falhar mesmo com código correto?
Respostas concretas, com limites e exemplos de processo, valem mais do que garantias absolutas.
Como analisar a proposta
Monte uma matriz com pesos definidos antes de receber os valores. Um exemplo:
| Critério | Peso sugerido | Evidência esperada |
|---|---|---|
| Entendimento do problema | 20% | diagnóstico, hipóteses e perguntas |
| Arquitetura e integração | 15% | opções e concessões documentadas |
| Segurança e privacidade | 15% | controles, testes e responsabilidades |
| Plano de entrega | 15% | etapas, critérios de aceite e riscos |
| Operação e suporte | 15% | monitoramento, SLA e continuidade |
| Comunicação | 10% | rituais, registros e responsáveis |
| Investimento total | 10% | implantação, licenças e manutenção |
Os pesos devem mudar conforme o contexto. Em um sistema crítico, segurança e continuidade provavelmente terão peso maior.
Sinais de alerta
- estimativa fechada sem perguntas suficientes;
- promessa de prazo ou resultado sem premissas;
- acesso compartilhado entre pessoas;
- código sem repositório da empresa;
- dependência de uma única pessoa sem documentação;
- ausência de ambiente de teste;
- uso de componentes sem política de atualização;
- proposta que não define suporte após a entrega;
- resistência a registrar decisões e riscos.
Faça uma etapa de descoberta quando o cenário for incerto
Projetos complexos não precisam começar com um grande contrato de construção. Uma descoberta curta pode produzir mapa do processo, arquitetura inicial, backlog priorizado, riscos, estimativa por faixas e plano de implementação. Esse resultado também melhora a comparação entre fornecedores.
Se a necessidade envolve múltiplos sistemas ou uma decisão de investimento relevante, uma consultoria de TI pode ajudar a estruturar essa etapa antes do desenvolvimento.
Conclusão
O melhor parceiro não é o que promete eliminar toda incerteza, mas o que torna decisões, riscos e evidências visíveis. Avalie a capacidade de compreender o negócio, construir com segurança e sustentar a solução ao longo do tempo.