Guia BA
Guia de Descoberta de Novo Projeto
Você entrou num projeto novo. O que você deveria perguntar primeiro?
Surya · 13 de agosto de 2026 · 13 min de leitura · 6 práticas
Para Business Analysts nas primeiras semanas de um projeto novo, BAs que têm documentos e acesso, mas ainda não conseguem explicar por que o projeto existe, Líderes de entrega recebendo um novo membro de time num projeto em andamento e Qualquer um que já ouviu "você já está confortável com o projeto?" cedo demais.
É sua primeira semana num projeto novo.
Você tem acesso ao Jira, um documento de requisitos de 74 páginas e uma agenda cheia de reuniões cujos títulos contêm palavras que você ainda não entende.
Depois seu gestor pergunta:
“Você já está confortável com o projeto?”
Você conheceu doze pessoas, abriu seis sistemas e coletou dezessete documentos.
Mas ainda não consegue explicar com confiança por que o projeto existe.
Isso é normal. O problema raramente é falta de informação — é que a informação chega em pedaços, e ninguém te conta como eles se conectam.
Primeiro, não tente entender tudo
“Entender o projeto” é grande demais para ser útil. Comece com um alvo menor. Ao final da descoberta, você deveria conseguir explicar:
O mapa de descoberta
O projeto novoIsso já basta para começar a contribuir sem fingir que você sabe tudo.
Descoberta não é sobre virar o especialista em dez dias. É sobre construir o mapa que te ajuda a fazer perguntas melhores no dia onze.
Conheça nosso projeto
Vamos usar uma empresa de seguros indiana fictícia chamada AaravCare.
Hoje, clientes enviam sinistros de seguro saúde por e-mail. Times de Operações baixam os documentos, digitam os detalhes num sistema de sinistros e contatam os clientes quando algo está faltando.
O briefing do projeto diz:
“Construir uma jornada digital de sinistros para reduzir o tempo de processamento.”
Parece claro. Não é.
“Jornada digital de sinistros” significa um formulário para enviar documentos—ou validação de apólice, checagens de fraude, rastreamento de status, aprovação automática e integração hospitalar também? E “reduzir o tempo de processamento” significa envio, revisão, aprovação ou pagamento mais rápidos?
Uma descrição de projeto te diz o que as pessoas querem construir. Ela pode não te dizer qual problema elas estão tentando resolver.
Comece entendendo por que o projeto existe
Antes de estudar telas, stories ou APIs, entenda o motivo pelo qual dinheiro e pessoas foram alocados nesse trabalho. Pergunte que problema estamos tentando resolver, quem sente esse problema, que evidência nos diz que vale a pena resolver, por que agora, o que acontece se não fizermos nada e como vamos saber que o projeto funcionou.
Na AaravCare, pessoas diferentes dão respostas diferentes:
Atendimento ao Cliente
“Os clientes continuam ligando porque não sabem o status do sinistro.”
Operação
“A gente gasta tempo demais checando envios incompletos.”
Financeiro
“O processamento manual torna a previsão de pagamento pouco confiável.”
Compliance
“A gente precisa de um registro melhor do que foi enviado, mudado e aprovado.”
O projeto tem vários problemas relacionados usando o mesmo nome de projeto. Seu trabalho é tornar esses problemas visíveis antes que o time trate uma funcionalidade como a resposta para todos eles.
Escreva um propósito de projeto de uma frase:
A fórmula
Estamos melhorando [processo] para [usuários] porque [problema atual], para que [resultado mensurável].
AaravCare
Estamos melhorando o envio e a validação inicial de sinistros para segurados e a Operação de Sinistros porque envios incompletos por e-mail criam atrasos evitáveis, para que mais sinistros cheguem prontos para avaliação, e os clientes consigam ver o que acontece a seguir.
Essa frase pode mudar conforme você aprende mais.
Ótimo. A descoberta deveria mudar seu entendimento.
Encontre as pessoas por trás do organograma
Uma lista de stakeholders te dá nomes e papéis. Ela não te diz como o projeto realmente toma decisões. Para cada área importante, identifique quem sente o problema, quem faz o trabalho hoje, quem é dono do resultado de negócio, quem toma decisões de política ou controle, quem é dono dos sistemas afetados, quem pode bloquear a mudança, quem vai dar suporte depois do release e quem está faltando na conversa.
Na AaravCare, o patrocinador do projeto é o Head de Transformação de Sinistros. Mas as regras para aceitar um sinistro pertencem à Operação de Sinistros. A Fraude decide quais envios precisam de checagens adicionais. O Financeiro é dono dos controles de pagamento. A Tecnologia é dona da plataforma de sinistros. O Atendimento ao Cliente lida com as ligações quando a jornada não está clara.
Um patrocinador não significa um único tomador de decisão.
Crie um mapa de decisão simples:
| Decisão | Pessoa ou papel responsável |
|---|---|
| O que torna um sinistro completo? | Operação de Sinistros |
| Quais sinistros exigem revisão de fraude? | Risco de Fraude |
| O que os clientes conseguem ver? | Produto + Compliance |
| Quando o pagamento pode ser liberado? | Sinistros + Financeiro |
| Como a solução será implementada? | Tecnologia |
Se a resposta é só “o negócio,” continue perguntando.
Siga o trabalho como ele acontece hoje
Documentos descrevem o processo oficial. As pessoas te mostram o real. Peça para alguém que faz o trabalho te guiar por um exemplo recente do início ao fim—não uma apresentação ou um processo ideal. Um caso real.
O sinistro da AaravCare, hoje
Depois pergunte:
- Onde o trabalho espera?
- O que é copiado manualmente?
- O que é checado duas vezes?
- Qual passo depende do conhecimento de uma pessoa só?
- Onde as pessoas saem do sistema oficial e usam e-mail ou planilhas?
- O que acontece quando informação está faltando?
- Como o cliente é informado?
Aquela planilha que alguém chama de “temporária” pode estar carregando metade do processo. Não a ignore só porque ela está faltando no diagrama de arquitetura.
Separe o estado atual do futuro prometido
Projetos novos costumam misturar três coisas diferentes: o que acontece hoje, o que alguém propôs e o que realmente foi aprovado. Mantenha-as separadas.
| Afirmação | O que ela realmente é |
|---|---|
| Clientes atualmente enviam documentos por e-mail | Estado atual |
| Clientes deveriam enviar documentos por um portal | Mudança proposta |
| O portal deve suportar arquivos PDF e JPEG até o limite de tamanho aprovado | Requisito — uma vez confirmado |
| A IA vai checar todo documento médico automaticamente | Ideia ou suposição |
Um slide impressionante não é uma decisão. Um protótipo não é necessariamente comportamento aprovado. Uma linha num documento antigo pode não ser mais verdade.
Para toda afirmação importante, pergunte:
Isso é comportamento atual, um requisito aprovado, uma proposta ou uma suposição?
Você vai evitar uma quantidade surpreendente de confusão com essa única pergunta.
Desenhe a jornada de sistemas e dado
Você não precisa de um diagrama de arquitetura perfeito no primeiro dia. Comece com uma jornada simples: quem cria a informação, onde ela entra, quais sistemas a usam, o que sai.
AaravCare — jornada de sistemas e dado
Agora pergunte sobre as conexões:
- Qual sistema é dono de cada campo importante?
- Quais integrações são em tempo real e quais são atrasadas?
- Qual identificador liga o mesmo sinistro através dos sistemas?
- O que acontece se um sistema não responde?
- Mensagens podem chegar duas vezes ou fora de ordem?
- Onde erros de validação são armazenados?
- Quem reconcilia divergências?
- Quais relatórios consomem o dado depois?
A tela é só onde o usuário encontra o processo. O requisito costuma viver no que acontece antes e depois dela.
Encontre as decisões já tomadas — e as que fingem ter sido tomadas
Novos membros do time costumam reabrir questões já resolvidas porque não conseguem encontrar a decisão original. Eles também herdam suposições que todo mundo trata como resolvidas porque ninguém lembra de tê-las questionado.
Crie um registro de decisões com cinco campos:
| Decisão | Status | Responsável | Motivo |
|---|---|---|---|
| Sinistros podem ser salvos como rascunho | Aprovada | Product Owner | Clientes podem não ter todo documento disponível |
| A IA vai classificar documentos | Proposta | Sem responsável | Esperava-se que reduzisse a triagem manual — nenhuma aprovação encontrada |
Status úteis são Proposta, Aprovada, Rejeitada, Substituída e Precisa confirmação.
Se ninguém consegue identificar quem aprovou algo, registre essa incerteza. Não a converta silenciosamente num fato.
Torne a fronteira de entrega visível
Um projeto pode ter uma visão clara e ainda assim ter um release pouco claro. Pergunte:
- O que está incluído no próximo release?
- O que está explicitamente fora de escopo?
- O que já está comprometido?
- Quais datas são fixas — e por quê?
- O que depende de outro time, fornecedor ou aprovação?
- O que precisa ser verdade antes do desenvolvimento começar?
- O que impediria a UAT ou o release em produção?
- Que trabalho continua manual depois do lançamento?
Na AaravCare, “sinistros digitais” é a visão. O primeiro release pode incluir só:
- Envio de sinistro
- Upload de documento
- Validação básica de apólice
- Confirmação e rastreamento de status
Automação de fraude e aprovação automática podem vir depois.
Isso não é uma falha de ambição. É uma fronteira de entrega usável.
O plano de descoberta dos primeiros 30 dias
Você não precisa completar a descoberta antes de contribuir. Use três passadas.
Entenda por que o projeto existe e aprenda sua linguagem.
- Leia o briefing do projeto, decisões recentes e o backlog atual
- Conheça o patrocinador, o Product Owner, o SME operacional, o líder de tecnologia e o líder de QA
- Escreva sua primeira versão da declaração de propósito do projeto
- Comece um glossário
- Capture contradições e perguntas em aberto
Resultado
Declaração de propósito, mapa de stakeholders e glossário.
Siga uma jornada real através de pessoas, sistemas e dado.
- Observe o processo atual
- Percorra um caso normal e um caso com falha
- Desenhe a jornada de processo e sistema
- Identifique donos de dado, integrações e workarounds manuais
- Separe decisões aprovadas de propostas e suposições
Resultado
Fluxo do estado atual, mapa de sistema/dado e registro de decisões.
Devolva seu entendimento para o time.
- Confirme o resultado alvo e as medidas de sucesso
- Valide o escopo e as fronteiras de release
- Exponha dependências e riscos de entrega
- Priorize perguntas sem resposta
- Cheque se o QA, a Operação e o Suporte veem algo faltando
- Combine o que você vai investigar a seguir
Resultado
Canvas de descoberta validado, lista de riscos e plano de próximas ações.
Trinta dias não é um prazo para saber tudo. É tempo suficiente para parar de depender de qualquer que seja a última pessoa que falou com você.
Um exemplo global: as mesmas perguntas, projeto diferente
Imagine entrar numa empresa global de SaaS que quer “automatizar o onboarding de funcionários.” O mesmo mapa funciona:
| Área | O que a descoberta revela |
|---|---|
| Por quê | Novos contratados esperam demais por contas e equipamentos |
| Pessoas | RH, gestores, TI, Segurança, Folha de Pagamento, Facilities e novos funcionários |
| Processo | Oferta aceita → funcionário criado → checagens concluídas → acesso e equipamento fornecidos |
| Sistemas | Plataforma de RH, provedor de identidade, folha de pagamento, service desk e gestão de dispositivos |
| Dado | Nome legal, localização, data de entrada, tipo de emprego, gestor e perfil de acesso |
| Decisões | Quem aprova acesso privilegiado? O que acontece quando uma data de entrada muda? |
| Fronteira | O primeiro release cria contas, encomenda equipamento ou os dois? |
País diferente, indústria diferente, mesmo problema: o nome do projeto é menor que o sistema de trabalho por trás dele.
Perguntas que BAs experientes fazem cedo
Uma vez que você entende a jornada básica, faça as perguntas menos confortáveis:
- Quais medidas de sucesso poderiam melhorar enquanto a experiência do cliente piora?
- Qual stakeholder se beneficia dessa mudança — e quem ganha mais trabalho?
- Que atividade manual a solução está silenciosamente dependendo?
- Qual regra existe por causa de regulação e qual existe porque "sempre fizemos assim"?
- O que acontece com os casos já em andamento quando a mudança entra no ar?
- Quem trata exceções depois do lançamento?
- Qual time downstream fica sabendo da mudança por último?
- O que precisa ser monitorado no primeiro dia?
- Qual é o rollback ou fallback se a jornada nova falhar?
- Qual suposição seria mais cara se estivesse errada?
Você não vai precisar de toda pergunta em todo projeto. Escolha as que podem mudar escopo, design, teste ou responsabilidade.
Cinco erros de descoberta para evitar
Ler tudo antes de falar com alguém
Documentos te dão histórico. Pessoas te dão contexto. Use os dois.
Reunir só com stakeholders sêniores
Líderes explicam o processo pretendido. As pessoas que fazem o trabalho te mostram onde ele se dobra.
Tratar acesso como entendimento
Ter acesso a Jira, Confluence e sistemas não significa que você entende como um caso se move através deles. Rastreie um exemplo real.
Esconder o que você não sabe
Perguntas visíveis tornam a descoberta mais segura. Suposições silenciosas fazem ela parecer terminada antes de estar.
Transformar a descoberta em análise permanente
Você nunca vai remover todo desconhecido. Exponha os que poderiam mudar a próxima decisão.
Antes de Dizer, “Eu Entendo o Projeto”
Cheque se você consegue responder:
A checagem de entendimento
- Por que esse projeto existe?
- Quem sente o problema?
- Como o processo funciona hoje?
- O que se espera que mude?
- Quais sistemas e dado estão envolvidos?
- Quem é dono das decisões importantes?
- O que está incluído no próximo release?
- Quais suposições ainda não foram verificadas?
- Onde a mudança poderia falhar?
- O que você deveria investigar a seguir?
Se você não consegue responder uma dessas, você não falhou na descoberta.
Você encontrou para onde a descoberta precisa ir a seguir.
Você não entende um projeto quando coletou todos os seus documentos.
Você entende quando consegue explicar como as peças dele se conectam.
Problema, pessoas, processo, sistemas, dado e decisões — trinta dias não é um prazo para saber tudo. É tempo suficiente para parar de depender de qualquer que seja a última pessoa que falou com você.
Leve isso com você
Canvas de Descoberta de Novo Projeto
CANVAS DE DESCOBERTA DE NOVO PROJETO 1. PROPÓSITO DO PROJETO Estamos melhorando: Para: Porque: Para que: Por que agora? O que acontece se não fizermos nada? Como o sucesso será medido? 2. PESSOAS E DECISÕES Patrocinador: Responsável pelo resultado de negócio: Product owner: SMEs operacionais: Donos de tecnologia: Responsáveis por QA / UAT: Risco / Compliance / Segurança: Responsável pelo suporte depois do release: Quem toma a decisão final quando as pessoas discordam? 3. PROCESSO ATUAL Gatilho: Passos principais: Pessoas envolvidas: Workarounds manuais: Pontos de espera: Falhas comuns: 4. MUDANÇA ALVO O que deveria mudar? O que deveria permanecer inalterado? Resultado esperado para o usuário: Resultado esperado para o negócio: 5. SISTEMAS E DADO Sistemas envolvidos: Sistema de referência: Dado importante: Donos do dado: Integrações: Relatórios / consumidores downstream: Comportamento de falha e recuperação: 6. ESCOPO E ENTREGA Dentro do escopo: Fora do escopo: Fronteira do release: Datas fixas e motivos: Dependências: Condições de prontidão: Fallback / rollback: 7. DECISÕES E SUPOSIÇÕES Decisões confirmadas: Propostas aguardando aprovação: Suposições: Informação conflitante: 8. RISCOS E PERGUNTAS EM ABERTO Risco ou pergunta: Por que isso importa: Responsável: Próxima ação: Prazo: 9. PRIORIDADES DOS PRIMEIROS 30 DIAS O que eu preciso entender primeiro? Qual jornada eu vou rastrear? Quais decisões precisam de confirmação? Quais riscos precisam de atenção antecipada? O que eu vou devolver para o time?
Receba novos guias em primeira mão.