Capítulo 22 - Gerenciamento de projetos

Os projetos precisam ser gerenciados, pois a engenharia de software profissional

está sempre sujeita a orçamentos organizacionais e restrições de cronograma.

Os critérios de sucesso para o gerenciamento de projetos para a maioria dos projeto

são:

1. Fornecer o software ao cliente no prazo estabelecido.

2. Manter os custos gerais dentro do orçamento.
3. Entregar software que atenda às expectativas do cliente.
4. Manter uma equipe de desenvolvimento que trabalhe bem e feliz.

O que tornam o gerenciamento de software particularmente desafiador são:

1. O produto é intangível. O software é intangível. Ele não pode ser visto ou

tocado. Os gerentes de projeto de software não podem ver o progresso, simplesmente
olhando para o artefato que está sendo construído. Em vez disso, eles dependem de
outros para produzir provas que eles possam usar para revisar o progresso do
trabalho.

2. Os grandes projetos de software são, muitas vezes, ‘projetos únicos’.

Geralmente, os grandes projetos de software são diferentes dos projetos anteriores
em alguns aspectos. As lições aprendidas em projetos anteriores podem não ser
transferíveis para novos projetos.

3. Os processos de softwares são variáveis e de organização específica. Ou seja,

ainda não somos confiantes em prever quando um processo de software, em particular,
conduzirá a problemas de desenvolvimento, especialmente quando o projeto de
software é parte de um projeto de engenharia de sistemas mais amplo.

É impossível fazer uma descrição do trabalho-padrão para um gerente de projeto de

software. O trabalho varia muito, de acordo com a organização e o produto de
software que está sendo desenvolvido. No entanto, a maioria dos gerentes assume a
responsabilidade em algum momento para algumas ou todas as atividades apresentadas
a seguir:

1. Planejamento de projeto. Os gerentes de projetos são responsáveis por

planejamento, elaboração de estimativa e de cronograma de desenvolvimento de
projeto e atribuição de algumas tarefas para as pessoas. Eles supervisionam o
trabalho para garantir que seja realizado conforme os padrões exigidos e acompanham
o progresso realizado para verificar se o desenvolvimento está no prazo e dentro do
orçamento.

2. Geração de relatórios. Os gerentes de projeto precisam ser capazes de se

comunicar em vários níveis, desde informações técnicas detalhadas até resumos de
gerenciamento. Eles devem escrever documentos concisos e coerentes que abstraem as
informações críticas dos relatórios de projeto detalhados. Eles devem ser capazes
de apresentar essas informações durante as revisões de progresso.

3. Gerenciamento de riscos. Os gerentes de projeto devem avaliar os riscos que

podem afetar um projeto, controlar esses riscos e agir quando surgem problema.

4. Gerenciamento de pessoas. Os gerentes de projeto são responsáveis por gerenciar

uma equipe de pessoas. Eles devem escolher as pessoas para sua equipe e estabelecer
formas de trabalhar que levem a um desempenho eficaz da equipe.

5. Elaboração de propostas. A proposta descreve os objetivos do projeto e como ele

vai ser realizado. Geralmente, ela inclui estimativas de custo e cronograma e
justifica por que o projeto deve ser confiado a uma determinada organização ou
equipe.

22.1 Gerenciamento de riscos

Ele envolve antecipar os riscos que podem afetar o cronograma do projeto ou a

qualidade do software que está sendo desenvolvido e tomar medidas para evitar tais
riscos.

Existem três categorias de risco relacionadas:

1. Riscos de projeto. Riscos que afetam o cronograma ou os recursos de projeto. Um

exemplo de um risco de projeto é a perda de um projetista experiente. Encontrar um
projetista substituto com competência e experiência adequados pode demorar muito
tempo e, por conseguinte, o projeto de software vai demorar mais tempo para ser
concluído.

2. Riscos de produto. Riscos que afetam a qualidade ou o desempenho do software que

está sendo desenvolvido. Um exemplo de um risco de produto é a falha de um
componente comprado para o desempenho esperado, podendo afetar o desempenho geral
do sistema de forma mais lenta do que o esperado.

3. Riscos de negócio. Os riscos que afetam a organização que desenvolve ou adquire

