Um Modelo de Gestão de Projectos

Transcrição

1 3 Um Modelo de Gestão de Projectos 3.1 Fases do Modelo de Gestão de Projectos Dois reputados consultores e investigadores em gestão de projectos de software Joseph Weiss e Robert Wysocki descobriram que existe um conjunto de princípios subjacentes a todas as metodologias de gestão de projectos de sucesso. Como consequência desenharam um ciclo de vida da gestão de projectos [Weiss & Wysocki, 1992] que está em consonância com o ciclo de vida subjacente ao PMBOK Guide. O modelo de gestão de projectos que se apresenta em seguida, e que será seguido ao longo deste livro, tem subjacente o modelo proposto por Weiss and Wysocki e segue estreitamente as recomendações do PMBOK Guide e os objectivos das ACPs do nível 4 do CMMI. Este modelo é composto por quatro fases, cada uma das quais com várias etapas: Fase 1: Identificação e Avaliação do Projecto - Selecção estratégica do projecto; - Avaliação da exequibilidade do projecto; - Elaboração do business case do projecto. Fase 2: Definição e Planeamento Detalhado do Projecto - Engenharia do sistema (Descrição do Âmbito + Modelo do Processo de Desenvolvimento); - Planeamento detalhado de prazos, recursos e custos; - Estabelecimento dos padrões e procedimentos da qualidade; - Planeamento da gestão dos riscos do projecto; - Estabelecimento do sistema de comunicações do projecto; - Definição e instalação de processos/ferramentas de controlo de alterações; FCA Ed ditora e Informática 59

2 Gestão de Projectos de Software - Estabelecimento do Plano de Infra-estrutura Tecnológica 13 ; - Preparação e submissão da Proposta do Projecto. Fase 3: Execução e Encerramento do Projecto - Monitorização do progresso do projecto relativamente ao plano; - Revisão dos planos do projecto; - Revisões da qualidade; - Revisões dos riscos; - Controlo de alterações; - Escalada de problemas; - Encerramento do projecto. Fase 4: Suporte Pós-instalação - Implementação do contrato de manutenção; - Realização de uma auditoria pós implementação 14. As quatro fases são realizadas em sequência, com um ponto de decisão entre cada fase ( ). Cada ponto de decisão é consubstanciado por um Relatório de Suporte à Decisão. A Figura 3.1 mostra esquematicamente este modelo. Vamos, em seguida, analisar brevemente as quatro fases enunciadas Identificação e Avaliação do Projecto Esta fase é executada a um nível estrategicamente elevado na companhia e compreende três etapas: selecção estratégica do projecto, avaliação da exequibilidade do projecto (justificação técnica e financeira) e elaboração do business case do projecto. A 1ª etapa tem a ver com o planeamento estratégico de sistemas de informação da empresa/organização e é realizada ao mais alto nível de decisão. Não nos debruçaremos aqui sobre este planeamento estratégico, com detalhe, por estar fora do âmbito desta obra. A 2ª etapa consiste na avaliação financeira e técnica (risco) de cada projecto concorrente aos recursos da companhia. Deve ser avaliado o impacto de cada projecto na arquitectura de TSI e nas infra-estruturas existentes. Esta etapa deve ser executada por um conjunto de Necessário apenas no caso de o sistema a implementar exigir uma alteração à infra-estrutura tecnológica da organização. Esta auditoria é levada a efeito, em muitas organizações, entre seis e nove meses após a entrada em exploração do software aplicacional. 60 FCA Editora de Informática

