(1927 - 18737) Gestao de Projetos e de Equipes

Universidade do Sul de Santa Catarina
Gesto de Projetos e de Equipes II

Disciplina na modalidade a distncia
Palhoa UnisulVirtual 2011
Mauro Faccioni Filho

Livro didtico Design instrucional Flavia Lumi Matuzawa Leandro Kingeski Pacheco 1 edio revista
Palhoa UnisulVirtual 2011
Copyright UnisulVirtual 2011 Nenhuma parte desta publicao pode ser reproduzida por qualquer meio sem a prvia autorizao desta instituio.
Edio Livro Didtico

Professores Conteudistas Mauro Faccioni Filho Design Instrucional Flavia Lumi Matuzawa Leandro Kingeski Pacheco Assistente Acadmico Aline Cassol Daga (1 ed. rev.) Projeto Grfico e Capa Equipe UnisulVirtual Diagramao Evandro Guedes Machado Davi Pieper (1 ed. rev.) Reviso B2B
658.404 F12 Faccioni Filho, Mauro Gesto de projetos e de equipes II : livro didtico / Mauro Faccioni Filho ; design instrucional Flavia Lumi Matuzawa, Leandro Kingeski Pacheco ; [assistente acadmico Aline Cassol Daga]. 1. ed. rev. Palhoa : UnisulVirtual, 2011. 169 p. : il. ; 28 cm. Inclui bibliografia. 1. Administrao de projetos. I. Matuzawa, Flavia Lumi. II. Pacheco, Leandro Kingeski. III. Daga, Aline Cassol. IV. Ttulo.
Ficha catalogrfica elaborada pela Biblioteca Universitria da Unisul
Sumrio
Apresentao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Palavras do professor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 UNIDADE 1 - Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 UNIDADE 2 - Estruturando a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 UNIDADE 3 - Executando o projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 UNIDADE 4 - Finalizando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Para concluir o estudo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Sobre o professor conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Respostas e comentrios das atividades de autoavaliao . . . . . . . . . . . . . 165 Biblioteca Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Apresentao
Este livro didtico corresponde disciplina Gesto de Projetos e de Equipes II. O material foi elaborado visando a uma aprendizagem autnoma e aborda contedos especialmente selecionados e relacionados sua rea de formao. Ao adotar uma linguagem didtica e dialgica, objetivamos facilitar seu estudo a distncia, proporcionando condies favorveis s mltiplas interaes e a um aprendizado contextualizado e eficaz. Lembre-se que sua caminhada, nesta disciplina, ser acompanhada e monitorada constantemente pelo Sistema Tutorial da UnisulVirtual, por isso a distncia fica caracterizada somente na modalidade de ensino que voc optou para sua formao, pois na relao de aprendizagem professores e instituio estaro sempre conectados com voc. Ento, sempre que sentir necessidade entre em contato; voc tem disposio diversas ferramentas e canais de acesso tais como: telefone, e-mail e o Espao Unisul Virtual de Aprendizagem, que o canal mais recomendado, pois tudo o que for enviado e recebido fica registrado para seu maior controle e comodidade. Nossa equipe tcnica e pedaggica ter o maior prazer em lhe atender, pois sua aprendizagem o nosso principal objetivo.
Bom estudo e sucesso! Equipe UnisulVirtual.
Palavras do professor
Os livros dedicados gesto de projetos dividem-se basicamente em dois tipos: aqueles que listam uma srie de tcnicas prticas de planejamento, e aqueles que discutem teoricamente a disciplina de gesto. Os do primeiro tipo acreditam que simplesmente aplicando alguma metodologia pr-concebida de gesto ser possvel gerenciar um projeto com eficincia e eficcia. Baseiamse em mtodos e tcnicas - uma srie imensa de planilhas e relatrios - e mais recentemente dedicam-se a explicar e implantar ferramentas computacionais. Os do segundo tipo analisam a gesto como uma disciplina capaz de apoiar e beneficiar aqueles que se dedicam ao planejamento e ao desenvolvimento de projetos, mas carecem de uma real experincia em diferentes tipos de projetos, os quais envolvem sempre um agente essencialmente subjetivo: o ser humano. Este livro didtico explora esse assunto de uma outra forma. Aqui o foco ser essencialmente na aprendizagem e na discusso que gera um tipo de conhecimento que pode e deve ser til aos que se interessam pelo tema. Nesse sentido, no um livro puramente acadmico, com unidades e sees que apresentam teorias e exemplos desvinculados da realidade e de uma viso aplicada aos negcios e aos trabalhos prticos. Sem dvida, muitas questes aqui colocadas vieram de pesquisas e anlises acadmicas, porm esto sempre focadas em aplicaes.
Plano de estudo
O plano de estudos visa a orient-lo no desenvolvimento da disciplina. Ele possui elementos que o ajudaro a conhecer o contexto da disciplina e a organizar o seu tempo de estudos. O processo de ensino e aprendizagem na UnisulVirtual leva em conta instrumentos que se articulam e se complementam, portanto, a construo de competncias se d sobre a articulao de metodologias e por meio das diversas formas de ao/mediao. So elementos desse processo:
o livro didtico; o Espao UnisulVirtual de Aprendizagem (EVA); as atividades de avaliao (a distncia, presenciais e de autoavaliao); o Sistema Tutorial.
Ementa
Criao de plano com fl uxo de trabalho e sincronismo de equipe e recursos. Controle da qualidade em projetos para Web. Encerramento de projetos. Verifi cao da satisfao do cliente. Feedback.
Objetivos
Geral:
Desenvolver conhecimentos das melhores prticas e mtodos atualmente utilizados na gesto de projetos e das equipes envolvidas.
Especficos:

Apresentar os conceitos bsicos da rea de gesto de projetos. Fornecer subsdios para a avaliao de riscos de um projeto, com nfase nos projetos de base tecnolgica. Apresentar tcnicas de planejamento, execuo e controle de projetos, formao de equipes e seu gerenciamento de reunies. Descrever um modelo para gesto de projetos. Verificao dos softwares disponveis para auxlio no gerenciamento de projetos. Utilizao de software livre para gesto de projetos.
Carga Horria
A carga horria total da disciplina 60 horas-aula.
Contedo programtico/objetivos
Veja, a seguir, as unidades que compem o livro didtico desta disciplina e os seus respectivos objetivos. Estes se referem aos resultados que voc dever alcanar ao final de uma etapa de estudo. Os objetivos de cada unidade definem o conjunto de conhecimentos que voc dever possuir para o desenvolvimento de habilidades e competncias necessrias sua formao.
12
Unidades de estudo: 4
Unidade 1 Planejamento
As principais metodologias de planejamento de projeto so apresentadas nesta unidade, bem como tcnicas para sua aplicao em problemas prticos. Mtodos como Grfico de Gantt, PERT/ CPM, estimativa de recursos e cronogramas fsico-financeiros so desenvolvidos e aplicados em projetos tpicos.
Unidade 2 Estruturando a equipe

A formao da equipe, descrio dos principais perfis e organizao dos recursos humanos para o trabalho em projetos o tema desta unidade. Problemas como terceirizao, treinamento e mtodos para dividir tarefas so estudados e as teorias sobre o assunto so apresentadas.
Unidade 3 Executando o projeto

Unidade que rene os temas relacionados ao dia a dia dos projetos, desde o comportamento da liderana, tomada de decises, estruturao de reunies, gesto de conflitos e aspectos diversos como motivao da equipe e gesto da qualidade. Como projetos so atividades com prazo definido, so descritos passos intermedirios com simulao, testes e validao como ferramentas de ajuste e melhoria contnua dos projetos e dos seus resultados.
Unidade 4 Finalizando o projeto

Unidade que relata as atividades de encerramento do projeto, os planos de contingncia em caso de problemas, e aspectos relativos s demandas originais do cliente, verificando ento o sucesso (ou fracasso) da empreitada. Mostra ainda que lies sero aprendidas no decorrer do trabalho, e que sem dvida idias para novos projetos devero surgir.
13
Agenda de atividades/Cronograma
Verifique com ateno o EVA, organize-se para acessar periodicamente a sala da disciplina. O sucesso nos seus estudos depende da priorizao do tempo para a leitura, da realizao de anlises e snteses do contedo e da interao com os seus colegas e professor. No perca os prazos das atividades. Registre no espao a seguir as datas com base no cronograma da disciplina disponibilizado no EVA. Use o quadro para agendar e programar as atividades relativas ao desenvolvimento da disciplina.
Atividades obrigatrias
Demais atividades (registro pessoal)
14
UNIDADE 1
Planejamento
Objetivos de aprendizagem
Compreender os diversos modelos que representam o desenvolvimento de projetos, especialmente aqueles voltados para as inovaes tecnolgicas. Distinguir duas tcnicas de planejamento de projetos, uma que j tem um sculo desde sua criao e que extremamente popular e til, e outra que surgiu h mais ou menos 50 anos e que veio complementar diversas lacunas e desvantagens da primeira. Analisar essas diferentes tcnicas e mtodos de planejamento, com exerccios e exemplos prticos. Incorporar o planejamento, por meio de ferramentas, s atividades iniciais de um projeto. Verificar que as estimativas de recursos, custos e prazos so mais coerentes e consistentes quando embasadas em um planejamento detalhado.
Sees de estudo
Seo 1 Modelagem do fluxo de atividades Seo 2 Metodologias de planejamento Grfico de Gantt Seo 3 Metodologias de planejamento PERT/CPM Seo 4 Estimativa de recursos Seo 5 Estimativa de custos
Para incio de estudo

Esta unidade fundamental para dar o primeiro passo prtico na execuo de um projeto. A histria dos projetos na humanidade comeou com obras marcantes, mas que no contavam com um planejamento detalhado. Com a Revoluo Industrial muitas coisas mudaram, especialmente a forma de se produzir, e o tempo de produo at chegar ao mercado. Atualmente, para que um projeto possa ser planejado e conduzido durante a sua execuo, necessrio ter uma viso abrangente e estratgica, com um comportamento muito mais de liderana do que de simples controle. Mas controle necessrio. Nesta unidade voc ver algumas ferramentas muito teis para apoio ao planejamento, para a estimativa de recursos e de custos, para a definio de prazos e para a administrao dos riscos. Sem essas ferramentas os projetos seriam praticamente impossveis de gerenciar. Ser apresentado o Grfico de Gantt, que provavelmente voc j conhece. Ultimamente esse tipo de grfico sofreu alteraes e foi incorporado pelos softwares de gesto de projetos, sendo provavelmente a tela mais popular de todos eles (quando no a nica). Junto ao Grfico de Gantt voc aprender, tambm, como construir diagramas que mostram o caminho crtico de um projeto, ou seja, aquela seqncia de atividades que dependem umas das outras, e que definem ento um prazo e uma conduo crtica do projeto. Qualquer alterao nesse caminho vai afetar todo o projeto (e prazo, em especial). Tais ferramentas so teis para o controle do projeto, mas tambm permitem toda espcie de estimativas, sejam de recursos necessrios ao projeto, sejam de custos ou de prazos. O estudo de como realizar essas estimativas o objeto da concluso desta unidade. Bons estudos!!
16
Seo 1 Modelagem do fluxo de atividades

Voc j estudou que preciso ter uma viso geral do projeto que permita avaliar sua viabilidade, os possveis riscos, as necessidades gerais para que seja desenvolvido e para que se obtenham os resultados esperados. Certamente durante esse processo de viso geral e estratgica, no possvel detalhar todos os elementos do projeto, mas suficiente para decidir sobre a sua viabilidade e ento dar um passo alm: partir para o desenvolvimento do projeto. A partir dessa idia geral ser necessrio agora comear a detalhar o projeto, e o primeiro elemento a sua modelagem e a definio de um fluxo de atividades.
O modelo de um objeto uma representao, uma simplificao desse objeto de forma que possamos entend-lo de forma abrangente.
- Para ficar mais claro, veja o exemplo a seguir:

A maquete de um prdio um modelo de como ser o prdio ao ficar pronto. Ele mostra as partes do edifcio, seu aspecto geral, numa proporo muito boa para que voc possa entend-lo antes de ficar pronto. Ele no o prdio, apenas o modelo do prdio. No entanto, voc pode comear a detalhar mais e mais o modelo desse prdio, como por exemplo fazendo os projetos de instalaes eltricas e de telecomunicaes dele. Os desenhos dessas instalaes so representaes, bem detalhadas, de como sero tais instalaes, porm continuam sendo modelos pois no so as instalaes em si.
Os modelos so usados para facilitar a viso do futuro objeto, e ao mesmo tempo podem ser usados para ajudar a construir tal objeto, ou seja, o modelo pode ajudar a realizar o projeto e chegar ao resultado final esperado.
17
H um modelo muito interessante de representao da realidade, que todos ns usamos, mas no nos damos conta: a nossa lngua. As palavras, e a forma como elas se relacionam, permitem que ns possamos representar o real e comunicar para outras pessoas as nossas idias. Estas, por sua vez, precisam compreender esse modelo de representao para decodificar o que falamos, criar as imagens mentais (compilar), e responder novamente usando esse modelo comum. Pessoas que falam lnguas diferentes no conseguem se comunicar, pois no dominam a mesma modelagem. Nesses casos usam outras formas de representao, como a mmica, por exemplo, que, no entanto, muito mais limitada. Na comunicao entre o ser humano e a mquina preciso tambm uma linguagem.
Modelar, dessa forma, significa representar um sistema, ou parte dele, em forma fsica (a maquete, por exemplo) ou simblica (desenho do projeto eltrico, por exemplo), de tal maneira que se possa predizer ou descrever seu comportamento. Assim, o modelo de representao uma idealizao do sistema fsico, e ele nos auxilia na anlise e na soluo dos problemas. Sem os modelos no haveria a civilizao como a conhecemos.
Algumas das principais caractersticas dos modelos, e que fazem com que tenham grande valor, so:
usando um modelo no preciso trabalhar diretamente com o sistema fsico real, ou seja, no necessrio pegar a ma para querer dizer ma, basta pronunciar a palavra, ou ainda, no preciso construir o prdio inteiro para mostr-lo, basta desenhar uma fachada ou construir uma maquete; prtico e seguro trabalhar com modelos, pois caso as coisas no se afigurem to boas, voc pode abandonar tudo no comeo; graus de preciso dependero do aprimoramento do modelo, ou seja, conforme voc queira ter maior preciso de como ser o projeto no final, voc pode ir aprimorando paulatinamente o prprio modelo;
18
reduo de tempo na anlise, pois no necessrio ter o projeto pronto para fazer as primeiras simulaes; o modelo abstrai o problema para o campo de domnio daquele que o analisa, quer dizer, ao modelar um problema, cada um o faz no campo que tem domnio; se um desenhista, faz o desenho, se um escultor, cria a maquete, se um matemtico, coloca na forma de equaes, se um escritor, coloca na forma de uma fico ou poema, e assim por diante; os modelos no so nicos, ou seja, possvel diversos tipos diferentes de modelo para uma mesma coisa; no caso do prdio, pode ser representado por meio de uma maquete de madeira e papelo, ou ento por uma maquete eletrnica, ou pelo desenho artstico da fachada etc., sendo que todas tero o seu valor; como o modelo apenas uma representao, uma reduo do real, ele contm erros, os quais so inerentes ao seu carter de reduo.
Com essas caractersticas voc pode perceber que os modelos tm inmeras utilidades, no s para planejar a gesto de projetos, mas para planejar o prprio projeto. Basicamente pode-se considerar como utilidades dos modelos de representao:
modelos ajudam a PENSAR modelos so instrumentos que permitem visualizar e pensar acerca de um sistema e do seu comportamento; boa parte dos problemas e das solues de um projeto voc consegue perceber e imaginar sobre esse instrumento; permitem COMUNICAR com um modelo bem representado possvel transmitir informaes sobre o projeto, e isto importantssimo na gesto da equipe; possvel PREVER com um modelo apropriado possvel simular o comportamento do sistema, e com isso prever ser provvel comportamento;
19
permitem CONTROLAR com um modelo voc tem condies de criar sistemas que simulam comportamento, e dessa forma possvel criar critrios de controle, inicialmente usados no modelo e depois associados ao sistema fsico real; ajudam a ENSINAR assim como os modelos ajudam a comunicar, passam, assim, a ser importante instrumento de auxlio na educao e no treinamento, pois representam o objeto numa escala menor e de testes.
Conforme Bazzo (1997), os modelos para apoio a projetos de engenharia e tecnologia podem ser divididos em quatro tipos: Modelo Icnico o modelo que representa com alto grau de semelhana o sistema fsico, seja em duas dimenses (como no caso das fotos e mapas, como na figura 1.1) ou em trs dimenses (maquetes, esculturas, prottipos).
Figura 1.1 Exemplo de representao icnica mapa urbano Fonte: Google Maps - London (2010).
Modelo Diagramtico tem pouca semelhana com o sistema fsico, e apresentado por meio de smbolos, linhas, diagramas. Facilita a compreenso do funcionamento de uma mquina, um processo ou sistema, sem dispersar a ateno em detalhes de outra ordem, e um bom exemplo disso so os fluxogramas que usamos nas empresas, mostrando como se d o fluxo de processos, ou ento o organograma dessa mesma empresa, que mostra como se distribuem os cargos e departamentos. No
20
entanto, por ser uma representao um pouco mais especializada, serve para aqueles que conhecem a conveno usada no diagrama (veja exemplo na figura 1.2).
Figura 1.2 Exemplo de representao diagramtica diagrama de atividades da UML Linguagem de Modelagem Unificada Fonte: Gooch (2000).
Modelo Matemtico um modelo simblico abstrato, que est cada vez mais associado aos problemas de tecnologia avanada, sendo o de aplicao mais importante na engenharia. Os modelos matemticos so os mais poderosos instrumentos de representao, e tm permitido modelos computacionais sofisticados, porm so altamente especializados e exigem conhecimento avanado dos usurios.
21
Modelo Grfico o modelo que representa o comportamento de fenmenos por meio de curvas, grficos, facilitando a sua verificao. H diversos tipos de grficos, como por exemplo os de linhas, com barras, em forma de pizza, etc. (veja por exemplo aqueles disponveis no Microsoft Excel), sendo que o traado se d a partir de um conjunto de valores previamente definidos pelo usurio.
Para desenvolver um projeto voc precisar, antes de tudo, criar um modelo de como se dar o desenvolvimento desse projeto.
Projetos muito pequenos no precisam de um modelo, assim como a construo da casinha do cachorro no precisa certamente de uma planta dessa casinha. Se, no entanto, ela tiver algum grau de complexidade maior, melhor desenhar. Tendo o modelo em mos voc poder, dessa maneira, utilizar mtodos de planejamento (que voc ver na prxima seo) e criar um detalhamento de como se desenvolver o projeto. Na figura 1.3 voc pode perceber como se d o fluxo do conhecimento durante o desenvolvimento de um projeto tecnolgico. As diferenas entre os trs tipos de fluxos definem prazos diferentes de entrega, mas podem depender de como se deu a contratao e quais os riscos aceitveis. A percepo clara de como se dar o desenvolvimento do projeto permitir uma boa diviso e detalhamento das atividades.

Figura 1.3 Trs modelos de fluxo de conhecimento no desenvolvimento de projetos tecnolgicos Fonte: Elaborao do autor (2006).
22
Na etapa inicial das idias, chamada de pesquisa, so adquiridos os conhecimentos e informaes necessrias para dar incio ao projeto.
Veja como se d o fluxo no modelo seqencial, cujo diagrama est apresentado na figura 1.4. No h passagem para a prxima etapa, chamada de desenvolvimento, sem que todas as atividades da primeira etapa tenham sido concludas. Na etapa do desenvolvimento ocorrem as primeiras implementaes do projeto como, por exemplo, a escrita das primeiras verses de um software, a criao do prottipo, os testes iniciais, as simulaes, etc. No modelo seqencial a passagem para a etapa de engenharia s ocorrer quando a etapa anterior estiver concluda. Na engenharia se dar a implantao do projeto, a criao de um piloto e sua colocao efetiva no mercado como, por exemplo, na finalizao e entrega de um novo produto, o que inclui o incio do funcionamento e suporte, ou a colocao em linha de fabricao de uma nova mquina. No modelo seqencial o conhecimento adquirido em cada etapa no influencia a etapa anterior, e novas decises so tomadas apenas com os conhecimentos j obtidos. Esse modelo de desenvolvimento de projetos conservador, e toma maior tempo de realizao total, pois nenhuma atividade segue seu andamento se a atividade anterior no tiver sido totalmente concluda.
A construo civil, por exemplo, usa esse modelo seqencial como padro e isso faz sentido, pois o tipo de projeto pressupe fases bem divididas e com requisitos de precedncia.
Precedncia: em projetos as atividades podem ter relaes de dependncia com outras atividades anteriores, as quais so prrequisitos para o seu incio.
23
Figura 1.4 Modelo seqencial de desenvolvimento de projeto, conforme Senz (2001) Fonte: Elaborao do autor (2006).
Se, no entanto, as etapas sofrerem um certo grau de mesclagem, de tal forma que a etapa seguinte tenha incio enquanto a etapa anterior ainda est na fase de encerramento, chamamos tal modelo de seqencial com solapamento. Esse no ainda um modelo radical de desenvolvimento de projetos, pois a ordem das etapas est bem definida, mas o fato de uma etapa j ter incio enquanto a outra ainda se desenrola, faz com que conhecimentos e problemas da etapa seguinte interfiram positivamente na etapa anterior, obrigando revises dinmicas do processo. Como voc pode ver no desenho da figura 1.5, os conhecimentos adquiridos em uma etapa podem interferir na soluo de problemas ainda da etapa anterior. Com isso h ganho de tempo no projeto, pois algumas decises tomadas faro com que determinado problema ou risco futuro sejam controlados ou mesmo eliminados.
Projetos de equipamentos ou softwares so exemplos para esse tipo de modelagem.
24
Figura 1.5 Diagrama de modelo seqencial com solapamento, inspirado em Senz (2001) Fonte: Elaborao do autor (2006).
A situao radical de desenvolvimento de projetos aquela onde as diferentes etapas esto totalmente entremeadas. Certamente esse o caso onde possvel obter o resultado do projeto no menor prazo possvel, mas isso exige um enorme controle e gesto detalhada. O que no simples! O diagrama da figura 1.6 mostra essa situao, chamada de modelo com solapamento, e percebe-se que os conhecimentos e problemas de uma etapa interferem nas solues de todas as outras etapas, sejam anteriores ou posteriores. Controlar tais interferncias, para que sejam proveitosas para o projeto, passa a ser um dos grandes problemas desse modelo. Problemas relativos montagem e engenheirizao de determinado produto podem gerar conhecimentos que tero grande valor l na etapa das idias iniciais, pois com tais conhecimentos seria possvel j imaginar solues que vo alterar o formato final do produto. O fluxo de tais informaes precisa ento ser contnuo, e esse tipo de modelo pressupe nfase nos ambientes de comunicao e integrao de equipes.
25
Figura 1.6 Soluo radical: modelo com solapamento (inspirado em Senz, 2001) Fonte: Elaborao do autor (2006).
Nesta seo voc conheceu a modelagem do fluxo das atividades de um projeto, e como podem ser os diversos modelos de representao, sejam do fluxo ou mesmo do projeto como um todo. A modelagem permite uma viso estratgica do projeto. A partir dessa viso estratgica possvel dar incio sua operacionalizao e, para isso, voc pode contar com mtodos e ferramentas, assunto da prxima seo.
Seo 2 Metodologias de planejamento Grfico de Gantt