o software. Por exemplo, um concorrente que introduz um novo produto é um risco
empresarial. A introdução de um produto competitivo pode significar que as
suposições feitas sobre vendas de produtos de software existentes podem ser
excessivamente otimistas.

Você deve registrar os resultados da análise de risco no plano de projeto,

juntamente com uma análise de consequências, a qual estabelece as consequências dos
riscos para o projeto, produto e negócio. Um gerenciamento eficaz de riscos torna
mais fácil lidar com os problemas para garantir que eles não demandem um orçamento
ou um atraso de cronograma inaceitáveis.

Vejamos um esboço do processo de gerenciamento de riscos envolvendo vários

estágios:

4. Identificação de riscos. Você deve identificar possíveis riscos de projeto, de

produto e de negócios.
5. Análise de riscos. Você deve avaliar a probabilidade e as consequências desses
riscos.
6. Planejamento de riscos. Você deve planejar para enfrentar o risco, evitando ou
minimizando seus efeitos sobre o projeto.
7. Monitoramento de riscos. Você deve avaliar regularmente os riscos e seus planos
para mitigação de riscos e atualizá-los quando souber mais sobre os riscos.

22.1.1 Identificação de riscos

Pode ser um processo de equipe quando uma equipe se junta para dicutir os riscos
possíveis. Como alternativa, o gerente de projeto pode usar sua experiência para
identificar os riscos mais prováveis ou críticos. Existem pelo menos seis tipos de
riscos que podem ser incluídos em um checklist de verificação de riscos:

1. Riscos de tecnologia. Riscos que derivam das tecnologias de software ou hardware

que são usadas para desenvolver o sistema.
2. Riscos de pessoas. Riscos que são associados às pessoas da equipe de
desenvolvimento.
3. Riscos organizacionais. Riscos que derivam do ambiente organizacional onde o
software está sendo desenvolvido.
4. Riscos de ferramentas. Riscos que derivam das ferramentas de software e outros
softwares de suporte usados para desenvolver o sistema.
5. Riscos de requisitos. Riscos que derivam das mudanças nos requisitos de cliente
e no processo de gerenciamento de mudanças de requisitos.
6. Riscos de estimativas. Riscos que derivam das estimativas de gerenciamento dos
recursos necessários para construir o sistema.

Ao terminar o processo de identificação de riscos, você deve ter uma longa lista de
riscos que poderiam ocorrer e afetar o produto, o processo e os negócios. Assim,
você precisa reduzir essa lista para um tamanho gerenciável. Se você tiver muitos
riscos, é praticamente impossível manter o controle de todos eles.

22.1.2 Análise de riscos

Você tem de confiar em seu próprio julgamento e na experiência advinda de projetos

anteriores e de problemas que surgiram neles. Não é possível fazer uma avaliação
precisa e numérica da probabilidade e gravidade de cada risco. Em vez disso, você
deve atribuir o risco a um entre vários tipos:

1. A probabilidade do risco pode ser avaliada como muito baixa (< 10%), baixa (10 a
25%), moderada (25 a 50%), alta (50 a 75%) ou muito alta (> 75%).
2. Os efeitos do risco podem ser avaliados como catastróficos (ameaçam a
sobrevivência do projeto), graves (causariam grandes atrasos), toleráveis (os
atrasos estão dentro da contingência permitida) ou insignificantes.

22.1.3 O planejamento de riscos

Considera cada um dos principais riscos que foram identificados e desenvolve

estratégias para gerenciar esses riscos. Para cada um dos riscos, você precisa
pensar em ações que possa tomar para minimizar a interrupção do projeto, caso
ocorra o problema identificado no risco. Você também precisa pensar sobre as
informações que pode precisar coletar durante a monitoração do projeto de maneira
que os problemas possam ser antecipados.

As possíveis estratégias de gerenciamento de riscos identificados para os

principais riscos (graves ou intoleráveis) estão divididas em três categorias:

1. Estratégias de prevenção. Seguir essas estratégias indica que a probabilidade de

um risco ocorrer será reduzida. Um exemplo de uma estratégia de prevenção de riscos
é a estratégia para lidar com componentes defeituosos.

2. Estratégias de minimização. Seguir essas estratégias indica que o impacto do

risco será reduzido. Um exemplo de uma estratégia de minimização de risco é a
estratégia para a doença de pessoal.

