--- title: "Perguntas a fazer antes de contratar um parceiro de software" description: "Perguntas a fazer a um parceiro de software antes de assinar: quem faz o trabalho, historial, âmbito, dono do código, segurança, transição e sinais de alerta." canonical: https://sdk.enterprises/pt/insights/choosing-a-software-partner language: pt --- # Perguntas a fazer antes de contratar um parceiro de software Atualizado a: 2026-09-25 > Antes de contratar um parceiro de engenharia de software, é preciso saber exatamente quem vai escrever o código, que sistemas semelhantes já entregou, como se definem o âmbito e a aceitação, e a quem pertence o código desde o primeiro dia. Respostas vagas a qualquer uma destas perguntas são um sinal de alerta mais forte do que um preço elevado. ## Saber quem vai realmente escrever o código As pessoas da reunião comercial muitas vezes não são as que vão construir o sistema. Peça os nomes, as funções e a experiência dos engenheiros que vão trabalhar no projeto, e peça para falar com o responsável técnico antes de assinar. Pergunte se alguma parte do trabalho é subcontratada ou feita por freelancers. Ambas as opções podem funcionar bem, mas o cliente deve sabê-lo, e o parceiro deve responder por todas as pessoas que traz. Pergunte também o que acontece se um engenheiro-chave sair a meio do projeto, e quem paga o tempo de que um substituto precisa para se pôr a par. - Quem é o responsável técnico, e que parte do seu tempo dedica a este projeto? - Que engenheiros são trabalhadores da empresa, e quais são subcontratados ou freelancers? - Como são selecionados e verificados os especialistas que trazem? - Qual é o processo se alguém sair ou não for a pessoa certa? ## Pedir um historial que corresponda ao problema Uma longa lista de clientes prova pouco se nada nela se parecer com o projeto em causa. Peça exemplos com restrições semelhantes: o mesmo tipo de sistema, um tráfego ou uma sensibilidade dos dados comparáveis e um contexto regulamentar parecido. Depois pergunte o que esta equipa fez em cada caso, e não o que o programa do cliente alcançou no seu conjunto. Seja preciso quanto à experiência que está a comprar. Algumas empresas apresentam o historial individual dos seus engenheiros, o que é legítimo se for dito com honestidade. Pergunte quando foi fundada a empresa, que trabalhos foram feitos ao abrigo dos seus próprios contratos e se é possível falar com um antigo cliente. ## Pôr por escrito o âmbito, as etapas e a aceitação Muitos litígios nascem de um âmbito que nunca foi escrito com precisão. Uma boa proposta identifica os entregáveis, divide o trabalho em etapas e define como cada etapa é aceite, por exemplo testes que passam, uma demonstração num ambiente de pré-produção ou documentação entregue. Pergunte como são tratados e orçamentados os pedidos de alteração, e qual é o modelo comercial. O preço fixo convém a trabalho bem definido, enquanto o regime de tempo e materiais convém à fase de descoberta e a requisitos em evolução. Em ambos os casos, os pressupostos por trás da estimativa devem estar à vista. ## Resolver a propriedade do código e a transição antes de começar O contrato deve dizer que o código e a propriedade intelectual associada pertencem ao cliente, e a partir de quando. Peça que os repositórios, as contas cloud e os domínios sejam criados na organização do cliente desde o primeiro dia, com o parceiro convidado como colaborador, para nunca depender dele para ter acesso. Planeie a transição no início, e não no fim. Pergunte o que vai receber: documentação, registos de decisões de arquitetura, runbooks de operação e sessões de trabalho com a sua própria equipa. Verifique que licenças de terceiros e open source o projeto vai usar, porque trazem obrigações. ## Combinar como acompanhar o progresso Nunca deveria ser preciso perguntar se o projeto está a correr como previsto. Combine um ritmo fixo, como uma demonstração semanal de software a funcionar e um breve ponto de situação escrito sobre o progresso, os riscos e as decisões que cabem ao cliente. Peça acesso direto ao gestor de tickets e ao repositório, e um interlocutor identificado que responda pela entrega. Esclareça como se escalam os problemas e em quanto tempo se pode esperar uma resposta. ## Testar as práticas de segurança, não os selos Pergunte como os engenheiros acedem aos sistemas e aos dados, como são guardados os segredos, como o código é revisto antes de ir para produção e como se verificam as dependências quanto a vulnerabilidades conhecidas. Respostas concretas valem mais do que um diapositivo cheio de logótipos. Se o parceiro for tratar dados pessoais por conta do cliente, é necessário um acordo de tratamento de dados que cumpra os requisitos do RGPD. Se um fornecedor invocar uma certificação, peça o certificado e o respetivo âmbito, e confirme que cobre a equipa e os serviços que está a contratar. ## Sinais de alerta que devem pôr fim à conversa Um sinal de alerta isolado pode ter explicação. Vários ao mesmo tempo costumam significar que o projeto vai ser mais difícil do que devia. - Não conseguem dizer o nome dos engenheiros que vão fazer o trabalho. - Os casos de estudo mostram resultados, mas não o que esta equipa fez realmente. - A estimativa chega antes de alguém ter feito perguntas detalhadas sobre o sistema. - Os repositórios e as contas cloud ficam sob o controlo do parceiro. - As etapas não têm critérios de aceitação escritos. - As perguntas sobre segurança recebem garantias genéricas em vez de práticas concretas. ## Pontos essenciais - Conhecer o responsável técnico e saber quem vai escrever o código antes de assinar. - Avaliar o historial pela proximidade às restrições do projeto e pelo que a própria equipa fez. - Etapas escritas com critérios de aceitação claros evitam muitos litígios sobre o âmbito. - Manter os repositórios e as contas cloud na organização do cliente desde o primeiro dia. - Pedir práticas de segurança concretas e provas de qualquer certificação que um fornecedor invoque. ## Perguntas frequentes ### Com quantos parceiros falar antes de escolher um? Com os suficientes para comparar diferenças reais de abordagem, o que na maioria dos projetos significa alguns. Dê a cada um o mesmo caderno de encargos e as mesmas perguntas, para que as respostas sejam comparáveis. ### Contrato a preço fixo ou em tempo e materiais: qual escolher? O preço fixo convém a trabalho que se consegue especificar em detalhe antes de começar. O regime de tempo e materiais convém à fase de descoberta, a requisitos em evolução e ao desenvolvimento contínuo, desde que haja relatórios transparentes e demonstrações regulares. ### O que deve abordar uma primeira chamada com um potencial parceiro? O objetivo, as restrições, o calendário e os sistemas existentes, e as perguntas que o parceiro faz de volta. Um parceiro que faz perguntas detalhadas sobre o sistema logo na primeira chamada costuma ser um que o vai orçamentar com honestidade. Na SDK Enterprises, essa primeira chamada é uma conversa de 30 minutos em francês ou em inglês. ## Comece pela sua necessidade - [Criação de websites](https://sdk.enterprises/pt/website-development) - [CTO a tempo parcial](https://sdk.enterprises/pt/fractional-cto) ## Serviços relacionados - [Auditoria técnica e consultoria](https://sdk.enterprises/pt/services/consulting) - [Software à medida](https://sdk.enterprises/pt/services/product-engineering)