Caso seja importante representar todo o projeto por um modelo estratgico, geral, para fazermos o seu planejamento necessrio descer nos detalhes, ou seja, decompor todo o trabalho em suas menores partes.
26
Essa decomposio significa dividir em tarefas cada vez menores as diversas atividades do projeto. H duas maneiras de se decompor um projeto: na forma de um organograma ou rvore de decomposio ou na forma de tabelas (VALERIANO, 1998). Tanto a rvore quanto a tabela trazem as mesmas informaes, sendo que a diferena est na forma de apresentao. Veja o quadro 1.1 e a figura 1.7 a seguir. Ambos nos mostram uma diviso de tarefas do projeto fictcio denominado Exemplo. No quadro 1.1 voc pode ver o quadro com o rascunho da diviso de etapas e com as diversas tarefas que sero necessrias para compor cada uma delas. Esse quadro permite que se anotem as diversas tarefas, e tal ferramenta, muito simples, permite que se escrevam todas as tarefas componentes.
Projeto EXEMPLO Etapa 1 Definies Compra materiais Organiza equipe Documentao ..... Etapa 2 Desenho Montagem Documentao ..... Etapa 3 Teste 1 Teste 2 Documentao Encerramento ..... Quadro 1.1 Diviso de tarefas de um projeto Exemplo Fonte: Elaborao do autor (2006).
A rvore da figura 1.7 representa as mesmas tarefas e etapas, porm numa representao espacial, o que para algumas pessoas facilita a compreenso dos diversos componentes. uma questo de escolha.
27
Figura 1.7 O mesmo projeto da figura 1.7 em uma diviso por rvore de decomposio Fonte: Elaborao do autor (2006).
Com esse tipo de diviso de tarefas voc pode imaginar e localizar todos os componentes do projeto. A partir dessa diviso, voc poder iniciar a construo do planejamento para execuo e gesto do projeto. Agora voc vai estudar trs mtodos para planejar o desenvolvimento do projeto:
Grfico de Gantt; Diagramas PERT e Mtodo do Caminho Crtico CPM.
So mtodos que vm sendo desenvolvidos nos ltimos cem anos, especialmente aps a Segunda Guerra Mundial, tendo tido grande nfase nos anos recentes com os projetos que envolvem desenvolvimento de software e sistemas de alta tecnologia.
28
Grfico de Gantt
O grfico de Gantt tambm chamado de grfico de barras. Foi concebido pelo engenheiro norte-americano Henry L. Gantt (1861-1919) (Hinojosa, 2003) para tentar resolver o problema da programao de diferentes atividades industriais. Essas atividades foram distribudas no calendrio 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 durao da atividade que tal barra representaria.
Ou seja, o incio da barra marcaria a data de comeo da atividade e o final da barra seu trmino, sendo que a barra se estende por todo o perodo compreendido entre as duas datas. A figura 1.8 mostra um exemplo de Grfico de Gantt desenhado em planilha (neste caso com o auxlio do MS Excel). Voc pode ver que o projeto se estende do dia 14/maro at 15/abril, e constitudo de quatro etapas, havendo dois projetistas neste trabalho. As barras pretas mostram os prazos previstos para a execuo de cada Etapa/Tarefa.
Figura 1.8 Exemplo de Grfico de Gantt Fonte: Elaborao do autor (2006).
Este tipo de grfico permite desenhar uma barra com a durao prevista, e junto a ela outra barra que vai sendo preenchida conforme as tarefas vo sendo cumpridas, de tal forma que possvel acompanhar o andamento do projeto e a proporo de atraso ou quanto se est adiantado em relao ao previsto.
29
Na figura 1.8 voc pode ver a barra cinza da Etapa 1 mostrando o andamento do projeto at aquele momento. Se o grfico estiver nessa posio no dia 21 de maro, ento voc pode perceber que o projeto est cumprindo seu prazo. Nesse exemplo, no eixo horizontal h um calendrio com a escala de tempo pertinente e mais adequada ao projeto (dias, semanas, meses etc). E, no eixo vertical as atividades que sero executadas, sendo que a barra de durao 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 visualizao que se requer. Projetos com equipes muito grandes costumam imprimir tais grficos em painis grandes, para que num nico relance voc possa ver as etapas, como vai indo o dia-a-dia do projeto, os principais responsveis, datas de incio e fim etc. O grfico que Henry Gantt criou tornou-se imensamente popular e passou a ser utilizado, sem grandes modificaes, no gerenciamento de todos os tipos de projetos em todo o mundo. Uma das desvantagens apontadas era que o grfico no interligava uma atividade outra, ou seja, no deixava clara a interdependncia entre as diferentes atividades. Verses recentes desse tipo de grfico passaram, assim, a utilizar setas de ligao entre as diferentes barras, para mostrar esse tipo de dependncia, especialmente a partir do uso de softwares como o MS Project. Porm, no necessrio um software para se construir o Grfico de Gantt, e justamente por isso to popular e essa uma das suas grandes vantagens: o traado 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 modificaes no planejamento acontecem, o grfico comea a se tornar confuso. A replanificao exige que se faa um novo grfico.
30
Tambm outra desvantagem o fato de que o grfico de Gantt no apresenta custos das etapas, e dificilmente se adapta a projetos muito complexos com mltiplas tarefas simultneas. Nesses casos se usam outros mtodos, como PERT e CPM, que sero apresentados adiante.
- Para que voc compreenda melhor, observe o exemplo a seguir: Voc agora vai conhecer um exemplo simples para aplicao do Grfico de Gantt. Voc ir construir uma rea de lazer com 30 metros quadrados, churrasqueira, pia e banheiro (e no final da disciplina a gente faz uma festa para comemorar, o que acham?). Este no um exemplo de projeto de software, mas suficientemente comum para que voc explore todas as questes relacionadas ao gerenciamento de um projeto que envolve equipe. A idia partiu do cliente, que pretende fazer uma comemorao, e deu a voc o prazo de oito semanas para entregar a obra pronta, sendo que todos os materiais para a obra so fornecidos por ele. Tudo comea pela decomposio do projeto em tarefas e, para isso, voc deve utilizar a decomposio em tabela, como aquela mostrada no exemplo do quadro 1.1. Que tal dar o nome a este novo projeto de Churrasqueira? Cada gestor de projeto poderia dividir as tarefas de forma diferente, pois no h uma regra especfica para isso, a no ser o conhecimento e a experincia particular de cada um. Proponho ento a seguinte diviso:
31
Projeto CHURRASQUEIRA Etapa 1 Preparao do terreno Limpeza do terreno Medies e marcaes Escavaes Etapa 2 Fundaes Montagem das madeiras de caixaria Montagem das ferragens da fundao Concretagem Etapa 3 Alvenaria Construo das paredes Montagem da churrasqueira Rebocos Etapa 4 Telhado Montagem da estrutura de madeira Colocao de Telhas Etapa 5 Piso Concretagem do piso Assentamento da Cermica do piso Etapa 6 Carpintaria Colocao de janelas Colocao de portas Etapa 7 Instalao Hidrulica Tubulaes de gua Colocao da caixa dgua Montagem de torneiras, descargas, acessrios Esgoto Etapa 8 Instalao Eltrica Instalao das Tubulaes Passagem dos cabos alimentadores Montagem das tomadas, luminrias e quadros Etapa 9 Pinturas e acabamento Pintura externa Pintura interna Limpeza final e entrega da obra
Quadro 1.2 Tabela com diviso de tarefas do projeto Churrasqueira Fonte: Elaborao do autor (2006).
32
Ao analisar a diviso acima, voc ir perceber que o projeto no to simples quanto podia parecer primeira vista, pois h inmeras tarefas, as quais ainda poderiam ser mais detalhadas. Por ser um exemplo, suficiente o que est definido acima. Considerando essas nove etapas, voc pode construir um grfico de Gantt simples e til para este projeto. Voc pode comear com uma planilha dividida em nove barras horizontais, onde voc deve anotar as etapas, e oito colunas onde voc deve anotar as semanas, como o da figura 1.9 a seguir. Neste desenho inclu algumas divises para facilitar o trabalho, tais como a diviso das colunas das semanas nos seus sete dias, com marcao do sbado (S) e do domingo (D), e nas barras horizontais h uma diviso que marca o prazo previsto (Prev) e outra diviso para depois se anotar o realizado (Real), conforme o projeto for andando. Alm disso, no espao reservado para escrever o nome das etapas, h tambm um questionamento sobre quem ir realizar aquela tarefa, ou seja, quem o responsvel por aquela tarefa especfica. Isso muito til para poder distribuir as responsabilidades, e da mesma forma til para aquele que vai trabalhar nela, pois pode compreender sua funo no conjunto das atividades bem como o impacto de seu prazo sobre o restante.
Figura 1.9 Planilha para Grfico de Gantt do projeto Churrasqueira Fonte: Elaborao do autor (2006).
33
O prazo de dois meses parece ser bastante enxuto, ento preciso ser cuidadoso na distribuio dos prazos para que se tenha sucesso. Veja que neste projeto o sucesso significa acabar antes do dia da comemorao, no sendo admitida outra possibilidade. A equipe que trabalhar neste projeto ser constituda, alm do gestor (voc), tambm de um mestre de obras, um pedreiro, um servente, um carpinteiro, um eletricista, um encanador e um pintor. So oito pessoas, sendo que alguns estaro presentes apenas em algumas etapas da obra. Fazendo uma reunio preliminar com todos os membros da equipe, so estimados os seguintes prazos de execuo para cada etapa:
Projeto CHURRASQUEIRA Etapa 1 Preparao do terreno Etapa 2 Fundaes e Estrutura Etapa 3 Alvenaria Etapa 4 Telhado Etapa 5 Piso Etapa 6 Carpintaria Etapa 7 Instalao Hidrulica Etapa 8 Instalao Eltrica Etapa 9 Pinturas e acabamento Prazos estimados pela equipe 2 dias 1 semana 4 semanas 1 semana 2 semanas 1 semana 1 semana 1 semana 2 semanas Dependncia Etapa 1 Etapa 2 Etapa 2 Etapa 4 Etapa 4 Etapa 4 Etapas 2 e 4
Quadro 1.3 Estimando prazos para as etapas do projeto Churrasqueira Fonte: Elaborao do autor (2006).
Se voc somar essa estimativa de prazos, voc e sua equipe chegaro a 13 semanas e 3 dias, o que supera a data final definida. Porm, algumas atividades podem ser feitas em paralelo, e nesse sentido que voc pode traar o primeiro esboo de grfico de Gantt, que est apresentado na figura 1.10.
34
Figura 1.10 Grfico de Gantt do projeto Churrasqueira primeiro esboo Fonte: Elaborao do autor (2006).
Algo que voc pode notar neste grfico que, para adequar o projeto ao prazo total, necessrio colocar algumas atividades em paralelo, e isso muito natural. O servio do telhado comeou mais ou menos no meio das atividades de alvenaria, e o piso est dividido em duas fases, sendo que a segunda fase aparece apenas aps o encerramento de todo o trabalho da alvenaria. Da mesma forma as instalaes hidrulicas e eltricas esto divididas em duas etapas.
Este projeto simples, ento no difcil perceber essas possibilidades de trabalho em paralelo para otimizar o tempo e a equipe. Porm, se algum que no conhece o projeto der uma olhada neste grfico, no entender porque h uma interrupo na instalao hidrulica em determinado ponto, e nem porque ela comea na quinta semana e no apenas na stima, por exemplo.
Uma diviso mais detalhada facilitaria essa viso externa, e certamente tambm facilitaria a prpria gesto do projeto. Uma nova opo de grfico de Gantt deste mesmo projeto est apresentada na figura 1.11.
35
Figura 1.11 Grfico de Gantt do projeto Churrasqueira (assumimos a sequncia de atividades definidas pelo mestre de obras) Fonte: Elaborao do autor (2006).
Este grfico detalha melhor algumas fases, que permite que se veja a dependncia entre um servio e outro. A dependncia no est explcita no grfico, porm algum com mais experincia perceber que o servio de telhados depende da finalizao da construo das paredes, e aps o telhado ficar pronto sero colocadas as tubulaes eltricas e hidrulicas. A concretagem do piso poder ser feita tambm aps a concluso do telhado, e voc comear a pintura externa aps a colocao das janelas e portas. Depois da concluso do piso, sero feitos os acabamentos das instalaes eltricas, passando todos os cabos e instalando tomadas e luminrias, bem como instalando acessrios da parte hidrulica. Por fim, ser feita a pintura externa e limpeza geral da obra, e afinal haver uma festa no domingo! Bem, este exemplo obviamente uma suposio de servio, mas ele espelha exatamente o que ocorre em todos os projetos. comum que se tenham muitas dvidas quando o servio est por comear e, assim, necessrio fazer alguns desenhos iniciais e avaliar se ser til a diviso que voc pensou inicialmente. Caso no seja, ou caso voc perceba que possvel detalhar um pouco mais, ento importante faz-lo.
36
No grfico anterior foi tambm preenchido o nome da pessoa da equipe responsvel por cada etapa. Desta forma possvel definir as atividades de cada um, e assim o trabalho individual ser otimizado.
O eletricista, por exemplo, poder participar de vrios outros projetos, bastando para isso preparar sua agenda conforme a distribuio de tarefas em cada projeto.
Para relembrar alguns tpicos estudados nas unidades e sees anteriores, analise um pouco mais esse exemplo da churrasqueira.
Do ponto de vista do modelo geral do projeto, pode-se dizer que foi considerado o modelo seqencial de trabalho, ou teria sido o modelo seqencial com solapamento?
Se voc voltar figura 1.4 perceber que no modelo seqencial existe a passagem de uma etapa do trabalho para outra sem alternativa de retorno. J na figura 1.5 se percebe que as atividades de uma etapa podem interferir numa etapa anterior, de tal forma que as duas ocorrem em paralelo (pelo menos em parte), sendo que o que acontece em uma atividade faz com que algumas coisas possam ser aprendidas e interfiram na maneira de se realizar algo na outra atividade. Este o caso das atividades de instalao hidrulica e eltrica, que acontecem quando ainda se est realizando a alvenaria. Certamente algumas solues pensadas em quaisquer dessas atividades podem interferir positivamente nas demais, como por exemplo:
combinar passagem de tubulaes pelos mesmos caminhos, evitando desperdcios; nvel de caimento para as guas; existncia de espaos de reserva (como cantos e reentrncias na parede); e muitos outros.
37
Por essa anlise, conclui-se que o modelo de desenvolvimento do projeto o seqencial com solapamento, que j tradicional na construo civil.
E quanto aos prazos, houve uma estimativa de prazos? Houve uma estimativa de recursos? Estimativa de custos e de benefcios?
Essas questes foram debatidas na unidade anterior, onde frisei a necessidade de se fazer tais levantamentos e anlises para permitir, s ento, o desenvolvimento do projeto. Considere esse projeto como bastante simples, que partiu de uma contratao onde o cliente j definiu algumas dessas questes. Veja:
Prazo o ponto de partida do projeto foi justamente um resultado desejado num determinado prazo: a comemorao com churrasco. Essa data definiu o prazo limite, para o qual tivemos de nos adequar. Benefcios se prestarmos ateno na resposta anterior j se percebe claramente o benefcio: a churrasqueira do cliente, onde ele poder realizar suas festas; nesse caso no h um produto a ser lanado no mercado, onde o valor ser medido pelo retorno financeiro, mas sim haver valor pelo retorno em qualidade de vida. Recursos no tivemos problemas com recursos materiais, pois o contratante previu o seu fornecimento; precisamos ento nos preocupar com a equipe (nossos recursos humanos). Custos com base na quantidade de trabalho envolvida, no nmero de horas e nas especialidades de pessoal, um oramento foi entregue ao cliente, que neste caso aceitou tais custos e teve de fazer os aportes financeiros semanalmente ( a prtica na construo civil).
E quanto aos riscos? Voc consegue prev-los?
38
Como voc pode ver na figura 1.10, o prazo estimado em cada atividade faz com que voc tenha pouca folga no projeto, caso algum problema acontea. E eles podem acontecer! Considere que ocorra um perodo de chuvas justamente durante as trs primeiras atividades: preparao do terreno, fundaes e alvenaria. Certamente haver atrasos nessas etapas, e isso poder afetar todo o projeto, pois como tais atividades esto encadeadas e delas dependem todas as restantes, dizemos que tais atividades perfazem um caminho crtico. O mtodo do caminho crtico ser discutido mais adiante. O gestor do projeto ter que pensar em alternativas. Outros riscos so a falta de pessoal por motivos alheios (doenas, mudanas), problemas financeiros do contratante, falta de algum material no mercado etc.
Para todos eles devemos pensar em alternativas, pois o sucesso desse projeto est vinculado a uma coisa: cumprir o prazo para a festa.
Volte agora ao grfico da figura 1.10 para analisar outra caracterstica desse tipo de diagrama. Apesar de voc j saber que uma atividade deve comear apenas quando a outra terminar (como por exemplo o telhado somente aps as paredes e estrutura estarem montadas, nesse caso), isso no est evidente no desenho. A pessoa que no conhece o projeto no perceber esse tipo de dependncia. Foi preciso avanar na construo desse tipo de diagramas e introduzir relaes de dependncia, o que se d em todos os modernos softwares de gerao de grficos de Gantt. Voc pode criar dependncias de quatro tipos entre atividades:
Dependncia fim-incio, quando o incio de uma Atividade B s possvel aps o fim da Atividade A. Dependncia fim-fim, quando o final da Atividade B deve, necessariamente, coincidir com o fim da Atividade A.
39
Dependncia incio-incio, quando o incio da Atividade B deve, necessariamente, coincidir com o incio da Atividade A. Dependncia fim-incio com folga, quando o incio de uma Atividade B s possvel aps o fim da Atividade A, porm h um tempo de folga para o incio da Atividade B.
A representao grfica dessas relaes de dependncias feita com setas interligando as extremidades das atividades, como voc pode ver nas figuras seguintes:
Figura 1.12 Dependncia Fim-Incio num Grfico de Gantt, onde B depende de A Fonte: Elaborao do autor (2006).
Figura 1.13 Dependncia Fim-Fim num Grfico de Gantt, onde B depende de A Fonte: Elaborao do autor (2006).
Figura 1.14 Dependncia Incio-Incio num Grfico de Gantt, onde B depende de A Fonte: Elaborao do autor (2006).
Figura 1.15 Dependncia Fim-Incio com folga num Grfico de Gantt, onde B depende de A Fonte: Elaborao do autor (2006).
40
A introduo das setas que mostram dependncias foi um grande avano na visualizao do planejamento, antes apenas possvel pela distribuio das barras num grfico com escala de tempo. Essa introduo permitiu perceber que as setas poderiam indicar algo mais no grfico, e da em diante um novo conjunto de grficos e diagramas foi desenvolvido e chegaremos, ento, ao Mtodo do Caminho Crtico (CPM) e diagramas PERT. Mas isso ser assunto para a prxima seo. Antes, para encerrar esta seo, veja duas ilustraes com exemplos de softwares que usam Grfico de Gantt com setas de dependncia. Na figura 1.16 voc pode ver uma tela gerada pelo jxProject de um projeto exemplo. Na figura 1.17 h outro projeto, onde a tela foi gerada pelo Microsoft Office Project.
Figura 1.16 Exemplo de Grfico de Gantt, software jxProject Fonte: Elaborao do autor (2006).
41
Figura 1.17 Exemplo de Grfico de Gantt, software Microsoft Office Project Fonte: Elaborao do autor (2006).
Seo 3 Metodologias de planejamento PERT/CPM

Aps a Segunda Guerra Mundial surgiu um projeto do governo norte-americano que acabou gerando uma profunda influncia na disciplina de gesto de projetos. Era o projeto Polaris, da Marinha, para produzir uma srie 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 desconfiana que o projeto gerou, pois se sabia que os prazos e custos de projetos militares eram constantemente estourados (PRADO, 1998). Para inverter esse quadro de desconfiana e ter o projeto aprovado, foi criada uma equipe especialmente para planejar e fiscalizar o andamento do projeto e a construo dos submarinos. Essa equipe foi
42
denominada Program Evaluation and Review Task Force, gerando a sigla PERT, que posteriormente viria a denominar a tcnica de representao do planejamento do projeto por eles desenvolvida Program Evaluation and Review Technique - PERT.
O projeto Polaris surpreendeu e foi desenvolvido em apenas trs anos, o que atraiu grande ateno para a equipe e para a tcnica que eles desenvolveram para a gesto de projetos.
Na dcada de 60 muitas melhorias foram incrementadas tcnica, incluindo o Critical Path Method CPM (Mtodo do Caminho Crtico), e todas as tcnicas de representao de projetos por redes de atividades e dependncias acabaram sendo reunidas atualmente no que se denomina PERT/CPM. A idia dessas tcnicas era criar um diagrama que verificasse os pr-requisitos de cada atividade, de tal forma que se pudesse compreender qual seria o conjunto de atividades, com seus prazos e em seqncia cronolgica, de tal maneira que fosse possvel traar o caminho crtico do projeto, ou seja, a seqncia de atividades que determinariam o menor tempo possvel do projeto. Dentre as vrias aplicaes das tcnicas PERT/CPM pode-se citar:
definir as atividades de um projeto; determinar a durao de cada atividade; com base nos prazos de cada atividade, buscar o prazo mnimo para o projeto total; encontrar as ligaes temporais entre as diversas atividades, ou seja, verificar os tempos de folga entre atividades seqenciadas; identificar quais atividades so crticas 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;
43
determinar qual a seqncia crtica do projeto considerando as atividades crticas, ou seja, determinar a seqncia de atividades crticas que perfazem o caminho crtico do projeto; verificar os tempos de folga que existem entre as atividades, de tal modo que se possa trabalhar com esses prazos durante a execuo do projeto sem afetar o prazo total.
Diferente do Grfico de Gantt, onde cada atividade ocupa uma barra do painel, nessas tcnicas de reviso e do caminho crtico so usadas setas para compor o diagrama, como no desenho da figura abaixo (figura 1.18), onde cada seta representa uma determinada atividade (atividade A, atividade B....) e os crculos representam um evento ou n, que a concluso de uma ou mais atividades.
Como voc pode ver no diagrama, a durao de cada atividade no est representada pelo comprimento da seta, pois os comprimentos dessas no tm escala. O que mais importa aqui verificar qual atividade depende de outra, sua precedente.
No caso do exemplo da figura 1.18, 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 precisaremos ter concludas as atividades C e D. Ou seja, o diagrama de setas define uma lgica para a seqncia de execuo.
Figura 1.18 Diagrama de setas simples com ns, que denotam a concluso de atividades Fonte: Elaborao do autor (2006).
44
As diferenas entre os mtodos como o Grfico de Gantt e as tcnicas PERT/CPM acontecem devido ao tipo de representao e de escala utilizada.
No Grfico de Gantt h uma escala de tempo bem definida, mas a representao das precedncias, da vinculao entre diferentes atividades e do caminho crtico no so evidentes. Para dar incio ao estudo das tcnicas PERT/CPM, faa primeiramente uma comparao grfica entre os diferentes mtodos, e ento evolua a partir desse ponto. Na figura 1.19 h duas representaes para o projeto Churrasqueira, que j foi tratado na seo anterior. Na parte superior da figura voc pode ver o Grfico de Gantt, exatamente o mesmo que foi apresentado na figura 1.10 (para maior clareza do desenho, retirei as linhas que representam prazo realizado). Na parte inferior da figura est uma representao por diagrama de setas do mesmo projeto, onde as letras denominam as atividades, conforme o seguinte quadro de correspondncia:
A B C D E F G H I J K L M preparao do terreno fundaes alvenaria - paredes alvenaria - reboco e cermicas telhado piso carpintaria tubulao hidrulica instalao hidrulica tubulao eltrica instalao eltrica pintura externa pintura interna e acabamento
Quadro 1.4 - Correspondncia letra - atividade Fonte: Elaborao do autor (2006).
45
Figura 1.19 Diagrama de setas com escala e acima o Grfico de Gantt do projeto Churrasqueira Fonte: Elaborao do autor (2006).
O diagrama de setas do projeto Churrasqueira da figura 1.19 est construdo dentro da escala de tempo definida no grfico de barras que est acima dele, como voc pode ver. Perceba que cada n est colocado exatamente na coluna que representa o incio ou final de uma determinada atividade. Repare, por exemplo, na atividade E Telhado: o n onde comea a seta est no incio do dia 7 de abril, e o n no final da seta est no dia 13. A seta E, ento, compreende 7 dias.
Mesmo para um projeto simples como este o desenho com setas acaba se tornando razoavelmente complexo e, de fato, no mostra muitas coisas. Da forma como est apresentado parece um modelo diagramtico ruim, e o Grfico de Gantt estava bem melhor, no ?
Acontece que a riqueza desse tipo de diagrama no est em representar na escala temporal o desenvolvimento do projeto, mas sim nos mostrar os seus pontos crticos de atraso. Vamos ento fazer duas modificaes no diagrama de setas do projeto Churrasqueira:
46
Redesenhe o diagrama para que fique mais claro, retirando a escala de tempo. Para no perder a referncia das atividades quanto ao seu prazo estimado, coloque sob cada seta o nmero de dias de sua durao.
Com essas duas modificaes simples voc ter o diagrama da figura 1.20 (Apesar de atividades diferentes, reunimos A,B e C em apenas um arco para simplificar o diagrama).
Figura 1.20 Diagrama de setas modificado do projeto Churrasqueira Fonte: Elaborao do autor (2006).
Bem, apesar de ser um desenho limpo, ainda no suficientemente claro para ajudar no planejamento do projeto. o momento, agora, de definir alguns conceitos e smbolos para construir os diagramas PERT/CPM. Com tais smbolos, apresentados no quadro da figura abaixo, voc poder fazer a construo final do diagrama do projeto Churrasqueira e partir para sua anlise como ferramenta de apoio na gesto de projetos.
47
Quadro 1.5 Quadro com simbologia e nomenclatura utilizados em diagamas PERT/CPM Fonte: Elaborao do autor (2006).
Como se v no quadro 1.5, alguns novos conceitos esto apresentados, tais como data mais cedo e mais tarde, folgas e smbolos com informaes. A data mais cedo (dc) representa a primeira data onde pode ocorrer o evento. J a data mais tarde (dt) a ltima data em que esse evento pode ocorrer, sem afetar o prazo do projeto. Essa data mais tarde existe quando h uma folga no projeto, e a folga especfica da atividade chamada de folga. A sequncia de atividades que define o prazo crtico do projeto, ou seja, aquela seqncia onde alteraes implicam uma alterao do prazo total do projeto, chamada de caminho crtico.
48
Volte agora ao diagrama da figura 1.20. possvel, ainda, simplificar um pouco mais o desenho. Veja 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 1.21 Diagrama PERT/CPM do projeto Churrasqueira, simplificao 1 Fonte: Elaborao do autor (2006).
Voc sabia que este diagrama pode ser simplificado mais uma vez? Veja a seguir como isto pode acontecer: A seta fantasma que une os ns do final da atividade E e do incio da atividade G pode ser suprimida, juntando ento esses dois ns. Com um pequeno rearranjo das setas e dos ns voc teria, dessa forma, o desenho simplificado do diagrama, conforme apresentado na figura 1.22. Repare como o diagrama ficou mais simples e objetivo, e como foi alterado desde o original, que desenhamos na figura 1.19. importante reparar que todo esse processo de construo foi realizado aqui para demonstrar a construo do diagrama PERT/ CPM, mas na prtica voc pode desenh-lo diretamente, apenas sabendo as atividades, suas precedncias e respectivas duraes. Voc ver isso num exerccio futuro.
49
Figura 1.22 Diagrama PERT/CPM do projeto Churrasqueira, simplificao 2 Fonte: Elaborao do autor (2006).
Tendo agora o diagrama desenhado, voc ir introduzir os smbolos que permitem colocar as informaes detalhadas do plano. Em primeiro lugar coloque os ns e para cada um d um nome, neste caso uma dezena para cada n de forma que, se voc precisar posteriormente inserir algum novo n, voc possa usar a numerao intermediria (ver figura 1.23). Como voc pode reparar, todas as datas de incio, mais cedo e mais tarde, esto em branco. Opte pela data mais cedo para o n 10 como sendo 1, ou seja, o primeiro dia da atividade A, e a partir da conte as datas em dias (poderamos tambm comear com 0 e isso no faz diferena, pois os totais sero os mesmos).
Figura 1.23 Diagrama projeto Churrasqueira, detalhamento 1 Fonte: Elaborao do autor (2006).
50
Tendo a primeira data mais cedo definida, voc pode ir preenchendo as dc dos outros ns. A dc do n 20 ser a dc do n 10 mais a durao da atividade ABC, ou seja,
dc20 = dc10 + duraoABC

