[1927 - 18737]gestao de projetos e de equipes

Universidade do Sul de Santa Catarina

PalhoçaUnisulVirtual

2011

Gestão de Projetos e de Equipes IIDisciplina na modalidade a distância

gestão_de_projetos_e_de_equipes_II.indb 1 1/9/2011 16:46:19

PalhoçaUnisulVirtual

2011

Design instrucional

Flavia Lumi Matuzawa

Leandro Kingeski Pacheco

1ª edição revista

Gestão de Projetos e de Equipes IILivro didático

Mauro Faccioni Filho


Edição – Livro Didático

Professores ConteudistasMauro Faccioni Filho

Design InstrucionalFlavia Lumi Matuzawa

Leandro Kingeski Pacheco

Assistente AcadêmicoAline Cassol Daga (1ª ed. rev.)

Projeto Gráfico e CapaEquipe UnisulVirtual

DiagramaçãoEvandro Guedes Machado

Davi Pieper (1ª ed. rev.)

RevisãoB2B

Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

Copyright © UnisulVirtual 2011

Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.

658.404F12 Faccioni Filho, Mauro

Gestão de projetos e de equipes II : livro didático / Mauro Faccioni Filho ; design instrucional Flavia Lumi Matuzawa, Leandro Kingeski Pacheco ; [assistente acadêmico Aline Cassol Daga]. – 1. ed. rev. – Palhoça : UnisulVirtual, 2011.

169 p. : il. ; 28 cm.

Inclui bibliografia.

1. Administração de projetos. I. Matuzawa, Flavia Lumi. II. Pacheco, Leandro Kingeski. III. Daga, Aline Cassol. IV. Título.


Sumário

Apresentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Palavras do professor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Planejamento UNIDADE 1 - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Estruturando a equipeUNIDADE 2 - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Executando o projetoUNIDADE 3 - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Finalizando o projetoUNIDADE 4 - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Sobre o professor conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Respostas e comentários das atividades de autoavaliação . . . . . . . . . . . . . 165Biblioteca Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169


7

Apresentação

Este livro didático corresponde à disciplina Gestão de Projetos e de Equipes II.

O material foi elaborado visando a uma aprendizagem autônoma e aborda conteúdos especialmente selecionados e relacionados à sua área de formação. Ao adotar uma linguagem didática e dialógica, objetivamos facilitar seu estudo a distância, proporcionando condições favoráveis às múltiplas interações 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 “distância” fica caracterizada somente na modalidade de ensino que você optou para sua formação, pois na relação de aprendizagem professores e instituição estarão sempre conectados com você.

Então, sempre que sentir necessidade entre em contato; você tem à disposição diversas ferramentas e canais de acesso tais como: telefone, e-mail e o Espaço 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 técnica e pedagógica 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 à gestão de projetos dividem-se basicamente em dois tipos: aqueles que listam uma série de técnicas práticas de planejamento, e aqueles que discutem teoricamente a disciplina de gestão.

Os do primeiro tipo acreditam que simplesmente aplicando alguma metodologia pré-concebida de gestão será possível gerenciar um projeto com eficiência e eficácia. Baseiam-se em métodos e técnicas - uma série imensa de planilhas e relatórios - e mais recentemente dedicam-se a explicar e implantar ferramentas computacionais.

Os do segundo tipo analisam a gestão como uma disciplina capaz de apoiar e beneficiar aqueles que se dedicam ao planejamento e ao desenvolvimento de projetos, mas carecem de uma real experiência em diferentes tipos de projetos, os quais envolvem sempre um agente essencialmente subjetivo: o ser humano.

Este livro didático explora esse assunto de uma outra forma. Aqui o foco será essencialmente na aprendizagem e na discussão que gera um tipo de conhecimento que pode e deve ser útil aos que se interessam pelo tema. Nesse sentido, não é um livro puramente acadêmico, com unidades e seções que apresentam teorias e exemplos desvinculados da realidade e de uma visão aplicada aos negócios e aos trabalhos práticos. Sem dúvida, muitas questões aqui colocadas vieram de pesquisas e análises acadêmicas, porém estão sempre focadas em aplicações.


Plano de estudo

O plano de estudos visa a orientá-lo no desenvolvimento da disciplina. Ele possui elementos que o ajudarão 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 construção de competências se dá sobre a articulação de metodologias e por meio das diversas formas de ação/mediação.

São elementos desse processo:

o livro didático; �

o Espaço UnisulVirtual de Aprendizagem (EVA); �

as atividades de avaliação (a distância, presenciais e de �

autoavaliação);

o Sistema Tutorial. �

Ementa

Criação de plano com fl uxo de trabalho e sincronismo de equipe e recursos. Controle da qualidade em projetos para Web. Encerramento de projetos. Verifi cação da satisfação do cliente. Feedback.


12


Objetivos

Geral:

Desenvolver conhecimentos das melhores práticas e métodos atualmente utilizados na gestão de projetos e das equipes envolvidas.

Específicos:

Apresentar os conceitos básicos da área de gestão de projetos. �

Fornecer subsídios para a avaliação de riscos de um �

projeto, com ênfase nos projetos de base tecnológica.

Apresentar técnicas de planejamento, execução e �

controle de projetos, formação de equipes e seu gerenciamento de reuniões.

Descrever um modelo para gestão de projetos. �

Verificação dos softwares disponíveis para auxílio no �

gerenciamento de projetos.

Utilização de software livre para gestão de projetos. �

Carga Horária

A carga horária total da disciplina é 60 horas-aula.

Conteúdo programático/objetivos

Veja, a seguir, as unidades que compõem o livro didático desta disciplina e os seus respectivos objetivos. Estes se referem aos resultados que você deverá alcançar 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 competências necessárias à sua formação.


13

Gestão de Projetos e de Equipes II

Unidades de estudo: 4

Unidade 1 – Planejamento

As principais metodologias de planejamento de projeto são apresentadas nesta unidade, bem como técnicas para sua aplicação em problemas práticos. Métodos como Gráfico de Gantt, PERT/CPM, estimativa de recursos e cronogramas físico-financeiros são desenvolvidos e aplicados em projetos típicos.

Unidade 2 – Estruturando a equipe

A formação da equipe, descrição dos principais perfis e organização dos recursos humanos para o trabalho em projetos é o tema desta unidade. Problemas como terceirização, treinamento e métodos para dividir tarefas são estudados e as teorias sobre o assunto são apresentadas.

Unidade 3 – Executando o projeto

Unidade que reúne os temas relacionados ao dia a dia dos projetos, desde o comportamento da liderança, tomada de decisões, estruturação de reuniões, gestão de conflitos e aspectos diversos como motivação da equipe e gestão da qualidade. Como projetos são atividades com prazo definido, são descritos passos intermediários com simulação, testes e validação como ferramentas de ajuste e melhoria contínua dos projetos e dos seus resultados.

Unidade 4 – Finalizando o projeto

Unidade que relata as atividades de encerramento do projeto, os planos de contingência em caso de problemas, e aspectos relativos às demandas originais do cliente, verificando então o sucesso (ou fracasso) da empreitada. Mostra ainda que lições serão aprendidas no decorrer do trabalho, e que sem dúvida idéias para novos projetos deverão surgir.


14


Agenda de atividades/Cronograma

Verifique com atenção o EVA, organize-se para acessar �

periodicamente a sala da disciplina. O sucesso nos seus estudos depende da priorização do tempo para a leitura, da realização de análises e sínteses do conteúdo e da interação com os seus colegas e professor.

Não perca os prazos das atividades. Registre no espaço �

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 obrigatórias

Demais atividades (registro pessoal)


1UNIDADE 1

Planejamento

Objetivos de aprendizagem

Compreender os diversos modelos que representam o �desenvolvimento de projetos, especialmente aqueles voltados para as inovações tecnológicas.

Distinguir duas técnicas de planejamento de projetos, �uma que já tem um século desde sua criação 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 técnicas e métodos de �planejamento, com exercícios e exemplos práticos.

Incorporar o planejamento, por meio de ferramentas, às �atividades iniciais de um projeto.

Verificar que as estimativas de recursos, custos e prazos �são mais coerentes e consistentes quando embasadas em um planejamento detalhado.

Seções de estudo

Seção 1 Modelagem do fluxo de atividades

Seção 2 Metodologias de planejamento – Gráfico de Gantt

Seção 3 Metodologias de planejamento – PERT/CPM

Seção 4 Estimativa de recursos

Seção 5 Estimativa de custos


16


Para início de estudo

Esta unidade é fundamental para dar o primeiro passo prático na execução de um projeto.

A história dos projetos na humanidade começou com obras marcantes, mas que não contavam com um planejamento detalhado. Com a Revolução Industrial muitas coisas mudaram, especialmente a forma de se produzir, e o tempo de produção até chegar ao mercado. Atualmente, para que um projeto possa ser planejado e conduzido durante a sua execução, é necessário ter uma visão abrangente e estratégica, com um comportamento muito mais de liderança do que de simples controle. Mas controle é necessário.

Nesta unidade você verá algumas ferramentas muito úteis para apoio ao planejamento, para a estimativa de recursos e de custos, para a definição de prazos e para a administração dos riscos. Sem essas ferramentas os projetos seriam praticamente impossíveis de gerenciar. Será apresentado o Gráfico de Gantt, que provavelmente você já conhece. Ultimamente esse tipo de gráfico sofreu alterações e foi incorporado pelos softwares de gestão de projetos, sendo provavelmente a tela mais popular de todos eles (quando não a única). Junto ao Gráfico de Gantt você aprenderá, também, como construir diagramas que mostram o caminho crítico de um projeto, ou seja, aquela seqüência de atividades que dependem umas das outras, e que definem então um prazo e uma condução crítica do projeto. Qualquer alteração nesse caminho vai afetar todo o projeto (e prazo, em especial).

Tais ferramentas são úteis para o controle do projeto, mas também permitem toda espécie de estimativas, sejam de recursos necessários ao projeto, sejam de custos ou de prazos. O estudo de como realizar essas estimativas é o objeto da conclusão desta unidade. Bons estudos!!


17


Seção 1 – Modelagem do fluxo de atividades

Você já estudou que é preciso ter uma visão geral do projeto que permita avaliar sua viabilidade, os possíveis riscos, as necessidades gerais para que seja desenvolvido e para que se obtenham os resultados esperados.

Certamente durante esse processo de visão geral e estratégica, não é possível detalhar todos os elementos do projeto, mas é suficiente para decidir sobre a sua viabilidade e então dar um passo além: partir para o desenvolvimento do projeto.

A partir dessa idéia geral será necessário agora começar a detalhar o projeto, e o primeiro elemento é a sua modelagem e a definição de um fluxo de atividades.

O modelo de um objeto é uma representação, é uma simplificação desse objeto de forma que possamos entendê-lo de forma abrangente.

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

A maquete de um prédio é um modelo de como será o prédio ao ficar pronto. Ele mostra as partes do edifício, seu aspecto geral, numa proporção muito boa para que você possa entendê-lo antes de ficar pronto. Ele não é o prédio, é apenas o modelo do prédio. No entanto, você pode começar a detalhar mais e mais o modelo desse prédio, como por exemplo fazendo os projetos de instalações elétricas e de telecomunicações dele. Os desenhos dessas instalações são representações, bem detalhadas, de como serão tais instalações, porém continuam sendo modelos pois não são as instalações em si.

Os modelos são usados para facilitar a visão 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.


18


Há um modelo muito interessante de representação da realidade, que todos nós usamos, mas não nos damos conta: é a nossa língua. As palavras, e a forma como elas se relacionam, permitem que nós possamos representar o real e comunicar para outras pessoas as nossas idéias. Estas, por sua vez, precisam compreender esse modelo de representação para decodificar o que falamos, criar as imagens mentais (compilar), e responder novamente usando esse modelo comum.

Pessoas que falam línguas diferentes não conseguem se comunicar, pois não dominam a mesma modelagem. Nesses casos usam outras formas de representação, como a mímica, por exemplo, que, no entanto, é muito mais limitada. Na comunicação entre o ser humano e a máquina é preciso também uma linguagem.

Modelar, dessa forma, significa representar um sistema, ou parte dele, em forma física (a maquete, por exemplo) ou simbólica (desenho do projeto elétrico, por exemplo), de tal maneira que se possa predizer ou descrever seu comportamento. Assim, o modelo de representação é uma idealização do sistema físico, e ele nos auxilia na análise e na solução dos problemas. Sem os modelos não haveria a civilização como a conhecemos.

Algumas das principais características dos modelos, e que fazem com que tenham grande valor, são:

usando um modelo não é preciso trabalhar diretamente �

com o sistema físico real, ou seja, não é necessário pegar a maçã para querer dizer “maçã”, basta pronunciar a palavra, ou ainda, não é preciso construir o prédio inteiro para mostrá-lo, basta desenhar uma fachada ou construir uma maquete;

é prático e seguro trabalhar com modelos, pois caso as �

coisas não se afigurem tão boas, você pode abandonar tudo no começo;

graus de precisão dependerão do aprimoramento �

do modelo, ou seja, conforme você queira ter maior precisão de como será o projeto no final, você pode ir aprimorando paulatinamente o próprio modelo;


19


redução de tempo na análise, pois não é necessário ter o �

projeto pronto para fazer as primeiras simulações;

o modelo abstrai o problema para o campo de domínio �

daquele que o analisa, quer dizer, ao modelar um problema, cada um o faz no campo que tem domínio; se é um desenhista, faz o desenho, se é um escultor, cria a maquete, se é um matemático, coloca na forma de equações, se é um escritor, coloca na forma de uma ficção ou poema, e assim por diante;

os modelos não são únicos, ou seja, é possível diversos �

tipos diferentes de modelo para uma mesma coisa; no caso do prédio, pode ser representado por meio de uma maquete de madeira e papelão, ou então por uma maquete eletrônica, ou pelo desenho artístico da fachada etc., sendo que todas terão o seu valor;

como o modelo é apenas uma representação, uma �

redução do real, ele contém erros, os quais são inerentes ao seu caráter de redução.

Com essas características você pode perceber que os modelos têm inúmeras utilidades, não só para planejar a gestão de projetos, mas para planejar o próprio projeto. Basicamente pode-se considerar como utilidades dos modelos de representação:

modelos ajudam a PENSAR – modelos são instrumentos �

que permitem visualizar e pensar acerca de um sistema e do seu comportamento; boa parte dos problemas e das soluções de um projeto você consegue perceber e imaginar sobre esse instrumento;

permitem COMUNICAR – com um modelo bem �

representado é possível transmitir informações sobre o projeto, e isto é importantíssimo na gestão da equipe;

é possível PREVER – com um modelo apropriado é �

possível simular o comportamento do sistema, e com isso prever ser provável comportamento;


20


permitem CONTROLAR – com um modelo você tem �

condições de criar sistemas que simulam comportamento, e dessa forma é possível criar critérios de controle, inicialmente usados no modelo e depois associados ao sistema físico real;

ajudam a ENSINAR – assim como os modelos ajudam a �

comunicar, passam, assim, a ser importante instrumento de auxílio na educação 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 Icônico – é o modelo que representa com alto grau de semelhança o sistema físico, seja em duas dimensões (como no caso das fotos e mapas, como na figura 1.1) ou em três dimensões (maquetes, esculturas, protótipos).

Figura 1.1 – Exemplo de representação icônica – mapa urbano Fonte: Google Maps - London (2010).

Modelo Diagramático – tem pouca semelhança com o sistema físico, e é apresentado por meio de símbolos, linhas, diagramas. Facilita a compreensão do funcionamento de uma máquina, um processo ou sistema, sem dispersar a atenção em detalhes de outra ordem, e um bom exemplo disso são os fluxogramas que usamos nas empresas, mostrando como se dá o fluxo de processos, ou então o organograma dessa mesma empresa, que mostra como se distribuem os cargos e departamentos. No


21


entanto, por ser uma representação um pouco mais especializada, serve para aqueles que conhecem a convenção usada no diagrama (veja exemplo na figura 1.2).

Figura 1.2 – Exemplo de representação diagramática – diagrama de atividades da UML – Linguagem de Modelagem Unificada Fonte: Gooch (2000).

Modelo Matemático – é um modelo simbólico abstrato, que está cada vez mais associado aos problemas de tecnologia avançada, sendo o de aplicação mais importante na engenharia. Os modelos matemáticos são os mais poderosos instrumentos de representação, e têm permitido modelos computacionais sofisticados, porém são altamente especializados e exigem conhecimento avançado dos usuários.


22


Modelo Gráfico – é o modelo que representa o comportamento de fenômenos por meio de curvas, gráficos, facilitando a sua verificação. Há diversos tipos de gráficos, como por exemplo os de linhas, com barras, em forma de pizza, etc. (veja por exemplo aqueles disponíveis no Microsoft Excel), sendo que o traçado se dá a partir de um conjunto de valores previamente definidos pelo usuário.

Para desenvolver um projeto você precisará, antes de tudo, criar um modelo de como se dará o desenvolvimento desse projeto.

Projetos muito pequenos não precisam de um modelo, assim como a construção da casinha do cachorro não precisa certamente de uma planta dessa casinha. Se, no entanto, ela tiver algum grau de complexidade maior, é melhor desenhar.

Tendo o modelo em mãos você poderá, dessa maneira, utilizar métodos de planejamento (que você verá na próxima seção) 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 tecnológico. As diferenças entre os três tipos de fluxos definem prazos diferentes de entrega, mas podem depender de como se deu a contratação e quais os riscos aceitáveis. A percepção clara de como se dará o desenvolvimento do projeto permitirá uma boa divisão e detalhamento das atividades.

��

��

��

��

��

��

��

��

Figura 1.3 – Três modelos de fluxo de conhecimento no desenvolvimento de projetos tecnológicos Fonte: Elaboração do autor (2006).


23


Na etapa inicial das idéias, chamada de “pesquisa”, são adquiridos os conhecimentos e informações necessárias para dar início ao projeto.

Veja como se dá o fluxo no modelo seqüencial, cujo diagrama está apresentado na figura 1.4.

Não há passagem para a próxima etapa, chamada de “desenvolvimento”, sem que todas as atividades da primeira etapa tenham sido concluídas. Na etapa do desenvolvimento ocorrem as primeiras implementações do projeto como, por exemplo, a escrita das primeiras versões de um software, a criação do protótipo, os testes iniciais, as simulações, etc.

No modelo seqüencial a passagem para a etapa de “engenharia” só ocorrerá quando a etapa anterior estiver concluída. Na engenharia se dará a implantação do projeto, a criação de um piloto e sua colocação efetiva no mercado como, por exemplo, na finalização e entrega de um novo produto, o que inclui o início do funcionamento e suporte, ou a colocação em linha de fabricação de uma nova máquina. No modelo seqüencial o conhecimento adquirido em cada etapa não influencia a etapa anterior, e novas decisões são tomadas apenas com os conhecimentos já obtidos.

Esse modelo de desenvolvimento de projetos é conservador, e toma maior tempo de realização total, pois nenhuma atividade segue seu andamento se a atividade anterior não tiver sido totalmente concluída.

A construção civil, por exemplo, usa esse modelo seqüencial como padrão e isso faz sentido, pois o tipo de projeto pressupõe fases bem divididas e com requisitos de precedência.

Precedência: em projetos as atividades podem ter relações de dependência com outras atividades anteriores, as quais são pré-requisitos para o seu início.


24


��

��

��

��

��

��

Figura 1.4 – Modelo seqüencial de desenvolvimento de projeto, conforme Sáenz (2001) Fonte: Elaboração do autor (2006).

Se, no entanto, as etapas sofrerem um certo grau de mesclagem, de tal forma que a etapa seguinte tenha início enquanto a etapa anterior ainda está na fase de encerramento, chamamos tal modelo de seqüencial com solapamento.

Esse não é ainda um modelo radical de desenvolvimento de projetos, pois a ordem das etapas está bem definida, mas o fato de uma etapa já ter início enquanto a outra ainda se desenrola, faz com que conhecimentos e problemas da etapa seguinte interfiram positivamente na etapa anterior, obrigando revisões dinâmicas do processo.

Como você pode ver no desenho da figura 1.5, os conhecimentos adquiridos em uma etapa podem interferir na solução de problemas ainda da etapa anterior. Com isso há ganho de tempo no projeto, pois algumas decisões tomadas farão com que determinado problema ou risco futuro sejam controlados ou mesmo eliminados.

Projetos de equipamentos ou softwares são exemplos para esse tipo de modelagem.


25


��

��

��

��

��

��

Figura 1.5 – Diagrama de modelo seqüencial com solapamento, inspirado em Sáenz (2001) Fonte: Elaboração do autor (2006).

A situação radical de desenvolvimento de projetos é aquela onde as diferentes etapas estão totalmente entremeadas. Certamente esse é o caso onde é possível obter o resultado do projeto no menor prazo possível, mas isso exige um enorme controle e gestão detalhada. O que não é simples!

O diagrama da figura 1.6 mostra essa situação, chamada de modelo com solapamento, e percebe-se que os conhecimentos e problemas de uma etapa interferem nas soluções de todas as outras etapas, sejam anteriores ou posteriores.

Controlar tais interferências, para que sejam proveitosas para o projeto, passa a ser um dos grandes problemas desse modelo. Problemas relativos à montagem e engenheirização de determinado produto podem gerar conhecimentos que terão grande valor lá na etapa das idéias iniciais, pois com tais conhecimentos seria possível já imaginar soluções que vão alterar o formato final do produto.

O fluxo de tais informações precisa então ser contínuo, e esse tipo de modelo pressupõe ênfase nos ambientes de comunicação e integração de equipes.


26


��

��

��

��

��

��

Figura 1.6 – Solução radical: modelo com solapamento (inspirado em Sáenz, 2001) Fonte: Elaboração do autor (2006).

Nesta seção você conheceu a modelagem do fluxo das atividades de um projeto, e como podem ser os diversos modelos de representação, sejam do fluxo ou mesmo do projeto como um todo. A modelagem permite uma visão estratégica do projeto.

A partir dessa visão estratégica é possível dar início à sua operacionalização e, para isso, você pode contar com métodos e ferramentas, assunto da próxima seção.

Seção 2 – Metodologias de planejamento – Gráfico de Gantt

Caso seja importante representar todo o projeto por um modelo estratégico, geral, para fazermos o seu planejamento é necessário descer nos detalhes, ou seja, decompor todo o trabalho em suas menores partes.


27


Essa decomposição 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 decomposição” ou na forma de tabelas (VALERIANO, 1998). Tanto a árvore quanto a tabela trazem as mesmas informações, sendo que a diferença está na forma de apresentação.