3 Um Modelo de Gestão de Projectos pessoas de várias áreas da empresa financeira, negócio e sistemas de informação. O seu output é o relatório de business case, destinado à gestão e contendo as conclusões da análise em termos financeiros, técnicos e de negócio. Este relatório é igualmente designado por estudo de exequibilidade. Selecção e Avaliação do Projecto Selecção estratégica do projecto Avaliação da exequibilidade Engenharia do sistema Plano de prazos, custos e recursos Definição e Planeamento Detalhado do Projecto Plano da qualidade Plano dos riscos Plano de comunicação Plano de gestão da configuração Monitorização e controlo do progresso Execução e Encerramento do Projecto Revisões dos riscos Revisões da qualidade Controlo de alterações Encerramento do projecto Suporte Pós-Instalação Manutenção Auditoria pós-implementação Figura 3.1 Um modelo de gestão de projectos de software O relatório do business case deverá incluir: Descrição sumária do projecto e da estratégia empresarial subjacente; Oportunidade e duração prevista do projecto; FCA Editora de Informática 61

4 Gestão de Projectos de Software Estimativa dos custos (de desenvolvimento e de exploração); Estimativa dos benefícios; Análise do investimento; Análise dos riscos; Outras opções consideradas; Impacto nos níveis de pessoal; Implicações de não se fazer nada. Em situação de concurso, uma empresa de serviços fará um exercício semelhante em alguns aspectos, embora com algumas variantes avaliação financeira, avaliação do risco, impacto nos recursos Definição e Planeamento Detalhado do Projecto A segunda fase do modelo de planeamento é o desenvolvimento de um plano detalhado do projecto incidindo nas diversas vertentes relevantes para a gestão do projecto âmbito, limitações, modelo de desenvolvimento, prazos, custos, recursos, qualidade, riscos, controlo de alterações, comunicações, etc. Dependendo da dimensão do projecto, isto pode ser um exercício para duas ou mais pessoas, embora tenha frequentemente lugar numa sessão de planeamento formal em que participam todos aqueles que têm um impacto sobre o projecto ou que sofrem um impacto do projecto. Esta sessão de planeamento pode ser repartida por vários dias, em função da dimensão do projecto. Todos os projectos têm um propósito, o qual é um acordo entre quem solicita o trabalho e quem o vai realizar, relativamente ao âmbito, características e funcionalidades do produto final a ser desenvolvido no projecto. A fase de definição do âmbito começa, de forma ideal, com uma troca de informação entre um cliente e um fornecedor (regra geral, o chefe de projecto). Essa troca de informação envolve normalmente uma discussão entre ambas as partes, de modo a assegurar que o pedido é perfeitamente entendido e que a resposta, sob a forma de determinados produtos ou entregas (deliverables), é igualmente entendida de forma clara. Nesta fase da vida do projecto, o propósito é limitado por um certo número de objectivos declarados, os quais clarificam a amplidão do propósito. Tomados em conjunto, o propósito e os objectivos declarados constituem a estrutura dentro da qual pode ser conduzido com sucesso todo o processo de planeamento. Uma vez concluída a definição, esta é documentada no plano inicial do projecto sob a forma de um ponto inicial descrição do âmbito descrevendo, em linguagem de gestão, o seguinte: 62 FCA Editora de Informática

5 Um Modelo de Gestão de Projectos Antecedentes e objectivos (negócio, projecto); Âmbito e principais produtos do projecto; Organização e recursos de alto nível; Riscos chave; Critérios de medida do sucesso do projecto; Custo e financiamento do projecto; Limitações, pressupostos e dependências que podem afectar o projecto e que merecem a atenção dos gestores; Plano de trabalhos; Processo de gestão do projecto. Depois de obtida a descrição do âmbito para o projecto, é fundamental decidir qual o modelo de desenvolvimento mais adequado aos condicionalismos vigentes modelo em V (ou em cascata), modelo em V com prototipagem, modelo de entrega incremental, modelo em espiral, etc. Com a definição do âmbito e do modelo de desenvolvimento, está concluída a definição da engenharia do sistema a desenvolver. Desta(s) sessão(ões) de planeamento sai a proposta de projecto, que inclui (para além da engenharia do sistema) os seguintes itens: Definição das actividades que constituem o projecto Estrutura de Decomposição do Trabalho 15 (EDT) e respectivas durações, tempo de calendário, custo e recursos necessários; Uma rede do projecto mostrando as dependências entre actividades e a duração total do projecto; Orçamento do projecto; Plano de recursos; Plano de gestão dos riscos; Plano da qualidade contendo a política de incorporação da qualidade, o plano de controlo da qualidade e a estratégia de preservação da qualidade; Estratégia e plano de gestão da configuração; Plano de comunicação do projecto, em termos de relatórios, revisões, reuniões de progresso, etc.; Plano de infra-estrutura tecnológica necessária para o sistema a desenvolver. 15 Work Breakdown Structure (WBS). FCA Editora de Informática 63