Com isso o diagrama passa a ser detalhado e temos a figura 1.24 com o n 20 preenchido.
Considerando a data mais cedo do n 20 (onde dc20 = 25) voc pode preencher as datas dc dos ns 30 e 40, conforme figura 1.25.
51
Definido o n 30 (cujo dc30 = 32) voc pode preencher os ns 50 e 60. Repare que o n 60 ser preenchido com a soma da dc do n 30 e a durao da atividade F, que mais longa que a atividade HJ. Assim voc ter:
Incidem sobre o n 70 duas atividades com duraes diferentes: L e IK. Se voc considerar a atividade L, ter dc70 igual a 43, mas se consider a atividade IK, teramos dc70 igual a 48, que uma data mais tarde do que a definida a partir do caminho L. Nesse caso, obrigatoriamente, deve-se assumir essa segunda data, que o dia 48, dia de incio da atividade final M. Com isso o diagrama fica assim preenchido:
52
O n 80 representa o evento de encerramento do projeto e ter tambm uma marcao de data mais cedo, que nesse caso representa o dia da entrega do projeto. Por ser esse o dia final, ento a data mais tarde coincide com a data mais cedo, ou seja,
dc80 = dt80 = dia da entrega do projeto.

Definida a data final do projeto, voc ter ento preenchido completamente o ltimo n, e poder fazer o caminho inverso do diagrama preenchendo agora a data mais tarde de incio de cada atividade. Faa isso e tire as concluses. Inicialmente voc deve preencher o ltimo n (ver figura 1.28).
Figura 1.28 Diagrama projeto Churrasqueira, detalhamento 5 incio do caminho inverso de preenchimento Fonte: Elaborao do autor (2006).
A data mais tarde do n 70, dt70 , ser encontrada subtraindo-se a durao da atividade M, da seguinte forma:
dt70 = dt80 duraoM

Com isso voc obter dt70 = 48, o que coincide com a data mais cedo desse mesmo n. Veja a figura 1.29, a seguir.
53
Figura 1.29 Diagrama projeto Churrasqueira, detalhamento 6 preenchimento das datas mais tarde de incio de cada atividade Fonte: Elaborao do autor (2006).
Adote o mesmo procedimento para os ns 40 e 60. Para o n 60 perceba que novamente as datas mais cedo e mais tarde coincidem, porm para o n 40 h uma diferena entre elas. Veja a figura 1.30.
A diferena entre datas que se v no n 40 a folga livre (FL). A atividade L pode comear entre os dias 38 e 43 sem afetar o desenvolvimento geral do projeto. Esse conceito de folga livre muito importante para o gestor do projeto pois, a partir desse dado, ele pode escolher, a partir de outras estimativas, como custos, equipe, riscos etc, a melhor data de incio dentro dessa margem de folga.
54
O n 50 est ligado ao 60 por uma atividade fantasma, que no tem durao. Assim a sua dt50 ser igual dt60 , ou seja, 45. E o n 30, como ficar? H trs ns na sua seqncia: 40, 50 e 60. Veja as trs expresses possveis e seus resultados:
dt30 = dt60 duraoF = 45 13 = 32 dt30 = dt50 duraoHJ = 45 2 = 43 dt30 = dt40 duraoG = 43 5 = 38

- Certamente devemos escolher o menor, pois seno afetaramos todos os prazos do projeto, certo? Nossa inteno na gesto do projeto desenvolver o trabalho no menor prazo possvel, cumprindo ou antecipando o prazo final. Com isso obtemos o seguinte diagrama:
Para definir o n 20 novamente voc dever fazer uma escolha entre duas opes: iniciar o clculo a artir de dt30 ou de dt40 . Com dt30 obtemos para o n 20 a data 25 (dt 20 = 25), que a menor e que ser ento adotada. Assim, preenchendo tambm o n 10, voc chegar ao diagrama PERT/CPM final do projeto Churrasqueira, apresentado na figura 1.32. Sem dvida, no um diagrama fcil de ser
55
entendido primeira vista, e para ser til preciso ter ao lado a tabela de referncia das atividades. Porm, ao analisar o desenho com maior cuidado, voc ver como poderosa essa ferramenta para tratar a questo dos prazos gerais do projeto, e como o gestor pode acompanhar e interferir sobre as diversas etapas visando seu controle efetivo e constante.
Figura 1.32 Diagrama PERT/CPM final do projeto Churrasqueira Fonte: Elaborao do autor (2006).
Voc pode verificar que no diagrama o caminho de atividades onde no h folga define o caminho crtico das atividades do projeto. Sobre esse conjunto de atividades o gestor deve prestar ateno especial e preparar suas estimativas de recursos e custos.
possvel desenhar o diagrama PERT/CPM sem ter montado o Grfico de Gantt?
Sim, mas importante perceber que os diagramas so diferentes e complementares para o gestor. Enquanto no Grfico de Gantt possvel ver a escala temporal claramente, bem como a pessoa responsvel por cada atividade e tambm acompanhar o andamento do projeto ao longo do tempo (preenchendo uma barra das tarefas executadas), no diagrama PERT/CPM possvel determinar a seqncia de atividades com suas precedncias, e perceber claramente quais atividades podem afetar todo o andamento do projeto.
56
Neste sentido importante ter as duas ferramentas como instrumentos objetivos de apoio ao gestor. Para criar diretamente um diagrama PERT/CPM, necessrio partir da tabela de diviso de tarefas, conforme visto no exemplo do quadro 1.1. No entanto, aquele quadro apresenta apenas a diviso das tarefas, e ser ento necessrio incluir duas colunas: uma para anotar o tempo estimado de realizao da tarefa, e outra para anotar quais as tarefas precedentes obrigatrias. Faa esse exerccio considerando a tabela que voc utilizou no exemplo do Projeto Churrasqueira. No quadro 1.6 reapresento a distribuio de tarefas, mas incluindo os prazos estimados e as tarefas precedentes. Para cada etapa procurei desenhar uma seta, com o nome da etapa sobre ela e o prazo abaixo. A seta deve chegar a um n. A seta correspondente a uma nova etapa deve partir do n onde se encerrou a etapa precedente. Setas de atividades-fantasma so desenhadas quando uma atividade tem mais de uma precedncia, e neste caso diferentes ns de origem. Ao final do desenho so feitas as simplificaes. Seguindo esse roteiro voc chegar ao diagrama da figura 1.32.
ETAPA
A B C D E F G H I J K L M
Projeto CHURRASQUEIRA
Preparao do terreno Fundaes Alvenaria paredes Alvenaria reboco e cermicas Telhado Piso Carpintaria Tubulao Hidrulica Instalao Hidrulica Tubulao Eltrica Instalao Eltrica Pintura Externa Pintura Interna e acabamento
Tempo estimado da etapa (dias)

2 7 15 13 7 13 5 2 3 2 3 5 7
Precedncia
A B C C E E C, E H, F C, E J, F G I, K, L
Quadro 1.6 Diviso de tarefas, com prazos e precedncias, do projeto Churrasqueira Fonte: Elaborao do autor (2006).
57
Um dos maiores problemas na montagem desse tipo de tabela ser na definio dos prazos de cada etapa. A estimativa de tempo deve ser feita, quando possvel, com a ajuda dos membros da equipe. O tempo estimado algo subjetivo, pois se considera a experincia de cada um. Nesse sentido, h as previses otimistas, as pessimistas e as provveis. A bibliografia (KEELING, 2002) prope definir um tempo provvel com a seguinte frmula para clculo do Tempo Estimado de uma determinada tarefa:
te = ( to + 4tm + tp ) / 6
Onde:
te tempo estimado da tarefa; to tempo otimista, ou seja, durao prevista mais curta; tm tempo provvel, ou seja, durao mdia prevista; tp tempo pessimista, ou seja, durao prevista mais longa.
Ainda assim, h os que consideram o Tempo Estimado nesta frmula muito otimista, podendo-se ento aplicar a seguinte alternativa mais conservadora (KEELING, 2002):
te = ( to + 3tm + 2tp ) / 6
Com isso voc conclui o estudo de ferramentas de apoio para o planejamento das etapas de um projeto. Na seo anterior voc viu que para o projeto ser iniciado era preciso analisar sua viabilidade quanto aos recursos, custos, prazo e benefcios. Tendo o planejamento realizado e os prazos estimados, preciso agora estimar os recursos e custos necessrios ao projeto.
58
Seo 4 Estimativa de recursos

Tendo um planejamento do projeto, voc pode agora estimar os recursos necessrios para ele. Bem, estimar no uma cincia exata. DeMarco (1991) prope algumas definies diferentes, tais como:
Estimativa a previso mais otimista que no tem uma probabilidade zero de tornar-se realidade. Ou Uma estimativa uma previso que tanto pode estar acima quanto abaixo do resultado real.
Essas definies soam estranhas, mas dizem muito sobre o ato de estimar: um chute que pode marcar o gol ou apenas passar mais ou menos perto. Voce deve ter claro que precisa estimar o melhor possvel para evitar riscos durante o projeto. Quanto aos recursos necessrios a um projeto, basicamente h os seguintes:
Materiais so os produtos necessrios para confeccionar o projeto, tais como matrias-primas, produtos manufaturados, componentes, hardware etc. Equipamentos so as mquinas e ferramentas necessrias para poder trabalhar as matrias-primas, escrever o cdigo de um software, facilitar uma construo etc. Pessoal os recursos humanos aparecem como o principal requisito em projetos, especialmente em projetos de tecnologia; a prxima unidade discutir este item. Financeiros so os custos do projeto, que advm dos gastos relativos a materiais, equipamentos, locaes, fretes, transportes, pessoal, licenas, direitos autorais, etc (a estimativa de custos o assunto da prxima seo).
59
Como voc estudou na seo anterior, o planejamento do projeto tem um foco muito intenso no prazo geral, pois como projetos so trabalhos com data marcada para acabar, o prazo determinante. Para realizar o planejamento foi feita uma diviso de tarefas, e essa diviso o fator que ir permitir estimar recursos, tarefa por tarefa. Desta forma deve-se partir da tabela onde as tarefas foram divididas e incluir colunas especficas para descrever recursos necessrios.
Q quadro apresentado na figura abaixo um exemplo de relatrio a ser preenchido no incio do projeto. Este exemplo partiu do quadro anterior, descrito no quadro 1.2. Para cada projeto especfico dever ser construda uma tabela exclusiva, sendo que a coluna dos recursos definir uma lista de necessidades.
Projeto CHURRASQUEIRA Etapa 1 Preparao do terreno Limpeza do terreno Medies e marcaes Escavaes Etapa 2 Fundaes Montagem das madeiras de caixaria Montagem das ferragens da fundao Concretagem Etapa 3 Alvenaria Construo das paredes ........
Recursos necessrios
Tratores (dois dias) Topgrafo Tratores (um dia)
XX dzias de madeira para caixaria; Pessoal para montagem da caixaria; XX barras de ferro; XX caminhes de concreto
XX milheiros de tijolos; Xx sacos de cimento; Etc. ...........
Quadro 1.7 Diviso de tarefas com estimativa de recursos Fonte: Elaborao do autor (2006).
60
Seo 5 Estimativa de custos

A distribuio de custos do projeto feita num grfico chamado de cronograma fsico-financeiro. Este deve aproveitar o grfico de barras que voc viu no Grfico de Gantt, sendo que os custos do projeto podem ser distribudos ao longo do tempo de durao do projeto. Para cada item, definido nos recursos estimados para o desenvolvimento do projeto, voc dever fazer uma estimativa de gastos. O uso do grfico de barras interessante, nesse caso, devido clareza visual de apresentao. - Veja um exemplo para entender melhor esse tipo de cronograma. A figura 1.33 apresenta o Grfico de Gantt de um projeto hipottico com sete atividades Tarefas A at G cujos trabalhos transcorrem em 16 semanas, aproximadamente quatro meses. Tendo estimados os recursos necessrios para desenvolver cada tarefa, os custos podem ser distribudos por tarefa e por unidade de tempo, neste caso por semana. Sobre o prprio grfico os valores so anotados, semanalmente.
Figura 1.33 Estimando custos cronograma fsico-financeiro Fonte: Elaborao do autor (2006).
Fazendo a estimativa de custos por atividade e por unidade de tempo possvel chegar a valores mais prximos do real. Quanto maior a diviso das tarefas, melhor. Anotados todos os valores voc far a somatria, tambm por unidade de tempo. A cada semana voc chega a um valor total, conforme vemos na ltima
61
linha do grfico. Com tais valores possvel estimar o valor total de custos do projeto, apresentado no canto inferior direito da figura. Outra visualizao dos custos desse mesmo projeto apresentada na figura 1.34, a qual decorre dos valores obtidos na estimativa do grfico de barras.
Figura 1.34 Grfico de linha do cronograma fsico-financeiro Fonte: Elaborao do autor (2006).
Percebemos pelo grfico da figura 1.34 que o projeto dever dispor de recursos financeiros bem maiores do que a mdia nas semanas 6 e 7. Fazendo essa anlise pode-se retornar ao planejamento do projeto e, caso necessrio, alterar a durao das tarefas que impactam nesses valores, nesse caso especialmente a Tarefa C. Se no for possvel alterar, ento o caixa do projeto dever estar preparado para tal fluxo.
62
Sntese
Nesta unidade foram apresentados modelos e mtodos muito importantes para o gestor de projetos e de suas equipes. Em primeiro lugar foi feita uma avaliao de como o fluxo de atividades pode ser distribudo em um projeto, de acordo com o tipo de projeto e de suas necessidades especficas. Projetos de tecnologias mais tradicionais, ou com contratos de mbito conservador, levam a modelos de desenvolvimento com uma cadncia diferente, por exemplo, daqueles projetos onde o tempo de chegada ao mercado fator decisivo de sucesso, ou onde as tecnologias no so dominadas e precisamos fazer revises e retornos constantes a etapas anteriores. Depois voc viu as tcnicas de planejamento que foram desenvolvidas nos ltimos cem anos, que basicamente o perodo onde a disciplina de gesto de projetos tomou forma. O grfico que apresenta as diversas atividades em forma de barras ao longo do tempo foi desenvolvido por Gantt e ficou extremamente popular, sendo ainda a base das diversas ferramentas de planejamento, especialmente os softwares recentes como o MSProject, o jxProject e diversos outros. A popularidade do Grfico de Gantt deve-se fora de sua clareza visual para representar o projeto e, recentemente, a implantao de setas de precedncia interligando as barras, aumentou ainda mais a sua qualidade como modelo. Esse grfico tambm permite acompanhar as tarefas previstas comparando-as com as realizadas, por meio de uma barra extra desenhada ao lado ou diretamente sobre a barra original. Outra utilidade est na representao dos custos dos projetos discretizados por tarefa e por unidade de tempo adotada, facilitando em muito a estimativa de custos gerais do projeto.
63
Apesar de a imensa utilidade do Grfico de Gantt, outro mtodo foi desenvolvido para facilitar o planejamento do tempo de durao do projeto trata-se do mtodo do caminho crtico, denominado genericamente de PERT/CPM. Esse grfico permite distinguir num projeto qual a seqncia crtica de atividades, de tal forma que o gestor pode prestar ateno especfica em tais atividades, e at mesmo alter-las para que o projeto seja adiantado ou tenha seu prazo corrigido. Com tais ferramentas de planejamento e anlise pode-se, ento, chegar a estimativas bastante realistas quanto aos recursos necessrios ao projeto, e quais seus custos.
Atividades de auto-avaliao
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 implantao, o qual no deve superar dois meses, e que deve ser primeiro implantado no setor administrativo e somente depois no setor de produo da empresa. O projeto tem as seguintes atividades: reunies do grupo do projeto para definir o programa; redao do programa de qualidade; treinamento do pessoal do setor administrativo; treinamento do pessoal do setor de produo; implantao do programa de qualidade no setor Administrativo; implantao do programa no setor de produo; avaliao dos resultados e concluso, com entrega dos relatrios direo. Faa sua anlise e, com base nela, preencha o quadro a seguir:
Projeto Qualidade
ABCDEFG-
Prazos estimados pela equipe de implantao
Precedncias (letras)
64
2) Prepare o Grfico de Gantt para a planilha de atividades do exerccio anterior Projeto QUALIDADE, e considere ainda que os treinamentos podem ser feitos em seqncia, independente do incio do trabalho de implantao no setor de produo. (Faa de acordo com o quadro apresentado na pgina 66).
3) Baseado no Grfico de Gantt que voc criou no Projeto Qualidade, reproduza-o e faa logo abaixo dele o diagrama de setas com escala. (Faa de acordo com a figura apresentada na pgina 67).
65
Projeto Qualidade
A SD 01 / set 02 / set 03 / set 04 / set 05 / set 06 / set 07 / set 08 / set 09 / set 10 / set 11 / set 12 / set 13 / set 14 / set 15 / set 16 / set 17 / set 18 / set 19 / set 20 / set 21 / set 22 / set 23 / set 24 / set 25 / set 26 / set 27 / set 28 / set 29 / set 30 / set 01 / out 02 / out 03 / out 04 / out 05 / out 06 / out 07 / out 08 / out 09 / out 10 / out 11 / out 12 / out 13 / out 14 / out 15 / out 16 / out 17 / out 18 / out 19 / out 20 / out 21 / out 22 / out 23 / out 24 / out 25 / out 26 / out B C D E F G
SD
SD
SD
SD
SD
SD
SD
66
A SD 01 / set 02 / set 03 / set 04 / set 05 / set 06 / set 07 / set 08 / set 09 / set 10 / set 11 / set 12 / set 13 / set 14 / set 15 / set 16 / set 17 / set 18 / set 19 / set 20 / set 21 / set 22 / set 23 / set 24 / set 25 / set 26 / set 27 / set 28 / set 29 / set 30 / set 01 / out 02 / out 03 / out 04 / out 05 / out 06 / out 07 / out 08 / out 09 / out 10 / out 11 / out 12 / out 13 / out 14 / out 15 / out 16 / out 17 / out 18 / out 19 / out 20 / out 21 / out 22 / out 23 / out 24 / out 25 / out 26 / out
SD
SD
SD
SD
SD
SD
SD
67
4) Modifique o diagrama de setas do exerccio 3, simplifique-o e crie o Diagrama PERT/CPM do mesmo, usando a simbologia aplicada nesta disciplina e reproduzida abaixo.
Desenhe o diagrama passo a passo, calculando para cada n a data mais cedo e posteriormente a data mais tarde para cada atividade (use os modelos abaixo para desenhar o diagrama).
68
69
5) No exerccio anterior, onde h uma Folga Livre (FL)? O que isso significa para o gestor do projeto QUALIDADE?
70
Saiba mais
Nesta unidade, voc estudou modelos de representao como forma de entender um projeto, a partir de uma viso geral. Para o desenvolvimento de software surgiu uma tecnologia que busca criar modelos de representao, por meio de diagramas, que muito se assemelham aos diagramas genricos que usamos aqui. Essa tecnologia chamada UML Unified Modelling Language, e est baseada na modelagem de diversos tipos de diagramas, os quais abrangem diferentes vises 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. Os diagramas UML de Caso de Uso e de Atividades, em especial, se assemelham com o que foi tratado aqui, e devem participar com ferramentas naturais no planejamento de projetos de software e de tecnologia em geral. A UML desenvolvida atualmente por uma organizao internacional sem fins lucrativos, e toda sua documentao pode ser encontrada na internet. Vrios softwares para desenvolvimento UML esto disponveis hoje para download gratuito, como, por exemplo, o POSEIDON.
As idias da Microsoft para gesto de projetos de software tambm esto disponveis na internet. Anlises de risco, estimativas, grupos de trabalhos e diversos outros conceitos so discutidos no que eles chamaram Microsoft Solutions Framework MSF.
71
UNIDADE 2
Estruturando a equipe
Compreender aspectos da formao e estruturao de equipes, conforme cada tipo de projeto discutido nas unidades anteriores. Perceber como contornar os problemas de estruturao de uma equipe. Reconhecer os diversos modelos de estruturao de equipes em diferentes organizaes. Compreender as dificuldades que um gestor pode trazer ao trabalho com projetos quando no se ajusta a um perfil de liderana criativa. Compreender que, em projetos, as equipes precisam trabalhar com objetivos definidos de cooperao e de participao proativa.
Sees de estudo
Seo 1 Estruturando a equipe Seo 2 Recursos humanos e perfis Seo 3 Treinamento Seo 4 Responsabilidade e diviso de tarefas Seo 5 Terceirizao

Voc ver que esta unidade contm muito mais opinies pessoais do que tcnicas e dicas infalveis. So opinies baseadas em anos de atuao em diferentes projetos, seja com equipes trabalhando dentro do escritrio ou em trabalhos de campo, seja com pequenas empresas ou em grandes corporaes, e com modelos de estrutura hierrquica os mais diversos possveis. No entanto, no so somente opinies, mas tambm algumas tcnicas e mtodos so apresentados aqui. De incio, voc ver um modelo de formao de equipes e como se do os problemas no comeo dos relacionamentos, especialmente quando a equipe tem vrias pessoas de origens diversas. Esses problemas acontecem devido aos diferentes perfis humanos, ou seja, s diferentes caractersticas de comportamento e atitude, muito mais do que diferenas de conhecimento tcnico. As questes tcnicas, muitas vezes, podem ser resolvidas por meio de treinamentos especficos e dirigidos. No o caso quando temos grandes diferenas comportamentais. Nesses casos, precisamos ter lderes frente das equipes, pois o que interessa em projetos ter ambientes de grande cooperao e o interesse sincero (e ousado!) pelo sucesso. Falaremos um pouco sobre liderana, mas deixaremos o principal para a prxima unidade. Nesta unidade, voc estudar apenas algumas alegorias (que espero que sejam divertidas, e esclarecedoras tambm!). Voc ver tambm cinco diferentes modelos de estruturao de equipes, que so os mais usados pelos grupos de projetos, variando desde os casos mais complexos, nas grandes empresas, at os trabalhos mais simples e com pequenas equipes. Esses modelos so muito teis e nos ajudam a estruturar o grupo de pessoas e comunicar as funes e interfaces de trabalho.
74
Treinamento e terceirizao so os outros dois tpicos tratados aqui, sendo que o processo de terceirizao assumiu, nos ltimos tempos, um carter estratgico para as empresas e especialmente para os pases dominantes, o que tem trazido muita discusso para a arena econmica e poltica, e isto est ligado diretamente ao nosso objeto de estudo. Bom estudo a todos!
Seo 1 Estruturando a equipe