Veja o quadro 1.1 e a figura 1.7 a seguir. Ambos nos mostram uma divisão de tarefas do projeto fictício denominado “Exemplo”. No quadro 1.1 você pode ver o quadro com o rascunho da divisão de etapas e com as diversas tarefas que serão necessárias 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 EXEMPLOEtapa 1• Definições• Compra materiais• Organiza equipe• Documentação• .....Etapa 2• Desenho • Montagem• Documentação• .....Etapa 3• Teste 1• Teste 2• Documentação• Encerramento

• .....

Quadro 1.1– Divisão de tarefas de um projeto “Exemplo” Fonte: Elaboração do autor (2006).

A árvore da figura 1.7 representa as mesmas tarefas e etapas, porém numa representação espacial, o que para algumas pessoas facilita a compreensão dos diversos componentes. É uma questão de escolha.


28


��

��

��

��

��

��

��

��

Figura 1.7 – O mesmo projeto da figura 1.7 em uma divisão por árvore de decomposição Fonte: Elaboração do autor (2006).

Com esse tipo de divisão de tarefas você pode imaginar e localizar todos os componentes do projeto. A partir dessa divisão, você poderá iniciar a construção do planejamento para execução e gestão do projeto.

Agora você vai estudar três métodos para planejar o desenvolvimento do projeto:

Gráfico de Gantt; �

Diagramas PERT e �

Método do Caminho Crítico – CPM. �

São métodos que vêm sendo desenvolvidos nos últimos cem anos, especialmente após a Segunda Guerra Mundial, tendo tido grande ênfase nos anos recentes com os projetos que envolvem desenvolvimento de software e sistemas de alta tecnologia.


29


Gráfico de Gantt

O gráfico de Gantt também é chamado de gráfico de barras. Foi concebido pelo engenheiro norte-americano Henry L. Gantt (1861-1919) (Hinojosa, 2003) para tentar resolver o problema da programação de diferentes atividades industriais. Essas atividades foram distribuídas no calendário de maneira que o conjunto de atividades pudesse ser visualizado, com a facilidade de se perceber, pelo tamanho de uma determinada barra, qual seria a duração da atividade que tal barra representaria.

Ou seja, o início da barra marcaria a data de começo da atividade e o final da barra seu término, sendo que a barra se estende por todo o período compreendido entre as duas datas.

A figura 1.8 mostra um exemplo de Gráfico de Gantt desenhado em planilha (neste caso com o auxílio do MS Excel). Você pode ver que o projeto se estende do dia 14/março até 15/abril, e é constituído de quatro etapas, havendo dois projetistas neste trabalho. As barras pretas mostram os prazos previstos para a execução de cada Etapa/Tarefa.

Figura 1.8 – Exemplo de Gráfico de Gantt Fonte: Elaboração do autor (2006).

Este tipo de gráfico permite desenhar uma barra com a duração prevista, e junto a ela outra barra que vai sendo preenchida conforme as tarefas vão sendo cumpridas, de tal forma que é possível acompanhar o andamento do projeto e a proporção de atraso ou quanto se está adiantado em relação ao previsto.


30


Na figura 1.8 você pode ver a barra cinza da Etapa 1 mostrando o andamento do projeto até aquele momento. Se o gráfico estiver nessa posição no dia 21 de março, então você pode perceber que o projeto está cumprindo seu prazo.

Nesse exemplo, no eixo horizontal há um calendário com a escala de tempo pertinente e mais adequada ao projeto (dias, semanas, meses etc). E, no eixo vertical as atividades que serão executadas, sendo que a barra de duração da atividade é pintada no eixo horizontal ocupando o prazo previsto.

O formato da barra, sua cor, grossura da linha, etc., depende apenas de quem a está construindo e da facilidade de visualização que se requer. Projetos com equipes muito grandes costumam imprimir tais gráficos em painéis grandes, para que num único relance você possa ver as etapas, como vai indo o dia-a-dia do projeto, os principais responsáveis, datas de início e fim etc.

O gráfico que Henry Gantt criou tornou-se imensamente popular e passou a ser utilizado, sem grandes modificações, no gerenciamento de todos os tipos de projetos em todo o mundo.

Uma das desvantagens apontadas era que o gráfico não interligava uma atividade à outra, ou seja, não deixava clara a interdependência entre as diferentes atividades.

Versões recentes desse tipo de gráfico passaram, assim, a utilizar setas de ligação entre as diferentes barras, para mostrar esse tipo de dependência, especialmente a partir do uso de softwares como o MS Project.

Porém, não é necessário um software para se construir o Gráfico de Gantt, e justamente por isso é tão popular e essa é uma das suas grandes vantagens: o traçado simples e direto.

Com isso passa a ser muito útil nas etapas iniciais de planejamento (HINOJOSA, 2003), mas quando o projeto passa a se desenvolver e modificações no planejamento acontecem, o gráfico começa a se tornar confuso. A replanificação exige que se faça um novo gráfico.


31


Também é outra desvantagem o fato de que o gráfico de Gantt não apresenta custos das etapas, e dificilmente se adapta a projetos muito complexos com múltiplas tarefas simultâneas. Nesses casos se usam outros métodos, como PERT e CPM, que serão apresentados adiante.

- Para que você compreenda melhor, observe o exemplo a seguir:

Você agora vai conhecer um exemplo simples para aplicação do Gráfico 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 não é um exemplo de projeto de software, mas é suficientemente comum para que você explore todas as questões relacionadas ao gerenciamento de um projeto que envolve equipe. A idéia partiu do cliente, que pretende fazer uma comemoração, e deu a você o prazo de oito semanas para entregar a obra pronta, sendo que todos os materiais para a obra são fornecidos por ele.

Tudo começa pela decomposição do projeto em tarefas e, para isso, você deve utilizar a decomposição 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 não há uma regra específica para isso, a não ser o conhecimento e a experiência particular de cada um.

Proponho então a seguinte divisão:


32


Projeto CHURRASQUEIRA

Etapa 1 – Preparação do terreno

• Limpeza do terreno

• Medições e marcações

• Escavações

Etapa 2 – Fundações

• Montagem das madeiras de caixaria

• Montagem das ferragens da fundação

• Concretagem

Etapa 3 – Alvenaria

• Construção das paredes

• Montagem da churrasqueira

• Rebocos

Etapa 4 – Telhado

• Montagem da estrutura de madeira

• Colocação de Telhas

Etapa 5 – Piso

• Concretagem do piso

• Assentamento da Cerâmica do piso

Etapa 6 – Carpintaria

• Colocação de janelas

• Colocação de portas

Etapa 7 – Instalação Hidráulica

• Tubulações de água

• Colocação da caixa dágua

• Montagem de torneiras, descargas, acessórios

• Esgoto

Etapa 8 – Instalação Elétrica

• Instalação das Tubulações

• Passagem dos cabos alimentadores

• Montagem das tomadas, luminárias e quadros

Etapa 9 – Pinturas e acabamento

• Pintura externa

• Pintura interna

• Limpeza final e entrega da obra

Quadro 1.2 – Tabela com divisão de tarefas do projeto “Churrasqueira” Fonte: Elaboração do autor (2006).


33


Ao analisar a divisão acima, você irá perceber que o projeto não é tão simples quanto podia parecer à primeira vista, pois há inúmeras 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 gráfico de Gantt simples e útil para este projeto.

Você pode começar 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 divisões para facilitar o trabalho, tais como a divisão das colunas das semanas nos seus sete dias, com marcação do sábado (S) e do domingo (D), e nas barras horizontais há uma divisão que marca o prazo previsto (Prev) e outra divisão para depois se anotar o realizado (Real), conforme o projeto for andando.

Além disso, no espaço reservado para escrever o nome das etapas, há também um questionamento sobre quem irá realizar aquela tarefa, ou seja, quem é o responsável por aquela tarefa específica. Isso é muito útil para poder distribuir as responsabilidades, e da mesma forma é útil para aquele que vai trabalhar nela, pois pode compreender sua função no conjunto das atividades bem como o impacto de seu prazo sobre o restante.

Figura 1.9 – Planilha para Gráfico de Gantt do projeto “Churrasqueira” Fonte: Elaboração do autor (2006).


34


O prazo de dois meses parece ser bastante enxuto, então é preciso ser cuidadoso na distribuição dos prazos para que se tenha sucesso. Veja que neste projeto o sucesso significa acabar antes do dia da comemoração, não sendo admitida outra possibilidade. A equipe que trabalhará neste projeto será constituída, além do gestor (você), também de um mestre de obras, um pedreiro, um servente, um carpinteiro, um eletricista, um encanador e um pintor. São oito pessoas, sendo que alguns estarão presentes apenas em algumas etapas da obra. Fazendo uma reunião preliminar com todos os membros da equipe, são estimados os seguintes prazos de execução para cada etapa:

Projeto CHURRASQUEIRA Prazos estimados pela equipe Dependência

Etapa 1 – Preparação do terreno 2 dias —

Etapa 2 – Fundações e Estrutura 1 semana Etapa 1

Etapa 3 – Alvenaria 4 semanas Etapa 2

Etapa 4 – Telhado 1 semana Etapa 2

Etapa 5 – Piso 2 semanas Etapa 4

Etapa 6 – Carpintaria 1 semana —

Etapa 7 – Instalação Hidráulica 1 semana Etapa 4

Etapa 8 – Instalação Elétrica 1 semana Etapa 4

Etapa 9 – Pinturas e acabamento 2 semanas Etapas 2 e 4

Quadro 1.3 – Estimando prazos para as etapas do projeto “Churrasqueira” Fonte: Elaboração do autor (2006).

Se você somar essa estimativa de prazos, você e sua equipe chegarão a 13 semanas e 3 dias, o que supera a data final definida. Porém, algumas atividades podem ser feitas em paralelo, e nesse sentido é que você pode traçar o primeiro esboço de gráfico de Gantt, que está apresentado na figura 1.10.


35


Figura 1.10 – Gráfico de Gantt do projeto “Churrasqueira” – primeiro esboço Fonte: Elaboração do autor (2006).

Algo que você pode notar neste gráfico é que, para adequar o projeto ao prazo total, é necessário colocar algumas atividades em paralelo, e isso é muito natural. O serviço do telhado começou mais ou menos no meio das atividades de alvenaria, e o piso está dividido em duas fases, sendo que a segunda fase aparece apenas após o encerramento de todo o trabalho da alvenaria. Da mesma forma as instalações hidráulicas e elétricas estão divididas em duas etapas.

Este projeto é simples, então não é difícil perceber essas possibilidades de trabalho em paralelo para otimizar o tempo e a equipe. Porém, se alguém que não conhece o projeto der uma olhada neste gráfico, não entenderá porque há uma interrupção na instalação hidráulica em determinado ponto, e nem porque ela começa na quinta semana e não apenas na sétima, por exemplo.

Uma divisão mais detalhada facilitaria essa visão externa, e certamente também facilitaria a própria gestão do projeto. Uma nova opção de gráfico de Gantt deste mesmo projeto está apresentada na figura 1.11.


36


Figura 1.11 – Gráfico de Gantt do projeto “Churrasqueira” (assumimos a sequência de atividades definidas pelo “mestre de obras”) Fonte: Elaboração do autor (2006).

Este gráfico detalha melhor algumas fases, que permite que se veja a dependência entre um serviço e outro. A dependência não está explícita no gráfico, porém alguém com mais experiência perceberá que o serviço de telhados depende da finalização da construção das paredes, e após o telhado ficar pronto serão colocadas as tubulações elétricas e hidráulicas. A concretagem do piso poderá ser feita também após a conclusão do telhado, e você começará a pintura externa após a colocação das janelas e portas.

Depois da conclusão do piso, serão feitos os acabamentos das instalações elétricas, passando todos os cabos e instalando tomadas e luminárias, bem como instalando acessórios da parte hidráulica. Por fim, será feita a pintura externa e limpeza geral da obra, e afinal haverá uma festa no domingo!

Bem, este exemplo é obviamente uma suposição de serviço, mas ele espelha exatamente o que ocorre em todos os projetos. É comum que se tenham muitas dúvidas quando o serviço está por começar e, assim, é necessário fazer alguns desenhos iniciais e avaliar se será útil a divisão que você pensou inicialmente. Caso não seja, ou caso você perceba que é possível detalhar um pouco mais, então é importante fazê-lo.


37


No gráfico anterior foi também preenchido o nome da pessoa da equipe responsável por cada etapa. Desta forma é possível definir as atividades de cada um, e assim o trabalho individual será otimizado.

O eletricista, por exemplo, poderá participar de vários outros projetos, bastando para isso preparar sua agenda conforme a distribuição de tarefas em cada projeto.

Para relembrar alguns tópicos estudados nas unidades e seções 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 seqüencial de trabalho, ou teria sido o modelo seqüencial com solapamento?

Se você voltar à figura 1.4 perceberá que no modelo seqüencial 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 instalação hidráulica e elétrica, que acontecem quando ainda se está realizando a alvenaria. Certamente algumas soluções pensadas em quaisquer dessas atividades podem interferir positivamente nas demais, como por exemplo:

combinar passagem de tubulações pelos mesmos �

caminhos, evitando desperdícios;

nível de caimento para as águas; �

existência de espaços de reserva (como cantos e �

reentrâncias na parede);

e muitos outros. �


38


Por essa análise, conclui-se que o modelo de desenvolvimento do projeto é o seqüencial com solapamento, que já é tradicional na construção civil.

E quanto aos prazos, houve uma estimativa de prazos? Houve uma estimativa de recursos? Estimativa de custos e de benefícios?

Essas questões foram debatidas na unidade anterior, onde frisei a necessidade de se fazer tais levantamentos e análises para permitir, só então, o desenvolvimento do projeto.

Considere esse projeto como bastante simples, que partiu de uma contratação onde o cliente já definiu algumas dessas questões. Veja:

Prazo � – o ponto de partida do projeto foi justamente um resultado desejado num determinado prazo: a comemoração com churrasco. Essa data definiu o prazo limite, para o qual tivemos de nos adequar.

Benefícios � – se prestarmos atenção na resposta anterior já se percebe claramente o benefício: a churrasqueira do cliente, onde ele poderá realizar suas festas; nesse caso não há um produto a ser lançado no mercado, onde o valor será medido pelo retorno financeiro, mas sim haverá valor pelo retorno em qualidade de vida.

Recursos � – não tivemos problemas com recursos materiais, pois o contratante previu o seu fornecimento; precisamos então nos preocupar com a equipe (nossos recursos humanos).

Custos � – com base na quantidade de trabalho envolvida, no número de horas e nas especialidades de pessoal, um orçamento foi entregue ao cliente, que neste caso aceitou tais custos e teve de fazer os aportes financeiros semanalmente (é a prática na construção civil).

E quanto aos riscos? Você consegue prevê-los?


39


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 aconteça. E eles podem acontecer!

Considere que ocorra um período de chuvas justamente durante as três primeiras atividades: preparação do terreno, fundações e alvenaria. Certamente haverá atrasos nessas etapas, e isso poderá afetar todo o projeto, pois como tais atividades estão encadeadas e delas dependem todas as restantes, dizemos que tais atividades perfazem um caminho crítico.

O método do caminho crítico será discutido mais adiante. O gestor do projeto terá que pensar em alternativas. Outros riscos são a falta de pessoal por motivos alheios (doenças, mudanças), 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 gráfico da figura 1.10 para analisar outra característica desse tipo de diagrama. Apesar de você já saber que uma atividade deve começar apenas quando a outra terminar (como por exemplo o telhado somente após as paredes e estrutura estarem montadas, nesse caso), isso não está evidente no desenho.

A pessoa que não conhece o projeto não perceberá esse tipo de dependência. Foi preciso avançar na construção desse tipo de diagramas e introduzir relações de dependência, o que se dá em todos os modernos softwares de geração de gráficos de Gantt. Você pode criar dependências de quatro tipos entre atividades:

Dependência � fim-início, quando o início de uma Atividade B só é possível após o fim da Atividade A.

Dependência � fim-fim, quando o final da Atividade B deve, necessariamente, coincidir com o fim da Atividade A.


40


Dependência � início-início, quando o início da Atividade B deve, necessariamente, coincidir com o início da Atividade A.

Dependência � fim-início com folga, quando o início de uma Atividade B só é possível após o fim da Atividade A, porém há um tempo de folga para o início da Atividade B.

A representação gráfica dessas relações de dependências é feita com setas interligando as extremidades das atividades, como você pode ver nas figuras seguintes:

��

��

Figura 1.12 – Dependência Fim-Início num Gráfico de Gantt, onde B depende de A Fonte: Elaboração do autor (2006).

��

��

Figura 1.13 – Dependência Fim-Fim num Gráfico de Gantt, onde B depende de A Fonte: Elaboração do autor (2006).

��

��

Figura 1.14 – Dependência Início-Início num Gráfico de Gantt, onde B depende de A Fonte: Elaboração do autor (2006).

��

��

��

Figura 1.15 – Dependência Fim-Início com folga num Gráfico de Gantt, onde B depende de A Fonte: Elaboração do autor (2006).


41


A introdução das setas que mostram dependências foi um grande avanço na visualização do planejamento, antes apenas possível pela distribuição das barras num gráfico com escala de tempo. Essa introdução permitiu perceber que as setas poderiam indicar algo mais no gráfico, e daí em diante um novo conjunto de gráficos e diagramas foi desenvolvido e chegaremos, então, ao Método do Caminho Crítico (CPM) e diagramas PERT. Mas isso será assunto para a próxima seção.

Antes, para encerrar esta seção, veja duas ilustrações com exemplos de softwares que usam Gráfico de Gantt com setas de dependência.

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 Gráfico de Gantt, software jxProject Fonte: Elaboração do autor (2006).


42


Figura 1.17 – Exemplo de Gráfico de Gantt, software Microsoft Office Project Fonte: Elaboração do autor (2006).

Seção 3 – Metodologias de planejamento – PERT/CPM

Após a Segunda Guerra Mundial surgiu um projeto do governo norte-americano que acabou gerando uma profunda influência na disciplina de gestão de projetos. Era o projeto Polaris, da Marinha, para produzir uma série de submarinos nucleares em cinco anos.

Esse projeto iria envolver mais de 9000 empreiteiros diferentes e devia ter o “de acordo” do Congresso, o que teve um enorme impacto tal o clima de desconfiança que o projeto gerou, pois se sabia que os prazos e custos de projetos militares eram constantemente estourados (PRADO, 1998). Para inverter esse quadro de desconfiança e ter o projeto aprovado, foi criada uma equipe especialmente para planejar e fiscalizar o andamento do projeto e a construção dos submarinos. Essa equipe foi


43


denominada Program Evaluation and Review Task Force, gerando a sigla PERT, que posteriormente viria a denominar a técnica de representação do planejamento do projeto por eles desenvolvida – Program Evaluation and Review Technique - PERT.

O projeto Polaris surpreendeu e foi desenvolvido em apenas três anos, o que atraiu grande atenção para a equipe e para a técnica que eles desenvolveram para a gestão de projetos.

Na década de 60 muitas melhorias foram incrementadas à técnica, incluindo o Critical Path Method – CPM (Método do Caminho Crítico), e todas as técnicas de representação de projetos por redes de atividades e dependências acabaram sendo reunidas atualmente no que se denomina PERT/CPM.

A idéia dessas técnicas era criar um diagrama que verificasse os pré-requisitos de cada atividade, de tal forma que se pudesse compreender qual seria o conjunto de atividades, com seus prazos e em seqüência cronológica, de tal maneira que fosse possível traçar o “caminho crítico” do projeto, ou seja, a seqüência de atividades que determinariam o menor tempo possível do projeto.

Dentre as várias aplicações das técnicas PERT/CPM pode-se citar:

definir as atividades de um projeto; �

determinar a duração de cada atividade; �

com base nos prazos de cada atividade, buscar o prazo �

mínimo para o projeto total;

encontrar as ligações temporais entre as diversas �

atividades, ou seja, verificar os tempos de folga entre atividades seqüenciadas;

identificar quais atividades são críticas no projeto, ou �

seja, aquelas cujo prazo determina o andamento de todo o projeto, e que se ocorrer um problema qualquer de atraso, todo o projeto sofrerá retardo;


44


determinar qual é a seqüência crítica do projeto �

considerando as atividades críticas, ou seja, determinar a seqüência de atividades críticas que perfazem o “caminho crítico” do projeto;

verificar os tempos de folga que existem entre as atividades, �

de tal modo que se possa trabalhar com esses prazos durante a execução do projeto sem afetar o prazo total.

Diferente do Gráfico de Gantt, onde cada atividade ocupa uma barra do painel, nessas técnicas de revisão e do caminho crítico são usadas setas para compor o diagrama, como no desenho da figura abaixo (figura 1.18), onde cada seta representa uma determinada atividade (atividade A, atividade B....) e os círculos representam um evento ou nó, que é a conclusão de uma ou mais atividades.

Como você pode ver no diagrama, a duração de cada atividade não está representada pelo comprimento da seta, pois os comprimentos dessas não têm escala. O que mais importa aqui é verificar qual atividade depende de outra, sua precedente.

No caso 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 concluídas as atividades C e D. Ou seja, o diagrama de setas define uma lógica para a seqüência de execução.

Figura 1.18 – Diagrama de setas simples com nós, que denotam a conclusão de atividades Fonte: Elaboração do autor (2006).


45


As diferenças entre os métodos como o Gráfico de Gantt e as técnicas PERT/CPM acontecem devido ao tipo de representação e de escala utilizada.

No Gráfico de Gantt há uma escala de tempo bem definida, mas a representação das precedências, da vinculação entre diferentes atividades e do “caminho crítico” não são evidentes.

Para dar início ao estudo das técnicas PERT/CPM, faça primeiramente uma comparação gráfica entre os diferentes métodos, e então evolua a partir desse ponto.

Na figura 1.19 há duas representações para o projeto “Churrasqueira”, que já foi tratado na seção anterior. Na parte superior da figura você pode ver o Gráfico 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 representação por diagrama de setas do mesmo projeto, onde as letras denominam as atividades, conforme o seguinte quadro de correspondência:

A preparação do terreno

B fundações

C alvenaria - paredes

D alvenaria - reboco e cerâmicas

E telhado

F piso

G carpintaria

H tubulação hidráulica

I instalação hidráulica

J tubulação elétrica

K instalação elétrica

L pintura externa

M pintura interna e acabamento

Quadro 1.4 - Correspondência letra - atividade Fonte: Elaboração do autor (2006).


46


Figura 1.19 – Diagrama de setas com escala e acima o Gráfico de Gantt do projeto “Churrasqueira” Fonte: Elaboração do autor (2006).

O diagrama de setas do projeto “Churrasqueira” da figura 1.19 está construído dentro da escala de tempo definida no gráfico de barras que está acima dele, como você pode ver.

Perceba que cada nó está colocado exatamente na coluna que representa o início ou final de uma determinada atividade. Repare, por exemplo, na atividade E – Telhado: o nó onde começa a seta está no início do dia 7 de abril, e o nó no final da seta está no dia 13. A seta E, então, compreende 7 dias.