6 Gestão de Projectos de Software O plano do projecto é uma descrição de eventos futuros e, nesse sentido, constitui um modelo do projecto. À medida que os eventos ocorrem no projecto, o modelo é afectado e pode alterar-se de modo a descrever como se prevê a evolução dos eventos futuros. Como o plano do projecto é um modelo, podemos usá-lo para testar estratégias alternativas de redireccionamento de eventos futuros. À medida que se iniciam os trabalhos, a natureza do projecto muda por vezes de forma radical: As actividades podem adiantar-se ou atrasar-se, em relação ao plano; Os membros da equipa podem ser redistribuídos, abandonar a empresa ou adoecer; As condições de mercado podem alterar-se, tornando obsoletos um, ou vários, dos objectivos do projecto. Estes eventos podem ocorrer um de cada vez, ou em simultâneo, e o chefe de projecto tem de estar preparado para analisar, decidir e agir. Para tanto, deverá possuir, desde o início, uma ideia clara da complexidade e dimensão do projecto e do trabalho a desenvolver. Na realidade, existem várias dimensões a considerar, ao formular uma estratégia: Se uma actividade se adiantar, ou atrasar, é possível ajustar os recursos atribuídos às fases futuras? Se uma, ou várias, actividades se atrasarem, é possível redistribuir outros recursos atribuídos ao projecto, de modo a restabelecer o cronograma original do projecto? Como é que o chefe de projecto pode, em simultâneo, comprimir o prazo do projecto e evitar conflitos insolúveis de atribuição de recursos? Que recursos são possíveis passar de um projecto para outro, sem afectar de forma adversa o prazo de cada um deles? Como todas estas situações envolvem um certo número de variáveis interdependentes, o chefe de projecto tem de as tratar com o auxílio de um modelo de projecto computorizado como, por exemplo, o MS Project, o Open Plan, o Plan View ou o Artemis. Uma vez aprovada a proposta de projecto, este entra na fase seguinte, em que são concluídos os detalhes da calendarização dos trabalhos e é iniciado o esforço de desenvolvimento Execução e Encerramento do Projecto A equipa de projecto é especificada no início da fase de execução. É fundamental eliminar a noção errada de que o sucesso (ou insucesso) do projecto depende de uma só pessoa. Embora alguns membros específicos da equipa possam ter sido identificados no início da fase de planeamento, os restantes membros são identificados no começo da fase 64 FCA Editora de Informática