Considere um campeonato de futebol como um projeto: cada time traa seus objetivos, contrata jogadores, treinador, busca recursos e tem datas definidas para chegar aos resultados. H inmeros riscos, pois uma competio com muitas variveis. Sabemos que uma questo muito importante, sempre discutida pelos comentaristas e que tambm a conversa do incio de cada semana aps uma rodada emocionante, trata da formao e do entrosamento dos jogadores dentro de campo. Cada jogador tem sua funo, sabemos mais ou menos sobre suas qualidades e alguns so reconhecidos por sua competncia. No entanto em cada partida h um comportamento diferente, h um jeito diferente de jogo, e simultaneamente encantamentos e decepes. Certamente os projetos de pesquisa, de engenharia, de software, no so assim to famosos nem to visveis, mas muitas vezes so bastante emocionantes. E vo depender de quanto h de sensao de time na equipe.
Constituir uma equipe relativamente fcil, constituir um time, no tanto.
75
A equipe constituda a partir da definio de funes, ento possvel determinar as caractersticas necessrias de um indivduo para que preencha tal funo. Grandes companhias preparam uma lista de requisitos mnimos para que se procurem funcionrios para determinada vaga. Em algumas equipes h pessoas trabalhando no recrutamento que atuam como mquinas de verificao: olham currculos e buscam aquelas que preenchem tais requisitos, depois fazem as entrevistas e as anlises de perfil (psiclogos trabalham nisso) e, por fim, algum contratado e passa a integrar a equipe. Essas companhias enxergam o trabalho como atividade rotineira e, muitas vezes, mquinas e pessoas no fazem grande diferena. Atividades rotineiras suportam equipes assim, mas penso que projetos no. Projetos, assim como campeonatos, exigem pessoas que trabalhem em cooperao e que gostem, realmente, de chegar aos resultados com sucesso. Em uma equipe convencional, de rotina, cada um faz a sua funo (no precisaria ser assim!). Em um projeto os membros da equipe trabalham para ajudar os outros, fazendo a sua funo e colaborando para que os outros realizem as suas.
O primeiro conceito importante na formao de uma equipe a cooperao. O segundo conceito importante o objetivo comum.
A pessoa nesse caso um agente que toma decises e tem liberdade de ao, ao contrrio da mquina.
Os membros da equipe devem trabalhar em regime de cooperao em busca de um objetivo comum. Isto j estava claro desde o comeo de nosso estudo, pois voc viu que uma das chaves de sucesso do projeto a viso clara sobre o resultado esperado. 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 no ganham o campeonato algo ficou faltando!). Isso quer dizer que no basta analisar as competncias pelo currculo. necessrio que alm da competncia a pessoa que vai fazer parte da equipe de projeto tenha a cultura da colaborao. Isso no pode ser detectado sem a convivncia. E gerentes de projetos que no sejam lderes, muitas vezes no conseguiro sacar essa caracterstica. Essa percepo
76
exige experincia e intuio. Aqui estamos saindo do campo das cincias exatas e entrando no campo pantanoso das relaes humanas (nada exatas...).
Na estruturao da equipe de um projeto, conforme Valeriano (1998), h quatro momentos distintos: Formao. Quando se renem os membros do projeto e as funes so distribudas, ainda no h clareza das atividades a serem realizadas As pessoas no se conhecem e o tratamento formal. Por no haver conhecimento h um ambiente de confuso inicial. Turbulncia. A partir do incio das atividades comeam a se formar subgrupos a partir de afinidades pessoais, e muitas vezes principiam atritos, especialmente em equipes grandes com pessoas de variados tipos. A turbulncia comum em projetos, especialmente quando os riscos so grandes e iminentes. Normalizao. Se os perodos de turbulncia so resolvidos pela liderana, 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 perodo a equipe entra em equilbrio criativo e cooperativo, e o projeto tem alto rendimento. Os membros sentem-se parte do time de trabalho, reconhecem a liderana e os companheiros como importantes em seu prprio papel.
Essas quatro fases de estruturao podem acontecer ou no, sendo que muitos projetos chegam a crescer at a normalizao apenas, sem atingir o ambiente propcio do desempenho. Sustentar a fase do desempenho , alm de tudo, uma tarefa difcil que exige esforo contnuo. Veja na figura a seguir o diagrama esquemtico dessa estrutura.
77
Figura 2.1 Representao esquemtica das fases de estruturao da equipe de projeto Fonte: Elaborao do autor (2006).
Seo 2 Recursos humanos e perfis

Como voc viu na seo anterior, a escolha de perfis humanos para trabalhar em uma equipe de projeto est fora da escolha de caractersticas exatas, caractersticas pr-definidas e nas quais algumas pessoas especiais se encaixariam. Esse o campo das relaes humanas, relaes sempre sutis, delicadas, que variam infinitamente. Os membros da equipe acabam por se moldar s caractersticas do gestor. Se o gestor for um lder, poder conduzir sua equipe para a fase do desempenho. Se no, provavelmente permanecero na fase da normalizao. Portanto ser importante discutirmos os perfis dos gestores, sejam lderes ou no. Mas antes de falar dos gestores/lderes, vamos tentar descrever alguns perfis tpicos das pessoas que viro a fazer parte de nossas equipes de projeto.
78
Keeling (2002) apresenta diversos tipos de perfis citando outros autores como Margerison e McCann, que comentam sobre oito diferentes papis, Belbin, que classifica nove grupos descritivos, ou Parker, com apenas quatro papis. Os quatro papis de Parker, citados por Keeling (2002) so:
Contribuidor. Aquele que contribui com atividades e resultados, mas no participativo. Colaborador. O que participa do desenvolvimento em conjunto. Comunicador. Capaz de comunicar as atividades e de integrar grupos por meio da comunicao. Desafiador. O que sempre apresenta as questes e participa dos trabalhos num esprito de desafio (o que pode ser bom ou ruim, depende da situao e do caso).
Essas tentativas de classificao muitas vezes caem no vazio, tal o nmero de possibilidades e de percepes. Muito provavelmente no possvel ser cientfico nesse caso, e a classificao ser local e temporal, ou seja, depender do ambiente, da situao e das condies culturais de um determinado grupo. Pela dificuldade do tratamento cientfico (se que isso necessrio), posso fazer uma brincadeira e descrever alguns perfis que j participaram de projetos junto comigo, e que no decorrer das experincias foram se formando como tipos, facilmente reconhecveis. Veja alguns:
79
O que est sempre disposto. Esse o tipo de pessoa que est sempre cheia de energia, e para qualquer atividade que se apresenta, logo j quer sair fazendo coisas; tem disposio e energia, mas por esse motivo acaba por se entregar ao trabalho antes de saber exatamente o que fazer, prejudicando todo o desempenho.
O que nunca entrega. Tive projetistas trabalhando comigo que sempre estavam a um passo de fechar um projeto ou parte dele, mas por algum motivo estranho esse passo nunca acontecia; personaliza aquela Lei de Murphy que diz que ao completar 90% do trabalho, ficam faltando os outros 90%. O problema da entrega um dos mais importantes em projeto, pois chama a ateno sobre o fato dos projetos em geral no serem entregues no prazo, e isso decorre da dificuldade em ver, claramente, o fim de cada etapa. O que finge ser especialista. O ditado popular diz que especialista aquele que sabe quase tudo sobre quase nada. Como geralmente as pessoas normais no conhecem tudo sobre tudo, muitas vezes algum que domina meia dzia de belas frases tcnicas e alguns acrnimos da moda, passa por especialista. Na informtica isso muito comum, e tenho visto em conferncias por a aqueles profissionais que aparentam grande conhecimento e que no resistem a mais do que duas perguntas; para nossos projetos, vamos nos cuidar com esse tipo. O que especialista, mas no se entende com os outros. Vale a mesma mxima de especialista do item anterior, porm nesse caso ele de fato conhece um quase tudo sobre um quase nada que interessa ao projeto, o problema que, por esse motivo, o tipo acredita que vale mais do que os outros e tem enorme dificuldade de relacionamento. Se projetos so trabalhos de cooperao, sua especialidade perde o valor automaticamente; melhor algum que sabe um pouco sobre o quase nada, e que possa cooperar com aqueles que esto sua volta. O que puxa-saco. No preciso pensar muito para lembrar de pessoas com esse perfil, pois no h grupo que no tenha esse membro (infelizmente); concorda sempre com o superior hierrquico, e inconscientemente se move para ficar sua sombra (e com as suas sobras); caso haja um atrito, vai se colocar do lado do que tem mais fora, e no consegue agir com opinio prpria; deve ser eliminado da equipe sempre que for descoberto.
80
O que suga energia. Em uma equipe de alto desempenho buscamos cooperao e boa vontade, e quando h divergncias elas so tratadas como geradoras de novas solues. Contudo h o perfil de pessoa que funciona como um buraco negro, sugando idias e a energia do resto dos membros de equipe; difcil perceber essa ao, e muitas vezes s fica evidente depois de muito tempo, e muito estrago. O que no comunica. Comunicao fator crtico de sucesso em projetos, mas a dificuldade de comunicar com clareza e objetividade algo muito comum; no estamos livres desse problema, e temos que ficar atentos em ns mesmos e em nossas aes; a busca por comunicar deve ser uma meta paralela meta por entregar. O que detalhista operacional. A pessoa que logo se entrega ao trabalho e vai direto para a bancada, querendo produzir algo, geralmente tem essa caracterstica do detalhista operacional: no consegue parar para ver o projeto em linhas gerais e j quer realizar alguma parte dele. Boa parte dos softwares que conhecemos foi desenvolvida por pessoas assim, e por isso a dificuldade de integrao, a dificuldade de melhorar, a dificuldade de achar erros etc. O que generalista estratgico. Perfil diametralmente oposto ao anterior, sempre est olhando o projeto, e qualquer atividade, de um ponto de vista muito genrico; tem dificuldade para colocar a mo na massa, pois sempre tem uma viso nova, geral, para colocar, e no percebe o momento de partir da superfcie para o fundo, ou seja, consegue navegar mas no mergulhar.
Esta lista pode se estender por pginas e pginas. Deixarei para voc imaginar alguns outros perfis problemticos.
Analisando perfis problemticos, voc consegue avaliar quem manter e quem evitar em sua equipe de trabalho? Reflita sobre isso!
81
Por outro lado temos a figura do gestor, e variados perfis tambm tm sido escritos sobre ele. As publicaes sobre gesto e estudos de gerenciamento discorrem sobre tcnicas e mtodos de gesto, mas ultimamente h nfase sobre as caractersticas da liderana acopladas atividade gestora. Conheci um sujeito que no gostava da palavra lder, pois associava essa imagem com a figura do carisma, a algum cheio de seguidores fanticos. Esse sujeito certamente no era um lder de projetos, nem de empresas (de fato no era, pois fugia das situaes crticas, amedrontado). Se, nos pargrafos anteriores, discorremos sobre variados perfis de membros de equipes de projeto, cabe tambm apresentar alguns perfis de gestores.
Na prxima unidade, as funes dos lderes e suas relaes com os membros da equipe, durante a execuo do projeto, sero discutidas em maior profundidade. Aqui vamos ficar apenas com algumas notas sobre perfis de gestores, na forma de caricaturas (ou seja: como no ser um gestor!).
A brincadeira a seguinte: sem ofender o mundo animal vamos descrever trs modelos diferentes de gestores comparando-os com o comportamento de animais. Obviamente esses animais no se comportam exatamente assim mas, como metfora, podem ser teis e voc perceber que h muitas pessoas agi ndo assim (no s em filmes!). Bem, eu j conheci. Vamos a eles:
82
Gestor-rinoceronte. Quando voc vir aquele gerente andando em passos largos e falando alto na direo de um funcionrio da equipe, o tom ameaador j denunciar a performance de rinoceronte; ele no precisa ser gordo nem grande, basta esse comportamento de quem quer resultado pelo aspecto ameaador. A cara de tonto e o seu contedo de conhecimento quase nulo, mas no se pode duvidar que se esbarrar com ele, trar conseqncias fsicas (mas no intelectuais, pois seu estilo no esse). Esse o famoso gerento, que pensa em obter resultados de sua equipe de projeto chamando a todos todo o tempo para cobrar algum resultado, resultado que ele mesmo no tem certeza qual seria, devido sua falta de domnio. Esse tipo introjetado no cargo por algum outro superior (talvez um gerente-raposa), e sua equipe se divide entre os que tm medo e os que querem distncia. Como evitar ser um gestor-rinoceronte? Respeitando os membros da equipe, ouvindo com educao, estudando o projeto, respeitando as dificuldades, assumindo os riscos em parceria, participando como um colaborador e no como um cobrador truculento. Gestor-cobra. Diferente do rinoceronte, esse tipo de gestor evita confrontos e prefere agir sorrateiramente. Voc no est vendo, mas sabe que ele est observando suas aes de longe, pronto para atacar se qualquer coisa sair errada. Em sua frente ele est quieto, muitas vezes com aquela educao disfarada e o esforo para parecer no controle. Se alguma apresentao pblica do projeto for necessria ele designar um membro da equipe, pois ele mesmo no vai se expor. Compartilha com o rinoceronte o desconhecimento dos detalhes do projeto, mas como fala pouco no possvel determinar at onde conhece ou no conhece. tica para ele uma palavra de dicionrio, no um comportamento. Com esse tipo de gestor o grupo de projeto acaba se conformando a entregar apenas o mnimo necessrio, e aqueles que ousam destoar so aniquilados sorrateiramente. Como evitar ser um gestor-cobra? Admitindo as diferentes vises da equipe, expondo-se, sendo claro, agindo com tica nos relacionamentos, no destilando o veneno da negatividade entre pessoas que esperam criao e liberdade.
83
Gestor-raposa. Enquanto o tipo rinoceronte coordena a equipe de projeto derrubando o que encontra pela frente e o tipo cobra coordena a equipe pelo medo do que no est vendo, o tipo raposa muito mais sutil e muitas vezes engana inmeras pessoas com seu ar de sabedoria. Por isso chamamos determinado poltico de raposa: ele esperto e gil, e sempre quer se dar bem pelas articulaes que faz (em proveito prprio, certamente). Esse tipo de gestor no se importa com os membros da equipe, e afaga suas cabeas enquanto esses lhe servem. No entanto no dia que algo ameaa sua posio, busca uma maneira sutil de desviar o inconveniente. No h projeto criativo que ande bem com esse tipo de gestor, pois no admite as diferenas. O que o distingue do tipo cobra que no articula um ataque s escondidas, e de fato estuda e conhece muitas coisas. Seu problema o medo e a dificuldade de relacionamento, pois se comporta de forma arredia, distante e fria. Uma boa idia dentro da equipe para ele uma ameaa, pois aquele membro poderia ser superior a ele. Se tiver um rinoceronte e uma cobra a seu servio, eles faro o servio sujo por ele. Como evitar ser um gestor-raposa? Fazendo um exerccio por admitir as diferenas, abrindo-se aos relacionamentos, permitindo o trabalho em grupo e participando dele, aproximando-se, e muitas vezes simplesmente cumprimentando os membros da sua equipe. Parece simples, no ? Mas a realidade tem mostrado que a maioria dos gestores, infelizmente, acaba se adequando a um desses papis, ou hbridos deles.
Por fim, na definio de perfis para escolher os membros da equipe de projetos, podemos tentar nos guiar por algumas notas de trabalho. Uma alternativa interessante criar a matriz de qualidades desejveis e de funes necessrias em um projeto. Digamos que se tenha um grupo de pessoas na empresa que possa vir a participar do projeto, e precisamos definir suas posies. Ao mesmo tempo sabe-se as competncias tcnicas necessrias, e comportamentais tambm, para trabalhar nele. Criar e preencher uma matriz, como a do exemplo do quadro 2.1, ajuda a perceber os perfis e como distribuir os papis. Olhando para a matriz temos a tendncia a eleger o profissional F
84
como lder da equipe, pois tem experincia e dispe de tempo, enquanto o profissional D novo na empresa, e isso pode gerar algum desconforto. Em domnio tcnico vemos que os profissionais B e E so capacitados, mas no dispem de tempo livre (podem estar engajados em outros projetos), e a alternativa ser discutir com eles as possibilidades de rearranjo de trabalhos.
Perfil e necessidades Membro da equipe Profissional A Profissional B Profissional C Profissional D Profissional E Profissional F Quadro 2.1 Matriz de perfis e competncias profissionais Fonte: Elaborao do autor (2006). X X X X X X X X X Conhecer Conhecer Conhecer tecnologia tecnologia tecnologia 1 2 3 X X X Dominar uso de X X X X X X X Exp. de Exp. de trabalho trabalho em equipe em equipe Disp. de tempo X X Novo na empresa
Seo 3 Treinamento
A educao anterior ao treinamento. Para que haja algum treinamento necessrio que os membros da equipe tenham uma educao prvia e apropriada.
A formao do conhecimento e a aprendizagem passam pela anlise crtica e pela reflexo, prprias do ser humano, enquanto que o treinamento para atividades rotineiras pode ser feito at mesmo com animais.
No incio da revoluo industrial foi necessria mo-de-obra treinada para operar mquinas, e tal operao passava por uma repetio contnua de procedimentos. Muitas crticas foram dirigidas a tais atividades, que de alguma forma se repetem at hoje, especialmente nos pases em processo de industrializao.
85
Nessa poca foi criado o Senai, at hoje responsvel por treinamento de mo-de-obra para esse tipo de indstria.
Esse ambiente de incio de industrializao teve espao no Brasil mais ou menos no meio do sculo passado, quando grandes indstrias de base foram criadas. Nosso pas, de certa maneira, no evoluiu muito desse ambiente de indstrias bsicas, processadoras de matria-prima, e facilmente se percebe isto vendo a importncia econmica que tais empresas tm entre as 500 maiores. Indstrias da era da informao (que exigem mais educao do que treinamento) ainda so incipientes, ao contrrio do que acontece na Europa ou Amrica do Norte.
Considerando que estamos aqui estudando projetos de desenvolvimento e inovao, o treinamento cabe como complemento e ajuste para a equipe.
Veja o exemplo de matriz do quadro 2.1. Precisamos de algumas competncias especficas de tecnologias para o desenvolvimento do projeto, alguns treinamentos sero necessrios para uniformizar os conhecimentos dos membros da equipe. Isso deve estar no foco da gerncia do projeto, para evitar que o desconhecimento tcnico seja empecilho ou fator de risco. Mas se o projeto for de longo prazo, melhor criar alternativas de educao em grupo do que meros treinamentos de curta durao, cuja funo atender objetivos bem definidos e de alcance imediato. Ainda na matriz do quadro 2.1, se observa que h perfis desejveis e que, aparentemente, no so preenchidas pelos seus membros (como liderana, por exemplo). Ultimamente tm tido nfase os treinamentos para lderes, e tenho visto nas empresas o interesse (superficial em muitos casos) de oportunizar o surgimento de lideranas. Treinamentos so criados para esses casos, e gerentes so envolvidos neles. A liderana , no entanto, mais uma questo de comportamento e atitude do que de tcnica. O incentivo a esse surgimento deve passar por um ambiente que estimule a liberdade de expresso e experimentao.
86
Treinamentos so feitos para tecnologias, no para comportamentos.
Seo 4 Responsabilidades e diviso de tarefas

Em um projeto as atividades so divididas ao mximo, como voc viu na composio de Diagramas de Gantt, unidade 4. A diviso das atividades feita para se ter clareza dos objetivos e para perceber as entregas parciais. Tambm no Diagrama de Gantt atribumos tarefas para os membros da equipe e, assim, cada um enxerga suas metas e seus prazos. Atividades diferentes para pessoas diferentes. A distribuio de responsabilidades ser feita de acordo com o modelo adotado pela gerncia do projeto. H gestores que centralizam em excesso as decises, e outros que delegam. O equilbrio depender bastante do seu perfil, assim como da acomodao dos membros da equipe. Segundo Page-Jones (1990), prioridades so para gerentes, no para funcionrios. Com isso ele quer afirmar a distribuio de responsabilidades conforme o papel de cada um na equipe. Para a gerncia do negcio a meta o resultado global e a satisfao do cliente, enquanto para o desenvolvedor a meta a entrega conforme a especificao da sua tarefa. Este o Modelo de Equipe definido no framework da Microsoft (MSF, 1998) quando define papis em uma equipe. Assim, para cada um, uma tarefa de cada vez. Para definir os papis e comunic-los equipe importante criar um organograma, definindo as funes e a hierarquia dos membros. H inmeras 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. Segundo Keeling (2002), h cinco estruturas tpicas de grupos de projetos:
87
1. Estruturas diferenciadas e exclusivas. 2. Estruturas hbridas. 3. Estruturas matriciais. 4. Estruturas modulares. 5. Estruturas horizontais. Vamos discutir as principais delas e ver como podem se adequar aos nossos projetos.
Estruturas exclusivas
Projetos de pequeno porte, que consigam ter seu prprio pessoal e recursos exclusivos, e tm pequena complexidade, podem montar estruturas organizacionais simples e funcionais. Esse tipo de estrutura direta em seus procedimentos e fcil de ser compreendida pelos membros da equipe. Pequenas empresas de engenharia da construo, por exemplo, trabalham desta maneira, onde o gestor do projeto trabalha com um conjunto de tcnicos e pessoas de apoio administrativo, e ele reporta diretamente ao cliente final. A figura 2.2 apresenta o diagrama desse modelo, que chamado de estrutura exclusiva porque os membros do projeto so dedicados a um projeto apenas.
Figura 2.2 Estrutura exclusiva Fonte: Elaborao do autor (2006).
88
Estruturas hbridas
Em projetos internos s empresas maiores, onde vrios projetos ocorrem ao mesmo tempo, as estruturas hbridas passam a ocorrer com maior freqncia. Veja a figura 2.3, onde um organograma tpico desse modelo de estrutura apresentado. O gestor do projeto conta com membros dedicados exclusivamente quele trabalho, mas precisa paralelamente recorrer a outras pessoas, que no estaro dedicadas a esse projeto, mas que so 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 no lhe permitida, o que levar o projeto a atrasos e disperses.
Figura 2.3 Estrutura hbrida Fonte: Elaborao do autor (2006).
Estruturas matriciais
Estruturas matriciais so bem mais complexas e exigem grande maturidade de trabalho, tanto por parte da empresa quanto por parte dos membros das diversas equipes. A figura 2.4 apresenta esse tipo de estrutura, onde vemos que diversos projetos ocorrem ao mesmo tempo, sendo que os membros fazem parte das reas
89
da empresa, e no dos projetos exclusivamente, ou seja, cada funcionrio est inserido em determinado setor da empresa e executa servios que atendem ora a um projeto, ora a outro. Algum estar responsvel 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 est alocado a um determinado setor/departamento da empresa. Sem dvida a coordenao desse tipo de estrutura mais complexa, e exige alto grau de organizao geral da empresa, especialmente em relao aos planos de produo.
Figura 2.4 Estrutura matricial Fonte: Elaborao do autor (2006).
Estruturas modulares
Estruturas modulares ocorrem quando, dentro da empresa, h grupos com relativa autonomia e determinada especializao, que realizam determinado tipo de servio. O gestor de determinado projeto emprega esse grupo modular para desenvolver parte do projeto, e vai distribuindo assim as atividades conforme as especializaes. Internamente o grupo (ou mdulo de desenvolvimento) tem autonomia para gerenciar aquela etapa,
90
sendo que o gestor geral do projeto percebe a entrada e a sada do mdulo, mas no propriamente o que acontece em seu interior. Projetos de software, por exemplo, envolvendo grandes equipes com diferentes conhecimentos, podem usar esse tipo de estrutura.
Figura 2.5 Estrutura modular Fonte: Elaborao do autor (2006).
Estruturas horizontais
As estruturas horizontais geralmente so formadas por poucos membros, onde h uma grande maturidade no trabalho em conjunto. As relaes se do em rede, onde todas as pessoas se relacionam com todas as outras. O lder do grupo tem a funo 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 renem especialistas e, por esse motivo, o lder geralmente tambm um especialista tcnico ou cientfico, de tal forma que sua ascendncia sobre o grupo seja inequvoca. A figura 2.6 mostra exemplo de configurao de uma estrutura horizontal. O modelo de desenvolvimento de aplicativos da Microsoft (MSF, 1998) tambm se baseia nesse modelo horizontal, definido por pequena equipe de pares ou especialistas trabalhando em papis multidisciplinares e interdependentes. A questo da multidisciplinaridade, que surge
91
aqui, tem especial interesse em projetos de inovao tecnolgica, como no caso dos aplicativos. O ambiente proporcionado por uma estrutura horizontal permite os dilogos constantes e a troca positiva de idias, nascedouro de solues criativas.

