GESTÃO DE PROJETOS

Aula 01

Prof. Cleuber Moreira FernandesMestre em Ciência da Computação - UnB

Cleubermf@yahoo.com.brhttp://br.groups.yahoo.com/group/GP-2008

1

1. Conceitos de Gestão de Projetos

1.1 Perguntas e respostas importantes

a) O que é?

Uma atividade importante quando sistemas de computadores são construídos. Envolve o planejamento, a monitoração

e o controle de recursos, processo e eventos que ocorrem à medida que o software evolui de um conceito prelimiar

para uma implementação operacional.

b) Quem faz?

Todos gerenciam em uma certa medida, mas o escopo das atividades de gestão varia com a pessoa que as executam.

Um engenheiro de software gerencia suas atividades do dia-a-dia, planejando e controlando tarefas técnicas. Gerentes

de projeto planejam, monitoram e controlam o trabalho de uma equipe composta por analistas, arquitetos,

programadores, testadores etc. Gerentes seniores coordenam a interface entre o negócio e os profissionais de software.

c) Por que é importante?

Construir software é uma atividade complexa, principalmente se o escopo do produto é grande e envolve tecnologias

de ponta.

d) Quais são os passos?

Precisa-se entender os 4 P’s – Pessoas, Produto, Processo e Projeto. Pessoas precisam ser organizadas para realizar o

trabalho de software efetivamente. A comunicação com o cliente precisa ocorrer para que o escopo e os requisitos do

produto sejam entendidos. Um processo precisa ser selecionado a fim de se adquar ao pessoal e ao produto. O projeto

precisa ser planejado, estimado o esforço e o tempo para executar as tarefas de trabalho: definição de produtos de

trabalho, estabelecimento de marcos de qualidade e estabelecimento de mecanismos para monitorar e controlar o

trabalho definido pelo plano.

e) Qual o produto do trabalho?

O plano de projeto, que é produzido à medida que as atividades de gerência são iniciadas. O plano define os processos

e as tarefas a serem conduzidos, o pessoal que executará o trabalhoe os mecanismos para avaliar riscos, controlar

modificações e avaliar qualidade.

f) Como garanto que fiz corretamente?

Não se pode ter completa certeza de que o plano de projeto está correto até que se tenha entregue um produto de alta

qualidade, pontualmente e dentro do orçamento.

1.2 Os 4 P’s

a) Pessoal

O fator pessoal é tão importante que o Software Engineering Institute desenvolveu um modelo de maturidade da

capacidade de gestão de pessoal (People-CMM), para orientar organizações de software a atrair, desenvolver, motivar,

empregar e reter o talento necessário para melhorar sua capacidade de desenvolvimento de software.

2

Esse modelo define as seguinte práticas-chave para pessoal de software: recrutamento, seleção, gestão de

desempenho, treinamento, remuneração, desenvolvimento de carreira, organização e projeto do trabalho, e

desenvolvimento de equipe.

b) Produto

Para se planejar um projeto, devem ser estabelecidos os objetivos e o escopo do produto, as soluções alternativas

devem ser consideradas e as restrições técnicas e gerenciais devem ser identificadas. Sem essas informações é impossível

definir estimativas de custo razoáveis e “precisas”, avaliações efetivas de risco e cronogramas que proporcione uma

indicação significativa do progresso. Pode iniciar como engenharia de processo do negócio e terminar na engenharia de

requisitos de software.

c) Processo

Fornece o arcabouço a partir do qual pode ser estabelecido um plano abrangente para o desenvolvimento de software.

Vários conjuntos diferentes de tarefas, produtos de trabalho, papéis e pontos de controle, permitem adaptação às

características do projeto e às necessidades da equipe de projeto. Por fim, atividades guarda-chuva – garantia da qualidade,

gerenciamento de configurações e mudanças, medição – cobrem o modelo de processo.

c) Projeto

A única forma conhecida de gerir a complexidde é por meio de projetos de software planejados e controlados.

1.3 Pessoal

Em pesquisa realizada pelo IEEE com os vice-presidentes de 3 importantes empresas de tecnologia, todos

consideraram as pessoas o fator mais importante de um projeto de tecnologia. Apesar de reconhecerem isso, as ações

empreendidas nessa áreas nem sempre condizem com seu valor.

1.3.1 Os participantes (stakeholders)

• Gerentes seniores – cuidam dos aspectos do negócio que influenciam o projeto;

• Gerentes de projeto (técnicos) – planejam, motivam, organizam e controlam os profissionais que fazer o

trabalho;

• Especialistas – fornecem o conhecimento técnico necessário à engenharia;