7 Um Modelo de Gestão de Projectos de execução. Nas organizações actuais, a equipa de projecto é sempre inter-funcional e extravasa frequentemente as fronteiras organizacionais. Para além da identificação dos elementos da equipa, são examinados e aperfeiçoados os planos de trabalho e desenvolvidas descrições detalhadas das tarefas do projecto. São igualmente estabelecidas as regras operacionais, o tipo de frequência dos relatórios e a periodicidade das reuniões de situação do projecto. A monitorização inicia-se logo após ter começado o trabalho do projecto. Nas fases anteriores foi definido um conjunto de relatórios de situação do projecto designados igualmente por relatórios de progresso que são usados para monitorizar o progresso do projecto. Enquanto alguns desses relatórios são apenas usados pela equipa de projecto, outros são distribuídos ao cliente/utilizador e à gestão de topo. O progresso do projecto é monitorizado relativamente ao plano aprovado e são efectuadas as revisões da qualidade sob a forma de peer reviews, walkthroughs ou auditorias para verificar se os objectivos da qualidade estão a ser alcançados. Os riscos são revistos como parte das reuniões de revisão de projecto (geralmente semanais). A gestão de alterações é uma parte importante desta fase e segue os procedimentos de pedidos de alteração, definidos durante a fase de implementação do plano. Os pedidos de alterações provocam sempre algum replaneamento. Quando é recebido um pedido, o chefe de projecto analisa o plano do projecto à procura de formas de satisfazer o pedido de alteração. É igualmente importante ter previsto um procedimento de escalada de problemas, para lidar com situações sérias de deslizamento de prazos e/ou custos e/ou funcionalidade. A fase final do ciclo de vida inicia-se quando o cliente/utilizador diz que o projecto terminou e aceita os seus resultados. Os critérios de aceitação foram especificados e acordados anteriormente, pelo cliente/utilizador e pelo chefe de projecto, como parte do plano do projecto. O encerramento do projecto envolve: A instalação do software; O refinamento e conclusão da documentação do projecto; O encerramento dos contratos existentes (com o cliente e com os fornecedores); A elaboração, pelo chefe de projecto, de uma súmula final das lições aprendidas com o projecto. É fundamental que as organizações aprendam com os seus erros e sucessos. Para isso, o repositório de projectos deve ser complementado, no encerramento do projecto, com as principais lições aprendidas. Isto é uma tarefa do chefe de projecto. FCA Editora de Informática 65

8 Gestão de Projectos de Software Suporte Pós-instalação Embora o ciclo de vida do projecto tenha chegado ao seu fim, o produto de software aplicacional desenvolvido no projecto iniciou o seu próprio ciclo de vida. O cliente irá querer certamente dispor de um qualquer tipo de contrato de manutenção que preveja eventuais correcções de erros e adição de novas funcionalidades. Esta manutenção não será efectuada pela equipa de projecto que entretanto se terá desmembrado e dedicado a outros projectos mas sim por pessoal dedicado a este tipo de serviço. Em diversas organizações em especial multinacionais é usual efectuar-se uma auditoria pós-implementação, num prazo compreendido entre seis e nove meses após o início da entrada em exploração. Essa auditoria pós-implementação tem como objectivo assegurar que: Os produtos em exploração estão a ser úteis; O suporte prestado é adequado; Os benefícios esperados estão a ser alcançados, ou espera-se venham a ser alcançados; Cada uma destas fases tem certas metodologias associadas, bem como determinada documentação tipo, as quais serão tratadas nas Partes II, III e IV deste livro. A Figura 3.2 mostra as várias fases do modelo aqui proposto, bem como os diversos documentos e revisões a realizar em cada fase. Estudo de exequibilidade Project charter Definição do âmbito Rede das actividades Plano dos riscos Plano da qualidade Plano de infra-estrutura tecnológica (PIT) Relatórios de revisão Relatórios dos testes Relatório de encerramento Selecção do projecto Definição detalhada do projecto Execução e encerramento do projecto Workshop do risco Revisão do project charter Revisão da arquitectura Revisão do PIT Revisão do plano de actividades Revisão dos riscos Revisões da qualidade Revisões do risco Revisões dos testes Encerramento do projecto Relatório de auditoria Suporte pós-instalação Auditoria pós-implementação Figura 3.2 Fases do modelo, revisões e documentos 66 FCA Editora de Informática

