Preview only show first 10 pages with watermark. For full document please download

Gerência De Projetos 2007

Gestão de Projetos

   EMBED

  • Rating

  • Date

    December 2018
  • Size

    6.2MB
  • Views

    6,270
  • Categories


Share

Transcript

Universidade do Sul de Santa Catarina Gerência de Projetos Disciplina na modalidade a distância Palhoça UnisulVirtual 2007 book.indb 1 31/5/2007 14:23:18 Créditos Unisul - Universidade do Sul de Santa Catarina UnisulVirtual - Educação Superior a Distância Campus UnisulVirtual Avenida dos Lagos, 41 Cidade Universitária Pedra Branca Palhoça – SC - 88137-100 Fone/fax: (48) 3279-1242 e 3279-1271 E-mail: [email protected] Site: www.virtual.unisul.br Reitor Unisul Gerson Luiz Joner da Silveira Vice-Reitor e Pró-Reitor Acadêmico Sebastião Salésio Heerdt Chefe de Gabinete da Reitoria Fabian Martins de Castro Pró-Reitor Administrativo Marcus Vinícius Anátoles da Silva Ferreira Campus Sul Diretor: Valter Alves Schmitz Neto Diretora adjunta: Alexandra Orsoni Campus Norte Diretor: Ailton Nazareno Soares Diretora adjunta: Cibele Schuelter Campus UnisulVirtual Diretor: João Vianney Diretora adjunta: Jucimara Roesler Equipe UnisulVirtual Administração Renato André Luz Valmir Venício Inácio Avaliação Institucional Dênia Falcão de Bittencourt Biblioteca Soraya Arruda Waltrick Capacitação e Apoio Pedagógico à Tutoria Angelita Marçal Flores (Coordenadora) Caroline Batista Enzo de Oliveira Moreira Patrícia Meneghel Vanessa Francine Corrêa book.indb 2 Coordenação dos Cursos Adriano Sérgio da Cunha Aloísio José Rodrigues Ana Luisa Mülbert Ana Paula Reusing Pacheco Charles Cesconetto Diva Marília Flemming Fabiano Ceretta Itamar Pedro Bevilaqua Janete Elza Felisbino Jucimara Roesler Lauro José Ballock Lívia da Cruz (Auxiliar) Luiz Guilherme Buchmann Figueiredo Luiz Otávio Botelho Lento Marcelo Cavalcanti Maria da Graça Poyer Maria de Fátima Martins (Auxiliar) Mauro Faccioni Filho Michelle D. Durieux Lopes Destri Moacir Fogaça Moacir Heerdt Nélio Herzmann Onei Tadeu Dutra Patrícia Alberton Raulino Jacó Brüning Rodrigo Nunes Lunardelli Simone Andréa de Castilho (Auxiliar) Criação e Reconhecimento de Cursos Diane Dal Mago Vanderlei Brasil Desenho Educacional Daniela Erani Monteiro Will (Coordenadora) Carmen Maria Cipriani Pandini Carolina Hoeller da Silva Boeing Dênia Falcão de Bittencourt Flávia Lumi Matuzawa Karla Leonora Dahse Nunes Leandro Kingeski Pacheco Ligia Maria Soufen Tumolo Márcia Loch Viviane Bastos Viviani Poyer Núcleo de Acessibilidade Vanessa de Andrade Manoel Núcleo de Avaliação da Aprendizagem Márcia Loch (Coordenadora) Cristina Klipp de Oliveira Silvana Denise Guimarães Design Gráfico Cristiano Neri Gonçalves Ribeiro (Coordenador) Adriana Ferreira dos Santos Alex Sandro Xavier Evandro Guedes Machado Fernando Roberto Dias Zimmermann Higor Ghisi Luciano Pedro Paulo Alves Teixeira Rafael Pessi Vilson Martins Filho Disciplinas a Distância Tade-Ane de Amorim Cátia Melissa Rodrigues (Auxiliar) Gerência Acadêmica Patrícia Alberton Gerência de Ensino Ana Paula Reusing Pacheco Logística de Encontros Presenciais Márcia Luz de Oliveira (Coordenadora) Aracelli Araldi Graciele Marinês Lindenmayr José Carlos Teixeira Letícia Cristina Barbosa Kênia Alexandra Costa Hermann Priscila Santos Alves Núcleo de Formatura e Eventos Jackson Schuelter Wiggers Logística de Materiais Jeferson Cassiano Almeida da Costa (Coordenador) Eduardo Kraus Monitoria e Suporte Rafael da Cunha Lara (coordenador) Adriana Silveira Andréia Drewes Caroline Mendonça Cristiano Dalazen Dyego Rachadel Edison Rodrigo Valim Francielle Arruda Gabriela Malinverni Barbieri Jonatas Collaço de Souza Josiane Conceição Leal Maria Eugênia Ferreira Celeghin Rachel Lopes C. Pinto Vinícius Maykot Serafim Produção Industrial e Suporte Arthur Emmanuel F. Silveira (coordenador) Francisco Asp Relacionamento com o Mercado Walter Félix Cardoso Júnior Secretaria de Ensino a Distância Karine Augusta Zanoni Albuquerque (Secretária de ensino) Ana Paula Pereira Andréa Luci Mandira Carla Cristina Sbardella Deise Marcelo Antunes Djeime Sammer Bortolotti Franciele da Silva Bruchado Grasiela Martins James Marcel Silva Ribeiro Jenniffer Camargo Lamuniê Souza Lauana de Lima Bezerra Liana Pamplona Marcelo José Soares Marcos Alcides Medeiros Junior Maria Isabel Aragon Olavo Lajús Priscilla Geovana Pagani Rosângela Mara Siegel Silvana Henrique Silva Vanilda Liordina Heerdt Vilmar Isaurino Vidal Secretária Executiva Viviane Schalata Martins Tecnologia Osmar de Oliveira Braz Júnior (Coordenador) Jefferson Amorin Oliveira Ricardo Alexandre Bianchini Rodrigo de Barcelos Martins 31/5/2007 14:23:23 Apresentação Bem-vindo! Parabéns, você está recebendo o livro didático da disciplina Gerência de Projetos. O processo de ensino e aprendizagem na UnisulVirtual leva em conta instrumentos que se articulam e se complementam, portanto, a construção de competências se dá sobre a articulação de metodologias e por meio das diversas formas de ação/ mediação. São elementos desse processo: „ O livro didático; „ O EVA (Espaço UnisulVirtual de Aprendizagem); „ Atividades de avaliação (complementares, a distância e presenciais). Os materiais didáticos foram construídos especialmente para este curso, levando em consideração o seu perfil e as necessidades da sua formação. Como os materiais estarão, a cada nova versão, recebendo melhorias, pedimos que você encaminhe suas sugestões sempre que achar oportuno via professor-tutor ou monitor. Recomendamos que antes de você começar os seus estudos, verifique as datas-chave e elabore o seu plano de estudo pessoal, garantindo assim a boa produtividade no curso. Lembre: você não está só nos seus estudos. Conte com o Sistema Tutorial da UnisulVirtual sempre que precisar de ajuda ou alguma orientação. Desejamos que você tenha êxito neste curso! Equipe UnisulVirtual. book.indb 3 31/5/2007 14:23:23 book.indb 4 31/5/2007 14:23:23 Mauro Faccioni Filho Gerência de Projetos Livro didático Design instrucional Dênia Falcão de Bittencourt 2ª ed. revista e atualizada Palhoça UnisulVirtual 2007 book.indb 5 31/5/2007 14:23:23 Copyright © UnisulVirtual 2007 Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição. Edição – Livro Didático Professor Conteudista Mauro Faccioni Filho Design Instrucional Dênia Falcão de Bittencourt Projeto Gráfico e Capa Equipe UnisulVirtual Diagramação Evandro Guedes Machado Revisão Ortográfica B2B 658.404 F12 Faccioni Filho, Mauro Gerência de projetos : livro didático / Mauro Faccioni Filho; design instrucional Dênia Falcão de Bittencourt. 2. ed. rev. – Palhoça : UnisulVirtual, 2007. 218 p. : il. ; 28 cm. Inclui bibliografia. 1. Administração de projetos. I. Bittencourt, Dênia Falcão de. II. Título. Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul book.indb 6 31/5/2007 14:23:23 Sumário Palavras do professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 UNIDADE UNIDADE UNIDADE UNIDADE UNIDADE 1 2 3 4 5 – – – – – Introdução aos projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Análise do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Planejamento e elaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 a execução do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Análise e conclusão do projeto. . . . . . . . . . . . . . . . . . . . . . . . 183 Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Sobre o professor conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Respostas e comentários das atividades de auto-avaliação . . . . . . . . . . . . 213 book.indb 7 31/5/2007 14:23:23 book.indb 8 31/5/2007 14:23:23 Palavras do Professor Bem vindo! Os livros dedicados à gestão de projetos dividem-se basicamente em dois tipos: aqueles que listam uma série de técnicas práticas de planejamento, e aqueles que discutem teoricamente a disciplina de gestão. Os do primeiro tipo acreditam que simplesmente aplicando alguma metodologia preconcebida de gestão será possível gerenciar um projeto com eficiência e eficácia. Baseiam-se em métodos e técnicas - uma série imensa de planilhas e relatórios - e mais recentemente dedicam-se a explicar e implantar ferramentas computacionais. Os do segundo tipo analisam a gestão como uma disciplina capaz de apoiar e beneficiar aqueles que se dedicam ao planejamento e ao desenvolvimento de projetos, mas carecem de uma real experiência em diferentes tipos de projetos, os quais envolvem sempre um agente essencialmente subjetivo: o ser humano. Este livro didático explora esse assunto de uma outra forma. Aqui o foco será essencialmente na aprendizagem e na discussão que gera um tipo de conhecimento que pode e deve ser útil aos que se interessam pelo tema. Neste sentido este não é um livro puramente acadêmico, com unidades e seções que apresentam teorias e exemplos desvinculados da realidade e de uma visão aplicada aos negócios e aos trabalhos práticos. Sem dúvida, muitas questões aqui colocadas vieram de pesquisas e análises acadêmicas, porém estão sempre focadas em aplicações. book.indb 9 31/5/2007 14:23:23 A idéia central desta disciplina é discorrer sobre as principais teorias de gestão de projetos, mas com o olhar voltado às aplicações e ao nível estratégico. A palavra “gestão” está intimamente relacionada à função de “gerência”, como veremos, e a gerência se assemelha a uma função operacional voltada ao controle. Mas em projetos isso não funciona. O melhor foco para a gestão de projetos deve estar colocado no conceito de liderança, pois a liderança submete a gestão, e não o inverso. Com essas palavras iniciais gostaria então de convidá-lo a essa aventura do conhecimento – o estudo dos projetos, sua organização, planejamento e, acima de tudo, trabalho de redes sociais participativas e cooperativas. Bom estudo! Professor Mauro Faccioni Filho. book.indb 10 31/5/2007 14:23:24 Plano de estudo O plano de estudo visa orientar você no desenvolvimento da disciplina. Ele possui elementos que o ajudarão a conhecer o contexto da disciplina e a organizar o seu tempo de estudo. Ementa da disciplina O processo de gerência. Modelo PMI. Planejamento do processo de desenvolvimento. Detalhamento das etapas de gerência de um projeto. Ferramentas para a gerência de projeto. Objetivos book.indb 11 „ Apresentar os conceitos básicos da área de gerência de projetos; „ Fornecer subsídios para a avaliação de riscos de um projeto, com ênfase nos projetos de base tecnológica; „ Apresentar técnicas de planejamento, execução e controle de projetos, formação de equipes e seu gerenciamento em reuniões; „ Descrever um modelo para gerência de projetos; „ Verificação dos softwares disponíveis para auxílio no gerenciamento de projetos; „ Utilização de software livre para gerência de projetos. 31/5/2007 14:23:24 Conteúdo programático/tempo de dedicação Unidade 1 - INTRODUÇÃO AOS PROJETOS. (12 h/a) „ História „ Conceitos „ Motivação para o projeto „ Tipos de projeto Unidade 2 - ANÁLISE DO PROJETO (12 h/a) „ Avaliação inicial „ Requisitos do cliente e solução de problemas „ Algoritmo do projeto „ Prazo „ Viabilidade do projeto „ Antecipando e administrando riscos „ Ferramenta de apoio para análise e planejamento Unidade 3 - PLANEJAMENTO E ELABORAÇÃO (20 h/a) „ Modelagem do fluxo de atividades „ Metodologias de planejamento – Gráfico de Gantt „ Metodologias de planejamento – PERT/CPM „ Estimativa de recursos e custos „ Recursos humanos em projetos „ Divisão de tarefas „ O modelo PMI 12 book.indb 12 31/5/2007 14:23:24 Unidade 4 - A EXECUÇÃO DO PROJETO (8 h/a) „ Preparação e início dos trabalhos „ Liderança versus gestão „ Tomada de decisões „ Reuniões „ Gerenciando qualidade „ Gestão de conflitos „ Simulação, testes e validação. Unidade 5 - ANÁLISE E CONCLUSÃO DO PROJETO (8 h/a) „ Fase de finalização „ Plano de contingência „ Atendendo as expectativas do cliente „ Sobre o sucesso (ou fracasso) do projeto „ Equipe e documentação „ Lições aprendidas e novas idéias 13 book.indb 13 31/5/2007 14:23:24 Agenda de atividades / Cronograma „ Verifique com atenção o cronograma no “EVA”, organizese para acessar periodicamente o espaço das disciplinas cursadas. Lembre-se que o sucesso nos seus estudos depende da priorização do tempo para a leitura, da realização de análises e sínteses do conteúdo e da interação com os seus colegas e professor tutor. „ Antes de iniciar a realização das atividades de avaliação, leia com atenção os critérios de avaliação apresentados pelo professor tutor no plano de ensino da disciplina no “EVA”. „ Não perca os prazos das atividades. Registre no espaço a seguir as datas-chave com base no cronograma disponibilizado no EVA. 14 book.indb 14 31/5/2007 14:23:24 Atividades obrigatórias Avaliação a distância (AD) Avaliação presencial (AP) Avaliação final (AF) Demais atividades (registro pessoal) Tenha por hábito, usar o quadro para agendar e programar as atividades relativas ao desenvolvimento da disciplina. 15 book.indb 15 31/5/2007 14:23:24 book.indb 16 31/5/2007 14:23:24 UNIDADE 1 Introdução aos projetos 1 Objetivos de aprendizagem Ao final desta unidade você terá subsídios para: „ Entender como os projetos se desenvolveram na história da humanidade. „ Compreender diferenças entre projetos e atividades rotineiras e contínuas. „ Constatar quais são os motivos que levam à realização de um projeto. „ Aprender os principais conceitos sobre projetos e gerência, bem como tipos de projeto e suas classificações. Seções de estudo A seguir, apresentam-se as seções para você estudar. Seção 1 História. Seção 2 Conceitos. Seção 3 Motivação para o projeto. Seção 4 Tipos de projeto. Após a leitura dos conteúdos, realize as atividades propostas no final da unidade e no EVA. book.indb 17 31/5/2007 14:23:24 Universidade do Sul de Santa Catarina Para início de estudo Esta disciplina o convida a aprofundar um assunto que, em minha opinião, é fascinante: PROJETOS. Você concorda comigo, não é mesmo? No entanto, saiba que há muitas idéias equivocadas sobre o que seriam projetos, e para evitar que você não corra o mesmo risco, o tema desta unidade é compreender teoricamente qual o conceito moderno de Projetos partindo de suas raízes históricas. Há várias diferenças entre projetos e tarefas de rotina, assim como há diversos tipos de projetos. Neste estudo, você conhecerá a classificação de acordo com modelos hoje aceitos, e também as principais tendências sobre gerência de projetos, com atenção especial ao modelo PMI, que será mais bem descrito ao longo do livro. Um fator importante é o da motivação para o projeto, que vai definir o caminho do seu sucesso, bem como a aderência aos requisitos do cliente e uma classificação do projeto, muito útil para seu futuro planejamento. São vários desafios de estudo, então bom trabalho e boa sorte! SEÇÃO 1 - História A palavra “projeto” é muito comum e está presente nos diálogos de todos os dias. Porém, os conceitos que se formaram em sua volta diferem de uma pessoa para a outra, e isso acontece porque o uso convencional dessa palavra varia de situação a situação. Mas antes de você começar a aprofundar o conceito de projeto no âmbito desta disciplina, é importante conhecer de onde veio essa forma 18 book.indb 18 31/5/2007 14:23:24 Gerência de Projetos de trabalho e como tal definição vem se modificando ao longo da história. Na história da humanidade o trabalho foi se organizando lentamente. Tribos nômades andavam pelo planeta há milhares de anos buscando alimentos e lutando contra as adversidades. Com a invenção de alguns artefatos e a domesticação dos animais, o homem passou de nômade a sedentário, tendo começado a construir habitações e aglomerados de casas, formando aldeias, vilas e cidades. O arranjo do trabalho se modificou, e não tendo mais que buscar o alimento por meio da caça, o homem passou a produzi-lo e estocá-lo. Alguns passaram a deter mais poder do que outros, começaram a poupar objetos de valor e terras, ampliando os domínios terrestres e até mesmo o patrimônio sobre as questões espirituais. Por essa época, surgem alguns empreendimentos feitos para marcar a presença dessas pessoas poderosas para sempre sobre a Terra. Todos se lembram das pirâmides do Egito, obras realizadas para sepultar os faraós, considerados deuses. Com esse propósito específico de sepultamento, a pirâmide era encomendada pelo próprio faraó (que iria usá-la após a morte!) e então “projetistas” e construtores desenvolviam seu desenho e passavam a executar a obra. O prazo da execução era aproximadamente o da duração da vida do faraó, ou preferivelmente menor, obviamente. Milhares de homens formavam as equipes e literalmente eram “usados” na construção, quebrando e carregando pedras até a exaustão. Unidade 1 book.indb 19 19 31/5/2007 14:23:24 Universidade do Sul de Santa Catarina Figura 1.1 - As três pirâmides do Egito, dos Faraós Quéops, Quéfren e Miquerinos. Além dos faraós muitos homens ricos encomendavam suas próprias pirâmides, cada um na medida das suas riquezas. Muitas não ficavam prontas a tempo, e vin ham então servir para o sepultamento de alguma outra pessoa. As pirâmides eram tipicamente “projetos”. Uma das mais interessantes e importantes obras já feitas pelo homem começou a ser construída 685 anos antes da Era Cristã. As Grandes Muralhas da China tiveram seu início com a pretensão de defesa de diferentes reinos, naquela época em luta pela expansão dos seus territórios (Courau, 2004). Não havia a China como tal como você conhece hoje, mas sim um conjunto de sete reinos em combate, todos buscando conquistar e anexar os vizinhos. Um desses reinos se chamava Qin (origem do nome atual da China) e foi comandado por Zheng, que por volta de 240 a 220 AC conseguiu vencer e anexar os outros reinos, unificando todos eles. E em 220 AC decidiu realizar essa obra gigantesca, ligando os trechos de muralhas existentes e criando, de fato, as Grandes Muralhas da China. Com o objetivo de separar o país dos bárbaros, e internamente definir a unidade da nação e a civilização, a obra teve um prazo de aproximadamente 10 anos de construção, uma extensão de mais de 6.000 quilômetros de muros com altura de até 16 metros e fortificações para soldados a cada 60 metros, recursos humanos da ordem de centenas de milhares de operários em regime de trabalho forçado e um plano de produção rígido (na verdade, cruel). Esse é um típico projeto. Esses são exemplos de grandes projetos da antiguidade que mudaram a história da humanidade e a maneira dos homens agirem uns em relação aos outros e em relação à natureza. 20 book.indb 20 31/5/2007 14:23:24 Gerência de Projetos Pessoas envolvidas nesses projetos começaram a perceber algumas características típicas de um projeto, que eram diferentes, por exemplo, de uma tarefa rotineira como a manutenção de um dique, o dia a dia das batalhas, ou as tarefas administrativas de condução da política imperial romana ou chinesa. Projetos têm objetivos definidos e prazo de conclusão, e para que isso aconteça com sucesso é preciso conduzir, coordenar e controlar um projeto e as pessoas que o integram. Talvez o primeiro livro sobre o assunto tenha sido “An Essay on Projects” (“Um ensaio sobre projetos”), escrito por Daniel Defoe em 1697 (Cleland, 2004). Um pouco depois, durante o século 19, os governos dos países mais desenvolvidos começaram a contratar grandes projetos de infra-estrutura, tais como ferrovias, pontes, embarcações, etc., demandando enormes esforços das companhias para a seu execução, com valores financeiros e prazos pré-definidos. Decisões importantes deviam ser tomadas nos projetos, para que atendessem às solicitações desses grandes clientes, e tais decisões eram gerenciais, administrativas. Não era mais possível escravizar milhares de homens para construir uma estrada, como tantas vezes na história já tinha acontecido. E também não havia fundos ilimitados. Além disso, a gerência desses projetos tinha que seguir algum tipo de planejamento. Um cientista da administração surge nessa época e começa a estudar detalhadamente o trabalho, mostrando que a produtividade pode ser aumentada se o trabalho for dividido em tarefas pequenas e distintas. Seu nome é Frederick Taylor (18561915), e ele é considerado o pai da ciência da administração (Sisk, 2004). Com a sua contribuição, a indústria pôde modificar seu modo produtivo e deslanchar para aquilo que se conhece hoje: em vez de um trabalhador executar todas as tarefas até concluir determinado produto, ele se ocupa apenas de uma tarefa, especializando-se nela. Com isso, a produtividade aumenta e os produtos são feitos em série. Fundamental para a revolução industrial em curso, a contribuição de Taylor também teve seu lado negativo, transformando o trabalhador numa espécie de máquina, de engrenagem dentro do processo produtivo, que tem Unidade 1 book.indb 21 21 31/5/2007 14:23:25 Universidade do Sul de Santa Catarina sido sempre muito criticada e satirizada, como no filme “Tempos Modernos” de 1936 de Charlie Chaplin – o Carlitos. Junto com Taylor trabalhava Henry Gantt (1861-1919), que estudou em detalhes as operações associadas a um trabalho, decompondo-as em tarefas. Para ver as diversas tarefas em seqüência, e como elas vão se sucedendo até o final de um determinado projeto, Gantt inventou um gráfico constituído de barras, sendo que cada barra representa uma tarefa e seu tamanho representa uma duração. Os gráficos de Gantt ficaram famosíssimos e até hoje são usados para gerenciar projetos. Você estudará esses gráficos em detalhe mais à frente nesta disciplina, e poderá conferir o quanto estes poderão ajudá-lo a gerenciar seus projetos. Na figura a seguir, veja um exemplo de gráfico de Gantt. Figura 1.2 – Exemplo de gráfico de Gantt. O reconhecimento do campo de conhecimento denominado Gerência de Projetos. Durante a Segunda Guerra Mundial, muitos projetos tecnológicos foram desenvolvidos pelos militares dos países em luta. Com o fim da guerra, evidenciou-se a existência de um campo do conhecimento específico da administração de projetos, que ficou conhecido em inglês por “project management”, e em 22 book.indb 22 31/5/2007 14:23:25 Gerência de Projetos português por gerência de projetos, ou gerência de projetos. A maior associação mundial de engenheiros eletrônicos e eletricistas – o IEEE, Institute of Electrical and Electronic Engineers – criou, em 1954, a revista Transactions on Engineering Management especialmente para discutir temas relacionados à gerência de projetos e produção em engenharia, que tem influenciado consideravelmente a área. Também nos anos 50 surgem dois métodos ( CPM e PERT ) que se tornaram muito importantes na “gerência de projetos”, disciplina que passou a fazer parte de todos os currículos de Administração e Engenharia de Produção desde então (Prado, 1998). „ O primeiro surgiu na empresa Du Pont em 1957, com o título de Método do Caminho Crítico – CPM (iniciais do título em inglês Critical Path Method). A empresa buscava melhorar suas técnicas de planejamento e controle de projetos de engenharia, e o método fez enorme sucesso desde o início. „ Quase simultaneamente a marinha americana lançou um projeto complexo para a construção de submarinos atômicos, o projeto Polaris. Devido à complexidade do projeto, ao relacionamento de diversas empresas (eram mais de 9.000 empreiteiros!), e à complexidade tecnológica envolvida, um sistema de planejamento e controle precisava ser desenvolvido. Esse sistema foi criado em 1958 e denominado PERT (Program Evaluation and Review Technique), que significa “técnica de avaliação e revisão de programas/projetos”. Na época, uma pesquisa foi realizada nos EUA para verificar como se comportavam os projetos governamentais e privados com relação ao que era planejado e ao efetivamente realizado. O quadro a seguir mostra os desvios encontrados (Prado,1998). Tabela 1.1 – Desvios no planejamento. Desvio entre o Planejado e o Realizado Projeto Desvio de tempo Desvio de custo Governamental / militar Privado 40 a 50% 40% 100 a 200% 70% Unidade 1 book.indb 23 23 31/5/2007 14:23:25 Universidade do Sul de Santa Catarina Esses dados foram divulgados e criaram polêmica. Projetos governamentais podiam superar em até 200% os custos inicialmente estimados! No entanto, com o uso do PERT, o projeto Polaris foi realizado com sucesso – dentro do orçamento e em apenas três anos. A partir daí, os métodos PERT e CPM acabaram se fundindo e assumindo inclusive o formato de Diagrama de Precedências, técnica desenvolvida na França em 1964 (Prado,1998). Você irá estudá-lo e exercitá-lo no decorrer desta disciplina. A evolução dos sistemas computacionais, na segunda metade do século XX, é que vai contribuir para a melhoria dos métodos de gerência de projetos. Mesmo porque os próprios sistemas computacionais são desenvolvidos na forma de projetos, e por isso demandam técnicas de planejamento e controle específicos. Algumas normas começaram a ser escritas para a gerência de projetos, e nos EUA foi criado o “Instituto de Gerência de Projetos” – PMI (Project Management Institute), o qual tem sido responsável pelas mais recentes e importantes contribuições nesse campo, especialmente o livro “Guide to the Project Management Body of Knowledge”, conhecido como PMBOK (PMBOK, 2004). Você irá estudar o modelo definido por esse instituto nas próximas unidades. Figura 1.3 – Logo do instituto PMI e fac-símile da capa da 3ª. Edição do PMBOK. 24 book.indb 24 31/5/2007 14:23:25 Gerência de Projetos Uma alternativa aos métodos normatizados pelo PMBOK foi apresentada por Eliyahu Goldratt em 1997, com o nome de CCPM – Critical Chain Project Management, que pode ser traduzido como “gerência de projetos pelo encadeamento crítico” (RAZ, 2004). Isso demonstra o quanto ainda está em desenvolvimento a área da gerência de projetos. Mas quem pensa que o uso de gráficos de Gantt, Caminho Crítico, PERT, CCPM e outros métodos resolveram o problema, infelizmente está enganado. No ano de 1998, The Standish Group realizou uma pesquisa nos EUA e descobriu que muita coisa estava fora do lugar. Conforme reportado pela empresa Process Quality Associates Inc., de acordo com alguns resultados contidos no quadro abaixo, procure ver o quanto ainda há por fazer. Tabela 1.2 – Estatísticas apresentando problemas típicos de projetos. Desafios e sintomas típicos de projetos Média nacional EUA (1998) Atraso Apenas 44% dos projetos são concluídos no prazo. Na média os projetos costumam atrasar em até 222% do prazo programado. Acima do custo estimado. 189% Não atingem satisfatoriamente os requisitos 70% dos projetos técnicos planejados. Cancelados antes do término. 30% dos projetos A rápida evolução da computação, especialmente da década de 1990 em diante, e também das tecnologias da comunicação e informação, onde a Internet é o maior símbolo, representa um novo desafio. É necessário criarmos métodos capazes de auxiliar a gerência de projetos, de um lado, e fazer com que tais métodos não sejam, em si mesmos, empecilhos burocráticos à dinâmica do trabalho. Uma vez compreendida a história da área gerência de projetos, a próxima seção abordará o estudo de alguns conceitos introdutórios relativos à matéria em exame. Unidade 1 book.indb 25 25 31/5/2007 14:23:26 Universidade do Sul de Santa Catarina SEÇÃO 2 - Conceitos Antes de você começar a interagir e estudar o conceito de Gerência de Projetos, é importante entender algumas definições, tentando evitar equívocos ou interpretações errôneas. 2.1. O que é projeto? A primeira palavra importante a considerar é, obviamente, “projeto”. No histórico das grandes obras e empreendimentos humanos que você acompanhou na seção anterior, pôde perceber alguns elementos em comum: prazos, objetivos, custos, recursos. Mas a importância desses componentes foi mudando com o tempo. Por exemplo, o prazo de construção das pirâmides deveria ser menor que o tempo de vida do faraó. Mas como isso não podia ser determinado, muitas vezes o serviço ultrapassava do prazo. Na construção das Muralhas da China ninguém se importava com as equipes de construtores. Morriam trabalhando e eram substituídos depois de se exaurirem, ou seja, ninguém se importava com os recursos humanos. Com o passar das eras e chegando já nos tempos modernos, pôde-se verificar que os objetivos ficaram mais claros e mais especializados, os prazos cada vez mais curtos, os custos sempre maiores, e os recursos cada vez mais escassos. Conforme Antônio Houaiss, em seu dicionário de língua portuguesa (Houaiss, 2004), projeto pode ser definido como: idéia, desejo, intenção de fazer ou realizar (algo), no futuro; plano; descrição escrita e detalhada de um empreendimento a ser realizado; delineamento, esquema. 26 book.indb 26 31/5/2007 14:23:26 Gerência de Projetos Neste livro foi adotada uma visão voltada à gerência de projetos, a qual está definida pelo Project Management Institute como: Um projeto é um conjunto de tarefas, arranjado numa seqüência ou relação definida, que produz um efeito ou saída pré-definida. Um projeto sempre tem um começo, meio e um final. (“A project is a series of tasks, arranged in a defined sequence or relationship, that produce a pre-defined output or effect. A project always has a start, middle, and an end.”) É importante ainda considerar que a visão de projeto neste livro compreende os empreendimentos voltados às áreas de tecnologia, como software e engenharia, por exemplo, e de certa forma isso os diferencia de outros tipos de projeto, como é o caso de uma campanha política, ou o projeto de salvação das baleias, dar a volta ao mundo numa bicicleta, etc. Também é importante ressaltar que o projeto tem um ciclo de vida bem definido, pois “um projeto sempre tem um começo, meio e um final”. Qual é a diferença entre projeto e tarefas de rotina / atividades contínuas? Projetos não são empreendimentos de rotina, são empreendimentos completos e independentes (Keeling, 2002), com recursos e administração próprios. Para exemplificar essa questão, veja na tabela a seguir um determinado campo de trabalho ou área de atividades humanas relacionado a um tipo de projeto, bem como a uma atividade rotineira (que não é projeto). Unidade 1 book.indb 27 27 31/5/2007 14:23:26 Universidade do Sul de Santa Catarina Tabela 1.3 – Exemplos comparativos entre atividades de rotina e projetos. Área Exemplo de projeto Exemplo de tarefa de rotina ou atividade contínua Culinária Lançamento de um restaurante temático Administração do restaurante temático Construção civil Desenhar e construir um prédio comercial Manter e operar o sistema elétrico e de automação do prédio Eletrônica Desenvolver novo tipo de condensador eletrônico Construir telefones celulares Agricultura Pesquisar planta resistente a determinado tipo de praga Plantar e colher as safras Software Pesquisar novo sistema de reconhecimento de fala Suporte técnico aos usuários de determinada plataforma Pelo quadro se percebe que, enquanto os projetos têm um objetivo preciso, fácil de medir e um resultado previsível, as atividades contínuas são planejadas a longo prazo, o controle pode mudar bastante durante o tempo, sempre procurando novas oportunidades e mesmo outros resultados, diferentes daqueles pensados no início. Lançar o restaurante, por exemplo, tem apenas um resultado: a sua inauguração. Porém sua operação pode trazer resultados tão diferentes quanto a mudança dos pratos, variações de cardápio conforme o gosto dos clientes, diminuição ou aumento da equipe conforme as vendas, mudança de gerentes, e assim por diante. 2.2. Qual é o conceito de Gerência? Conforme Houaiss (2004), em seu dicionário de língua portuguesa, gerência pode ser definida como: “ato ou efeito de gerir; administração, gerência” Uma característica de muitas disciplinas dedicadas à gerência de projetos, e da maioria dos livros sobre o assunto, é que eles se dedicam a fornecer ao estudioso um conjunto de ferramentas e metodologias, modelos de planilhas, softwares e outros 28 book.indb 28 31/5/2007 14:23:26 Gerência de Projetos dispositivos, dando a entender que isto é o que basta para uma boa gerência. No entanto, disponibilizar e ensinar a usar ferramentas e métodos de gerência é um assunto estritamente operacional, e não estratégico. Compreendo que a simples gerência de um projeto pode ser feita com o uso de ferramentas de apoio, mas o sucesso de um projeto depende de liderança e cooperação, assuntos que extrapolam, e muito, o campo operacional. Desta forma, neste livro, busque olhar a palavra “gerência” visando ir além da gerência operacional, tentando encontrar as brechas para um trabalho de liderança e cooperação, sempre voltadas a uma visão abrangente e estratégica do projeto. A gerência está associada à idéia de controle, de administração. Para Page-Jones (1990), a gerência de projetos está associada a cinco atividades: „ planejar o projeto, „ organizar todos os recursos, „ integrar os diversos elementos durante a execução do projeto, „ medir o andamento das atividades e „ revisar o plano para corrigir eventuais discrepâncias, para alcançar o objetivo do projeto. A gerência de projetos compreende as funções de planejamento, organização de recursos, distribuição e comunicação das tarefas às pessoas da equipe, com monitoramento constante das atividades e motivação do grupo para a conquista do objetivo pré-definido. Para o estudo desta disciplina, adote uma definição mais genérica, que engloba essas atividades, pois assim está sendo compreendida atualmente a função de gerência em projetos. Unidade 1 book.indb 29 29 31/5/2007 14:23:26 Universidade do Sul de Santa Catarina 2.3. Qual é a definição de Prazo? Prazo é a palavra do momento. Há uma preocupação enorme com prazos, pois os recursos são sempre escassos, e colocar um produto no mercado antes do que a concorrência pode ser o fator do sucesso. E justamente nos prazos é onde acontecem os maiores erros de previsão. Por quê? Você irá estudar isso mais adiante. Por enquanto, reflita sobre a seguinte definição de prazo: Considerando o objetivo do projeto, prazo é o tempo disponível para se chegar ao resultado. 2.4. Como é a definição de recursos na abordagem desta disciplina? É comum confundir recursos com dinheiro, ou recursos com custos. Porém, extraia deste estudo uma definição mais abrangente, pois as condições financeiras possibilitam obter diversos recursos, mas não todos. Veja o caso em que se precisa de um determinado especialista, um engenheiro de grandes estruturas, por exemplo. Mesmo com dinheiro para contratá-lo, é possível que não exista alguém com disponibilidade. Uma definição útil é: Recursos são as condições econômicas, materiais, equipamentos e pessoal necessário para desenvolver determinado projeto a contento. 30 book.indb 30 31/5/2007 14:23:26 Gerência de Projetos 2.5. E a definição de custos? Idéias maravilhosas, projetos visionários, nada disso pode ser concretizado se não houver condições de pagar os custos de desenvolvimento. Recursos são necessários, os equipamentos custam dinheiro, materiais de consumo também, cada vez mais caras são as horas de trabalho das pessoas e dos especialistas, em particular. Custos são os gastos financeiros necessários para que todos os outros recursos sejam adequadamente distribuídos no projeto, desde o início até a sua conclusão. 2.6. E a Equipe de trabalho? O principal elemento de um projeto, independentemente de sua dimensão ou importância, é o conjunto de pessoas responsáveis pela sua consecução. Impossível seria construir as muralhas da China sem os milhares de operários que lá estiveram, e no entanto, eles eram considerados descartáveis, trabalhavam como escravos. Com o avanço da civilização isso mudou, e além de imprescindível num projeto, o homem passou a ter “valor”. Mas projetos (a não ser os muito pequenos) não são para um homem só. Precisam constituir grupos, com atividades e responsabilidades diversas, interagindo todo o tempo e em busca de um objetivo comum. Com isso chega-se ao trabalho cooperativo. Em projeto, é imprescindível a presença de grupos de pessoas trabalhando de forma cooperada. Nesta disciplina, conceba como conceito de equipe de projeto o seguinte: Unidade 1 book.indb 31 31 31/5/2007 14:23:26 Universidade do Sul de Santa Catarina Grupo de indivíduos dedicados ao projeto, com funções e responsabilidades bem definidas, trabalhando em regime de cooperação e focados no sucesso da empreitada. SEÇÃO 3 - Como se dá a motivação para o projeto? Se um projeto tem origem numa idéia, por causa de uma necessidade social, comercial ou por um novo conhecimento tecnológico disponível, para que ele possa crescer e chegar à etapa do desenvolvimento e ir até o final, chegando a um resultado próximo do esperado, ele precisa de uma motivação que o alimente. Diversas são as motivações possíveis, desde o empenho unicamente pessoal até um contrato abrangente e inviolável. Você irá estudar nesta disciplina algumas dessas motivações, sabendo antecipadamente que muitas vezes elas estão mescladas no dia a dia dos projetos, umas com mais força, outras menos. São exemplos de motivação: Alguém em uma pequena empresa teve a “visão” de um novo produto, que acredita ser capaz de alterar o futuro de sua empresa. Essa visão passa a ser então um guia e um objetivo, capaz de motivar e ajustar cada momento de desenvolvimento do projeto que é então gerado. Os líderes são muitas vezes movidos por essas “visões”, que são perseguidas constantemente até o final, sem descanso. Tal visão pode surgir na busca de resolver um problema, pessoal ou empresarial. Para uma determinada empresa que vem perdendo posições no mercado, o projeto de um novo produto pode nascer como a reação ao produto concorrente que vem se destacando. Essa “reação” comercial motiva o nascimento e a execução do projeto, geralmente com forte pressão por resultados e prazos. É uma motivação reativa. 32 book.indb 32 31/5/2007 14:23:27 Gerência de Projetos Por outro lado, a empresa ativa busca sua ampliação no mercado não apenas pela reação ao que já surgiu, mas pela criação de novos produtos. Essa cultura criativa define as empresas que lideram o mercado, pois constantemente estão criando produtos inovadores ou lançando novas formas de se relacionar com seus clientes, o que acaba mudando o comportamento geral do mercado e as favorece. Como não podia deixar de ser, as empresas criativas são mais raras do que as reativas, e ambas são motivadas pela competição. Nos casos anteriores há uma motivação que é o denominador comum: sucesso da empresa. Esse motivador movimenta o mundo do capital e está na base do crescimento econômico. Também há o motivador que é o sucesso pessoal, perseguido não pelas empresas, mas pelos indivíduos. Na base do sucesso pessoal, um dos grandes motivadores é o ganho financeiro. O prêmio em dinheiro dá motivação para perseguir o projeto até o final, mesmo que a pessoa muitas vezes não dê valor algum ao projeto em si, mas simplesmente à remuneração. Fora do campo puramente pessoal ou empresarial, o progresso social pode ser um grande motivador no desenvolvimento de projetos. Parece ser esse o caso dos projetos ecológicos e ambientalistas, onde um determinado grupo social, interessado em melhorias locais ou regionais, empreende projetos de caráter específico. Sindicatos, associações, organizações civis de interesse público e partes do governo também são geradores de projetos especiais, voltados ao bemestar social. Unidade 1 book.indb 33 33 31/5/2007 14:23:27 Universidade do Sul de Santa Catarina Como se dá o nascimento de projetos de Tecnologia? Os projetos das áreas tecnológicas nascem de uma sucessão de avanços no conhecimento humano. Tais conhecimentos vão se acumulando, e uns se servem dos outros para avançar sempre mais, seja questionando-os, seja aprimorando-os e transformando-os. Acompanhe a figura a seguir, inspirada no trabalho de Jay Paap (2004), que mostra um modelo de inovação tecnológica. Figura 1.4 - Um modelo de inovação tecnológica. Necessidades que surgem no negócio, ou na vida diária das pessoas, ou de renovação do mercado, enfim, problemas que surgem todos os dias, estão constantemente nos desafiando a buscar novas soluções. Quando alguém aceita esse desafio, e simultaneamente há conhecimentos científicos e tecnológicos disponíveis, idéias surgem. Uma criteriosa seleção dessas idéias pode levar ao desenvolvimento de novos produtos ou novos processos que, se alcançarem sucesso, serão amplamente utilizados e difundidos. A transformação dessas idéias em produtos ou processos é considerada uma Inovação Tecnológica, e pode ser algo tão simples como uma nova maneira de assentar tijolos numa construção, ou tão complexa quanto lançar uma nova linguagem de programação. Cada ciclo tecnológico tem origem numa inovação. 34 book.indb 34 31/5/2007 14:23:31 Gerência de Projetos A inovação tecnológica pode ser caracterizada como a primeira vez em que se utiliza um determinado produto, processo, sistema ou serviço, sejam novos ou melhorados, introduzidos num determinado mercado, ou numa produção. O centro de gravidade da inovação tecnológica é a empresa. Os processos inovadores são bastante complexos, pois estão ligados ao desenvolvimento de projetos nas áreas de engenharia e tecnologia avançadas, e com isso podem apresentar as seguintes incertezas: „ são irregulares, quando há diferentes etapas de trabalho, possibilidades de retrocessos, re-análises constantes, etc; „ são de alto risco, quando não há certeza de que corresponderão ao que originalmente foi imaginado; „ são excessivamente lentos ou prolongados, com resultados que demoram para chegar ao mercado, muitas vezes comprometendo sua receptividade. Como melhor conduzir os projetos de inovação tecnológica? Projetos de inovação tecnológica, nas empresas, podem assumir a metodologia científica, onde quatro passos críticos estão colocados para a solução de um problema: 1. Definir o problema, ou seja, caracterizar adequadamente os seus limites, saber o que se pretende resolver com a maior exatidão possível. 2. Descrever o problema, determinando onde está inserido e com que outros fatos o problema está relacionado. A descrição do problema deve ser feita com o máximo de detalhamento. Unidade 1 book.indb 35 35 31/5/2007 14:23:32 Universidade do Sul de Santa Catarina 3. Formular hipóteses de solução, que possam ser estudadas e testadas dentro do escopo do trabalho. Nessa etapa será criado um plano de trabalho. 4. Executar o projeto de pesquisa propriamente dito, verificando as hipóteses, testando as possibilidades, confirmando e rejeitando soluções intermediárias, a fim de obter os resultados esperados. Uma vez compreendidos alguns conceitos introdutórios ao estudo da área de Gestão de projetos, na próxima seção conheça quais são os tipos de projetos. SEÇÃO 4 - Tipos de projeto? Os projetos podem ser classificados em diversas categorias, e essa classificação vai variar conforme os interesses comerciais, científicos e industriais, ou então conforme os graus de dificuldade, ou mesmo conforme o ambiente em que se desenvolvem. A seqüência de estudo sugere que você conheça algumas dessas possíveis divisões, e ao final propõe a sistematização dessas classificações, de modo a facilitar a visão estratégica sobre tipos de projetos. Como os projetos podem ser classificados? Quais são os tipos existentes? Os projetos podem ser classificados: „ De acordo com o que você estudou nas Seções 1 e 2 desta Unidade, eles podem ser classificados quanto à natureza científica e tecnológica, e neste sentido podem ser, a grosso modo, divididos nos seguintes tipos: a) Projetos de Pesquisa – são os projetos científicos, que geralmente acontecem em universidades e centros de pesquisa, e nascem da idéia de pesquisadores e linhas de pesquisa já 36 book.indb 36 31/5/2007 14:23:32 Gerência de Projetos em andamento; podem ser de pesquisa básica, quando direcionados a resolver problemas genéricos e teóricos, sem aplicação prática em vista, ou de pesquisa aplicada, quando voltados a usar uma teoria em alguma nova aplicação, não necessariamente útil de imediato; b) Desenvolvimento Tecnológico – ao contrário dos projetos científicos, os projetos de desenvolvimento tecnológico nascem da idéia de empresários e engenheiros, e estão orientados diretamente ao mercado, buscando introduzir inovação tecnológica, seja em produtos diretamente para a venda, ou em processos de produção ou comercialização dentro das empresas; por serem projetos de inovação, estão fortemente associados ao conhecimento científico gerado em pesquisas básicas e/ou aplicadas; c) Engenharia – são os que se baseiam em conhecimentos e tecnologias dominadas, e estão voltados a construir protótipos e produtos com aplicação bem definida; os projetos de engenharia mais comuns que conhecemos são os da construção civil. Outra forma de dividir os projetos está relacionada à sua origem institucional. Neste caso, não estamos fazendo distinção entre ciência, tecnologia ou engenharia, mas sim quanto ao tipo de instituição que os originou. Uma possível divisão desses projetos seria a seguinte: a) Comerciais – são os projetos que nascem dentro das empresas buscando diferencial competitivo no mercado; pode ser a idéia de um novo produto, baseada em estatísticas e pesquisas realizadas junto ao consumidor, ou a necessidade de modificação de um processo de venda ou de produção, com foco em melhoria comercial; lançamentos de novas embalagens, novas versões de software e novas formas de entrega para o consumidor são exemplos desse tipo; Unidade 1 book.indb 37 37 31/5/2007 14:23:32 Universidade do Sul de Santa Catarina Chamamos de chão de fábrica o ambiente onde geralmente estão instaladas as máquinas da indústria, e onde o processo operacional de produção acontece; não inclui, por exemplo, as áreas de administração, vendas, compras e projetos. Do inglês lay-out, representa um esboço ou modelo genérico de disposição de peças, móveis e equipamentos num ambiente. Máquina-ferramenta é aquela que é usada para fabricar outras máquinas, mais especificamente para dar forma a objetos sólidos como madeira e metal, os quais serão usados como peças em outras máquinas. b) Industriais – muito próximos dos projetos do tipo “comercial”, também estão objetivando diferencial competitivo; no entanto são desenvolvidos no interior da indústria buscando melhorias no processo produtivo do chão de fábrica, sem um relacionamento direto com perspectivas comerciais (apesar de estar claro que tais melhorias vão colaborar na qualidade de todo o sistema); são projetos que vão desde uma modificação de leiaute no chão de fábrica, passando por projetos de introdução de automatismos em máquinas até a criação de novas máquinas-ferramenta; c) Governamentais – os governos são grandes geradores de projetos, e alguns envolvem toda a sociedade e podem até mesmo mudar os rumos de uma região ou de um país; em tese, nascem das necessidades sociais e de visões estratégicas para buscar suprir tais necessidades, mas o que se vê geralmente são as vaidades políticas e a visão limitada como geradores de tais projetos, que muitas vezes acabam em gastos inúteis do dinheiro público; mas certamente há também os projetos de sucesso, muitas vezes polêmicos, que são capazes de modificar todo um panorama histórico; e há também os projetos de pequeno porte, igualmente importantes, que mudam, por exemplo, o trânsito de um bairro ou introduzem ali uma área verde e de preservação; d) De fomento – projetos de fomento são também, em geral, governamentais, mas se distinguem um pouco daqueles por estarem voltados a desenvolver algum aspecto da economia e/ou tecnologia, ou seja, buscam criar ambientes favoráveis para que a iniciativa privada se desenvolva; importantíssimos por sua característica de apoio estrutural, um bom exemplo desse tipo de projeto é a criação de parques tecnológicos e incubadoras de empresas, fomentadores de novos negócios e de inúmeros outros projetos de inovação dentro dessas empresas ou idéias nascentes (cabe aqui ressaltar que a Unisul criou e mantém uma incubadora, com o apoio do governo de Santa Catarina); 38 book.indb 38 31/5/2007 14:23:32 Gerência de Projetos e) Acadêmicos – são os projetos que se desenvolvem dentro do ambiente das instituições educacionais, tais como monografias e teses, bem como softwares e outros produtos, caracterizando-se por uma relativa distância das aplicações industriais. É possível fazer uma separação de tipos de projeto também quanto ao seu impacto no conhecimento ou no mercado, independente de sua origem ou de sua natureza técnica. Essa divisão pode ajudá-lo a ver determinado projeto em relação à sua “ambição”: a) Impacto tecnológico ou Breakthrough – tipo de projeto que se caracteriza por resultar em considerável impacto em uma tecnologia ou em um mercado, modificando hábitos de consumidores e alterando completamente a finalidade da tecnologia anterior; é um tipo raro de projeto, porque intrinsecamente é de risco, não se sabendo determinar se terá sucesso, o qual muitas vezes nem era esperado; veja-se o exemplo da introdução dos compact discs no mercado musical, que praticamente aboliu o uso de discos de vinil e fitas magnéticas, ou o caso do uso da transmissão por rádio na telefonia, que em poucos anos está mudando completamente o cenário das telecomunicações mundiais; b) Plataforma ou sistema – projeto que envolve inúmeros conhecimentos e módulos diferentes, geralmente composto por uma série de pequenos projetos (os derivados), que serão depois arranjados num sistema único e maior; tipicamente é multidisciplinar, envolvendo conhecimentos diversos e várias áreas; o atual projeto de desenvolvimento do sistema de televisão digital brasileiro é um exemplo; c) Isolados – são aqueles projetos independentes, não vinculados a um sistema e nem derivados de uma necessidade de melhoria; basicamente são os projetos criados por indivíduos (como o desejo de uma casa, por exemplo) ou de uma pequena empresa para lançar um novo produto no mercado; Unidade 1 book.indb 39 39 31/5/2007 14:23:32 Universidade do Sul de Santa Catarina d) Projetos Derivados – caracterizam-se por ser projetos pequenos e de prazo curto, derivados de outros maiores ou de requisições de melhorias em sistemas já em funcionamento regular; são exemplos as criações de novos leiautes de embalagem, um determinado móvel ou novo dispositivo em uma máquina-ferramenta. Como definir o tipo de projeto tecnológico? Recentemente Dov Dvir et al. (2004) desenvolveram e passaram a aplicar um esquema genérico para definir tipos de projetos. Esse esquema, ou framework, foi denominado de “Modelo UCP” (iniciais de Uncertainty, Complexity e Pace, que pode ser traduzido aqui por Incerteza, Complexidade e Prazo), sobre o qual é possível classificar os diversos tipos de projetos tecnológicos. O desenho da figura a seguir mostra esse modelo como uma configuração de três dimensões, onde cada eixo representa uma das variáveis, tendo cada projeto uma posição nesse espaço, conforme sua posição relativa em cada eixo. Figura 1.5 – Modelo UCP para classificação de projetos (DVIR et al., 2004). Devido a sua utilidade na definição dos tipos de projeto, a seguir você irá acompanhar um pouco mais o modelo de Dov Dvir et al, a descrição dos eixos e suas subdivisões. 40 book.indb 40 31/5/2007 14:23:32 Gerência de Projetos „ O eixo da Incerteza apresenta os diferentes níveis de incerteza que um projeto pode assumir, seja quanto ao tempo necessário para sua execução, quanto aos recursos e equipe que serão alocados, a tecnologia disponível e mesmo sobre a qualidade e sucesso do resultado final. Nesse sentido, os criadores do Modelo UCP dividem os projetos em quatro tipos: a) Tipo A – Baixa Tecnologia: são aqueles projetos baseados em tecnologias existentes e dominadas, onde não há necessidade de nenhum desenvolvimento ou conhecimento adicional, a não ser os já disponíveis; os projetos de construção civil são típicos deste nível, pois o grau de incerteza tecnológica é mínimo, e o mesmo tipo de projeto já foi realizado inúmeras vezes, não havendo o que inventar; por esse motivo a gerência deve ser rígida e não permitir variações no plano original; b) Tipo B – Média Tecnologia: também são baseados em tecnologias existentes, porém podem incorporar alguma novidade no desejo de criar algum diferencial para o produto resultante; esse tipo de projeto tem poucas incertezas e geralmente acontece em indústrias tradicionais e bem estabelecidas onde o desenvolvimento tecnológico ocorre lentamente, como é o caso da indústria automobilística ou de máquinas pesadas, onde apesar do domínio tecnológico também é preciso incorporar algum novo dispositivo ou elemento; devido às poucas incertezas, a novidade é incorporada rapidamente ao produto, geralmente depois de um ou dois ciclos de desenvolvimento do projeto; c) Tipo C – Alta Tecnologia: são os projetos onde as tecnologias a serem empregadas são novas, apesar de já existirem quando o projeto se inicia; a alta tecnologia se expressa porque tais tecnologias pela primeira vez estarão integradas num determinado produto ou processo, e o desenvolvimento de tal projeto passa a ter uma Unidade 1 book.indb 41 41 31/5/2007 14:23:32 Universidade do Sul de Santa Catarina série de incertezas, caracterizando-se por ter longos períodos de planejamento, modelagem, desenvolvimento e revisões, que exigem muitas vezes retornar ao início do processo, levando a variações grandes de custos e de modificações nos prazos originalmente definidos; para que aconteça uma estabilização da tecnologia são necessários vários ciclos de projeto e reprojeto, até a consolidação do produto/processo; d) Tipo D – Super Alta Tecnologia: esse é o tipo de projeto mais raro, onde se tem um objetivo claro, porém ainda não há tecnologias disponíveis para realizá-lo; somente governos e empresas muito grandes se lançam nesse tipo de projeto, onde o grau de incerteza é elevadíssimo, e que levará a inúmeros outros projetos derivados para buscar as tecnologias necessárias; o projeto Genoma pode se caracterizar como sendo desse tipo, assim como o projeto aeroespacial Apollo, que pretendia levar o homem até a Lua e envolveu milhares de pessoas e pesquisadores, conseguindo finalmente obter o resultado desejado, e junto a isso gerou uma enorme variedade de subprodutos e novas tecnologias; a figura abaixo representa as classificações no eixo das Incertezas com relação às tecnologias envolvidas. Figura 1.6 – Eixo das Incertezas no Modelo UCP (DVIR et al., 2004). 42 book.indb 42 31/5/2007 14:23:33 Gerência de Projetos „ O eixo da Complexidade relaciona os diferentes projetos quanto à complexidade do sistema em desenvolvimento, e dessa forma o nível de gerência necessária. Inúmeros elementos podem estar relacionados num projeto, e a forma como eles se relacionam é que define os níveis de complexidade, conforme os seguintes níveis: a) Nível 1 – Montagem: são projetos onde diferentes elementos são arranjados em composições simples, ou simples montagens, de tal forma que o resultado se configura num único produto com funções bem determinadas como por exemplo, uma máquina; nesse nível de complexidade os projetos geralmente são desenvolvidos internamente por uma empresa, sem relações externas; b) Nível 2 – Sistemas: os projetos com nível de complexidade maior, que envolvem inúmeros elementos e diferentes equipes, de diferentes empresas e subcontratados, têm maior nível de complexidade e são chamados nesse modelo de “Sistemas”; são exemplos desse tipo um novo projeto de automóvel ou avião, ou a reengenharia de uma empresa inteira; c) Nível 3 – Supersistemas: são aqueles formados por inúmeros outros sistemas, em geral dispersos entre diferentes empresas e categorias tecnológicas, que precisam agir em conjunto em busca dos resultados definidos pelo contratante, muitas vezes uma instituição governamental ou consórcio de empresas; a construção do túnel que liga a Inglaterra à França é um exemplo desse tipo, assim como a construção do metrô de São Paulo; a gerência desse tipo de projeto envolve inúmeros gestores e uma imensa quantidade de documentos e relatórios, de forma a coordenar esforços de diferentes organizações e lugares; o eixo da Complexidade quanto aos sistemas envolvidos é apresentado na figura a seguir. Unidade 1 book.indb 43 43 31/5/2007 14:23:33 Universidade do Sul de Santa Catarina Figura 1.7 – Eixo da Complexidade no Modelo UCP (DVIR et al., 2004). „ O eixo dos Prazos divide os projetos quanto ao tempo disponível ou necessário para o seu desenvolvimento. Como você estudou na Unidade 1, os prazos são ultrapassados na grande maioria dos projetos, gerando custos não previstos e atrasos na entrega aos clientes, e por esse motivo são uma fonte enorme de preocupação. Nesse sentido, os criadores do Modelo UCP identificam três tipos de projetos quanto aos “prazos”: a) Regulares: são aqueles projetos onde existe um prazo definido, mas há razoável tolerância aos atrasos e modificações de agenda, como acontece, por exemplo, na construção de edifícios residenciais e em estradas; perturbações e modificações de investimento são toleradas e admissíveis; apesar de não desejáveis, temos exemplos comuns em projetos de implantação de sistemas de software gerencial em empresas (os ERPs), e são tolerados porque se admite que há fatores não percebidos no começo do projeto e que o atrasam, e a importância da sua implantação é preponderante, independente do prazo; b) Competitivos: são os projetos mais comuns no ambiente industrial/empresarial, e estão endereçados a novas oportunidades de negócios, posicionamento estratégico ou lançamento de novas linhas de produtos; nesses casos a perda do prazo não é fatal para a empresa, 44 book.indb 44 31/5/2007 14:23:33 Gerência de Projetos mas atrasos podem ser o motivo de fracasso em um lançamento e a perda de liderança em determinado mercado; c) Críticos: são os projetos onde o atraso significa o fracasso total, implicando em falência ou derrota; projetos desse tipo surgem em fases críticas, como por exemplo, em guerras, quando projetos militares precisam ser concluídos no tempo justo; por esse motivo, a gerência é rigorosa e há pouco tempo para documentação e outros tipos de burocracia, levados ao mínimo necessário (veja a figura a seguir). Figura 1.8 – Eixo dos Prazos no Modelo UCP (DVIR et al., 2004). Considerando os eixos apresentados, é possível posicionar um projeto ou situação de determinado produto, e buscar então um novo posicionamento estratégico. É o que se dá no exemplo do artigo citado de Dvir et al. (2004), que relata o caso do desenvolvimento de um sistema de controle e proteção contra incêndios. Na figura a seguir é representada a atual posição do produto e a posição futura numa disposição bidimensional. Unidade 1 book.indb 45 45 31/5/2007 14:23:33 Universidade do Sul de Santa Catarina Figura 1.9 – Exemplo de projeto apresentado no artigo de DVIR et al. (2004). É importante ter uma compreensão de como os projetos se dividem, sabendo que os diversos esquemas se ajustam aos projetos conforme o ponto de vista que estamos tomando para estudá-los ou prepará-los. Com essa compreensão é possível ter sempre uma visão estratégica na criação e na gerência do projeto. Agora que você já acompanhou a leitura desta unidade, para praticar os novos conhecimentos, realize as atividades propostas a seguir e no EVA. Atividades de auto-avaliação Leia com atenção os enunciados e realize as atividades. 1) Considerando que projetos têm “objetivos definidos e prazo de conclusão”, encontre um exemplo de projeto em sua própria experiência, ou na história, e descreva o mesmo. 46 book.indb 46 31/5/2007 14:23:33 Gerência de Projetos 2) Com respeito à administração dos projetos ao longo da história, você estudou que houve um momento em que se passou do trabalho realizado sem planejamento para um início de teorização e implantação de práticas gerenciais. Em que época isso acontece, e por que motivos? 3) Na seqüência veja os dois quadros. O primeiro é de um levantamento realizado em 1958, e o segundo tem dados de 1998. Compare os índices, analise se houve mudanças nesse período, e a seguir, descreva suas observações nas linhas em branco. Quadro 1.1 – Desvios no planejamento (1958). Desvio entre o Planejado e o Realizado Projeto Desvio de tempo Desvio de custo Governamental / militar Privado 40 a 50% 40% 100 a 200% 70% Quadro 1.2 – Estatísticas apresentando problemas típicos de projetos (1998) Desafios e sintomas típicos de projetos Atraso Média nacional EUA (1998) Apenas 44% dos projetos são concluídos no prazo. Na média os projetos costumam atrasar em até 222% do prazo programado. Acima do custo estimado. 189% Não atingem satisfatoriamente os requisitos técnicos planejados. 70% dos projetos Cancelados antes do término. 30% dos projetos Unidade 1 book.indb 47 47 31/5/2007 14:23:34 Universidade do Sul de Santa Catarina 4) Considere o quadro a seguir, onde exemplos de projetos são comparados com exemplo de tarefas de rotina. Escreva no quadro alguns novos exemplos para as áreas determinadas. Área Exemplo de projeto Exemplo de tarefa de rotina ou atividade contínua Concessionária de energia elétrica Software Indústria Automobilística Bancos Governo 5) Veja o diagrama a seguir. Pesquise um produto ou serviço presente no mercado que tenha sido desenvolvido seguindo esses passos, e descreva brevemente as diversas etapas. 48 book.indb 48 31/5/2007 14:23:34 Gerência de Projetos 6) A figura a seguir apresenta o Modelo UCP de classificação de projetos. Considere os seguintes casos, classificando-os e marcando no gráfico: ( A ) A construção de uma casa, e classifique esse projeto segundo o modelo UCP, marcando no desenho com eixos “complexidade x incerteza” a posição relativa do projeto. ( B ) Faça o mesmo considerando um projeto de desenvolvimento de software para controle de biblioteca, por exemplo, e faça a marcação. ( C ) Em Santa Catarina está sendo desenvolvido o projeto de um novo carro, com tecnologia brasileira e tração 4x4. Classifique e marque também este projeto no desenho. Comente no final as diferenças que você vê entre os três tipos de projeto. Unidade 1 book.indb 49 49 31/5/2007 14:23:34 Universidade do Sul de Santa Catarina Síntese Nesta unidade você estudou como os projetos se desenvolveram na história da humanidade, e como eles se separaram, primeiro na prática, depois conceitualmente, das atividades rotineiras e contínuas. Aprendeu os principais conceitos sobre projetos e gerência, avaliando os motivos que levam à sua realização. Alguns tipos de classificação de projeto foram apresentados, e o principal deles, o Modelo UCP, atribui níveis de incerteza, complexidade e prazo, o que permite ao gestor uma visão ampla das características do trabalho que o espera. Com base na motivação do projeto, pode-se passar à fase de análises de viabilidade e planejamento, assuntos da próxima unidade. Até lá! Saiba mais Para aprofundar os temas abordados na unidade sugere-se: 1. www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=177 - link para estudo da SOFTEX, Sociedade para Promoção da Excelência do Software Brasileiro, sobre os mercados de software do Brasil, China e Índia. 2. http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=37 nesse link há um conjunto de estudos e artigos sobre a situação do software no Brasil, constantemente atualizados e que permitem uma visão ampla das oportunidades de negócio no mercado da informática. Links úteis Alguns links são muito úteis para a comunidade de ciência e tecnologia. Dê uma olhada nestes abaixo: 1. www.finep.gov.br – este é o sítio da Financiadora de Estudos e Projetos, do Ministério de Ciência e Tecnologia do Brasil. Vários editais de financiamento para inovação tecnológica são colocados ali constantemente, e são dedicados ao fomento 50 book.indb 50 31/5/2007 14:23:34 Gerência de Projetos industrial e empresarial. Há inclusive investimentos em projetos tecnológicos a fundo perdido, ou seja, não reembolsáveis. No sítio da Finep você vai saber como está o andamento da maioria dos grandes projetos tecnológicos do país. 2. www.cnpq.br – o Ministério da Ciência e Tecnologia também dispõe do Conselho Nacional do Desenvolvimento Científico e Tecnológico – CNPq – que também financia bolsas e projetos tecnológicos diversos, com ênfase em pesquisadores e desenvolvedores cursando graduação ou recém formados. Além disso, traz uma série de informativos e editais importantes. 3. Veja no seguinte sítio um artigo muito interessante sobre criatividade no desenvolvimento de novos projetos. Aponta oito tópicos como importantíssimos para a carreira criativa na área de desenvolvimento de tecnologia. http://carreiras.empregos. com.br/carreira/administracao/comportamento/131101criatividade_fraley.shtm 4. Veja no Brasil a ANPEI - Associação Nacional de Pesquisa, Desenvolvimento e Engenharia das Empresas Inovadoras, cujo sítio é www.anpei.org.br . Vários artigos importantes, estatísticas e outras informações sobre projetos de pesquisa e inovação tecnológica, bem como oportunidades de negócios. Unidade 1 book.indb 51 51 31/5/2007 14:23:34 book.indb 52 31/5/2007 14:23:34 UNIDADE 2 Análise do projeto 2 Objetivos de aprendizagem Ao final desta unidade você terá subsídios para: „ Compreender a importância da avaliação e análise prévia em projetos. „ Constatar que os requisitos do cliente definem o planejamento geral do projeto, que deve ser elaborado a partir de um algoritmo. „ Analisar a questão dos prazos, sua influência na viabilidade de um projeto, e quais os riscos inerentes ao processo. „ Conhecer algumas das ferramentas computacionais que apóiam o planejamento dos projetos. Seções de estudo A seguir, apresentam-se as seções para você estudar. Seção 1 Seção 2 Seção 3 Seção 4 Seção 5 Seção 6 Seção 7 Avaliação inicial Requisitos do cliente e solução de problemas Algoritmo do projeto Prazo Viabilidade do projeto Antecipando e administrando riscos Ferramenta de apoio para análise e planejamento Após a leitura dos conteúdos, realize as atividades propostas no final da unidade e no EVA. book.indb 53 31/5/2007 14:23:34 Universidade do Sul de Santa Catarina Para início de estudo Nesta unidade você irá ver que é fundamental, para o sucesso de um projeto, que seja feita uma análise ampla do problema a ser resolvido. O cliente, aquele que está solicitando o projeto, muitas vezes não consegue mostrar todas as nuances do problema, então uma análise profunda e ampla será necessária. Junto à definição dos motivos do projeto, está o estabelecimento de um “caminho bem planejado” para sua execução, que será traduzido aqui por “algoritmo” do projeto, o qual permite traçar um caminho preciso de execução. Os métodos de planejamento partem desse algoritmo para avaliar os recursos necessários e fazer o planejamento das etapas de desenvolvimento. Também será analisada a questão do prazo e dos riscos de um projeto que podem ser previstos e, desta forma, criadas alternativas para sua administração. Além disso, muitas ferramentas computacionais têm surgido ultimamente para apoiar o planejamento dos projetos. Ao longo deste estudo você irá conhecer algumas delas e saber como utilizá-las para estabelecer um plano geral. Ao estudo! SEÇÃO 1 - Avaliação inicial Para que os projetos tenham sucesso é preciso ter, antes de tudo, uma visão clara sobre a sua finalidade e sobre o resultado final esperado. Em recente artigo sobre lideranças em equipes de projetos, Christenson e Walker (2004) definem esse tipo de atitude, vinculada a uma comunicação objetiva do projeto, como fatores essenciais para que toda a equipe tenha real compromisso com o seu sucesso. Você viu na unidade anterior que uma série de diferentes fatores influencia no surgimento de um projeto. Mas para que ele tome forma e possa evoluir ainda há muito que fazer. Quem 54 book.indb 54 31/5/2007 14:23:34 Gerência de Projetos encomendou o projeto, quem teve a idéia, quem sentiu a sua necessidade, muitas vezes não sabe exatamente o que quer nem aonde quer chegar. A primeira pergunta que se deve fazer, nesses casos, é: Qual é o problema? Você irá se surpreender com a resposta, pois o real problema não aparece, e em seu lugar vêm meias palavras e pedaços de problemas. Para chegar a sua raiz é preciso argumentar um pouco mais, na tentativa de clarear a própria idéia do projeto, pois geralmente o usuário, o fabricante, o empresário, não tem clareza sobre o problema a ser resolvido. - preciso melhorar o tempo de produção desta linha de montagem. É de fato um “grande” problema, e então seria necessário contar com um “grande” projeto (sem saber direito que projeto seria esse). Talvez o tempo da linha de montagem seja grande porque, ao finalizar cada etapa da montagem, alguém pára para contar peças. - Então, se houvesse um sistema de contagem automático, esse tempo poderia ser reduzido. Essa automação poderia ser um contador em determinados trechos da esteira, o que já existe no mercado, basta comprar e instalar. Porém, seria necessário pegar os dados gerados pelo contador e envia-los para o departamento de estoque, onde planilhas são construídas. Bem, esse processo de análise pode ir bem longe, até se chegar de fato a um problema com uma solução a ser implementada, e para se ter tal solução um projeto será criado. Parece simples, mas não é. Unidade 2 book.indb 55 55 31/5/2007 14:23:34 Universidade do Sul de Santa Catarina O primeiro passo, o passo fundamental, é transformar o assunto no qual está inserido o “problema” em uma definição exata, pois um trabalho de desenvolvimento só tem sentido quando se procura uma solução, ou seja, quando se sabe o resultado a ser obtido, o que só acontece quando há clareza no problema a ser resolvido. A isso se denomina escopo do problema. Clientes têm idéias confusas sobre os seus próprios desejos. E se nossa tarefa é criar soluções para problemas de tecnologia complexos, será preciso envolver a associação de conhecimentos: „ adquiridos em etapas de pesquisa e desenvolvimento científico e/ou; „ de engenharia e/ou; „ empíricos. Não parece fácil. Quanto maiores a complexidade e incerteza do projeto a ser trabalhado, maior a necessidade de envolver diferentes membros na equipe, buscando complementaridades. Da mesma maneira, para que se aproxime do problema, é preciso criar para ele um modelo de representação. Na tentativa de definir um problema, há duas maneiras de encará-lo: „ Partido geral, ou amplo: definir o problema de maneira ampla permite criar soluções menos usuais, pois o universo de análise é maior. Com isso se quer dizer que ângulos diferentes podem ser analisados, e soluções que 56 book.indb 56 31/5/2007 14:23:35 Gerência de Projetos estavam fora do alcance de visão do cliente ou da equipe, por exemplo, podem surgir e resolver a questão. Observe a figura: Soluções abrangentes e variadas Visão ampla Efeitos não visíveis Causas não visíveis Efeitos não visíveis Causas e efeitos visíveis REGIÃO DO PROBLEMA Causas não visíveis Figura 2.1 – Representação esquemática do problema com abordagem de “visão ampla”. Na figura, você observou que na região do problema há várias causas e efeitos que não estão imediatamente visíveis, a não ser que um partido geral seja tomado, e que uma capacidade de visão ampla esteja em ação. Com isso, vários aspectos podem ser analisados, e propostas de soluções abrangentes e variadas podem ser assumidas. „ Partido restrito: Visões restritivas levam a soluções de pequeno alcance, ao contrário de uma percepção ampla que pode levar a soluções de maior alcance. Problemas atacados desde o início de maneira pormenorizada podem gerar soluções deslocadas, e um gasto excessivo de tempo e dinheiro. Observe a figura: Unidade 2 book.indb 57 57 31/5/2007 14:23:35 Universidade do Sul de Santa Catarina Solução restrita Visão restrita Efeitos não visíveis Causas não visíveis Efeitos não visíveis Causas e efeitos visíveis REGIÃO DO PROBLEMA Causas não visíveis Figura 2.2 – Representação esquemática do problema com abordagem de “visão restrita”. Você percebeu na figura, que onde um conjunto de causas e efeitos não está no campo de visão dado por um partido restrito. Isso gera uma solução de alcance limitado, que muito provavelmente não agirá sobre causas e efeitos não percebidos. Considero essa dualidade de visões, a ampla e a restrita, como o problema fundamental das áreas de pesquisa, desenvolvimento e engenharia, seja em setores de software ou de construção, da indústria ou do serviço, da nossa vida profissional ou da nossa vida privada. Por esse motivo, vou explorar um pouco mais esses conceitos com alguns exemplos e estudos de caso (obviamente com a expectativa de influenciar você a buscar um partido amplo!). Leia com atenção: 58 book.indb 58 31/5/2007 14:23:35 Gerência de Projetos Caso 1 – implantação de um ERP Conheci uma empresa que tinha várias filiais espalhadas por extenso território e mais de mil e quinhentos funcionários. Não vou contar aqui a novela e os dramas que aconteceram na escolha do software ou na sua implantação. Vou iniciar o caso do momento em que uma rede de comunicação IP foi contratada de uma grande empresa de telecomunicações. Qual era o problema? Antes do contrato dessa grande rede IP, todos os usuários reclamavam de imensos problemas de demora para resolver qualquer coisa com o tal software ERP, que tinha vindo para ser “a salvação do sistema de informações” dessa empresa. O usuário evidentemente achava que isso seria um novo problema para ele, tão acostumado em preencher papeizinhos. e a esperança surgiu no coração de todos. Nesse momento fiz a minha primeira análise e relatei a todos: o problema está no sistema, e a rede não vai alterar seu comportamento. Bem, eu não queria frustrar as esperanças de ninguém. Veio a nova rede e tudo continuou como era antes (e minha equipe já tinha apresentado todos os gráficos de desempenho, antes e depois da existência da rede, mas ninguém estava disposto a abandonar suas crenças até que cada um visse novamente, em sua própria máquina, que tudo continuava igual). Chegou a vez da segunda solução (restrita): se o sistema não funcionava bem deveria ser problema com o servidor, então a solução seria trocar o servidor (isso foi feito). Acredito que tenha melhorado um por cento (é uma crença particular, baseada na redução proporcional de reclamações). Mas cada vez que fazia uso do novo sistema, o mesmo não respondia ou demorava demais para dar uma resposta, muitas vezes “travando”. Fiz as seguintes perguntas: o sistema é lento em todas as solicitações? Apenas das filiais? Poderia haver problemas nas rotinas implementadas para acesso ao banco de dados? Então surgiu a primeira solução (restrita) do problema: era a infra-estrutura de rede que não funcionava bem. Foi contratada então a nova rede IP Quanto mais as perguntas foram cercando diferentes aspectos do sistema, cada vez mais as respostas indicaram que o problema estava na Unidade 2 book.indb 59 59 31/5/2007 14:23:36 Universidade do Sul de Santa Catarina própria construção do sistema. Bem, se essas perguntas tivessem sido feitas numa etapa bem anterior, talvez as coisas tivessem ocorrido de modo diverso, mas na vida real a empresa deixou por isso mesmo e passou a conviver com o ERP, como se fosse uma espécie de filho defeituoso vivendo para sempre dentro de casa. ganhar alguns pontinhos sabia inteligentemente manipular referenciais comparativos (e é por isso que os concursos de Qualidade não têm valor, a não ser para os ignorantes sobre o assunto). Pois bem, uma das suas iniciativas era a de aumentar a interatividade com os clientes e melhorar a imagem junto ao mercado, sendo que reformular o site da empresa Outro caso que também era um dos planos. Já havia um destaca a falta da visão ampla: site em funcionamento, mas Caso 2 – encomenda de um novo era tão fraco e desestruturado “site corporativo” que o número de visitas era muito baixo, e ainda Estive em certa companhia menor ao de alguns sites onde a cultura tecnológica especializados de algumas de remontava ainda à época da suas seções industriais, que segunda revolução industrial, tinham feito os seus de forma ou seja, a cultura tinha conseguido evoluir do ambiente independente. O gerente geral de marketing da empresa, que das máquinas a vapor para as surpreendentemente também máquinas elétricas. Isso não é acumulava a função de gerente uma crítica à companhia, pois técnico geral, resolveu mudar ela estava adequada ao seu mercado, que a enxergava como essa situação contratando um novo ambiente, de tal forma capaz de entregar produtos tradicionais (e conservadores) e que embutisse os sites das seções, não permitindo assim nisso era razoável. que tivessem tal independência No entanto, o discurso da nova de relacionamento com o mercado. direção era de remodelagem dos seus objetivos, e o foco Esse era o clima geral do era estar a par das novas negócio e tal era o problema tecnologias e dos novos a resolver: um novo site processos de qualidade, corporativo com esse conjunto tanto é que fazia questão de de premissas, sejam de participar dos concursos de marketing, sejam de política. qualidade regionais, e para 60 book.indb 60 31/5/2007 14:23:36 Gerência de Projetos Tanto esse gerente como seu diretor, ambos tendo conquistado suas posições a partir de negociações políticas (e não por talento empreendedor ou por conhecimento do mercado), desprezavam as novas tecnologias, em um nível tal que o primeiro escrevia e-mails como se fossem ofícios e o segundo mal conhecia as regras do português escrito. Isso não consistia num grande problema no ambiente em que viviam, mas tornou-se grave quando resolveram influenciar nas definições do novo site. entre empresas de design para contratar o tal site, e ganhou a que tinha o menor preço. Certamente a descrição do propósito da contratação estava conforme os objetivos desse assessor, e as empresas fizeram seus orçamentos praticamente “no escuro”. Ganhou o menor preço e então chegou a terceira solução (restritíssima) para o problema, que foi a de dar uma “melhorada” no site existente. Todos os funcionários da empresa, seus gestores, aqueles que formulavam suas novas estratégias, bem O gerente geral de marketing como seus principais clientes assumiu a função de gestor e fornecedores, ficaram fora desse projeto e trouxe a primeira solução (restrita) para desse processo de análise de definições, e enfim, após o caso: passou a incumbência para o assessor de marketing da uns seis meses de atraso, o empresa. Ele mesmo não tinha novo site foi publicado. Sem interação com as aplicações uma visão geral da empresa e informatizadas da empresa, sabia disso. sem dinamismo e sem O assessor de marketing tinha capacidade de mostrar as próprias atividades da empresa, dois problemas, que todos foi um fracasso (as próprias conheciam: não dominava estatísticas do site mostravam tecnologias e não conhecia isso). a cultura da empresa (mas imaginava que, após ter Para o diretor e para o gerente lido algumas revistas sobre isso não teve importância, publicidade, podia discutir afinal já tinham um “novo” qualquer assunto). site, e era o que importava para os concursos regionais de O assessor trouxe então a segunda solução (restrita) para qualidade (e sua publicidade e política pessoal). o problema: fez uma licitação Unidade 2 book.indb 61 61 31/5/2007 14:23:36 Universidade do Sul de Santa Catarina Para o assessor de marketing isso também não tinha importância, pois ele cumpriu seu dever e o emprego estava mantido (tempos depois foi promovido!). da sua própria sobrevivência no futuro. Começou então a tomar um partido amplo para analisar o problema, e iniciou um conjunto de ações em No entanto essa visão restrita (e seqüência, sempre com soluções neste caso também mesquinha) criativas e tomadas por uma visão de conjunto. fez a empresa dar um passo para trás (talvez irreversível). Em primeiro lugar, não Eu poderia continuar descrevendo casos e mais casos desse tipo de visão restrita aplicada à solução de problemas, e infelizmente parece ser adotada por uma ampla maioria. Temos que lutar contra isso. Deixem-me dar então apenas um exemplo de visão ampla que, mesmo fazendo parte da minoria, pode mudar os rumos de toda uma empresa ou mesmo de um país. Acompanhe: Caso 3 – uma gigante da telefonia celular Assim como nos dois casos anteriores, verídicos, também neste não vou revelar o nome da empresa onde o fato ocorreu (apesar de ser muito fácil adivinhar). E apesar de ter vivido o dia a dia daqueles dois casos, neste último, infelizmente, não tive participação. Bem, em meados dos anos 70, a empresa vivia uma crise no seu mercado, sendo que os grandes compradores de seus produtos, voltados à área elétrica e eletrônica, estavam perdendo o poder de compra. A empresa tinha um grande problema nas mãos, que era o mudou completamente de ramo para não desperdiçar seu conhecimento técnico em eletrônica e sua cultura de fabricação de produtos com excelência. Ao mesmo tempo, assumiu como solução (de ampla visão) não competir diretamente com empresas orientais que tinham preços baixos em produtos eletrônicos. Outra solução foi competir num mercado nascente e de alto valor agregado, que naquele momento ainda consistia numa promessa: o da telefonia celular. No início dos anos noventa, a empresa já detinha um razoável conhecimento na área, e um 62 book.indb 62 31/5/2007 14:23:36 Gerência de Projetos domínio consistente do seu mercado local que, no entanto, era de dimensão restrita. O que aconteceu foi que, em aproximadamente cinco anos, essa empresa assumiu a liderança mundial na venda Também com uma visão ampla de aparelhos, partindo de uma e estratégica do mercado simples empresa de eletrônica mundial, previu que a produção periférica, sendo atualmente de aparelhos de telefonia copiada pela enxurrada de celular teria valor agregado novos fabricantes orientais, quando inserisse qualidade no que para disputar o mercado software, e não no hardware do insistem numa estratégia de equipamento. preços reduzidos. Adotou uma solução (ampla) de pesquisar e desenvolver novas interfaces e aplicativos voltados à facilidade de manuseio por parte do usuário, muito mais do que desenvolver simplesmente a miniaturização dos aparelhos ou a qualidade de baterias, o que considerou como commodities. Na época, um dos líderes mundiais nesse mercado era uma empresa americana, que valorizava a robustez do aparelho. A série de soluções (amplas) adotadas pela empresa, sempre com uma visão geral sobre o seu mercado e sobre os costumes, tendências e interesses dos seus clientes finais, fez com que conquistasse e mantivesse a posição de líder. Essa mesma visão é que criou um ambiente aberto de discussão com desenvolvedores de software de todo o mundo, que continuam colaborando para sua expansão e liderança. Unidade 2 book.indb 63 commodities – palavra da língua inglesa que indica que o produto ou sistema é de uso ou conhecimento genérico, tendo poucas diferenças de valor, independente de quem os fabrica ou fornece. 63 31/5/2007 14:23:36 Universidade do Sul de Santa Catarina É importante que você observe nesses casos, sejam de sucesso ou de fracasso, algumas características e traços comuns. Observe: Ambiente de cooperação Um partido amplo de visão não acontece onde as pessoas sentem-se limitadas no seu relacionamento; a visão centrada em si mesmo naturalmente limita um olhar descompromissado, capaz de enxergar outras facetas fora do seu mundo particular. Ambientes onde há uma cultura de cooperação, ou seja, onde as pessoas gostam de ajudar e de receber ajuda, admitindo que isso não seja uma forma disfarçada de aproveitamento, permitem liberdade de expressão. Conhecimento técnico aliado à visão de mercado Certamente apenas um ambiente de cooperação não é suficiente, pois em problemas técnicos é necessário um conhecimento específico. Porém, apenas o conhecimento técnico é algo limitante, e deve ser contrabalançado com uma visão externa, voltada para o mercado e para outras facetas não técnicas. Multidisciplinaridade Ao mesmo tempo, é difícil ter conhecimento técnico em muitas e variadas áreas, especialmente na atualidade onde há tantas tecnologias que se desenvolvem tão rapidamente. Equipes trabalhando em conjunto e com alto grau de cooperação são capazes de reunir conhecimentos de diferentes disciplinas, capazes de gerar soluções de ampla visão. Visão medíocre O contrário desse ambiente de cooperação e multidisciplinar acontece onde impera uma visão medíocre, aquela que não admite relacionamentos e que acredita que, se alguém dá uma sugestão, é porque está “planejando algo”. Também faz parte da visão medíocre a confusão que une ciência exata e crenças, fazendo com que um problema seja analisado sob o ponto de vista do “achismo”. Muitos técnicos excelentes, engenheiros que conheci e que eram tidos por gênios na universidade, resolveram ficar alheios ao desenvolvimento dos seus colegas, supondo que sua imensa capacidade seria o bastante para resolver os grandes problemas do futuro. Hoje infelizmente muitos deles estão presos às suas baias, resolvendo mini-problemas sob as ordens de gerentes pouco espertos, porém politicamente articulados. Política pessoal A articulação política de caráter pessoal é, necessariamente, a visão restrita. Centrada no “eu”, torna-se incapaz de um partido abrangente para as soluções, mesmo que para problemas estritamente pessoais. Isso se estende para a postura de solução de quaisquer problemas, e quando se dá no nível empresarial pode ser uma catástrofe. Nos casos antes citados você viu o que significou na contratação do “web site corporativo”, apesar de, pessoalmente, os contratantes terem aparentemente “se dado bem ”. No entanto, nesse tipo de ambiente, muitos dos que estavam em volta esperavam ansiosos a queda dos chefes, muitas vezes para substituí-los com as mesmas práticas (renovadamente restritas). 64 book.indb 64 31/5/2007 14:23:36 Gerência de Projetos Por fim, para completar o estudo desta seção, você deve entender que as estratégias são definidas e implementadas com uma visão de partido amplo, e as questões operacionais estão definidas sobre questões restritas, ou partes de uma estratégia. O momento em que uma ou outra deve acontecer é que define o tipo de visão a ser adotada. SEÇÃO 2 - Requisitos do cliente e solução de problemas A expressão “requisitos do cliente” é comum entre os desenvolvedores de software, e para muitos outros profissionais, de outras áreas, parece uma expressão nova. O cliente nesse caso é aquele que precisa resolver um problema, ou que está gerando uma demanda específica, e desse modo tem uma idéia aproximada daquilo que quer obter. Como acompanhou anteriormente, esse cliente conhece talvez alguns dos efeitos de um problema, mas geralmente não todos. E quando tem um desejo, no fundo não sabe exatamente como expressá-lo. Aquele que foi chamado, por algum motivo, para resolver o problema de um requisitante qualquer, antes de tudo precisará saber afinal “qual é o problema a resolver” e qual é o resultado esperado. O primeiro passo a tomar é coletar o maior número possível de informações. A coleta de informações está presente em todas as etapas do trabalho, desde a primeira reunião com um cliente ou o nascimento da idéia de um projeto, passando por todas as etapas do projeto até a chegada do resultado, sendo um precioso instrumento de aperfeiçoamento e correção contínua. Neste sentido, cada etapa de um projeto pode ser vista como um novo Unidade 2 book.indb 65 65 31/5/2007 14:23:36 Universidade do Sul de Santa Catarina começo, onde os requisitos das etapas devem ser novamente levantados e analisados. Nas etapas iniciais, a coleta vem diretamente do cliente que solicita a solução de um problema, mas em casos onde há uma idéia de produto, por exemplo, tais informações podem vir da literatura e de experiências prévias, seja dos desenvolvedores, seja de outros envolvidos no projeto. Quais os procedimentos para levantar os requisitos básicos do cliente? Alguns procedimentos para levantar os requisitos básicos do cliente, ou as informações para o desenvolvimento de um novo produto ou sistema, e encaminhar uma primeira visão geral do problema / solução são: „ Se o problema a ser resolvido está escrito - devem-se listar as informações que estão no seu enunciado, na tentativa de detalhar o melhor possível suas partes; „ Se for um defeito a eliminar - descrever todos os efeitos conhecidos e enumerar todas as possíveis causas; „ Se for um novo produto ou processo a desenvolver - listar o que deve ser determinado pela solução, ou seja, definir com a maior clareza possível o que está sendo buscado; „ A partir dos dados levantados e do partido amplo do problema - deve-se criar modelos e esquemas de representação, permitindo uma melhor visualização do conjunto; nesse sentido o desenvolvimento de desenhos esquemáticos, diagramas e fluxogramas, torna-se útil para a compreensão do todo, mesmo que tais desenhos não sigam modelos padronizados (isto não importa nesse momento); „ Além das informações listadas - dos desenhos e de outros dados coletados, é importante verificar as leis físicas associadas e suas equações, no caso dos problemas 66 book.indb 66 31/5/2007 14:23:37 Gerência de Projetos científicos, mas também outros impeditivos e limitantes, tais como questões jurídicas, restrições técnicas, restrições ambientais, etc.; „ Tomar proveito de modelos computacionais e simuladores - como ferramentas de apoio para compreender o problema, retratá-lo e simular situações, bem como aprimorar o desenho de diagramas, gráficos de planejamento, aplicar hipóteses de solução e desenvolver esquemas gerais e/ou detalhados. O desenho da figura abaixo reproduz esses passos na forma de um diagrama de coleta de informações para a solução de problemas. Como se pode notar, é um diagrama genérico que não esgota as possibilidades de tipos de problemas ou idéias originais a serem transformadas em projetos. Mas dá uma clara percepção da necessidade de coleta do maior número de informações, inclusive de fontes externas ao problema, para então chegar à fase de se criar hipóteses de solução. Problema definido ou Defeito a eliminar ou Dados coletados Desenho, diagrama ou modelo Novo produto Hipóteses de solução Objetivos do projeto Outras informações Figura 3.3 – Diagrama do nascimento do projeto com coleta de informações e requisitos do cliente. Com as hipóteses de solução formuladas, é possível traçar objetivos de chegada considerando as hipóteses que têm maior chance de sucesso. Esses objetivos serão perseguidos em todo o projeto, e para isso é preciso definir um caminho de trabalho para abordar o projeto. Esse caminho está definido no algoritmo do projeto, apresentado na próxima seção. Unidade 2 book.indb 67 67 31/5/2007 14:23:37 Universidade do Sul de Santa Catarina SEÇÃO 3 - Algoritmo do projeto O algoritmo é a uma seqüência lógica de passos, que permite modelar um determinado programa, ou projeto, entendidos e definidos com exatidão para que o projeto chegue ao resultado esperado. Tendo um objetivo bem definido, conforme você estudou na seção anterior, é preciso determinar um fluxograma genérico de atividades, até o objetivo ser atingido. O algoritmo apresentado na figura a seguir foi adaptado a partir de uma proposta de Meillir Page-Jones (1990). O fluxograma se inicia a partir dos objetivos definidos, e vai ser encerrado quando os mesmos forem alcançados. Qual é o conjunto de atividades que determina a Gerência de Projeto? Neste algoritmo, pode-se ver o conjunto de atividades que determina a Gerência do Projeto, as quais são: „ planejamento, „ definição e organização dos recursos, „ acompanhamento da execução, „ medição dos resultados obtidos e „ revisão, quando então o ciclo reinicia, se necessário. Acompanhe o desenho a seguir e analise cada uma das etapas, procurando observar o fluxo das atividades. 68 book.indb 68 31/5/2007 14:23:37 Gerência de Projetos Objetivos do projeto Planejamento das atividades Ferramentas de apoio Definição dos recursos Obtenção dos recursos Integração dos recursos Execução das atividades Revisão do projeto NÃO Acompanhamento e medições Os objetivos foram alcançados SIM Encerramento do projeto Figura 3.4 – Algoritmo genérico com o fluxograma do desenvolvimento do projeto. Para compreender o que consiste cada etapa, acompanhe a seguir uma breve descrição de cada uma delas: a) Planejamento das atividades – o planejamento consiste em dividir o objetivo geral do projeto em tarefas, ou pequeno objetivos, que vão se encadeando numa seqüência determinada, a fim de atingir o resultado esperado do projeto. „ Também consiste em definir recursos materiais, financeiros e de pessoal, para cada um desses pequenos objetivos, com os trabalhos a serem feitos num determinado prazo pré-estabelecido. Unidade 2 book.indb 69 69 31/5/2007 14:23:37 Universidade do Sul de Santa Catarina b) Definição dos recursos – a definição dos recursos é uma das tarefas do planejamento, porém coloco à parte no algoritmo e logo após a fase do planejamento para destacar a importância dessa etapa. Muitas vezes a definição dos recursos necessários não é bem determinada, o que pode acarretar carências na etapa da execução, que podem então ser fatais. „ Definir com a maior exatidão os recursos necessários, sejam financeiros, materiais, equipamentos ou pessoal com a qualificação necessária, contribuirá para completar a fase do planejamento e para diminuir riscos. „ Recursos subestimados levarão a importantes faltas, enquanto recursos superestimados levarão a custos altos, inviabilizando o projeto em alguns casos. c) Obtenção dos recursos – somente com uma boa definição de recursos é possível partir para a fase da sua obtenção, que pode ser uma tarefa bastante difícil no processo do projeto. „ Se for um projeto dentro de uma grande organização, talvez os recursos já estejam previamente alocados, mas se o projeto for empreendido por uma pequena empresa, eles podem ser escassos. Neste caso, recursos externos serão necessários, o que tomará um determinado tempo até serem obtidos. Essa demora não é favorável, por exemplo, nas áreas de alta tecnologia. d) Integração dos recursos – os recursos podem vir de fontes diferentes, e muitas vezes guardam grandes diferenças entre si. Nesse momento é que são organizadas as equipes, distribuídas as tarefas e feitas as discussões iniciais de repasse de informações. „ Pense, por exemplo, num conjunto de pessoas com diferentes habilidades, e que ainda não se conhecem. Ou então na utilização de equipamentos novos, ainda não dominados por 70 book.indb 70 31/5/2007 14:23:37 Gerência de Projetos todos. Nesse sentido é que a integração dos recursos assume importante papel, determinante para o progresso do projeto dentro do prazo estipulado. „ Arranjos de lay-out de produção, organização de máquinas, montagem de laboratório, treinamento e comunicação do planejamento completo para todos os envolvidos, são atividades desta etapa. e) Execução das atividades – muitos consideram que o projeto só está de fato em desenvolvimento quando se inicia a execução das atividades. Isto é um grande engano, como você já pôde ver pela quantidade e importância das etapas precedentes, que são etapas preparatórias e de planejamento. A etapa da execução é aquela em que os recursos materiais são utilizados pela equipe, que desenvolve a série de tarefas designadas no planejamento, tendo em vista atingir os sub-objetivos, numa ordem tal que permita chegar aos objetivos finais desejados. „ Tome como exemplo algo muito simples como a construção de uma casa. Depois de elaborados os projetos e tendo listagens de materiais e memoriais descritivos, que definem em detalhe como se construirá a casa (essa é a etapa do planejamento), passa-se a fazer os orçamentos, contratar pessoal e reuni-los para discutir, com um partido amplo, como será a construção e os prazos a serem cumpridos. A partir de então começa a execução do projeto, que provavelmente foi subdivido em fundações, alvenaria, telhado, rebocos, instalações, etc. f) Acompanhamento e medições – como a execução deve seguir o planejamento, certamente deverá haver o acompanhamento e a verificação do andamento do projeto, avaliando periodicamente a concordância entre Unidade 2 book.indb 71 71 31/5/2007 14:23:37 Universidade do Sul de Santa Catarina uma coisa e outra. Muitas vezes, é nessa etapa onde se faz mais visível a presença da gerência, devido ao controle do planejamento. „ Como o objetivo geral deve ter sido subdividido em pequenos objetivos, com metas e prazos menores, faz-se necessário verificar o alcance de tais metas com medições periódicas, ou seja, nos prazos determinados para cada sub-objetivo. g) Revisão do projeto – durante o acompanhamento e medições, caso os objetivos não sejam alcançados, seja devido ao tempo gasto para chegar até aquele ponto, seja pela qualidade diferente da esperada, o projeto deve passar por revisões. Rever o projeto durante o seu andamento significa reavaliar constantemente o planejamento, bem como redefinir os objetivos quando necessário. „ Caso a revisão seja feita apenas no final do projeto, poderão acontecer enormes frustrações (financeiras ou de expectativa). „ A figura a seguir representa esse ciclo de revisão a cada etapa do projeto, que deve seguir adiante caso os sub-objetivos, esperados naquela etapa, tenham sido alcançados. Replanejamento Revisão da etapa NÃO Os sub-objetivos foram alcançados? SIM Próxima etapa Figura 3.5 – Fluxograma específico da fase da revisão. „ Se não foram alcançados os objetivos, uma revisão da etapa deve ser feita, indicando possibilidades de modificação e retificação, que precisam passar então por um replanejamento 72 book.indb 72 31/5/2007 14:23:37 Gerência de Projetos para seguir adiante. Satisfeita a condição, vai-se para a próxima etapa até serem alcançados os objetivos gerais do projeto. h) Encerramento do projeto – encerrar o projeto significa atingir seus objetivos. A finalização do projeto não é simplesmente acabar um produto ou compilar um código. O encerramento é uma etapa bem definida, na qual toda a documentação deverá ser organizada e entregue àquele que o encomendou, com a comunicação mais completa e abrangente possível sobre o resultado alcançado e os problemas e soluções encontrados. Tendo sido bem entendido o algoritmo do projeto, a próxima seção trata de um tema especial para a Gerência de projetos: Prazo. SEÇÃO 4 - Prazo Projetos são estabelecidos com prazo determinado. Como você pode perceber, se não houver uma data aproximada para o empreendimento ser encerrado, então não haverá um projeto e sim uma tarefa de rotina. A definição do prazo é algo que nasce a partir dos requisitos do cliente, pois os objetivos por ele definidos só têm sentido se forem cumpridos até uma determinada época, na qual então podem ser aplicados. A discussão sobre prazos deve se dar considerando as vantagens que o projeto busca, as condições reais da equipe de desenvolvimento e os recursos disponíveis. Na opinião de Meillir Page-Jones (1990), há quatro fatores que fazem os projetos terem prazos irreais. Tais prazos irreais à primeira vista são exeqüíveis, porém quando o conjunto de fatores Unidade 2 book.indb 73 73 31/5/2007 14:23:38 Universidade do Sul de Santa Catarina que determina o andamento do projeto entra em jogo, o prazo se perde. O que leva os projetos a serem assumidos como prazos irreais? A seguir analise esses quatro fatores geradores de prazos irreais. 1. Racionalização do desejo - Page-Jones considera que esse primeiro fator se dá quando alguém, que tem poder sobre a equipe, imagina um prazo qualquer e, conforme seu desejo, impõe uma data final aleatória. Partindo dessa data estabelecida por um desejo, aquele que vai gerenciar o projeto tenta dividir as tarefas em prazos menores para adaptar ao prazo global. Ajustando ao máximo, ele talvez consiga configurar um conjunto de pequenas tarefas com prazos muito justos, dando a entender que talvez seja possível cumprir a meta. Após uma partida acelerada, os membros da equipe terão que fazer paradas de revisão, talvez correções e ajustes, e então o prazo começa a ceder e a equipe, cansada, diminui a capacidade de produção. Isso pode acontecer, por exemplo, quando um político define a data para uma inauguração, sem ter a mínima noção do tempo e das questões legais que envolvem a contratação e a execução da respectiva obra. Ou quando o diretor de uma empresa determina que tal software deva estar funcionado em sua empresa em determinado momento, sem buscar saber se tal software sequer existe ou é adaptável. 2. Estimativa prematura - se a estimativa do prazo total for feita muito no começo da análise do que será o projeto, tal data pode parecer imutável (para os membros 74 book.indb 74 31/5/2007 14:23:38 Gerência de Projetos da equipe) e muito provavelmente será irreal. Ora, muitas das particularidades do projeto serão percebidas conforme se aprofunda a discussão e o planejamento do projeto, e só então será possível prever com maior acuidade os prazos das diversas etapas, culminando com um prazo global mais próximo da realidade de execução. A estimativa prematura acontece no afã de se ter uma data final para o projeto ficar pronto, mas devemos controlar esse desejo. Certamente a estimativa dependerá em muito do domínio que se tem da tecnologia empregada no projeto. 3. Compromisso progressivo - Page-Jones atribui uma conotação bastante negativa para esse fator, por considerá-lo de procedimento não ético. Consiste em estabelecer um escopo de projeto reduzido para a equipe, que então define um prazo para tal escopo. A partir do início da execução o contratante, ou mesmo o gestor, vai ampliando o escopo e mostrando sua verdadeira composição, com constantes incrementos de necessidades e de compromissos. Não sendo mais possível voltar atrás, a equipe tenta ajustar as novas necessidades dentro do planejamento, estressando dessa forma todo o trabalho. Perdas e danos podem ser irreparáveis, especialmente pelo sentimento de ter sido enganado, e certamente não haverá prazo cumprido. 4. Escala de valores - O que Page-Jones chama de escala de valores está apresentado na figura a seguir. O projeto tem um determinado custo para ser desenvolvido, que está representado pela linha tracejada, enquanto os ganhos a serem auferidos com o projeto finalizado estão representados pela linha contínua. A definição da melhor data para entregar o projeto está relacionada com o melhor valor agregado possível. Unidade 2 book.indb 75 75 31/5/2007 14:23:38 Universidade do Sul de Santa Catarina Figura 3.6 – Representação das vantagens relativas de um projeto considerando o prazo (adaptado de Page-Jones, 1990). Parta do princípio segundo o qual tal “primeira data” seja exeqüível, e que todas as análises levaram a definir essa data como adequada. Os atrasos que ocorreram farão a data de entrega escorregar para a direita no gráfico, e o valor adicional de vantagens vai diminuindo proporcionalmente, até atingir um ponto onde não há mais valor adicional, e os prejuízos começarão a aumentar progressivamente. Então, o que não fazer no momento de definir prazos de um projeto? Considerando as implicações estudadas, é importante: „ não ceder ao primeiro impulso de se definir uma data sem antes analisar o máximo possível de dados do projeto; „ perceber quando a data definida não passa de um “desejo racionalizado”, e então buscar esclarecer o porquê da data, ou mesmo declinar do projeto para evitar o fracasso; 76 book.indb 76 31/5/2007 14:23:38 Gerência de Projetos „ discutir em detalhe todos os objetivos do projeto, para evitar depois uma série de novos compromissos que não haviam ficado claros no início; „ perceber com a maior clareza possível a escala de valores do projeto ao longo do tempo, evitando embarcar em um projeto onde a primeira data de entrega esteja próxima demais da data “fatal”. SEÇÃO 5 - Viabilidade do projeto Você já estudou a origem das idéias de novos projetos, das motivações, dos requisitos do cliente, da visão geral do projeto e do conceito de prazo. Porém, resta analisar, antes de começar um projeto, se de fato ele é viável e quais os riscos envolvidos na sua execução. Muitas vezes um projeto é iniciado sem um estudo de sua viabilidade nem dos seus riscos, o que tem sido a fonte de inúmeros fracassos. Mesmo os projetos muito simples precisam de um estudo de viabilidade, e tal estudo dará condições de se tomar as melhores decisões desde o início, minimizando riscos, despesas extraordinárias e atrasos. Projetos complexos, que envolvem múltiplas disciplinas e grandes custos, podem exigir um estudo de viabilidade, como um documento preparado por consultoria externa e análise aprofundada. Quais fatores analisar ao estudar a viabilidade? São os seguintes os fatores preponderantes a serem analisados num estudo de viabilidade: benefícios, recursos, custos e tempo. Unidade 2 book.indb 77 77 31/5/2007 14:23:38 Universidade do Sul de Santa Catarina Esses quatro fatores podem ser vistos como elementos interrelacionados, como apresentado na figura a seguir: custos prazo recursos benefícios Figura 3.7 – Fatores fundamentais na viabilidade dos projetos. Acompanhe a descrição de cada um deles e suas relações. Procure observar que, no estudo de viabilidade, tais fatores ainda não são estimados com grande nível de detalhamento, mas apenas o suficiente para se ter uma “visão geral do projeto”. a) Benefícios - são os resultados positivos esperados do projeto depois de finalizado. Alguns dos benefícios são facilmente mensuráveis e outros não. Os mensuráveis são aqueles que você pode comparar com o que se tinha antes do projeto ter sido realizado. Veja a seguinte lista de exemplos: aumento do patrimônio (construção de máquinaferramenta, edificação); „ aumento do faturamento (ascensão das vendas, redução de desistências); „ maior lucratividade (diminuição de custos, maior preço de venda devido ao valor agregado ao produto); „ maior agilidade (na produção, na resposta a solicitações externas e internas). „ 78 book.indb 78 31/5/2007 14:23:39 Gerência de Projetos O projeto pode trazer também uma série de benefícios cuja medição não é tão simples quanto comparar lucros ou tempo de resposta. Nesse caso, está-se falando de benefícios intangíveis, que podem ser tão ou mais importantes que os tangíveis. Pense nos seguintes itens: aumento da satisfação dos clientes (apesar de ser possível medir por meio de pesquisas, este é um item subjetivo e bastante variável); „ fixação de determinada marca como líder de qualidade; „ sensação de “time vencedor”. „ b) Recursos - considere os recursos como sendo materiais (equipamentos, instalações, softwares, etc.) e humanos (a equipe do projeto). Projetos que envolvem o desenvolvimento de novas máquinas, por exemplo, exigirão como parte dos recursos o acesso a laboratórios de testes. Também é importante ressaltar que os recursos humanos adequados não são apenas os que detêm certo tipo de conhecimento técnico, algo que não é o bastante. É preciso dispor de pessoas com conhecimento técnico e com capacidade de trabalho cooperativo, base fundamental de todo projeto. c) Custos - considerando os recursos materiais e humanos necessários para o desenvolvimento do projeto, recursos financeiros serão necessários para custeá-lo, geralmente considerada a sua parte mais delicada. Ora, é possível dispor de excelente pessoal, idéias brilhantes, domínio tecnológico e um mercado potencial, mas as dificuldades da sobrevivência diária podem impedir o uso de certo montante de dinheiro em um projeto, mesmo considerando seu provável sucesso. Unidade 2 book.indb 79 79 31/5/2007 14:23:39 Universidade do Sul de Santa Catarina c) Tempo (Prazo) - lembre-se de que você já estudou a questão da definição de prazos na seção anterior, e aqui cabe ressaltar seu papel fundamental na análise da viabilidade de um projeto. Certamente se os prazos definidos forem irreais, o projeto será inviável e fracassará. O estudo de viabilidade deve considerar o prazo com especial cuidado. Muitas vezes, o projeto encomendado tem os recursos necessários, pessoal especializado e com grande domínio da tecnologia, e o pagamento é bastante bom, mas o prazo exageradamente curto não pode ser resolvido com a inclusão de mais pessoas, por exemplo. No desenvolvimento de um sistema computacional, o acréscimo de membros na equipe pode, às vezes, significar acréscimo de confusão. O projeto é viável? Estudar a viabilidade do projeto é, antes de mais nada, pesar os possíveis benefícios, os custos, a disponibilidade dos recursos e do prazo, comparando com os riscos previsíveis capazes de estragarem tudo. No quadro a seguir, acompanhe um modelo de questionário / relatório, bastante simplificado (e subjetivo), para um Estudo de Viabilidade de Projetos. 80 book.indb 80 31/5/2007 14:23:40 Gerência de Projetos Estudo de viabilidade Equipe de estudo: Local e data: Resumo do projeto (escopo, objetivos, estratégias) Benefícios: - quais são as vantagens mensuráveis que o projeto trará? - quais são os valores comparativos? Benefícios: - que vantagens intangíveis ele trará? - como se poderá verificar? Descrição: Descrição: Recursos: - quais os recursos materiais necessários para o projeto? - esses recursos estão disponíveis? - caso não disponíveis, é possível obtê-los? Descrição: Recursos: - quais os recursos humanos necessários para o projeto? - essas pessoas estão disponíveis para o projeto? - caso não disponíveis, há outras pessoas para substituí-las? Descrição: Custos: - considerando os recursos necessários, quanto dinheiro será necessário para desenvolver o projeto? - esse montante está disponível? Descrição: Custos: - há fontes de financiamento? Descrição: Prazo: - qual o prazo pré-definido pelo “cliente” para o projeto? Descrição: Prazo: - considerando a experiência da equipe, qual o prazo estimado para o projeto? É igual ao pré-definido? Descrição: Conclusões quanto à viabilidade do projeto: Recomendações: Anexos (tabelas, demonstrativos, estatísticas, reportagens, tendências tecnológicas e comerciais, etc.) Quadro 1 – Modelo de relatório para estudo de viabilidade de projetos. Unidade 2 book.indb 81 81 31/5/2007 14:23:40 Universidade do Sul de Santa Catarina Observe que este modelo não esgota todas as possibilidades de análise, pelo contrário. Mas encaminha uma série de questões iniciais, com as quais é necessário você se preocupar para tentar perceber se é viável prosseguir com o desenvolvimento do projeto e contra quais riscos é preciso se resguardar. Cada projeto, obviamente, trará questões particulares, que devem ser tratadas e resumidamente descritas. Posteriormente, no caso do projeto seguir em desenvolvimento, as estimativas detalhadas de custos, benefícios e recursos deverão ser tratadas. SEÇÃO 6 - Antecipando e administrando riscos Os riscos de um projeto já estão lá antes mesmo de ele nascer. Você poderá verificar como prevê-los com a maior antecipação possível, e então administrar a sua existência (já que não é possível eliminálos completamente). Você tem que encarar o risco como uma ameaça, que pode levar o projeto ao erro, às perdas e ao fracasso. Geralmente não é possível evitar essa ameaça. Os riscos podem ser considerados conforme a probabilidade de ocorrerem e conforme o impacto que terão sobre o projeto, caso ocorram. Há riscos de enorme impacto como, por exemplo, a falta de recursos financeiros bem no meio do projeto – essa falta faz simplesmente o projeto ser abortado. Você terá então de avaliar se há de fato a probabilidade de isso ocorrer. Se o recurso financeiro para custear o projeto não está depositado previamente e depende de financiamento externo, a probabilidade de falta pode ser considerável. Outra questão se refere ao impacto do risco do atraso do projeto em um benefício esperado. Se for o lançamento de um produto de área de forte concorrência, o impacto é enorme e deve ser avaliada a probabilidade de ocorrer. Há outros casos onde a 82 book.indb 82 31/5/2007 14:23:40 Gerência de Projetos probabilidade de ocorrência dos riscos é alta, porém o impacto deles é mínimo. Durante o período da construção de uma casa, a probabilidade de chuvas é altíssima e, sendo assim, uma série de atividades alternativas é programada, fazendo com que esse risco tenha baixo impacto no projeto. Outra questão importante se refere à origem dos riscos, que o desenho a seguir apresenta de modo esquemático: Risco externo Área do projeto Risco interno Figura 3.8 – Riscos internos e externos. Observe que os riscos em projetos podem basicamente ser de origem interna e de origem externa. Essa diferença de origem leva tais riscos a um tratamento diferente quanto à sua previsão, administração e eliminação. Acompanhe como é identificada cada origem: a) Riscos de origem interna - os riscos de origem interna passam a existir a partir do nascimento do projeto. Unidade 2 book.indb 83 83 31/5/2007 14:23:40 Universidade do Sul de Santa Catarina Podem ser considerados típicos riscos internos dos projetos: equipamentos defeituosos; „ equipe despreparada para trabalho em grupo; „ falta de domínio tecnológico; „ gastos excessivos; „ estouro de prazo devido a falhas de desenvolvimento; „ estouro de prazo devido a erros no gerenciamento; „ necessidades tecnológicas desconsideradas durante o planejamento das etapas; „ a complexidade do sistema, não devidamente percebida nas etapas iniciais; „ alterações no escopo do projeto. „ b) Riscos de origem externa - são aqueles que independem de qualquer atividade ou planejamento do projeto, mas podem acontecer e afetar seriamente o seu andamento. Podem ser considerados típicos riscos provocados por agentes externos aos projetos: causas/fenômenos naturais; „ crises políticas de uma região ou país; „ crises econômicas; „ doenças; „ problemas do financiador do projeto ou do fornecedor de insumos/recursos; „ alterações na legislação; „ pressões da organização, da sociedade, do cliente; „ alterações no mercado quanto às suas necessidades ou capacidade de compra. „ 84 book.indb 84 31/5/2007 14:23:41 Gerência de Projetos Como agir diante dos riscos? Com essas considerações sobre origem, probabilidade e impacto dos riscos sobre o projeto, há duas possibilidades de ação: a) Deixar acontecer e, então, tentar resolver. b) Antecipar e administrar os riscos. O processo de administração de riscos deve ser contínuo, desde o planejamento inicial do projeto até as suas últimas etapas, e consiste em um ciclo de atividades, conforme você pode ver na figura a seguir: Etapa Identificar os riscos Nova Etapa Analisar os riscos Planejar ação sobre os riscos Eliminar ou administrar os riscos Figura 3.9 – Antecipando e administrando riscos. Esse ciclo deve se repetir a cada nova etapa, e os riscos identificados devem ser comunicados a todos os participantes do projeto, seja para os de nível inferior, seja para os de nível superior (mesmo que isso possa desagradar). Unidade 2 book.indb 85 85 31/5/2007 14:23:41 Universidade do Sul de Santa Catarina O ciclo para o tratamento dos riscos é composto do seguinte: 1. Identificação de riscos; 2. análise; 3. planejamento da ação contra esses riscos; 4. controle/eliminação dos riscos; 5. nova etapa do projeto e nova identificação de riscos. Acompanhe a descrição de cada um deles: a ) Identificação de riscos - esse é o primeiro passo na administração dos riscos, e consiste em sua identificação. O modelo apresentado no quadro abaixo aponta diversas causas de riscos e proporciona uma visão do projeto sob a perspectiva de suas ameaças. Essa identificação deve ser feita reunindo a equipe do projeto, e a sua experiência será fator chave para perceber proativamente os riscos possíveis. A partir da sua identificação, devem ser descritos com clareza, declarando sua origem e a conseqüência que trarão ao projeto caso aconteçam. b ) Análise - partindo da identificação e da expressão clara e objetiva dos riscos do projeto, o segundo passo consiste em analisá-los, seja quanto à probabilidade, seja quanto ao impacto. Se o risco tiver probabilidade de 100%, será uma certeza, e não apenas um risco. Se o risco tiver probabilidade próxima de zero, poderá ser desprezado. Quanto ao impacto, se for muito reduzido, talvez não seja necessário dispender esforços na tentativa de eliminá-lo, esforços esses que devem ser destinados a outras atividades. A inexperiência de uma equipe é, em si, um fator de alto risco num projeto. Claro que uma equipe iniciante deve ter chance de se responsabilizar por um projeto, e é necessário que isso aconteça para que se obtenha experiência. Nesses casos, projetos de baixa complexidade são os recomendados e, então, um processo de identificação e análise de riscos, bem elaborado e estudado, trará conhecimentos importantíssimos para a carreira (digo isso porque vejo que a maioria dos envolvidos em projetos NÃO realiza tais estudos, e só obtém experiência após excessivos erros). 86 book.indb 86 31/5/2007 14:23:41 Gerência de Projetos c ) Planejar ações sobre esses riscos -identificados os riscos, conhecidas as suas probabilidades e o impacto que podem causar no projeto, é preciso planejar ações para evitar ou reduzir tal impacto. O processo de planejamento passa pelas seguintes perguntas: „ Conhecemos o risco? „ Podemos conviver com ele, se acontecer? „ Como é possível atenuar seu impacto? „ O que é possível fazer para evitá-lo? As respostas a essas perguntas levarão o projeto a um conjunto de planos de ação. Cada risco detectado merecerá uma discussão sobre ações preparatórias, e quando os riscos do projeto forem altos demais, talvez seja melhor não aceitar o projeto. d ) Controle/eliminação dos riscos -identificados os riscos, analisados e criados os planos de ação, é hora de colocar as coisas para andar. As ações devem ter data para começar, e uma vez colocadas em andamento, os riscos devem ser monitorados. Se determinada ação teve sucesso, o risco pode ter sido eliminado. Caso não tenha sido eliminado e surja no meio do projeto, deve então ser controlado para determinar o mínimo impacto possível no projeto. Se havia o risco de um atraso, por exemplo, e o atraso aconteceu, o plano de contingência de ampliar a equipe ou terceirizar partes do projeto deve ser colocado em prática, buscando a todo custo manter a data final de entrega em garantia. Controlar os riscos é o último passo do ciclo da administração dos riscos, e basicamente se divide em: „ Controlar os planos de ação preventivos; „ monitorar a eclosão dos riscos previstos; „ responder à eclosão de tais riscos com ações corretivas; „ monitorar o surgimento de novos riscos, não previstos; „ refazer o planejamento de ações; Unidade 2 book.indb 87 87 31/5/2007 14:23:42 Universidade do Sul de Santa Catarina „ integrar-se ao processo global da gerência do projeto. No quadro 2, Modelo de relatório para estudo de riscos de projetos, são apresentadas diversas questões importantes para detecção, análise e ações preparatórias contra os riscos do projeto. Observe: Estudo de riscos Equipe de estudo: Local e data: Resumo do projeto (escopo, objetivos, estratégias) Riscos quanto aos benefícios: - o cliente tem uma idéia exata do resultado a ser obtido? - ou tem uma idéia aproximada? - é possível medir os benefícios? Descrição: Riscos quanto aos benefícios: - qual a probabilidade desse tipo de riscos? - qual o seu impacto? Descrição: Riscos quanto aos recursos: - há equipamentos de reserva? - há pessoal de reserva? - a tecnologia empregada é inteiramente dominada? Descrição: Riscos quanto aos recursos: - qual a probabilidade desse tipo de riscos? - qual o seu impacto? Descrição: Riscos quanto aos custos: - o financiamento de todo o projeto está garantido? - há um montante de reserva? Descrição: Riscos quanto aos custos: - qual a probabilidade desse tipo de riscos? - qual o seu impacto? Descrição: 88 book.indb 88 31/5/2007 14:23:42 Gerência de Projetos Riscos quanto ao prazo: - há fatores internos ou externos, não considerados, que podem afetar o prazo do projeto? Descrição: Riscos quanto ao prazo: - a equipe de projeto é experiente? Descrição: Riscos quanto ao prazo: - qual a probabilidade desse tipo de riscos? - qual o seu impacto? Descrição: Lista dos 10 riscos mais importantes: Podemos conviver com eles? É possível atenuá-los? É possível evitá-los? Conclusões quanto aos riscos do projeto: Anexos (tabelas, demonstrativos, estatísticas, reportagens, tendências tecnológicas e comerciais, etc.). Quadro 2 – Modelo de relatório para estudo de riscos de projetos. Tal modelo pode e deve ser adaptado para as condições de cada projeto e cada equipe. Toma tempo inicial da equipe do projeto, mas garantirá ganhos substanciais no decorrer dos trabalhos, seja por evitar riscos, seja pelo conhecimento aprofundado que trará a todos os envolvidos com o trabalho que virá pela frente. SEÇÃO 7 - Ferramenta de apoio para análise e planejamento Existem atualmente várias ferramentas computacionais para apoio na análise e planejamento de projetos. A seguir, são citadas algumas dessas ferramentas, que poderão ser utilizadas por você para a prática de gerência de projetos. Unidade 2 book.indb 89 89 31/5/2007 14:23:42 Universidade do Sul de Santa Catarina „ Um produto muito interessante de apoio ao gerenciamento de projetos foi desenvolvido com a Linguagem Java e está disponível para uso gratuito: O nome do produto é “Free Project Management Software”, mais conhecido como jxProject, e está disponível para download no sítio www.jxproject. com. Este software é de uso bastante simples, porém de grande utilidade, pois cria gráficos de Gantt de grande qualidade com a inclusão de dependências entre tarefas (o que você verá em detalhes na próxima unidade deste livro). Acompanhe a seguir uma tradução que fiz diretamente do texto de apresentação do jxProject, que está disponível em inglês no original, no site mencionado acima. “Se você está buscando um Software de Gerência de Projetos Gratuito, então você veio ao lugar certo. Você pode instalar jxProject em todos os seus computadores sem nenhum custo. Você também pode compartilhar seus planejamentos de projetos com qualquer um que tenha acesso à Internet, pois qualquer pessoa na Internet pode acessar e instalar jxProject. Plataformas Windows, Linux e Solaris suportam o jxProject, e muitos usuários de Mac OSX têm relatado seu grande sucesso usando este software. E como é possível? O aplicativo é financiado por propaganda, colocada na parte superior à direita da janela do aplicativo, e tal propaganda é que financia o desenvolvimento e manutenção desse sistema.” “História: fundado em 2001 por Peter Hawkins, com a missão de colocar uma cópia de jxProject em todos os computadores. Palavras de Peter Hawkins: ‘Tenho trabalhado em computação desde que me formei em Engenharia Mecânica em 1986. De 1986 a 1994, trabalhei nas áreas de engenharia e manufatura, incluindo processos de controle de manufatura e sistemas CAD/CAM, geralmente usando UNIX/C. De 1994 a 2001, trabalhei com várias tecnologias aplicadas a negócios com TCP/IP, HTTP, RDBMS, OLAP, Java e Windows em indústrias diversas, como a de produtos de software, saúde, comunicações sem fio e comércio eletrônico’”.Em outro trecho do seu depoimento, 90 book.indb 90 31/5/2007 14:23:42 Gerência de Projetos Peter Hawkins comenta: “Existem duas tecnologias que mudaram fundamentalmente a maneira como softwares devem ser desenvolvidos. São: Arquitetura Orientada e Objeto e execução Multi-threaded. Tenho visto companhias desenvolvendo software do mesmo jeito que elas faziam nos anos 70, ainda que as tecnologias tenham mudado completamente. A falha em implementar processos de trabalho que incorporem essas diferentes tecnologias contribui significativamente para a falta de eficiência no desenvolvimento de software, hoje em dia. Parte do que venho fazendo com o jxProject está aperfeiçoando meus próprios métodos para incorporar tais novas tecnologias. Vejo positivamente os escritos de Eliyahu M. Goldratt, cujos livros ‘Theory of Constraints’ e ‘Critical Chain’ nos dão uma visão mais completa das forças que agem sobre os processos de negócios.” „ O mais popular software comercial de gerência é o da Microsoft, e se chama Microsoft Project – MSProject. O MSProject é uma marca registrada e é o produto de maior sucesso hoje da Microsoft depois do Office. Você verá que muitas empresas usam essa ferramenta, que pode ser adquirida nas revendas autorizadas e está disponível também em www.microsoft.com/ brasil/office/project/standard.asp. Acompanhe a seguir algumas informações gerais sobre esse produto, extraídos do sítio da Microsoft. Certamente tais informações são de âmbito comercial, e cada usuário deverá verificar com cautela se o produto se ajusta ou não às suas necessidades, especialmente em produtos como esse, que não estão voltados para aplicações específicas, mas sim pretendem atender a uma gama muito extensa de atividades. Esse tipo de pretensão em softwares tem a desvantagem de abrigar um número excessivo de módulos e acessórios, o que acaba por incluir uma complexidade desnecessária para o usuário. Unidade 2 book.indb 91 91 31/5/2007 14:23:42 Universidade do Sul de Santa Catarina “O Microsoft Office Project Standard 2003 é utilizado pelos gerentes de projetos que precisam de uma ferramenta de área de trabalho para gerenciar seus projetos de maneira independente, mas que não exigem coordenação rigorosa com outros gerentes de projeto, nem a capacidade degerenciar recursos a partir de um repositório central. O Project Standard 2003 foi projetado para aprimorar a capacidade de organizar o trabalho e para comunicar de maneira eficiente e sucinta por ferramentas familiares e fáceis de serem usadas.” Segundo a Microsoft, “o Project Standard 2003 ajuda a organizar e gerenciar melhor o trabalho e pessoas, para garantir que os projetos sejam entregues na data, e que estejam dentro do orçamento. Com o Project Standard 2003, é possível: Organizar seu trabalho de maneira mais eficiente, com recursos e poder de planejamento poderoso. „ Controlar e avaliar os impactos do planejamento e alterações de recursos em todos os planos do projeto. „ Personalizar planos para capturar informações específicas para seus projetos. „ Exibir as informações do projeto que você deseja revisar. „ Dar enfoque às informações que precisam de sua atenção com filtros e grupos.” Algumas facilidades para quem já usa os pacotes da Microsoft: “O Project Standard 2003 ajuda a projetar seus planos de projeto e status de maneira eficiente e sucinta, permitindo que você: „ Aumente seu impacto sobre o trabalho, usando Copiar Imagem para o Assistente do Office para comunicar e apresentar idéias e informações do Project Standard 2003 em outros programas do Office System como Microsoft Office Word 2003, Microsoft Office PowerPoint® 2003 e Microsoft Office Visio® 2003. „ Comunique mais claramente, usando novos aprimoramentos de impressão para imprimir cópias de uma página de planejamentos de projeto. „ Compartilhar informações do projeto com membros da equipe, salvando arquivos do Project (MPP) em um site do Microsoft Windows® SharePointTM Services (WSS). WSS é um componente do Microsoft Windows Server 2003 que permite que os usuários criem sites para compartilhamento de informações e colaboração de documentos. „ 92 book.indb 92 31/5/2007 14:23:42 Gerência de Projetos Iniciar rapidamente as ferramentas que auxiliam na metodologia de gerenciamento de projetos, para que você possa configurar agendas e gerenciar recursos de maneira mais eficiente. „ Acessar ajuda online e treinamento, para obter assistência e suporte atualizado e relevante. „ Baixar um modelo da Galeria de Modelos, ao invés de iniciar um projeto a partir do rascunho. „ Usar ferramentas familiares para fazer um trabalho mais sofisticado e de impacto, sem a necessidade de treinamento extensivo. „ Economizar tempo movendo informações do projeto facilmente entre o Project 2003 e outros programas do Office, como Microsoft Office Excel 2003. „ Navegar e aprender o Project Standard 2003, rapidamente, com uma interface atualizada consistente com os programas do Microsoft Office 2003.” „ Esses são outros softwares de gerência disponíveis no mercado, mas a introdução de novos produtos comerciais continua todos os dias. Cada empresa ou gestor deve escolher o que melhor se adapta ao seu estilo: „ Pert Chart Expert „ WBS Chart Pro „ Mindmanager „ Primavera Team Play „ PMOffice „ Open Project System „ Rational Project Manager „ PS8 „ Tassc Estimator Manager „ Gantt Project (grátis e disponível em www. ganttproject.org.) Unidade 2 book.indb 93 93 31/5/2007 14:23:42 Universidade do Sul de Santa Catarina Agora que você já concluiu a leitura desta unidade, pratique os novos conhecimentos, realizando as atividades propostas a seguir e no EVA. Atividades de auto-avaliação Leia com atenção os enunciados e realize as atividades. 1) Considere o seguinte problema, colocado por um cliente: “Atualmente meu pessoal da área comercial emite propostas de serviços usando planilhas de cálculo Excel e documentos gerados no Word. Quando o cliente dá o “aceite” na proposta, muitas vezes vários itens dela foram modificados, porém isso não é ajustado na planilha. O pessoal de vendas precisa ajustar a lista de produtos a serem entregues, e faz isso manualmente, gerando uma nova lista. A nota fiscal é emitida à mão, e finalmente a reposição do estoque é feita por meio de constantes verificações nas prateleiras. Eu gostaria de automatizar meu processo de reposição de estoques”. Em sua opinião, qual é o escopo do problema, segundo uma avaliação “restrita”, e “qual seria uma visão ampla” desse mesmo problema? 94 book.indb 94 31/5/2007 14:23:43 Gerência de Projetos 2) Quando o cliente descreve o seu problema, ele o faz com a própria linguagem e com uma visão particular, que muitas vezes indica um caminho de solução. Você sabe que muitas vezes esse caminho pode não levar à melhor solução. Veja a figura a seguir, que apresenta um diagrama com a coleta de informações e requisitos do cliente, visando o melhor entendimento do problema proposto. Considerando esse diagrama e sua experiência, liste as principais ações que você deve tomar para chegar ao melhor entendimento do problema. Problema definido ou Defeito a eliminar ou Dados coletados Desenho, diagrama ou modelo Novo produto Hipóteses de solução Objetivos do projeto Outras informações 3) Qual a função do algoritmo no planejamento do projeto? Unidade 2 book.indb 95 95 31/5/2007 14:23:43 Universidade do Sul de Santa Catarina 4) Como você define a data “fatal” do projeto? (veja a figura a seguir) 96 book.indb 96 31/5/2007 14:23:43 Gerência de Projetos 5) Riscos são inerentes a qualquer projeto. Por quê? Síntese Nesta unidade, você pôde entender a importância da avaliação e análise prévia em projetos, e como os requisitos do cliente definem o planejamento geral do projeto, que deve ser elaborado a partir de um algoritmo. Esse “algoritmo” do projeto permite traçar um caminho preciso de execução, e muitas vezes você terá que utilizar ferramentas computacionais para apoiar o planejamento dos projetos, estabelecendo e desenhando um plano geral. Você estudou também a importância do prazo e como os riscos podem interferir em um projeto. Se forem antecipados, você poderá criar formas de administrar tais riscos e até mesmo tirar vantagem deles. Na próxima unidade, você irá estudar e praticar alguns métodos gráficos de planejamento de projetos. Até lá! Unidade 2 book.indb 97 97 31/5/2007 14:23:43 Universidade do Sul de Santa Catarina Saiba mais Para aprofundar os temas abordados na unidade, sugere-se: 1. Atualmente é importantíssimo estar atualizado sobre o que acontece no Project Management Institute (PMI), que edita o PMBOK e tem mais de 150 mil associados em todo o mundo. Você deve dar uma olhada em: www.pmi.org. Nesse site, você encontrará artigos variados, conferências, possibilidade de se associar, comprar livros e saber o que acontece de novo no mundo da gerência de projetos. 2. Outro local importante no desenho de métodos e teorias sobre a gerência de projetos é a Sociedade de Gerência de Engenharia do IEEE (IEEE Engineering Management Society (EMS). Essa sociedade está no endereço http://www.ewh.ieee.org/soc/ems/, e o sítio do IEEE geral é o www.ieee.org. 3. Algumas revistas muito interessantes sobre a área de gerência de projetos de tecnologia estão hoje disponíveis e abertas na internet. Um exemplo é a revista http://www.worldscinet.com/ compsci.shtml, específica sobre Gerência de Tecnologia. Nesse mesmo sítio, você poderá encontrar diversas outras publicações (em inglês) sobre temas de interesse da computação. 98 book.indb 98 31/5/2007 14:23:43 UNIDADE 3 Planejamento e elaboração 3 Objetivos de aprendizagem Ao final desta unidade você terá subsídios para: „ Conhecer as técnicas de planejamento de projetos. „ Analisar essas diferentes técnicas e métodos de planejamento, com exercícios e exemplos práticos. „ Aprender a incorporar o planejamento, por meio de ferramentas, às atividades iniciais de um projeto. „ Verificar que as estimativas de recursos, custos e prazos são mais coerentes e consistentes quando embasadas em um planejamento detalhado. „ Aprender a dividir tarefas de projeto entre os membros da equipe. Seções de estudo A seguir, apresentam-se as seções para você estudar. Seção 1 Modelagem do fluxo de atividades Seção 2 Metodologias de planejamento – Gráfico de Seção 3 Seção 4 Seção 5 Seção 6 Seção 7 Gantt Metodologias de planejamento – PERT/CPM Estimativa de recursos e custos Recursos humanos em projetos Divisão de tarefas O modelo PMI Após a leitura dos conteúdos, realize as atividades propostas no final da unidade e no EVA. book.indb 99 31/5/2007 14:23:43 Universidade do Sul de Santa Catarina Para início de estudo Nesta unidade você vai aprender técnicas de modelagem e planejamento de projetos. A primeira delas, e mais antiga, é o Gráfico de Gantt, que permite colocar em um gráfico de barras todas as atividades e tarefas, distribuídas ao longo do tempo. A outra técnica é chamada atualmente de PERT/CPM, e permite verificar quais atividades representam o “caminho crítico” de um projeto, ou seja, aquele que estabelece a seqüência crítica de atividades. Vocês estudará o papel dos membros da equipe de projeto, e como dividir a tarefa entre eles, visando um trabalho produtivo e um ambiente de cooperação, considerando diferentes estruturas. Saberá ainda como o modelo PMI está presente nas técnicas de gerência de projetos e sua influência nas técnicas modernas de gestão. Bom estudo! SEÇÃO 1 - Modelagem do fluxo de atividades Para que um projeto seja desenvolvido e se obtenham os resultados esperados, é preciso ter uma visão geral que permita avaliar sua viabilidade, os possíveis riscos e suas necessidades gerais. Certamente, durante esse processo de visão geral, não é possível detalhar todos os elementos do projeto. Mas é suficiente para decidir sobre a sua viabilidade e então dar um passo além: o desenvolvimento do projeto. Para detalhar o projeto, o primeiro passo é a sua modelagem e a definição de um fluxo de atividades. Um modelo de um objeto é uma representação, é uma simplificação desse objeto para que você possa entendê-lo de forma abrangente. 100 book.indb 100 31/5/2007 14:23:44 Gerência de Projetos Por exemplo, a maquete de um prédio é um modelo de como será o prédio ao ficar pronto. Ele mostra as partes do edifício, seu aspecto geral, numa proporção muito boa para que possamos entendê-lo antes de ficar pronto. Ele não é o prédio, é apenas o modelo do prédio. No entanto, a gente pode começar a detalhar mais e mais o modelo desse prédio, como, por exemplo, fazendo os projetos de instalações elétricas e de telecomunicações dele. Os desenhos dessas instalações são representações, bem detalhadas, de como serão tais instalações, porém continuam sendo modelos, pois não são as instalações em si. Modelar, dessa forma, significa representar um sistema, ou parte dele, em forma física (a maquete, por exemplo) ou simbólica (desenho do projeto elétrico, por exemplo), de tal maneira que se possa predizer ou descrever seu comportamento. Usa-se os modelos para facilitar a visão do futuro objeto, e ao mesmo tempo usa-se o modelo para ajudar a construir tal objeto, ou seja, o modelo pode lhe ajudar a realizar o projeto e chegar ao resultado final esperado. Assim, o modelo de representação é uma idealização do sistema físico, e ele nos auxilia na análise e na solução dos problemas. Sem os modelos não teríamos a civilização como a conhecemos. Algumas das principais características dos modelos, e que fazem com que tenham grande valor, são: „ usando um modelo não é preciso trabalhar diretamente com o sistema físico real, não é preciso construir o prédio inteiro para mostrá-lo, basta desenhar um fachada ou construir uma maquete; „ é prático e seguro trabalhar com modelos, pois caso as coisas não se afigurem tão boas, podemos abandonar tudo no começo; Unidade 3 book.indb 101 101 31/5/2007 14:23:44 Universidade do Sul de Santa Catarina „ graus de precisão dependerão do aprimoramento do modelo, ou seja, conforme a gente queira ter maior precisão de como será o projeto no final, podemos ir aprimorando paulatinamente sobre o próprio modelo; „ redução de tempo na análise, pois não precisamos ter o projeto pronto para fazer as primeiras simulações; „ o modelo abstrai o problema para o campo de domínio daquele que o analisa, quer dizer, ao modelar um problema, cada um o faz no campo que tem domínio; se é um desenhista, faz o desenho, se é um escultor, cria a maquete, se é um matemático, coloca na forma de equações, se é um escritor, coloca na forma de uma ficção ou poema, e assim por diante; „ os modelos não são únicos, ou seja, é possível fazer diversos tipos diferentes de modelo para uma mesma coisa; no caso do prédio, podemos representá-lo por meio de uma maquete de madeira e papelão, ou então por uma maquete eletrônica, ou pelo desenho artístico da fachada, etc., sendo que todas terão o seu valor; „ como o modelo é apenas uma representação, uma redução do real, ele contém erros, os quais são inerentes ao seu caráter de redução. Com essas características você pode perceber que os modelos têm inúmeras utilidades, não só para planejar a gestão de projetos, mas para planejar o próprio projeto. Basicamente considere como utilidades dos modelos de representação: modelos ajudam a PENSAR; „ permitem COMUNICAR; „ é possível PREVER; „ permitem CONTROLAR; „ nos ajudam a ENSINAR. „ 102 book.indb 102 31/5/2007 14:23:44 Gerência de Projetos Os modelos para apoio a projetos de engenharia e tecnologia, conforme Bazzo (1997) podem ser divididos em quatro tipos: „ Modelo ICÔNICO – é o modelo que representa com alto grau de semelhança o sistema físico, seja em duas dimensões (como no caso das fotos e mapas) ou em três dimensões (maquetes, esculturas, protótipos). Figura 3.1 – Exemplo de representação icônica – mapa urbano. „ Modelo DIAGRAMÁTICO – tem pouca semelhança com o sistema físico, e é apresentado por meio de símbolos, linhas, diagramas. Facilita a compreensão do funcionamento de uma máquina, um processo ou sistema, sem dispersar a atenção em detalhes de outra ordem, e um bom exemplo disso são os fluxogramas usados nas empresas, mostrando como se dá o fluxo de processos, ou então o organograma dessa mesma empresa, que mostra como se distribuem os cargos e departamentos. No entanto, por ser uma representação um pouco mais especializada, serve para aqueles que conhecem a convenção usada no diagrama. „ Modelo MATEMÁTICO – é um modelo simbólico abstrato, que está cada vez mais associado aos problemas de tecnologia avançada, sendo o de aplicação mais importante na engenharia. Os modelos matemáticos são os mais poderosos instrumentos de representação, e têm permitido modelos computacionais sofisticados, porém são altamente especializados e exigem conhecimento avançado dos usuários. Unidade 3 book.indb 103 103 31/5/2007 14:23:44 Universidade do Sul de Santa Catarina „ Modelo GRÁFICO – é o modelo que representa o comportamento de fenômenos por meio de curvas, gráficos, facilitando a sua verificação. Há diversos tipos de gráficos como, por exemplo, de linhas, com barras, em forma de pizza, etc. (veja, por exemplo aqueles disponíveis no Microsoft Excel), sendo que o traçado se dá a partir de um conjunto de valores previamente definidos pelo usuário – como você estudará, o Gráfico de Gantt é um modelo gráfico de representação. Projetos muito pequenos obviamente não precisam de um modelo, assim como a construção da casinha do cachorro não precisa certamente de uma planta dessa casinha. Se, no entanto, a casinha tiver algum grau de complexidade maior, é melhor desenhar. Tendo o modelo em mãos pode-se, então utilizar métodos de planejamento e criar um detalhamento de como se desenvolverá o projeto. Observe na figura 3.2, como se dá o fluxo do conhecimento durante o desenvolvimento de um projeto tecnológico. MODELO SEQUENCIAL Idéias, Pesquisa Preparação, Desenvolvimento Execução, Piloto, Engenharia Tempo MODELO SEQUENCIAL COM SOLAPAMENTO Tempo MODELO COM SOLAPAMENTO Tempo Figura 3.2 – Três modelos de fluxo de conhecimento no desenvolvimento de projetos tecnológicos Veja que as diferenças entre os três tipos de fluxos definem prazos diferentes de entrega, mas podem depender de como se deu a contratação e quais os riscos aceitáveis. Como lidar com a escolha dos modelos? 104 book.indb 104 31/5/2007 14:23:45 Gerência de Projetos A percepção clara de como se dará o desenvolvimento do projeto permitirá uma boa divisão e detalhamento das atividades. „ Na etapa inicial das idéias, chamada de “pesquisa”, são adquiridos os conhecimentos e informações necessárias para dar início ao projeto. Não há passagem para a próxima etapa, chamada de “desenvolvimento”, sem que todas as atividades da primeira etapa tenham sido concluídas. „ Na etapa do desenvolvimento ocorrem as primeiras implementações do projeto, como por exemplo, a escrita das primeiras versões de um software, a criação do protótipo, os testes iniciais, as simulações, etc. „ No modelo seqüencial a passagem para a etapa de “engenharia” só ocorrerá quando a etapa anterior estiver concluída. „ Na engenharia se dará a implantação do projeto, a criação de um piloto e sua colocação efetiva no mercado como, por exemplo, na finalização e entrega de um novo produto, o que inclui o início do funcionamento e suporte, ou a colocação em linha de fabricação de uma nova máquina. „ No modelo seqüencial o conhecimento adquirido em cada etapa não influencia a etapa anterior, e novas decisões são tomadas apenas com os conhecimentos já obtidos. Esse modelo de desenvolvimento de projetos é bastante conservador, e toma maior tempo de realização total, pois nenhuma atividade segue seu andamento se a atividade anterior não tiver sido totalmente concluída. A Unidade 3 book.indb 105 105 31/5/2007 14:23:45 Universidade do Sul de Santa Catarina construção civil usa esse modelo seqüencial como padrão e isso faz sentido, pois o tipo de projeto pressupõe fases bem divididas e com requisitos de precedência. Precedência – em projetos as atividades podem ter relações de dependência com outras atividades, anteriores, as quais são pré-requisitos para o seu início. „ Se, no entanto, as etapas sofrerem um certo grau de mesclagem, de tal forma que a etapa seguinte tenha início, enquanto a etapa anterior ainda está na fase de encerramento, denomina-se tal modelo de seqüencial com solapamento. Conhecimentos e problemas da etapa seguinte interferem positivamente na etapa anterior, obrigando revisões dinâmicas do processo. Projetos de equipamentos ou softwares são exemplos para esse tipo de modelagem. „ A situação radical de desenvolvimento de projetos é aquela onde as diferentes etapas estão totalmente entremeadas, chamada de modelo com solapamento, e percebe-se que os conhecimentos e problemas de uma etapa interferem nas soluções de todas as outras etapas, sejam anteriores ou posteriores. O fluxo de informações precisa então ser contínuo, e esse tipo de modelo pressupõe ênfase nos ambientes de comunicação e integração de equipes. Nesta seção você interagiu com a modelagem do fluxo das atividades de um projeto, e como podem ser os diversos modelos de representação, sejam do fluxo ou mesmo do projeto como um todo. A modelagem permite uma visão estratégica do projeto. A partir dessa visão estratégica você poderia dar início a sua operacionalização, e para isso necessitará contar com métodos e ferramentas, assunto da próxima seção. SEÇÃO 2 - Metodologias de planejamento – Gráfico de Gantt Para fazer o planejamento do projeto é necessário descer nos detalhes, ou seja, decompor todo o trabalho em suas menores partes. Essa decomposição significa dividir em tarefas cada vez menores as diversas atividades do projeto. 106 book.indb 106 31/5/2007 14:23:46 Gerência de Projetos Há duas maneiras de se decompor um projeto: na forma de um organograma ou “árvore de decomposição”, ou na forma de tabelas (Valeriano, 1998). Tanto a árvore quanto a tabela trazem as mesmas informações, sendo que a diferença está na forma de apresentação. Veja as figuras 3.3 e 3.4 a seguir que mostram uma divisão de tarefas do projeto fictício denominado “Exemplo”. Na figura 3.3 você pode ver a tabela com o rascunho da divisão de etapas e com as diversas tarefas que serão necessárias para compor cada uma delas. Essa tabela permite que sejam anotadas as diversas tarefas, e tal ferramenta, muito simples, permite que se escrevam todas as tarefas componentes. Projeto EXEMPLO Etapa 1 • Definições • Compra materiais • Organiza equipe • Documentação • ..... Etapa 2 • Desenho • Montagem • Documentação • ..... Etapa 3 • Teste 1 • Teste 2 • Documentação • Encerramento • ..... Figura 3.3 – Tabela com divisão de tarefas de um projeto “Exemplo”. Unidade 3 book.indb 107 107 31/5/2007 14:23:46 Universidade do Sul de Santa Catarina A árvore da figura 3.4 apresenta as mesmas tarefas e etapas, porém numa representação espacial, o que para algumas pessoas facilita a compreensão dos diversos componentes. É uma questão de escolha. Projeto EXEMPLO Etapa 1 Definições Compra Etapa 2 Org. Equipe Desenho Documentação Montagem Documentação Etapa 3 Teste 1 Teste 2 Documentação Teste 1 Figura 3.4 – O mesmo projeto da figura 3.3 em uma divisão por árvore de decomposição. Com esse tipo de divisão de tarefas é possível imaginar e localizar todos os componentes do projeto. A partir dessa divisão você iniciará a construção do planejamento para execução e gestão do projeto. Como planejar o desenvolvimento do projeto? Para tal, a seguir você estudará três métodos para planejar o desenvolvimento do projeto: „ Gráfico de Gantt, „ Diagramas PERT e „ Método do Caminho Crítico – CPM. São métodos que vêm sendo desenvolvidos nos últimos cem anos, especialmente após a Segunda Guerra Mundial, tendo tido grande ênfase nos anos recentes com os projetos que envolvem desenvolvimento de software e sistemas de alta tecnologia. 108 book.indb 108 31/5/2007 14:23:46 Gerência de Projetos a) Gráfico de Gantt - O gráfico de Gantt também é chamado de gráfico de barras. Foi concebido pelo engenheiro norte-americano Henry L. Gantt (1861-1919) (Hinojosa, 2003) para tentar resolver o problema da programação de diferentes atividades industriais, distribuindo-as no calendário de maneira que o conjunto de atividades pudesse ser visualizado, com a facilidade de se perceber, pelo tamanho de uma determinada barra, qual seria a duração da atividade que tal barra representaria. Ou seja, o início da barra marcaria a data de começo da atividade e o final da barra seu término, sendo que a barra se estende por todo o período compreendido entre as duas datas. A figura 3.5 mostra um exemplo de Gráfico de Gantt desenhado em planilha (neste caso com o auxílio do MS Excel). Veja que o projeto se estende do dia 14/ março até 17/abril, e é constituído de quatro etapas, havendo dois projetistas neste trabalho. As barras pretas mostram os prazos previstos para a execução de cada Etapa/Tarefa. Figura 3.5 – Exemplo de Gráfico de Gantt. Este tipo de gráfico permite desenhar uma barra com a duração prevista, e junto a ela outra barra que vai sendo preenchida conforme as tarefas vão sendo cumpridas, de tal forma que é possível acompanhar o andamento do projeto e a proporção de atraso ou quanto se está adiantado em relação ao previsto. Na figura veja a barra cinza da Etapa 1 mostrando o andamento do projeto até aquele momento. Se você estiver com o gráfico nessa posição no dia 21 de março, então perceberá que o projeto está cumprindo seu prazo. Unidade 3 book.indb 109 109 31/5/2007 14:23:46 Universidade do Sul de Santa Catarina Como você pode ver nesse exemplo, no eixo horizontal apresenta-se um calendário com a escala de tempo pertinente e mais adequada ao projeto (dias, semanas, meses, etc.). No eixo vertical estão incluídas as atividades que serão executadas, sendo que a barra de duração da atividade é pintada no eixo horizontal ocupando o prazo previsto. O formato da barra, sua cor, grossura da linha, etc., depende apenas de quem a está construindo e da facilidade de visualização que se requer. Projetos com equipes muito grandes costumam imprimir tais gráficos em painéis grandes, para que num único relance se possa ver as etapas, como vai indo o dia-a-dia do projeto, os principais responsáveis, datas de início e fim, etc. O gráfico que Henry Grantt criou tornou-se imensamente popular e passou a ser utilizado, sem grandes modificações, no gerenciamento de todos os tipos de projetos em todo o mundo. Umas das desvantagens apontada era que não interligava uma atividade à outra, ou seja, não deixava clara a interdependência entre as diferentes atividades. Versões recentes desse tipo de gráfico passaram então a utilizar setas de ligação entre as diferentes barras, para mostrar esse tipo de dependência, especialmente a partir do uso de softwares como o MS Project. Porém não é necessário um software para se construir o Gráfico de Gantt, e justamente por isso é tão popular e essa é uma das suas grande vantagens: o traçado simples e direto. Com isso passa a ser muito útil nas etapas iniciais de planejamento (Hinojosa, 2003), mas quando o projeto passa a se desenvolver e modificações no planejamento acontecem, o gráfico começa a se tornar confuso. A replanificação exige que se faça um novo gráfico. Também uma desvantagem é que o gráfico de Gantt não apresenta custos das etapas, e dificilmente se adapta a projetos muito complexos com múltiplas tarefas simultâneas. Nesses casos se usam outros métodos, como PERT e CPM. A seguir acompanhe o desenvolvimento de um exemplo simples para aplicação do Gráfico de Gantt. 110 book.indb 110 31/5/2007 14:23:47 Gerência de Projetos Vamos supor a construção de uma área de lazer com 30 metros quadrados, churrasqueira, pia e banheiro. E é um exemplo suficientemente comum para explorarmos todas as questões relacionadas ao gerenciamento de um projeto que envolve equipe. A idéia partiu do cliente, que pretende fazer uma comemoração, e nos deu o prazo de oito semanas para entregarmos a obra pronta, sendo que todos os materiais para a obra são fornecidos por ele. Vamos começar fazendo a decomposição do projeto em tarefas, e para isso utilizaremos a decomposição em tabela. Chamaremos este novo projeto de “Churrasqueira”. Proponho a seguinte divisão: Projeto CHURRASQUEIRA Etapa 1 – Preparação do terreno • Limpeza do terreno • Medições e marcações • Escavações Etapa 2 – Fundações • Montagem das madeiras de caixaria • Montagem das ferragens da fundação • Concretagem Etapa 3 – Alvenaria • Construção das paredes • Montagem da churrasqueira • Rebocos Etapa 4 – Telhado • Montagem da estrutura de madeira • Colocação de Telhas Etapa 5 – Piso • Concretagem do piso • Assentamento da Cerâmica do piso Etapa 6 – Carpintaria • Colocação de janelas • Colocação de portas Etapa 7 – Instalação Hidráulica • Tubulações de água • Colocação da caixa dágua Unidade 3 book.indb 111 111 31/5/2007 14:23:47 Universidade do Sul de Santa Catarina • Montagem de torneiras, descargas, acessórios • Esgoto Etapa 8 – Instalação Elétrica • Instalação das Tubulações • Passagem dos cabos alimentadores • Montagem das tomadas, luminárias e quadros Etapa 9 – Pinturas e acabamento • Pintura externa • Pintura interna • Limpeza final e entrega da obra Figura 3.6 – Tabela com divisão de tarefas do projeto “Churrasqueira”. Ao analisar a divisão acima percebemos que o projeto não é tão simples como podia parecer à primeira vista, pois há inúmeras tarefas, as quais ainda poderiam ser mais detalhadas. Por ser um exemplo, ficaremos com o que está definido acima. Considerando essas nove etapas vamos construir um gráfico de Gantt simples e útil para nosso projeto. Vamos começar com uma planilha dividida em nove barras horizontais, onde anotaremos as etapas, e oito colunas onde anotaremos as semanas, como o da figura 3.7 abaixo. Neste desenho incluí algumas divisões para facilitar nosso trabalho, tais como a divisão das colunas das semanas nos seus sete dias, com marcação do sábado (S) e do domingo (D), e nas barras horizontais fiz uma divisão para marcarmos o prazo previsto (Prev) e outra divisão para depois podermos anotar o realizado (Real), conforme o projeto for andando. Além disso, no espaço reservado para escrever o nome das etapas, há também um questionamento sobre quem irá realizar aquela tarefa, ou seja, quem é o responsável por aquela tarefa específica. Isso é muito útil para poder distribuir as responsabilidades, e também é útil para aquele que vai trabalhar nela, pois pode compreender sua função no conjunto das atividades bem como o impacto de seu prazo sobre o restante. 112 book.indb 112 31/5/2007 14:23:47 Gerência de Projetos Figura 3.7 – Planilha para Gráfico de Gantt do projeto “Churrasqueira”. O prazo de dois meses parece ser bastante enxuto, então teremos que ser cuidadosos na distribuição dos prazos para termos sucesso. E vejam que neste projeto o sucesso significa acabar antes do dia da comemoração, não sendo admitida outra possibilidade. A equipe que trabalhará conosco neste projeto será constituída, além do gestor (você), também de um mestre de obras, um pedreiro, um servente, um carpinteiro, um eletricista, um encanador e um pintor. São oito pessoas, sendo que alguns estarão presentes apenas em algumas etapas da obra. Fazendo uma reunião preliminar com todos os membros da equipe estimamos os seguintes prazos de execução para cada etapa: Projeto churrasqueira Prazos estimados pela equipe Dependência Etapa 1 – Preparação do terreno 2 dias - Etapa 2 – Fundações e estrutura 1 semana Etapa 1 Etapa 3 – Alvenaria 4 semanas Etapa 2 Etapa 4 – Telhado 1 semana Etapa 2 Etapa 5 – Piso 2 semanas Etapa 4 Etapa 6 – Carpintaria 1 semana - Etapa 7 – Instalação Hidráulica 1 semana Etapa 4 Etapa 8 – Instalação Elétrica 1 semana Etapa 4 Etapa 9 – Pinturas e acabamento 2 semanas Etapas 2 e 4 Figura 3.8 – Estimando prazos para as etapas do projeto “Churrasqueira”. Se repararmos nessa estimativa de prazos, chegamos a 13 semanas e 3 dias, o que supera a data final que dispomos. Porém, sabemos que algumas atividades podem ser feitas em paralelo, e nesse sentido é que Unidade 3 book.indb 113 113 31/5/2007 14:23:47 Universidade do Sul de Santa Catarina vamos traçar nosso primeiro esboço de gráfico de Gantt, que está apresentado na figura 3.9, assumindo as dependências ainda de forma muito simplificada. Figura 3.9 – Gráfico de Gantt do projeto “Churrasqueira” – primeiro esboço. Algo que se nota neste gráfico é que, para adequar o projeto ao prazo total, necessitamos colocar algumas atividades em paralelo, e isso é muito natural. O serviço do telhado começou mais ou menos no meio das atividades de alvenaria, e o piso está dividido em duas fases, sendo que a segunda fase aparece apenas após o encerramento de todo o trabalho da alvenaria. Da mesma forma as instalações hidráulicas e elétricas estão divididas em duas etapas. Esse projeto é simples, então não é difícil perceber essas possibilidades de trabalho em paralelo para otimizar o tempo e a equipe, porém se alguém que não conhece o projeto der uma olhada neste gráfico, não entenderá porque há uma interrupção na instalação hidráulica em determinado ponto, e nem porque ela começa na quinta semana e não apenas na sétima, por exemplo. Uma divisão mais detalhada facilitaria essa visão externa, e certamente também facilitaria a própria gestão do projeto. Uma nova opção de gráfico de Gantt deste mesmo projeto está apresentada na figura 3.10. 114 book.indb 114 31/5/2007 14:23:48 Gerência de Projetos Figura 3.10 – Gráfico de Gantt do projeto “Churrasqueira”. Este gráfico detalha melhor algumas fases, que permite que se veja a dependência entre um serviço e outro. A dependência não está explícita no gráfico, porém alguém com mais experiência perceberá que o serviço de telhados depende da finalização da construção das paredes, e após o telhado ficar pronto serão colocadas as tubulações elétricas e hidráulicas. A concretagem do piso poderá ser feita também após a conclusão do telhado, e começaremos a pintura externa após a colocação das janelas e portas. Depois da conclusão do piso faremos os acabamentos das instalações elétricas, passando todos os cabos e instalando tomadas e luminárias, bem como instalando acessórios da parte hidráulica. Por fim faremos a pintura externa e limpeza geral da obra. Este exemplo é obviamente uma suposição de serviço, mas ele espelha exatamente o que ocorre em todos os projetos. Você pode ter muitas dúvidas quando o serviço está por começar, e então é necessário fazer alguns desenhos iniciais e avaliar se será útil a divisão que inicialmente foi pensada. Caso não seja, ou caso você perceba que é possível detalhar um pouco mais, então é importante fazê-lo. Unidade 3 book.indb 115 115 31/5/2007 14:23:48 Universidade do Sul de Santa Catarina No gráfico apresentado foi também preenchido o nome da pessoa da equipe responsável por cada etapa. Desta forma é possível definir as atividades de cada um, e assim o trabalho individual será otimizado. O eletricista, por exemplo, poderá participar de vários outros projetos, bastando para isso preparar sua agenda conforme a distribuição de tarefas em cada projeto. Volte agora ao gráfico da figura 3.10 para analisar outra característica desse tipo de diagrama. Apesar de você saber que uma atividade deve começar apenas quando outra terminar (como por exemplo, o telhado somente após as paredes e estrutura estarem montadas), isso não está tão evidente no desenho. A pessoa que não conhece o projeto não perceberá esse tipo de dependência. Foi preciso avançar na construção desse tipo de diagramas e introduzir relações de dependência, o que se dá em todos os modernos softwares de geração de gráficos de Gantt. Como são as relações de dependência entre as atividades no gráfico de Gantt? É possível serem criadas dependências de quatro tipos entre atividades: 1. Dependência fim-início, quando o início de uma Atividade B só é possível após o fim da Atividade A; 2. Dependência fim-fim, quando o final da Atividade B deve, necessariamente, coincidir com o fim da Atividade A; 3. Dependência início-início, quando o início da Atividade B deve, necessariamente, coincidir com o início da Atividade A; 4. Dependência fim-início com folga, quando o início de uma Atividade B só é possível após o fim da Atividade A, porém há um tempo de folga para o início da Atividade B. 116 book.indb 116 31/5/2007 14:23:48 Gerência de Projetos A representação gráfica dessas relações de dependências é feita com setas interligando as extremidades das atividades, como se vê nas figuras seguintes. Atividade A Atividade B Figura 3.11 – Dependência Fim-Início num Gráfico de Gantt, onde B depende de A. Atividade A Atividade B Figura 3.12 – Dependência Fim-Fim num Gráfico de Gantt, onde B depende de A. Atividade A Atividade B Figura 3.13 – Dependência Início-Início num Gráfico de Gantt, onde B depende de A. Atividade A Atividade B FOLGA Figura 3.14 – Dependência Fim-Início com folga num Gráfico de Gantt, onde B depende de A. A introdução das setas que mostram dependências foi um grande avanço na visualização do planejamento, antes apenas possível pela distribuição das barras num gráfico com escala de tempo. Essa introdução permitiu perceber que as setas poderiam indicar algo mais no gráfico, e daí em diante um novo conjunto de gráficos e diagramas foi desenvolvido, e chega-se então ao Método do Caminho Crítico (CPM) e diagramas PERT. Unidade 3 book.indb 117 117 31/5/2007 14:23:49 Universidade do Sul de Santa Catarina SEÇÃO 3 - Metodologias de planejamento – PERT/CPM Após a Segunda Guerra Mundial, surgiu um projeto do governo norte-americano que acabou causando profunda influência na disciplina de gestão de projetos. Era o projeto Polaris, da Marinha, para produzir uma série de submarinos nucleares em cinco anos. Esse projeto iria envolver mais de 9000 empreiteiros diferentes, e devia ter o “de acordo” do Congresso, o que teve um enorme impacto tal o clima de desconfiança que o projeto gerou, pois sabia-se que os prazos e custos de projetos militares eram constantemente estourados (Prado, 1998). Para reverter esse quadro de desconfiança e ter o projeto aprovado, foi criada uma equipe especialmente para planejar e fiscalizar o seu andamento e a construção dos submarinos. Essa equipe foi denominada Program Evaluation and Review Task Force, gerando a sigla PERT, que posteriormente viria a denominar a técnica de representação do planejamento do projeto por eles desenvolvida – Program Evaluation and Review Technique - PERT. Figura 3.15. Submarino Polaris – extraída de http:// stores.ebay.com/The-Silent-Service-SubmarineStore O projeto Polaris supreendeu e foi desenvolvido em apenas três anos, o que atraiu grande atenção para a equipe e para a técnica que eles desenvolveram para a gestão de projetos. Na década de 60 muitas melhorias foram incrementadas à técnica, incluindo o Critical Path Method – CPM (Método do Caminho Crítico), e todas as técnicas de representação de projetos por redes de atividades e dependências acabaram sendo reunidas atualmente, no que se denomina PERT/CPM. A idéia dessas técnicas era criar um diagrama que verificasse os pré-requisitos de cada atividade, de forma que se pudesse compreender qual seria o conjunto de atividades, com seus prazos e em seqüência cronológica, de tal maneira que fosse possível traçar o “caminho crítico” do projeto, ou seja, a seqüência de atividades que determinariam o menor tempo possível do projeto. 118 book.indb 118 31/5/2007 14:23:50 Gerência de Projetos Aonde se pode aplicar as técnicas PERT/COM? Entre as várias aplicações das técnicas PERT/CPM pode-se citar: „ definir as atividades de um projeto; „ determinar a duração de cada atividade; „ com base nos prazos de cada atividade, buscar o prazo mínimo para o projeto total; „ encontrar as ligações temporais entre as diversas atividades, ou seja, verificar os tempos de folga entre atividades seqüenciadas; „ identificar quais atividades são críticas no projeto, ou seja, aquelas cujo prazo determina o andamento de todo o projeto, e que se ocorrer um problema qualquer de atraso, todo o projeto sofrerá retardo; „ determinar qual é a seqüência crítica do projeto considerando as atividades críticas, ou seja, determinar a seqüência de atividades críticas que perfazem o “caminho crítico” do projeto; „ verificar os tempos de folga que existem entre as atividades, de tal modo que se possa trabalhar com esses prazos durante a execução do projeto sem afetar o prazo total. Diferente do Gráfico de Gantt, onde cada atividade ocupa uma barra do painel, nessas técnicas de revisão e do caminho crítico são usadas setas para compor o diagrama. Observe o desenho da figura a seguir (figura 3.16), onde cada seta representa uma determinada atividade (atividade A, atividade B, ....) e os círculos representam um evento ou nó, que é a conclusão de uma ou mais atividades.. Unidade 3 book.indb 119 119 31/5/2007 14:23:51 Universidade do Sul de Santa Catarina Figura 3.16 – Diagrama de setas simples com nós, que denotam a conclusão de atividades. Como você pode ver no diagrama, a duração de cada atividade não está representada pelo comprimento da seta, pois os comprimentos dessas não têm escala. O que mais importa aqui é verificar qual atividade depende de outra, sua precedente. No caso desse exemplo da figura 3.16 você pode ver que a atividade B só ocorre depois de A, e D ocorre depois de B. No entanto, para que a atividade H possa acontecer, necessariamente você precisa ter concluídas as atividades C e D. Ou seja, o diagrama de setas define uma lógica para a seqüência de execução. As diferenças entre os métodos como o Gráfico de Gantt e o as técnicas PERT/CPM acontecem devido ao tipo de representação e de escala utilizadas. No Gráfico de Gantt existe uma escala de tempo bem definida, mas a representação das precedências, da vinculação entre diferentes atividades e do “caminho crítico”, nem sempre são evidentes. Para entender como se dá na prática as técnicas PERT/CPM primeiramente acompanhe uma comparação gráfica entre os diferentes métodos, e então evoluirá seu estudo a partir desse ponto. Na figura 3.17 há duas representações para projeto “Churrasqueira”, que você já estudou na seção anterior. Na parte superior da figura veja o Gráfico de Gantt, exatamente o mesmo que foi estudado anteriormente. 120 book.indb 120 31/5/2007 14:23:51 Gerência de Projetos Figura 3.17 – Diagrama de setas com escala e acima o Gráfico de Gantt do projeto “Churrasqueira”. Na parte inferior da figura está um representação por diagrama de setas do mesmo projeto, onde as letras denominam as atividades, conforme a seguinte tabela de correspondência: A PREPARAÇÃO DO TERRENO B FUNDAÇÕES C ALVENARIA - PAREDES D ALVENARIA - REBOCO E CERÂMICAS E TELHADO F PISO G CARPINTARIA H TUBULAÇÃO HIDRÁULICA I INSTALAÇÃO HIDRÁULICA J TUBULAÇÃO ELÉTRICA K INSTALAÇÃO ELÉTRICA L PINTURA EXTERNA M PINTURA INTERNA E ACABAMENTO Figura 3.18 – Tabela com lista de atividades. O diagrama de setas do projeto “Churrasqueira” da figura 3.17 está construído dentro da escala de tempo definida no gráfico de barras que está acima dele, como você pode ver. Percebam que cada nó está colocado exatamente na coluna que representa o início ou final de uma determinada atividade. Repare, por exemplo, na atividade E – Telhado: o nó onde começa a seta está no início do dia 7 de abril, e o nó no final da seta está no dia 13. A seta E então compreende 7 dias. Mesmo para Unidade 3 book.indb 121 121 31/5/2007 14:23:51 Universidade do Sul de Santa Catarina um projeto simples como este o desenho com setas acaba se tornando razoavelmente complexo, e de fato não nos mostra muitas coisas. Da forma como foi apresentado não lhe parece um modelo diagramático ruim, e que o Gráfico de Gantt estava bem melhor? Acontece que a riqueza desse tipo de diagrama não está em representar na escala temporal o desenvolvimento do projeto, mas sim nos mostrar os seus pontos críticos de atraso. Para você entender melhor isto, veja que a seguir são feitas duas modificações no diagrama de setas do projeto “Churrasqueira”: Redesenho do diagrama para que fique mais claro, retirando a escala de tempo; „ Para não perder a referência das atividades quanto ao seu prazo estimado, sob cada seta é colocado o número de dias de sua duração. „ Figura 3.19 – Diagrama de setas modificado do projeto “Churrasqueira”. Com essas duas modificações simples se obtem o diagrama da figura 3.19 (apesar das atividades A, B e C serem diferentes, estas são reunidas numa seta para simplificar o diagrama). 122 book.indb 122 31/5/2007 14:23:51 Gerência de Projetos Bem, apesar de ser um desenho limpo, ainda não é suficientemente claro para ajudar no planejamento do projeto, não é mesmo? Que conceitos e símbolos são utilizados nos diagramas PERT/COM? Para construir os diagramas PERT/COM mais objetivos e limpos são utilizados alguns conceitos e símbolos. Com tais símbolos, apresentados no quadro da figura a seguir, você poderá então fazer a construção final do diagrama do projeto “Churrasqueira” e partir para sua análise como ferramenta de apoio na gestão de projetos. Figura 3.20 – Quadro com simbologia e nomenclatura utilizados em diagramas PERT/CPM. Unidade 3 book.indb 123 123 31/5/2007 14:23:51 Universidade do Sul de Santa Catarina Como você pode ver na figura 3.20, alguns novos conceitos estão apresentados, tais como “data mais cedo e mais tarde”, folgas e símbolos com informações: „ Data mais cedo (dc) - representa a primeira data onde pode ocorrer o evento. „ Data mais tarde (dt) - é a última data em que esse evento pode ocorrer, sem afetar o prazo do projeto. „ A “data mais tarde” existe quando há uma folga no projeto, e a folga específica da atividade é chamada de “folga”. „ A sequência de atividades que define o prazo crítico do projeto, ou seja, aquela seqüência onde alterações implicam alteração do prazo total do projeto, é chamada de “caminho crítico”. Saiba que você ainda poderia simplificar um pouco mais o desenho. Observe que o nó ao final da atividade D, o nó que dá origem à atividade L e o nó ao final da atividade G podem ser reunidos em um só, sem alterar a ordem das atividades. Assim o diagrama passaria a ser: Figura 3.21 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplificação 1. Esse diagrama pode ser simplificado mais uma vez. A seta fantasma que une os nós do final da atividade E e do início da atividade G pode ser suprimida, juntando 124 book.indb 124 31/5/2007 14:23:52 Gerência de Projetos então esses dois nós. Com um pequeno rearranjo das setas e dos nós teríamos então, o desenho simplificado do diagrama, conforme apresentado na figura 3.22. Repare como o diagrama ficou mais simples e objetivo, e como foi alterado desde o original. É importante reparar que todo esse processo de construção foi realizado aqui para demonstrar a construção do diagrama PERT/CPM, mas na prática você pode desenhá-lo diretamente, apenas sabendo as atividades, suas precedências e respectivas durações. As ferramentas computacionais fazem isso automaticamente. Acompanhe a figura: Figura 3.22 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplificação 2. Tendo agora o diagrama desenhado, o próximo passo será introduzir os símbolos que permitem colocar as informações detalhadas do plano. Em primeiro lugar se coloca os nós e para cada um se dá um “nome”, neste caso uma dezena para cada nó de forma que, se precisar posteriormente inserir algum novo nó, use a numeração intermediária (ver figura 3.23). Como você pode perceber, todas as datas de início, mais cedo e mais tarde, estão em branco. Veja que é assumida a data mais cedo para o nó 10 como sendo “1”, ou seja, o “primeiro dia” da atividade ABC, e a partir daí conte as datas em dias (mas não há problema se assumir a data mais cedo como “0”). Unidade 3 book.indb 125 125 31/5/2007 14:23:52 Universidade do Sul de Santa Catarina Figura 3.23 – Diagrama projeto “Churrasqueira”, detalhamento 1. Uma vez que você tenha a primeira “data mais cedo” definida, pode-se ir preenchendo as dc dos outros nós. A dc do nó 20 será a dc do nó 10 mais a duração da atividade ABC, ou seja, dc20 = dc10 + duraçãoABC E assim, fazendo todas as contas até o último nó, você obterá a data final do projeto, como apresentado na Figura 3.24. Figura 3.24 – Diagrama projeto “Churrasqueira”. Preenchido completamente o último nó, é possível fazer o caminho inverso do diagrama preenchendo agora a “data mais tarde” de início de cada atividade. A data mais tarde do nó 70, dt70 , será encontrada subtraindo-se a duração da atividade M, da seguinte forma: 126 book.indb 126 31/5/2007 14:23:52 Gerência de Projetos dt70 = dt80 – duraçãoM Adotando, assim, o mesmo procedimento para todos os nós, você obterá como resultado a figura 3.25, a seguir. Figura 3.25 – Diagrama PERT/CPM final do projeto “Churrasqueira”. No diagrama veja que o caminho de atividades onde não há folga define o “caminho crítico” das atividades do projeto. Sobre esse conjunto de atividades o gestor deve prestar atenção especial e preparar suas estimativas de recursos e custos. Enquanto no Gráfico de Gantt é possível ver a escala temporal claramente, bem como, a pessoa responsável por cada atividade e também acompanhar o andamento do projeto ao longo do tempo (preenchendo uma barra das tarefas “executadas”); no diagrama PERT/CPM é possível determinar a seqüência de atividades com suas precedências, e perceber claramente quais as atividades que podem afetar todo o andamento do projeto. Nesse sentido é importante ter as duas ferramentas como instrumentos objetivos de apoio ao gestor. Uma vez compreendido o estudo das seções iniciais desta unidade, você concluiu o estudo de ferramentas de apoio para o planejamento das etapas de um projeto. Unidade 3 book.indb 127 127 31/5/2007 14:23:52 Universidade do Sul de Santa Catarina E uma vez tendo o planejamento realizado e os prazos estimados, é preciso agora estimar os recursos e custos necessários ao projeto. Siga em frente! SEÇÃO 4 - Estimativa de recursos e custos Tendo um planejamento do projeto, é possível estimar os recursos necessários para ele. Bem, estimar não é uma ciência exata. DeMarco (1991), propõe algumas definições um pouco diferentes, tais como: Estimativa é a previsão mais otimista que não tem uma probabilidade zero de tornar-se realidade. Uma estimativa é uma previsão que tanto pode estar acima quanto abaixo do resultado real. Essas definições soam estranhas, mas dizem muito sobre o ato de estimar: é um “chute” que pode marcar o gol ou apenas passar mais ou menos perto. Precisamos estimar o melhor possível para evitar riscos durante o projeto. Quais são os recursos necessários a um projeto? Quanto aos recursos necessários a um projeto, basicamente há os seguintes: „ Materiais – são os produtos necessários para confeccionar o projeto, tais como matérias-primas, produtos manufaturados, componentes, hardware, etc.; „ Equipamentos – são as máquinas e ferramentas necessárias para poder trabalhar as matérias-primas, escrever o código de um software, facilitar uma construção, etc.; 128 book.indb 128 31/5/2007 14:23:52 Gerência de Projetos „ Pessoal – os recursos humanos aparecem como o principal requisito em projetos, especialmente em projetos de tecnologia, na próxima unidade discutiremos este item; „ Financeiros – são os custos do projeto, que advém dos gastos relativos a materiais, equipamentos, locações, transportes, pessoal, licenças, fretes, direitos autorais, etc.; a estimativa de custos é o assunto da próxima seção. Como você já acompanhou, o planejamento do projeto tem um foco muito intenso no prazo geral, pois como projetos são trabalhos com data marcada para acabar, o prazo é algo determinante. Para realizar o planejamento se faz uma divisão de tarefas, e essa divisão é o fator que irá permitir estimar recursos, tarefa por tarefa. Dessa forma se pode partir da tabela onde as tarefas foram divididas e incluir colunas específicas para descrever recursos necessários. Unidade 3 book.indb 129 129 31/5/2007 14:23:53 Universidade do Sul de Santa Catarina A tabela apresentada na figura a seguir é um exemplo de relatório a ser preenchido no início do projeto. Este exemplo partiu de tabela anterior. Projeto CHURRASQUEIRA Recursos necessários Etapa 1 – Preparação do terreno • Limpeza do terreno Tratores (dois dias) • Medições e marcações Topógrafo • Escavações Tratores (um dias) Etapa 2 – Fundações • Montagem das madeiras de caixaria XX dúzias de madeira para caixaria; Pessoal para montagem da caixaria; • Montagem das ferragens da fundação XX barras de ferro; • Concretagem XX caminhões de concreto Etapa 3 – Alvenaria • Construção das paredes XX milheiros de tijolos; Xx sacos de cimento; Etc. • ........ ........... Figura 3.26 – Divisão de tarefas com estimativa de recursos. Para cada projeto específico deverá ser construída uma tabela exclusiva, sendo que a coluna dos recursos definirá uma lista de necessidades. A próxima etapa é realizar a estimativa dos custos. Como realizar a estimativa de custos? A distribuição de custos do projeto é feita num gráfico chamado de “cronograma físico-financeiro”. Aproveita o gráfico de barras que você estudou no Gráfico de Gantt, sendo que os custos do projeto podem ser distribuídos ao longo do tempo de duração do projeto. Para cada item, definido nos recursos estimados para o desenvolvimento do projeto, é 130 book.indb 130 31/5/2007 14:23:53 Gerência de Projetos feita uma estimativa de gastos. O uso do gráfico de barras é interessante nesse caso, devido à clareza visual de apresentação. A seguir, acompanhe um exemplo para entender melhor esse tipo de cronograma. Na figura 3.27 é apresentado o Gráfico de Gantt de um projeto hipotético com sete atividades – Tarefas A até G – cujos trabalhos transcorrem em 16 semanas, aproximadamente quatro meses. Tendo estimados os recursos necessários para desenvolver cada tarefa, os custos podem ser distribuídos por tarefa e por unidade de tempo, nesse caso por semana. Sobre o próprio gráfico os valores são anotados, semanalmente, e se tem aí o Cronograma Físico-Financeiro. Figura 3.27 – Estimando custos – cronograma físico-financeiro. Fazendo a estimativa de custos por atividade e por unidade de tempo é possível chegar a valores mais próximos do real. Quanto maior a divisão das tarefas, melhor. Anotados todos os valores fazemos a somatória, também por unidade de tempo. A cada semana se chega a um valor total, conforme você pode ver na última linha do gráfico. Com tais valores se pode estimar o valor total de custos do projeto, apresentado no canto inferior direito da figura. Unidade 3 book.indb 131 131 31/5/2007 14:23:53 Universidade do Sul de Santa Catarina Outra visualização dos custos desse mesmo projeto é apresentada na figura 3.28, a qual decorre dos valores obtidos na estimativa do gráfico de barras. Figura 3.28 – Gráfico de linha do cronograma físico-financeiro. Percebe-se pelo gráfico da figura 3.38 que o projeto deverá dispor de recursos financeiros bem maiores do que a média nas semanas 6 e 7. Fazendo essa análise pode-se retornar ao planejamento do projeto e, caso necessário, alterar a duração das tarefas que impactam nesses valores, nesse caso especialmente a Tarefa C. Se não for possível alterar, então o caixa do projeto deverá estar preparado para tal fluxo. Uma vez que você compreendeu como realizar a estimativa dos cursos, na próxima seção veja como estruturar os recursos humanos em projetos. 132 book.indb 132 31/5/2007 14:23:53 Gerência de Projetos SEÇÃO 5 - Recursos humanos em projetos Para entender este tema que tal pensar um campeonato de futebol como um projeto: Em um campeonato de futebol, onde cada time traça seus objetivos, contrata jogadores, treinador, busca recursos e tem datas definidas para chegar aos resultados. Há inúmeros riscos, pois é uma competição com muitas variáveis. Sabe-se que uma questão muito importante, sempre discutida pelos comentaristas e que também é a conversa do início de cada semana após uma rodada emocionante, trata da formação e do entrosamento dos jogadores dentro de campo. Cada jogador tem sua função, sabe-se mais ou menos sobre suas qualidades, e alguns são reconhecidos por sua competência. No entanto, em cada partida há um comportamento diferente, há um jeito diferente de jogo, e simultaneamente encantamentos e decepções. Certamente os projetos de pesquisa, de engenharia, de software, não são assim tão famosos nem tão visíveis, mas muitas vezes são bastante emocionantes. E vão depender do espírito de “time” na equipe. Constituir uma equipe é relativamente fácil, constituir um time, não tanto. A equipe é constituída a partir da definição de funções, então é possível determinar as características necessárias de um indivíduo para que preencha tal função. Grandes companhias preparam uma lista de requisitos mínimos para que se procurem funcionários para determinada vaga. Em algumas, há pessoas trabalhando no recrutamento que atuam como máquinas de verificação: olham currículos e buscam Unidade 3 book.indb 133 133 31/5/2007 14:23:53 Universidade do Sul de Santa Catarina aquelas que preenchem tais requisitos, depois fazem as entrevistas e as análises de perfil, e por fim alguém é contratado e passa a integrar a equipe. Essas companhias enxergam o trabalho como atividade rotineira, e muitas vezes máquinas e pessoas não fazem grande diferença (a pessoa nesse caso é um agente que toma decisões e tem liberdade de ação, ao contrário da máquina). Atividades rotineiras até podem suportar equipes assim, mas com certeza projetos não. Projetos, assim como campeonatos, exigem pessoas que trabalhem em cooperação e que gostem, realmente, de chegar aos resultados com sucesso. Numa equipe convencional, de rotina, cada um faz a sua função (não precisaria ser assim!). Num projeto os membros da equipe trabalham para ajudar os outros, fazendo a sua função e colaborando para que os outros realizem as suas. O primeiro conceito importante na formação de uma equipe é cooperação. O segundo conceito importante é: objetivo comum. Formar uma equipe que trabalhe com objetivo comum e de forma cooperativa é um verdadeiro desafio (basta ver que muitas vezes os times com os melhores jogadores não ganham o campeonato – algo ficou faltando!). Isso quer dizer que não basta analisar as competências pelo currículo. É necessário que, além da competência, a pessoa que vai fazer parte da equipe de projeto tenha a cultura da colaboração. Isso não pode ser detectado sem a convivência. E gerentes de projetos que não sejam líderes, muitas vezes não conseguirão entender essa característica. Essa percepção exige experiência e intuição. Perceba que aqui se sai do campo das ciências exatas e entra no campo “pantanoso” das relações humanas (nada exatas...). 134 book.indb 134 31/5/2007 14:23:53 Gerência de Projetos Quais são os momentos distintos no processo de se estruturar uma equipe para um projeto? Na estruturação da equipe de um projeto, conforme Valeriano (1998),há quatro momentos distintos: „ Formação: quando se reúnem os membros do projeto e as funções são distribuídas; ainda não há clareza das atividades a serem realizadas, as pessoas não se conhecem e o tratamento é formal; por não haver conhecimento há um ambiente de confusão inicial; „ Turbulência: a partir do início das atividades começam a se formar subgrupos, a partir de afinidades pessoais, e muitas vezes principiam atritos, especialmente em equipes grandes com pessoas de variados tipos; a turbulência é comum em projetos, especialmente quando os riscos são grandes e iminentes; „ Normalização: se os períodos de turbulência são resolvidos pela liderança, os processos de trabalho passam a ser bem conhecidos e aceitos por todos. As atividades tornam-se claras, assim como os objetivos, estabelecem-se normas internas e o trabalho passa a andar; „ Desempenho: nesse período a equipe entra em equilíbrio criativo e cooperativo, e o projeto tem alto rendimento; os membros sentem-se parte do time de trabalho, reconhecem a liderança e os companheiros como importantes em seu próprio papel. Essas quatro fases de estruturação podem acontecer ou não, sendo que muitos projetos chegam a crescer até a normalização, sem atingir o ambiente propício do “desempenho”. Sustentar a fase do desempenho é, além de tudo, uma tarefa difícil que exige esforço contínuo do gestor. Veja na figura a seguir, o diagrama esquemático dessa estrutura. Unidade 3 book.indb 135 135 31/5/2007 14:23:53 Universidade do Sul de Santa Catarina Figura 3.29 – Representação esquemática das fases de estruturação da equipe de projeto. Se o gestor for um líder, poderá conduzir sua equipe para a fase do “desempenho”. Se não, provavelmente permanecerão na fase da “normalização”. E, além da liderança, os perfis das pessoas que virão a fazer parte de nossas equipes de projeto vão influenciar o ambiente de cooperação. Keeling (2002), apresenta diversos tipos de perfis citando outros autores, tais como Margerison e McCann, que comentam sobre oito diferentes papéis, Belbin, que classifica nove grupos descritivos, ou Parker, com apenas quatro papéis. Os quatro papéis de Parker, citados por Keeling (2002) são: „ Contribuidor – aquele que contribui com atividades e resultados, mas não é participativo; „ Colaborador – o que participa do desenvolvimento em conjunto; „ Comunicador – capaz de comunicar as atividades e de integrar grupos por meio da comunicação; „ Desafiador – o que sempre apresenta as questões e participa dos trabalhos num espírito de desafio (o que pode ser bom ou ruim, dependendo da situação ). Na composição dos membros de uma equipe uma alternativa interessante é criar a matriz de qualidades desejáveis e de funções necessárias em um projeto. 136 book.indb 136 31/5/2007 14:23:53 Gerência de Projetos Imagine que você tenha um grupo de pessoas na empresa que possa vir a participar do projeto, e precisa definir suas posições. Ao mesmo tempo, sabese as competências técnicas e comportamentais necessárias para trabalhar nele. Criar e preencher uma matriz, como a do exemplo da figura 3.30, ajuda a perceber os perfis e a maneira de distribuir os papéis. Perfil e necessidades Conhecer Membro da equipe Profissional A Conhecer Conhecer tecnologia tecnologia tecnologia “1” “2” “3” X Profissional B Profissional C Exp. de Exp. de trabalho trabalho em equipe em equipe X X X X Novo na empresa X X X X Disp. de tempo X X Profissional D Profissional E Dominar uso de “X” X X Profissional F X X X X X X X Olhando para a matriz se tem a tendência a eleger o “profissional F” como líder da equipe, pois tem experiência e dispõe de tempo, enquanto o “profissional D” é novo na empresa, e isso pode gerar algum desconforto. Em domínio técnico se vê que os profissionais B e E são capacitados, mas não dispõem de tempo livre (podem estar engajados em outros projetos), e a alternativa será discutir com eles as possibilidades de rearranjo de trabalhos. Uma vez que você compreendeu como estruturar os recursos humanos em projetos, na próxima seção aprenda como realizar a divisão de tarefas. SEÇÃO 6 - Divisão de tarefas Num projeto as atividades são divididas ao máximo, como você acompanhou na composição de Diagramas de Gantt. A divisão das atividades é feita para se ter clareza dos objetivos e para perceber as entregas parciais. Também no Diagrama de Gantt são atribuídas Unidade 3 book.indb 137 137 31/5/2007 14:23:54 Universidade do Sul de Santa Catarina tarefas para os membros da equipe e, assim, cada um enxerga suas metas e seus prazos. Atividades diferentes para pessoas diferentes. A distribuição de responsabilidades será feita de acordo com o modelo adotado pela gerência do projeto. Há gestores que centralizam em excesso as decisões, e outros que delegam. O equilíbrio dependerá bastante do seu perfil, assim como da acomodação dos membros da equipe. Para a gerência do negócio a meta é o resultado global e a satisfação do cliente, enquanto que para o desenvolvedor a meta é a entrega conforme a especificação da sua tarefa. Segundo Page-Jones (1990), as prioridades são para gerentes, não para funcionários. Com isso ele quer afirmar a distribuição de responsabilidades conforme o papel de cada um na equipe. Este é o Modelo de Equipe definido no “ framework” da Microsoft (MSF, 1998) quando define papéis em uma equipe. Assim, para cada um, uma tarefa de cada vez. Para definir os papéis e comunicá-los à equipe é importante criar um organograma, definindo as funções e a hierarquia dos membros. Há inúmeras possibilidades de estruturar tal organograma, e isso dependerá da complexidade do projeto, da empresa onde a equipe de projeto está sendo montada, de como o projeto interfere nas atividades da empresa, etc. Quais são as estruturas típicas de grupos de projetos? Segundo Keeling (2002), há as seguintes estruturas típicas de grupos de projetos: „ estruturas diferenciadas e exclusivas, 138 book.indb 138 31/5/2007 14:23:54 Gerência de Projetos „ estruturas híbridas, „ estruturas matriciais, „ estruturas modulares, „ estruturas horizontais. A seguir, veja em detalhes como se configura cada uma delas, procure entender como elas podem se adequar aos projetos. a) Estruturas exclusivas - Projetos de pequeno porte, que consigam ter seu próprio pessoal e recursos exclusivos e têm pequena complexidade, podem montar estruturas organizacionais simples e funcionais. Esse tipo de estrutura é direta em seus procedimentos e fácil de ser compreendida pelos membros da equipe. Pequenas empresas de engenharia da construção, por exemplo, trabalham desta maneira, onde o gestor do projeto trabalha com um conjunto de técnicos e pessoas de apoio administrativo, e ele reporta diretamente ao cliente final. Figura 3.31 – Estrutura exclusiva. b) Estruturas híbridas - Em projetos internos às empresas maiores, onde vários projetos ocorrem ao mesmo tempo, as estruturas híbridas passam a ocorrer com maior freqüência. Veja a figura 3.32, onde um organograma típico desse modelo de estrutura é apresentado. O gestor do projeto conta com membros dedicados exclusivamente Unidade 3 book.indb 139 139 31/5/2007 14:23:54 Universidade do Sul de Santa Catarina àquele trabalho, mas precisa paralelamente recorrer a outras pessoas, que não estarão dedicadas a esse projeto, mas que são importantes para ele e que simultaneamente se dedicam a outras áreas dentro da empresa. Se o gestor do projeto tiver liberdade de trabalho para recrutar tais pessoas, e dispuser de parte do seu tempo, o projeto terá sucesso. Empecilhos ocorrem quando essa liberdade não lhe é permitida, o que levará o projeto a atrasos e dispersões. Figura 3.32 – Estrutura híbrida. c) Estruturas matriciais - Estruturas matriciais são bem mais complexas e exigem grande maturidade de trabalho, tanto por parte da empresa como por parte dos membros das diversas equipes. A figura 3.33 apresenta esse tipo de estrutura. Veja que diversos projetos ocorrem ao mesmo tempo. Sendo que os membros fazem parte das áreas da empresa, e não exclusivamente dos projetos, ou seja, cada funcionário está inserido em determinado setor da empresa e executa serviços que atendem ora a um projeto, ora a outro. Alguém estará responsável pelo projeto, e será definido como seu gestor, mas mesmo esse gestor pode estar designado para mais de um projeto, ou para partes de um projeto, sendo que esse mesmo gestor faz parte de um determinado setor/departamento 140 book.indb 140 31/5/2007 14:23:54 Gerência de Projetos da empresa. Sem dúvida, a coordenação desse tipo de estrutura é mais complexa, e exige alto grau de organização geral da empresa, especialmente em relação aos planos de produção. Figura 3.33 – Estrutura matricial. d) Estruturas modulares - Estruturas modulares ocorrem quando, dentro da empresa, há grupos com relativa autonomia e determinada especialização, que realizam determinado tipo de serviço. O gestor do projeto emprega esse grupo modular para desenvolver parte do projeto, e vai distribuindo assim as atividades conforme as especializações. Internamente o grupo (ou módulo de desenvolvimento) tem autonomia para gerenciar aquela etapa, sendo que o gestor geral do projeto percebe a entrada e a saída do módulo, mas não propriamente o que acontece em seu interior. Projetos de software, por exemplo, envolvendo grandes equipes com diferentes conhecimentos, podem usar esse tipo de estrutura. Unidade 3 book.indb 141 141 31/5/2007 14:23:55 Universidade do Sul de Santa Catarina Figura 3.34 – Estrutura modular. e) Estruturas horizontais - As estruturas horizontais geralmente são formadas por poucos membros, onde há uma grande maturidade no trabalho em conjunto. As relações se dão em rede, onde todas as pessoas se relacionam com todas as outras. O líder do grupo tem a função de acompanhar o andamento das atividades, e ele mesmo muitas vezes é membro ativo do desenvolvimento do projeto, como por vezes acontece em trabalhos de pesquisa e desenvolvimento reunindo pesquisadores diversos. Projetos que usam esse tipo de estrutura reúnem especialistas, e por esse motivo o líder geralmente é também um especialista técnico ou científico, de tal forma que sua ascendência sobre o grupo seja inequívoca. A figura 3.35 mostra exemplo de configuração de uma estrutura horizontal. O modelo de desenvolvimento de aplicativos da Microsoft (MSF, 1998) também se baseia nesse modelo horizontal, definido por “pequena equipe de pares ou especialistas trabalhando em papéis multidisciplinares e interdependentes”. A questão da multidisciplinaridade, que surge aqui, tem especial interesse em projetos de inovação tecnológica, como no caso dos aplicativos. O ambiente proporcionado por uma estrutura horizontal permite os diálogos constantes e a troca positiva de idéias, nascedouro de soluções criativas. 142 book.indb 142 31/5/2007 14:23:55 Gerência de Projetos Figura 3.35 – Estrutura horizontal de equipe de projeto. Uma vez compreendidas as principais técnicas para planejamento de projetos, na seção seguinte conheça em detalhes o modelo do Project Management Institute (PMI). SEÇÃO 7 - O modelo PMI Recentemente os trabalhos do Project Management Institute (PMI), dos Estados Unidos, têm sido difundidos em todo o mundo e têm chamado especial atenção dos gestores de projeto. Muitos confundem o PMI com um novo método, ou nova técnica, mas esse instituto tem se dedicado a reunir o conhecimento sobre gestão de projetos e difundi-lo na forma de Normas. Ficou famoso o Guia PMBOK (veja as referências bibliográficas ao final deste livro), que é o “Guia do Conjunto de Conhecimentos Unidade 3 book.indb 143 143 31/5/2007 14:23:55 Universidade do Sul de Santa Catarina em Gerenciamento de Projetos” do PMI e atual Norma Nacional Americana ANSI/PMI 99-001-2004. O Project Management Institute (PMI) foi fundado em 1969 e a primeira versão do seu guia foi publicado em 1987 com o título: “O Conjunto de Conhecimentos em Gerenciamento de Projetos”. Em 1996 foi lançada nova versão, já com o título Guia PMBOK®. Esse conjunto de conhecimentos é preparado e revisado através de um processo voluntário de desenvolvimento, sendo que a norma é um consenso de especialistas e interessados nos tópicos do gerenciamento de projetos. O Instituto administra o processo de redação e estabelece regras para promover a imparcialidade dos conceitos a serem publicados. Como resultado, o PMBOK torna-se uma espécie de grande manual da área de gerenciamento de projetos, compilando o conhecimento prático e teórico até o momento atual, servindo de base para gestores e para novos estudiosos. São nove as áreas do conhecimento em gerenciamento de projetos cobertas pela terceira edição, com os seguintes tópicos e subtópicos (ver PMBOK, 3ª. Edição): „ „ Gerenciamento de integração do projeto „ Desenvolver o termo de abertura do projeto „ Desenvolver a declaração do escopo preliminar do projeto „ Desenvolver o plano de gerenciamento do projeto „ Orientar e gerenciar a execução do projeto „ Monitorar e controlar o trabalho do projeto „ Controle integrado de mudanças „ Encerrar o projeto Gerenciamento do escopo do projeto „ Planejamento do escopo 144 book.indb 144 31/5/2007 14:23:56 Gerência de Projetos „ „ „ „ „ Definição do escopo „ Criar EAP (Estrutura Analítica do Projeto) „ Verificação do escopo „ Controle do escopo Gerenciamento de tempo do projeto „ Definição da atividade „ Seqüenciamento de atividades „ Estimativa de recursos da atividade „ Estimativa de duração da atividade „ Desenvolvimento do cronograma „ Controle do cronograma Gerenciamento de custos do projeto „ Estimativa de custos „ Orçamentação „ Controle de custos Gerenciamento da qualidade do projeto „ Planejamento da qualidade „ Realizar a garantia da qualidade „ Realizar o controle da qualidade Gerenciamento de recursos humanos do projeto „ Planejamento de recursos humanos „ Contratar ou mobilizar a equipe do projeto „ Desenvolver a equipe do projeto „ Gerenciar a equipe do projeto Unidade 3 book.indb 145 145 31/5/2007 14:23:56 Universidade do Sul de Santa Catarina „ „ „ Gerenciamento das comunicações do projeto „ Planejamento das comunicações „ Distribuição das informações „ Relatório de desempenho „ Gerenciar as partes interessadas Gerenciamento de riscos do projeto „ Planejamento do gerenciamento de riscos „ Identificação de riscos „ Análise qualitativa de riscos „ Análise quantitativa de riscos „ Planejamento de respostas a riscos „ Monitoramento e controle de riscos Gerenciamento de aquisições do projeto „ Planejar compras e aquisições „ Planejar contratações „ Solicitar respostas de fornecedores „ Selecionar fornecedores „ Administração de contrato „ Encerramento do contrato”. Você reparou que os principais tópicos descritos acima estão presentes neste livro, e também que foram descritos algumas das novas tendências em gestão e análises teóricas realizadas em publicações do IEEE (Institute of Electrical and Electronic Engineers). Para conhecer mais sobre este método, veja ainda nas Unidades deste livro as seções “saiba mais” e as referências bibliográficas no final. Antes, para exercitar os novos conhecimento, realiza as atividades propostas a seguir e no EVA. 146 book.indb 146 31/5/2007 14:23:56 Gerência de Projetos Atividades de auto-avaliação Leia com atenção os enunciados e realize as atividades. 1) Considere o seguinte problema: será implantado um novo sistema de qualidade na EMPRESA, e uma equipe interna foi designada para montar o projeto de implantação, o qual não deve superar dois meses, e que deve ser primeiro implantado no setor administrativo e somente depois no setor de produção da empresa. O projeto tem as seguintes atividades: reuniões do grupo do projeto para definir o programa; redação do programa de qualidade; treinamento do pessoal do setor administrativo; treinamento do pessoal do setor de produção; implantação do programa de qualidade no setor Administrativo; implantação do programa no setor de produção; avaliação dos resultados e conclusão, com entrega dos relatórios à direção. Faça sua análise e, com base nela, preencha o quadro a seguir: Prazos estimados pela equipe de implantação Projeto Qualidade ABCDEFG- Unidade 3 book.indb 147 147 31/5/2007 14:23:56 Universidade do Sul de Santa Catarina 2) Prepare o Gráfico de Gantt para a planilha de atividades do exercício anterior – Projeto QUALIDADE, e considere ainda que os treinamentos podem ser feitos em seqüência, independente do início do trabalho de implantação no setor de produção. Projeto QUALIDADE 3) Quais são as quatro fases de estruturação da equipe, e em sua opinião qual a mais problemática? Por que a fase escolhida é a mais problemática? 4) Como uma matriz de perfis e competência pode ajudar na estruturação de uma equipe? 148 book.indb 148 31/5/2007 14:23:57 Gerência de Projetos 5) Em sua opinião, qual tipo de estrutura de equipe melhor se ajusta ao desenvolvimento de software em uma pequena empresa, cujos projetos são iniciados apenas sob a demanda do cliente? 6) Qual o modelo de estrutura representado na figura abaixo? Qual o seu grande problema? Unidade 3 book.indb 149 149 31/5/2007 14:23:58 Universidade do Sul de Santa Catarina 7) Em que tipo de estrutura é possível uma grande troca de conhecimentos, sendo que as pessoas trabalham entre pares? Qual a vantagem desse tipo de estrutura na Gestão de TI e na indústria de softwares? 150 book.indb 150 31/5/2007 14:23:58 Gerência de Projetos Síntese Nesta unidade você estudou modelos e métodos importantes para o gerente de projetos, em especial o gráfico que apresenta as diversas atividades em forma de barras ao longo do tempo, desenvolvido por Gantt. A popularidade desse tipo de Gráfico Gantt deve-se à força de sua clareza visual.Recentemente a implantação de setas de precedência interligando as barras aumentou ainda mais a sua qualidade como modelo. Apesar da imensa utilidade do Gráfico de Gantt, outro método foi desenvolvido para facilitar o planejamento do tempo de duração do projeto – trata-se do método do caminho crítico, denominado genericamente de PERT/CPM. Com tais ferramentas de planejamento e análise pode-se chegar a estimativas bastante realistas quanto aos recursos necessários ao projeto, e quais seus custos. O modelo PMI é uma abordagem que apresenta uma visão geral dos aspectos de projeto, considerando a visão particular desse Instituto americano. Também estudou a questão da formação das equipes de projeto a partir do planejamento em gráficos. Você viu que os perfis são muito variados, e também são dinâmicos, ou seja, as pessoas têm comportamentos diferentes, conforme o meio em que estão. Para dividir as tarefas e encontrar os perfis corretamente, uma técnica interessante é preparar uma matriz de competências. Para organizar o grupo de trabalho em difentes tarefas, foram estudados cinco modelos estruturais, que dependerão de cada tipo de projeto a ser trabalhado. Na próxima unidade você estudará como se dá o dia-a-dia do projeto durante sua execução, seus problemas de rotina e os aspectos importantes da liderança no sucesso da empreitada. Até lá! Unidade 3 book.indb 151 151 31/5/2007 14:23:58 Universidade do Sul de Santa Catarina Saiba mais Para aprofundar os temas abordados na unidade sugere-se: 1. Nesta unidade, você estudou modelos de representação como forma de entender um projeto, a partir de uma visão geral. Para o desenvolvimento de software surgiu uma tecnologia que busca criar modelos de representação, por meio de diagramas, que muito se assemelham aos diagramas genéricos que usamos aqui. Essa tecnologia é chamada “UML – Unified Modelling Language”, e está baseada na modelagem de diversos tipos de diagramas, os quais abrangem diferentes visões de um projeto de software, seja ele simples como o “Hello World / Alô Mundo”, que se vê em Java, seja de sistemas das mais variadas complexidades. A UML é desenvolvida atualmente por uma organização internacional sem fins lucrativos, e toda sua documentação pode ser encontrada em www.uml.org. Vários softwares para desenvolvimento UML estão disponíveis hoje para download gratuito, como por exemplo, o POSEIDON (veja em http://www.gentleware.com/index.php ). Veja também o sítio http://www.cragsystems.co.uk/ITMUML/index.htm para estudar uma introdução a UML. 2. Veja em www.gestiopolis.com/recursos/documentos/fulldocs/ ger/pertcpm.htm um artigo bastante completo e com exemplos variados do uso de PERT/CPM, em espanhol. Casos práticos e exercícios, bem como exemplos de tabelas e relatórios. 3. As idéias da Microsoft para gestão de projetos de software estão disponíveis no endereço http://www.microsoft.com/ technet/itsolutions/msf/default.mspx. Análises de risco, estimativas, grupos de trabalhos e diversos outros conceitos são discutidos no que eles chamaram “Microsoft Solutions Framework – MSF”. 4. Veja em www.teses.usp.br a dissertação de mestrado de Leandro Patah, “Alinhamento estratégico de estrutura organizacional de projetos: uma análise de múltiplos casos”. Este trabalho foca em diversos tipos de estrutura, especialmente a matricial, e trará conhecimentos aprofundados sobre o tema. 152 book.indb 152 31/5/2007 14:23:58 Gerência de Projetos 5. Entre novamente no sítio da SOFTEX (www.softex.br) e veja os estudos sobre terceirização de mão-de-obra, bem como o estudo comparativo entre as indústrias de software no Brasil, China e Índia. Há exemplos de como a terceirização alavancou a indústria indiana, por exemplo. Ao mesmo tempo, isso tem trazido impacto sobre a “formação de equipes de TI” nos Estados Unidos. Unidade 3 book.indb 153 153 31/5/2007 14:23:59 book.indb 154 31/5/2007 14:23:59 UNIDADE 4 A execução do projeto Objetivos de aprendizagem Ao final desta unidade você terá subsídios para: „ Compreender que a preparação correta no início de um projeto permite a gerência e o controle eficaz da qualidade. „ Perceber que líderes e gestores podem ser tipos bem diferentes. „ Estudar técnicas e práticas para controle de prazos e recursos, para encontros de trabalho, e para gestão de conflitos. „ Verificar que um projeto de sucesso exige etapas de simulação, testes e validação dos resultados intermediários, onde são buscados incrementos de melhoria. 4 Seções de estudo A seguir, apresentam-se as seções para você estudar. Seção 1 Seção 2 Seção 3 Seção 4 Seção 5 Seção 6 Seção 7 Seção 8 Seção 9 Preparação e início dos trabalhos Liderança versus gestão Tomada de decisões Motivação e comunicação Reuniões Acompanhamento e controle Gerenciando tempo, recursos e qualidade Gestão de conflitos Simulação, testes e validação Após a leitura dos conteúdos, realize as atividades propostas no final da unidade e no EVA. book.indb 155 31/5/2007 14:23:59 Universidade do Sul de Santa Catarina Para início de estudo Esta unidade apresenta questões práticas como a partida do projeto, os possíveis conflitos advindos do choque entre pessoas da equipe com variados perfis, bem como as características do gestor do projeto para tratar tais conflitos e dificuldades. Em especial, é debatido o perfil do gestor quando comparado com o do líder, assunto que é muito abordado em debates sobre desenvolvimento tecnológico e inovação. Tais diferenças de perfis podem afetar positiva ou negativamente o desenvolvimento do projeto e, até mesmo dificultar a administração de conflitos, por exemplo. Também será tema de estudo, nesta unidade, as simulações e os testes de revisão contínua, facilitando a busca, durante a fase de desenvolvimento do projeto, de conquistas parciais. Tais conquistas parciais é que garantem o resultado esperado do projeto conforme você verá. Então, está preparado? Siga em frente e bom estudo! SEÇÃO 1 - Preparação e início dos trabalhos A produção em projetos é uma decorrência do planejamento, pois como você já viu nas demais unidades, o projeto é um trabalho com data marcada para acabar, enquanto as atividades de produção de rotina não têm tal finalidade, e as pessoas entram no trabalho de uma empresa ou indústria, por exemplo, quando as coisas já estão acontecendo. Outro fator importante e por isso aparentemente tanta preparação, é que num projeto é preciso sempre ter a visão do conjunto e não apenas das partes. Tendo o planejamento 156 book.indb 156 31/5/2007 14:23:59 Gerência de Projetos realizado, os recursos disponíveis, os objetivos claros e o contrato estabelecido junto ao cliente, é que se pode iniciar os trabalhos. O que fazer para começar o projeto? Para preparar e começar o projeto é importante você considerar que: „ muitas pessoas imaginam que trabalhar em um projeto é imediatamente começar a programar, ou perfurar, ou martelar, ou seja, alguma atividade que demande muito esforço. A energia é despendida logo no começo e, por não se saber onde chegar, logo tudo esvanece e o projeto perde o sentido. Trabalhar num projeto não é desprender um enorme esforço em direção a um objetivo desconhecido, para parecer que o suor faz o trabalho, pois projeto exige reflexão. „ Outros pensam que alguém deve dar as ordens e será este alguém que terá todo o projeto “na cabeça”, basta seguir seus passos. Provavelmente há um responsável e líder num projeto (no entanto este responsável certamente não tem o projeto todo na cabeça). Não existe um “ser sagrado” que sabe tudo sobre o trabalho a ser realizado, já que o responsável depende inteiramente da sua equipe. „ Como o projeto é uma atividade inerentemente coletiva, é preciso que haja o espírito do trabalho cooperativo. Não há como fazer projetos com algum nível de complexidade sem a participação criativa e positiva de várias pessoas. Unidade 4 book.indb 157 157 31/5/2007 14:23:59 Universidade do Sul de Santa Catarina Um exemplo de ação neste sentido foi divulgada recentemente, quando um grupo de projetistas inventou uma espécie de jogo em rede de computadores, uma espécie de gincana, em que eles brincavam de colocar partes do projeto num diretório comum e a vitória era cumprir tal demanda num prazo cada vez mais curto – tratava-se de uma brincadeira que fazia do projeto uma diversão em forma de game! O início de um projeto deve se dar com uma reunião! Nesta reunião, o escopo do projeto deve ser exposto com a maior clareza possível, discutido em detalhes, o plano de produção deve ser delineado, as tarefas divididas e as responsabilidades atribuídas. É neste momento que o fluxograma geral (você lembra do algoritmo do projeto?) deve ser apresentado, discutido e suas cópias distribuídas. A comunicação dos procedimentos, já discutidos, deve ser feita a partir desse contato inicial. Mas reuniões são muito mal vistas. Você sabe por quê? As pessoas pensam que reuniões são chatas, que não dizem nada, que o chefe senta na extremidade da mesa para mandar. No entanto, 158 book.indb 158 31/5/2007 14:23:59 Gerência de Projetos as reuniões podem ser interessantes, se: „ tiverem uma pauta bem definida; „ a pauta não for extensa; „ os assuntos são claros e de conhecimento dos presentes; „ o horário de começar e acabar for bem definido; „ forem suficientemente breves; „ houver um coordenador, capaz de distribuir a fala entre os diversos presentes; „ houver um líder, capaz de decidir quando for necessária uma decisão. Há empresas que fazem tantas reuniões que as pessoas acham que trabalhar é participar de reuniões, enquanto que outras pessoas acham que a pior coisa do mundo é uma reunião. Nem uma nem outra está correta. Provavelmente é a reunião que está mal conduzida. Passada a fase das reuniões iniciais, o projeto tem início. Os grupos de trabalho estão com suas atividades definidas, prazos estabelecidos e resultados por alcançar. Resta então cumprir tais etapas, já estabelecidas no Gráfico de Gantt do projeto. Se o planejamento foi bem feito, há uma divisão bem clara de objetivos e atividades e possivelmente com sub-etapas de prazos curtos. E assim que começam os trabalhos de desenvolvimento, a mentalidade de “uma entrega a cada dia” é estabelecida entre todos os membros da equipe. Com isto, há a sensação comum de que os projetos devem “andar” e que devem estar no prazo. Unidade 4 book.indb 159 Orientação a “zero-defeito” e prazos curtos de entregas intermediárias – a Microsoft estabeleceu este conceito como um objetivo de desenvolvimento (MSF, 1998). 159 31/5/2007 14:23:59 Universidade do Sul de Santa Catarina Na Microsoft, o gerente de projeto Chris Peters considera que a atividade de um projetista não é simplesmente colaborar no projeto para que esse chegue ao resultado final. Ele considera que cada projetista, ao começar seu trabalho, deve estar pensando em “entregar”. Sobre isso, analise o parágrafo seguinte: Todos [os projetistas]… têm o mesmo trabalho. Eles têm exatamente a mesma descrição de trabalho. E esta é entregar (embarcar) produtos. Seu trabalho não é escrever código. Seu trabalho não é testar. Seu trabalho não é escrever especificações. Seu trabalho é entregar produtos. Isto é o que um grupo de desenvolvimento faz. Seu papel como um desenvolvedor ou como um testador é secundário. Não estamos dizendo que não são importantes – mas são secundários para seu trabalho real, o qual é entregar um produto. Quando você acorda cedo de manhã e vem para seu trabalho, você diz, “Qual é o foco – estamos tentando entregar ou estamos tentando escrever código?” A resposta é: nós estamos tentando entregar. Você não está tentando escrever código. (MSF, 1998). Observe que esta citação esclarece a atitude do projetista ao participar de um grupo de trabalho. E com este foco, o trabalho deve ser iniciado. 160 book.indb 160 31/5/2007 14:23:59 Gerência de Projetos SEÇÃO 2 - Liderança versus gestão Nossa sociedade está muito mais acostumada a trabalhar com gestores ou gerentes, do que com líderes. A função da gerência tem sido muitas vezes confundida com uma espécie de atuação por cobrança e controle, que coloca os gerentes numa condição de animosidade com seu grupo de gerenciados. Ou seja, aqueles que ficam submetidos ao gerente se sentem diminuídos e perdem a motivação do trabalho criativo. Muitas vezes isso, de fato, acontece. Conheço vários gerentes que se sentem muito satisfeitos em... mandar. Mas aqui surge uma dúvida: Quais são as qualidades esperadas de um gerente de projetos? No entendimento de Page-Jones (1990), as qualidades de um gerente de projetos são as seguintes: „ integridade pessoal; „ sensibilidade; „ capacidade de estabelecer objetivos; „ capacidade de cumprir objetivos; „ tenacidade; „ capacidade de inspirar; „ disposição de servir; „ coragem de delegar; „ competência técnica; Unidade 4 book.indb 161 161 31/5/2007 14:24:00 Universidade do Sul de Santa Catarina „ capacidade para comunicar a realidade; „ capacidade de pensar e ser inovador; „ coragem para tomar decisões. Tais características cabem perfeitamente para os líderes, especialmente as qualidades de “inspirar, ser inovador e ter coragem de tomar decisões”. Nem sempre os gerentes são inspiradores, inovadores e decisores e, mesmo assim, são ótimos gerentes, pois são capazes de coordenar os prazos e distribuir tarefas adequadamente, assim como os membros da equipe confiam nele para conduzir o trabalho até o final. Quais são os atributos desejáveis em um gerente de projeto? Em seu livro sobre gerenciamento de projetos, Valeriano (1998) cita Denis Donaire, que considera que os atributos desejáveis em um gerente estão divididos em três grandes áreas: conhecimentos, habilidades e atitudes. Acompanhe a seguir o quadro apresentando cada área. 162 book.indb 162 31/5/2007 14:24:00 Gerência de Projetos Quadro 4.1 – Atributos desejáveis para um gerente de projeto Atributos desejáveis • o gestor precisa ter conhecimento do sistema administrativo e financeiro da organização onde trabalha; • precisa conhecer o funcionamento do sistema de RH – recursos humanos, e como se dão as relações jurídicas com relação aos funcionários e terceirizados da empresa; Conhecimento organizacional • práticas, políticas e valores, isto é, percepção clara de como funciona a organização em suas práticas no dia-a-dia, a política interna das relações e quais os valores considerados por aqueles que trabalham nela; Conhecimentos • consciência do custo e das implicações das decisões técnicas, o que implica em reconhecer as relações entre as ações e o que isso implica em gastos no projeto e para a empresa; • produtos, missões e mercados ou clientes da organização, que significam um conhecimento profundo das atividades econômicas da organização. • o gestor precisa conhecer áreas correlatas à especialização de que trata o projeto, com uma visão geral das competências tecnológicas; Conhecimento técnico • também precisa ter competência técnica em pelo menos uma área de especialização; • por fim, deve ter domínio de métodos de pesquisa, que permitam relacionar os diversos membros da equipe em um desenvolvimento equilibrado e voltado para resultados. Unidade 4 book.indb 163 163 31/5/2007 14:24:00 Universidade do Sul de Santa Catarina • o gestor deve ter a capacidade, e isso deve ser perceptível, de planejamento, organização e controle das atividades do projeto; • para comandar sua equipe é desejável que desenvolva sua capacidade de liderança; • capacidade de auto-análise, ou seja, constantemente fazer auto-crítica das suas atitudes, dos seus conhecimentos e das necessidades de aprimoramento técnico; De comando • capacidade de alocação de recursos, que advém do conhecimento dos recursos disponíveis e daqueles que serão necessários buscar no desenvolvimento do projeto; • capacidade de gerar confiança no superior; isto se dá pela integridade e pela segurança ao trabalhar orientado a resultados; Habilidades • escolha do estilo de liderança adequado; • habilidade de tomada de decisões, condição essencial numa função de comando (o gerente que não toma decisões é considerado fraco por sua equipe, o que desmotiva o grupo). • trabalhar em equipe, que está relacionada à capacidade de cooperar e gerenciar conflitos; • criatividade, especialmente na solução de problemas inesperados e distantes daqueles que foram avaliados como riscos inerentes ao projeto; Outras habilidades • capacidade de redigir com clareza, precisão e concisão, que são habilidades relacionadas à capacidade de se comunicar, nev vcessária para o andamento do projeto de forma coordenada e racional; • relacionamento pessoal, habilidade relacionada ao dia-a-dia do trabalho em equipe, às atitudes de educação na convivência (infelizmente não é nada irreal o “gerente” que se dirige aos membros de sua equipe aos berros). • interesse por questões administrativas; Posicionamento em relação a aspectos internos e externos • disciplina de trabalho; • entrosamento com pessoal externo à organização; Atitudes • ambição profissional. Estratégia de ação • hábito de começar o ataque ao problema pela revisão da literatura, pela revisão dos projetos da mesma área que o antecederam, seja na empresa ou outros locais e, principalmente, a capacidade de exercitar sempre uma visão geral do problema e do ambiente de negócios onde o projeto está envolvido; • hábito de leitura sistemática de textos técnicos. 164 book.indb 164 31/5/2007 14:24:00 Gerência de Projetos Stephen Covey (2005) criou uma ilustração que relaciona diferenças entre liderança e gerência. No quadro a seguir, apresento uma adaptação de tal tabela de acordo com os conceitos desenvolvidos neste livro: Quadro 4.2 - Diferenças entre liderança e gerência Diferenças Liderança Gerência Interesse nas pessoas nas coisas Trabalha na espontaneidade com a estrutura Idéias liberação e fortalecimento controle delas e das atividades Presteza eficácia eficiência Prefere planejar e programar trabalhar sob um programa Gasto considera como investimento considera como despesa Trabalho baseado em princípios em técnicas Procura transformação transação Poder centrado em princípios utilidade Procura resolver por discernimento medição Fazer a coisa certa certas as coisas Resolve baseado numa direção em rapidez Pensa em uma linha superior resultados Tem propósitos métodos Decide baseado em princípios em práticas Ponto de vista Para o líder a pergunta é: “a escada está junto da parede certa?” Para o gestor o que importa é: subir rapidamente a escada Fonte: Adaptado de Covey (2005). Bem, não é necessário fazer um juízo de valor sobre qual o melhor líder ou gestor, pois os papéis dependerão da atividade, do tamanho do problema ou do tipo do projeto. De certa forma, os dois papéis devem estar combinados. Uma vez dado início ao projeto, tendo um planejamento claro das atividades e consideradas as funções de liderança e de gestão, passa-se agora aos detalhes do dia-a-dia do projeto. E um dos pontos fundamentais de qualquer projeto é a tomada de decisão, assunto de estudo na próxima seção. Unidade 4 book.indb 165 165 31/5/2007 14:24:00 Universidade do Sul de Santa Catarina Seção 3 - Tomada de decisões Hoje, uma grande parte dos textos sobre administração empresarial focaliza o problema da tomada de decisão. Decidir significa escolher uma opção entre várias e, com isto, há sempre o risco da escolha não recair sobre a melhor opção. Um campeão de xadrez decide o melhor movimento a cada vez e seu exercício de escolha é renovado a cada nova jogada. Aquele que tomar decisões erradas perderá o jogo. Assim também o goleiro na hora do pênalti: a decisão do seu movimento poderá implicar ou não na defesa do gol. Sabese que os grandes craques de qualquer esporte, especialmente os coletivos, aliam as habilidades pessoais e de relacionamento à capacidade de antever os movimentos do jogo e tomar a decisão que levará ao gol, ao ponto, ao sucesso, enfim. Que milagre poderia ser este, capaz de levar a uma decisão certa no momento certo? Alguns traços são comuns entre esses “tomadores de decisão”: „ experiência anterior; „ treino em decidir e executar (as jogadas, os chutes); „ o exercício da visão ampla (do jogo); „ coragem de, após um erro, calibrar os movimentos para tentar de novo até acertar. Você já deve ter assistido em algum desses momentos mágicos no esporte, quando o atleta resolve arriscar um difícil movimento, muitas vezes num momento crítico onde a chance da derrota 166 book.indb 166 31/5/2007 14:24:00 Gerência de Projetos é enorme e, cheio de confiança, decidir uma partida. Um jogo coletivo é como um projeto: há um objetivo a ser atingido, o prazo está estabelecido e só é possível vencer se a equipe estiver unida e entusiasmada. Para Page-Jones (1990), a tomada de decisão durante um projeto envolve quatro passos: 1. identificar possíveis modos de ação e chegar a um entendimento comum do que cada opção significa; 2. identificar as ramificações de cada opção, incluindo vantagens e desvantagens; 3. discutir e avaliar cada uma dessas ramificações; 4. escolher o modo de ação mais vantajoso e partir para ele. Como você pôde acompanhar, num projeto há a necessidade da constante avaliação das opções possíveis e disponíveis que, combinada à experiência prévia do decisor, definirá as próximas ações. Seção 4 - Reuniões Como você já estudou nesta unidade, as reuniões de projeto são muito importantes, pois são momentos especiais de comunicação e decisão. Durante o encaminhamento do projeto, os planos, as discussões e os rumos do trabalho são colocados e precisam ser encarados como ambientes coletivos para o desenvolvimento do próprio projeto. Como fazer para que a reunião seja bem sucedida? Para que uma reunião venha a ser bem sucedida, Page-Jones (1990) coloca as seguintes sugestões de ação: Unidade 4 book.indb 167 167 31/5/2007 14:24:01 Universidade do Sul de Santa Catarina 1) Antes da reunião • o grupo de trabalho ou o gestor/líder deve definir um lugar conveniente para a reunião; • os participantes devem ser selecionados conforme o assunto em pauta e não, simplesmente, reunir todos do grupo; • antes de marcar uma agenda, é importante verificar se todos podem, de fato, participar; • se há consenso sobre uma data e horário, fazer então o aviso com antecedência; • a pauta de reunião deve ser bem definida e levada aos participantes com antecedência; • o número de itens em pauta deve ser restrito, evitando dispersão e superficialidade. 2) Durante a reunião • deve ser designado um moderador, capaz de controlar as falas e questões; • também deve ser designado um secretário, que anote os pontos principais discutidos, bem como as resoluções adotadas, criando então uma ata; • o grupo deve prender-se à pauta, evitando entrar em assuntos diversos; • definir regras de procedimento, conforme o objetivo dos itens de pauta (planejamento, comunicação, resolução de problemas, decisão). 3) Depois da reunião • todos os itens de ação devem ser anotados e devem ser atribuídas responsabilidades por cada item de ação; • distribuir a ata da reunião. Tenho certeza que você, ao ler estas linhas, pensou em reuniões em que já tomou parte e que não seguiram tais recomendações. Aquelas que tiveram alguém capaz de conduzir as conversas, talvez tenham tido bons resultados, porém a maioria deve ter sido enfadonha e sem resultados, sem contar a sensação do tempo perdido. Se a reunião não tiver pauta, peça uma. Se não tiver definida a hora de acabar, pergunte qual é. Para o projeto de desenvolvimento de uma inovação tecnológica, um software, um novo produto, haverá com certeza várias reuniões e caberá a cada um de nós interferir no seu bom andamento. 168 book.indb 168 31/5/2007 14:24:01 Gerência de Projetos Seção 5 - Gerenciando qualidade Gerenciar a qualidade é buscar a ausência de erros. Muitas vezes não se presta atenção aos erros e se cria metas de qualidade que podem ser bem baixas para nossa vida social, apesar de parecerem excelentes para a vida profissional. Para contextualizar esta questão do erro, acompanhe a seguir um texto de Philip Crosby, citado por Tom DeMarco (1991): “As pessoas foram condicionadas a acreditar que o erro é inevitável. Não apenas aceitamos o erro, nós o prevemos. Quando projetamos circuitos, programamos um computador, fazemos um planejamento, soldamos conexões, datilografamos uma carta, fazemos um orçamento, ou montamos componentes, não nos preocupamos se cometemos alguns erros; e a gerência prevê o acontecimento desses erros. Achamos que os seres humanos possuem um fator de erro integrado a eles. Entretanto, não mantemos o mesmo padrão, quando a coisa passa para o campo da vida pessoal. Se mantivéssemos, aceitaríamos com naturalidade receber troco errado (a menos); aceitaríamos que as enfermeiras deixassem cair no chão um percentual de recém-nascidos; acharíamos natural entrar na casa errada de vez em quando. Como indivíduos, não toleramos esses erros. Portanto temos dois pesos e duas medidas: um para nós e um para a empresa. A razão para isso é que a família cria para nós padrões de desempenho bem mais altos do que as empresas. Muitas empresas gastam 10, 15 ou até mesmo 20% do faturamento de suas vendas com sucata, re-trabalho, garantias, consertos, testes e inspeções. Os erros que produzem esse desperdício são causados diretamente pelo pessoal da empresa, tanto pelos funcionários como pela administração. Para eliminar esse desperdício, para melhorar o funcionamento e aumentar a eficácia, precisamos nos concentrar na prevenção dos defeitos e dos erros que nos assolam. O erro que é prevenido não precisa de consertos, exames ou explicações. Unidade 4 book.indb 169 169 31/5/2007 14:24:01 Universidade do Sul de Santa Catarina O primeiro passo é adotar uma atitude de prevenção de defeitos. Essa atitude é chamada, simbolicamente, de Defeito-Zero.” Como você pode refletir, o controle da qualidade passa antes por um conceito do que é o defeito e até onde estamos dispostos a aceitá-lo. Quais são os momentos críticos do gerenciamento da qualidade? Conforme o artigo “Managing project quality” (Kloppeborg & Petrick, 2004), o gerenciamento da qualidade em projetos passa por dois momentos críticos: a abertura do trabalho e seu encerramento. Os pontos fundamentais a serem tratados nesses dois momentos são: 1) Fase inicial do projeto „ identificação dos objetivos do projeto; „ alinhamento estratégico com a empresa e com o objetivo do cliente; „ alinhamento operacional com a capacidade de produção da estrutura disponível; „ seleção dos recursos necessários; „ contrato detalhado do projeto descrevendo: „ o porquê do projeto; „ o quê; „ quando; „ quanto custa; „ quais os riscos; „ como fazer; 170 book.indb 170 31/5/2007 14:24:01 Gerência de Projetos „ os fatores críticos do sucesso, o plano de comunicação, os conhecimentos necessários e os compromissos. 2) Fase de encerramento „ definição e comunicação do benefícios reais entregues para o cliente; „ expressão de reconhecimento aos participantes; „ entregar prêmios quando há méritos especiais (evitando aquele tipo de mediocrização que evita prêmios para não “magoar” os mais fracos). De posse de um Diagrama de Gantt com acompanhamento constante das etapas realizadas, sabemos dos custos envolvidos e do tempo gasto a cada momento. Fazendo a revisão de cada etapa é possível replanejar o projeto e avaliar as condições do tempo restante e recursos disponíveis e ainda necessários. Seção 6 - Gestão de conflitos Como não podia deixar de ser, o trabalho em equipe é, quase sempre, um ambiente de conflitos. Isso acontece devido ao dinamismo dos pensamentos e sentimentos humanos, em constante movimento e readequação. Quais são os tipos de conflitos? Segundo Valeriano (1998), existem três tipos de conflitos: „ o de ordem intrapessoal, que ocorre em cada indivíduo, consigo mesmo; „ interpessoal, que ocorre entre diferentes indivíduos; Unidade 4 book.indb 171 171 31/5/2007 14:24:01 Universidade do Sul de Santa Catarina „ intergrupos, que se dá entre diferentes grupos. Esses conflitos estão presentes em todos os ambientes sociais, sejam de trabalho, familiar ou de comunidades em geral e, obviamente, estão presentes nas equipes de projeto, as quais muitas vezes estão reunidas por um pequeno período de tempo e de forma muito intensa, a potencializar estas relações. Esses três tipos de conflito, intrapessoal, interpessoal e intergrupos então presentes no decorrer dos projetos segundo as seguintes causas potenciais (KEELING, 2002): „ na definição de cronogramas; „ na definição das prioridades; „ na composição dos recursos humanos para trabalhar no projeto; „ opiniões técnicas e de desempenho; „ procedimentos administrativos; „ custos; „ conflitos de personalidade. No quadro 4.3 a seguir, você poderá observar quais são os conflitos em projetos como os oriundos de diferenças entre os indivíduos e as organizações devido aos seus diferentes objetivos. Quadro 4.3 - Fontes de conflitos Diferenças de objetivos como fonte de conflitos Indivíduo / profissional Organização / gerência Busca a inovação tecnológica. Busca o lucro. Quer autonomia de ação. Quer integrar os profissionais na organização. Quer livrar-se de regras e procedimentos. Estabelece as regras e procedimentos. Quer autoridade baseada em mérito. Autoridade baseada em hierarquia. Quer ser recompensado com base em seu desempenho. Recompensa conforme o interesse da organização. Quer ampla comunicação entre pares. Bloqueia a comunicação interna. Busca otimização do próprio trabalho. Busca cumprimento de cronogramas e custos. Fonte: Adaptada de Valeriano (1998). 172 book.indb 172 31/5/2007 14:24:02 Gerência de Projetos Você percebeu como são interesses e objetivos diferentes: indivíduo e organização! Observe que as pessoas têm diversas necessidades e intenções, que muitas vezes não combinam ou se ajustam às das organizações, mesmo que tais organizações, paradoxalmente, tenham sido construídas por indivíduos. Num projeto, isto pode ser a fonte de um grande fracasso e o gestor do projeto deverá saber criar suficiente blindagem entre os objetivos mais gerais da organização e os específicos do projeto, que devem refletir os indivíduos que o compõem. Há organizações que trabalham orientadas para projetos, porém com a mentalidade de organização tradicional. Não será possível vencer a contradição, se não houver um repensar de seus princípios. Organizações envelhecidas, nascidas ainda com a mentalidade dos princípios da revolução industrial, por exemplo, buscam renovação adotando práticas de reengenharia e gestão por projetos e fracassam logo em seguida sem saber o porquê. A orientação a projetos é uma orientação às pessoas, eis a resposta. No entanto, não estaremos livres de conflitos em um projeto, então será necessário administrá-los. Como realizar a administração dos conflitos? Para Valeriano (1998), há as seguintes possibilidades de se administrar conflitos num projeto, por: „ Confronto ou solução de problemas, quando as partes envolvidas encaram o problema e buscam juntas alternativas de solução; Unidade 4 book.indb 173 173 31/5/2007 14:24:02 Universidade do Sul de Santa Catarina „ Comprometimento, que é a busca de soluções alternativas, por parte do gerente do projeto, dando algum grau de satisfação às partes envolvidas; „ Acomodação, são enfatizadas as áreas onde há acordo e esquecidas ou desprezadas as áreas conflitantes; haverá perda para o projeto se as áreas de atrito eram, de alguma forma, importantes para seu prosseguimento; „ Prevalência, que é quando uma das partes prevalece sobre a outra, numa relação ganha-perde; „ Retirada, quando o conflito é deixado de lado, sem solução, o que pode trazer o aprofundamento da crise; muitas vezes a retirada é usada como modo de administrar a crise, considerando a retomada do problema algum tempo depois, quando houve tempo para melhor reflexão. Considerando tais possibilidades, será função do gestor escolher a maneira de tratar o conflito. Com certeza, a melhor forma de administrar os conflitos se dá quando são percebidos o mais cedo possível. Como muitas doenças, se o conflito for detectado no início, é mais fácil de curar e, se muito tarde, pode ser impossível. Uma vez compreendido como administrar os conflitos durante a gestão dos projetos, na próxima seção acompanhe como realizar o teste e a validação do projeto. Seção 7 - Simulação, testes e validação Projetos podem ter resultados melhores se forem testados em etapas, com resultados parciais e não aguardar até o final para ver o que deu certo e o que deu errado. Neste sentido, é importante, para cada etapa e subdivisão do projeto, buscar conseguir um resultado palpável. 174 book.indb 174 31/5/2007 14:24:02 Gerência de Projetos No caso da construção civil, por exemplo, a finalização da etapa das fundações tem como resultado as próprias fundações, que podem ser testadas quanto às características necessárias de resistência e dimensões. Qualquer problema aí detectado pode ser resolvido imediatamente, não sendo necessário aguardar até o final da obra para perceber que os alicerces não suportaram o peso da construção – seria um desastre! Em projetos de software há a possibilidade de dividir o sistema em pequenos módulos, de tal forma que cada módulo tenha características específicas, definidas inicialmente e atingi-las é o objetivo a ser alcançado no final da etapa. Quanto maior a divisão de etapas e, desta forma, de objetivos intermediários, mais fácil será detectar possíveis problemas e corrigi-los a tempo. Um exemplo de divisão em etapas desse tipo está definido nos “pacotes diários” e nos “protótipos de prova” do Microsoft Solutions Framework (MSF, 1998). O objetivo é chegar ao final de cada dia com um protótipo sendo que este deva estar testável. Esse protótipo é compilado e deve funcionar. Passa-se para a etapa seguinte se o pacote diário anterior alcançou o sucesso. Uma outra alternativa, é o uso de simuladores em projetos mais complexos. Nesses casos, uma boa forma de testes prévios é o uso de simulações computacionais, que permitem uma visão do produto, possibilitando fazer testes variados em um ambiente computacional. Um ótimo exemplo dessa situação são os softwares de apoio a projeto (CAD), que em mecânica e arquitetura permitem visualizar e testar peças, máquinas e ambientes. A detecção de falhas durante a simulação permite enormes economias de tempo e dinheiro. Unidade 4 book.indb 175 175 31/5/2007 14:24:02 Universidade do Sul de Santa Catarina A validação do projeto é feita então por etapas e por simulações, sendo que no final de cada etapa e mesmo durante cada uma delas, um processo de revisão contínua é a melhor solução de qualidade de um projeto de sucesso. Segundo Page-Jones (1990), há várias revisões a serem feitas no decorrer do projeto, com testes contínuos e validação a cada etapa. Quais são as revisões e testes que necessitam ser realizados? Especificamente sobre projetos, as revisões e testes, deve-se realizar as seguintes ações: „ revisão do escopo do projeto, que analisa constantemente se o projeto está adequado às intenções e necessidades dos usuários/ clientes; „ revisão de análise, que verifica se os problemas anunciados no escopo estão sendo cuidados; „ revisão do projeto, que verifica se preenche as especificações, os padrões de qualidade e se tem condições de ser implementado; „ revisão da programação e do sistema, que verifica se os resultados dos testes do protótipo estão adequados; „ revisão da aceitação, que verifica se, após os testes do protótipo, já é possível colocar o resultado do projeto em produção; „ revisão de produção, que verifica se o sistema de produção está adequado e se há oportunidades de melhoria no produto; 176 book.indb 176 31/5/2007 14:24:02 Gerência de Projetos „ revisão dos aspectos técnicos do projeto; „ revisão dos aspectos comerciais; „ revisão pós-projeto, que busca aprender com os resultados finais do projeto. Simulações, revisões e testes são atividades do dia-a-dia do projeto e, como visto, interferem inclusive no seu final e podem se estender à produção, atividade que já não pertencerá ao escopo do projeto em si, mas à rotina. Agora que você finalizou a leitura desta unidade realize as atividades propostas a seguir e no EVA. Atividades de auto-avaliação Leia com atenção os enunciados e realize as atividades. 1) O que é importante fazer para iniciar um projeto? Explique porque é importante a fase preparação para o início do projeto. Procure comentar com um exemplo que você já vivenciou. Unidade 4 book.indb 177 177 31/5/2007 14:24:03 Universidade do Sul de Santa Catarina 2) Como você descreve os quatro passos da decisão? Dê um exemplo prático, a partir da sua experiência. 3) Descreva as principais fontes de conflito entre os indivíduos e as instituições, dando exemplos de sua própria experiência. 178 book.indb 178 31/5/2007 14:24:03 Gerência de Projetos 4) Quais as formas de administrar um conflito e qual delas melhor se adapta ao seu estilo de gestão? Por que esta forma de atuar e não as outras? Faça um comparativo e publique na “Exposição”. 5) Qual a importância do uso de simuladores no desenvolvimento de projetos? Unidade 4 book.indb 179 179 31/5/2007 14:24:03 Universidade do Sul de Santa Catarina Síntese Nesta unidade, você viu como os preparativos iniciais do projeto devem ocorrer e quais atividades são importantes para que a produção tenha início acompanhando o planejamento definido previamente. Você pôde aprender que o início do projeto pode definir também o padrão de qualidade que será buscado em toda a fase de desenvolvimento, especialmente se for implantada uma cultura de “defeito-zero”. Também foi analisada a comparação entre as características do gestor e as do líder. A figura do líder aqui definida é a do sujeito capaz de criar ambientes de cooperação e de trabalho criativo. Para isto, muitas vezes é necessário administrar conflitos, mostrar caminhos produtivos e tomar decisões que definam rumos para o projeto. Sem dúvida, uma das características fundamentais nessas atividades é a de motivar e inspirar. Por fim, tomando por base a necessidade de, durante a fase de planejamento, segmentar o projeto em pequenas tarefas e etapas, a fase de desenvolvimento pressupõe um conjunto de revisões e testes, que podem ser bem sucedidos se o projeto tiver resultados claros a serem atingidos em cada uma de tais etapas. Na próxima unidade, você estudará as atividades de encerramento do projeto, o processo de documentação dos trabalhos e também da dissolução da equipe e das análises finais, para verificar se os objetivos foram alcançados. Até lá! Saiba mais Para aprofundar os temas abordados na unidade, sugere-se: 1. As reuniões geralmente são esperadas como atividades não muito proveitosas. Isso acontece porque não existe uma boa preparação para elas. Uma reunião bem preparada conduz a 180 book.indb 180 31/5/2007 14:24:03 Gerência de Projetos decisões importantes e realizações. Acesse o link a seguir e conheça algumas sugestões e práticas para uma boa reunião citadas no artigo intitulado A boa geometria da reunião, de Carlos Cardoso Aveline. http://www.terra.com.br/planetanaweb/ flash/reconectando/ambiente/334/reuniao.htm 2. O uso de simuladores pode ser importante para verificar protótipos de produtos, antes mesmo de eles serem construídos. No caso do desenvolvimento eletrônico, por exemplo, há um interessante conjunto de simuladores, desenvolvidos com Java, que podem ser vistos no link: http://www.amanogawa.com/index. html . O exemplo é o seguinte: no projeto de uma antena, o projetista tem como variar as características do produto, e testar seus resultados. Se for construir um circuito eletrônico, poderá fazer simulações específicas. Você quer fazer um projeto de um novo modelo de “pipa/papagaio/maranhão”? (cada região usa um nome diferente). Veja o simulador computacional da NASA que está no site http://www.grc.nasa.gov/WWW/K-12/ airplane/kiteprog.html. Este é mais um ótimo exemplo de como simuladores apóiam o trabalho de novos projetos. Unidade 4 book.indb 181 181 31/5/2007 14:24:03 book.indb 182 31/5/2007 14:24:03 UNIDADE 5 Análise e conclusão do projeto 5 Objetivos de aprendizagem Ao final desta unidade você terá subsídios para: „ Compreender aspectos relativos à finalização do projeto, à dissolução das equipes e aos registros documentais do trabalho. „ Verificar que o sucesso do projeto ou o fracasso, está intimamente ligado às expectativas do cliente, por um lado, e à capacidade de liderança do gestor, por outro. „ Perceber que todo trabalho de projeto é uma fonte de aprendizagem, mas para que o aprendizado ocorra será necessário extrair lições e refletir sobre elas. „ Constatar que um projeto pode ser a origem de muitos outros, mas para isto os membros da equipe precisam estar atentos às oportunidades. Seções de estudo A seguir, apresentam-se as seções para você estudar. Seção 1 Seção 2 Seção 3 Seção 4 Seção 5 Seção 6 Fase de finalização Plano de contingência Atendendo as expectativas do cliente Sobre o sucesso (ou fracasso) do projeto Equipe e documentação Lições aprendidas e novas idéias Após a leitura dos conteúdos, realize as atividades propostas no final da unidade e no EVA. book.indb 183 31/5/2007 14:24:03 Universidade do Sul de Santa Catarina Para início de conversa As atividades de encerramento do projeto são o objeto de estudo nesta unidade, as quais consideram aspectos diversos como o processo de documentação dos trabalhos e também da dissolução da equipe e das análises finais, quando se verificará o grau de sucesso ou fracasso, alcançado pelo trabalho. O sucesso estará ligado à demanda original, vinda do cliente, seja este cliente um contratante externo ou você mesmo. Se a expectativa for atendida, a sensação de missão cumprida estará no ar. Se não, será a frustração do fracasso. Mas com o fracasso, principalmente, se aprende muito, é de onde se pode tirar lições para aproveitar no desenvolvimento dos novos projetos. Bom estudo! Seção 1 - Fase de finalização A finalização do projeto pode acontecer por dois motivos: (a) as coisas deram certas e o resultado esperado está sendo atingido; (b) as coisas deram erradas e é melhor finalizar antes que piore. Primeiro considere a opção “a” e deixe a opção “b” para a próxima seção. A avaliação de que o resultado está sendo atingido é obtida por medições que devem ser feitas a cada etapa do trabalho. Você viu isto quando estudou o algoritmo do projeto e foram tratados o acompanhamento e as medições em cada atividade. Atingir o grau satisfatório em cada uma dessas medições faz o projeto caminhar rumo ao objetivo final. 184 book.indb 184 31/5/2007 14:24:03 Gerência de Projetos Uma das marcas principais do encerramento do projeto é a data limite ou prazo final. Muitas vezes não teremos como discutir contra uma data, não haverá prorrogações. Então deveremos trabalhar tendo em vista tal data. O controle disso se dará no preenchimento e na atualização constante do Gráfico de Gantt, preenchendo-se as atividades “realizadas” e comparando-se com o “previsto”, assim como avaliando-se a cada passo o “caminho crítico” do projeto no diagrama PERT/CPM. Fechado o projeto, será importante avaliar as estatísticas sobre o tempo gasto, recursos utilizados, os riscos previstos que aconteceram e os que não aconteceram, se os custos previstos foram suficientes e todos os demais dados que possam ajudar a compreender melhor a gestão dos próximos projetos. Encerrar o projeto não será apenas concluir os trabalhos e fechar a porta. Este será o momento de avaliar se as expectativas do cliente foram atingidas e, se foram, avaliar o grau de sucesso do trabalho. Será o momento de reunir toda a documentação (obrigatoriamente) gerada, para que a história do trabalho seja preservada, permitindo a introdução do resultado do projeto num ciclo de vida de produção, bem como, permitir avançar em melhorias e mesmo em novos projetos, a partir das lições aprendidas. Será também o momento de desfazer a equipe, que nos casos de sucesso se transforma num momento triste e, nos de fracasso, uma libertação. Nas próximas seções você estudará com maior profundidade esses tópicos. Unidade 5 book.indb 185 185 31/5/2007 14:24:04 Universidade do Sul de Santa Catarina Seção 2 - Plano de contingência Na seção anterior, lembre-se que você interagiu com duas opções, “a” e “b”. Você já estudou a primeira opção e agora chegou a hora de estudar a segunda. Você já viu que em todo filme ou brincadeira, caso as coisas saiam erradas, diz-se que: Vamos ativar o plano “B”! Ora, esse plano “B” é o plano de contingência. O plano de contingência, infelizmente, não é uma “carta na manga” que facilmente é lançada sobre a mesa e muda todo o jogo. Geralmente é um conjunto de ações, tomadas sob pressão, geradoras de conflitos e de crises, pois o plano de contingência é um plano de solução de crises. A percepção do erro geralmente é postergada ao máximo e isto ocorre de forma inconsciente. Ninguém gosta de errar. Para isso, tem-se as ferramentas de planejamento, acompanhamento e controle do projeto (você acompanhou várias neste livro), que devem fazer parte de cada momento de revisão para que se possa perceber se estamos de acordo ou não com o planejado. Tais ferramentas apontam os erros, basta fazer as marcações e ler os indicadores. E tendo visto os erros, não é certo trabalhar com desculpas, pois este é outro defeito do ser humano, aceitável apenas em questões sentimentais (e não de trabalho). Realizando as revisões e percebendo erros capazes de afetar seriamente o projeto, um plano de contingência deve ser aplicado. Várias ações devem ser tomadas quando um projeto sai dos trilhos rumo ao fracasso. Quais são as ações corretivas? 186 book.indb 186 31/5/2007 14:24:04 Gerência de Projetos Conforme o trabalho de Iacovou e Dexter (2004), são definidas as seguintes ações corretivas, tentando remediar a situação: „ desenvolver um plano de recuperação; „ redefinir e gerenciar o propósito do projeto, ou seja, avaliar novamente o escopo do projeto e o que, de fato, se quer atingir; „ reavaliar o negócio e considerar o cancelamento do projeto, quando de fato não há solução de continuidade; „ replanejar o projeto usando métodos de estimativa apropriados e comprovados; „ gerenciar as expectativas dos clientes, pois eles perceberão rapidamente que “as coisas não estão indo bem”; „ formular um plano de comunicação objetivo e aberto, tanto para os membros da equipe, como para fornecedores e clientes – isso trará confiança; „ dividir o restante do projeto em pequenas partes ou atividades, facilitando o controle, a percepção de objetivos menores e mais próximos, bem como a capacidade de acreditar no sucesso; „ tratar as dificuldades pessoais da equipe do projeto, especialmente quando esta equipe se sentiu culpada pela aproximação do insucesso; „ incorporar práticas corretivas no processo de desenvolvimento do restante do projeto; „ por fim, reavaliar a liderança, verificando se ela é capaz de alinhar as diversas forças componentes do projeto rumo ao seu objetivo. O ponto principal de um plano de contingência, desta forma, é a tomada de decisão. Unidade 5 book.indb 187 187 31/5/2007 14:24:04 Universidade do Sul de Santa Catarina Tomar decisões é a tarefa dos líderes empenhados no sucesso. Por esse motivo, ao perceber que um projeto não vai bem, é importante verificar se o líder vai bem. Seção 3 - Atendendo as expectativas do cliente Toda propaganda hoje diz o seguinte: Fazemos de tudo para atender as expectativas do cliente. Sabemos que isto é apenas propaganda e que ninguém atende exatamente as expectativas do cliente. Provavelmente porque tais expectativas não são bem conhecidas. Nem mesmo pelos clientes. Quando um de nós diz: “vou comprar um quilo de açúcar” é muito fácil atender tal expectativa. No entanto, se dizemos: “queria um software para gerenciar a venda em balcão”, a expectativa é muito mais complexa do que está expressa nesta simples frase. Não é fácil compreender como o cliente deseja que o software seja, o tempo de resposta, a interface, quanto está disposto a gastar e muitas outras questões desse tipo. Não há uma regra sobre como avaliar todos esses requisitos, mas uma série de procedimentos foi apresentada neste livro ao discutir sobre os requisitos do cliente. A análise aprofundada de tais requisitos e a comunicação clara do que se entendeu como escopo do problema, tanto para o próprio cliente como para os membros da equipe de projeto, é condição básica para atender expectativas. E digo expectativas no plural, por entender que há 188 book.indb 188 31/5/2007 14:24:04 Gerência de Projetos aquelas específicas do cliente e aquelas da equipe e ambas devem ser atendidas para que haja sucesso. Além disso, não acredito em empresas que vivem alardeando que “fazem tudo pelo cliente”. As empresas fazem antes algo por si mesmas, depois pelo cliente. E nisto não há um juízo de certo ou errado, mas simplesmente o fato de que, para sobreviver, a empresa precisa olhar para si mesma. Não se trata também de ultrapassar limites de ética ou avançar em atitudes oportunistas, mas, sim, de ser realista quanto às finalidades de cada sujeito neste jogo. Assim, a expectativa do cliente deve ser tratada como algo objetivo e deve ficar claro para ambas as partes o que é possível realizar e o que não é. Chegar ao fim do projeto é, então, contemplar a expectativa desse cliente, seja ele um contratante externo, uma demanda da empresa ou um desejo de você mesmo. Ao confrontar tal contemplação, tem-se uma medida do sucesso do trabalho. Seção 4 - Sobre o sucesso (ou fracasso) do projeto O projeto foi entregue no prazo, gastou-se menos do que o previsto, o produto alcançou ou até mesmo superou as expectativas, os benefícios mensuráveis pelo seu resultado são enormes... bem, temos um projeto de sucesso. A equipe será condecorada, haverá prêmios para os responsáveis, a empresa passará a vender mais ou conquistar um nicho que antes não detinha. Inovações serão incorporadas pela indústria e pelo mercado e, dependendo do grau, poderão até mesmo revolucionar um setor ou um hábito. Para seqüência deste estudo, imagine, porém, a situação inversa: o fracasso. Todos queremos evitá-lo e, mesmo quando houver um fracasso, precisamos aprender com ele para crescer. Não há vitorioso que não tenha fracassado alguma(s) vez(es). Unidade 5 book.indb 189 189 31/5/2007 14:24:04 Universidade do Sul de Santa Catarina Como você pode se prevenir dos fracassos em projetos? Para Keeling (2002), existe fracasso em projetos quando: „ objetivos não são alcançados no prazo; „ custos vão além dos limites aceitáveis; „ resultados têm nível de qualidade comprometido. Nesses três itens resumem-se os fatores que definem um projeto: prazo, custos, recursos e benefícios. Se algum deles não for atendido, tem-se indícios de fracassos. No entanto, você pode fazer uma análise mais sutil. Há casos de projetos que foram concluídos com custo excessivo, muito além do orçamento original e acima do prazo estipulado. São exemplos desse tipo a Ópera de Sydney, na Austrália e o Eurotúnel, que liga a Inglaterra e França. No entanto, quem ousaria hoje dizer que são fracassos? Do ponto de vista dos custos e dos prazos, foram. Mas os benefícios aparentemente superam em muito essas falhas. Estes são casos de projetos estratégicos e visionários, que são considerados no início como equivocados ou previamente fracassados. Com o passar do tempo, percebe-se o quanto foram importantes para os desdobramentos futuros. Isso se deve à visão poderosa, à intuição e à persistência de lideranças e não aos cálculos e estudos de burocratas anônimos. 190 book.indb 190 31/5/2007 14:24:05 Gerência de Projetos Figura 5.1. Ópera de Sydney, na Austrália, projetada em 1957 pelo dinamarquês Jorn Utzon, que hoje é Patrimônio Nacional da Austrália. Atualmente, muitos projetos na área de software têm sido vítimas da síndrome do fracasso. Por este motivo, boa parte dos estudos recentes sobre gestão de projetos tem se voltado a analisar tais casos e o interesse sobre os trabalhos do PMI (Project Management Institute) é sintomático de uma realidade de mercado. Segundo Page-Jones (1990), embora todo projeto de Processamento de Dados enfrente dificuldades técnicas, elas não são a causa principal de fracassos. Os desastres verdadeiramente impressionantes são devidos a gerenciamento inadequado ou inepto de projetos. Esse autor ataca exatamente o ponto: os problemas relativos a projetos não estão nas questões técnicas e tampouco em atrasos ou gastos, pois, estes são conseqüências de um problema maior: o fracasso da gestão. Como evitar o fracasso da gestão? Unidade 5 book.indb 191 191 31/5/2007 14:24:05 Universidade do Sul de Santa Catarina Pode-se evitar fracassos, conforme Keeling (2002), com: „ melhor avaliação de viabilidade; „ análise de riscos criteriosa; „ uso de métodos de planejamento; „ uso de sistemas de controle. Porém, isto não é suficiente, apesar de necessário. Um grupo de trabalho pode se reunir e fazer várias avaliações, considerar inúmeros riscos e gerar grandes relatórios, preencher planilhas e usar softwares de planejamento de projetos. Mas tudo isso é inócuo se não houver o poder da decisão e o poder da decisão é uma atividade humana. Com isto, quero dizer que é preciso ter liderança para que um projeto aspire ao sucesso. Para encerrar esta seção, acompanhe um caso famoso de fracasso, motivo de estudos e pesquisas dos interessados em administração sobre o projeto de construção de uma embarcação de guerra, no século XVII. 192 book.indb 192 31/5/2007 14:24:06 Gerência de Projetos Estudo de Caso: VASA – um projeto fracassado do século XVII. O caso da embarcação “Vasa” foi apresentado no artigo de Kessler et al. (2004), do qual retirei a história seguinte. Figura 5.2. Representação em escala reduzida, Museu do VASA (Fairley e Willshire, 2003). No começo do século XVII, a Suécia estava engajada numa série de batalhas navais contra a Dinamarca, Rússia e Polônia. Em 1625, dez embarcações de guerra suecas foram abatidas quando estavam patrulhando a Baía de Riga. Por este motivo, foram aceleradas as atividades de construção de uma das maiores naves de guerra daquele tempo: Vasa. Por ter descoberto que a Dinamarca planejava construir um barco ainda maior que o Vasa, o rei da Suécia, Gustavus Adolphus, ordenou alterações na especificação do navio para introduzir um segundo nível de canhões e mais canhões do que originalmente planejado. Com tais modificações o Vasa excedeu em muito o que poderia ser suportado pelo lastro original. Unidade 5 book.indb 193 193 31/5/2007 14:24:06 Universidade do Sul de Santa Catarina Além disso, o mestre construtor, Henrik Hybertson, faleceu, deixando a construção nas mãos de um gerente inexperiente e mais fraco nas decisões e controle dos operários. No verão de 1628, um teste de estabilidade foi conduzido pelo Almirante Klas Fleming e pelo Capitão Sofring Hansson. Trinta homens correram de um lado ao outro do navio. Depois da terceira corrida o navio inclinava tão violentamente que o teste foi interrompido. No entanto, Fleming decidiu não postergar o lançamento do navio, alegando que o mestre construtor já tinha feito navios antes e não havia com o quê se preocupar. Menos de um mês depois, em 10 de agosto de 1968, o Vasa foi levado ao mar. Para mostrar o poder dos armamentos da embarcação, o Capitão Hansson velejou com as portas dos canhões abertas, o que não era usual. Depois de navegar pouco mais de mil metros em mar calmo, o Vasa entornou e naufragou, levando consigo cinqüenta marinheiros para o fundo do porto de Estocolmo. Era uma embarcação magnífica, que tinha custado cerca de 5% do tesouro sueco, com 64 canhões pesados e para 300 marinheiros, feito para simbolizar a força e a beleza da Suécia e para meter medo no coração dos seus inimigos. Muita discussão foi feita para descobrir os culpados pelo desastre, mas ninguém foi formalmente acusado. O rei foi parcialmente culpado por ter demandas pouco realistas, Hybertson pelo desenho medíocre do projeto, Fleming por não ter dado atenção aos testes realizados e Hansson pela inabilidade no comando da embarcação. Os erros, porém, foram bem mais graves do que esses e pode-se considerar os seguintes detalhes: 1. os construtores tentaram imitar o projeto da embarcação dinamarquesa Sancta Sophia, no entanto não tinham conhecimento técnico nem capacidade de desenvolver procedimentos construtivos para tanto; 2. ênfase na elegância e no poder de fogo e pouca importância à estabilidade e navegabilidade; 3. excesso de pressa na construção do barco e pouca atenção a sua qualidade, especialmente se considerar a sua dimensão e a quantidade de novas tecnologias que estavam incorporadas, o que atribuía ao projeto uma série de riscos e incertezas; 194 book.indb 194 31/5/2007 14:24:07 Gerência de Projetos 4. os testes durante a fase de desenvolvimento eram incompletos, houve desprezo pelos resultados de tais testes e excesso de otimismo com o resultado do projeto, desconsiderando os sinais em contrário; 5. três pessoas diferentes fizeram especificações e definições para o projeto, de forma independente, modificando o conjunto (o Rei, Hybertson e o último mestre); 6. o projetista principal, Hybertson, faleceu um ano antes de o navio ser concluído e não deixou documentação ou memória, ou seja, não houve transferência tecnológica; 7. o rei não tinha conhecimentos técnicos para o problema proposto e, mesmo assim, interferiu no projeto como seu chefe supremo. Este conjunto de fatores gerou esse fracasso exemplar. Seção 5 - Equipe e documentação Equipes de projeto podem criar tal afinidade e desfazê-las não é fácil. Ficam as afinidades e o entusiasmo, especialmente se há sucesso. O encerramento das atividades deve passar por uma avaliação de finalização. Uma discussão franca sobre erros e acertos, especialmente no que se refere ao modelo de gestão adotado, bem como ao dia-a-dia da equipe, trará benefícios e crescimento a todos. Reconhecimento dos méritos: eis uma obrigação. Há muitos casos de projetistas que empenham horas de esforço e imaginação num projeto e sabemos que não são apenas aquelas horas que estão escritas lá na planilha. Estas horas são doações espontâneas daqueles que gostam de desafios e almejam sempre a qualidade e a realização. O reconhecimento disto deve Unidade 5 book.indb 195 195 31/5/2007 14:24:08 Universidade do Sul de Santa Catarina ser manifestado claramente e, quando houver oportunidade e condições, deve ser premiado. Receber um prêmio, mesmo que seja uma simples palavra de agradecimento sincero, é algo honroso. Conheço gestores que não sabem premiar e consideram que realizar o trabalho é a obrigação de cada um. Tomara que você não encontre um desses pela frente! Documentação é um ponto falho em quase todos os projetos. Quando Joãozinho e Mariazinha entraram pelo caminho desconhecido na floresta, a trilha de pedras que ele deixou foi seu documento principal, o documento que permitiu que ele voltasse para casa. Este era o “caminho das pedras”. No entanto, quando o único material que ele tinha para documentar o caminho, na segunda vez que entrou pela floresta, eram pedaços de miolo de pão, os pássaros comeram sua marcação e ele se perdeu. Esta documentação era efêmera. A memória é uma documentação efêmera. A documentação não é adequada se não for clara, estiver arquivada, acessível e possível de ser entendida por outros. Você acompanhou desde a primeira unidade que o planejamento está baseado em análises, avaliações, relatórios, depois planilhas e diagramas. Muitos desses documentos serão usad os ao longo do projeto para revisões, serão realizadas reuniões que deverão gerar atas e assim por diante. Além disso, o trabalho técnico será baseado em desenhos, rascunhos, anotações, resultados de testes e muitos outros documentos de variados tipos. 196 book.indb 196 31/5/2007 14:24:08 Gerência de Projetos Nenhum projeto poderá ser considerado encerrado se a documentação não estiver adequadamente preservada e organizada. É uma obrigação dos responsáveis de cada etapa do projeto e do gestor finalmente, organizar, arquivar e preservar a documentação do projeto, que deve ser parte do resultado final do trabalho. Seção 6 - Lições aprendidas e novas idéias Cada projeto é uma oportunidade de aprendizagem e, geralmente, aprendemos com os erros. A constante revisão do projeto, em cada uma das suas etapas, será um exercício de análise e, para isso, contamos com diversos instrumentos, tais como relatórios preenchidos lá no começo e que devem ser analisados em comparação com o realizado, passo a passo. Muitas críticas e idéias surgirão nesses momentos e é importante avançar sobre isto. Como dito na seção anterior, a documentação gerada será uma fonte de recursos de aprendizado. A leitura do caso “Vasa” também é uma oportunidade de aprendizagem, pois você poderá estudar erros e acertos em projetos de outros para avaliar caminhos. O estudo de casos proporciona, em contraste com nossa própria experiência, uma fonte rica de aprendizagem. Considere novamente o caso “Vasa” e compare com projetos na área de software. Foi exatamente isso que fizeram Fairley e Willshire (2003) em seu artigo sobre problemas em projetos de software, buscando antídotos para Unidade 5 book.indb 197 197 31/5/2007 14:24:08 Universidade do Sul de Santa Catarina tais problemas numa série de sugestões, cujas principais estão apresentadas no quadro 5.1. Quadro 5.1. Problemas em projetos de software e seus antídotos, adaptado de (Fairley & Willshire, 2003). PROBLEMA Pressão excessiva de prazos Pressão excessiva de prazos Mudanças no escopo e nas necessidades Falta de especificações técnicas Falta de documentação de planejamento Inovações excessivas ou secundárias ANTÍDOTOS • estimativas objetivas de prazo • mais e melhores recursos priorizações • estimativas objetivas de prazo • mais e melhores recursos priorizações • desenvolvimento iterativo • modificar gestão de controle e planejamento • desenvolvimento de especificações prévias • atualização das especificações com base em eventos indicação de um arquiteto de software • desenvolvimento de planejamento prévio • atualizações periódicas e baseadas em eventos indicação de um gestor de projetos • maior controle sobre a linha de trabalho • análise de impactos gestão contínua dos riscos • uso de protótipos Falta de métodos científicos • desenvolvimento incremental uso de métricas de medição da performance técnica Ignorando o óbvio • assimilar as lições aprendidas anteriormente Comportamento anti-ético • cultura de trabalho baseada em ética nos relacionamentos uso e aderência a códigos de ética formais Aparentemente, um projeto de embarcação nada tem a ver com o desenvolvimento de software, mas não é bem isto que nos sugere este conjunto de “problemas e seus antídotos”. Analisando o quadro 5.1 você pode perceber que as lições tiradas do episódio são muitas e algumas das mais importantes dizem respeito ao uso de métricas de performance, ao desenvolvimento incremental, à divisão do projeto em pequenas etapas, ao controle constante do desenvolvimento e a uma cultura baseada em ética e bom relacionamento. 198 book.indb 198 31/5/2007 14:24:09 Gerência de Projetos Você poderia ainda listar mais algumas lições! Tais como: „ não se deve imitar projetos sem o suficiente conhecimento técnico; „ buscar concisão e usabilidade; „ não se submeter à pressa e dar atenção especial à qualidade; „ realização constante e contínua de testes, durante todas as etapas; „ reduzir os cargos de responsabilidade, para evitar o “empurra-empurra” da decisão; „ gerar documentação sempre e não apenas no final; „ aqueles que não têm conhecimento técnico não devem interferir em assuntos que não são de sua competência. Se você retornar à unidade 1 deste livro, poderá ver que os projetos foram se modificando no decorrer do tempo e as lições aprendidas foram sendo incorporadas pouco a pouco. No início, houve desperdício imenso de recursos financeiros e mesmo de vidas humanas. Um esforço enorme de melhoria se deu na época da revolução industrial e logo depois, chegando ao começo do século XX com teorias e ferramentas específicas. Hoje, temos um número muito maior de ferramentas, sistemas computacionais especiais e disputas teóricas em revistas especializadas. Porém, ao mesmo tempo, os resultados não são tão animadores. Basta conferir nos quadros apresentados na unidade 1 que comparam o passado e o presente. Espero que você se dedique firmemente para não colocar seus próprios projetos naquela estatística. Bem, você estudou questões sobre aprendizagem e sobre o processo de tirar lições dos fatos, das dificuldades e soluções que irá encontrar no decorrer do trabalho de desenvolvimento do projeto. Porém, acredite, Unidade 5 book.indb 199 199 31/5/2007 14:24:09 Universidade do Sul de Santa Catarina tais lições só serão percebidas e aprendidas por pessoas e equipes especiais. Para pessoas e equipes cheias de idéias e criatividade, encerrar um projeto geralmente serve de pretexto para dar origem a um novo projeto, pois todas as idéias que foram surgindo no meio do caminho são sementes para novos trabalhos. Empresas buscam pessoas assim, para que sobrevivam no mercado criando oportunidades de novos negócios. Anotações feitas durante o trajeto de desenvolvimento serão geradoras de oportunidades em ambos os sentidos. Por um lado, vários apontamentos indicarão a necessidade de acrescentar melhorias incrementais, as quais não caberiam no decorrer do projeto já que atrasariam o trabalho ou determinariam custos impossíveis de cumprir. Por outro lado, idéias completamente novas poderão surgir, apontando para soluções radicalmente diferentes. É importante também perceber que o fracasso de um projeto não é, necessariamente, o encerramento das oportunidades. Os fracassos ou os graves problemas de um projeto chamam a atenção para novas oportunidades de desenvolvimento. Mas para renascer é preciso ter o espírito e a convicção dos líderes. Inúmeras oportunidades estão a sua frente. Ou seja, é a hora de começar um novo projeto. Boa sorte! 200 book.indb 200 31/5/2007 14:24:09 Gerência de Projetos Atividades de auto-avaliação Leia com atenção os enunciados e realize as atividades. 1) Quais são os passos para implantar um plano de recuperação num projeto em crise? Exemplifique com projetos de sua experiência. 2) Que grandes dificuldades existem no atendimento das expectativas do cliente? Unidade 5 book.indb 201 201 31/5/2007 14:24:09 Universidade do Sul de Santa Catarina 3) Como se pode prevenir um projeto do fracasso? Que atitudes você pode tomar nesse sentido? 4) Quais lições você tira do fracasso do projeto VASA para seus próprios projetos? 202 book.indb 202 31/5/2007 14:24:09 Gerência de Projetos Síntese Nesta unidade, você viu que é importante uma análise criteriosa de todos os passos dados durante o projeto e documentá-los. Assim, será possível dar continuidade às melhorias que o projeto exigir, permitir o suporte ao produto, aprender com os erros e acertos do processo e também gerar novas idéias de projetos. Outra questão importante refere-se ao reconhecimento dos membros da equipe como os verdadeiros responsáveis pelas conquistas obtidas. Evidenciar tais méritos é uma obrigação, pois a partir do momento que o projeto se encerra as pessoas se voltarão para outros trabalhos e funções, e lembrando-se desses momentos de desafio, sentirão satisfação por saber que foram reconhecidos. Haverá os casos de fracassos, que devem ser analisados com ainda maior rigor, permitindo nosso crescimento pessoal e também a propagação da experiência para todos os interessados. Estudos de casos famosos são, também, importantes objetos de pesquisa e análise. Oportunidades de novos projetos estão a nossa disposição. A última seção fala justamente disto e, de certa forma, nos liga ao início deste livro, que discute a origem dos projetos. Que seja aqui o ponto de ligação para o eterno recomeçar, seja dos estudos, seja dos projetos, seja dos novos empreendimentos de sucesso. Até mais! Unidade 5 book.indb 203 203 31/5/2007 14:24:09 Universidade do Sul de Santa Catarina Saiba mais Para aprofundar os temas abordados na unidade, sugere-se: 1 – Visite o site http://www.arcweb.com/ e veja inúmeros estudos e oportunidades de novos projetos na área empresarial e industrial. Veja também estudos de casos e análises de mercado. 2 - O IEEE – Institute of Electric and Electronic Engineers – mantém uma Sociedade voltada à gestão de engenharia e projetos, de âmbito mundial. É a IEEE Engineering Management Society. Visite o site http://www.ewh.ieee.org/soc/ ems/ e veja inúmeras oportunidades de trabalho, estudo, artigos, revistas, etc. Estudantes de graduação de qualquer área podem se associar com valores de taxas anuais especiais. 204 book.indb 204 31/5/2007 14:24:09 Para concluir o estudo Com este livro, você fez uma revisão geral da disciplina de Gerência de Projetos. Foram trabalhados os principais tópicos da matéria, desde o início da idéia de um projeto, passando por seu planejamento, técnicas de modelagem, métodos de controle durante a fase de execução, procedimentos para encerramento e documentação, chegando à entrega ao cliente ou solicitante. O assunto da “gerência de projetos” é essencialmente moderno, apesar dos projetos fazerem parte da história do homem. É moderno porque, atualmente, os ciclos de evolução tecnológica se sucedem muito rapidamente e as empresas precisam se renovar continuamente para se manterem vivas. Esta renovação, na maioria das vezes, se dá pela criação de novos produtos e processos através de projetos. Espero ter colocado elementos úteis para o estudante e leitor, que possibilitem a abertura de novas idéias e a revisão dos conceitos existentes. É um assunto vivo e, por isto, sujeito a críticas e novas propostas. Ficarei grato por todos os comentários e críticas que você, leitor atento, possa fazer. Sucesso a todos! Prof. Mauro Faccioni Filho book.indb 205 31/5/2007 14:24:09 book.indb 206 31/5/2007 14:24:10 Referências BAZZO, Walter Antônio, PEREIRA, Luiz Teixeira do Vale. Introdução à Engenharia, 5.ed. Florianópolis, Editora da UFSC, 1997. CHRISTENSON, Dale; WALKER, Derek H. T. Understanding the role of “vision”in project success. IEEE Engineering Management Review, vol 32, no. 4, 2004. pp 57-73. CLELAND, David. The evolution of project management. IEEE Transactions on Engineering Management, v.51, no. 4, 2004, pp. 396-397. COURAU, Christophe. Muralhas que dividiram os homens, História Viva, edição 13, novembro de 2004. http://www2.uol. com.br/historiaviva/home.html (acessado em 18/02/2005) COVEY, Stephen. O 8º. Hábito: da eficácia à grandeza. Rio de Janeiro: Elsevier, 2005. 413 p. DeMARCO, Tom. Controle de projetos de software. Editora Campus, Rio de Janeiro, 1991. 304 pp. DVIR, Dov, SHENHAR, Aaron., ALKAHER, Shlomo. From a single discipline product to a multidisciplinary system: adapting the right style to the right project. IEEE Engineering Management Review, vol 32, no. 1, 2004. pp 12-23. FACCIONI Filho, Mauro. Especificação e solução de problemas de engenharia. (Apostila) curso de Especialização “Automação e Computação Industrial”, fevereiro de 2004, CTAI/Senai/SC, Florianópolis. FACCIONI Filho, Mauro. Gestão de Projetos e de Equipes. Palhoça: Unisul Virtual, 2005. 300p. FAIRLEY, Richard E., WILLSHIRE, Mary Jane. Why the Vasa Sank: 10 Problems and Some Antidotes for Software Projects. IEEE Software. March/April, 2003. pp 18-25 (disponível em http://computer.org/ software ) FERNANDES, Jorge Monteiro. Gestão da Tecnologia como parte da estratégia competitiva das empresas. Brasília: IPDE, 2003. 275 p. book.indb 207 31/5/2007 14:24:10 GOOCH, Tom. Object Oriented Analysis and Design Team. Kennesaw State University, 2000. (disponível em http://pigseye.kennesaw.edu/ ~dbraun/csis4650/A&D/index.htm. Acesso em: 24/Abril/2005). GREEFF, Gerhard. Staying in sync. ISA Intech/Industrial Computing, vol 52, no. 6, June 2005. pp. 51-55. (www.isa.org/intech) HINOJOSA, María Alejandra. DIAGRAMA DE GANTT. 2003. Disponível em www.gestiopolis.com, acessado em 24/04/2005. HOUAISS, Antônio. Dicionário Houaiss da Língua Portuguesa. Editora Objetiva / Instituto Antônio Houaiss. Rio da Janeiro, 2004. 2922 pp. IACOVOU, Charalambos, DEXTER, Albert. Turning around runaway information technology projects. IEEE Engineering Management Review, vol 32, no. 4, 2004. pp 97-112. KEELING, Ralph. Gestão de projetos, uma abordagem global. Editora Saraiva, 2002, 294 pp. KESSLER, Eric H., BIERLY, Paul, GOPALAKRISHNAN, Shanthi. VASA Syndrome: insights from a 17th-Century new-product disaster. IEEE Engineering Management Review, vol 32, no. 1, 2004. pp 38-48. KLOPPENBORG, Timothy; PETRICK, Joseph. Managing Project Quality. IEEE Engineering Management Review, vol 32, no. 4, 2004. pp 86-790. MSF – Microsoft Solutions Framework, 1998. Disponível em www. microsoft.com/technet/itsolutions/msf/default.mspx PAAP, Jay, KATZ, Ralph. Anticipating disruptive innovation. IEEE Engineering Management Review, vol 32, no. 2, 2004. pp 74-85. PAGE-JONES, Meillir. Gerenciamento de projetos: guia prático para restauração da qualidade em projetos e sistemas de processamento de dados. São Paulo: McGraw-Hill, 1990. 328 pp. PQA - History of Project Management, www.pqa.net, acessado em 15/02/2004. Process Quality Associates Inc. PMBOK, Guide to the Project Management Body of Knowledge, Project Management Institute, 2004, 3a. edição, 388 pp. PRADO, Darci Santos do. PERT/COM – Série Gerência de Projetos, volume 4. 1998. Belo Horizonte. Editora DG. RAZ, Tzvi, BARNES, Robert, DVIR, Dov. A critical look at Critical Chain Project Management. IEEE Engineering Management Review, vol 32, no. 2, 2004. pp 35-44. SÁENZ, Tirso W., CAPOTE, Emilio G. Ciência, Inovação e Gestão Tecnológica, IEL/SENAI, Brasília, 2002. book.indb 208 31/5/2007 14:24:10 SISK, Toney. The History of Project Management. http://officeupdate. microsoft.com/downloadDetails/projhistory.htm. Acesso em 20/Fev/2005) VALERIANO, Dalton L. Gerência em projetos – pesquisa, desenvolvimento e engenharia. São Paulo: Makron Books, 1998. 438 pp. book.indb 209 31/5/2007 14:24:10 book.indb 210 31/5/2007 14:24:11 Sobre o professor conteudista Mauro Faccioni Filho nasceu em Maringá, PR, em 29 de outubro de 1962. Formou-se em Engenharia Elétrica pela Universidade Federal de Santa Catarina (UFSC) no começo do ano de 1985 e nesse mesmo ano fundou a empresa Creare Engenharia (www.creare.com.br), junto com dois colegas da universidade. Posteriormente, concluiu, também na UFSC, Mestrado (1997) e Doutorado (2001) em Engenharia Elétrica, com estudos sobre representações tridimensionais e modelagem numérica computacional. Nos anos 2002 a 2004, atuou como diretor do Centro de Tecnologia em Automação e Informática – CTAI, em Florianópolis, tendo participado da criação de cursos superiores e de pré-incubadora empresarial tecnológica, além de ter editado revista técnica em automação e informática. Desde 2002 está na UNISUL como professor. Participou do desenvolvimento em 2004 do projeto do Curso Superior de Tecnologia em Web Design e Programação, do qual é atualmente coordenador e onde atua também como tutor. Em 2006, fundou a empresa FAZION Sistemas, dedicada à “inteligência em redes móveis”, onde sua equipe desenvolve softwares para “web móvel” (www. fazion.com.br) . Com vários artigos técnicos e científicos publicados, lançou ainda três livros de poemas. Seu currículo completo está disponível para consulta online no banco de dados do CNPq, no endereço http://buscatextual.cnpq. br/buscatextual/index.jsp. book.indb 211 31/5/2007 14:24:11 book.indb Sec1:212 31/5/2007 14:24:11 Respostas e comentários das atividades de auto-avaliação A seguir, acompanhe as respostas sobre as atividades de autoavaliação apresentadas ao longo de cada uma das unidades desta disciplina. Para o melhor aproveitamento do seu estudo, confira suas respostas somente depois de realizar as atividades propostas. UNIDADE 1 1) Resposta: o exemplo descrito deve claramente identificar um objetivo e um prazo determinado de execução 2) Resposta: durante a revolução industrial há maior interesse em desenvolver métodos de gerência, para evitar gastos desnecessários, perdas de tempos, atrasos, etc. Um cientista da administração surge nessa época e começa a estudar detalhadamente o trabalho, mostrando que a produtividade pode ser aumentada se o trabalho for dividido em pequenas tarefas separadas. Seu nome é Frederick Taylor (1856-1915) e ele é considerado o pai da ciência da administração (SISK, 2004). 3) Resposta: na prática não houve mudanças e os índices são muito próximos e até piores, apesar da implementação de variadas técnicas para controle de produção introduzidas durante o século XX. Isto indica que as empresas não estão utilizando tais técnicas e continuam realizando seus trabalhos sem gerenciamento. book.indb Sec1:213 31/5/2007 14:24:11 Universidade do Sul de Santa Catarina 4) Respostas: Área Exemplo de projeto Exemplo de tarefa de rotina ou atividade contínua Concessionária de energia elétrica (projeto de nova hidrelétrica) (operação da hidrelétrica) Software (nova plataforma de e-commerce) ( manutenção de aplicativo) Indústria Automobilística (desenho de novo lançamento) (linha de montagem) Bancos (criar nova linha de financiamento e lançar no mercado) (operar carteiras de crédito) Governo (desenvolver sistema de eleição eletrônica) (emissão de títulos eleitorais) 5) Resposta - exemplo: - necessidade: um sistema de marcação do tempo que fosse portátil -conhecimentos: tecnologia mecânica dominada - idéias: relógio de pulso, de bolso - seleção: de pulso - desenvolvimento: artesãos suíços - uso de difusão: relógios de quartzo, com ponteiros e com visor digital, etc) 6) Resposta: veja o desenho a seguir. carro 4x4 casa software 214 book.indb Sec1:214 31/5/2007 14:24:11 Sistemas Informatizados Corporativos no Âmbito da Administração Pública: SIAFI, SIAFEM e SIGEF UNIDADE 2 1) Resposta exemplo: Visão restrita: instalar um software de controle de estoque, que relaciona os produtos em prateleira e dá a baixa a partir da emissão da nota fiscal de venda, com controle feito por um “responsável” pelo estoque; Visão ampla: sistema integrado que verifica o estoque durante o processo de emissão de propostas, ele deve ser atualizado a cada modificação solicitada pelo cliente, sendo que quando este dá o aceite, imediatamente o estoque recebe o aviso da baixa e a reposição é requisitada automaticamente. 2) Resposta exemplo:: „ listar as informações que estão no enunciado, na tentativa de detalhar o melhor possível suas partes; „ descrever todos os efeitos conhecidos do produto, quando for o caso, e enumerar todas as possíveis causas; „ listar o que deve ser determinado pela solução, ou seja, definir com a maior clareza possível o que está sendo buscado; „ criar modelos e esquemas de representação, permitindo uma melhor visualização do conjunto; „ desenvolver desenhos esquemáticos, diagramas e fluxogramas; „ verificar as leis físicas associadas e também outros impeditivos e limitantes, tais como questões jurídicas, restrições técnicas, restrições ambientais, etc; „ usar simuladores como ferramentas de apoio. 3) Resposta: o algoritmo permite modelar o planejamento do projeto de maneira a entendermos e definirmos todos os passos que devem ser seguidos na execução do projeto, para que o mesmo chegue ao resultado esperado. 4) Resposta: a partir de certo prazo o projeto perde o sentido. Isto não significa apenas que ele dá prejuízo, mas simplesmente não há mais possibilidade de se obter sucesso, como por exemplo, no lançamento de um produto específico para uma data, ou quando há uma concorrência, ou devido a um fenômeno natural, etc. 5) Resposta: porque projetos são trabalhos que envolvem variáveis muito diversas e como há um prazo determinado para seu encerramento, fatores como custos e recursos tendem a variar conforme a complexidade do problema e por isto é difícil manter todas as previsões. 215 book.indb Sec1:215 31/5/2007 14:24:11 Universidade do Sul de Santa Catarina UNIDADE 3 1) Resposta: porque projetos são trabalhos que envolvem variáveis muito diversas e como há um prazo determinado para seu encerramento, fatores como custos e recursos tendem a variar conforme a complexidade do problema e por isto é difícil manter todas as previsões. Projeto Qualidade Prazos estimados pela equipe de implantação A - reuniões do grupo do projeto para definir o programa 1 semana, 7 dias B - redação do programa de qualidade 2 semanas, 14 dias C - treinamento do pessoal do setor administrativo 3 dias D - implantação do programa de qualidade no setor administrativo; 2 semanas, 14 dias E - treinamento do pessoal do setor de produção 3 dias F - implantação do programa no setor de produção; 2 semanas, 14 dias G - avaliação dos resultados e conclusão 3 dias 2) Resposta: 4) Resposta: a matriz ajuda a definir as necessidades de um projeto e alinhar aos recursos humanos disponíveis para o trabalho. Não havendo recursos humanos na empresa ou grupo, pode-se buscar por recrutamento externo. Da mesma forma, a matriz ajuda a definir os investimentos financeiros do projeto, pois é possível definir os gastos com a equipe de acordo com os custos de hora-homem dos membros escolhidos. 216 book.indb Sec1:216 31/5/2007 14:24:11 Sistemas Informatizados Corporativos no Âmbito da Administração Pública: SIAFI, SIAFEM e SIGEF 5) Resposta: Geralmente a estrutura exclusiva, com um organograma bem definido, é o que melhor se adapta nessas condições. Nesse modelo, os membros do projeto são dedicados a um projeto apenas. 6) Resposta: esta é a estrutura matricial e seu grande problema é a complexidade, que exige maturidade da empresa e das equipes de projeto para poderem trabalhar em vários projetos simultaneamente, com equipes alterando-se conforme o cronograma e o setor/atividade. 7) Resposta: na estrutura do tipo horizontal, pois os membros da equipe se reconhecem como pares, mesmo quando os domínios e os interesses técnicos são muito diferentes. Esse tipo de estrutura é tipicamente multidisciplinar, com grande número de idéias e soluções criativas, o que favorece o desenvolvimento de aplicativos de software. UNIDADE 4 1) Resposta: antes de começar um projeto é necessário uma etapa de reflexão para elaborar a etapa de início do projeto. A etapa de início de um projeto deve se dar por conta de uma reunião. Nesta reunião, os planos serão discutidos em detalhes, o plano de produção deve ser delineado, as tarefas divididas e as responsabilidades atribuídas. O fluxograma geral deve ser apresentado, discutido e suas cópias distribuídas. A comunicação dos procedimentos, já discutidos, deve ser feita a partir desse contato inicial. 2) Resposta: os quatros passos são: (1) identificar possíveis modos de ação, (2) verificar vantagens e desvantagens; (3) discutir e avaliar; (4) escolher o modo de ação mais vantajoso e partir para ele. 3) Resposta: resposta subjetiva, baseada no seguinte quadro: Diferenças Indivíduo / profissional Busca a inovação tecnológica Quer autonomia de ação Quer livrar-se de regras e procedimentos Quer autoridade baseada em mérito Quer ser recompensado com base em seu desempenho Quer ampla comunicação entre pares Busca otimização do próprio trabalho Organização / gerência Busca o lucro Quer integrar os profissionais na organização Estabelece as regras e procedimentos Autoridade baseada em hierarquia Recompensa conforme o interesse da organização Bloqueia a comunicação interna Busca cumprimento de cronogramas e custos 4) Resposta: as formas apresentas são: por confronto, por comprometimento, por acomodação, por prevalência, por retirada. 5) Resposta: O uso de simuladores pode ser importante para verificar protótipos de produtos, antes mesmo de eles serem construídos. Os simuladores passaram a ser ainda mais importantes com o avanço da informática, que permitiu o uso de simulação computacional, que poupa 217 book.indb Sec1:217 31/5/2007 14:24:13 Universidade do Sul de Santa Catarina tempo e dinheiro, especialmente em projetos de produtos complexos ou muito grandes, como máquinas, grandes hidrelétricas, grandes construções, etc. UNIDADE 5 1) Resposta: os passos são: „ desenvolver um plano de recuperação; „ redefinir e gerenciar o propósito do projeto; „ reavaliar o negócio; „ replanejar o projeto usando métodos de estimativa; „ gerenciar as expectativas dos clientes; „ formular um plano de comunicação; „ dividir o restante do projeto em pequenas partes; „ tratar as dificuldades pessoais da equipe do projeto; „ incorporar práticas corretivas; „ reavaliar a liderança (Os exemplos serão individuais). 2) Resposta: erros de comunicação no início do projeto causam frustrações na fase final. Os clientes têm dificuldades para definir seus requisitos e muitas vezes têm expectativas exageradas. 3) Resposta: pode-se evitar fracassos tomando as seguintes atitudes: „ avaliando detalhadamente a viabilidade do projeto antes de começá-lo; „ fazendo uma análise de riscos criteriosa; „ usando métodos de planejamento; „ usando sistemas de controle durante a fase de desenvolvimento. 4) Resposta: subjetiva: haverá citações sobre o descontrole, sobre a falta de liderança, sobre as interrupções constantes feitas pelo rei, sobre a falta de conhecimento técnico apropriado, sobre o planejamento fraco, sobre a falta de documentação. 218 book.indb Sec1:218 31/5/2007 14:24:13