Como gerenciar e estimar os requisitos não estruturados recebidos dos clientes


21

Muitas vezes, durante a fase de licitação de um projeto, recebo os requisitos de um sistema de software de nossos clientes em potencial, em um formato não estruturado, de várias fontes [email, documentos do word, excel]. Geralmente, um grupo de "desenvolvedores de produtos" do lado do cliente cria essas "soluções propostas" para os problemas de negócios que eles têm. Embora sejam especialistas no domínio comercial, muitas vezes não têm as soluções corretas.

Isto resulta em

  • várias versões do mesmo requisito
  • mistura de dois requisitos em um
  • algumas versões do requisito posteriormente, os requisitos que foram combinados são separados novamente, cada um levando consigo algumas das novas adições

Como você trabalha com esses requisitos e os classifica em casos de uso adequados e antes do início do desenvolvimento? Quais ferramentas podemos usar para rastrear o histórico de um determinado requisito, desde a primeira vez que ele foi concebido até o momento em que se cristalizou em um caso de uso adequado? Estimar o trabalho com relação aos requisitos recebidos dessa maneira é um pesadelo que acaba cometendo erros no entendimento correto do requisito e na estimativa correta do esforço realizado.

Depois que vencemos o projeto, os clientes refletem um pouco mais sobre seus requisitos e conseguem articulá-lo adequadamente. O que acontece nesse caso é que algumas funcionalidades são descartadas, outras aprimoradas e outras são revertidas. Basicamente, isso pode anular algumas das estimativas do item de trabalho que foram feitas antes da conquista do projeto. Eu estaria interessado em saber se existe algum sistema pelo qual possamos construir uma árvore de um requisito específico e como cada ramo resultou em uma estimativa diferente.

Alguma dica, ferramenta, truque para tornar essa atividade mais gerenciável? Estou apenas tentando obter informações de alguém mais experiente do que eu em gerenciamento de requisitos e estimativa de esforço.


1
Alguém da sua equipe trabalha com a equipe de "desenvolvimento de produtos" para fazer a análise de requisitos (por exemplo, um analista de negócios)?
Deco

Sim, faço isso em todos os casos em que não fazemos orçamento em um BA.
user20358

Respostas:


17

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.


4

Eu encararia isso como um processo iterativo. O passo 1 é reunir os requisitos. O passo 2 é classificá-los. O passo 3 é priorizá-los. O passo 4 é a decomposição em bits pequenos o suficiente para estimar o esforço. O passo 5 é reunir esses bits em um intervalo de esforço global (digamos 84 pessoas por dia). O passo 6 é mapear o esforço para os recursos (84 pessoas / dia / 2 devs = 42 dias).

Então, neste momento, você está preso entre as etapas 1 e 2. Você tem requisitos, mas não os possui da forma que precisa.

Digamos que você tenha várias versões do mesmo requisito. Estes são essencialmente os mesmos? Nesse caso, escolha o que parece ser o mais claro e use-o. Se eles variam em detalhes, escolha o que parece ser o mais lógico e use esse. Em seguida, envie uma mensagem ao cliente solicitando que ele verifique o requisito. Você pode ter que ir e voltar várias vezes para obter o requisito certo. Não desista ou desanime. Muitos projetos falharam devido a requisitos insuficientes.

Use o projeto Microsoft para manter o trabalho e o cronograma sincronizados com os requisitos de alteração. Se o cliente solicitar uma alteração, especifique o trabalho adicional, conecte-o ao seu modelo e informe-os sobre a nova data. Não se deixe levar por acreditar que você pode simplesmente trazer novos desenvolvedores em intervalos aleatórios para pegar a folga. Sua programação deve levar em consideração o tempo de aceleração sempre que um novo recurso é adicionado. Você só poderá modelar isso adequadamente se prestar atenção em cada projeto e aprender com ele. Digamos que você tenha trazido Bob para o projeto X depois que ele durou quatro meses. Quão produtivo ele foi no 1º mês? O terceiro?

Você deve revisar o modelo do projeto semanalmente, fazendo atualizações sempre que necessário. Mantenha um registro histórico das mudanças. Isso ajudará você a fornecer melhores estimativas no futuro.

doug

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.