APRENDER. PRATICAR. EVOLUIR.1. Começar pelo problema e pelas pessoas
Uma equipa fictícia reconcilia movimentos de fundos todas as manhãs. O pedido inicial é comprar uma ferramenta, mas o problema observado é o tempo gasto a distinguir ficheiros repetidos de correções legítimas. Antes de escolher a solução, descreve quem executa o trabalho, qual é o resultado pretendido e onde surgem as exceções. Ouve analistas, suporte noturno e o responsável pelo processo. Uma entrevista revela a experiência de uma pessoa; uma sessão com exemplos permite comparar interpretações. Regista divergências e quem pode esclarecer cada regra. O coordenador de projeto facilita esta descoberta sem assumir que a pessoa mais experiente tem autoridade para aprovar todas as necessidades.
2. Escrever critérios que permitem decidir
Um requisito como o painel deve ser rápido deixa espaço para interpretações incompatíveis. Pergunta qual é a operação, quem a executa, com que volume e em que condições. Neste exercício, os envolvidos acordam medir o percentil 95 do tempo de pesquisa para 30 utilizadores simultâneos, num conjunto de dados definido. O limite numérico deve resultar da necessidade e de uma decisão informada, nunca de uma escolha arbitrária do coordenador. Inclui critérios funcionais, como distinguir um ficheiro repetido de uma correção, e condições operacionais pertinentes. Um critério permite aceitar ou rejeitar um resultado observado; a existência de um documento não demonstra que o comportamento foi implementado.
3. Seguir a cadeia entre necessidade e evidência
Usa identificadores estáveis para ligar necessidade, requisito, componente, teste e decisão de aceitação. Uma linha pode conter N2, R7, importador, T7, versão 3 e resultado pendente. Esta estrutura ajuda a encontrar necessidades sem implementação e alterações sem testes adequados. Se T7 passou na versão 2 e R7 mudou na versão 3, a ligação continua a ser útil, mas o resultado anterior não demonstra o novo comportamento. Analisa o impacto antes de decidir o que repetir. Também verifica o sentido inverso: uma funcionalidade sem necessidade identificada pode representar trabalho desnecessário ou uma necessidade ainda não documentada. A matriz orienta perguntas; não substitui julgamento técnico nem aprovação.
4. Resolver pedidos com autoridade explícita
Num projeto com âmbito aprovado, um pedido de retenção adicional pode afetar armazenamento, operação, prazo e orçamento. Regista a razão do pedido e prepara opções, incluindo manter a solução atual, ajustar o pedido ou alterar compromissos. Identifica quem decide segundo a governação aplicável. O responsável por escrever a ata pode não ter autoridade para aprovar despesa. Numa entrega adaptativa, as necessidades também são analisadas e priorizadas; a presença de um backlog não elimina restrições financeiras ou decisões formais necessárias. Comunica o resultado e atualiza os elementos afetados depois da decisão adequada. Não confundas uma conversa favorável com uma autorização que o processo exige de forma explícita.
5. Preparar uma decisão de release
Uma release precisa de critérios próprios, componentes necessários e evidência adequada ao risco. No caso fictício, importar movimentos e aplicar permissões são indispensáveis para reconciliar com segurança; exportar gráficos é desejável. Se a capacidade não chega, apresenta uma opção que preserve o objetivo e adie trabalho menos necessário, com consequências visíveis. Um painel com 20 testes aprovados em 21 não demonstra prontidão se o teste bloqueado cobre um requisito obrigatório. Explica o que está demonstrado, o que falta e quem pode decidir sobre a situação. Um desvio autorizado, quando o processo o permite, deve ficar distinguido de um teste aprovado; não reescreve retroativamente a evidência.
6. Exercício guiado e resumo
Constrói uma matriz pequena para três requisitos: importar um ficheiro válido, recusar um duplicado e permitir a recuperação pelo suporte. Define uma pessoa responsável por esclarecer cada regra, um teste observável e a versão alvo. Imagina que os dois primeiros testes passam e a recuperação não foi executada. Escreve um estado de duas frases que preserve o progresso e exponha a lacuna. Depois acrescenta um pedido de retenção e identifica decisões e evidência afetadas. O resultado esperado é uma cadeia compreensível entre necessidade, compromisso e demonstração. Revê se existem palavras vagas, grupos esquecidos, resultados de versões anteriores ou aprovações atribuídas a quem apenas recolheu informação.
Exemplo fictício: R1 importa o ficheiro, R2 rejeita uma repetição e R3 permite recuperação pelo suporte. R1 e R2 passaram na versão 3; R3 está bloqueado. O estado correto distingue entrega técnica parcial de aceitação ainda pendente.
Armadilhas comuns
Contar documentos como evidência, aceitar resultados de outra versão, confundir destinatário com aprovador e esconder um requisito obrigatório numa percentagem agregada.
Tópicos relacionados: Descobrir requisitos e validar resultados · Partes interessadas e comunicação
Cada requisito precisa de uma necessidade identificável, critérios verificáveis e evidência aplicável. Pedidos e lacunas devem chegar à pessoa com autoridade para decidir.
Referência: Project management and business analysis · CAPM ECO 2023; official outline consulted 2026-09-29