3. Planos de contingência. Seguir essas estratégias indica que você está preparado
e tem uma estratégia para lidar com o pior. Um exemplo de uma estratégia de
contingência é a estratégia para problemas financeiros organizacionais.

22.1.4 Monitoração de riscos

É o processo de verificar se suas suposições sobre os riscos de produto, de

processo e de negócios não mudaram. Você deve avaliar regularmente cada um dos
riscos identificados para decidir se esse risco está se tornando mais ou menos
provável. Você também precisa verificar se os efeitos dos riscos mudaram ou não.
Para fazer isso, você deve observar outros fatores, como o número de solicitações
de mudanças de requisitos, que lhe dão pistas sobre a probabilidade de risco e seus
efeitos. Esses fatores dependem, obviamente, dos tipos de riscos.

Você deve monitorar esses riscos, regularmente, em todas as fases de um projeto. Em

cada revisão da gerência, você deve considerar e discutir cada um dos principais
riscos separadamente. Você deve decidir se os riscos são mais ou menos suscetíveis
de surgirem e se a seriedade e as consequências deles se alteraram.

22.2 Gerenciamento de pessoas

As pessoas que trabalham em uma organização de software são seus maiores ativos.
Custa muito para recrutar e reter boas pessoas e cabe aos gerentes de software
garantirem que a empresa obtenha o melhor retorno possível sobre seus
investimentos.

Há quatro fatores críticos no gerenciamento de pessoas:

1. Consistência. Ninguém espera que o reconhecimento seja igual para todos, mas as
pessoas não devem sentir que sua contribuição para a organização é subvalorizada.
2. Respeito. Pessoas diferentes têm habilidades diferentes e os gerentes devem
respeitar essas diferenças. A todos os membros da equipe devem ser dadas
oportunidades de contribuir. Claro que, em alguns casos, você vai encontrar pessoas
que simplesmente não se encaixam em uma equipe e não podem continuar.
3. Inclusão. Pessoas contribuem efetivamente quando sentem que são ouvidas por
outras pessoas e que suas propostas são levadas em consideração.
4. Honestidade. Como gerente, você deve sempre ser honesto sobre o que está indo
bem e o que vai mal na equipe. Você também deve ser honesto sobre seu nível de
conhecimento técnico e estar disposto a submeter-se a algum membro da equipe com
mais conhecimento, quando necessário.

22.2.1 Motivação de pessoas

Como gerente de projetos, você precisa motivar as pessoas que trabalham com você
para que elas contribuam com o melhor de suas habilidades. Motivação significa
organizar o trabalho e o ambiente de trabalho para incentivar as pessoas a
trabalharem do modo mais eficaz possível.

É importante, do ponto de vista de gerenciamento, certificar-se de que as

necessidades sociais, de autoestima e autorrealização das pessoas são satisfeitas.

Segundo a hieraruia de necessiades humanas, temos:

1. Para satisfazer as necessidades sociais, você precisa dar às pessoas tempo para
encontrarem seus colegas de trabalho e oferecer-lhes oportunidades para se
encontrarem. Portanto, é importante você organizar alguns encontros presenciais no
início do projeto para que as pessoas possam interagir diretamente com outros
membros da equipe. Por meio dessa interação direta, as pessoas tornam-se parte de
um grupo social e aceitam as metas e prioridades desse grupo.

2. Para satisfazer as necessidades de autoestima, você precisa mostrar às pessoas

que elas são valorizadas pela organização, e uma forma simples e eficaz de fazer
isso é pelo reconhecimento público. Certamente, as pessoas também devem sentir que
são pagas em um nível que reflete suas habilidades e experiência.

3. Finalmente, para satisfazer as necessidades de autorrealização, você precisa dar

às pessoas responsabilidade por seu trabalho, atribuir-lhes tarefas exigentes (mas
não impossíveis) e fornecer um programa de treinamento em que elas possam
desenvolver suas habilidades. O treinamento é uma importante influência motivadora
para as pessoas, assim como a aquisição de novos conhecimentos e novas habilidades.

Os tipos de personalidade também influenciam na motivação. Bass e Dunteman (1963)

classificam os profissionais em três tipos:

1. Pessoas orientadas a tarefas, que são motivadas pelo trabalho que fazem. Na
engenharia de software, essas são as pessoas motivadas pelo desafio intelectual do
desenvolvimento de software.

2. Pessoas automotivadas, que são motivadas, principalmente, pelo sucesso e

reconhecimento pessoal. Elas estão interessadas no desenvolvimento de software como
um meio de alcançarem seus próprios objetivos. Essas pessoas têm objetivos de longo
prazo que as motivam, como progressão na carreira, e desejam ser bem-sucedidas em
seu trabalho para concretizar tais objetivos.

3. Pessoas orientadas a interações, que são motivadas pela presença e ações dos
colegas de trabalho.

22.3 Trabalho de equipe

Montar uma equipe que tenha o equilíbrio entre as habilidades técnicas, a

experiência e as personalidades é uma tarefa de gerenciamento crítico. No entanto,
os grupos bem-sucedidos são mais do que um conjunto de indivíduos com equilíbrio de
habilidades. Um bom grupo é coeso e tem espírito de equipe. As pessoas envolvidas
são motivadas pelo sucesso do grupo, bem como por seus próprios objetivos pessoais.

Os benefícios da criação de um grupo coeso são:

1. O grupo pode estabelecer seus próprios padrões de qualidade.

2. As pessoas se apoiam e aprendem umas com as outras.
3. O conhecimento é compartilhado.
4. Refatoração e melhorias contínuas são incentivadas. Os membros do grupo
trabalham coletivamente para entregar resultados de alta qualidade e corrigir
problemas, independentemente dos indivíduos que originalmente criaram o projeto ou
o programa.

Uma das maneiras mais eficazes de promoção da coesão é tratar os membros do grupo
como responsáveis e confiáveis e disponibilizar informações livremente. A troca de
informações é uma maneira eficaz de fazer as pessoas se sentirem valorizadas e como
membros de um grupo.

Existem três fatores genéricos que afetam o trabalho de equipe:

1. As pessoas no grupo. Você precisa de uma mistura de pessoas em um grupo de um

projeto, pois o desenvolvimento de software envolve diversas atividades, como
negociação com clientes, programação, testes e documentação.

2. A organização de grupo. Um grupo pode ser organizado de maneira que os

indivíduos possam contribuir com o melhor de suas habilidades e as tarefas possam
ser concluídas conforme o esperado.

3. Comunicações técnicas e gerenciais. A boa comunicação entre os membros do grupo,

bem como entre a equipe de engenharia de software e outros participantes do
projeto, é essencial.
Obs.: ter a equipe certa não garante o sucesso do projeto. Muitas outras coisas
podem dar errado, incluindo mudanças nos negócios e no ambiente de negócios. No
entanto, se você não prestar atenção à composição, à organização e às comunicações
do grupo, você aumenta a probabilidade de que seu projeto seja executado com
dificuldades.

22.3.1 Seleção de membros de grupo

Envolve a criação de um grupo com equilíbrio certo entre as habilidades técnicas e

personalidades, assim como a organização desse grupo para que os membros trabalhem
juntos com eficiência.

Um grupo com personalidades complementares pode funcionar melhor do que um grupo

selecionado unicamente pela capacidade técnica. As pessoas que são orientadas a
interações ajudam a facilitar as comunicações dentro do grupo. Elas gostam de
conversar e podem detectar as tensões e divergências em um estágio inicial, antes
que isso tenha um grande impacto sobre o grupo.

22.3.2 Organização de grupo

As questões organizacionais mais importantes para os gerentes de projetos são:

1. O gerente de projetos deve ser o líder técnico do grupo? Para grandes projetos,
é melhor nomear um engenheiro sênior para ser o arquiteto de projeto, que assumirá
a responsabilidade pela liderança técnica.
2. Quem será envolvido na tomada de decisões técnicas críticas e como estas serão
tomadas? As decisões serão tomadas pelo arquiteto de sistema, pelo gerente de
projetos ou por um consenso entre o maior número de membros de equipe?
3. Como serão tratadas as interações com os stakeholders externos e a gerência
sênior da empresa? Em muitos casos, o gerente de projetos será responsável por
essas interações, assistidas pelo arquiteto de sistema, caso este exista. No
entanto, um modelo organizacional alternativo sugere a criação de um papel dedicado
interessado nos contatos externos e a nomeação de alguém com habilidades de
interação adequadas para esse papel.
4. Como os grupos podem integrar pessoas que não estão no mesmo local de trabalho?
5. Como o conhecimento pode ser compartilhado entre o grupo? Deve-se evitar muito
compartilhamento de informações, pois as pessoas ficam sobrecarregadas e o excesso
de informações pode distraí-las de seu trabalho.