Figura 2.6 Estrutura horizontal de equipe de projeto Fonte: Elaborao do autor (2006).
Seo 5 Terceirizao
A palavra terceirizao entrou na moda h uns dez ou vinte anos atrs, e foi uma soluo adotada na indstria para otimizar seus modelos de produo. Basicamente consistia em contratar partes da produo com empresas externas, ou terceiras, em vez de produzir com equipes prprias. Com isso era possvel obter uma concentrao de esforos, dentro da empresa, em atividades e conhecimentos que lhe eram prprias, no sendo necessrio desenvolver competncias diversas.
92
O uso de empresas de transporte foi uma terceirizao do servio de entregas, por exemplo. A terceirizao caminhou cada vez mais para dentro das empresas e, ento, partes do produto passaram a ser feitas por outras empresas (por exemplo, as peas diversas de um carro. E por isso que as fbricas de automveis so chamadas hoje de montadoras. Mas isso implicou tambm um enorme esforo de controle de qualidade e de prazos de entrega, pois uma parte do processo que falhasse comprometia todo o conjunto. Veio do Japo ento a expresso just in time, para significar os procedimentos de entrega no prazo exato. Com o passar do tempo percebeu-se que a terceirizao poderia avanar muito mais, pois fabricar pedaos de ferro e mont-los no era o segredo de uma empresa, e sim a concepo, o desenho, a inteligncia da criao do produto. A partir disso uma cadeia imensa de pequenos fabricantes se estabeleceu, e hoje muitos esforos dos governos por trazer grandes empresas se do pela inteno de formar cadeias produtoras ao redor delas.
No entanto, estamos falando de terceirizao de tarefas contnuas da indstria, enquanto que no caso dos projetos, a idia um pouco diferente, por se tratar de servios de durao limitada e com objetivos pr-definidos.
A terceirizao tem sido utilizada para ganhar produtividade, para ganhar tempo, para colocar especialistas fazendo as especialidades. Em projetos a produtividade est relacionada ao prazo. Para que seja possvel a terceirizao, necessria uma sincronizao muito forte entre o trabalho que est sendo executado pela equipe interna do projeto e a equipe ou pessoa que ficar responsvel pelo trabalho externo, ou terceirizado. A estrutura modular, mostrada na figura 2.5 anteriormente, uma possibilidade de trabalhos desse tipo, pois cada grupo ou mdulo, pode ser visto como uma unidade independente que tem uma determinada tarefa a cumprir. Identificar as competncias de tais grupos e ter os trabalhos alinhados entre os diferentes grupos o desafio.
93
A indstria da construo civil j atingiu essa maturidade para a terceirizao de servios de um projeto. Equipes de empreiteiros diversos, grupos externos de eletricistas e tcnicos hidrulicos, entre outros, atuam como terceirizados no projeto. Isso funciona adequadamente porque a indstria da construo civil repete os procedimentos obra aps obra, e cabe ao engenheiro da obra fazer a gesto desses diferentes grupos.
Mais recentemente a indstria de software tem trazido exemplos de terceirizao.
Metodologias como o do PMI Project Management Institute (PMBOK, 2004), modelos como o CMM (Capability Mature Model) e linguagens com a UML (Unified Modeling Language), vm trazendo um alto grau de profissionalizao para o setor de software, fazendo com que haja uma segmentao bem delimitada na produo dos aplicativos. Isso vem gerando grandes debates nos Estados Unidos, pois muitas atividades consideradas estratgicas nessa indstria passaram a ser terceirizadas em outros pases, especialmente ndia e China, que competem utilizando mo-de-obra qualificada, porm muito mais barata do que a americana. So os efeitos da globalizao numa indstria que no precisa mais do que uma rede como a internet para fazer todo o transporte das partes e peas terceirizadas. Para encerrar esse assunto, veja os dois quadros reproduzidos abaixo, onde o primeiro aponta para o aumento dos contratos de terceirizao, publicado no site da ASSESPRO SC, e o segundo com a matria publicada no site da SOFTEX, que reproduz texto a respeito dos riscos da terceirizao apontados pela empresa de consultoria Gartner dos Estados Unidos. Esse um assunto bastante atual e que dever perdurar nos debates devido ao processo de globalizao acelerado dos mercados, especialmente os ligados s inovaes tecnolgicas e informao.
94
Terceirizao de software e servios de TI cresce

Mercado mundial de terceirizao dever crescer 7,9%. De acordo com um estudo do Gartner esse percentual corresponde aos anos de 2003 a 2008. A terceirizao continua crescendo em todo o mundo, embora em ritmo diferente, em relao regio analisada, de acordo com estudo do Gartner. A taxa Composta de Crescimento Anual (CAGR) de terceirizao ser de 7,9%, entre 2003 e 2008, enquanto a taxa total de crescimento de TI atingir 5,4%. Os gastos com terceirizao de TI e terceirizao de processos de negcios (BPO), em mbito mundial, crescem mais rapidamente do que os gastos com servios individuais e aqueles baseados em projetos. Isso reflete uma tendncia de crescimento da terceirizao, que vai alm do mero gerenciamento de sistemas e processos j implementados. As empresas terceirizadas esto assumindo cada vez mais as responsabilidades de desenvolver e oferecer novos sistemas e processos, bem como seu gerenciamento. De acordo com estudo existem dois fatores que impulsionam o avano do mercado de servios em regies diferentes: o primeiro refere-se cultura local e s prticas de negcios; e o segundo, diz respeito aos padres estabelecidos pelas grandes companhias globai s que compem o mercado. Sobre a situao do mercado local, o Brasil e o Mxico so os lderes em terceirizao na Amrica Latina, seguidos do Chile e da Colmbia.
Quadro 2.2 Sobre o aumento da terceirizao Fonte: Softex (2005).
95
Gartner aponta riscos da terceirizao offshore

Por COMPUTERWORLD Empresas de todo o mundo gastaro mais de 50 bilhes de dlares com iniciativas de terceirizao offshore (fora do pas) ou nearshore (dentro do pas) de TI at 2007, aponta a consultoria Gartner. No entanto, alerta a companhia em um novo estudo, muitos projetos falharo devido a planejamentos mal estruturados. Muitas companhias tm buscado nas estratgias de terceirizao de TI uma forma de obter vantagem competitiva frente aos concorrentes, seja com reduo de custos ou aumento de produtividade. Mas estes objetivos podem ser seriamente comprometidos por diversos fatores. Em seu estudo, o Gartner selecionou os cinco maiores riscos que podem comprometer o sucesso da terceirizao, seja esta feita por meio de um parceiro local ou por um especializado de outro pas. 1. Reduo de custos impraticvel Muitas companhias decidem buscar servios em outros pases, com o propsito de reduzir custos. Segundo o Gartner, um profissional de manuteno de aplicaes indiano, por exemplo, ganha cerca de 25 dlares por hora, contra a mdia de 87 dlares cobrados pelo mesmo servio, nos Estados Unidos. Contudo, um erro limitar os custos da operao apenas ao salrio do funcionrio. A consultoria alerta para outros gastos atrelados a fatores como infra-estrutura, comunicaes, viagens e treinamento relacionado a questes culturais. Portanto, o custo inicial da operao alto e, em muitos casos, pode ser mais rentvel aps um ano de operao. 2. Perda de produtividade Pelo menos inicialmente, os prestadores de servios offshore tendem a no apresentar a mesma produtividade que a companhia mantinha internamente. De acordo com o Gartner, em mercados emergentes muitos programadores so jovens e no possuem a mesma experincia que a companhia encontra em seu pas de origem.
96
3. Comprometimento e comunicao enfraquecidos Muitos executivos simplesmente esquecem seus contratos depois que so assinados. A consultoria alerta para a necessidade de se estar engajado com o prestador de servios para que se mantenha a qualidade de servios pr-acordados. Estabelecer uma boa comunicao entre as partes crucial, definindo claramente projetos, objetivos e expectativas. Dentro de casa, o diretor de tecnologia tem que deixar muito claro porque mandar as operaes para outro pas traz mais benefcios para a companhia. 4. Diferenas culturais Estilos de comunicao e atitudes de autoridade mudam conforme a regio e estas diferenas podem trazer problemas. Em algumas culturas, o ato de questionar a autoridade de determinada pessoa considerado falto de respeito. Empresas interessadas na terceirizao offshore devem realizar treinamento entre equipes para evitar esse tipo de situao, alerta o Gartner. 5. Distncia entre teoria e prtica Algumas organizaes podem vender mais do que realmente oferecem. preciso que o prestador de servios tenha todos os processos internalizados com suporte e segurana, antes de colocar um projeto em operao. O Gartner tambm destaca para a necessidade de se verificar o grau de maturidade dos processos da empresa, utilizando padres reconhecidos de mercado como o CMM, do Software Engineering Institute. Fraquezas nesta rea podem se transformar em projetos mal-sucedidos.
Quadro 2.3 Problemas da terceirizao Fonte: Softex (2005).
97
Sntese
Nesta unidade voc estudou os princpios da estruturao de uma equipe de projeto. O conceito fundamental, muitas vezes repetido e exemplificado, o do trabalho cooperativo. A cooperao Inicialmente foram apresentados os quatro passos que se do na formao das equipes de projeto: o perodo inicial da formao, seguido muitas vezes de um ambiente turbulento, quando os primeiros subgrupos se formam e h distncias a romper, depois o perodo onde as normas de trabalho se impem e a liderana institui uma normalizao, seguido ento do perodo de desempenho cooperativo e onde, de fato, os resultados comeam a aparecer. Depois vimos que os perfis so muito variados, e tambm so dinmicos, ou seja, as pessoas tm comportamentos diferentes conforme o meio em que esto. Para dividir as tarefas e encontrar os perfis corretamente, uma tcnica interessante preparar uma matriz de competncias, conforme vimos exemplo no quadro 2.3. Com essa matriz possvel estudar diferentes composies de pessoas na equipe. Ajustes de competncias tcnicas e de habilidades de trabalho podem ser feitas, dessa forma, por meio de treinamentos. Mas importante destacar que o treinamento ser eficaz se as pessoas da equipe tm uma educao de base adequada. Nisto que se diferencia o treinamento da educao. Para organizar o grupo de trabalho em diferentes tarefas, cinco modelos estruturais foram apresentados:
98
1. Estruturas diferenciadas e exclusivas, com pessoas dedicadas exclusivamente ao projeto; 2. Estruturas hbridas, onde h uma composio de dedicaes exclusivas e outras parciais; 3. Estruturas matriciais, em que pessoas de uma organizao trabalham em difentes projetos simultaneamente, conforme suas habilidades, sendo que o gestor do projeto o responsvel por administrar essa locao e os resultados parciais, 4. Estruturas modulares, formadas por pequenos grupos dedicados a sub-projetos, os quais podem colaborar para um projeto ou vrios, e; 5. Estruturas horizontais, geralmente em projetos pequenos e que envolvem pares de especialistas, os quais no tm um comando central.
Esses modelos podem ser ajustados caso a caso, e dependero da experincia e liderana do gestor para que obtenham o desempenho desejado. Por fim, esta unidade tratou da terceirizao como uma variao a mais dos modelos estruturais anteriores. A terceirizao vem se expandindo em todas as atividades produtivas e alcana tambm os processos de trabalho relacionados a projetos. No caso do desenvolvimento de tecnologias da informao h apreenso, pois a terceirizao tem deslocado os servios para regies remotas, que tm preocupado tanto no sentido da perda de empregos quanto na perda do controle do conhecimento como do prprio andamento do projeto.
99
1) Quais so as quatro fases de estruturao da equipe e, em sua opinio, qual a mais problemtica? Por que a fase escolhida a mais problemtica?
2) Como uma matriz de perfis e competncia pode ajudar na estruturao de uma equipe?
3) Em sua opinio, qual tipo de estrutura de equipe melhor se ajusta ao desenvolvimento de software em uma pequena empresa, cujos projetos so iniciados apenas sob a demanda do cliente?
100
4) Qual o modelo de estrutura representado na figura abaixo? Qual o seu grande problema?
5) Em que tipo de estrutura possvel uma grande troca de conhecimentos, sendo que as pessoas trabalham entre pares? Qual a vantagem desse tipo de estrutura na indstria de softwares?
101
6) Como voc avalia os riscos da terceirizao na rea de software?
Saiba mais
Veja a dissertao de mestrado de Leandro Patah, Alinhamento estratgico de estrutura organizacional de projetos: uma anlise de mltiplos casos. Este trabalho foca em diversos tipos de estrutura, especialmente a matricial, e trar conhecimentos aprofundados sobre o tema. Entre novamente no site da SOFTEX e veja os estudos sobre terceirizao, bem como o estudo comparativo entre as indstrias de software no Brasil, China e ndia. H exemplos de como a terceirizao alavancou a indstria indiana, por exemplo.
102
UNIDADE 3
Executando o projeto
Compreender aspectos do incio de um projeto e como o seu bom entendimento permite a gerncia e o controle eficaz da qualidade. Perceber as diferenas bsicas entre lderes e gestores. Estudar tcnicas e prticas para controle de prazos e recursos, encontros de trabalho e gesto de conflitos. Verificar as vrias subdivises e etapas intermedirias que um projeto de sucesso demanda.
Sees de estudo
Seo 1 Preparao e incio dos trabalhos Seo 2 Liderana versus gesto Seo 3 Tomada de decises Seo 4 Motivao e comunicao Seo 5 Reunies Seo 6 Gerenciando qualidade, tempo e recursos Seo 7 Gesto de conflitos Seo 8 Simulao, testes e validao

Tendo uma srie de ferramentas e prticas de planejamento em mos, estudadas anteriormente, chegamos ao dia-a-dia de trabalho do projeto. Neste momento teremos que colocar em prtica o planejamento, e novas dificuldades certamente surgiro. Esta unidade apresenta questes prticas relacionadas com o incio do projeto, com os possveis conflitos advindos do choque entre pessoas da equipe com variados perfis, bem como as caractersticas do gestor do projeto para tratar tais conflitos e dificuldades. Em especial debatido o perfil do gestor quando comparado com o do lder, assunto que vem tomando parte de muitos debates sobre desenvolvimento tecnolgico e inovao j que tais diferenas de perfis podem afetar positiva ou negativamente o desenvolvimento do projeto e mesmo dificultar a administrao de conflitos, por exemplo. Tambm nesta unidade tratado o tema das simulaes e testes de reviso contnua, assunto que foi abordado anteriormente quando se defendeu a necessidade de segmentar o projeto em pequenas etapas e atividades, facilitando a busca, durante a fase de desenvolvimento do projeto, de conquistas parciais. Tais conquistas parciais que garantem, como veremos aqui, o resultado positivo esperado do projeto. Bom estudo!
Seo 1 Preparao e incio dos trabalhos

At agora j falamos muito sobre planejamento, sobre estimativas de recursos, anlise de riscos, formao de equipes de trabalho e muitas outras coisas, mas chegou a hora de colocar a mo na massa, ou seja, de fazer as coisas acontecerem. s vezes pode parecer que se perde muito tempo com planejamento, que o certo ir direto ao assunto e j sair produzindo. Esse o risco que correm todos os inexperientes (e muitos experientes tambm). Na realidade, a produo em projetos uma decorrncia do planejamento, pois como j foi dito vrias vezes, o projeto um trabalho com data marcada para acabar, enquanto as atividades
104
de produo de rotina no tm tal finalidade e as pessoas entram no trabalho de uma empresa ou indstria, por exemplo, quando as coisas j esto acontecendo. Outro fator importante e, por isso, aparentemente tanta preparao, que em um projeto preciso sempre ter a viso do conjunto e no apenas das partes. Tendo realizado tal planejamento, previsto os recursos disponveis e tendo os objetivos claros e o contrato estabelecido junto ao cliente, hora de comearmos os trabalhos. Para preparar e comear o projeto interessante voc considerar as seguintes observaes:
muitas pessoas imaginam que trabalhar em um projeto comear imediatamente a programar, ou a perfurar, ou a martelar, ou seja l o que for que parea demandar muito esforo. Dessa forma, a energia despendida logo no comeo e, na maioria das vezes por no se saber onde se quer chegar, rapidamente tudo esvaece e o projeto perde, ento, o sentido;
trabalhar em um projeto no despender um enorme esforo em direo a um objetivo desconhecido, para aparentar que o suor faz o trabalho. Projeto, necessariamente, exige reflexo;
muitos pensam que algum tem que dar as ordens e que esse algum que tem todo o projeto na cabea, bastando seguir seus passos. Provavelmente h um algum responsvel e lder num projeto, no entanto esse responsvel certamente no tem o projeto todo na cabea;
no existe um ser sagrado que sabe tudo sobre o trabalho a ser realizado, e o responsvel depende inteiramente da sua equipe;
como o projeto uma atividade inerentemente coletiva, fundamental que haja o esprito do trabalho cooperativo;
no h como fazer projetos com algum nvel de complexidade sem a participao criativa e positiva de vrias pessoas. vi recentemente um grupo de
105
projetistas que inventou uma espcie de jogo em rede de computadores, uma espcie de gincana, em que eles brincavam de colocar partes do projeto num diretrio comum, e a vitria era cumprir tal demanda num prazo cada vez mais curto era uma brincadeira que fazia do projeto uma diverso em forma de game! O incio de um projeto deve acontecer com uma reunio. Nessa reunio o escopo do projeto deve ser exposto com a maior clareza possvel, os detalhes devem ser discutidos at a exausto, o plano de produo deve ser detalhado, as tarefas divididas e as responsabilidades atribudas. neste momento que o fluxograma geral (lembra do algoritmo do projeto?) deve ser apresentado, discutido e suas cpias distribudas. A comunicao dos procedimentos, j discutidos aqui, deve ser feita a partir dessa reunio de contato inicial. Geralmente as reunies so muito mal vistas. Por qu? Algumas pessoas pensam que reunies so chatas, que no dizem nada, que o chefe senta na extremidade da mesa apenas para mandar. Essa uma viso de reunies normalmente veiculadas em filmes e novelas. Podemos imit-las e ento ter pssimas reunies ou ento optarmos em seguir um caminho muito mais objetivo e perceber que reunies so timos momentos para fazer o trabalho, de fato, andar rumo ao sucesso. As reunies sero interessantes se:
tiverem uma pauta bem definida; a pauta no for extensa; os assuntos forem claros e de conhecimento dos presentes; o horrio de comeo e fim forem bem definidos; forem suficientemente breves; (as CPIs do governo so longas e repetitivas, mas no so reunies, percebe?) houver um coordenador, capaz de gerenciar as falas entre os diversos presentes; houver um lder, capaz de decidir quando for necessria uma deciso.
106
H empresas que fazem tantas reunies que as algumas pessoas chegam a pensar que trabalhar participar de reunies e, outras pessoas pensam que a pior coisa do mundo uma reunio. Nem uma nem outra est correta. Provavelmente, nestas empresas as reunies esto sendo mal conduzidas. Depois da fase de reunies iniciais o projeto tem, ento, seu comeo. Os grupos de trabalho esto com suas atividades definidas, prazos estabelecidos e resultados por alcanar. Resta cumprir as etapas, j estabelecidas no Grfico de Gantt do projeto. Se o planejamento foi bem feito, h uma definio bem clara de objetivos e atividades e, possivelmente, com sub-etapas de prazos curtos.
A Microsoft, por exemplo, trabalha com uma orientao designada como zero-defeito com prazos curtos de entregas intermedirias como objetivo de maior desenvolvimento (MSF, 1998). Assim que comeam os trabalhos de desenvolvimento, a mentalidade de uma entrega a cada dia estabelecida entre todos os membros da equipe. Com isso, h a sensao comum de que os projetos devem andar e que devem estar no prazo. Na Microsoft o gerente de projeto Chris Peters considera que a atividade de um projetista no simplesmente colaborar no projeto para que ele chegue ao resultado final. Ele considera que cada projetista, ao comear seu trabalho, deve estar pensando em entregar. Leia o seguinte pargrafo e pense nisso: Todos [os projetistas] tm o mesmo trabalho. Eles tm exatamente a mesma descrio de trabalho. E esta entregar (embarcar) produtos. Seu trabalho no escrever cdigo. Seu trabalho no testar. Seu trabalho no escrever especificaes. Seu trabalho entregar produtos. Isto o que um grupo de desenvolvimento faz. Seu papel como um desenvolvedor ou como um testador secundrio. No estamos dizendo que no so importantes mas so secundrios para seu trabalho real, o qual entregar um produto. Quando voc acorda cedo de manh e vem para seu trabalho, voc diz, Qual o focoestamos tentando entregar ou estamos tentando escrever cdigo? A resposta : ns estamos tentando entregar. Voc no est tentando escrever cdigo. (MSF, 1998)
107
Este pargrafo elucida sobre a atitude esperada de um projetista ao participar de um grupo de trabalho. com este foco que o trabalho deve ser iniciado.
Seo 2 Liderana versus gesto

