APRENDER. PRATICAR. EVOLUIR.1. Escolher participantes pela informação necessária
Num projeto fictício, o sponsor pede uma nova aplicação porque o fecho de fundos termina tarde. Antes de preparar a entrevista, formula perguntas sobre o resultado, os pontos de espera e as decisões que o projeto deve permitir. Inclui quem executa o batch, quem trata exceções, quem recebe o resultado e quem aprova regras, identificando turnos e geografias diferentes. Um workshop cheio de gestores pode deixar de fora o único operador que conhece um workaround noturno. A lista de participantes deve ligar cada pessoa ao conhecimento ou à autoridade necessários. Confirma disponibilidade, material de preparação e como recolher informação de quem não pode estar presente. O objetivo não é entrevistar toda a organização, mas cobrir as perspetivas que podem alterar a compreensão da necessidade.
2. Perguntar por acontecimentos e exceções
Em vez de perguntar “concorda que automatizar resolve o atraso?”, pede o percurso de uma execução recente e de uma execução problemática. Identifica entradas, sequência, esperas, decisões manuais e critérios de conclusão. Usa exemplos sintéticos ou dados autorizados e minimizados. Se a pessoa disser “o ficheiro chega sempre às seis”, pede o fuso, a data de negócio, a regra em feriados e evidência das exceções. Não transformes a primeira resposta numa regra universal. Uma entrevista revela intenções e interpretações; observação e registos podem revelar diferenças entre processo descrito e processo executado. Combina técnicas conforme a dúvida, sem tratar logs como prova completa: podem faltar eventos, existir clocks diferentes ou haver trabalho fora do sistema.
3. Conservar versões do entendimento
Uma nota de entrevista pode conter três coisas diferentes: o que foi observado, a explicação proposta e uma decisão ainda por tomar. Regista-as separadamente com origem e âmbito. “O ficheiro foi recebido às 06:10 UTC” é uma observação; “o fornecedor causou o atraso” é uma hipótese que depende de outras etapas; “aceitar até às 06:15” é uma regra que precisa de autoridade. Devolve o entendimento aos participantes usando exemplos e perguntas explícitas. A confirmação de que as notas representam a conversa não equivale à aprovação de requisitos, ao financiamento de uma opção ou à aceitação de produção. Se houver correção posterior, preserva a versão anterior e o motivo da mudança para que consumidores saibam que conclusão foi alterada.
4. Trabalhar o conflito sem fabricar consenso
Negócio quer aceitar ficheiros até ao cut-off e operações precisa de tempo para validar antes de um envio externo. As afirmações podem referir eventos diferentes: chegada, validação ou transmissão. Modela a sequência e identifica a restrição de cada parte antes de escolher um horário. Quando a divergência é real, apresenta opções, consequências e quem tem autoridade para decidir. Uma votação por maioria não substitui uma regra de aprovação ou uma obrigação aplicável ao cenário. Também não basta escolher a opinião da pessoa mais sénior sem registar o risco e o âmbito. O analista pode facilitar e recomendar; deve distinguir essa contribuição da decisão que pertence ao owner autorizado. Regista discordância residual e ações necessárias para que o acordo seja executável.
5. Medir redução de incerteza
Após três workshops, a equipa tem muitas páginas mas continua sem uma regra para ficheiros repetidos. O número de sessões não demonstra que a análise está pronta. Mantém uma lista de perguntas abertas com impacto, evidência necessária, owner e próxima decisão. Usa exemplos de aceitação para verificar se desenvolvimento, operações e negócio interpretam a regra da mesma forma. Uma demonstração guiada pode resolver uma ambiguidade que outra apresentação não resolve. Reavalia a abordagem quando participantes relevantes faltam, hipóteses deixam de ser válidas ou a informação não permite decidir. No reporte ao gestor técnico, mostra o que ficou confirmado, o que permanece hipotético e quais lacunas bloqueiam a mudança. A equipa pode então escolher investigação adicional, limitar âmbito ou adiar uma decisão com conhecimento do impacto.
Negócio diz “aceite até às 17:00”; APS diz “validado até às 16:55”. Primeiro identifica os eventos e as dependências, antes de tratar os horários como simples opiniões concorrentes.
Armadilhas comuns
Confundir presença com cobertura, pergunta orientada com descoberta, confirmação de notas com aprovação e número de workshops com prontidão.
Tópicos relacionados: Decisões, versões e dependências · Modelar, verificar e validar requisitos · Medir o resultado e interpretar evidência
Torna visível o caminho entre informação recolhida, entendimento confirmado e decisão autorizada.
Referência: The Business Analysis Standard · CBAP six-knowledge-area blueprint, May 2026 handbook