💭 Já recebeu uma demanda que soava mais como um enigma do que um projeto?
Algo do tipo: “precisamos de um sistema que faça isso aqui… sabe?”
Essa é a clássica situação do “faça uma casa”, quando o cliente sabe que precisa de um teto, mas não consegue descrever quantos cômodos, janelas ou portas.
E é exatamente aí que mora o perigo: os requisitos invisíveis.
Eles são os maiores responsáveis por retrabalho, escopo indefinido e produtos que não resolvem o problema real.
Mas aqui vai o ponto central: stakeholders não precisam ter todas as respostas.
Quem precisa fazer as perguntas certas somos nós.
Neste artigo, compartilho 5 técnicas práticas que transformam o caos das ideias vagas em um blueprint claro e acionável.
1. 🗣️ Vá Além do “Sim” ou “Não”: Priorize Perguntas Abertas
Perguntas fechadas são aquelas que podem ser respondidas com “sim”, “não” ou uma opção de múltipla escolha.
Elas são excelentes para validar informações já conhecidas.
No entanto, para a fase de descoberta, o verdadeiro valor está nas perguntas abertas, que incentivam respostas detalhadas e subjetivas.
Isso permite que os stakeholders explorem o problema em seus próprios termos.
Em um estudo de caso sobre o projeto SAPPE, um simulador de provas do ENADE, a equipe de desenvolvimento partiu de um documento de visão que continha apenas três requisitos funcionais.
Ao aplicar técnicas como entrevistas e questionários com perguntas abertas, eles conseguiram identificar seis novos requisitos funcionais, mais que dobrando o escopo conhecido do sistema.
Por que isso funciona?
O estudo conclui que:
“A utilização de perguntas abertas facilita a identificação de requisitos que não poderiam ser descobertos com perguntas fechadas.” — estudo SAPPE
Em contraste, no projeto NaData, do mesmo estudo, o uso exclusivo de questionários fechados não se mostrou eficaz para coletar requisitos.
Perguntas abertas dão aos stakeholders a liberdade para articular o problema, revelando nuances e necessidades que os analistas talvez não tivessem previsto.
Essencialmente, perguntas abertas transferem o poder da “solução” para a “exploração do problema”, permitindo que você descubra o valor real em vez de apenas validar suposições.
2. ✏️ Pergunte com Protótipos: Transforme o Abstrato em Concreto
A prototipagem é uma técnica que permite “fazer perguntas” através de um modelo funcional, em vez de palavras.
Como define Danielle Teixeira, um protótipo é “a forma mais rápida e econômica de se definir e até mesmo validar um produto”.
Ele transforma conceitos abstratos em algo tangível com o qual os stakeholders podem interagir.
Imagine uma equipe desenvolvendo a tela de login de um aplicativo.
Em vez de perguntar “Como você quer que a tela de login funcione?”, a equipe cria um protótipo de baixa fidelidade.
Simplesmente “rabiscando” as primeiras necessidades em uma folha de papel.
Ao interagir com o rascunho, o cliente imediatamente percebe que precisa de uma opção de “Esqueci minha senha” e de login social (Google/Facebook), requisitos que não haviam sido mencionados na conversa inicial.
A partir desse feedback, a equipe pode evoluir para wireframes (média fidelidade) e mockups (alta fidelidade) para refinar os detalhes.
Como destaca o padrão IEEE Std 830, os clientes reagem de forma mais imediata e precisa a um protótipo visual do que a um documento escrito denso.
Isso é especialmente eficaz para superar a dificuldade de stakeholders que “não sabem exatamente o que querem”.
Isso transforma a validação de requisitos de um exercício intelectual para uma experiência tátil, desarmando a abstração que muitas vezes esconde desalinhamentos críticos.
Um protótipo falho é um sucesso, pois representa um fracasso barato e precoce, que evita um fracasso caro e tardio no desenvolvimento.
3. 👀 Observe o Trabalho Real: Use a Etnografia para Descobrir Requisitos Ocultos
A Etnografia é uma técnica de observação na qual o analista se insere no ambiente de trabalho do cliente.
O objetivo não é perguntar como o trabalho é feito, mas sim observar “como as pessoas realmente trabalham” no seu dia a dia.
Essa imersão revela processos e necessidades que muitas vezes não são verbalizados.
Exemplo Prático: Uma equipe está criando um software para gerenciar o atendimento em um hospital.
Em entrevistas, os enfermeiros descrevem um processo de registro de pacientes que parece perfeitamente linear e organizado.
No entanto, ao observar o trabalho real, o analista percebe que os enfermeiros são constantemente interrompidos para atender emergências.
Eles colaboram de maneira informal, anotando informações temporárias em post-its colados nos monitores.
Essa observação revela um requisito crucial que jamais seria mencionado:
O sistema precisa permitir salvar rascunhos de registros e ter um mecanismo de notificação para colaboração rápida entre a equipe.
A Etnografia é poderosa para descobrir requisitos sociais e organizacionais que os stakeholders omitem, seja por acharem óbvios ou por não perceberem sua relevância para o sistema.
A Etnografia não apenas refina requisitos, ela descobre oportunidades de inovação.
Ao entender o fluxo de trabalho real, com suas interrupções e soluções improvisadas (como os post-its), você pode projetar uma solução que não apenas digitaliza um processo, mas o otimiza de uma forma que os próprios stakeholders não haviam imaginado.
4. 🎬 Construa Histórias com Cenários: Pergunte “E se…”
A técnica de Cenários estrutura a coleta de requisitos em torno de histórias de uso.
Um cenário geralmente inclui um nome, ator, pré-condições, um fluxo normal e, o mais importante, fluxos alternativos.
É na exploração dos “fluxos alternativos” que a equipe consegue descobrir os requisitos para tratamento de exceções e situações anormais.
Por Exemplo, para um sistema de caixa eletrônico (ATM), a equipe cria o cenário “Sacar dinheiro”.
O fluxo normal é simples: o cliente insere o valor, confirma e o dinheiro é liberado.
A verdadeira descoberta acontece quando a equipe começa a perguntar “E se…?”:
- “E se o saldo for insuficiente?”
- “E se o caixa não tiver notas de R$10 para compor o valor?”
- “E se a conexão com o banco cair após o débito na conta, mas antes da entrega do dinheiro?”
Cada uma dessas perguntas, estruturadas pelo cenário, gera requisitos detalhados para tratamento de erros, comunicação com o usuário e transações de recuperação, que poderiam ser facilmente esquecidos.
Cenários transformam a coleta de requisitos em uma atividade de storytelling colaborativo.
Isso força stakeholders e desenvolvedores a pensarem além do “caminho feliz” e a especificarem como o sistema deve se comportar quando as coisas dão errado.
Construir cenários é construir a resiliência do produto.
A confiança do usuário não é conquistada no fluxo ideal, mas na forma como o sistema lida com a imperfeição.
A exploração dos “E se…?” é o que transforma um produto funcional em um produto confiável.
5. 🔍 Mapeie os Pontos de Vista: Entenda Quem Responde a Qual Pergunta
Diferentes stakeholders têm perspectivas, necessidades e, às vezes, requisitos conflitantes sobre o mesmo sistema.
A análise de “Pontos de Vista” (Viewpoints) é uma técnica para organizar essa complexidade, em vez de tentar criar uma solução única que agrade a todos.
“diferentes stakeholders possuem diferentes requisitos que expressam de maneira diferente” – Sommerville, Ian
Imagine que no desenvolvimento de um sistema bancário, a equipe precisa definir os requisitos para a funcionalidade de “consultar saldo”.
Em vez de fazer uma pergunta genérica, eles identificam os principais pontos de vista:
- Titular da conta: Precisa ver o saldo detalhado com todas as transações.
- Caixa do banco: Talvez só precise saber se o saldo é suficiente para um saque, sem visualizar o valor exato, por questões de privacidade e segurança.
- Gerente de contas: Pode precisar ver um histórico de saldos ao longo do tempo para fazer uma análise de crédito.
Cada ponto de vista gera um requisito funcional distinto e evita o conflito que surgiria ao tentar criar uma única tela de “consulta de saldo” para todos.
Essa técnica estrutura a elicitação, garantindo que as perguntas certas sejam feitas às pessoas certas.
Ao invés de buscar um consenso forçado, a equipe identifica e organiza as necessidades específicas de cada grupo.
Esta técnica transforma conflitos de requisitos de um obstáculo em uma ferramenta de design.
Em vez de buscar um “meio-termo” medíocre, a análise de pontos de vista permite entregar valor focado e preciso para cada grupo de stakeholders, reconhecendo que uma solução “tamanho único” raramente serve a todos com excelência.
🎨 A Arte de Fazer a Pergunta Certa é Usar a Ferramenta Certa
Fazer perguntas melhores não se resume a encontrar uma única “pergunta mágica”.
Trata-se de ter um arsenal de técnicas:
- perguntas abertas para explorar
- protótipos para tangibilizar
- observação para descobrir o oculto
- cenários para testar os limites
- análise de pontos de vista para organizar a complexidade
Cada uma dessas abordagens é uma ferramenta para guiar a conversa da ambiguidade à clareza.
Um processo de requisitos bem executado é a fundação de qualquer projeto de sucesso.
É a sua melhor ferramenta para evitar o retrabalho, o escopo indefinido e a insatisfação do cliente que tanto assombram nossa indústria.
Ao dominar essas técnicas, você não está apenas coletando requisitos; você está construindo um entendimento compartilhado que é o verdadeiro blueprint para o sucesso.