• Clientes – Especificam os requisitos;

• Usuários – interagem com o software após implantado.

1.3.2 Líderes de equipe

Com frequência, pessoas caem na posição de gerência de projeto e viram gerentes por acidente!

Um gerente de projetos deve possuir as seguintes características:

a) Solução de problemas – diagnosticas os aspectos técnicos e organizacionais mais relevantes, estruturar

sistematicamente uma solução e motivar outros profissionais a desenvolver a solução, aplicar lições aprendidas e ser

flexível para mudar o rumo se as tentativas iniciais não frutificarem.

3

b) Identidade gerencial – deve assumir o encargo do projeto.

c) Realização – otimizar a produtividade da equipe premiando a iniciativa e a realização e demonstrar, com suas próprias

ações, que assumir risco controlado não implica punição.

d) Influência e construção de espírito de equipe – um gerente de projeto eficiente deve conseguir ver as pessoas,

entender os sinais verbais e não verbais e reagir às suas necessidades. Deve manter o controle em situações de alta

tensão.

1.3.3 Equipe de Software

a) Democrática DescentralizadaNão possui líder permanente, sendo substituídos periodicamente. A comunicação entre os membros da equipe é horizontal.

b) Controlada DescentralizadaPossui um líder definido e líderes secundários (responsáveis por sub-tarefas)

4

c) Controlada CentralizadaPossui um gerente sênior que planeja e revê todas as atividades técnicas das equipes.Um engenheiro de retaguarda que apóia o gerente sênior nas suas atividades e pode substituí-lo, com perda mínima dacontinuidade do projeto.

• A estrutura Democrática Descentralizada resulta em moral elevada e satisfação no trabalho• A estrutura Democrática Descentralizada é adequada para tratar problemas mais difíceis.• Quando a modularização é alta, a estrutura Controlada Centralizada ou a Controlada Descentralizada funcionarão

bem.• As estruturas Controlada Descentralizada e Controlada Centralizada produzem menos falhas.

É importante notar que o reconhecimento de diferenças humanas é o primeiro passos na direção de criar equipes que

se aglutinam.

1.3.4 Problemas de coordenação e comunicação

Uma equipe de engenharia de software precisa estabelecer métodos específicos para coordenar o pessoal que faz o

trabalho e lidar efetivamente com as características modernas do software: escala, incerteza e interoperabilidade.

Para conseguir isso, mecanismos para comunicação formal e informal precisam ser estabelecidos entre os membros da

equipe e entre diferentes equipes.

• Abordagens formais e impessoais – documentos escritos, reuniões estruturadas, documentos de engenharia de

software, momorandos técnicos, marcos de projeto, cronogramas, pedidos de modificação, relatórios de detecção

de erros.

• Procedimentos formais e interpessoais – atividades de garantia da qualidade aplicadas aos produtos do trabalho

de engenharia, como reuniões de revisão e inspeções do projeto e código.

• Procedimentos informais e interpessoais – reniões de grupo para disseminação da informação e solução de

problemas.

• Comunicação eletrônicas – email, documentos digitais, vídeo-conferências.

• Redes Interpessoais – discussões informais com membros da equipe e estranhos ao projeto.

5

1.4 Produto

O gerente de projeto tem um dilema no início de um projeto. São necessárias estimativas quantitativas e um plano

organizado, mas não há informação sólida disponível. Assim sendo, é preciso examinar o produto e o problema que ele

pretende resolver no início do projeto.

1.4.1 Escopo do software

A delimitação do escopo é a primeira atividade de um projeto.

• Contexto – sistema maior, negócio, restrições.

• Objetivos da informação – que objetos de dados são necessários como entrada e saída

• Função e desempenho – transformação dos dados de entrada em saídas. Características especiais de

desempenho.

1.4.2 Decomposição do problema

Conhecida pela estratégia “dividir para conquistar”, é uma atividade de análise de requisitos que visa particionar um

problema complexo em problemas menores, mais gerenciáveis. Esse refinamento é necessário para que as estimativas de

custo e prazo sejam mais realístas.

1.5 Produto

As fases genéricas que caracterizam o processo de software – definição, desenvolvimento e manutenção – são

aplicáveis a todo software. O problema é selecionar o processo que é mais adequado para um software específico a ser

trabalhado por uma equipe de engenharia. Um conjunto de paradígmas pode ser escolhido.

• Sequêncial Linear

• Prototipagem

• Espiral

• Iterativo e Incremental

O gerente de projeto deve decidir qual modelo é mais apropriado para:

a) o cliente que solicitou e as pessoas que executarão o trabalho;

