Discovery de software: o que é e por que fazer antes

O jeito mais caro de descobrir um requisito é depois que o sistema está pronto. A tela foi feita, o banco foi modelado, a integração foi escrita, e só então alguém do financeiro diz: "mas a nota de devolução não funciona assim". Corrigir isso agora mexe em tudo.

O discovery, que também chamamos de diagnóstico, é a etapa que antecipa essas descobertas para o momento em que mudar custa uma conversa e um rabisco, e não semanas de retrabalho. Este texto explica o que acontece nessa etapa, o que ela entrega de concreto, como você se prepara para ela e por que cronograma e investimento só fazem sentido depois dela.

O risco de construir o sistema errado

Projetos de software raramente falham por falta de competência técnica. Falham porque construíram, com competência, a coisa errada. Os motivos são quase sempre os mesmos:

• O problema foi descrito pela solução. "Precisamos de um aplicativo" em vez de "os pedidos de campo chegam com erro e atrasam o faturamento".
• Quem pediu não é quem usa. A diretoria descreve o processo como deveria ser; a operação faz de outro jeito, por bons motivos que ninguém registrou.
• As regras estão na cabeça das pessoas. Exceções, aprovações informais e ajustes que acontecem por mensagem nunca apareceram num documento.
• As integrações foram subestimadas. O ERP não tem a API que se imaginava, o fornecedor do sistema legado não responde, o dado que deveria existir não existe.

Uma proposta feita sem entender isso é um chute. Ou o fornecedor coloca uma margem grande para se proteger, ou corta o que não entendeu, ou descobre no meio do projeto e renegocia. Nenhuma das três é boa para você.

O que acontece no diagnóstico

O discovery é trabalho investigativo, feito junto com a sua equipe. As atividades variam conforme o problema, mas costumam incluir:

Entrevistas com quem executa o processo, não só com quem decide. O vendedor, o conferente do depósito, o analista do financeiro. É neles que moram as exceções.

Observação no local, quando faz sentido. Ver o técnico preenchendo a ordem de serviço no caminhão ou o comprador montando a cotação revela coisas que nenhuma reunião revela: sinal de internet fraco, luva que impede usar tela pequena, planilha paralela que ninguém mencionou.

Análise dos artefatos existentes. Planilhas, formulários, relatórios, telas do sistema atual, exportações de dados. Uma planilha bem usada é quase uma especificação.

Levantamento técnico. Quais sistemas existem, como expõem dados, quem os mantém, que restrições de segurança, LGPD e infraestrutura se aplicam.

Priorização. Com tudo na mesa, a equipe separa o que é essencial para a primeira fase do que pode esperar, e define o critério de sucesso.

Como se preparar: problema, usuários e fluxos

Você não precisa chegar com um documento de requisitos. Na verdade, é melhor que não chegue com um documento de telas. O que ajuda de verdade é ter clareza sobre três coisas.

O problema, em termos de negócio. O que está custando tempo, dinheiro, erro ou risco hoje? Como você sabe? O que precisa ser verdade daqui a um tempo para dizer que valeu a pena?

Os usuários. Quem vai usar o sistema, com que frequência, em que ambiente (escritório, campo, celular, balcão) e com que nível de familiaridade com tecnologia. Inclua quem só consulta e quem aprova, não só quem opera.

Os fluxos principais. Descreva, mesmo que em tópicos, o caminho de ponta a ponta do processo mais importante: onde ele começa, quem faz cada etapa, que documento ou informação passa de mão em mão, onde trava.

Também ajuda muito escrever o que fica fora. Dizer "neste momento não queremos mexer no faturamento" evita que o escopo cresça por gravidade.

Por fim, reserve tempo das pessoas certas. O discovery depende de acesso a quem conhece o processo, e a agenda dessas pessoas costuma ser o maior gargalo.

Protótipo navegável antes do código

Uma das entregas mais valiosas do discovery é o protótipo navegável: telas clicáveis que simulam o fluxo principal, sem código de produção por trás.

Ele serve para algo que documento nenhum faz: colocar o futuro sistema na frente de quem vai usar e observar a reação. O usuário tenta concluir uma tarefa e esbarra num campo que não sabe preencher, procura uma informação que não está na tela, pergunta onde fica a aprovação do gerente. Cada tropeço é um requisito descoberto de graça.

Mudar um protótipo é rápido. Mudar um sistema construído, não. Por isso vale iterar no protótipo até que os usuários principais consigam completar os fluxos sem ajuda.