Mesmo para um projeto simples como este o desenho com setas acaba se tornando razoavelmente complexo e, de fato, não mostra muitas coisas. Da forma como está apresentado parece um modelo diagramático ruim, e o Gráfico de Gantt estava bem melhor, não é?

Acontece que a riqueza desse tipo de diagrama não está em representar na escala temporal o desenvolvimento do projeto, mas sim nos mostrar os seus pontos críticos de atraso. Vamos então fazer duas modificações no diagrama de setas do projeto “Churrasqueira”:


47


Redesenhe o diagrama para que fique mais claro, �

retirando a escala de tempo.

Para não perder a referência das atividades quanto ao seu �

prazo estimado, coloque sob cada seta o número de dias de sua duração.

Com essas duas modificações 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: Elaboração do autor (2006).

Bem, apesar de ser um desenho limpo, ainda não é suficientemente claro para ajudar no planejamento do projeto.

É o momento, agora, de definir alguns conceitos e símbolos para construir os diagramas PERT/CPM. Com tais símbolos, apresentados no quadro da figura abaixo, você poderá fazer a construção final do diagrama do projeto “Churrasqueira” e partir para sua análise como ferramenta de apoio na gestão de projetos.


48


Quadro 1.5 – Quadro com simbologia e nomenclatura utilizados em diagamas PERT/CPM Fonte: Elaboração do autor (2006).

Como se vê no quadro 1.5, alguns novos conceitos estão apresentados, tais como “data mais cedo e mais tarde”, folgas e símbolos com informações.

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 específica da atividade é chamada de “folga”.

A sequência de atividades que define o prazo crítico do projeto, ou seja, aquela seqüência onde alterações implicam uma alteração do prazo total do projeto, é chamada de “caminho crítico”.


49


Volte agora ao diagrama da figura 1.20. É possível, 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”, simplificação 1 Fonte: Elaboração 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 nós do final da atividade E e do início da atividade G pode ser suprimida, juntando então esses dois nós. Com um pequeno rearranjo das setas e dos nós 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 construção foi realizado aqui para demonstrar a construção do diagrama PERT/CPM, mas na prática você pode desenhá-lo diretamente, apenas sabendo as atividades, suas precedências e respectivas durações. Você verá isso num exercício futuro.


50


Figura 1.22 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplificação 2 Fonte: Elaboração do autor (2006).

Tendo agora o diagrama desenhado, você irá introduzir os símbolos que permitem colocar as informações detalhadas do plano.

Em primeiro lugar coloque os nós 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 numeração intermediária (ver figura 1.23).

Como você pode reparar, todas as datas de início, mais cedo e mais tarde, estão 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 (poderíamos também começar com “0” e isso não faz diferença, pois os totais serão os mesmos).

Figura 1.23 – Diagrama projeto “Churrasqueira”, detalhamento 1 Fonte: Elaboração do autor (2006).


51


Tendo a primeira “data mais cedo” definida, você pode ir preenchendo as dc dos outros nós. A dc do nó 20 será a dc do nó 10 mais a duração da atividade ABC, ou seja,

dc20 = dc10 + duraçãoABC

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 nós 30 e 40, conforme figura 1.25.



52


Definido o nó 30 (cujo dc30 = 32) você pode preencher os nós 50 e 60. Repare que o nó 60 será preenchido com a soma da dc do nó 30 e a duração da atividade F, que é mais longa que a atividade HJ. Assim você terá:


Incidem sobre o nó 70 duas atividades com durações diferentes: L e IK. Se você considerar a atividade L, terá dc70 igual a 43, mas se consider a atividade IK, teríamos 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 início da atividade final M. Com isso o diagrama fica assim preenchido:



53


O nó 80 representa o evento de encerramento do projeto e terá também uma marcação de data mais cedo, que nesse caso representa o dia da entrega do projeto. Por ser esse o dia final, então 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á então preenchido completamente o último nó, e poderá fazer o caminho inverso do diagrama preenchendo agora a “data mais tarde” de início de cada atividade. Faça isso e tire as conclusões. Inicialmente você deve preencher o último nó (ver figura 1.28).

Figura 1.28 – Diagrama projeto “Churrasqueira”, detalhamento 5 – início do caminho inverso de preenchimento Fonte: Elaboração do autor (2006).

A data mais tarde do nó 70, dt70 , será encontrada subtraindo-se a duração da atividade M, da seguinte forma:

dt70 = dt80 – duraçãoM

Com isso você obterá dt70 = 48, o que coincide com a data mais cedo desse mesmo nó. Veja a figura 1.29, a seguir.


54


Figura 1.29 – Diagrama projeto “Churrasqueira”, detalhamento 6 – preenchimento das “datas mais tarde” de início de cada atividade Fonte: Elaboração do autor (2006).

Adote o mesmo procedimento para os nós 40 e 60. Para o nó 60 perceba que novamente as datas “mais cedo” e “mais tarde” coincidem, porém para o nó 40 há uma diferença entre elas. Veja a figura 1.30.


A diferença entre datas que se vê no nó 40 é a folga livre (FL). A atividade L pode começar 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 início dentro dessa margem de folga.


55


O nó 50 está ligado ao 60 por uma atividade fantasma, que não tem duração. Assim a sua dt50 será igual à dt60 , ou seja, 45. E o nó 30, como ficará? Há três nós na sua seqüência: 40, 50 e 60. Veja as três expressões possíveis e seus resultados:

dt30 = dt60 – duraçãoF = 45 – 13 = 32

dt30 = dt50 – duraçãoHJ = 45 – 2 = 43

dt30 = dt40 – duraçãoG = 43 – 5 = 38

- Certamente devemos escolher o menor, pois senão afetaríamos todos os prazos do projeto, certo?

Nossa intenção na gestão do projeto é desenvolver o trabalho no menor prazo possível, 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 opções: iniciar o cálculo a artir de dt30 ou de dt40 . Com dt30 obtemos para o nó 20 a data “25” (dt20 = 25), que é a menor e que será então adotada.

Assim, preenchendo também o nó 10, você chegará ao diagrama PERT/CPM final do projeto “Churrasqueira”, apresentado na figura 1.32. Sem dúvida, não é um diagrama fácil de ser


56


entendido à primeira vista, e para ser útil é preciso ter ao lado a tabela de referência das atividades. Porém, ao analisar o desenho com maior cuidado, você verá como é poderosa essa ferramenta para tratar a questão 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: Elaboração do autor (2006).

Você pode verificar que no diagrama o caminho de atividades onde não há folga define o “caminho crítico” das atividades do projeto. Sobre esse conjunto de atividades o gestor deve prestar atenção especial e preparar suas estimativas de recursos e custos.

É possível desenhar o diagrama PERT/CPM sem ter montado o Gráfico de Gantt?

Sim, mas é importante perceber que os diagramas são diferentes e complementares para o gestor.

Enquanto no Gráfico de Gantt é possível ver a escala temporal claramente, bem como a pessoa responsável por cada atividade e também acompanhar o andamento do projeto ao longo do tempo (preenchendo uma barra das tarefas “executadas”), no diagrama PERT/CPM é possível determinar a seqüência de atividades com suas precedências, e perceber claramente quais atividades podem afetar todo o andamento do projeto.


57


Neste sentido é importante ter as duas ferramentas como instrumentos objetivos de apoio ao gestor.

Para criar diretamente um diagrama PERT/CPM, é necessário partir da tabela de divisão de tarefas, conforme visto no exemplo do quadro 1.1. No entanto, aquele quadro apresenta apenas a divisão das tarefas, e será então necessário incluir duas colunas: uma para anotar o tempo estimado de realização da tarefa, e outra para anotar quais as tarefas precedentes obrigatórias.

Faça esse exercício considerando a tabela que você utilizou no exemplo do Projeto Churrasqueira. No quadro 1.6 reapresento a distribuição 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 são desenhadas quando uma atividade tem mais de uma precedência, e neste caso diferentes nós de origem. Ao final do desenho são feitas as simplificações. Seguindo esse roteiro você chegará ao diagrama da figura 1.32.

ETAPA Projeto CHURRASQUEIRA Tempo estimado da etapa (dias) Precedência

A Preparação do terreno 2 -

B Fundações 7 A

C Alvenaria – paredes 15 B

D Alvenaria – reboco e cerâmicas 13 C

E Telhado 7 C

F Piso 13 E

G Carpintaria 5 E

H Tubulação Hidráulica 2 C, E

I Instalação Hidráulica 3 H, F

J Tubulação Elétrica 2 C, E

K Instalação Elétrica 3 J, F

L Pintura Externa 5 G

M Pintura Interna e acabamento 7 I, K, L Quadro 1.6 – Divisão de tarefas, com prazos e precedências, do projeto “Churrasqueira” Fonte: Elaboração do autor (2006).


58


Um dos maiores problemas na montagem desse tipo de tabela será na definição dos prazos de cada etapa. A estimativa de tempo deve ser feita, quando possível, com a ajuda dos membros da equipe. O tempo estimado é algo subjetivo, pois se considera a experiência de cada um. Nesse sentido, há as previsões otimistas, as pessimistas e as prováveis. A bibliografia (KEELING, 2002) propõe definir um tempo provável com a seguinte fórmula para cálculo do “Tempo Estimado” de uma determinada tarefa:

te = ( to + 4tm + tp ) / 6

Onde:

te – tempo estimado da tarefa; �

to – tempo otimista, ou seja, duração prevista mais curta; �

tm – tempo provável, ou seja, duração média prevista; �

tp – tempo pessimista, ou seja, duração prevista mais �

longa.

Ainda assim, há os que consideram o Tempo Estimado nesta fórmula muito “otimista”, podendo-se então 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 seção anterior você viu que para o projeto ser iniciado era preciso analisar sua viabilidade quanto aos recursos, custos, prazo e benefícios. Tendo o planejamento realizado e os prazos estimados, é preciso agora estimar os recursos e custos necessários ao projeto.


59


Seção 4 – Estimativa de recursos

Tendo um planejamento do projeto, você pode agora estimar os recursos necessários para ele. Bem, estimar não é uma ciência exata. DeMarco (1991) propõe algumas definições diferentes, tais como:

Estimativa é a previsão mais otimista que não tem uma probabilidade zero de tornar-se realidade. Ou Uma estimativa é uma previsão que tanto pode estar acima quanto abaixo do resultado real.

Essas definições soam estranhas, mas dizem muito sobre o ato de estimar: é um “chute” que pode marcar o gol ou apenas passar mais ou menos perto. Voce deve ter claro que precisa estimar o melhor possível para evitar riscos durante o projeto.

Quanto aos recursos necessários a um projeto, basicamente há os seguintes:

Materiais � – são os produtos necessários para confeccionar o projeto, tais como matérias-primas, produtos manufaturados, componentes, hardware etc.

Equipamentos � – são as máquinas e ferramentas necessárias para poder trabalhar as matérias-primas, escrever o código de um software, facilitar uma construção etc.

Pessoal � – os recursos humanos aparecem como o principal requisito em projetos, especialmente em projetos de tecnologia; a próxima unidade discutirá este item.

Financeiros � – são os custos do projeto, que advêm dos gastos relativos a materiais, equipamentos, locações, fretes, transportes, pessoal, licenças, direitos autorais, etc (a estimativa de custos é o assunto da próxima seção).


60


Como você estudou na seção anterior, o planejamento do projeto tem um foco muito intenso no prazo geral, pois como projetos são trabalhos com data marcada para acabar, o prazo é determinante.

Para realizar o planejamento foi feita uma divisão de tarefas, e essa divisão é 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 específicas para descrever recursos necessários.

Q quadro apresentado na figura abaixo é um exemplo de relatório a ser preenchido no início do projeto. Este exemplo partiu do quadro anterior, descrito no quadro 1.2. Para cada projeto específico deverá ser construída uma tabela exclusiva, sendo que a coluna dos recursos definirá uma lista de necessidades.

Projeto CHURRASQUEIRA Recursos necessários

Etapa 1 – Preparação do terreno

• Limpeza do terreno Tratores (dois dias)

• Medições e marcações Topógrafo

• Escavações Tratores (um dia)

Etapa 2 – Fundações

• Montagem das madeiras de caixariaXX dúzias de madeira para caixaria;Pessoal para montagem da caixaria;

• Montagem das ferragens da fundação XX barras de ferro;

• Concretagem XX caminhões de concreto

Etapa 3 – Alvenaria

• Construção das paredesXX milheiros de tijolos;Xx sacos de cimento;Etc.

• ........ ...........

Quadro 1.7 – Divisão de tarefas com estimativa de recursos Fonte: Elaboração do autor (2006).


61


Seção 5 – Estimativa de custos

A distribuição de custos do projeto é feita num gráfico chamado de “cronograma físico-financeiro”.

Este deve aproveitar o gráfico de barras que você viu no Gráfico de Gantt, sendo que os custos do projeto podem ser distribuídos ao longo do tempo de duração do projeto. Para cada item, definido nos recursos estimados para o desenvolvimento do projeto, você deverá fazer uma estimativa de gastos.

O uso do gráfico de barras é interessante, nesse caso, devido à clareza visual de apresentação.

- Veja um exemplo para entender melhor esse tipo de cronograma.

A figura 1.33 apresenta o Gráfico de Gantt de um projeto hipotético com sete atividades – Tarefas A até G – cujos trabalhos transcorrem em 16 semanas, aproximadamente quatro meses. Tendo estimados os recursos necessários para desenvolver cada tarefa, os custos podem ser distribuídos por tarefa e por unidade de tempo, neste caso por semana. Sobre o próprio gráfico os valores são anotados, semanalmente.

Figura 1.33 – Estimando custos – cronograma físico-financeiro Fonte: Elaboração do autor (2006).

Fazendo a estimativa de custos por atividade e por unidade de tempo é possível chegar a valores mais próximos do real. Quanto maior a divisão das tarefas, melhor. Anotados todos os valores você fará a somatória, também por unidade de tempo. A cada semana você chega a um valor total, conforme vemos na última


62


linha do gráfico. Com tais valores é possível estimar o valor total de custos do projeto, apresentado no canto inferior direito da figura. Outra visualização dos custos desse mesmo projeto é apresentada na figura 1.34, a qual decorre dos valores obtidos na estimativa do gráfico de barras.

Figura 1.34 – Gráfico de linha do cronograma físico-financeiro Fonte: Elaboração do autor (2006).

Percebemos pelo gráfico da figura 1.34 que o projeto deverá dispor de recursos financeiros bem maiores do que a média nas semanas 6 e 7. Fazendo essa análise pode-se retornar ao planejamento do projeto e, caso necessário, alterar a duração das tarefas que impactam nesses valores, nesse caso especialmente a Tarefa C. Se não for possível alterar, então o caixa do projeto deverá estar preparado para tal fluxo.


63


Síntese

Nesta unidade foram apresentados modelos e métodos muito importantes para o gestor de projetos e de suas equipes. Em primeiro lugar foi feita uma avaliação de como o fluxo de atividades pode ser distribuído em um projeto, de acordo com o tipo de projeto e de suas necessidades específicas. Projetos de tecnologias mais tradicionais, ou com contratos de âmbito conservador, levam a modelos de desenvolvimento com uma cadência diferente, por exemplo, daqueles projetos onde o tempo de chegada ao mercado é fator decisivo de sucesso, ou onde as tecnologias não são dominadas e precisamos fazer revisões e retornos constantes a etapas anteriores.

Depois você viu as técnicas de planejamento que foram desenvolvidas nos últimos cem anos, que basicamente é o período onde a disciplina de gestão de projetos tomou forma. O gráfico 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 Gráfico de Gantt deve-se à força de sua clareza visual para representar o projeto e, recentemente, a implantação de setas de precedência interligando as barras, aumentou ainda mais a sua qualidade como modelo. Esse gráfico também 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 representação dos custos dos projetos discretizados por tarefa e por unidade de tempo adotada, facilitando em muito a estimativa de custos gerais do projeto.


64


Apesar de a imensa utilidade do Gráfico de Gantt, outro método foi desenvolvido para facilitar o planejamento do tempo de duração do projeto – trata-se do método do caminho crítico, denominado genericamente de PERT/CPM. Esse gráfico permite distinguir num projeto qual a seqüência crítica de atividades, de tal forma que o gestor pode prestar atenção específica 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 análise pode-se, então, chegar a estimativas bastante realistas quanto aos recursos necessários ao projeto, e quais seus custos.

Atividades de auto-avaliação

1) Considere o seguinte problema: será implantado um novo sistema de qualidade na EMPRESA, e uma equipe interna foi designada para montar o projeto de implantação, o qual não deve superar dois meses, e que deve ser primeiro implantado no setor administrativo e somente depois no setor de produção da empresa. O projeto tem as seguintes atividades: reuniões do grupo do projeto para definir o programa; redação do programa de qualidade; treinamento do pessoal do setor administrativo; treinamento do pessoal do setor de produção; implantação do programa de qualidade no setor Administrativo; implantação do programa no setor de produção; avaliação dos resultados e conclusão, com entrega dos relatórios à direção. Faça sua análise e, com base nela, preencha o quadro a seguir:

Projeto Qualidade Prazos estimados pela equipe de implantação

Precedências (letras)

A -

B -

C -

D -

E -

F -

G -


65


2) Prepare o Gráfico de Gantt para a planilha de atividades do exercício anterior – Projeto QUALIDADE, e considere ainda que os treinamentos podem ser feitos em seqüência, independente do início do trabalho de implantação no setor de produção.

(Faça de acordo com o quadro apresentado na página 66).

3) Baseado no Gráfico de Gantt que você criou no Projeto Qualidade, reproduza-o e faça logo abaixo dele o diagrama de setas com escala.

(Faça de acordo com a figura apresentada na página 67).


66


Projeto QualidadeA B C D E F G

SD 01 / set02 / set03 / set04 / set05 / set06 / set07 / set




SD 29 / set30 / set01 / out02 / out03 / out04 / out05 / out

SD 06 / out07 / out08 / out09 / out10 / out11 / out12 / out




67


A B C D E F GSD 01 / set

02 / set03 / set04 / set05 / set06 / set07 / set




SD 29 / set30 / set01 / out02 / out03 / out04 / out05 / out





68


4) Modifique o diagrama de setas do exercício 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).


69



70


5) No exercício anterior, onde há uma Folga Livre (FL)? O que isso significa para o gestor do projeto QUALIDADE?


71


Saiba mais

Nesta unidade, você estudou modelos de representação como forma de entender um projeto, a partir de uma visão geral. Para o desenvolvimento de software surgiu uma tecnologia que busca criar modelos de representação, por meio de diagramas, que muito se assemelham aos diagramas genéricos que usamos aqui. Essa tecnologia é chamada “UML – Unified Modelling Language”, e está baseada na modelagem de diversos tipos de diagramas, os quais abrangem diferentes visões de um projeto de software, seja ele simples como o “Hello World / Alô Mundo”, que se vê em Java, seja de sistemas das mais variadas complexidades. 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 organização internacional sem fins lucrativos, e toda sua documentação pode ser encontrada na internet. Vários softwares para desenvolvimento UML estão disponíveis hoje para download gratuito, como, por exemplo, o POSEIDON.

As idéias da Microsoft para gestão de projetos de software também estão disponíveis na internet. Análises de risco, estimativas, grupos de trabalhos e diversos outros conceitos são discutidos no que eles chamaram “Microsoft Solutions Framework – MSF”.


2UNIDADE 2

Estruturando a equipe


Compreender aspectos da formação e �estruturação de equipes, conforme cada tipo de projeto discutido nas unidades anteriores.

Perceber como contornar os problemas de �estruturação de uma equipe.

Reconhecer os diversos modelos de estruturação �de equipes em diferentes organizações.

Compreender as dificuldades que um gestor pode �trazer ao trabalho com projetos quando não se ajusta a um perfil de liderança criativa.

Compreender que, em projetos, as equipes �precisam trabalhar com objetivos definidos de cooperação e de participação proativa.

Seções de estudo

Seção 1 Estruturando a equipe

Seção 2 Recursos humanos e perfis

Seção 3 Treinamento

Seção 4 Responsabilidade e divisão de tarefas

Seção 5 Terceirização


74



Você verá que esta unidade contém muito mais opiniões pessoais do que “técnicas e dicas infalíveis”. São opiniões baseadas em anos de atuação em diferentes projetos, seja com equipes trabalhando dentro do escritório ou em trabalhos de campo, seja com pequenas empresas ou em grandes corporações, e com modelos de estrutura hierárquica os mais diversos possíveis. No entanto, não são somente opiniões, mas também algumas técnicas e métodos são apresentados aqui.

De início, você verá um modelo de formação de equipes e como se dão os problemas no começo dos relacionamentos, especialmente quando a equipe tem várias pessoas de origens diversas. Esses problemas acontecem devido aos diferentes perfis humanos, ou seja, às diferentes características de comportamento e atitude, muito mais do que diferenças de conhecimento técnico.

As questões técnicas, muitas vezes, podem ser resolvidas por meio de treinamentos específicos e dirigidos. Não é o caso quando temos grandes diferenças comportamentais. Nesses casos, precisamos ter líderes à frente das equipes, pois o que interessa em projetos é ter ambientes de grande cooperação e o interesse sincero (e ousado!) pelo sucesso. Falaremos um pouco sobre liderança, mas deixaremos o principal para a próxima unidade.

Nesta unidade, você estudará apenas algumas alegorias (que espero que sejam divertidas, e esclarecedoras também!).

Você verá também cinco diferentes modelos de estruturação de equipes, que são 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 são muito úteis e nos ajudam a estruturar o grupo de pessoas e comunicar as funções e interfaces de trabalho.


75


Treinamento e terceirização são os outros dois tópicos tratados aqui, sendo que o processo de terceirização assumiu, nos últimos tempos, um caráter estratégico para as empresas e especialmente para os países dominantes, o que tem trazido muita discussão para a arena econômica e política, e isto está ligado diretamente ao nosso objeto de estudo.

Bom estudo a todos!

Seção 1 – Estruturando a equipe

Considere um campeonato de futebol como um projeto: cada time traça seus objetivos, contrata jogadores, treinador, busca recursos e tem datas definidas para chegar aos resultados.

Há inúmeros riscos, pois é uma competição com muitas variáveis. Sabemos que uma questão muito importante, sempre discutida pelos comentaristas e que também é a conversa do início de cada semana após uma rodada emocionante, trata da formação e do entrosamento dos jogadores dentro de campo.

Cada jogador tem sua função, sabemos mais ou menos sobre suas qualidades e alguns são reconhecidos por sua competência. No entanto em cada partida há um comportamento diferente, há um jeito diferente de jogo, e simultaneamente encantamentos e decepções.

