Como obter os requisitos do projeto das partes interessadas

Introdução

Reunir os requisitos das partes interessadas do projeto geralmente é como puxar os dentes. E se você não se esforçar para cumprir todos os requisitos antes de iniciar o desenvolvimento em um projeto, acabará com uma lista muito longa de problemas durante o teste que deveriam ter sido capturados como requisitos. Há uma variedade de maneiras de conduzir a conversa para garantir que você capture todos os requisitos como parte de um projeto, como coletar histórias de usuário, configurar sessões de brainstorming, diagramar fluxos de processo e muito mais. Seja você um gerente de projeto ou um analista de negócios, este artigo o orienta por algumas das abordagens mais padrão para reunir os requisitos do projeto para garantir que seu projeto comece com o pé direito.

As histórias de usuário geralmente são estruturadas em torno da função do solicitante, do que ele deseja e por que deseja.

Designmodo

Histórias de usuários

Esteja você construindo algo completamente novo ou atualizando um aplicativo existente, a primeira rodada de requisitos deve sempre ser capturada por meio de histórias de usuário. Se essas histórias vêm de usuários finais ou partes interessadas, não importa, e você pode coletá-las de qualquer pessoa. O objetivo é capturar suas expectativas sobre o que será construído e os detalhes sobre como desejam que funcione. Existem diferentes formatos para capturar histórias de usuários, mas todos geralmente capturam a função associada ao solicitante, o que essa pessoa deseja e por que deseja. Essas histórias precisarão ser aprofundadas no processo do projeto.

Sessões de brainstorming

As sessões de brainstorming normalmente envolviam todas as partes interessadas identificadas e alguns dos usuários finais em potencial reunidos em uma sala e apresentando suas ideias sobre quais deveriam ser os requisitos de um projeto. O objetivo é manter a discussão e as pessoas falando. Se houver discrepâncias entre os requisitos que já foram discutidos ou a sua interpretação dos requisitos, coloque isso para o grupo discutir. Como essas sessões geralmente acontecem com uma rapidez incrível, é melhor gravar a conversa ou ter um escriba dedicado para que você possa se concentrar em ser um participante ativo em vez de ficar preso tentando capturar tudo. Se você seguir esse caminho, não é incomum ter mais de uma dessas sessões para garantir que tudo seja discutido.

Embora as sessões de brainstorming sejam ótimas para colocar todos os requisitos abertamente e ter uma conversa sobre eles, resolver tudo depois de uma dessas reuniões pode ser doloroso, devido ao volume de informações.

PM Alliance

Sessões de revisão

Continue colocando os requisitos na frente das partes interessadas do projeto para revisão e não subestime a quantidade de tempo que um grupo pode levar para chegar a um acordo em torno de todos os requisitos de um projeto. Não é incomum que discutir para um pequeno projeto possa levar algumas semanas. Uma abordagem é esperar até que todos dêem uma aprovação verbal sobre os requisitos e, em seguida, esperar alguns dias antes de voltar com todos para obter suas assinaturas em um documento formal onde você pode pedir que dêem uma olhada rápida novamente - apenas para estar do lado seguro. Outra abordagem é pedir a alguém na empresa com conhecimento sobre o que você está fazendo para revisar os requisitos para garantir que tudo pareça o mais hermético possível.

O que incluir em um relatório semanal de status do projeto

Diagrama de Processo

A diagramação de processos é onde você reúne toda a equipe e percorre o fluxo de cada um dos processos identificados que farão parte do projeto. Isso força as partes interessadas a pensar sobre cada etapa do aplicativo solicitado e, frequentemente, expõe novos requisitos que ninguém havia levado em consideração anteriormente. A saída dessas sessões também serve como uma entrada fantástica para wireframing.

Continue perguntando por quê

Perguntar por que é um driver poderoso durante as conversas de requisitos e requisitos específicos e claros não serão desenvolvidos de forma confiável até que não faça mais sentido fazer essa pergunta. Ele força as partes interessadas a pensar nos componentes granulares de seus requisitos iniciais, o que pode ser doloroso e demorado. Além disso, às vezes perguntar continuamente pode expor algo que inicialmente foi considerado um requisito que, afinal, não precisa ser um requisito.