O que perguntar antes de contratar desenvolvimento de sistema para a empresa?

Por que as perguntas importam mais que a proposta?

Para contratar desenvolvimento de sistema com segurança, comece pelas perguntas e não pela proposta. Uma proposta bem formatada mostra o que o fornecedor pretende entregar, mas só as respostas revelam como ele entende o problema, como trabalha e o que acontece depois da entrega. Perguntar antes reduz o risco de descobrir tarde demais que escopo, responsabilidades e continuidade foram interpretados de formas diferentes.

Um sistema sob medida passa a fazer parte da rotina da empresa: guarda dados, aplica regras e é usado por pessoas todos os dias. Por isso, a escolha de quem vai construí-lo não deve se apoiar só em portfólio e simpatia na reunião. A decisão envolve entendimento do problema, forma de trabalho, qualidade da entrega e continuidade, e cada um desses pontos pode ser verificado com perguntas objetivas.

Organizações públicas brasileiras precisam documentar decisões desse tipo, e parte do material é aberta. As diretrizes e o modelo de serviços de desenvolvimento, manutenção e sustentação de software publicados pelo governo federal mostram como uma organização estrutura o assunto antes de pedir propostas. A empresa privada não precisa copiar esse rito, mas pode aproveitar a lógica: descrever a necessidade, definir como a entrega será conferida e prever o que acontece depois. [1] [2]

Que problema o sistema precisa resolver?

Antes de falar com qualquer fornecedor, escreva em poucas linhas o problema que o sistema deve resolver. Evite começar por funcionalidades, como “precisamos de um painel”, e descreva a dor: “o financeiro refaz o mesmo relatório à mão toda semana”. Quando o problema está claro, fica mais fácil comparar propostas e perceber quem está resolvendo a sua rotina e quem está apenas oferecendo telas.

A lógica de analisar a necessidade antes de procurar solução aparece, no setor público, no Estudo Técnico Preliminar e na etapa de fundamentação, descritos no portal do Tribunal de Contas da União. Na empresa, isso pode virar um registro simples, com o que acontece hoje, quem sofre com o problema e o que seria considerado uma melhora. Esse registro também protege você de aceitar uma solução bonita para um problema que não era o principal. [4] [7]

• Descrição da rotina atual, com as ferramentas e planilhas que existem hoje.
• Quem usa o processo, quem aprova e quem recebe o resultado.
• Pontos em que o trabalho trava, é refeito ou depende de memória de uma pessoa.
• Regras que não podem ser quebradas, como permissões, prazos e conferências.
• Dados e sistemas que precisam conversar com a novidade.

O fornecedor entende a sua rotina antes de propor?

Um bom sinal é o fornecedor fazer mais perguntas do que respostas na conversa inicial. Quem entende de desenvolvimento sabe que a parte difícil costuma estar nas exceções: o pedido que muda depois de aprovado, o cliente com regra especial, o relatório que só uma pessoa sabe montar. Se a proposta chega pronta sem ouvir quem usa o processo, o risco de retrabalho é maior.

Como o escopo e a primeira entrega devem ser descritos?

Peça que o fornecedor descreva o escopo em partes que possam ser vistas e testadas, e não apenas como uma lista de telas. Uma descrição útil diz o que a pessoa consegue fazer ao final de cada parte, quais dados entram, quais regras se aplicam e o que fica de fora por enquanto. Quando o escopo é vago, qualquer pedido novo vira discussão sobre o que estava ou não combinado.

Pergunte também qual parte pode entrar em uso mais cedo. Uma entrega inicial pequena, usada de verdade por quem faz o trabalho, ensina mais do que meses de reuniões sobre telas ainda inexistentes. Para aprofundar o que definir antes de fechar, veja o que definir no escopo de um sistema sob medida.

• O que a pessoa consegue fazer ao final de cada entrega?
• O que ficou fora do escopo e pode entrar depois?
• Como um pedido novo é avaliado e combinado durante o trabalho?
• Quem na empresa precisa validar cada parte e em quanto tempo isso influencia o ritmo?

Como o fornecedor estima o tamanho do trabalho?

Peça para o fornecedor explicar como chegou à estimativa, não apenas qual é o resultado. Há técnicas diferentes: algumas partem das funcionalidades, outras da experiência com sistemas parecidos, outras de ciclos curtos que reajustam o plano a cada entrega. Os guias sobre pontos de função publicados por uma instituição financeira pública, por exemplo, tratam de uma forma de medir o tamanho funcional do software e de usar essa medida na organização do serviço. [3] [8]

Nenhuma técnica elimina a incerteza, e desconfie de quem a promete. O importante é entender o que muda a estimativa: requisitos novos, dados em mau estado, integrações com sistemas antigos, dependência de respostas da sua equipe. Pergunte como as mudanças são tratadas e quem decide quando elas aparecem. Para entender o que costuma influenciar o prazo, leia quanto tempo leva para desenvolver um sistema.

Como o fornecedor garante qualidade, testes e segurança?

