Antes de pedir um orçamento
Contratar uma empresa de software é entregar a alguém uma parte do seu negócio que, provavelmente, não consegue rever linha a linha. Não vai ler o código, mas vai viver com ele: os ecrãs lentos, o erro que não para de voltar, a alteração simples que, de alguma forma, demora duas semanas. É por isso que a decisão tem de ir além do preço e da boa primeira impressão.
Antes de falar com os fornecedores, escreva um breve briefing: o problema que o projeto resolve, quem o vai utilizar, o que tem de estar pronto na primeira versão e se existe uma data que não pode mudar, como um lançamento ou uma época de vendas. Esse briefing facilita a comparação das respostas e mostra-lhe quem está realmente a ouvir e quem está a ler um guião.
Portefólio: peça trabalhos que estejam no ar
Capturas de ecrã bonitas no Dribbble ou no Behance não provam que algo funciona. Peça links de projetos entregues: o site que carrega, a aplicação que pode instalar, a loja que recebe encomendas reais. Abra-os no telemóvel, navegue, preencha um formulário e veja se a página continua rápida numa ligação móvel.
Pergunte o que a empresa fez realmente em cada projeto. Construiu tudo ou apenas o design? Pegou num sistema a meio? Ainda o mantém? Uma equipa séria responde sem hesitar e, quando há um acordo de confidencialidade, explica o que pode e o que não pode mostrar.
Se o seu projeto tem um requisito específico, como faturação recorrente, integração com um ERP ou uma funcionalidade de IA, pergunte se já construíram algo semelhante e peça para ver a funcionar. A experiência com o seu tipo de problema vale mais do que a experiência com a framework da moda.
O processo, do diagnóstico à entrega
Pergunte o que acontece entre a assinatura e o lançamento. Uma boa resposta tem etapas claras: perceber o negócio, definir o âmbito, desenhar os ecrãs, desenvolver, testar e publicar. Quando um fornecedor salta diretamente do orçamento para a programação, as perguntas que deviam ter surgido no diagnóstico aparecem a meio do projeto, quando as alterações custam mais.
Preste atenção também ao ritmo de entrega. Etapas curtas com versões de teste que pode abrir no seu telemóvel ou navegador permitem corrigir o rumo cedo. O padrão oposto, meses de silêncio seguidos de uma grande apresentação, é de onde vêm as piores surpresas.
- Qual é a primeira etapa e o que recebo no fim dela?
- Vou ver um protótipo dos ecrãs antes de o desenvolvimento começar?
- Com que frequência vou receber uma versão para testar?
- Quem testa o produto e em que dispositivos?
- O que acontece se eu quiser alterar algo a meio?
Quem faz o trabalho e como vão comunicar
As pessoas que vendem o projeto nem sempre são as que o constroem. Algumas empresas fecham o negócio e passam o trabalho a freelancers ou a outra empresa, e o cliente só descobre quando a qualidade desce ou ninguém sabe responder a uma pergunta técnica. Subcontratar não é errado em si, mas deve ser dito logo no início. Pergunte quem vai trabalhar no seu projeto, se pertencem à equipa da empresa e se poderá falar com os programadores quando for preciso.
Combine como vai funcionar a comunicação: que canal, com que frequência recebe atualizações e quem é o ponto de contacto de cada lado. Uma breve reunião semanal sobre o que foi feito, o que se segue e o que está bloqueado vale mais do que dezenas de mensagens dispersas. Se vai contratar uma equipa nearshore, por exemplo uma empresa brasileira a trabalhar com um cliente na Europa, pergunte pelo horário em comum e pela língua usada no dia a dia. E repare em como o fornecedor comunica durante o processo comercial. Se as respostas demoram dias agora, raramente ficam mais rápidas depois de assinado o contrato.
Código, domínio e contas: de quem é o quê
Esta é a pergunta que muita gente esquece e depois lamenta. O código-fonte é seu? O domínio está registado em nome da sua empresa? O alojamento, a base de dados e as contas da App Store, do Google Play e de pagamentos estão em seu nome ou no do fornecedor?
A situação a evitar é ter tudo nas contas do fornecedor. Se a relação terminar, perde o acesso ao seu próprio produto ou tem de negociar para o recuperar. O ideal é que o código esteja num repositório a que tem acesso, que as principais contas estejam em seu nome e que haja documentação suficiente para outra equipa pegar no trabalho.
Pergunte que tecnologias vão usar e porquê. Uma stack madura e bem documentada facilita contratar outra pessoa mais tarde. Uma ferramenta proprietária que só aquela empresa sabe operar deixa-o refém.
Contrato e âmbito por escrito
Uma boa proposta descreve as entregas com detalhe suficiente para evitar discussões mais tarde: ecrãs, funcionalidades, perfis de utilizador, integrações, o que fica fora do âmbito, o prazo de cada etapa, o preço e as condições de pagamento. Expressões como "sistema de gestão completo" ou "uma aplicação como a do nosso concorrente" não são âmbito, porque cada parte vai imaginar algo diferente.
Leia com atenção o que acontece quando algo muda. Alguma coisa vai mudar, porque cada projeto ensina coisas que ninguém sabia no início. O contrato deve dizer como as alterações são avaliadas, orçamentadas e aprovadas antes de entrarem no calendário. Verifique também o período de garantia para correção de erros após a entrega, a confidencialidade, o tratamento de dados pessoais ao abrigo da lei de proteção de dados que se aplica ao seu caso (RGPD, CCPA ou LGPD) e as condições para terminar a colaboração.
O que acontece depois do lançamento
O lançamento é quando começa a utilização real, e é a utilização real que revela as correções necessárias. Um ecrã que falha num telemóvel específico, um fluxo que os clientes não percebem, uma integração de terceiros que muda de versão sem aviso. Pergunte quem trata disso, com que rapidez e como é faturado.
Pergunte se existe um plano de manutenção, o que cobre (correção de erros, atualizações de segurança, pequenas melhorias, monitorização) e como são tratadas as novas funcionalidades. Um fornecedor que entrega e desaparece obriga-o a procurar alguém novo para trabalhar num código que nunca viu, e esse recomeço raramente é barato.
Sinais de alerta antes de assinar
Alguns comportamentos surgem antes do contrato e dizem muito sobre como o projeto vai correr:
Desconfie também do jargão excessivo usado para impressionar. Quem domina o assunto sabe explicar, em linguagem simples, porque é que uma escolha faz sentido para o seu caso.
- Um orçamento enviado sem uma única pergunta sobre o seu negócio, os seus utilizadores ou as suas regras.
- Um prazo demasiado curto para o âmbito, prometido antes de perceberem o projeto.
- Um "fazemos tudo" como resposta a cada pedido, sem assinalar riscos nem sugerir algo para mais tarde.
- Relutância em mostrar projetos no ar ou em dizer quem vai construir o seu.
- Código, domínio e contas mantidos em nome do fornecedor.
- Pagamento total adiantado, sem etapas associadas a entregas.
- Uma proposta sem qualquer menção ao que fica fora do âmbito.
Perguntas para levar à reunião
Se quer um guião, leve estas perguntas a todos os fornecedores e compare as respostas lado a lado. Para além do conteúdo, repare em quem responde com clareza e quem se esquiva.
Na BG Coding, só orçamentamos depois de perceber o projeto, e a proposta traz âmbito, prazo e preço definidos, divididos em etapas que pode acompanhar. O código e as contas pertencem ao cliente. Se está a comparar fornecedores, use esta mesma lista connosco.
- Posso ver projetos semelhantes ao meu a funcionar no ar?
- Quais são as etapas e o que recebo em cada uma?
- Quem vai trabalhar no projeto e com quem falo no dia a dia?
- Com que frequência vou testar uma nova versão?
- O código, o domínio e as contas ficam em meu nome?
- Como são tratadas as alterações de âmbito?
- O que está incluído depois do lançamento?