Certamente os projetos de pesquisa, de engenharia, de software, não são assim tão famosos nem tão visíveis, mas muitas vezes são bastante emocionantes. E vão depender de quanto há de sensação de “time” na equipe.

Constituir uma equipe é relativamente fácil, constituir um time, não tanto.


76


A equipe é constituída a partir da definição de funções, então é possível determinar as características necessárias de um indivíduo para que preencha tal função. Grandes companhias preparam uma lista de requisitos mínimos para que se procurem funcionários para determinada vaga.

Em algumas equipes há pessoas trabalhando no recrutamento que atuam como máquinas de verificação: olham currículos e buscam aquelas que preenchem tais requisitos, depois fazem as entrevistas e as análises de perfil (psicólogos trabalham nisso) e, por fim, alguém é contratado e passa a integrar a equipe.

Essas companhias enxergam o trabalho como atividade rotineira e, muitas vezes, máquinas e pessoas não fazem grande diferença. Atividades rotineiras suportam equipes assim, mas penso que projetos não.

Projetos, assim como campeonatos, exigem pessoas que trabalhem em cooperação e que gostem, realmente, de chegar aos resultados com sucesso. Em uma equipe convencional, de rotina, cada um faz a sua função (não precisaria ser assim!). Em um projeto os membros da equipe trabalham para ajudar os outros, fazendo a sua função e colaborando para que os outros realizem as suas.

O primeiro conceito importante na formação de uma equipe é a cooperação. O segundo conceito importante é o objetivo comum.

Os membros da equipe devem trabalhar em regime de cooperação em busca de um objetivo comum. Isto já estava claro desde o começo de nosso estudo, pois você viu que uma das chaves de sucesso do projeto é a visão 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 não ganham o campeonato – algo ficou faltando!). Isso quer dizer que não basta analisar as competências pelo currículo. É necessário que além da competência a pessoa que vai fazer parte da equipe de projeto tenha a cultura da colaboração. Isso não pode ser detectado sem a convivência. E gerentes de projetos que não sejam líderes, muitas vezes não conseguirão sacar essa característica. Essa percepção

A pessoa nesse caso é um agente que toma decisões e tem liberdade de ação, ao contrário da máquina.


77


exige experiência e intuição. Aqui estamos saindo do campo das ciências exatas e entrando no campo pantanoso das relações humanas (nada exatas...).

Na estruturação da equipe de um projeto, conforme Valeriano (1998), há quatro momentos distintos:

Formação. Quando se reúnem os membros do projeto e as funções são distribuídas, ainda não há clareza das atividades a serem realizadas As pessoas não se conhecem e o tratamento é formal. Por não haver conhecimento há um ambiente de confusão inicial.

Turbulência. A partir do início das atividades começam a se formar subgrupos a partir de afinidades pessoais, e muitas vezes principiam atritos, especialmente em equipes grandes com pessoas de variados tipos. A turbulência é comum em projetos, especialmente quando os riscos são grandes e iminentes.

Normalização. Se os períodos de turbulência são resolvidos pela liderança, os processos de trabalho passam a ser bem conhecidos e aceitos por todos, as atividades tornam-se claras, assim como os objetivos, estabelecem-se normas internas e o trabalho passa a andar.

Desempenho. Nesse período a equipe entra em equilíbrio criativo e cooperativo, e o projeto tem alto rendimento. Os membros sentem-se parte do time de trabalho, reconhecem a liderança e os companheiros como importantes em seu próprio papel.

Essas quatro fases de estruturação podem acontecer ou não, sendo que muitos projetos chegam a crescer até a normalização apenas, sem atingir o ambiente propício do “desempenho”. Sustentar a fase do desempenho é, além de tudo, uma tarefa difícil que exige esforço contínuo. Veja na figura a seguir o diagrama esquemático dessa estrutura.


78


��

��

��

��

��

��

��

��

Figura 2.1 – Representação esquemática das fases de estruturação da equipe de projeto Fonte: Elaboração do autor (2006).

Seção 2 – Recursos humanos e perfis

Como você viu na seção anterior, a escolha de perfis humanos para trabalhar em uma equipe de projeto está fora da escolha de características exatas, características pré-definidas e nas quais algumas pessoas “especiais” se encaixariam. Esse é o campo das relações humanas, relações sempre sutis, delicadas, que variam infinitamente.

Os membros da equipe acabam por se moldar às características do gestor. Se o gestor for um líder, poderá conduzir sua equipe para a fase do “desempenho”. Se não, provavelmente permanecerão na fase da “normalização”. Portanto será importante discutirmos os perfis dos gestores, sejam líderes ou não. Mas antes de falar dos gestores/líderes, vamos tentar descrever alguns perfis típicos das pessoas que virão a fazer parte de nossas equipes de projeto.


79


Keeling (2002) apresenta diversos tipos de perfis citando outros autores como Margerison e McCann, que comentam sobre oito diferentes papéis, Belbin, que classifica nove grupos descritivos, ou Parker, com apenas quatro papéis. Os quatro papéis de Parker, citados por Keeling (2002) são:

Contribuidor. � Aquele que contribui com atividades e resultados, mas não é participativo.

Colaborador. � O que participa do desenvolvimento em conjunto.

Comunicador. � Capaz de comunicar as atividades e de integrar grupos por meio da comunicação.

Desafiador. � O que sempre apresenta as questões e participa dos trabalhos num espírito de desafio (o que pode ser bom ou ruim, depende da situação e do caso).

Essas tentativas de classificação muitas vezes caem no vazio, tal é o número de possibilidades e de percepções. Muito provavelmente não é possível ser “científico” nesse caso, e a classificação será local e temporal, ou seja, dependerá do ambiente, da situação e das condições culturais de um determinado grupo.

Pela dificuldade do tratamento “científico” (se é que isso é necessário), posso fazer uma brincadeira e descrever alguns perfis que já participaram de projetos junto comigo, e que no decorrer das experiências foram se formando como tipos, facilmente reconhecíveis. Veja alguns:


80


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 disposição 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 atenção sobre o fato dos projetos em geral não 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 não conhecem tudo sobre tudo, muitas vezes alguém que domina meia dúzia de belas frases técnicas e alguns acrônimos da moda, passa por especialista. Na informática isso é muito comum, e tenho visto em conferências por aí aqueles profissionais que aparentam grande conhecimento e que não resistem a mais do que duas perguntas; para nossos projetos, vamos nos cuidar com esse tipo.

O que é especialista, mas não se entende com os outros. � Vale a mesma máxima de especialista do item anterior, porém 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 são trabalhos de cooperação, sua especialidade perde o valor automaticamente; melhor alguém que sabe “um pouco” sobre o “quase nada”, e que possa cooperar com aqueles que estão à sua volta.

O que “puxa-saco”. � Não é preciso pensar muito para lembrar de pessoas com esse perfil, pois não há grupo que não tenha esse membro (infelizmente); concorda sempre com o superior hierárquico, 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 força, e não consegue agir com opinião própria; deve ser eliminado da equipe sempre que for descoberto.


81


O que suga energia. � Em uma equipe de alto desempenho buscamos cooperação e boa vontade, e quando há divergências elas são tratadas como geradoras de novas soluções. Contudo há o perfil de pessoa que funciona como um “buraco negro”, sugando idéias e a energia do resto dos membros de equipe; é difícil perceber essa ação, e muitas vezes só fica evidente depois de muito tempo, e muito estrago.

O que não comunica. � Comunicação é fator crítico de sucesso em projetos, mas a dificuldade de comunicar com clareza e objetividade é algo muito comum; não estamos livres desse problema, e temos que ficar atentos em nós mesmos e em nossas ações; 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 característica do detalhista operacional: não 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 integração, a dificuldade de melhorar, a dificuldade de achar erros etc.

O que é generalista estratégico. � Perfil diametralmente oposto ao anterior, sempre está olhando o projeto, e qualquer atividade, de um ponto de vista muito genérico; tem dificuldade para “colocar a mão na massa”, pois sempre tem uma visão nova, geral, para colocar, e não percebe o momento de partir da superfície para o fundo, ou seja, consegue navegar mas não mergulhar.

Esta lista pode se estender por páginas e páginas. Deixarei para você imaginar alguns outros perfis problemáticos.

Analisando perfis problemáticos, você consegue avaliar quem manter e quem evitar em sua equipe de trabalho? Reflita sobre isso!


82


Por outro lado temos a figura do gestor, e variados perfis também têm sido escritos sobre ele. As publicações sobre gestão e estudos de gerenciamento discorrem sobre técnicas e métodos de gestão, mas ultimamente há ênfase sobre as características da liderança acopladas à atividade gestora.

Conheci um sujeito que não gostava da palavra “líder”, pois associava essa imagem com a figura do carisma, a alguém cheio de seguidores fanáticos. Esse sujeito certamente não era um líder de projetos, nem de empresas (de fato não era, pois fugia das situações críticas, amedrontado).

Se, nos parágrafos anteriores, discorremos sobre variados perfis de membros de equipes de projeto, cabe também apresentar alguns perfis de gestores.

Na próxima unidade, as funções dos líderes e suas relações com os membros da equipe, durante a execução do projeto, serão discutidas em maior profundidade. Aqui vamos ficar apenas com algumas notas sobre perfis de gestores, na forma de caricaturas (ou seja: como não ser um gestor!).

A brincadeira é a seguinte: sem ofender o mundo animal vamos descrever três modelos diferentes de gestores comparando-os com o comportamento de animais. Obviamente esses animais não se comportam exatamente assim mas, como metáfora, podem ser úteis e você perceberá que há muitas pessoas agi ndo assim (não só em filmes!). Bem, eu já conheci. Vamos a eles:


83


Gestor-rinoceronte. � Quando você vir aquele gerente andando em passos largos e falando alto na direção de um funcionário da equipe, o tom ameaçador já denunciará a performance de rinoceronte; ele não precisa ser gordo nem grande, basta esse comportamento de quem quer resultado pelo aspecto ameaçador. A cara é de tonto e o seu conteúdo de conhecimento é quase nulo, mas não se pode duvidar que se esbarrar com ele, trará conseqüências físicas (mas não inte-lectuais, pois seu estilo não é esse). Esse é o famoso “gerentão”, que pensa em obter resultados de sua equipe de projeto cha-mando a todos todo o tempo para cobrar algum resultado, resultado que ele mesmo não tem certeza qual seria, devido à sua falta de domínio. Esse tipo é introjetado no cargo por algum outro superior (talvez um gerente-raposa), e sua equipe se divide entre os que têm medo e os que querem distância.

Como evitar ser um gestor-rinoceronte? Respeitando os membros da equipe, ouvindo com educação, estudando o projeto, respeitando as dificuldades, assumindo os riscos em parceria, participando como um colaborador e não como um cobrador truculento.

Gestor-cobra. � Diferente do rinoceronte, esse tipo de gestor evita confrontos e prefere agir sorrateiramente. Você não está vendo, mas sabe que ele está observando suas ações de longe, pronto para atacar se qualquer coisa sair errada. Em sua frente ele está quieto, muitas vezes com aquela edu-cação disfarçada e o esforço para parecer no controle. Se alguma apresentação pública do projeto for necessária ele designará um membro da equipe, pois ele mesmo não vai se expor. Compartilha com o rinoceronte o desconhecimento dos detalhes do projeto, mas como fala pouco não é possí-vel determinar até onde conhece ou não conhece. Ética para ele é uma palavra de dicionário, não um comportamento. Com esse tipo de gestor o grupo de projeto acaba se con-formando a entregar apenas o mínimo necessário, e aque-les que ousam destoar são aniquilados sorrateiramente.

Como evitar ser um gestor-cobra? Admitindo as diferentes visões da equipe, expondo-se, sendo claro, agindo com ética nos relacionamentos, não destilando o veneno da negatividade entre pessoas que esperam criação e liberdade.


84


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 não está vendo, o tipo “raposa” é muito mais sutil e muitas vezes engana inúmeras pessoas com seu ar de sabedoria. Por isso chamamos determinado político de “raposa”: ele é esperto e ágil, e sempre quer se dar bem pelas articulações que faz (em proveito próprio, certamente). Esse tipo de gestor não se importa com os membros da equipe, e afaga suas cabe-ças enquanto esses lhe servem. No entanto no dia que algo ameaça sua posição, busca uma maneira sutil de desviar o inconveniente. Não há projeto criativo que ande bem com esse tipo de gestor, pois não admite as diferenças. O que o distingue do tipo “cobra” é que não 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 idéia dentro da equipe para ele é uma ameaça, pois aquele membro poderia ser superior a ele. Se tiver um rinoceronte e uma cobra a seu serviço, eles farão o serviço sujo por ele.

Como evitar ser um gestor-raposa? Fazendo um exercício por admitir as diferenças, 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, não é? Mas a realidade tem mostrado que a maioria dos gestores, infelizmente, acaba se adequando a um desses papéis, ou híbridos deles.

Por fim, na definição 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 desejáveis e de funções necessárias em um projeto. Digamos que se tenha um grupo de pessoas na empresa que possa vir a participar do projeto, e precisamos definir suas posições. Ao mesmo tempo sabe-se as competências técnicas necessárias, e comportamentais também, 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 papéis. Olhando para a matriz temos a tendência a eleger o “profissional F”


85


como líder da equipe, pois tem experiência e dispõe de tempo, enquanto o “profissional D” é novo na empresa, e isso pode gerar algum desconforto. Em domínio técnico vemos que os profissionais B e E são capacitados, mas não dispõem de tempo livre (podem estar engajados em outros projetos), e a alternativa será discutir com eles as possibilidades de rearranjo de trabalhos.

Perfil e necessidades Conhecer tecnologia

“1”

Conhecer tecnologia

“2”

Conhecer tecnologia

“3”

Dominar uso de

“X”

Exp. de trabalho

em equipe

Exp. de trabalho

em equipe

Disp. de tempo

Novo na empresa

Membro da equipe

Profissional A X X X

Profissional B X X X X

Profissional C X X

Profissional D X X X X

Profissional E X X X X

Profissional F X X X

Quadro 2.1 – Matriz de perfis e competências profissionais Fonte: Elaboração do autor (2006).

Seção 3 – Treinamento

A educação é anterior ao treinamento. Para que haja algum treinamento é necessário que os membros da equipe tenham uma educação prévia e apropriada.

A formação do conhecimento e a aprendizagem passam pela análise crítica e pela reflexão, próprias do ser humano, enquanto que o treinamento para atividades rotineiras pode ser feito até mesmo com animais.

No início da revolução industrial foi necessária mão-de-obra treinada para operar máquinas, e tal operação passava por uma repetição contínua de procedimentos. Muitas críticas foram dirigidas a tais atividades, que de alguma forma se repetem até hoje, especialmente nos países em processo de industrialização.


86


Esse ambiente de início de industrialização teve espaço no Brasil mais ou menos no meio do século passado, quando grandes indústrias de base foram criadas.

Nosso país, de certa maneira, não evoluiu muito desse ambiente de indústrias básicas, processadoras de matéria-prima, e facilmente se percebe isto vendo a importância econômica que tais empresas têm entre as “500 maiores”. Indústrias da era da informação (que exigem mais educação do que treinamento) ainda são incipientes, ao contrário do que acontece na Europa ou América do Norte.

Considerando que estamos aqui estudando projetos de desenvolvimento e inovação, o treinamento cabe como complemento e ajuste para a equipe.

Veja o exemplo de matriz do quadro 2.1. Precisamos de algumas competências específicas de tecnologias para o desenvolvimento do projeto, alguns treinamentos serão necessários para uniformizar os conhecimentos dos membros da equipe. Isso deve estar no foco da gerência do projeto, para evitar que o desconhecimento técnico seja empecilho ou fator de risco. Mas se o projeto for de longo prazo, é melhor criar alternativas de educação em grupo do que meros treinamentos de curta duração, cuja função é atender objetivos bem definidos e de alcance imediato.

Ainda na matriz do quadro 2.1, se observa que há perfis desejáveis e que, aparentemente, não são preenchidas pelos seus membros (como liderança, por exemplo). Ultimamente têm tido ênfase os treinamentos para líderes, e tenho visto nas empresas o interesse (superficial em muitos casos) de oportunizar o surgimento de lideranças.

Treinamentos são criados para esses casos, e gerentes são envolvidos neles.

A liderança é, no entanto, mais uma questão de comportamento e atitude do que de técnica. O incentivo a esse surgimento deve passar por um ambiente que estimule a liberdade de expressão e experimentação.

Nessa época foi criado o Senai, até hoje responsável por treinamento de mão-de-obra para esse tipo de indústria.


87


Treinamentos são feitos para tecnologias, não para comportamentos.

Seção 4 – Responsabilidades e divisão de tarefas

Em um projeto as atividades são divididas ao máximo, como você viu na composição de Diagramas de Gantt, unidade 4. A divisão das atividades é feita para se ter clareza dos objetivos e para perceber as entregas parciais. Também no Diagrama de Gantt atribuímos tarefas para os membros da equipe e, assim, cada um enxerga suas metas e seus prazos. Atividades diferentes para pessoas diferentes.

A distribuição de responsabilidades será feita de acordo com o modelo adotado pela gerência do projeto. Há gestores que centralizam em excesso as decisões, e outros que delegam. O equilíbrio dependerá bastante do seu perfil, assim como da acomodação dos membros da equipe.

Segundo Page-Jones (1990), “prioridades são para gerentes, não para funcionários”. Com isso ele quer afirmar a distribuição de responsabilidades conforme o papel de cada um na equipe. Para a gerência do negócio a meta é o resultado global e a satisfação do cliente, enquanto para o desenvolvedor a meta é a entrega conforme a especificação da sua tarefa. Este é o Modelo de Equipe definido no framework da Microsoft (MSF, 1998) quando define papéis em uma equipe. Assim, para cada um, uma tarefa de cada vez.

Para definir os papéis e comunicá-los à equipe é importante criar um organograma, definindo as funções e a hierarquia dos membros. Há inúmeras possibilidades de estruturar tal organograma, e isso dependerá da complexidade do projeto, da empresa onde a equipe de projeto está sendo montada, de como o projeto interfere nas atividades da empresa, etc. Segundo Keeling (2002), há cinco estruturas típicas de grupos de projetos:


88


Estruturas diferenciadas e exclusivas.1.

Estruturas híbridas.2.

Estruturas matriciais.3.

Estruturas modulares.4.

Estruturas horizontais.5.

Vamos discutir as principais delas e ver como podem se adequar aos nossos projetos.

Estruturas exclusivas

Projetos de pequeno porte, que consigam ter seu próprio pessoal e recursos exclusivos, e têm pequena complexidade, podem montar estruturas organizacionais simples e funcionais. Esse tipo de estrutura é direta em seus procedimentos e fácil de ser compreendida pelos membros da equipe. Pequenas empresas de engenharia da construção, por exemplo, trabalham desta maneira, onde o gestor do projeto trabalha com um conjunto de técnicos e pessoas de apoio administrativo, e ele reporta diretamente ao cliente final. A figura 2.2 apresenta o diagrama desse modelo, que é chamado de estrutura exclusiva porque os membros do projeto são dedicados a um projeto apenas.

��

��

��

��

Figura 2.2 – Estrutura exclusiva Fonte: Elaboração do autor (2006).


89


Estruturas híbridas

Em projetos internos às empresas maiores, onde vários projetos ocorrem ao mesmo tempo, as estruturas híbridas passam a ocorrer com maior freqüência. Veja a figura 2.3, onde um organograma típico desse modelo de estrutura é apresentado. O gestor do projeto conta com membros dedicados exclusivamente àquele trabalho, mas precisa paralelamente recorrer a outras pessoas, que não estarão dedicadas a esse projeto, mas que são importantes para ele e que simultaneamente se dedicam a outras áreas dentro da empresa. Se o gestor do projeto tiver liberdade de trabalho para recrutar tais pessoas, e dispuser de parte do seu tempo, o projeto terá sucesso. Empecilhos ocorrem quando essa liberdade não lhe é permitida, o que levará o projeto a atrasos e dispersões.

��

��

��

��

��

��

��

Figura 2.3 – Estrutura híbrida Fonte: Elaboração do autor (2006).

Estruturas matriciais

Estruturas matriciais são 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


90


da empresa, e não dos projetos exclusivamente, ou seja, cada funcionário está inserido em determinado setor da empresa e executa serviços que atendem ora a um projeto, ora a outro. Alguém estará responsável pelo projeto, e será definido como seu gestor, mas mesmo esse gestor pode estar designado para mais de um projeto, ou para partes de um projeto, sendo que esse mesmo gestor está alocado a um determinado setor/departamento da empresa. Sem dúvida a coordenação desse tipo de estrutura é mais complexa, e exige alto grau de organização geral da empresa, especialmente em relação aos planos de produção.

��

��

��

��

��

��

��

��

��

��

Figura 2.4 – Estrutura matricial Fonte: Elaboração do autor (2006).

Estruturas modulares

Estruturas modulares ocorrem quando, dentro da empresa, há grupos com relativa autonomia e determinada especialização, que realizam determinado tipo de serviço. O gestor de determinado projeto emprega esse grupo modular para desenvolver parte do projeto, e vai distribuindo assim as atividades conforme as especializações. Internamente o grupo (ou módulo de desenvolvimento) tem autonomia para gerenciar aquela etapa,


91


sendo que o gestor geral do projeto percebe a entrada e a saída do módulo, mas não propriamente o que acontece em seu interior. Projetos de software, por exemplo, envolvendo grandes equipes com diferentes conhecimentos, podem usar esse tipo de estrutura.

��

��

��

��

��

��

��

Figura 2.5 – Estrutura modular Fonte: Elaboração do autor (2006).

Estruturas horizontais

As estruturas horizontais geralmente são formadas por poucos membros, onde há uma grande maturidade no trabalho em conjunto. As relações se dão em rede, onde todas as pessoas se relacionam com todas as outras. O líder do grupo tem a função de acompanhar o andamento das atividades, e ele mesmo muitas vezes é membro ativo do desenvolvimento do projeto, como por vezes acontece em trabalhos de pesquisa e desenvolvimento reunindo pesquisadores diversos. Projetos que usam esse tipo de estrutura reúnem especialistas e, por esse motivo, o líder geralmente é também um especialista técnico ou científico, de tal forma que sua ascendência sobre o grupo seja inequívoca.

A figura 2.6 mostra exemplo de configuração de uma estrutura horizontal. O modelo de desenvolvimento de aplicativos da Microsoft (MSF, 1998) também se baseia nesse modelo horizontal, definido por “pequena equipe de pares ou especialistas trabalhando em papéis multidisciplinares e interdependentes”. A questão da multidisciplinaridade, que surge


92


aqui, tem especial interesse em projetos de inovação tecnológica, como no caso dos aplicativos. O ambiente proporcionado por uma estrutura horizontal permite os diálogos constantes e a troca positiva de idéias, nascedouro de soluções criativas.