Entusiastas do XP afirmam que a estrutura formal inibe a troca de informações.

Geralmente, em XP, muitas decisões percebidas como decisões de gestão (como as
decisões de agendamento) são atribuídas aos membros de grupo. Os programadores
trabalham juntos em pares para desenvolver o código e assumem responsabilidade
conjunta sobre os programas desenvolvidos.

Os grupos informais podem ser muito bem-sucedidos, particularmente quando a maioria

dos membros do grupo é experiente e competente. Esse grupo toma decisões por
consenso, o que melhora o desempenho e a coesão. No entanto, se a maior parte de um
grupo for composta de membros inexperientes ou incompetentes, a informalidade
poderá ser um obstáculo porque não há uma autoridade definitiva para direcionar o
trabalho, causando falta de coordenação entre os membros de grupo e, possivelmente,
eventuais falhas de projeto.

22.3.3 Comunicações de grupo

É absolutamente essencial que os membros de grupo se comuniquem de maneira eficaz e

eficiente com outros membros e com os stakeholders de outros projetos. Boa
comunicação também ajuda a reforçar a coesão de grupo. Membros de grupo conseguem
compreender as motivações, os pontos fortes e os pontos fracos das outras pessoas
do grupo.

A eficácia e a eficiência das comunicações são influenciadas por:

1. Tamanho de grupo. Conforme um grupo se torna maior, a comunicação eficaz entre

os membros fica mais difícil.
2. Estrutura de grupo. Pessoas em grupos estruturados informalmente comunicam mais
eficazmente do que as pessoas em grupos com uma estrutura formal, hierárquica.
3. Composição de grupo. A comunicação é melhor em grupos mistos do que em grupos do
mesmo sexo.
4. Ambiente físico de trabalho. A organização do local de trabalho é um fator
importante para facilitar ou inibir as comunicações.
5. Canais de comunicação disponíveis. Como as equipes de projeto se tornam cada vez
mais distribuídas, com membros de equipe trabalhando remotamente, você precisará
fazer uso de várias tecnologias para facilitar a comunicação.

Uma comunicação eficaz é alcançada quando a comunicação ocorre em dois sentidos e

as pessoas envolvidas podem discutir problemas e informações e estabelecer um
entendimento comum sobre as propostas e problemas.

PONTOS IMPORTANTES

> Um bom gerenciamento de projetos de software é essencial, caso os projetos de

engenharia de software devam ser desenvolvidos no prazo e dentro do orçamento.
> O gerenciamento de software é diferente de outros gerenciamentos de engenharia. O
software é intangível. Projetos podem ser novos ou inovadores; assim, não existe um
corpo de experiências para orientar seu gerenciamento. Os processos de software não
são tão maduros quanto os processos de engenharia tradicionais.
> Atualmente, o gerenciamento de riscos é reconhecido como uma das mais importantes
tarefas de gerenciamento de projetos.
> O gerenciamento de riscos envolve a identificação e a avaliação dos importantes
riscos do projeto para estabelecer a probabilidade de que eles ocorram e as
consequências para o projeto caso esses riscos ocorram. Você deve fazer planos para
evitar, gerenciar ou lidar com riscos suscetíveis quando, e se, eles surgirem.
> As pessoas podem ser motivadas pela interação com outras pessoas, pelo
reconhecimento da gerência e seus pares e pelas oportunidades de desenvolvimento
pessoal.
> Grupos de desenvolvimento de software devem ser bastante pequenos e coesos. Os
principais fatores que influenciam a eficácia de um grupo são as pessoas que o
compõem, a forma como ele está organizado e a comunicação entre seus membros.
> As comunicações dentro de um grupo são influenciadas por fatores como o status
dos membros do grupo, o tamanho do grupo, sua composição entre homens e mulheres,
as personalidades e os canais de comunicação disponíveis.