Gestão de Projetos de Software PDF

I - Enquadramento da Gestão de Projetos --------------------------------------- ### 1.1 Definição de Projeto As organizações realizam trabalho. O trabalho envolve, geralmente, operações ou projetos, embora os dois se possam sobrepor. Operações e projetos podem partilhar muitas características, por...

I - Enquadramento da Gestão de Projetos --------------------------------------- ### 1.1 Definição de Projeto As organizações realizam trabalho. O trabalho envolve, geralmente, operações ou projetos, embora os dois se possam sobrepor. Operações e projetos podem partilhar muitas características, por exemplo, ambos são: - - - A principal diferença entre operações e projetos é que as primeiras são contínuas e repetitivas, e os projetos são temporários e únicos. De acordo com a NP ISO 21500, um projeto pode ser definido como: \"Um conjunto único de processos consistindo em atividades coordenadas e controladas com datas de início e de fim, desenvolvidas para alcançar um objetivo.\" Já o *PMBOK® Guide* apresenta uma definição mais simples: \"Um empreendimento temporário realizado com o objetivo de produzir um produto, serviço ou resultado único.\' Se alargarmos um pouco mais essa definição, poderemos definir o \"empreendimento\" como uma sequência de atividades únicas, complexas e interligadas, que têm um objetivo ou propósito e que devem ser concluídas num determinado período de tempo, dentro de um dado orçamento e de acordo com uma certa especificação. Analisemos cada uma das partes desta definição: **Sequência de atividades:** Um projeto compreende um conjunto de atividades que devem ser realizadas numa determinada sequência. A sequência de atividades é baseada em requisitos técnicos, não em prerrogativas de gestão. Para determinar a sequência, é útil pensar em termos de inputs e outputs o que é preciso como input para começar a trabalhar nesta atividade? Que atividades produzem aquelas outras como output? O output de uma atividade, ou conjunto de atividades, torna-se o input de outra atividade, ou conjunto de atividades. **Atividades únicas:** As circunstâncias deste projeto nunca aconteceram antes e nunca mais acontecerão. Cada vez que as atividades de um projeto se repetem, há sempre algo de diferente que as torna únicas. Regra geral, estas variações são aleatórias por natureza - por exemplo, a entrega de uma componente de hardware atrasa-se, alguém demora mais tempo a realizar a sua tarefa ou ocorre uma falha de eletricidade. Estes eventos aleatórios têm impacto no prazo e/ou no custo e são um desafio para o gestor de projeto. O seu domínio é o objeto da gestão do risco. **Atividades complexas:** As atividades do desenvolvimento de software não são simples. Desenhar uma interface de utilizador, por exemplo, é uma tarefa complexa. **Atividades interligadas:** A interligação implica a existência de relações lógicas ou técnicas entre pares de atividades. Existe uma ordem para a sequência de realização das atividades que constituem o projeto. Elas são consideradas interligadas porque o output de uma atividade é o input de outra - por exemplo, temos de desenhar um programa de computador, antes de podermos codificar. **Um objetivo** Os projetos podem ter um único objetivo - por exemplo, desenhar um campo de jogos para uma universidade. Os projetos maiores e mais complexos podem ser divididos em subprojetos, em que cada um é um projeto por direito próprio. Esta divisão é realizada com o objetivo de ter um melhor controlo de gestão. O inconveniente é que estes subproje- tos são interdependentes. No entanto, embora essa interdependência acrescente uma camada adicional de complexidade e comunicação, ela pode ser gerida. **Produto, serviço ou resultado:** O produto ou serviço-alvo do projeto pode ser único, embora a categoria a que pertence seja ampla. Por exemplo, milhares e milhares de sistemas de software têm sido desenvolvidos, mas cada um é individual e único cliente/utilizador diferente, desenho diferente, arquitetura diferente, localização diferente, etc. Como o produto de cada projeto é único, as características que o distinguem devem ser elaboradas progressivamente, isto é, por passos. Isto implica que a elaboração das características do produto deve ser cuidadosamente coordenada com o adequado âmbito do projeto, em especial se este for realizado sob um contrato. **Num dado período de tempo:** Os projetos têm uma data de conclusão, que pode ser imposta período internamente pela gestão ou externamente por um cliente. A data limite está, regra geral, fora do controlo de quem trabalha no projeto. Um projeto atinge o seu término quando os seus objetivos são alcançados ou quando se torna claro que os objetivos não podem atingidos e o projeto é cancelado. A natureza temporária dos projetos pode aplicar-se igualmente a outros aspetos do ambiente: - - **Com um dado orçamento:** Os projetos têm sempre recursos limitados - pessoas, dinheiro, equipamentos, etc. Embora esses recursos possam ser ajustados por excesso ou por defeito pela gestão, para o gestor de projeto eles são considerados recursos fixos. **Exemplo:** Se uma empresa tiver um único *web designer*, no momento, este é o recurso fixo disponível para os gestores de projeto. A gestão de topo pode alterar o número dos recursos, mas o gestor de projeto não se pode dar a esse luxo. Se esse *web designer* estiver inteiramente ocupado, o gestor de projeto tem um conflito de recursos para resolver. **De acordo com uma dada** **especificação:** O cliente, ou o recetor dos resultados do projeto, espera um certo nível de funcionalidade e qualidade do projeto. Embora o gestor de projeto trate as especificações como fixas, a realidade da situação é que existem muitos fatores que podem provocar alterações nas especificações. **Exemplo**: O cliente pode não ter definido exaustivamente os requisitos ou a situação do mercado pode ter-se alterado. Não é realista esperar que a especificação permaneça inalterável durante toda a vida do projeto. Isto levanta desafios especiais para o gestor de projeto. Os projetos de software possuem algumas características peculiares que os distinguem dos projetos noutras áreas económicas: - - - - - - - ### 1.2 Projetos e Estratégia Os projetos são uma forma de organizar atividades *que* não podem *ser* tratadas dentro dos limites operacionais normais das organizações. Por isso, os projetos são frequentemente utilizados como um meio de alcançar o plano estratégico da organização, quer a equipa de projeto faça parte dos seus quadros, quer seja um fornecedor *de* serviços contratado. Os projetos são tipicamente autorizados como resultado de uma, ou várias, das seguintes considerações: - - - - - - - ### **1.3 Diferenças entre Projetos de Software** e **Outros Projetos** Existem quatro diferenças básicas entre os projetos de software e os projetos de outros domínios, que justificam o seu tratamento especial: - - - - ### 1.4 Definição de Gestão de Projetos A gestão de um projeto é definida no *PMBOK® Guide* do seguinte modo: - Esta definição é bastante similar à da NP ISO 21500: - A gestão do projeto é levada a cabo através do uso dos processos de iniciação, planeamento, execução, monitorização e controlo, e encerramento (que adiante se descrevem). O gestor de projeto é a pessoa responsável pela gestão do projeto, a qual envolve: - - - - Os projetos de elevada qualidade entregam o produto ou serviço requerido de acordo com o âmbito, o prazo e o orçamento definidos. A tradução de *stakeholders* na norma NP ISO 21500 é partes interessadas. Usaremos doravante esta designação. ### 1.5 Restrições do Projeto **1.5.1 Definição e Características** Restrições são variáveis do projeto que, ao serem fixadas, restringem a liberdade de atuação do gestor de projeto e da sua equipa de gestão. Tradicionalmente, consideravam-se três restrições-tipo nos projetos: o prazo, o custo e o âmbito. Atualmente, considera-se que um número maior de variáveis pode ser objeto de restrições pelas partes interessadas, ou de qualquer outro fator influenciador do projeto (o mercado, normas que afetam o projeto, condições contratuais, etc.). Assim, as restrições podem ser exercidas sobre as seguintes variáveis do projeto: - - - - - - - O \"triângulo de restrições\" tradicional dá, assim, lugar ao \"hexágono de restrições\" (Figura 1.1). Custo Riscos Prazo Satisfação do cliente Qualidade Âmbito Recursos **Figura 1.1 - Restrições do projeto** As restrições estão em concorrência e necessitam de ser equilibradas para que o projeto possa ter sucesso. A natureza e as características de cada projeto influenciam as restrições que o gestor de projeto necessita de trabalhar. Por outro lado, a natureza das relações entre estes fatores determina que, se um deles varia, pelo menos um dos outros poderá ser afetado. **Exemplos:** - - - Por vezes, as diferentes partes interessadas do projeto têm ideias diferentes sobre a importância relativa dos diferentes fatores, criando, com essa atitude, um enorme desafio ao gestor de projeto. **1.5.2 Deslizamento do Âmbito** O deslizamento do âmbito é o termo usado para designar qualquer alteração no projeto que não estava no plano original. A mudança é constante; esperar o contrário é simplesmente irrealista. As alterações ocorrem por vários motivos que não têm nada que ver com a capacidade ou a perspicácia do cliente/utilizador ou do gestor de projeto. A concorrência pode introduzir, ou anunciar que vai introduzir, uma nova versão deste produto e a gestão da empresa pode decidir que é necessário estar presente no mercado antes da concorrência. O trabalho do gestor de projeto é encontrar soluções para conciliar estas alterações. **1.5.3 Deslizamento do Esforço** O deslizamento do esforço é a consequência de os membros da equipa não fazerem progressos compatíveis com o esforço de trabalho realizado. A \"síndrome dos 5%\" faz já parte do folclore da indústria do software: parece que falta sempre 5% do projeto para concluir, independentemente do esforço despendido para o terminar. Todas as semanas o relatório de situação progride, mas o volume de trabalho remanescente não parece diminuir na mesma proporção. A única coisa eficaz que o gestor de projeto pode fazer - além de verificações aleatórias - é aumentar a frequência de relatórios de situação para aqueles membros da equipa que aparentam estar a sofrer de deslizamento do esforço. **1.5.4 Deslizamento da Funcionalidade** O deslizamento da funcionalidade está intimamente relacionado com o deslizamento do âmbito e acontece quando os membros da equipa adicionam aos produtos do projeto, de forma arbitrária, aspetos e funções que acham que o cliente gostaria de ter. É o que o *Project Management Institute* (PMI) denomina *golden plate*. O problema é que o cliente não especificou a funcionalidade (provavelmente por algum bom motivo). Se o membro da equipa tem uma forte sensação sobre a necessidade desta nova funcionalidade, devem ser seguidos procedimentos formais de **controlo de alterações**. Este assunto será discutido no Capítulo 15. **Exemplo:** O programador está ocupado a codificar um determinado módulo do sistema e tem a ideia de que **o** menciona esta opção. Parece perfeitamente normal que o programador decida incluir a opção, em vez cliente poderá gostar de ter uma outra opção incluída. O documento de requisitos do sistema não de ter de passar pelo mais demorado processo de controlo de alterações. Embora esta abordagem pareça bastante inocente, pode ter consequências bastante sérias Primeiro que tudo, como a funcionalidade não está no documento de requisitos do sistema, também não estará nos procedimentos dos testes de aceitação, na do utilizador e no programa de treino do utilizador. - - - A mensagem é clara: deve realizar-se um pedido formal de alteração e, se este for aprovado, devem ser modificados o plano do projeto e todas as atividades relacionadas. ### 1.6 Influências Organizacionais nos Projetos A estrutura e a cultura organizacionais, bem como o estilo de liderança, têm uma forte influência no modo com os projetos de software são conduzidos, em virtude de os engenheiros de software serem trabalhadores do conhecimento que desenvolvem e modificam software num ambiente de trabalho em equipa estreitamente coordenado. **1.6.1 Sistemas Organizacionais** Organizações orientadas por projetos são aquelas cujas operações primárias são projetos. Estas organizações correspondem às seguintes categorias: - - Estas organizações tendem a implementar sistemas de gestão destinados a facilitar a gestão de projetos. Por exemplo, os seus sistemas financeiros estão muitas vezes especialmente desenhados para facilitar a contabilização, a monitorização e a emissão de relatórios de múltiplos projetos simultâneos. As organizações não orientadas por projetos - empresas de produção, firmas de serviços financeiros, etc. - raramente dispõem de sistemas de gestão desenhados para suportar, de forma eficiente e eficaz, as necessidades de projetos. A ausência de sistemas orientados por projetos torna, geralmente, a gestão de projetos mais difícil. Em alguns casos, as organizações não orientadas por projetos têm departamentos, ou outras subunidades, que operam como organizações orientadas por projetos e dispõem de sistemas adequados. A equipa de gestão do projeto deve estar muito consciente do modo como os sistemas da organização afetam o projeto. Por exemplo, se a organização recompensa os seus gestores funcionais por cobrarem tempo de colaboradores a projetos, a equipa de gestão do projeto pode ter necessidade de implementar controlos para garantir que o pessoal atribuído está, de facto, a ser usado no projeto. **1.6.2 Culturas e Estilos Organizacionais** A maioria das organizações desenvolveu culturas próprias, que se encontram refletidas nos seus valores, normas, crenças e expectativas; nas suas políticas e procedimentos; na 0 sua visão das relações de autoridade, etc.) As culturas organizacionais exercem, muitas vezes, uma influência direta sobre o projeto. **Exemplos:** - - Devido à natureza única dos projetos de software (produto intangível e trabalho em equipa estreitamente coordenado), os fatores organizacionais que influenciam a moral e a motivação dos especialistas de software são diferentes dos que afetam outros elementos da mesma organização e incluem fatores como: - - - - - - - - O desenvolvimento de software tende a ser uma experiência de aprendizagem e partilha de conhecimento. Diversos fatores organizacionais incrementam a aprendizagem e a partilha de conhecimento entre os elementos das equipas de projeto e, como consequência, aumentam a qualidade do produto e o desempenho do projeto: - - - - - - - Reciprocamente, a ausência destes fatores pode resultar num decréscimo da motivação e do moral, quer ao nível individual quer da equipa. Estes fatores são importantes para todos os trabalhadores do conhecimento, como é o caso dos especialistas de software. **1.6.3 Estrutura Organizacional** As empresas de software podem organizar os projetos de diversas maneiras: - - - Internamente, um projeto de software é tipicamente organizado em uma ou várias pequenas equipas (dez membros, ou menos, por equipa) em que o número de equipas depende da dimensão e âmbito do projeto. Equipas reduzidas e coordenadas minimizam os problemas de comunicação interna e entre equipas, em virtude de o número de possíveis canais de comunicação em pequenas equipas ser inferior ao número de canais em equipas de grande dimensão. Outros elementos funcionais de uma organização de software poderão fornecer serviços de suporte, como gestão da configuração, ferramentas e suporte a infraestruturas, ou capacidades independentes de verificação e validação. A Tabela 1.1 detalha as características-chave, associadas com projetos, dos principais tipos de estruturas empresariais. Tabela 1.1 - Influências das estruturas organizacionais nos projetos Uma outra questão é o alinhamento da estrutura organizacional do projeto de software com a estrutura desejada para o produto de software. De acordo com a a conhecida Lei de Conway\" \[Conway, 1968\], \"qualquer um que desenhe um sistema produzirá inevitavelmente um desenho cuja estrutura é uma cópia da estrutura de comunicação da organização.\" **Exemplo:** Um projeto que é organizado usando três equipas de desenvolvimento (ou uma única equipa com três elementos) tenderá a desenvolver um produto de software com três componentes, ao passo que um projeto com quatro equipas (ou uma única equipa com quatro elementos) tenderá a desenvolver o mesmo produto com quatro componentes, em virtude de o software ser um produto do esforço coordenado de equipas e membros de equipas que distribuem entre si as funcionalidades e interfaces a serem implementados. É evidente que, à semelhança de todas as \"leis do software\", a lei de Conway é uma diretriz, não uma lei da física ou da química. ### 1.7 *Project Management Office* À medida que a prática da gestão de projetos foi crescendo, cresceu igualmente a necessidade de métodos de implementação sistemáticos. As organizações agiram rapidamente no sentido de adquirir software de gestão de prazos, enviar empregados a cursos de formação em gestão de projetos e mesmo de estabelecer programas académicos de graduação no domínio. As empresas podem fazer algo mais para melhorar a sua gestão de projetos: estabelecer ***Project Management Offices*** (PMO). **1.7.1 Objetivos do *Project Management Office*** O PMO é constituído por profissionais de gestão de projetos que servem as necessidades da sua organização, em termos de gestão de projetos. Embora os deveres e funções dos PMO variem de acordo com a organização, nos últimos anos verificou-se uma convergência de papéis distintos (Figura 1.2). **Figura 1.2 - PMO**: **um fornecedor integral de serviços** Atualmente, os PMO desempenham algumas das seguintes funções, ou mesmo todas: - - - - **1.7.2 Necessidade de um *Project Management Office*** Se uma organização realizar projetos de uma forma esporádica, não tem necessidade de desenvolver aptidões sistemáticas para se comprometer com projetos. Neste caso, implementar um PMO seria análogo a \"matar mosquitos com uma espingarda\". No entanto, à medida que uma organização orienta cada vez mais energia para a implementação de projetos, uma abordagem *ad hoc* da gestão de projetos conduz a ineficiências e pode mesmo ser perigosa. Quando o número de projetos aumenta, mais imperiosa se torna a necessidade de implementar um PMO. Quando é estabelecido um PMO, a organização pode desenvolver uma abordagem consistente para a implementação de projetos. Além disso, se o PMO for configurado para servir a organização inteira, pode desempenhar um importante papel na integração das atividades interfuncionais ao longo da organização. Pode igualmente incentivar o profissionalismo na gestão de projetos. Os PMO atuais têm os seus antecedentes nas indústrias da defesa e da construção, as quais foram sempre orientadas por projetos e organizadas de modo a centralizar as atividades de gestão de projetos num único local. No entanto, estes PMO tradicionais eram diferentes daqueles que hoje estão a emergir, na medida em que serviam as necessidades de um único projeto, grande e complexo. Por exemplo, se era iniciado um projeto para construção de uma aeronave, estabelecia-se de imediato um PMO. O Quadro 1.1 enumera os beneficios progressivos da implementação de um PMO. Em contraste com esta abordagem tradicional, os PMO atualmente emergentes servem as necessidades mais abrangentes em gestão de projetos da organização. Não são implementados para tratar de um único projeto, mas para servir múltiplos projetos e a organização global. Beneficios do PMO: - - - - - - **Quadro 1.1** - **Benefícios progressivos de um PMO** **1.7.3 Fornecimento de Gestores de Projeto** Uma importante função do PMO é satisfazer as necessidades da organização em gestores de projeto que possuam a adequada mistura de aptidões técnicas e de gestão. Os gestores de projeto podem, por exemplo: - - - - Além de realizar estas funções de suporte, os gestores de projeto devem estar igualmente disponíveis para realizar projetos de desenvolvimento de software. Para poder satisfazer as necessidades da organização em gestores de projeto, de uma forma constante, o PMO deve possuir aptidões de desenvolvimento de recursos humanos, ou seja, deve ser capaz de: - - - - - Vamos analisar de seguida cada uma dessas aptidões. **1.7.3.1 Identificar as Aptidões Requeridas** Quando o PMO recebe um pedido para fornecer a um grupo um gestor de projeto qualificado, deve ser capaz de identificar as aptidões exigidas para o trabalho. Estas aptidões são simultaneamente técnicas e de gestão. O PMO deve ser igualmente capaz de identificar as aptidões pessoais necessárias para o trabalho: - - - Exemplos: - - **1.7.3.2 Identificar Indivíduos para Projetos Particulares** Quando recebe um pedido de um gestor de projeto qualificado para gerir um projeto, o PMO deve ser capaz de analisar a lista de possíveis candidatos e encontrar a pessoa mais adequada para o trabalho. Isto significa que o PMO necessita de desenvolver uma base de dados com as qualificações dos gestores de projeto da organização. Selecionar uma pessoa significa encontrar alguém com as aptidões pessoais, de gestão e técnicas adequadas. Alguns estudos efetuados sugerem que os melhores gestores de projeto possuem a maioria das seguintes aptidões (se não todas): - - - - - - - - - **1.7.3.3 Atribuir as Pessoas Certas no Momento Adequado** A oportunidade da atribuição de recursos é muito importante. Colocar um génio no projeto não adianta muito à equipa caso chegue atrasado ou adiantado uma semana. Para poder atribuir recursos oportunamente, o PMO tem de ser eficaz em várias áreas. Por exemplo, tem de possuir um bom conhecimento do cronograma do projeto. - - - O PMO deve possuir as aptidões necessárias para ajudar os gestores de projeto a libertarem-se das múltiplas exigências que espartilham o seu tempo. **1.7.3.4 Adquirir os Gestores de Projeto Adequados** Os gestores das organizações contemporâneas estão constantemente comprometidos com decisões de fazer internamente ou adquirir em *outsourcing*. **Exemplo:** - - Nas suas tentativas para recrutar gestores de projeto, os PMO têm de seguir o mesmo processo de decisão. Devem ser obtidas respostas para questões como: - - - Cada uma destas abordagens tem pontos fortes e pontos fracos. Ao formar os gestores de projeto internamente, a organização cria um grupo de profissionais que desenvolve aptidões e capacidades de gestão de projetos no contexto da própria organização. Isso é bom. Por outro lado, estes profissionais precisarão de vários anos antes de se transformarem em gestores de projeto experientes e valiosos. Se recrutar gestores de projeto experientes, a organização pode admitir profissionais qualificados de uma forma rápida. No entanto, no início a sua experiência pode não ser inteiramente relevante para o contexto específico da organização. Além disso, se a organização espera contratar os melhores profissionais, tem de estar preparada para oferecer elevados salários e manter esses níveis salariais no futuro. Finalmente, ao contratar atividades de gestão de projetos a um fornecedor externo, a organização pode ter uma abordagem flexível na aquisição de quem necessita. No entanto, estas pessoas podem não ser totalmente adequadas para o contexto específico da organização e serão certamente caras. Além disso, a dependência de terceiros pode conduzir a um défice das aptidões nucleares da organização. **1.7.3.5 Avaliar as Aptidões dos Gestores de Projeto** Se o PMO se tornar a \"casa\" dos gestores de projeto, então tem de ser capaz de efetuar avaliações do seu desempenho. Num PMO de dimensões reduzidas, o próprio diretor realiza essa tarefa. Em PMO de maior dimensão, as revisões de avaliação do desempenho serão levadas a cabo por subdiretores que têm responsabilidades em áreas pertinentes. A principal dificuldade na avaliação do desempenho de gestores de projeto é que o avaliador, que trabalha no PMO, não dispõe de muitas oportunidades para observar o gestor de projeto em funções. A avaliação será largamente baseada na informação prestada por clientes a quem o gestor de projeto tem estado atribuído. Embora este *feedback* seja importante, deve reconhecer-se que os clientes não estão geralmente numa posição boa para avaliar as capacidades de gestores de projeto. Por exemplo, podem faltar-lhes as aptidões técnicas para avaliar os méritos técnicos do desempenho da equipa de projeto. **1.7.4 Desenvolver os Gestores de Projeto** O aspeto das empresas alterou-se dramaticamente. Para serem competitivas, instituíram transformações radicais nos seus modos de operação, reengenharia de processos, redução da dimensão (*downsizing*), diminuição dos níveis de gestão intermédia (flattening), delegação de poder nos empregados (*empowerment*) e subcontratação de serviços e produção (*outsourcing*). Em conjunto, estas transformações contribuíram para um ambiente que promove o emprego de gestão de projetos como forma de ajustamento aos desafios contemporâneos. Embora exista hoje uma forte procura de gestores de projeto que façam as coisas acontecer, ao mesmo tempo temos uma situação em que a oferta de bons gestores de projeto é insuficiente para satisfazer a procura. Se as organizações pretendem adquirir e manter gestores de projeto altamente qualificados e motivados, devem criar um ambiente que lhes possibilite prosperar. Os PMO devem desempenhar um papel central neste empreendimento, concentrando-se em quatro aspetos: - - - - **1.7.4.1 Melhorar os Conhecimentos e Aptidões dos Gestores de Projeto** Os requisitos em conhecimento e aptidões para gestores de projeto podem ser desanimadores: - - - Algumas organizações com desempenhos mais elevados proporcionam aos seus gestores Embora alguma dessa formação possa andar em torno da compreensão dos produtos e conhecimentos, desde gestão de projetos básica e análise financeira, a conhecimentos sobre Internet. As organizações que quiserem desenvolver um grupo forte de gestores projeto, têm de dedicar recursos significativos à formação e ao treino. A Orientação para o Desenvolvimento de Carreira de gestores de projeto atingiu o estatuto de profissão. Em grande medida, este profissionalismo tem sido alimentado pelos auspícios do PMI que determinou que os gestores de projeto mais eficazes são competentes em dez áreas de conhecimento (ver ponto 2.2.3). O PMI administra exames de certificação para avaliar a medida em que os indivíduos são competentes nestas dez áreas. Os PMO devem requerer que os gestores de projeto sigam este processo de certificação. **1.7.4.2 Fornecer Suporte** Mesmo os mais inteligentes e enérgicos gestores de projeto falharão se não lhes for fornecido o necessário suporte para executarem eficazmente o seu trabalho. O PMO deve fornecer aos gestores de projeto um processo claramente definido para a execução do seu trabalho. Deve fornecer-lhes igualmente as ferramentas necessárias, incluindo hardware e pacotes de software aplicacional. No entanto, os PMO não têm controlo direto sobre muitos dos itens que contribuem para o adequado suporte aos projetos por exemplo, os sistemas de processamento de encomendas e sistemas contabilísticos. Consideremos o caso dos sistemas contabilísticos - embora seja difícil, se não impossí- vel, efetuar um adequado controlo de custos sem um sistema baseado em atividades ou um sistema de contabilidade de projetos, a maioria das organizações possui apenas sistemas de contabilidade geral não orientados para a realidade dos projetos. ### 1.8 Classificação dos Projetos De acordo com o *Center for Project Management,* os projetos podem ser classificados de acordo com duas dimensões: ambiente empresarial e ambiente tecnológico. Esta instituição desenvolveu uma *Complexity Assessment Grid,* baseada na medição de 40 variáveis que definem as características do projeto no domínio bidimensional referido. Um projeto típico pode então ser representado por um ponto na *Complexity Assessment Matrix* (Figura 1.3). Os pontos podem cair numa de quatro categorias: **Projetos Tipo IV** - possuem baixo valor empresarial e usam uma tecnologia bem estabelecida. De facto, estes são projetos que podem ter sido repetidos várias vezes e constituem atualmente uma rotina da organização; **Projetos Tipo III** - caracterizam-se pelo seu elevado valor empresarial, embora possam possuir uma complexidade técnica moderada ou baixa; **Projetos Tipo II** - podem usar tecnologias novas ou complexas e, na medida em que o seu valor empresarial se revele moderado ou baixo, podem distinguir-se dos projetos Tipo I; **Projetos Tipo I** - possuem todas as características dos projetos Tipos II e III, n medida em que usam tecnologias complexas e possuem um elevado valor empresarial. São os mais exigentes, entre os quatro tipos, e são frequentemente complexo. **Figura 1.3 - Avaliação da complexidade de um projeto** ### 1.9 O Sucesso dos Projetos de Software Podemos definir um projeto de sucesso como aquele que: - - - Usando estes critérios, determinar o sucesso deveria ser claro e absoluto, certo? Infelizmente não é assim tão simples. Se partes interessadas-chave acordam que um projeto tem valor suficiente para justificar o compromisso de recursos que excedem o orçamento original, o projeto pode ser ainda considerado um sucesso. De igual modo, um projeto que entregou tudo no desenho detalhado poderá ser considerado um fracasso se não incluiu elementos vitais que as partes interessadas necessitavam. Embora isto pareça injusto, sucesso e fracasso não são apenas questões de factos, nem tem apenas que ver com o que foi entregue. Acima de tudo, a determinação se um projeto é um sucesso ou um insucesso tem que ver com a forma como o projeto é **percecionado**: - - - - Poderíamos ser levados a pensar que a taxa de insucesso decaiu significativamente ao longo dos últimos 20 anos, dada a crescente ênfase na gestão de projeto e a ampla adoção de standards como o *PMBOK® Guide* e o *PRINCE2*. No entanto, os estudos realizados ao longo dos anos contrariam essa asserção. De acordo com dados do *Gartner Group* \[Gartner Group, 2012\], os custos dos projetos de TI representam mais de 25% da despesa total com projetos em todo o mundo. Ainda de acordo com o *Gartner Group*, 75% dos grandes projetos de software (projetos com um orçamento de 10 milhões de euros, ou mais) falham nos objetivos que se propõem alcançar. E, de acordo com o *Standish Group* \[Standish Group, 2013\], 61% dos projetos de TI falham e são responsáveis por mais de 8000 milhões de euros de prejuízos apenas nos EUA! Os atrasos são superiores a 70% e os custos aumentam em mais de 65%, sendo que cerca de 50% das funcionalidades implementadas raramente ou nunca são utilizadas. Segundo o *Standish Group*, as práticas pobres de gestão de projeto nunca foram consideradas uma causa de insucesso, desde que os estudos se iniciaram em 1994. Por isso, se a má gestão de projeto não é a causa principal da falha dos projetos, então qual é? De acordo com o *Chaos Report* \[Standish Group, 2013\], as três principais causas do insucesso dos projetos são (Figura 1.4): - - - Detalharemos este tema adiante, no ponto 1.9.3. **1.9.1 Expectativas das Partes Interessadas** É fundamental a identificação oportuna de todas as **partes interessadas**, isto é, as pessoas e organizações que estão ativamente envolvidas no projeto ou cujos interesses podem ser afetados de forma positiva ou negativa, em resultado da execução do projeto ou da sua conclusão bem-sucedida. Esta identificação é importante, pois permite determinar quais são as suas necessidades expectativas e, depois, gerir e influenciar essas expectativas de modo a garantir Organização e práticas de gestão do projeto pobres. **Figura 1.4 - Principais causas de insucesso dos projetos de software** A identificação das partes interessadas é, muitas vezes, difícil. Por exemplo, um trabalha dor de uma linha de montagem, cujo emprego depende do resultado do projeto de desenho de um novo produto, é uma parte interessada no projeto? Entre as partes interessadas em qualquer projeto podem constar: - - - - - - - - - - Existem, além destes, muitos nomes e categorias de diferentes partes interessadas internos e externos, donos e financiadores, fornecedores e contratados, membros da equipa e respetivas famílias, departamentos governamentais e empresas de comunicação (jornais, canais de televisão, etc.), cidadãos individuais, organizações de influência temporária ou permanente e a sociedade em geral. Os papéis podem sobrepor-se, como quando uma firma de engenharia financia uma fábrica que está a desenhar. A gestão das expectativas das partes interessadas pode ser difícil porque têm frequentemente objetivos muito diferentes, que podem entrar em conflito. **Exemplos:** - - - De uma maneira geral, as diferenças entre partes interessadas devem ser resolvidas **a favor do cliente**. Isto não significa, contudo, que as necessidades e expectativas de outros possam ser menosprezadas. Encontrar as soluções adequadas para tais diferenças pode constituir um dos maiores desafios da gestão do projeto. **1.9.2 Fatores Críticos de Sucesso dos Projetos de Software** Segundo o *Standish Group* \[Standish Group, 2013\], dez fatores contribuem de forma crítica para o sucesso dos modernos projetos de software: - - - - - - - - - - Vamos analisar, de seguida, cada um destes fatores críticos. **1.9.2.1 Suporte da Gestão Executiva** A pessoa mais importante no projeto é o sponsor executivo. Esta pessoa é a responsável máxima pelo sucesso ou insucesso do projeto. **1.9.2.2 Envolvimento dos Utilizadores** O grau de envolvimento dos utilizadores, bem como a experiência e idoneidade dos elementos envolvidos, são determinantes para o sucesso, embora o nivel de comprometimento constitua o principal fator. **1.9.2.3 Otimização** O Standish Group define otimização como \"um projeto com poucos recursos humanos e entregas aceleradas\". E a grande tendência atual dos projetos de software, potenciada pelo uso de metodologias ágeis de desenvolvimento. **1.9.2.4 Recursos Qualificados** Ter recursos qualificados num projeto significa ter as pessoas certas a fazer as coisas certas no momento certo. **1.9.2.5 Gestão de Projeto Eficaz** O gestor de projeto é a força condutora central de um projeto. A sua eficácia é um fator- -chave para o sucesso do projeto. É necessário manter um equilíbrio delicado entre a qualidade do produto, o prazo requerido para o produzir e os custos incorridos. **1.9.2.6 Processos Ágeis** Ter processos ágeis é atualmente percecionado como sendo o remédio universal contra *o* insucesso dos projetos de desenvolvimento de software. Uma das razões principais é o facto de os processos ágeis simplificarem a execução de projetos pequenos e facilitarem a decomposição de projetos grandes em projetos mais pequenos. O segredo é o método da tentativa e erro e o uso de processos iterativos. O software deve ser desenvolvido em passos pequenos e iterativos, usando equipas reduzidas e focalizadas. **1.9.2.7 Objetivos Claros** Clareza e enfoque são essenciais para o sucesso dos projetos. No entanto, os pequenos projetos podem ter um pouco mais de ambiguidade e risco, em virtude de possuírem um ciclo de vida mais curto. Por outro lado, também não necessitam de ser tão estreitamente alinhados com a estratégia empresarial como os projetos de maiores dimensões, em virtude de terem muitas vezes um caráter algo experimental. **1.9.2.8 Maturidade Emocional** Maturidade emcional é ter as aptidões necessárias de autoconsciência, consciência social. autogestão e gestão de relacionamentos. Estas aptidões são fundamentais para uma pequena equipa de projeto e as respetivas partes interessadas; quando estão ausentes manifestam-se frequentemente como os \"cinco pecados capitais\" dos projetos de software como definidos no Chaos Knowledge Centre do *Standish Group:* ambição, arrogância, ignorância, fraudulência e não participação. A maturidade emocional começa e acaba com a gestão, não apenas dos resultados reais do projeto, mas igualmente dos resultados percecionados. **1.9.2.9 Execução Eficaz** A execução é o ato de realizar um projeto de acordo com um plano. Em geral, é mais fácil executar pequenos projetos do que projetos de grande dimensão. Torna-se ainda mais fácil quando se combinam pequenos projetos com uma gestão financeira e uma metodologia formal. Quando se adicionam aptidões de liderança e experiência em gestão de projetos ainda se torna mais fácil criar um resultado positivo. A ideia é que a equipa de projeto fornece orientação e promove o progresso do projeto. **1.9.2.10 Ferramentas e Infraestrutura** Quando se trata de ferramentas e infraestrutura para pequenos projetos, menos é mais. Poucas ferramentas de gestão de projeto e ainda menos opções de infraestrutura ajudam pequenos projetos a serem executados mais rapidamente, com menor custo e melhor qualidade. Um dos principais problemas com ferramentas é que as organizações se tornam dependentes e ficam escravas delas, ao invés de usarem o seu próprio discernimento e experiência. Isto conduz com frequência à desilusão. As ferramentas devem ajudar ao sucesso dos projetos, não tornarem-se um obstáculo. **1.9.3 A Curva do Esforço** Embora se tenham mencionado atrás os benefícios de uma gestão de projeto rigorosa, a sua prática não é fácil, nem isenta de problemas. As pressões do trabalho e os prazos aparentemente irrealistas, impostos muitas vezes, constituem uma forte tentação no sentido de se começar imediatamente o trabalho, sem despender o tempo necessário para o preparar. Quando a equipa de projeto e os gestores estão ansiosos para que o trabalho se inicie, é dificil para o gestor de projeto concentrar-se no desenvolvimento de um sólido plano de ação. Por vezes, parece que o nível de detalhe do plano é exagerado, embora não o seja. O gestor de projeto deve resistir à pressão de iniciar o trabalho, sem ter antes despendido algum tempo a desenvolver um plano detalhado. Tem sido demonstrado que um planeamento pobre tem um custo posterior no projeto, em termos de derrapagem dos prazos, qualidade baixa e expectativas não satisfeitas. A curva do esforço diz que o planeamento bem feito exige esforço no início, mas poupa esforços posteriores no ciclo de vida do projeto (Figura 1.5). Um gestor de projeto que não planeia expõe-se a esforços (e problemas) significativos após o início do projeto. Na realidade, o esforço e os problemas têm tendência para aumentar à medida que o projeto progride. ### **1.10 Papel e Responsabilidades do Gestor de Projeto** O papel do gestor de projeto evoluiu consideravelmente ao longo dos anos, integrando atualmente funções e responsabilidades que não eram do domínio da gestão de projetos há 10 anos. Neste ponto examinam-se os tipos de papéis que um gestor de projeto típico necessita d ser capaz de executar para ser um profissional credível, eficaz e bem-sucedido. Estes papéis dão origem a responsabilidades e conflitos que devem ser avaliados e resolvidos Uma dessas responsabilidades é o seu próprio desenvolvimento e melhoria permanentes Este ponto destina-se a dar algumas indicações sobre o tipo de aptidões profissionais que um moderno gestor de projeto tem de possuir. O gestor de projeto é responsável por coordenar e integrar atividades ao longo de linhas funcionais múltiplas. Para fazer isso, o gestor de projeto necessita de: - - - O papel do gestor de projeto não é fácil, tem frequentemente responsabilidades acrescidas, mas muito pouca autoridade, o que o força a negociar com a gestão de topo bem como com a gestão funcional, o controlo dos recursos do projeto. Embora a organização do projeto seja uma entidade especializada, orientada para a tarefa, não pode agir separadamente da estrutura tradicional da organização. Assim, o gestor de projeto tem de \"atravessar a barreira\" entre as duas organizações. O termo gestão das interfaces é muito utilizado para definir este papel, que pode ser descrito como a gestão das inter-relações: - - - - Para ser um bom gestor de projeto, um indivíduo [tem] de possuir um misto de aptidões técnicas e de gestão, em virtude de ser chamado a realizar uma variedade de funções e tarefas: **Alinhamento do projeto com o negócio**: - - - - - - **Planeamento do projeto:** - - - - - - - **Construção de parcerias com o cliente**: - - - - - - - **Gestão do projeto:** - - - - - - - - **Liderança da equipa de projeto**: - - - - -