��

��

��

��

��

��

��

Figura 2.6 – Estrutura horizontal de equipe de projeto Fonte: Elaboração do autor (2006).

Seção 5 – Terceirização

A palavra terceirização entrou na moda há uns dez ou vinte anos atrás, e foi uma solução adotada na indústria para otimizar seus modelos de produção. Basicamente consistia em contratar partes da produção com empresas externas, ou terceiras, em vez de produzir com equipes próprias.

Com isso era possível obter uma concentração de esforços, dentro da empresa, em atividades e conhecimentos que lhe eram próprias, não sendo necessário desenvolver competências diversas.


93


O uso de empresas de transporte foi uma terceirização do serviço de entregas, por exemplo. A terceirização caminhou cada vez mais para dentro das empresas e, então, partes do produto passaram a ser feitas por outras empresas (por exemplo, as peças diversas de um carro. E é por isso que as fábricas de automóveis são chamadas hoje de “montadoras”.

Mas isso implicou também um enorme esforço de controle de qualidade e de prazos de entrega, pois uma parte do processo que falhasse comprometia todo o conjunto. Veio do Japão então a expressão “ just in time”, para significar os procedimentos de entrega no prazo exato.

Com o passar do tempo percebeu-se que a terceirização poderia avançar muito mais, pois fabricar pedaços de ferro e montá-los não era o segredo de uma empresa, e sim a concepção, o desenho, a inteligência da criação do produto. A partir disso uma cadeia imensa de pequenos fabricantes se estabeleceu, e hoje muitos esforços dos governos por trazer grandes empresas se dão pela intenção de formar cadeias produtoras ao redor delas.

No entanto, estamos falando de terceirização de tarefas contínuas da indústria, enquanto que no caso dos projetos, a idéia é um pouco diferente, por se tratar de serviços de duração limitada e com objetivos pré-definidos.

A terceirização 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 possível a terceirização, é necessária uma sincronização muito forte entre o trabalho que está sendo executado pela equipe interna do projeto e a equipe ou pessoa que ficará responsável pelo trabalho externo, ou terceirizado.

A estrutura modular, mostrada na figura 2.5 anteriormente, é uma possibilidade de trabalhos desse tipo, pois cada grupo ou módulo, pode ser visto como uma unidade independente que tem uma determinada tarefa a cumprir. Identificar as competências de tais grupos e ter os trabalhos alinhados entre os diferentes grupos é o desafio.


94


A indústria da construção civil já atingiu essa maturidade para a terceirização de serviços de um projeto. Equipes de empreiteiros diversos, grupos externos de eletricistas e técnicos hidráulicos, entre outros, atuam como terceirizados no projeto. Isso funciona adequadamente porque a indústria da construção civil repete os procedimentos obra após obra, e cabe ao engenheiro da obra fazer a gestão desses diferentes grupos.

Mais recentemente a indústria de software tem trazido exemplos de terceirização.

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), vêm trazendo um alto grau de profissionalização para o setor de software, fazendo com que haja uma segmentação bem delimitada na produção dos aplicativos.

Isso vem gerando grandes debates nos Estados Unidos, pois muitas atividades consideradas estratégicas nessa indústria passaram a ser terceirizadas em outros países, especialmente Índia e China, que competem utilizando mão-de-obra qualificada, porém muito mais barata do que a americana. São os efeitos da globalização numa indústria que não precisa mais do que uma rede como a internet para fazer todo o “transporte” das partes e peças terceirizadas.

Para encerrar esse assunto, veja os dois quadros reproduzidos abaixo, onde o primeiro aponta para o aumento dos contratos de terceirização, publicado no site da ASSESPRO – SC, e o segundo com a matéria publicada no site da SOFTEX, que reproduz texto a respeito dos riscos da terceirização apontados pela empresa de consultoria Gartner dos Estados Unidos. Esse é um assunto bastante atual e que deverá perdurar nos debates devido ao processo de globalização acelerado dos mercados, especialmente os ligados às inovações tecnológicas e à informação.


95


Terceirização de software e serviços de TI cresce

Mercado mundial de terceirização deverá crescer 7,9%. De acordo com um estudo do Gartner esse percentual corresponde aos anos de 2003 a 2008.

A terceirização continua crescendo em todo o mundo, embora em ritmo diferente, em relação à região analisada, de acordo com estudo do Gartner.

A taxa Composta de Crescimento Anual (CAGR) de terceirização será de 7,9%, entre 2003 e 2008, enquanto a taxa total de crescimento de TI atingirá 5,4%.

Os gastos com terceirização de TI e terceirização de processos de negócios (BPO), em âmbito mundial, crescem mais rapidamente do que os gastos com serviços individuais e aqueles baseados em projetos.

Isso reflete uma tendência de crescimento da terceirização, que vai além do mero gerenciamento de sistemas e processos já implementados. As empresas terceirizadas estão 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 avanço do mercado de serviços em regiões diferentes: o primeiro refere-se à cultura local e às práticas de negócios; e o segundo, diz respeito aos padrões estabelecidos pelas grandes companhias globai s que compõem o mercado.

Sobre a situação do mercado local, o Brasil e o México são os líderes em terceirização na América Latina, seguidos do Chile e da Colômbia.

Quadro 2.2 – Sobre o aumento da terceirização Fonte: Softex (2005).


96


Gartner aponta riscos da terceirização offshore Por COMPUTERWORLD

Empresas de todo o mundo gastarão mais de 50 bilhões de dólares com iniciativas de terceirização offshore (fora do país) ou near-shore (dentro do país) de TI até 2007, aponta a consultoria Gartner. No entanto, alerta a companhia em um novo estudo, muitos projetos falharão devido a planejamentos mal estruturados.

Muitas companhias têm buscado nas estratégias de terceirização de TI uma forma de obter vantagem competitiva frente aos concorrentes, seja com redução 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 terceirização, seja esta feita por meio de um parceiro local ou por um especializado de outro país.

1. Redução de custos impraticável

Muitas companhias decidem buscar serviços em outros países, com o propósito de reduzir custos. Segundo o Gartner, um profissional de manutenção de aplicações indiano, por exemplo, ganha cerca de 25 dólares por hora, contra a média de 87 dólares cobrados pelo mesmo serviço, nos Estados Unidos.

Contudo, é um erro limitar os custos da operação apenas ao salário do funcionário. A consultoria alerta para outros gastos atrelados a fatores como infra-estrutura, comunicações, viagens e treinamento relacionado a questões culturais. Portanto, o custo inicial da operação é alto e, em muitos casos, pode ser mais rentável após um ano de operação.

2. Perda de produtividade

Pelo menos inicialmente, os prestadores de serviços offshore tendem a não apresentar a mesma produtividade que a companhia mantinha internamente. De acordo com o Gartner, em mercados emergentes muitos programadores são jovens e não possuem a mesma experiência que a companhia encontra em seu país de origem.


97


3. Comprometimento e comunicação enfraquecidos

Muitos executivos simplesmente esquecem seus contratos depois que são assinados. A consultoria alerta para a necessidade de se estar engajado com o prestador de serviços para que se mantenha a qualidade de serviços pré-acordados.

Estabelecer uma boa comunicação 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 operações para outro país traz mais benefícios para a companhia.

4. Diferenças culturais

Estilos de comunicação e atitudes de autoridade mudam conforme a região e estas diferenças podem trazer problemas. Em algumas culturas, o ato de questionar a autoridade de determinada pessoa é considerado falto de respeito. Empresas interessadas na terceirização offshore devem realizar treinamento entre equipes para evitar esse tipo de situação, alerta o Gartner.

5. Distância entre teoria e prática

Algumas organizações podem vender mais do que realmente oferecem. É preciso que o prestador de serviços tenha todos os processos internalizados com suporte e segurança, antes de colocar um projeto em operação. O Gartner também destaca para a necessidade de se verificar o grau de maturidade dos processos da empresa, utilizando padrões 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 terceirização Fonte: Softex (2005).


98


Síntese

Nesta unidade você estudou os princípios da estruturação de uma equipe de projeto. O conceito fundamental, muitas vezes repetido e exemplificado, é o do trabalho cooperativo. A cooperação Inicialmente foram apresentados os quatro passos que se dão na formação das equipes de projeto: o período inicial da formação, seguido muitas vezes de um ambiente turbulento, quando os primeiros subgrupos se formam e há distâncias a romper, depois o período onde as normas de trabalho se impõem e a liderança institui uma normalização, seguido então do período de desempenho cooperativo e onde, de fato, os resultados começam a aparecer.

Depois vimos que os perfis são muito variados, e também são dinâmicos, ou seja, as pessoas têm comportamentos diferentes conforme o meio em que estão. Para dividir as tarefas e encontrar os perfis corretamente, uma técnica interessante é preparar uma matriz de competências, conforme vimos exemplo no quadro 2.3.

Com essa matriz é possível estudar diferentes composições de pessoas na equipe. Ajustes de competências técnicas 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 têm uma educação de base adequada. Nisto é que se diferencia o treinamento da educação.

Para organizar o grupo de trabalho em diferentes tarefas, cinco modelos estruturais foram apresentados:


99


1. Estruturas diferenciadas e exclusivas, com pessoas dedicadas exclusivamente ao projeto;

2. Estruturas híbridas, onde há uma composição de dedicações exclusivas e outras parciais;

3. Estruturas matriciais, em que pessoas de uma organização trabalham em difentes projetos simultaneamente, conforme suas habilidades, sendo que o gestor do projeto é o responsável por administrar essa locação e os resultados parciais,

4. Estruturas modulares, formadas por pequenos grupos dedicados a sub-projetos, os quais podem colaborar para um projeto ou vários, e;

5. Estruturas horizontais, geralmente em projetos pequenos e que envolvem pares de especialistas, os quais não têm um comando central.

Esses modelos podem ser ajustados caso a caso, e dependerão da experiência e liderança do gestor para que obtenham o desempenho desejado.

Por fim, esta unidade tratou da terceirização como uma variação a mais dos modelos estruturais anteriores. A terceirização vem se expandindo em todas as atividades produtivas e alcança também os processos de trabalho relacionados a projetos. No caso do desenvolvimento de tecnologias da informação há apreensão, pois a terceirização tem deslocado os serviços para regiões remotas, que têm preocupado tanto no sentido da perda de empregos quanto na perda do controle do conhecimento como do próprio andamento do projeto.


100



1) Quais são as quatro fases de estruturação da equipe e, em sua opinião, qual a mais problemática? Por que a fase escolhida é a mais problemática?

2) Como uma matriz de perfis e competência pode ajudar na estruturação de uma equipe?

3) Em sua opinião, qual tipo de estrutura de equipe melhor se ajusta ao desenvolvimento de software em uma pequena empresa, cujos projetos são iniciados apenas sob a demanda do cliente?


101


4) Qual o modelo de estrutura representado na figura abaixo? Qual o seu grande problema?

��

��

��

��

��

��

��

��

��

��

5) Em que tipo de estrutura é possível uma grande troca de conhecimentos, sendo que as pessoas trabalham entre pares? Qual a vantagem desse tipo de estrutura na indústria de softwares?


102


6) Como você avalia os riscos da terceirização na área de software?

Saiba mais

Veja a dissertação de mestrado de Leandro Patah, “Alinhamento estratégico de estrutura organizacional de projetos: uma análise de múltiplos casos”. Este trabalho foca em diversos tipos de estrutura, especialmente a matricial, e trará conhecimentos aprofundados sobre o tema.

Entre novamente no site da SOFTEX e veja os estudos sobre terceirização, bem como o estudo comparativo entre as indústrias de software no Brasil, China e Índia. Há exemplos de como a terceirização alavancou a indústria indiana, por exemplo.


3UNIDADE 3

Executando o projeto


Compreender aspectos do início de um projeto e como o �seu bom entendimento permite a gerência e o controle eficaz da qualidade.

Perceber as diferenças básicas entre líderes e gestores. �

Estudar técnicas e práticas para controle de prazos e �recursos, encontros de trabalho e gestão de conflitos.

Verificar as várias subdivisões e etapas intermediárias que �um projeto de sucesso demanda.

Seções de estudo

Seção 1 Preparação e início dos trabalhos

Seção 2 Liderança versus gestão

Seção 3 Tomada de decisões

Seção 4 Motivação e comunicação

Seção 5 Reuniões

Seção 6 Gerenciando qualidade, tempo e recursos

Seção 7 Gestão de conflitos

Seção 8 Simulação, testes e validação


104



Tendo uma série de ferramentas e práticas de planejamento em mãos, estudadas anteriormente, chegamos ao dia-a-dia de trabalho do projeto. Neste momento teremos que colocar em prática o planejamento, e novas dificuldades certamente surgirão. Esta unidade apresenta questões práticas relacionadas com o início do projeto, com os possíveis conflitos advindos do choque entre pessoas da equipe com variados perfis, bem como as características do gestor do projeto para tratar tais conflitos e dificuldades.

Em especial é debatido o perfil do gestor quando comparado com o do líder, assunto que vem tomando parte de muitos debates sobre desenvolvimento tecnológico e inovação já que tais diferenças de perfis podem afetar positiva ou negativamente o desenvolvimento do projeto e mesmo dificultar a administração de conflitos, por exemplo.

Também nesta unidade é tratado o tema das simulações e testes de revisão contínua, 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!

Seção 1 – Preparação e início dos trabalhos

Até agora já falamos muito sobre planejamento, sobre estimativas de recursos, análise de riscos, formação de equipes de trabalho e muitas outras coisas, mas chegou a hora de “colocar a mão 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 também). Na realidade, a produção em projetos é uma decorrência do planejamento, pois como já foi dito várias vezes, o projeto é um trabalho com data marcada para acabar, enquanto as atividades


105


de produção de rotina não têm tal finalidade e as pessoas entram no trabalho de uma empresa ou indústria, por exemplo, quando as coisas já estão acontecendo.

Outro fator importante e, por isso, aparentemente tanta preparação, é que em um projeto é preciso sempre ter a visão do conjunto e não apenas das partes. Tendo realizado tal planejamento, previsto os recursos disponíveis e tendo os objetivos claros e o contrato estabelecido junto ao cliente, é hora de começarmos os trabalhos.

Para preparar e começar o projeto é interessante você considerar as seguintes observações:

muitas pessoas imaginam que trabalhar em um projeto é �

começar imediatamente a programar, ou a perfurar, ou a martelar, ou seja lá o que for que pareça demandar muito esforço. Dessa forma, a energia é despendida logo no começo e, na maioria das vezes por não se saber onde se quer chegar, rapidamente tudo esvaece e o projeto perde, então, o sentido;

trabalhar em um projeto não é despender um enorme »

esforço em direção a um objetivo desconhecido, para aparentar que o suor faz o trabalho. Projeto, necessariamente, exige reflexão;

muitos pensam que ‘alguém’ tem que dar as ordens e �

que esse ‘alguém’ é que tem todo o projeto na cabeça, bastando seguir seus passos. Provavelmente há um ‘alguém’ responsável e líder num projeto, no entanto esse responsável certamente não tem o projeto todo na cabeça;

não existe um “ser sagrado” que sabe tudo sobre o »

trabalho a ser realizado, e o responsável depende inteiramente da sua equipe;

como o projeto é uma atividade inerentemente coletiva, é �

fundamental que haja o espírito do trabalho cooperativo;

não há como fazer projetos com algum nível de »

complexidade sem a participação criativa e positiva de várias pessoas. – vi recentemente um grupo de


106


projetistas que inventou uma espécie de jogo em rede de computadores, uma espécie de gincana, em que eles brincavam de colocar partes do projeto num diretório comum, e a vitória era cumprir tal demanda num prazo cada vez mais curto – era uma brincadeira que fazia do projeto uma diversão em forma de game!

O início de um projeto deve acontecer com uma reunião. Nessa reunião o escopo do projeto deve ser exposto com a maior clareza possível, os detalhes devem ser discutidos até a exaustão, o plano de produção deve ser detalhado, as tarefas divididas e as responsabilidades atribuídas. É neste momento que o fluxograma geral (lembra do algoritmo do projeto?) deve ser apresentado, discutido e suas cópias distribuídas. A comunicação dos procedimentos, já discutidos aqui, deve ser feita a partir dessa reunião de contato inicial.

Geralmente as reuniões são muito mal vistas. Por quê? Algumas pessoas pensam que reuniões são chatas, que não dizem nada, que o chefe senta na extremidade da mesa apenas para mandar. Essa é uma visão de reuniões normalmente veiculadas em filmes e novelas. Podemos imitá-las e então ter péssimas reuniões ou então optarmos em seguir um caminho muito mais objetivo e perceber que reuniões são ótimos momentos para fazer o trabalho, de fato, andar rumo ao sucesso. As reuniões serão interessantes se:

tiverem uma pauta bem definida; �

a pauta não for extensa; �

os assuntos forem claros e de conhecimento dos �

presentes;

o horário de começo e fim forem bem definidos; �

forem suficientemente breves; (as CPIs do governo são �

longas e repetitivas, mas não são reuniões, percebe?)

houver um coordenador, capaz de gerenciar as falas entre �

os diversos presentes;

houver um líder, capaz de decidir quando for necessária �

uma decisão.


107


Há empresas que fazem tantas reuniões que as algumas pessoas chegam a pensar que trabalhar é participar de reuniões e, outras pessoas pensam que a pior coisa do mundo é uma reunião. Nem uma nem outra está correta. Provavelmente, nestas empresas as reuniões estão sendo mal conduzidas.

Depois da fase de reuniões iniciais o projeto tem, então, seu começo. Os grupos de trabalho estão com suas atividades definidas, prazos estabelecidos e resultados por alcançar. Resta cumprir as etapas, já estabelecidas no Gráfico de Gantt do projeto. Se o planejamento foi bem feito, há uma definição bem clara de objetivos e atividades e, possivelmente, com sub-etapas de prazos curtos.

A Microsoft, por exemplo, trabalha com uma orientação designada como “zero-defeito” com prazos curtos de entregas intermediárias como objetivo de maior desenvolvimento (MSF, 1998). Assim que começam os trabalhos de desenvolvimento, a mentalidade de “uma entrega a cada dia” é estabelecida entre todos os membros da equipe. Com isso, há a sensação 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 não é simplesmente colaborar no projeto para que ele chegue ao resultado final. Ele considera que cada projetista, ao começar seu trabalho, deve estar pensando em “entregar”. Leia o seguinte parágrafo e pense nisso: “Todos [os projetistas]… têm o mesmo trabalho. Eles têm exatamente a mesma descrição de trabalho. E esta é entregar (embarcar) produtos. Seu trabalho não é escrever código. Seu trabalho não é testar. Seu trabalho não é escrever especificações. Seu trabalho é entregar produtos. Isto é o que um grupo de desenvolvimento faz. Seu papel como um desenvolvedor ou como um testador é secundário. Não estamos dizendo que não são importantes – mas são secundários para seu trabalho real, o qual é entregar um produto. Quando você acorda cedo de manhã e vem para seu trabalho, você diz, ‘Qual é o foco—estamos tentando entregar ou estamos tentando escrever código? ’ A resposta é: nós estamos tentando entregar. Você não está tentando escrever código.” (MSF, 1998)


108


Este parágrafo elucida sobre a atitude esperada de um projetista ao participar de um grupo de trabalho. É com este foco que o trabalho deve ser iniciado.

Seção 2 – Liderança versus gestão

Conforme você estudou anteriormente na unidade 5, foram ressaltadas diferenças entre as atitudes da liderança e da gestão, sendo dados, por brincadeira, os exemplos do gestor-rinoceronte, gestor-cobra e gestor-raposa. Agora é hora de falar um pouco mais sério sobre o assunto.

Estamos muito mais acostumados a trabalhar com gestores, ou gerentes, do que com líderes. A função da gerência tem sido muitas vezes confundida com uma espécie de atuação por cobrança e controle que coloca os gerentes numa condição de animosidade com seu grupo de gerenciados. Ou seja, aqueles que ficam submetidos ao gerente se sentem diminuídos e perdem, geralmente, a motivação 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 têm ojeriza por liderança, pois vêem na figura do líder uma espécie de ser “sagrado” que detêm a verdade. É possível que essa imagem falsa tenha origem de duas fontes: a primeira é a mitologia criada sobre líderes carismáticos, que levam as pessoas a fazer coisas que normalmente não fariam; a segunda é que esse tipo de gestor não consegue cumprir funções muito mais simples, essas sim dos líderes, como tomar decisões, se arriscar mais e apoiar verdadeiramente cada um dos membros de sua equipe. A ojeriza acaba se dando por não conseguirem cumprir nenhum dos dois papéis. Não assumem a figura carismática por não concordarem ou não se adaptarem a ela. Também acabam não assumindo a função de liderança objetiva e criativa por não terem a habilidade de relacionamento humano necessária. Com esse distanciamento, acabam manifestando uma ojeriza generalizante, denegrindo todos os tipos de liderança.


109


No entendimento de Page-Jones (1990) são as seguintes as qualidades de um gerente de projetos:

integridade pessoal, �

sensibilidade, �

capacidade de estabelecer objetivos, �

capacidade de cumprir objetivos, �

tenacidade, �

capacidade de inspirar, �

disposição de servir, �

coragem de delegar, �

competência técnica, �

capacidade para comunicar a realidade, �

capacidade de pensar e ser inovador, �

coragem de tomar decisões. �

Estas características cabem perfeitamente para os líderes, especialmente as qualidades de “inspirar, ser inovador e ter coragem de tomar decisões”. Nem sempre os gerentes são inspiradores, inovadores e decisores e, mesmo assim, são ótimos gerentes, pois são capazes de coordenar os prazos e distribuir tarefas adequadamente 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 desejáveis em um gerente estão divididos em três grandes áreas: conhecimentos, habilidades e atitudes. O detalhamento dessa divisão é o seguinte:


110


a) Conhecimentos desejáveis

Em relação ao � conhecimento organizacional o gestor necessita:

ter conhecimento do sistema administrativo e a) financeiro da organização onde trabalha;

conhecer o funcionamento do sistema de RH b) (recursos humanos) e como se dão as relações jurídicas com relação aos funcionários e terceirizados da empresa;

práticas, políticas e valores, que é a percepção c) clara de perceber como funciona a organização em suas práticas no dia-a-dia, a política interna das relações e por quais valores se orientam aqueles que trabalham nela;

ter consciência do custo e das implicações das d) decisões técnicas; o que implica reconhecer as relações entre as ações e o que isso significa no tocante aos gastos no projeto e para a empresa;

ter conhecimento das atividades econômicas e) da organização, dos seus produtos, missões e mercados ou clientes da organização, que significa um conhecimento profundo das atividades econômicas da organização.

Em relação ao � conhecimento técnico, o gestor necessita:

conhecer áreas correlatas à especialização de a) que trata o projeto, com uma visão geral das competências tecnológicas;

ter competência técnica em pelo menos uma área b) de especialização;

ter domínio de métodos de pesquisa, que c) permitam relacionar os diversos membros da equipe em um desenvolvimento equilibrado e voltado a resultados.


111


b) Habilidades desejáveis

Em relação às � habilidades de comando o gestor necessita:

ter a capacidade (e isso deve ser perceptível) a) de planejamento, organização e controle das atividades do projeto;

desenvolver sua capacidade de liderança (pois b) consideramos que a capacidade de liderar é inata a todas as pessoas);

capacidade de auto-análise, ou seja, c) constantemente fazer a auto-crítica das suas atitudes, dos seus conhecimentos e das necessidades de aprimoramento técnico;

capacidade de alocação de recursos que advém d) do conhecimento dos recursos disponíveis e daqueles que serão necessários buscar no desenvolvimento do projeto;

capacidade de gerar confiança no superior e e) isso se dá pela integridade e pela segurança ao trabalhar orientado a resultados;

perceber e escolher o estilo de liderança f) adequado a equipe de trabalho, o tipo de projeto e do cliente contratante, seja externo ou um superior da empresa;

habilidade de tomada de decisões, condição g) essencial numa função de comando (o gerente que não toma decisões é considerado fraco por sua equipe, o que desmotiva o grupo).

Outras habilidades: �

trabalhar em equipe, habilidade esta que já a) comentamos muitas vezes ao longo deste livro e que está relacionada à capacidade de cooperar e gerenciar conflitos;


112


criatividade, especialmente na solução de b) problemas inesperados e distantes daqueles que foram avaliados como riscos inerentes ao projeto, sendo que a criatividade também está relacionada à habilidade de manter diálogos constantes com os membros da equipe e com a inspiração motivacional, gerando idéias diferentes das convencionais;

capacidade de redigir com clareza, precisão e c) concisão, habilidades relacionadas à capacidade de se comunicar, necessária para o andamento do projeto de forma coordenada e racional;

relacionamento pessoal, habilidade relacionada d) ao dia-a-dia do trabalho em equipe, às atitudes de educação na convivência (infelizmente não é nada difícil encontrarmos “gerentes” que se dirigem aos membros de sua equipe aos berros).

Sobre o relacionamento pessoal temos um caso interessante: disse certa vez numa reunião de gerentes que eu não aceitaria trabalhar numa empresa onde os “chefes” se acham no direito de humilhar seus funcionários, e os resultados foram dois: primeiro, fui estigmatizado por tais “gerentes” e “saído” 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 não entendo se os funcionários mentem nas entrevistas ou se tais listas são arranjadas.

c) Atitudes

Posicionamento em relação a aspectos internos e �

externos:

interesse por questões administrativas, que a) implicam conhecer e se posicionar em relação aos diversos aspectos do trabalho, na empresa e no projeto, mesmo que não sejam suas funções as atividades executivas da administração empresarial;


113


disciplina de trabalho, que envolve ao mesmo b) tempo a dedicação produtiva diária ao próprio trabalho e, na sua condição de gestor, do exemplo aos membros da equipe de que a disciplina é a geradora da produção e do resultado;

entrosamento com pessoal externo à c) organização, pois isso é essencial para realizar as interfaces de negociação de requisitos, solicitação de recursos extraordinários, verificação de pendências, solução de conflitos diversos etc.;

ambição profissional, que é necessária para o d) crescimento tanto do indivíduo quanto do seu grupo de projeto; ambiente sem ambição de crescimento e sucesso é desmotivador.

Estratégias de ação: �

hábito de começar o ataque ao problema pela a) revisão da literatura, pela revisão dos projetos da mesma área que o antecederam, seja na empresa ou outros locais e, principalmente, a capacidade de exercitar sempre uma visão geral do problema e do ambiente de negócios onde o projeto está envolvido;

hábito de leitura sistemática de textos técnicos, b) pois com isso há atualização constante em relação às inovações tecnológicas e geração de novas idéias, ponto fundamental para lançar novos projetos, como os discutidos na unidade 1 deste livro.

Essas são considerações gerais sobre gerência, mas o que defendemos como principal para o sucesso de um projeto é a atitude da liderança. Nos tópicos citados anteriormente, a maioria das atribuições que você estudou serve tanto para gerentes quanto para líderes enquanto outras são características específicas da liderança. É preciso que você entenda que as características de “líder” são inerentes a todos nós mas, em geral, não são estimuladas nos indivíduos em uma sociedade que procura, de certa maneira, uniformizar procedimentos e atitudes. Tal uniformização (ou mediocrização) pode ser considerada uma doença que afeta o nosso desenvolvimento como indivíduos e, por conseqüência, como


114


sociedade. Não é o caso de dizer que todos devem ser líderes em todas as atividades, mas sim, que saibamos nos posicionar sempre em que tal comportamento de liderança se faça necessário. A liderança implica também o discernimento da compreensão do momento em que precisamos ser parte de um grupo onde já há um líder no qual devemos depositar confiança no trabalho.

Stephen Covey (2005) criou uma tabela que relaciona diferenças entre liderança e gerência e, no quadro abaixo, apresento uma adaptação de tal tabela de acordo com os conceitos desenvolvidos para este livro:

LIDERANÇA GERÊNCIA

Interessado nas pessoas Interessado nas coisas

Trabalha na espontaneidade Trabalha com a estrutura

Liberação e fortalecimento das idéias Controle das atividades e das idéias

Eficácia Eficiência

Prefere planejar e programar Prefere trabalhar sob um programa

Considera gasto como investimento Considera gasto como despesa

Trabalha baseado em princípios Trabalha baseado em técnicas

Procura transformação Procura transação

Poder centrado em princípios Poder centrado em utilidade

Procura resolver por discernimento Procura resolver por medição

Fazer a coisa certa Fazer certo as coisas

Resolve baseado numa direção Resolve baseado em rapidez

Pensa numa linha superior Pensa em resultados

Tem propósitos Tem métodos

Decide baseado em princípios Decide baseado em práticas

Busca algo acima das coisas Busca algo dentro dos sistemas

Para o líder a pergunta é: “a escada está junto da parede certa?”

Para o gestor o que importa é: subir rapidamente a escada

Quadro 3.1 – Diferenças entre Liderança e Gerência Fonte: Adaptado de Covey (2005).


115


Especificamente sobre lideranças, Christenson (2004) avança ainda mais sobre seus conceitos dividindo-as em quatro diferentes tipos, descritas abaixo:

a que considera os indivíduos1. , ou seja, é capaz de estimular as pessoas de sua equipe e seus seguidores a terem uma visão nova de seu próprio trabalho;

a que estimula intelectualmente2. , gerando um alinhamento positivo das idéias das pessoas em relação à organização e ao projeto;

a que influencia os ideais3. , ou seja, estimula seus colegas de trabalho a alcançarem altos níveis de habilidade;

a que motiva inspirações4. , levando seu grupo de colegas a olharem além do interesse próprio e em direção ao benefício de todo o time.

Bem, não é necessário fazer um juízo de valor sobre qual o melhor, líder ou gestor, pois os papéis dependerão da atividade, do tamanho do problema ou do tipo do projeto. De certa forma, os dois papéis devem estar combinados (e não agir como o gestor que execrava “líderes” em sua organização).

Começado o projeto, tendo um planejamento claro das atividades (veja também as unidades anteriores com os Diagramas de Gantt e as ferramentas PERT/CPM), consideradas as funções de liderança e de gestão, passa-se agora aos detalhes do dia-a-dia do projeto. Um dos pontos nevrálgicos de qualquer projeto é a tomada de decisão, assunto da próxima seção.


116


Seção 3 – Tomada de decisões

Hoje uma grande parte dos textos sobre administração empresarial dirige seu olhar para o problema da tomada de decisão.

Decidir significa escolher uma opção entre várias e, com isso, há sempre o risco da escolha não recair sobre a melhor opção.

Um campeão de xadrez decide o melhor movimento a cada vez e seu exercício de escolha é renovado a cada nova jogada. Aquele que cometer mais decisões erradas, perderá o jogo. Assim também o goleiro na hora do pênalti: a decisão do seu movimento poderá implicar ou não 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 decisão que levará ao gol, ao ponto, enfim, ao sucesso.

Que “milagre” poderia ser esse, capaz de levar a uma decisão certa no momento certo?

Alguns traços são comuns entre esses “tomadores de decisão”:

experiência anterior; �

treino em decidir e executar (as jogadas, os chutes); �

o exercício da visão ampla (do jogo); �

coragem de, após um erro, calibrar os movimentos para �

tentar de novo até acertar.

Quem ama os esportes já viu algum desses momentos mágicos quando o atleta resolve arriscar um difícil movimento, muitas vezes num momento crítico onde a chance da derrota era enorme e, cheio de confiança, decidir uma partida.


117


Um jogo coletivo é como um projeto: há um objetivo a ser atingido, o prazo está estabelecido e só é possível vencer se a equipe estiver unida e entusiasmada.

Para Page-Jones (1990) a tomada de decisão durante um projeto envolve quatro passos:

identificar possíveis modos de ação e chegar a um �

entendimento comum do que cada opção significa;

identificar as ramificações de cada opção, incluindo �

vantagens e desvantagens;

discutir e avaliar cada uma dessas ramificações; �

escolher o modo de ação mais vantajoso e partir para ele. �

Como vemos, em um projeto, há a necessidade da constante avaliação das opções possíveis e disponíveis e isso combinado à experiência prévia do decisor, definirá as próximas ações.

Seção 4 – Motivação e comunicação

Em um projeto, outro fator importante para o bom andamento do trabalho, é a clara comunicação para toda a equipe e interessados, sobre os objetivos, os resultados a serem alcançados e sobre como se darão todas as pequenas divisões e etapas até chegar aos resultados esperados. Nesse sentido, um planejamento utilizando o Gráfico de Gantt parece ser fundamental, uma vez que ele utiliza o gráfico de barras ao longo de tempo e é conhecido de todos. A comunicação, seja inicial ou a cada etapa do projeto, deve se dar sobre tal gráfico e deve ser acompanhada da marcação sobre o “já realizado” e sobre o que falta realizar.


118


A comunicação clara das atividades deve ser feita a cada momento importante, tal como inícios e encerramentos de etapas, mas o dia-a-dia de cada etapa exige entusiasmo e motivação por continuar. Infelizmente, muitos entre nós sofrem de um mal moderno conhecido como depressão 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 também a constante necessidade de superação de desafios. Assim, primar por uma comunicação que motive e que entusiasme o indivíduo é mister para se alcançar resultados positivos.

Em uma pesquisa sobre a motivação para o trabalho, Page-Jones (1990) cita a obra de Maslow para definir as necessidades básicas dos seres humanos e, como tais necessidades, precisam ser satisfeitas para que se sintam motivados. O quadro abaixo representa tais necessidades.

Necessidades Níveis Exemplos

BÁSICAS· Fisiológicas· segurança· sociais

· Fome, sono, sede· no emprego, tranqüilidade· pertencer a grupo, família, amigos

DE CRESCIMENTO· Estima· auto-realização

· Sensação do trabalho bem feito· desafio vencido, desenvolvimento

Quadro 3.2 – Necessidades básicas e motivação Fonte: Page-Jones (1990).


119


Pelo que você pode observar no quadro, enquanto as necessidades básicas parecem satisfeitas em boa parte da sociedade atual (salvo nas regiões mais pobres e de maior desigualdade no país e no mundo), o mesmo já não se pode dizer das necessidades de crescimento. Mesmo nos países mais ricos e de maior distribuição de renda, os níveis de auto-estima e auto-realização parecem não estar ainda bem resolvidos. Neste ponto voltamos às seções anteriores para perceber que são motivacionais as atitudes dos líderes, que se posicionam frente a desafios e que sabem valorizar o trabalho e o esforço de todos. Gestores sem tais habilidades, sem dúvida, farão projetos fracassarem.

Seção 5 – Reuniões

Reuniões... isso não lhe parece um assunto bastante pueril para um livro sobre gestão de projetos?

De fato seria, caso as reuniões não tivessem assumido um papel de tortura e de desgaste para muito de nós. Há empresas, especialmente as públicas, ou alguns partidos e agremiações políticas, que parecem se movimentar apenas por meio de reuniões. Por causa disso, esses encontros de trabalho passaram a ser encarados por muitas pessoas como inúteis, mas, certamente, não o são.

Atribuo grande importância às reuniões de projeto, pois são momentos especiais de comunicação e decisão. São nesses momentos que os planos, as discussões e os rumos do trabalho são colocados e precisam ser enfrentados como ambientes coletivos para o desenvolvimento do próprio projeto. Para que uma reunião venha a ser bem-sucedida, Page-Jones (1990) coloca as seguintes sugestões de ação:


120


1. Antes da reunião:

o grupo de trabalho ou o gestor/líder, deve definir um �

lugar conveniente para a reunião;

os participantes devem ser selecionados conforme o �

assunto em pauta e não simplesmente reunir todos do grupo;

antes de marcar uma agenda, é importante verificar se �

todos podem, de fato, participar;

se há consenso sobre uma data e horário, fazer então o �

aviso com antecedência;

a pauta de reunião deve ser bem definida e levada aos �

participantes com antecedência;

o número de itens em pauta deve ser restrito, evitando �

dispersão e superficialidade.

2. Durante a reunião:

deve ser designado um moderador capaz de organizar/ �

gerenciar as falas e questões propostas pelos indivíduos do grupo;

também deve ser designado um secretário que anote os �

pontos principais discutidos, bem como, as resoluções adotadas, criando então uma ata;

o grupo deve prender-se à pauta, evitando entrar em �

assuntos diversos;

definir regras de procedimento conforme o objetivo dos �

itens de pauta (planejamento, comunicação, resolução de problemas, decisão).


121


3. Depois da reunião:

todos os itens de ação devem ser anotados e devem ser �

atribuídas responsabilidades por item de ação;

distribuir a ata da reunião. �

Tenho certeza que você, ao ler essas linhas, estará pensando em reuniões em que já tomou parte e que não se seguiram tais recomendações. Aquelas que tiveram alguém capaz de conduzir as conversas talvez, tenham tido bons resultados, porém, a maioria, deve ter sido enfadonha e sem resultados, sem contar com a sensação do tempo perdido.

Para o projeto de desenvolvimento de uma inovação tecnológica, um software, um novo produto, haverá, com certeza, várias reuniões e caberá a cada um de nós interferir para garantir o seu bom andamento. Se a reunião não tiver pauta, solicite uma. Se a hora de acabar não estiver definida, pergunte qual é.

Seção 6 – Gerenciando qualidade, tempo e recursos

Gerenciar a qualidade é buscar a ausência de erros. Muitas vezes, não prestamos atenção 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 atenção o seguinte texto:

As pessoas foram condicionadas a acreditar que o erro é inevitável. Não apenas aceitamos o erro, nós o prevemos. Quando projetamos circuitos, programamos um computador, fazemos um planejamento, soldamos conexões, datilografamos uma carta, fazemos um orçamento, ou montamos componentes, não nos preocupamos se cometemos alguns erros; e a gerência prevê o acontecimento desses erros. Achamos que os seres humanos possuem um fator de erro integrado a eles.


122


Entretanto, não mantemos o mesmo padrão, quando a coisa passa para o campo da vida pessoal. Se mantivéssemos, aceitaríamos com naturalidade receber troco errado (a menos); aceitaríamos que as enfermeiras deixassem cair no chão um percentual de recém-nascidos; acharíamos natural entrar na casa errada de vez em quando. Como indivíduos, não toleramos esses erros. Portanto, temos dois pesos e duas medidas: um para nós e um para a empresa.

A razão para isso é que a família cria para nós padrões de desempenho bem mais altos do que as empresas...

Muitas empresas gastam 10, 15 ou até mesmo 20% do faturamento de suas vendas com sucata, retrabalho, garantias, consertos, testes e inspeções. Os erros que produzem esse desperdício são causados diretamente pelo pessoal da empresa, tanto pelos funcionários quanto pela administração. Para eliminar esse desperdício, para melhorar o funcionamento e aumentar a eficácia, precisamos nos concentrar na prevenção dos defeitos e dos erros que nos assolam. O erro que é prevenido não precisa de consertos, exames ou explicações. O primeiro passo é adotar uma atitude de prevenção 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 distância dele, de um ponto de vista conceitual. Muitas empresas buscam entender “defeitos” na produção a partir de índices de erro encontrados numa linha de fabricação, na quantidade de “bugs” do sistema, ou diversos outros indicadores preparados para apontar uma não-conformidade. Ora, defeito não é necessariamente um índice, mas sim a atitude de aceitar a sua existência ou não 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.


123


Conforme o artigo “Managing project quality”, o gerenciamento da qualidade em projetos passa por dois momentos críticos: a abertura do trabalho e seu encerramento. Os pontos fundamentais a serem tratados nesses dois momentos são:

1. Fase inicial do projeto

Identificação dos objetivos do projeto; �

alinhamento estratégico com a empresa e com o objetivo �

do cliente;

alinhamento operacional com as capacidades de �

produção da estrutura disponível;

seleção dos recursos necessários; �

contrato detalhado do projeto descrevendo: �

o porquê do projeto (onde se apresentam as a) justificativas do trabalho e as causas que o inspiraram);

o quê? (onde o escopo detalhado do trabalho b) deve ser colocado, definindo claramente os resultados esperados);

quando? (em que é apresentado o cronograma c) geral do trabalho, definindo datas de início e fim, bem como de interação entre equipe de projetos e cliente/contratante)

quanto custa? (especificando o valor global do d) projeto e medições financeiras parciais, quando necessário)

Quais os riscos? (descrevendo condicionantes e) e possíveis problemas, capazes de alterar o andamento do projeto, seja em prazos, seja em custos)

Kloppeborg & Petrick, 2004.


124


como fazer? (apresentando os fatores críticos f) do sucesso, o plano de comunicação, os conhecimentos necessários e os compromissos, bem como outras ações que afetarão o processo de produção do projeto).

2. Fase de encerramento

Definição e comunicação dos benefícios reais entregues �

para o cliente;

expressão de reconhecimento aos participantes; �

entregar prêmios quando há méritos especiais (evitando �

aquele tipo de mediocrização que evita prêmios para não “magoar” os mais fracos).

De posse de um Diagrama de Gantt, com acompanhamento constante das etapas realizadas, sabemos dos custos envolvidos e do tempo gasto a cada momento. Fazendo a revisão da etapa, é possível replanejar o projeto e avaliar as condições de tempo restante e recursos disponíveis e ainda necessários.

Seção 7 – Gestão de conflitos

Como não podia deixar de ser, o trabalho em equipe é, quase sempre, um ambiente de conflitos. Isso acontece devido ao dinamismo dos pensamentos e sentimentos humanos em constante movimento e readequação. Segundo Valeriano (1998), existem três tipos de conflitos:

o de ordem � intrapessoal, que ocorre em cada indivíduo, consigo mesmo;

o � interpessoal, que ocorre entre diferentes indivíduos;

o � intergrupos, que se dá entre diferentes grupos.


125


Os conflitos estão presentes em todos os ambientes sociais, sejam de trabalho, familiar ou de comunidades em geral e, obviamente, estão presentes também nas equipes de projeto as quais, muitas vezes, estão reunidas por um pequeno período de tempo e de forma muito intensa o que, via de regra, potencializa as relações.

Esses três tipos de conflito, intrapessoal, interpessoal e intergrupos, estão presentes no decorrer dos projetos segundo as seguintes causas potenciais (KEELING, 2002):

na definição de cronogramas, quando diferentes �

interesses tendem a se contrapor na preparação das agendas de trabalho;

na definição das prioridades; �

na composição dos recursos humanos a trabalhar no �

projeto, onde afinidades pessoais tendem a se manifestar;

opiniões técnicas e de desempenho, durante o desenrolar �

dos trabalhos;

procedimentos administrativos, geralmente um ponto �

delicado de discussões entre a equipe do projeto e suas liberdades de ação contra as amarras muitas vezes necessárias da burocracia administrativa;

custos, na batalha infindável 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 diferenças entre os indivíduos e as organizações devido a seus diferentes objetivos. As pessoas têm diversas necessidades e intenções que, muitas vezes, não combinam ou se ajustam às das organizações, mesmo que tais organizações, paradoxalmente, tenham sido construídas por indivíduos. O quadro apresenta uma tabela de exemplos, adaptada de Valeriano (1998).


126


Diferenças de objetivos como fonte de conflitos

Indivíduo / profissional Organização / gerência

Busca a inovação tecnológica Busca o lucro

Quer autonomia de ação Quer integrar os profissionais na organização

Quer livrar-se de regras e procedimentos Estabelece as regras e procedimentos

Quer autoridade baseada em mérito Autoridade baseada em hierarquia

Quer ser recompensado com base em seu desempenho Recompensa conforme o interesse da organização

Quer ampla comunicação entre pares Bloqueia a comunicação interna

Busca otimização do próprio trabalho Busca cumprimento de cronogramas e custos

Quadro 3.3 – Fontes de conflitos Fonte: Adaptado de Valeriano (1998).

Você percebe como são 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 organização e os específicos do projeto que, por sua vez, devem refletir sobre os indivíduos que o compõem. Há organizações que trabalham orientadas por projetos, porém com a mentalidade tradicional. Não será possível vencer a contradição se não houver um repensar de princípios. Organizações envelhecidas, nascidas ainda com a mentalidade dos princípios da revolução industrial, por exemplo, buscam renovação adotando práticas de reengenharia e gestão por projetos e, normalmente, fracassam logo em seguida sem saber o porquê. A orientação por projetos é uma orientação às pessoas, pois os projetos são movidos pelas pessoas que compõem as equipes de projetos. Assim, será necessária uma mentalidade direcionada ao relacionamento das pessoas, e não a um conjunto de regras rígidas, protocoladas por inúmeros papéis e procedimentos técnicos, apropriados para controlar máquinas, não indivíduos. Sem tal mentalidade, os projetos fracassam.


127


No entanto, mesmo que teoricamente saibamos onde estão as supostas raízes dos problemas, não estaremos, necessariamente livres de conflitos em um projeto, então será imprescindível administrá-los. Para Valeriano (1998), há as seguintes possibilidades de se administrar conflitos num projeto:

por � confronto ou solução de problemas, quando as partes envolvidas encaram o problema e buscam juntos alternativas de solução;

por � comprometimento, que é a busca de soluções alternativas, por parte do gerente do projeto, dando algum grau de satisfação às partes envolvidas;

por � acomodação, onde são enfatizadas as áreas onde há acordo, e esquecidas ou desprezadas as áreas conflitantes; haverá perda para o projeto se as áreas de atrito eram, de alguma forma, importantes para seu prosseguimento;

