Os requisitos crescerão e mudarão. Eu não acho que alguém possa argumentar isso.
Como coletar e processar solicitações recebidas .
Na minha experiência, ajuda na coleta de requisitos se houver um único ou muito pequeno grupo de clientes atuando como um filtro para fornecer requisitos novos ou atualizados a um pequeno grupo de planejadores de desenvolvimento. Qualquer pessoa do lado deles pode propor ou redigir, mas a entrega deve ser feita apenas por muito poucos. Quanto menos pessoas envolvidas na troca de uma parte para a outra, melhor.
O objetivo de filtrar um grupo menor de pessoas não é descartar ou diminuir o esforço e as informações de outras pessoas, mesmo que duplicadas ou aparentemente sem importância na superfície, mas limitar os pontos de falha: informações perdidas ou mal manuseadas. Ele segue um princípio semelhante ao objetivo do encapsulamento e das interfaces: proteger dados privados e estabelecer um protocolo comum para lidar com solicitações semelhantes. Permitam-me reiterar: o envio de duplicatas está ok. Como planejador, isso me diz que o que eles estão falando ou propondo é importante. Salve ou grave tudo.
Como rastrear e organizar requisitos
No curto prazo, adquira tecnologia de ponta
Obviamente, existem soluções de baixa tecnologia que podem ser eficazes em grande parte para organizar e rastrear os requisitos de entrada: quadros brancos, adesivos, cartazes, o que você tem. Isso pode ser ótimo para o planejamento de curto prazo. Eles são altamente visíveis, aceitam notação de forma livre e são fáceis de 'reconfigurar'.
A longo prazo, use uma ferramenta de software pesquisável, classificável e vinculável
Para esforços de longo alcance, algum tipo de software seria valioso. Existem ferramentas especializadas de gerenciamento de requisitos: Portas, Clearcase / Clearquest e muitas outras. Essas ferramentas altamente especializadas são ótimas no que fazem, mas geralmente são um exagero. Às vezes, mesmo uma planilha antiga simples é mais do que adequada. Pessoalmente, considero os sistemas gerais de rastreamento de problemas bastante úteis para fazer isso, e no momento o meu favorito é o redmine, mas outros, com certeza, também ficariam bem.
Com um sistema de rastreamento de problemas, qualquer pessoa que você escolha permitir poderá criar um 'novo problema' ou requisito e adicionar os detalhes que acharem adequados para incluir. Eles podem acompanhar o problema e fornecer feedback para quaisquer ações que você realizar com ele. Você pode categorizá-lo novamente, ajustar a prioridade, reescrever o corpo, anexar informações suplementares, associá-lo a outros 'problemas', promover a um recurso ou nível de nível superior ou 'caso de uso' ou história ou qualquer terminologia adequada ao seu sistema, ad nauseum. Em outras palavras, você pode fazer muito para criar uma lista de requisitos relacionados rastreáveis, classificáveis, priorizados, com reconhecimento de histórico por meio de problemas. Além de ser razoavelmente configurável e de código aberto, se a ferramenta não for exatamente o que eu preciso ou desejo a qualquer momento, posso alterá-la com bastante facilidade para melhor atender às necessidades do meu processo.
Uma observação final sobre as ferramentas, com quem conversei com bastante sucesso, usando arquivos de texto antigos simples em um sistema de gerenciamento de alterações e versão. Obviamente, eles obtêm os benefícios de versões históricas. Eles também utilizam o sistema operacional básico e ferramentas suplementares para localizar, vincular e catalogar os requisitos. Eles não conseguem adicionar tanta meta-informação estruturada e relacionada, mas não sentem que precisam dela e, por seus esforços, não agregam valor suficiente. Esse pode ou não ser o seu caso. A vantagem é que, potencialmente, há menos peças de software em sua pilha de desenvolvimento para gerenciar e manter.
Requisitos pós-adjudicação do contrato / pós-desenvolvimento do projeto
O aspecto final da pergunta é como gerenciar os requisitos após o início de um esforço. Penso que há duas ideias principais sobre isso, e parte de como você lida com elas depende da natureza do seu relacionamento com o cliente: primeiro, se estiver sob contrato a um valor fixo, os requisitos que surgirem após a adjudicação do contrato poderão ser incorporados. A implicação é que eles podem alterar o escopo do esforço; portanto, a taxa ou a conta serão maiores quando esses itens extras forem entregues e aceitos; a menos que uma quantidade equivalente de esforço seja removida da proposta aceita. Se houver uma mudança no escopo, você deverá garantir que o cliente entenda e aceite a conseqüência; caso contrário, esses envios tardios deverão ser apresentados.
Segundo, para os novos requisitos que entram após a adjudicação do contrato e o contrato é mais orientado para um esforço de tempo e material (o que for necessário para concluir o corpo do trabalho), você pode e deve ser um pouco mais flexível se o o cliente insiste em incluí-lo durante esse período específico. Você será pago independentemente de incluir ou não, desde que tudo o que você diz que fará seja feito.
Se você não estiver familiarizado com eles, consulte uma abordagem Kanban e métodos Agile. Essas técnicas podem ajudar a focar as preocupações imediatas, sem necessariamente perder de vista os objetivos de desenvolvimento a longo prazo.
Apresentar opções como cenários "e se" e dar ao cliente uma escolha e a decisão
Em qualquer um dos casos, uma estimativa de 'e se' é uma boa estratégia a ser empregada ao negociar com o cliente e sua equipe. Construa uma comparação lado a lado das tarefas, seus custos e o cronograma conforme planejado, com uma coluna mostrando as mesmas informações para as abordagens alternativas. O Microsoft Project é provavelmente um bom candidato para fazer isso, pois você pode criar estimativas diferentes com base em um conjunto de tarefas bastante semelhante.
No entanto, mesmo uma planilha básica costuma ser igualmente eficaz para demonstrar como alterações ou inclusões específicas afetariam o custo e o cronograma. Uma lista nesse caso é provavelmente tão eficaz quanto uma árvore para demonstrar as diferenças. A ferramenta e o método que você escolhe para construir esses cenários dependem amplamente do tamanho do projeto e da equipe (mas mesmo um software A triplo como o MS Project tem seus próprios limites de utilidade e capacidade).
Considere estes cenários what if como itens de trabalho internos e salve-os durante o projeto. Foram demonstrações críticas no processo de tomada de decisão e negociação. Você também pode ter que revisitá-los ou repeti-los para uma rodada sucessiva do que acontecerá.
Ao preparar cenários what if, uma explicação suplementar dos prós e contras de uma perspectiva técnica ou de implementação (em termos simplificados) pode ser útil para ajudar a justificar por que uma alternativa teria um impacto tão significativo.