Artigo de Abel Reis publicado na Revista Business Standard, Julho de 2003.
Que diferença há entre erguer uma pirâmide no Egito Antigo e implementar um moderno e complexo sistema de informações? Inúmeras, mas duas chamam aqui nossa atenção: a construção de uma pirâmide tinha prazos elásticos – gerações – e recursos virtualmente infinitos – material e escravos, milhares de escravos. O desenvolvimento de sistemas de software de média/grande complexidade nos coloca o desafio de especificar, implementar e testar autênticas obras de Engenharia em prazos enxutos – poucos meses ou anos – e com recursos finitos – orçamentos, plataformas tecnológicas e equipes de projeto.
É provável que os egípcios usassem formas rudimentares de administração de suas grandes obras (faraônicas de fato), como de resto todas as grandes obras de Engenharia e Arquitetura ao longo da história da humanidade devem tê-lo feito. A Revolução Industrial contudo trouxe nova exigência: eficiência. A produção em larga escala guiada pela otimização de tempos, movimentos e custos. Assim, a partir do século XIX, com o advento dos conceitos de Administração Científica e a introdução de controles e previsibilidade nas organizações, inicia-se a formalização de práticas e ferramentas de administração de projetos. Contudo, são os programas militares e espaciais americanos iniciados nos anos 50, os grandes impulsionadores da disciplina de Gestão de Projetos. Mais recentemente, instituições como o PMI (Project Management Institute) (EUA) ou o IPMA (International Project Management Association) (Europa) vêm contribuindo para a consolidação teórica e a difusão de experiências e melhores práticas na área.
Em última instância, práticas bem-definidas e sistemáticas de gestão de projetos visam a garantir que objetivos claramente estabelecidos entre contratante e contratado sejam atingidos em prazos aceitáveis (para ambas as partes), com alocação ótima de recursos. Ou seja, tempo e dinheiro são recursos escassos e como tal devem ser administrados. Neste sentido, escopo, prazo, recursos, riscos e comunicação são fatores críticos cuja administração ao longo de um projeto, por práticas rigorosas e consistentes, permitem garantir o alcance de objetivos, minimizando riscos, e antecipando problemas. Vamos aqui nos deter em três desses fatores.
Escopo delimita as entregas (conjunto de funcionalidades de um sistema) que devem ser apresentadas ao final de um projeto para o cumprimento de seus objetivos. É o mais elementar de todos os fatores a serem gerenciados no projeto de sistemas. Contudo é o mais negligenciado. Isso decorre quase sempre da informalidade com a qual as referidas características são descritas. É como se alguém construísse uma casa sem suas especificações arquitetônicas (planta baixa, elétrica e hidráulica); ou seja, corre-se o sério risco, durante a obra, de descobrir que o banheiro principal ficou do lado de fora da casa. No projeto de sistemas a falta da especificação técnica para a delimitação e detalhamento de escopo leva invariavelmente a surpresas desagradáveis, para contratantes e contratados. Em última instância, escopo é uma ferramenta de comunicação na qual o contratador expressa necessidades, expectativas, regras inerentes ao domínio da aplicação (regras de negócio) e outros aspectos relevantes à compreensão, por parte do contratado, do que se espera da aplicação final. Ausência de escopo claramente definido resulta freqüentemente em clientes insatisfeitos e fornecedores irritados – quando não “quebrados”.
Prazo é o mais mensurável e sensível dos fatores de projeto. Mensurável por razões evidentes pois trata-se de uma medida do tempo materializada num cronograma; e sensível porque qualquer estimativa errada de projeto (ex.: recursos) o atinge diretamente. Gerenciamento de prazo é uma atividade que envolve monitorar e avaliar os demais fatores de forma a garantir que o progresso físico do projeto (quanto das funcionalidades previstas no escopo foi implementado) está em linha com seu progresso no tempo. Quase sempre há diferenças para pior (“falta tempo no fim do projeto”). Muitos desentendimentos entre contratados e contratantes no projeto de sistemas decorrem de uma visão errada de que prazo é um alvo fixo. Infelizmente não é. E por que não é? Porque no projeto de sistemas de média/alta complexidade há diversas fontes de interferência que afetam o prazo, entre eles: (a) a dinâmica das organizações e dos mercados (novos requerimentos); (b) o amadurecimento interno dos contratantes, que revêem definições e necessidades (revisão de requerimentos); e (c) a eventual falta de maturidade das plataformas tecnológicas envolvidas no projeto. Todos os pontos citados podem afetar o prazo e talvez nenhum deles possa ser previsto e controlado de forma efetiva no início do projeto. Portanto, prazo é um alvo móvel, e o que podemos assegurar é a probabilidade de atingi-lo dados os recursos disponíveis e os eventuais riscos envolvidos. Chegamos, assim, ao nosso terceiro fator crítico na gestão de projetos: riscos.
Riscos são eventos que não queremos que ocorram, mas que podem ocorrer. Portanto devemos monitorá-los. Mesmo assim, de forma geral e, no projeto de sistemas em particular, a mentalidade de avaliação estruturada de riscos é pouco difundida (pelo menos no Brasil). No âmbito da gestão de um projeto, riscos afetam (eventualmente de forma irreversível) a viabilidade de prazo ou recursos tais como estipulados originalmente. A identificação, análise, qualificação, ponderação e mitigação (execução de ações de contorno) devem ser realizadas recorrentemente de modo a perseguir as metas vigentes, ou ainda antecipar o seu descumprimento de forma a permitir que alternativas sejam consideradas a tempo.
O tema aqui em questão é amplo e haveria muito outros pontos a considerar. Mas vale por fim lembrar que a aplicação de técnicas de gestão de projetos no desenvolvimento de sistemas deve caber a contratados, mas também a contratantes. Em particular, escopo, prazo e riscos são fatores a serem geridos de forma aberta e compartilhada pelos envolvidos (cliente e fornecedor). No Brasil hoje é possível identificar um movimento ainda que tímido nesta direção, por exemplo através da criação de PMO’s (Project Management Office, instância de auditoria e suporte teórico e prático aos projetos), junto às áreas de sistemas de grandes empresas. Desta forma, ganha-se enorme eficácia e reduzem-se os riscos de chegar a “pirâmides inacabadas”.