por � prevalência, que é quando uma das partes prevalece sobre a outra, numa relação ganha-perde;

por � retirada, quando o conflito é deixado de lado, sem solução, 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 reflexão.

Considerando tais possibilidades, será função do gestor escolher a maneira de lidar com o conflito. Com certeza a melhor forma de administrar os conflitos se dá quando são percebidos o mais cedo possível. Como muitas doenças, se o conflito for detectado no início é mais fácil de curar e, se muito tarde, pode ser impossível. Por isso a atenção do gestor é primordial.


128


Seção 8 – Simulação, testes e validação

Projetos podem ter resultados melhores se forem testados em etapas, como resultados parciais e não aguardar até o final para ver o que deu certo e o que deu errado. Nesse sentido é importante para cada etapa e sub-divisão do projeto, buscar conseguir um resultado palpável. No caso da construção civil, por exemplo, a finalização da etapa das fundações tem como resultado as próprias fundações, que podem ser testadas quanto às características necessárias de resistência e dimensões.

Qualquer problema aí detectado pode ser resolvido imediatamente, não sendo necessário aguardar até o final da obra para perceber que os alicerces não suportaram o peso da construção – seria um desastre!

Em projetos de software há a possibilidade de dividir o sistema em pequenos módulos, de tal forma que, cada um tenha características específicas, definidas inicialmente e que, atingi-las é o objetivo a ser alcançado no final da etapa. Quanto maior a divisão de etapas e, desta forma, de objetivos intermediários, mais fácil será detectar possíveis problemas e corrigi-los a tempo.

Um exemplo de divisão em etapas desse tipo, está definida nos “pacotes diários” e nos “protótipos de prova” do Microsoft Solutions Framework (MSF, 1998). O objetivo é chegar no final de cada dia com um protótipo testável. Esse protótipo é compilado e deve funcionar. Só se passa para a etapa seguinte se o pacote diário anterior alcançou o sucesso.

Outra alternativa é o uso de simuladores em projetos mais complexos. Nesses casos, uma boa forma de testes prévios é o uso de simulações computacionais que permitem uma visão do produto, possibilitando fazer testes variados em um ambiente computacional.

Um ótimo exemplo disso são os softwares de apoio a projeto (CAD), que em mecânica e arquitetura permitem visualizar e testar peças, máquinas e ambientes. A detecção de falhas durante a simulação permite enormes economias de tempo e dinheiro.


129


A validação do projeto é feita por etapas e por simulações, sendo que no final de cada etapa, e mesmo durante cada uma delas, um processo de revisão contínua é a melhor solução de qualidade para a continuidade de um projeto de sucesso. Segundo Page-Jones (1990) há várias revisões a serem feitas no decorrer do projeto, visando a testes contínuos e validação a cada etapa. Especificamente sobre projetos, as revisões e testes são:

revisão do � escopo do projeto, que analisa constantemente se o projeto está adequado às intenções e necessidades dos usuários/clientes;

revisão de � análise, que verifica se os problemas anunciados no escopo estão sendo cuidados;

revisão do � projeto, que verifica se preenche as especificações, os padrões de qualidade e se tem condições de ser implementado;

revisão da � programação e do sistema, que verifica se os resultados dos testes do protótipo estão adequados;

revisão da � aceitação, que verifica se após os testes do protótipo já é possível colocar o resultado do projeto em produção;

revisão de � produção, que verifica se o sistema de produção está adequado e se há oportunidades de melhoria no produto;

revisão dos � aspectos técnicos do projeto;

revisão dos � aspectos comerciais;

revisão � pós-projeto, que busca aprender com os resultados finais do projeto.

Simulações, revisões e testes são atividades do dia-a-dia do projeto e, como visto, interferem inclusive no seu final e podem se estender à produção, atividade que já não pertencerá ao escopo do projeto em si, mas à rotina. Quando chegar este momento, teremos o final do projeto, assunto da próxima unidade.


130


Síntese

Nesta unidade você viu como se dão os preparativos iniciais do projeto e quais as atividades são importantes para que a produção tenha início acompanhando o planejamento definido previamente. O início do projeto define também o padrão de qualidade que será buscado em toda a fase de desenvolvimento, especialmente se for implantada uma cultura de “defeito-zero”.

Como fundamento desta unidade está a comparação entre as características do gestor e as do líder. Em unidades anteriores esse tema já havia sido iniciado, mas aqui foi aprofundado e percebeu-se que a liderança é capaz de motivar a equipe, condição essencial para que todos busquem um resultado comum, de forma entusiasmada e ambicionando o sucesso coletivo. Com certeza a figura do líder aqui definida não é a do sujeito carismático, que conduz seguidores fanáticos, mas sim a do que é capaz de criar ambientes de cooperação e de trabalho criativo. Para isso, muitas vezes é necessário administrar conflitos, mostrar caminhos produtivos e tomar decisões que definam rumos para o projeto. Sem dúvida, uma das características fundamentais nessas atividades é a de motivar e inspirar.

Por fim, tomando por base a necessidade de, durante a fase de planejamento, segmentar o projeto em pequenas tarefas e etapas, a fase de desenvolvimento pressupõe um conjunto de revisões e testes, que 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 revisões e análises, e o exemplo de protótipos intermediários foi apresentado como solução para busca de melhorias e conquistas parciais, visando à obtenção do objetivo final do projeto por meio de vários incrementos parciais bem-sucedidos.


131



1) Dos quatro tipos de líderes definidos por Christenson (o que considera os indivíduos, o que estimula intelectualmente, o que influencia os ideais, e o que motiva inspirações), qual é, na sua opinião, o mais importante? Justifique.

2) Como você descreve os quatro passos da decisão? Dê um exemplo prático, a partir da sua experiência.

3) Descreva as principais fontes de conflito entre os indivíduos e as instituições, dando exemplos de sua própria experiência.


132


4) Quais as formas de administrar um conflito, e qual delas melhor se adapta ao seu estilo de gestão? Por que essa forma de atuar e não as outras? Faça um comparativo e publique na “Exposição”.

5) Qual a importância do uso de simuladores no desenvolvimento de projetos?


133


Saiba mais

As reuniões geralmente são esperadas como atividades não muito proveitosas. Isso acontece porque não existe uma boa preparação para elas. Uma reunião bem preparada conduz a decisões importantes e, geralmente, sucesso nas realizações. Veja algumas sugestões e práticas para uma boa reunião, no artigo intitulado “A boa geometria da reunião”, de Carlos Cardoso Aveline.

O uso de simuladores pode ser importante para verificar protótipos de produtos, antes mesmo de eles serem construídos. No caso do desenvolvimento eletrônico, por exemplo, há um interessante conjunto de simuladores, desenvolvidos com Java, disponíveis na internet.

O exemplo é o seguinte: no projeto de uma antena o projetista tem como variar as características do produto, e testar seus resultados. Se for construir um circuito eletrônico, poderá fazer simulações específicas. Você quer fazer um projeto de um novo modelo de “pipa/papagaio/maranhão”? (cada região usa um nome diferente). Veja o simulador computacional da NASA que está no site da NASA. Este é mais um ótimo exemplo de como simuladores apoiam o trabalho de novos projetos.


4UNIDADE 4

Finalizando o projeto


Compreender aspectos relativos à finalização do �projeto, à dissolução das equipes e aos registros documentais do trabalho.

Verificar que o sucesso do projeto ou o fracasso está �intimamente ligado, por um lado, às expectativas do cliente e, por outro, à capacidade de liderança do gestor.

Perceber que todo trabalho de projeto é uma fonte de �aprendizagem, mas para que o aprendizado ocorra é necessário extrair lições 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.

Seções de estudo

Seção 1 Fase de finalização

Seção 2 Planos de contingência em caso de problemas

Seção 3 Atendendo as expectativas do cliente

Seção 4 Sobre o sucesso (ou fracasso) do projeto

Seção 5 Desfazendo a equipe

Seção 6 Documentação

Seção 7 Lições aprendidas

Seção 8 Idéias para um novo projeto


136



Esta é a unidade que encerra o livro e justamente trata do encerramento do trabalho de projeto. As atividades de encerramento do projeto são comentadas considerando aspectos diversos como o processo de documentação dos trabalhos que permitirão, por exemplo, gerar o trabalho de suporte ao produto quando o mesmo entrar em ciclo de produção e venda ou para implementar melhorias contínuas durante sua fase de consolidação.

Trata também da dissolução da equipe e das análises finais, quando então se verificará o grau de sucesso ou fracasso alcançado 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 sensação de missão cumprida estará no ar. Senão, será a frustração do fracasso.

Porém, com o fracasso também se aprende muito e assim precisamos tirar lições para aproveitar no desenvolvimento dos novos projetos, pois esses, com certeza virão. E, por esse motivo, a última seção mostra uma figura representativa de oportunidades de novos projetos no ambiente atual de negócios. Mas para ver tais oportunidades é preciso ter os olhos bem abertos. Bom estudo!


137


Seção 1 – Fase de finalização

A finalização do projeto pode acontecer por dois motivos:

o resultado esperado está sendo atingido; a)

nada deu certo e é melhor finalizar antes que piore. b)

Bem, vamos primeiro considerar a opção “a”, deixando a opção “b” para a próxima seção.

A avaliação de que o resultado está sendo atingido é obtida por medições que devem ser feitas a cada etapa do trabalho. Você acompanhou isso desde a unidade 3, quando estudamos o algoritmo do projeto e tratamos do acompanhamento e das medições em cada atividade. Atingir o grau satisfatório em cada uma dessas medições, 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, não teremos como discutir contra uma data previamente estipulada, não haverá prorrogações. Então, deveremos trabalhar tendo em vista tal data. O controle quanto a isso se dará no preenchimento e na atualização constante do Gráfico de Gantt preenchendo as atividades “realizadas” e comparando com o “previsto”. Da mesma forma avaliando a cada passo o “caminho crítico” do projeto no diagrama PERT/CPM.

Fechado o projeto, será importante avaliar as estatísticas quanto ao tempo gasto, recursos utilizados, os riscos previstos que acontecerem e os que não aconteceram, se os custos previstos foram suficientes, e todos os demais dados que possam ajudar a compreender melhor a gestão dos próximos projetos.

Encerrar o projeto não será apenas concluir os trabalhos e fechar a porta. Este será o momento de avaliar se as expectativas do cliente foram atingidas e, se foram, avaliar o grau de sucesso do trabalho. Será o momento de reunir toda a documentação (obrigatoriamente) gerada para que, com isso, a história do trabalho seja preservada, permitindo a introdução do resultado do projeto num ciclo de vida de produção, bem como, permitir


138


avançar em melhorias e mesmo em novos projetos a partir das lições aprendidas. Será também o momento de desfazer a equipe que, nos casos em que se obteve sucesso, se transforma num momento triste e, nos casos em que se verificou fracasso, uma libertação. Nas próximas seções discutiremos com maior profundidade esses tópicos.

Seção 2 – Planos de contingência em caso de problemas

Na seção anterior, falamos das duas possibilidades de opções, “a” e “b” e já discutimos a primeira opção. 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 contingência.

O plano de contingência, infelizmente, não é uma “carta na manga” que facilmente é lançada sobre a mesa, mudando todo o jogo. Geralmente é um conjunto de ações, tomadas sob pressão, geradoras de conflitos e de crises, pois o plano de contingência é um plano de solução de crises. A percepção do erro geralmente é postergada ao máximo e isso, muitas vezes, ocorre de forma inconsciente dado que não gostamos de errar. Para isso temos as ferramentas de planejamento, acompanhamento e controle do projeto (vimos várias neste livro) que devem fazer parte de cada momento de revisão para que possamos constatar se estamos de acordo, ou não, com o planejado. Tais ferramentas apontam os erros, basta fazer as marcações e ler os indicadores. E, tendo visto os erros, não é certo trabalhar com desculpas, pois esse é outro defeito do ser humano, aceitável apenas em algumas questões sentimentais, mas não de trabalho.

Realizando as revisões e percebendo erros capazes de afetar seriamente o projeto, um plano de contingência deve ser aplicado imediatamente. Conforme o trabalho de Iacovou e Dexter (2004), várias ações devem ser tomadas quando um projeto sai


139


dos trilhos rumo ao fracasso. Tais autores, apontam as seguintes ações corretivas como tentativas de remediar a situação:

desenvolver um plano de recuperação; �

redefinir e gerenciar o propósito do projeto, ou seja, �

avaliar novamente o escopo do projeto e o que, de fato, se quer atingir;

reavaliar o negócio e considerar o cancelamento do �

projeto, quando de fato não há solução de continuidade (deve haver um grande desprendimento para isso!);

replanejar o projeto usando métodos de estimativa �

apropriados e comprovados;

gerenciar as expectativas dos clientes, pois estes perceberão �

rapidamente que “as coisas não estão indo bem”;

formular um plano de comunicação objetivo e �

aberto, tanto para os membros da equipe quanto para fornecedores e clientes – isso trará confiança;

dividir o restante do projeto em pequenas partes ou �

atividades, o que facilitará o controle, a percepção de objetivos menores e mais próximos, bem como a capacidade de acreditar no sucesso;

tratar as dificuldades pessoais da equipe do projeto, �

especialmente quando essa equipe se sentiu culpada pela aproximação do insucesso;

incorporar práticas corretivas no processo de �

desenvolvimento do restante do projeto;

por fim, reavaliar a liderança, verificando se essa �

liderança é capaz de alinhar as diversas forças componentes do projeto rumo ao seu objetivo.

O ponto principal de um plano de contingência, dessa forma, é a tomada de decisão. Tomar decisões é a tarefa dos líderes empenhados no sucesso. Por esse motivo, ao perceber que um projeto não vai bem, é importante verificar se o líder vai bem.


140


Seção 3 – Atendendo as expectativas do cliente

Toda propaganda hoje diz o seguinte: “fazemos de tudo para atender as expectativas do cliente”. Sabemos que isso é apenas propaganda e ninguém atende, exatamente, as expectativas do cliente. Provavelmente porque tais expectativas não são bem conhecidas, nem mesmo pelos próprios clientes.

Quando um de nós diz: “vou comprar um quilo de açúcar”, é muito fácil atender tal expectativa. No entanto, se dizemos: “queria um software para gerenciar a venda em balcão”, a expectativa é muito mais complexa do que está expressa nessa simples frase. Não é fácil apreender do cliente como seria tal software, o tempo de resposta, a interface, quanto está disposto a gastar e muitas outras questões desse tipo. Não há uma regra sobre como avaliar todos esses requisitos. A análise aprofundada de tais requisitos e a comunicação clara do que se entendeu como escopo do problema, tanto para o cliente quanto para os membros da equipe de projeto é condição básica para atender expectativas. E refiro expectativas no plural por entender que há aquelas específicas do cliente e aquelas da equipe e ambas devem ser atendidas para que haja sucesso.

Além disso, não acredito em empresas que vivem alardeando que “fazem tudo pelo cliente”. As empresas fazem antes, algo por si mesmas, depois pelo cliente. E nisto não há um juízo de certo ou errado, mas simplesmente o fato de que, para sobreviver, a empresa precisa olhar para si mesma. Não se trata também de ultrapassar limites de ética ou avançar em atitudes oportunistas, mas sim, de ser realista quanto às finalidades de cada sujeito neste jogo. A expectativa do cliente deve ser tratada como algo objetivo e deve ficar claro para ambas as partes o que é possível realizar e o que não é.

Chegar ao fim do projeto é, então, contemplar a expectativa desse cliente, seja ele um contratante externo, uma demanda da empresa ou um desejo de nós mesmos. Ao confrontar tal contemplação, teremos uma medida do sucesso do nosso trabalho.


141


Seção 4 – Sobre o sucesso (ou fracasso) do projeto

O projeto foi entregue no prazo, gastou menos do que o previsto, o produto alcançou ou até mesmo superou as expectativas, os benefícios mensuráveis pelo seu resultado são enormes...Temos, então, um projeto de sucesso. A equipe será condecorada, haverá prêmios para os responsáveis, a empresa passará a vender mais ou conquistar um nicho que antes não detinha. Inovações serão incorporadas pela indústria e pelo mercado e, dependendo do grau, poderão até mesmo revolucionar um setor ou um hábito.

Vamos nos debruçar, porém, na situação inversa - o fracasso. Todos queremos evitá-lo, contudo, mesmo quando o fracasso for inevitável, precisamos aprender com ele para crescer. Não há vitorioso que não tenha fracassado alguma vez. É preciso então prevenir, mas como poderemos nos prevenir dos fracassos em projetos?

Para Keeling (2002), existe fracasso em projetos quando:

objetivos não são alcançados no prazo; �

custos vão além dos limites aceitáveis; �

resultados são obtidos com nível de qualidade �

comprometido.

Nesses três itens resumem-se os fatores que definem um projeto: prazo, custos, recursos e benefícios. Se algum deles não for contemplado, temos indícios de fracassos. No entanto, podemos fazer uma análise mais sutil. Há casos de projetos que foram concluídos com custo excessivo, muito além do orçamento original e ainda acima do prazo estipulado. São exemplos desse tipo: a Ópera de Sydney, na Austrália e o Eurotúnel, que liga a Inglaterra à França. No entanto, quem ousaria hoje dizer que são fracassos? Do ponto de vista dos custos e dos prazos, o foram. Mas os benefícios aparentemente superam em muito essas falhas. Esses são casos de projetos estratégicos e visionários que são considerados no início como equivocados ou previamente fracassados. Porém, com o passar do tempo se percebe o quanto foram importantes para os desdobramentos futuros. Isso se deve à visão poderosa, à intuição e à persistência de lideranças e não aos cálculos e estudos de burocratas anônimos.


142


Figura 4.1 – Ópera de Sydney, na Austrália, projetada em 1957 pelo dinamarquês Jorn Utzon, que hoje é Patrimônio Nacional da Austrália Fonte: Travels in Paradise (2011).

Atualmente, muitos projetos na área de software têm sido vítimas da síndrome do fracasso. Por esse motivo, boa parte dos estudos recente sobre gestão de projetos tem se voltado a analisar tais casos, sendo que o interesse sobre os trabalhos do PMI (Project Management Institute) é sintomático de uma realidade de mercado. Nas palavras de Page-Jones (1990, p. 83),

embora todo projeto de Processamento de Dados enfrente dificuldades técnicas, elas não são a causa principal de fracassos. Os desastres verdadeiramente impressionantes são devidos a gerenciamento inadequado ou inepto de projetos.

Esse autor destaca exatamente o ponto o qual estamos estudando: os problemas relativos a projetos não estão nas questões técnicas e tampouco em atrasos ou gastos, pois esses, via de regra, são conseqüências de um problema maior: o fracasso da gestão.

Como evitar o fracasso da gestão? Conforme Keeling (2002), pode-se evitar fracassos com:

melhor avaliação de viabilidade; �

análise de riscos criteriosa; �

uso de métodos de planejamento; �

uso de sistemas de controle. �


143


Porém, isso não é suficiente, apesar de necessário. Um grupo de trabalho pode se reunir e fazer várias avaliações, considerar inúmeros riscos e gerar grandes relatórios, preencher planilhas e usar softwares de planejamento de projetos. Mas tudo isso é inócuo se não houver o poder da decisão e o poder da decisão é uma atividade humana. Com isso quero dizer que é preciso ter liderança para que um projeto aspire ao sucesso. Para encerrar esta seção, veja o caso do projeto de construção de uma embarcação de guerra, no século XVII. Esse é um caso clássico de fracasso, motivo de estudos e pesquisas dos interessados em administração.

Figura 4.2 – Representação em escala reduzida, Museu do VASA Fonte: Fairley e Willshire (2003).


144


Estudo de Caso VASA – um projeto fracassado do século XVII

O caso da embarcação “Vasa” foi apresentado no artigo de Kessler et al. (2004), do qual retirei a seguinte história: No começo do século XVII a Suécia estava engajada numa série de batalhas navais contra a Dinamarca, Rússia e Polônia. Em 1625, dez embarcações de guerra suecas foram abatidas quando estavam patrulhando a Baía de Riga. Por esse motivo foram aceleradas as atividades de construção de uma das maiores naves de guerra daquele tempo: Vasa. Por ter descoberto que a Dinamarca planejava construir um barco ainda maior que o Vasa, o rei da Suécia Gustavus Adolphus ordenou alterações na especificação do navio para introduzir um segundo nível de canhões, mais canhões do que originalmente planejado. Com tais modificações, o Vasa excedeu, em muito, o que poderia ser suportado pelo lastro original. Além disso, o mestre construtor Henrik Hybertson faleceu, o que deixou a construção nas mãos de um gerente inexperiente e mais fraco nas decisões e controle dos operários.

No verão de 1628 um teste de estabilidade foi conduzido pelo Almirante Klas Fleming e pelo Capitão Sofring Hansson. Trinta homens correram de um lado ao outro do navio. Depois da terceira corrida o navio inclinava tão violentamente que o teste foi interrompido. No entanto Fleming decidiu não postergar o lançamento do navio, alegando que o mestre construtor já tinha feito navios antes e não havia com o que se preocupar. Menos de um mês depois, em 10 de agosto de 1968, o Vasa foi levado ao mar. Para mostrar o poder dos armamentos da embarcação, o Capitão Hansson velejou com as portas dos canhões abertas, o que não era usual. Depois de navegar pouco mais de mil metros em mar calmo, o Vasa entornou e naufragou, levando consigo cinqüenta marinheiros para o fundo do porto de Estocolmo. Era uma embarcação magnífica, que tinha custado cerca de 5% do tesouro sueco, com 64 canhões pesados e para 300 marinheiros. Feito para simbolizar a força e a beleza da Suécia e para meter medo no coração dos seus inimigos.

Muitas discussões foram realizadas para descobrir os culpados pelo desastre, mas ninguém foi formalmente acusado. O rei foi parcialmente culpado por ter demandas pouco realistas, Hybertson pelo desenho medíocre do projeto, Fleming por não ter dado atenção aos testes realizados e Hansson pela inabilidade no comando da embarcação.


145


Os erros, porém, foram bem mais graves do que esses. Analisando alguns, podemos considerar os seguintes detalhes:

1. Os construtores tentaram imitar o projeto da embarcação dinamarquesa Sancta Sophia, no entanto não tinham conhecimento técnico nem capacidade de desenvolver procedimentos construtivos para tanto.

2. Ênfase na elegância e no poder de fogo e pouca importância à estabilidade e navegabilidade.

3. Excesso de pressa na construção do barco e pouca atenção à sua qualidade, especialmente se considerar a sua dimensão e a quantidade de novas tecnologias que estavam incorporadas o que atribuía ao projeto uma série de riscos e incertezas.

4. Os testes durante a fase de desenvolvimento eram incompletos, houve desprezo pelos resultados de tais testes e excesso de otimismo com o resultado do projeto, desconsiderando os sinais em contrário.

