Discovery de software: a etapa que decide o preço do seu projeto

Existe uma etapa que quase todo cliente quer pular e quase todo projeto que deu errado pulou. Ela tem nome estrangeiro, aparece no início do cronograma e parece caro demais para algo que não gera uma tela sequer: o discovery.

O nome atrapalha. Discovery não é workshop, não é reunião de alinhamento e não é papelada antes do trabalho de verdade. É a investigação da operação que transforma uma lista de desejos em um escopo que pode ser construído, estimado e cobrado.

O problema que o discovery resolve

Quando uma empresa descreve o sistema que quer, ela descreve o processo como ele deveria funcionar. Quem executa o processo todo dia conhece outra versão: a que tem exceção, atalho, planilha paralela, combinado informal entre dois setores e aquela regra que só o Fulano sabe aplicar.

Software construído sobre a primeira versão quebra no primeiro contato com a operação real. E aí acontece a conversa mais cara do projeto: "mas isso a gente sempre fez assim". Sempre — só que ninguém contou.

Todo requisito que não foi levantado vira uma suposição. Toda suposição errada vira retrabalho. Todo retrabalho vira custo e prazo.

O que acontece dentro de um discovery

Conversa com quem opera, não só com quem decide

O gestor descreve o objetivo; quem está na ponta descreve a realidade. As duas visões são necessárias, e a segunda é a que costuma faltar. Uma tarde acompanhando o atendimento, o chão de fábrica ou o balcão revela mais do que semanas de reunião.

Mapa do processo como ele é hoje

Não como deveria ser. Cada passo, cada aprovação, cada momento em que a informação sai de um sistema e entra em outro pela mão de alguém. É nesse mapa que aparecem os gargalos que o software precisa atacar — e os que ele não vai resolver, porque são problemas de processo e não de tecnologia.

Inventário técnico

O que já existe e vai continuar existindo: ERP, emissor fiscal, meio de pagamento, planilhas críticas, base legada. Para cada item, três perguntas: tem API, tem documentação, tem alguém que conhece? A resposta muda a estimativa de forma direta.

Regras de negócio e suas exceções

Como o preço é calculado, quem pode aprovar o quê, o que acontece quando o cliente é um caso especial. As exceções são o coração do custo: cada uma delas é um caminho a mais para construir, testar e manter.

Definição de sucesso

O que precisa ser verdade em seis meses para o projeto ter valido a pena? "Ter um sistema" não é resposta. "Fechar o mês em dois dias em vez de dez" é. Sem essa frase, ninguém consegue priorizar nada depois.

O que fica de fora

Tão importante quanto a lista do que será feito. Escopo sem fronteira explícita é escopo que cresce em silêncio.

O que você deve receber ao final

• Mapa do processo atual e do processo desejado, com os pontos de mudança destacados;
• Lista de funcionalidades priorizada, separando o que entra na primeira versão e o que vem depois;
• Proposta de arquitetura e de integrações, com os riscos técnicos já identificados;
• Protótipo navegável ou wireframes dos fluxos principais;
• Estimativa de esforço e prazo, com as premissas assumidas escritas;
• Lista de riscos, e o que será feito com cada um.

Se o discovery termina só com uma apresentação bonita e um valor no fim, ele não foi um discovery.

Quanto custa e quanto tempo leva

Como ordem de grandeza, o discovery costuma representar entre 5% e 15% do esforço total do projeto e durar de duas a quatro semanas para sistemas de operação. Parece muito para quem só quer ver tela pronta. É pouco diante do que ele evita: refazer um módulo inteiro porque a regra de aprovação era outra custa muito mais do que a semana que teria revelado a regra.

Há um efeito colateral valioso: com um discovery documentado na mão, você consegue pedir orçamento a qualquer fornecedor e comparar propostas de verdade — porque todo mundo estará estimando a mesma coisa.

Como se preparar e aproveitar melhor

• Libere as pessoas certas. Quem opera o processo precisa de tempo de agenda, não de um encaixe de quinze minutos.
• Junte as planilhas paralelas. Cada uma delas é um requisito que ninguém escreveu.
• Traga os números. Volume de pedidos, de atendimentos, de documentos por mês. Volume define arquitetura.
• Levante acessos desde já. Credencial de API e ambiente de teste de terceiros demoram, e demoram sempre.
• Aceite ouvir "isso não precisa de software". Às vezes o gargalo é de processo, e um bom fornecedor diz isso em vez de vender um módulo.

Sinais de alerta na hora de contratar

• O fornecedor dá preço fechado na primeira reunião, sem ter visto a operação;
• Ninguém pede para falar com quem usa o sistema hoje;
• A proposta lista tecnologias, mas não lista premissas;
• Não existe nada escrito sobre o que está fora do escopo;
• O discovery é oferecido "de graça" — o que geralmente significa que ele será raso, ou que o custo dele está diluído em outro lugar.

Por que tratamos isso como etapa 01

No nosso processo, cada etapa existe para remover um risco específico. O discovery remove o maior deles: o de construir com precisão a coisa errada. Entendemos a operação antes de escrever código — quem usa, quais processos existem hoje, onde está a dor real e o que define sucesso. O escopo nasce da operação, não de suposição.

Se a sua empresa está prestes a pedir orçamento de um sistema, converse com a Sixtec antes de fechar o escopo. É a hora em que a conversa vale mais.