PJMG quality Modelo de actividades da gestão de projectos de desenvolvimento de software no âmbito da qualidade

Transcrição

1 PJMG quality Modelo de actividades da gestão de projectos de desenvolvimento de software no âmbito da qualidade DULCE CRISTINA DOS SANTOS IRIA GONÇALVES Tese de Doutoramento Sob orientação do Professor Doutor João Eduardo Quintela Alves de Sousa Varajão e do Professor Doutor José Bulas Cruz Universidade de Trás-os-Montes e Alto Douro Departamento de Engenharias Vila Real, 2009

2

3 PJMG quality Modelo de actividades da gestão de projectos de desenvolvimento de software no âmbito da qualidade Tese de Doutoramento DULCE CRISTINA DOS SANTOS IRIA GONÇALVES Tese apresentada por Dulce Cristina dos Santos Iria Gonçalves à Universidade de Trás-os-Montes e Alto Douro para cumprimento dos requisitos necessários à obtenção do grau de Doutor em Informática, sob orientação do Professor Doutor João Eduardo Quintela Alves de Sousa Varajão, Professor Auxiliar do Departamento de Engenharias da Universidade de Trás-os-Montes e Alto Douro e do Professor Doutor José Bulas Cruz, Professor Catedrático do Departamento de Engenharias, da Universidade de Trás-os-Montes e Alto Douro. Universidade de Trás-os-Montes e Alto Douro Departamento de Engenharias Vila Real, 2009

4

5 Ao meu irmão Artur Aos meus filhos Beatriz, Francisco e Margarida são a luz da minha vida Ao meu marido Francisco a quem amo incondicionalmente

6 Ao meu marido a quem amo incondicionalmente.

7 Agradecimentos Desviando-me do formalismo que geralmente é seguido em teses e documentos formais de carácter científico, vou começar por agradecer à minha família. Sem a sua ajuda e paciência, este trabalho não teria sido humanamente possível. Os meus pais foram excepcionais no apoio que me deram, e na força que me transmitiram. A eles tudo devo, muito obrigada. Tentei sempre não retirar o tempo devido à minha família. Tentei, nestes anos, não privar os meus filhos da infância e de todas as actividades que lhe estão inerentes. Procurei não transferir as minhas preocupações e ansiedades para o meio familiar. Sei bem que muitas vezes não tive sucesso, principalmente nos últimos tempos. Obrigada ao meu marido e aos meus filhos. Desculpem as minhas angústias, falta de paciência e alguma indisponibilidade para vos ver crescer com a calma necessária que uma mãe deve ter e proporcionar. À Luciana e ao Henrique pelo apoio, compreensão e amizade. Não poderia deixar de agradecer profundamente ao Professor Doutor João Varajão de uma forma muito especial. Não só pela sua competência e capacidade como orientador, mas também como amigo. Ensinou-me a ser rigorosa. Aturou-me as impaciências, as frustrações, as reservas, os desapontamentos, as ansiedades, e a teimosia. E, com muita paciência, lutou contra o meu desânimo. Sem a sua preciosa ajuda e amizade seria impossível concluir este trabalho com sucesso. Ao Professor Doutor José Bulas Cruz, pelo apoio e empenho demonstrado e por ter acreditado neste projecto. Pela clarividência e assertividade das suas intervenções que muito ajudaram. VII

8 Ao Professor Doutor António Pereira por ter tornado possível a realização deste projecto, pelo apoio e pela ajuda prestada. Ao Professor Doutor João Barroso pelo empenho demonstrado. A todos os especialistas das empresas que contribuíram no estudo de casos e que disponibilizaram o seu tempo para participar neste trabalho, em particular a Manuel João Santos, a Joaquim de Matos, a Jorge Filipe, a Susana Oliveira, a Luís Coelho, a Nuno Cepeda, a Pedro Faúlha. À Márcia Catarino e ao João Pedro Pombo pelo trabalho e contributos fundamentais na realização desta tese. À Alda pelo apoio dado nas revisões do Inglês e pelas sugestões interessantes que forneceu. À Vanda, à Cristina e à Alda pelos momentos de boa disposição e amizade. Ao Instituto Politécnico de Leiria (IPL) e à Escola Superior de Tecnologia e Gestão (ESTG) de Leiria pelo apoio prestado. Ao Rui Rijo e ao Ricardo Martinho pela amizade, apoio e pelo ânimo que me transmitiram. Aos colegas do Departamento de Engenharia Informática da ESTG pelo espírito de grupo e incentivo ao longo desta caminhada, fundamentais para a conclusão do trabalho. Ao meu Psiquiatra Professor Doutor Francisco Alte da Veiga pela ajuda, apoio e motivação. A todos o meu profundo e sincero reconhecimento! Agradeço a Deus pelo Dom da Vida. VIII

9 Resumo As organizações encontram-se cada vez mais dependentes das tecnologias da informação para o seu funcionamento. Não obstante a importância reconhecida aos sistemas e tecnologias da informação e a atenção que desde há alguns anos a esta parte lhes tem sido dedicada, os resultados dos investimentos não têm correspondido às expectativas, revelando-se decepcionantes em muitos casos. Este facto marca a necessidade crescente de respostas mais eficazes por parte da gestão de projectos, específicas para as novas realidades dos projectos de desenvolvimento de software. Os gestores de projecto são pressionados a realizar projectos de software com qualidade, no tempo previsto e dentro do orçamento. Para além das competências tecnológicas, necessitam possuir as competências de gestão necessárias, ter o trabalho suportado por ferramentas adequadas, reger as suas funções por boas práticas e linhas orientadoras para a gestão correcta, e precisam efectuar um controlo rigoroso dos projectos de software. O crescente aumento da exigência por parte dos clientes dos projectos reforça a importância da qualidade, ao ponto de se tornar crucial à sobrevivência das organizações responsáveis pelo desenvolvimento de software e daquelas que o utilizam para competir no mercado. No contexto da qualidade em projectos de desenvolvimento de software, é importante considerar o processo de gestão que tem por finalidade assegurar que cada uma das fases de desenvolvimento do sistema e a interligação entre estas, são executadas correctamente. Apesar de existirem contributos valiosos que permitem um aperfeiçoamento da gestão de projectos e uma rentabilização do trabalho dos gestores, não existe um modelo de gestão de projectos estruturante no caso concreto da gestão da qualidade e com foco no responsável principal: o gestor de projectos. IX

10 Dada a sua relevância, a procura de soluções na área da gestão da qualidade na gestão de projectos para auxiliar a combater o insucesso de projectos de software tornou-se a finalidade principal do presente trabalho de investigação. Visando dar um contributo para uma maior eficácia das funções que o gestor de projectos deve executar, propomos um modelo de actividades para a gestão de projectos no âmbito da garantia de qualidade, resultante de análise documental, de um processo de entrevistas, respectiva análise da informação obtida, de um Survey e de um estudo Delphi. O modelo de actividades proposto é uma ferramenta de trabalho com o objectivo de optimizar o desempenho do gestor, potenciando a normalização e agilização das respectivas actividades, contribuindo para a garantia de qualidade do projecto e, consequentemente, para a satisfação do cliente. A presente tese procura, também, contribuir para o preenchimento da lacuna sentida relativamente à necessidade de um conhecimento mais abrangente da realidade da gestão de projectos em Portugal. X

11 Abstract Organizations depend more and more on the Information Technologies to work. In spite of the importance and attention given to the information systems and technologies, the results of the investments are not as good as expected and quiet deceptive in many cases. This fact marks the growing need for specific answers for the project management and for the new realities of software projects. The project managers are feeling more and more pressure when developing/achieving quality software projects because of the short time and budget offered. Besides technology skills, they should have management skills; their work should be supported by the adequate tools and should act according to good practises and principles/rules for a correct management. They also should supervise tightly the software projects. The growing of competitiveness and more and more demanding clients reinforce the importance of quality. That fact is crucial to maintain organizations responsible for software development projects working. Quality is also essential to the organizations which use the projects to compete in the market. When we talk about quality in software development projects, it s important to make sure, beyond the different stages of the development system and quality management, that the project management process used to assure that every stage and connection between them, is correctly performed. The project manager is responsible for these activities of quality management. Although there are valuable contributions that allow an improvement of project management and a return on the project managers work, there isn t a structured project management framework for quality management and project manager oriented. XI

12 Due to its relevance, the seeking of solutions in the quality management area, in the projects management, to fight the lack of success in software projects is the main goal of this investigation work. We intend to give a real contribution for the improvement of efficiency in the quality area which should be performed by the project manager. We propose a model of activities for the project management in quality scope. It is the result of documental analyses, of a process of interviews and their respective information analyses obtained, of a Survey and a Delphi study. The model of activities proposed is a working tool used in order to optimize the manager performance and help to normalise and to make easier the carrying out of the respective activities. Having that in mind the project quality and consequently the client satisfaction will be a reality. With this thesis we also try to contribute to reduce the lack of a more comprehensive knowledge of the reality of project management in Portugal. XII

13 Do livro dos Provérbios Feliz o homem que encontra a sabedoria, que adquiriu a inteligência, porque a sua aquisição vale mais que a prata, e os seus frutos são melhores que o ouro fino (Prov. 3, v13-14). Do livro da Sabedoria Resolvi tomar a sabedoria por companheira da minha vida, sabendo que ela será para mim uma boa conselheira (Sab. 8, v9). XIII

14

15 Índice de Conteúdo AGRADECIMENTOS RESUMO ABSTRACT ÍNDICE DE CONTEÚDO ÍNDICE DE FIGURAS ÍNDICE DE TABELAS ACRÓNIMOS VII IX XI XV XXI XXVII XXXI CAPÍTULO 1 INTRODUÇÃO CARACTERIZAÇÃO CONJUNTURAL MOTIVAÇÕES, OBJECTIVOS E CONTRIBUTOS FUNDAMENTAIS ORGANIZAÇÃO E ESTRUTURA DA DISSERTAÇÃO PARTE I - ESTADO DA ARTE 15 CAPÍTULO 2 PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE CONCEITO DE PROJECTO TIPOS DE DESENVOLVIMENTO DE SOFTWARE Projectos de desenvolvimento de software à medida Projectos de desenvolvimento de Commercial off-the-shelf software Sumário PARTICULARIDADES DOS PROJECTOS DE DESENVOLVIMENTO À MEDIDA Boas práticas do desenvolvimento à medida Aspectos e desafios do desenvolvimento de software à medida XV

16 2.4 PARTICULARIDADES DOS PROJECTOS DE DESENVOLVIMENTO BASEADO EM COMMERCIAL OFF-THE-SHELF SOFTWARE PROJECTOS DE DESENVOLVIMENTO HÍBRIDO DE SOFTWARE Dificuldades na implementação de um ERP Boas práticas na implementação de um ERP CAPÍTULO 3 GESTÃO DE PROJECTOS CONTEXTO HISTÓRICO TÉCNICAS E METODOLOGIAS DA GESTÃO DE PROJECTOS GESTÃO DE PROJECTOS NAS TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO CONCEITOS DA ÁREA DA GESTÃO DE PROJECTOS AS PRINCIPAIS ÁREAS DE CONHECIMENTO DA GESTÃO DE PROJECTOS Gestão do âmbito Gestão do tempo Gestão do custo Gestão da qualidade Gestão de recursos humanos Gestão da comunicação Gestão do risco Gestão de aquisições Gestão da integração CICLO DE VIDA DO PROJECTO DESENVOLVIMENTO DE PROJECTOS E DESENVOLVIMENTO DE SISTEMAS NOVAS ABORDAGENS E OPORTUNIDADES DE INVESTIGAÇÃO NA ÁREA DA GESTÃO DE PROJECTOS EVOLUÇÃO DA GESTÃO DE PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE CAPÍTULO 4 GESTÃO DA QUALIDADE CONCEITO DE QUALIDADE GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE Família ISO Modelo CMMI Termos relacionados com a qualidade XVI

17 CAPÍTULO 5 O GESTOR DE PROJECTOS CARACTERIZAÇÃO DO GESTOR DE PROJECTOS RESPONSABILIDADES COMPETÊNCIAS INTERACÇÕES PARTE II - CONTRIBUIÇÕES 121 CAPÍTULO 6 PROCESSO DE INVESTIGAÇÃO ABORDAGENS DE INVESTIGAÇÃO DESENHO DA INVESTIGAÇÃO DEFINIÇÃO DO PROBLEMA Concepção do projecto de investigação Estudo de casos Caracterização das empresas Recolha de informação Elaboração de entrevistas Realização de entrevistas Tratamento e organização dos dados Estudo Delphi Estudo Survey Finalização do projecto de investigação CAPÍTULO 7 CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS INTRODUÇÃO ESTUDO SURVEY Caracterização do estudo realizado Caracterização das empresas e dos respondentes Caracterização dos projectos realizados na empresa Processos gerais usados na gestão de projectos Gestão do Âmbito Gestão do Tempo Gestão do Custo Gestão da Qualidade Gestão dos Recursos Humanos Gestão da Comunicação Gestão do Risco XVII

18 Gestão de Aquisições Encerramento do projecto Ranking de actividades Sucesso de um projecto O gestor de projectos CAPÍTULO 8 MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE INTRODUÇÃO AO MODELO MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Fase de planeamento Fase de execução Fase de encerramento SÍNTESE DO MODELO ACTIVIDADES DETERMINANTES DE SUCESSO DA GESTÃO DA QUALIDADE Aplicação do método ao problema Condução do estudo Conclusão do estudo PARTE III - CONCLUSÃO 287 CAPÍTULO 9 CONSIDERAÇÕES FINAIS SÍNTESE DA TESE DISCUSSÃO DOS RESULTADOS E PRINCIPAIS CONTRIBUTOS Caracterização de projectos de desenvolvimento de software Revisão dos aspectos fundamentais da gestão de projectos Principais fundamentos da gestão da qualidade Caracterização do gestor de projectos Caracterização da realidade portuguesa da gestão de projectos Modelo de actividades do gestor de projectos no âmbito da qualidade LIMITAÇÕES DO TRABALHO REALIZADO DESENVOLVIMENTO SUBSEQUENTE E PROPOSTAS DE TRABALHO FUTURO Difusão de resultados Continuação do estudo de caracterização da realidade da gestão de projectos Aplicação prática do modelo XVIII

19 9.4.4 Adaptação do modelo Estudo do impacto ao nível do custo da aplicação prática do modelo CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS 307 ANEXO I: CARTAS CONVITE ÀS ORGANIZAÇÕES PARTICIPANTES 331 ANEXO II: PREPARAÇÃO DAS ENTREVISTAS 337 ANEXO III: TRANSCRIÇÃO DAS ENTREVISTAS DO PRIMEIRO CASO DE ESTUDO 339 ANEXO IV: TRANSCRIÇÃO DAS ENTREVISTAS DO SEGUNDO CASO DE ESTUDO 379 ANEXO V: ESTUDO DELPHI 393 ANEXO VI: QUESTIONÁRIO DA CARACTERIZAÇÃO DA GP EM GRANDES EMPRESAS PORTUGUESAS 397 XIX

20

21 Índice de Figuras Figura 1.1: Problema, tese e objectivos do trabalho Figura 1.2: Estrutura da tese Figura 2.1: Altura em que o utilizador/cliente e o developer estão identificados em cada um dos três tipos de desenvolvimento de software Figura 2.2: Desenvolvimento baseado em COTS, processo simplificado Figura 2.3: Diferenças entre o desenvolvimento convencional e o desenvolvimento baseado em COTS Figura 3.1: Framework de gestão de projectos Figura 3.2: Processos das áreas do conhecimento da gestão de projectos Figura 3.3: Sobreposição dos grupos de processos em cada fase do projecto Figura 3.4: Ligações entre os grupos de processos em cada fase do projecto Figura 3.5: Interacção entre fases do projecto Figura 4.1: Ciclo PDCA, de Deming ou de Melhoria Contínua Figura 4.2: Elementos chave do TQM Figura 4.3: Componentes da SQA Figura 4.4: Modelo de um sistema de gestão da qualidade baseado em processos Figura 4.5: Componentes do Modelo CMMI XXI

22 Figura 4.6: Níveis de Maturidade do Modelo CMMI Figura 5.1: Valores fundamentais para a abordagem da gestão de projectos Figura 5.2: Competências do gestor de projecto: the eye of competence Figura 6.1: Método de investigação baseado em etapas proposto por Bunge Figura 6.2: Projecto de investigação Figura 7.1: Número de projectos em que os gestores do survey participaram na empresa nos últimos três anos Figura 7.2: Duração dos projectos em que os gestores do survey participaram na empresa nos últimos três anos Figura 7.3: Orçamento médio dos projectos do survey nos últimos três anos Figura 7.4: Tipo de desenvolvimento verificado nos projectos do survey realizados nos últimos três anos Figura 7.5: Tipo de complexidade verificada nos projectos do survey realizados nos últimos três anos (top 5) Figura 7.6: Aspectos do sucesso de um projecto do survey (top 5) Figura 7.7: Aspectos do sucesso dos projectos do survey realizados nos últimos três anos Figura 7.8: Processos gerais usados na gestão de projectos (top 3) Figura 7.9: Ranking de processos gerais usados na gestão de projectos (top 3) Figura 7.10: Processos utilizados na gestão do âmbito (top 3) Figura 7.11: Ranking de processos utilizados na gestão do âmbito (top 3) Figura 7.12: Processos utilizados na gestão do tempo (top 3) Figura 7.13: Ranking de processos utilizados na gestão do tempo (top 3) Figura 7.14: Processos utilizados na gestão do custo (top 3) Figura 7.15: Ranking de processos utilizados na gestão do custo (top 3) Figura 7.16: Processos utilizados na gestão da qualidade (top 3) XXII

23 Figura 7.17: Ranking de processos utilizados na gestão da qualidade (top 3) Figura 7.18: Processos utilizados na gestão dos recursos humanos (top 3) Figura 7.19: Ranking de processos utilizados na gestão dos recursos humanos (top 3) Figura 7.20: Processos utilizados na gestão da comunicação (top 3) Figura 7.21: Ranking de processos utilizados na gestão da comunicação (top 3) Figura 7.22: Processos utilizados na gestão do risco (top 3) Figura 7.23: Ranking de processos utilizados na gestão do risco (top 3) Figura 7.24: Processos utilizados na gestão de aquisições (top 3) Figura 7.25: Ranking de processos utilizados na gestão de aquisições (top 3) Figura 7.26: Informação produzida aquando do encerramento do projecto (quando este é efectuado) Figura 7.27: Ranking de informação produzida aquando do encerramento do projecto (quando este é efectuado) Figura 7.28: Acções de manutenção do sistema desenvolvido (top 3) Figura 7.29: Ranking de acções de manutenção do sistema desenvolvido (top 3) Figura 7.30: Processos mais realizados na gestão de projectos (top 12) Figura 7.31: Processos menos realizados na gestão de projectos (top 12) Figura 7.32: Cenários na definição do sucesso de um projecto (top 5) Figura 7.33: Aspectos importantes no desenvolvimento bem sucedido de um projecto (top 5) Figura 7.34: Constrangimentos influenciadores do sucesso de um projecto (top 5) Figura 7.35: Actividades do gestor de projectos (top 5) Figura 7.36: Capacidades do gestor de projectos (top 5) Figura 8.1: Modelo de actividades da gestão de projectos no âmbito da qualidade XXIII

24 Figura 8.2: Diferença entre um planeamento tradicional e um planeamento baseado no paradigma testware Figura 8.3: Esquema do processo de definição de métricas Figura 8.4: Artefactos utilizados e produzidos para realização da actividade Definição do plano de métricas Figura 8.5: Artefactos utilizados e produzidos para realização da actividade Elaboração do plano de aceitação do cliente Figura 8.6: Artefactos utilizados e produzidos para realização da actividade Elaboração do plano de envolvimento do cliente Figura 8.7: Artefactos utilizados e produzidos para realização da actividade Definição do plano de gestão de alterações Figura 8.8: Artefactos utilizados e produzidos para realização da actividade Elaboração do plano de progresso Figura 8.9: Acções necessárias à recolha, análise e registo de métricas Figura 8.10: Artefactos utilizados e produzidos para realização da actividade Gestão de pedidos de alteração Figura 8.11: Artefactos utilizados e produzidos para realização da actividade Auditar o projecto de acordo com o plano de qualidade Figura 8.12: Artefactos utilizados e produzidos para realização da actividade Gestão de reclamações Figura 8.13: Processso de tratamento de uma não conformidade Figura 8.14: Artefactos utilizados e produzidos para realização da actividade Controlo do plano de aceitação Figura 8.15: Artefactos utilizados e produzidos para realização da actividade Reuniões de controlo de progresso Figura 8.16: Artefactos utilizados e produzidos para realização da actividade Produção de relatórios de progresso interno Figura 8.17: Artefactos utilizados e produzidos para realização da actividade Produção de relatórios para o cliente Figura 8.18: Artefactos utilizados e produzidos para realização da actividade Gestão de entregáveis XXIV

25 Figura 8.19: Artefactos utilizados e produzidos para realização da actividade Controlo da qualidade Figura 8.20: Artefactos utilizados e produzidos para realização da actividade Arquivar documentação Figura 8.21: Artefactos utilizados e produzidos para realização da actividade Produção de relatório final de projecto Figura 8.22: Artefactos utilizados e produzidos para realização da actividade Elaboração do inquérito final de satisfação do cliente Figura 8.23: Artefactos utilizados e produzidos para realização da actividade Sistematizar e enriquecer base de conhecimento Figura 8.24: Enquadramento do modelo de actividades da gestão de projectos no âmbito da qualidade Figura 8.25: Actividades fundamentais no âmbito da gestão da qualidade Figura V.1: Quadro Q-Sort para uma lista de 32 questões XXV

26

27 Índice de Tabelas Tabela 2.1: Problemas/Características relacionadas com os três tipos de desenvolvimento Tabela 2.2: Diferenças relevantes entre desenvolvimento à medida e package software Tabela 2.3: Sumário das boas práticas do desenvolvimento de software à medida Tabela 2.4: Recomendações de best practices (boas práticas) para o sucesso em implantação de sistemas ERP Tabela 3.1: Taxa de sucesso de projectos de tecnologias de informação e comunicação Tabela 4.1: Catorze princípios para a gestão da qualidade propostos por Deming Tabela 4.2: Diferenças entre Garantia da Qualidade e Controlo da Qualidade Tabela 5.1: Características pessoais e interpessoais do gestor de projectos Tabela 5.2: Competências gerais do gestor de projecto Tabela 5.3: Interacções principais do gestor de projectos com os diferentes tipos de actores do projecto (stakeholders) Tabela 6.1: Sumário do tipo de problema, área da ciência e métodos utilizados em Engenharia do software Tabela 6.2: Actividades antecedentes e complementares ao projecto de investigação XXVII

28 Tabela 6.3: Quadro com os especialistas entrevistados no estudo de caso Novabase Tabela 6.4: Quadro com os especialistas entrevistados no estudo de caso ADP Portugal Tabela 8.1: Actividades do modelo PJMG quality Tabela 8.2: Lista de actividades executadas na fase de planeamento e respectivos deliverables produzidos Tabela 8.3: Estrutura típica de uma proposta do plano de projecto Tabela 8.4: Exemplo da descrição de dois planos de contingência Tabela 8.5: Aspectos críticos versus características da solução proposta Tabela 8.6: Estrutura do plano de testes baseado na Norma IEEE Tabela 8.7: Estrutura do plano de qualidade Tabela 8.8: Métricas definidas para o objectivo indicado no item três Tabela 8.9: Exemplo de uma matriz de produtos gerados versus responsáveis Tabela 8.10: Exemplo de uma matriz de actividades versus entidades responsáveis Tabela 8.11: Apresentação de um resumo da reunião de kick-off Tabela 8.12: Proposta da estrutura para o plano de gestão de alterações Tabela 8.13: Lista de actividades executadas na fase de planeamento e respectivos deliverables produzidos Tabela 8.14: Tipos de não conformidades que podem ocorrer Tabela 8.15 Método 5W2H Tabela 8.16: Exemplo de uma lista de work packages analisada numa reunião de progresso Tabela 8.17: Exemplo de uma lista de milestones analisada numa reunião de progresso Tabela 8.18: Exemplo de uma lista de entregáveis analisada numa reunião de progresso Tabela 8.19: Exemplo de uma lista de acções tratada numa reunião de progresso XXVIII

29 Tabela 8.20: Lista de actividades determinantes da gestão de projectos no âmbito da qualidade Tabela 8.21: Lista ordenada das actividades determinantes de sucesso no âmbito da qualidade Tabela 9.1: Síntese de contributos do projecto de investigação XXIX

30

31 Acrónimos Nesta tese são utilizadas abreviaturas de designações comuns apenas apresentadas aquando da sua primeira utilização: BPM CMMI Business Process Modeling Capability Maturity Model Integration COTS Commercial Off-The-Shelf Software CRM EI ERP ES GP Customer Relationship Management Engenharia Informática Enterprise Resource Planning Engenharia do Software Gestão de Projectos PMBoK Project Management Body of Knowledge PMI PMP RAD RH RUP SBC SCM SGQ SI SPM SQA TI TIC TQM Project Management Institute Project Management Professional Rapid Application Development Recursos Humanos Rational Unified Process Sistema baseado em COTS Software Configuration Management Sistema de Gestão de Qualidade Sistemas de Informação Software Project Management Software Quality Assurance Tecnologias de Informação Tecnologias de Informação e Comunicação Total Quality Management XXXI

32

33

34

35 Capítulo 1 Introdução Os dias prósperos não vêm por acaso. São granjeados, como as searas, com muita fadiga e com muitos intervalos de desalento. Camilo Castelo Branco O primeiro capítulo apresenta o contexto do trabalho realizado, refere as principais questões que motivaram a realização deste trabalho, e os objectivos do projecto. O problema de investigação e as questões de investigação são definidos, e as contribuições esperadas são apresentadas. O capítulo também inclui uma breve discussão sobre a metodologia de pesquisa, e termina com uma panorâmica da estrutura da tese. The first chapter presents the context work, the motivations and the project s objectives. The problem investigation, the research questions and the expected contributions are stated. This chapter includes a brief discussion of research methodology. It is also a structure thesis overview. A Gestão de Projectos (GP), entendida como o conjunto de actividades que visa a optimização de um projecto, é hoje, mais do que nunca, crucial para o sucesso de qualquer projecto de uma organização. Se é um facto que nem sempre houve a capacidade de reconhecer a importância da gestão de projectos para a sobrevivência e desenvolvimento das organizações, também é verdade actualmente haver uma preocupação crescente em dotá-las de Sistemas de Informação (SI) adequados para o suporte de todas as suas actividades (Varajão, 2002). Assim, a gestão de projectos tem sido uma área cada vez mais valorizada por ser crucial para o sucesso de projectos (Schmidt, Lyytinen, Keil, & Cule, 2001). O grau de complexidade da sociedade, das instituições e das organizações actuais impõe o recurso a sistemas informáticos. Do bom funcionamento desses sistemas e respectivo sucesso, depende a qualidade de vida dos cidadãos, o sucesso e a viabilidade das organizações. O papel dos sistemas de informação é crescentemente crítico e cada vez mais incontornável. [PJMG quality, 1]

36 CAPÍTULO UM - INTRODUÇÃO Muitas organizações têm hoje a clara percepção que o desenvolvimento de software é uma actividade crítica para os seus negócios, tanto do ponto de vista da inovação como da própria sustentabilidade do negócio, não podendo portanto, ser admissível que as iniciativas de desenvolvimento de software sejam realizadas sem qualidade. Grande parte das organizações mundiais depende das novas tecnologias e de Sistemas de Informação (SI), sendo estes elementos para aumentar a eficiência do negócio, aproveitar oportunidades e ganhar vantagens competitivas (Albertin, 2001; Kenneth C Laudon & Laudon, 2006). Em suma, podemos afirmar que os SI fazem parte de um conjunto de instrumentos que os gestores podem usar para melhorar a tomada de decisão, melhorar o desempenho organizacional e aumentar o lucro da empresa. Não obstante os cuidados que nos últimos anos têm sido dedicados às Tecnologias de Informação (TI), os projectos de desenvolvimento de software, continuam a falhar em demasiados casos (Varajão, Cardoso, Gonçalves, & Cruz, 2008) Neste contexto, a gestão de projectos de desenvolvimento de software procura minimizar estas falhas, assumindo a função de coordenar a acção dos recursos, propiciar a execução de processos de uma forma estruturada, tendo como objectivo alcançar qualidade do software criado. Os problemas com os projectos de desenvolvimento de software são observáveis desde há já várias décadas, e fragilizam o exercício da actividade da gestão de projectos, exigindo-se assim novos esforços de investigação na procura de contributos para a sua resolução (Varajão, 2002). Defende-se nesta tese a necessidade e possibilidade de se encontrarem soluções no âmbito da Qualidade para combater o insucesso da GP de desenvolvimento de software nas organizações. Acreditamos que uma das causas do insucesso recorrente está na função do gestor de projectos e na qualidade com que desempenha as suas actividades. Para poder assegurar que o projecto se desenvolve na direcção certa precisa de uma visão de conjunto. Tendo por referência estas convicções, propomos nesta tese um novo modelo de actividades, na área da Gestão da Qualidade, para a Gestão de Projectos. Nas secções seguintes é contextualizado o trabalho, apresentadas as motivações e objectivos da investigação e a organização e estrutura da tese. [PJMG quality, 2]

37 CARACTERIZAÇÃO CONJUNTURAL 1.1 CARACTERIZAÇÃO CONJUNTURAL As organizações humanas apresentam-se hoje como entidades nas quais a informação representa um papel activo e fulcral para a sua continuidade e desenvolvimento no espaço de uma sociedade cada vez mais global, marcada por grande dinamismo e mutabilidade. Mutabilidade essa que se dá a todos os níveis, fruto de uma evolução radical de valores, saberes e percepções do mundo, em que é particularmente assinalável a influência de um conjunto de efeitos e tendências associadas à aceleração do progresso científico e tecnológico no domínio da informação (Varajão, 2005). A gestão das TIC e a implementação de projectos de TIC desempenham um papel fundamental como factor competitivo. Aliás, o sucesso dos negócios é, em larga medida, determinado pela eficácia com que as TIC são utilizadas. Observa-se, deste modo, um contínuo e forte investimento em TIC por parte das organizações, ao longo das últimas décadas. Por exemplo, na década de noventa, nos Estados Unidos, o investimento em computadores e equipamento de comunicações ultrapassou o investimento em equipamento industrial (Lefebvre & Lefebvre, 1996). Apesar das TIC constituírem instrumentos poderosos e imprescindíveis para a sobrevivência e evolução de uma grande maioria das organizações, a simples adopção de TIC não é garante da obtenção de resultados positivos ou de vantagens competitivas (Varajão, 2002). Apesar de ser um tema de acesa discussão (Crafts, 2002; Triplett, 1999), tem sido difícil estabelecer uma relação directa entre a adopção de TIC e a obtenção de rendimento, dependendo a concretização deste último do modo como são utilizadas as tecnologias disponíveis. À medida que todas as organizações têm acesso à mesma base tecnológica, grande parte do seu impacto será resultado de uma gestão e utilização criativa. Se a sua utilização originasse automaticamente vantagens competitivas, dado que estas últimas advêm de se fazer algo que outros não conseguem igualar, não seriam na verdade factores de diferenciação (Varajão, 2002, 2005). É neste contexto que a correcta concepção e implementação de projectos de TIC tem um papel particulamente decisivo. As TIC, em permanente e rápida evolução, tornaram-se determinantes para a condução e posicionamento competitivo de praticamente qualquer organização, transformando definitivamente a sua realidade e a própria essência dos [PJMG quality, 3]

38 CAPÍTULO UM - INTRODUÇÃO negócios. Perante o seu grande potencial, as organizações lideram o desenvolvimento e aplicação das TI, quer através da optimização do seu funcionamento interno, quer induzindo alterações a nível do seu negócio, capitalizando os desenvolvimentos das TI para se tornarem mais dinâmicas e com maior capacidade de inovação em resposta à mudança dos mercados. Este esforço manifesta-se no peso e na taxa de crescimento que os investimentos em SI têm na estrutura de custos das organizações modernas. As TI são o alicerce da organização contemporânea. Actualmente é quase impossível conceptualizar uma organização que não use TI, não sendo exagerado afirmar que os efeitos das TI têm sido (e certamente continuarão a ser) profundos na realidade das organizações (Hirschheim, 1998), quer do ponto de vista da incorporação destas tecnologias na cadeia de valor da empresa, quer do ponto de vista da constituição de vantagens competitivas. O problema da elevada frequência de insucessos no desenvolvimento de software, existe desde os primórdios da revolução computacional e provavelmente persistirá no futuro (Brooks, 1987). Como referido por Varajão (Varajão, 2002) em 1995, Ward (Ward, 1995) indicava que apenas escassos 30% do total dos investimentos efectuados em sistemas e tecnologias de informação correspondiam aos resultados esperados. Dois anos mais tarde, Strassman (Strassmann, 1997) asseverava que 31% dos projectos informáticos são cancelados e 53% ultrapassam os orçamentos e os tempos planeados. Um relatório 1 do Standish Group (Kind& Fergunson, 1997) revelava que: Cerca de um terço dos projectos de tecnologias de informação são cancelados antes de serem concluídos; Cerca de metade dos orçamentos de projectos excedem em 189% as estimativas iniciais; Os atrasos médios dos projectos que enfrentam dificuldades são de 222%; Em média, o produto final contém apenas 61% das funcionalidades originalmente especificadas. Passados três anos, o Software Engineering Institute (EUA) e a empresa Computers & Concepts Associates (CCA, 1998; SEI, 2000), afirmavam que demasiados projectos tornam-se excessivamente onerosos e incapazes de fornecer a qualidade, fiabilidade e capacidade necessárias dentro dos prazos previstos. Segundo dados do Standish Group, em 1994 apenas 16% dos projectos de TIC/SI atingiam um estado de sucesso contra 31% de projectos falhados e 53% em estado de desafio (challanged). O estado de desafio significa que à data 1 Charting the Seas of Technology: The CHAOS Study. [PJMG quality, 4]

39 CARACTERIZAÇÃO CONJUNTURAL estes projectos ultrapassavam o tempo e orçamento previstos ou estavam subespecificados (Schwalbe, 2002). Apesar de uma melhoria significativa em 2006, havendo um total de 35% de projectos bem sucedidos, 19% a falhar e 46% em estado de desafio, há ainda um longo caminho a percorrer de modo a que a maioria dos projectos atinja um estado de sucesso. Os problemas são conhecidos: desvios orçamentais significativos, incumprimento de prazos e deficiências de desempenho. Estes problemas surgem de um modo geral da incapacidade de gestão e não de dificuldades técnicas, sendo esta a raiz de muitos dos problemas que afectam a aquisição de sistemas, o que se agrava com o aumento crescente da sua complexidade e custo (Varajão, 2002). Esta realidade tem implicações muito sérias, principalmente porque os investimentos em TI são muitas vezes significativos, com implicações a longo prazo. Apesar das TI constituírem reconhecidamente instrumentos poderosos e imprescindíveis para a sobrevivência e evolução de virtualmente qualquer organização, a simples adopção de TI não é garante da obtenção de resultados positivos ou de vantagens competitivas, não havendo uma relação directa entre a sua adopção e a obtenção de retorno, dependendo a concretização deste último do modo como são utilizadas as tecnologias disponíveis (F. Li, 1995; Strassmann, 1997). Na década de 1960, uma nova profissão preocupada essencialmente com os sistemas informáticos, olhou para as outras profissões na procura de guias e modelos para ajudar a formalizar e estabelecer melhores práticas. Dada a importância da engenharia de hardware no início da computação, muitos dos modelos iniciais para o desenvolvimento e gestão de projectos em TI foram baseados na engenharia e, numa extensão menor, na construção civil. Por exemplo, o sistema clássico de metodologias de desenvolvimento de sistemas foi baseado directamente nos ciclos de desenvolvimento de produtos da construção e da engenharia. Os primeiros modelos formais de gestão de projectos em TI também reflectiam aqueles desenvolvidos na Defesa e nas indústrias de construção. As organizações vivem hoje uma época de conhecimento e inovação (Porter, 2007). A abertura de novos mercados comerciais fruto da globalização, e os avanços tecnológicos das últimas décadas originaram um ambiente no qual as organizações de tecnologias de informação são forçadas a procurar novos processos, que lhes permitam ultrapassar os actuais limites de actuação. Procuram também activamente novas opções para a redução de custos, enquanto que, simultaneamente, tentam competir mais eficazmente nos seus mercados. [PJMG quality, 5]

40 CAPÍTULO UM - INTRODUÇÃO No ambiente económico e tecnológico actual, as transformações no mercado são constantes, pelo que as organizações que procuram o sucesso têm que estar preparadas para enfrentar grandes desafios e conseguirem aproveitar novas oportunidades de negócio. As organizações que se dedicam à produção de software, também, são influenciadas pela globalização dos mercados; e tal como as outras, precisam de encontrar o caminho para melhorarem os seus produtos. As organizações que fazem do software o seu negócio e que desejem destacarse, têm que dirigir as suas acções para a alteração da gestão do desenvolvimento dos seus produtos, a fim de se tornarem capazes de produzir software de elevada qualidade, com custos competitivos. É expectável que, com o decorrer do tempo, os gestores de projectos de software adquiram mais conhecimentos, que lhes permita compreenderem melhor as complexidades da tecnologia e, consequentemente, reduzir substancialmente a incidência de erros no software (Ewusi-Mensah, 2003). No entanto, é preciso fazer algo mais para compreender os problemas da gestão de projectos de software e procurar ultrapassá-los. A prática de uma metodologia bem sucedida de gestão de projectos de software torna-se, não somente necessária, como imprescindível às organizações de hoje. A gestão pela qualidade pode determinar o sucesso de um projecto de desenvolvimento de software, agregando valor ao negócio da organização. Em última instância, uma gestão de projectos proactiva e dinâmica pode transformar uma organização, proporcionar potenciais benefícios e torná-la, de facto, competitiva e bem sucedida. 1.2 MOTIVAÇÕES, OBJECTIVOS E CONTRIBUTOS FUNDAMENTAIS A área de trabalho desta tese foi motivada pela experiência adquirida ao longo de vários anos de trabalho efectuado em concepção e desenvolvimento de projectos de software e de problemas de investigação ainda em aberto identificados durante a revisão da literatura nas áreas de SI, desenvolvimento de projectos e gestão de projectos. Pressman (2000) refere diversas causas para o insucesso dos projectos e sistemas de informação: Falta de empenho da gestão de topo; Falta de comprometimento e empenho dos utilizadores; [PJMG quality, 6]

41 MOTIVAÇÕES, OBJECTIVOS E CONTRIBUTOS FUNDAMENTAIS Incompreensão do valor dos sistemas de informação; Falta de entendimento e sintonia entre informáticos e clientes utilizadores do sistema, no âmbito e requisitos do mesmo; Deficiências várias no processo de desenvolvimento; Falhas na coordenação do projecto, nomeadamente ao nível da definição dos objectivos e prioridades e da elaboração de estimativas; Falta de qualidade e inadequação dos recursos envolvidos; Mudanças frequentes dos requisitos do negócio e incapacidade de lidar com esta situação; Dificuldades de integração de componentes; Qualidade e desempenho do software deficiente, muito relacionados com problemas ao nível do controlo de qualidade; Incapacidade de identificar e controlar os riscos do projecto. De acordo com estudos efectuados (Demarco, 1997; Ewusi-Mensah, 2003; Jones, 2004; Kappelman, McKeeman, & Zhang, 2006; Standish Group, 1996, 1998; Yetton, Martin, Sharma, & Johnston, 2000), alguns dos principais aspectos que aumentam a probabilidade de falhas dos projectos de TIC são: Falta de especificação e visão clara dos requisitos; Expectativas irrealistas devido à má estimativa e a constrangimentos políticos nas organizações; Falta de decomposição do projecto, ou seja, o nível de detalhe em que o projecto é decomposto não é o suficiente para se realizar uma boa estimativa de âmbito, duração, recursos necessários e custos associados; Má gestão de Recursos Humanos (RH) e de conflitos; Falta de apoio e de foco no projecto por parte dos actores do projecto; Falta de foco estratégico e de apoio da gestão de topo. O facto do insucesso dos projectos de TIC ser ainda significativo e o facto de se conseguirem identificar aspectos chave como causas das suas falhas levam a [PJMG quality, 7]

42 CAPÍTULO UM - INTRODUÇÃO que a investigação prossiga na procura de metodologias, frameworks, métodos, técnicas e ferramentas com vista a melhorar o desenho, a implementação e, em última instância, o sucesso dos projectos, com o objectivo de dar resposta às necessidades particulares e específicas da GP de projectos em TIC. Inquestionavelmente, a complexidade das organizações está a aumentar, requerendo SI igualmente mais complexos para a satisfação das suas necessidades de informação. Esta situação introduz um grau adicional de complexidade na prática da GP. Cada organização necessita de lidar com diferentes problemas, envolvendo diferentes profissionais (com experiência e formação diferentes), utilizando métodos e técnicas distintos, recorrendo a diferentes fornecedores para obter os serviços que necessita, etc. Consequentemente, o exercício da GP está a tornar-se mais difícil, o que não só resulta da complexidade das organizações, como também de outros problemas, como o facto da GP muitas vezes não ser compreendida pela gestão, as diferentes vias para a obtenção de serviços não serem devidamente consideradas e as técnicas e ferramentas serem focalizadas em determinados aspectos sem considerar a sua integração com outras técnicas e ferramentas (Varajão, 2002). No que diz respeito à GP, e face ao insucesso dos projectos em TIC ser ainda significativo (Standish Group, 2004a), têm existido vários esforços em várias frentes para combatê-lo, conseguindo-se identificar aspectos chave como causas das suas falhas, que levam a que a investigação prossiga na procura de metodologias, métodos, técnicas e ferramentas com vista a melhorar a concepção, a construção, a implementação, e o decorrente sucesso dos projectos, com o objectivo de dar resposta às necessidades particulares e específicas da GP em TIC. O crescente aumento de competitividade e exigência do cliente reforça a importância da qualidade, ao ponto de se tornar vital à sobrevivência das organizações responsáveis pelo desenvolvimento de sistemas de informação (SI) e daquelas que os utilizam para competir no mercado. Já no início da década de 1990, Yourdon (1992) colocava algumas questões: Porque é que poucas organizações adoptam a qualidade de forma consistente? Porque será que algumas nem sequer a adoptam? Conscientes desta realidade e concentrados em procurar causas do insucesso da gestão de projectos de TI e desenvolvimento de software nas organizações, de modo a ser possível a apresentação de soluções válidas para este problema, focamos inicialmente o nosso projecto de investigação no estudo dos diferen- [PJMG quality, 8]

43 MOTIVAÇÕES, OBJECTIVOS E CONTRIBUTOS FUNDAMENTAIS tes tipos de desenvolvimento de software, procurando identificar princípios e práticas que permitissem estabelecer um conjunto de orientações úteis para o exercício da GP. Mais concretamente, estávamos preocupados em desenvolver uma reflexão profunda dos diversos aspectos que caracterizam o âmbito do desenvolvimento de software, tendo sempre presente que só é possível gerir aquilo que se conhece, identificar o que a GP necessita de conhecer sobre o desenvolvimento de software, de forma a conduzir a sua actividade de acordo com o interesse e as necessidades da organização. Apesar de a normalização na gestão de projectos de software reduzir a probabilidade de insucesso, temos que ter em consideração que esta não garante o sucesso do projecto. O gestor do projecto assume um papel muito importante na gestão de projectos. Sem um bom gestor muito dificilmente um projecto é bem sucedido. Acreditando que uma das fontes do problema reside no trabalho de Gestor de Projecto, propomos desenvolver um modelo de actividades na área da qualidade que identifica as actividades e aspectos críticos do seu desempenho. Propomo-nos ainda identificar os aspectos determinantes da actividade do Gestor, no que concerne ao controlo e garantia de Qualidade. Esse esforço foi desenvolvido com vista à criação e desenvolvimento de um novo modelo que contribuísse para a melhoria da gestão da realidade complexa da GP, focando o nosso trabalho nas actividades da gestão da qualidade. Assim, como se pode ver na Figura 1.1, identificou-se como um problema da GP a inexistência de um modelo de suporte para as actividades do gestor de projectos de desenvolvimento de software focado na área da qualidade, o que é condicionador do sucesso dos projectos. A procura de uma solução para este problema tornou-se finalidade deste projecto, formulando-se como principal tese, a necessidade da criação de um modelo de actividades da gestão da qualidade para o gestor de projectos de desenvolvimento de software com vista a optimizar o seu trabalho no âmbito da Qualidade. [PJMG quality, 9]

44 CAPÍTULO UM - INTRODUÇÃO Figura 1.1: Problema, tese e objectivos do trabalho De acordo com a finalidade de proposta, é possível formular um conjunto de objectivos específicos cos que traduzem as grandes motivações do projecto, bem como os principais contributos desses objectivos, que se descrevem de seguia revisão dos da. Para cumprir os objectivos estabelecidos, torna-se necessária fundamentos e da literatura sobre os diferentes tipos de desenvolvimento de software,, a gestão de projectos e a actividade do gestor de projectos de desen- volvimento de software. Assim, nesta tese, apresentam-se os conceitos e abor- dagens principais pais da Gestão da Qualidade. Focam-se os aspectos relevantes e as respectivas limitações desta temática. Como resultados desta revisão, foi efectuada a descrição e sistematização de alguns dos aspectos mais importan- tes da gestão de projectos e da profissão de gestor de projectos. O presente trabalho oferece uma revisão dos fundamentos e principais conceitos da ges- tão de projectos e um contributo sobre a forma como nos dias de hoje a GP deve ser encarada. O segundo objectivo é caracterizar a realidade da gestão de projectos em grandes empresas portuguesas; a concretização deste objectivo foi alcançada [PJMG quality, 10]

45 ORGANIZAÇÃO E ESTRUTURA DA DISSERTAÇÃO com a realização de um questionário online dirigido a gestores de projectos das maiores empresas portuguesas em termos de facturação. O terceiro objectivo é identificar e caracterizar as actividades fundamentais da função do gestor de projectos no âmbito da garantia de qualidade; o principal contributo deste objectivo é a proposta do modelo de actividades determinantes do gestor de projecto no âmbito da garantia de qualidade, contribuindo para a optimização do seu trabalho. Este é o objectivo central da presente tese. Finalmente, o quarto objectivo é a identificação das actividades determinantes na área da GP de modo a permitir optimizar os esforços de gestão. 1.3 ORGANIZAÇÃO E ESTRUTURA DA DISSERTAÇÃO Esta secção apresenta sucintamente a organização e conteúdo do presente trabalho. A estrutura definida materializa uma abordagem gradual no estudo da GP, traduzindo o curso dos trabalhos desenvolvidos no cumprimento dos objectivos definidos para o projecto. Os capítulos estão organizados de modo a permitir uma compreensão progressiva, seguindo um fio condutor, desde um conjunto de reflexões iniciais até uma série de expectativas futuras e considerações finais. O presente capítulo, introdutório, procura sintetizar todo o projecto. A descrição da organização da tese, aqui a ser apresentada, encerra o capítulo inicial. A tese está organizada em três partes e nove capítulos conforme ilustrado na Figura 1.2. [PJMG quality, 11]

46 CAPÍTULO UM - INTRODUÇÃO Figura 1.2: Estrutura da tese Primeira parte: Estado da Arte A primeira parte caracteriza globalmente, os diferentes tipos de projectos de desenvolvimento de software, salienta a importância da gestão de projectos no seu desenvolvimento, aborda a Gestão da Qualidade em projectos de desenvolvimento de software e efectua a caracterização da função do gestor de projectos através da descrição das suas responsabilidades e competências. É composta pelos capítulos dois, três, quatro e cinco. No segundo capítulo, Projectos de desenvolvimento de software, efectua-se a caracterização dos dois principais tipos de desenvolvimento de projectos de software. É apresentado um resumo comparativo das principais características que lhes são inerentes. No terceiro capítulo é apresentada uma panorâmica da Gestão de Projectos, principais técnicas e ferramentas utilizadas. São revistos alguns conceitos fundamentais de modo a propiciar uma base sólida para o estudo e prática da GP e facilitar o entendimento do trabalho apresentado nos capítulos seguintes. No quarto capítulo é abordada a Gestão da Qualidade em Projectos de desenvolvimento de software. Apresentam-se os conceitos fundamentais e aborda- [PJMG quality, 12]

47 ORGANIZAÇÃO E ESTRUTURA DA DISSERTAÇÃO gens principais desta temática, focam-se os aspectos relevantes e as respectivas limitações. É definida a qualidade e respectivas actividades que a compõem. São definidos os elementos chave da abordagem Total Quality Management. São detalhadas as normas e referenciais dos sistemas de gestão da qualidade. Sendo o gestor de projectos o actor principal deste trabalho, no quinto capítulo é apresentada a caracterização da função do gestor de projectos através da descrição das suas responsabilidades e competências. São ainda focadas as interacções do gestor com os outros intervenientes de um projecto. Segunda parte: Contribuições Na segunda parte são salientados os factores motivadores do trabalho realizado, caracterizado o problema para cuja resolução se pretende contribuir, identificadas as finalidades e os objectivos definidos, e genericamente sintetizados os contributos do trabalho desenvolvido. O objectivo central da segunda parte da tese é a apresentação detalhada do modelo de actividades do gestor de projectos no âmbito da gestão da qualidade. É composta por três capítulos: seis, sete e oito. O sexto capítulo proporciona uma breve revisão de abordagens e estratégias de investigação empírica no campo da engenharia de software. É apresentado e descrito o processo de investigação e os respectivos instrumentos utilizados no desenvolvimento do trabalho. É ainda efectuada a descrição do processo de recolha, de tratamento e análise de dados. No sétimo capítulo é apresentada a caracterização da realidade da gestão de projectos em Portugal nas grandes empresas. É explanado o estudo efectuado e os resultados obtidos. No capítulo oitavo, momento fulcral da tese, surge a proposta do modelo de actividades do gestor de projectos no âmbito da garantia de qualidade. É detalhado o modelo construído com base na análise dos resultados. São identificadas as actividades fundamentais do gestor e apresentada uma lista ordenada das actividades determinantes. [PJMG quality, 13]

48 CAPÍTULO UM - INTRODUÇÃO Terceira parte: Conclusão A terceira e última parte fornece uma generalização de tudo o que foi apresentado nos capítulos precedentes. Nesta, são tecidas as conclusões e contributos do trabalho, registadas as referências e apresentados os anexos. O capítulo nono, fornece uma generalização de tudo o que foi desenvolvido nos capítulos precedentes, através da discussão dos resultados obtidos e dos principais contributos para o desenvolvimento da área de GP. Termina com diversas reflexões sobre a continuidade desejada para o estudo e com uma série de considerações finais. Os anexos apresentam alguns dados que, pela sua importância para a compreensão do trabalho desenvolvido, não poderiam ser omissos, mas todavia, dado o nível de detalhe, não fazia sentido colocá-los no corpo da tese. É o caso das cartas-convite às organizações participantes do estudo de casos (Anexo I), da preparação do processo das entrevistas (Anexo II). A respectiva transcrição das entrevistas das duas organizações participantes (Anexos III e IV). Constam também dos anexos alguns dados detalhados do estudo Delphi (Anexo V) e o questionário do estudo da caracterização da gestão de projectos em grandes empresas portuguesas (Anexo VI). Terminada a apresentação da organização da tese, no próximo capítulo, capítulo dois, são caracterizados os diferentes tipos de projectos de desenvolvimento de software, com o objectivo de propiciar uma base sólida para o entendimento do trabalho desenvolvido nos capítulos seguintes. [PJMG quality, 14]

49 Primeira Parte ESTADO DA ARTE O objectivo da primeira parte é realizar a caracterização do estado da arte. É constituída por quatro capítulos. No capítulo dois, Projectos de desenvolvimento de software, são apresentados os diferentes tipos de projectos de desenvolvimento de software efectuando-se também um resumo comparativo das suas diferentes características. No capítulo três, Gestão de Projectos, é apresentado uma panorâmica da Gestão de Projectos, principais técnicas e ferramentas utilizadas. No quarto capítulo, Gestão da Qualidade, é abordada a Gestão da Qualidade em projectos de desenvolvimento de software. Apresentam-se os conceitos e abordagens principais desta temática, focam-se os aspectos relevantes e as respectivas limitações (apresentação de normas). No quinto capítulo, O gestor de projectos, efectua-se a caracterização da função do gestor de projectos através da descrição das suas responsabilidades e competências. Focam-se ainda as interacções do gestor com os outros intervenientes de um projecto. [PJMG quality, 15]

50

51 First Part STATE OF THE ART The purpose of the first part is to carry out a description of the state of the art. It is divided into four chapters. The second chapter the software development projects gives us different types of the projects and a brief summary of their different characteristics. The third chapter Project management provides an overview of project management, main techniques and tools used. The fourth chapter presents the quality management in software development projects; it gives the concepts and the main approaches of this topic. It also shows the aspects which are relevant and the respective limitations. The fifth draws a characterization of the function of the project management through the description of his responsibilities and skills. It also refers the managers interactions with other intervenients of a project. [PJMG quality, 17]

52

53 Capítulo 2 Projectos de desenvolvimento de software O único lugar onde o sucesso vem antes do trabalho é no dicionário. Albert Einstein O objectivo deste capítulo é efectuar a caracterização dos principais tipos de desenvolvimento de projectos de software. Apresenta-se também um resumo comparativo das principais características que lhes são inerentes. This chapter goal is the characterization of the main types of software development projects. It also presents a comparative summary of its main features. 2.1 CONCEITO DE PROJECTO Antes de se iniciar a caracterização dos tipos de desenvolvimento de software são apresentadas algumas definições de projecto. Um projecto é: Um esforço complexo, destinado a atingir um objectivo específico, dentro de determinado prazo e orçamento, o qual tem normalmente uma natureza multifuncional, é único e não repetitivo dentro da Organização Cleland & King (1983) Um empreendimento criador de mudança; limitado no tempo e em âmbito; com uma determinada finalidade; que envolve uma variedade de recursos; e é único Andersen et al. (1987) Um projecto é um esforço temporário, realizado para criar um produto ou serviço único Project Management Body Knowledge - PMBoK (PMI, 2000) [PJMG quality, 19]

54 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE 2.2 TIPOS DE DESENVOLVIMENTO DE SOFTWARE O investimento em tecnologias e sistemas de informação tem crescido significativamente ao longo dos últimos anos, introduzindo mudanças significativas em várias áreas de actividade. Diferentes tipos de sistemas de software e diferentes tipos de projectos foram surgindo para dar resposta às necessidades das organizações em constante evolução. De modo a fazer face aos problemas que os projectos de desenvolvimento de software têm apresentado nos últimos anos, torna-se necessário compreender as particularidades de cada tipo de projecto. Os projectos de desenvolvimento de software são cruciais na evolução de praticamente qualquer empresa. Contrastando com a sua importância, este tipo de projectos tem mantido uma reputação menos feliz no que concerne ao sucesso, o que se deve frequentemente a uma gestão de projectos (GP) menos conseguida. A sofisticação e a eficácia com que as ferramentas e as técnicas de gestão são aplicadas, influenciam a forma como as organizações realizam os seus negócios, usam recursos e respondem às variações dos mercados. O grande desafio que se coloca a um gestor de projectos é perceber os conceitos da GP e determinar que ferramentas e técnicas devem ser aplicadas e como devem ser aplicadas em projectos específicos (Schwalbe, 2002). Torna-se, assim, importante perceber as características dos diferentes tipos de desenvolvimento de software, de forma a ser possível realizar uma GP consciente e consonante com as suas características particulares. Na Figura 2.1 estão representados os três tipos de desenvolvimento de software e a altura em são identificadas as duas componentes do processo (utilizador e developer). De notar que o termo utilizador, neste contexto, refere-se ao conjunto de pessoas que estão directamente envolvidas com o projecto. O termo developer refere-se aos membros que participam activamente no processo de desenvolvimento do projecto. Nas subsecções que se seguem são apresentados alguns dos aspectos principais dos diferentes tipos de desenvolvimento de software. [PJMG quality, 20]

55 TIPOS DE DESENVOLVIMENTO DE SOFTWARE Desenvolvimento por contrato Desenvolvimento de produto Utilizadores identificados Developers identificados Utilizadores identificados Developers identificados Desenvolvimento interno e desenvolvimento à medida Utilizadores identificados Developers identificados Tempo Início do Projecto Entrega do Projecto Figura 2.1: Altura em que o utilizador/cliente e o developer estão identificados em cada um dos três tipos de desenvolvimento de software Fonte: Adaptado de (Hansen, 2005) Projectos de desenvolvimento de software à medida Entende-se por desenvolvimento de software à medida (custom development) a construção de sistemas de engenharia de software feitos de raiz, adaptados às necessidades específicas de cada cliente. São identificadas e definidas regras que são únicas para uma organização. Tem tipicamente como objectivo a concepção de soluções de negócio que implementam processos da organização. Compreende um contacto inicial com o cliente, percepcionando o modo como o seu negócio se desenrola, a enunciação de recomendações para áreas de melhoria, a elaboração de um business case com propostas concretas, a implementação e, no limite, pode chegar ao outsourcing do processo. As competências na área de BPM (Business Process Modeling) são essenciais nesta área estratégica de desenvolvimento. O desenvolvimento de software à medida, não é meramente um processo técnico de construção de um sistema de informação, mas também um processo social que envolve os stakeholders das múltiplas componentes organizacionais. [PJMG quality, 21]

56 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE Dentro do desenvolvimento de software à medida existem dois tipos de desenvolvimento possíveis: Desenvolvimento de software por contrato, descrito na subsecção ; Desenvolvimento interno, descrito na secção Desenvolvimento de software por contrato Neste tipo de desenvolvimento, a organização ou entidade utilizadora, (ou seja, o cliente final) é identificada desde o início do processo. A organização identifica os requisitos iniciais do sistema ou da aplicação pretendida através de uma especificação de requisitos e/ou do respectivo contrato. Os contratos de desenvolvimento de software definem os principais aspectos comerciais e requisitos técnicos e são normalmente documentos com algum grau de complexidade e extensos. Após o contrato ter sido conferido, a entidade responsável pelo desenvolvimento é identificada ou escolhida, e as duas entidades (cliente e fornecedor) reúnem esforços e trabalham em parceria para efectuarem a especificação de requisitos mais detalhada e o respectivo refinamento. É definido o âmbito do projecto. Este tipo de desenvolvimento é similar ao desenvolvimento interno, mas a diferença reside no facto das partes envolvidas não terem o mesmo objectivo de negócio (Lauesen, 2002). Para além da identificação do cliente, existem quatro aspectos importantes referenciados nos contratos de desenvolvimento de software (Lichtenstein, 2004): Custo: reflecte o preço do contrato, isto é, o custo do desenvolvimento inicial. Existem duas técnicas básicas para a determinação do preço: time-and-material ou preço fixo. Em alguns casos específicos estas duas técnicas podem ser combinadas; Pontos de controlo (milestones): A duração do desenvolvimento é definida pelo planeamento do projecto e respectivos deliverables; Manutenção: Reflecte-se no contrato através da inclusão de correcções e adaptações a novos ambientes ou necessidades. O cliente deve decidir se opta por serviços de manutenção externa, ou se efectua a manutenção internamente; [PJMG quality, 22]

57 TIPOS DE DESENVOLVIMENTO DE SOFTWARE Eficácia: É difícil medir a eficácia a longo prazo, uma vez que a sua realização depende do cliente e dos responsáveis pelo desenvolvimento. No entanto alguns contratos efectuam uma ligação entre o pagamento final a uma determinada medida de eficácia. Conclui-se que o desenvolvimento por contrato pode conter riscos a curto prazo e a longo prazo. Estes riscos são partilhados tipicamente de forma assimétrica. O cliente assume normalmente os riscos a longo prazo, uma vez que a manutenção é baseada no custo do tipo time-and-material, o que implica que os pagamentos não estão relacionados com a eficácia a longo prazo. A organização responsável pelo desenvolvimento assume os riscos de curto prazo através de um preço fixo e milestones indexadas aos pagamentos (Lichtenstein, 2004). Lichtenstein (2004) sugere a combinação de diferentes técnicas de avaliação e cálculo de custos, um maior investimento na monitorização e medição formal dos riscos do projecto, a aplicação de procedimentos formais de gestão para controlar e monitorizar a evolução do projecto em curso. Conclui que um contrato baseado na opção de time-and-material não é, muitas vezes, a melhor opção, sendo de considerar o custo baseado em partilha de responsabilidades. Com esta abordagem, os pagamentos devem estar relacionados com o desempenho obtido, o que conduz ao empenho dos dois lados através da experiência de pagamentos efectivos baseados na medição da eficácia. A troca de riscos a longo prazo por riscos de curto prazo é uma forma de se conseguir um maior esforço ao nível da eficácia e desempenho neste tipo de desenvolvimento (Lichtenstein, 2004) Desenvolvimento interno Neste tipo de desenvolvimento, também denominado in-house, tanto os clientes como os responsáveis pelo desenvolvimento (developers) são conhecidos desde o início do projecto e é possível identificar o tipo de utilizadores logo no início. A principal característica destes projectos é o facto de serem suportados pelas organizações responsáveis pelo desenvolvimento que os irão utilizar internamente. O desenvolvimento da especificação de requisitos é uma tarefa partilhada em simultâneo pelo cliente, tipicamente um utilizador interno, e pelo developer. Uma cooperação muito próxima entre estes dois intervenientes cria melhores condições para a obtenção de consenso e para o perfeito entendimento das consequências e eventuais mudanças com a introdução do novo [PJMG quality, 23]

58 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE sistema (Lauesen, 2002). No entanto, potencia o aparecimento de alguns pontos fracos devido ao facto de ser frequente que as partes envolvidas trabalhem sobre pressão e, neste contexto, as consequências são raramente claras para cada parte envolvida. A mudança é algo recorrente nas organizações. Vários estudos têm sido realizados para perceber como são conduzidas e acompanhadas essas mudanças e como ocorrem nas organizações em que é praticado este tipo de desenvolvimento. Um dos estudos realizados neste contexto foi o de Reich & Nelson (Reich & Nelson, 2003). Neste estudo foram identificados os três principais condutores da mudança numa organização: Mudança rápida da estratégia do negócio esta mudança requer o foco nos custos e na eficiência, de outra forma as organizações perdem competitividade e aumentam o grau de mudança oriunda de diversas direcções; Competências em TI e equipa experiente de utilizadores as competências em tecnologias dos utilizadores têm evoluído ao longo da última década. O utilizador desempenha também, na actualidade, funções de cliente e de parceiro. Como cliente, a comunidade de utilizadores é pouco tolerante a falhas de projectos tecnológicos e tem expectativas elevadas quanto ao perfeito funcionamento e desempenho da respectiva execução do projecto. Como parceiros, os utilizadores exigem igualdade na tomada de decisões, tanto ao nível tecnológico como ao nível dos processos de negócio. Têm também parte activa no controlo orçamental que financia novos projectos; Complexidade tecnológica e e-business as oportunidades dadas pelo e-business permitem maior integração dos processos internos e externos. Criou um ambiente tecnológico ainda mais complexo. Por este motivo a segurança tornou-se numa questão primária. No estudo de Reich & Nelson (2003), também foram analisadas as transições futuras nas organizações que praticam o desenvolvimento interno. Essas transições cobrem as seguintes áreas: Tecnologia e arquitectura; Organização de TI; Práticas de TI; [PJMG quality, 24]

59 TIPOS DE DESENVOLVIMENTO DE SOFTWARE Desenvolvimento aplicacional. O contexto actual para estas transições é a pressão contínua do negócio, acentuada ao longo dos anos. Esta aceleração resulta num grande volume de trabalho para os profissionais de TI de um nível elevado, que necessitam de apoio e de formação para gerir a mudança. A mudança tecnológica rápida e contínua potencia o aparecimento do outsourcing. Mudanças estruturais das organizações de TI são também contínuas. Novas competências, para os profissionais de TI, têm de ser desenvolvidas para lidarem com a transição do trabalho individual para o trabalho em equipa, assim como o conhecimento do negócio (Reich & Nelson, 2003). A execução com zero defeitos é uma das expectativas altas dos utilizadores para o desenvolvimento aplicacional. Requer uma orientação total ao nível dos processos, uma gestão de projecto forte, monitorização e métricas Projectos de desenvolvimento de Commercial off-the-shelf software Este tipo de desenvolvimento é mais vulgarmente denominado por Commercial off-the-shelf software (COTS), isto é, desenvolvimento de projectos baseado em componentes off-the-shelf. A indústria de software não tem uma interpretação comum ou uma definição consensual deste tipo de desenvolvimento. Os dois conceitos chave a definir são produto COTS e processo COTS (Torchiano & Morisio, 2004). O processo de desenvolvimento baseado em COTS envolve as seguintes ideias: Efectuar a combinação de produtos existentes; O mercado exerce uma forte influência na evolução do produto; As variações podem ocorrer durante o processo e desenvolvimento, impostas pelo mercado ou por mudança de requisitos. No desenvolvimento convencional, as variações resultam dos requisitos. Os analistas captam as variações na fase de definição de requisitos. Neste tipo de desenvolvimento as variações advêm dos requisitos e das necessidades de mercado. [PJMG quality, 25]

60 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE É ilustrado na Figura 2.2 o processo de desenvolvimento baseado em COTS de forma simplificada. Os produtos COTS são produzidos e/ou distribuídos por vendedores; os integradores compõem um conjunto de produtos num sistema baseado em produtos COTS. Produção Cliente Utilizador Vendedor Produto COTS Aceitação Utilização Papel Tarefa Integrador Integração Sistema baseado em COTS Artefacto (input/output) Figura 2.2: Desenvolvimento baseado em COTS, processo simplificado Fonte: Adaptado de (Torchiano & Morisio, 2004) Dentro deste processo simplificado podemos identificar quatro papéis principais e dois tipos de artefactos: Vendedor: representa a organização que produz, vende ou distribui o produto. Constitui a fonte do produto e respectiva documentação. Frequentemente fornece algum tipo de serviços de sustentação, que podem ser disponibilizados livremente ou vendidos separadamente. Integrador: corresponde à organização que constrói o sistema através de produtos COTS; existe a possibilidade de junção de componentes internamente desenvolvidos com partes de desenvolvimento de software (glueware). [PJMG quality, 26]

61 TIPOS DE DESENVOLVIMENTO DE SOFTWARE Cliente: representa a organização que adquire o sistema. O cliente pode ou não, coincidir com o utilizador. Utilizador: refere-se ao conjunto de pessoas que irá usar o SBC (após a respectiva entrega por parte do integrador ao cliente). Produtos COTS: um produto COTS é uma parte de código que não é desenvolvido internamente, é adquirido a um vendedor e utilizado tal como é, ou com pequenas modificações. Sistema baseado em COTS (SBC): constitui o sistema (ou uma parte integrante) construído pelo integrador e disponibilizado ao cliente. Os responsáveis pelo desenvolvimento são conhecidos desde o início, mas os potenciais clientes ou utilizadores do produto final são desconhecidos até o produto ser comercializado. Apesar deste aspecto, o desenvolvimento do produto baseia-se numa ideia ou numa necessidade sentida por um futuro cliente, existente ou novo. No entanto a incerteza acerca do universo de utilizadores é uma faceta importante a ser considerada no desenvolvimento do produto, devido ao destino inesperado que muitos produtos acabam por ter, positivo ou negativo. A organização responsável pelo desenvolvimento do produto deve considerá-lo como um produto comercial. O marketing do produto assume um papel importante entre o fornecedor e o cliente e, neste caso, é uma tarefa muitas vezes assumida e desempenhada pela equipa de desenvolvimento. Uma característica muito importante deste desenvolvimento é a orientação às releases do produto. O planeamento das releases é um objectivo primordial. A definição de requisitos para a próxima release do produto deve ser bem especificada. No entanto, devem-se perspectivar os requisitos definidos para as próximas releases. Os requisitos especificados devem ter em consideração os objectivos e as necessidades das futuras releases definidas previamente no planeamento. Ao nível do contrato a situação é similar ao desenvolvimento de software interno descrito na secção anterior (Lauesen, 2002) Sumário Nas secções anteriores foram apresentadas as principais características de cada um dos tipos de desenvolvimento de software em particular. A Tabela 2.1 [PJMG quality, 27]

62 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE ilustra as características dos três tipos de software apresentados, efectuando a comparação entre eles. Características Desenvolvimento contratado Desenvolvimento de produto Desenvolvimento interno Utilizador ou cliente - Sim - Não - Sim identificado desde o início - Não - Sim - Sim Equipa de desenvolvimento identificada desde o início Custo Milestones/duração Manutenção Eficácia Know-how no negócio, mudança rápida de estratégia de negócio - Preço fixo - Time/material - Planeamento e deliverables estão registados no contrato - Preço fixo - Time/material - Raramente é requerida pelo cliente, mas o cliente espera os deliverables no tempo previsto - Difícil de medir - Necessário para um melhor entendimento e formulação dos requisitos, pressão contínua do negócio, essencial para a perícia do negócio - Preço fixo - O cliente controla o orçamento - Orientação às releases - As componentes envolvidas trabalham sobre pressão - Percepção alcançada - Preço fixo - O cliente controla o orçamento - Não é requerida pelo cliente, mas a sobrevivência do produto no mercado depende da sua eficiência - Necessário, mas os utilizadores estão distantes - Requerida pelo cliente - Necessário para um melhor entendimento e formulação dos requisitos, pressão contínua do negócio, essencial para a perícia do negócio [PJMG quality, 28]

63 PARTICULARIDADES DOS PROJECTOS DE DESENVOLVIMENTO À MEDIDA Mudança tecnológica e complexidade Necessidade de criação de standards Necessidade de orientação do processo - Percepção é necessária para a sobrevivência no mercado - Pode ser necessário dependendo dos requisitos do cliente - Pode ser requerida pelo cliente - Percepção é necessária para a sobre- processos inter- - Integração de vivência no mercado nos e externos - Pode ser necessário - Reconhecida, apesar das mudanças de requisitos do negócio e do ambiente tecnológico - Pode ser requerida - Reconhecida pelo cliente Papel desempenhado pelo departamento de TI na relação com a organização - TI representa o negócio principal da organização - TI representa o negócio principal da organização - Precisa de demonstrar o valor do negócio para o resto da organização Tabela 2.1: Problemas/Características relacionadas com os três tipos de desenvolvimento Fonte: Adaptado de (Hansen, 2005) 2.3 PARTICULARIDADES DOS PROJECTOS DE DESENVOLVIMENTO À MEDIDA O desenvolvimento de software à medida tem características especiais e, por este motivo, tem constituído um desafio para os gestores ao longo dos tempos (Wang, Barron, & Seidmann, 1997). Esses atributos estão associados com a assimetria da informação, com a avaliação por parte do utilizador, com custos de desenvolvimento e com relacionamentos específicos com o investimento. Num projecto de desenvolvimento à medida, os preços de mercado para o software não ajudam a resolver o problema dos custos e de avaliação. O sistema a desenvolver pode cobrir diversas áreas aplicacionais. O cliente assume que os fornecedores são especialistas em todas as áreas porque as suas qualificações previamente analisadas são um garante dessa assunção. O relacionamento entre o consultor e utilizador envolve tipicamente assimetrias na informação partilhada e o processo de acesso à informação não é transparente. As organizações precisam de conhecer a sua própria informação (Hoven, 2001). Infelizmente uma parte significativa do conhecimento das organizações [PJMG quality, 29]

64 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE permanece sem ser utilizado e nem sempre está disponível para todos os seus recursos. A monitorização do progresso é intrinsecamente mais complexa do que no caso de outros tipos de desenvolvimento. No desenvolvimento de software à medida, o engenheiro de software é confrontado com várias variáveis que envolvem os outros stakeholders ao longo do processo de desenvolvimento. O ambiente inerente ao desenvolvimento de software à medida difere do mundo de desenvolvimento de produtos de software em diversos aspectos (Poole, 2003). Uma das diferenças chave consiste no facto dos objectivos do projecto serem definidos por elementos internos e externos à organização responsável pelo desenvolvimento. O engenheiro de software é um dos muitos participantes na definição dos requisitos da aplicação resultante. O desenvolvimento de software à medida apresenta três itens fundamentais: Características e qualidade: envolve o âmbito, isto é, à definição das características em relação a: tempo e custo; Tempo: o segundo item refere-se ao WBS (work breakdown structure), ao planeamento e atribuições individuais para o desempenho das tarefas respectivas; Custo: o terceiro item refere-se à estimativa de custo, que depende das horas estimadas e do volume de trabalho. No entanto, estes três itens não são balanceados uniformemente. Geralmente, as características influenciam o tempo e o tempo influencia o custo. Existem algumas causas que podem influenciar de forma negativa o atributo fundamental o âmbito: As pessoas mudam a sua forma de pensar sobre o que pretendem, ou alteram a sua perspectiva em relação a determinado objectivo definido. Quanto maior for a duração do projecto, a probabilidade das mudanças ocorrerem será mais elevada; Novos elementos envolvidos no processo podem decidir que existe algo muito importante que tem de ser contemplado no projecto; este tipo de situações acontece com mais frequência se o novo elemento exercer uma posição de autoridade; [PJMG quality, 30]

65 PARTICULARIDADES DOS PROJECTOS DE DESENVOLVIMENTO À MEDIDA A evolução tecnológica pode também contribuir para que algumas características devam mudar ou podem oferecer algumas potencialidades novas que devem ser adicionadas; Uma descrição incompleta do sistema pode potenciar percepções erradas dos requisitos pretendidos; Relativamente ao processo de tratamento de excepções, consome-se frequentemente, muito tempo na escrita e documentação de suporte dos requisitos e não são consideradas as excepções. Na Tabela 2.2 é efectuada uma comparação entre os ambientes do desenvolvimento de software à medida e desenvolvimento de software por pacotes (package software). Dimensão Desenvolvimento à medida Desenvolvimento por pacotes Ponto típico em que a maioria de clientes são identificados Número de organizações cliente Distância física entre o cliente e o consultor Tipos comuns de projectos Termos para o cliente de software Medidas de sucesso - Antes de começar o desenvolvimento - Normalmente uma - Muitas - Pequena (normalmente os clientes estão no mesmo edifício dos consultores) - Novo sistema - Componente forte de manutenção - Utilizador - Utilizador Final - Satisfação - Aceitação - Após o desenvolvimento e quando o produto é lançado no mercado - Elevada - Novos produtos - Novas versões (grandes e pequenas) - Cliente - Vendas - Posicionamento no mercado - Boas revisões do produto Tabela 2.2: Diferenças relevantes entre desenvolvimento à medida e package software Fonte: Adaptado de (Mark Keil & Carmel, 1995) [PJMG quality, 31]

66 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE Boas práticas do desenvolvimento à medida Na Tabela 2.3 é apresentado um sumário das boas práticas como fio condutor do desenvolvimento. A apresentação é efectuada perspectivando três níveis: Indústria; abordagem do desenvolvimento de software; esforços da equipa de desenvolvimento e ambiente cultural. Boas práticas do desenvolvimento de software à medida Comunidade industrial Abordagem do desenvolvimento de software Ambiente cultural e esforços da equipa de desenvolvimento - Domínio sobre as pressões ao nível do custo; - A aceitação e a satisfação do utilizador constituem medidas de sucesso. - Orientado ao processo com o envolvimento do utilizador. - Orientados à especialização de papéis a desempenhar; - Direccionados aos requisitos definidos; - Sinergias de grupo. Tabela 2.3: Sumário das boas práticas do desenvolvimento de software à medida Fonte: Adaptado de (Sawyer, 2000) Aspectos e desafios do desenvolvimento de software à medida Um dos aspectos primordiais que caracteriza o desenvolvimento à medida reside no facto de cada cliente ser único, com diferentes objectivos, diferentes áreas de negócio, diferentes necessidades de desenvolvimento. Algumas questões podem ser consideradas: Qual é a tipologia elaborada no contrato de desenvolvimento à medida tendo em conta a forma de entrega e o seu desenvolvimento? Como efectuar um seguimento perante mudanças imprevisíveis ao longo do desenvolvimento? Quais são os aspectos principais a considerar na regulação das diferentes etapas do contrato de desenvolvimento à medida? Como regular o período de prova dos contratos de desenvolvimento à medida? [PJMG quality, 32]

67 PARTICULARIDADES DOS PROJECTOS DE DESENVOLVIMENTO À MEDIDA Como resolver a problemática da propriedade e a utilização dos resultados? Como dotar de flexibilidade os projectos implantados (gestão da mudança)? O cliente, muitas vezes, especifica os requisitos assumindo que os fornecedores já têm conhecimento do domínio da aplicação a ser desenvolvida. As necessidades dos clientes, em particular nas empresas de serviços no mercado regional, variam na medida da sua dimensão, da complexidade dos seus processos e da sua estrutura organizacional, na sua apetência e adaptação à utilização de novas tecnologias. No geral, as empresas aspiram a tornar os seus processos operacionais mais eficientes e mais transparentes, a promover o acesso à informação relevante para tomada de decisões ao longo de toda a cadeia organizacional, e a melhorar e agilizar a relação com os parceiros de negócio, fornecedores e clientes. As respostas a essas necessidades são naturalmente de natureza diversa e, na maioria das vezes, combinações de soluções de vários tipos. Poderão ser propostos: Soluções standard, preconcebidas, pelas quais o cliente paga uma licença de utilização. Essa licença pode assumir vários moldes, conforme o regime de licenciamento, desde o pagamento de um valor por instalação, por número de utilizadores ou por transacção efectuada. São normalmente soluções mais económicas, e uma boa opção sempre que respondam aos requisitos base, uma vez que constituem normalmente produtos robustos, e com garantias de evolução contínua. A instalação de uma central de reservas turísticas num grupo hoteleiro é um exemplo de uma dessas soluções; Serviços de consultoria, no levantamento de requisitos, especificação de arquitecturas de sistemas, pesquisa e selecção de soluções existentes, especificação de integrações, etc.; Desenvolvimento de soluções à medida. Soluções completamente novas, ou extensões a soluções existentes, de modo a responder a necessidades específicas do cliente. [PJMG quality, 33]

68 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE 2.4 PARTICULARIDADES DOS PROJECTOS DE DESENVOLVIMENTO BASEA- DO EM COMMERCIAL OFF-THE-SHELF SOFTWARE As especificidades dos projectos de desenvolvimento baseado em Commercial off-the-shelf software (COTS) são as seguintes: São utilizados standards ao nível da arquitectura e do desenho; Os COTS podem influenciar a definição dos processos de negócio; Podem existir incompatibilidades entre as práticas do fornecedor COTS e as práticas utilizadas para o desenvolvimento do projecto. Existe uma considerável mudança de paradigma entre o desenvolvimento à medida onde o software é modelado e implementado e o desenvolvimento baseado em COTS que sugere a aquisição de produtos já implementados e disponíveis no mercado (C. F. Alves, 2001). A Figura 2.3 mostra a mudança entre essas duas formas de desenvolvimento: no desenvolvimento convencional existe uma sequência linear das actividades, enquanto no desenvolvimento baseado em COTS existem acções simultâneas entre o processo de requisitos, a arquitetura de software e os produtos COTS que serão adquiridos. Desenvolvimento convencional Desenvolvimento baseado em COTS Requisitos Arquitectura Requisitos Produtos COTS Arquitectura Definição e negociação simultâneas Implementação Figura 2.3: Diferenças entre o desenvolvimento convencional e o desenvolvimento baseado em COTS Fonte: Adaptado de (C. F. Alves, 2001). O processo de selecção é uma das fases mais importantes do processo de desenvolvimento baseado em COTS. Durante essa fase são escolhidos um ou mais produtos adequados para integrar o sistema final. Assim, a selecção [PJMG quality, 34]

69 PARTICULARIDADES DOS PROJECTOS DE DESENVOLVIMENTO BASEADO EM COMMERCIAL OFF-THE-SHELF SOFTWARE apropriada é fundamental para o sucesso desses sistemas; senão, podem ser ocasionados inúmeros problemas nas fases seguintes como uma possível incompatibilidade com o restante do sistema. O sucesso desses sistemas depende largamente do processo de selecção de componentes que atenda satisfatoriamente aos requisitos essenciais dos stakeholders. Na generalidade, os modelos de engenharia de software existentes, tais como os modelos Cascata e Espiral (Sommerville, 1996), não são adequados para o desenvolvimento baseado em componentes. Os modelos anteriores não tratam o processo simultâneo entre especificação dos requisitos, descrição da arquitectura e aquisição/integração de produtos COTS (Foreman, 1999). Não avaliam o extenso processo e o custo associado com as actividades de avaliação e integração desses componentes. Como resultado, implementar sistemas baseados em COTS usando estes modelos normalmente conduz a projectos inconsistentes (Tran & Liu, 1997). Para dar resposta a este problema foram propostos vários modelos de ciclo de vida específicos para desenvolvimento baseado em COTS. Geralmente, englobam as seguintes fases (A. W. Brown & Wallnau, 1996): avaliação, selecção, adaptação, integração e actualização. As actividades de avaliação e selecção de produtos candidatos são alguns dos aspectos fundamentais do seu ciclo de vida, uma vez que nessa altura são analisadas as características de cada produto COTS candidato e a respectiva conformidade com as necessidades dos stakeholders (Kontio, 1995). Se um produto inadequado for seleccionado, pode provocar riscos e problemas nas fases seguintes (C. F. Alves & Castro, 2001). A utilização de pacotes de software menos adequados à solução que se pretende pode ser mais oneroso que a correcção de problemas no software de desenvolvimento à medida. O sucesso de sistemas baseados em COTS depende maioritariamente do conhecimento correcto das capacidades e limitações de cada produto (Ncube, 2000). Por forma a atingir esse sucesso, a avaliação dos produtos deve ser um processo simultâneo com a aquisição de requisitos dos stakeholders (C Alves, Castro, & Alencar, 2000). É defendido que os requisitos para sistemas baseados em COTS devem ser definidos da forma mais flexível possível (Carina Alves & Finkelstein, 2004). Existem situações em que requisitos críticos não podem ser totalmente satisfeitos sem adaptação do produto. Noutros casos existem requisitos que ficam [PJMG quality, 35]

70 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE comprometidos devido a limitações do produto. Em ambas as situações, é importante analisar cuidadosamente as consequências envolvidas. Por exemplo, a decisão de adaptar um produto, de modo a alinhá-lo com o processo organizacional de uma empresa, poderia resultar no esforço substancial de programação que pode limitar as vantagens da utilização de produtos COTS. Do mesmo modo, a decisão de mudar requisitos pode implicar graves riscos que poderiam afectar o sucesso do sistema. A priorização de requisitos é particularmente importante no desenvolvimento baseado em COTS porque muitos requisitos não poderão ser preenchidos por qualquer produto disponível. Portanto, a atribuição de prioridade ajuda a distinguir requisitos essenciais (ou seja, necessidades críticas que devem sempre ser satisfeitas) de requisitos não prioritários (ou seja, aqueles que não comprometem o funcionamento do sistema). No entanto, dependendo do número de requisitos, pode ser muito difícil a comparação eficaz da importância relativa de cada requisito com relação aos outros. Um problema adicional é que os stakeholders oferecem alguma resistência a priorizar requisitos com receio que os fornecedores limitem os seus esforços para satisfazer apenas o núcleo das funcionalidades correspondentes a requisitos críticos. É frequente, durante a fase de pré-qualificação do produto COTS, os fornecedores indicarem que os seus produtos satisfazem plenamente todas as funcionalidades críticas (o que pode não ser exactamente verdade), de forma a passarem o processo de qualificação. Na realidade, a falta de confiança em relação aos fornecedores de produtos COTS é um desafio fundamental que os stakeholders enfrentam. 2.5 PROJECTOS DE DESENVOLVIMENTO HÍBRIDO DE SOFTWARE Durante as décadas de 70 e 80, proliferaram as soluções de software de desenvolvimento à medida. No entanto, o crescimento das soluções integradas de software com custos mais reduzidos começou a dominar o mercado e a fazer parte de importantes investimentos efectuados em tecnologias de informação desde os anos 90. Durante anos as organizações mantiveram os seus próprios departamentos de desenvolvimento; no entanto, verificou-se que muitos dos processos empresariais eram similares, o que conduziu ao crescimento do software standard. Outros factores podem ser considerados para justificar este crescimento, tais como: os custos elevados de desenvolvimento e manutenção, as constantes alterações do contexto económico e social e a grande dependência que as organizações tinham dos seus departamentos de desenvolvimento. [PJMG quality, 36]

71 PROJECTOS DE DESENVOLVIMENTO HÍBRIDO DE SOFTWARE A evolução das tecnologias também contribuiu para que o processo de desenvolvimento de novos sistemas de informação evoluísse do desenvolvimento à medida para a agregação de componentes off-the-shelf (COTS). Esta mudança reduziu, de uma forma significativa, os custos e tempos de desenvolvimentos em projectos de e-business (Horowitz & Lambert, 2006). Trouxe, no entanto, novos riscos e novos desafios à Gestão de Projectos (GP). Os métodos, as técnicas, a gestão de recursos humanos, de comunicação e todos os aspectos relacionados com a GP, são totalmente diferentes dos projectos de desenvolvimento de software tal como os conhecíamos (Horowitz& Lambert, 2006). Por outras palavras, no contexto dos projectos de desenvolvimento híbrido de software, passamos a ter partes de desenvolvimento no projecto que são COTS e outras que são custom development. Neste contexto os sistemas ERP têm um papel preponderante. Num ambiente globalizado e permeado de mudanças cada vez mais complexas, a gestão adequada da informação assume importância decisiva no processo de tomada de decisão e na busca de vantagens competitivas nas organizações. Diante deste cenário, as empresas focaram suas atenções ao desenvolvimento de sistemas de informação integrados que propiciam informações essenciais aos principais executivos de uma organização. Esta fase iniciou-se a partir da metade dos anos 90, quando as empresas começaram a adoptar os sistemas Enterprise Resource Planning (ERP) (Ujihara, Cardoso, & Chaves, 2006). Os ERP como produtos standard, impõem a sua lógica à estratégia e cultura de uma organização (T. Davenport, 1998). Contudo, existe sempre a possibilidade de se efectuarem adequações ou desenvolvimentos à medida. Acreditar ou pensar que as adequações e desenvolvimentos à medida são algo sem grande importância, é uma ideia totalmente errada (Gomes, 2007). Apesar de todo o enfoque que se dá à implementação, esta não consegue resolver todos os problemas. Por outro lado, devido ao facto de os ERPs serem altamente configuráveis sem adaptações não conseguem ajustar-se à realidade organizacional (Brancroft, Seip, & Sprengel, 1998; T. Davenport, 1998; T. H. Davenport, 2000). A parametrização compreende a preparação do ambiente para a empresa, de forma que o sistema incorpore as regras do negócio, as opções oferecidas pelo sistema, a selecção de campos, a definição de parâmetros, a execução de funções, entre outros. [PJMG quality, 37]

72 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE A adaptação é constituída pela agregação, ao sistema, de módulos ou funcionalidades específicas para a empresa, através de programação na mesma tecnologia utilizada pelo fornecedor do sistema. A adaptação deve ser praticada de forma restrita, pois torna difícil a manutenção do sistema e a actualização de versões. A duração da actualização de um sistema deve ser a menor possível, já que por vezes, é necessária a paralisação das operações da empresa para tal finalidade. Dessa forma, estabelece-se uma necessidade de balanceamento entre a implementação de adaptações e a complexidade do processo de actualização de versões. Tendo em consideração este aspecto, a empresa deve procurar obter uma parceria com o fornecedor do sistema, que pode assumir parte dos custos de desenvolvimento da adaptação e incorporá-la ao pacote, se for comercialmente atractiva. Caso esta alternativa não seja viável, a empresa deve procurar uma tecnologia adequada para que a actualização (upgrade) do seu sistema e as adaptações realizadas ocorram de forma rápida. Um sistema Enterprise resource planning (ERP) é um software de gestão dos recursos empresariais que integra as diferentes funções da empresa para criar operações mais eficientes. Integra os dados chave e a comunicação entre as áreas da empresa, fornecendo informações detalhadas sobre as operações da mesma (Buckhout, Frey, & Jr., 1999). Souza & Zwicker (Souza & Zwicker, 2000) definem ERP como sistemas de informação integrados, adquiridos na forma de pacotes comerciais, para suportar a maioria das operações de uma empresa. Procuram atender a requisitos genéricos do maior número possível de empresas, incorporando modelos de processos de negócio obtidos pela experiência acumulada de fornecedores, consultorias e pesquisa em processos de benchmarking. A integração é possível pela partilha de informações comuns entre os diversos módulos, armazenadas numa base de dados centralizada. Um ERP é um pacote de software de gestão que permite a uma empresa gerir o uso dos seus recursos, sejam eles, materiais, pessoas ou equipamentos. Um ERP abrange uma grande área de funcionalidades de forma integrada. Essas funcionalidades incluem, entre outras, finanças e contabilidade, vendas e distribuição, orçamentação e planificação, recursos humanos, imobilizado, gestão de stocks, plano director de produção e gestão de ordens de fabrico, e compras. Para Laudon e Laudon (2006) (Kenneth C Laudon & Laudon, 2006), o ERP é um sistema que integra todas as facetas da empresa, inclusive planejamento, produção, vendas. [PJMG quality, 38]

73 PROJECTOS DE DESENVOLVIMENTO HÍBRIDO DE SOFTWARE Os mais importantes atributos de um ERP são a sua capacidade para: Automatizar e integrar a maioria dos processos empresariais; Partilhar dados e processos por toda a empresa; Produzir e permitir o acesso à informação em tempo real. Para Lima e outros autores (Lima et al., 2000), a adopção de um ERP afecta a empresa em todas as suas dimensões, culturais, organizacionais ou tecnológicas. Esses sistemas controlam toda a empresa, da produção às finanças, registando e processando cada facto novo na engrenagem corporativa e distribuindo a informação de maneira clara e segura, em tempo real. Os sistemas ERP são actualmente as principais ferramentas de gestão e exigem a atenção multi-disciplinar das operações de gestão, sistemas de informação, financeiro, marketing, comportamento organizacional e no campo dos recursos humanos (Sarkis& Sundarraj, 2003). A utilização de um ERP tem um enorme impacto na transformação da organização, especialmente no controlo, permitindo uma visão centralizada de toda a estrutura da organização (Holland & Light, 1999). Estes sistemas controlam toda a organização, distribuindo a informação de maneira clara e segura, em tempo real (Botta-Genoulaz, Millet, & Grabot, 2005). Ao adoptar um ERP, o objectivo básico não é colocar o software em produção, mas melhorar os processos de negócio através da utilização das TI. Mais do que uma mudança de tecnologia, a adopção desses sistemas implica um processo de mudança organizacional (Mendes & Filho, 2002), envolvendo alterações nas tarefas e responsabilidades das pessoas e dos departamentos. O ERP fornece informações geradas a partir do processo operacional, para optimizar o dia-a-dia da empresa, permitir um planeamento estratégico mais seguro e garantir a flexibilidade para evoluir (Centola & Zabeu, 1999). Um ERP é constituído por módulos que atendem às necessidades de informação de apoio à tomada de decisão de todos os sectores da empresa, integrados entre si, a partir de uma base de dados única e não redundante. Todos os processos são documentados e contabilizados, gerando regras de negócio bem definidas e permitindo maior controlo sobre alguns pontos vulneráveis do negócio, como a administração de custos, controlo fiscal e stocks. A adopção destes sistemas põe fim aos vários sistemas que funcionavam de [PJMG quality, 39]

74 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE forma isolada na empresa, com informações redundantes e com pouca fiabilidade (Miltello, 1999). Para Davenport (T. H. Davenport, 2000), o ERP é um sistema de software que promove a integração das informações que circulam pela empresa. Esse sistema impõe sua própria lógica à estratégia, à cultura e à organização da empresa. É uma solução genérica que procura atender a todo tipo de empresa e seu projeto reflete uma série de hipóteses sobre como operam as organizações. É desenvolvido para refletir as melhores práticas de negócio, porém a decisão sobre a melhor prática é de responsabilidade do cliente. Numa publicação da Deloitte Consulting (Consulting, 1998) um ERP é definido como um software de negócio que permite à empresa automatizar e integrar a maioria de seus processos; partilhar práticas de negócio e dados comuns pela empresa; e disponibilizar a informação em tempo real. É visto como a solução para acabar com os vários programas que funcionam no mesmo ambiente empresarial, sem integração, produzindo informações de pouca qualidade para o negócio. Sistemas dessa natureza são adquiridos com o intuito de tornar os processos empresariais mais ágeis e extrair informações mais apuradas da empresa. Segundo Stamford (Stamford, 2003), o ERP possibilita um fluxo de informações único, contínuo e consistente por toda a empresa sob uma única base de dados. É um instrumento para a melhoria de processos de negócio, orientado por esses processos e não pelas funções e departamentos da empresa, com informações on-line em tempo real. Permite visualizar por completo as transacções efectuadas pela empresa, desenhando um amplo cenário de seus processos de negócios. Surgiram da confluência de factores como: integração de empresas transnacionais exigindo tratamento único e em tempo real da informação; tendência de substituição de estruturas funcionais por estruturas ancoradas em processos; e integração dos vários sistemas de informação em um único sistema (Mendes& Filho, 2002). O sistema ERP, assim, está presente em praticamente todas as áreas da empresa, desde as relacionadas ao sector de produção até às que estão directamente ligadas a decisões estratégicas e ao posicionamento empresarial no mercado. Para Kavanagh (Kavanagh, 2006), o sistema ERP constitui uma tecnologia com grande potencial de geração de atividades colaborativas, em que a integração proporcionada pelo ERP habilita melhorias de processos e de administração da informação durante o processo de tomada de decisão. Por ser caracterizado como um sistema que objetiva a integração das informações e do tratamento [PJMG quality, 40]

75 PROJECTOS DE DESENVOLVIMENTO HÍBRIDO DE SOFTWARE do conhecimento gerado na organização, o ERP tem-se evidenciado como uma das principais ferramentas tecnológicas utilizadas pelas empresas que almejam patamares elevados de competitividade. Existem duas abordagens possíveis para a implementação de sistemas ERP (Silva& Alves, 2001): Desenvolvimento à medida; Implementação de pacotes configuráveis. Desenvolvimento à medida: Este tipo de desenvolvimento caracteriza-se por uma total adequação às necessidades do negócio para o qual se destinam. Os tempos de desenvolvimento são normalmente muito significativos. O custo associado ao desenvolvimento de raiz de uma aplicação ERP é elevado. Um dos aspectos positivos é a cobertura do negócio a 100%. Implementação de pacotes configuráveis: As funcionalidades dos módulos de um sistema ERP representam uma solução genérica que reflecte uma série de considerações sobre a forma como as empresas operam em geral. Para flexibilizar a sua utilização num maior número de empresas de diversos segmentos, os sistemas ERP foram desenvolvidos para que a solução genérica possa ser configurada até um certo grau ou nível. Na implementação de um sistema ERP, a configuração é um compromisso entre os requisitos da empresa e as funcionalidades disponíveis no sistema. Inicialmente, na maioria das vezes, os processos de negócio das empresas precisam de ser redefinidos para que os seus requisitos se aproximem das funcionalidades do sistema. A primeira etapa consiste na selecção dos módulos que serão instalados. A característica modular permite que cada empresa utilize somente os módulos que necessita e possibilita que módulos adicionais sejam agregados futuramente. Mesmo com a configuração, a solução pode não contemplar alguns requisitos específicos das empresas. Nesses casos, é necessário utilizar outros sistemas complementares ou abandonar alguns requisitos específicos e adoptar processos genéricos. Muitas empresas calculam de forma errada os custos relativos à implantação de um ERP. Os custos incluem: licenças do software, hardware, serviços de consultoria e formação. As principais dificuldades referem-se à actualização constante do sistema e gestão das versões. Mesmo após a implementação, o sistema mantém-se em evolução contínua, de forma a reflectir os processos da empresa. Os fornece- [PJMG quality, 41]

76 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE dores incorporam novos recursos e novas formas de executar processos e corrigem problemas. Muitas alterações podem ser consideradas novas implementações. A adopção de um ERP é um processo de mudança organizacional envolvendo alterações nas tarefas e responsabilidades de indivíduos, departamentos e relações entre os departamentos. Para Stamford (Stamford, 2003), os problemas referem-se à escala de reengenharia de processos, às tarefas de parametrização durante a implementação, à inexperiência da equipa de suporte, à implementação longa, ao alto custo relacionado com a consultoria e formação, à complexidade na adaptação e aos benefícios que nem sempre se concretizam. A implantação e os serviços associados custam tipicamente até sete vezes mais do que a compra do software. Outro problema refere-se à premissa de que os modelos de referência do sistema incorporam as melhores práticas de negócios. Pode haver desencontros entre, por exemplo, tipo de indústria e melhores práticas desse segmento e os modelos de referência do sistema. De acordo com Miltello (Miltello, 1999), nem tudo é simples no mundo do ERP. A implantação é cara e demorada, sendo preciso submeter todos os processos a uma verificação geral. Na prática, a corporação necessita repensar toda sua estrutura, o que a leva a buscar ajuda de profissionais especializados, elevando o investimento. Taurion (Taurion, 1999) afirma que o redesenho de processos e as mudanças organizacionais são essenciais para alcançar os objectivos. A empresa deve abandonar a estrutura organizacional hierarquizada e basear-se em estruturas ancoradas em processos. A implantação não pode ser encarada como mudança de tecnologia, mas antes como um processo de mudança organizacional. Após a implantação, ainda são necessários ajustes no sistema para solucionar os problemas de desempenho e falhas ocasionadas pela pouca familiaridade dos utilizadores. A interface do ERP com outros sistemas não é fácil. Uma pesquisa realizada por Wood Jr. (JR., 1999) revela que a decisão sobre a adopção de ERP foi muitas vezes tomada de forma apressada, alimentada pelo marketing dos fornecedores. Muitas empresas não perceberam a amplitude e a profundidade das questões envolvidas. É preciso avaliar a estratégia e a visão de futuro da empresa e identificar as necessidades de informação. Quando questionadas sobre as desvantagens, foram obtidas as seguintes respostas: não atendimento das necessidades específicas dos negócios, perda de algumas funções essenciais dos negócios, visão superficial dos processos, dependência de um único fornecedor, excesso de controlo, falta de envolvimento da alta administração, planeamento inadequado, perda de his- [PJMG quality, 42]

77 PROJECTOS DE DESENVOLVIMENTO HÍBRIDO DE SOFTWARE tórico durante a conversão, baixa adequação entre o sistema e o contexto empresarial do País e falta de suporte adequado. Ao longo das últimas décadas conseguiram-se criar infra-estruturas de integração robustas. No entanto, existem ainda dificuldades na integração de processos, dados e sistemas existentes numa empresa ou organização. As tecnologias ERP durante os anos 90, permitiram realmente resolver os problemas de integração internos criados pelas aplicações herdadas do passado (gestão financeira, gestão de recursos humanos, gestão de inventário, entre outras). O problema é que o mundo não parou; os modelos de negócio impulsionados pelo crescimento da Internet e focados na relação com os clientes, levaram ao aparecimento de aplicações especialistas. As empresas cresceram e, devido também à sua mutação, surge a necessidade da integração das arquitecturas empresariais. Uma empresa na actualidade tem de reagir a estímulos críticos, cada vez mais em tempo real. O Gartner Group (Gartner Group, 2003) estima que 40% do tempo de desenvolvimento das aplicações é consumido na criação de interfaces e pontos de integração entre aplicações e fontes de dados. Colangelo Filho (Filho, 2001) explica, que o sucesso da implantação do ERP está no processo de integração entre as partes envolvidas. As maiores dificuldades no desenvolvimento dos sistemas de informação (SI) estão actualmente na componente de integração (Lam, 2005). Muitos dos actuais desafios presenciados pelos administradores contemporâneos têm como causa a falta de integração entre SI ou mesmo o uso de soluções inadequadas de integração (Consulting, 1999; Sordi & Marinho, 2007) Dificuldades na implementação de um ERP Na prática, muitos dos projectos de implementação de sistemas do tipo ERP apresentam características de ambos os tipos de implementação. O alinhamento dos processos ERP standard com os processos inerentes ao negócio é considerado com uma etapa crítica do processo de implementação (Botta-Genoulaz, Millet, & Grabot, 2005). As principais dificuldades referem-se à actualização constante do sistema e gestão de versões. Mesmo após a implementação, o sistema mantém-se em evolução contínua, de forma a reflectir os processos da empresa. Os fornecedores incorporam novos recursos e novas formas de executar processos e corrigem problemas. Muitas alterações podem ser consideradas novas implementações. As principais barreiras e dificuldades de acordo com o estudo de Mendes e Filho (Mendes & Filho, 2002) são: Análise dos processos; Actualização [PJMG quality, 43]

78 CAPÍTULO DOIS - PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE constante do sistema; Complexidade na parametrização; Dificuldade na comunicação; Equipa experiente para conduzir a implementação; Dependência de um único fornecedor; Interface do sistema não amigável; Mudança organizacional; Não envolvimento da gestão de topo; Planeamento inadequado. Para Stamford (Stamford, 2003), os problemas referem-se à escala de reengenharia de processos, às tarefas de parametrização durante a implementação, à inexperiência da equipa de suporte, à implementação longa, ao alto custo relacionado à consultoria e formação, à complexidade e aos benefícios que nem sempre se concretizam. Outro problema refere-se à premissa de que os modelos de referência do sistema incorporam as melhores práticas de negócios (Mendes & Filho, 2002). Na prática, é necessário repensar toda sua estrutura, o que leva à necessidade de contratar profissionais especializados, elevando o investimento. A reengenharia de processos e as mudanças organizacionais são essenciais para alcançar os objectivos. Num contexto de um projecto com estas características, a GP tem que ser racionalizada de modo a ser possível lidar com os diversos problemas que surgem Boas práticas na implementação de um ERP Uma pesquisa, denominada Second Wave, realizada pela Deloitte Consulting (Consulting, 1998), foi orientada especificamente para implantações de sistemas ERP. Através dos seus resultados, foram identificadas correlações existentes entre práticas de implantação e sucesso em resultados com projectos desta natureza. As considerações da pesquisa em relação às melhores práticas são descritas na Tabela 2.4. Sequência Recomendações para o sucesso: best practices 1 Concentrar-se em adquirir competências e benefícios, não apenas no uso do sistema 2 Alinhar a organização ao destino, ou seja, aos objectivos da implantação 3 Promover mudanças equilibradas em pessoas, processos e tecnologia 4 Aplicar técnicas de planeamento e gestão de projectos 5 Utilizar o estudo de viabilidade como ferramenta de gestão 6 Definir métricas e utilizá-las como um meio de suporte à gestão 7 Expandir as competências para além do âmbito do sistema ERP [PJMG quality, 44]

79 PROJECTOS DE DESENVOLVIMENTO HÍBRIDO DE SOFTWARE 8 Ensinar a organização a usar as novas competências 9 Atribuir responsabilidades pelos benefícios 10 Promover a transição da equipa de projecto da implantação para a pós implantação, ou seja, a equipa deve efectuar o acompanhamento do sistema durante um período após o sistema entrar em produção 11 Fomentar o conhecimento de processos obtido com o projecto 12 Promover a homogeneização de processos pós implantação Tabela 2.4: Recomendações de best practices (boas práticas) para o sucesso em implantação de sistemas ERP Fonte: Adaptado de (Filho, 2001; Ujihara, Cardoso, & Chaves, 2006) Neste capítulo efectou-se a caracterização dos principais tipos de desenvolvimento de software Apresentaram-se as dificuldades e os desafios de cada tipo de desenvolvimento. Foi também elaborado um resumo comparativo das características relacionadas com os diferentes tipos. No capítulo seguinte aborda-se a Gestão de Projectos, incidindo particularmente nos conceitos referenciais e nas áreas de conhecimento. [PJMG quality, 45]

80

81 Capítulo 3 Gestão de Projectos "The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labor to perform the same task." Tom Clancy, (The Sum of All Fears) Neste capítulo é efectuada uma reflexão sobre a realidade actual da Gestão de Projectos. São apresentados os conceitos referenciais da Gestão de Projectos e identificadas as suas principais áreas de conhecimento. In this chapter we have made a reflection on the current reality of projects management. The referencial concepts of projects management are presented and identified the main areas of expertise. A evolução das organizações é hoje pautada por uma crescente necessidade de implementação de projectos de TIC. Constata-se, no entanto, os sucessivos fracassos de projectos que não cumprem os seus objectivos, sendo muitas vezes os erros cometidos semelhantes. O facto do insucesso dos projectos em TIC ser ainda significativo (Standish Group, 2004a) e de se conseguirem identificar aspectos chave como causas das suas falhas, leva a que a investigação prossiga na procura de metodologias, métodos, técnicas e ferramentas, com vista a melhorar a concepção, a construção, a implementação, e o decorrente sucesso dos projectos. Neste capítulo efectua-se uma reflexão sobre a realidade actual da Gestão de Projectos (GP). É efectuada uma contextualização histórica e é abordado o problema do insucesso; são apresentados os conceitos referenciais e identificadas as suas principais áreas; é ainda explicado o ciclo de vida do projecto; por fim, são identificados novos desafios e oportunidades de investigação na área. Segundo o Project Management Institute (PMI), a gestão de projectos é a aplicação de conhecimentos, capacidades, ferramentas e técnicas para que as activi- [PJMG quality, 47]

82 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS dades do projecto consigam alcançar os seus requisitos, através da utilização de processos de iniciação, planeamento, execução, controlo e conclusão inerentes a cada fase do projecto (PMI, 2000). 3.1 CONTEXTO HISTÓRICO Desde há muito tempo que na história humana existem projectos. Empreendimentos como as pirâmides do Egipto e a Grande Muralha da China já exigiram grandes esforços de gestão. No entanto, o conceito mais moderno de GP começou com o Projecto de Manhattan, liderado pelos militares dos Estados Unidos da América para o desenvolvimento da bomba atómica. Na verdade a indústria militar foi a peça chave no desenvolvimento de muitos conceitos e técnicas de GP (Schwalbe, 2002). Em 1917 Henry Gantt desenvolveu o famoso gráfico de Gantt (Gantt chart) como uma ferramenta de distribuição temporal de trabalho. Os gestores desenhavam manualmente gráficos para mostrar tarefas agendadas numa dada calendarização. Esta ferramenta forneceu um formato padrão para o planeamento e revisão do trabalho a realizar nos primeiros projectos militares. Hoje em dia, os gestores de projectos continuam a utilizar o gráfico de Gantt como uma ferramenta fundamental para comunicar cronogramas de projectos. A técnica Program Evaluation and Review Technique é outra técnica marcante na GP e foi utilizada pela primeira vez em 1958 no projecto do míssil submarino Polaris da Marinha Americana (Sapolsky, 1972). Esta técnica ajudou os gestores a modelar as relações entre as tarefas dos projectos, permitindo a criação de previsões de tempo e custo mais realistas. Estas relações permitem analisar a sequência de tarefas a ser realizada e a determinar e monitorizar o caminho crítico (critical path) do projecto o caminho mais longo existente num diagrama de rede de tarefas e que determina a data mais breve do término do projecto. Em 1970 os militares começaram a utilizar software no auxílio da gestão de grandes projectos. Dada a dimensão e complexidade dos projectos foi necessário aumentar o conhecimento sobre GP e criar ferramentas de suporte. O software de GP inicialmente era muito dispendioso e era executado em mainframes como, por exemplo, o Ártemis, que permitia a análise de complexos escalonamentos na indústria de aviação. O Ártemis exigia uma pessoa a tempo inteiro para operar o programa e utilizava pen-plotters extremamente dispendiosas no desenho dos diagramas que permitia produzir. [PJMG quality, 48]

83 TÉCNICAS E METODOLOGIAS DA GESTÃO DE PROJECTOS À medida que o hardware se tornou mais barato, de menor dimensão e o software começou a ter suporte gráfico, as aplicações de GP passaram a ser mais fáceis de utilizar, mais acessíveis e mais populares. Actualmente, as diferentes indústrias usam o software de GP em todos os tipos de projectos das mais variadas dimensões. A sofisticação e a eficácia com que as ferramentas e as técnicas de GP são aplicadas influenciam a forma como as organizações realizam o negócio, usam recursos e respondem às variações dos mercados de uma forma mais rápida e mais precisa. A figura de gestor de projecto refere-se a alguém que lidera a construção de um estádio de futebol, uma colheita de fundos para uma associação sem fins lucrativos ou o desenvolvimento de uma aplicação de comércio electrónico. Todos estes exemplos convergem para um único ponto: independentemente da indústria é necessário perceber os problemas existentes quando se pretende gerir um projecto com sucesso. O grande desafio do gestor de projecto é perceber os conceitos da GP e determinar que ferramentas e técnicas devem ser aplicadas e como devem ser aplicadas em projectos específicos (Schwalbe, 2002). 3.2 TÉCNICAS E METODOLOGIAS DA GESTÃO DE PROJECTOS Um framework muito divulgado de GP é o Project Management Body of Knowledge (PMBoK) do Project Management Institute (PMI). O PMI procura definir as áreas de conhecimento usualmente aceites como sendo exigidas por um gestor de projecto numa tentativa de definir um standard e melhorar o processo de gestão de projectos (PMI, 2000). O PMBoK aborda, para além do custo, tempo e qualidade, métodos para gerir a integração, o âmbito, recursos, risco, pessoas e comunicação. Estes métodos encontram-se integrados através de cinco processos que se aplicam a todas as áreas do conhecimento: inicialização, planeamento, execução, controlo e fecho. Outros frameworks, como o Centre for Research in the Management of Projects Body of Knowledge (CRMPBoK), expande as áreas tradicionais do PMBoK incorporando áreas adicionais pertinentes ao corpo de conhecimento de GP, tais como tecnologia, desenho, aspectos humanos, considerações ambientais, finanças, marketing, enquadramento estratégico do negócio e gestão (Morris, 2001). [PJMG quality, 49]

84 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS 3.3 GESTÃO DE PROJECTOS NAS TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO Apenas num período de vinte anos a tecnologia em termos do hardware e do software utilizados no desenvolvimento de SI mudou radicalmente. Nos anos 80, devido à evolução do hardware, o custo de desenvolvimento de um novo sistema transferiu-se do hardware para o software. Deste modo, os métodos aplicados na engenharia de sistemas concentraram-se no software (Horowitz & Lambert, 2006). Nas últimas décadas os projectos de software atingiram índices de insucesso elevado (Standish Group, 2004a). No entanto, medir o sucesso dos projectos de TIC é complexo devido às várias definições de sucesso. De uma forma simplista, sucesso pode ser medido em termos de satisfação de prazos, orçamentos e funcionalidades ou serviços entregues (Standish Group, 1998). A análise do relatório Chaos do Standish Group (Standish Group, 2001, 2004a, 2006) ao longo dos últimos anos mostra uma melhoria significativa nos aspectos de entrega de projecto dentro do orçamento e de acordo com a especificação. O número de falhas também foi reduzido significativamente, considerando que o número de projectos duplicou em oito anos de pesquisa. Contudo, quase metade dos projectos mantém-se no estado de desafio (challenged) conforme indicado na Tabela 3.1. De acordo com o Standish Group, isto significa que à data estes projectos ultrapassavam o tempo e orçamento previstos ou estavam sub-especificados. Estado Sucesso 16% 27% 26% 28% 34% 29% 35% Falha 31% 40% 28% 23% 15% 18% 19% Desafio 53% 33% 46% 49% 51% 53% 46% Tabela 3.1: Taxa de sucesso de projectos de tecnologias de informação e comunicação Fonte: Coligido a partir dos relatórios do Standish Group (Standish Group, 2006) e de Schwalbe (Schwalbe, 2002). De modo a evitar as usuais falácias sobre os baixos retornos nos grandes investimentos em TIC, o sucesso dos projectos de TIC deve também ser medi- [PJMG quality, 50]

85 CONCEITOS DA ÁREA DA GESTÃO DE PROJECTOS do em termos do valor proporcionado aos accionistas da empresa e da sua contribuição para que a empresa atinja os seus objectivos estratégicos (Shenhar, Renier, & Wideman, 1996). O critério que tem precedência depende da natureza do projecto, dos seus objectivos e da política ou cultura das organizações envolvidas. Outras perspectivas sobre falha e sucesso foram alvo de estudo de Linberg (Linberg, 1999), que aponta como relevante a gestão de expectativas realizadas. Apesar destas visões mais abrangentes sobre a definição de sucesso e falha dos projectos de TIC, os técnicos e os gestores sentiram (e sentem) a necessidade de respostas da gestão de projecto específicas para as realidades dos projectos de software (B Hughes & M Cotterell, 2002). Surgiu então a área do Software Project Management (SPM). A SPM envolve a gestão de todos os aspectos e assuntos que estão relacionados com o desenvolvimento de um projecto de software, nomeadamente identificação do âmbito e dos objectivos dos projectos, monitorização e controlo, gestão do risco, controlo e alocação de recursos bem como ainda a gestão de contratos, qualidade e equipas. Inicialmente foram aplicadas ao desenvolvimento de software as técnicas tradicionais de GP. Existem diversas abordagens standard de GP que são aplicáveis a diferentes áreas do SPM, tais como PMBoK (PMI, 2000), PRINCE2 (Commerce, 2005) e BS6079 (Institute, 2000). Apesar disso, ao longo do tempo os métodos da GP não endereçavam as características únicas do desenvolvimento de software (B Hughes & M Cotterell, 2002). Isto levou ao desenvolvimento da SPM como uma área de aplicação e de estudo independente. 3.4 CONCEITOS DA ÁREA DA GESTÃO DE PROJECTOS Nesta secção são apresentados os principais conceitos utilizados no domínio do estudo da GP. As definições utilizadas provêm do PMBoK (PMI, 2004a) e de Kathy Schwalbe (Schwalbe, 2002). As definições baseadas nestas referências dão o contexto necessário para análises posteriores. Sempre que adequado são explicitamente introduzidos na discussão outros autores. Os projectos distinguem-se das tarefas operacionais habituais no sentido em que são temporários, são únicos, tem um objectivo específico, têm uma data de início e de fim e requerem um conjunto diverso de Recursos Humanos (RH) com conhecimentos e competências necessários às tarefas a realizar (PMI, 2000). [PJMG quality, 51]

86 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS Numa organização, num dado momento, podem realizar-se diversos projectos em simultâneo. Um programa consiste num conjunto de projectos geridos de uma forma coordenada. A escolha dos projectos que devem ser desenvolvidos exige frequentemente uma avaliação das várias hipóteses possíveis, enquadrada com o plano estratégico da organização (Kenneth C Laudon & Laudon, 2006). Existem várias técnicas que ajudam na selecção dos projectos, embora não se trate de uma ciência exacta, tais como: Concentração nas necessidades que a organização como um todo identifica como sendo importantes e prioritárias; Categorização dos projectos de TIC em projectos de baixa, média ou alta prioridade, considerando critérios como, entre outros, problemas, oportunidades, directivas ou a duração que tornem mais evidente a escolha; Análise financeira das várias hipóteses de projectos, como por exemplo, Net Present Value 2, Return on Investment 3 ou Payback Analysis 4. Decididos quais os projectos que fazem parte do programa, é necessário concretizá-los efectuando a gestão de cada projecto. A Figura 3.1 apresenta um framework que contém os elementos principais da GP: os actores (stakeholders) do projecto, as áreas de conhecimento (knowledge areas) e as ferramentas e técnicas utilizadas (tools and techniques). 2 O Net Present Value de um investimento e/ou projecto é a diferença entre o valor presente da soma dos fluxos de entrada de dinheiro que se esperam do investimento e o valor presente da quantia investida inicialmente. Esta abordagem permite considerar o factor da desvalorização do capital ao longo do tempo. 3 O Return On Investment é um indicador de desempenho de um investimento e/ou projecto e de comparação entre investimentos e/ou projectos. Corresponde ao rácio entre o dinheiro ganho (ou perdido) num investimento e/ou projecto e o dinheiro investido nesse projecto e/ou investimento (a valores presentes). 4 O Payback corresponde ao tempo que demora a recuperar o valor investido nos custos de instalação de um investimento e/ou projecto. [PJMG quality, 52]

87 AS PRINCIPAIS ÁREAS DE CONHECIMENTO DA GESTÃO DE PROJECTOS Os actores são as pessoas envolvidas ou afectadas pelo projecto e pelas actividades do projecto, tais como o patrocinador do projecto, a equipa do projecto, pessoal de suporte, operadores, utilizadores, fornecedores e até mesmo oponentes ao projecto. As necessidades das pessoas e as suas expectativas são importantes no início e ao longo da vida do projecto. Figura 3.1: Framework de gestão de projectos Fonte: Adaptado de (Schwalbe, 2002) Os gestores de projecto devem estabelecer um bom relacionamento com os vários actores de modo a assegurar que as suas necessidades e expectativas são compreendidas, geridas e atingidas. As áreas de conhecimento identificadas na figura são apresentadas em seguida. 3.5 AS PRINCIPAIS ÁREAS DE CONHECIMENTO DA GESTÃO DE PROJECTOS As áreas de conhecimento descrevem as competências chave que os gestores de projecto devem desenvolver. No centro estão as nove áreas da GP segundo o PMBok (PMI, 2000) e Kathy Schwalbe (Schwalbe, 2002). As quatro áreas base da GP são: gestão do âmbito, gestão do tempo, gestão do custo e gestão da [PJMG quality, 53]

88 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS qualidade. Estas são consideradas como áreas base uma vez que levam à concretização de objectivos específicos do projecto: A gestão do âmbito consiste na definição e na gestão de todo o trabalho necessário para a realização, com sucesso, do projecto; A gestão do tempo envolve estimar a duração do projecto, desenvolver um calendário do projecto e assegurar a conclusão a tempo do projecto; A gestão do custo prepara e gere o orçamento do projecto; A gestão da qualidade garante que o projecto satisfará as necessidades na medida em que foram requeridas. As restantes quatro áreas de conhecimento são a gestão de recursos humanos, de risco, de comunicação e de compras. Estas são consideradas como áreas facilitadoras porque são os meios através dos quais os objectivos do projecto são atingidos: A gestão de RH preocupa-se em tornar efectiva a participação das pessoas envolvidas no projecto; A gestão da comunicação envolve gerar, agregar, distribuir e armazenar a informação do projecto; A gestão do risco identifica, analisa e elabora respostas aos riscos associados ao projecto; A gestão das compras trata da identificação e aquisição de produtos ou serviços que são necessários ao projecto e que se encontram fora da organização. A gestão da integração é a área que afecta e é afectada por todas as outras áreas de conhecimento. Os gestores de projecto devem ter conhecimento e competências em todas as nove áreas. As técnicas e as ferramentas auxiliam os gestores de projecto e as equipas de projecto na execução das suas tarefas nas diversas áreas de conhecimento. Na secção seguinte serão descritas mais em detalhe as áreas de conhecimento que a GP envolve. Cada uma das áreas é composta por uma série de processos. Embora não existam receitas para executar os vários processos e as suas tarefas, existem processos com práticas centrais que devem ser realizadas. Na Figura 3.2 seguinte [PJMG quality, 54]

89 AS PRINCIPAIS ÁREAS DE CONHECIMENTO O DA GESTÃO DE PROJECTOS PROJE podem ver-se se os processos principais de cada uma das áreas do conhecimento da gestão de projectos. Esses Esses processos foram definidos pelo PMI nas suas edições do Project Management Body of Knowledge (PMBOK) dos anos de 2000 e 2004 (PMI, 2000, 2004b).. Figura 3.2: Processos das áreas do conhecimento da gestão de projectos Fonte: (Catarino, 2008), baseado em (PMI, 2000, 2004b) Gestão do âmbito mbito O âmbito refere-se se a todo o trabalho envolvido na criação dos produtos do projecto e dos processos usados na sua criação. Os actores do projecto têm de chegar a um acordo acordo sobre quais devem ser os produtos do projecto e como devem ser produzidos. A gestão do âmbito mbito inclui os processos envolvidos na definição e no controlo do que deve estar e não deve estar incluído no projecto. O objectivo é garantir que a equipa de projecto ojecto e os restantes actores têm o mesmo entendimento sobre que produtos serão realizados como resultado resultado do projecto e que procesproce sos serão usados na sua concretização. Os principais processos envolvidos na gestão do âmbito são: [PJMGquality, 55]

90 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS Iniciação: que implica o compromisso da organização para o início ou para a continuação para uma nova fase de um projecto. Um dos artefactos (deliverables) dos processos de iniciação é a declaração do projecto, que é um dos documentos chave não só para formalizar o reconhecimento da existência de um projecto, como também para dar uma visão abrangente sobre o projecto; Planeamento do âmbito: que envolve o desenvolvimento de documentos que fornecem a base para futuras decisões de projecto, incluindo os critérios para determinar se um projecto ou fase foi completado com sucesso. A equipa de projecto realiza o documento de âmbito do projecto e o plano de projecto como resultado do processo de planeamento do âmbito; Definição do âmbito: consiste na subdivisão dos artefactos do projecto em componentes menores e mais geríveis. Resulta deste processo uma estrutura de artefactos a produzir denominada work breakdown structure; Verificação do âmbito: formalização da aceitação do âmbito do projecto. Actores chave do projecto, tais como o cliente e o patrocinador, aceitam formalmente os artefactos do projecto durante este processo; Controlo da mudança de âmbito: gerir as mudanças de âmbito e os seus impactos. As mudanças de âmbito, as acções correctivas e as lições aprendidas são os artefactos deste processo Gestão do tempo A gestão de tempo consiste, numa forma simplista, em garantir que o projecto se conclui no tempo previsto. Os principais processos envolvidos na gestão de tempo são: Definição das actividades: identificação específica e detalhada das actividades que a equipa de projecto e restantes actores têm de realizar de modo a produzir os artefactos do projecto. Uma actividade ou tarefa é um elemento de trabalho que representa uma parte do projecto e que ocorre durante um período de tempo, duração esperada, tem um custo e recursos associados. Estes elementos de trabalho encontram-se usualmente na work breakdown structure; [PJMG quality, 56]

91 AS PRINCIPAIS ÁREAS DE CONHECIMENTO DA GESTÃO DE PROJECTOS Sequenciação das actividades: identificação e documentação das relações entre as actividades dos projectos; Estimativa da duração das actividades: estimativa do número de períodos de trabalho necessário para completar cada actividade; Desenvolvimento do calendário do projecto: análise da sequência das actividades, as estimativas de duração e os requisitos de recursos de modo a criar o calendário do projecto; Controlo do calendário: controlo e gestão de mudanças ao cronograma Gestão do custo A gestão do custo de um projecto procura garantir que este é completado dentro do orçamento aprovado. Os gestores de projecto têm de garantir que os seus projectos estão bem definidos, têm estimativas de tempo e de orçamento realísticas e que estão envolvidos na sua definição e aprovação. Os processos da gestão do custo são: Planeamento de recursos: determinar que recursos (pessoas, competências, equipamento e materiais) e que quantidades se devem utilizar para realizar as actividades do projecto. A saída do planeamento de recursos é uma lista de requisitos de recursos; Estimativa de custos: consiste em desenvolver uma estimativa dos custos dos recursos necessários à realização do projecto. As principais saídas do processo de estimativa de custos são as estimativas, a documentação de suporte a essas estimativas e o plano da gestão de custos; Baseline de custo: alocação do custo estimado aos itens individuais de trabalho permitindo criar uma baseline para medição do desempenho. A principal saída deste processo é, pois, a baseline de custos; Controlo de custos: controlo das mudanças ao orçamento do projecto. As principais saídas do processo são estimativas de custos revistas, actualizações do orçamento, acções correctivas, estimativa do custo do projecto com base no desempenho até ao momento, e lições aprendidas. [PJMG quality, 57]

92 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS Gestão da qualidade Segundo a International Organization for Standardization qualidade é a totalidade das características de uma entidade que permitem satisfazer necessidades explícitas ou implícitas (Standardization, 2006). O grande objectivo da gestão da qualidade é o de assegurar que o projecto satisfaz as necessidades que levaram à sua realização. A gestão da qualidade envolve atingir ou exceder as expectativas dos clientes. No entanto é necessário perceber bem o que significa qualidade para o cliente. Em última análise é o cliente que decide o que significa qualidade aceitável. A gestão da qualidade envolve três processos principais: Qualidade do planeamento: identificação de quais os standards de qualidade que são relevantes para o projecto e como os satisfazer; Garantia de qualidade: avaliação periódica do desempenho do projecto de modo a assegurar que o projecto satisfará os standards de qualidade especificados; Controlo de qualidade: consiste em monitorizar os resultados do projecto de modo a, por um lado, assegurar que estes estão em conformidade com os standards especificados e, por outro, a procurar formas de melhorar a qualidade global do projecto Gestão de recursos humanos A gestão de RH procura a melhor utilização das pessoas envolvidas no projecto. Nos RH de um projecto incluem-se todos os actores do projecto: patrocinadores, clientes, os membros da equipa de projecto, pessoal de suporte, fornecedores, entre outros. Os principais processos envolvidos na gestão de RH são: Planeamento organizacional: identificar, atribuir e documentar os perfis dos membros da equipa do projecto, responsabilidades e relações hierárquicas. As saídas-chave deste processo incluem os papéis e as atribuições de responsabilidades (usualmente apresentadas sob a forma de uma matriz) e o organograma do projecto; Aquisição do staff: que envolve ir buscar, ou garantir a disponibilidade, do pessoal necessário ao projecto; Desenvolvimento da equipa: implica a construção de um conjunto de competências individuais de modo a conseguir um desempenho [PJMG quality, 58]

93 AS PRINCIPAIS ÁREAS DE CONHECIMENTO DA GESTÃO DE PROJECTOS de equipa (e não apenas de grupo), onde o desempenho final é maior do que o da soma das partes Gestão da comunicação O objectivo da gestão da comunicação num projecto é garantir a recolha, o armazenamento, a geração apropriada e a tempo, a disseminação e a disponibilidade da informação do projecto. Os principais processos da gestão da comunicação são: Plano de comunicações: consiste em determinar a informação necessária para cada actor e quais as necessidades de comunicação entre eles. Corresponde a responder às questões: Quem precisa de informação? De que informação? Quando e como deve ser fornecida? Distribuição da informação: garantir que a informação é disponibilizada atempadamente; Geração de relatórios de desempenho: recolha e disseminação de informação de desempenho incluindo relatórios de estado, medição de progresso e previsões; Fecho administrativo: gerar, recolher e disseminar informação para formalizar a conclusão de fase ou projecto Gestão do risco A gestão do risco consiste em identificar, analisar e responder ao risco ao longo da vida de um projecto. Envolve detectar potenciais problemas e os seus impactos no caso de ocorrerem, para que seja possível colocar em prática um conjunto de acções que previna/minore esses efeitos. Os principais processos envolvidos na gestão do risco são: Planeamento da gestão do risco: decidir como abordar e planear as actividades de gestão do risco para o projecto. As saídas deste projecto são o planeamento da gestão do risco, as categorias do risco e informação de histórico; Identificação do risco: determinar que riscos são passíveis de afectar o projecto e documentar as características de cada um deles. As [PJMG quality, 59]

94 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS saídas do planeamento da gestão do risco são as entradas deste processo; Análise qualitativa do risco: caracterização e análise dos riscos ordenando por prioridades os seus efeitos nos objectivos do projecto. Após a identificação dos riscos, a equipa de projecto pode criar um ranking dos riscos do projecto; Análise quantitativa do risco: consiste em medir a probabilidade e as consequências dos riscos e estimar os seus efeitos nos objectivos dos projectos (análise de impacto). Com base neste trabalho é possível estimar probabilidades de cumprimento dos objectivos do projecto; Plano de resposta ao risco: plano de medidas concretas que permitam prevenir os riscos ou que possam fazer face a riscos que se venham a verificar; Controlo e monitorização do risco: acompanhamento dos riscos, verificação da sua evolução, identificação de novos riscos, actualização do estado dos riscos, da sua probabilidade de ocorrência, e dos seus planos de resposta Gestão de aquisições A gestão de aquisições inclui os processos necessários para a aquisição a terceiros de bens e/ou serviços para a realização do projecto. Os processos principais são: Planeamento das aquisições: envolve determinar o que comprar e quando. É preciso decidir de que se vai fazer outsourcing, determinar o tipo de contrato e criar uma declaração de trabalho; Plano de solicitações: consiste em desenvolver documentos como um Request For Proposal e desenvolver critérios de avaliação de propostas; Solicitações: obtenção de cotações e propostas associadas; Selecção de fornecedores: este processo avalia as várias ofertas dos fornecedores, negocia os contratos e atribui um contrato a um fornecedor; [PJMG quality, 60]

95 CICLO DE VIDA DO PROJECTO Administração de contratos: consiste na gestão da relação com o fornecedor e inclui o acompanhamento do desempenho, a realização de pagamentos e a gestão das mudanças ao contrato; Fecho de contratos: verificação do produto ou serviço, aceitação formal e auditoria do contrato Gestão da integração A gestão de integração envolve coordenar todas as outras áreas de conhecimento ao longo do ciclo de vida de um projecto. Pretende-se garantir que todos os elementos do projecto se encontram realizados e concluídos no tempo certo para que este se finalize com sucesso. Os processos principais envolvidos na gestão de integração são: Desenvolvimento do plano de projecto: que consiste em colocar os resultados dos outros processos de planeamento de uma forma consistente e coerente num único documento; Execução do plano de projecto: que consiste na execução do plano de projecto através da realização das actividades nele incluídas; Controlo integrado da mudança: que envolve coordenar as mudanças ao longo de todo o projecto e em todas as áreas envolvidas e afectadas pela mudança. 3.6 CICLO DE VIDA DO PROJECTO Para lidar com o grau de incerteza inerente a qualquer projecto, este é decomposto num conjunto de fases a que se dá o nome de ciclo de vida do projecto. As fases de um projecto variam de acordo com o projecto em si e com a indústria a que diz respeito. No entanto, algumas fases são comuns a todos os projectos: concepção, desenvolvimento, implementação e fecho. As duas primeiras, concepção e desenvolvimento, são referidas como as fases de estudo de viabilidade e as duas últimas, implementação e fecho, como as fases de aquisição. Na fase da concepção é feita uma descrição breve do projecto com a motivação para o desenvolvimento do projecto, os conceitos base, um plano de trabalho de alto nível e uma estimativa de custo. No final desta fase a gestão de projecto deve entregar um relatório e uma apresentação com esta informação. O relatório e a apresentação são exemplos de artefactos resultantes (deliverables) [PJMG quality, 61]

96 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS de uma fase. Um artefacto é neste contexto um produto produzido como parte de um projecto. Após a fase de concepção estar completa e a passagem à próxima fase estar aprovada pela organização, segue-se o desenvolvimento, onde a equipa de projecto desenvolve um plano mais detalhado, uma estimativa de custo mais precisa e um plano de trabalho mais elaborado. A terceira fase é a implementação. Nesta fase a equipa de projecto desenvolve o trabalho necessário à realização do projecto. Cria para isso uma estimativa de custo definitiva, segue um calendário detalhado de trabalho e gera relatórios de evolução do projecto para os actores. Na última fase, a fase de fecho, todo o trabalho deve ser completado e deve-se proceder à aceitação do projecto por parte do cliente. A equipa de projecto deve documentar as suas experiências e as lições aprendidas. Com base nos artefactos produzidos, o projecto é avaliado no final de cada fase. Só então se decide se este deve prosseguir para a fase seguinte. Deste modo, para avaliar o progresso do projecto, para garantir que continua no bom caminho, para corrigir eventuais desvios, ocorrem, no final de cada uma das fases, as chamadas revisões de fase (phase exits ou kill points). Desta forma é possível avaliar e controlar os custos e os riscos associados ao projecto. Em cada fase decorrem processos associados a cada uma das áreas de conhecimento anteriormente apresentadas. No contexto do PMBoK (PMI, 2000), um processo é um conjunto de acções que visa produzir um resultado. No caso dos processos de gestão, o resultado pretendido é a descrição detalhada das actividades e respectiva organização de forma a completar o projecto. Os processos de gestão das nove áreas de conhecimento pertencem a um dos cinco grupos possíveis: Iniciação processos que autorizam a fase ou projecto; Planeamento processos que definem e refinam os objectivos do projecto determinando o melhor curso de acção a seguir; Execução processos responsáveis pela coordenação de pessoas e recursos para levar a cabo o plano de projecto; [PJMG quality, 62]

97 CICLO DE VIDA DO PROJECTO Controlo processos que controlam e asseguram que os objectivos do projecto são alcançados; Encerramento contém os processos que permitem formalizar o encerramento de uma fase ou do próprio projecto. Um projecto só transita para a fase seguinte se a fase anterior for formalmente encerrada, excepto se o risco for aceitável e as fases decorrerem paralelamente (fast tracking). Um projecto é declarado como concluído quando todas as suas fases forem totalmente encerradas. A Figura 3.3 ilustra a distribuição dos grupos de processos relativamente a qualquer fase do projecto. Dentro da mesma fase os vários grupos estão interligados, as saídas de um grupo constituem as entradas para os processos de outro grupo (ver Figura 3.4). Figura 3.3: Sobreposição dos grupos de processos em cada fase do projecto Fonte: Adaptado de (PMI, 2000) [PJMG quality, 63]

98 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS Figura 3.4: Ligações entre os grupos de processos em cada fase do projecto Fonte: Adaptado de (PMI, 2000) Cada processo é caracterizado por um conjunto de entradas, um conjunto de saídas e técnicas e ferramentas utilizadas para as produzir. Podemos ver na Figura 3.5 a interacção entre fases do projecto. Figura 3.5: Interacção entre fases do projecto Fonte: Adaptado de (PMI, 2000) [PJMG quality, 64]

99 DESENVOLVIMENTO DE PROJECTOS E DESENVOLVIMENTO DE SISTEMAS 3.7 DESENVOLVIMENTO DE PROJECTOS E DESENVOLVIMENTO DE SIS- TEMAS É importante distinguir entre desenvolvimento de sistemas e desenvolvimento de projectos. Os profissionais das TIC estão familiarizados com o conceito de ciclo de vida de desenvolvimento de sistemas (systems development life cycle), usado para descrever as fases envolvidas no desenvolvimento e manutenção dos SI. Estas fases são usualmente descritas como planeamento, análise, desenho, implementação e suporte de SI. Outro conceito familiar é o de engenharia de software, que é a área de conhecimento que estuda os princípios, metodologias, modelos, técnicas e ferramentas do desenvolvimento de software. Alguns dos modelos de ciclo de vida de desenvolvimento de sistemas mais conhecidos são o modelo Linear Sequencial (waterfall), o modelo Espiral winwin de Boehm, o modelo Incremental, o modelo Rapid Application Development (RAD), o modelo Prototipagem, os modelos Ágeis e o Rational Unified Process (RUP) da Rational. O modelo Linear Sequencial apresenta uma sequência de passos bem definidos para o desenvolvimento de sistemas. Uma vez concluído um dos passos não é possível, segundo o modelo, voltar ao passo anterior. Por este motivo, aspectos importantes como a gestão da mudança de requisitos e controlo de versões, a título de exemplo, não são abrangidos pelo modelo. Apesar das grandes limitações que apresenta, este modelo representa uma referência da engenharia de software por ter sido o primeiro modelo de desenvolvimento estruturado de sistemas. O modelo Espiral introduziu os conceitos de gestão de risco e de desenvolvimento com base em iterações. O modelo Incremental assenta no desenvolvimento de software baseado em versões, em que cada versão adiciona funcionalidades à versão anterior, aproximando-se assim, progressivamente, dos requisitos do produto e permitindo a evolução dos mesmos. O modelo RAD tem como objectivo a produção rápida de sistemas com o menor sacrifício da qualidade e inclui quatro fases: planeamento de requisitos, desenho das interfaces para o utilizador, construção e finalização. As ferramentas RAD potenciam a rápida prototipagem e a geração do código. [PJMG quality, 65]

100 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS O modelo Prototipagem é utilizado quando é necessário clarificar de uma forma rápida e eficaz os requisitos do utilizador. Os modelos Ágeis, como o Extreme, são baseados em quatro valores: comunicação, simplicidade, feedback, e coragem. São modelos incrementais que se baseiam em desenvolvimento rápido de pequenas releases. Com o feedback adequado estas releases vão sendo continuamente revistas até se atingirem os objectivos. Por fim, o RUP é um modelo de desenvolvimento orientado à formalidade e à documentação, sendo aplicado a projectos de grande dimensão. Todos estes modelos são exemplos de ciclos de vida de desenvolvimento de sistemas, existindo inúmera informação sobre esta área (Boehm, 1996; Ghezzi, Jazayeri, & Mandriolli, 2003; Kruchten, 1996; Pfleeger, 2001; Pressman, 2000). O tipo de software e a complexidade do SI a ser desenvolvido determina que modelo utilizar. É importante distinguir os conceitos de ciclo de vida de um projecto e ciclo de vida de desenvolvimento de sistemas. Por exemplo, a fase de planeamento para um novo SI pode incluir um projecto para a contratação de uma empresa externa para ajudar a identificar e avaliar as várias hipóteses para o desenvolvimento de uma aplicação em particular, tal como um novo sistema de processamento de encomendas ou de gestão de stocks. Esta fase pode incluir tarefas como a realização de um inquérito aos utilizadores sobre os actuais SI utilizados actualmente na organização. Por outro lado, a fase de análise dos sistemas pode incluir um projecto para redesenhar processos para uma dada área de negócio. Pode também abranger um projecto para criar novos modelos de dados (ou reformular existentes). Todos estes exemplos mostram que os produtos de TIC de dimensão considerável são compostos de vários projectos, onde são aplicados os princípios, as metodologias, as técnicas e as ferramentas de GP. No desenvolvimento de SI, a GP é uma actividade ortogonal mas sempre presente, ou seja, é realizada em todas as fases de qualquer modelo de desenvolvimento do produto. Por este motivo a GP é tão fundamental nas TIC (Schwalbe, 2002). [PJMG quality, 66]

101 NOVAS ABORDAGENS E OPORTUNIDADES DE INVESTIGAÇÃO NA ÁREA DA GESTÃO DE PROJECTOS 3.8 NOVAS ABORDAGENS E OPORTUNIDADES DE INVESTIGAÇÃO NA ÁREA DA GESTÃO DE PROJECTOS De acordo com estudos efectuados (Demarco, 1997; Ewusi-Mensah, 2003; Jones, 2004; Kappelman, McKeeman, & Zhang, 2006; Standish Group, 1996, 1998; Yetton, Martin, Sharma, & Johnston, 2000), alguns dos principais aspectos que aumentam a probabilidade de falhas dos projectos de TIC são: Falta de especificação e visão clara dos requisitos; Expectativas irrealistas devido à má estimativa e a constrangimentos políticos nas organizações; Falta de decomposição do projecto, ou seja, o nível de detalhe em que o projecto é decomposto não é o suficiente para se realizar uma boa estimativa de âmbito, duração, recursos necessários e custos associados; Má gestão de RH e de conflitos; Falta de apoio e de foco no projecto por parte dos actores do projecto; Falta de foco estratégico e de apoio da gestão de topo. O facto do insucesso dos projectos de TIC ser ainda significativo e o facto de se conseguirem identificar aspectos chave como causas das suas falhas, levam a que a investigação prossiga na procura de metodologias, frameworks, métodos, técnicas e ferramentas com vista a melhorar o desenho, a implementação e, em última instância, o sucesso dos projectos, com o objectivo de dar resposta às necessidades particulares e específicas da GP de projectos em TIC. Neste contexto, surge, na área da análise e especificação de requisitos, uma nova área de estudo Requirements Interaction Management (Robinson, Pawlowski, & Volkov, 2003) que procura analisar se um sistema pode satisfazer um determinado conjunto de requisitos em simultâneo. A satisfação de um requisito pode invalidar a satisfação de outros (Lamsweerde, 2000). Dada a dimensão dos projectos de TIC e reconhecendo-se que os erros de concepção são os mais difíceis de rectificar é relevante identificar e gerir, aquando da análise e especificação de requisitos, as relações críticas que existem entre eles, e que não são óbvias sem a ajuda de métodos específicos. [PJMG quality, 67]

102 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS Na área das estimativas de recursos existem novas abordagens, como um modelo causal proposto por Fenton (Fenton et al., 2004), que permite incorporar não só dados de histórico de projectos, como ainda a experiência de peritos. Deste modo é possível ultrapassar os modelos baseados no cálculo da dimensão do problema, como os métodos do número das linhas de código e, mais tarde, o dos pontos de função, que não tinham em conta factores como as pessoas e as suas competências e os processos. A gestão de expectativas e adequação das competências às novas práticas implementadas para controlo de projectos surge também como um desafio. Os aspectos da gestão de RH têm sido objecto de inúmeros estudos desde a vertente da gestão de conflitos (Barki & Hartwick, 2001) até à vertente da diversidade da constituição das equipas (G. Klein, Jiang, & Tesch, 2002) e das suas relações pessoais (Aiken, 2004), em ambos os casos de modo a reduzir o risco dos projectos. Nesse sentido é importante que os gestores de projecto percebam como os vários tipos de riscos afectam os resultados dos projectos (Wallace& Keil, 2004). Com o objectivo de incorporar os aspectos estratégicos e de focus, quer da gestão de topo, quer dos actores do projecto, surgem novas abordagens como, por exemplo, a aplicação dos conceitos de Balanced Scorecard (Schwartz, 2008), utilizadas na gestão estratégica e do desempenho das organizações, à GP de TIC (Brock, Hendricks, Linnell, & Smith, 2003). Surge então a oportunidade de desenvolver novas práticas com a missão de endereçar os desafios estratégicos para uma gestão mais eficaz e adaptada às novas necessidades. Tradicionalmente os projectos de TIC eram concretizados pela equipa de projecto e restantes actores do projecto numa única localização geográfica e com elementos culturalmente próximos. Contudo, devido à globalização e aos avanços nas tecnologias da computação, esta realidade alterou-se, sendo hoje desenvolvidos e entregues em ambientes distribuídos e colaborativos. Isto significa que os tradicionais métodos de GP não respondem às complexidades adicionais que se encontram num sistema distribuído. Tornam-se necessários níveis elevados de colaboração, interdependência entre tarefas e distribuição ao longo do tempo, espaço e tecnologia (Nienaber & Cloete, 2003). Estes novos desafios, derivados da globalização e dos avanços da tecnologia e da sua diversidade levam a que surjam ferramentas baseadas em agentes de software (Krupansky, 2003; Nienaber & Cloete, 2003) de suporte aos processos da GP, de novos estudos sobre a gestão de RH em ambientes virtuais (Beise, 2004) e [PJMG quality, 68]

103 EVOLUÇÃO DA GESTÃO DE PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE da gestão de configurações (Estublier et al., 2005; Nguyen, Munson, & Boyland, 2005). Um dos grandes desafios da actualidade situa-se na GP em que se exige a coordenação de equipas provenientes de diferentes áreas tecnológicas e de várias práticas. A evolução das tecnologias levou ainda a que o processo de desenvolvimento de novos SI evoluísse do desenvolvimento à medida para a agregação de componentes off-the-shelf (Commercial Off-The-Shelf software). Esta mudança reduziu, de uma forma significativa, os custos e tempos de desenvolvimentos em projectos de e-business (Horowitz & Lambert, 2006). Trouxe, no entanto, novos riscos e novos desafios à GP. Os métodos, as técnicas, a gestão de RH, de comunicação e todos os aspectos relacionados com a GP, são totalmente diferentes dos projectos de desenvolvimento de software tal como os conhecíamos (Horowitz& Lambert, 2006). 3.9 EVOLUÇÃO DA GESTÃO DE PROJECTOS DE DESENVOLVIMENTO DE SOFTWARE Os projectos de TI são cruciais no crescimento económico. Existe, na actualidade, um crescente investimento de capital, em tecnologias da informação e comunicação, que gera valor através de projectos que colocam a tecnologia ao serviço da sociedade. Este crescimento ao longo dos anos introduziu mudanças e transformações em várias áreas do trabalho e da própria sociedade. Actualmente em muitas áreas é difícil imaginar a vida sem sistemas e ferramentas de TI. Devido a este facto, a sua importância não pode ser subestimada. Contrastando com a sua importância, os projectos de TI têm tido uma reputação menos feliz junto do público no que concerne ao desempenho. Os estudos do Standish Group CHAOS Report reforçaram esta visão do custo elevado, dos prazos ultrapassados, do âmbito incompleto e do baixo desempenho. A justificação da alternativa do outsourcing é em parte justificada em termos de equipas com mais competências, incluindo os gestores de projectos. Em 1999 e em 2003 o Standish Group reportou algumas melhorias no desempenho de projectos de TI. Um dos objectivos é melhorar significativamente o desempenho; para tal, um dos principais alvos é melhorar a forma como os projectos são geridos. Outro alvo é a capacidade organizacional na gestão de projectos. Para as organizações que têm vários projectos a decorrer, quer internos ou através [PJMG quality, 69]

104 CAPÍTULO TRÊS - GESTÃO DE PROJECTOS de outsourcing, um dos alvos passa pela redução em média, dos custos que eventualmente são ultrapassados em todos os projectos existentes. A evolução das tecnologias levou ainda a que o processo de desenvolvimento de novos sistemas de informação evoluísse do desenvolvimento à medida para a agregação de componentes off-the-shelf (COTS Commercial off-the-shelf software). Esta mudança reduziu de uma forma significativa os custos e tempos de desenvolvimentos em projectos de e-business Trouxe, no entanto, novos riscos e novos desafios à gestão de projectos. Os métodos, as técnicas, a gestão de recursos humanos, de comunicação, etc., são totalmente diferentes dos projectos de software tal como os conhecíamos (Horowitz & Lambert, 2006). No que diz respeito ao posicionamento hierárquico da gestão de projectos numa organização, verifica-se actualmente que a gestão de projectos fornece uma metodologia de gestão e um conjunto de técnicas e ferramentas, para que os projectos sejam geridos com sucesso e como forma de responder à gestão de topo pela implementação bem sucedida ou não dos projectos no terreno. Verifica-se, assim, que a gestão de projectos se enquadra num posicionamento hierárquico entre o nível operacional e o nível estratégico da organização. Cumpriu-se, neste capítulo, o objectivo de identificação dos condutores contemporâneos da GP, de modo a caracterizar o seu estado da arte, tendências actuais e principais problemas. Foi ainda possível abordar os aspectos fundamentais da GP aplicada a projectos de TIC e da complexidade que estes apresentam face a outras áreas onde a GP está mais consolidada e desenvolvida. [PJMG quality, 70]

105 Capítulo 4 Gestão da Qualidade Qualidade não é uma acção, é um hábito Aristóteles Neste capítulo são apresentados conceitos fundamentais na área da gestão da qualidade. É definida a qualidade e respectivas actividades que a compõem. São definidos os elementos chave da abordagem Total Quality Management. São detalhadas as normas e referenciais dos sistemas de gestão da qualidade. This chapter presents the main concepts in the area of quality management. Quality and the corresponding activities are defined. It is also defined the key elements of Total Quality Management approach. Finally it gives the rules and standards details of management quality systems. Para compreender em que consiste a gestão da qualidade em toda a sua extensão é fundamental clarificar alguns conceitos. Em primeiro lugar é essencial compreender o conceito de qualidade. Existem inúmeras definições para qualidade, dependendo do contexto e da época em que a definição foi elaborada. Esta variedade de definições resulta da dificuldade em definir e medir a qualidade. Actualmente, no âmbito da gestão de projectos, a qualidade pode ser definida por a totalidade das características de uma entidade que permitem satisfazer necessidades explícitas ou implícitas (ISO, 2000). Nos últimos anos, os pontos de vista da qualidade têm mudado radicalmente, sendo que hoje em dia a ênfase está a ser colocada mais na gestão da qualidade, fazendo com que a qualidade se torne numa forte estratégia de competitividade (Kerzner, 2001). Schulmeyer (1999) aborda os princípios da qualidade e a revolução causada no mundo da economia por esses conceitos, fornece uma visão geral de como estes conceitos poderiam ser usados na indústria de software. A qualidade não seria apenas slogan ou objectivos arbitrários e passaria a ser um meio de melhoria real aplicada através de estudos e acções sistemáticas (Schulmeyer & Mcmanus, 1999). [PJMG quality, 71]

106 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE 4.1 CONCEITO DE QUALIDADE Qualidade de software é definida pelo IEEE (The Institute of Electrical and Electronics Engineers) como o grau com que um sistema, componente ou processo atende: (1) aos requisitos especificados e (2) às expectativas ou necessidades de clientes ou utilizadores" (IEEE, Std 610) (IEEE, 1999). A ISO (The International Standards Organization) define, na Norma NP EN ISO 9000 (2000), a qualidade como grau de satisfação de requisitos dado por um conjunto de características intrínsecas. Segundo a mesma norma, requisito é a necessidade ou expectativa expressa, geralmente implícita ou obrigatória. Estas duas definições, provenientes de organizações respeitadas pela comunidade académica, mostram que a qualidade de um produto está estritamente ligada à satisfação de seus requisitos. Já em 1993, Juran (Juran, 1993) afirmava que se estava perante uma rápida expansão da competição internacional em qualidade. Segundo este autor essa expansão é causada pela convergência de forças como: a proliferação de multinacionais, uma crescente competição global, o desenvolvimento de mercados regionais que destroem proteccionismos e a protecção ambiental. Desta informação podemos retirar uma previsão lógica: The 20th century has been the century of productivity. The 21st century will be the century of quality (Juran, 1993). A qualidade passa de característica importante para característica fundamental e exigida pelo cliente, Feigenbaum em Litsikas (1995) (Litsikas, 1995) afirma a poor man can t afford to buy cheap, he has to buy quality, ser barato já não garante a conquista de mercados, mas uma qualidade duradoura permite esse objectivo (Ganhão, 1992). Belchior (Belchior, 1997), relacionando qualidade e software refere: Quando se deseja um produto de software de alta qualidade, deve-se assegurar que cada uma de suas partes constituintes possua alta qualidade (Humphrey, 1995). Portanto, os resultados intermediários, no processo de produção, devem ser imediatamente examinados após a sua conclusão, procurando garantir que erros e inadequações no produto sejam detectados o mais cedo possível, pois a qualidade final do produto é função de todas as fases anteriores de seu ciclo de desenvolvimento. (...) Qualidade, portanto, não significa somente excelência ou um outro atributo de um certo produto final. A qualidade deve ser perseguida dentro da organização pois, certamente, é isto o que os utilizadores esperam de um produto. [PJMG quality, 72]

107 CONCEITO DE QUALIDADE Pressman (2000) define qualidade de software como: Conformidade com os requisitos de desempenho, os requisitos funcionais explicitamente declarados, as normas de desenvolvimento explicitamente documentadas e, finalmente, as características implícitas esperadas em todo o software desenvolvido de forma profissional. Laudon (2001) afirma: As soluções para os problemas de qualidade de software incluem uma metodologia apropriada de desenvolvimento de sistemas, alocação de recursos apropriados durante o desenvolvimento dos sistemas, o uso de medidas e o uso de ferramentas. Menciona, também, a necessidade de ferramentas para a gestão de projectos, a produção, a reutilização e debugging de código, e a geração de testes. Basili (1994), ao discutir a qualidade de software no contexto do TQM (ou Total Quality Management, abordagem aplicada no Japão em 1950, formalmente designada TQM somente em 1985), refere que a qualidade é um conceito multidimensional, fazendo a ligação entre a qualidade e a satisfação do cliente e seus elementos chave (Basili, Kan, & Shapiro, 1994). Assim, os elementos do TQM são: (i) Foco no cliente; (ii) Melhoria de processo; (iii) Lado humano da qualidade; (iv) Dados, medidas, e análise. Nas dimensões da qualidade, podem ser incluídas: (v) A entidade interessada; (vi) O ponto de vista sobre essa entidade; (vii) Atributos de qualidade dessa entidade. A estreita relação dos conceitos de qualidade com o TQM levou Basili (1994) a afirmar: Para melhorar a qualidade durante o desenvolvimento, precisamos de modelos de processos de desenvolvimento; Para conseguir qualidade, todos os elementos do TQM precisam ser observados; Quando os requisitos do cliente são verificados, o desafio consiste em reflecti-los nos processos de desenvolvimento dos produtos; As revisões e as inspecções de software são diferentes das inspecções industriais; [PJMG quality, 73]

108 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE No desenvolvimento do software, a reutilização não deve ser limitada ao código; O que é medido é melhorado. 4.2 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS O conceito de qualidade deve ser compreendido como oferecendo valor ao cliente e deve reforçar a posição competitiva da empresa no seu mercado de actuação. Os Sistemas de Gestão da Qualidade devem estar alinhados às estratégias de negócio, sendo desdobrados em directrizes e objectivos organizacionais, que traduzam as necessidades dos clientes a todos os níveis da estrutura organizacional (Akao, 1997; Carvalho & Paladini, 2005; Merli, 1993). A própria estrutura da organização, deve ganhar maior flexibilidade por meio da abordagem por processos (T. Davenport, 1990). Qualidade não pode ser obtida por um esforço isolado de uma única área e não está restrita a acções num único nível organizacional. A qualidade não surge do acaso e é resultado de um esforço de planeamento. Por conseguinte, a área de Gestão da Qualidade e a Gestão de Projectos apresentam possibilidades de criação de sinergias (Prieto, Prieto, & Carvalho, 2005). Durante os últimos anos tem existido uma evolução no sentido de melhorar a qualidade dos projectos, não sendo apenas uma melhoria a nível do produto, mas sobretudo a nível da qualidade da liderança e da qualidade da gestão de projectos. Isto deve-se, em parte, ao facto dos clientes exigirem cada vez mais um melhor desempenho, um cumprimento dos requisitos mais rigoroso, mais rapidez no desenvolvimento do produto, níveis mais altos de tecnologias, menos defeitos e menos custos (Kerzner, 2001). Num estudo realizado por Deming concluiu-se que apenas 15% dos problemas da qualidade do projecto têm origem no nível operacional da organização, ou seja, na parte de fabrico dos produtos. Assim, 85% dos problemas de qualidade estão relacionados com o processo de construção do produto, no nível estratégico e no nível de gestão da organização, podendo ser resolvidos com uma gestão da qualidade mais eficiente (Kerzner, 2001). Um outro estudo, efectuado na China em 2004, concluiu que as organizações que têm dado uma importância significativa às normas e à gestão da qualidade têm obtido elevados benefícios (Sarkis & Zhu, 2004). Este estudo reforça a ideia que um projecto em que é realizada uma gestão cuidada da qualidade será, à partida, um projecto com maior probabilidade de ser bem sucedido. [PJMG quality, 74]

109 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS A nível de projectos de desenvolvimento de software a gestão da qualidade é apontada como uma necessidade, não só pelos gestores dos projectos ou pelos clientes, mas também pelos que os desenvolvem (Bezerra, 2004). Isto acontece essencialmente devido a algumas razões (McDaniel, 2002): este tipo de projectos apresenta uma enorme colecção de operações distintas; os problemas com estes projectos continuam a ser muitos; cada vez mais os SI desempenham actividades críticas nas organizações. Uma das principais causas apontadas para a reduzida qualidade dos projectos de desenvolvimento de software está relacionada com o facto de os problemas (ligados à qualidade) serem detectados demasiado tarde, muitas vezes por falta de ferramentas para analisar as métricas da qualidade dos programas (Liu, Kane, & Bambroo, 2006). A gestão da qualidade visa garantir a eficácia e eficiência de todas as actividades envolvidas no projecto, desenvolvimento e implementação de um produto ou serviço, relativamente ao sistema e ao seu desempenho (Pyzdek & Keller, 2003), ou seja, foca-se não só na qualidade do produto a obter, mas também nos meios ou processos utilizados para a sua obtenção. A gestão da qualidade é a área do conhecimento da gestão de projectos que visa garantir a satisfação das necessidades e dos objectivos que levaram à realização do projecto, sejam satisfeitos, conduzindo a uma melhoria contínua do projecto (Visschedijk, Hendriks, & Nuyts, 2005). É um aspecto que deve estar presente em todas as etapas do projecto, acompanhando todo o seu ciclo de vida, já que se a má qualidade for detectada no final da construção do produto, nada, ou muito pouco, poderá ser feito para resolver o problema (Liu, Kane, & Bambroo, 2006). A gestão da qualidade não é algo que se aplique num dado momento, mas é sim um processo contínuo de aprendizagem para a organização (Balla, Bemelmans, Kusters, & Trienekens, 2002). Segundo Amorim (2004), a qualidade organizacional deve existir necessariamente antes da instanciação da qualidade ao nível do projecto. A autora recomenda algumas dessas actividades de alcance organizacional: Definição dos objectivos da qualidade e de políticas de qualidade para a organização; Estabelecimento de procedimentos, padrões e métricas institucionais da qualidade; Estabelecimento de papéis e da função da qualidade na organização; [PJMG quality, 75]

110 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE Formatação do perfil para os profissionais envolvidos no processo de software; Realização de formação para os envolvidos no processo, para a disseminação dos conceitos da qualidade para a organização; Estabelecimento de controlo sobre os custos das actividades de qualidade nos projectos. Existem três processos principais que compõem a gestão da qualidade (Kerzner, 2001; PMI, 2004b): o planeamento da qualidade, a garantia da qualidade e o controlo da qualidade. No processo de planeamento da qualidade determinam-se os padrões de qualidade que são importantes para o sucesso do projecto. Depois de identificados devem-se descrever esses padrões e as formas de os satisfazer (PMI, 2004b). É necessário definir padrões de qualidade para todas as etapas de desenvolvimento dos produtos. No desenvolvimento de software esta necessidade é ainda mais relevante na medida em que existe um grande número de operações em cada fase de desenvolvimento (Liu, Kane, & Bambroo, 2006). Segundo o PMI (PMI, 2004b), o processo de planeamento da qualidade tem como entradas os factores ambientais da organização, os activos de processos organizacionais, a declaração do âmbito e o plano de gestão do projecto. Os factores ambientais da organização são regulamentos, regras, normas e directrizes do ambiente social onde a organização está inserida e que podem, de certa forma, afectar o projecto. Os activos de processos organizacionais são as políticas, procedimentos, regras de qualidade, conhecimentos adquiridos anteriormente e bases de dados específicas da organização. A declaração do âmbito do projecto documenta as principais entregas do projecto, assim como os objectivos que auxiliam na definição dos requisitos, limites de custo, tempo e recursos, assim como requisitos de desempenho e condições que levam a que as entregas do projecto sejam aceites. As saídas do processo de planeamento da qualidade incluem o plano de gestão da qualidade, as métricas da qualidade, as listas de verificação de qualidade, o plano de melhorias no processo, as linhas base da qualidade e as actualizações no plano de gestão do projecto. O plano de gestão de qualidade descreve a forma como os gestores implementam a política de qualidade da organização, funcionando como um componente auxiliar do plano de gestão do projecto. Este plano deve abordar o controlo da qualidade e a garantia da qua- [PJMG quality, 76]

111 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS lidade. As métricas são definições operacionais que descrevem algum facto, e dizem como ele é medido pelo controlo de qualidade. As listas de verificação da qualidade são ferramentas estruturadas que servem para verificar se as etapas necessárias foram executadas. Por vezes as organizações criam listas de verificação de qualidade padrão para facilitar a resolução de tarefas que se executam frequentemente. No plano de melhorias no processo as etapas de análise dos processos são descritas em detalhe, de forma a facilitar a identificação de desperdícios e de actividades sem valor agregado. Na linha de base da qualidade são registados os objectivos de qualidade do projecto que servem de base para a criação dos relatórios de desempenho. Por último, o plano de gestão do projecto é actualizado pela inclusão do plano de gestão da qualidade e o plano de melhorias nos processos auxiliares. Algumas técnicas que permitem transformar as entradas do planeamento da qualidade em saídas, são a análise de custo benefício, o custo da qualidade, o benchmarking em que se faz a comparação das práticas do projecto reais com as planeadas de outros projectos, e o projecto de experimentos que é um método estatístico que serve para identificar factores que influenciem variáveis específicas de um produto ou processo. O processo de garantia da qualidade tem como objectivo realizar avaliações periódicas ao desempenho do projecto. Aplicam-se as actividades de qualidade, previamente planeadas, com o objectivo de se perceber se o projecto está a respeitar os requisitos necessários. Qualquer indivíduo ou grupo pode executar esta tarefa desde que seja orientado e preparado para a sua realização (PMI, 2004b). Este processo tem como objectivo principal minimizar os riscos de incumprimento dos objectivos, dos prazos e dos custos (Kerzner, 2001). Segundo Kerzner, um bom sistema de garantia da qualidade é um sistema multifuncional, orientado à prevenção. O processo apela a uma melhoria contínua do projecto, inclui um plano para a criação e manutenção de medidas de desempenho e inclui auditorias da qualidade. Auditorias da qualidade são avaliações independentes, realizadas por pessoal qualificado que visam garantir que o projecto respeita os requisitos de qualidade (Kerzner, 2001). As entradas no processo de garantia da qualidade são em parte as saídas do processo anterior: o plano de gestão da qualidade, as métricas de qualidade e o plano de melhorias no processo. Este processo apresenta ainda outras entradas, como as informações sobre o desempenho do trabalho, solicitações de mudança aprovadas, medições no controlo da qualidade, solicitações de mudança implementadas, acções correctivas implementadas e reparo de defei- [PJMG quality, 77]

112 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE to implementado. As informações sobre o desempenho do trabalho referem-se às actividades do projecto. Assim, incluem, entre outros, a evolução do cronograma que inclui as actividades que já foram iniciadas e terminadas, as entregas terminadas e as não terminadas, se estão a ser respeitados os custos, os padrões de qualidade, as estimativas de tempo das actividades do cronograma e os recursos. Nas solicitações de mudança documentam-se por escrito as mudanças necessárias e as aprovadas que surgem durante a realização do projecto. Essas mudanças podem provocar alterações de políticas, planos de gestão de projectos, procedimentos, custos, orçamentos, cronogramas, métodos de trabalho e requisitos de produtos, qualidade e âmbito. As medições do controlo da qualidade apresentam os resultados das actividades de controlo da qualidade, de forma a analisar e avaliar os processos e os padrões de qualidade da organização. As solicitações de mudança implementadas são documentos com as mudanças que foram realizadas pela equipa de gestão do projecto quando o mesmo foi executado. As acções correctivas implementadas são as actividades de correcção que foram aprovadas e implementadas pela equipa, para que no futuro, os requisitos do projecto fiquem de acordo com o plano de gestão do projecto. As acções preventivas implementadas são os actos preventivos que foram aprovados e implementados, para reduzir os riscos negativos do projecto. Por último, os reparos de defeito implementados são as actividades executadas de forma a corrigir os defeitos dos produtos. As saídas da garantia da qualidade, que servirão de entrada no processo de controlo da qualidade, são as mudanças solicitadas, as acções correctivas recomendadas, os activos de processos organizacionais e o plano de gestão de projecto. As mudanças solicitadas relacionam-se com as alterações que são realizadas de forma a aumentar a eficácia e a eficiência do projecto e das políticas, processos e procedimentos da organização. As acções correctivas recomendadas são indicações que permitirão aumentar a eficácia e eficiência do projecto, de forma a garantir a qualidade do mesmo. Os activos de processos organizacionais e o plano de gestão de projectos, neste caso, são apenas actualizações dos documentos já criados noutros processos, ou seja, no planeamento da qualidade e nos processos da gestão da integração, respectivamente. Estas actualizações são realizadas com vista a uma melhoria contínua nos processos, de forma a aumentar a probabilidade de se cumprirem os padrões de qualidade do projecto. As actividades utilizadas no processo de garantia da qualidade são as auditorias da qualidade, a análise do processo, as técnicas de planeamento da quali- [PJMG quality, 78]

113 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS dade, e as do controlo da qualidade. As auditorias da qualidade são análises estruturadas e independentes que permitem averiguar se as políticas, processos e procedimentos do projecto estão de acordo com os da organização. Esta ferramenta confirma a implementação das solicitações de mudanças aprovadas, acções correctivas, reparo de defeito e acções preventivas, acima descritos. A análise do processo envolve as etapas do plano de melhorias do processo e verifica as melhorias necessárias do ponto de vista organizacional e técnico. Esta ferramenta inclui uma técnica para analisar um problema ou situação e determinar as causas do mesmo, para assim se produzirem acções preventivas. Esta técnica é denominada análise causa-raíz. Tal como foi referido, as actividades do planeamento da qualidade e do controlo de qualidade são também utilizadas nesse processo. No controlo da qualidade comparam-se os padrões de qualidade previamente definidos com os resultados actuais do projecto, de forma a perceber se o projecto respeita os padrões de qualidade. Este processo é, normalmente, responsabilidade do gestor de projectos (PMI, 2004b). As entradas do controlo da qualidade são em parte as saídas do processo de planeamento da qualidade, como o plano de gestão da qualidade, as métricas de qualidade, as listas de verificação da qualidade e os activos de processos organizacionais. Outras entradas pertinentes são as informações sobre o desempenho do trabalho e as solicitações de mudanças aprovadas, entradas essas descritas no processo de garantia de qualidade. Uma outra entrada deste processo são as entregas, e incluem produtos, resultados ou capacidades para realizar serviços, que devem ser produzidas com a realização do projecto. Estas entregas encontram-se definidas na documentação do plano de gestão do projecto. As saídas resultantes do controlo da qualidade são medições de controlo de qualidade, validação de reparação de defeitos, baseline da qualidade, acções correctivas recomendadas, acções preventivas recomendadas, mudanças solicitadas, reparo de defeitos recomendado, activos de processos organizacionais, entregas validadas e o plano de gestão do projecto. As medições do controlo da qualidade, o reparo de defeitos recomendado, a baseline da qualidade, as acções correctivas recomendadas, as acções preventivas recomendadas e os activos de processos organizacionais, são entradas e saídas dos processos de garantia da qualidade e do planeamento da qualidade, já explicados nesses processos. Na validação de reparação de defeitos as actividades são inspeccionadas e decide-se se são aceites ou não. As que forem rejeitadas podem levar a [PJMG quality, 79]

114 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE uma validação de reparação de defeitos posterior. As mudanças solicitadas são despoletadas quando as acções correctivas e preventivas recomendadas exigem mudanças no projecto. As entregas validadas são registos de todas as entradas que são válidas. Nas software houses é necessário executar ainda mais processos para realizar uma gestão da qualidade eficiente como os testes, a fiabilidade, e a manutenção (Gill, 2005). É fundamental realizar testes como os testes de unidade, de integração, de aceitação e de usabilidade, ao longo das fases de desenvolvimento de um projecto de software. Só assim se conseguirá garantir a fiabilidade e segurança desse software, que são duas características cada vez mais decisivas devido ao aumento do número de actividades críticas que suportam nas organizações (McDaniel, 2002). Por mais testes que se realizem, há sempre uma grande possibilidade de ocorrerem problemas quando se migram os projectos para os processos organizacionais dos clientes. Assim, é necessário garantir a manutenção do software com a finalidade de garantir a qualidade de funcionamento do mesmo. Desta forma, a gestão da qualidade de um projecto de software só termina no final de vida do próprio software. As organizações de desenvolvimento de software atravessam ainda outra barreira, relativamente à garantia da qualidade dos projectos. Como já várias vezes referimos, elas estão inseridas numa atmosfera tumultuosa e em constante mudança, em que a velocidade de evolução tem sido muito elevada (Kenneth C Laudon & Laudon, 2006; Mellis, 1998). Essas circunstâncias transmitem, muitas vezes, um clima de incertezas aos gestores de projectos, já que, embora tenham de conduzir o projecto num sentido, pode ser necessário alterá-lo a fim de responder às mudanças do ambiente. Assim, a gestão da qualidade pode ser ameaçada já que os próprios padrões de qualidade podem ser alterados a qualquer momento. Nesta perspectiva, a gestão da qualidade dos projectos de desenvolvimento de software pode tornar-se bastante complexa, sendo muitas vezes necessário ter bastante criatividade e capacidade de improviso para se conseguir obter vantagens dessas mudanças ambientais (Mellis, 1998). Jiang, juntamente com outros autores, realizou um estudo no qual foram realizados inquéritos junto de engenheiros de software. Muitos desses engenheiros revelaram que vêm com bons olhos o desenvolvimento de ferramentas ou estratégias para medir o desempenho e a qualidade dos projectos. Concluíram ainda nesse estudo que é urgente que as organizações tenham um cuidado mais elevado do planeamento, controlo e execução das actividades dos projec- [PJMG quality, 80]

115 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS tos (Jiang, Klein, Hwang, Huang, & Hung, 2004). Desta forma, é necessário que essas organizações dêem maior importância às actividades da gestão da qualidade, já que constituem um meio para maximizar a qualidade final dos produtos. Um aspecto importante é saber quem é o responsável pela qualidade dos projectos. Segundo Deming, todos os indivíduos da organização são responsáveis pela qualidade dos projectos, começando no topo da organização. Contudo, o gestor de projectos é claramente o que mais suporta as responsabilidades de gestão da qualidade, sendo considerado a chave para uma gestão da qualidade eficiente. Tal como iremos abordar na secção seguinte deste capítulo, é o gestor que deve criar ambientes onde se promova a confiança e a cooperação entre os membros da equipa, criar estratégias de integração, ter um foco especial no cliente e criar uma resolução de problemas estruturada. Uma das principais falhas cometidas pelos gestores relaciona-se com o facto de olharem apenas para a qualidade no resultado final dos projectos. Um bom gestor deve concentrar-se em todo o processo de gestão de qualidade de modo a que os resultados finais tenham a qualidade pretendida (Breyfogle, 2003; Kerzner, 2001). Apesar disto, todos os membros da equipa de projecto devem ser treinados para identificar problemas, recomendar soluções e implementar as soluções recomendadas (Kerzner, 2001). Nas empresas mais pequenas muitas vezes um indivíduo realiza actividades que não são do seu âmbito e competência. Por exemplo, se é um bom programador passa a ser também analista de sistemas, e consecutivamente passa a ser gestor de projectos. Embora por vezes isso possa vir a ser saudável, noutros casos pode trazer consequências negativas, sendo que as competências devem ser alocadas conforme as necessidades da actividade a ser desenvolvida (Bezerra, 2004). Este factor é importante no sentido de determinar se uma pessoa está ou não apta para realizar determinadas funções, o que é determinante para a qualidade final do projecto, pois, caso um indivíduo não esteja preparado para desempenhar funções de gestor, de um analista, ou qualquer outro papel que lhe seja atribuído, dificilmente conseguirá desempenhar as tarefas de forma a maximizar a qualidade do produto. Nas organizações em geral, e nas empresas de desenvolvimento de software, nas quais se pretenda que os seus produtos sejam vendidos um pouco por todo mundo, levanta-se ainda outra questão relacionada com a qualidade dos produtos: a diversidade cultural. Podem surgir problemas devido à ignorância ou insensibilidade cultural, já que o que faz sentido num determinado país, [PJMG quality, 81]

116 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE segundo a sua cultura e política, noutro país pode não fazer. Siakas, no seguimento de um inquérito realizado em organizações de vários países, sugere que se realizem estudos entre universidades, centros de investigação e indústria, que funcionem em vários países, por forma a refinar questões relacionadas com a qualidade dos projectos e promovendo a melhoria da visibilidade de actividades críticas de sucesso de projectos de software, aumentando as taxas de sucesso das organizações e reforçando a sua competitividade a nível mundial (Siakas& Georgiadou, 2002). Para Sommerville (2003) a gestão da qualidade envolve definir procedimentos e padrões que devem ser utilizados durante o desenvolvimento de software e verificar se estão a ser seguidos por todos os envolvidos. Além dessas responsabilidades, o gestor da qualidade deve também desenvolver uma cultura da qualidade, encorajar as equipas para assumirem a responsabilidade pela qualidade de seu trabalho, e desenvolverem novas abordagens para a melhoria dessa qualidade. Sommerville estrutura a gestão da qualidade em três actividades principais (Sommerville, 2003): Garantia da Qualidade: cuida da montagem de uma estrutura de procedimentos e de padrões organizacionais, que suportem o desenvolvimento de software de qualidade; Planeamento da Qualidade: adapta a partir dos padrões institucionais os procedimentos e as necessidades para a qualidade de um projecto específico; Controle da Qualidade: preocupa-se com a definição e a aprovação de processos para assegurem que procedimentos e padrões de qualidade, especificados para o projecto, sejam seguidos pela equipa de desenvolvimento. Esta necessidade de uma estrutura completa, envolvendo a qualidade dos produtos, a eficácia do uso dos processos e a determinação dos processos institucionais, é o grande desafio da organização (Azevedo, 2005). Segundo o PMBoK (PMI, 2004a), a gestão da qualidade de um projecto inclui os processos necessários para assegurar que o projecto satisfaça as necessidades para as quais foi criado. O Total Quality Management (TQM), representa uma abordagem de gestão para melhoria do processo de qualidade com foco principal na equipa (Deming, [PJMG quality, 82]

117 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS 1986). É defendido que o envolvimento de todas as pessoas dentro da organização é essencial para melhorar a qualidade do processo. A organização é vista como um processo em que o objectivo constante é melhoria contínua do processo da qualidade. A abordagem é baseada em catorze princípios propostos por Deming em 1986 enumerados na Tabela 4.1. Sequência Princípios 1 Criar uma iniciativa estável de melhoria do produto e do serviço com os objectivos: competitividade, manutenção no mercado e criação de emprego. 2 Adoptar uma nova filosofia. A gestão deve despertar para o desafio, aprender as suas responsabilidades e assumir a liderança na mudança. 3 Terminar com a dependência da inspecção para melhorar a qualidade, construindo a qualidade no produto em primeiro lugar. 4 Terminar a prática de determinar o negócio unicamente na base do preço. Minimizar o custo total e promover uma relação de longo prazo, de lealdade e de confiança com o fornecedor. 5 Melhorar continuamente o sistema de produção e serviço, para melhorar a qualidade e produtividade e dessa forma reduzir custos. 6 Instituir a formação no posto de trabalho. 7 Instituir a liderança. O objectivo da supervisão deve ser de ajudar as pessoas, máquinas e dispositivos a fazer um trabalho melhor. A supervisão da gestão é necessária à semelhança da supervisão dos trabalhadores ligados à produção. 8 Melhorar continuamente o sistema de produção e serviço, para melhorar a qualidade e produtividade e dessa forma reduzir custos. 9 Eliminar barreiras funcionais entre as áreas. 10 Eliminar slogans, exortações e objectivos dirigidos à força de trabalho como zero defeitos e novos níveis de produtividade. Estes originam relações adversas. As causas de baixa qualidade e produtividade pertencem ao sistema e vão para além da força de trabalho. [PJMG quality, 83]

118 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE 11 Eliminar standards de trabalho (cotas) na zona de produção. Substituir a liderança. Eliminar a liderança por objectivos, a liderança por números, por objectivos numéricos. Substituir a liderança. 12 Remover barreiras que reduzam o orgulho no trabalho realizado. A responsabilidade do supervisor deve ser alterada de simples números para qualidade. Eliminar barreiras que afastem as pessoas da gestão e da engenharia do orgulho do seu trabalho. Isto significa a abolição de pontuações anuais de mérito e da gestão por objectivos. 13 Instituir um programa vigoroso de educação e melhoria pessoal. 14 Colocar tudo e todos na organização a trabalhar para conseguir alcançar os objectivos de mudança. Tabela 4.1: Catorze princípios para a gestão da qualidade propostos por Deming Fonte: (Deming, 1986) Um dos principais pontos da abordagem de Deming é a noção de serviço ao cliente (MacDonnel, 1994). Todos os intervenientes para quem o serviço é desenvolvido devem ser tratados como clientes. Outro ponto fundamental é o papel da gestão de topo no garante do sucesso da gestão da qualidade. Deming (Deming, 1986) considera que o suporte não é suficiente, é responsabilidade da gestão criar e comunicar a visão, com o objectivo da melhoria contínua. O Ciclo de Deming (P-D-C-A) (Plan-Do-Check-Act) é um ciclo de melhoria contínua, sendo uma ferramenta útil para definir, implementar, controlar acções correctivas e melhorias dos processos. Este ciclo contempla quatro fases (Deming, 1986): P (Plan) = Planear: o primeiro passo na melhoria consiste no estabelecimento de objectivos e metas e no planeamento das acções necessárias para os alcançar; D (Do) = Fazer: Implementar as acções planeadas; C (Check) = Controlar: comparar os resultados obtidos com os objectivos propostos; A (Act) = Actuar: Se as acções não forem eficazes, é necessário executar acções correctivas e preventivas que assegurem o cumprimento dos objectivos e conduzam à melhoria contínua. [PJMG quality, 84]

119 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS Quando se alcançam os objectivos, estabelecem-se novos objectivos e recomeça-se o ciclo. Seguindo a lógica do ciclo PDCA, o fim de um ciclo dá origem a um novo ciclo em que as não conformidades detectadas, já corrigidas, não voltam a aparecer dando-se assim origem a um movimento de melhoria contínua (Figura 4.1). Figura 4.1: Ciclo PDCA, de Deming ou de Melhoria Contínua Fonte: Adaptado de (Fernandes, 2005) O termo TQM, amplamente usado nas organizações, também descreve uma abordagem para a melhoria da qualidade. Independente dos seus vários tipos de implementação, os elementos chave do TQM podem ser resumidos conforme ilustrado na Figura 4.2. Em seguida são descritos os elementos que são considerados como elementos chave da Gestão da Qualidade Total: Foco do Cliente (Customer Focus) - O objectivo é atingir a satisfação total do cliente. O foco do cliente inclui o estudo das necessidades e vontades do cliente, levantamento de requisitos do cliente, a medição e a gestão da satisfação do cliente. Melhoria de Processo (Process Improvement) - O objectivo é reduzir as variações de processo e atingir a melhoria da qualidade contínua. Este elemento inclui ambos os processos de negócio e o processo de desenvolvimento do produto. Através da melhoria de processo, a qualidade do produto será reforçada. Lado Humano da Qualidade (Human Side of Quality) - O objectivo é criar a cultura de qualidade por toda a empresa. As áreas de [PJMG quality, 85]

120 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE foco incluem liderança, apoio da gestão de topo, participação total de todos os colaboradores da empresa, e outros factores humanos como sociais e psicológicos. Métricas, Modelos, Medições e Análises (Metrics, Models, Measurement and Analysis) - O objectivo é direccionar a melhoria contínua em todos os parâmetros da qualidade por um sistema de medição orientado a metas. Figura 4.2: Elementos chave do TQM Fonte: Adaptado de (Martinho, 2008) No contexto de sistemas de informação e software o conceito da norma ISO aplica-se na sua totalidade, sendo que os utilizadores finais sempre terão as expectativas de um alto padrão de qualidade para que suas tarefas sejam sempre executadas da maneira mais adequada possível. Tian (2005) afirma que as expectativas de qualidade para sistemas de software estão relativamente ligadas em dois aspectos (Tian, 2005): O sistema de software deve fazer o que é suposto ser executado; Devem ser realizadas estas tarefas específicas correctamente e satisfatoriamente. Indirectamente, as duas afirmações de Tian (2005) estão baseadas na norma ISO 9000:2005 (ISO, 2005) sendo que o sistema deve fazer o que se espera que ele realize, de acordo com o levantamento de requisitos especificado. Contudo, a qualidade possui alguns princípios básicos, como: [PJMG quality, 86]

121 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS Tentar prevenir defeitos em detrimento da correcção; Ter a certeza que os defeitos que foram encontrados, são corrigidos o mais rápido possível. Estabelecer e eliminar as causas, bem como os sintomas dos defeitos; Auditar o trabalho de acordo com padrões e procedimentos previamente estabelecidos. Segundo Lewis (2004), uma definição formal de Software Quality Assurance (SQA) é "actividades sistemáticas fornecendo evidências para o uso pretendido para o produto total de software". Pode-se ainda definir como Quality Assurance "o conjunto de actividades de apoio para fornecer confiança de que os processos estão estabelecidos e estão continuamente melhorados para produzir produtos que atendam as especificações e que sejam adequados para o uso pretendido" (Lewis, 2004). SQA envolve todo o processo de desenvolvimento de software, efectuando as devidas monitorizações e melhorias de processos pertinentes, fazendo com que os padrões e procedimentos acordados sejam respeitados e garantindo que os problemas são encontrados e as respectivas acções correctivas são aplicadas. Este tipo de acção é orientado para a prevenção. O IEEE define qualidade de software como: (1) Um padrão planeado e sistemático de todas as acções necessárias para fornecer confiança adequada que um item ou produto está em conformidade com os requisitos técnicos estabelecidos; (2) Um conjunto de actividades projectadas para avaliar o processo pelo qual produtos são desenvolvidos ou manufacturados. SQA é também formada por um grupo de pessoas que participam através de todo o ciclo de vida de engenharia de software que influenciam de forma positiva e quantificam a qualidade do software que é desenvolvido. Verificam se o produto final está de acordo com os requisitos. Como já foi focado, a SQA não é somente uma área associada exclusivamente com actividades de desenvolvimento de software, mas sim com actividades que se expandem durante todo o ciclo de vida de desenvolvimento de software. [PJMG quality, 87]

122 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE Portanto, isso consiste em realizar a qualidade tanto do processo como do produto. No processo, podemos quantificar a sua qualidade através de métricas para qualidade de software e no produto com as técnicas de verificação e validação. Essas actividades podem ser, por exemplo, avaliações como as citadas pela ISO 9000, auditorias, inspecções formais, teste de software, revisões. Ainda no processo podemos usar os métodos de garantia da qualidade no formato de auditorias e relatórios para a gestão de topo, além de avaliações constantes do processo e análise estatística de controlo do processo. No produto, os métodos de garantia da qualidade são revisões, inspecção formal e teste de software, além da revisão dos resultados do teste de software realizada por experts, auditorias do produto e testes realizados pelo cliente. Lewis (2004) defende que as organizações que não utilizam processos de SQA tendem a mostrar os seguintes indicadores de falta de qualidade: O software que foi entregue frequentemente apresenta falhas; Consequências inaceitáveis de falhas de sistemas, desde financeiras até cenários reais de aplicação; Os sistemas não estão disponíveis para a utilização pretendida; Os sistemas são frequentemente muito caros; Os custos de detectar e remover defeitos são, por vezes, excessivos. Por outro lado, nas organizações onde são implementados processos de SQA e que efectuam a sua aplicação de maneira adequada: A remoção de erros acontece no momento em que é barato corrigir; Há melhoria da qualidade do produto; Processo de recolha de métricas de acordo com os objectivos; é estabelecida uma base de dados de métricas: planeamento, taxas de falhas e outros indicadores da qualidade; A SQA é um recurso para a melhoria de processo. Segundo Lewis (2004), as actividades mais comuns da SQA consistem em: Teste de Software (Verificação e Validação), Gestão de Configuração de Software e Controle da Qualidade. Na Figura 4.3, podemos ver a relação entre estas três actividades principais juntamente com Padrões, Procedimentos, Convenções e Especificações. [PJMG quality, 88]

123 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS Figura 4.3: Componentes da SQA. Fonte: Adaptado de (F. M. Campos, 2008) Em seguida são descritos os elementos que compõem a SQA. Controlo da Qualidade (Quality Control): O controlo da qualidade é definido como um processo com métodos que são usados para monitorar o trabalho e observar se os requisitos estão a ser satisfeitos. O foco é justamente em revisões e remoção de defeitos e erros antes da dos produtos. O controlo da qualidade deve ser da responsabilidade da unidade organizacional que produz o produto. No entanto, é possível ter a mesma equipa que constrói o produto, a realizar também o controlo da qualidade, ou a estabelecer um grupo de controlo da qualidade separado ou um departamento dentro da mesma unidade organizacional que desenvolve o produto. O controlo da qualidade consiste em verificar checklists 5 bem definidas em produtos especificados no plano de garantia da qualidade. Um exemplo clássico de controlo da qualidade é a realização das auditorias de software. A auditoria é o grau mais maduro e formal dentro das revisões, sendo necessária uma preparação prévia, participantes definidos adequadamente e critérios de entrada e saída bem definidos. O controlo da qualidade é projectado para 5 Listas de verificação para assegurar qua as acções que estão descritas ou enumeradas são geridas de forma adequada e não são esquecidas. [PJMG quality, 89]

124 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE detectar defeitos e corrigir esses defeitos encontrados, enquanto que a garantia da qualidade é orientada para a prevenção de defeitos. Plano de testes de Software (Software Testing): Conforme Lewis (2004), é uma estratégia usada para a gestão de risco. Os testes de software são usados para verificar que requisitos funcionais e não funcionais foram implementados devidamente. A limitação desta abordagem (software testing), é que na fase em que acontece, muitas vezes é difícil garantir a qualidade no produto. Isto devido a várias organizações ainda usarem o modelo Waterfall, ou modelo cascata, que foca justamente a actividade ou fase de testes de software somente no final do modelo, ou seja, caso algum defeito seja encontrado (erros em requisitos, por exemplo) todo ciclo deverá ser inicializado novamente. O Software Testing foca quase exclusivamente as actividades de verificação e validação. Gestão de Configuração de Software (SCM- Software Configuration Management): O SCM é responsável por identificar, rastrear e controlar mudanças nos elementos do software de um sistema. O SCM controla a evolução do sistema de software, através da gestão de versões dos componentes de software e dos seus relacionamentos. O propósito é identificar todos os componentes inter-relacionados do software para controlar a sua evolução através das várias fases no ciclo de vida de desenvolvimento de software. SCM é uma área que pode ser aplicada para actividades, incluindo: desenvolvimento de software, controlo de documentação, controlo de mudanças e manutenção. O SCM consiste, ainda num conjunto de actividades que asseguram que a arquitectura e codificação são definidas e não podem ser alterados, sem um estudo dos impactos da mudança e sem a geração de documentação respectiva. Para que estes três principais componentes funcionem correctamente, o sucesso do programa de garantia da qualidade de software também depende de uma colecção coerente de padrões, procedimentos, convenções e especificações, conforme indicado na Figura 4.3. A combinação de todos os componentes e das melhores práticas é o que chamamos de Software Quality Assurance. Esse trabalho é realizado com o objectivo de garantir a qualidade de software do produto final entregue ao cliente ou utilizador final. Para que esta estrutura esteja devidamente documentada e aceite por todos os membros da equipa do projecto, é necessário um planea- [PJMG quality, 90]

125 GESTÃO DA QUALIDADE NO ÂMBITO DA GESTÃO DE PROJECTOS mento adequado. Esse planeamento é feito no Software Quality Assurance Plan ou Plano de Garantia da Qualidade de Software. Segundo Lewis (2004), "O plano de garantia da qualidade de software é um resumo ou esboço das medidas de qualidade para garantir níveis de qualidade dentro do esforço do desenvolvimento de software. O plano é usado como uma baseline para comparar os níveis de qualidade durante o desenvolvimento com os níveis planeados de qualidade. Um dos grandes erros geralmente cometidos por pessoas e organizações é confundir os conceitos e aplicação dos termos Controlo da Qualidade (Quality Control) e Garantia da Qualidade (Quality Assurance). Embora usados de maneira errônea em muitos lugares, ambos os termos têm propósitos totalmente diferentes (Martinho, 2008). A Tabela 4.2 mostra a diferença entre estas duas actividades. Quality Assurance 1. Garantia da qualidade garante que o processo é definido e apropriado 2. Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade. 3. Garantia da qualidade é orientada ao processo. 4. Garantia da qualidade é orientada à prevenção. Quality Control 1. As actividades de controlo da qualidade focam na descoberta de defeitos específicos. 2. Um exemplo de controlo da qualidade poderia ser: "Os requisitos definidos são os requisitos correctos?". 3. Controlo da qualidade é orientado a produto. 4. Controle da qualidade é orientado à detecção. 5. Foco em monitorização e melhoria de processo. 6. As actividades são focadas no início das fases no ciclo de vida de desenvolvimento de software. 5. Inspecções e garantia de que o produto de trabalho atenda aos requisitos especificados. 6. As actividades são focadas no final das fases no ciclo de vida de desenvolvimento de software. 7. Garantia da qualidade garante que os 7. Controle da qualidade garante que os processos estão a ser executados de resultados do trabalho são os esperados forma correcta. conforme requisitos. Tabela 4.2: Diferenças entre Garantia da Qualidade e Controlo da Qualidade Fonte: (Martinho, 2008) [PJMG quality, 91]

126 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE Com isto, pode afirmar-se que os testes de software são uma das actividades de controlo da qualidade, ou seja, os testes de software são orientados ao produto e estão no domínio do controlo da qualidade. 4.3 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE A implementação de sistemas da qualidade tem como objectivo específico a busca, o controle e a melhoria contínua dos processos de trabalho para uma crescente satisfação dos clientes. Num Sistema de Gestão da Qualidade (SGQ), a organização diz o que vai fazer (nível das normas e procedimentos documentados), faz o que pretende e prova o que fez (por meio da documentação gerada). Através das informações registadas em suportes físicos são objectivadas as acções, possibilitando o controlo dos resultados. O sistema de gestão de qualidade de uma organização é único, isto é, não é igual ao de nenhuma outra organização. O SGQ depende dos objectivos da organização e das suas práticas de gestão, depende do conjunto de recursos humanos que o definem e actualizam. No entanto, existe um conjunto de elementos de um SGQ, que se revelou como um conjunto mínimo adequado à elaboração de um referencial inicial para a construção do sistema da qualidade de qualquer empresa. Estes elementos compõem a série ISO Apesar destes aspectos, não é finalidade de nenhuma norma da série ISO 9000 padronizar sistemas de qualidade implementados pelas organizações. Segundo a ISO 9000:2000, um sistema de gestão da qualidade procura auxiliar as organizações a aumentar continuamente a satisfação de seus clientes, atentando para as suas necessidades e expectativas. Estas expectativas são continuamente reflectidas em requisitos para materiais, serviços e informações, e são compartilhadas por um grande número de organizações em todo o mundo. Trata-se de uma rede internacional de informações sobre normas, padrões e qualificações para o alcance da excelência. O objectivo da normalização é o estabelecimento de soluções, por consenso das partes interessadas, para assuntos que têm carácter repetitivo, tornando-se uma ferramenta poderosa na auto-disciplina dos agentes activos dos mercados, ao simplificar os assuntos e evidenciando ao legislador se é necessária regulamentação específica em matérias não cobertas por normas (Qualidade, 2008). [PJMG quality, 92]

127 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE Abreu (F. Abreu, 2000) refere que a normalização assume o papel catalizador da indústria de software disponibilizando definições de consenso e compreensão alargada, enquadramentos de referência (para o estabelecimento de métodos de desenvolvimento) e pontos de referência (face aos quais se podem exprimir e avaliar as melhorias conseguidas). Refere ainda, que evita a tentação de reinventar a roda, guia o processo de desenvolvimento de forma coerente e comprovada, produz produtos com aceitação alargada (em particular quando devem obedecer a requisitos de inter-operacionalidade, ou produção em série) e evidencia a qualidade de produtos e processos (através da certificação). Qualquer norma é considerada uma referência idónea do mercado a que se destina, sendo por isso usada em processos: de legislação, de acreditação, de certificação, de metrologia, de informação técnica, e até por vezes nas relações comerciais Cliente - Fornecedor. A certificação ISO 9000 demonstra que o sistema de qualidade da organização é credível e efectivo. Fornece evidência de que a organização é qualificada para produzir produtos e serviços de qualidade, porém não avalia directamente a qualidade de nenhum produto ou serviço. No entanto, as normas da ISO não são suficientes para o sucesso da implementação da estratégia de melhoria contínua da qualidade Família ISO 9000 Sommerville (2003) ao referir-se à norma ISO 9000:2000 apresenta-a como um padrão internacional, que pode ser utilizado para o desenvolvimento de um sistema de gestão da qualidade em todas as indústrias. Comenta que A ISO 9001 é a mais geral das normas e aplica-se a organizações que se preocupam com o processo de qualidade de empresas que projectam, desenvolvem e fazem manutenção de produtos. (Sommerville, 2003). A família ISO 9000 do ano 2000 (IPQ, 2008a) é constituída por três normas principais, em que as necessidades dos vários sectores de actividade estão garantidas, dada a natureza genérica das normas: ISO Sistemas de Gestão da Qualidade. Fundamentos e Vocabulário; ISO Sistemas de Gestão da Qualidade. Requisitos; [PJMG quality, 93]

128 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE ISO Sistemas de Gestão da Qualidade. Linhas de Orientação para a Melhoria do Desempenho. E ainda pelas quatro normas seguintes: ISO Linhas de orientação para auditorias da qualidade e ambiente; ISO Garantia da qualidade em equipamentos de medição; ISO Linhas de orientação (Guidelines for training); ISO/TR Linhas de orientação para a documentação do Sistema de Gestão da Qualidade (Guidelines for quality management system documentation). A norma ISO 10006: Quality Management Systems Guidelines for quality management in projects é complementar à família ISO A ISO aborda a gestão de projectos, mas não é um guia para a gestão de projectos. Fornece directrizes que devem ser utilizadas na gestão para manter a qualidade em projectos. Define como os princípios e práticas de gestão da qualidade se devem relacionar com a gestão de projectos. Aplica-se a projectos de diferentes graus de complexidade e tamanho. Ao considerar a norma ISO como um guia de directrizes, esta norma não é utilizada para fins de certificação. O objectivo fundamental desta norma é manter a gestão da qualidade em projectos através de um processo sistemático. Apesar desta norma ser orientada ao processo, no caso de um processo necessitar ser efectuado em vários tempos, não fica clara a sequência de passos necessária neste caso. São apontados alguns pontos fracos a esta norma (Pither & Duncan, 1998; Stanleigh, 2004): Apresenta falhas na documentação; Processo de gestão de qualidade é deficiente; Não se considera um guia à gestão de projetos, contudo, na fraseologia, sim. A ISO 9001:2000 adopta uma abordagem de gestão por processos e aplica o ciclo de melhoria "PDCA" ilustrado na Figura 4.1. A ISO 9001 pertence à família de normas ISO 9000, que fornece a estrutura a que deve obedecer um sistema de gestão da qualidade. A família da ISO 9000 [PJMG quality, 94]

129 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE foi revista em Dezembro Nesta revisão surgiu a ISO 9001:2000, que anulou as anteriores versões ISO 9001/2/3/:1994. Os requisitos da ISO 9001:2000 estão distribuídos nas secções: Sistema de Gestão da Qualidade. Uma organização necessita de assegurar o estabelecimento dos seus processos, de como estes interagem, quais os recursos requeridos e como são medidos e melhorados estes processos. Também tem de ser estabelecido um sistema de controlo da documentação, um manual da qualidade e os controlos dos registos da qualidade. Responsabilidade da Gestão. A gestão, ao nível mais elevado, necessita de se envolver de acordo com os requisitos desta importante secção da norma. É da responsabilidade da gestão ajustar políticas, definir objectivos e revê-los, assim como comunicar a eficácia do sistema dentro da organização. Gestão de Recursos. Foi colocada mais ênfase nos recursos que a organização necessita para assegurar que o cliente recebe o que foi acordado. Abrange, não só as pessoas, mas também os recursos físicos, tais como permissões do equipamento e todos os serviços de suporte necessários. Realização do Produto. Esta secção cobre os processos que são necessários para fornecer o produto/serviço. Estes processos cobrem actividades como a análise dos requisitos do cliente, o projecto e desenvolvimento do produto, a compra dos materiais e serviços, e a respectiva entrega. Medição, Análise e Melhoria. Através da medição dos processos, da satisfação de cliente, da gestão de sistemas e da melhoria contínua, fica garantida a efectiva gestão do sistema. A ISO 9001:2000 (IPQ, 2008b) baseia-se em oito princípios fundamentais de gestão de qualidade: Focalização no cliente; Liderança; Envolvimento das pessoas; Abordagem por processos; Abordagem à gestão através de um Sistema de Gestão de Qualidade (SGQ); [PJMG quality, 95]

130 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE Melhoria contínua; Abordagem à tomada de decisões baseada em factos; Relações mutuamente benéficas com fornecedores. Em seguida são descritos os oito princípios de gestão da qualidade (Chaves, 2007; Hele, 2003): a) Focalização no cliente: As organizações dependem dos seus clientes e consequentemente, convém que compreendam as suas necessidades actuais e futuras, satisfaçam os seus requisitos e se esforcem por exceder as suas expectativas. Sem clientes uma organização não existe. É imprescindível que, estrategicamente, a gestão de topo da organização conheça as necessidades correntes e futuras dos seus clientes para que possa realizar os planos necessários para cumprir os requisitos. A medida da satisfação dos clientes faz parte da informação usada pela gestão de topo para determinar futuras medidas estratégicas e os recursos necessários da organização. A comunicação entre a organização e os seus clientes é um factor determinante e deve ser clara. Os clientes devem saber a quem pedir informações e quem devem contactar na organização. b) Liderança: Os líderes estabelecem a finalidade e a orientação da organização. Convém que estes criem e mantenham o ambiente interno que permita o pleno envolvimento das pessoas para se atingirem os objectivos da organização. A estratégia deve ser consensual e comunicada a partir do topo da organização. É através de uma boa comunicação com o resto da organização que a política e os objectivos são conhecidos e monitorizados, assim como o incentivo e motivação geral por todas as partes para o sucesso da organização. A gestão também necessita de ter em atenção os interesses das partes interessadas, focadas na ISO 9004:2000: clientes; fornecedores; a organização e seus accionistas; trabalhadores e sociedade. c) Envolvimento das pessoas: As pessoas, em todos os níveis, são a essência de uma organização, e o seu pleno envolvimento permite que as suas aptidões sejam utilizadas em benefício da organização. [PJMG quality, 96]

131 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE Os requisitos das séries de normas ISO 9000:2000 referem a importância da comunicação. Os colaboradores são informados, conhecem a importância e relevância das suas actividades para atingir os objectivos da organização. A ISO 9001:2000 também requer que as competências de todos os funcionários envolvidos na organização sejam conhecidas e avaliadas, com o objectivo de assegurar que têm as aptidões adequadas para a função que desempenham. d) Abordagem por processos: Um determinado resultado é alcançado de forma mais eficiente quando as actividades e os recursos associados são geridos como um processo. A ISO 9001 incentiva a abordagem por processos de gestão da qualidade, considerando processos como as actividades que recebem entradas e as convertem em saídas com valor acrescentado, sendo que, frequentemente, a saída de um processo é a entrada de outro (Figura 4.4). Figura 4.4: Modelo de um sistema de gestão da qualidade baseado em processos Fonte: retirado da NP EN ISO 9001:2000 (IPQ, 2008b) e) Abordagem da gestão como um sistema: Identificar, compreender e gerir processos inter-relacionados como um sistema, contribui para que a organização atinja os seus objectivos como um processo. [PJMG quality, 97]

132 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE A organização deve olhar para as interdependências dos processos e a forma como estes podem ser integrados no sistema. Para garantir a eficácia dos processos, as organizações devem questionar: Quem é o responsável pelos processos? Essa pessoa responsável tem a certeza que essa sequência dos processos é a mais correcta e eficaz? Quem é responsável por assegurar que existem recursos adequados pessoas e equipamentos para os processos serem eficazes? Quem é responsável por medir e monitorizar os processos? Quem é responsável por assegurar que os processos são melhorados quando é necessário? Revendo estes pontos periodicamente a gestão consegue assegurar que os processos atingem os objectivos definidos pela política de gestão. f) Melhoria contínua: Convém que a melhoria contínua do desempenho global de uma organização atinja os seus objectivos com eficácia e eficiência. A melhoria contínua não deve ser vista pela organização como uma tarefa aborrecida, mas sim como um objectivo permanente. Existem sempre áreas na organização onde podem ser feitos melhoramentos. As fontes de informação para adquirir a melhoria contínua são múltiplas, tais como: Registo da opinião dos clientes sobre a organização, os seus produtos e serviços; Identificação das diversas ameaças e riscos para o negócio e dos pontos onde os melhoramentos devem ser realizados para minimizar esses riscos; Recolha de opiniões dos fornecedores acerca dos aspectos susceptíveis de melhoria; Localização de oportunidades e áreas de melhoria obtidas a partir de auditorias e revisões internas. Antes de iniciar o ciclo de melhoria contínua, a organização deve descrever a situação actual de modo a ser possível compará-la com a situação posterior à melhoria. [PJMG quality, 98]

133 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE g) Abordagem à tomada de decisões baseadas em factos: As decisões eficazes são baseadas na análise de dados e informação. Tomar as decisões certas para uma organização nunca é uma decisão fácil, mas a utilização da informação baseada em factos, com intuição e experiência, pode ajudar na tomada de decisões. h) Relações mutuamente benéficas com fornecedores: Uma organização e os seus fornecedores são interdependentes e uma relação de benefício mútuo promove a aptidão de ambas as partes para criar valor. Uma boa relação com os fornecedores, é um valor acrescentado para a organização e para os seus fornecedores. É também desejável que, sempre que possível, ambas as partes actuem em conjunto para poderem retirar vantagens das oportunidades. A International Organization for Standardization (ISO) publicou, em , a nova edição da Normas ISO 9001 (ISO 9001:2008) (IPQ, 2008a). Esta nova edição decorre do compromisso da ISO em periodicamente rever e actualizar as Normas, e conclui mais de dois anos de trabalho do Technical Commitee 176 (ISO TC 176), responsável pelo desenvolvimento e manutenção das Normas para Sistemas de Gestão da Qualidade (SGQ). Para a actual revisão de 2008, a ISO estabeleceu como propósito/objectivo apenas fazer clarificações do texto da Norma, com base nos 8 anos de experiência da sua utilização em todo o mundo, não introduzindo novos requisitos. Embora existam algumas alterações em relação ao texto da Norma de 2000, a SGS ICS considera que as clarificações ora formalizadas coincidem com o seu entendimento, desde sempre adoptado na prática de Auditoria e Certificação dos Sistemas de Gestão da Qualidade dos seus Clientes. Por esta razão, é expectável que a ISO 9001:2008 tenha impacto relativamente reduzido nos SGQ adequadamente implementados e já certificados pela SGS ICS segundo a ISO 9001:2000. Na maioria dos casos, um SGQ correctamente implementado e em conformidade com os requisitos da ISO 9001:2000 necessitará apenas de pequenos ajustamentos para assegurar a conformidade com a nova edição da Norma. De notar que os consumidores não compram sistemas de gestão da qualidade, mas sim produtos e serviços. [PJMG quality, 99]

134 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE Muito frequentemente o elemento externo mais importante, isto é, os clientes da organização, são pouco valorizados. Um sistema de gestão da qualidade deve começar e terminar indo ao encontro do ponto de vista dos clientes. O objectivo de muitas certificações é frequentemente mais na conformidade com os requisitos normativos do que no verdadeiro alvo do sistema de gestão da qualidade que é a satisfação dos clientes. Muitas cláusulas da norma ISO 9001:2000 especificam este requisito chave, ou seja, a satisfação dos clientes. Por exemplo, a cláusula 1.1 Generalidades define requisitos para um sistema de gestão da qualidade em que uma organização necessita demonstrar a sua aptidão para consistentemente fornecer produtos que vão ao encontro dos requisitos do cliente. A cláusula 1.2 Aplicação determina que as exclusões para requisitos só são aceitáveis se não afectarem a aptidão ou a responsabilidade da organização para proporcionar um produto que vá ao encontro dos requisitos do ciente. A cláusula 8.1 Generalidades, requer que a organização implemente os processos de monitorização, medição e melhoria necessários para demonstrar a conformidade do produto Modelo CMMI O modelo Capability Maturity Model (CMM), inspirado nos conceitos de estágios de evolução de Nolan (Nolan 1973), foi desenvolvido pelo Carnegie- Mellon Software Engineering Institute (SEI) a pedido da força aérea norte americana que necessitava de um modelo abstracto para a avaliação do software fornecido por terceiros. Publicado pela primeira em 1989, o CMM já não é suportado pelo SEI, tendo evoluído para o modelo Capability Maturity Model Integration (CMMI), cuja última versão, a 1.2, foi publicada em Novembro de 2007 (SEI, 2007a). O CMMI é um modelo de referência que contém práticas (genéricas ou específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). O CMMI procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI é um modelo de avaliação dos processos de melhoria para o desenvolvimento de produtos e serviços. Consiste num conjunto de best practices que promovem actividades de desenvolvimento e manutenção que cobrem [PJMG quality, 100]

135 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE todo o ciclo de vida de desenvolvimento de projectos, desde a sua concepção até à entrega, passando pela sua manutenção. Uma vez que o foco da sua actuação é a melhoria dos processos da organização, o CMMI ajuda as organizações que se dedicam ao desenvolvimento e manutenção de produtos e serviços a melhorar a sua capacidade de desenvolver o seu negócio, através do aumento da sua competitividade, capacidade de delivery, capacidade de gestão e controlo do seu processo produtivo e da qualidade na entrega do produto final. No CMMI, as práticas genéricas descrevem as actividades que se dirigem aos aspectos da institucionalização (Chrissis, Konrad, & Shrum, 2003). O CMMI deve ser usado no processo de melhoria das diferentes actividades como uma colecção das melhores práticas, ou como um referencial para organizar e dar prioridade às actividades, para suportar a coordenação de actividades multidisciplinares necessárias ao desenvolvimento de um produto e como um meio de realçar o alinhamento entre os objectivos do processo de melhoria das actividades com os objectivos da organização (SEI, 2007a). O referencial CMMI, na sua versão 1.2, organiza os componentes usados na geração de modelos, materiais de formação e métodos de avaliação. Os componentes do referencial CMMI estão organizados em grupos com a denominação de constelações. Uma constelação é uma colecção de componentes CMMI que são usados para construir modelos, testar materiais e verificar documentos. Temos então as seguintes constelações: CMMI-DEV (SEI, 2006): que agrupa os anteriores modelos CMMI- SE/SW/IPPD/SS, relativos a: engenharia de sistemas (CMMI-SE); engenharia de software (CMMI-SW); desenvolvimento integrado de produtos e processos (CMMIIPPD) e gestão de serviços fornecidos por terceiros (CMMI-SS); CMMI-SVC (SEI, 2007c): o CMMI para serviços; CMMI-ACQ (SEI, 2007b): o CMMI para aquisições. Destas constelações aquela que nos interessa no contexto da qualidade na área da gestão de projectos é a CMMI-DEV, porque é a que está relacionada com o desenvolvimento de software. O CMMI utiliza dois caminhos de melhoria. Um caminho permite às organizações incrementar a melhoria de processos, correspondendo a áreas de processo individuais (ou áreas de processo) seleccionadas pela organização. O [PJMG quality, 101]

136 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE outro caminho permite às organizações melhorar um conjunto de processos relacionados, incrementando sucessivamente conjuntos de áreas de processo. Estes dois caminhos de melhoria estão associados com os dois tipos de níveis correspondendo às duas representações: contínua (usando o termo de nível de capacidade) e por estádios (usando o termo níveis de maturidade) (SEI, 2006). A representação contínua permite à organização seleccionar uma área de processo (ou grupo de áreas) e melhorar os processos relacionados. Esta representação utiliza níveis de capacidade para caracterizar a melhoria relativa de uma área de processo individual. É caracterizado por seis níveis de capacidade: 0 - incompleto, 1 - executado, 2 - gerido, 3 - definido, 4 - gerido quantitativamente e 5 - optimizado. A representação por estádios utiliza conjuntos de áreas de processo para definir um caminho de melhoria para a organização. Este caminho de melhoria é caracterizado por níveis de maturidade. Cada nível de maturidade fornece um conjunto de áreas de processo que caracterizam diferentes ambientes organizacionais. É caracterizado por cinco níveis de maturidade: 1 - inicial, 2 - gerido, 3 - definido, 4 - gerido quantitativamente, e 5 - optimizado. Na Figura 4.5 estão representados os componentes do modelo que são agrupados em 3 categorias (SEI, 2006): requerido, esperado e informativo. Os componentes requeridos descrevem o que é que uma organização deve conseguir para satisfazer a área de processo. Esta realização deve ser visivelmente implementada nos processos da organização. Os componentes requeridos do CMMI são compostos por objectivos específicos e genéricos. A satisfação dos objectivos é usada para decidir onde uma área de processo foi conseguida e satisfeita. Os componentes esperados descrevem o que é que a organização deve implementar para conseguir os componentes requeridos. Os componentes esperados incluem práticas genéricas e específicas. Os componentes informativos fornecem detalhes que ajudam a organização a começar a pensar acerca de como se aproximar dos componentes esperados e requeridos. [PJMG quality, 102]

137 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE Figura 4.5: Componentes do Modelo CMMI Fonte: Adaptado de (SEI, 2006). O CMMI contempla nas duas versões, embora organizadas de forma diferente, as chamadas áreas de processo. Uma área de processo é um conjunto de melhores práticas relacionadas com uma área específica que, quando executada com outros procedimentos, satisfaz os objectivos considerados importantes para uma melhoria significativa da área. As áreas de processo por ordem alfabética são: análise causal e resolução; gestão de configuração; análise de decisão e resolução; gestão integrada de projecto; medição e análise; inovação organizacional e entrega; definição de processo organizacional; foco de processo organizacional; desempenho de processo organizacional; formação organizacional; monitorização e controlo de projecto; planeamento de projecto; garantia de qualidade de processo e produto; integração de produto; gestão quantitativa de projecto; gestão de requisitos; desenvolvimento de requisitos; gestão de riscos; gestão de acordos com fornecedor; solução técnica; validação; e verificação. [PJMG quality, 103]

138 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE A indicação de finalidade descreve a finalidade da área de processo e é um componente informativo. As notas introdutórias da área de processo descrevem os conceitos cobertos na área de processo e é um componente informativo. Um objectivo específico descreve características únicas que devem estar presentes para satisfazer a área de processo. Um objectivo específico é um componente requerido, e é usado para ajudar a determinar se a área de processo é satisfeita. Os objectivos genéricos são assim designados, porque o mesmo objectivo pode ser aplicado a múltiplas áreas de processo. Um objectivo genérico descreve as características que devem estar presentes para institucionalizar os processos e implementar a área de processo. É um componente requerido e é usado para ajudar a determinar se a área de processo é satisfeita. Uma prática específica é a descrição de uma actividade que é considerada importante na realização de um objectivo específico associado. As práticas específicas descrevem as actividades que são esperadas para resultar na realização dos objectivos específicos da área de processo. Uma prática específica é um componente esperado. Os produtos típicos listam saídas simples de uma prática específica. São chamados produtos típicos porque normalmente existem outros produtos que também são efectivos mas não são listados. É um componente informativo. As sub-práticas são descrições detalhadas que fornecem orientação para interpretar e implementar uma prática genérica ou específica. São componentes informativas significando somente o fornecimento de ideias que podem ser utilizadas para a melhoria do processo. As práticas genéricas são chamadas genéricas porque a mesma prática aplicase a múltiplas áreas de processo. Uma prática genérica é a descrição de uma actividade que é considerada importante para conseguir o objectivo genérico associado. É um componente do tipo esperado. A elaboração de uma prática genérica aparece numa área de processo para fornecer orientação na forma como uma prática genérica deve ser aplicada unicamente à área de processo. É um componente do tipo informativo. Para alcançar um nível particular, a organização deve satisfazer todos os objectivos apropriados à área de processo ou conjunto de áreas de processos para a melhoria, sendo uma capacidade ou um nível de maturidade. [PJMG quality, 104]

139 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE O CMMI proporciona uma eficiente e efectiva avaliação e melhoria de múltiplos processos de diferentes disciplinas numa organização; a redução de custos de formação e avaliação; uma visão comum e integrada de melhoria para todos os elementos de uma organização; e um novo meio de representar informação de disciplinas específicas numa norma, por intermédio de processos de melhoria comprovados (Trigo, 2009). As organizações podem atingir melhoramentos progressivos no que diz respeito à sua maturidade, atingindo primeiramente uma estabilidade a nível do projecto, e avançando nos níveis seguintes e no melhoramento contínuo dos processos, usando tanto dados quantitativos como qualitativos na tomada de decisões. A representação faseada (Figura 4.6) identifica os níveis de maturidade no qual uma organização deve evoluir para estabelecer uma cultura de excelência. Como cada nível de maturidade tem a sua base no nível anterior, passar níveis de maturidade é normalmente contra-producente. Um processo definido que é característica do nível 3 pode ser posto em risco se as práticas de gestão do nível 2 estão deficientemente definidas e implementadas. Por exemplo, uma má gestão pode criar um fraco planeamento de compromisso do calendário ou levar à falha do controlo de mudanças dos requisitos de base. Repetitivo Os processos são definidos e mantidos AD-HOC O controlo do projecto não é efectuado; os eventos ocorrem de forma aleatória Definido Os processos são definidos qualitativamente e institucionalizados Gerido Os processos são aferidos qualitativamente Optimizado Os melhoramentos dão feedback para os processos. O processo está em mudança constante - Qualidade + + Riscos. - + Custo.- Figura 4.6: Níveis de Maturidade do Modelo CMMI Fonte: Adaptado de (eproject, Dezembro, 2004; Jokela & Lalli, 2003) [PJMG quality, 105]

140 CAPÍTULO QUATRO - GESTÃO DA QUALIDADE Contrapondo o CMMI com o PMBoK conclui-se que o CMMI tem como objectivo servir de guia para as empresas melhorarem os processos que já utilizam, dando ênfase na empresa como organização, e actua só em organizações que desenvolvem projectos de software. Já o PMBoK actua em organizações que desenvolvem projectos em qualquer área, dando ênfase nas qualificações do gestor de projectos. Resumindo, o CMMI explica o que fazer e o PMBoK ensina como fazer Termos relacionados com a qualidade Há um conjunto de termos no âmbito da Qualidade que importa clarificar antes de prosseguirmos. Todos os termos que a seguir se apresentam estão de acordo com a norma portuguesa NP EN ISO 9000:2000 Sistemas de Gestão da Qualidade e Vocabulário. de características intrínsecas; Requisito: necessidade ou expectativa expressa, geralmente implícita ou obrigatória; Classe: categoria ou classificação atribuída a diferentes requisitos da qualidade de produtos, processos ou sistemas com o mesmo uso funcional; Satisfação de clientes: percepção dos clientes quanto ao grau de satisfação dos seus requisitos; Capacidade: aptidão de uma organização, sistema ou processo para realizar um produto que satisfaça os requisitos desse produto; Sistema: conjunto de elementos interrelacionados e interactuantes; Sistema de gestão: sistema para o estabelecimento da política e dos objectivos e para a concretização desses objectivos; Sistemas de gestão da qualidade: sistema de gestão para dirigir e controlar uma organização no que respeita à qualidade; Política da qualidade: conjunto de intenções e de orientações de uma organização relacionadas com a qualidade, como formalmente expressas pela gestão de topo; [PJMG quality, 106]

141 NORMAS E REFERENCIAIS DOS SISTEMAS DE GESTÃO DE QUALIDADE Objectivo da qualidade: algo que se procura obter ou atingir relativo à qualidade; Gestão da qualidade: actividades coordenadas para dirigir e controlar uma organização no que respeita à qualidade; Planeamento da qualidade: parte da gestão da qualidade orientada para o estabelecimento dos objectivos da qualidade e para a especificação dos processos operacionais e dos recursos relacionados necessários para atingir esses objectivos; Controlo da qualidade: parte de gestão da qualidade orientada para a satisfação dos requisitos da qualidade; Garantia da qualidade: parte da gestão da qualidade orientada no sentido de gerar confiança quanto à satisfação dos requisitos da qualidade; Melhoria da qualidade: parte da gestão da qualidade orientada para o aumento da capacidade para satisfazer os requisitos da qualidade; Melhoria contínua: actividade permanente com vista a incrementar a capacidade para satisfazer requisitos; Eficácia: medida em que as actividades planeadas foram realizadas e conseguidos os resultados planeados; Eficiência: relação entre os resultados obtidos e os recursos utilizados. [PJMG quality, 107]

142

143 Capítulo 5 O Gestor de Projectos "De facto, não fracassei ao tentar, cerca de dez mil vezes, desenvolver um acumulador. Simplesmente, encontrei dez mil maneiras que não funcionam." Thomas A. Edison Alguém que nunca tenha cometido um erro é porque nunca tentou nada de novo." Albert Einstein ( ) Sendo o gestor de projectos o actor principal deste trabalho, neste capítulo é apresentada a caracterização da função do gestor de projectos através da descrição das suas responsabilidades e competências. São focadas as interacções do gestor com os outros intervenientes de um projecto. As the project manager is the main actor in this work, in this chapter we will be able to read about the project manager functions characterization through the description of his responsibilities, abilities and roles.the chapter also describes the manager interactions with other actors in a project. O gestor de projecto é responsável pelo processo usado para gerir um projecto. A eficácia dos projectos depende em grande parte da capacidade e competências do gestor que deve estar preparado para os factores endógenos e exógenos ao projecto. Saber motivar as pessoas envolvidas, prever a probabilidade de ocorrência de um determinado incidente no projecto, comunicar os respectivos objectivos e resultados, planear e controlar adequadamente os custos e cumprir os principais critérios de qualidade são algumas das competências (skills) que o gestor de projectos deve ter (APOGEP, 2009). É no gestor de projectos, no seu papel na organização, nos projectos e respectiva gestão, que nos vamos focar nas próximas secções deste capítulo. 5.1 CARACTERIZAÇÃO DO GESTOR DE PROJECTOS Tal como um engenheiro para exercer algumas das suas actividades profissionais precisa de ser reconhecido por algumas instituições (por exemplo, Ordem [PJMG quality, 109]

144 CAPÍTULO CINCO - O GESTOR DE PROJECTOS dos Engenheiros, ANACOM 6, Direcção Geral de Energia), também um profissional em Gestão de Projectos começou há alguns anos a ter uma necessidade de certificação profissional. Existem duas instituições a nível internacional que proporcionam a certificação de gestores de projectos, o Project Management Institute (PMI), criado em 1969 e a International Project Management Association (IPMA), criada em O PMI e a IPMA têm em Portugal órgãos nacionais associados. O PMI tem um chapter Portugal criado em 2000 e a APOGEP (Associação Portuguesa de Gestão de Projectos) foi criada em 1994 e está desde o início ligada à IPMA, a maior entidade europeia no domínio da gestão de projectos. Como se pode constatar, em Portugal deram-se os primeiros passos no âmbito da Gestão de Projectos moderna há relativamente poucos anos. O gestor de projectos tem um papel crucial no êxito do projecto. É responsável por planear, organizar, coordenar e controlar as tarefas do projecto, alocando recursos humanos, financeiros e de informação, de forma a garantir o sucesso do projecto (Karlsen, Gottschalk, & Andersen, 2002). Nos últimos anos, devido ao facto de cada vez se dar mais valor à gestão de projectos, a importância do papel do gestor de projectos tem evoluído de tal forma que os gestores têm cada vez mais funções (Miguel, 2002). Desta forma, os seus conhecimentos têm de ser a vários níveis, relacionados, em parte, com as áreas do conhecimento da gestão de projectos. Podemos definir pelo menos três grupos de capacidades que o gestor precisa desempenhar de forma a obter sucesso nos seus projectos (Katz, 1955): capacidades técnicas, humanas e conceptuais. A capacidade técnica está relacionada com a sua aptidão para utilizar os seus conhecimentos e os métodos e tecnologias ao seu dispor para promover o sucesso dos projectos. Estas habilidades são importantes, visto que o gestor tem a responsabilidade de definir os requisitos dos projectos, como as tarefas são realizadas, que recursos humanos e não humanos são necessários para as realizar (Kerzner, 2001), tendo em conta as necessidades do cliente (Heerkens, 2002). Além disso, é necessário adquirir conhecimentos da área da gestão de projectos, conhecendo ferramentas, técnicas, processos e tecnologias que permitam uma gestão eficiente de cada projecto (Heerkens, 2002). Nos gestores de projectos de desenvolvimento de software esta capacidade é ainda mais importante, já que o gestor tem ainda de conhecer instrumentos, como, por exemplo, 6 ANACOM: Autoridade Nacional de Comunicações [PJMG quality, 110]

145 CARACTERIZAÇÃO DO GESTOR DE PROJECTOS processos, técnicas de análise, de programação, hardware, aplicações já existentes, entre outras, que lhe permitirão conhecer melhor as tarefas a realizar durante a execução do projecto. Além de precisar de conhecimentos sobre tecnologias, o gestor de projectos tem de conseguir tirar o melhor partido das suas potencialidades (Karlsen, Gottschalk, & Andersen, 2002). Por vezes, mesmo que haja tecnologia disponível, os gestores não conseguem aproveitar as suas características para optimizar as actividades dos projectos (Kenneth C Laudon & Laudon, 2006). A capacidade humana relaciona-se com as relações sociais dentro da organização e, consequentemente, na equipa do projecto. Esta é talvez das capacidades mais difíceis de aplicar, já que compreender o comportamento humano é algo complexo. O gestor tem de ter conhecimentos a nível de gestão de recursos humanos, exercendo uma liderança que promova a coesão da equipa, criando um clima de confiança entre os indivíduos que o rodeiam, e mantendo uma atitude de apoio a essa equipa. Tudo isto de forma a conseguir elevados níveis de motivação dos intervenientes do projecto, já que só assim conseguirá obter desses recursos a eficiência e produtividade necessárias para o sucesso do trabalho (Miguel, 2002). Embora os gestores de projectos tenham cada vez mais responsabilidade, têm também cada vez menos autoridade. As suas habilidades nas relações interpessoais tornam-se ainda mais importantes já que têm de conseguir controlar uma equipa sem terem uma autoridade elevada, ou seja, tem que se ter uma grande capacidade de influenciar e convencer os outros (Heerkens, 2002). Segundo Kernzer, um dos maiores desafios para o gestor de projectos é conseguir alcançar os objectivos dos seus projectos a nível de tempo, custo e desempenho, mesmo que os recursos humanos estejam com um desempenho abaixo da média esperada (Kerzner, 2001). Heerkens definiu uma lista de capacidades comportamentais que um gestor de projectos deve ter: liderança individual e da equipa, boa comunicação oral e escrita e capacidade de resolução de conflitos, de delegação, de negociação e de influencia sobre os outros (Heerkens, 2002). No que concerne à capacidade conceptual um gestor de projectos tem que compreender a estrutura, a cultura, a política, os objectivos, os processos de negócio e a situação económica da organização, ou seja, conhecer as suas principais operações (Kerzner, 2001). Tem de conseguir monitorizar e controlar os processos do projecto, fazendo uma eficiente gestão de riscos manifestando uma atitude proactiva, a fim de antecipar possíveis problemas e tendo a noção [PJMG quality, 111]

146 CAPÍTULO CINCO - O GESTOR DE PROJECTOS que é um agente de mudança (Miguel, 2002) mas contudo sem por em causa a política global da organização (Kerzner, 2001). Os projectos em TI continuam a ser inerentemente arriscados uma vez que a tecnologia e as necessidades das organizações continuam a mudar e a evoluir. A equipa de projecto deve ter uma abordagem assertiva na gestão de riscos enquanto procura conseguir benefícios para o projecto. Dado que cada projecto é diferente, no início do projecto devem ser esclarecidas as responsabilidades específicas e a autoridade do gestor para que não existam confusões sobre as funções e serviços que são esperadas do gestor naquele projecto específico. Além disso, deve também ser decidido que responsabilidades e autoridade o gestor de projecto vai delegar a outras pessoas da equipa de projecto, tais como líderes e coordenadores. Na Figura 5.1 estão representados os valores fundamentais que o gestor de projecto deve ter em conta na abordagem da gestão de projectos. Figura 5.1: Valores fundamentais para a abordagem da gestão de projectos O gestor de projectos enfrenta dois desafios principais: Decidir o que fazer, apesar da incerteza, risco, e uma grande quantidade de informação potencialmente relevante; Como garantir o desempenho das tarefas, através de um amplo e diversificado conjunto de pessoas, apesar de ter um controlo directo e limitado sobre elas. A Tabela 5.1 apresenta as características chave requeridas pelo gestor de projecto de forma a dar resposta a estes desafios. [PJMG quality, 112]

147 RESPONSABILIDADES Características Pessoais Mostrar bom senso Ser organizado Foco sobre o futuro Ter capacidade crítica Perspectiva de manter os objectivos fundamentais Interpessoais Liderar a equipa mantendo a coesão numa equipa de projecto multidisciplinar Construir uma relação de confiança e de respeito e utilizar a sua autoridade quando a situação o exigir Demonstrar união, estabilidade e resistência em situações de pressão Adaptar o estilo de gestão à situação concreta, utilizar a negociação na gestão de conflitos Comunicar eficazmente Ser sensível à cultura e políticas da organização Tabela 5.1: Características pessoais e interpessoais do gestor de projectos Nas secções seguintes analisam-se as responsabilidades, competências e interacções que devem ser consideradas na função do gestor de projectos. 5.2 RESPONSABILIDADES O gestor deve compreender a estratégia do negócio, os objectivos do cliente e ter uma visão clara da forma como alcançar esses objectivos. O gestor do projecto deve acordar com o cliente o âmbito do projecto e resolver eventuais conflitos entre os diferentes objectivos dos seus intervenientes. O gestor de projecto é responsável pelo planeamento do projecto, actualização do plano e monitorização do progresso do mesmo de acordo com o plano elaborado. É também responsável por assegurar que as actividades, no âmbito da qualidade, decorrem e são realizadas conforme o previsto no plano de projecto. Tendo em conta as responsabilidades do gestor de projectos, podemos afirmar que essas responsabilidades se dividem em quatro níveis (Heerkens, 2002): responsabilidade com o projecto, com a organização, com a equipa e consigo mesmo. A nível do projecto, o gestor é responsável por garantir que sejam cumpridos os prazos das entregas, os orçamentos, as funcionalidades e a qualidade, garantindo assim o sucesso do projecto. A nível da organização, é res- [PJMG quality, 113]

148 CAPÍTULO CINCO - O GESTOR DE PROJECTOS ponsável por fazer com que o projecto traga retornos positivos à organização e que os seus procedimentos se enquadrem na política global da empresa. Quanto à equipa, o gestor deve conseguir um equilíbrio entre as necessidades de cada um dos indivíduos da equipa e as necessidades da equipa como uma unidade social (Heerkens, 2002). Os quatro níveis de responsabilidades são, por vezes, muito complexos de gerir já que surgem conflitos entre as partes. Cabe ao gestor de projectos decidir as prioridades, o que se pode revelar uma tarefa muito complicada. Por um lado, tem de respeitar a organização, por outro a equipa de trabalho e, por fim, ainda tem de garantir o sucesso do projecto. Devido a estes conflitos, as responsabilidades consigo próprio são muitas vezes deixadas para trás o que acaba por o deixar insatisfeito com o desenrolar do projecto (Heerkens, 2002). Outro aspecto muito importante do gestor de projecto, é o estilo de liderança que adopta. A liderança democrática do gestor de projectos, associada à gestão de projectos, influencia profundamente e positivamente a realização do projecto e o sucesso do mesmo (L. Li, Yi, & Chai, 2007). No âmbito da gestão em TI, Karlsen, tendo em conta um estudo de Grover, Jeong, Kettinger e Lee, identificou seis papéis que os gestores devem desempenhar, estando eles interligados com as já referidas capacidades que os gestores devem ter (Grover, Jeong, Kettinger, & Lee, 1993; Karlsen, Gottschalk, & Andersen, 2002): líder, alocação de recursos, porta-voz, empreendedor, monitor e ligação. Um gestor de projectos tem também de desempenhar cada um destes papéis. Desempenha um papel de líder, já que deve executar supervisão, organização e coordenação dos recursos humanos que compõem as suas equipas. Desempenha um papel de alocação de recursos, pois é ele que estuda as necessidades dos projectos a nível de recursos humanos, financeiros e de informação. O gestor funciona como porta-voz, já que é ele que comunica com elementos exteriores à equipa de projecto, normalmente com o cliente. O gestor de projectos pode desempenhar um papel de empreendedor, na medida em que pode ser ele a negociar com o cliente, ou a disputar projectos novos com outras equipas de projecto podendo assim trazer retornos positivos para a organização. Tem um papel de monitor no que diz respeito ao acompanhamento de mudanças do meio onde os seus projectos vão ser implementados, para que assim consiga criar estratégias de forma a maximizar o desempenho do mesmo. Por último, funciona como elemento de ligação entre a sua equipa, a organização e o cliente. [PJMG quality, 114]

149 COMPETÊNCIAS As decisões dos gestores de projectos de desenvolvimento de software são difíceis ao longo de todo o ciclo de vida desses projectos (Bertolino & Mirandola, 2007). Os requisitos dos projectos modificam-se inúmeras vezes, frequentemente ocorrem erros de análise, há uma comunicação deficiente com os clientes, falta de conhecimentos do gestor em relação ao âmbito do projecto a realizar, ocorrem problemas técnicos (Moynihan, 1997), as alterações do meio já não justificam determinadas fracções do projecto, entre outros problemas que tornam o desenho de decisões algo muito complexo (Bertolino & Mirandola, 2007). Em suma, as funções dos gestores de projectos requerem cada vez mais capacidades de gestão e conhecimentos em diferentes áreas. Só assim será possível coordenar equipas, compreender clientes, gerir recursos e prazos que levarão ao sucesso dos projectos. 5.3 COMPETÊNCIAS As competências do gestor de projectos são claramente um factor vital no sucesso de projectos. No entanto continuam a ser qualidades difíceis de quantificar. As competências do gestor fornecem a base para as competências em gestão de projectos. As competências principais são identificadas e definidas na Tabela 5.2. Competências Liderança Comunicação Designação Descrição Foca-se em estabelecer direcção, alinhamento de recursos humanos, motivar e inspirar. A liderança não deve estar limitada ao gestor do projecto. Deve ser demonstrada em todos os níveis hierárquicos da equipa de gestão do projecto. Envolve o intercâmbio de informações, e pode assumir muitas formas diferentes tais como comunicação escrita, oral, interna, externa, formal, informal, vertical, horizontal. Comunicar eficazmente requer a aplicação de técnicas, tais como: utilização de modelos; escolha dos meios de comunicação; estilo de escrita; [PJMG quality, 115]

150 CAPÍTULO CINCO - O GESTOR DE PROJECTOS Capacidade de negociação Resolução de problemas Gestão de conflitos técnicas de apresentação; planeamento e gestão de reuniões. Negociação envolve conferenciar com as partes envolvidas no projecto, de forma a alcançar um acordo. As negociações ocorrem dentro de muitas das actividades de gestão de projecto. Durante o projecto, pode surgir a necessidade de negociação de um ou alguns dos itens seguintes: âmbito custo e cronograma; alterações de âmbito, custo ou cronograma; termos e condições do contrato; compromissos (atribuições); recursos. Resolução de problemas é o resultado da definição do problema e da respectiva tomada de decisão para a sua resolução. A definição do problema requer uma distinção entre causas e sintomas. A tomada de decisão inclui a análise do problema para identificar soluções viáveis, efectuar a escolha entre as respectivas soluções e aplicação dessa escolha. As decisões também envolvem o elemento tempo: a decisão certa é a melhor solução no momento em que deve ser efectuada. Gestão de conflitos envolve a arbitragem entre as diferentes perspectivas, prioridades, atitudes, visões e orientações, para chegar à melhor solução para o projecto. Evitar conflitos durante um projecto pode ter como consequência a perda de controlo sobre o mesmo. Existem várias técnicas de gestão de conflitos que podem ser adoptadas: Smoothing: analisar os conflitos nas devidas proporções e enfatizar a compreensão e a comunhão de objectivos e dos diversos pontos de vista; Comprometimento: encontrar opções ou soluções que sejam aceitáveis para as partes envolvidas de forma a alcançar um compromisso; Autoridade: exercer a autoridade para forçar uma opção e resolver situação de conflito; [PJMG quality, 116]

151 COMPETÊNCIAS Influência na organização Withdrawing: quando a resolução do conflito pode ser mais prejudicial para o projeto que o próprio conflito; Confrontação: potenciar uma situação que conduza ao aparecimento de um conflito que estava implícito. Envolve habilidade e aptidões para atingir objectivos. Exige uma compreensão das estruturas formais e informais dentro das organizações envolvidas no projecto. O poder, política e persuasão podem ser utilizados em sentido positivo, para orientar os recursos humanos a exectuarem actividades que normalmente não fariam, dentro de um grupo que pode ter interesses muito divergentes. Tabela 5.2: Competências gerais do gestor de projecto Actualmente os gestores de projecto exercem a sua actividade num contexto de mudança rápida, com um conjunto vasto de intervenientes e com a infuência de vários factores externos. Os projectos são mais complexos, em maior número e com naturezas diversificadas. A busca pelas competências comportamentais dos gestores e membros da equipa de projecto tornaram-se mais pronunciadas e exigentes (IPMA, 2006). No entanto estamos perante um forte e crescente sentido de individualismo. A necessidade de uma descrição detalhada das competências para a gestão de projectos, no actual contexto de mudança é óbvia. A International Project Management Association (IPMA) representa as competência do gestor de projecto através do olho da competência conforme Figura 5.2. A figura representa a integração de todos os elementos da gestão de projectos visualizados através dos olhos do gestor de projecto, ao ser efecutada a avaliação de uma situação específica. A simbologia do olho indica também duas características importantes: clareza e visão. Este símbolo é apropriado, no que se refere ao ser humano, o gestor de projectos, que é a parte mais importante em qualquer avaliação da competência em gestão de projectos. [PJMG quality, 117]

152 CAPÍTULO CINCO - O GESTOR DE PROJECTOS Figura 5.2: Competências do gestor de projecto: the eye of competence Fonte: Adaptado de (IPMA, 2006). A sua composição inclui três faixas de competências: Competências técnicas descrevem os elementos fundamentais ao nível técnico de competências de gestão. Também são referidas como elementos sólidos; Competências comportamentais descrevem os elementos pessoais das competências de gestão. O conteúdo desta faixa abrange também as atitudes e aptidões do gestor de projecto; Competências contextuais descrevem os elementos das competências de gestão relacionadas com o contexto do projecto. Esta gama abrange a competência do gestor de projeto na gestão de relações com a organização e respectivo alinhamento com a gestão e a capacidade de funcionar em projectos focados na organização. 5.4 INTERACÇÕES As interacções exactas e a comunicação oportuna do gestor de projecto com os stakeholders são um factor importante para o sucesso do projecto. As interacções chave com as outras partes envolvidas no projecto são: Interação com o patrocinador do projecto; Interação com o gestor do projecto do cliente; Interação com a equipa de projecto. [PJMG quality, 118]

153 INTERACÇÕES Na Tabela 5.3 são descritas as interacções principais com os diferentes tipos de actores do projecto. Interacções Stakeholders Patrocinador do projecto Gestor do projecto do cliente Equipa de projecto Descrição Informar a gestão dos aspectos críticos do projecto; Recomendar mudanças na organização ou no âmbito do projecto, caso se revele necessário para o sucesso do projecto; Pedido de financiamento adicional e fornecer a respectiva justificação; Identificar os obstáculos para satisfazer os factores críticos de sucesso definidos para o projecto. O patrocinador não deve ser sobrecarregado com detalhes. O foco deve ser apenas nos pontos importantes. Elaborar um plano com acções para cada aspecto crítico identificado. Comunicar o estado do projecto, incluindo o orçamento actualizado; Documentar e actualizar o estado financeiro do projecto e actualizar previsões com base em dados reais e em estimativas para a conclusão; Endereçar questões relacionadas com o negócio, com o sistema e com a equipa; Endereçar questões do âmbito no tempo oportuno. Deve existir sensibilidade na forma de comunicação com o cliente. Ajudar o cliente a ter sucesso, em vez de procurar as respectivas falhas. Deve sempre ser definido o que é preciso ser efectuado e quem deve ser responsável. Relatórios de acompanhamento e reuniões são métodos eficazes de comunicação. Planear tempo para questões de investigação e verificação de factos. Ser cuidadoso para não serem omitidas as pessoas correctas da respectiva lista de distribuição. Fornecer informação detalhada e periódica à equipa de projecto; Resumir concretizações, planeamentos e questões para as tarefas mais detalhadas; Identificar metas que estão próximas do seu termo e respectivos deliverables; [PJMG quality, 119]

154 CAPÍTULO CINCO - O GESTOR DE PROJECTOS Resolver as questões e problemas pendentes; Conhecer os membros da equipa e procurar eventuais problemas escondidos. Devem ser definidas, de forma clara e inequívoca, as expectativas e fornecer a direcção específica aos membros da equipa, quando necessário. Explícitar com clareza quem é responsável por determinada tarefa ou item de acção. Durante as reuniões, programar as discussões detalhadas para outra altura, de forma a serem cumpridos todos os objectivos da agenda. Assegurar que as actas de reuniões mostram claramente a toda a equipa que é responsável pela conclusão das tarefas atribuídas. Tabela 5.3: Interacções principais do gestor de projectos com os diferentes tipos de actores do projecto (stakeholders). Finda a apresentação da primeira parte da tese onde foram apresentados alguns conceitos fundamentais com o objectivo de propiciar uma base sólida para o entendimento do trabalho desenvolvido, é iniciado no próximo capítulo um segundo momento da tese, onde é descrito o processo de investigação que conduziu à obtenção dos resultados, que irão ser apresentados ao longo da segunda parte. [PJMG quality, 120]

155 Segunda Parte CONTRIBUIÇÕES O objectivo central da segunda parte da tese é a apresentação detalhada do modelo de actividades do gestor de projectos no âmbito da gestão da qualidade. É constituída por quatro capítulos. O sexto capítulo proporciona uma breve revisão de abordagens e estratégias de investigação empírica no campo da engenharia de software. É apresentado e descrito o processo de investigação e os respectivos instrumentos utilizados no desenvolvimento do trabalho. É ainda efectuada a descrição do processo de recolha, de tratamento e análise de dados. No sétimo capítulo é apresentada a caracterização da realidade da gestão de projectos em Portugal nas grandes empresas. É descrito o estudo efectuado e os resultados obtidos. No capítulo oito é proposto o modelo de actividades do gestor de projectos no âmbito da garantia de qualidade. É detalhado o modelo construído com base na análise dos resultados. São identificadas as actividades fundamentais do gestor e apresentada uma lista ordenada das actividades determinantes. [PJMG quality, 121]

156

157 Second Part CONTRIBUTIONS The main purpose of the second part of the thesis is a detailed presentation of the developed model and it is constituted by four chapters. The sixth chapter provides us a brief revision of approaches and strategies of empirical investigation in the software engineering field. Not only the investigation process is presented and described in this chapter but also the tools used in the work development. It also makes the description of the recollection process of the treatment and data processing and analyses. In the seventh chapter we carried out a characterization of the reality of projects management in the big enterprises in Portugal. The study and results are also described in this chapter. In chapter eight the model of activities of the projects manager in the quality area are referred. Based on the results we built a detailed model. The core activities of the manager are identified and a list of the critical activities is given in this chapter too. [PJMG quality, 123]

158

159 Capítulo 6 Processo de investigação A experiência mostra que, prevendo com bastante antecedência os passos a serem dados, é possível agir rapidamente na hora de executá-los. Cardeal Richelieu ( ) Aquele que duvida e não investiga torna-se não só infeliz mas também injusto. Pascal Se soubéssemos o que iríamos fazer, não chamaríamos a isto investigação, pois não? Albert Einstein Este capítulo proporciona uma breve revisão de abordagens e estratégias de investigação empírica no campo da engenharia de software. É apresentado e descrito o processo de investigação seguido e os respectivos instrumentos que foram utilizados. Efectua-se a descrição do processo de recolha e tratamento de dados. This chapter provides a brief review of empirical research approaches and strategies in the software engineering field. The project design is described and the research tools are presented. The collection and data processing are also described. As fontes da cultura científica são diversas e a concepção do termo ciência foi evoluindo ou alterando-se ao longo de séculos de História, desde a Antiguidade de Platão e Aristóteles, onde a interdisciplinaridade sobressaía sobre a disciplinaridade, passando pelo Período Medieval, cuja total compreensão está longe de ter sido revelada, pela Modernidade de Galileu, Descartes, Newton ou Lavoisier, que estabeleceram metodologias científicas e filosóficas rigorosas, isentas de ambiguidade, até se atingir a Época Contemporânea com um poderio científico-técnico nunca antes igualado (Gonçalves, 1997). Existem variadas classificações de ciência, baseada em critérios diferentes. Uma das classificações da ciência é a divisão em ciências formais (lógica e matemática) e empíricas (como a biologia, química, etc.). Na primeira são utilizados métodos de investigação dedutivos, as últimas têm por base métodos [PJMG quality, 125]

160 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO empíricos (dedutivo e indutivo). Esta não é, porém, a única classificação usada. Bunge (Bunge, 1967) faz uma distinção entre as ciências puras e aplicadas, incluindo as tecnologias nas ciências aplicadas. Consoante o objectivo do estudo que se pretende, procura-se encontrar um método que melhor se adequa a esse estudo. A engenharia como ciência constrói novos objectos (modelos, técnicas, metodologias e similares) que podem ser objectos de estudo para a investigação científica. Seguindo esta linha de raciocínio, a engenharia não foca o seu conhecimento apenas nos objectos mas principalmente na experiência (know-how). 6.1 ABORDAGENS DE INVESTIGAÇÃO A investigação em Engenharia do Software (ES) trata com problemas de natureza diferente que devem ser investigados com métodos diferentes. Os métodos de investigação podem ser classificados de diversas formas. Uma das classificações que é reconhecida e aceite pela comunidade científica é a divisão em duas categorias (Michael D. Myers, 1997): métodos quantitativos e qualitativos. Os métodos de investigação quantitativos são especialmente vocacionados para estudar os fenómenos naturais originalmente desenvolvidos nas ciências naturais. Os métodos de investigação qualitativos foram desenvolvidos nas ciências sociais para permitir aos investigadores estudar os fenómenos sociais e culturais, ou seja, para ajudar a compreender as pessoas e os contextos sociais e culturais nos quais vivem. O estudo destes fenómenos é tipicamente efectuado com base em entrevistas, questionários, documentos, impressões e reacções do investigador. Incluem trabalhos de investigação, estudos de caso, etnografia. Embora a maior parte dos investigadores desenvolva trabalho de investigação qualitativo ou quantitativo, alguns investigadores sugerem a combinação de um ou mais métodos de investigação num mesmo estudo (processo de triangulação). Alguns autores (Esperanza, 2005) acrescentam um terceiro tipo de métodos, os métodos de investigação criativa, que são os que recorrem mais às artes (embora a criatividade e a ciência estejam a tornar-se cada vez mais relacionadas). A Tabela 6.1 mostra os principais objectos de estudo, ciências e os métodos de investigação utilizados em ES. [PJMG quality, 126]

161 ABORDAGENS DE INVESTIGAÇÃO Tipo de problema Ciência Objecto de estudo Características/ Atributos Métodos Estudo de engenharia Software engineering science Construção de novos objectos Engenharia Qualitativo Criativo Estudo de natureza empírica Software science Objecto construído Empírico Quantitativo Estudo de natureza cultural e social Science of Information systems Implementação e utilização de objectos construídos Cultural e Social Qualitativo Tabela 6.1: Sumário do tipo de problema, área da ciência e métodos utilizados em Engenharia do software Fonte: Adaptado de (Esperanza, 2005) O método típico de investigação para ES baseia-se frequentemente no modelo por etapas, proposto por Bunge (Bunge, 1967) para a investigação científica em geral (Figura 6.1). Embora estas etapas sejam baseadas no método hipotético dedutivo, devido ao seu carácter geral podem ser aplicadas, com algumas modificações, em qualquer tipo de investigação. A etapa resolução é aquela onde residem as maiores diferenças, uma vez que é nesta fase que é efectuada a escolha das técnicas (ensaios, entrevistas, etc.) para saber se o método de investigação adequado é qualitativo, quantitativo ou criativo. A questão importante, e onde reside a maior dificuldade no domínio da investigação, é a identificação da(s) estratégia(s) mais adequada(s) ao problema em análise. Se o problema é identificar os factores que influenciam um determinado resultado ou para testar o efeito de determinado processo, abordagens quantitativas devem ser escolhidas. Se o problema está em compreender por que razão os resultados são como são ou identificar as causas, uma abordagem qualitativa é a mais adequada. [PJMG quality, 127]

162 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO Figura 6.1: Método de investigação baseado em etapas proposto por Bunge Fonte: (Bunge, 1967; Marcos, 2005) A abordagem mista utiliza diferentes métodos nas diversas fases de um estudo. Yin (Robert K. Yin, 2003) defende que a escolha de uma abordagem deve depender da análise de três condições: O tipo das questões de investigação questões do tipo como e porquê são explicativas e, em regra, devem ser estudadas ao longo do tempo, em experiências ou estudos de casos replicados. O quê, quem, onde, quantos, ou quanto são questões que incidem sobre a frequência, ou descrevem a incidência de um determinado fenómeno; A extensão do controlo - apenas em experimentação, o investigador pode controlar eventos comportamentais. Num estudo de caso, o investigador não pode controlar os eventos, mas pode controlar as medidas a serem usadas; [PJMG quality, 128]

163 ABORDAGENS DE INVESTIGAÇÃO O foco a experimentação ou estudo de caso concentra-se na contemporaneidade, em oposição aos inquéritos, que incidem mais sobre os eventos ou factos históricos. Os dois métodos de recolha de dados mais comuns são os questionários e as entrevistas (Babbie, 1990). Os questionários podem, simultaneamente, ser fornecidos em suporte papel ou em formato electrónico (por exemplo, ou Internet). Comparativamente com os questionários, as vantagens das entrevistas são: A entrevista consegue tipicamente alcançar maiores taxas de resposta do que, por exemplo, um inquérito via correio electrónico ( ); Um entrevistador geralmente diminui o número de respostas do tipo "não sabe" e "não responde ; É possível o entrevistador observar e fazer perguntas. A principal desvantagem de uma entrevista consiste no facto de exigir um maior esforço que um questionário e consumir mais tempo. No entanto, a entrevista pode incluir várias perguntas abertas para ajudar a obter novas perspectivas sobre as questões de investigação. Segundo Orlikowski e Baroudi, existem três perspectivas filosóficas que, de certa forma, podem classificar a investigação (M. D. Myers & Avison, 2007; Orlikowski & Baroudi, 1991): positivista, interpretativa e crítica. Os positivistas defendem que os mundos sociais são idênticos ao mundo natural. Como são mundos com as mesmas características, a forma de os investigar pode ter os mesmos princípios (Dawn, Uday, & Ajay, 2001). A investigação positivista é comparável à científica na medida em que se destina a produzir uma representação exacta da realidade (Villiers, 2005). O paradigma interpretativo, ou construtivista, declara que o conhecimento é algo adquirido socialmente por pessoas activas no processo de investigação (Dawn, Uday, & Ajay, 2001). Quer isto dizer que o acesso à realidade, dado ou socialmente construído, se faz através de construções sociais, como a linguagem, a consciência e de significados compartilhados (M. D. Myers & Avison, 2007). [PJMG quality, 129]

164 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO Por último, os investigadores críticos incidem os seus estudos na crítica social, pois defendem que as pessoas só mudam devido a constrangimentos e conflitos sociais, culturais e políticos (M. D. Myers & Avison, 2007). Tal como na escolha dos métodos a usar, qualitativos ou quantitativos, as três perspectivas filosóficas apresentadas podem adaptar-se às TI, dependendo do que se pretende investigar. No nosso estudo vamos basear-nos no paradigma interpretativo já que este paradigma valoriza os factores sociais, políticos, estruturais, culturais, ambientais e os contextos externos da organização (H. Klein & Myers, 1999), aspectos essenciais no que diz respeito à gestão de projectos. 6.2 DESENHO DA INVESTIGAÇÃO A determinação do método de investigação mais adequado aos fins de um projecto que se pretende desenvolver tem sido, é e será (possivelmente) um assunto polémico e por isso em constante discussão e evolução (Gable, 1994; Stolen, 1993). É um assunto complexo, e por isso sem respostas imediatas (Amaral, 1994; Varajão, 2002). Na área particular dos SI, devido quer à sua complexidade quer à sua natureza multidisciplinar (Venkatraman, 1986), ainda é mais evidente esta realidade (Galliers, 1992). Numa investigação, a metodologia funciona como um mapa que orienta e conduz até ao destino (Sarmento, 2002). A escolha do caminho para chegar ao objectivo dá-se, de acordo com Yin (1994), através da análise do tipo de questões formuladas. Acautelar os aspectos metodológicos num processo de investigação, constitui uma etapa fundamental para o sucesso do trabalho (Santos, 2004). A investigação qualitativa tem sido considerada por vários autores como válida para a investigação em SI (Avison, Lau, Myers, & Nielsen, 1999; Carrol & Swatman, 2000; Markus, 1997). Cobre uma diversidade de paradigmas de investigação, entre os quais o paradigma interpretativista que irá ser utilizado nesta investigação, para o qual são utilizados diversos métodos (tais como estudo de casos, estudos de campo, etnografia e investigação-acção), processos e técnicas de investigação. O elemento comum da investigação qualitativa é a recolha de dados na forma de palavras e imagens, as quais são analisadas por métodos que não incluem estatísticas ou quantificação (Strauss & Corbin, 1990). [PJMG quality, 130]

165 DESENHO DA INVESTIGAÇÃO Na sequência de uma análise detalhada do problema, dos aspectos relevantes na elaboração de um trabalho científico e das diferentes abordagens e métodos, definiu-se um processo de investigação com vista a identificar e caracterizar as actividades determinantes da gestão de projectos no âmbito da garantia de qualidade. A Figura 6.2 apresenta as fases seguidas no presente trabalho. Numa fase inicial procedeu-se à definição da área de estudo, seguida da concepção do projecto de investigação. As fases seguintes foram estabelecidas de acordo com os fins do trabalho. As diversas actividades do processo estão inter-relacionadas, não sendo este simplesmente sequencial. Figura 6.2: Projecto de investigação [PJMG quality, 131]

166 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO Nas secções seguintes são descritas detalhadamente as várias etapas do projecto de investigação. 6.3 DEFINIÇÃO DO PROBLEMA O primeiro passo consistiu na identificação da área de estudo onde o problema está inserido. O trabalho de doutoramento proposto insere-se na área de SI e, dentro desta, no domínio da GP de SI. O presente trabalho decorre como consequência natural de um conjunto de trabalhos e actividades efectuados anteriormente nesta área, os quais se encontram resumidos na Tabela 6.2. Os resultados alcançados nesta investigação derivam, também da experiência profissional, da análise e estudo de um conjunto de documentação e elementos que foram sendo utilizados e recolhidos ao longo de dez anos, e da sua respectiva evolução enquanto material de trabalho. Após a identificação da área de estudo seguiu-se a definição do problema. A participação nos diferentes projectos identificados na Tabela 6.2 permitiu uma melhor compreensão da área da gestão de projectos através troca de experiências com diversos gestores de projectos e as respectivas equipas de trabalho caracterizadas por uma grande diversidade de profissionais. A preocupação constante pela obtenção de um projecto de qualidade devido à certificação de qualidade que vigorava nas organizações em que houve a oportunidade de colaborar, a obrigatoriedade na adopção de normas e a constante evolução e realimentação do método utilizado e respectivo sistema de qualidade, permitiu recolher material empírico (registos e documentos) que se revelaram fundamentais nos trabalhos de investigação desenvolvidos no âmbito deste projecto. A definição da área de estudo e da questão de investigação deste projecto é, pois, resultado de um conjunto de experiências, de um envolvimento directo e do profundo interesse pela área da gestão de projectos e pelos problemas actualmente ainda identificados na área. Ano Actividades Entidades Consultora funcional desempenhando as seguintes funções: Participação na elaboração do Business Plan; Participação na realização de propostas; Reuniões de análise; Levantamento e especificação de requisitos Novabase ACD Advanced Custom Development [PJMG quality, 132]

167 DEFINIÇÃO DO PROBLEMA funcionais; Análise de requisitos; Elaboração do caderno de especificação de requisitos; Elaboração de documentação do projecto; Elaboração de documentação no âmbito da certificação de qualidade; Gestão das expectativas do cliente; Coordenação Técnica de Equipas de Análise e Desenvolvimento em diversos projectos, tendo como principais responsabilidades: Coordenação do trabalho desenvolvido pelos programadores; Validação e correcção do trabalho desenvolvido com o caderno de análise efectuado e aceite previamente; Integração e planeamento de tarefas; Gestão de tempo; Reuniões de acompanhamento de projecto; Reporte de informação ao Director de Projecto; Desenho de testes e acompanhamento dos mesmos; Acompanhamento nas fases de instalação e/ou configuração do sistema; Apoio ao arranque na entrada em produção; Reengenharia de processos nas diferentes áreas de negócio dos diversos clientes de forma a optimizar o modo de funcionamento e a simplificar os processos de negócio. Projectos realizados: Sistema de Base de Dados Sectoriais para a DGITA -Direcção Geral das Alfândegas e dos Impostos Especiais sobre o Consumo; Sistema de informação constituído pelos seguintes subsistemas: FAP Fraudes Aduaneiras Potenciais; CEA Controlo Estatístico de Acções; FAC Fraudes Aduaneiras Constatadas; TID Tráfico Ilícito de Drogas e Histó- [PJMG quality, 133]

168 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO rico; Análise e concepção da integração do Portal de Candidaturas e Pedidos de Pagamento On-line com o Site do IFC - Instituto de Gestão de Fundos Comunitários da funcionalidade existente no SIGMA - Sistema Integrado de Gestão dos Fundos Comunitários na Região Autónoma da Madeira; Análise e concepção do sistema e a coordenação da equipa que efectuou a implementação do Site de Reservas Online e Meios de Pagamento Electrónicos para a Movijovem (pousadas de juventude), com a utilização do MBNet (Sistema de compras na Web com Segurança). Consultoria funcional e coordenação técnica de equipas de análise e desenvolvimento em diversos projectos. Projectos realizados: Concepção e coordenação do desenvolvimento da Aplicação SIGA para a Fundação Calouste Gulbenkian (Sistema de Informação para a Gestão de Actas e documentos para o Conselho de Administração da Fundação Calouste Gulbenkian); Responsabilidade pela criação e implementação do protocolo de transferência de dados das Bases de Dados do SIARA e SIBov para a Base de Dados da aplicação SNIRB (Sistema Nacional de Identificação e Registo de Bovinos); Concepção do desenho e implementação da estrutura que suporta o modelo; Manutenção dos seguintes sistemas para a Movijovem: GesRes-Aplicação de Gestão de Reservas e facturação; GesRes Access-Aplicação de Gestão Administrativa; GesRes Web- Aplicação de Gestão de Reservas e facturação para a Web; Integração dos sistemas especificados com o sistema desenvolvido para o site; Responsabilidade pela análise, desenvolvi- Novabase, DM Desenvolvimento à Medida [PJMG quality, 134]

169 DEFINIÇÃO DO PROBLEMA mento e implementação do Site de candidaturas de projectos abrangidos pelo 3º Quadro Comunitário de Apoio para a DGPA (Direcção Geral das Pescas). Participação em projectos de desenvolvimento de Sistemas de Informação, nomeadamente: Projecto SIDReg QCA III (Sistema de Informação do Desenvolvimento Regional), para a DGDR (Direcção Geral do Desenvolvimento Regional) que processa a informação necessária ao financiamento dos fundos estruturais do terceiro Quadro Comunitário de Apoio (QCA III); Projecto SIGEP QCA III (Sistema de Informação de Gestão de Fundos Estruturais das Pescas), que controla e processa toda a informação necessária ao financiamento de fundos estruturais do terceiro Quadro Comunitário de Apoio; Projecto SIGNO (Sistema de Informação para os Gestores Comunitários), que processa toda a informação necessária ao financiamento dos fundos estruturais do 3º Quadro Comunitário de Apoio (QCA III); Formação dos utilizadores dos sistemas. Analista/programadora tendo desempenhado as seguintes funções: Análise de requisitos, desenho e desenvolvimento das aplicações; Consultadoria técnica; Apoio nas fases de instalação/configuração; Apoio às fases de teste e entrada em produção; Formação dos utilizadores das aplicações; Análise de novas funcionalidades; Manutenção das aplicações. Projectos desenvolvidos: Projecto SIDReg (Sistema de Informação do Desenvolvimento Regional), para a DGDR Novabase, DM Desenvolvimento à Medida Novabase, SI Sistemas de Informação [PJMG quality, 135]

170 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO (Direcção Geral do Desenvolvimento Regional); Projecto SIGEP (Sistema de Informação de Gestão de Fundos Estruturais das Pescas), para a Direcção Geral de Pescas e Secretarias Regionais das Regiões Autónomas da Madeira e Açores; Projecto SIGC-SIARA, para a SRAPA (Secretaria Regional de Agricultura, Pescas e Ambiente com a respectiva integração de dados; Projecto SIARA (Sistema de Informação de Explorações Agro-Pecuárias), para a Secretaria Regional de Agricultura e Pescas da Região Autónoma dos Açores; Projecto SIBov (Sistema de Informação dos Efectivos Bovinos), para a Secretaria Regional da Agricultura e Pescas da Região Autónoma dos Açores. Tabela 6.2: Actividades antecedentes e complementares ao projecto de investigação Na GP, o facto do insucesso dos projectos em TIC ser ainda significativo (Standish Group, 2004b, 2006) e de se conseguirem identificar aspectos-chave como causas das suas falhas levam a que a investigação prossiga na procura de metodologias, métodos, técnicas e ferramentas com vista a melhorar a concepção, a construção, a implementação, e o decorrente sucesso dos projectos, com o objectivo de dar resposta às necessidades particulares e específicas da GP em TIC. De acordo com estudos efectuados (Demarco, 1997; Ewusi-Mensah, 2003; Jones, 2004; Kappelman, McKeeman, & Zhang, 2006; Standish Group, 1996, 1998; Yetton, Martin, Sharma, & Johnston, 2000), alguns dos principais aspectos que aumentam a probabilidade de falhas dos projectos de TIC são as faltas de especificação, de uma visão clara dos requisitos e de decomposição do projecto. O nível de detalhe em que o projecto é decomposto não é, muitas vezes, o suficiente para se realizar uma boa estimativa de âmbito, duração, recursos necessários e custos associados. Dada a dimensão dos projectos de TIC e reconhecendo-se que os erros de concepção são os mais difíceis de rectificar, é relevante identificar e gerir, aquan- [PJMG quality, 136]

171 DEFINIÇÃO DO PROBLEMA do da análise e especificação de requisitos, as relações críticas que existem entre eles e que não são óbvias sem a ajuda de métodos específicos. A definição de um problema em investigação consiste na especificação em concreto do que se pretende investigar. A procura de contributos na área da qualidade da GP tornou-se a finalidade deste projecto e conduziu a identificar e caracterizar as actividades determinantes da função do gestor de projectos no âmbito da garantia de qualidade e à decorrente construção de um modelo de actividades. Pretende-se com este modelo contribuir activamente para a competência em gestão de projectos no âmbito da garantia de qualidade. Os trabalhos das fases seguintes do processo foram desenvolvidos de acordo com a estrutura apresentada na Figura 6.2, que corresponde ao desenho do projecto de investigação estabelecido. Numa fase final, os resultados obtidos foram revistos e sintetizados na presente tese. Nas secções seguintes são explicitadas e detalhadas individualmente as diferentes etapas do processo Concepção do projecto de investigação Após a definição do problema procedeu-se à concepção do projecto de investigação, com o objectivo de identificar o método (ou métodos) de investigação mais adequado(s) para encontrar respostas para os contributos perseguidos. Um método de investigação é uma estratégia de pesquisa que parte de pressupostos filosóficos base para a concepção e condução da investigacão (Michael D. Myers, 1997). Na sequência de uma análise detalhada do problema, dos aspectos relevantes na elaboração de um trabalho científico, das diferentes abordagens e métodos apresentados anteriormente, procedeu-se à definição do processo de investigação. Os objectivos do trabalho empírico consistem em: Caracterização da realidade da gestão de projectos em grandes empresas portuguesas; Identificar e caracterizar as actividades fundamentais da função do gestor de projectos no âmbito da garantia de qualidade; Construção de um novo modelo de actividades da gestão de projectos no âmbito da garantia de qualidade; Identificação das actividades determinantes na área da GP e classificação das mesmas. [PJMG quality, 137]

172 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO A utilização de uma abordagem qualitativa afigurou-se como particularmente apropriada para a condução deste projecto, uma vez que permite focar o interesse em toda a complexidade da área em estudo. Como já foi referido na secção anterior, as fontes de informação dos métodos qualitativos incluem a observação, a observação participativa (trabalho de campo), entrevistas, questionários, documentos e textos, bem como as impressões e reacções dos investigadores (Michael D. Myers, 1997). Exemplos de métodos normalmente associados à tradição interpretativa são o estudo de caso, estudo etnográfico, pesquisa-acção e grounded theory. É de referir, no entanto, que a palavra qualitativa não é sinónima de interpretativa. A pesquisa qualitativa pode ser positivista ou interpretativa (Michael D. Myers, 1997). A escolha de um determinado método de pesquisa qualitativa como, por exemplo, o estudo de caso, é independente da posição filosófica subjacente. A pesquisa com base em estudo de caso pode ser positivista (R.K. Yin, 1994) ou interpretativa (Walsham, 1993), tal como a pesquisa baseada na acção pode ser positivista (Clark, 1972) ou interpretativa (Elden& Chisholm, 1993). A razão do interesse crescente dos métodos qualitativos em EI e em SI resulta do desenvolvimento da maior parte das aplicações informáticas terem hoje de considerar, cada vez mais, os factores sociais e humanos. O domínio dos SI há vários anos que passou a ser um domínio misto, tecnológico e social, fundado na necessidade de conciliar soluções tecnológicas com necessidades organizacionais (Michael D. Myers, 1997). Conceitos como normas sociais, valores, crenças, simbolismos e representações, são hoje considerados essenciais para o sucesso de muitos projectos tecnológicos. A escolha do método de pesquisa influencia a forma como o pesquisador efectua a recolha dos dados. A qualidade de uma pesquisa qualitativa depende, sobretudo, da capacidade de recolher os dados (Pozzebon, 1998). A capacidade de escolher o método mais adequado e de recolher os dados com qualidade está relacionada com um dos pré-requisitos para a condução de qualquer pesquisa qualitativa: as habilidades e conhecimentos do pesquisador sobre o tema em investigação (Michael D. Myers, 1997). Os resultados das pesquisas que utilizam métodos qualitativos (como o estudo de caso, por exemplo) dependem fortemente do poder de integração do [PJMG quality, 138]

173 DEFINIÇÃO DO PROBLEMA pesquisador, da sua aptidão na selecção do local e dos métodos de recolha de dados (R.K. Yin, 1994). Além do conhecimento e experiência do investigador, muitas das condições que possibilitam um maior rigor científico podem ser optimizadas com a elaboração de um protocolo. A elaboração de um protocolo é uma estratégia a ser seguida para aumentar a fiabilidade de qualquer estudo qualitativo. Deve conter os instrumentos, os respectivos procedimentos e as regras gerais que deverão ser seguidas na sua utilização (R.K. Yin, 1994). Neste trabalho, após a definição da abordagem de investigação a adoptar, foi traçado um plano de investigação e deu-se início ao projecto formal de investigação, cujas fases principais são descritas em seguida. Para responder às diversas questões subjacentes ao trabalho, o desenho da investigação contemplou várias fases. No sentido de caracterizar a gestão de projectos de desenvolvimento de software em Portugal (primeiro objectivo: caracterização da realidade da gestão de projectos em grandes empresas portuguesas), realizou-se um estudo que envolveu a utilização de um questionário online cujo convite para resposta foi enviado via e via CTT a uma amostra casual estratificada de 200 gestores de projectos entre as 1000 maiores empresas portuguesas em termos de facturação (segundo o Instituto Nacional de Estatística). Os resultados obtidos foram alvo de análise estatística descritiva. Para os dois objectivos seguintes (identificar e caracterizar as actividades fundamentais da função do gestor de projectos no âmbito da garantia de qualidade; construção de um novo modelo de actividades) considerou-se a utilização de estudos de caso, com uma análise qualitativa dos dados, uma vez que se tratam de variáveis complexas. Para tal foram seleccionadas duas empresas. Para Yin (1994) não existe diferença, em termos metodológicos, na utilização de um ou mais estudos de caso. Trata-se de uma opção do investigador quando desenha a investigação. Contudo, as evidências, que resultam de casos múltiplos, são mais entusiasmantes e a investigação mais robusta. A lógica subjacente a um desenho de estudo de casos múltiplos é a de replicação e não de amostragem, ou seja, quando realizamos múltiplos estudos de caso, deveremos, na opinião de Yin (1994), considerá-los como múltiplas experiências e não como diferentes sujeitos a responder a um mesmo questionário. A recolha de dados foi obtida através de técnicas qualitativas: revisão, análise documental e entrevistas semi-estruturadas. A análise dos dados obtidos foi [PJMG quality, 139]

174 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO efectuada, à medida que se realizava a sua recolha, servindo de base orientadora de todo o trabalho empírico. Para o último objectivo foi realizado um estudo Delphi, no qual se pretendeu identificar dentro do conjunto das actividades identificadas quais as mais determinantes para o sucesso. Segundo Deslauriers (Deslauriers, 1991), a análise dos dados permite guiar o investigador na sua amostragem, que é de natureza intencional, e dá-lhe pistas sobre o que lhe resta descobrir relativo ao fenómeno em estudo durante o processo de recolha de dados Estudo de casos A decisão de optar por estudos de caso teve por base os seguintes pressupostos (Lee, 1999): Não se pode separar as características do gestor de projecto, das características das organizações onde os gestores desempenham as suas funções. Tal separação resultaria numa visão incompleta, e até incorrecta, de situações, pois, além das características dos intervenientes, é necessário considerar as relações que se estabelecem entre elas. Para Miles e Huberman (1994), isto conduz à necessidade de conhecer e compreender a riqueza do local onde ocorre o fenómeno; As ocorrências são definidas de acordo com a perspectiva dos actores organizacionais, pelo que o seu ponto de vista tem de ser considerado. O estudo de caso pressupõe que se pode adquirir conhecimento a partir da exploração intensa de um caso (Franco & Costa, 2007). É um método sólido de realizar uma pesquisa que permite focar o contemporâneo. Este método, segundo Trivinos (1995) e Godoy (1995), é o procedimento mais adequado para o estudo mais detalhado de uma determinada situação. Yin (1994) refere que os estudos de caso são mais adequados quando o fenómeno a investigar é contemporâneo, ou sobre o qual o investigador não tem controlo. Estes possibilitam uma visão global do fenómeno e permitem apreender as características e os significados dos eventos. Os estudos de caso são seleccionados porque permitem chamar a atenção para o que se pode aprender a partir de um caso específico (Neilson, 1997). [PJMG quality, 140]

175 DEFINIÇÃO DO PROBLEMA De acordo com Yin (1994), um dos componentes do estudo de caso é a definição, precisamente, do que é o caso. A definição dos objectivos revela que a unidade de análise, nesta investigação, é o gestor de projectos. O estudo de casos é, neste trabalho, conduzido com o objectivo de identificar as actividades do gestor de projectos na área da qualidade, que contribuem para uma maior eficácia do seu trabalho e, consequentemente, para o sucesso de projectos em TI. Pretende-se desenvolver um modelo para o gestor de projectos, com a componente da qualidade como foco principal, através da identificação das actividades determinantes do seu trabalho. Foram efectuados dois estudos de caso. A selecção dos casos baseou-se na combinação dos seguintes elementos: Empresas pertencentes ao sector da actividade de TI; Com casos de sucesso com provas dadas; Certificação de qualidade: optou-se por escolher um caso com certificação de qualidade e outro sem certificação com o objectivo de analisar e comparar os dois casos distintos; Aplicação de uma metodologia de gestão de projectos: nos dois casos é seguida uma metodologia de gestão de projectos; Localização geográfica das empresas: foram escolhidas duas empresas com sedes pertencentes a grandes centros urbanos e localizadas em zonas distintas (Lisboa e Porto, sul e norte, respectivamente); Diversidade dos projectos desenvolvidos; Certificações em curso: uma das empresas tem a certificação ISO 9001 e tem em curso o processo de certificação CMMI; Sector de actuação: uma empresa actua em vários sectores, a outra num sector de actividade específico Caracterização das empresas De seguida descrevem-se as empresas que foram objecto de estudo. [PJMG quality, 141]

176 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO InforAuto A Inforauto, S.A., hoje ADP Portugal, nasceu no ano 1989, sendo na altura uma empresa do Grupo Sousa Lima com o objectivo de prestar serviços de consultoria informática para o retalho automóvel, apresentando-se como a representante portuguesa da software house multinacional Kerrigde. Em 2004, o Grupo Salvador Caetano adquire o grupo Sousa Lima, e fica detentor das duas empresas de consultoria para o ramo automóvel, a Inforauto e a Rigor Consultoria e Gestão, S.A., que desde 1999 prestava serviços de consultoria informática principalmente para as concessões do Grupo. Dado que, na perspectiva da administração do Grupo Salvador Caetano, não seria profícuo deter duas empresas que prestavam praticamente os mesmos serviços, esta decidiu extinguir a Rigor e incorporar os seus recursos humanos na estrutura da Inforauto. A Inforauto nasceu assim, no sector automóvel com o objectivo de distribuir e implementar o DMS (Dealer Manager System) líder a nível mundial, o Autoline da Kerridge Automotive Systems. A Inforauto, Sistemas de Informação, possui instalações em Lisboa e no Porto. Os escritórios da Inforauto em Lisboa, que provêm ainda da altura em que a Inforauto pertencia ao Grupo Sousa Lima, situam-se no Tagus Park e serve de local de trabalho a várias dezenas de colaboradores. No Porto os escritórios da Inforauto localizam-se nas instalações da Salvador Caetano Comércio Automóveis, onde trabalham 25 colaboradores, correspondendo assim a um total de 46 colaboradores. A missão da Inforauto é contribuir para a melhoria da eficiência global do sector automóvel através da prestação de serviços profissionais de Consultoria e Formação, suportados por sistemas de informação integrados desenvolvidos nas mais modernas tecnologias de informação. A Inforauto implementa soluções dedicadas ao retalho automóvel que acompanham a evolução das tecnologias de informação e se adaptam às transformações do sector, prestando serviços profissionais de consultoria, suportados em soluções informáticas e dirigidos exclusivamente ao sector do retalho automóvel, proporcionando aos seus intervenientes soluções inovadoras que permitam, por um lado, gerir o negócio de forma mais eficaz e, por outro, aproximar os clientes às redes de concessionários e às marcas respectivas. [PJMG quality, 142]

177 DEFINIÇÃO DO PROBLEMA Baseando as suas competências num profundo conhecimento do sector automóvel, a Inforauto presta serviços de integração tecnológica no sector do retalho automóvel, numa base de cooperação e compromisso com os seus clientes. O principal objectivo declarado da Inforauto é proporcionar aos intervenientes do sector automóvel soluções inovadoras que permitam, por um lado, aumentar a eficiência da gestão do negócio e, por outro, aproximar os clientes às redes de concessionários e às marcas respectivas. Integrada na Fogeca.com (Grupo Salvador Caetano) desde 2002, a Inforauto viu os seus serviços aumentarem com a transferência de actividades da empresa Rigor (também da Fogeca.com). Como resultado da integração da actividade tecnológica da Rigor, a Inforauto passou a deter adicionalmente as ofertas do DMS Sigma, das soluções de Business Intelligence em plataforma Cognos, e das soluções de hardware, software e aluguer operacional de equipamentos. Em termos de mercado, a Inforauto consolidou a sua posição na rede Mercedes. Obteve uma penetração importante na rede oficial Mitsubishi Motors Portugal ao obter cerca de um terço das concessões como clientes. E marcou fortemente a entrada em marcas fora do universo Daimler-Chrysler com as implementações da Baviera Comércio de Automóveis, Grupo Gamobar e Império Autocenter. Actualmente a Inforauto dispõe de um conjunto de produtos e serviços, para o sector automóvel, que lhe permite apresentar uma oferta global à escala das necessidades das empresas que operam neste sector: DMS Autoline principal solução para a gestão de Grupos e Concessionários; IMS Autoline solução para a gestão de Importadores Automóveis; DMS Sigma solução própria, desenvolvida internamente, que poderá ser orientada para os reparadores autorizados e pequenas oficinas; Sistemas de Business Intelligence - Reporting Operacional, Reporting Financeiro, Sistema de Controlo Orçamental e Consolidação Financeira; Consultoria no sector automóvel nas áreas de Operações e Logística, Marketing e CRM, Qualidade e Ambiente; [PJMG quality, 143]

178 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO Gestão da Mudança; Formação - Área Comportamental e Liderança, Administração de sistemas e redes, Segurança Informática; Soluções de hardware, software e infra-estruturas de comunicação. A estrutura organizacional da Inforauto tem por base a localização dos seus dois escritórios em Lisboa e Porto e as suas áreas de trabalho. Actualmente os potenciais clientes da Inforauto são as entidades do sector automóvel que actuam no Retalho (concessionários) e na Distribuição (importadores e construtores de veículos e peças). Contudo a empresa pretende, a partir de 2006, apresentar soluções para as áreas de Gestão de Frotas, Rent-acar e Serviços de Inspecção Técnica (Peritagens e averiguação de sinistros). A Inforauto tem 150 clientes, com mais de utilizadores de sistemas DMS, distribuídos em Portugal Continental, Madeira, Açores, Espanha, Cabo Verde e Angola. O parque de licenças a 31 de Agosto de 2005 era de 2.114, e estima-se que alcance as licenças até final de A reputação da Inforauto junto dos seus clientes deve-se fundamentalmente à elevada qualidade dos seus serviços e aos excelentes resultados que foram sendo consecutivamente obtidos. Dos vários clientes da Inforauto, alguns destacam-se pela significativa presença no mercado automóvel português, como é o caso dos seguintes grupos automóveis: Mercedes-Benz Portugal; Mitsubishi Motors Portugal; Grupo Fernando Simão; Grupo Salvador Caetano; Baviera Comércio Automóveis; Carclasse; Império Autocenter; Grupo Gamobar; Grupo Sorel; Grupo Setucal; [PJMG quality, 144]

179 DEFINIÇÃO DO PROBLEMA Soc. Comercial C. Santos; Grupo Auto-Industrial; A Inforauto tem como clientes concessionários das mais variadas marcas de automóveis, tais como: Mercedes-Benz, BMW, Mitsubishi Motors, Lexus, Seat, Opel, Chevrolet, Toyota, Alfa Romeo, Fiat, Lancia, Volkswagen. Novabase A Novabase surge no ano de 1989 com um posicionamento de software house, especialista em desenvolvimento à medida. Dois anos depois, a empresa deu início ao COSTAIM, projecto embrião dos produtos para sistemas de informação hospitalar, que correspondeu à primeira de várias iniciativas de Investigação e Desenvolvimento bem sucedidas. A Novabase Sistemas de Informação (primeira empresa da Novabase) foi criada em Maio de Foram os seus fundadores um conjunto de investigadores na área de Engenharia de Sistemas e Computadores (INESC), iniciando a sua actividade na área de Sistemas de Informação, cujo objectivo primordial estava orientado para o desenvolvimento à medida de sistemas de média/grande dimensão. Sendo especialista no desenvolvimento de software, definiu e formalizou o seu processo produtivo, tendo sido a primeira empresa portuguesa, neste mercado, a ser certificada pelo IPQ - Instituto Português da Qualidade, em Dezembro de 1994, segundo a norma NP EN ISO Durante os primeiros anos de actividade criou referências sólidas, consubstanciadas em projectos de sucesso, nomeadamente na área da Administração Pública (Agricultura, Segurança Social, Educação, Saúde, Justiça, etc.), tendo ainda criado os seus primeiros produtos próprios (GEMEO para a medicina ocupacional, GPLO para o licenciamento de obras e NOVAMAIL para o registo de correspondência). Estabeleceu uma sólida actividade de formação nas suas áreas tecnológicas de base, e conseguiu, ainda neste período, os primeiros contratos em domínios fora da Administração Pública. Participou ainda como parceiro, e como chefe-de-consórcio, em projectos de Investigação e Desenvolvimento (I&D) internacionais. Numa segunda fase do seu desenvolvimento empresarial, expandiu-se para novos mercados, nomeadamente o financeiro, verificando-se também uma [PJMG quality, 145]

180 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO mudança de posicionamento, de forma a apresentar-se ao mercado como fornecedor de soluções informáticas globais. Abarcou novos domínios tecnológicos como o da gestão dos fluxos de trabalho ("Workflow"), o do Suporte à Decisão/DataWarehousing, o do Comércio Electrónico e criou uma estrutura organizacional mais horizontal que lhe permitiu lançar novos líderes e potenciar o seu crescimento sustentado. No ano de 1994, a Novabase obteve a certificação de qualidade (norma ISO 9001), concedida pelo IPQ: Modelo de garantia da qualidade na concepção, desenvolvimento, produção, instalação e assistência pós venda. Em 1995, reposicionou os seus negócios como Integrador de Sistemas e criou as primeiras unidades especializadas por sectores de actividade, tendo sido, também, efectuados os primeiros projectos em Macau. No ano de 1996, o IAPMEI atribuiu o prémio "PME Excelência", pelas boas práticas de gestão e resultados financeiros, tendo nesse ano, o volume de negócios ultrapassado 5 milhões de euros. Em 1997, dá-se a criação das primeiras spin-offs (Novabase Suporte à Decisão e Novabase Porto), verificando-se nos dois anos seguintes a constituição de duas novas empresas especializadas (a Nbo, Recursos em TI e a Cfocus). Posteriormente foram criadas duas novas empresas - Mentor.IT e Novabase Serviços e efectuados os primeiros projectos no Brasil e Cabo Verde. O volume de negócios no final de 1999 foi superior a 24,94 milhões de euros. Presente no lançamento mundial da Televisão Digital Interactiva com a set-top box produzida pela Octal, a Novabase fechou o ano de 2000 com um Volume de Negócios superior a 52,85 milhões de euros. Em Julho de 2000, a Novabase foi admitida à cotação na Bolsa de Valores de Lisboa e Porto, tendo a operação de colocação de títulos (IPO) corrido com sucesso, com a procura superado largamente a oferta. No início de Outubro desse ano o título passou a integrar o índice BVL 30 e, em Janeiro de 2001, entrou para o PSI 20. Em Maio de 2002 a Novabase passou a integrar o Next 150. O ano de 2001 ficou ainda marcado com o lançamento da Novabase no Brasil nas áreas de Business Inteligence, Customer Relationship Management e Enterprise Resources Planning. Com o objectivo de consolidar a sua actividade no mercado do país vizinho, em 2002, a Novabase Consulting alarga o seu negócio a Espanha, abrindo sedes em Madrid e Barcelona. O negócio será centrado nas áreas de CRM, [PJMG quality, 146]

181 DEFINIÇÃO DO PROBLEMA Data Quality y Business Intelligence mas prestará também serviços de consultoria multidisciplinar em áreas, como o Outsourcing, ebusiness e Middleware. Depois de em 1993 ter sido a primeira empresa no sector dos Sistemas de Informação a obter a certificação dos seus processos, a Novabase Consulting recebeu, em Outubro de 2003, o Certificado do Sistema de Gestão da Qualidade, de acordo com a mais recente norma de referência NP EN ISO 9001:2000 para o âmbito Concepção e Comercialização de Integração de Soluções, Consultoria e Outsourcing de Tecnologias de Informação. O Volume de Negócios atingiu, em 2007, os M, o que representa um crescimento de 19.8% face aos M registados em Para obter esta Certificação de Nível 3, a Novabase foi sujeita a uma auditoria composta pela identificação de evidências para os projectos a auditar (cerca de 1800 documentos e factos relacionados com o processo produtivo) e também por entrevistas com as equipas de projecto e responsáveis dos processos mais relevantes. A implementação do CMMI na Novabase tem como foco principal a melhoria do processo produtivo, quer ao nível da produtividade quer ao nível da qualidade dos produtos. Para conseguir esses objectivos a iniciativa assentou no desenvolvimento em três pilares: a adopção de alguns princípios orientadores que complementaram o método de trabalho já praticado pela Novabase (ex: definição de métricas de avaliação de projectos); a revisão da metodologia de trabalho e da adopção de boas práticas de trabalho na implementação das suas soluções; e o registo centralizado de informação sobre os projectos, aumentando a capacidade de controlo e gestão da sua execução. Esta certificação posiciona a empresa na elite mundial onde o grau de excelência só é ultrapassado pelo grau de exigência. Tal vai exigir que a Novabase entregue, cada vez mais, e melhor valor ao cliente. Para esta certificação contribuíram a expertise tecnológica, o conhecimento funcional e as competências que caracterizam a Novabase Recolha de informação A recolha de dados deve contemplar várias fontes, contribuindo assim para a triangulação dos dados, bem como para criar elos de evidências que relacionem os dados recolhidos às questões de investigação colocadas (R.K. Yin, 1994). [PJMG quality, 147]

182 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO Os métodos e técnicas utilizadas na recolha de dados dos casos de estudo, foram a análise documental e as entrevistas pessoais semi-estruturadas. Tratam-se de fontes de informação típicas de um estudo de caso. A sua finalidade prende-se com a possibilidade de confrontar a informação recolhida através da análise documental e das entrevistas, por forma a aumentar a confiança nessas fontes. Os documentos definem a compreensão de problemas particulares, prescrevem comportamentos apropriados e diferentes formas de realizar as actividades na organização (Forster, 1994). Contudo, é preciso ter-se em conta que a informação recolhida pode não ser representativa da vida numa organização, pelo que necessita de ser verificada, interpretada e triangulada com outras fontes (Sarmento, 2002). A entrevista preenche geralmente três funções (Fortin, 1999): Servir de método exploratório para examinar conceitos, relações entre as variáveis e conceber hipóteses; Servir de principal instrumento de medida de uma investigação; Servir de complemento a outros métodos, tanto para explorar resultados não esperados, como para validar os resultados obtidos com outros métodos, ou ainda para aprofundá-los. Moser e Kalton (Moser & Kalton, 1971) descrevem a entrevista como uma conversa entre um entrevistador e um entrevistado com o objectivo de extrair informação do entrevistado. Wiseman e Aron (Wiseman & Aron, 1972) comparam a condução de uma entrevista a uma expedição piscatória e, explicando esta analogia, Cohen e Manion (Cohen & Manion, 1989) acrescentam que, tal como a pesca, a entrevista é uma actividade que requer uma preparação cuidadosa, muita paciência e experiência considerável se a eventual recompensa for uma captura valiosa. As entrevistas permitem colher informações junto dos participantes, relativas aos factos e às ideias, aos comportamentos, às preferências, aos sentimentos, às expectativas e às atitudes. A entrevista apoia-se no testemunho do sujeito, não tendo o investigador acesso senão ao material que o participante consente em fornecer-lhe (Fortin, 1999). Moser e Kalton (Moser & Kalton, 1971) situam os diferentes tipos de entrevista no que chamam um continuum de formalidade. Num extremo encontra-se a entrevista completamente formalizada, em que o entrevistador se comporta, [PJMG quality, 148]

183 DEFINIÇÃO DO PROBLEMA tanto quanto possível, como uma máquina. No outro extremo está a entrevista completamente informal, cuja forma é determinada por cada entrevistado. Numa entrevista não estruturada, o objecto é para extrair o máximo de informação possível sobre um tema amplamente definido. Por outro lado, quanto mais formalizada e estruturada for a entrevista, mais fácil será agregar e quantificar os resultados. Outro tipo de entrevista é a semi-estruturada. Esta entrevista inclui perguntas específicas e perguntas abertas destinadas a não suscitar apenas as informações previstas, mas também recolher outros tipos de informação. Na entrevista semi-estruturada o objectivo é que no fim da entrevista todos os temas propostos tenham sido cobertos (Wilson, 1985). As entrevistas assumem uma função preparatória ou instrumental, contribuindo para a identificação, validação e aprofundamento dos aspectos críticos. Nos dois casos de estudo utilizou-se a análise documental e a entrevista semiestruturada. A estrutura da entrevista foi desenvolvida com base na literatura consultada previamente. A análise de documentos, formais e informais, cedidos pelas empresas estudadas, foi também outro instrumento de recolha de dados. O conhecimento que se pretende adquirir para a construção do modelo exige um perfil específico dos entrevistados. É determinante seleccionar especialistas da área que possuam a experiência e conhecimento necessários para a caracterização abrangente do fenómeno. Esta experiência deve abranger um conjunto de actividades e de boas práticas na área da GP, que vão desde consultadoria em GP de SI, passando por experiência em desenvolvimento de software, até a trabalho efectuado em diversas áreas de negócio, diversas áreas geográficas com mercados de diferentes maturidades e dimensões. Por fim, seria ainda desejável que os visados tivessem formação complementar na área da gestão de projectos. Para obter esse conhecimento são necessárias técnicas de recolha de dados que possibilitem abordar de modo lato os diferentes aspectos relevantes a considerar. As entrevistas assumem a função preparatória ou instrumental em que contribuem na identificação, validação e aprofundamento dos aspectos críticos. [PJMG quality, 149]

184 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO Elaboração de entrevistas Como já referido na secção anterior, as entrevistas permitem colher informações junto dos participantes, relativas aos factos e às ideias, aos comportamentos, às preferências, aos sentimentos, às expectativas e às atitudes. A entrevista apoia-se no testemunho do sujeito, não tendo o investigador acesso senão ao material que o participante consente em fornecer-lhe (Fortin, 1999; Rijo, 2008). Optou-se pela elaboração de entrevistas semi-estruturadas para dar liberdade ao entrevistado de expor o que é importante para ele, em vez de falar do que é importante para o entrevistador. No entanto definiu-se uma estrutura base que garantisse que todos os tópicos considerados cruciais fossem abordados. Houve a preocupação de manter a estrutura base bastante versátil, de modo a não influenciar a subjectividade do entrevistado. O processo de condução de entrevistas subdividiu-se em: Recolha de uma parte dos dados durante uma primeira visita ao local; Selecção dos participantes; Preparar uma série de questões gerais a utilizar a partir do estudo dos documentos fornecidos; Preparação dos meios para registar as respostas às questões das entrevistas; Elaboração de um plano que consistiu num conjunto de questões pré-definidas. A elaboração e realização de entrevistas requerem um longo período de tempo, exigem uma formação antecipada e aprofundada do tema e os dados são difíceis de organizar. No entanto os resultados obtidos por este meio revelamse bastante realistas e possibilita diversidade relativamente às questões e às respostas. Existem vários autores, nomeadamente (R.K. Yin, 1994), que se têm pronunciado sobre a fragilidade da utilização das entrevistas devido a vários factores, como por exemplo: má formulação das questões que levam o entrevistado a corroborar as ideias do investigador e a enviesar o estudo; ou o entrevistador não sabe ouvir e observar o entrevistado durante a entrevista; ou a falta de adaptabilidade e flexibilidade do entrevistador. [PJMG quality, 150]

185 DEFINIÇÃO DO PROBLEMA Apesar das eventuais fragilidades apontadas por alguns autores, acredita-se, tal como Patton (1987) e Yin (1994), que as entrevistas são uma das mais importantes fontes de informação no estudo de caso. King (1994) refere mesmo que a entrevista é um método altamente flexível, que pode ser usado em qualquer parte, e é capaz de produzir dados que nos permitam uma análise com grande profundidade. As entrevistas permitem ao investigador entrar no mundo do entrevistado e compreender a sua perspectiva (Patton, 1987:109) Realização de entrevistas As entrevistas efectuadas duraram, em média, cerca de uma hora e trinta minutos, variando entre uma hora a duas horas. Apesar de algumas entrevistas serem mais curtas e outras mais demoradas, todas seguiram o mesmo protocolo. Na primeira fase, foram colocadas questões de índole geral como qual o seu percurso profissional ou quais as suas responsabilidades?, de modo a não influenciar o entrevistado no seu esclarecimento. Na segunda fase, foram colocadas questões definidas para obter informação em aspectos específicos que poderiam estar ausentes das reflexões prévias. Algumas entrevistas foram registadas em fita magnética (com a concordância explícita dos entrevistados) e transcritas sob a forma de registos não organizados. As que não foram registadas, houve o cuidado de transcrever tudo o que era comunicado pelo entrevistado. [PJMG quality, 151]

186 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO Novabase Nome do entrevistado Formação Funções Desempenhadas (Experiência) Hierarquia Funções actuais Luís Coelho Licenciatura em Engenharia Informática pelo Instituto Superior Técnico Certificação: GP - Nível C Sénior pela APO- GEP (IPMA) e PM Nível 4 Analista programador Analista Funcional; Consultor; Chefia de projectos; Coordenação de equipas; Gestor de projectos. Manager Funções de gestão de projectos Coordenador da equipa de projecto. Nuno Cepeda Licenciatura em Engenharia Informática pelo Instituto Superior Técnico Consultor; Gestão de Projectos; Controlo Qualidade. Senior Manager Responsável por uma unidade de negócios focada nos processos de negócio de núcleo de Correios e logística dos mercados, o Governo (Justiça, Segurança Social e Educação), Media e Telecomunicações, com 75 consultores; As principais funções que desempenha são: - Planeamento estratégico; - Gestão de equipas (carreira e motivação); - Gestão operacional e financeira; - Gestão de projectos. Pedro Faúlha Licenciatura em Engenharia Informática pelo Instituto Superior Técnico Certificação: GP - Nível C Sénior pela APO- GEP (IPMA) e PM Nível 4 Analista programador Analista Funcional; Consultor; Chefia de projectos; Coordenação de equipas; Gestor de projectos. Manager Funções de gestão de projectos Coordenador da equipa de projecto. Tabela 6.3: Quadro com os especialistas entrevistados no estudo de caso Novabase [PJMG quality, 152]

187 DEFINIÇÃO DO PROBLEMA Nome do entrevistado Formação Jorge Filipe Licenciatura em Contabilidade e Administração; CAP para Formação Inicial Curso de Gestão de Projectos PMO. ADP Portugal Funções Desempenhadas (Experiência) Consultoria na área Financeira; Contabilidade; Gestor de projectos. Hierarquia Funções actuais - Gestor de Gestão de projectos Equipas; - Project Gestão de Manager projectos Joaquim de Matos Licenciatura em Informática de Gestão pela Universidade do Minho; Gestão de Projecto; Controlo da Qualidade. Manager Responsável pela área de Consultoria Técnica CAP em Formação. Manuel João Santos Licenciatura em Informática de Gestão pela Universidade do Minho; Formação Sénior Consultant; Manager na - Consultor Sénior - Senior Manager Gestão de projectos Consultor Sénior CAP para Formação Deloit Inicial Curso de Gestão de Projectos PMO. Susana Oliveira Licenciatura em Informática de Gestão pela Universidade do Minho. Desenvolvimento na Deloit Consultor na área de BI (Business Inteli- Consultor sénior - Senior Manager Responsável pela área de BI (Business Inteligence) gence); Gestão de projectos. Tabela 6.4: Quadro com os especialistas entrevistados no estudo de caso ADP Portugal Cada documento resultante foi validado pelo respectivo entrevistado. Salvaguardou-se sempre a confidencialidade dos elementos recolhidos. A primeira entrevista permitiu identificar novos aspectos ainda não considerados no decorrer do processo de revisão bibliográfica e optimizar a postura e atitude nas entrevistas seguintes. Este processo de melhoramento contínuo foi realizado ao longo de todas as entrevistas. A transcrição completa das entrevistas pode ser consultada nos Anexos III e IV. 153

188 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO Como os entrevistadores são seres humanos, e não máquinas, há sempre o perigo do factor parcialidade se imiscuir nas entrevistas e da sua forma de ser poder influenciar os entrevistados (Selltiz, Jahoda, Deutsch, & Cook, 1962). É difícil evitar completamente este factor mas, estar ciente dos problemas e o controlo constante sobre nós próprios, podem ajudar (Gravon, 1966). Realizou-se, por isso, uma preparação cuidada e pormenorizada, quer ao nível da estruturação das entrevistas, quer ao nível da postura e atitude a ter na entrevista. A experiência adquirida ao longo das entrevistas também permitiu reduzir os potenciais factores de enviesamento dos resultados obtidos. Deste modo procurou-se que as entrevistas decorressem num local calmo e onde o entrevistador não fosse interrompido. A apresentação do entrevistador procurou ir de encontro à do entrevistado de modo a proporcionar um ambiente de confiança e evitar qualquer perturbação no entrevistado. O horário de encontro foi cumprido com pontualidade. Houve um esforço no sentido de evitar os enviesamentos verbais e não verbais durante a entrevista: o enunciado das questões, o tom de voz, a expressão facial, a posição corporal, entre outros aspectos. De entrevista para entrevista, com base na informação das anteriores, foi possível optimizar os temas a abordar e a postura, nomeadamente nos seguintes aspectos: Introdução de determinados temas não abrangidos pela estruturação inicial; Acréscimo de informação para aprofundamento face às questões inicialmente colocadas; Redução do número de interrupções que foram feitas ao entrevistado, de modo a não quebrar o raciocínio, e permitir que este concluísse a sua ideia; Sempre que se mostrou adequado, alterou-se a ordem dos temas e evitou-se quebrar o raciocínio do entrevistado e a fluidez da entrevista Tratamento e organização dos dados Em investigação qualitativa, a análise dos dados é uma fase do processo indutivo de investigação que está intimamente ligado ao processo de escolha dos participantes e às diligências efectuadas para a recolha de dados. Esta fase não [PJMG quality, 154]

189 DEFINIÇÃO DO PROBLEMA é separada das outras fases de investigação, visto que se efectua, geralmente, ao mesmo tempo que a amostragem e a recolha de dados (Rijo, 2008). A análise dos dados permite, portanto, guiar o investigador na sua amostragem que é de natureza intencional (Deslauriers, 1991) e dá-lhe pistas sobre o que lhe resta descobrir sobre o fenómeno em estudo, durante o processo de recolha dos dados. A análise dos dados em investigação qualitativa define-se, portanto, como uma fase integrada no processo de investigação, presente de cada vez que o investigador se remete a um período de recolha de dados e em que ele se deve situar em relação ao que já emergiu dos dados e ao que resta para descobrir (Deslauriers, 1991). Existem diferentes abordagens para recolher, analisar e interpretar dados qualitativos. A linha comum é que todos os modos qualitativos de análise se relacionem, numa primeira fase, com análise textual, seja verbal ou escrita (Michael D. Myers, 1997). Yin (R.K. Yin, 1994) recomenda alguns requisitos para a condução de uma pesquisa com qualidade na fase de análise dos dados, que são apresentados de seguida: Mostrar que a análise está baseada em todas as evidências relevantes; Incluir todas as maiores interpretações rivais da análise; Endereçar o aspecto mais significativo do estudo; Utilizar os conhecimentos anteriores do pesquisador (conhecimento especialista). Logo que uma recolha de dados é efectuada há, em todas as abordagens qualitativas, uma fase preliminar à análise propriamente dita. Esta fase é a da organização dos dados. O conteúdo recolhido a partir das entrevistas foi organizado para que pudesse ser analisado. No caso das entrevistas transcreveu-se integralmente o seu conteúdo. Foram desenvolvidos ao longo da análise, memorandos (memos) e diagramas. Os memos e os diagramas são ajudas que acompanham a análise para registar os produtos preliminares das análises. Os memos são notas que se assemelham a comentários sobre unidades de sentido identificadas e a sua definição. Estas definições podem ser teóricas ou operacionais. Os memos são os pedaços do puzzle que, uma vez retomados no fim do trajecto, e colocados em con- [PJMG quality, 155]

190 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO junto, trazem uma clarificação importante para a construção da teoria. Os diagramas são representações gráficas que ajudam a compreender a relação entre os conceitos emergentes, podendo ser feitos no decorrer de toda a análise (Fortin, 1999). Segundo Tesch (Tesch, 1990), a análise de dados de um estudo de caso pode ser de três tipos: Interpretativa que visa analisar ao pormenor todos os dados recolhidos com a finalidade de organizá-los e classificá-los em categorias, que possam explorar e explicar o fenómeno em estudo; Estrutural, que analisa dados com a finalidade de se encontrarem padrões que possam clarificar e/ou explicar a situação em estudo; Reflexiva que visa, na sua essência, interpretar ou avaliar o fenómeno a ser estudado, quase sempre por julgamento ou intuição do investigador. A organização e interpretação dos dados obedeceram aos seguintes passos propostos por Franco (Franco& Costa, 2007): Pré-análise, que consistiu na organização e teve por objectivo operacionalizar e sintetizar as ideias iniciais; Exploração de material, que consistiu em operações de codificação e enumeração, segundo um conjunto de regras previamente formuladas; Tratamento dos dados obtidos, análise de conteúdo e sua interpretação. Mais precisamente, a interpretação e a análise dos dados recolhidos foram tratadas com base no que os inquiridos disseram (interpretação de primeira ordem) e subsequente validação (interpretação de segunda ordem). A técnica utilizada no tratamento e análise dos dados recolhidos através das entrevistas foi a análise de conteúdo com base na abordagem proposta por King (1998) denominada Template Analysis. Conforme King esta abordagem ocupa uma posição intermédia entre a análise de conteúdo (Weber, 1985), onde os temas são todos predeterminados, e cuja distribuição é normalmente analisada estatisticamente, e a grounded theory (Glaser & Strauss, 1967), onde não existem temas definidos a priori. No seu conjunto, esta técnica revela-se mais flexível e com menos procedimentos [PJMG quality, 156]

191 DEFINIÇÃO DO PROBLEMA prescritivos do que a grounded theory, permitindo ao investigador ajustar os temas com a realidade em estudo. Esta metodologia de análise é dotada de grande flexibilidade porque permite a adaptação do template ao longo da análise dos dados. Esta abordagem é também designada por Thematic Coding e pressupõe a produção de uma lista de temas pelo investigador (template) que representam os temas identificados nos dados textuais. Alguns destes temas são definidos, a priori, mas podem ser modificados e acrescentados à medida que o investigador lê e interpreta os dados empíricos Estudo Delphi Com vista a reforçar e a corroborar as actividades obtidas na primeira fase e a identificar desse conjunto as actividades determinantes da função do gestor de projectos no âmbito da garantia de qualidade foi realizado um estudo Delphi O método Delphi começou a ser pensado no final dos anos 40 quando a Rand Corporation começou a investigar as opiniões de peritos científicos. O método foi pela primeira vez utilizado por esta organização, já nos anos 50, no âmbito de um projecto militar (N. Dalkey & Helmer, 1963; Landeta, 2006). Só na década seguinte é que o Delphi foi utilizado noutras áreas (N. Dalkey & Helmer, 1963; Landeta, 2006). Inicialmente o Delphi era um estudo em que o objectivo era obter um consenso de opiniões de um grupo de especialistas, através de questionários. Apenas mais tarde essa definição foi um pouco mais generalizada sendo considerado uma investigação social técnica, cujo objectivo é a obtenção de uma opinião usando um grupo de peritos (Landeta, 2006). Trata-se de um método de comunicação entre um grupo de pessoas que podem fornecer valiosas contribuições a fim de resolver um problema complexo (Landeta, 2006; Linstone & Turoff, 1975). O método Delphi tem sido utilizado em vários formatos, havendo um número reduzido de investigadores que o utilizam tal como foi estruturado inicialmente (Keeney& Hasson Felicity and McKenna Hugh, 2001; Santos, 2004). Segundo Santos, (Santos, 2004) existem muitas críticas ao método Delphi que se focam na ideia de que o método não tem evidência de confiança porque, caso se execute o estudo com dois ou mais grupos de especialistas, não há garantias de se obterem os mesmos resultados. Contudo, vários estudos já foram realizados com a finalidade de avaliar a confiança e validade do méto- [PJMG quality, 157]

192 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO do, estudos esses que vieram assegurar que o método é credível e válido (Keeney & Hasson Felicity and McKenna Hugh, 2001; Landeta, 2006). Landeta realizou um estudo em que pretendeu demonstrar a validade do método Delphi para as ciências sociais. Para a realização do estudo foram analisadas publicações científicas como artigos, teses e conferências em que o estudo Delphi foi aplicado. Nesse estudo concluiu-se que o estudo Delphi teve o seu pico de utilização em publicações científicas nos anos 80 mas que, contudo, continua a ser um método bastante utilizado, sendo um estudo válido de previsão e apoio à tomada de decisão (Landeta, 2006). No âmbito dos SI, nos últimos anos a utilização do método Delphi tem continuado a aumentar (Santos, 2004). Esse aumento parece-nos justificado pelo aumento da importância que os SI têm tido para as organizações. Tal como já foi referido, na aplicação do estudo Delphi são realizados questionários a um conjunto de peritos na área em estudo. Perito neste contexto, é um especialista no seu campo ou alguém que tem um conhecimento acerca de um tema específico (Green, 1999; Santos, 2004), podendo esse conhecimento ser tácito 7 ou explícito 8. No método Delphi, ao conjunto de peritos que respondem ao questionário dá-se o nome de Painel de peritos. A escolha dos especialistas é de extrema importância já que são as suas respostas que levam à conclusão do estudo. Os peritos devem ser imparciais no que diz respeito ao estudo em questão, e o conjunto de peritos escolhido deve ser heterogéneo em relação aos grupos profissionais e sociais a que pertencem. Em relação ao tamanho do painel de peritos existem muitas opiniões que referem vários tamanhos ideais. Segundo os estudos realizados por Santos e Somerville, não deve ser definido um tamanho base para o painel de peritos, já que esse tamanho dependerá do estudo a realizar (Santos, 2004; Somerville, 2007). Segundo Adams, para painéis superiores a 30 a validade e confiança do Delphi não sofre um aumento significativo (Adams, 2001; Santos, 2004), sendo que a partir dos 13 indivíduos a confiança é já de 0,8 (N. C. Dalkey, 1969; Santos, 2004). Estes valores justificam-se pois o estudo é realizado com peritos que devem ter uma opinião clara, precisa e verdadeira acerca das temáticas. Embora possam existir investigações com traços semelhantes, cada investigação é única e deve ser olhada como tal. É necessário ter em conta muitos 7 Conhecimento tácito é um conhecimento informal que reside na mente de cada indivíduo, gerado através das experiências de cada um (Nonaka et al. 1997). 8 O conhecimento explícito é um conhecimento formal que está exteriorizado em determinada plataforma, física ou virtual (Nonaka et al. 1997). [PJMG quality, 158]

193 DEFINIÇÃO DO PROBLEMA aspectos na definição do painel de peritos, nomeadamente o tema da investigação, as características culturais e politicas dos locais onde a pesquisa vai ser realizada, o ambiente em que os peritos estão envolvidos. O método Delphi é constituído por um questionário realizado em várias rondas. Nas utilizações tradicionais do Delphi na primeira ronda eram colocadas questões abertas aos peritos. Contudo, este método levava, normalmente, a um conjunto bastante elevado de itens. O que se faz normalmente, a fim de evitar o problema, é fornecer uma lista de questões que os peritos devem ordenar segundo a ordem de importância (M. Keil, Tiwana, & Bush, 2002), deixando no entanto que possam ser sugeridos novos aspectos. Este método é mais eficiente que o anterior, tendo contudo a desvantagem de limitar as opções disponíveis. Nas rondas seguintes os resultados são disponibilizados aos especialistas. No final de cada ronda os dados são tratados e é enviado um novo questionário, tendo em conta os resultados da ronda anterior. No método tradicional do Delphi eram utilizadas quatro rondas. Nos estudos actuais realizam-se comummente rondas até haver um determinado nível de consenso por parte dos peritos (Beretta, 1996; Green, 1999; Santos, 2004). Segundo Santos, realizam-se em média três rondas do questionário (Keeney & Hasson Felicity and McKenna Hugh, 2001; Santos, 2004). A razão para este facto é apontada por Keeney que afirma que, na última ronda há uma taxa baixa de respostas aos questionários por parte dos peritos, o que os leva a terminar o estudo no final da terceira ronda (Keeney & Hasson Felicity and McKenna Hugh, 2001). A falta de tempo para a realização do estudo e o tempo que os peritos demoram a responder são outros factores que levam à paragem do estudo nessa altura (Santos, 2004). O tempo de duração do estudo Delphi varia normalmente entre 45 dias e 5 meses, podendo sempre variar devido aos meios utilizados e ao número de rondas realizadas (Delbecq, Van de Ven, & Gustafson, 1975; Okoli & Pawlowski, 2004). Existem várias técnicas para medir o nível de consenso das respostas dos especialistas, estando na sua maioria relacionadas com estatística. As técnicas mais usuais são a média e mediana, desvio padrão, percentagem dos factores de topo, amplitude interquartil, coeficiente de concordância Kendall s W, coeficiente Alfa de Cronbach (Santos, 2004). No nosso estudo utilizaremos alguns destes métodos ou técnicas, e outros que nos parecem pertinentes. Existem algumas ideias chave sobre os estudos Delphi que os caracterizam como vantajosos. Contudo, os estudos não são perfeitos e têm também sido [PJMG quality, 159]

194 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO alvo de algumas críticas (Landeta, 2006; Okoli & Pawlowski, 2004; Santos, 2004; Somerville, 2007). As respostas dos especialistas são anónimas, ou seja, não há acesso a quem deu que resposta. Isso pode ser visto tanto como uma vantagem como uma desvantagem. Por um lado o facto de as respostas serem anónimas pode fazer com que os peritos sejam mais verdadeiros e sinceros nas suas respostas, pois podem sentir-se menos pressionados (Santos, 2004). Por outro lado, o anonimato pode tornar-se numa desvantagem pois pode levar a acções de irresponsabilidade por parte dos peritos. Outra desvantagem é apontada no facto das respostas ao estudo serem individuais já que, por vezes, o factor social é apontado como motivante (Landeta, 2006). A vantagem desta questão é que os especialistas podem estar geograficamente dispersos o que facilita bastante a realização do estudo, podendo mesmo aumentar a sua qualidade visto que não se está dependente da localização geográfica para se recrutarem especialistas (Okoli& Pawlowski, 2004). O facto de os questionários poderem estar abertos a novas questões sugeridas pelos especialistas é também uma vantagem, havendo assim um feedback controlado. Isso funciona ainda como factor motivacional pois leva, por vezes, a que os peritos sintam que a sua participação no estudo é realmente relevante (Somerville, 2007). Outra vantagem do método Delphi é que, depois da obtenção das respostas, podem obter-se resultados tanto qualitativos como quantitativos. Landeta aponta ainda alguns problemas que podem surgir, mas geralmente são problemas que estão relacionados com uma aplicação deficiente do método. Desses problemas salientamos alguns, como o pouco rigor na escolha dos peritos, questões mal formuladas, dados insuficientemente analisados ou ao facto de se ignorarem novas questões sugeridas pelos especialistas (Landeta, 2006). Para os fins que nos propusemos foi utilizado um estudo Delphi, no qual o processo geral seguido foi: apresentação de uma lista de actividades a um conjunto de especialistas da área, e cada um deles identifica a importância relativa de cada uma dessas actividades. Este processo de atribuição de importância foi realizado através do método estatístico denominado Q-Sort. Em vários estudos, com objectivos semelhantes ao nosso, o mesmo método foi utilizado, conferindo ainda mais confiança nos resultados obtidos (Dorit & Yolande, 2007; Jaideep, Ram, & Pradeep, 2005; Jef, Jan van, Rob, Jos, & Aarnout, 2007; [PJMG quality, 160]

195 DEFINIÇÃO DO PROBLEMA Santos, 2004; Schmidt, Lyytinen, Keil, & Cule, 2001; Somerville, 2007; Xiang- Hua, Li-Hua, & Michael, 2006) Estudo Survey Os inquéritos (surveys) permitem recolher dados através de questionários e/ou entrevistas sobre o fenómeno em estudo, permitindo a subsequente análise dos dados recolhidos, inferir regras, ou elaborar generalizações sobre o fenómeno do mundo real (Macedo, Zacarias, & Tribolet, 2005). Este método, com recurso a questionários para a recolha de dados, foi utilizado para efectuar a caracterização da realidade da gestão de projectos em Portugal nas grandes empresas, nomeadamente a Gestão da Qualidade foi uma das áreas abordadas. Em Portugal são raros os estudos com uma divulgação abrangente em torno desta área. Com vista a contribuir para colmatar uma lacuna sentida relativamente à necessidade de um conhecimento mais abrangente da realidade da gestão de projectos em Portugal, foi desenvolvido um estudo com a participação de grandes empresas portuguesas. Particularmente, procurou-se caracterizar o perfil dos gestores de projectos nacionais, identificar que tipo de projectos têm sido realizados, que características apresentam esses projectos, quais as actividades que nas várias áreas da gestão de projectos têm merecido mais atenção por parte das empresas, quais os factores de sucesso mais valorizados, quais os constrangimentos que mais frequentemente surgem, que técnicas são utilizadas, e muitos outros aspectos. Como foi referido, no sentido de caracterizar a gestão de projectos de desenvolvimento de software em Portugal, realizou-se um estudo que envolveu um questionário online cujo convite para resposta foi enviado via e via CTT a uma amostra casual estratificada de 200 gestores de projectos entre as 1000 maiores empresas portuguesas em termos de facturação (segundo o Instituto Nacional de Estatística). Este público-alvo afigurou-se apropriado, pois são as grandes empresas que normalmente, por terem projectos de maior complexidade e dimensão, necessitam ter um maior controlo e gestão dos mesmos. Particularmente, procurou-se caracterizar o perfil dos gestores respondentes ao questionário, caracterizar o tipo e as características dos projectos realizados, as técnicas mais frequentemente realizadas na GP, quais as áreas de conhecimento que tem maior atenção por parte dos gestores de projectos, quais as condicionantes mais comuns ao sucesso dos projectos, entre muitos outros aspectos. [PJMG quality, 161]

196 CAPÍTULO SEIS - PROCESSO DE INVESTIGAÇÃO O questionário apresentado em anexo (Anexo VI), foi disponibilizado no período de a e compreendeu três rondas. Obtiveram-se 20 respostas válidas, ou seja, um pouco mais de 10.1% de taxa de resposta dado ter havido três convites que não foram entregues por dificuldades de correspondência. O questionário foi estruturado por grupos temáticos de questões e contou com vários tipos de perguntas (escolha múltipla, texto livre, hierarquização) e foi testado várias vezes, sofrendo um processo iterativo de validação de conteúdo e clareza até se obter a versão final que foi registada numa plataforma online sendo esta a única opção disponibilizada de resposta. As respostas foram recolhidas e analisadas nos quatro meses seguintes. Foi feita uma análise estatística descritiva que levou à criação de gráficos, tabelas e rankings que permitem uma leitura mais simples e rápida dos resultados Finalização do projecto de investigação Após a realização das actividades previstas no processo de investigação, procedeu-se à integração e harmonização dos elementos obtidos e conceptualizados no decorrer de todo o projecto de investigação e, consequentemente, à redacção final da tese. Os resultados obtidos estão assim fundamentados em elementos empíricos que foram sistematicamente recolhidos e analisados sob a abordagem desenvolvida. Em síntese, todos os trabalhos efectuados contribuíram na construção do modelo de actividades do gestor de projectos no âmbito da garantia de qualidade, resultado central desta tese. O estudo de casos, através do processo de entrevistas, permitiu obter resultados extremamente úteis para a validação dos elementos previamente reúnidos existentes e na identificação de novos elementos. O Survey permitiu efectuar a caracterização da gestão de projectos nas grandes empresas portuguesas e permitiu constatar que o conjunto de elementos já disponíveis mostrava-se muito completo. Possibilitou também a validação e corroboração do modelo de actividades. A realização do estudo Delphi permitiu, não só consolidar a lista de actividades do gestor de projectos como também identificar, desse conjunto, as actividades que se afiguram como as mais determinantes no âmbito da qualidade. Finda a apresentação do processo seguido, os próximos capítulos serão dedicados à apresentação e discussão dos resultados obtidos. [PJMG quality, 162]

197 Capítulo 7 Caracterização da realidade da gestão de projectos nas grandes empresas portuguesas All sciences are vain and full of errors that are not born of experience, Mother of all certainty, and that are not tested by experience Leonardo da Vinci Neste capítulo é apresentado o estudo realizado com a finalidade de caracterizar a realidade portuguesa em termos da Gestão de Projectos nas grandes empresas portuguesas, focando o trabalho do gestor de projectos e as actividades de suporte à sua função. São apresentados os resultados do survey. In this chapter is presented the survey that was carried out in order to characterize the Portuguese reality in terms of Project management in the big Portuguese companies, focusing on the work of the project manager and the activities to support his function. The results of the survey are also presented. A gestão de projectos tem vindo a mudar, assistindo-se a nível internacional a um considerável amadurecimento nesta área, com resultados de desenvolvimento bastante significativos ao longo da última década. Apesar da GP ser uma área que, muito particularmente a partir do lançamento do Chaos Report (Standish Group, 1994), despertou o interesse de vários investigadores em todo o mundo, que divulgaram nos anos seguintes vários estudos e conclusões (alguns inclusivamente a relativizar os resultados do estudo do Standish Group), em Portugal são raros os estudos com uma divulgação abrangente em torno desta área. (Varajão, Cardoso, Gonçalves, & Cruz, 2008) 7.1 INTRODUÇÃO O significativo desenvolvimento das tecnologias da informação e comunicação (TIC) veio conferir às empresas um conjunto extraordinário de instrumentos para a melhoria da produtividade e da sua capacidade competitiva. Cedo as empresas souberam reconhecer as potencialidades dos investimentos em TIC, primeiro com a sua aplicação a nível operacional, e depois, progressivamente, [PJMG quality, 163]

198 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS abrangendo a gestão a todos os níveis. Como tal, diferentes tipos de sistemas de software e diferentes tipos de projectos foram surgindo para dar resposta às necessidades em constante evolução das empresas. A acompanhar a maior difusão e abrangência das aplicações das TIC nas empresas, a complexidade envolvida nos projectos de desenvolvimento de software também aumentou consideravelmente, não apenas no que respeita ao conjunto de requisitos envolvidos, como também no que concerne às restrições que se colocam, por exemplo, em termos de tempo e orçamentos disponíveis para a concretização dos projectos. Os projectos distinguem-se das operações no sentido em que são um esforço ou empreendimento temporário, são únicos, têm um objectivo específico, têm um princípio e uma duração bem definidos, e requerem um conjunto diverso de recursos e competências necessárias à realização de um produto, de um serviço ou de um resultado único. Os projectos de desenvolvimento de software têm grande relevância no seio das empresas, dado que hoje as TIC são elementos decisivos para o seu crescimento e sustentabilidade. Neste contexto, a gestão de projectos é uma área cada vez mais valorizada pelas empresas, uma vez que sem uma gestão eficaz, dificilmente é possível obter sucesso na execução dos projectos. A gestão de projectos pode ser entendida como um conjunto de processos aplicados a um projecto, para produzir um produto ou serviço, através de uma abordagem de gestão sistemática e adequada às características desse mesmo projecto. Hoje encontramos aplicações da gestão de projectos em praticamente todas as áreas de actividade de uma empresa. Relativamente aos projectos de desenvolvimento de software, estes têm mantido ao longo dos últimos anos uma reputação menos feliz em termos do sucesso obtido na sua concretização, o que se deve frequentemente a uma gestão de projectos menos conseguida. De acordo com diversos estudos efectuados, são várias as causas para a falha dos projectos (Demarco, 1997; Ewusi-Mensah, 2003; Jones, 2004; Kappelman, McKeeman, & Zhang, 2006; Standish Group, 1996, 1998; Yetton, Martin, Sharma, & Johnston, 2000): estimativa e planeamento indevidos; falta de envolvimento do cliente; falta de decomposição do projecto; relutância em reconhecer o terminus de um projecto; falta de especificação e visão clara dos requisitos; expectativas irrealistas e constrangimentos políticos nas organizações; má gestão de recursos humanos [PJMG quality, 164]

199 ESTUDO SURVEY e de conflitos; falta de apoio e de comprometimento no projecto por parte dos seus actores; falta de foco estratégico; etc. Uma paragem quase obrigatória em estudos realizados na área da gestão de projectos é o trabalho realizado pelo Standish Group, que originou um relatório de referência em 1994: o Chaos Report (Standish Group, 1994). Referenciado por muitos investigadores, uns criticando os resultados apresentados, outros nele sustentando as suas próprias teorias, este relatório apresentava, na altura em que foi pela primeira vez publicado, valores extremamente negativos no que diz respeito ao sucesso dos projectos realizados nas empresas. Desde então o Standish Group tem repetido periodicamente o seu estudo nesta área, o qual tem revelado melhorias significativas na gestão de projectos em termos dos resultados obtidos, o que sai reforçado se considerarmos que o número de projectos na área de desenvolvimento de software é hoje significativamente superior àquele verificado em meados da década de Contudo, há ainda um elevado número de projectos que acabam por se encontrar no estado Challenged, indicando uma derrapagem no orçamento, no calendário ou no cumprimento de requisitos. 7.2 ESTUDO SURVEY Com vista a contribuir para colmatar uma lacuna sentida relativamente à necessidade de um conhecimento mais abrangente da realidade da gestão de projectos em Portugal, foi conduzido um estudo com a finalidade de caracterizar em múltiplas dimensões a gestão de projectos realizada em grandes empresas portuguesas. Particularmente, procurou-se identificar que tipo de projectos têm sido realizados, que características apresentam esses projectos, quais as actividades que nas várias áreas da gestão de projectos têm merecido mais atenção por parte das empresas, quais os factores de sucesso mais valorizados, quais os constrangimentos que mais frequentemente surgem, que técnicas são utilizadas, e muitos outros aspectos. O estudo foi conduzido por um grupo de trabalho e operacionalizado por João Pombo (Cardoso, 2008) Caracterização do estudo realizado O estudo realizado envolveu um questionário online cujo convite para resposta foi enviado via e via CTT a uma amostra casual estratificada de 200 gestores de projectos entre as 1000 maiores empresas portuguesas em termos [PJMG quality, 165]

200 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS de facturação (segundo o INE). O questionário foi disponibilizado no período de 14/2/2008 a 15/5/2008 e compreendeu três rondas. Obtiveram-se 20 respostas válidas, ou seja, um pouco mais de 10.1% de taxa de resposta dado ter havido três convites que não foram entregues por dificuldades de correspondência. É, assim, à luz destas características do estudo que devem ser considerados os resultados obtidos. A crescente importância da gestão de projectos tem levado ao surgimento de grupos de trabalho e de diversos referenciais, os quais têm contribuído para o amadurecimento desta disciplina. Exemplo disso mesmo é o PMI (Project Management Institute), a quem se deve a criação em 1976 do PMBoK (Project Management Body of Knowledge), o qual contém técnicas, métodos e processos, sendo hoje um referencial importante na área da gestão de projectos, dado que é utilizado em todo o mundo. Outro exemplo a merecer referência é o PRINCE 2 (Projects IN Controlled Environments), neste caso mais focado em projectos de TIC. Esta documentação de processos e boas práticas, permite aos gestores de projecto evitar muitos dos erros cometidos no passado, e garante uma base de conhecimento que tem vindo a justificar o crescimento do número de projectos terminados com sucesso, o que é notável se considerarmos o contexto e a complexidade crescente dos projectos, o que por consequência os torna cada vez mais difíceis de gerir. Neste trabalho socorremo-nos do PMBoK para a apresentação dos conceitos relativos à gestão de projectos e para a estruturação do estudo efectuado Caracterização das empresas e dos respondentes Dentro do conjunto das empresas respondentes, a maioria (60%) tem entre 201 e 2000 colaboradores, um volume de negócios até 250 milhões de Euros (55%), tem presença internacional (55%), tem pelo menos uma certificação (60%) e enquadra-se em vários sectores de actividade. Das empresas que têm certificações, todas são certificadas com a ISO Os gestores participantes são maioritariamente do sexo masculino (80%), com idades compreendidas entre os 31 e os 40 anos (55%), trabalham há mais de cinco anos na empresa actual (74%), têm como área de formação inicial as TIC (60%), têm formação superior (75%) e uma experiência em gestão de projectos de pelo menos dois anos (65%). Numa percentagem elevada, em 55% das empresas, não é utilizada formalmente uma metodologia de gestão de projectos. Das restantes empresas, 30% [PJMG quality, 166]

201 ESTUDO SURVEY utilizam uma metodologia desenvolvida internamente e 15% optam pela mesma solução, mas baseando-se em vários referenciais (ex: PMBoK). Apenas 5% das empresas responderam utilizar um modelo de maturidade de gestão de projectos. Praticamente todos os gestores recorrem a ferramentas informáticas para suporte da sua actividade, sendo que 60% referiram utilizar o MS Project, 55% o MS Excel e 35% referiram utilizar outras ferramentas. 20% dos gestores de projecto referiram ainda ter uma especialização, dos quais metade em gestão de projectos Caracterização dos projectos realizados na empresa Nos últimos três anos, na sua maioria, os gestores participaram em menos do que 10 projectos realizados na empresa (71%) (Figura 7.1), projectos esses que apresentaram características muito diversificadas, dividindo-se entre sistemas ERP, sistemas de CRM, sistemas de Business Intelligence, sistemas específicos ao negócio, etc., tiveram uma duração tipicamente inferior a seis meses (cerca de 57%) (Figura 7.2) e um orçamento inferior a euros (cerca de 59%) (Figura 7.3). No que concerne ao tipo de desenvolvimento há também uma maioria de projectos a envolver o desenvolvimento à medida (80%) (Figura 7.4). Figura 7.1: Número de projectos em que os gestores do survey participaram na empresa nos últimos três anos [PJMG quality, 167]

202 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Figura 7.2: Duração dos projectos em que os gestores do survey participaram na empresa nos últimos três anos Figura 7.3: Orçamento médio dos projectos do survey nos últimos três anos [PJMG quality, 168]

203 ESTUDO SURVEY Figura 7.4: Tipo de desenvolvimento verificado nos projectos do survey realizados nos últimos três anos Um dos aspectos que se procurou caracterizar com o estudo realizado foi a identificação das principais fontes de complexidade dos projectos realizados, as quais podem surgir da complexidade inerente às tecnologias envolvidas nos projectos, à dimensão do projecto, à estrutura organizacional, às entidades envolvidas, à identificação e definição de requisitos, etc. Na figura 7.5 é possível encontrar os cinco principais aspectos de complexidade identificados pelos gestores, nos projectos em que participaram nos últimos três anos. A fonte de complexidade mais frequentemente verificada está relacionada com os processos de negócio (com cerca de 32% dos gestores a referi-la). As alterações significativas no âmbito surgiram também claramente destacadas, com cerca de 24% dos gestores a referenciá-la. [PJMG quality, 169]

204 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Figura 7.5: Tipo de complexidade verificada nos projectos do survey realizados nos últimos três anos (top 5) Não é estranho que as alterações no âmbito sejam consideradas como um dos principais contribuintes para a complexidade, dado que quando questionados sobre quantos projectos daqueles em que tinham participado nos últimos três anos tinham sofrido alterações no âmbito e na solução final, em média os gestores responderam mais do que 54%. Tal é um facto importante dado que, como é reconhecido, este é normalmente um ingrediente do insucesso nos projectos, dado que da gestão do âmbito dependem outras áreas, como a estimativa do custo e do tempo. Como tal, uma falha nesta área provocará alterações que conduzem frequentemente a derrapagens de tempo e a custos adicionais. Tipicamente o sucesso de um projecto tem sido considerado à luz do cumprimento do orçamento, do tempo e dos requisitos do sistema. Mas naturalmente que tal tem que ser devidamente ponderado em função das características inerentes ao projecto e das circunstâncias que o rodeiam, de modo que outros factores podem surgir com um peso importante na determinação do sucesso. No estudo realizado procuramos identificar genericamente os factores que os gestores de projectos das grandes empresas portuguesas mais valorizam no cumprimento de um projecto, tendo-lhes sido apresentados diversos factores para além dos factores típicos relacionados com orçamento, tempo e requisi- [PJMG quality, 170]

205 ESTUDO SURVEY tos, como terminar dentro dos limites da qualidade, apresentação de soluções com um desempenho superior, utilização optimizada de recursos, etc. Os cinco principais aspectos encontram-se identificados na figura 7.6. Os factores que foram, em média, mais valorizados são os típicos, concluindose que primeiro é valorizado o cumprimento dos requisitos, de seguida o cumprir dos cronogramas e, só depois, o terminar do projecto dentro do orçamento. Figura 7.6: Aspectos do sucesso de um projecto do survey (top 5) Na figura 7.7 é possível observar os resultados obtidos nos diversos projectos realizados conforme indicado pelos respondentes. Do total de projectos já concluídos, cerca de 86% terminaram dentro do orçamento previsto, cerca de 72% de acordo com os requisitos especificados e cerca de 64% dentro do tempo previsto. Destes resultados é de notar que um dos grandes problemas que se coloca actualmente nos projectos em grandes empresas portuguesas se prende com o cumprimento do calendário. Por outro lado, face a estes resultados, é de notar um desalinhamento entre aquilo que é considerado prioritário pelos gestores em termos de aspectos do sucesso (ou seja, requisitos, seguido de tempo e finalmente orçamento). De notar ainda que, para estimar a duração do projecto 85% das empresas respondentes afirma recorrer à experiência resultante de projectos anteriores com tarefas similares, 25% recorrem aos métodos PERT/CPM e 25% a especialistas. [PJMG quality, 171]

206 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Figura 7.7: Aspectos do sucesso dos projectos do survey realizados nos últimos três anos A gestão de projectos pode ser estruturada em diversas áreas: a gestão do âmbito, a gestão do tempo, a gestão do custo; a gestão da qualidade; a gestão dos recursos humanos; a gestão da comunicação; a gestão do risco; e a gestão de aquisições. Pode ainda identificar-se uma outra área, a gestão da integração, responsável pela articulação de todas as outras áreas. Cada uma destas áreas será detalhada nas próximas secções, assim como serão apresentados outros aspectos da realidade da gestão de projectos em Portugal, entre os quais, processos que, nas várias áreas da gestão de projectos, têm recebido mais atenção por parte das empresas, principais constrangimentos no desenvolvimento bem sucedido de um projecto e capacidades consideradas mais importantes no desempenho de um gestor de projectos Processos gerais usados na gestão de projectos Nesta secção são apresentados os processos que recebem actualmente mais atenção por parte dos gestores de projecto em grandes empresas portuguesas. No estudo realizado, os diversos processos da gestão de projectos foram organizados em várias áreas de modo a facilitar a sua compreensão (pese o facto de alguns processos serem transversais a essas áreas). Para cada processo apresentado, solicitou-se aos gestores participantes que indicassem se, nos [PJMG quality, 172]

207 ESTUDO SURVEY projectos em que intervêm, esse processo é realizado Sempre, Frequentemente, Ocasionalmente ou Nunca. Através das respostas obtidas foi possível criar um ranking e identificar os processos aos quais é dada mais atenção. Alguns dos primeiros aspectos da gestão de projectos de desenvolvimento de software que se procuraram caracterizar com o estudo realizado foram os processos gerais utilizados mais frequentemente. Em boa parte, estes são processos que surgem no cerne da gestão de projectos e, naturalmente, afectam e são afectados por outras áreas de conhecimento. Inclusivamente alguns desses processos são tipicamente considerados na área da gestão da integração. Tendo sido apresentados diversos processos aos gestores participantes, entre os quais se encontravam, por exemplo, a utilização de registos de lições aprendidas em projectos anteriores antes de se iniciar um novo projecto, a criação de um plano de projecto, o encerramento formal do projecto, entre outros, nos gráficos apresentados é possível verificar quais desses processos são actualmente mais frequentemente realizados. O Top 3 dos processos gerais realizados (Figura 7.8) inclui a elaboração do plano de projecto, a identificação dos factores críticos de sucesso e, em iguais circunstâncias, a criação de documentação de arranque do projecto e a realização do processo de encerramento do projecto. De notar que, na elaboração do plano de projecto, 39% dos gestores referem utilizar diagramas de Gantt e os diagramas de rede são usados por 26%. Na Figura 7.9 é apresentado o ranking dos processos gerais utilizados. Figura 7.8: Processos gerais usados na gestão de projectos (top 3) [PJMG quality, 173]

208 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Figura 7.9: Ranking de processos gerais usados na gestão de projectos (top 3) Gestão do Âmbito A gestão do âmbito inclui os processos envolvidos na definição e controle do que deve ser considerado no projecto, ou seja, que produtos ou serviços devem ser realizados e quais os processos a utilizar para os conseguir. Esta é uma área que tem por finalidade garantir que a equipa de projecto e os restantes actores têm o mesmo entendimento sobre os resultados esperados do projecto e sobre os processos que serão usados. Tipicamente, a gestão do âmbito envolve a iniciação do projecto, enquadrando-o na realidade da empresa, e o planeamento, definição e controlo de mudanças no âmbito. Nos gráficos apresentados é possível identificar o Top 3 dos processos mais frequentemente realizados na área da gestão do âmbito por parte dos gestores de projecto em grandes empresas portuguesas (Figura 7.10). Os processos identificados fazem parte de um conjunto mais alargado de processos que foram apresentados aos gestores, entre os quais também se podiam encontrar a definição de prioridades em termos de requisitos de acordo com as expectativas do cliente, a identificação das expectativas do cliente e a definição das fronteiras do projecto. No topo da lista dos processos a que é dada mais atenção, aparece a descrição detalhada dos objectivos do projecto, o envolvimento do cliente na definição e validação do âmbito e a definição das entregas [PJMG quality, 174]

209 ESTUDO SURVEY (produtos/serviços) do projecto. Na Figura 7.11 é apresentado o Ranking de processos utilizados na gestão do âmbito. Figura 7.10: Processos utilizados na gestão do âmbito (top 3) Figura 7.11: Ranking de processos utilizados na gestão do âmbito (top 3) Gestão do Tempo A principal finalidade da gestão do tempo é garantir que o projecto é realizado e finalizado dentro do tempo previsto. Envolve estimar a duração do projecto, [PJMG quality, 175]

210 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS desenvolver um calendário do projecto, e assegurar a conclusão do projecto de acordo com o prazo definido. Dado que o tempo é um dos aspectos tipicamente considerados para aferir o sucesso de um projecto, esta área reveste-se assim de particular importância. Os principais processos envolvidos na gestão do tempo são a definição, sequenciação e estimativa da duração das actividades, e o desenvolvimento e controlo do calendário do projecto. No âmbito do estudo realizado foram apresentados diversos processos aos gestores participantes, entre os quais, criação de uma lista detalhada das actividades a realizar de modo a garantir o cumprimento dos objectivos e requisitos do projecto, obtenção da concordância da equipa de projecto no que respeita a tempos definidos e definição de pontos de controlo. Figura 7.12: Processos utilizados na gestão do tempo (top 3) [PJMG quality, 176]

211 ESTUDO SURVEY Figura 7.13: Ranking de processos utilizados na gestão do tempo (top 3) Nos gráficos apresentados (Figura 7.12 e Figura 7.13) é possível verificar que, do conjunto de processos apresentados, aqueles que foram referidos como mais frequentemente realizados são a indicação ao cliente de eventuais desvios no progresso do trabalho, a análise de problemas e a apresentação de soluções ou acções correctivas no caso de serem detectados problemas/desvios, e a participação de toda a equipa de trabalho na definição do plano de projecto Gestão do Custo A gestão do custo, à semelhança da gestão do tempo, aparece com grande destaque na gestão de projectos, dado que o cumprimento do orçamento é também um dos aspectos de um projecto que comummente é considerado na avaliação do sucesso. A gestão do custo procura garantir que o projecto é completado dentro do orçamento definido. Sendo os recursos e os orçamentos sempre limitados, esta área requer grande rigor e exigência, sendo necessária a realização de diversos processos relacionados com o planeamento de recursos, e a estimativa e controlo de custos. Dentro de um conjunto de processos, entre os quais se incluíam a identificação de oportunidades com o objectivo de melhorar a rentabilidade de um projecto, a consideração de diferentes alternativas para a resolução de problemas e as suas consequências em termos de custos antes de ser tomada uma [PJMG quality, 177]

212 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS decisão ou ser sugerida uma solução e elaboração de uma estimativa de custos para os recursos necessários, foram identificados os processos que mais frequentemente são realizados nas empresas. Figura 7.14: Processos utilizados na gestão do custo (top 3) Nos gráficos apresentados (Figura 7.14 e Figura 7.15) é possível verificar que no Top 3 se encontram a realização do controlo de custos, a identificação dos recursos necessários e a elaboração de uma estimativa de custos para as actividades. Figura 7.15: Ranking de processos utilizados na gestão do custo (top 3) [PJMG quality, 178]

213 ESTUDO SURVEY Gestão da Qualidade A gestão da qualidade procura assegurar que o projecto satisfaz as necessidades que conduziram à sua realização de acordo com as expectativas dos clientes. A sua finalidade principal é garantir que os objectivos do projecto são atingidos com a qualidade adequada de forma a satisfazer as necessidades identificadas. Envolve vários processos, desde o planeamento até ao controlo da qualidade. De notar que nesta área é fundamental identificar o significado de qualidade sob a perspectiva do cliente e pesar claramente a relação custo/benefício das acções necessárias para atingir determinados níveis de qualidade. Foram apresentados diversos processos aos gestores participantes, entre os quais se encontram, por exemplo, definição de actividades que garantam normas de qualidade, definição de métricas para a aferição da qualidade e controlo da qualidade através da monitorização de resultados. Figura 7.16: Processos utilizados na gestão da qualidade (top 3) No gráfico apresentado é possível verificar quais desses processos são actualmente mais frequentemente realizados (Figura 7.16). O Top 3 dos processos gerais realizados inclui, assim, a identificação de problemas e respectiva análise, a normalização de documentação por projecto e a gestão de um repositório [PJMG quality, 179]

214 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS central de documentação de projecto, de forma sistemática e acessível pelos diversos elementos da equipa (Figura 7.17). Figura 7.17: Ranking de processos utilizados na gestão da qualidade (top 3) Gestão dos Recursos Humanos Nos recursos humanos de um projecto incluem-se todos os actores do projecto: patrocinadores, clientes, os elementos da equipa de projecto, pessoal de suporte, fornecedores, entre outros. A gestão de recursos humanos visa a optimização da utilização dos recursos humanos envolvidos no projecto. Naturalmente que os recursos humanos intervenientes num projecto são de vital importância para o seu sucesso, dado que são um dos mais evidentes facilitadores ou condicionadores do trabalho desenvolvido. Os principais processos envolvidos são o planeamento organizacional, e a aquisição e o desenvolvimento da equipa. Nos gráficos apresentados é possível identificar o Top 3 dos processos mais frequentemente realizados na área da gestão dos recursos humanos por parte dos gestores de projecto em grandes empresas portuguesas (Figura 7.18). Os processos identificados fazem parte de um conjunto mais alargado de processos que foram apresentados aos gestores, entre os quais também se podiam encontrar são criadas oportunidades para transferir conhecimentos entre os diferentes elementos da equipa, é efectuado um plano de formação para os elementos da equipa de projecto e são estabelecidas prioridades do trabalho da equipa. No topo da lista dos processos a que é dada mais atenção, aparece [PJMG quality, 180]

215 ESTUDO SURVEY a identificação das responsabilidades de cada elemento da equipa, a definição dos objectivos do trabalho de cada elemento da equipa e a motivação da equipa para o cumprimento dos objectivos do projecto. Figura 7.18: Processos utilizados na gestão dos recursos humanos (top 3) Na Figura 7.19 é apresentado o Ranking de processos utilizados na gestão de recursos humanos. Figura 7.19: Ranking de processos utilizados na gestão dos recursos humanos (top 3) [PJMG quality, 181]

216 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Gestão da Comunicação A finalidade da gestão da comunicação num projecto é garantir que a informação é obtida, arquivada, criada, disseminada e disponibilizada atempadamente e com a qualidade necessária. Por outras palavras, a gestão da comunicação procura garantir que a informação estará disponível a quem dela precisa, de forma adequada, e na altura e no local necessários. Os principais processos envolvidos nesta área são o planeamento das comunicações, a distribuição da informação, a criação de relatórios de desempenho e o encerramento administrativo. No âmbito do estudo realizado foram apresentados diversos processos aos gestores participantes, entre os quais, o planeamento da comunicação e é efectuado um plano de reuniões externas. Figura 7.20: Processos utilizados na gestão da comunicação (top 3) Nos gráficos apresentados é possível verificar que, do conjunto de processos apresentados, aqueles que foram referidos como mais frequentemente realizados são a distribuição de informação ao cliente, a distribuição da informação aos elementos da equipa e a criação de um plano de reuniões internas (Figura 7.20). [PJMG quality, 182]

217 ESTUDO SURVEY Figura 7.21: Ranking de processos utilizados na gestão da comunicação (top 3) Na Figura 7.21 é apresentado o Ranking de processos utilizados na gestão da comunicação Gestão do Risco A gestão do risco procura identificar e analisar as possíveis ameaças ao sucesso do projecto e, sempre que possível, implementar medidas preventivas de modo a evitar que as ameaças se concretizem efectivamente. Envolve, assim, detectar potenciais problemas e os seus possíveis impactes, para que seja possível colocar em prática um conjunto de acções que previna ou minore esses efeitos. Os principais processos ligados à gestão do risco são a identificação de riscos, a análise de riscos, a criação de um plano de resposta aos riscos e o controlo das respostas aos riscos identificados. Dentro de um conjunto de processos entre os quais se incluíam a avaliação do impacte do risco e da sua possibilidade de ocorrência, a monitorização do risco e a selecção de riscos para uma análise mais detalhada, foram identificados os processos que mais frequentemente são realizados nas empresas. Nos gráficos apresentados é possível verificar que no Top 3 se encontram a identificação dos riscos do projecto na fase de planeamento, a definição de acções correctivas e a definição de acções preventivas (Figura 7.22). Na Figura 7.23 é apresentado o Ranking de processos utilizados na gestão de risco. [PJMG quality, 183]

218 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Figura 7.22: Processos utilizados na gestão do risco (top 3) Figura 7.23: Ranking de processos utilizados na gestão do risco (top 3) Gestão de Aquisições A gestão de aquisições inclui os processos relativos à aquisição de bens e/ou serviços a terceiros no contexto de um projecto. Os processos principais são o planeamento das compras, o pedido e obtenção de propostas de fornecedores, a [PJMG quality, 184]

219 ESTUDO SURVEY selecção de fornecedores, a administração de contratos e, finalmente, o encerramento dos contratos. Em projectos em que o nível de outsourcing é muito elevado, esta área torna-se numa das mais importantes áreas da gestão de projectos dado que, para além das aquisições se tornarem um dos principais factores de custo, a falha de um contrato pode condicionar todo o projecto. Tendo sido apresentados diversos processos aos gestores participantes, entre os quais se encontravam, por exemplo, o planeamento de solicitações e a identificação dos bens e serviços necessários a contratar ao exterior, entre outros, nos gráficos apresentados é possível verificar quais desses processos são actualmente mais frequentemente realizados (Figura 7.24).. O Top 3 dos processos gerais realizados inclui, assim, a elaboração e gestão dos contratos, o planeamento das compras e a análise das condições e custos dos diversos fornecedores possíveis. Na Figura 7.25 é apresentado o Ranking de processos utilizados na gestão de aquisições. Figura 7.24: Processos utilizados na gestão de aquisições (top 3) [PJMG quality, 185]

220 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Figura 7.25: Ranking de processos utilizados na gestão de aquisições (top 3) Encerramento do projecto Após a identificação dos processos mais frequentemente realizados nas diver- sas áreas da gestão de projectos, procuramos identificar a informação produzida aquando do encerramento do projecto e se a fase de manutenção (subsequente à implementação do projecto) está normalmente incluída na gestão de projectos. Os gestores de projectos que referiram eriram efectuar o encerramento formal nos projectos são 35% do total dos participantes no estudo. No que concerne à informação, aquela que mais frequentemente é produzida no encerramento dos projectos (Top 3) tem a ver com a informação geral de gastos durante o projecto, informação sobre a importância do projecto e das vantagens adquiri- das pela empresa pela sua realização e informação sobre as mais-valiaestratégico que o projecto traz à empresa (Figura 7.26). Tendo em consideração a importância dada à gestão de aquisições e à gestão de custos, é natural encontrar no topo da lista a informação geral de gastos durante o projecto. De notar que estes três tipos de informação encontram-se numa lista que inclui a nível também, por exemplo, informação geral dos tempos utilizados nas tarefas do projecto, informação geral dos riscos e problemas identificados no projecto e informação de lições aprendidas no decorrer do projecto. [PJMG quality, 186]

221 ESTUDO SURVEY Figura 7.26: Informação produzida aquando do encerramento do projecto (quando este é efectuado) Figura 7.27: Ranking de informação produzida aquando do encerramento do projecto (quando este é efectuado) Quando questionados se o projecto incluía (normalmente) a manutenção do sistema desenvolvido, 70% dos gestores afirmaram que a mesma não estava incluída no projecto. [PJMG quality, 187]

222 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Aos 30% dos gestores de projecto que afirmaram efectuar a manutenção do sistema como parte integrante do projecto, foi pedido que indicassem a frequência de determinados processos nesta fase, entre os quais é feita uma auditoria contínua ao valor do projecto para a empresa, são registados os riscos da fase de manutenção e são registadas possíveis s alterações do âmbito na fase de manutenção. Como é possível observar nos gráficos apresentados, do conjunto de processos propostos, aqueles que foram referidos como mais frequentemente realizados foram são registados os custos da fase de manutenção, é efectuada a gestão de recursos e avalia-se continuamente a possibilidade de continuar ou terminar o projecto de acordo com as necessidades da empresa. Mais uma vez os custos aparecem como uma das princi- pais preocupações dos gestores de projectos. Figura 7.28: Acções de manutenção do sistema desenvolvido (top 3) [PJMG quality, 188]

223 ESTUDO SURVEY Figura 7.29: Ranking de acções de manutenção do sistema desenvolvido (top 3) Ranking de actividades Os gestores de projecto participantes no estudo foram questionados sobre a frequência de realização de mais de 60 processos envolvidos na gestão de projectos. Através das respostas obtidas foi possível apresentar nas edições ante- riores da Semana Informática diversos rankings das actividades mais frequen- temente realizadas, organizadas por área da gestão de projectos. Para além das actividades mais frequentes por área, interessa também identi- ficar quais as áreas que têm estado no cerne da gestão de projectos e aquelas que provavelmente necessitam de mais atenção. Através da análise da totalidade das respostas verifica-se que a gestão das aquisições e a gestão do custo são as áreas que actualmente recebem mais atenção, dado que os seus processos são mais frequentemente realizados. Já a gestão do risco e a gestão da qualidade são áreas que se apresentam numa situação oposta, o que pode indiciar que não estão a ser devidamente conside- radas por parte dos gestores de projectos. Na figura 7.30 é possível encontrar o ranking dos processos realizados com mais frequência na gestão de projectos, independentemente da área em que se enquadram. De notar que oito desses processos se enquadram na gestão de aquisições e na gestão de custos, pertencendo os restantes à gestão do âmbito (dois) e à gestão de recursos humanos (dois). Tendo os gestores de projecto participantes refe- [PJMG quality, 189]

224 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS rido que cerca de 86% dos projectos em que participaram nos últimos três anos terminaram am dentro do orçamento previsto, tal pode dever-se em grande parte à grande ênfase que é dada à gestão das aquisições e à gestão do custo. Figura 7.30: Processos mais realizados na gestão de projectos (top 12) Procurou-se também identificar os processos realizados com menor frequência, os quais se encontram listados na Figura Dos vários processos, a grande maioria pertence à área da gestão da qualidade (oito), sendo que os restantes pertencem à gestão do risco (três) e à gestão da comunicação (um). [PJMG quality, 190]

225 ESTUDO SURVEY Figura 7.31: Processos menos realizados na gestão de projectos (top 12) Este resultado veio reforçar a necessidade de um maior empenho por parte do gestor de projecto no âmbito da qualidade. Como se pode constatar através destes resultados os processos da área da qualidade são os que tem menos atenção por parte dos gestores, facto este que reforça a necessidade de uma optimização nas actividades do gestor na área da qualidade. A gestão da qualidade deve ser encarada como um factor de diferenciação no trabalho do gestor pela positiva. Verifica-se, portanto, que apesar de todos os progressos obtidos ao longo dos últimos anos, as actividades de garantia da qualidade ainda encontram grande espaço para evoluir tendo em conta as necessidades crescentes da sociedade actual. [PJMG quality, 191]

226 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Sucesso de um projecto O sucesso de um projecto deve ser aferido com base num conjunto rico de factores, apesar de ser tipicamente considerado com base no cumprimento do orçamento, no cumprimento do calendário e na satisfação de requisitos, aspectos reforçados pela visão que o Chaos Report marcou ao longo do tempo. Esse é precisamente um dos principais pontos de discórdia de vários investigadores relativamente aos estudos iniciais do Standish Group, dado que não só esses três factores poderão não ser factores decisivos na determinação do sucesso, como inclusivamente poderão haver outros factores que assumam uma importância primordial. Por exemplo, em termos simples, se no final do projecto um cliente se encontrar satisfeito com o resultado apesar de haver uma ou duas semanas de atraso, o sucesso do projecto pode ser considerado superior àquele obtido caso o projecto seja terminado dentro do custo, tempo e requisitos previstos, mas o cliente não se encontre satisfeito (por exemplo, resultante de má gestão das expectativas). No estudo realizado procurou-se identificar não apenas os cenários tipicamente mais valorizados para a aferição do sucesso alcançado, como também os aspectos considerados mais críticos para o sucesso de um projecto e os principais constrangimentos que afectam o desejado desenvolvimento de um projecto. Foram apresentados aos gestores participantes vários cenários de encerramento do projecto e foi-lhes solicitado que os ordenassem por importância na definição de sucesso do projecto, ou seja, deveriam seleccionar primeiro o cenário mais relevante e assim sucessivamente. Alguns dos cenários apresentados foram, por exemplo, o projecto foi completado (mesmo havendo acordo para a redução de funcionalidades), o projecto foi entregue ao cliente quando necessário (não necessariamente dentro do prazo previsto), o projecto terminou dentro de um custo acessível para o cliente (não necessariamente dentro do custo previsto) e os utilizadores consideram o sistema de fácil utilização. Na figura 7.32 é possível verificar que os principais cenários estão intimamente relacionados com o cumprimento de requisitos e encontram-se claramente destacados, seguidos do cumprimento tempo e do custo esperados. [PJMG quality, 192]

227 ESTUDO SURVEY Figura 7.32: Cenários na definição do sucesso de um projecto (top 5) Com base num conjunto alargado de aspectos importantes para o desejado desenvolvimento de um projecto em que se encontravam, por exemplo, a eficácia da comunicação no projecto, a existência de expectativas realistas relati- vamente ao projecto, o envolvimento da gestão de topo, o desempenho de tarefas técnicas e o envolvimento do cliente em todo o processo, foi solicitado aos gestores de projectos que classificassem esses aspectos utilizando uma escala de Likert de 1 a 5, em que 1 indicava que o aspecto era menos relevante e 5 que era mais relevante. Os aspectos considerados mais relevantes para o sucesso de um processo encontram-se presentes na figura 7.33 e são o planea- mento do projecto, a definição clara dos objectivos e dos requisitos do projecto, a eficácia do gestor de projecto, o planeamento e organização da equipa do projecto e, em igualdade de circunstâncias, o empenho da equipa de projecto em atingir os objectivos definidos e o envolvimento do cliente em todo o pro- cesso. [PJMG quality, 193]

228 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Figura 7.33: Aspectos importantes no desenvolvimento bem sucedido de um projecto (top 5) Tal como foi feito para a identificação de aspectos importantes para o desejado desenvolvimento de um projecto, também se procuraram identificar os constrangimentos mais condicionadores do sucesso. Embora estes estejam intimamente relacionados com os primeiros, foi relevante a sua consideração, até para ser possível reforçar a informação obtida. Dentro de um conjunto de constrangimentos em que se encontravam, por exemplo, a falta de análise dos riscos, a alteração de requisitos/alteração do âmbito, falhas na gestão de custos, falta de experiência da equipa de trabalho, foi solicitado aos gestores que classificassem esses aspectos utilizando uma escala de Likert de 1 a 5, em que 1 indicava que o aspecto era menos relevante e 5 que era mais relevante. Os principais constrangimentos identificados para o sucesso de um processo encontram-se presentes na figura 7.34 e são a falta de foco estratégico e de apoio da gestão de topo, sobreposição de projectos, falhas na especificação e visão pouco clara dos requisitos, falta de competências na equipa de trabalho e conflitos entre colaboradores e má gestão de recursos humanos. [PJMG quality, 194]

229 ESTUDO SURVEY Figura 7.34: Constrangimentos influenciadores do sucesso de um projecto (top 5) O gestor de projectos A eficácia de um gestor de projectos é um factor determinante para o sucesso de virtualmente qualquer projecto. A ele colocam-se grandes desafios e exigências, que variam desde deter um conjunto diversificado de capacidades técnicas e humanas, perceber os múltiplos conceitos, técnicas e ferramentas da gestão de projectos, e ser capaz de as aplicar de acordo com as circunstâncias particulares de cada projecto em que se vê envolvido. No estudo realizado procuramos identificar as actividades mais relevantes no seu trabalho e as capacidades que os gestores de projecto consideram mais importantes no seu desempenho. Foi apresentada uma lista diversificada de actividades aos gestores e foi-lhes pedido que classificassem a sua relevância de acordo com uma escala de Likert de 1 a 5, em que 1 indicava que a actividade era menos relevante e 5 que era mais relevante. Dentro de um conjunto de actividades em que se encontravam, por exemplo, controlar o risco do projecto, planear a gestão de alterações, elaborar o plano da qualidade, motivar a equipa do projecto e planear a gestão de alterações, foi possível identificar aquelas que são consideradas mais relevan- tes e são apresentadas na figura [PJMG quality, 195]

230 CAPÍTULO SETE - CARACTERIZAÇÃO DA REALIDADE DA GESTÃO DE PROJECTOS NAS GRANDES EMPRESAS PORTUGUESAS Definir objectivos do projecto, identificar e definir o âmbito do projecto, comunicar com o cliente do projecto, definir aspectos críticos do projecto, e controlar o progresso do projecto em igualdade de circunstâncias com o pla- neamento do projecto, são as actividades mais relevantes. Figura 7.35: Actividades do gestor de projectos (top 5) Relativamente às capacidades consideradas importantes para o desempenho do gestor de projectos, foi apresentada uma lista de capacidades aos gestores e foi-lhes solicitado que seleccionassem primeiro a capacidade mais relevante e assim sucessivamente. Na figura 7.36 a capacidade de liderança surge claramente destacada, seguida da capacidade de comunicação também com um destaque claro. [PJMG quality, 196]

231 ESTUDO SURVEY Figura 7.36: Capacidades do gestor de projectos (top 5) É interessante notar que, dos gestores de projectos participantes no estudo, 50% já trabalharam como programadores e 55% já foram analistas de sistemas, sendo que 40% já desempenharam as duas funções. No próximo capítulo é apresentado o modelo de actividades do gestor de pro- jectos no âmbito da garantia de qualidade. [PJMG quality, 197]

232

233 Capítulo 8 Modelo de actividades do gestor de projecto no âmbito da qualidade Não são os mais fortes da espécie que sobrevivem, nem os mais inteligentes, mas sim os que respondem melhor às mudanças. Charles Darwin Se não posso realizar grandes coisas, posso pelo menos fazer pequenas coisas com grandeza. Clarck Neste capítulo é apresentado o modelo de actividades da gestão de projectos no âmbito da garantia de qualidade. É caracterizado o modelo construído com base nos resultados obtidos. É efectuada a descrição das actividades das diferentes fases constituintes do modelo. São identificadas as actividades determinantes do modelo. No final do capítulo é apresentado um resumo do modelo. This chapter presents the activities model of projects management in terms of the quality assurance. The model based on the results obtained is characterized. It s also made the activities description of the different model phases. The determinant activities of the model are identified. At the end of the chapter a summary of the model is presented. 8.1 INTRODUÇÃO AO MODELO Um dos grandes desafios do presente consiste em disponibilizar a informação certa, no contexto correcto, aos recursos humanos correctos, de modo atempado. Num projecto de desenvolvimento de software, o trabalho dos elementos individuais de cada equipa depende maioritariamente da disponibilização de informação atempada, tanto do gestor de projecto como de outros colaboradores (que podem ser responsáveis por liderar determinadas actividades). A elaboração de relatórios (nomeadamente relatórios de progresso) é outro ponto-chave na colaboração entre os elementos da equipa. Elaborar e manter um plano do projecto preciso e actualizado e de acordo com o previsto revela-se uma actividade que constitui um desafio permanente. A possibilidade de se poder publicar e partilhar informação (ou genericamente um conjunto de arte- [PJMG quality, 199]

234 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE factos associados a um projecto), bem como existir uma forma fácil de receber feedback, torna-se essencial em projectos de TIC modernos. Na actualidade, o excesso e sobrecarga de informação pode ser prejudicial, em igualdade de circunstâncias com o acesso reduzido à informação de um projecto. Os diversos estudos do Standish Group (Standish Group, 1996, 1998, 2001, 2004a, 2006) evidenciam a necessidade de uma GP rigorosa em projectos de TIC. As abordagens existentes, como o PMBoK (PMI, 2000) ou o Prince2 (Commerce, 2005), são genericamente aplicáveis a qualquer tipo de projecto. No entanto, os métodos da GP não endereçam as características únicas do desenvolvimento de software (Bob Hughes & Mike Cotterell, 2002), o que levou ao desenvolvimento da Software Project Management (SPM) como área de aplicação e de estudo independente. Apesar de a normalização na gestão de projectos de software reduzir a probabilidade de insucesso, temos que ter em consideração que esta não garante o sucesso do projecto. O gestor do projecto assume um papel muito importante na gestão de projectos. Sem um bom gestor muito dificilmente um projecto é bem sucedido. Um projecto pode ser gerido de diversas formas. Como tal, torna-se fundamental a elaboração e o uso de normas na gestão de projectos com o objectivo de obter maior eficiência no planeamento, na execução, no acompanhamento e na implementação das actividades, pois permite acesso prático às informações, melhor aplicação dos recursos, optimização de prazos e gestão de mudanças necessárias. O Project Management Institute (PMI) tem dado uma ajuda valiosa nesse sentido e nos mais variados sectores da indústria, principalmente com a publicação do PMBoK e a certificação PMP 9, que permitem um aperfeiçoamento e uma rentabilização do trabalho dos gestores. No entanto, não existe um modelo de gestão de projectos com foco na área da qualidade e para o responsável principal: o gestor de projectos. Segundo Campos (1992), os modelos são instrumentos que indicam os procedimentos (meios) para a execução dos trabalhos ou actividades, de tal modo que cada um tenha condições de assumir a responsabilidade pelos resultados de seu trabalho (V. F. Campos, 1992). 9 A Certificação PMP (Project Management Professional) faz parte do Programa Profissional de Certificações do PMI (Project Management Institute) sendo actualmente considerada e reconhecida internacionalmente como a mais elevada credencial profissional na área de Gestão de Projectos. [PJMG quality, 200]

235 INTRODUÇÃO AO MODELO Um padrão ou modelo pode ser alterado para a inclusão de procedimentos, conceitos e também métodos de medida. A criação e adopção de modelos na organização é a situação ideal, pois a dependência do sucesso dos projectos deixa de estar intimamente vinculado à equipa, ou a um elemento específico. Passa, então, a estar associada ao conjunto proposto, discutido e validado das práticas gerais, que serão uma base credível de melhores técnicas aplicadas na organização. Sendo assim, as organizações devem encarar a padronização como uma ferramenta que trará benefícios de custo, prazos, satisfação do cliente e principalmente qualidade nos serviços e produtos oferecidos (W. L. Vieira, 2004). Desta forma, todas as equipas poderão adoptar as melhores práticas, terão um plano mestre a ser seguido, saberão que métricas utilizar para analisar o seu desempenho e poder corrigir algum desvio de rumo. Até os erros poderão servir como base de aprendizagem e nortearão novos planeamentos e o amadurecimento dos processos. Segundo Vieira (2004) a sobrevivência humana depende há milhares de anos da padronização. Originalmente, não era necessário registar os processos padronizados, pois as pessoas aprendiam observando e guardando na memória. Hoje em dia os procedimentos documentados através do papel ou electronicamente constituem memória e para isso conta-se com organismos, governamentais ou não, como é o caso da ISO - International Organization for Standardization, que auxiliam na elaboração de procedimentos documentados, através de normas técnicas. Os padrões começam frequentemente como directrizes que descrevem uma aproximação preferida e, mais tarde, com a adopção difundida, transformamse em regulamentos de facto, isto é, institucionalizam-se (PMI, 2004a). Quando há mudanças ou alterações nas exigências e nos objectivos, a execução do processo poderá também mudar para assegurar que este permaneça eficaz. No entanto, Tartarelli (2004) conclui: com a padronização ganha-se em produtividade e em qualidade, mas perde-se em capacidade de inovação por causa da rigidez estrutural e pela perda da visão sistémica. A adopção de modelos deve ser um item relevante no desenvolvimento do software, mas nunca como solução única e estática. Portanto, uma vez definido um modelo organizacional, esse processo deverá passar por melhorias, sempre que se revele necessário. [PJMG quality, 201]

236 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE O processo deve ser conhecido por todos os seus envolvidos, para que possa ser utilizado adequadamente, levando a organização a ter procedimentos padronizados. O modelo organizacional, assim reflectido, deve tornar-se numa linha de orientação para a melhoria do processo. Neste capítulo é apresentado o resultado principal da tese: um modelo de actividades da gestão de projectos no âmbito da qualidade e uma lista ordenada das actividades determinantes nesta área. De modo a clarificar a aplicação do termo modelo é apresentado o sentido em que é utilizado no presente trabalho. Os modelos são representações simplificadas de alguma parte da realidade, sendo extremamente importantes para a compreensão dessa mesma realidade. Um modelo pode ser definido como um esquema teórico em matéria científica representativo de um comportamento, de um fenómeno ou conjunto de fenómenos (Press, 2008). A utilização de modelos a diversos níveis é frequente nos métodos e abordagens analíticas, normalmente associados a níveis de abstracção distintos (Amaral, 1994). Um modelo é um padrão, um plano, uma representação, ou descrição para mostrar a estrutura ou o funcionamento de um objecto, sistema ou conceito. Um modelo mental é uma representação cognitiva de uma ideia ou de um processo. É uma representação simplificada da realidade. De um modo geral, o termo modelo refere-se a conhecimento estruturado que procura reflectir uma realidade. Os modelos existem internamente como modelos mentais e externamente como artefactos cognitivos. Os artefactos cognitivos podem ter muitas formas: textos escritos, histórias orais, gráficos, diagramas, figuras, vídeos, folhas de cálculo, equações, simulações de computador, entre outros. Todos constroem modelos mentais das realidades com que têm que lidar. Todos simulam mentalmente estes modelos de forma a retirar significado e a prever consequências. George Box tornou célebre a expressão de que todos os modelos estão errados alguns modelos são úteis (Box, 1979) e Barry Richmond (Richmond, 1981) a de que apesar de todos os modelos estarem errados, e de não existirem modelos completos, não temos outra hipótese senão usá-los. No âmbito do presente trabalho considera-se um modelo como um conhecimento estruturado que procura reflectir uma realidade (com as limitações anteriormente referidas) e que permite compreender, orientar e facilitar a acti- [PJMG quality, 202]

237 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE vidade e desempenho do gestor de projectos de desenvolvimento de software no âmbito da qualidade. O objectivo principal da construção do modelo de actividades do gestor de projectos para a qualidade relaciona-se com o aumento da visibilidade do projecto desde o seu início. O gestor do projecto fica dotado de uma ferramenta de trabalho que lhe permite a identificação de potenciais problemas o mais cedo possível, conferindo-lhe a capacidade de resolução dos mesmos com uma maior antecipação e rigor. O modelo que é apresentado neste capítulo resulta de várias fontes de trabalho que concorrentemente contribuíram para o resultado obtido. A informação obtida na pesquisa bibliográfica, todos os elementos consultados da documentação recolhida e cedida pelas empresas, a recolha de dados através das entrevistas semi-estruturadas e respectiva análise da informação obtida. Foram identificadas um conjunto de actividades principais constituintes do modelo. Com vista a perceber a prática da Gestão de Projectos em Portugal foi conduzido um survey com a finalidade de caracterizar em múltiplas dimensões a gestão de projectos realizada em grandes empresas portuguesas. Foi realizado um estudo Delphi, no qual se pretendem identificar as actividades determinantes do conjunto das actividades identificadas, numa primeira fase. Este estudo também contribuiu para a corroboração e refinamento do modelo. 8.2 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE De acordo com a certificação ISO 9001:2000 a qualidade deve atender a: Melhor planeamento e controlo dos processos de trabalho, eliminando passos desnecessários; Padronização das tarefas e definição de responsabilidades, para maior segurança e agilidade nas actividades; Criação de um sistema de controlo para identificação e tratamento das anomalias verificadas durante o processo, evitando refazer trabalho já efectuado; Realização das actividades buscando melhorias na qualidade e aumento da satisfação dos clientes. [PJMG quality, 203]

238 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE A gestão da qualidade de um projecto abrange todas as fases e componentes desse projecto. Necessita da participação de todos os membros da equipa de projecto e deve ser encarada como um dos alicerces do projecto. A base da qualidade do projecto corresponde à qualidade das práticas de gestão da qualidade da organização que nele está envolvida e que contribui para o desenvolvimento dos processos e resultados do projecto em causa. É a organização que especifica a política de qualidade, objectivos e responsabilidades neste âmbito e a forma como qualidade é implementada, por exemplo através do plano da qualidade, procedimentos operacionais standard, medidas de controlo, métricas e outros aspectos definidos pelo sistema de gestão de qualidade da organização. Um dos riscos de ignorar a qualidade é o de não alcançar os objectivos do projecto. Deve ser privilegiado o rigor, a qualidade e a inovação do trabalho. A política da qualidade deve consubstanciar-se no lema: Atingir sempre, e se possível exceder, as expectativas do cliente Atingir este objectivo pressupõe em primeiro lugar, efectuar uma rigorosa gestão do projecto, a qual exige uma gestão de qualidade de todo o seu ciclo de vida. Cada actividade deve materializar-se em produtos intermédios ou documentos, sobre os quais seja possível efectuar um controlo efectivo, revisões periódicas e testes exaustivos. Sempre que possível os métodos e técnicas utilizados na gestão de projectos devem ser suportados por ferramentas computacionais, de modo a garantir um desempenho mais expedito do gestor. Garantir a qualidade não é tarefa fácil, no entanto é fortemente compensadora pelo aumento de produtividade que desencadeia e pela redução significativa que produz, em termos de correcções e manutenção. A gestão de projecto deve garantir que o desenvolvimento do projecto é realizado com base num metodologia sólida, que obedeça a um conjunto bem definido de normas e procedimentos de trabalho. Com este modelo de suporte à gestão de projecto estão claramente identificadas as suas fases, as entregas previstas, os recursos humanos e materiais necessários, os riscos associados, os prazos estabelecidos, os custos estimados, as limitações existentes, o modo como é realizada a verificação e o controlo de documentos produzidos. Os métodos e técnicas utilizadas na GP devem ser suportados por ferramentas computacionais expeditas. [PJMG quality, 204]

239 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE O modelo de actividades proposto nesta tese e que será apresentado neste capítulo é uma ferramenta de trabalho com o objectivo de optimizar o desempenho do gestor, potenciando a normalização e agilização das respectivas actividades, contribuindo para a garantia de qualidade do projecto e, consequentemente, para a satisfação do cliente. Pretende-se com este modelo contribuir activamente para a competência em gestão de projectos no âmbito da garantia de qualidade. Tem de ser uma competência requerida pelos gestores de projecto de todas as organizações que desejem prosperar num mundo cada vez mais competitivo e com projectos cada vez mais complexos. A par da qualidade técnica, a capacidade de gerir projectos de TI é um requisito fundamental dentro das empresas. O gestor do projecto está no centro de todas as decisões e por isso tem que ter capacidade para garantir e negociar o cumprimento das expectativas de cada um dos intervenientes: do sponsor 10 ao utilizador da solução (Alves, J. 2008). Este modelo tem como principais objectivos: Dotar o gestor de projectos de uma ferramenta de trabalho de forma a optimizar o seu desempenho; Fornecer ao gestor de projectos uma ferramenta, que disponibiliza informações sobre os pontos fortes e fracos do projecto, indicando os problemas que poderão surgir pela aplicação inadequada dos processos de trabalho; Dar uma contribuição para as competências que o gestor de projectos deve reunir para desempenhar as actividades da gestão da qualidade em gestão de projectos; Disponibilizar um acesso mais eficiente à informação do projecto; Dar um contributo para a melhoria da eficácia das funções que o gestor de projectos deve executar e que determinam a implementação correcta e a qualidade dos projectos (e consequentemente o sucesso dos projectos); Dar uma contribuição para a prática da gestão de projectos no âmbito da qualidade; 10 patrocinador [PJMG quality, 205]

240 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Potenciar o encontro do equilíbrio entre os vários objectivos do projecto que normalmente são forças opostas: há que garantir todo o âmbito do projecto e com qualidade, mas por outro lado o tempo e o orçamento são sempre limitados; Enfatizar a importância do planeamento e das acções preditivas. Na construção deste modelo foca-se a qualidade como factor integrante de todas as actividades nele representadas. O que se pretende com o modelo é alicerçar (consolidar) a componente da qualidade na função do seu actor principal, o gestor de projectos, através da identificação das actividades determinantes do seu trabalho que tem neste modelo, a gestão da qualidade como elemento principal. As actividades constituintes do modelo que se aceitam como relevantes para a prática da gestão de projectos e respectivas fases a que pertencem estão representadas na Figura 8.1. O PJMG quality : Permite a sistematização das funções do gestor no âmbito da qualidade e no cumprimento dos seus objectivos; Potencia a optimização do desempenho das actividades do gestor; Permite a normalização dos processos constituintes das fases principais da gestão de projectos; Evita a perda de eficácia centrando as funções do gestor de projectos nas actividades determinantes; Enfatiza o rigor e a simplificação; Potencia a aproximação dos referenciais teóricos com a prática de gestão real de um projecto; Hierarquiza as actividades, segundo o grau de importância de cada uma, no contexto da gerência ao qual está inserido (gestão de custo, de prazo, de qualidade, etc.); Potencia a melhoria dos factores de prazo, custo e qualidade dos trabalhos realizados pela equipa do projecto. [PJMG quality, 206]

241 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Este modelo permite que se faça a adaptação de cada uma das fases a uma determinada metodologia relacionada com o desenvolvimento de projectos de software ou projectos com diferentes metodologias de desenvolvimento. Pretende-se que o gestor encontre neste modelo um elemento de suporte para dar resposta a um conjunto de questões que se revelam fundamentais no âmbito da garantia de qualidade: Qual o impacto de cada fase do projecto no desenvolvimento do mesmo? Quando é que se pode dar por concluído o sistema? Qual o factor de diferenciação do sistema desenvolvido? Como se pode avaliar a produtividade final do trabalho desenvolvido? Que aspectos se devem ter em consideração para garantir a evolução do sistema (sistemas não obsoletos)? Qual o impacto da fase de manutenção em relação à duração do projecto? Como avaliar o grau de satisfação dos clientes? A utilização deste modelo deve ser perspectivada em função de cada caso em particular. O gestor deve sempre tomar uma atitude crítica, analisando o modelo à procura de melhorias contínuas, sempre que possível. [PJMG quality, 207]

242 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Actividades da Gestão de Projectos Processos no âmbito da gestão da qualidade PL.01 PL.02 PL.03 PL.04 Elaboração do plano de projecto Definição dos aspectos críticos do projecto Elaboração do plano de qualidade Definição do plano de métricas PL.07 PL.08 PL.09 Reunião de Kickoff Definição do plano de gestão de alterações Elaboração do plano de progresso EX.01 EX.02 EX.03 EX.04 Recolher, analisar e registar dados para as métricas do projecto Recolher, analisar e efectuar a gestão de pedidos de alteração Auditar o projecto de acordo com o plano de qualidade Gestão de reclamações EX.07 EX.08 EX.09 EX.10 Reuniões de controlo de progresso Produção de relatórios de progresso internos Produção de relatórios para o cliente Gestão dos Entregáveis EN.01 EN.02 EN.03 EN.04 Arquivar documentação Produzir relatório final de projecto Elaboração do inquérito final de satisfação do cliente Sistematizar e enriquecer base de conhecimento PL.05 Elaboração do plano de aceitação do cliente EX.05 Gestão de não conformidades EX.11 Validar pontos de controlo do projecto PL.06 Elaboração do plano de envolvimento do cliente EX.06 Controlo do plano de aceitação com o cliente Figura 8.1: Modelo de actividades da gestão de projectos no âmbito da qualidade [PJMG quality, 208]

243 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE O modelo proposto reúne as seguintes actividades enumeradas de seguida na Tabela 8.1. Id Designação PL01 Elaboração do plano de projecto PL02 Definição dos aspectos críticos do projecto PL03 Elaboração do plano de qualidade PL04 Definição do plano de métricas PL05 Elaboração do plano de aceitação do cliente PL06 Elaboração do plano de envolvimento do cliente PL07 Reunião de Kick-off PL08 Definição do plano de gestão de alterações PL09 Elaboração do plano de progresso EX01 Recolher, analisar e registar métricas do projecto EX02 Recolher, analisar e tratar pedidos de alteração EX03 Auditar o projecto de acordo com o plano de qualidade EX04 Gestão de reclamações EX05 Gestão de não conformidades EX06 Controlo do plano de aceitação com o cliente EX07 Reuniões de controlo de progresso EX08 Produção de relatórios de progresso internos EX09 Produção de relatórios para o cliente EX10 Gestão dos entregáveis EX11 Controlo de qualidade EN01 Arquivar documentação EN02 Produzir relatório final de projecto EN03 Elaboração do inquérito final de satisfação do cliente EN04 Sistematizar e enriquecer base de conhecimento Tabela 8.1: Actividades do modelo PJMG quality [PJMG quality, 209]

244 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE O modelo é composto por três fases principais de actuação do gestor do projecto nas fases que constituem o ciclo de vida do projecto apresentado no capítulo três. Esta divisão proposta pelo modelo baseia-se no ciclo de vida da gestão de projectos. Proporciona um grau mais efectivo de gestão e controlo dos processos e reduz o grau de incerteza associado. Existem três fases principais no modelo de actividades proposto: Fase de planeamento Nesta fase estão englobadas as actividades de definição do projecto relacionadas com o âmbito, qualidade, tempo e custo; as actividades desta fase também determinam a organização dos recursos e responsabilidades na condução do projecto; Fase de execução São efectuadas as actividades de monitorização e acompanhamento do projecto; Fase de encerramento Tem por objectivo o fecho formal do projecto. Estabelece mecanismos para o potencial desenvolvimento ou continuidade do projecto. Cada fase também representa um momento estratégico do projecto, proporcionando uma oportunidade para confirmar a necessidades do cliente e do negócio. No final de cada fase deve ser realizada uma revisão. As revisões realizam-se durante o projecto em intervalos correspondentes ao fim de cada fase. Estas revisões devem assegurar que existe uma base adequada para continuar as actividades seguintes. Desta forma adquire-se um maior grau de certeza na prossecução do projecto dado que erros e mal-entendidos não se acumularão no decurso do desenvolvimento. A revisão serve fundamentalmente para detectar erros, defeitos e qualidades de um produto intermédio. Permite assim garantir que a fase seguinte começa sem erros propagados da fase anterior. De seguida são apresentadas as três fases constituintes do modelo proposto: Fase de planeamento, Fase de execução e Fase de Encerramento É efectuada uma descrição de cada fase e respectivos objectivos. [PJMG quality, 210]

245 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Fase de planeamento No início de um projecto, existe um conjunto de ideias e opiniões sobre a finalidade e o âmbito do projecto, qual deverá ser o produto final, e como o projecto deve ser executado. Nesta fase deve existir a preocupação em formalizar e planear o projecto. É necessário definir quais os fins a que o projecto se destina atingir e qual o seu âmbito. Ao cumprir estes objectivos, é criado um ponto de referência para avaliar a qualidade do que é efectivamente produzido no final do projecto. É também necessário desenvolver um processo pelo qual os objectivos do projecto podem ser alcançados. Este processo envolve tipicamente a realização de uma série de tarefas ou actividades, produzindo um conjunto de produtos no decurso do projecto. As tarefas devem ser definidas com clareza e por razões de controlo, é útil organizar estas tarefas numa estrutura top down, onde progressivamente é especificado o trabalho exigido com mais pormenor. A fase de planeamento é normalmente a mais difícil de executar e muitas vezes negligenciada (Schwalbe, 2002). O desafio nesta fase é identificar, alinhar objectivos e seleccionar recursos. Uma parte essencial da identificação é compreender claramente quais são as expectativas do cliente e traduzi-las em especificações de projecto. Neste caso, o alinhamento de recursos consiste na compreensão dos objectivos estratégicos da empresa para que posteriormente estes objectivos sejam decompostos em outros objectivos para os processos. Também é importante a compreensão clara das necessidades dos clientes porque terão impacto no âmbito, no custo e no tempo. A selecção inclui a determinação dos recursos necessários para o projecto, incluindo os recursos humanos: definições sobre o patrocinador do projecto, gestores e membros, competências técnicas e financeiras necessárias. Esta fase estará concluída quando o âmbito do projecto estiver definido e aprovado. De acordo com o PMBoK, a gestão do âmbito inclui uma declaração sucinta dos produtos que serão fornecidos e, eventualmente, dos que não serão fornecidos. O planeamento do âmbito também pode declarar o que o projecto não vai fazer ou o que o produto resultante não vai ser (Maximiano, 2002). A gestão do âmbito está fortemente relacionada com outras três áreas prazo, custo e qualidade (Dinsmore, 1999). [PJMG quality, 211]

246 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE A fase de planeamento deve ser conduzida de forma a: Definir clara e explicitamente objectivos e âmbito do projecto; Desenvolver um calendário global de actividades e recursos necessário à realização da totalidade do projecto; Desenvolver um cronograma detalhado das actividades e dos recursos requeridos para realizar a fase seguinte do projecto; Definir a estrutura do projecto que pode ser utilizada para a gestão efectiva do projecto e para a execução do trabalho necessário; Estabelecer um business case adequado para o projecto; Obter o compromisso e a aprovação necessárias da gestão de topo, para o projecto; Preparar um perfil financeiro do projecto, que será utilizada para acompanhar e controlar o desempenho financeiro; Determinar as medidas que serão utilizadas no projecto para medir e manter a qualidade dos processos e resultados tangíveis. A Tabela 8.2 lista as actividades executadas nesta fase e os respectivos deliverables 11 principais (produtos ou documentos) produzidos durante a fase de planeamento. ID Actividade Deliverable principal PL.01 Elaboração do plano de projecto Plano de gestão de projecto PL.02 Definição dos aspectos críticos do projecto Documento aspectos críticos PL.03 Elaboração do plano de qualidade Plano de qualidade PL.04 Definição do plano de métricas Plano de métricas 11 Um entregável ou deliverable é um objecto tangível ou intangível produzido como resultado da execução de um projecto. Um entregável pode ser criado a partir de múltiplos entregáveis menores. [PJMG quality, 212]

247 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE PL.05 Elaboração do plano de aceitação do cliente Plano de aceitação PL.06 Elaboração do plano de envolvimento do cliente Plano de envolvimento PL.07 Reunião de Kick-off Acta da reunião PL.08 Definição do plano de gestão de alterações Plano de gestão de alterações PL.09 Elaboração do plano de progresso Plano de progresso Tabela 8.2: Lista de actividades executadas na fase de planeamento e respectivos deliverables produzidos PL.01 Elaboração do plano de projecto O plano de projecto consiste na documentação formal e organizada, relativa a objectivos, âmbito, planeamento e meios de acompanhamento e execução do projecto, sendo a referência básica para o gestor de projecto. PlanoProjecto=Âmbito+PlanoAcção+PlanoControlo O plano do projecto é um documento aprovado formalmente, utilizado para gerir e controlar a execução do projecto. O objectivo principal do plano é documentar o planeamento e as decisões assumidas para o projecto. Deve facilitar a comunicação entre os stakeholders, e deve incluir a documentação de âmbito, custo e cronograma base. O plano de projecto pode ser resumido ou detalhado (PMI, 2000). O planeamento do projecto é definido como o estabelecimento de planos formais para a realização dos objectivos definidos para o projecto (Meredith & Mantel, 2003). O planeamento é da responsabilidade do gestor de projecto, que deve assegurar que este se realize de forma correcta para a completa satisfação dos stakehoders. Elaborar e manter um plano de projecto preciso, actualizado e de acordo com o previsto revela-se uma actividade que constitui um desafio. Por isso, o gestor deve garantir que execuções [PJMG quality, 213]

248 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE são realizadas de acordo com o plano da linha base, mas também que essa linha base seja fiável. A definição do plano consiste na elaboração de um documento consistente e coerente com os seguintes objectivos: Estabelecer o âmbito do projecto, objectivos técnicos e de negócio, recursos e cronograma necessários para atingir os objectivos do projecto; Desenvolver uma base de trabalho para envolvimento do cliente e determinar os recursos necessários; Preparar o perfil financeiro do projecto, que será utilizado para monitorizar e controlar o desempenho financeiro; Determinar as medidas que serão utilizados no projecto para medir e manter a qualidade dos processos do projecto e respectivos resultados. O plano define, também um conjunto de passos necessários à execução do projecto de acordo com as expectativas do cliente. Deve incluir: Objectivos, restrições, âmbito, abordagem a seguir; Entregáveis e respectivo faseamento; Plano da documentação; Plano de gestão de alterações; Plano de gestão de reclamações; Pontos de controlo do projecto; Agenda de reuniões de acompanhamento. Este plano também é composto por um conjunto de políticas, regras de gestão, procedimentos e normas que se aplicam ao projecto e segundo o qual o projecto deve ser gerido. Deve ser utilizado como base de todo o trabalho do gestor. Os principais pontos que devem ser garantidos no controlo do projecto são: Duração prevista (prazos de execução do projecto); Monitorização do custo do projecto com âmbito e qualidade respeitadas (vertente financeira); [PJMG quality, 214]

249 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Objectivos iniciais do projecto respeitados; Alinhamento com o cliente. O plano de projecto apresenta uma visão completa proposta para o projecto e contém informações mais detalhadas sobre a abordagem do projecto, âmbito, estrutura, técnicas de gestão e de cumprimentos dos objectivos. A estrutura típica de uma proposta para um plano de projecto é apresentada na Tabela 8.3. Plano de projecto Componente Visão geral do projecto (Project Overview) Âmbito Objectivos Restrições e riscos Faseamento do projecto Entregas Descrição Apresenta uma descrição da finalidade, do âmbito, dos objectivos gerais e restrições do projecto. Define a finalidade e o âmbito do projecto. Define as funções principais do projecto e objectivos chave. Define as restrições identificadas para o projecto.quaisquer restrições especiais que possam afectar a realização do projecto (por exemplo, recursos limitados ou data de entrega do projecto); são identificados os condicionalismos técnicos e de gestão, caso existam. Define as diversas fases que compõem o projecto. Define os entregáveis do projecto e respectiva composição. Organização do projecto Fronteiras Papéis e responsabilidades Plano de trabalho Descreve como é efectuado o desenvolvimento do projecto, como é planeado, organizado, quem desenvolve o quê; descreve também os processos de execução e controlo. Inclui informação da area de negócio, stakeholders, estratégias de aquisição e estratégias de gestão. Define as fronteiras do projecto. Definição da estrutura da equipa de projecto. Especificação das respectivas funções e responsabilidades. O modelo de processos, actividades de enquadramento e atribuições definidas e selecionadas para o projecto. Decomposição funcional e respectivo agendamento de tarefas. [PJMG quality, 215]

250 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Plano de acompanhamento do projecto Esta componente do plano de projecto apresenta, de forma estruturada, todos os procedimentos necessários para acompanhamento e avaliação da execução do projecto e dos resultados alcançados. É efectuada a monitorização ou acompanhamento das actividades a executar. São estabelecidos procedimentos para realizar observações e verificações das condições e do progresso do projecto em pontos estratégicos ao longo de sua execução. Permite ta bem avaliar em que medida os resultados esperados estão a ser alcançados. Plano da documentação; Plano de gestão de alterações; Planos de suporte Plano de aceitação do cliente; Plano de envolvimento de cliente; Plano de progresso. Tabela 8.3: Estrutura típica de uma proposta do plano de projecto PL.02 Definição dos aspectos críticos do projecto A definição dos aspectos críticos consiste na identificação do que é mais urgente e que causa maior impacto no desenvolvimento do projecto, focalizado no cliente. Esta actividade consiste na identificação dos aspectos críticos do projecto com foco no cliente e contextualizando a respectiva área de negócio. É fundamental compreender e saber como abordar os aspectos críticos de uma organização. Devem ser identificados os aspectos que contribuem para a satisfação do cliente. Identificar o que é mais urgente e que causa maior impacto no desenvolvimento do projecto. Aqui são mencionados os aspectos críticos do projecto, ou seja, os aspectos que podem condicionar o desenvolvimento e o sucesso do mesmo. A reflexão sobre os pontos críticos permitirá antecipar as acções necessárias e os recursos que deverão ser mobilizados, reduzindo o risco associado ao projecto. Por exemplo, se o fornecedor de determinado recurso é fundamental para a empresa garantir o prazo de entrega ao cliente, este facto constitui um ponto crítico. Deve-se tentar conseguir uma parceria com o fornecedor ou ten- [PJMG quality, 216]

251 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE tar encontrar uma lista de fornecedores alternativa que possam garantir o cumprimento dos prazos. Por outro lado, a análise dos pontos críticos deve permitir que o gestor se prepare, preferencialmente por escrito, para planos de contingência (ou seja, como agir se surgirem situações inesperadas), de forma a minimizar os riscos do projecto. Na Tabela 8.4 são apresentados exemplos de planos de contingência. Uma proposta para a esquematização dos aspectos críticos é a elaboração de uma tabela de aspectos considerados críticos versus características da solução proposta para o projecto (Tabela 8.5). Id Descrição Responsável 1 Procurar obter toda a informação possível dos analistas envolvidos no desenvolvimento da aplicação anterior. Desenvolver a solução tão independentemente quanto possível ao nível dos dados, se necessário recorrer a tabelas auxiliares para controlo. 2 Reunir com o director de projecto do cliente no sentido de o fazer entender as implicações do problema no projecto e assim procure acelerar o processo de aprovação de documentos enviados. Se tal não se revelar viável, enveredar por aprovações tácitas e basear o trabalho subsequente nas mesmas. Analista funcional Gestor de projecto Tabela 8.4: Exemplo da descrição de dois planos de contingência Tabela de aspectos críticos versus características da solução proposta Aspecto/Factor Descrição Solução proposta Adequação às regras da instituição A garantia de satisfação dos utilizadores passa em primeiro lugar pela correcta interpretação das suas necessidades. Execução de uma especificação de requisitos detalhada, que complementa os elementos fornecidos no documento de requisitos de sistema. [PJMG quality, 217]

252 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Facilidade de utilização Versatilidade Escalabilidade da solução Segurança e confidencialidade Uma interface com o utilizador intuitiva e de simples utilização, com reduzido tempo de aprendizagem, conduz a uma aceitação mais célere pelos utilizadores. Uma elevada capacidade de adaptação da solução permite a sua evolução de acordo com as alterações do modelo de funcionamento das áreas abrangidas. As tecnologias utilizadas não podem actuar como um factor limitador mas sim como um factor sinergético no crescimento das organizações. Confidencialidade, autorização e autenticação das interacções com o sistema. Utilização de modelos de iteração utilizados com sucesso no que respeita à interacção com os utilizadores, traduzindo-se na redução do tempo de aprendizagem por parte destes. Utilização de ferramentas de desenvolvimento e de metodologias que garantem a possibilidade de evolução da solução. A utilização de tecnologias e metodologias que respondam às solicitações da organização através do simples redimensionamento dos equipamentos. Utilização de mecanismos robustos de segurança impostos pela infra-estrutura tecnológica. Tabela 8.5: Aspectos críticos versus características da solução proposta PL.03 Elaboração do plano de qualidade A elaboração do plano da qualidade consiste na definição formal dos objectivos e estratégias que constituem a referência para o processo de garantia de qualidade. Neste plano devem estar definidas as estratégias, normas e procedimentos que compõem os processos de qualidade. [PJMG quality, 218]

253 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE O plano de garantia de qualidade é um documento que contém todas as informações necessárias para realizar as actividades de garantia de qualidade do projecto. Existem informações referenciadas pelo plano de projecto que também são referenciadas no plano de qualidade; no entanto, é importante desenvolver os dois planos porque apresentam finalidades distintas. O plano da qualidade é um documento específico para um produto, actividade ou serviço (ou grupo) que indica as actividades necessárias relacionadas com a qualidade. Define linhas de orientação para a execução do projecto. A satisfação do cliente é considerada como parte integrante das especificações do projecto; um dos objectivos do plano da qualidade é possibilitar a verificação no terreno se o produto final está de acordo com os requisitos definidos previamente. A definição deste plano é importante para apurar as expectativas de qualidade para o projecto, e essas expectativas devem estar reflectidas no planeamento das entregas do projecto (definidas no plano de projecto). O plano de projecto também deve estar alinhado com as estratégias da qualidade. Também define os recursos humanos, papéis e responsabilidades que dizem respeito à qualidade. Os objectivos de um plano de garantia da qualidade é o reconhecimento da importância de: Satisfação do cliente Entendimento, avaliação, definição e gestão de expectativas de forma a atender às necessidades do cliente. Isso exige uma combinação de conformidade com os requisitos (o projecto deve produzir o que se comprometeu a produzir) e adequação ao uso (o produto ou serviço deve satisfazer as necessidades reais); Prevenção O custo de prevenção de erros é, em geral muito menor que o custo de corrigi-los; Responsabilidade da gestão O sucesso exige a participação de todos os membros da equipa, mas é sempre responsabilidade da gerência fornecer os recursos necessários para que exista sucesso; Melhoria contínua As iniciativas de melhoria da qualidade realizadas podem melhorar a qualidade da gestão do projecto e também a qualidade do produto. O plano de qualidade é tipicamente composto pelos seguintes elementos: [PJMG quality, 219]

254 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Definição de estratégias de gestão de qualidade, normas e procedimentos; Definição de normas para a documentação a ser produzida ao longo do projecto; Conjunto de documentos que serão produzidos (preferencialmente devem estar definidos modelos/templates para os documentos indicando o seu conteúdo); Definição dos pontos de controlo; Definição de auditorias de qualidade (o processo de definição de auditorias deve seguir todo o ciclo de vida do projecto). O que se pretende auditar é um conjunto de regras com maior risco, que devem ser identificadas pelo gestor do projecto, através dos requisitos definidos. Devem ser estabelecidos e mantidos procedimentos documentados para o planeamento e implementação de auditorias da qualidade internas a fim de verificar se as actividades relativas à qualidade e os resultados associados estão em conformidade com as disposições previstas para aferir a eficácia do sistema da qualidade; Definição do plano de testes que consiste no âmbito, abordagem, recursos e escalonamento (planeamento) das actividades de teste previstas. Identifica itens de teste, as funcionalidades a serem testadas, as tarefas de teste, quem executará cada tarefa, e quaisquer riscos que potencialmente requeiram planos de contingência. Os dois primeiros elementos apresentados acima podem ser omissos, caso esteja implementado na organização um sistema de garantia de qualidade com documentação descritiva destes procedimentos. Uma metodologia que pode ser adoptada para a concepção do plano de testes alicerça-se no paradigma Testware que é baseado e suportado pela norma IEEE.829 (IEEE, 2008). Esta norma descreve um conjunto de documentos que devem ser gerados para as actividades de gestão de testes. Mais do que apresentar um conjunto de documentos, que deve ser utilizado ou adaptado para determinados projectos, a norma apresenta um conjunto de informações necessárias para os testes. A sua utilização correcta auxilia o gestor a concentrar-se tanto nas fases de planeamento e execução, como na fase [PJMG quality, 220]

255 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE de realização de testes, evitando o erro comum de só começar a pensar no desenho dos testes após a conclusão da fase de codificação de um projecto. Existem duas etapas principais na definição do plano de testes: desenho dos testes e o planeamento da execução dos testes. A ilustra a diferença entre um planeamento de projecto (gantt project ou gráfico de gantt) tradicional, em que os testes são uma fase do projecto, e um planeamento (gantt project) sob este paradigma de Testes de Software. Figura 8.2: Diferença entre um planeamento tradicional e um planeamento baseado no paradigma testware É evidente o benefício da lógica de prevenção de erros em detrimento da lógica de controlo de erros: Time-To-Market reduzido e por inerência menor custo e maior satisfação do cliente. A Norma ANSI/IEEE para documentação de testes de software (IEEE, 2008) define plano de testes como: Um documento que define o âmbito, abordagem, recursos e escalonamento (planeamento) das actividades de teste previstas. Identifica itens de teste, as funcionalidades a serem testadas, as tarefas de teste, quem executará cada tarefa, e quaisquer riscos que requeiram planos de contingência [PJMG quality, 221]

256 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Na Tabela 8.6 é apresentada uma estrutura do plano de testes. Plano de testes Item Identificador do plano de testes Introdução Itens de teste Características a serem testadas Características que não são testadas Abordagem ou plano de acção Critério de aceitação e rejeição dos testes (sucesso /insucesso) Critério de suspensão e retoma de testes Produtos ou documentos Descrição Nome ou número único que identifica o projecto. Descrição do objecto do plano de testes. Inclui referências a todas as normas e documentos relevantes utilizados na definição da estratégia seguida. Lista de todos os componentes do programa (função, módulo, classe, método, menu, ecrã, relatório, etc) que vão ser testados, incluindo os documentos de referência. Caso seja necessário também se pode incluir na lista, o que não vai ser testado. Identifica todas as características e combinações que serão testadas (deve referenciar as especificações do desenho do teste). Identifica todas as características e combinações que não serão testadas e qual o motivo. Para cada característica ou conjunto, deve ser descrito qual a estratégia que assegura que as mesmas serão adequadamente testadas. Devem ser especificadas as actividades principais, técnicas, ferramentas a utilizar. Referencia as restrições, nomeadamente prazos e recursos. Descreve quais os critérios que serão utilizados para determinar se cada item de teste passou ou falhou. Descreve quais os critérios que serão utilizados para suspender e retomar o teste. Identifica quais os documentos que vão ser produzidos como resultado da actividade de testes e respectivo resultado. [PJMG quality, 222]

257 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Descreve a lista de tarefas necessárias à preparação e execução dos testes: Actividades de teste Dependências entre tarefas; Responsáveis; Esforço necessário à realização da tarefa; Quando é realizada. Ambiente requerido Descreve quais os requisitos de software, hardware e outros para o ambiente de testes. Responsabilidades Descreve os grupos responsáveis pela gestão, preparação, execução, verificação e solução de problemas dos testes. Recursos humanos e formação Escalonamento (cronograma) Riscos e contingências Descreve as necessidades de formação para habilitar os recursos envolvidos no processo. Lista de datas, recursos humanos e materiais; cronograma da actividade de teste. Identifica os riscos do plano de testes e o plano de contingência (o que pode correr mal e respectivas acções de resposta). Aprovação Identifica os nomes e respectivas funções de todas as pessoas que precisam de aprovar o plano. Tabela 8.6: Estrutura do plano de testes baseado na Norma IEEE.829 O plano da qualidade possibilita de forma adequada e facilitada, localizar no tempo e através do tempo, o conjunto de actividades relevantes para a qualidade, cuja execução é possível prever, e que, de forma geral, devem acontecer num determinado período. De seguida é apresentada a Tabela 8.7 que ilustra uma estrutura do plano de qualidade. [PJMG quality, 223]

258 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Plano de qualidade Item Descrição Estratégias Normas Documentação produzida Pontos de controlo Auditorias de qualidade Plano de testes Execução de uma especificação de requisitos detalhada, que complementa os elementos fornecidos no documento requisitos de sistema. Identificação e documentação dos critérios e normas dos requisitos de qualidade a adoptar. Conjunto de documentos que serão produzidos (preferencialmente devem estar definidos modelos/templates para os documentos indicando o seu conteúdo). Definição dos pontos de controlo e respectivos objectivos para acompanhamento do projecto. Planeamento da revisão das entregas e respectivo trabalho de acompanhamento. As auditorias incluem a revisão dos processos utilizados para criar as entregas do projecto. Fornecem informação imparcial sobre se estão a ser utilizados e seguidos os processos de trabalho definidos previamente. Define o âmbito, abordagem, recursos e planeamento das actividades de teste previstas. Identifica itens de teste e as funcionalidades a serem testadas. Tabela 8.7: Estrutura do plano de qualidade PL.04 Definição do plano de métricas A definição do plano de métricas, entendido como um conjunto integrado de actividades, consiste em definir os elementos e regras que permitem medir a qualidade do projecto de acordo com os objectivos definidos. [PJMG quality, 224]

259 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Há bastante tempo que têm vindo a ser propostas métricas e modelos nelas baseados. Alguns estudos detalhados (A. Consortium, 1991; P. Consortium, 1991; Grady & Caswell, 1987) indicam que a implementação de um programa de métricas ajuda na obtenção de melhores resultados do ponto de vista da gestão, quer no curto prazo (para um dado projecto) quer no longo prazo (projectos futuros) melhorando a estimativa, a produtividade e a qualidade (F. B. Abreu, 1992) Com efeito, um número cada vez maior de organizações tem vindo a obter resultados promissores com a implementação de programas de métricas. Estes indicadores positivos têm alertado a comunidade de gestores de projectos, pelo que se espera que, a médio prazo, também nas empresas com projectos de menor dimensão (como ocorre no tecido empresarial português desta área) sejam colhidos futuramente benefícios idênticos. Um plano de métricas deve descrever quem, o quê, onde, quando, como e o porquê de métricas. Com respostas a todas estas perguntas quem lê o plano sabe exactamente porque é que as métricas são recolhidas, como são usadas e analisadas (Pfleeger, 1995). O plano deve prever onde e quando, o processo de recolha será realizado. Alguns dados precisam de ser recolhidos regularmente, outros podem só ser recolhidos uma vez durante todo o processo. O tempo e a frequência de recolha de dados estão relacionados com os objectivos e aspectos críticos do projecto e estas relações devem estar explicitadas no plano. Para um plano de métricas ser claro dever conter a seguinte informação: Quem é responsável pela recolha de dados; Quando são recolhidos os dados e com que frequência; Onde, ou em que processo, são recolhidos; Como serão recolhidos os dados. Métricas e a respectiva análise são muito importantes na gestão da qualidade bem como para atingir a satisfação do cliente (Issac, Rajendran, & Anantharaman, 2006). Medições eficazes de desempenho e resultados influenciam a eficácia da gestão (Kanji & Sá, 2002). Métricas são elementos de medida que são usadas para obter um controlo eficaz sobre os processos e objectivos a atingir e permitem melhorar o desempenho organizacional. Permitem que o gestor de projecto monitorize as actividades e proponha alterações ao longo do ciclo de vida do desenvolvimento de software caso se revele necessário. Não existem [PJMG quality, 225]

260 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE actualmente medidas de qualidade de software universalmente aceites (ISO , Sec 6.4.1). A Norma ISO , que é um framework das normas de qualidade de desenvolvimento de software sugere a medição de qualidade e, ao mesmo tempo, admite que não existem standards para medidas de qualidade de software. Para uma boa utilização de métricas, um ponto fundamental é a escolha do conjunto de medidas a serem recolhidas. Devem efectivamente trazer informações que permitam a reflexão e decisão sobre o que está a ser avaliado. Métricas que exijam muito esforço para sua obtenção devem ser evitadas. Esta actividade tem por objectivo a definição dos elementos e regras que medem a qualidade do projecto. Devem ser definidos os objectivos e que processos serão considerados no modelo de garantia de qualidade. Na Figura 8.3 é apresentado de forma esquemática o processo de definição de métricas. Figura 8.3: Esquema do processo de definição de métricas A definição de métricas passa sempre pela identificação dos objectivos específicos para o projecto e pela identificação dos aspectos críticos, respeitando o modelo de garantia de qualidade. A definição dos atributos é efectuada com base nos objectivos identificados para o projecto, nos aspectos críticos que foram identificados e tendo em conta os critérios definidos no âmbito da qualidade. Neste plano apresentamos os exemplos seguintes de propostas de métricas: [PJMG quality, 226]

261 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE PL Um critério definido para a garantia de qualidade é a diminuição de nãoconformidades. Para este objectivo poderão ser definidas as seguintes métricas: Resolução em termos de prioridade das não conformidades; Tempo de fecho; Tempo de resolução. PL Análise do tempo utilizado na aprovação e implementação de alterações. Para este objectivo poderão ser definidas as seguintes métricas: Quantidade de alterações implementadas por período, elementos de configuração, tipo, serviço; Quantidade de alterações supervisionadas por prazo; Percentagem (total e detalhada por classificação) de alterações implementadas sem êxito; Tempo médio de resolução, ou derivação; Percentagem de ocorrências fechadas. PL Verificação e validação de requisitos. Para este objectivo poderão ser definidas as métricas que estão descritas na Tabela 8.8. Definição de Métricas Objectivos Atributos Métricas Diminuição das não conformidades Análise do tempo utilizado na aprovação e implementação de alterações Indicadores de desempenho. Indicadores de duração Indicadores de quantidade Resolução em termos de prioridade Tempo de resolução Tempo de fecho Tempo médio de resolução Tempo médio de fecho Nº de alterações por período Nº de alterações supervisionadas Percentagem de alterações implementadas sem êxito Percentagem de ocorrências fechadas [PJMG quality, 227]

262 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Verificar se um determinado módulo preenche os requisitos estabelecidos durante a fase de análise Validação de requisitos Taxa de validação de requisitos Nº requisitos validados/total de requisitos Taxa de alteração de requisitos Nº alterações aceites/total de requisitos Tabela 8.8: Métricas definidas para o objectivo indicado no item três Na Figura 8.4 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. Figura 8.4: Artefactos utilizados e produzidos para realização da actividade Definição do plano de métricas PL.05 Elaboração do plano de aceitação do cliente O plano de aceitação do cliente é o garante da aceitação correcta do projecto e componentes respectivas por parte do cliente. Este plano tem por objectivo definir de forma clara e inequívoca todo o processo de aceitação do projecto pelo cliente e garantir a correcta aceitação das soluções. Descreve como o cliente irá avaliar os artefactos produzidos para determinar se atendem a um conjunto predefinido de critérios de aceitação. O plano de aceitação cria um consenso entre o cliente e o timing definido para o projecto sobre como determinar a aceitação da solução. Este processo deve ser definido de forma faseada. Os critérios de aceitação são descritos e detalhados neste documento e são identificadas as respectivas tarefas que compõem a aceitação. O plano de aceitação deve ser composto pela seguinte informação: [PJMG quality, 228]

263 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Definição de todos os entregáveis (deliverables) do projecto e respectivo plano de entrega ao cliente (delivery management); Referência de todos os produtos a validar e a aceitar pelo cliente (exemplos: caderno de especificação de requisitos, plano de testes, plano de formação, suporte ao arranque em produção, manutenção evolutiva); Descrição do processo de aceitação de cada produto ou entregável; Calendarização respectiva de cada validação por parte do cliente. Na Figura 8.5 são enumerados os artefactos necessários para a realização da actividade Elaboração do plano de aceitação do cliente e os artefactos produzidos. Figura 8.5: Artefactos utilizados e produzidos para realização da actividade Elaboração do plano de aceitação do cliente É construída uma matriz com a documentação/produtos gerados e respectivos responsáveis pela sua aprovação e quem participa na sua execução. A Tabela 8.9 ilustra um exemplo da definição de produtos gerados e respectivos responsáveis pela sua realização. Função associada à Entidade Cliente Documentação/ Produto Director de projecto Chefe de projecto Consultor área negócio Consultor financeiro Consultor comercial Caderno de especificação de requisitos A A P, A P Casos de teste A E [PJMG quality, 229]

264 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Acta da reunião de steering Actas de reuniões de acompanhamento A, P P P P P A, P Actas de reuniões de análise A A, P Legenda: A = Aprova; E=Executa; P=Participa Tabela 8.9: Exemplo de uma matriz de produtos gerados versus responsáveis PL.06 Elaboração do plano de envolvimento do cliente O plano de envolvimento do cliente consiste na definição das tarefas e decisões da responsabilidade do cliente ao longo do projecto. O plano de envolvimento do cliente e o plano de aceitação do cliente complementam-se. O plano de envolvimento deve ser definido de forma integrada com o plano de aceitação do cliente. Esta actividade tem também por objectivo garantir o alinhamento do cliente com o acordado inicialmente. Permite com maior rigor efectuar a gestão de expectativas. Os requisitos do cliente, incluindo os relacionados com o cumprimento de disposições legais aplicáveis à sua actividade, são determinados e atendidos com o propósito de aumentar a sua satisfação. O plano de envolvimento do cliente tem por objectivo principal o comprometimento do cliente nas opções e decisões tomadas para o desenvolvimento do projecto. São descritas as actividades e responsabilidades do cliente que são enumeradas em seguida: São identificadas as actividades em que o cliente deve participar; É descrito o processo de participação; O cliente tem também por responsabilidades: Validação dos requisitos de qualidade do projecto; Validação do plano de testes; [PJMG quality, 230]

265 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Validação dos documentos produzidos na fase de análise. É sempre aconselhável que o cliente participe nas diferentes fases de desenvolvimento do produto. Este envolvimento permitirá obter o feedback do cliente ao longo de todo o ciclo, de modo a chegar ao fim com um produto que responda cabalmente às suas necessidades. Além disso, este envolvimento permite uma gestão de tempo e de custo mais eficientes, dado que se conseguem diminuir significativamente ou mesmo eliminar as repetições de trabalho já realizado por rejeição do lado do cliente. Deve ser construída uma matriz de actividades e respectivos responsáveis pela sua aprovação e quem participa na sua execução, conforme ilustrado na Tabela Funções associadas à Entidade Cliente Actividades Director de projecto Chefe de projecto Consultor área negócio Consultor financeiro Consultor comercial Reunião de arranque Reuniões de acompanhamento P P P P P P P P Reuniões de análise P P Validação do Caderno de especificação de requisitos A A, P Validação da documentação produzida A A, P Validação dos requisitos de qualidade A A, P Validação do plano de testes A Aprovação do Caderno de especificação de requisitos A A, P Aprovação do plano de testes A A, P [PJMG quality, 231]

266 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Validação do plano de aceitação Aprovação do plano de aceitação A A A, P A, P Aprovação do plano de formação A A A, P Aprovação do plano de suporte ao A A A, P arranque do projecto Legenda: A = Aprova; P = Participa Tabela 8.10: Exemplo de uma matriz de actividades versus entidades responsáveis Na Figura 8.6 são enumerados os artefactos necessários para a realização da actividade e os artefactos produzidos. Figura 8.6: Artefactos utilizados e produzidos para realização da actividade Elaboração do plano de envolvimento do cliente PL.07 Reunião de Kick-off Reunião formal de arranque do projecto. Certifica que todos têm a plena noção e compreensão dos papéis, funções e responsabilidades, ao longo do projecto. A reunião de kick-off ou de arranque do projecto é um dos elementos mais críticos da fase do planeamento, é a reunião em que todos os envolvidos (membros da equipa, gestores de projecto, fornecedores, cliente) devem participar. É uma reunião formal e, como tal, a agenda da reunião de kick-off deve ser elaborada e compartilhada antecipadamente, com todas as partes interessadas do projecto. Fornece o esboço do que acontecerá na reunião de kick-off. [PJMG quality, 232]

267 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE A reunião de kick-off deve fornecer uma visão geral do projecto. Um esboço para uma reunião de kick-off pode também incluir várias actividades iniciais do planeamento. Esta reunião tem um papel muito importante no arranque do projecto e na forma como o cliente irá ser envolvido em todo o processo. Como tal deve ser planeada atempadamente e preparada de forma cuidada. Devem ser definidos e planeados os itens a abordar e a detalhar na reunião. O gestor do projecto deve estar bem preparado e deve certificar-se se a estratégia delineada para a reunião tem a concordância da gestão de topo. Tem como finalidades principais apresentar o projecto e notificar formalmente todos os stakeholders do arranque do projecto. Certifica também que todos os envolvidos têm as suas funções (papéis) e responsabilidades definidas e clarificadas. A duração deve ser aproximadamente entre uma a duas horas. As reuniões poderão ser mais extensas, e são especialmente importantes se o projecto for muito complexo ou controverso. Há um número de itens específicos que devem ser abordados e detalhados na reunião: Detalhar a informação do projecto: Objectivos do projecto; Âmbito do projecto; Aspectos críticos; Principais riscos do projecto; Responsabilidades de cada um dos stakeholders; Cronograma inicial com os marcos principais (milestones). O plano de envolvimento e o plano de aceitação devem ser validados e aprovados pelo cliente. Deve ser elaborada a acta da reunião e será efectuado por escrito o compromisso formal de todos os envolvidos no projecto. A acta deve também contemplar os pontos de discordância dos elementos, caso existam, e as soluções propostas ou acordadas para os ultrapassar. Na Tabela 8.11 é apresentado um resumo da reunião de kick-off. [PJMG quality, 233]

268 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Tabela resumo da reunião de kick-off A comunicação é crítica para o sucesso de qualquer projecto e a reunião de arranque é um excelente método de comunicação. Objectivos Participantes Formato Tópicos Marcar formalmente o arranque do projecto; Apresentar uma visão partilhada do projecto; Estabelecer um compromisso entre todos os envolvidos no projecto; Estabelecer as expectativas do projecto. Equipa de projecto; Stakeholders. Primeira parte baseada numa apresentação; Segunda parte da reunião deve permitir discutir alguns dos tópicos apresentados. Organização da equipa; Objectivos e âmbito do projecto; Calendarização, actividades principais e milestones: Responsabilidades dos intervenientes; Principais desafios. Tabela 8.11: Apresentação de um resumo da reunião de kick-off PL.08 Definição do plano de gestão de alterações Definir os processos e as ferramentas que serão utilizados para planear, executar e acompanhar as alterações relacionadas com o projecto de desenvolvimento de software. A proposta do plano de alterações é o garante da integridade original dos objectivos do projecto e reitera a necessidade de qualquer modificação nesses objectivos ser avaliada correctamente. As alterações são um dos factores que podem comprometer a qualidade num projecto uma vez que vão alterar as especificações inicialmente aprovadas. O gestor do projecto e a equipa do projecto devem perceber que alterações ao âmbito são uma ocorrência normal durante um projecto e não são sinais de problemas que devem ser evitados a todo o custo. De facto, em alguns casos, é algo positivo. Em primeiro lugar, o cliente não consegue normalmente identificar todos os requisitos e funcionalidades que são necessárias para a solução [PJMG quality, 234]

269 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE final. Em segundo lugar, a realidade do negócio muda ao longo do tempo, e como tal os requisitos do projecto também podem mudar. As alterações existem e como tal devem ser submetidas a um processo de gestão de alterações. Esse processo deve detalhar a especificação da alteração em causa, identificar os benefícios que justificam a submissão da alteração e deve ser avaliado o seu impacto nos requisitos do projecto, no orçamento e nos prazos. Se não conseguirmos incluir a mudança, a solução final poderá não corresponder às expectativas ou pode mesmo tornar-se inutilizável. Por isso, o cliente deve ter a possibilidade de propor alterações durante o projecto quando assim se justifique. O problema surge quando o gestor do projecto não consegue gerir de forma pro-activa os pedidos de alteração que eventualmente surjam. Num projecto deve ser efectuado um plano que descreva o processo que permita gerir eficazmente as alterações. O processo deve identificar a alteração, determinar o seu valor, determinar o impacto no projecto. A informação resultante será avaliada pelo responsável ou director de projecto. Este pode determinar se a alteração deve ser incluída e, caso afirmativo, deve entender qual o impacto no projecto e obter o orçamento e prazo adicionais necessários para incluir a alteração no projecto. O objectivo desta actividade é produzir um plano que documente os processos e ferramentas que são utilizados para planear, executar e acompanhar as alterações relacionadas com o projecto. As alterações podem ser pedidas pelo cliente ou podem surgir internamente. Podem também ser detectadas nas reuniões de acompanhamento ou progresso. As alterações devem ser agrupadas por motivo (de acordo com a razão que as originou), para resolver determinado problema ou falha, ou para implementar uma melhoria. Sempre que surge uma alteração deve ser identificada a razão porque se pretende efectuar essa alteração. Os pedidos de alteração devem ser tratados como novas actividades ou tarefas. Uma actividade pode constituir a resolução de uma falha, um pedido de melhoria, ou simplesmente uma descrição de uma linha da alteração, que deve ser efectuada dependendo do grau de rigor necessário para o processo de acompanhamento de alterações e de defeitos. Este tipo de abordagem deve suportar todos estes tipos de actividades e quaisquer outros que seja necessário definir. [PJMG quality, 235]

270 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE A principal vantagem da gestão das alterações, baseada em actividades, reside no facto de nenhuma alteração poder ser efectuada sem um motivo associado e sem ser previamente analisada. Outra vantagem consiste nas alterações serem integradas e consistentes. Na maior parte dos casos, quando é efectuada uma alteração, é necessário proceder a diversas alterações em diferentes ficheiros ou componentes. Uma outra vantagem reside no facto de evitar o descontrolo do âmbito. A maioria dos gestores reconhece grandes alterações do âmbito mas são menos diligentes com as pequenas alterações. Existe a tendência de incorporar o trabalho adicional das pequenas alterações sem muita reflexão ou análise preliminar. O descontrolo do âmbito acontece quando são aceites um grande número de pequenas alterações. A equipa ao efectuar as pequenas alterações apercebe-se, nessa altura, que vão suportar demasiado trabalho não previsto inicialmente, e como consequência não é possível garantir o orçamento e prazos acordados. Os membros da equipa interagem de uma forma directa com o cliente, como tal recebem com mais frequência os pedidos de alteração. Por este motivo, toda a equipa deve compreender a importância da gestão de alterações, devem proceder conforme o descrito no plano de alterações e reencaminhar os pedidos para o gestor de projecto. Não devem assumir trabalho extra ou implementarem alterações sem seguir o procedimento descrito, porque é provável que outras actividades ou tarefas planeadas terminem com atraso o que pode por em risco todo o projecto. De seguida é apresentada a Tabela 8.12 que ilustra uma estrutura do plano de gestão de alterações. Plano de gestão de alterações Item Descrição Tem por objectivo registar os pedidos que os utilizadores apresentam para efectuar uma alteração ou necessidade de uma melhoria. Registo do pedido A informação deste registo é determinada em conformidade com as normas ou standards existentes na organização para a recepção de pedidos de alteração. Para pedidos de melhoria, deve-se enviar uma especificação dos requisitos a contemplar. [PJMG quality, 236]

271 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Em qualquer caso, será imprescindível abranger a identificação, origem e tipo de pedido, atribuir uma prioridade inicial e incorporar uma descrição, a mais exacta possível, que facilite a sua análise posterior. Análise de motivo de pedido Análise de impacto da alteração Aprovação do pedido Aceitação pelo cliente Reformulação do plano de trabalho É efectuada uma análise de impacto nas vertentes do âmbito, do tempo e do custo de acordo com o definido no plano de projecto. É efectuada uma análise de impacto nas vertentes do âmbito, do tempo e do custo de acordo com o definido no plano de projecto. Com base na análise efectuada, é decidida a aprovação ou reprovação do pedido. É efectuada a aceitação pelo cliente seguindo o processo definido no plano de aceitação. É reformulado o plano de trabalho de forma a incluir a alteração (ajustar o plano de forma a incluir as alterações necessárias e respectivos testes). É elaborada documentação específica para o efeito. Tabela 8.12: Proposta da estrutura para o plano de gestão de alterações Na Figura 8.7 são enumerados os artefactos necessários para a realização da actividade e os artefactos produzidos. Figura 8.7: Artefactos utilizados e produzidos para realização da actividade Definição do plano de gestão de alterações [PJMG quality, 237]

272 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE PL.09 Elaboração do plano de progresso O plano de progresso tem por objectivo definir e clarificar como será efectuado o acompanhamentodo projecto e define os procedimentos de controlo que sustentam a monitorização da evolução do projecto. O progresso do projecto deve ser monitorizado regularmente e ciclicamente. O plano de progresso tem por objectivo definir e clarificar como será efectuado o acompanhamento e a monitorização da evolução do projecto. Descreve os procedimentos de controlo que vão sustentar a monitorização do projecto. É fundamental acompanhar e monitorizar de que forma o plano de projecto está a ser seguido. São planeados os pontos de controlo (checkpoints) para o projecto. Nestes checkpoints são efectuadas as seguintes actividades: Recolha de trabalho efectivo e respectiva informação de desempenho; Recolha das estimativas mais recentes para completar as tarefas em execução; Comparação do desempenho actual com o plano; Determinação das causas do desvio; Promove replaneamento; Identificação das situações de tolerância; Envolve todos os intervenientes. Os checkpoints são efectuados ao longo de todo o projecto, normalmente em intervalos semanais e fornecem um mecanismo de monitorização e controlo do trabalho e desempenho diário em relação ao projecto. A informação sobre o desempenho é obtida, e os planos são actualizados antes das reuniões de controlo do projecto. Isto permite que a reunião se concentre em determinar o que fazer a seguir. A descrição dos processos de controlo inclui a definição dos níveis de tolerância para o desempenho do projecto. Quando esses níveis definidos são ultrapassados, o gestor de projecto deve proceder ao plano de acções definido para situações de excepção, para repor o controlo do projecto. No documento correspondente ao plano deve constar: [PJMG quality, 238]

273 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Planeamento das reuniões para reportar o progresso do projecto e identificar respectivos desvios; Periodicidade das mesmas; Planeamento das actividades de gestão para controlo do progresso; Planeamento de revisões; Planeamento de revisões de progresso da equipa; Planeamento de revisões de progresso do projecto; Planeamento de reuniões de steering commitee 12 onde é revisto o relatório de progresso. Na Figura 8.8 são enumerados os artefactos utilizados para a realização da actividade e os artefactos produzidos pela sua execução. Figura 8.8: Artefactos utilizados e produzidos para realização da actividade Elaboração do plano de progresso Fase de execução Durante esta fase, o foco incide sobre a execução do projecto em consonância com o definido na fase de planeamento. No entanto, são muitas as actividades de gestão de projectos que precisam de ser efectuados para além de trabalho do projecto em si: Controlar o progresso do projecto; Controlar a qualidade dos entregáveis do projecto; Controlar o processo de alterações de acordo com o plano de gestão de alterações; 12 Reuniões de acompanhamento. [PJMG quality, 239]

274 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Resolução de problemas que surjam durante esta fase de execução; Controlar as expectativas do cliente; Controlar o progresso do trabalho da equipa de projecto; Gestão do âmbito, qualidade, custo e cronograma das actividades desta fase para atender ou exceder as expectativas do cliente; Comparar o progresso da execução dos planos, identificar desvios, e ajustar para corrigir os desvios significativos; Antecipar possíveis riscos para o projecto e medidas preventivas para evitá-los; Assegurar a integridade dos resultados da fase e que as alterações que eventualmente ocorram são coerentes com os objectivos do projecto; Eficiência na resolução de questões e problemas que são identificados, identificar as causas e aplicar acções correctivas; Dirigir a equipa de forma próxima e directa para conseguir um ambiente de trabalho gratificante e eficiente. Muitas destas actividades são planeadas para o projecto durante a fase de planeamento. Contudo, é durante esta fase que a sua execução correcta é assegurada. São efectuadas as actividades de monitorização e acompanhamento do projecto. A Tabela 8.13 lista as actividades executadas nesta fase e os respectivos deliverables principais (produtos ou documentos) produzidos durante a fase de execução. ID Actividade Deliverable principal EX.01 Recolher, analisar e registar dados para métricas do projecto. Registo de métricas EX.02 Recolher, analisar e tratar pedidos de alteração. Pedidos de alteração EX.03 Auditar o projecto de acordo com o plano de qualidade Relatório de auditoria [PJMG quality, 240]

275 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE EX.04 Gestão de reclamações Pedidos de reclamação EX.05 Gestão de não conformidades Fichas de não conformidades EX.06 Reuniões de contolo de progresso Actas das reuniões EX.07 Controlo do plano de aceitação com o cliente Documentação de aceitação EX.08 Produção de relatórios de progresso interno Relatório de progresso EX.09 Produção de relatórios para Relatório de acompanhamento o cliente para o cliente EX.10 Gestão de entregáveis Entregáveis EX.11 Controlo de qualidade Relatórios de auditoria Tabela 8.13: Lista de actividades executadas na fase de planeamento e respectivos deliverables produzidos EX.01 Recolher, analisar e registar dados para as métricas do projecto Recolher elementos para a construção das métricas de acordo com os objectivos definidos no plano de qualidade. O processo de recolha de dados para a análise das métricas (Metrics Analysis) deve ser efectuado de acordo com os objectivos definidos no plano de métricas. Embora as métricas não sejam a panaceia para todos os males no processo de desenvolvimento de software, quando utilizadas em conjunção com outras actividades, tais como um recrutamento cuidadoso dos elementos das equipas de desenvolvimento e de controlo de qualidade, formação adequada e atempada, a sua utilização tem sido apontada como um factor catalisador da qualidade e produtividade (F. B. Abreu, 1992). [PJMG quality, 241]

276 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE A este propósito transcreve-se um trecho da norma ISO (ISO, 1991) integrado na secção 6 - "Sistema de Qualidade - Actividades de Suporte", dedicado às métricas: "6.4.1 Medição do produto Deverão ser divulgadas e utilizadas métricas relevantes do produto de software em particular, para gerir os processos de desenvolvimento e de entrega (aos clientes finais). Actualmente não existem medidas da qualidade do software universalmente aceites. Contudo deverão ser utilizadas, pelo menos, algumas métricas que traduzam as falhas e/ou defeitos do ponto de vista do cliente. As métricas seleccionadas deverão ser descritas de forma a que os resultados sejam comparáveis. O produtor de produtos de software deverá recolher e agir com base nas medidas de qualidade desses produtos. Essas medidas deverão ser utilizadas com as seguintes finalidades: a) para recolher dados e divulgar valores das métricas numa base regular; b) para identificar o nível de desempenho baseado em cada métrica; c) para levar uma acção correctiva se os níveis da métrica piorarem ou se excederem os níveis de objectivo definidos; d) para estabelecer objectivos de melhoria em termos das métricas Medição do processo O fornecedor deverá obter medidas quantitativas da qualidade dos processos de desenvolvimento e de entrega. Essas métricas deverão reflectir: a) quão bem está a ser levado a cabo o processo de desenvolvimento em termos de cumprimento atempado de marcos e objectivos; b) quão efectivo é o processo de desenvolvimento na redução das probabilidades de inserção de defeitos no software e de não detecção de defeitos existentes. Tal como nas métricas de produto, o que interessa é que sejam utilizadas no controlo e melhoria do processo de desenvolvimento e não quais as métricas específicas que são utilizadas. A escolha das métricas deverá enquadrar-se no processo adoptado e, se possível, ter um impacto directo na qualidade do software produzido. Para diferentes produtos do mesmo produtor poderão ser apropriadas diferentes métricas." [PJMG quality, 242]

277 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE O processo de recolha e análise de métricas pode ser efectuado com base em checklists. Na técnica de leitura baseada em checklists, é utilizada uma lista para a leitura e análise das métricas. Esta lista deve relacionar os itens a serem verificados e o que deve ser entendido como defeito ou não conformidade. A recolha de métricas é um dos processos mais sofisticados da gestão de processos, podendo tornar-se bastante complexo e difícil. Esta característica devese ao facto de termos uma grande dificuldade em definir e recolher métricas. E é justamente por essa dificuldade que na maioria das vezes elas são ignoradas. A Figura 8.9 ilustra os procedimentos necessários para a execução desta actividade. Figura 8.9: Acções necessárias à recolha, análise e registo de métricas [PJMG quality, 243]

278 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE EX.02 Recolher, analisar e efectuar a gestão de pedidos de alteração Efectuar a análise dos pedidos de alteração com base na definição de processos que consta no plano de qualidade. Efectuar a classificação dos pedidos de acordo com o plano de alterações. Para se efectuar a avaliação devida de um pedido de alteração é necessário que o registo do pedido respectivo seja efectuado de forma completa, clara e não ambígua (Miguel, 2006). Para cada actividade que surge é efectuado o respectivo registo e analisado o motivo. EX Registo e análise do pedido: No registo do pedido deve constar a seguinte informação: Análise do impacto da alteração de acordo com o que está definido no âmbito do projecto (impacto no âmbito); Identificação do impacto financeiro; Identificação do impacto temporal; Análise do motivo do pedido; Aprovação do pedido em sede de steering; Após aprovação é delineado o plano de acção de acordo com o especificado no plano de gestão de alterações. EX Acompanhamento e controlo do pedido: Efectua-se o acompanhamento do plano de acção em conformidade com os pontos de controlo estabelecidos na actividade anterior. Realiza-se o acompanhamento das alterações necessárias nos componentes de cada subsistema envolvido, seguindo as actividades identificadas no plano de acção. Efectua-se o controlo da planificação estabelecida, que abrange os seguintes aspectos: Efectuar o registo das alterações que o pedido motivou ao longo dos processos de desenvolvimento envolvidos; [PJMG quality, 244]

279 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Verificar se os testes unitários, de integração e de sistema, que foram considerados necessários para os componentes a modificar, foram realizados; Verificar se apenas o estabelecido e descrito foi modificado e, no caso contrário, justificar o motivo; Assegurar que foram efectuadas as actualizações respectivas; Efectuar o controlo dos diversos desenvolvimentos existentes em paralelo sobre um mesmo componente, no intuito de coordenar as modificações incluídas em cada um destes, e assegurar que, na passagem à fase de produção, serão implantados correctamente. EX Aprovação e Fecho do Pedido: A conclusão ou fecho do pedido é formalmente aprovada em conformidade com os resultados obtidos na tarefa ou fase especificada anteriormente. É efectuado o registo formal do fecho do pedido. É conveniente registar dados quantitativos relativos ao tempo utilizado na análise do pedido, no estudo do impacto, resolução da alteração, recursos utilizados. O registo deste tipo de informação proporciona uma base quantitativa sobre a qual se podem tomar decisões relativas à eficácia das técnicas e procedimentos utilizados, e viabiliza a possibilidade de maior eficácia no desempenho da gestão de alterações. Na Figura 8.10 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. Figura 8.10: Artefactos utilizados e produzidos para realização da actividade Gestão de pedidos de alteração [PJMG quality, 245]

280 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE EX.03 Auditar o projecto de acordo com o plano de qualidade Efectuar auditorias em função dos checkpoints principais do projecto, definidos no plano de qualidade. A realização de auditorias tem por objectivo a avaliação do cumprimento dos requisitos do projecto. O que se pretende objectivamente é validar no terreno se o produto ou serviço em produção está de acordo com os requisitos definidos e acordados com o cliente. A validação e controlo do plano estabelecido são focados nos seguintes aspectos: Determinar a conformidade dos elementos do sistema com os requisitos especificados; Promover melhorias no sistema; Satisfazer exigências regulamentares; Avaliar eficácia do sistema de gestão de qualidade; Verificar se o sistema de gestão cumpre eficazmente a política e os objectivos definidos pela organização. As auditorias internas devem ser programadas em função da natureza e da importância da actividade a auditar e de acordo com o definido no plano de qualidade. São planeadas em função dos checkpoints 13 principais do projecto. Devem ser conduzidas por pessoas independentes daquelas que tenham responsabilidade directa nas actividades a auditar. Os resultados das auditorias devem ser registados e levados ao conhecimento dos responsáveis da área auditada. Os responsáveis dessa área devem desenvolver atempadamente as acções correctivas relativamente às deficiências detectadas na auditoria. As actividades de seguimento das auditorias devem englobar a verificação e o registo da implementação e da eficácia das acções correctivas tomadas. Nas auditorias devem existir os seguintes vectores de análise: Auditar o projecto numa determinada vertente; Auditar o processo de gestão de risco. 13 Pontos de controlo [PJMG quality, 246]

281 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE As etapas principais de uma auditoria consistem em: Preparação da auditoria; Execução ou realização da auditoria; Elaboração do relatório com os resultados e as conclusões da auditoria. O planeamento ou preparação de cada auditoria é composto por: Definição do âmbito e data da auditoria; Junção de resultados de reuniões internas realizadas previamente; Definição de checklist específica para a auditoria; Definição da vertente da auditoria. A realização de auditorias deve ser guiada por checklists de verificação. Na técnica baseada em checklists, já consolidada na indústria, é utilizada uma lista para a leitura e análise de artefactos. Esta lista relaciona os itens a serem verificados e o que deve ser entendido como não conformidade. Para cada tipo de artefato há uma lista específica (Caderno de Especificação de Requisitos, Cenários, Plano de Testes, Casos de Teste, Código, entre outros). A utilização de checklists, permite: Documentar que todos os aspectos relativos ao plano da auditoria são verificados; Fornecer a base para a reunião e para o relatório da auditoria; Fornecer a evidência objectiva de que a auditoria foi realizada. De forma a uniformizar as checklists a utilizar deve ser definido um modelo. Apresenta-se de seguida a descrição de um modelo com uma estrutura exemplo para checklists: Uma secção com a identificação da mesma, onde devem constar, a designação da checklist, o código, o âmbito, o autor, a data, a versão, o responsável pela aprovação e os documentos relacionados; Outra secção que deve ter o nome do documento/produto a auditar, o código e a versão deste, o elemento ou módulo a que este pertence, e o conjunto de itens a avaliar. [PJMG quality, 247]

282 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Deve ser produzido um relatório da auditoria que permite conhecer o controlo de qualidade efectuado e as respectivas métricas utilizadas durante a fase de execução. O relatório de auditoria consiste num documento a ser preenchido no final da auditoria interna, referindo as conformidades e não conformidades do Sistema da Qualidade. Em primeiro lugar o relatório deve ter uma secção informativa, com a seguinte informação: a área auditada, a data da realização, a versão, o(s) departamento(s) envolvido(s), pessoas contactadas, o responsável pela elaboração do relatório e o responsável pela aprovação. Deve ter uma secção onde se especificam os resultados da auditoria e as deficiências encontradas, e uma outra secção onde se descrevem as acções de melhoria propostas. Na Figura 8.11 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. Figura 8.11: Artefactos utilizados e produzidos para realização da actividade Auditar o projecto de acordo com o plano de qualidade EX.04 Gestão de reclamações Consiste na identificação e classificação de reclamações e aplicação de acções para a sua resolução de acordo com o plano de gestão de reclamações. Ao longo da construção do projecto e das sucessivas entregas ao cliente, podem surgir reclamações. Se não forem traçadas estratégias de gestão de reclamações que façam com que as mesmas sejam resolvidas, a satisfação do cliente pode diminuir, o que conduz a uma qualidade mais baixa do projecto. Segundo Ahmed e Kangari, a forma como a equipa do projecto responde às reclamações é um dos seis factores que mais contribuem para a satisfação do cliente (Ahmed & Kangari, 1995; Yang & Peng, 2008). Em primeiro lugar é [PJMG quality, 248]

283 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE necessário conseguir identificar, analisar e classificar as reclamações para se perceber se são urgentes e se dão ou não origem a uma alteração. A integração do cliente é mais uma vez bastante relevante para se conseguir perceber a natureza e as razões que conduziram à reclamação. Para saber que regras e acções se devem usar na resolução da reclamação, é necessário perceber se esta se relaciona ou não com o âmbito do projecto pois pode ser necessário reconstruir alguns pontos do plano de projecto. Outro dado importante a registar sobre cada reclamação é o tempo que se tem para responder à mesma. Ao realizar-se a gestão de reclamações deve elaborar-se um relatório de esclarecimento de acordo com o que se definiu no plano de gestão de reclamações. No final do projecto devem ter-se todas as reclamações documentadas e tratadas, ou pelo menos uma percentagem elevada que deve ser inicialmente estipulada pela equipa de gestão de projectos. Existem dois tipos de reclamações a considerar: Reclamações voluntárias; Reclamações automáticas devem ser geradas automaticamente quando é obtido um resultado menor que um dado nível de satisfação de cliente no inquérito de satisfação de cliente. A realização do inquérito de satisfação do cliente deve estar especificada no Plano de Qualidade. Pode ser efectuado segundo um dos modelos: Com uma determinada periodicidade; Uma vez por ano; No final do projecto; Ad-hoc (sem calendarização definida, mediante necessidade). O processo de gestão de reclamações também deve contemplar as normas definidas no plano da qualidade. As reclamações também geram não conformidades. O tratamento das reclamações ou sugestões de forma eficaz tem a finalidade de eliminar falhas e melhorar as suas características e de aumentar a satisfação e a fidelidade dos clientes. Para que se possam tratar as manifestações dos clientes (reclamações voluntárias, sugestões, pedidos, solicitação de informações que chegam à organiza- [PJMG quality, 249]

284 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE ção), é necessária a definição de meios de acesso que representem os canais de relacionamento adequados ao cliente. É importante que os canais escolhidos estejam de acordo com os tipos de cliente (segmentação do mercado e agrupamento dos clientes), e que estes sejam divulgados para se tornarem conhecidos e facilitar a efectiva utilização pelo cliente. Mesmo existindo diversos canais de relacionamento com o cliente, é fundamental a existência de um processo estruturado para tratar e responder de forma rápida e eficaz às reclamações. Esse processo deve incluir a definição de padrões de atendimento e tempo para resposta formal ao cliente. A gestão das reclamações e sugestões inclui a análise das causas e a determinação de prioridades com base no impacto nos custos, no âmbito e nos critérios definidos para a classificação destas ocorrências. Todo o processo pode ser apoiado pela actuação da equipa para a resolução de problemas e, também, por um sistema informatizado que permite o registo e acompanhamento das reclamações e sugestões. É importante que sejam consideradas todas as reclamações e sugestões, incluindo aquelas que são recebidas por meio de contactos informais. O procedimento sugerido consiste na abertura de um indício de nãoconformidade, o qual orientará para a identificação dos factos que geraram a reclamação. Caso a reclamação resulte de deficiências na condução ou orientação dos processos internos, é gerado um registo de não conformidade, e em consequência deve ser criado um plano de acção para corrigir os efeitos gerados pelo problema e para evitar que os mesmos voltem a ocorrer. No caso de sugestão dada pelo cliente, o tratamento é efectuado conforme procedimento de acção preventiva, o qual deve ser encaminhado para avaliação da sugestão e, caso se justifique, de aceitação da mesma. Na Figura 8.12 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. [PJMG quality, 250]

285 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Figura 8.12: Artefactos utilizados e produzidos para realização da actividade Gestão de reclamações EX.05 Gestão de não conformidades Registar as não conformidades detectadas garantindo que todas são analisadas e concluídas. Esta gestão é um ponto-chave para o sucesso final. A gestão de não conformidades é um factor crítico de sucesso do SGQ. Não só é importante registar as não conformidades mas também garantir que todas são analisadas e concluídas. O objectivo é efectuar uma actuação de forma reactiva para evitar a reincidência da não conformidade e, de forma proactiva, para prevenir a ocorrência das mesmas. Com o sistema de garantia de qualidade pretende-se evitar a existência de não conformidades pendentes em todas as fases do processo produtivo, de forma a garantir que o produto final obtido corresponde efectivamente a um produto com um conjunto de características adequadas às necessidades do cliente. A excelência em termos de qualidade total determina que toda e qualquer discrepância com relação a requisitos, procedimentos, instruções ou normas estabelecidas, seja investigada e registada adequadamente, em conjunto com as eventuais acções correctivas, preventivas ou de disposição, que sejam necessárias. Uma não conformidade é o não atendimento a um requisito ou não satisfação de um requisito especificado. (NP EN ISSO 8402/1997). O trabalho é projectado para atender aos requisitos traduzidos das necessidades do cliente. Quando o produto ou serviço deixa de atender a uma ou alguma das necessidades destas partes interessadas, configura-se uma não conformidade. Quando ocorre uma não conformidade é necessário tratá-la adequadamente, para prevenir a sua reincidência, conhecendo e eliminando a sua causa ou as [PJMG quality, 251]

286 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE suas causas. Podem ser detectados vários tipos de não conformidades conforme ilustrado na Tabela Tipo das não conformidades Processo Reclamações do cliente Auditorias Internas da Qualidade Sistema de Qualidade Descrição Identificadas durante a execução de actividades dos processos para atendimento dos requisitos definidos. Detectadas pelos clientes durante a execução do projecto. Solicitações de modificações ou alterações são excluídas. Identificadas durante o processo de realização de auditorias internas conforme especificação no plano de qualidade. Identificados desvios em relação aos standards de Qualidade definidos (indicadores atribuídos aos objectivos estabelecidos); qualquer outra situação que possa comprometer o SGQ definido. Tabela 8.14: Tipos de não conformidades Uma não conformidade é composta por uma causa e por um efeito. A causa é o factor que efectivamente provocou o desvio em relação a uma condição programada ou planeada e que, consequentemente, impediu o cumprimento dos requisitos. O efeito provocado pela não conformidade, é o resultado diferente do esperado ou necessário. O tratamento de uma não conformidade engloba os seguintes passos: Análise da não conformidade entendimento claro e preciso do facto ocorrido; Eliminação do efeito da não conformidade é a acção sobre o efeito, resolvendo ou eliminando a não-conformidade; Identificação da causa ou das causas da não conformidade identificação clara dos factores que provocaram o desvio em relação à situação planeada ou programada. Pode ser elaborado um diagrama de causa/efeito; [PJMG quality, 252]

287 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Verificação da abrangência da não-conformidade consiste na verificação da influência das causas identificadas em outros processos, produtos ou serviços; Definição e implementação de um plano de acções correctivas as acções correctivas actuam directamente na eliminação das causas da não conformidade assegurando a sua não reincidência. É fundamental a utilização de ferramentas de qualidade para construção de um plano de acção consistente. O método 5W2H apresentado na Tabela 8.15 é um exemplo de uma ferramenta de qualidade, e pode ser utilizado para a adopção de um plano de acção correctiva/preventiva, após a definição das possíveis causas; A audição da decisão do cliente sempre que as correcções a efectuar possam ter impacto nas características e desempenho do serviço; Verificação da implementação e eficácia das acções correctivas adoptadas esta etapa assegura que as acções correctivas foram efectivamente implementadas e eliminaram a causa da nãoconformidade. O plano de acção tem como objectivo orientar as diversas acções a serem implementadas. Através da sua utilização pode-se identificar as acções e as responsabilidades pela sua execução, entre outros aspectos. De acordo com Oliveira (Oliveira, 1995) um plano de acção deve estar estruturado para permitir a rápida identificação dos elementos necessários à sua implementação. Estes elementos básicos são descritos pelo que se convencionou chamar método 5W2H. Método 5W2H Dados Designação Descrição 5W 2H What O Quê? Que a tarefa ou acção será executada (etapas); Who Quem? Quem realizará cada tarefa (responsabilidade); Where Onde? Onde será executada cada tarefa ou acção (local); When Quando? Quando é realizada cada tarefa (tempo); Why Porquê? Por que deve ser executada a tarefa (justificativa); How Como? Como deverá ser realizada cada tarefa (método); How much Quanto custa? Quanto custará cada etapa ou tarefa (custo); Tabela 8.15: Método 5W2H [PJMG quality, 253]

288 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE O que é expectável de um Sistema de Gestão da Qualidade é que, com a consolidação do mesmo, o número de acções correctivas tendam a reduzir e o número de acções preventivas tendam a aumentar. Na Figura 8.13 é apresentada de forma resumida a sequência do processo de tratamento de uma não conformidade. Figura 8.13: Processso de tratamento de uma não conformidade O procedimento de acções correctivas e preventivas encontra-se dividido em cinco fases, desde a identificação da situação não conforme até ao seu fecho: [PJMG quality, 254]

289 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE EX Identificação da situação de não conformidade real ou potencial: 1.1 A detecção e a identificação da origem da não conformidade podem resultar de: a) Reclamações de clientes ou partes interessadas, recebidas via telefone, correio electrónico, carta, fax ou pessoalmente; b) Não conformidades internas detectadas, que possam afectar a qualidade, a segurança e o ambiente; c) Não conformidades potenciais. EX Registo e caracterização da situação de não conformidade: 2.1. Registo e identificação da não conformidade na ficha de não conformidade, acções correctivas ou preventivas; 2.2. Envio da ficha de não conformidade, acções correctivas ou preventivas para a área responsável pela resolução da não conformidade; 2.3. Análise e identificação das causas prováveis que originaram a situação; 2.4. Determinação da acção (correcção, acção correctiva ou acção preventiva): a) Descrição das acções a desenvolver, meios necessários e resultados esperados; b) Data de implementação e responsável; 2.5. Envio de uma cópia da acção para o gestor da qualidade, segurança e ambiente; 2.6. Registo no mapa de controlo das acções correctivas ou preventivas. EX Implementação e seguimento da acção: 3.1. Desenvolvimento das acções tendentes à implementação da acção: a) No caso de acções no âmbito da segurança e saúde no trabalho é necessário identificar os perigos e riscos, antes da implementação das acções; 3.2. A acção correctiva ou preventiva definida é objecto de seguimento, para monitorizar a implementação da acção, ou seja, verifi- [PJMG quality, 255]

290 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE car se os prazos definidos estão a ser cumpridos e se estão a ser produzidos os efeitos desejados. EX Revisão dos resultados: 4.1. Após conclusão de uma acção correctiva ou preventiva, verifica-se se a acção está totalmente implementada e se o seu resultado foi eficaz na eliminação das causas da não conformidade, evitando a sua repetição ou ocorrência; 4.2. Os resultados da avaliação da eficácia da acção correctiva ou preventiva são registados na ficha de não conformidade, acções correctivas ou preventivas; 4.3. Caso a acção não tenha concretizado os resultados previstos, é definida e implementada uma nova acção; 4.4. No final da acção, a ficha de não conformidade, acções correctivas ou preventivas é enviada ao gestor da qualidade, segurança e ambiente, sendo-lhe comunicados os resultados obtidos. EX Fecho da não conformidade: 5.1. O fecho de uma não conformidade é formalizado no documento onde é efectuado o registo de todas as não conformidades e é registado no mapa de controlo de acções correctivas ou preventivas. EX.06 Controlo do plano de aceitação com o cliente Efectuar a verificação do cumprimento do que está definido no plano de aceitação do cliente. O controlo deste plano é efectuado através dos seguintes itens: Gerir os entregáveis de modo a garantir a correcta aceitação pelo cliente; Validação do cumprimento dos critérios da aceitação dos entregáveis produzidos pelo projecto que estão especificados e acordados formalmente entre o fornecedor e cliente (ex: contrato); Verificação dos métodos e técnicas descritas no plano; Verificação da aceitação de todos os entregáveis descritos no plano; [PJMG quality, 256]

291 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Verificação do cumprimento por parte do cliente da aceitação de entrega de testes, demonstrações, análises e inspecções que são realizados ao longo do projecto conforme plano de progresso. Na Figura 8.14 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. Figura 8.14: Artefactos utilizados e produzidos para realização da actividade Controlo do plano de aceitação EX.07 Reuniões de controlo de progresso Consiste na realização das reuniões de progresso com a equipa de projecto de acordo com o definido no plano de qualidade. As reuniões de progresso devem ser realizadas seguindo o plano de progresso. Participam nesta reunião os elementos que compõem a equipa de projecto. Estas reuniões devem ter em consideração a informação recolhida nos pontos de controlo realizados. Os objectivos destas reuniões são: Contabilizar todo o trabalho já realizado até à data; Determinar qual o trabalho que está em progresso e saber quando cada actividade será finalizada. O relatório do progresso do projecto deve ser actualizado com base nas actas das reuniões de acompanhamento ou controlo de progresso. As reuniões de controlo de progresso ficam registadas através da acta de reunião de controlo de progresso. [PJMG quality, 257]

292 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Estas reuniões, são regra geral, compostas pelo seguinte plano de trabalho: Revisão da acta anterior; Revisão do plano e do estado das actividades ou pacotes de trabalho (work packages); Identificação de melhoria nos processos; Revisão de riscos; Acompanhamento de acções; Agendamento da próxima reunião. A revisão do plano e do estado das actividades é efectuada com base na seguinte informação: - Work packages; - Milestones (Metas); - Entregáveis; - Acções. De seguida apresentam-se exemplos destas várias componentes nas tabelas Tabela 8.16, Tabela 8.17, Tabela 8.18 e Tabela Work Packages WP# Título Estado Comentários WP Gestão Projecto e Controlo da Qualidade WP Levantamento e Especificação Requisitos Utilizador WP Especificação de Arquitectura WP Implementação WP Validação Em curso Verificar datas de auditorias e pontos de controlo. Concluída Verificar prazos de entrega do caderno de especificação de requisitos. Concluída Em curso Especificar em acta os atrasos e respectivas causas. Em curso Tabela 8.16: Exemplo de uma lista de work packages analisada numa reunião de progresso. [PJMG quality, 258]

293 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Milestones ML# Título Data Estado Comentários ML-01 KOM - Reunião de Kick-Off 01-Mar Concluído ML-02 PDR - Especificação Concluída 02-Abr Concluído Estamos à espera de Feedback por parte do cliente. ML-03 Workshop 05-Abr Em preparação Validação dos recursos necessários. ML-04 QR - Projecto Testado e Revisto 11-Jul Não iniciado ML-05 PCM - Reunião Fim Projecto 30-Jul Não iniciado Tabela 8.17: Exemplo de uma lista de milestones analisada numa reunião de progresso. Entregáveis DL# Título Data Estado Comentários DL-01 Especificação de Requisitos 02-Abr Concluído DL-02 Especificação de Testes 02-Mai Concluído DL-03 Protótipo 02-Jun Concluído DL-04 Especificação de Arquitectura 02-Abr Concluído DL-05 Relatório de Testes 15-Jun Não iniciado DL-06 Termo de Aceitação 30-Mai Em desemvolvimento Verificar se está em consonância com o plano de aceitação. DL-07 Relatório de Estágio 15-Jul Não iniciado Tabela 8.18: Exemplo de uma lista de entregáveis analisada numa reunião de progresso [PJMG quality, 259]

294 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Acções ACT# Descrição Responsável Data Limite Estado ACT-01 Colocar on-line Prog-aab Jul Aberta ACT-02 Identificar responsáveis por áreas e marcar datas para formação ACT-03 Dar formação aos responsáveis identificados Com-aca 30-Jun Aberta AF - dci 20-Jul Aberta ACT-04 Marcar reunião com o cliente 12-Abr Fechada Tabela 8.19: Exemplo de uma lista de acções tratada numa reunião de progresso Na Figura 8.15 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. Figura 8.15: Artefactos utilizados e produzidos para realização da actividade Reuniões de controlo de progresso EX.08 Produção de relatórios de progresso internos Elaboração dos relatórios de progresso do projecto após as reuniões de controlo Os relatórios de progresso nem sempre são tão eficazes quanto deveriam ser. Esta realidade aplica-se tanto para os elementos da equipa que submetem esses relatórios ao gestor do projecto, bem como para o gestor do projecto que 14 Prog aab é um exemplo de como pode ser indicado um recurso humano do projecto (Prog: indica a função do responsável; aab: indica a sigla do responsável) [PJMG quality, 260]

295 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE submete os relatórios aos principais Stakeholders. Um dos principais motivos reside no facto de quem elabora os relatórios, considerar a sua execução como uma tarefa incómoda e não uma forma de comunicar informações valiosas. Tipicamente, recebe-se um relatório de progresso resumido, ou um relatório de progresso que contém todas as actividades triviais que foram realizadas. De modo a uniformizar o tipo de relatório, a sua produção deve ser efectuada com base nas normas definidas no plano da qualidade para a documentação a ser produzida ao longo do projecto (deve estar definido um modelo que indica o seu conteúdo). Após a realização de uma reunião de controlo de progresso, deve ser gerado este relatório. Deve ser assegurado que a informação contida no relatório de progresso possa ser utilizada no processo de tomada de decisões. A informação descrita deve ser útil e poderá ser usada para gerir o projecto e manter os stakeholders informados. O relatório de progresso deve centrar-se nos seguintes tópicos: Actividades realizadas desde o último relatório; Progresso realizado nas actividades planeadas; Planeamento das próximas actividades; Comentários ou observações pertinentes sobre as actividades que deveriam estar concluídas, mas que denotam algum atraso; Problemas encontrados, os respectivos impactos no projecto, e o que está a ser pensado para a sua resolução; Pedidos de alteração do âmbito; Questões, planos de acção para resolução de ocorrências e o seu estado; Novos riscos identificados; Observações úteis ao leitor. O relatório de progresso deverá incluir somente a informação que seja relevante. No entanto, poderá descobrir que parte da audiência está interessada somente nas excepções relativamente ao previsto (director de projecto), enquanto a outra parte está mais interessada nos detalhes (equipas técnicas). Uma das formas de satisfazer os dois tipos de receptores é escrever relatórios de progresso formais com base em excepções e incluir os detalhes em apêndi- [PJMG quality, 261]

296 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE ces (anexos). Por exemplo, alguns leitores poderão querer saber o que foi realizado no período anterior e o que está planeado para o próximo período. Contudo, outros poderão querer conhecer todo o calendário das actividades. Neste caso deve ser incluído o calendário completo como anexo. Estes relatórios são produzidos periodicamente conforme definido no plano de gestão do projecto e em consonância com os pontos de controlo definidos para o projecto. Na Figura 8.16 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. Figura 8.16: Artefactos utilizados e produzidos para realização da actividade Produção de relatórios de progresso interno EX.09 Produção de relatórios para o cliente Estes relatórios são produzidos periodicamente conforme definido no plano de envolvimento do cliente, em consonância com o plano de aceitação do cliente e com o plano da qualidade. A construção de relatórios é uma prática que deve estar presente no decorrer dos projectos. O plano de envolvimento com o cliente é essencial, tanto para garantir a sua satisfação, como para servir de defesa no caso de o cliente decidir alterar os requisitos (Kern, 2003). Tendo em conta esse plano, deverão ser criados e enviados relatórios ao cliente acerca do desenvolvimento do projecto. O relatório para o cliente deve centrar-se nos seguintes pontos: Indicação das actividades a realizar pelo cliente e respectivo progresso; Estado e respectiva evolução de pedidos de alteração do âmbito; [PJMG quality, 262]

297 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Estado e respectiva evolução de pedidos de reclamação; Lista dos entregáveis e respectivo estado de evolução; Comentários úteis ao cliente. Na Figura 8.17 são enumerados os artefactos necessários para a realização desta actividade e os artefactos produzidos. Figura 8.17: Artefactos utilizados e produzidos para realização da actividade Produção de relatórios para o cliente EX.10 Gestão de entregáveis Gerir os entregáveis (deliverables) e garantir a sua correcta aceitação pelo cliente. Esta actividade tem por principal objectivo a gestão dos entregáveis (delivery management) para o cliente e respectiva gestão dos timings que estão definidos no plano de projecto. O planeamento da gestão dos entregáveis tem por objectivo prevenir ineficiências detectadas na comunicação e garantir a qualidade dos entregáveis. Deve validar: O conteúdo e objectivos de cada entregável (deliverable); O cumprimento do faseamento das entregas; Se o papel do cliente está a ser cumprido e em consonância com o que está determinado nos planos de envolvimento e de aceitação; [PJMG quality, 263]

298 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE O plano de entrega ao cliente: as entregas devem ser geridas de forma a garantir a correcta aceitação pelo cliente. Na Figura 8.18 são enumerados os artefactos necessários para a realização desta actividade e os artefactos produzidos. Figura 8.18: Artefactos utilizados e produzidos para realização da actividade Gestão de entregáveis EX. 11 Validar pontos de controlo (controlo da qualidade) Verificar e analisar a informação obtida nos pontos de controlo e determinar acções correctivas, caso necessário; antecipar problemas e analisar o seu impacto. A norma ISO 9001 define qualidade como sendo: "A totalidade dos recursos e as características de um produto ou serviço que suporta a sua capacidade de satisfazer uma determinada necessidade". Garantir a qualidade, não sendo tarefa fácil, é fortemente compensadora pelo aumento de produtividade que desencadeia e pela redução significativa que produz em termos de correcções e manutenção. A garantia da qualidade é constituída pelo conjunto de actividades, que devem ser rigorosamente observadas, o que permite ter uma razoável expectativa de que os produtos a produzir e os serviços a prestar vão estar em consonância com o plano de qualidade definido. O controlo da qualidade é efectuado através da realização de pontos de controlo que permitem a identificação de problemas, alterações e atrasos. É pro- [PJMG quality, 264]

299 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE duzido um relatório que permite ao cliente conhecer o controlo da qualidade efectuado e das respectivas métricas e medidas utilizadas durante a fase de execução. No planeamento dos pontos de controlo deve constar: Determinar produtos e documentos necessários à monitorização; Verificar o estado da documentação necessária; Elaborar lista de participantes; Agendar reuniões de feedback; Preparar documentos e produtos a serem revistos. Validar pontos de controlo - Correspondem a pontos de situação periódicos definidos no plano da qualidade. Deve ser efectuado um checkpoint cycle, isto é, todos os membros da equipa devem dar feedback do seu trabalho e respectivo progresso. Cada membro deve dar a seguinte informação: Data de início para as actividades iniciadas no período em causa; Data final para as actividades que terminaram nesse período; Trabalho efectivo (esforço), em horas por tarefa nesse período; Estimativa em horas para completar a tarefa; Tempo que falta para terminar a tarefa. O controlo da qualidade também inclui as revisões de fim de fase que devem ser efectuadas pelo gestor. Acções a efectuar nas revisões: Verificar e analisar a informação obtida nos pontos de controlo e determinar acções correctivas, caso necessário; Validação dos pontos de controlo de acordo com o plano da qualidade; Controlar cumprimento dos prazos; Controlar qualidade dos entregáveis. Uma revisão de fim de fase permite ao gestor a possibilidade de previsão de atrasos e de antecipar problemas e proceder à análise atempada do seu impac- [PJMG quality, 265]

300 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE to. Na Figura 8.19 são enumerados os artefactos utilizados para a realização da actividade e os respectivos artefactos produzidos. Figura 8.19: Artefactos utilizados e produzidos para realização da actividade Controlo da qualidade Fase de encerramento Um aspecto normalmente negligenciado é o encerramento e arquivo de projectos. É importante ter a noção de que a informação e o conhecimento adquiridos com um projecto são, mais do que nunca, activos críticos, e deve ser preocupação do gestor do projecto, geri-los e protegê-los da forma mais adequada. A possibilidade de se armazenar ou arquivar informação do projecto (incluindo documentos e outros artefactos) é algo mais importante do que pode aparentar numa primeira abordagem. A possibilidade de restaurar (a informação arquivada) em projectos futuros ou em actividades subsequentes ligadas a um projecto é fundamental na optimização e reutilização de esforço, nomeadamente na aplicação de processos de trabalho normalizados (adaptando-os eventualmente a novas realidades). Nesta fase estão incluídas as actividades formais de fecho do projecto. O projecto deve passar por uma fase formal de encerramento. Pode existir trabalho pendente do projecto que tem de ser analisado e resolvido antes do encerramento formal do projecto. Este tipo de trabalho poderá ser cancelado, ou deverão ser criados mecanismos para completar o trabalho, tais como manutenção do programa, ou estruturação de projectos adicionais. Todos os mecanismos de controlo e monitorização do projecto devem ser formalmente encerrados. Todos os documentos e relatórios devem ser finalizados, revistos e arquivados, conforme definição para o efeito. [PJMG quality, 266]

301 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE O processo de encerramento estabelece os procedimentos necessários para coordenar as actividades de verificação, documentação e aceitação das entregas do projecto. As actividades de encerramento implicam a execução de três actividades principais: Encerramento administrativo do projecto documenta os resultados do projecto e verifica se estão actualizados; Encerramento dos contratos em vigor verificação de que o trabalho descrito no contrato foi concluído de forma correcta; Registo das lições aprendidas constituem o resultado final do processo de encerramento; documentam o sucesso ou insucesso do projecto. Na condução do encerramento do projecto, devem continuar a ser geridas mudanças e problemas que tenham sido reportados. Questões na fase final do projecto podem ser frequentes, fase em que os clientes percebem que possuem apenas um curto período de tempo restante para influenciar os resultados dos projectos. O promotor do projecto e o gestor de projecto devem assumir uma liderança nesta fase do projecto para controlar a introdução de novas questões por parte do cliente. EN.01 Arquivar documentação Validar, finalizar e armazenar toda a documentação referente ao projecto. Os registos devem ser estabelecidos e mantidos para proporcionar evidências. Deve ser efectuado o registo centralizado de informação do projecto porque permite aumentar a capacidade de controlo e gestão da execução do mesmo. O repositório do projecto deve ser alimentado ao longo de todo o projecto, mas na fase final assume particular relevância. Os recursos físicos podem facilmente perder-se em projectos de infra-estrutura compartilhada com o cliente. Devem ser mantidos registos do equipamento, licenças e materiais que serão conservados pelo fornecedor e pelo cliente. [PJMG quality, 267]

302 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Toda a documentação produzida ao longo do projecto deve ser arquivada antes do encerramento formal do projecto e respectiva aceitação pelo cliente. Toda a informação referente ao projecto deve ser validada, finalizada e armazenada, pois no futuro pode ser uma mais-valia em projectos semelhantes, na mesma área de negócio ou em projectos que em que tenham ocorrido determinadas situações. Se for possível não cometer os mesmos erros em dois projectos será uma mais-valia a nível de custos, tempo e recursos. Na Figura 8.20 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. Figura 8.20: Artefactos utilizados e produzidos para realização da actividade Arquivar documentação EN.02 Produzir relatório final de projecto Elaborar relatório final do projecto de acordo com os resultados obtidos. Registar desvios e alterações face ao planeamento inicial, caso ocorram. O relatório final de projecto deve conter todas as actividades de encerramento do projecto. Deve explicitar os requisitos e objectivos cumpridos. Caso existam alterações ao âmbito que foram contempladas, deve documentar com rigor essas alterações. Deve ser elaborado um bom documento de lições aprendidas que pode ser colocado em anexo a este relatório. É um relatório fundamental em termos de continuidade do projecto. Funciona como suporte fundamental no caso da manutenção evolutiva. [PJMG quality, 268]

303 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Na Figura 8.21 são enumerados os artefactos necessários à realização desta actividade e os artefactos produzidos. Figura 8.21: Artefactos utilizados e produzidos para realização da actividade Produção de relatório final de projecto EN03. Elaboração de inquérito final de satisfação do cliente A avaliação da satisfação do cliente tem por objectivo mensurar a sua percepção sobre o projecto e identificar oportunidades para melhoria. O termo satisfação do cliente está relacionado com a percepção que o cliente tem ao comparar o desempenho do produto/serviço com suas expectativas. A satisfação do cliente pode ser então considerada, de forma simplificada, uma questão de análise da expectativa versus desempenho efectivo (FNQ, 2008). Segundo Kujala e Ahola, os inquéritos são a forma mais comum de constatar a satisfação do cliente (Kujala & Ahola, 2005). Assim, este inquérito é bastante importante para se avaliar se o projecto tem um resultado positivo ou negativo. Os benefícios destes inquéritos dependem da forma como a organização os realiza e, posteriormente, avalia (Kujala & Ahola, 2005). Ainda que se cumpram requisitos de tempo, orçamento e âmbito, se o cliente não estiver satisfeito, a qualidade do projecto é claramente questionável. O conhecimento das percepções e reacções dos clientes pode aumentar significativamente a possibilidade de melhores decisões organizacionais. Assim, para captar adequadamente essas percepções e reacções, os instrumentos de avaliação da satisfação devem ser bem definidos, caso contrário, as decisões tomadas a partir dessas informações podem ser prejudiciais ao sucesso da organização. [PJMG quality, 269]

304 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE A avaliação da satisfação do cliente pode incluir tanto métodos quantitativos quanto qualitativos, conforme já mencionado no tópico sobre identificação e tratamento das necessidades e expectativas dos clientes. Uma avaliação eficaz deve fornecer informações confiáveis sobre os atributos do produto e dos serviços, segundo a visão do cliente, bem como sobre a relação entre essa visão e a probabilidade de suas acções futuras relacionadas e ao fornecimento de referências positivas para a organização. Um modelo geral para o processo de avaliação da satisfação por meio de questionário inclui as seguintes etapas: Determinar as necessidades/expectativas do cliente as expectativas estão implícitas nos requisitos do cliente. As expectativas representam necessidades, normalmente não explicitadas ou latentes. O cliente espera que as características do produto proporcionem respostas às suas necessidades mais importantes e prioritárias, com base em experiências passadas, comparações com produtos similares, tecnologia disponível ou outros factores (como exemplo pode citar-se: acesso simplificado às informações, respostas rápidas às reclamações ou solicitações); Elaborar e avaliar o questionário; Executar o questionário; Proceder à recolha dos dados; Analisar os dados; Tirar conclusões e tomar decisões e eventualmente programar a execução das acções para promover melhorias. Na Figura 8.22 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. [PJMG quality, 270]

305 MODELO DE ACTIVIDADES DA GESTÃO DE PROJECTOS NO ÂMBITO DA QUALIDADE Figura 8.22: Artefactos utilizados e produzidos para realização da actividade Elaboração do inquérito final de satisfação do cliente EN.04 Sistematizar e enriquecer base de conhecimento A aprendizagem organizacional está intimamente ligada à gestão da qualidade e do conhecimento, já que os seus processos (aquisição de conhecimentos; partilha do que se aprende; assimilação pela memória organizacional; utilização de novos conhecimentos para solução sistemática dos problemas; experimentação; auto-aprendizagem das experiências individuais e dos outros e disseminação rápida dos conhecimentos) apelam igualmente ao envolvimento e à participação para a melhoria do desempenho, através de uma aprendizagem contínua (Ochoa, 2004). Um dos problemas da gestão do conhecimento reside precisamente na transferência do conhecimento. Como tal, deve existir uma plataforma de gestão de conhecimento que deve ser enriquecida na fase de encerramento de um projecto. O repositório do projecto deve ser alimentado durante o desenrolar do projecto, de forma a conter toda a documentação elaborada. No entanto, o modo como os repositórios estão organizados nem sempre facilitam um posterior acesso rápido e directo à informação que pode ser de importância relevante para projectos futuros. Torna-se fundamental na fase final do projecto a sistematização do conhecimento adquirido. A documentação principal que deve servir de suporte ao enriquecimento do conhecimento e respectiva acessibilidade são: Documento com lições aprendidas privilegiar a utilização das lições aprendidas reduz o tempo de planeamento de um novo projecto com características similares e na mesma área de negócio. [PJMG quality, 271]

306 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Reduz o risco de serem cometidos os mesmos erros. Nesta actividade deve ser documentada a seguinte informação: o sucesso ou insucesso do projecto, acções correctivas, razões da sua implementação e resultados respectivos; variações no desempenho e respectivas causas; riscos não planeados que eventualmente ocorreram; erros cometidos que poderiam ter sido evitados. Relatório final do projecto; Checklists de verificação do projecto. Na Figura 8.23 são enumerados os artefactos utilizados para a realização desta actividade e os artefactos produzidos. Figura 8.23: Artefactos utilizados e produzidos para realização da actividade Sistematizar e enriquecer base de conhecimento 8.3 SÍNTESE DO MODELO A gestão de projectos reúne várias áreas de conhecimento, sendo fundamental para o gestor de projecto o domínio efectivo dessas mesmas áreas. Nesse contexto, a gestão da qualidade, apesar de ser fundamental, é muitas vezes menosprezada conforme se pode verificar no resultado do estudo da gestão de projectos descrito no capítulo sete desta tese. É a esta área que é atribuído um menor grau de importância pelos gestores respondentes refletido na reduzida execução dos processos respectivos. [PJMG quality, 272]

307 SÍNTESE DO MODELO As causas fundamentais deste resultado estão relacionadas com o custo e o esforço que são acrescidos ao projecto e também devido à inexistência de um guia estruturado para um desempenho eficiente da gestão da qualidade. Os referenciais existentes não cobrem da forma abrangente e necessária as questões relacionadas com a gestão da qualidade em gestão de projectos de desenvolvimento de software. O modelo apresentado visa dar um contributo na área da qualidade, pretendendo constituir um guia e um referencial de forma a que a gestão da qualidade assuma o grau de importância necessário, e contribua efectivamente para o sucesso e para a entrega de soluções com qualidade. O modelo, como é possível observar na Figura 8.24, é transversal às nove áreas de conhecimento apresentadas e detalhadas no PMBoK, seguindo a sua abordagem no que toca às principais áreas de conhecimento que o constituem. No entanto, o foco deste modelo é a área da qualidade, sendo nesta que pretende dar o seu contributo, mais concretamente nas actividades realizadas pelo gestor durante o desenrolar de um projecto. Está estruturado da seguinte forma: É composto por três fases, e cada fase reúne diversas actividades; As actividades têm uma cor associada que identifica a fase a que pertencem; As setas representam interacções existentes entre as diferentes actividades. Apesar do modelo ser constituído por três fases com actividades específicas, o mesmo não é estático, existindo interacções entre actividades de diferentes fases. Esta interactividade entre fases potencia uma dinâmica na gestão de projectos e que torna o modelo mais abrangente e adaptável à gestão de projectos de diferentes áreas de negócio, facto importante devido à diversidade existente nos projectos da actualidade. [PJMG quality, 273]

308 CAPÍTULO OITO - MODELO DE ACTIVIDADES DO GESTOR DE PROJECTO NO ÂMBITO DA QUALIDADE Figura 8.24: Enquadramento do modelo de actividades da gestão de projectos no âmbito da qualidade [PJMG quality, 274]