5. Três diferentes pessoas fizeram especificações e definições para o projeto de forma independente, modificando o conjunto (o Rei, Hybertson e o último mestre).

6. O projetista principal, Hybertson, faleceu um ano antes de o navio ser concluído e não deixou documentação ou memória, ou seja, não houve transferência tecnológica.

7. O rei não tinha conhecimentos técnicos para 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 – Representação da embarcação ao afundar, Museu do VASA Fonte: Fairley e Willshire (2003).


146


Seção 5 – Desfazendo a equipe

Equipes de projeto podem criar afinidades de tal monta que, desfazê-las, não é tarefa fácil. Permanecem as afinidades e o entusiasmo, especialmente se houve sucesso. O encerramento das atividades deve passar por uma avaliação de finalização. Uma discussão franca sobre erros e acertos, principalmente no que se refere ao modelo de gestão adotado, bem como o dia-a-dia da equipe, trará benefícios e crescimento a todos.

Reconhecer os méritos: eis uma obrigação.

Há muitos casos de projetistas que empenham horas de esforço e imaginação num projeto e sabemos todos que não são apenas aquelas horas que estão lá escritas na planilha. Essas horas são doações espontâneas daqueles que gostam de desafios e almejam sempre a qualidade e a realização. O reconhecimento disso deve ser manifestado claramente e quando houver oportunidade e condições, deve ser premiado.

Receber um prêmio, mesmo que seja uma simples palavra de agradecimento sincero, é algo honroso. Conheço gestores que não sabem premiar e que consideram que realizar o trabalho é a obrigação de cada um. Desejo a esses a sorte que se deseja aos ratos de esgoto.

Seção 6 – Documentação

Documentação é um ponto falho em quase todos os projetos. Quando Joãozinho e Mariazinha entraram pelo caminho desconhecido na floresta, a trilha de pedras que 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


147


pedaços de miolo de pão, os pássaros comeram sua marcação e eles se perderam. Essa documentação era efêmera. A memória é uma documentação efêmera.

A documentação não é adequada se não for clara, estiver arquivada, acessível e possível de ser entendida por outros. Vimos, desde a primeira unidade, que o planejamento está baseado em análises, avaliações, relatórios, depois planilhas e diagramas. Muitos desses documentos serão usados ao longo do projeto para revisões, bem como serão realizadas reuniões que deverão gerar atas e assim por diante. Além disso, o trabalho técnico será baseado em desenhos, rascunhos, anotações, resultados de testes e muitos outros documentos de variados tipos. É uma obrigação dos responsáveis de cada etapa do projeto e do gestor, organizar, arquivar e preservar a documentação do projeto a qual deve ser parte do resultado final do trabalho.

Nenhum projeto poderá ser considerado encerrado se a documentação não estiver adequadamente preservada e organizada.

Seção 7 – Lições aprendidas

Cada projeto é uma oportunidade de aprendizagem e, geralmente, aprendemos com os erros. A constante revisão do projeto, em cada uma das suas etapas, será um exercício de análise e, para isso, contamos com diversos instrumentos como, relatórios preenchidos lá no começo e que devem ser analisados em comparação com o realizado, passo a passo. Muitas críticas e idéias surgirão nesses momentos e é importante avançar sobre isso. Como dito na seção anterior, a documentação gerada será uma fonte de recursos de aprendizado.

A leitura do caso “Vasa” também é uma oportunidade de aprendizagem, pois podemos estudar erros e acertos em projetos realizados por outros para avaliar caminhos. O estudo de casos proporciona, em contraste com nossa própria experiência, uma fonte rica de aprendizagem. Vamos considerar novamente o


148


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 antídotos para tais problemas numa série de sugestões, cujas principais estão apresentadas no quadro 4.1. Aparentemente um projeto de embarcação nada tem a ver com o desenvolvimento de software, mas não é bem isso que nos sugere esse conjunto de “problemas e seus antídotos”.

PROBLEMA ANTÍDOTOS

Pressão excessiva de prazos· Estimativas objetivas de prazo · Mais e melhores recursos· Priorizações

Mudanças no escopo e nas necessidades· Desenvolvimento interativo· Modificar gestão de controle e planejamento

Falta de especificações técnicas

· Desenvolvimento de especificações prévias· Atualização das especificações com base em eventos· Indicação de um arquiteto de software

Falta de documentação de planejamento· Desenvolvimento de planejamento prévio· Atualizações periódicas e baseadas em eventos· Indicação de um gestor de projetos

Inovações excessivas ou secundárias· Maior controle sobre a linha de trabalho· Análise de impactos· Gestão contínua dos riscos

Falta de métodos científicos

· Uso de protótipos· Desenvolvimento incremental· Uso de métricas de medição da performance técnica

Ignorando o óbvio · Assimilar as lições aprendidas anteriormente

Comportamento antiético· Cultura de trabalho baseada em ética nos relacionamentos· Uso e aderência a códigos de ética formais

Quadro 4.1 – Problemas em projetos de software e seus antídotos Fonte: Adaptado de Fairley e Willshire (2003).


149


Vendo o quadro 4.1 percebemos que as lições tiradas do episódio são muitas e algumas das mais importantes dizem respeito ao uso de métricas de performance, ao desenvolvimento incremental, à divisão do projeto em pequenas etapas, ao controle constante do desenvolvimento e a uma cultura baseada em ética e bom relacionamento. Podemos ainda listar mais algumas, tais como:

Não se deve imitar projetos sem o suficiente �

conhecimento técnico;

Buscar concisão e usabilidade; �

Não se submeter à pressa e dar atenção especial à �

qualidade;

Realização constante e contínua de testes, durante todas �

as etapas;

Reduzir os cargos de responsabilidade, para evitar o �

“empurra-empurra” da decisão;

Gerar documentação sempre e não apenas no final; �

Aqueles que não têm conhecimento técnico não devem �

interferir em assuntos que não são de sua competência.

Os projetos foram se modificando no decorrer do tempo e as lições aprendidas foram sendo incorporadas pouco a pouco. No início houve desperdício imenso de recursos financeiros e mesmo de vidas humanas. Um esforço enorme de melhoria se deu na época da revolução industrial e, logo depois, chegando ao começo do século XX com teorias e ferramentas específicas. Hoje temos um número muito maior de ferramentas, sistemas computacionais especiais e disputas teóricas em revistas especializadas. Porém, ao mesmo tempo, os resultados não são tão animadores. Então, vamos trabalhar firmemente para não colocarmos nossos próprios projetos naquela estatística.


150


Seção 8 – Idéias para um novo projeto

Na seção anterior discorremos sobre aprendizagem e sobre o processo de tirar lições dos casos de insucessos, das dificuldades e soluções que vamos encontrando no decorrer do trabalho de desenvolvimento do projeto. Porém, acredito que tais lições só são percebidas e aprendidas por pessoas e equipes especiais, cheias de idéias e criatividade. Acabar um projeto, geralmente serve de pretexto para dar origem a um novo projeto, pois todas as idéias que foram surgindo no meio do caminho são sementes para novos trabalhos. Empresas buscam pessoas assim, para que sobrevivam no mercado criando oportunidades de novos negócios.

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 criação e o lançamento de um produto totalmente novo. Anotações feitas durante o trajeto de desenvolvimento serão geradoras de oportunidades em ambos os sentidos. Por um lado, vários apontamentos dirão da necessidade de acrescentar melhorias incrementais, as quais não caberiam no decorrer do projeto, pois atrasariam o trabalho ou determinariam custos impossíveis de cumprir. Por outro lado, idéias completamente novas poderão surgir, apontando para soluções radicalmente diferentes. Um exemplo? A criação do Compact Disc foi uma solução totalmente diferente para o problema da gravação em fitas magnéticas.

É importante, também, perceber que o fracasso de um projeto não é, necessariamente, o encerramento das oportunidades. Fracassos ou graves problemas de um projeto chamam a atenção para novas oportunidades de desenvolvimento. Contudo, para renascer é preciso ter o espírito e a convicção dos líderes.

Por fim, gostaria de encerrar chamando a atenção para a estrutura de negócios da figura 4.4, com uma representação em três dimensões onde os eixos definem diferentes atuações no interior da empresa ou organização. Este desenho está pleno de idéias para novos projetos. Vamos ver mais de perto.


151


Figura 4.4 – Processos em um ambiente de negócios Fonte: Adaptado de Greeff (2005).

O eixo horizontal conecta a cadeia de fornecimento a de relacionamento com o cliente, o vertical estabelece a ligação entre a produção e a administração do negócio 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 idéias de novos projetos. Mas hoje o essencial está nas ligações entre o maior conjunto possível de eixos e a isso poderíamos chamar de gestão dos processos. Projetos podem surgir para interligar o processo de produção no chão-de-fábrica ao ambiente administrativo, por exemplo, e é o que está começando a acontecer, neste exato momento, com a interligação entre a automação industrial e o ERP das companhias. Iguais a essa, inúmeras oportunidades estão à nossa frente. Ou seja, é a hora de começar um novo projeto. Boa sorte!

ERP: iniciais de Enterprise Resource Planning, que representa o sistema computacional integrado para gestão empresarial, composto de módulos diversos como os de ‘contabilidade, finanças, recursos humanos, compras, orçamentos, estoques’, entre outros, facilitando o fluxo de informações entre os departamentos da empresa visando a otimização do seu planejamento.


152


Síntese

Nesta unidade você estudou sobre a importância de uma análise criteriosa de todos os passos dados durante o projeto e que tais passos precisam ser cuidadosamente documentados. Com isso será possível 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 também gerar novas idéias de projetos.

Outra questão importante refere-se ao reconhecimento dos membros da equipe como os verdadeiros responsáveis pelas conquistas obtidas. Evidenciar tais méritos é uma obrigação pois, a partir do momento que o projeto se encerra, as pessoas se voltarão para outros trabalhos e funções, porém se lembrarão desses momentos de desafio e sentirão satisfação por saber que foram reconhecidas.

Haverá os casos de fracassos, não estaremos livres disso. Esses casos devem ser analisados com ainda maior rigor, permitindo nosso crescimento pessoal e também a propagação da experiência para todos os interessados. Vimos que casos famosos de fracassos são um bom objeto de estudo e, também, que há vezes onde um suposto fracasso se revelou como sendo um empreendimento de sucesso ao longo do tempo. Também esses são casos importantes de pesquisa e análise, especialmente por considerar que foram, geralmente, conduzidos por líderes obstinados e capazes de inspirar e motivar suas equipes a despeito dos fatores negativos momentâneos.

Oportunidades de novos projetos estão à nossa disposição. A última seção fala justamente disso e, de certa forma, nos liga ao início deste livro que discute a origem dos projetos. Que seja aqui, então, o ponto de ligação para o eterno recomeçar, seja dos estudos, seja dos projetos, seja dos novos empreendimentos de sucesso. Até mais!


153



1) Quais são os passos para implantar um plano de recuperação, em um projeto em crise? Exemplifique com projetos de sua experiência.

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 lições você tira do fracasso do projeto VASA para seus próprios projetos?


154


5) Considere seu próprio campo de trabalho e sua experiência profissional, e analise a figura abaixo. Que nova idéia de projeto, concreta e exeqüível, você pode sugerir?


155


Saiba mais

O IEEE – Institute of Electric and Electronic Engineers – mantém uma Sociedade voltada à gestão de engenharia e projetos, de âmbito mundial. É a IEEE Engineering Management Society. Visite o site desse instituto e veja inúmeras oportunidades de trabalho, estudo, artigos, revistas etc. Estudantes de graduação, de qualquer área, podem se associar com valores de taxas anuais especiais.


Para concluir o estudo

Chego ao final deste trabalho e espero ter cumprido boa parte das suas intenções! Quem dirá isso será você, leitor e estudante. Pois também sou um estudante deste tema, que muito me interessa e sempre me desafia. Ao longo do tempo fui reunindo informações teóricas e, ao mesmo tempo, agindo em diferentes projetos, alguns de sucesso, outros nem tanto. Tentei colocar o máximo desses conhecimentos e experiências aqui, e simultaneamente comparar e refletir sobre novas tendências neste campo.

Apresentei algumas técnicas e modelo de apoio, seja nas análises iniciais ou para o planejamento, acompanhamento e controle do projeto até seu final, sabendo, no entanto, que tais técnicas e modelos vão sendo alterados com o tempo e com o desenvolvimento das tecnologias de gestão. Dessa forma, o foco principal não foi em tais modelos, mas sim no seu uso como ferramentas de auxílio numa visão ampla do processo de trabalho envolvido em projetos, sejam eles de que tamanho forem. Assim, atenção foi dada essencialmente na aprendizagem e na discussão que gera conhecimento. Por esse motivo, acredito que tenha acompanhado ao lado do cunho acadêmico de um livro de graduação, também uma abordagem direcionada às aplicações práticas e ao nível estratégico, fundamentais para o progresso do nosso dia-a-dia.

Também é importante frisar que este livro seja uma introdução ao tema da gestão de projetos e das equipes que os compõem, sendo que inúmeros 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 nós mesmos devemos contribuir no debate.


Por fim, gostaria de frisar a importância da liderança em projetos, tema tantas vezes abordado aqui. A gestão que desenvolve os aspectos da liderança saberá conduzir seu trabalho ao aprendizado constante, ao sucesso, e especialmente ao bem-estar das pessoas, nosso objetivo primordial. Sucesso a todos!

Prof. Mauro Faccioni Filho


Referências

BAZZO, Walter Antônio; PEREIRA, Luiz Teixeira do Vale. Introdução à Engenharia. 5. ed. Florianópolis: Editora da UFSC, 1997.

CHRISTENSON, Dale; WALKER, Derek H. T. Understanding the role of “vision” in project success. IEEE Engineering Management Review, 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. 396-397, 2004.

CORAU, Christophe. Muralhas que dividiram os homens. História Viva. 13. ed., nov. 2004. Disponível em <http://www.uol.com.br/historiaviva/home.html>. Acesso em: 18 fev. 2005.

COVEY, Stephen. O 8º hábito: da eficácia à 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. Especificação e solução de problemas de engenharia. Florianópolis: CTAI/Senai/SC, 2004. Apostila do Curso de Especialização em Automação e Computação 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. Disponível em: <http://computer.org/software>.

FERNANDES, Jorge Monteiro. Gestão da tecnologia como parte da estratégia competitiva das empresas. Brasília: IPDE, 2003.

GOOCH, Tom. Object oriented analysis and design team. Kennesaw State University, 2000. Disponível em: <http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/index.htm>. Acesso em: 24 abr. 2005.

GREEFF, Gerhard. Staying in sync. ISA Intech/Industrial Computing, v. 52, n. 6, p. 51-55, jun. 2005. Disponível em: <www.isa.org/intech>.


HINOJOSA, María Alejandra. Diagrama de Gantt. 2003. Disponível em: <www.gestiopolis.com>. Acesso em: 24 abr. 2005.

HOUAISS, Antônio. Dicionário Houaiss da Língua Portuguesa. Rio da Janeiro: Editora Objetiva / Instituto Antônio 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. Gestão de projetos: uma abordagem global. São 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. Disponível em: <http://www.markham.edu.pe/uk2002/uk_day_11.htm>. Acesso em: 14 abr. 2011. il.

MONUMENTOS HISTÓRICOS. Pirâmides do Egito. 25 abr. 2011. Disponível em: <http://monumentos252.blogspot.com/>. Acesso em: 17 maio 2011. il.

MICROSOFT SOLUTIONS FRAMEWORK (MSF). 1998. Disponível 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 prático para restauração da qualidade em projetos e sistemas de processamento de dados. São Paulo: McGraw-Hill, 1990.

PROCESS QUALITY ASSOCIATES INC (PQA). History of Project Management. Disponível 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: Série Gerência 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.

SÁENZ, Tirso W.; CAPOTE, Emilio G. Ciência, inovação e gestão tecnológica. Brasília: IEL/SENAI, 2002.


161


SISK, Toney. The history of project management. Disponível em: <http://offi ceupdate.microsoft.com/downloadDetails/projhistory.htm>. Acesso em: 20 fev. 2005.

SOFTEX – EXCELLENCE IN SOFTWARE. Terceirização de software e serviços de TI cresce. 09 jun. 2005. Disponível 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. Disponível em: <http://www.travelsinparadise.com/australia/sydney/pictures/sydney-bridge-03.html>. Acesso em: 24 maio 2011. il.

VALERIANO, Dalton L. Gerência em projetos: pesquisa, desenvolvimento e engenharia. São Paulo: Makron Books, 1998.


Sobre o professor conteudista

Mauro Faccioni Filho nasceu em Maringá, PR, em 29 de outubro de 1962. Formou-se em Engenharia Elétrica pela Universidade Federal de Santa Catarina (UFSC) no começo do ano de 1985, e nesse mesmo ano fundou a empresa Creare Engenharia, junto com dois colegas da universidade. Posteriormente concluiu, também na UFSC, Mestrado (1997) e Doutorado (2001) em Engenharia Elétrica, com estudos sobre representações tridimensionais e modelagem numérica computacional.

Nos anos 2002 a 2004 atuou como diretor do Centro de Tecnologia em Automação e Informática – CTAI, em Florianópolis, tendo participado na criação de cursos superiores e de pré-incubadora empresarial tecnológica, além de ter editado revista técnica em automação e informática.

Desde 2002 na UNISUL, como professor, participou do desenvolvimento em 2004 do projeto do Curso Superior de Tecnologia em Web Design e Programação, do qual é atualmente coordenador e onde atua também como tutor.

Com vários artigos técnicos e científicos publicados, lançou ainda três livros de poemas. Seu currículo completo está disponível para consulta on-line no banco de dados do CNPq, no endereço http://buscatextual.cnpq.br/buscatextual/index.jsp.


Respostas e comentários das atividades de autoavaliação

Unidade 1

1)

Programa Qualidade Prazos estimados pela equipe de implantação

A - reuniões do grupo do projeto para definir o programa 1 semana, 7 dias

B - redação do programa de qualidade 2 semanas, 14 dias

C - treinamento do pessoal do setor administrativo 3 dias

D - implantação do programa de qualidade no setor Administrativo; 2 semanas, 14 dias

E - treinamento do pessoal do setor de produção 3 dias

F - implantação do programa no setor de produção; 2 semanas, 14 dias

G - avaliação dos resultados e conclusão 3 dias

2)

3)


166


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 disponíveis dentro de tal folga, sem afetar o andamento geral do projeto.

Unidade 2

1) As quatro fases são “Formação, Turbulência, Normalização e Desempenho”. Geralmente a mais problemática é a segunda fase, pois há a formação 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 disponíveis para o trabalho. Não havendo recursos humanos na empresa ou grupo, pode-se buscar por recrutamento externo. Da mesma forma a matriz ajuda a definir os investimentos financeiros do projeto, pois é possível definir os gastos com 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 condições. Nesse modelo os membros do projeto são 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 vários 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 domínios e os interesses técnicos são muito diferentes. Esse tipo de estrutura é tipicamente multidisciplinar, com grande número de idéias e soluções criativas, o que favorece desenvolvimento de aplicativos de software.


167


6) Resposta subjetiva. Comentários sobre produtividade, sobre riscos de atraso, sobre falta de qualidade, sobre diferenças culturais afetando os resultados, sobre queda de preços.

Unidade 3

1) Resposta subjetiva. O que considera os indivíduos tem o perfil de “humano”, o intelectual é o que lança desafios, o que influencia ideais e inspirações é o motivador das pessoas.

2) Os quatros passos são: (1) identificar possíveis modos de ação, (2) verificar vantagens e desvantagens; (3) discutir e avaliar; (4) escolher o modo de ação mais vantajoso, e partir para ele.

3) Resposta subjetiva baseada no seguinte quadro:

Diferenças

Indivíduo / profissional Organização / gerência

Busca a inovação tecnológica Busca o lucro

Quer autonomia de ação Quer integrar os profissionais na organização

Quer livrar-se de regras e procedimentos Estabelece as regras e procedimentos

Quer autoridade baseada em mérito Autoridade baseada em hierarquia

Quer ser recompensado com base em seu desempenho Recompensa conforme o interesse da organização

Quer ampla comunicação entre pares Bloqueia a comunicação interna

Busca otimização do próprio trabalho Busca cumprimento de cronogramas e custos

4) As formas apresentadas são: por confronto, por comprometimento, por acomodação, por prevalência, por retirada.

5) O uso de simuladores pode ser importante para verificar protótipos de produtos, antes mesmo de eles serem construídos. Os simuladores passaram a ser ainda mais importantes com o avanço da informática, que permitiu o uso de simulação computacional, que poupa tempo e dinheiro, especialmente em projetos de produtos complexos ou muito grandes, como máquinas, grandes hidrelétricas, grandes construções etc.


Unidade 4

1) Os passos são:

desenvolver um plano de recuperação; �redefinir e gerenciar o propósito do projeto; �reavaliar o negócio; �replanejar o projeto usando métodos de estimativa; �gerenciar as expectativas dos clientes; �formular um plano de comunicação; �dividir o restante do projeto em pequenas partes; �tratar as dificuldades pessoais da equipe do projeto; �incorporar práticas corretivas; �reavaliar a liderança �

(Os exemplos serão individuais).

2) Erros de comunicação no início do projeto causam frustrações na fase final. Os clientes têm dificuldades para definir seus requisitos, e muitas vezes têm expectativas exageradas.

3) Pode-se evitar fracassos tomando as seguintes atitudes:

avaliando detalhadamente a viabilidade do projeto antes de começá-lo; �fazendo uma análise de riscos criteriosa; �usando métodos de planejamento; �usando sistemas de controle durante a fase de desenvolvimento. �

4) Resposta subjetiva. Poderá haver citações sobre o descontrole, sobre a falta de liderança, sobre as interrupções constantes feitas pela lei, sobre a falta de conhecimento técnico apropriado, sobre o planejamento fraco, sobre a falta de documentação.

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 chão-de-fábrica aconteceram principalmente na China e na Coréia, sendo que os processos de venda estavam concentrados nos escritórios regionais da empresa.


Biblioteca Virtual

Veja a seguir os serviços oferecidos pela Biblioteca Virtual aos alunos a distância:

Pesquisa a publicações 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

Empréstimo de livros �www. unisul.br/emprestimos

Escaneamento de parte de obra � *

Acesse a página da Biblioteca Virtual da Unisul, disponível no EVA e explore seus recursos digitais.

Qualquer dúvida escreva para [email protected]

* Se você optar por escaneamento de parte do livro, será lhe enviado o sumário da obra para que você possa escolher quais capítulos deseja solicitar a reprodução. Lembrando que para não ferir a Lei dos direitos autorais (Lei 9610/98) pode-se reproduzir até 10% do total de páginas do livro.


[1927 - 18737]gestao de projetos e de equipes

Documents