Conforme voc estudou anteriormente na unidade 5, foram ressaltadas diferenas entre as atitudes da liderana e da gesto, sendo dados, por brincadeira, os exemplos do gestor-rinoceronte, gestor-cobra e gestor-raposa. Agora hora de falar um pouco mais srio sobre o assunto. Estamos muito mais acostumados a trabalhar com gestores, ou gerentes, do que com lderes. A funo da gerncia tem sido muitas vezes confundida com uma espcie de atuao por cobrana e controle que coloca os gerentes numa condio de animosidade com seu grupo de gerenciados. Ou seja, aqueles que ficam submetidos ao gerente se sentem diminudos e perdem, geralmente, a motivao do trabalho criativo. Muitas vezes isso, de fato, acontece. Voc, com certeza, deve conhecer casos ou mesmo gerentes que se sentem muito satisfeitos em simplesmente mandar. H os gestores que tm ojeriza por liderana, pois vem na figura do lder uma espcie de ser sagrado que detm a verdade. possvel que essa imagem falsa tenha origem de duas fontes: a primeira a mitologia criada sobre lderes carismticos, que levam as pessoas a fazer coisas que normalmente no fariam; a segunda que esse tipo de gestor no consegue cumprir funes muito mais simples, essas sim dos lderes, como tomar decises, se arriscar mais e apoiar verdadeiramente cada um dos membros de sua equipe. A ojeriza acaba se dando por no conseguirem cumprir nenhum dos dois papis. No assumem a figura carismtica por no concordarem ou no se adaptarem a ela. Tambm acabam no assumindo a funo de liderana objetiva e criativa por no terem a habilidade de relacionamento humano necessria. Com esse distanciamento, acabam manifestando uma ojeriza generalizante, denegrindo todos os tipos de liderana.
108
No entendimento de Page-Jones (1990) so as seguintes as qualidades de um gerente de projetos:
integridade pessoal, sensibilidade, capacidade de estabelecer objetivos, capacidade de cumprir objetivos, tenacidade, capacidade de inspirar, disposio de servir, coragem de delegar, competncia tcnica, capacidade para comunicar a realidade, capacidade de pensar e ser inovador, coragem de tomar decises.
Estas caractersticas cabem perfeitamente para os lderes, especialmente as qualidades de inspirar, ser inovador e ter coragem de tomar decises. Nem sempre os gerentes so inspiradores, inovadores e decisores e, mesmo assim, so timos gerentes, pois so capazes de coordenar os prazos e distribuir tarefas adequadamente e os membros da equipe confiam nele para conduzir o trabalho at o final. Em seu livro sobre gerenciamento de projetos, Valeriano (1998) cita Denis Donaire, este considera que os atributos desejveis em um gerente esto divididos em trs grandes reas: conhecimentos, habilidades e atitudes. O detalhamento dessa diviso o seguinte:
109
a) Conhecimentos desejveis
Em relao ao conhecimento organizacional o gestor necessita: a) ter conhecimento do sistema administrativo e financeiro da organizao onde trabalha; b) conhecer o funcionamento do sistema de RH (recursos humanos) e como se do as relaes jurdicas com relao aos funcionrios e terceirizados da empresa; c) prticas, polticas e valores, que a percepo clara de perceber como funciona a organizao em suas prticas no dia-a-dia, a poltica interna das relaes e por quais valores se orientam aqueles que trabalham nela; d) ter conscincia do custo e das implicaes das decises tcnicas; o que implica reconhecer as relaes entre as aes e o que isso significa no tocante aos gastos no projeto e para a empresa; e) ter conhecimento das atividades econmicas da organizao, dos seus produtos, misses e mercados ou clientes da organizao, que significa um conhecimento profundo das atividades econmicas da organizao.
Em relao ao conhecimento tcnico, o gestor necessita: a) conhecer reas correlatas especializao de que trata o projeto, com uma viso geral das competncias tecnolgicas; b) ter competncia tcnica em pelo menos uma rea de especializao; c) ter domnio de mtodos de pesquisa, que permitam relacionar os diversos membros da equipe em um desenvolvimento equilibrado e voltado a resultados.
110
b) Habilidades desejveis
Em relao s habilidades de comando o gestor necessita: a) ter a capacidade (e isso deve ser perceptvel) de planejamento, organizao e controle das atividades do projeto; b) desenvolver sua capacidade de liderana (pois consideramos que a capacidade de liderar inata a todas as pessoas); c) capacidade de auto-anlise, ou seja, constantemente fazer a auto-crtica das suas atitudes, dos seus conhecimentos e das necessidades de aprimoramento tcnico; d) capacidade de alocao de recursos que advm do conhecimento dos recursos disponveis e daqueles que sero necessrios buscar no desenvolvimento do projeto; e) capacidade de gerar confiana no superior e isso se d pela integridade e pela segurana ao trabalhar orientado a resultados; f) perceber e escolher o estilo de liderana adequado a equipe de trabalho, o tipo de projeto e do cliente contratante, seja externo ou um superior da empresa; g) habilidade de tomada de decises, condio essencial numa funo de comando (o gerente que no toma decises considerado fraco por sua equipe, o que desmotiva o grupo).
Outras habilidades: a) trabalhar em equipe, habilidade esta que j comentamos muitas vezes ao longo deste livro e que est relacionada capacidade de cooperar e gerenciar conflitos;
111
b) criatividade, especialmente na soluo de problemas inesperados e distantes daqueles que foram avaliados como riscos inerentes ao projeto, sendo que a criatividade tambm est relacionada habilidade de manter dilogos constantes com os membros da equipe e com a inspirao motivacional, gerando idias diferentes das convencionais; c) capacidade de redigir com clareza, preciso e conciso, habilidades relacionadas capacidade de se comunicar, necessria para o andamento do projeto de forma coordenada e racional; d) relacionamento pessoal, habilidade relacionada ao dia-a-dia do trabalho em equipe, s atitudes de educao na convivncia (infelizmente no nada difcil encontrarmos gerentes que se dirigem aos membros de sua equipe aos berros).
Sobre o relacionamento pessoal temos um caso interessante: disse certa vez numa reunio de gerentes que eu no aceitaria trabalhar numa empresa onde os chefes se acham no direito de humilhar seus funcionrios, e os resultados foram dois: primeiro, fui estigmatizado por tais gerentes e sado da empresa um tempo depois; segundo, a empresa surpreendentemente entrou na lista da revista Exame como uma das melhores para se trabalhar (!!), e at hoje no entendo se os funcionrios mentem nas entrevistas ou se tais listas so arranjadas.
c) Atitudes
Posicionamento em relao a aspectos internos e externos: a) interesse por questes administrativas, que implicam conhecer e se posicionar em relao aos diversos aspectos do trabalho, na empresa e no projeto, mesmo que no sejam suas funes as atividades executivas da administrao empresarial;
112
b) disciplina de trabalho, que envolve ao mesmo tempo a dedicao produtiva diria ao prprio trabalho e, na sua condio de gestor, do exemplo aos membros da equipe de que a disciplina a geradora da produo e do resultado; c) entrosamento com pessoal externo organizao, pois isso essencial para realizar as interfaces de negociao de requisitos, solicitao de recursos extraordinrios, verificao de pendncias, soluo de conflitos diversos etc.; d) ambio profissional, que necessria para o crescimento tanto do indivduo quanto do seu grupo de projeto; ambiente sem ambio de crescimento e sucesso desmotivador.
Estratgias de ao: a) hbito de comear o ataque ao problema pela reviso da literatura, pela reviso dos projetos da mesma rea que o antecederam, seja na empresa ou outros locais e, principalmente, a capacidade de exercitar sempre uma viso geral do problema e do ambiente de negcios onde o projeto est envolvido; b) hbito de leitura sistemtica de textos tcnicos, pois com isso h atualizao constante em relao s inovaes tecnolgicas e gerao de novas idias, ponto fundamental para lanar novos projetos, como os discutidos na unidade 1 deste livro.
Essas so consideraes gerais sobre gerncia, mas o que defendemos como principal para o sucesso de um projeto a atitude da liderana. Nos tpicos citados anteriormente, a maioria das atribuies que voc estudou serve tanto para gerentes quanto para lderes enquanto outras so caractersticas especficas da liderana. preciso que voc entenda que as caractersticas de lder so inerentes a todos ns mas, em geral, no so estimuladas nos indivduos em uma sociedade que procura, de certa maneira, uniformizar procedimentos e atitudes. Tal uniformizao (ou mediocrizao) pode ser considerada uma doena que afeta o nosso desenvolvimento como indivduos e, por conseqncia, como
113
sociedade. No o caso de dizer que todos devem ser lderes em todas as atividades, mas sim, que saibamos nos posicionar sempre em que tal comportamento de liderana se faa necessrio. A liderana implica tambm o discernimento da compreenso do momento em que precisamos ser parte de um grupo onde j h um lder no qual devemos depositar confiana no trabalho. Stephen Covey (2005) criou uma tabela que relaciona diferenas entre liderana e gerncia e, no quadro abaixo, apresento uma adaptao de tal tabela de acordo com os conceitos desenvolvidos para este livro:
LIDERANA Interessado nas pessoas Trabalha na espontaneidade Liberao e fortalecimento das idias Eficcia Prefere planejar e programar Considera gasto como investimento Trabalha baseado em princpios Procura transformao Poder centrado em princpios Procura resolver por discernimento Fazer a coisa certa Resolve baseado numa direo Pensa numa linha superior Tem propsitos Decide baseado em princpios Busca algo acima das coisas Para o lder a pergunta : a escada est junto da parede certa? Quadro 3.1 Diferenas entre Liderana e Gerncia Fonte: Adaptado de Covey (2005). GERNCIA Interessado nas coisas Trabalha com a estrutura Controle das atividades e das idias Eficincia Prefere trabalhar sob um programa Considera gasto como despesa Trabalha baseado em tcnicas Procura transao Poder centrado em utilidade Procura resolver por medio Fazer certo as coisas Resolve baseado em rapidez Pensa em resultados Tem mtodos Decide baseado em prticas Busca algo dentro dos sistemas Para o gestor o que importa : subir rapidamente a escada
114
Especificamente sobre lideranas, Christenson (2004) avana ainda mais sobre seus conceitos dividindo-as em quatro diferentes tipos, descritas abaixo: 1. a que considera os indivduos, ou seja, capaz de estimular as pessoas de sua equipe e seus seguidores a terem uma viso nova de seu prprio trabalho; 2. a que estimula intelectualmente, gerando um alinhamento positivo das idias das pessoas em relao organizao e ao projeto; 3. a que influencia os ideais, ou seja, estimula seus colegas de trabalho a alcanarem altos nveis de habilidade; 4. a que motiva inspiraes, levando seu grupo de colegas a olharem alm do interesse prprio e em direo ao benefcio de todo o time. Bem, no necessrio fazer um juzo de valor sobre qual o melhor, lder ou gestor, pois os papis dependero da atividade, do tamanho do problema ou do tipo do projeto. De certa forma, os dois papis devem estar combinados (e no agir como o gestor que execrava lderes em sua organizao). Comeado o projeto, tendo um planejamento claro das atividades (veja tambm as unidades anteriores com os Diagramas de Gantt e as ferramentas PERT/CPM), consideradas as funes de liderana e de gesto, passa-se agora aos detalhes do dia-a-dia do projeto. Um dos pontos nevrlgicos de qualquer projeto a tomada de deciso, assunto da prxima seo.
115
Seo 3 Tomada de decises

Hoje uma grande parte dos textos sobre administrao empresarial dirige seu olhar para o problema da tomada de deciso.
Decidir significa escolher uma opo entre vrias e, com isso, h sempre o risco da escolha no recair sobre a melhor opo.
Um campeo de xadrez decide o melhor movimento a cada vez e seu exerccio de escolha renovado a cada nova jogada. Aquele que cometer mais decises erradas, perder o jogo. Assim tambm o goleiro na hora do pnalti: a deciso do seu movimento poder implicar ou no a defesa do gol. Sabe-se que os grandes craques de qualquer esporte, especialmente os coletivos, aliam s habilidades pessoais e de relacionamento, a capacidade de antever os movimentos do jogo e tomar a deciso que levar ao gol, ao ponto, enfim, ao sucesso.
Que milagre poderia ser esse, capaz de levar a uma deciso certa no momento certo?
Alguns traos so comuns entre esses tomadores de deciso:
experincia anterior; treino em decidir e executar (as jogadas, os chutes); o exerccio da viso ampla (do jogo); coragem de, aps um erro, calibrar os movimentos para tentar de novo at acertar.
Quem ama os esportes j viu algum desses momentos mgicos quando o atleta resolve arriscar um difcil movimento, muitas vezes num momento crtico onde a chance da derrota era enorme e, cheio de confiana, decidir uma partida.
116
Um jogo coletivo como um projeto: h um objetivo a ser atingido, o prazo est estabelecido e s possvel vencer se a equipe estiver unida e entusiasmada.
Para Page-Jones (1990) a tomada de deciso durante um projeto envolve quatro passos:
identificar possveis modos de ao e chegar a um entendimento comum do que cada opo significa; identificar as ramificaes de cada opo, incluindo vantagens e desvantagens; discutir e avaliar cada uma dessas ramificaes; escolher o modo de ao mais vantajoso e partir para ele.
Como vemos, em um projeto, h a necessidade da constante avaliao das opes possveis e disponveis e isso combinado experincia prvia do decisor, definir as prximas aes.
Seo 4 Motivao e comunicao

Em um projeto, outro fator importante para o bom andamento do trabalho, a clara comunicao para toda a equipe e interessados, sobre os objetivos, os resultados a serem alcanados e sobre como se daro todas as pequenas divises e etapas at chegar aos resultados esperados. Nesse sentido, um planejamento utilizando o Grfico de Gantt parece ser fundamental, uma vez que ele utiliza o grfico de barras ao longo de tempo e conhecido de todos. A comunicao, seja inicial ou a cada etapa do projeto, deve se dar sobre tal grfico e deve ser acompanhada da marcao sobre o j realizado e sobre o que falta realizar.
117
A comunicao clara das atividades deve ser feita a cada momento importante, tal como incios e encerramentos de etapas, mas o diaa-dia de cada etapa exige entusiasmo e motivao por continuar. Infelizmente, muitos entre ns sofrem de um mal moderno conhecido como depresso que, em geral, os impede de continuar.
Como evitar e como superar tal mal?
Parece que uma das formas de felicidade do ser humano o sentir-se til, para si mesmo e para seu meio social, assim como tambm a constante necessidade de superao de desafios. Assim, primar por uma comunicao que motive e que entusiasme o indivduo mister para se alcanar resultados positivos. Em uma pesquisa sobre a motivao para o trabalho, PageJones (1990) cita a obra de Maslow para definir as necessidades bsicas dos seres humanos e, como tais necessidades, precisam ser satisfeitas para que se sintam motivados. O quadro abaixo representa tais necessidades.
Necessidades BSICAS Nveis Fisiolgicas segurana sociais Estima auto-realizao Exemplos Fome, sono, sede no emprego, tranqilidade pertencer a grupo, famlia, amigos Sensao do trabalho bem feito desafio vencido, desenvolvimento
DE CRESCIMENTO
Quadro 3.2 Necessidades bsicas e motivao Fonte: Page-Jones (1990).
118
Pelo que voc pode observar no quadro, enquanto as necessidades bsicas parecem satisfeitas em boa parte da sociedade atual (salvo nas regies mais pobres e de maior desigualdade no pas e no mundo), o mesmo j no se pode dizer das necessidades de crescimento. Mesmo nos pases mais ricos e de maior distribuio de renda, os nveis de auto-estima e auto-realizao parecem no estar ainda bem resolvidos. Neste ponto voltamos s sees anteriores para perceber que so motivacionais as atitudes dos lderes, que se posicionam frente a desafios e que sabem valorizar o trabalho e o esforo de todos. Gestores sem tais habilidades, sem dvida, faro projetos fracassarem.
Seo 5 Reunies
Reunies... isso no lhe parece um assunto bastante pueril para um livro sobre gesto de projetos?
De fato seria, caso as reunies no tivessem assumido um papel de tortura e de desgaste para muito de ns. H empresas, especialmente as pblicas, ou alguns partidos e agremiaes polticas, que parecem se movimentar apenas por meio de reunies. Por causa disso, esses encontros de trabalho passaram a ser encarados por muitas pessoas como inteis, mas, certamente, no o so. Atribuo grande importncia s reunies de projeto, pois so momentos especiais de comunicao e deciso. So nesses momentos que os planos, as discusses e os rumos do trabalho so colocados e precisam ser enfrentados como ambientes coletivos para o desenvolvimento do prprio projeto. Para que uma reunio venha a ser bem-sucedida, Page-Jones (1990) coloca as seguintes sugestes de ao:
119
1. Antes da reunio:
o grupo de trabalho ou o gestor/lder, deve definir um lugar conveniente para a reunio; os participantes devem ser selecionados conforme o assunto em pauta e no 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 horrio, fazer ento o aviso com antecedncia; a pauta de reunio deve ser bem definida e levada aos participantes com antecedncia; o nmero de itens em pauta deve ser restrito, evitando disperso e superficialidade.
2. Durante a reunio:
deve ser designado um moderador capaz de organizar/ gerenciar as falas e questes propostas pelos indivduos do grupo; tambm deve ser designado um secretrio que anote os pontos principais discutidos, bem como, as resolues adotadas, criando ento 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, comunicao, resoluo de problemas, deciso).
120
3. Depois da reunio:
todos os itens de ao devem ser anotados e devem ser atribudas responsabilidades por item de ao; distribuir a ata da reunio.
Tenho certeza que voc, ao ler essas linhas, estar pensando em reunies em que j tomou parte e que no se seguiram tais recomendaes. Aquelas que tiveram algum capaz de conduzir as conversas talvez, tenham tido bons resultados, porm, a maioria, deve ter sido enfadonha e sem resultados, sem contar com a sensao do tempo perdido. Para o projeto de desenvolvimento de uma inovao tecnolgica, um software, um novo produto, haver, com certeza, vrias reunies e caber a cada um de ns interferir para garantir o seu bom andamento. Se a reunio no tiver pauta, solicite uma. Se a hora de acabar no estiver definida, pergunte qual .
Seo 6 Gerenciando qualidade, tempo e recursos

Gerenciar a qualidade buscar a ausncia de erros. Muitas vezes, no prestamos ateno aos erros e criamos metas de qualidade que podem ser bem baixas para nossa vida social, apesar de parecerem excelentes para a vida profissional. Leia com ateno o seguinte texto:
As pessoas foram condicionadas a acreditar que o erro inevitvel. No apenas aceitamos o erro, ns o prevemos. Quando projetamos circuitos, programamos um computador, fazemos um planejamento, soldamos conexes, datilografamos uma carta, fazemos um oramento, ou montamos componentes, no nos preocupamos se cometemos alguns erros; e a gerncia prev o acontecimento desses erros. Achamos que os seres humanos possuem um fator de erro integrado a eles.
121
Entretanto, no mantemos o mesmo padro, quando a coisa passa para o campo da vida pessoal. Se mantivssemos, aceitaramos com naturalidade receber troco errado (a menos); aceitaramos que as enfermeiras deixassem cair no cho um percentual de recm-nascidos; acharamos natural entrar na casa errada de vez em quando. Como indivduos, no toleramos esses erros. Portanto, temos dois pesos e duas medidas: um para ns e um para a empresa. A razo para isso que a famlia cria para ns padres 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, retrabalho, garantias, consertos, testes e inspees. Os erros que produzem esse desperdcio so causados diretamente pelo pessoal da empresa, tanto pelos funcionrios quanto pela administrao. Para eliminar esse desperdcio, para melhorar o funcionamento e aumentar a eficcia, precisamos nos concentrar na preveno dos defeitos e dos erros que nos assolam. O erro que prevenido no precisa de consertos, exames ou explicaes. O primeiro passo adotar uma atitude de preveno de defeitos. Essa atitude chamada, simbolicamente, de Defeito-Zero. Texto de Philip Crosby, citado por Tom DeMarco, (1991)
Como voc pode observar, o controle da qualidade passa antes por um conceito do que o defeito e at onde estamos dispostos a aceit-lo. Entender o que defeito nos ajuda a ter distncia dele, de um ponto de vista conceitual. Muitas empresas buscam entender defeitos na produo a partir de ndices de erro encontrados numa linha de fabricao, na quantidade de bugs do sistema, ou diversos outros indicadores preparados para apontar uma no-conformidade. Ora, defeito no necessariamente um ndice, mas sim a atitude de aceitar a sua existncia ou no nos nossos procedimentos de rotina. Tanto que DeMarco (1991), para projetos de software, tenta extinguir a palavra bug e substitu-la por defeito, pois considera que isso traz um impacto maior no processo de qualidade.
122
Conforme o artigo Managing project quality, o gerenciamento da qualidade em projetos passa por dois momentos crticos: a abertura do trabalho e seu encerramento. Os pontos fundamentais a serem tratados nesses dois momentos so:
Kloppeborg & Petrick, 2004.
1. Fase inicial do projeto
Identificao dos objetivos do projeto; alinhamento estratgico com a empresa e com o objetivo do cliente; alinhamento operacional com as capacidades de produo da estrutura disponvel; seleo dos recursos necessrios; contrato detalhado do projeto descrevendo: a) o porqu do projeto (onde se apresentam as justificativas do trabalho e as causas que o inspiraram); b) o qu? (onde o escopo detalhado do trabalho deve ser colocado, definindo claramente os resultados esperados); c) quando? (em que apresentado o cronograma geral do trabalho, definindo datas de incio e fim, bem como de interao entre equipe de projetos e cliente/contratante) d) quanto custa? (especificando o valor global do projeto e medies financeiras parciais, quando necessrio) e) Quais os riscos? (descrevendo condicionantes e possveis problemas, capazes de alterar o andamento do projeto, seja em prazos, seja em custos)
123
f) como fazer? (apresentando os fatores crticos do sucesso, o plano de comunicao, os conhecimentos necessrios e os compromissos, bem como outras aes que afetaro o processo de produo do projeto).
2. Fase de encerramento
Definio e comunicao dos benefcios reais entregues para o cliente; expresso de reconhecimento aos participantes; entregar prmios quando h mritos especiais (evitando aquele tipo de mediocrizao que evita prmios para no 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 reviso da etapa, possvel replanejar o projeto e avaliar as condies de tempo restante e recursos disponveis e ainda necessrios.
Seo 7 Gesto de conflitos

Como no 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 readequao. Segundo Valeriano (1998), existem trs tipos de conflitos:
o de ordem intrapessoal, que ocorre em cada indivduo, consigo mesmo; o interpessoal, que ocorre entre diferentes indivduos; o intergrupos, que se d entre diferentes grupos.
124
Os conflitos esto presentes em todos os ambientes sociais, sejam de trabalho, familiar ou de comunidades em geral e, obviamente, esto presentes tambm nas equipes de projeto as quais, muitas vezes, esto reunidas por um pequeno perodo de tempo e de forma muito intensa o que, via de regra, potencializa as relaes. Esses trs tipos de conflito, intrapessoal, interpessoal e intergrupos, esto presentes no decorrer dos projetos segundo as seguintes causas potenciais (KEELING, 2002):
na definio de cronogramas, quando diferentes interesses tendem a se contrapor na preparao das agendas de trabalho; na definio das prioridades; na composio dos recursos humanos a trabalhar no projeto, onde afinidades pessoais tendem a se manifestar; opinies tcnicas e de desempenho, durante o desenrolar dos trabalhos; procedimentos administrativos, geralmente um ponto delicado de discusses entre a equipe do projeto e suas liberdades de ao contra as amarras muitas vezes necessrias da burocracia administrativa; custos, na batalha infindvel por uns solicitando mais dinheiro e outros negando; conflitos de personalidade (sobre isso, nem h o que comentar).
No quadro 3.3, abaixo, voc poder observar os conflitos em projetos oriundos de diferenas entre os indivduos e as organizaes devido a seus diferentes objetivos. As pessoas tm diversas necessidades e intenes que, muitas vezes, no combinam ou se ajustam s das organizaes, mesmo que tais organizaes, paradoxalmente, tenham sido construdas por indivduos. O quadro apresenta uma tabela de exemplos, adaptada de Valeriano (1998).
125
Diferenas de objetivos como fonte de conflitos Indivduo / profissional Busca a inovao tecnolgica Quer autonomia de ao Quer livrar-se de regras e procedimentos Quer autoridade baseada em mrito Quer ser recompensado com base em seu desempenho Quer ampla comunicao entre pares Busca otimizao do prprio trabalho Quadro 3.3 Fontes de conflitos Fonte: Adaptado de Valeriano (1998). Organizao / gerncia Busca o lucro Quer integrar os profissionais na organizao Estabelece as regras e procedimentos Autoridade baseada em hierarquia Recompensa conforme o interesse da organizao Bloqueia a comunicao interna Busca cumprimento de cronogramas e custos
Voc percebe como so diferentes os interesses e os objetivos entre os diferentes grupos?
Em um projeto isso pode ser a fonte de um grande fracasso. Assim, o gestor do projeto dever estar atento para saber criar suficiente blindagem entre os objetivos mais gerais da organizao e os especficos do projeto que, por sua vez, devem refletir sobre os indivduos que o compem. H organizaes que trabalham orientadas por projetos, porm com a mentalidade tradicional. No ser possvel vencer a contradio se no houver um repensar de princpios. Organizaes envelhecidas, nascidas ainda com a mentalidade dos princpios da revoluo industrial, por exemplo, buscam renovao adotando prticas de reengenharia e gesto por projetos e, normalmente, fracassam logo em seguida sem saber o porqu. A orientao por projetos uma orientao s pessoas, pois os projetos so movidos pelas pessoas que compem as equipes de projetos. Assim, ser necessria uma mentalidade direcionada ao relacionamento das pessoas, e no a um conjunto de regras rgidas, protocoladas por inmeros papis e procedimentos tcnicos, apropriados para controlar mquinas, no indivduos. Sem tal mentalidade, os projetos fracassam.
126
No entanto, mesmo que teoricamente saibamos onde esto as supostas razes dos problemas, no estaremos, necessariamente livres de conflitos em um projeto, ento ser imprescindvel administr-los. Para Valeriano (1998), h as seguintes possibilidades de se administrar conflitos num projeto:
por confronto ou soluo de problemas, quando as partes envolvidas encaram o problema e buscam juntos alternativas de soluo; por comprometimento, que a busca de solues alternativas, por parte do gerente do projeto, dando algum grau de satisfao s partes envolvidas; por acomodao, onde so 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; por prevalncia, que quando uma das partes prevalece sobre a outra, numa relao ganha-perde; por retirada, quando o conflito deixado de lado, sem soluo, o que pode causar um 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 reflexo.
Considerando tais possibilidades, ser funo do gestor escolher a maneira de lidar com o conflito. Com certeza a melhor forma de administrar os conflitos se d quando so percebidos o mais cedo possvel. Como muitas doenas, se o conflito for detectado no incio mais fcil de curar e, se muito tarde, pode ser impossvel. Por isso a ateno do gestor primordial.
127
Seo 8 Simulao, testes e validao

Projetos podem ter resultados melhores se forem testados em etapas, como resultados parciais e no aguardar at o final para ver o que deu certo e o que deu errado. Nesse sentido importante para cada etapa e sub-diviso do projeto, buscar conseguir um resultado palpvel. No caso da construo civil, por exemplo, a finalizao da etapa das fundaes tem como resultado as prprias fundaes, que podem ser testadas quanto s caractersticas necessrias de resistncia e dimenses.
Qualquer problema a detectado pode ser resolvido imediatamente, no sendo necessrio aguardar at o final da obra para perceber que os alicerces no suportaram o peso da construo seria um desastre!
Em projetos de software h a possibilidade de dividir o sistema em pequenos mdulos, de tal forma que, cada um tenha caractersticas especficas, definidas inicialmente e que, atingilas o objetivo a ser alcanado no final da etapa. Quanto maior a diviso de etapas e, desta forma, de objetivos intermedirios, mais fcil ser detectar possveis problemas e corrigi-los a tempo.
Um exemplo de diviso em etapas desse tipo, est definida nos pacotes dirios e nos prottipos de prova do Microsoft Solutions Framework (MSF, 1998). O objetivo chegar no final de cada dia com um prottipo testvel. Esse prottipo compilado e deve funcionar. S se passa para a etapa seguinte se o pacote dirio anterior alcanou o sucesso.
Outra alternativa o uso de simuladores em projetos mais complexos. Nesses casos, uma boa forma de testes prvios o uso de simulaes computacionais que permitem uma viso do produto, possibilitando fazer testes variados em um ambiente computacional.
Um timo exemplo disso so os softwares de apoio a projeto (CAD), que em mecnica e arquitetura permitem visualizar e testar peas, mquinas e ambientes. A deteco de falhas durante a simulao permite enormes economias de tempo e dinheiro.
128
A validao do projeto feita por etapas e por simulaes, sendo que no final de cada etapa, e mesmo durante cada uma delas, um processo de reviso contnua a melhor soluo de qualidade para a continuidade de um projeto de sucesso. Segundo PageJones (1990) h vrias revises a serem feitas no decorrer do projeto, visando a testes contnuos e validao a cada etapa. Especificamente sobre projetos, as revises e testes so:
reviso do escopo do projeto, que analisa constantemente se o projeto est adequado s intenes e necessidades dos usurios/clientes; reviso de anlise, que verifica se os problemas anunciados no escopo esto sendo cuidados; reviso do projeto, que verifica se preenche as especificaes, os padres de qualidade e se tem condies de ser implementado; reviso da programao e do sistema, que verifica se os resultados dos testes do prottipo esto adequados; reviso da aceitao, que verifica se aps os testes do prottipo j possvel colocar o resultado do projeto em produo; reviso de produo, que verifica se o sistema de produo est adequado e se h oportunidades de melhoria no produto; reviso dos aspectos tcnicos do projeto; reviso dos aspectos comerciais; reviso ps-projeto, que busca aprender com os resultados finais do projeto.
Simulaes, revises e testes so atividades do dia-a-dia do projeto e, como visto, interferem inclusive no seu final e podem se estender produo, atividade que j no pertencer ao escopo do projeto em si, mas rotina. Quando chegar este momento, teremos o final do projeto, assunto da prxima unidade.
129
Sntese
Nesta unidade voc viu como se do os preparativos iniciais do projeto e quais as atividades so importantes para que a produo tenha incio acompanhando o planejamento definido previamente. O incio do projeto define tambm o padro de qualidade que ser buscado em toda a fase de desenvolvimento, especialmente se for implantada uma cultura de defeito-zero. Como fundamento desta unidade est a comparao entre as caractersticas do gestor e as do lder. Em unidades anteriores esse tema j havia sido iniciado, mas aqui foi aprofundado e percebeu-se que a liderana capaz de motivar a equipe, condio essencial para que todos busquem um resultado comum, de forma entusiasmada e ambicionando o sucesso coletivo. Com certeza a figura do lder aqui definida no a do sujeito carismtico, que conduz seguidores fanticos, mas sim a do que capaz de criar ambientes de cooperao e de trabalho criativo. Para isso, muitas vezes necessrio administrar conflitos, mostrar caminhos produtivos e tomar decises que definam rumos para o projeto. Sem dvida, uma das caractersticas 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 pressupe um conjunto de revises e testes, que pode ser bem-sucedido se o projeto tiver resultados claros a serem atingidos em cada uma de tais etapas. Casos mais complexos podem exigir simuladores para facilitar essas revises e anlises, e o exemplo de prottipos intermedirios foi apresentado como soluo para busca de melhorias e conquistas parciais, visando obteno do objetivo final do projeto por meio de vrios incrementos parciais bem-sucedidos.
130
1) Dos quatro tipos de lderes definidos por Christenson (o que considera os indivduos, o que estimula intelectualmente, o que influencia os ideais, e o que motiva inspiraes), qual , na sua opinio, o mais importante? Justifique.
2) Como voc descreve os quatro passos da deciso? D um exemplo prtico, a partir da sua experincia.
3) Descreva as principais fontes de conflito entre os indivduos e as instituies, dando exemplos de sua prpria experincia.
131
4) Quais as formas de administrar um conflito, e qual delas melhor se adapta ao seu estilo de gesto? Por que essa forma de atuar e no as outras? Faa um comparativo e publique na Exposio.
5) Qual a importncia do uso de simuladores no desenvolvimento de projetos?
132
Saiba mais
As reunies geralmente so esperadas como atividades no muito proveitosas. Isso acontece porque no existe uma boa preparao para elas. Uma reunio bem preparada conduz a decises importantes e, geralmente, sucesso nas realizaes. Veja algumas sugestes e prticas para uma boa reunio, no artigo intitulado A boa geometria da reunio, de Carlos Cardoso Aveline. O uso de simuladores pode ser importante para verificar prottipos de produtos, antes mesmo de eles serem construdos. No caso do desenvolvimento eletrnico, por exemplo, h um interessante conjunto de simuladores, desenvolvidos com Java, disponveis na internet. O exemplo o seguinte: no projeto de uma antena o projetista tem como variar as caractersticas do produto, e testar seus resultados. Se for construir um circuito eletrnico, poder fazer simulaes especficas. Voc quer fazer um projeto de um novo modelo de pipa/papagaio/maranho? (cada regio usa um nome diferente). Veja o simulador computacional da NASA que est no site da NASA. Este mais um timo exemplo de como simuladores apoiam o trabalho de novos projetos.
133
UNIDADE 4
Finalizando o projeto
Compreender aspectos relativos finalizao do projeto, dissoluo das equipes e aos registros documentais do trabalho. Verificar que o sucesso do projeto ou o fracasso est intimamente ligado, por um lado, s expectativas do cliente e, por outro, capacidade de liderana do gestor. Perceber que todo trabalho de projeto uma fonte de aprendizagem, mas para que o aprendizado ocorra necessrio extrair lies e refletir sobre elas. Verificar que um projeto pode ser a origem de muitos outros, mas para isso os membros da equipe precisam estar atentos s oportunidades.
Sees de estudo
Seo 1 Fase de finalizao Seo 2 Planos de contingncia em caso de problemas Seo 3 Atendendo as expectativas do cliente Seo 4 Sobre o sucesso (ou fracasso) do projeto Seo 5 Desfazendo a equipe Seo 6 Documentao Seo 7 Lies aprendidas Seo 8 Idias para um novo projeto

