Na seção anterior, mostrei que o çiclo de vida do projeto estrutura do permite que mais de uma atividade ocorra de cada vez. Deixe-me dizer isso de uma outra maneira: na situação mais extrema, todas as atividades do ciclo de vida do projeto estruturado podem
acontecer simultaneamente. No outro extremo, o gerente do projeto pode decidir a adoção da abordagem seqüencial, com o término de toda uma atividade antes do início de uma outra.
É prático ter-se uma terminologia para ajudar na discussão sobre esses extremos, bem como sobre compromissos entre os dois extremos. Uma abordagem radical do ciclo de vida do projeto estruturado é uma em que as atividades de 1 a 9 têm lugar em paralelo desde o início do projeto, isto é, a codificação começa no primeiro dia do projeto e o levantamento e a análise continuam até o último dia do projeto. Em contraste, numa abordagem con.servadora de ciclo de vida do projeto estruturado, toda a atividade N é completada antes do início da atividade
N+1.
Obviamente, nenhum gerente de projeto em seu juízo perfeito ado taria qualquer desses dois extremos. O que é preciso entender é que os extremos radical e conservador
definidos acima são as duas pontas de um leque de escolhas - isso está ilustrado na figura 5.5. Existe um número infinito de escolhas entre os extremos radical e conservador. Um gerente de projeto poderia decidir finalizar 75% da atividade de levanta mento, seguidos pela complementação de 75% de análise de sistemas, e,
116
em seguida, 75% do projeto, a fim de produzir uma razoável versão reduzida de um sistema cujos detalhes poderiam ser aperfeiçoados, em seguida, por um segundo passo através do ciclo de vida do projeto. Ou, o gerente poderia decidir terminar todo o levantamento e a análise, seguida pela complementação de 50% do projeto e 50% da implemen tação. As possibilidades são verdadeiramente intermináveis!
RADICAL RADICAL CONSERVADORA CONSERVADORA Figura 5.5: Opções de implementação radical e conseivadora
Como um gerente de projeto decide se adota uma abordagem radi cal ou uma abordagem conservadora? Basicamente, não há uma resposta
exata. A decisão é habitualmente baseada nos seguintes fatores: • Quão inconstante é o usuário?
• Qual é a pressão sobre a equipe do projeto para produzir resul tados imediatos e tangíveis?
• Qual é a pressão sobre o gerente do projeto para produzir um cronograma, um orçamento e avaliação de pessoas e outros
recursos?
• Quais são os perigos de ser cometido um grande erro técnico?
Como você pode perceber, nenhuma dessas perguntas tem uma resposta simples e direta. Por exemplo, não se pode perguntar ao usuá rio do sistema, em uma conversa casual: «A propósito, quão inconstante você está hoje?” Por outro lado, o gerente do projeto deve estar apto a avaliar a situação, com base na observação, especialmente se ele for um veterano que negociou com muitos usuários e com muitos gerentes de nível superior antes.
Se o gerente do projeto conclui que está tratando com um usuário inconstante - um cuja personalidade é do tipo que adia as decisões finais até que ele veja como o sistema vai funcionar - ele provavelmen te optaria por uma abordagem mais radical. O mesmo vale se o gerente estiver lidando com um usuário inexperiente, que tenha tido muito pou cos sistemas construídos para ele. Por que levar anos desenvolvendo um conjunto
absolutamente perfeito de especificações somente para des cobrir que o usuário não entendeu o significado das especificações?
117
Se, entretanto, o gerente estiver tratando com um usuário veterano que está
absolutamente seguro do que quer, e se o usuário trabalha em uma área de negócios estável e que dificilmente se modificará radical- mente em períodos mensais, então o projeto pode receber uma aborda gem mais conservadora. Certamente existem muitas situações interme diárias: o usuário pode ter certeza de algumas funções comerciais a se rem realizadas, mas pode se sentir um pouco inseguro a respeito dos tipos de relatórios e informações gerenciais que gostaria que o sistema fornecesse. Ou, se o usuário estiver familiarizado com os sistemas de processamento batch, ele poderia se sentir inseguro do impacto que um sistema on-line teria na empresa.
Além da inconstância existe um segundo fator a ser considerado: a pressão para produzir resultados imediatos e palpáveis. Se, devido a pressões políticas ou outras pressões externas, a equipe de projeto preci sar simplesmente acelerar um projeto e executá-lo em uma data específi ca, então é recomendável uma abordagem um tanto radical. O gerente
do projeto ainda corre o risco de ter somente 90% do sistema completo quando chegar a data fatal, mas, ele pelo menos terá um sistema funcio nando em 90%, o que poderá ser demonstrado e talvez até posto em produção. Isto é normalmente melhor do que ter terminado toda a aná lise de sistemas, todo o projeto e todo o código, porém nada de testes.
Naturalmente, todos os projetos estão sob alguma pressão por re sultados tangíveis; é simplesmente uma questão de grau, e é um aspecto que pode ser bastante dinâmico. Um projeto se que inicia com baixa intensidade, com um cronograma confortável, pode de repente tornar-se de alta prioridade e ter a data limite adiantada em seis meses ou em um ano. Uma das vantagens de fazer a análise de sistemas, o projeto, a codi ficação e a implementação top-down é que se pode parar uma atividade em qualquer ponto e deixar os detalhes restantes para considerações subseqüentes; enquanto isso, a análise de sistemas de alto nível que te nha sido completada pode ser usada para começar o projeto de alto nível, e assim por diante.
Outro fator em gerenciamento de projeto é o requisito sempre presente, em organizações maiores, para produzir cronogramas, avalia ções, orçamentos e coisas semelhantes. Em algumas organizações, isso tende a ser feito de uma forma consideravelmente informal, tipicamente porque os projetos são relativamente pequenos e porque a direção sente que qualquer erro de avaliação te’ um impacto insignificante em toda a organização. Nesses casos, po e-se adotar uma abordagem radical, mesmo que as estimativas sejan apenas adivinhações. Em contraste, projetos maiores necessitam de estimativas relativamente detalhadas de requisitos de pessoal, recursos de computador e assim por diante; e isso só pode ser feito depois que tiverem sido feitos o levantamento, a análise e o projeto
detalhados. Em outras palavras, quanto mais detalhadas e 118
exatas tiverem ue ser as estimauvas, mais provavei sera que o projeio siga uma abordagem conservadora.
Finalmente, o gerente de projeto deve considerar o perigo de cometer um erro técnico maior. Por exemplo, suponha que toda a sua experiência anterior como gerente de projeto tenha sido com um peque no sistema de processamento batch em um IBM System/36. E agora, subitamente, se encontre com a incumbência de desenvolver um sistema de informações gerenciais de banco de dados distribuído de multipro cessamento de tempo- real on-line que processará 2 milhões de transa ções por dia, a partir de 5.000 terminais espalhados pelo mundo. Em tais situações, um dos perigos da abordagem radical é descobrir uma grande falha de projeto depois que uma grande parte do sistema inicial de alto nível ter sido implementado.
Ele pode descobrir, por exemplo, que para o seu maravilhoso siste ma funcionar, um módulo de baixo nível tem de executar sua tarefa em 19 microssegundos - porém seus programadores, de repente, avisam que não existem meios de codificar um módulo tão eficiente - não em COBOL, nem em C, e nem mesmo em (ugh!) linguagem assembly. En tão, ele deve estar atento ao fato de que a adoção da abordagem radical exige que seus analistas de sistemas e projetistas escolham um “top” para o seu sistema relativamente cedo rio jogo, e existe sempre o perigo de descobrir, na descida até a base, que eles escolheram o top errado!
No entanto, considere um outro cenário: o gerente de projeto deci diu construir um sistema de PED com um novo hardware, um novo sistema operacional, um sistema de gerenciamento de banco de dados (produzido por alguém que não o fornecedor do hardware) e um novo pacote de telecomunicações (produzido por um outro fornecedor). Todos os fornecedores têm manuais atraentes e lustrosos descrevendo seus produtos, mas eles nunca interfacearam seus respectivos produtos de hardware e software. Quem sabe se eles trabalharão juntos? Quem sabe se a taxa de desempenho apregoada por um fornecedor será des truída pelos recursos de sistema usados por um dos demais fornecedo res? Certamente, em um caso como esse, o gerente de projeto poderia escolher uma abordagem radical, de modo que a versão inicial do siste ma pudesse ser usada para explorar possíveis problemas de interface e de interação entre os componentes dos fornecedores.
Se o gerente do projeto estiver na direção de um tipo familiar de sistema, algo assim como o seu sistema de pagamento, então, provavel mente, terá uma boa idéia sobre quão realistas são suas metas. É possível que se lembre de seu último projeto, que espécies de módulos irá preci sar no nível detalhado, e lembrar-se-á com muita clareza de como se parecia a estrutura de sistema de alto nível. Nesse caso, ele pode estar pretendendo aceitar os riscos de cometer um engano por causa dos outros benefícios que a abordagem radical vai lhe oferecer.
119
Resumindo, a abordagem radical é mais apropriada para pesquisas e esforços de
desenvolvimento de pouca monta, em que ninguém esteja completamente seguro do que o sistema final deverá fazer. Também é indicada para ambientes em que alguma coisa deve estar funcionando em uma certa data e em situações onde a percepção do usuário sobre o que ele deseja que o sistema faça está sujeito a alterações. A abordagem
conservadora, por outro lado, tende a ser usada em grandes projetos, nos quais quantias maciças de dinheiro podem ser gastas e para os quais sejam necessários análise e projeto cuidadosos para prevenir desastres subseqüentes. No entanto, cada projeto é diferente e exige sua própria mistura individual de implementação top-down radical e conservadora. Para lidar com a natureza individual de qualquer projeto, o gerente do projeto deve estar preparado para modificar sua abordagem, a meio do caminho, se necessário for.