Muitos projetos começam mal porque ninguém faz estas perguntas iniciais

Há um momento em que um projeto parece avançar - reuniões marcadas, tarefas abertas, prazos no calendário - mas, por baixo, já começou torto. O problema raramente é falta de esforço; é falta de planeamento de projeto com uma análise de requisitos feita a sério, no início, quando ainda é barato mudar de ideias. É aí que se decide se a equipa vai construir algo útil ou apenas “entregar coisas”.

Muitos projetos começam mal porque ninguém quer ser a pessoa que abranda o entusiasmo com perguntas difíceis. Só que as perguntas iniciais não são burocracia: são a forma mais rápida de evitar retrabalho, conflitos e entregas que ninguém usa.

O padrão que se repete: correr antes de saber para onde

No arranque, toda a gente concorda com frases vagas: “tem de ser simples”, “tem de ser rápido”, “o cliente vai adorar”. Depois, cada pessoa imagina um “simples” diferente, e o projeto passa a ser uma negociação contínua, sprint após sprint. O planeamento vira remendos: ajusta-se o scope, empurra-se a data, pede-se “só mais um bocadinho”.

A análise de requisitos existe precisamente para travar este efeito dominó. Não para escrever documentos intermináveis, mas para alinhar expectativas, decisões e critérios de aceitação quando ainda há margem para escolher.

Um projeto não falha no final. Normalmente, falha em silêncio nas primeiras duas semanas.

As perguntas que quase ninguém faz (e que mudam tudo)

Abaixo estão perguntas simples, mas com “dentes”. Se as fizerem cedo, o projeto fica mais pequeno, mais claro e mais fácil de entregar.

1) Qual é a decisão que isto vai permitir tomar?

Se a resposta for “melhorar a experiência” ou “ter mais visibilidade”, parem e peçam um exemplo real. Que decisão muda amanhã se isto existir? Quem a toma? Com que frequência?

Uma funcionalidade que não muda decisões costuma virar ruído: dashboards ignorados, formulários a mais, notificações que toda a gente desliga.

2) Quem é o utilizador principal - e quem só “opina”?

Num projeto típico aparecem cinco “donos”: negócio, marketing, operações, compliance, direção. Mas o utilizador que vive com a solução todos os dias quase sempre é esquecido.

Façam a pergunta com nomes e contextos: “Isto é para a Maria do backoffice fechar pedidos 30% mais rápido, ou para o diretor ver números numa reunião?” As duas coisas podem coexistir, mas não com o mesmo ecrã, o mesmo fluxo e a mesma prioridade.

3) O que fica fora da primeira versão?

Se não houver lista de exclusões, a primeira versão torna-se um saco sem fundo. E o mais comum é a equipa “assumir” que certos temas ficam fora… até alguém os exigir na véspera de entrega.

Criem uma lista curta do que não será feito agora. Não é um “não” eterno; é uma fronteira para proteger a entrega.

• Integração com sistema X (fica para fase 2)
• Migração histórica completa (fica para depois do piloto)
• Personalizações por perfil avançadas (apenas básico no arranque)

4) Como vamos saber que está feito (sem discussões)?

“Feito” não é “está no ambiente”. É cumprir critérios verificáveis. A pergunta certa é: que teste um terceiro consegue fazer para confirmar?

Exemplos práticos: - “Um pedido é criado em menos de 2 minutos, sem campos obrigatórios inúteis.” - “O relatório bate certo com a fonte oficial para um período fechado.” - “Erro de validação aparece antes de submeter, com mensagem clara.”

Sem isto, cada review vira debate de opiniões.

5) Qual é a restrição que manda em todas as outras?

Há sempre uma restrição dominante, mesmo que ninguém a diga: prazo legal, orçamento congelado, stack tecnológica, equipa reduzida, dependência de fornecedor. Se não estiver explícita, vai aparecer como surpresa.

Perguntem: “Se tivermos de sacrificar algo, o que é intocável?” A resposta ajuda a priorizar com honestidade.

Um mini-exemplo realista: o “portal simples” que explode

Numa empresa, alguém pede “um portal simples para pedidos internos”. A equipa imagina um formulário e um painel. Duas semanas depois, surge: aprovações por hierarquia, anexos pesados, auditoria, SSO, perfis por unidade, relatórios mensais, integrações com ERP.

Nada disto é absurdo. O erro é ter sido descoberto por acidente, já com desenvolvimento em curso.

Uma análise de requisitos leve, no início, teria apanhado cedo: - que existem fluxos diferentes (pedido urgente vs. normal); - que compliance exige rasto de auditoria; - que o “simples” afinal significa menos cliques, não menos regras.

Como transformar perguntas em ação (sem burocracia)

O truque não é fazer um workshop infinito. É criar um pequeno pacote de alinhamento que caiba numa página e que toda a gente aceite como referência.

• Objetivo em 2–3 linhas (com métrica, se possível)
• Utilizador principal + 2 cenários reais
• Lista de “fora do scope” para esta fase
• Critérios de aceitação (5–10, curtos)
• Riscos e dependências (o que pode bloquear)

Depois, usem-no no planeamento de projeto: priorização, estimativas, milestones e decisões de trade-off. É aqui que a análise de requisitos deixa de ser teoria e passa a ferramenta.

A melhor forma de acelerar é reduzir incerteza, não aumentar velocidade.

Sinais de alerta: se isto já estiver a acontecer, voltem atrás

Há sintomas clássicos de arranque frágil. Se reconhecerem dois ou três, compensa parar um dia e refazer o alinhamento.

• “Depois logo vemos” aparece em todas as reuniões
• Mudam-se prioridades semanalmente sem um critério claro
• Cada área pede “só mais isto” e ninguém diz não
• A equipa entrega, mas o utilizador não adota
• O QA encontra problemas que são… discussões de interpretação

Um projeto saudável não elimina mudanças; torna-as explícitas e geríveis.

FAQ:

• Como faço análise de requisitos sem escrever um documento enorme? Foque-se em cenários reais, critérios de aceitação e decisões a suportar. Uma página bem feita, validada pelos decisores, vale mais do que 30 páginas ignoradas.
• Quem deve responder a estas perguntas? Um decisor de negócio (prioridades), um utilizador que execute o trabalho (realidade), e alguém técnico (restrições e impacto). Sem este trio, ficam buracos.
• Isto não atrasa o início do projeto? Atrasar 1–2 dias para esclarecer reduz semanas de retrabalho. O custo do “mal-entendido” cresce muito depois de começar a construir.
• E se houver desacordo entre stakeholders? Registem a divergência e forcem uma escolha: qual é a restrição dominante e qual o critério de sucesso. Sem decisão, o desacordo vira requisito escondido.