O protótipo também é a melhor ferramenta de alinhamento interno. Diretoria, operação e TI olhando para a mesma tela discutem com muito mais precisão do que lendo o mesmo documento.

Arquitetura, integrações e riscos mapeados

Enquanto o lado de negócio se desenha, o lado técnico também avança:

• Arquitetura proposta, em linguagem clara: quais componentes, onde roda, como os dados fluem, o que é web e o que é mobile, o que precisa funcionar sem internet.
• Mapa de integrações: com quais sistemas o novo sistema conversa, em que sentido, quem é dono de cada dado e como cada integração será feita, seja por API, arquivo ou outro mecanismo.
• Requisitos não funcionais: volume esperado, disponibilidade necessária, perfis de acesso, trilha de auditoria, obrigações de LGPD, necessidade de operação offline.
• Registro de riscos: o que pode dar errado, com que probabilidade e o que fazer a respeito. A API do ERP que ninguém testou, a migração de dados de um sistema antigo, a dependência de um fornecedor externo.

Quando o risco técnico é alto, o discovery pode incluir uma prova de conceito pequena: testar de verdade a integração mais incerta antes de apostar o projeto inteiro nela.

O plano de fases: por que prazo e investimento vêm depois

É aqui que muita gente estranha. Por que não dar prazo e investimento logo na primeira conversa?

Porque qualquer número dado antes do discovery é baseado em suposições, e as suposições são exatamente o que o discovery testa. O que determina o esforço de um sistema não é a quantidade de telas, é a combinação de escopo, regras de negócio, integrações, exceções e requisitos não funcionais, e boa parte disso só aparece quando se olha de perto. Os fatores que pesam estão detalhados em quanto custa desenvolver um software sob medida.

Ao final do discovery, o plano de fases diz:

• o que entra na primeira fase, geralmente um MVP com escopo bem definido;
• o que vem nas fases seguintes e em que ordem;
• os riscos principais de cada fase e como serão tratados;
• as dependências do seu lado, como acessos, decisões e pessoas;
• a base para estimar prazo e investimento com fundamento.

Às vezes o resultado do discovery é não construir. A conclusão pode ser que um sistema de mercado atende, que o problema é de processo e não de software, ou que vale começar por uma integração pequena. Esse resultado também tem valor, e muito. A comparação entre caminhos está em ERP sob medida ou ERP de mercado.

Os entregáveis são seus, mesmo se trocar de fornecedor

Um bom discovery produz material que continua útil independentemente de quem vai desenvolver:

• mapa do processo atual e do processo proposto;
• protótipo navegável;
• lista priorizada de funcionalidades e do que fica fora;
• arquitetura proposta e mapa de integrações;
• registro de riscos e premissas;
• plano de fases.

Esse material deve ser entregue à sua empresa, em formato que outra equipe consiga ler. Se o fornecedor que fez o discovery não for o mesmo que vai construir, você não perde o trabalho. Isso também é um bom teste na hora de escolher uma software house: pergunte o que exatamente você recebe ao final do diagnóstico e em que formato.

Quando o discovery pode ser mais enxuto

Nem todo projeto precisa de uma investigação extensa. O discovery pode ser mais curto quando:

• o problema é bem delimitado, como uma integração específica entre dois sistemas conhecidos;
• já existe documentação confiável do processo e dos sistemas envolvidos;
• a empresa está evoluindo um sistema que o mesmo fornecedor já conhece.

Ele merece mais profundidade quando o processo envolve várias áreas, quando há sistemas legados sem documentação, quando existe operação em campo ou quando o sistema vai tratar dados sensíveis.

Checklist antes de começar

• Consigo descrever o problema sem falar da solução?
• Sei quem são os usuários e em que ambiente trabalham?
• Tenho os fluxos principais esboçados, mesmo em tópicos?
• Sei o que fica fora deste projeto?
• Reservei tempo das pessoas que conhecem o processo?
• Sei quais entregáveis vou receber e em que formato?

Entender antes de construir

Na Pervian Tech, todo projeto começa por um diagnóstico. Entrevistamos quem opera, analisamos planilhas e sistemas, prototipamos os fluxos principais com os usuários e entregamos arquitetura, integrações, riscos e plano de fases por escrito. É o coração do nosso trabalho em arquitetura de software.

O diagnóstico inicial é gratuito, e é a partir dele que definimos um plano sob medida e o investimento sob consulta, com base no que foi encontrado e não em suposições. Se você tem um problema e ainda não sabe o tamanho da solução, comece a conversa por aqui.