Esta a unidade que encerra o livro e justamente trata do encerramento do trabalho de projeto. As atividades de encerramento do projeto so comentadas considerando aspectos diversos como o processo de documentao dos trabalhos que permitiro, por exemplo, gerar o trabalho de suporte ao produto quando o mesmo entrar em ciclo de produo e venda ou para implementar melhorias contnuas durante sua fase de consolidao. Trata tambm da dissoluo da equipe e das anlises finais, quando ento se verificar o grau de sucesso ou fracasso alcanado pelo trabalho. Esse sucesso estar ligado demanda original, vinda do cliente, seja esse cliente um contratante externo ou voc mesmo. Se a expectativa for atendida, a sensao de misso cumprida estar no ar. Seno, ser a frustrao do fracasso. Porm, com o fracasso tambm se aprende muito e assim precisamos tirar lies para aproveitar no desenvolvimento dos novos projetos, pois esses, com certeza viro. E, por esse motivo, a ltima seo mostra uma figura representativa de oportunidades de novos projetos no ambiente atual de negcios. Mas para ver tais oportunidades preciso ter os olhos bem abertos. Bom estudo!
136
Seo 1 Fase de finalizao

A finalizao do projeto pode acontecer por dois motivos: a) o resultado esperado est sendo atingido; b) nada deu certo e melhor finalizar antes que piore. Bem, vamos primeiro considerar a opo a, deixando a opo b para a prxima seo. A avaliao de que o resultado est sendo atingido obtida por medies que devem ser feitas a cada etapa do trabalho. Voc acompanhou isso desde a unidade 3, quando estudamos o algoritmo do projeto e tratamos do acompanhamento e das medies em cada atividade. Atingir o grau satisfatrio em cada uma dessas medies, faz o projeto caminhar rumo ao objetivo final que o sucesso. Uma das marcas principais do encerramento do projeto a data limite, ou prazo final. Muitas vezes, no teremos como discutir contra uma data previamente estipulada, no haver prorrogaes. Ento, deveremos trabalhar tendo em vista tal data. O controle quanto a isso se dar no preenchimento e na atualizao constante do Grfico de Gantt preenchendo as atividades realizadas e comparando com o previsto. Da mesma forma avaliando a cada passo o caminho crtico do projeto no diagrama PERT/CPM. Fechado o projeto, ser importante avaliar as estatsticas quanto ao tempo gasto, recursos utilizados, os riscos previstos que acontecerem e os que no aconteceram, se os custos previstos foram suficientes, e todos os demais dados que possam ajudar a compreender melhor a gesto dos prximos projetos. Encerrar o projeto no 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 documentao (obrigatoriamente) gerada para que, com isso, a histria do trabalho seja preservada, permitindo a introduo do resultado do projeto num ciclo de vida de produo, bem como, permitir
137
avanar em melhorias e mesmo em novos projetos a partir das lies aprendidas. Ser tambm o momento de desfazer a equipe que, nos casos em que se obteve sucesso, se transforma num momento triste e, nos casos em que se verificou fracasso, uma libertao. Nas prximas sees discutiremos com maior profundidade esses tpicos.
Seo 2 Planos de contingncia em caso de problemas

Na seo anterior, falamos das duas possibilidades de opes, a e b e j discutimos a primeira opo. Chegou a hora de discutirmos sobre a segunda. Voc j viu que, em muitos filmes ou brincadeiras se diz que, caso as coisas saiam errado, vamos ativar o plano B. Ora, esse plano B o plano de contingncia. O plano de contingncia, infelizmente, no uma carta na manga que facilmente lanada sobre a mesa, mudando todo o jogo. Geralmente um conjunto de aes, tomadas sob presso, geradoras de conflitos e de crises, pois o plano de contingncia um plano de soluo de crises. A percepo do erro geralmente postergada ao mximo e isso, muitas vezes, ocorre de forma inconsciente dado que no gostamos de errar. Para isso temos as ferramentas de planejamento, acompanhamento e controle do projeto (vimos vrias neste livro) que devem fazer parte de cada momento de reviso para que possamos constatar se estamos de acordo, ou no, com o planejado. Tais ferramentas apontam os erros, basta fazer as marcaes e ler os indicadores. E, tendo visto os erros, no certo trabalhar com desculpas, pois esse outro defeito do ser humano, aceitvel apenas em algumas questes sentimentais, mas no de trabalho. Realizando as revises e percebendo erros capazes de afetar seriamente o projeto, um plano de contingncia deve ser aplicado imediatamente. Conforme o trabalho de Iacovou e Dexter (2004), vrias aes devem ser tomadas quando um projeto sai
138
dos trilhos rumo ao fracasso. Tais autores, apontam as seguintes aes corretivas como tentativas de remediar a situao:
desenvolver um plano de recuperao; redefinir e gerenciar o propsito do projeto, ou seja, avaliar novamente o escopo do projeto e o que, de fato, se quer atingir; reavaliar o negcio e considerar o cancelamento do projeto, quando de fato no h soluo de continuidade (deve haver um grande desprendimento para isso!); replanejar o projeto usando mtodos de estimativa apropriados e comprovados; gerenciar as expectativas dos clientes, pois estes percebero rapidamente que as coisas no esto indo bem; formular um plano de comunicao objetivo e aberto, tanto para os membros da equipe quanto para fornecedores e clientes isso trar confiana; dividir o restante do projeto em pequenas partes ou atividades, o que facilitar o controle, a percepo de objetivos menores e mais prximos, bem como a capacidade de acreditar no sucesso; tratar as dificuldades pessoais da equipe do projeto, especialmente quando essa equipe se sentiu culpada pela aproximao do insucesso; incorporar prticas corretivas no processo de desenvolvimento do restante do projeto; por fim, reavaliar a liderana, verificando se essa liderana capaz de alinhar as diversas foras componentes do projeto rumo ao seu objetivo.
O ponto principal de um plano de contingncia, dessa forma, a tomada de deciso. Tomar decises a tarefa dos lderes empenhados no sucesso. Por esse motivo, ao perceber que um projeto no vai bem, importante verificar se o lder vai bem.
139
Seo 3 Atendendo as expectativas do cliente

Toda propaganda hoje diz o seguinte: fazemos de tudo para atender as expectativas do cliente. Sabemos que isso apenas propaganda e ningum atende, exatamente, as expectativas do cliente. Provavelmente porque tais expectativas no so bem conhecidas, nem mesmo pelos prprios clientes. Quando um de ns diz: vou comprar um quilo de acar, muito fcil atender tal expectativa. No entanto, se dizemos: queria um software para gerenciar a venda em balco, a expectativa muito mais complexa do que est expressa nessa simples frase. No fcil apreender do cliente como seria tal software, o tempo de resposta, a interface, quanto est disposto a gastar e muitas outras questes desse tipo. No h uma regra sobre como avaliar todos esses requisitos. A anlise aprofundada de tais requisitos e a comunicao clara do que se entendeu como escopo do problema, tanto para o cliente quanto para os membros da equipe de projeto condio bsica para atender expectativas. E refiro expectativas no plural por entender que h aquelas especficas do cliente e aquelas da equipe e ambas devem ser atendidas para que haja sucesso. Alm disso, no acredito em empresas que vivem alardeando que fazem tudo pelo cliente. As empresas fazem antes, algo por si mesmas, depois pelo cliente. E nisto no h um juzo de certo ou errado, mas simplesmente o fato de que, para sobreviver, a empresa precisa olhar para si mesma. No se trata tambm de ultrapassar limites de tica ou avanar em atitudes oportunistas, mas sim, de ser realista quanto s finalidades de cada sujeito neste jogo. A expectativa do cliente deve ser tratada como algo objetivo e deve ficar claro para ambas as partes o que possvel realizar e o que no . Chegar ao fim do projeto , ento, contemplar a expectativa desse cliente, seja ele um contratante externo, uma demanda da empresa ou um desejo de ns mesmos. Ao confrontar tal contemplao, teremos uma medida do sucesso do nosso trabalho.
140
Seo 4 Sobre o sucesso (ou fracasso) do projeto

O projeto foi entregue no prazo, gastou menos do que o previsto, o produto alcanou ou at mesmo superou as expectativas, os benefcios mensurveis pelo seu resultado so enormes...Temos, ento, um projeto de sucesso. A equipe ser condecorada, haver prmios para os responsveis, a empresa passar a vender mais ou conquistar um nicho que antes no detinha. Inovaes sero incorporadas pela indstria e pelo mercado e, dependendo do grau, podero at mesmo revolucionar um setor ou um hbito. Vamos nos debruar, porm, na situao inversa - o fracasso. Todos queremos evit-lo, contudo, mesmo quando o fracasso for inevitvel, precisamos aprender com ele para crescer. No h vitorioso que no tenha fracassado alguma vez. preciso ento prevenir, mas como poderemos nos prevenir dos fracassos em projetos? Para Keeling (2002), existe fracasso em projetos quando:
objetivos no so alcanados no prazo; custos vo alm dos limites aceitveis; resultados so obtidos com nvel de qualidade comprometido.
Nesses trs itens resumem-se os fatores que definem um projeto: prazo, custos, recursos e benefcios. Se algum deles no for contemplado, temos indcios de fracassos. No entanto, podemos fazer uma anlise mais sutil. H casos de projetos que foram concludos com custo excessivo, muito alm do oramento original e ainda acima do prazo estipulado. So exemplos desse tipo: a pera de Sydney, na Austrlia e o Eurotnel, que liga a Inglaterra Frana. No entanto, quem ousaria hoje dizer que so fracassos? Do ponto de vista dos custos e dos prazos, o foram. Mas os benefcios aparentemente superam em muito essas falhas. Esses so casos de projetos estratgicos e visionrios que so considerados no incio como equivocados ou previamente fracassados. Porm, com o passar do tempo se percebe o quanto foram importantes para os desdobramentos futuros. Isso se deve viso poderosa, intuio e persistncia de lideranas e no aos clculos e estudos de burocratas annimos.
141
Figura 4.1 pera de Sydney, na Austrlia, projetada em 1957 pelo dinamarqus Jorn Utzon, que hoje Patrimnio Nacional da Austrlia Fonte: Travels in Paradise (2011).
Atualmente, muitos projetos na rea de software tm sido vtimas da sndrome do fracasso. Por esse motivo, boa parte dos estudos recente sobre gesto de projetos tem se voltado a analisar tais casos, sendo que o interesse sobre os trabalhos do PMI (Project Management Institute) sintomtico de uma realidade de mercado. Nas palavras de Page-Jones (1990, p. 83),
embora todo projeto de Processamento de Dados enfrente dificuldades tcnicas, elas no so a causa principal de fracassos. Os desastres verdadeiramente impressionantes so devidos a gerenciamento inadequado ou inepto de projetos.
Esse autor destaca exatamente o ponto o qual estamos estudando: os problemas relativos a projetos no esto nas questes tcnicas e tampouco em atrasos ou gastos, pois esses, via de regra, so conseqncias de um problema maior: o fracasso da gesto. Como evitar o fracasso da gesto? Conforme Keeling (2002), pode-se evitar fracassos com:
melhor avaliao de viabilidade; anlise de riscos criteriosa; uso de mtodos de planejamento; uso de sistemas de controle.
142
Porm, isso no suficiente, apesar de necessrio. Um grupo de trabalho pode se reunir e fazer vrias avaliaes, considerar inmeros riscos e gerar grandes relatrios, preencher planilhas e usar softwares de planejamento de projetos. Mas tudo isso incuo se no houver o poder da deciso e o poder da deciso uma atividade humana. Com isso quero dizer que preciso ter liderana para que um projeto aspire ao sucesso. Para encerrar esta seo, veja o caso do projeto de construo de uma embarcao de guerra, no sculo XVII. Esse um caso clssico de fracasso, motivo de estudos e pesquisas dos interessados em administrao.
Figura 4.2 Representao em escala reduzida, Museu do VASA Fonte: Fairley e Willshire (2003).
143
Estudo de Caso VASA um projeto fracassado do sculo XVII

O caso da embarcao Vasa foi apresentado no artigo de Kessler et al. (2004), do qual retirei a seguinte histria: No comeo do sculo XVII a Sucia estava engajada numa srie de batalhas navais contra a Dinamarca, Rssia e Polnia. Em 1625, dez embarcaes de guerra suecas foram abatidas quando estavam patrulhando a Baa de Riga. Por esse motivo foram aceleradas as atividades de construo 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 Sucia Gustavus Adolphus ordenou alteraes na especificao do navio para introduzir um segundo nvel de canhes, mais canhes do que originalmente planejado. Com tais modificaes, o Vasa excedeu, em muito, o que poderia ser suportado pelo lastro original. Alm disso, o mestre construtor Henrik Hybertson faleceu, o que deixou a construo nas mos de um gerente inexperiente e mais fraco nas decises e controle dos operrios. No vero de 1628 um teste de estabilidade foi conduzido pelo Almirante Klas Fleming e pelo Capito Sofring Hansson. Trinta homens correram de um lado ao outro do navio. Depois da terceira corrida o navio inclinava to violentamente que o teste foi interrompido. No entanto Fleming decidiu no postergar o lanamento do navio, alegando que o mestre construtor j tinha feito navios antes e no havia com o que se preocupar. Menos de um ms depois, em 10 de agosto de 1968, o Vasa foi levado ao mar. Para mostrar o poder dos armamentos da embarcao, o Capito Hansson velejou com as portas dos canhes abertas, o que no era usual. Depois de navegar pouco mais de mil metros em mar calmo, o Vasa entornou e naufragou, levando consigo cinqenta marinheiros para o fundo do porto de Estocolmo. Era uma embarcao magnfica, que tinha custado cerca de 5% do tesouro sueco, com 64 canhes pesados e para 300 marinheiros. Feito para simbolizar a fora e a beleza da Sucia e para meter medo no corao dos seus inimigos. Muitas discusses foram realizadas para descobrir os culpados pelo desastre, mas ningum foi formalmente acusado. O rei foi parcialmente culpado por ter demandas pouco realistas, Hybertson pelo desenho medocre do projeto, Fleming por no ter dado ateno aos testes realizados e Hansson pela inabilidade no comando da embarcao.
144
Os erros, porm, foram bem mais graves do que esses. Analisando alguns, podemos considerar os seguintes detalhes: 1. Os construtores tentaram imitar o projeto da embarcao dinamarquesa Sancta Sophia, no entanto no tinham conhecimento tcnico nem capacidade de desenvolver procedimentos construtivos para tanto. 2. nfase na elegncia e no poder de fogo e pouca importncia estabilidade e navegabilidade. 3. Excesso de pressa na construo do barco e pouca ateno sua qualidade, especialmente se considerar a sua dimenso e a quantidade de novas tecnologias que estavam incorporadas o que atribua ao projeto uma srie de riscos e incertezas. 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 contrrio. 5. Trs diferentes pessoas fizeram especificaes e definies 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 concludo e no deixou documentao ou memria, ou seja, no houve transferncia tecnolgica. 7. O rei no tinha conhecimentos tcnicos para resolver o problema proposto, e mesmo assim interferiu no projeto como seu chefe supremo. Devido a esse conjunto de fatores, verifica-se o exemplar fracasso.
Figura 4.3 Representao da embarcao ao afundar, Museu do VASA Fonte: Fairley e Willshire (2003).
145
Seo 5 Desfazendo a equipe

Equipes de projeto podem criar afinidades de tal monta que, desfaz-las, no tarefa fcil. Permanecem as afinidades e o entusiasmo, especialmente se houve sucesso. O encerramento das atividades deve passar por uma avaliao de finalizao. Uma discusso franca sobre erros e acertos, principalmente no que se refere ao modelo de gesto adotado, bem como o dia-a-dia da equipe, trar benefcios e crescimento a todos.
Reconhecer os mritos: eis uma obrigao.
H muitos casos de projetistas que empenham horas de esforo e imaginao num projeto e sabemos todos que no so apenas aquelas horas que esto l escritas na planilha. Essas horas so doaes espontneas daqueles que gostam de desafios e almejam sempre a qualidade e a realizao. O reconhecimento disso deve ser manifestado claramente e quando houver oportunidade e condies, deve ser premiado. Receber um prmio, mesmo que seja uma simples palavra de agradecimento sincero, algo honroso. Conheo gestores que no sabem premiar e que consideram que realizar o trabalho a obrigao de cada um. Desejo a esses a sorte que se deseja aos ratos de esgoto.
Seo 6 Documentao
Documentao um ponto falho em quase todos os projetos. Quando Joozinho e Mariazinha entraram pelo caminho desconhecido na floresta, a trilha de pedras que eles deixaram foi seu documento principal, o documento que permitiu que voltassem para casa. Esse 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
146
pedaos de miolo de po, os pssaros comeram sua marcao e eles se perderam. Essa documentao era efmera. A memria uma documentao efmera. A documentao no adequada se no for clara, estiver arquivada, acessvel e possvel de ser entendida por outros. Vimos, desde a primeira unidade, que o planejamento est baseado em anlises, avaliaes, relatrios, depois planilhas e diagramas. Muitos desses documentos sero usados ao longo do projeto para revises, bem como sero realizadas reunies que devero gerar atas e assim por diante. Alm disso, o trabalho tcnico ser baseado em desenhos, rascunhos, anotaes, resultados de testes e muitos outros documentos de variados tipos. uma obrigao dos responsveis de cada etapa do projeto e do gestor, organizar, arquivar e preservar a documentao do projeto a qual deve ser parte do resultado final do trabalho. Nenhum projeto poder ser considerado encerrado se a documentao no estiver adequadamente preservada e organizada.
Seo 7 Lies aprendidas

