Todo Mundo Quer uma Coisa Diferente. Qual É o Requisito de Verdade?

Você está numa reunião de requisitos.

O Comercial diz:

“A gente precisa de mais flexibilidade.”

A Operação diz:

“A gente precisa de controles mais rígidos.”

O Compliance diz:

“A gente precisa de menos exceções.”

A Tecnologia finalmente pergunta:

“Alguém pode simplesmente dizer o que a gente vai construir?”

Todo mundo olha para o BA.

Essa não é necessariamente uma reunião ruim.

Pode simplesmente significar que cada stakeholder está protegendo uma coisa diferente.

Seu trabalho não é encontrar a frase que todo mundo desgosta igualmente.

Seu trabalho é descobrir:

Que resultado estamos tentando alcançar, quais restrições são reais e quais trocas estamos dispostos a fazer?

Aqui está a situação

Imagine uma empresa de e-commerce mudando seu processo de reembolso.

O Comercial quer que os agentes aprovem reembolsos rapidamente.

A Operação quer controles porque erros de reembolso saem caro.

O Risco quer que reembolsos grandes sejam revisados.

A Tecnologia quer um fluxo único e claro.

Então qual é o requisito?

“Deixar os reembolsos flexíveis”? “Exigir aprovação”? “Reduzir exceções”?

Nenhuma dessas frases basta.

São posições de stakeholders.

O requisito de verdade está por baixo delas.

1. ESCUTE — o que cada stakeholder está realmente protegendo?

Comece entendendo cada perspectiva.

Pergunte ao Comercial: “Que problema mais flexibilidade resolveria?” Talvez clientes esperem dois dias por reembolsos simples.

Pergunte à Operação: “De que risco os controles estão nos protegendo?” Talvez os agentes às vezes reembolsem o valor errado.

Pergunte ao Risco: “Quais reembolsos realmente precisam de revisão adicional?” Talvez só os reembolsos acima de um certo valor.

Agora a discordância fica mais precisa.

O Comercial talvez não queira ficar totalmente sem controles. A Operação talvez não queira aprovação em tudo.

Essas eram posições. As necessidades por baixo delas podem ser compatíveis.

2. SEPARE — necessidade ou solução proposta?

Stakeholders costumam descrever soluções como requisitos.

“Adiciona uma tela de aprovação.”

“Dá um botão de override para os gestores.”

“Deixa tudo automático.”

Antes de aceitar a solução, pergunte:

“Que problema isso resolveria?”

Talvez “tela de aprovação” signifique de verdade: reembolsos de alto valor precisam de revisão independente.

Talvez “botão de override” signifique: casos urgentes precisam de um caminho de exceção.

Talvez “automatizar tudo” signifique: reembolsos de baixo risco não deveriam esperar por revisão manual.

Agora você consegue desenhar em torno da necessidade, não da primeira solução que alguém sugeriu.

3. CONFLITO — onde as necessidades realmente colidem?

Escreva as necessidades claramente.

Comercial: reduzir o tempo de espera do cliente.
Operação: reduzir erros de reembolso.
Risco: controlar a exposição de alto valor.
Tecnologia: manter o fluxo sustentável.

Depois pergunte:

“Onde essas necessidades realmente entram em conflito?”

Talvez todo mundo concorde que reembolsos abaixo de um limite baixo deveriam ser rápidos.

A discordância só existe acima desse limite.

Uma discussão de quatro lados acabou de virar uma decisão só.

Isso é trabalho de BA.

4. RESTRIÇÕES — o que não pode ser negociado?

Algumas preferências são flexíveis. Algumas restrições não são.

Procure por:

• regulação
• política interna
• compromissos contratuais
• segurança
• orçamento
• arquitetura
• disponibilidade de dados
• datas de entrega
• capacidade operacional

Suponha que o Risco diga que reembolsos grandes exigem aprovação independente por causa de uma política da empresa.

Isso é diferente de:

“A gente prefere que os gestores aprovem.”

Deixe as restrições explícitas. Senão os times discutem opções que nunca foram viáveis.

5. PRIORIZE — o que importa mais?

Quando tudo é “crítico”, nada é.

Pergunte:

O que é indispensável? O que cria mais valor de negócio? O que evita o maior risco? O que pode esperar? O que acontece se a gente não fizer isso?

