A técnica da cascata é dividida em estágios. Os líderes do projeto devem incluir estimativas para o tempo (e, portanto, dinheiro) necessário para cada passo nos seus planos de projeto. Já estabelecemos que as estimativas de tempo são inerentemente problemáticas para qualquer projeto, muito mais quando devem ser definidas no início da vida do projeto. Só não é viável para projetos de software. Considere a possibilidade de que uma lista qualitativamente aceitável de capacidades possa ser compilada durante a fase de definição. Em princípio, isto deve permitir à equipa do projeto dar uma estimativa realista do tempo necessário para desenvolver cada recurso. No entanto, na realidade, há demasiadas incertezas para proporcionar uma aproximação justa:
No entanto, na realidade, há demasiadas incertezas para proporcionar uma aproximação justa:
- Frequentemente, depois de uma funcionalidade ser desenvolvida, constata-se que o cliente não precisa dele. Assim, as horas passadas a desenvolver esta característica podem ser consideradas em vão.
- Ao longo do projeto, os requisitos podem mudar.
- A capacidade deve ser fornecida a um custo elevado ou a baixo custo? Existem muitas técnicas de implementação e realização.
- Como é que a funcionalidade será tecnicamente desenhada? O design influencia muito a quantidade de tempo necessário para criá-lo.
- Em que medida o funcionamento deve ser de alto padrão? Por exemplo, deve uma aplicação web estar sempre totalmente acessível, ou deve ser permitida a uma baixa de algumas horas por ano?
- O tempo necessário para detetar e corrigir problemas de software varia de minutos a semanas.
- Quanto tempo demorará o novo software a instalar e integrar-se com os sistemas atuais do cliente?
- A falta de informação sobre potenciais soluções afeta ainda mais as estimativas de tempo. Além disso, estimar o tempo necessário para adquirir os conhecimentos necessários é um desafio.
A lista acima demonstra que uma variedade de variáveis pode influenciar o tempo necessário para desenvolver uma nova peça de software. As estimativas do tempo necessário para desenvolver uma funcionalidade no início de um projeto são frequentemente quatro vezes mais baixas ou quatro vezes mais altas. Isto implica que o tempo necessário pode ser quatro vezes mais ou quatro vezes menos do que uma estimativa errónea. À medida que o projeto se desenvolve, estas estimativas tornam-se mais precisas. Após completar o design funcional, a margem diminui para 25% de mais ou muito pouco. Só quando a funcionalidade foi desenvolvida é que é possível dar uma estimativa com um alto grau de confiança.
Riscos de Software #
O software de gestão de projetos nunca estará totalmente isento de erros. Mesmo para programas bem conhecidos que são amplamente utilizados (por exemplo, Word, Excel, Explorer, OS X, PHP e Flash), a Internet tem listas de falhas conhecidas. Regularmente, são disponibilizadas novas versões no mercado que corrigem bugs de software. Os clientes às vezes exigem que o software seja isento de erros. Na realidade, porém, tal objetivo tornaria inviável a conclusão de uma peça de software. Além disso, muitas vezes as falhas de software não são inerentes ao programa.
Flash foi usado para criar um jogo de instrução. O cliente concordou em obter o jogo como ficheiro e instalá-lo no seu próprio servidor. Durante o projeto, o cliente pediu que fosse adicionada uma funcionalidade de pontuação elevada ao jogo para aumentar a competitividade dos jogadores. Isto precisaria de um código de script PHP. Os desenvolvedores de jogos desenvolveram e testaram o código de script no seu próprio servidor executando Linux. Foi um sucesso. O cliente recebeu o código do jogo e do guião. No entanto, o cliente usou um servidor Windows e, por alguma razão, o script deixou de funcionar corretamente. As melhores notas não foram mantidas. O programador precisa, em última análise, de uma semana para resolver o problema. Ao que parece, o PHP e o Windows nem sempre funcionam bem em conjunto. O guião na sua totalidade não teve erros! Conseguiu fazê-lo funcionar através do uso de um hack, e todos ficaram satisfeitos — mas quem deve pagar por essa semana de trabalho adicional?
Outro projeto de desenvolvimento de software incluiu a criação de aplicações instrutivas também. A questão era que o software funcionava muito bem para os desenvolvedores, mas não era bom para o cliente. Depois de esgotar todas as outras possibilidades, o programador decidiu fazer uma visita ao cliente. Ao que parece, o cliente geria uma máquina pentium III do início dos anos 90. A lentidão do computador contribuiu para o mau desempenho do software. Além disso, os programadores tentaram o software num Pentium III, e funcionaram bem. Um exame mais aprofundado mostrou que o PC do cliente estava a funcionar lentamente devido a uma infeção por vírus e spyware.
Gerir incertezas no desenvolvimento de projetos #
A incerteza demonstrada pelas instâncias acima complica o processo de desenvolvimento dos planos de projeto. Além disso, complica as negociações entre as partes. Alguém deve suportar os riscos associados ao trabalho adicional que deve ser realizado. Se o pagamento for feito de hora em hora, o cliente tem todos os riscos. Quando uma taxa fixa é acordada (como é o caso de projetos financiados por subvenções), o desenvolvedor de software suporta o risco. Quando há mais de duas pessoas envolvidas, a situação torna-se mais complexa. Neste cenário, quem deve suportar o custo das horas suplementares trabalhadas no projeto?
Muitas vezes surgem litígios sobre quem deve ser responsabilizado pelos atrasos. Muitas vezes, a pessoa responsável é difícil de identificar. É bastante concebível que nenhuma das partes envolvidas seja culpada, uma vez que o “atraso” foi causado por uma estimativa inicial incorreta do número de horas exigidas. O excesso de horas de projeto e a questão de quem deve pagar são causas comuns de discórdia na indústria das tecnologias da informação.
