O documento fornece uma introdução aos conceitos básicos de gestão de projetos de software, incluindo os 4 Ps (Pessoas, Produto, Processo e Projeto). Discute a importância da gestão de pessoas e equipes, os diferentes tipos de estruturas de equipe, e os desafios de coordenação e comunicação em projetos de software. Também aborda a definição do escopo do produto e decomposição do problema, assim como a seleção e customização do processo de software.

1. GESTÃO DE PROJETOS
Aula 01
Prof. Cleuber Moreira Fernandes
Mestre em Ciência da Computação - UnB
Cleubermf@yahoo.com.br
http://br.groups.yahoo.com/group/GP-2008

2. 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.
1

3. 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.
2

4. 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 Descentralizada
Não possui líder permanente, sendo substituídos periodicamente. A comunicação entre os membros da equipe é horizontal.
b) Controlada Descentralizada
Possui um líder definido e líderes secundários (responsáveis por sub-tarefas)
3

5. c) Controlada Centralizada
Possui 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 da
continuidade 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.
4

6. 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.
5

7. 1.5.1 Fusão do Produto e do Processo
Funcio- Comunicação Planejamento Análise de Engenharia Construção e Avaliação pelo
nalidade com Cliente Risco Implantação Cliente
Cadastrar Datas e produtos Datas e produtos Datas e Datas e Datas e Datas e
Produtos trab. trab. produtos trab. produtos trab. produtos trab. produtos trab.
Emitir Datas e produtos Datas e produtos Datas e Datas e Datas e Datas e
Pedidos trab. trab. produtos trab. produtos trab. produtos trab. 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 como
fazer 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;
6

8. 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 do
projeto 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.
7