Transformando requisitos ruins em bons


requisitos-de-projetos

Ter requisitos ruins (ou não ter requisitos) definitivamente não é a melhor maneira de começar qualquer projeto. Mas a maioria dos gerentes de projeto irá dizer que você provavelmente não conseguirá obter os melhores requisitos de seu cliente do projeto – não importa o quão certo ele possa estar de ter documentado tudo para você.

O problema é que alguns clientes do projeto não têm sequer certeza se eles sabem o problema ou necessidade que o projeto vai resolver para eles. Nesses casos, não há nenhuma maneira de um cliente ter requisitos bons e detalhados esperando por você. Eles nem sequer sabem o verdadeiro problema ainda … eles provavelmente só documentaram um sintoma.

A questão é esta – os clientes não são conhecidos por oferecerem bons requisitos para as soluções que eles estão buscando das equipes de projeto. Idealmente, os clientes deveriam ter se encontrado internamente com seus usuários finais e especialistas para determinar exatamente qual é o problema, o que é o projeto real, e pelo menos quais são os requisitos de alto nível que precisam ser cumpridos pela equipe do projeto na medida em que eles desenvolvem e implementam a solução.

Na realidade, esses usuários finais são muitas vezes negligenciados deixando-nos responsáveis pela implementação de uma solução que pode ou não os ajudar a fazer o seu trabalho melhor. E se isso não resolve a necessidade – não importa quem culpamos, nós é que falhamos com o cliente do projeto, e não o contrário.

A fim de chegar ao ponto em que a equipe do projeto sabe o que precisa ser feito e exatamente o que se espera deles, algumas ações precisam ser tomadas. A partir da minha experiência, eu as reduzi às quatro etapas ou processos-chave seguintes que devemos passar como uma equipe de projeto. A fim de obter um bom controle sobre os requisitos reais e produzir uma solução final funcional para os usuários finais, a equipe do projeto deve…

  • Obter os requisitos iniciais do cliente no início do projeto;
  • Iniciar formalmente o projeto e definir as expectativas;
  • Definir os requisitos detalhadamente com o cliente;
  • Rastrear os requisitos com uma matriz de rastreabilidade.

Vejamos cada um destes com mais detalhes.

Obter os requisitos iniciais do cliente no início do projeto

Goste ou não, o nosso ponto de partida deve ser o que o cliente do projeto pode fornecer em termos de requisitos do projeto. Não podemos usar apenas esta fonte, já que eles provavelmente não serão completos o suficiente para atender as necessidades de requisitos detalhados, completos e reais.

Por definição, a fim de ser um bom requisito, ele deve ser unitário (definir uma coisa), completo, consistente, não-conjugado, rastreável, atual, sem ambiguidades, ter sua importância definida, e ser verificável. Podemos chegar lá com a ajuda do cliente do projeto, mas não é provável que o cliente vai chegar lá por conta própria.

Não há como o gerente de projeto saber o quão pronto o cliente está com o seu verdadeiro requisito do projeto até que ele veja o quanto de preparação ele já colocou no engajamento. Além disso, é absolutamente necessário o conhecimento do estado de preparação do cliente para mapear adequadamente um cronograma do projeto e quanto tempo a fase de planejamento vai exigir – algo que é uma entrada crítica para o kickoff do projeto.

Iniciar formalmente o projeto e definir as expectativas

Com todas as informações preliminares de preparação do projeto na mão, o gerente de projeto está agora pronto para montar um rascunho de cronograma de projeto com base nessas informações e qualquer informação obtida pela equipe de vendas. No mínimo, isso deveria incluir a declaração de trabalho, a estimativa original, pressupostos, e os recursos planejados.

Uma vez que o gerente de projeto tem o rascunho do cronograma do projeto pronto, uma data para o início, e uma apresentação formal preparada, a reunião inicial deve ser realizada com o cliente e a equipe do projeto. Esta é a reunião onde as expectativas são definidas, o cronograma é revisto e acordado, objetivos e marcos são estabelecidos, e o planejamento final do projeto é colocado em movimento.

Definir os requisitos detalhadamente com o cliente

Após a reunião de início do projeto, a equipe do projeto irá trabalhar com o cliente em novas atividades de planejamento do projeto. A principal atividade é a definição detalhada dos requisitos do projeto, incluindo fazer as perguntas certas ao cliente, equipe do cliente, especialistas temáticos dos clientes e usuários finais para identificar verdadeiramente quais são as reais necessidades do projeto.

Essa é a única maneira pela qual a equipe do projeto pode identificar de forma eficaz os requisitos pormenorizados para o cliente e a única maneira que eles podem confiantemente embarcar no desenvolvimento de uma solução de projeto que vai atender às necessidades do usuário final do cliente uma vez que a solução é implantada.

Rastrear os requisitos com uma matriz de rastreabilidade

Como já disse, documentar requisitos detalhados e precisos é importante, mas não é o fim do trabalho de requisitos. A melhor maneira de documentar os requisitos, e saber que nos levarão à solução final é criar uma matriz de rastreabilidade.

Esta é uma ferramenta dinâmica que será usada durante todo o projeto, e atualizada para mostrar onde cada requisito é construído para a solução e verificado em testes de aceitação do usuário para certificar que todas as funções funcionam, e depois formalmente aceito pelo cliente.

Resumo

Os requisitos são a essência do projeto. Requisitos ruins = um projeto ruim que geralmente envolve muito retrabalho, um orçamento e cronograma acima do esperado, e geralmente termina com um cliente insatisfeito e uma base de usuários finais frustrados. Isso é ruim, obviamente.

Estas quatro etapas ou ações não vão garantir o sucesso ou que você tenha ótimos requisitos para trabalhar. Projetos falham, os requisitos mudam sem percebermos, e os sistemas dos clientes são muitas vezes complexos – o que significa que não é fácil capturar bons requisitos todas as vezes. É nossa responsabilidade como gestores de projeto construir o tempo adequado para o cronograma do projeto e o orçamento para planejar e definir os requisitos do projeto. Isso garante melhor equilíbrio quando tentamos ir além do planejamento para o verdadeiro trabalho de projetar e construir a solução para o cliente. Além disso, requisitos bons e detalhados tornam o teste de aceitação do usuário mais fácil (e melhor), o que também serve para garantir que os usuários finais estão recebendo o que eles precisam, no longo prazo.

Ao compreender o verdadeiro problema, documentar requisitos detalhados e acompanhar esses requisitos através de uma matriz de rastreabilidade para garantir que eles são construídos de forma alinhada com a solução, a equipe do projeto pode estar confiante de que os usuários finais do cliente receberão uma solução que eles podem utilizar de maneira produtiva. O resultado final será uma implementação bem-sucedida e um cliente de projeto satisfeito.

Autor: Brad Egeland

Artigo publicado originalmente no site Project Times

Publicidade