Estimativa do projeto com requisitos crescentes

Fazer uma estimativa do projeto com um determinado conjunto de requisitos é uma coisa.

Mas, o que acontece quando o usuário repentinamente começa a alterá-los rapidamente e começa a adicionar novos requisitos ao conjunto já definido? E até chega a ficar bravo por que o projeto não foi concluído no prazo originalmente planejado.

Como devo lidar com essas situações? Propor algumas metodologias e leituras pode ser útil.

Você deve deixar claro para o cliente que as mudanças nos requisitos também são mudanças no escopo e fornecer atualizações às estimativas sempre que houver uma mudança nos requisitos.

As estimativas do projeto são chamadas estimativas por um motivo. Eles não são promessas. Se o cliente quiser fazer promessas, é um negócio diferente; agora você precisa fornecer estimativas muito maiores e com maior probabilidade de sucesso, usando requisitos congelados .

A maioria das estimativas de projeto fornece um certo nível de preenchimento, entre 20% a 100% de prêmio em tempo (ou mais) em relação a uma estimativa ideal. Verifique se suas estimativas incluem esse preenchimento.

Existem metodologias ágeis que fornecem melhor visibilidade para o cliente, para que eles possam ter uma idéia melhor do esforço envolvido e de como suas mudanças estão impactando os cronogramas.

Você precisa atualizar as estimativas quando eles atualizarem os requisitos e ter uma especificação definida do que o cliente aceitará como "concluído". "Minha estimativa anterior era para o conjunto de recursos X, Y. Se você deseja que eu adicione Z, estimo que estenderá a data de entrega em ..." etc.

Você deve comunicar formalmente o impacto no cronograma e nos custos ao cliente e à gerência ao alterar os requisitos ou adicionar novos. Faça o possível para impor um mecanismo formal de aprovação , para que eles pensem profundamente antes de pedir algo novo ou qualquer mudança. Caso contrário, você continuará ouvindo "Eu quero que você adicione XYZ" e depois "Eu disse XYZ, eu quis dizer ABC".

Pense no seu projeto como um triângulo (um amigo meu da PM realmente criou um triângulo físico que ele usou para obter um efeito adicional). As arestas são chamadas de tempo , custo e escopo . Você diz ao seu cliente que ele pode ter o controle de dois lados, mas você (responsável pela entrega) deve ter o controle de pelo menos um.

Assim, você pode fazer isso de forma rápida e barata - mas, em seguida, precisa ter o poder de reduzir o escopo.

Ou você pode obter mais recursos, mas isso levará mais tempo ou mais dinheiro.

Leia mais em http://en.wikipedia.org/wiki/Project_triangle

Você pode tentar implementar o Scrum , uma metodologia ágil que, de acordo com a sua situação, pode ser muito útil.

Da Wikipedia:

Scrum é um esqueleto de processo que contém conjuntos de práticas e funções predefinidas. Os principais papéis no Scrum são:

1. o “ScrumMaster”, que mantém os processos (normalmente no lugar de um gerente de projeto)
2. o "Dono do produto", que representa as partes interessadas e os negócios
3. a "Equipe", um grupo multifuncional de cerca de 7 pessoas que faz a análise, o design, a implementação, o teste, etc.

Durante cada "sprint", normalmente um período de duas a quatro semanas (com a duração decidida pela equipe), a equipe cria um incremento potencialmente transportável do produto (por exemplo, software de trabalho e testado). O conjunto de recursos que entram em um sprint vem do “backlog” do produto, que é um conjunto priorizado de requisitos de alto nível do trabalho a ser realizado. Quais itens da lista de pendências entram no sprint são determinados durante a reunião de planejamento do sprint.

Não se trata de metodologias, mas de comunicação com um cliente.

Tive muitas situações em que os clientes queriam adicionar constantemente novos recursos a um projeto não concluído e fiquei surpreso por aumentar o custo geral e os atrasos. Sendo o contexto e a personalidade desses clientes diferentes, foram necessárias abordagens diferentes, mas posso tentar isolar algumas diretrizes e conselhos:

• Certifique-se de que um cliente tenha acesso às informações gerais necessárias para entender por que uma alteração em um requisito pode afetar tanto o custo quanto o atraso . Em outras palavras, publique alguns artigos sobre essas coisas, explicando o que uma pessoa não técnica talvez não saiba.

Por exemplo, para a maioria das pessoas, é totalmente estranho que uma mudança que considerem pequena possa ter um grande impacto no projeto e ser muito cara (veja o exemplo na minha pergunta ). Se eles pedirem para fazer algumas alterações, e toda vez que você lhes disser, sem explicar nada, que eles teriam que pagar milhares de dólares quando esperassem de graça ou por algumas dezenas de dólares, provavelmente pensariam que você é apenas roubando seu dinheiro. Isso é especialmente verdade, já que alguns programadores antiéticos e empresas de software desenvolvem produtos não mantíveis (portanto, você não pode pedir para alterá-lo mais tarde por um desenvolvedor normal) e, em seguida, pede que você pague muito por cada modificação.

• Assegure-se de que um cliente tenha entendido por que a mudança específica que ele deseja tem impacto no custo . Para isso, você pode fornecer a ela os links para seus artigos (consulte o ponto anterior), ou apenas resumir, de maneira não técnica, o que é necessário para fazer uma alteração solicitada.

Essas explicações também são uma boa ideia, pois permitem que seu cliente tenha uma melhor compreensão do produto e da mudança. Em alguns casos, alguns de meus clientes acabaram dizendo que a mudança que eles queriam não era muito inteligente e que eles o fariam de outra maneira. Você também pode sugerir coisas. É muito apreciado por alguns clientes (aviso: outros odeiam) e mostra que você sabe do que está falando (em comparação com o macaco de código que acaba de traduzir os requisitos em código, sem pensar muito nas possíveis abordagens) .

• Garanta que um cliente não possa fazer o que quiser, a menos que tenha certeza. Para algumas pessoas, a única maneira é bloquear os requisitos definitivamente antes de começar a codificar . Caso contrário, é um desastre, e o projeto nunca terminará . Para outros, é apenas uma boa idéia nunca ver um projeto não terminado (em geral, meus clientes têm acesso ao produto não terminado muito cedo, para que possam fazer comentários / ajustes também).

Por exemplo, eu tinha um cliente que, depois de enviar requisitos "finais", enviou, em média, dez e-mails por dia com dez alterações de requisitos, passando por pequenas modificações ("Você pode alterar a largura da borda da zona do meio na página inicial?" de três a seis pixels? ") para as mudanças que afetaram todo o projeto (após dois meses de desenvolvimento, uma semana antes do lançamento:" Finalmente, acho que o ASP.NET é uma má idéia. Você poderia mudar para o PHP, por favor? " )

Portanto, para esse cliente , fomos obrigados a bloquear todos os requisitos antes de escrever o código. Foi escrito no contrato. Nenhuma alteração foi aceita antes do lançamento final.

Finalmente, não foi tão ruim, pois curiosamente nos permitimos ser muito organizados: o projeto foi lançado de acordo com os requisitos antigos e, alguns dias depois, começamos a próxima versão do zero com um conjunto completamente diferente de requisitos.