9 Um Modelo de Gestão de Projectos 3.2 Pontos de Decisão entre Fases O objectivo do ponto de decisão no final de uma fase é fornecer informação suficiente à gestão para a decisão de prosseguir, ou não, com a fase seguinte. As decisões de parar/prosseguir devem constituir decisões tripartidas, tomadas por três áreas: de negócio, tecnológica e dos utilizadores. Três questões chave devem ser colocadas em cada ponto de decisão: Negócio ainda vale a pena (isto é, o projecto ainda produz os benefícios esperados para o negócio)? Tecnologia ainda é tecnicamente viável (isto é, ainda se pode providenciar uma solução tecnológica satisfatória)? Utilizadores ainda conseguimos fazê-lo funcionar (isto é, ainda conseguimos usar funcionalmente o projecto para atingir os benefícios que os patrocinadores e o negócio esperam)? Como se pode ver na Figura 3.3, a decisão pode ser a prossecução de um de três caminhos: Prosseguir com o projecto, tendo em consideração eventuais recomendações. Não passar à fase seguinte enquanto não estiverem reunidas todas as condições consideradas necessárias. Parar o projecto. Fase anterior Selecção e Avaliação do Projecto Selecção estratégica do projecto Avaliação da exequibilidade Necessária mais informação ou âmbito aumentado Resultados Planos Custos Estimativas Engenharia do sistema Definição e Planeamento Detalhado do Projecto Plano de prazos, custos e recursos Plano da qualidade Plano dos riscos Plano de comunicação Plano de gestão da configuração Ponto de decisão de gestão PARAGEM OU ADIAMENTO Monitorização e controlo do progresso Execução e Encerramento do Projecto Revisões dos riscos Revisões da qualidade Controlo de alterações Encerramento do projecto Recomendações Fase seguinte Suporte Pós-Instalação Manutenção Auditoria pós-implementação Figura 3.3 Pontos de decisão entre fases do modelo FCA Editora de Informática 67

10 Gestão de Projectos de Software 3.3 Repositório do Projecto Deve ser estabelecido, desde o início do processo, um repositório do projecto, o qual conterá todos os documentos do projecto e constituirá um ponto de referência central para toda a informação pertinente. O conteúdo típico deste repositório inclui: A descrição do âmbito do projecto; Todas as entregas do projecto; Riscos do projecto e medidas de mitigação; Resultados dos testes; Resultados das revisões e/ou auditorias da qualidade; Aprovações do trabalho em execução; Pedidos de alteração ao sistema e respectivo seguimento; Notas de entrevistas; Minutas das reuniões; Correspondência; Diário do projecto. O repositório do projecto pode incluir vários volumes. O diário do projecto inclui todos os eventos, problemas e acções tomadas no projecto. Para além disso, a organização deve instituir uma base de conhecimento de projectos que consubstancie o conhecimento sobre todos os projectos que a organização realiza ao longo do tempo. Constitui tarefa dos chefes de projecto alimentarem essa base de conhecimento, a qual deverá conter, para cada projecto da organização, informação sobre: O âmbito; A dimensão (em pessoas mês); As particularidades tecnológicas; Os riscos; Os problemas encontrados; As lições aprendidas. É fundamental que cada empresa seja uma learning organization 16. De acordo com Peter Senge, o autor de The Fifth Discipline [Senge, 1990], isso só é possível se a informação 16 Uma learning organization é aquela em que as pessoas a todos os níveis, individual e colectivamente, aumentam continuamente a sua capacidade de produzir resultados de que gostam realmente. 68 FCA Editora de Informática

11 Um Modelo de Gestão de Projectos relevante for disseminada por todos aqueles que dela necessitam. O nível de desempenho e melhoria exigido hoje requer aprendizagem e muita adaptabilidade. Na maioria das indústrias e, por maioria de razão, na indústria de software não existe nenhum caminho claro para o sucesso. É, por isso, necessário um desempenho superior e uma vantagem competitiva: Para melhorar as relações com os clientes; Para evitar o declínio; Para melhorar a qualidade; Para compreender os riscos e a diversidade mais profundamente; Para manter uma permanente inovação. FCA Editora de Informática 69