Ordene os resultados em vez da hierarquia dos stakeholders. Por exemplo:

1. Impedir reembolsos de alto valor não autorizados.
2. Reduzir a espera do cliente para reembolsos de baixo risco.
3. Reduzir trabalho manual.
4. Melhorar os relatórios.

Agora as decisões de design têm algo para se ancorar.

6. TROCAS — mostre o que cada opção ganha e custa

Não pergunte:

“Qual opção você prefere?”

Mostre as consequências.

Agora o time não está discutindo opiniões.

Está escolhendo uma troca.

7. DECIDA — não persiga o consenso perfeito

Uma armadilha comum do BA é tentar deixar todo mundo completamente feliz.

Às vezes isso não é possível.

O objetivo não é:

Todo mundo ganha tudo.

O objetivo é:

A decisão certa é tomada com as trocas entendidas.

Se os stakeholders não conseguem concordar, identifique o responsável pela decisão. Apresente:

problema → opções → restrições → impacto → recomendação

Depois consiga uma decisão.

Consenso é útil.

Decisão é essencial.

8. DOCUMENTE — transforme a decisão em comportamento construível

Suponha que o time escolha aprovação baseada em risco. Agora deixe isso preciso.

Reembolsos abaixo do limite baixo podem ser processados por um agente de atendimento autorizado sem aprovação adicional.

Reembolsos na faixa do meio exigem confirmação do agente e registro do motivo.

Reembolsos acima do limite alto exigem aprovação do gestor antes de processar.

Depois defina:

• papéis de usuário
• limites
• exceções
• comportamento de erro
• requisitos de auditoria
• notificações
• relatórios
• critérios de aceitação

E não mande:

“Por favor revise os requisitos.”

Mande:

“Concordamos em aprovação baseada em risco. Por favor confirme esses limites, papéis e regras de exceção.”

Confirmação específica gera feedback melhor.

E se o stakeholder mais sênior discordar?

Hierarquia pode determinar quem decide. Isso não remove a necessidade de mostrar as consequências.

Se quem decide escolhe aprovação para todo reembolso, documente o impacto:

Aprovação em todo reembolso aumenta o controle, mas deve aumentar o tempo de atendimento e a carga de trabalho operacional.

Seu trabalho não é sobrepor a decisão de quem decide.

É garantir que essa pessoa consiga ver o que está escolhendo.

E se todo mundo estiver certo?

Frequentemente estão.

O Comercial está certo sobre a experiência do cliente. A Operação está certa sobre controle. O Risco está certo sobre exposição. A Tecnologia está certa sobre complexidade.

A resposta pode não ser escolher um vencedor.

Pode ser:

limites · fluxos diferentes · permissões · exceções · entrega faseada · regras configuráveis

Necessidades conflitantes às vezes precisam de um design melhor, não de compromisso.

Armadilhas comuns

Escolher um lado

“O Negócio quer isso, então a Tecnologia precisa construir.”

Você vira um mensageiro, não um analista.

Pular direto para soluções

“Vamos adicionar um botão de aprovação.”

Você pode resolver o problema errado.

Concordar com tudo

Todo pedido de stakeholder vira escopo. O produto fica caro e contraditório.

Ignorar suposições

Todo mundo acha que concordou porque ninguém disse em voz alta o que estava presumindo.

Perseguir consenso para sempre

As reuniões continuam porque ninguém identifica quem é responsável pela decisão.

Esquecer a troca

Três meses depois:

“Por que escolhemos isso?”

Ninguém lembra.

Antes de encerrar a reunião

Se você tem dez sins, a Tecnologia não deveria mais precisar perguntar: “Então… o que exatamente a gente vai construir?”

O que fica

A discordância entre stakeholders costuma ser onde o requisito de verdade está escondido.

Quando o Comercial pede flexibilidade, a Operação pede controle e o Risco pede menos exceções, não vá direto pro meio-termo.

Pergunte o que cada pessoa está tentando proteger. Exponha o conflito real. Deixe as restrições visíveis.

Mostre as trocas. Consiga a decisão.

O trabalho do BA não é encontrar o meio-termo. É encontrar o requisito que melhor serve o resultado dentro das restrições reais.

Um bom BA não faz todo mundo concordar.

Um bom BA garante que todo mundo entenda o que foi decidido — e por quê.