Pergunte como cada entrega é testada antes de chegar até você. Boas respostas citam testes com dados parecidos com os reais, conferência das regras de negócio, separação entre ambiente de teste e ambiente de uso, controle de versões e registro das correções. Se a resposta for apenas “nossa equipe é cuidadosa”, vale pedir exemplos de como isso acontece na prática.

Documentos de órgãos públicos, como a cartilha de boas práticas para desenvolvimento de sistemas da SETIC de Rondônia e a norma de desenvolvimento e manutenção de sistemas da EPE, organizam esses temas em regras que podem servir de roteiro de perguntas. Você não precisa dominar o vocabulário técnico para usá-los: basta perguntar se o fornecedor segue práticas parecidas e como mostra isso ao cliente. [5] [6]

• Quem aceita cada entrega e com base em quais critérios?
• Como são tratados acessos, senhas e permissões por função?
• Há registro das alterações feitas e de quem as fez?
• Existe cópia de segurança dos dados e teste de recuperação?

Quem fica com o código, os dados e a hospedagem?

Código, dados, hospedagem e direitos de uso são decisões diferentes, e confundi-las costuma gerar surpresa no futuro. Pergunte, de forma direta, quem será o responsável por cada item, em nome de quem ficam as contas e os acessos e o que acontece se a relação com o fornecedor terminar. Peça que as respostas estejam escritas na proposta, e não apenas ditas na reunião.

Os dados da empresa merecem atenção especial. Confirme como eles podem ser exportados, em que formato e em quanto tempo isso é possível. A mesma lógica vale para a comparação com ferramentas prontas, tema tratado em software sob medida ou SaaS: qual escolher.

O que acontece depois que o sistema entra em uso?

Sistema em uso precisa de cuidado contínuo: correções, ajustes de regra, atualização de componentes, acompanhamento de falhas e evolução. O modelo de serviços do governo federal trata desenvolvimento, manutenção e sustentação de software juntos, o que indica que a continuidade faz parte da decisão desde o início. Pergunte ao fornecedor como essa fase funciona e quem atende quando algo parar. [2]

Separe três situações: correção de erro, pequena melhoria e nova funcionalidade. Cada uma pode ter um caminho e uma forma de combinar diferentes. Pergunte por qual canal os chamados chegam, como são priorizados e que informações o fornecedor espera receber. Para organizar essa etapa, veja sustentação de software e estabilidade de sistemas.

Como o fornecedor se comunica e quem faz o trabalho?

Pergunte quem será o ponto de contato, quem desenvolve, quem testa e como o andamento será mostrado. Algumas empresas terceirizam partes do trabalho, e isso não é necessariamente um problema, desde que você saiba quem responde pelo resultado e como as informações circulam. Combine o ritmo de reuniões, o formato dos relatos de andamento e o canal para dúvidas rápidas.

Peça também referências de trabalhos parecidos e converse, se possível, com quem já usou o serviço. Pergunte o que foi bem, o que atrasou e como o fornecedor reagiu aos problemas. Para uma visão mais ampla de critérios de escolha, leia como escolher uma software house confiável.

Quais sinais indicam que vale pausar a conversa?

Alguns sinais merecem pausa antes de seguir: pressa para fechar, respostas vagas sobre código, dados e suporte, ausência de perguntas sobre a sua rotina e escopo descrito só por telas. Nenhum desses pontos prova sozinho que o fornecedor é ruim, mas todos indicam que há perguntas sem resposta. O comparativo abaixo mostra como uma conversa saudável costuma se diferenciar.

Qual roteiro de perguntas levar para a reunião?

Para facilitar a conversa, leve um roteiro curto e peça que as respostas sejam registradas por escrito. Assim, você compara fornecedores com os mesmos critérios e evita decidir pela impressão da reunião.

1. Como vocês entenderam o problema que queremos resolver?
2. Que perguntas ainda precisam ser feitas à nossa equipe?
3. O que entra na primeira entrega e o que fica para depois?
4. Como vocês estimam o trabalho e o que pode mudar essa estimativa?
5. Como cada entrega é testada e quem a aprova?
6. Quem fica com o código, os dados e os acessos?
7. Como os dados podem ser exportados se necessário?
8. Quem atende falhas e pedidos de ajuste depois da entrega?
9. Quem da equipe vai trabalhar no nosso projeto e como será a comunicação?
10. Há trabalhos parecidos que possamos conhecer ou referências para conversar?

Quando adiar a decisão ou começar menor?

Adie a decisão quando a empresa ainda não sabe descrever o problema, não tem quem acompanhe o trabalho ou depende de uma mudança de processo que ainda não foi combinada internamente. Um sistema não resolve desalinhamento entre áreas; ele só o torna mais visível. Nesses casos, uma etapa de diagnóstico ou um recorte menor costuma ser mais prudente do que um projeto amplo.

Se a dúvida é se já vale sair da planilha ou se a empresa está preparada para manter um sistema próprio, leia quando trocar a planilha por um sistema e como saber se a empresa está pronta para criar um sistema próprio. Quem decide com calma costuma chegar à reunião com perguntas melhores.