E se o desenvolvedor se incomodar com tantas perguntas?

Isso já é a resposta. Um profissional experiente reconhece que essas perguntas reduzem retrabalho e mal-entendido para os dois lados. Irritação com perguntas contratuais básicas costuma indicar que as respostas seriam desconfortáveis.

Preciso entender de tecnologia para avaliar as respostas?

Não. Nenhuma das doze perguntas é técnica. Todas são sobre processo, responsabilidade e propriedade, e as respostas boas são compreensíveis por qualquer pessoa. Se você não entende a resposta, o problema é da explicação, não do seu repertório.

Devo mandar as perguntas por escrito ou perguntar na reunião?

Pergunte na reunião e peça as respostas críticas por escrito depois, especialmente as de propriedade, prazo e mudança de escopo. A reação ao vivo mostra o preparo e o registro escrito serve de base para o contrato.

12 perguntas para fazer antes de fechar com um desenvolvedor

Antes de assinar com um desenvolvedor ou estúdio, faça estas doze perguntas e anote as respostas. Nenhuma delas é técnica, todas são respondíveis em dois minutos, e o padrão das respostas prevê com bastante precisão como o projeto vai correr. Leve a lista impressa para a reunião.

Sobre propriedade e saída

1. Quem fica com o código-fonte quando o projeto terminar?

Resposta boa: "Você. O repositório fica em conta da sua empresa desde o primeiro dia." Resposta ruim: qualquer coisa que envolva "o código é nosso, você tem licença de uso". Encerre a conversa se ouvir isso e não houver um motivo contratual claro e negociável.

2. Em nome de quem ficam servidor, banco de dados, domínio e chaves de API?

Resposta boa: tudo em contas corporativas suas, com o fornecedor tendo acesso concedido. Se o servidor está na conta pessoal do desenvolvedor, você depende do cartão de crédito dele para continuar existindo.

3. Se eu quiser trocar de fornecedor daqui a um ano, o que preciso receber de você?

Resposta boa: uma lista pronta, repositório, dump do banco, variáveis de ambiente, documentação de publicação, transferência de acessos. Fornecedores que já pensaram nisso respondem rápido. Os que nunca pensaram improvisam.

Sobre quem executa

4. Quem exatamente vai escrever esse código e qual a senioridade?

É comum a proposta ser desenhada por um sênior e executada por quem está aprendendo. Peça nomes, tempo de casa e a quantos projetos essa pessoa está alocada em paralelo.

5. Quantos projetos vocês estão tocando ao mesmo tempo neste momento?

Não existe número certo, mas existe resposta evasiva. Um estúdio pequeno com oito projetos simultâneos vai dar atenção fatiada ao seu.

6. Quem é o meu ponto de contato e com que frequência falamos?

Resposta boa: uma pessoa nomeada e um ritmo definido (reunião semanal, por exemplo). Resposta ruim: "qualquer um do time, é só chamar no WhatsApp". Sem canal e ritmo definidos, o acompanhamento vira cobrança.

Sobre escopo, prazo e mudança

7. O que está fora do escopo desta proposta?

Um fornecedor que só sabe listar o que está incluído não pensou no projeto o suficiente. A lista de exclusões é o que evita a discussão de agosto.

8. Quando eu pedir uma mudança no meio do projeto, como isso é tratado e cobrado?

Resposta boa: existe um processo, o pedido é registrado, estimado em horas, você aprova por escrito e o prazo é recalculado. Resposta ruim: "a gente vai vendo" ou "isso a gente encaixa". Ambas terminam em atrito.

9. Qual é o marco de entrega mais próximo e o que eu vou ver nele?

Se a primeira coisa que você vai ver funcionando está a três meses de distância, o risco é grande. Bons projetos entregam algo verificável nas primeiras três a quatro semanas, mesmo que pequeno.

Sobre depois da entrega

10. O que exatamente cobre a garantia e por quanto tempo?

Garantia cobre defeito, o que foi especificado e não funciona como especificado. Não cobre funcionalidade nova. Peça o prazo (60 a 90 dias é comum) e o tempo de resposta prometido dentro dela.

11. Se o sistema cair num domingo de manhã, o que acontece?

Resposta boa: existe monitoramento, existe um canal e existe um prazo de resposta acordado, mesmo que seja "segunda de manhã". Resposta ruim: silêncio, ou "isso não vai acontecer". Vai acontecer.

12. Quanto custa manter esse sistema por ano, incluindo infraestrutura?

Se o fornecedor não sabe estimar servidor, banco, e-mail transacional e monitoramento, ele não pensou na operação. Peça o número anual, não o mensal, o anual dói e por isso é honesto.

Como interpretar o conjunto

Padrão de resposta	O que significa
Respostas rápidas, específicas e com números	Já passou por isso várias vezes
"Depende" sem desdobrar em quais fatores	Não avaliou o projeto
Promessa de tudo, sem exclusões	Vai virar aditivo
Desconforto com as perguntas de propriedade	Modelo de negócio depende de dependência
"Nunca tivemos problema"	Ou tem pouco tempo de operação, ou não conta

Uma resposta ruim isolada não invalida um fornecedor. Três ou mais, sim, principalmente se estiverem nas perguntas 1, 2, 8 e 10, que são as que definem quanto poder você mantém depois de pagar.

O que fazer com as respostas

Transforme as respostas críticas em cláusulas. As perguntas 1, 2, 7, 8 e 10 devem virar texto no contrato, com os mesmos termos que foram ditos na reunião. Se algo que foi prometido verbalmente não puder ser escrito, ele não foi prometido de verdade.

E guarde a lista para o próximo projeto. As mesmas doze perguntas funcionam para um sistema de R$ 20 mil e para um de R$ 300 mil, muda o peso das respostas, não a lista.