10.0 Cachoeira vs. Gestão de Projetos Cíclicos (Parte 3) – Project Lifecycle & Outcomes

Ao longo do ciclo de vida do projeto, os utilizadores devem ser capazes de testar todos os resultados intermédios. #

Os clientes são instados a definir as suas necessidades o mais precisamente possível ao longo das fases de definição e design. Isto é um desafio por duas razões. Para começar, os consumidores têm uma compreensão limitada do potencial e impossibilidade das tecnologias da informação. Não têm noção do que é ou devem ser viáveis, nem sabem o que devem ou não desejar. Em segundo lugar, os consumidores carecem muitas vezes de uma compreensão aprofundada dos seus próprios processos comerciais.

Numerosas iniciativas de TI incluem a informatização dos processos de negócio atuais de uma organização. Embora os consumidores tenham trabalhado com processos durante um longo período de tempo, muitas vezes não têm a capacidade de conceber os seus próprios processos de negócio. Podem funcionar bem à sua maneira, mas não podem especificar o que é essa forma. É necessária uma definição exata do processo antes de desenvolver um software que impulsione a informatização. A complexidade dos clientes aumenta em resultado de ter de explicar os procedimentos atuais.

Determinação dos critérios #

Frequentemente, a lista de critérios produzidos durante a fase de definição está incompleta. Os programadores criam software de acordo com esta lista parcial durante a fase de implementação. Quando os consumidores encontram versões beta de novo software, as necessidades extra tornam-se evidentes. “Parece bom, mas poderia consertá-lo para que eu não tenha que inserir constantemente a minha senha?” Os programadores lamentam frequentemente que os clientes não tenham a certeza do que querem. Os clientes afirmam que, como especialistas, os desenvolvedores de software deveriam ter identificado o que os clientes querem mais cedo no processo.

Foi criado um design funcional abrangente para um projeto de software que incluía o processamento automatizado de aplicações para um serviço baseado na Web. Foram compiladas inúmeras necessidades de clientes. Depois de adicionar alguns desenhos de ecrã e desenhos de fluxo, os programadores podem começar.

Gestão de Clientes e Constrangimentos #

Possivelmente como resultado das severas restrições de tempo do projeto ou, possivelmente, como resultado da organização bastante caótica do cliente, os designers esqueceram-se de consistir numa componente crítica: a administração manual. O programa processou as candidaturas. Uma vez que as candidaturas deviam ser processadas automaticamente, os programadores argumentaram que não seria necessária uma administração humana. Este critério foi igualmente omitido do design funcional.

Quando o programa foi fornecido para testes, o cliente descobriu que muitas aplicações tinham exceções. Estas aplicações não podem ser processadas automaticamente e devem ser tratadas manualmente. No entanto, o programa funcionou inteiramente automaticamente.

A gestão do projeto waterfall requer testes do resultado real do projeto no final da fase de implementação. Esta é uma fase tardia de desenvolvimento. Entre a fase de definição, fase de conceção e fase de implementação, podem passar meses ou mesmo mais de um ano. Se as falhas de conceção forem encontradas numa fase tardia do projeto, pode ser dispendioso, se não impossível, modificar o programa sem iniciar completamente um novo projeto. Dado que é praticamente impossível definir todos os critérios com antecedência, é desejável uma abordagem de trabalho que permita testar os resultados (intermédios).

Análise de Requisitos #

Ao comparar uma série de potenciais empresas de software, um cliente perguntou sobre as possibilidades. Uma das partes estava hesitante e questionou a viabilidade de muitas das exigências do cliente. O lado oposto foi representado por um agente de vendas agressivo.

Quando um cliente perguntou sobre a viabilidade de um pedido específico, o vendedor ligou para os seus codificadores. “Podemos criar uma função que faz X?” O programador, que pensou principalmente em termos técnicos, disse que tudo era teoricamente concebível. Nem o programador nem o vendedor estavam preocupados com a viabilidade da gestão do projeto (por exemplo, tempo, dinheiro, complexidade e risco).

A excitação do representante de vendas superou o comportamento contido do outro partido. O cliente selecionou a oferta agressiva do representante de vendas. O projeto recém-adquirido foi então entregue a um gestor de projeto e a uma equipa de programadores.

Passado algum tempo, tornou-se claro que o projeto estava a ficar aquém das expectativas do cliente. Isto deveu-se, em parte, ao facto de os procedimentos serem muito mais complexos para o cliente do que pareciam inicialmente. Durante uma acesa troca de palavras entre as duas partes, o cliente disse que o vendedor tinha afirmado que a funcionalidade X não seria um problema.