Cada projeto uma oportunidade de aprendizagem e, geralmente, aprendemos com os erros. A constante reviso do projeto, em cada uma das suas etapas, ser um exerccio de anlise e, para isso, contamos com diversos instrumentos como, relatrios preenchidos l no comeo e que devem ser analisados em comparao com o realizado, passo a passo. Muitas crticas e idias surgiro nesses momentos e importante avanar sobre isso. Como dito na seo anterior, a documentao gerada ser uma fonte de recursos de aprendizado. A leitura do caso Vasa tambm uma oportunidade de aprendizagem, pois podemos estudar erros e acertos em projetos realizados por outros para avaliar caminhos. O estudo de casos proporciona, em contraste com nossa prpria experincia, uma fonte rica de aprendizagem. Vamos considerar novamente o
147
caso Vasa e comparar 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 antdotos para tais problemas numa srie de sugestes, cujas principais esto apresentadas no quadro 4.1. Aparentemente um projeto de embarcao nada tem a ver com o desenvolvimento de software, mas no bem isso que nos sugere esse conjunto de problemas e seus antdotos.
PROBLEMA Presso excessiva de prazos Mudanas no escopo e nas necessidades ANTDOTOS Estimativas objetivas de prazo Mais e melhores recursos Priorizaes
Falta de especificaes tcnicas
Desenvolvimento interativo Modificar gesto de controle e planejamento Desenvolvimento de especificaes prvias Atualizao das especificaes com base em eventos Indicao de um arquiteto de software Desenvolvimento de planejamento prvio Atualizaes peridicas e baseadas em eventos Indicao de um gestor de projetos Maior controle sobre a linha de trabalho Anlise de impactos Gesto contnua dos riscos
Falta de documentao de planejamento Inovaes excessivas ou secundrias
Falta de mtodos cientficos Ignorando o bvio Comportamento antitico
Uso de prottipos Desenvolvimento incremental Uso de mtricas de medio da performance tcnica Assimilar as lies aprendidas anteriormente Cultura de trabalho baseada em tica nos relacionamentos Uso e aderncia a cdigos de tica formais
Quadro 4.1 Problemas em projetos de software e seus antdotos Fonte: Adaptado de Fairley e Willshire (2003).
148
Vendo o quadro 4.1 percebemos que as lies tiradas do episdio so muitas e algumas das mais importantes dizem respeito ao uso de mtricas de performance, ao desenvolvimento incremental, diviso do projeto em pequenas etapas, ao controle constante do desenvolvimento e a uma cultura baseada em tica e bom relacionamento. Podemos ainda listar mais algumas, tais como:
No se deve imitar projetos sem o suficiente conhecimento tcnico; Buscar conciso e usabilidade; No se submeter pressa e dar ateno especial qualidade; Realizao constante e contnua de testes, durante todas as etapas; Reduzir os cargos de responsabilidade, para evitar o empurra-empurra da deciso; Gerar documentao sempre e no apenas no final; Aqueles que no tm conhecimento tcnico no devem interferir em assuntos que no so de sua competncia.
Os projetos foram se modificando no decorrer do tempo e as lies aprendidas foram sendo incorporadas pouco a pouco. No incio houve desperdcio imenso de recursos financeiros e mesmo de vidas humanas. Um esforo enorme de melhoria se deu na poca da revoluo industrial e, logo depois, chegando ao comeo do sculo XX com teorias e ferramentas especficas. Hoje temos um nmero muito maior de ferramentas, sistemas computacionais especiais e disputas tericas em revistas especializadas. Porm, ao mesmo tempo, os resultados no so to animadores. Ento, vamos trabalhar firmemente para no colocarmos nossos prprios projetos naquela estatstica.
149
Seo 8 Idias para um novo projeto

Na seo anterior discorremos sobre aprendizagem e sobre o processo de tirar lies dos casos de insucessos, das dificuldades e solues que vamos encontrando no decorrer do trabalho de desenvolvimento do projeto. Porm, acredito que tais lies s so percebidas e aprendidas por pessoas e equipes especiais, cheias de idias e criatividade. Acabar um projeto, geralmente serve de pretexto para dar origem a um novo projeto, pois todas as idias que foram surgindo no meio do caminho so sementes para novos trabalhos. Empresas buscam pessoas assim, para que sobrevivam no mercado criando oportunidades de novos negcios. Voc j estudou como as formas originam projetos, os quais podem ser muito simples, tal como um incremento de qualidade num produto que j temos, ou complexos, como a criao e o lanamento de um produto totalmente novo. Anotaes feitas durante o trajeto de desenvolvimento sero geradoras de oportunidades em ambos os sentidos. Por um lado, vrios apontamentos diro da necessidade de acrescentar melhorias incrementais, as quais no caberiam no decorrer do projeto, pois atrasariam o trabalho ou determinariam custos impossveis de cumprir. Por outro lado, idias completamente novas podero surgir, apontando para solues radicalmente diferentes. Um exemplo? A criao do Compact Disc foi uma soluo totalmente diferente para o problema da gravao em fitas magnticas. importante, tambm, perceber que o fracasso de um projeto no , necessariamente, o encerramento das oportunidades. Fracassos ou graves problemas de um projeto chamam a ateno para novas oportunidades de desenvolvimento. Contudo, para renascer preciso ter o esprito e a convico dos lderes. Por fim, gostaria de encerrar chamando a ateno para a estrutura de negcios da figura 4.4, com uma representao em trs dimenses onde os eixos definem diferentes atuaes no interior da empresa ou organizao. Este desenho est pleno de idias para novos projetos. Vamos ver mais de perto.
150
Figura 4.4 Processos em um ambiente de negcios Fonte: Adaptado de Greeff (2005).
O eixo horizontal conecta a cadeia de fornecimento a de relacionamento com o cliente, o vertical estabelece a ligao entre a produo e a administrao do negcio e o diagonal apresenta o desenvolvimento do produto e o suporte a ele durante seu ciclo de vida. Se estivermos presos apenas rea de desenvolvimento de novos produtos, estaremos condicionados a um pequeno terreno de idias de novos projetos. Mas hoje o essencial est nas ligaes entre o maior conjunto possvel de eixos e a isso poderamos chamar de gesto dos processos. Projetos podem surgir para interligar o processo de produo no cho-de-fbrica ao ambiente administrativo, por exemplo, e o que est comeando a acontecer, neste exato momento, com a interligao entre a automao industrial e o ERP das companhias. Iguais a essa, inmeras oportunidades esto nossa frente. Ou seja, a hora de comear um novo projeto. Boa sorte!
ERP: iniciais de Enterprise Resource Planning, que representa o sistema computacional integrado para gesto empresarial, composto de mdulos diversos como os de contabilidade, finanas, recursos humanos, compras, oramentos, estoques, entre outros, facilitando o fluxo de informaes entre os departamentos da empresa visando a otimizao do seu planejamento.
151
Sntese
Nesta unidade voc estudou sobre a importncia de uma anlise criteriosa de todos os passos dados durante o projeto e que tais passos precisam ser cuidadosamente documentados. Com isso ser possvel dar continuidade s melhorias que o projeto exigir, permitir o suporte ao produto quando for o caso, aprender com os erros e acertos do processo e tambm gerar novas idias de projetos. Outra questo importante refere-se ao reconhecimento dos membros da equipe como os verdadeiros responsveis pelas conquistas obtidas. Evidenciar tais mritos uma obrigao pois, a partir do momento que o projeto se encerra, as pessoas se voltaro para outros trabalhos e funes, porm se lembraro desses momentos de desafio e sentiro satisfao por saber que foram reconhecidas. Haver os casos de fracassos, no estaremos livres disso. Esses casos devem ser analisados com ainda maior rigor, permitindo nosso crescimento pessoal e tambm a propagao da experincia para todos os interessados. Vimos que casos famosos de fracassos so um bom objeto de estudo e, tambm, que h vezes onde um suposto fracasso se revelou como sendo um empreendimento de sucesso ao longo do tempo. Tambm esses so casos importantes de pesquisa e anlise, especialmente por considerar que foram, geralmente, conduzidos por lderes obstinados e capazes de inspirar e motivar suas equipes a despeito dos fatores negativos momentneos. Oportunidades de novos projetos esto nossa disposio. A ltima seo fala justamente disso e, de certa forma, nos liga ao incio deste livro que discute a origem dos projetos. Que seja aqui, ento, o ponto de ligao para o eterno recomear, seja dos estudos, seja dos projetos, seja dos novos empreendimentos de sucesso. At mais!
152
1) Quais so os passos para implantar um plano de recuperao, em um projeto em crise? Exemplifique com projetos de sua experincia.
2) Que grandes dificuldades existem no atendimento das expectativas do cliente?
3) Como se pode prevenir um projeto do fracasso? Que atitudes podemos tomar nesse sentido?
4) Quais lies voc tira do fracasso do projeto VASA para seus prprios projetos?
153
5) Considere seu prprio campo de trabalho e sua experincia profissional, e analise a figura abaixo. Que nova idia de projeto, concreta e exeqvel, voc pode sugerir?
154
Saiba mais
O IEEE Institute of Electric and Electronic Engineers mantm uma Sociedade voltada gesto de engenharia e projetos, de mbito mundial. a IEEE Engineering Management Society. Visite o site desse instituto e veja inmeras oportunidades de trabalho, estudo, artigos, revistas etc. Estudantes de graduao, de qualquer rea, podem se associar com valores de taxas anuais especiais.
155
Para concluir o estudo

Chego ao final deste trabalho e espero ter cumprido boa parte das suas intenes! Quem dir isso ser voc, leitor e estudante. Pois tambm sou um estudante deste tema, que muito me interessa e sempre me desafia. Ao longo do tempo fui reunindo informaes tericas e, ao mesmo tempo, agindo em diferentes projetos, alguns de sucesso, outros nem tanto. Tentei colocar o mximo desses conhecimentos e experincias aqui, e simultaneamente comparar e refletir sobre novas tendncias neste campo. Apresentei algumas tcnicas e modelo de apoio, seja nas anlises iniciais ou para o planejamento, acompanhamento e controle do projeto at seu final, sabendo, no entanto, que tais tcnicas e modelos vo sendo alterados com o tempo e com o desenvolvimento das tecnologias de gesto. Dessa forma, o foco principal no foi em tais modelos, mas sim no seu uso como ferramentas de auxlio numa viso ampla do processo de trabalho envolvido em projetos, sejam eles de que tamanho forem. Assim, ateno foi dada essencialmente na aprendizagem e na discusso que gera conhecimento. Por esse motivo, acredito que tenha acompanhado ao lado do cunho acadmico de um livro de graduao, tambm uma abordagem direcionada s aplicaes prticas e ao nvel estratgico, fundamentais para o progresso do nosso dia-a-dia. Tambm importante frisar que este livro seja uma introduo ao tema da gesto de projetos e das equipes que os compem, sendo que inmeros artigos, estudos e pesquisas continuam sendo feitos e publicados sobre isso no mundo, com crescente interesse nessa forma de desenvolvimento por projetos, que embalou toda a nova era de tecnologia que vivemos. Devemos estar atentos a tais estudos, e ns mesmos devemos contribuir no debate.
Por fim, gostaria de frisar a importncia da liderana em projetos, tema tantas vezes abordado aqui. A gesto que desenvolve os aspectos da liderana saber conduzir seu trabalho ao aprendizado constante, ao sucesso, e especialmente ao bemestar das pessoas, nosso objetivo primordial. Sucesso a todos! Prof. Mauro Faccioni Filho
Referncias
BAZZO, Walter Antnio; PEREIRA, Luiz Teixeira do Vale. Introduo Engenharia. 5. ed. Florianpolis: Editora da UFSC, 1997. CHRISTENSON, Dale; WALKER, Derek H. T. Understanding the role of vision in project success. IEEE Engineering Management Review, v. 32, n. 4, p. 57-73, 2004. CLELAND, David. The evolution of project management. IEEE Transactions on Engineering Management, v. 51, n. 4, p. 396397, 2004. CORAU, Christophe. Muralhas que dividiram os homens. Histria Viva. 13. ed., nov. 2004. Disponvel em <http://www.uol.com.br/ historiaviva/home.html>. Acesso em: 18 fev. 2005. COVEY, Stephen. O 8 hbito: da eficcia grandeza. Rio de Janeiro: Elsevier, 2005. DeMARCO, Tom. Controle de projetos de software. Rio de Janeiro: Campus, 1991. 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, v. 32, n. 1, p. 12-23, 2004. FACCIONI, Mauro. Especificao e soluo de problemas de engenharia. Florianpolis: CTAI/Senai/SC, 2004. Apostila do Curso de Especializao em Automao e Computao Industrial. FAIRLEY, Richard E.; WILLSHIRE, Mary Jane. Why the Vasa Sank: 10 problems and some antidotes for software projects. IEEE Software. p. 18-25, mar./abr., 2003. Disponvel em: <http:// computer.org/software>. FERNANDES, Jorge Monteiro. Gesto da tecnologia como parte da estratgia competitiva das empresas. Braslia: IPDE, 2003. GOOCH, Tom. Object oriented analysis and design team. Kennesaw State University, 2000. Disponvel em: <http://pigseye. kennesaw.edu/~dbraun/csis4650/A&D/index.htm>. Acesso em: 24 abr. 2005. GREEFF, Gerhard. Staying in sync. ISA Intech/Industrial Computing, v. 52, n. 6, p. 51-55, jun. 2005. Disponvel em: <www.isa.org/intech>.
HINOJOSA, Mara Alejandra. Diagrama de Gantt. 2003. Disponvel em: <www.gestiopolis.com>. Acesso em: 24 abr. 2005. HOUAISS, Antnio. Dicionrio Houaiss da Lngua Portuguesa. Rio da Janeiro: Editora Objetiva / Instituto Antnio Houaiss, 2004. IACOVOU, Charalambos; DEXTER, Albert. Turning around runaway information technology projects. IEEE Engineering Management Review, v. 32, n. 4, p. 97-112, 2004. KEELING, Ralph. Gesto de projetos: uma abordagem global. So Paulo: Editora Saraiva, 2002. KESSLER, Eric H.; BIERLY, Paul; GOPALAKRISHNAN, Shanthi. VASA Syndrome: insights from a 17th-Century new-product disaster. IEEE Engineering Management Review, v. 32, n. 1, p. 38-48, 2004. KLOPPENBORG, Timothy; PETRICK, Joseph. Managing project quality. IEEE Engineering Management Review, v. 32, n. 4, p. 86-790, 2004. MARKHAM COLLEGE. Day 12 Wednesday, 31st July. 31 jul. 2002. Disponvel em: <http://www.markham.edu.pe/uk2002/uk_day_11.htm>. Acesso em: 14 abr. 2011. il. MONUMENTOS HISTRICOS. Pirmides do Egito. 25 abr. 2011. Disponvel em: <http://monumentos252.blogspot.com/>. Acesso em: 17 maio 2011. il. MICROSOFT SOLUTIONS FRAMEWORK (MSF). 1998. Disponvel em: <www. microsoft.com/technet/itsolutions/msf/default.mspx>. PAAP, Jay; KATZ, Ralph. Anticipating disruptive innovation. IEEE Engineering Management Review, v. 32, n. 2, p. 74-85, 2004. PAGE-JONES, Meillir. Gerenciamento de projetos: guia prtico para restaurao da qualidade em projetos e sistemas de processamento de dados. So Paulo: McGraw-Hill, 1990. PROCESS QUALITY ASSOCIATES INC (PQA). History of Project Management. Disponvel em: <www.pqa.net>. Acesso em: 24 fev. 2004. PROJECT MANAGEMENT INSTITUTE (PMBOK). Guide to the Project Management Body of Knowledge. 3. ed. 2004. PRADO, Darci Santos do. PERT/COM: Srie Gerncia de Projetos, v. 4. Belo Horizonte: Editora DG, 1998. RAZ, Tzvi; BARNES, Robert; DVIR, Dov. A critical look at Critical Chain Project Management. IEEE Engineering Management Review, v. 32, n. 2, p. 35-44, 2004. SENZ, Tirso W.; CAPOTE, Emilio G. Cincia, inovao e gesto tecnolgica. Braslia: IEL/SENAI, 2002.
SISK, Toney. The history of project management. Disponvel em: <http:// offi ceupdate.microsoft.com/downloadDetails/projhistory.htm>. Acesso em: 20 fev. 2005. SOFTEX EXCELLENCE IN SOFTWARE. Terceirizao de software e servios de TI cresce. 09 jun. 2005. Disponvel em: <http://www.softex.br/ cgi/cgilua.exe/sys/start.htm?sid=4>. Acesso em: 09 jun. 2005. TRAVELS IN PARADISE. Travels Pictures. Sydney Pictures, Australia pictures, Sydney photos, Sydney Opera House, Australia photos. Disponvel em: <http://www.travelsinparadise.com/australia/sydney/pictures/sydneybridge-03.html>. Acesso em: 24 maio 2011. il. VALERIANO, Dalton L. Gerncia em projetos: pesquisa, desenvolvimento e engenharia. So Paulo: Makron Books, 1998.
161
Sobre o professor conteudista

Mauro Faccioni Filho nasceu em Maring, PR, em 29 de outubro de 1962. Formou-se em Engenharia Eltrica pela Universidade Federal de Santa Catarina (UFSC) no comeo do ano de 1985, e nesse mesmo ano fundou a empresa Creare Engenharia, junto com dois colegas da universidade. Posteriormente concluiu, tambm na UFSC, Mestrado (1997) e Doutorado (2001) em Engenharia Eltrica, com estudos sobre representaes tridimensionais e modelagem numrica computacional. Nos anos 2002 a 2004 atuou como diretor do Centro de Tecnologia em Automao e Informtica CTAI, em Florianpolis, tendo participado na criao de cursos superiores e de pr-incubadora empresarial tecnolgica, alm de ter editado revista tcnica em automao e informtica. Desde 2002 na UNISUL, como professor, participou do desenvolvimento em 2004 do projeto do Curso Superior de Tecnologia em Web Design e Programao, do qual atualmente coordenador e onde atua tambm como tutor. Com vrios artigos tcnicos e cientficos publicados, lanou ainda trs livros de poemas. Seu currculo completo est disponvel para consulta on-line no banco de dados do CNPq, no endereo http://buscatextual. cnpq.br/buscatextual/index.jsp.
Respostas e comentrios das atividades de autoavaliao

Unidade 1
1) Programa Qualidade A - reunies do grupo do projeto para definir o programa B - redao do programa de qualidade C - treinamento do pessoal do setor administrativo D - implantao do programa de qualidade no setor Administrativo; E - treinamento do pessoal do setor de produo F - implantao do programa no setor de produo; G - avaliao dos resultados e concluso 2) Prazos estimados pela equipe de implantao 1 semana, 7 dias 2 semanas, 14 dias 3 dias 2 semanas, 14 dias 3 dias 2 semanas, 14 dias 3 dias
3)
4)
5) H uma Folga Livre de 11 dias para a atividade E. Neste caso o gestor pode decidir a melhor data para que tal atividade seja executada, otimizando os recursos disponveis dentro de tal folga, sem afetar o andamento geral do projeto.
Unidade 2
1) As quatro fases so Formao, Turbulncia, Normalizao e Desempenho. Geralmente a mais problemtica a segunda fase, pois h a formao de sub-grupos de poder, as chamadas panelinhas, que podem fazer a equipe dispersar suas energias. 2) A matriz ajuda a definir as necessidades de um projeto, e alinhar aos recursos humanos disponveis para o trabalho. No 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 possvel definir os gastos com equipe, de acordo com os custos de hora-homem dos membros escolhidos. 3) Geralmente a estrutura exclusiva, com um organograma bem definido, o que melhor se adapta nessas condies. Nesse modelo os membros do projeto so dedicados a um projeto apenas. 4) Esta a estrutura matricial, e seu grande problema a complexidade, que exige maturidade da empresa e das equipes de projeto, para poderem trabalhar em vrios projetos simultaneamente, com equipes alterando conforme o cronograma e o setor/atividade. 5) Na estrutura do tipo horizontal, pois os membros da equipe se reconhecem como pares, mesmo quando os domnios e os interesses tcnicos so muito diferentes. Esse tipo de estrutura tipicamente multidisciplinar, com grande nmero de idias e solues criativas, o que favorece desenvolvimento de aplicativos de software.
166
6) Resposta subjetiva. Comentrios sobre produtividade, sobre riscos de atraso, sobre falta de qualidade, sobre diferenas culturais afetando os resultados, sobre queda de preos.
Unidade 3
1) Resposta subjetiva. O que considera os indivduos tem o perfil de humano, o intelectual o que lana desafios, o que influencia ideais e inspiraes o motivador das pessoas. 2) Os quatros passos so: (1) identificar possveis modos de ao, (2) verificar vantagens e desvantagens; (3) discutir e avaliar; (4) escolher o modo de ao mais vantajoso, e partir para ele. 3) Resposta subjetiva baseada no seguinte quadro:
Diferenas Indivduo / profissional

Busca a inovao tecnolgica Quer autonomia de ao Quer livrar-se de regras e procedimentos Quer autoridade baseada em mrito Quer ser recompensado com base em seu desempenho Quer ampla comunicao entre pares Busca otimizao do prprio trabalho
Organizao / gerncia
Busca o lucro Quer integrar os profissionais na organizao Estabelece as regras e procedimentos Autoridade baseada em hierarquia Recompensa conforme o interesse da organizao Bloqueia a comunicao interna Busca cumprimento de cronogramas e custos
4) As formas apresentadas so: por confronto, por comprometimento, por acomodao, por prevalncia, por retirada. 5) O uso de simuladores pode ser importante para verificar prottipos de produtos, antes mesmo de eles serem construdos. Os simuladores passaram a ser ainda mais importantes com o avano da informtica, que permitiu o uso de simulao computacional, que poupa tempo e dinheiro, especialmente em projetos de produtos complexos ou muito grandes, como mquinas, grandes hidreltricas, grandes construes etc.
167
Unidade 4
1) Os passos so: desenvolver um plano de recuperao; redefinir e gerenciar o propsito do projeto; reavaliar o negcio; replanejar o projeto usando mtodos de estimativa; gerenciar as expectativas dos clientes; formular um plano de comunicao; dividir o restante do projeto em pequenas partes; tratar as dificuldades pessoais da equipe do projeto; incorporar prticas corretivas; reavaliar a liderana
(Os exemplos sero individuais). 2) Erros de comunicao no incio do projeto causam frustraes na fase final. Os clientes tm dificuldades para definir seus requisitos, e muitas vezes tm expectativas exageradas. 3) Pode-se evitar fracassos tomando as seguintes atitudes: avaliando detalhadamente a viabilidade do projeto antes de come-lo; fazendo uma anlise de riscos criteriosa; usando mtodos de planejamento; usando sistemas de controle durante a fase de desenvolvimento.
4) Resposta subjetiva. Poder haver citaes sobre o descontrole, sobre a falta de liderana, sobre as interrupes constantes feitas pela lei, sobre a falta de conhecimento tcnico apropriado, sobre o planejamento fraco, sobre a falta de documentao. 5) Um exemplo simples foi o desenvolvimento do iPhone pela Apple, onde os processos de desenvolvimento se deram na Apple nos EUA e os processos de cho-de-fbrica aconteceram principalmente na China e na Coria, sendo que os processos de venda estavam concentrados nos escritrios regionais da empresa.
Biblioteca Virtual
Veja a seguir os servios oferecidos pela Biblioteca Virtual aos alunos a distncia:
Pesquisa a publicaes online www.unisul.br/textocompleto Acesso a bases de dados assinadas www. unisul.br/bdassinadas Acesso a bases de dados gratuitas selecionadas www.unisul.br/bdgratuitas Acesso a jornais e revistas on-line www. unisul.br/periodicos Emprstimo de livros www. unisul.br/emprestimos Escaneamento de parte de obra*
Acesse a pgina da Biblioteca Virtual da Unisul, disponvel no EVA e explore seus recursos digitais. Qualquer dvida escreva para bv@unisul.br
* Se voc optar por escaneamento de parte do livro, ser lhe enviado o sumrio da obra para que voc possa escolher quais captulos deseja solicitar a reproduo. Lembrando que para no ferir a Lei dos direitos autorais (Lei 9610/98) pode-se reproduzir at 10% do total de pginas do livro.

(1927 - 18737) Gestao de Projetos e de Equipes

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

(1927 - 18737) Gestao de Projetos e de Equipes

Diunggah oleh

Hak Cipta:

Format Tersedia

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Palhoa UnisulVirtual 2011

Mauro Faccioni Filho

Gesto de Projetos e de Equipes II

Palhoa UnisulVirtual 2011

Edio Livro Didtico

Ficha catalogrfica elaborada pela Biblioteca Universitria da Unisul

Bom estudo e sucesso! Equipe UnisulVirtual.

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Unidade 2 Estruturando a equipe

Unidade 3 Executando o projeto

Unidade 4 Finalizando o projeto

Universidade do Sul de Santa Catarina

Demais atividades (registro pessoal)

Universidade do Sul de Santa Catarina

Para incio de estudo

Gesto de Projetos e de Equipes II

Seo 1 Modelagem do fluxo de atividades

- Para ficar mais claro, veja o exemplo a seguir:

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Seo 2 Metodologias de planejamento Grfico de Gantt

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Grfico de Gantt; Diagramas PERT e Mtodo do Caminho Crtico CPM.

Gesto de Projetos e de Equipes II

Figura 1.8 Exemplo de Grfico de Gantt Fonte: Elaborao do autor (2006).

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

E quanto aos riscos? Voc consegue prev-los?

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Seo 3 Metodologias de planejamento PERT/CPM

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Quadro 1.4 - Correspondncia letra - atividade Fonte: Elaborao do autor (2006).

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

Universidade do Sul de Santa Catarina

Gesto de Projetos e de Equipes II

dc20 = dc10 + duraoABC

Universidade do Sul de Santa Catarina