b) as características do produto;

c) o ambiente de projeto.

6

1.5.1 Fusão do Produto e do Processo

Funcio-

nalidade

Comunicação

com Cliente

Planejamento Análise de

Risco

Engenharia Construção e

Implantação

Avaliação pelo

Cliente

Cadastrar

Produtos

Datas e produtos

trab.

Datas e produtos

trab.

Datas e

produtos trab.

Datas e

produtos trab.

Datas e

produtos trab.

Datas e

produtos trab.

Emitir

Pedidos

Datas e produtos

trab.

Datas e produtos

trab.

Datas e

produtos trab.

Datas e

produtos trab.

Datas e

produtos trab.

Datas e

produtos trab.

1.5.2 Decomposição do Processo

As tarefas reais variam com o projeto. A decomposição é a determinação de como as atividades da estrutura geral

(comunicação com o cliente, planejamento, ...) serão realizadas. A comunicação com o cliente num projeto pequeno pode

ser realizada com as seguintes tarefas:

1. Desenvolva uma lista de pontos a resolver;

2. Reuna-se com o cliente para discutir esses pontos;

3. Desenvolva conjuntamente uma declaração de escopo;

4. Revise a declaração com todos os interessados;

5. Modifique a declaração na medida do necessário.

Mas num projeto mais complexo, com escopo mais amplo, pode exigir uma série de outras tarefas que garantam maior

confiabilidade abrangência.

1.6 Projeto

Para gerir com sucesso um projeto de software é preciso entender o que pode dar errado e comofazer para dar certo. Seguem 10 sinais que indicam que um projeto está comprometido:

1. O pessoal de software não entende as necessidades de seus clientes;

2. O escopo do produto está mal definido;

3. As modificações são mal gerenciadas;

4. A tecnologia escolhida sobre modificações;

5. As necessidades do negócio modificam-se;

6. Os prazos são irreais, inexequíveis;

7. Os usuários são resistentes;

8. O patrocínio é perdido;

9. A equipe de projeto não tem pessoal com as aptidões adequadas;

7

A seguir estão algumas recomendações de como um gerente deve agir para evitar os problemas mencionados:

1. Comece com o pé direito – entender bem o problema para depois estabelecer objetivos e expectativas realísticas a

todos envolvidos no projeto. Isso é reforçado pela estruturação correta da equipe e pela atribuição da autonomia,

autoridade e tecnologia necessárias a conduzir o trabalho.

2. Mantenha a energia de momento – providenciar incentivos para evitar a rotatividade de pessoal ao mínimo. A

equipe deve enfatizar a qualidade em toda tarefa que executar.

3. Acompanhe o progresso – à medida que produtos do trabalho (especificações, código-fonte, casos de teste) são

produzidos e aprovados usando revisões técnicas formais como parte da atividade de garantia da qualidade.

4. Tome decisões adequadas – essencialmente as decisões devem ser no sentido de “manter a coisa simples”. Sempre

que possível optar pelo software comercial em uso ou componentes existentes. Evitar interfaces sob medida, quando

padrões estão disponíveis. Decida identificar e evitar riscos e atribuir mais tempo do que se acha necessário às tarefas

complexas ou arriscadas.

5. Faça uma análise a posteriori – Estabelecer um mecanismo consistente para extrair e registrar as lições aprendidas

em cada projeto. Avaliar cronogramas planejados e cumpridos, coletar e analisar métricas de projeto, obter

realimentação dos membros da equipe e dos clientes.

1.7 O Princípio W5HH

Este princípio apresenta uma série de questões que levam à definição das características-chave doprojeto e do plano de projeto resultante:

1. Por que (Why) o sistema está sendo desenvolvido?

A razão que justifica o gasto de pessoal, o tempo e o dinheiro.

2. O que (What) vai ser feito, quando (When)?

As respostas ajudam a equipe a estabelecer um cronograma do projeto pela identificação de tarefas-chave e prazos

exigidos pelo cliente.

3. Quem (Who) é responsável pela função?

Definir o papel e responsabilidade de cada membro da equipe de software.

4. Onde (Where) estão localizados na organização?

Nem todos os papéis e responsabilidades estão na própria equipe. O cliente, usuários e outros também têm

responsabilidades.

5. Como (How) o trabalho será conduzido técnica e gerencialmente?

Uma vez estabelecido o escopo do produto, uma estratégia gerencial e técnica deve ser definida.

6. Quanto (How much) é necessário de cada recurso?

A resposta é obtida pelo desenvolvimento de estimativas baseadas nas respostas às questões anteriores.