DANIELE MARTINS FERNANDO REZENDE CELESTINO JOÃO OSWALDO MAZUR MARCELO STIVAL WALTER RIBEIRO DE OLIVEIRA JR A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE MELHORES PRÁTICAS DE GERENCIAMENTO DE PROJETOS EM EMPRESAS DE PEQUENO PORTE DE DESENVOLVIMENTO DE SOFTWARE. Trabalho apresentado ao curso MBA em Gerência de Projetos, Pós-Graduação lato sensu, da Fundação Getúlio Vargas como requisito parcial para a obtenção do Grau de Especialista em Gerência de Projetos. ORIENTADOR: Prof. Denise Basgal Curitiba Março / 2009
202
Embed
A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE MELHORES ... · elaboração dos trabalhos para apresentação nos fóruns e orientação dada para elaboração deste trabalho de conclusão
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
DANIELE MARTINS
FERNANDO REZENDE CELESTINO
JOÃO OSWALDO MAZUR
MARCELO STIVAL
WALTER RIBEIRO DE OLIVEIRA JR
A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE
MELHORES PRÁTICAS DE GERENCIAMENTO DE
PROJETOS EM EMPRESAS DE PEQUENO PORTE DE
DESENVOLVIMENTO DE SOFTWARE.
Trabalho apresentado ao curso MBA em Gerência de Projetos, Pós-Graduação lato sensu, da Fundação Getúlio Vargas como requisito parcial para a obtenção do Grau de Especialista em Gerência de Projetos.
ORIENTADOR: Prof. Denise Basgal
Curitiba
Março / 2009
FUNDAÇÃO GETULIO VARGAS
PROGRAMA FGV MANAGEMENT
MBA EM GERÊNCIA DE PROJETOS
O Trabalho de Conclusão de Curso
“A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE MELHORES PRÁTICAS
DE GERENCIAMENTO DE PROJETOS EM EMPRESAS DE PEQUENO PORTE DE
DESENVOLVIMENTO DE SOFTWARE”
elaborado por DANIELE MARTINS, FERNANDO REZENDE CELESTINO, JOÃO
OSWALDO MAZUR, MARCELO STIVAL e WALTER RIBEIRO DE OLIVEIRA JR
e aprovado pela Coordenação Acadêmica do curso de MBA em Gerência de Projetos, foi
aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível
de especialização do Programa FGV Management.
Curitiba, 18 de março de 2009
Carlos A. C. Salles
Jr.
Coordenador
Acadêmico
Executivo
Prof. Denise Basgal
DECLARAÇÃO
A empresa Wasys Tecnology, representada neste documento pelo Sr.(a) JOÃO OSWALDO
MAZUR, Sócio-Diretor, autoriza a divulgação das informações e dados coletados em sua
organização, na elaboração do Trabalho de Conclusão de Curso intitulado “A ANÁLISE DA
MATURIDADE E RECOMENDAÇÕES DE MELHORES PRÁTICAS DE
GERENCIAMENTO DE PROJETOS EM EMPRESAS DE PEQUENO PORTE DE
DESENVOLVIMENTO DE SOFTWARE”, realizados pelos alunos DANIELE MARTINS,
FERNANDO REZENDE CELESTINO, JOÃO OSWALDO MAZUR, MARCELO STIVAL
e WALTER RIBEIRO DE OLIVEIRA JR, do curso de MBA em Gerência de Projetos, do
Programa FGV Management, com o objetivo de publicação e/ ou divulgação em veículos
acadêmicos.
Curitiba, 14 de Janeiro de 2009.
JOÃO OSWALDO
MAZUR
Sócio-Diretor
Wasys Tecnology
TERMO DE COMPROMISSO
Os alunos DANIELE MARTINS, FERNANDO REZENDE CELESTINO, JOÃO
OSWALDO MAZUR, MARCELO STIVAL e WALTER RIBEIRO DE OLIVEIRA JR,
abaixo assinados, do curso de MBA em Gerência de Projetos, Turma 02/2007 do Programa
FGV Management, realizado nas dependências do Instituto Superior de Administração e
Economia - ISAE/FGV, no período de 08/2007 a 02/2009, declaram que o conteúdo do
Trabalho de Conclusão de Curso intitulado “A ANÁLISE DA MATURIDADE E
RECOMENDAÇÕES DE MELHORES PRÁTICAS DE GERENCIAMENTO DE
PROJETOS EM EMPRESAS DE PEQUENO PORTE DE DESENVOLVIMENTO DE
SOFTWARE”, é autêntico, original e de sua autoria exclusiva.
Curitiba, 09 de março de 2009.
DANIELE
MARTINS
FERNANDO
REZENDE
CELESTINO
JOÃO OSWALDO
MAZUR
MARCELO
STIVAL
WALTER RIBEIRO
DE OLIVEIRA JR
Dedicamos este trabalho a todos os que
nos acompanharam e apoiaram durante este MBA:
familiares, amigos, professores e colegas.
RESUMO
O desenvolvimento e aplicação de processos formais de gerenciamento de projetos é um
grande passo no aumento da probabilidade de sucesso dos projetos. As empresas têm buscado
aprimorar estes processos e adotar modelos de maturidade e suas recomendações de boas
práticas. O objetivo deste trabalho é apresentar uma forma de medição do nível de maturidade
de empresas de pequeno porte no processo de desenvolvimento de software e, a partir do nível
atingido, sugerir uma seleção de boas práticas. Com isto espera-se que haja aprimoramento
em seus processos de gerenciamento de projetos e melhoraria em seu grau de maturidade. O
modelo de maturidade utilizado como referência neste trabalho é o OPM3, proposto pelo
PMI.
Palavras Chave: gerenciamento de projetos, maturidade, OPM3, empresa de pequeno porte,
melhores práticas.
ABSTRACT
Development and application of formal process of project management is a great step forward
the increase of success probability in projects. Companies have searched for improving in
these processes and adopted maturity models and their good practices recommendations. The
goal of this study is to present one way to measure the maturity level of small size companies
in the software development process and, from the measured level, suggest a selection of best
practices. With this we hope that the company improves its project management process and
its maturity level. The adopted maturity model was the OPM3, proposed by the PMI.
Key Words: project management, maturity, OPM3, small size company, best practices.
AGRADECIMENTOS
Agradecemos a todo apoio e incentivo recebido da professora Denise Basgal durante a
elaboração dos trabalhos para apresentação nos fóruns e orientação dada para
elaboração deste trabalho de conclusão de curso.
Agradecemos a todos os professores que, ao longo de um ano e meio, transmitiram-nos
sua experiência em gerência de projetos.
Agradecemos às nossas empresas, por terem nos apoiado e estimulado a cursar este
MBA.
Agradecemos, por fim, a nossos familiares e amigos, que nos apoiaram durante todo o
2 FUNDAMENTAÇÃO TEÓRICA......................................................................................172.1 O QUE É MATURIDADE EM GERENCIAMENTO DE PROJETOS.........................................17
2.2 MODELOS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS...............................20
8 APÊNDICES.........................................................................................................................688.1 APÊNDICE I – LISTA DE PERGUNTAS....................................................................................68
8.2 APÊNDICE II – LISTA DE BOAS PRÁTICAS............................................................................88
8.3 APÊNDICE III – LISTA DE CORRESPONDÊNCIA ENTRE PERGUNTAS E BOAS
8.6 APÊNDICE VI: QUESTIONÁRIO RESPONDIDO PELA EMPRESA......................................165
9 APÊNDICES POR AUTOR INDIVIDUAL....................................................................1689.1 DANIELE MARTINS..................................................................................................................168
9.2 FERNANDO REZENDE CELESTINO.......................................................................................172
9.3 JOÃO OSWALDO MAZUR........................................................................................................181
FIGURA 1: DISTRIBUIÇÃO PERCENTUAL DO NÍVEL DE MATURIDADE...........18
FIGURA 2: NÍVEL DE MATURIDADE POR TIPO DE ORGANIZAÇÃO...................19
FIGURA 3: GRAU DE MATURIDADE POR CATEGORIA DE PROJETO.................19
FIGURA 4: GRAU DE MATURIDADE POR ÁREA DE ATUAÇÃO.............................20
FIGURA 5: NÍVEIS DE MATURIDADE NO MODELO PRADO-MMGP....................22
FIGURA 6: NÍVEIS DE MATURIDADE NO MODELO CMMI.....................................23
FIGURA 7: FLUXOGRAMA DO PROCESSO DE DECISÃO MAKE-OR-BUY..........61
15
1 INTRODUÇÃO
1.1 CONSIDERAÇÕES INICIAIS
O setor de tecnologia da informação (TI) tem sido um grande aliado das estratégias
das empresas através da apresentação de soluções tecnológicas de auxílio, acompanhamento e
análise tanto do desenvolvimento quanto da aplicação destas estratégias. Porém, ao mesmo
tempo em que se apresenta como aliado, tem sofrido uma grande pressão das altas gerências e
diretorias da empresa para que os projetos sejam desenvolvidos com a agilidade e
confiabilidade.
A TI, através de sistemas de softwares, se mostra como uma grande parceira em
diversas frentes, como na gestão da empresa através de softwares gerenciais, que integram
todos os dados e processos de uma organização, os chamados ERP (Enterprise Resource
Planning) ou SIGE (Sistemas Integrados de Gestão Empresarial); também no controle e
auxílio do relacionamento dos clientes, através do CRM (Customer Relationship
Management) ou GRC (Gestão de Relacionamento com o Cliente), ferramentas complexas
tidas como essenciais para a gestão e sobrevivência de uma empresa.
A TI também é uma grande parceira em outras frentes menos essenciais para o
funcionamento da empresa, porém muito importantes para a implantação das estratégias
necessárias a sua perpetuação. As empresas demandam diversos softwares para estas funções,
por exemplo podemos citar o BI (Business Intelligence), que auxilia no processo de coleta,
organização, análise, compartilhamento e monitoramento de informações que oferecem
suporte a gestão de negócios; ou os softwares para automação de força de vendas (AFV); as
soluções de controle de fluxo e aprovação de trabalho (workflow); até as ferramentas de
colaboração como email, intranet e extranet.
A Wasys, empresa que inspirou este trabalho, mantém seu foco comercial nesta
segunda frente, atuando como desenvolvedora e parceira do departamento de TI das
empresas, fornecendo consultoria, serviços e soluções de software. Neste contexto a Wasys
apresenta-se como uma empresa cujo core business é, essencialmente, baseado em projetos e,
assim, tem todas as implicações, necessidades e problemas que a gerência de projetos
apresenta.
16
No intuito de auxiliar no gerenciamento de projetos o presente trabalho apresenta
uma forma de medir e avaliar o nível de maturidade em gerenciamento de projeto. A partir do
nível atingido, é feita uma sugestão de boas práticas com o objetivo de aprimorar os processos
formais de gerenciamento projetos de software e, por consequência, tentar aprimorar o grau
de maturidade neste processo. O modelo de maturidade utilizado como referência neste
trabalho é o OPM3, proposto pelo PMI.
17
2 FUNDAMENTAÇÃO TEÓRICA
2.1 O QUE É MATURIDADE EM GERENCIAMENTO DE PROJETOS
O gerenciamento de projetos pode ser resumido como um processo que utiliza
conhecimentos, habilidades, ferramentas e técnicas junto às atividades do projeto com o
intuito de atingir os objetivos do mesmo e atender as suas demandas. Se conhecimento e
habilidades estão diretamente ligados às pessoas e as técnicas e ferramentas estão ligadas à
organização, tem-se por pressuposto que o gerenciamento de projetos exige esforço e
desenvolvimento corporativo e pessoal.
Apesar do gerenciamento de projetos depender muito das pessoas dentro da
organização, é a organização que deve promover a implantação ou aprimoramento do
processo de gerenciamento de projetos. A organização deve ser responsável pela seleção das
pessoas com as habilidades corretas, promover e difundir o conhecimento relacionado a
gerência de projetos e também escolher as técnicas e ferramentas que guiarão e auxiliaram
neste processo gerencial.
O grau de estruturação da organização no processo de gerenciamento de projetos é o
que denomina-se grau ou nível de maturidade organizacional em gerenciamento de projetos.
No mercado existem diversos modelos de maturidade, dentre os quais é possível destacar:
Organizational Project Management Maturity Model (OPM3) do PMI; o Kezner’s Project
Management Maturity Model (PMMM) do Dr. Kerzner; o Project Management Maturity
Model (PMMM) da PM Solutions; o PRINCE2 Maturity Model (P2MM); o Modelo Prado-
MMGP, criado por Darci Prado; e o Capability Maturity Model Integration (CMMI), voltado
para projetos de TI.
No ano de 2005, Darci Prado e Russel Archibald lançaram a 1ª Pesquisa Sobre
Maturidade em Gerenciamento de Projetos. A pesquisa, que foi realizada via Internet, teve
como objetivo tentar mapear a realidade das empresas brasileiras com relação à maturidade e
seus resultados habilitaram uma nova consciência e dimensão sobre o gerenciamento de
projetos no Brasil.
Em 2006 a pesquisa foi elaborada com 258 profissionais e seus resultados, que foram
classificados em algumas categorias, trazem importantes informações, conforme destacado a
seguir. A primeira classificação das informações é com relação ao grau de maturidade das
empresas que participaram da pesquisa. A maturidade média das organizações brasileiras que
18
responderam à pesquisa é de 2,42, um valor considerado médio-baixo. Na figura 1 temos o
gráfico de maturidade das organizações classificados em cinco níveis. Os níveis estão
explicados na tabela 1.
Figura 1: Distribuição percentual do nível de maturidade(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
Tabela 1: Categorias de Nível de Maturidade.
(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em
www.maturityresearch.com. Acesso em 26/11/2008)
Outra classificação que pode ser destacada é o nível de maturidade por tipo de
organização. A figura 2 mostra como se encontra esta situação.
19
Figura 2: Nível de Maturidade por Tipo de Organização(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
Ainda é possível classificar o grau de maturidade de acordo com as categorias de
projetos do modelo de Archibald. A figura 3 mostra esta classificação.
Figura 3: Grau de Maturidade por Categoria de Projeto.(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
Uma última e importante classificação é pelo ramo de atividade da empresa. Esta
classificação está na figura 4.
20
Figura 4: Grau de Maturidade por Área de Atuação(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
A partir destes dados é possível concluir que as organizações ainda possuem um
longo caminho rumo a uma maior maturidade em gerenciamento de projetos. Os resultados
desta pesquisa mostram que 65,5% das organizações participantes estão no nível 1 e 2, ou
seja, ainda não implantaram padrões, métodos, estruturas ou sistemas de gerenciamento de
projetos que possa trazer resultados aos seus negócios. E somente 9% das organizações estão
em níveis 4 e 5, onde o domínio do processo de gerenciamento de projetos é alcançado.
2.2 MODELOS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS
Os modelos de maturidade, além de mensurar o estágio da organização na habilidade
de gerenciar seus projetos, em geral permitem também classificar as empresas em categorias
de maturidade, possibilitando o benchmark entre empresas. E nestes modelos as empresas
podem formular seu planejamento estratégico de melhoria, pois a partir do conhecimento do
estágio atual é possível estabelecer um caminho para atingir outros níveis.
2.2.1 Modelo Prado - MMGP
Um modelo bastante difundido no mercado atual é o modelo Prado-MMGP,
publicado em 2002 e desenvolvido pelo professor Darci Prado, que permite avaliar e
classificar o grau de maturidade tanto setorial quanto da corporação. Tem bastante difusão no
21
mercado, principalmente por sua simplicidade, pois o questionário possui apenas 40 questões,
e também pela sua universalidade de aplicação em qualquer instituição e em todas categorias
de projetos. A partir da avaliação é possível classificar o grau de maturidade da organização
em cinco níveis possíveis: inicial, conhecido, padronizado, gerenciado e otimizado. Abaixo
segue a melhor descrição destes níveis:
Nível 1, ou “Inicial” (Ad hoc), está caracterizado pelo baixo nível de conhecimento
ou desconhecimento do assunto, a inexistência de metodologia e/ou modelos de
gerenciamento e o uso de intuição no gerenciamento dos projetos.
Nível 2, ou “Conhecido”, está caracterizado por investimentos em conhecimentos
(treinamento), início da criação de uma nova cultura, iniciativas dispersas e não padronizadas.
Nível 3, ou “Padronizado”, está caracterizado pelo início da existência de padrões,
mapeamento de processos, implementação de uma plataforma de governança (estrutura
organizacional), alinhamento estratégico, metodologias, informatização, competência e uso
rotineiro dos padrões pelos gerentes de projetos.
Nível 4, ou “Gerenciado”, é o nível onde padrões são utilizados, foram aperfeiçoados
e funcionam; as causas de erros comuns ou rotineiros identificadas e eliminadas; os
relacionamentos humanos são eficientes e existe uma alinhamento eficiente com negócios da
organização.
Nível 5, ou “Otimizado” , está caracterizado pela otimização de prazos, de custos, de
qualidade e dos processos de gerenciamento.
Os níveis foram escolhidos a partir das dimensões que afetam diretamente o sucesso
do gerenciamento dos projetos, sendo eles: conhecimentos de gerenciamento de projetos, uso
de metodologia, informatização, estrutura organizacional adequada, relacionamentos humanos
eficientes e alinhamento com os negócios da organização.
A figura 5 mostra um gráfico comparativo entre o nível de sucesso e o grau de
maturidade da empresa e em como as dimensões se ampliam à medida que a empresa se torna
mais madura.
22
Figura 5: Níveis de Maturidade no Modelo Prado-MMGP(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
2.2.2 Modelo CMMI
Outro modelo de maturidade com bastante penetração de mercado é O Capability
Maturity Model Integration for Software (CMMI). O CMMI é um modelo desenvolvido pelo
Software Engineering Institute (SEI) que busca orientar as organizações de software na
implementação de melhorias contínuas em seu processo de desenvolvimento. O CMM guarda
algumas semelhanças com o modelo Prado-MMGP e também possui cinco níveis de
maturidade. Cada um destes níveis apresenta fundamentos sucessivos para a melhoria
contínua do processo.
O nível 1, chamado de “inicial”, é caracterizado como o estado caótico. Neste nível a
chance de sucesso e a garantia de qualidade do produto dependem de esforços individuais sem
qualquer nível de gerenciamento ou controle definidos explicitamente.
No nível 2, chamado de “repetível”, já existem processos básicos de gerenciamento
de projeto que permitem o acompanhamento de custo, cronograma e funcionalidade. É
repetível através dos procedimentos em outros processos similares.
O nível 3, chamado de “definido”, é caracterizado principalmente pela existência de
um processo de engenharia de software definido, documentado e padronizado. As atividades e
23
os entregáveis ou artefatos do processo de desenvolvimento de software são conhecidos,
compreendidos e documentados.
No nível 4, chamado de “gerenciado”, além das melhorias já implementadas no nível
3 também existe a preocupação, controle e medição da qualidade do processo e do produto.
Tanto o processo de software quanto os produtos são quantitativamente compreendidos e
controlados.
No nível 5, chamado de “otimizado”, há uma melhoria contínua dos processos. Este
nível permite avaliar e escolher com segurança novas tecnologias, técnicas, políticas de
treinamento e qualquer outra atividade relevante do processo, sempre buscando como
resultado um de produto de melhor qualidade.
A Figura 6 mostra a evolução do processo de desenvolvimento de software à medida
que se eleva no nível de maturidade.
Figura 6: Níveis de Maturidade no Modelo CMMI(fonte: FAGUNDES, Eduardo Mayer. Capability Maturity Model for Software. Disponível em
http://www.efagundes.com/artigos/CMM.htm. Acesso em 28/11/2008.)
2.2.3 O OPM3
Em 2004, o Project Management Institute (PMI) lançou o seu modelo de maturidade
Organizational Project Management Maturity Model (OPM3). Este modelo foi desenvolvido
com o apoio de mais de 800 voluntários com experiência em gerenciamento de projetos, tendo
por base 27 modelos de maturidade, incluindo 10 específicos sobre maturidade organizacional
e 9 da área de tecnologia de informação, incluindo o modelo CMMI.
24
O modelo OPM3 visa criar uma estrutura de melhoria contínua do ambiente de
gestão de projetos das organizações. Este objetivo é buscado através da recomendação de
“Boas Práticas”’ alinhadas com o PMBoK1, aceitas e utilizadas por empresas. Assim o PMI,
através do modelo OPM3, busca orientar as organizações na melhoria da gestão de projetos,
recomendando investimentos em treinamentos, disponibilização de novas ferramentas e
sistemas de controle de projeto, padronização de processos e documentação, entre outras
recomendações.
Dois conceitos importantes estão associados dentro do OPM3: as Boas Práticas e
Capacidades, e ambos estão associados a dois outros fatores chaves. Um é relacionando a
domínios de abrangência, sobre os quais se desenvolvem as indicações e recomendações de
amadurecimento organizacional. Os domínios mencionados no modelo OPM3 referem-se a
Projetos, Programas e Portfólio. O outro é associados aos estágios de melhoria contínua de
processos: “Standardize” onde têm-se processos estabelecidos, “Measure”, onde têm-se os
processos aplicados e avaliados, “Control”, onde os processos são monitorados e controlados
e “Continuous Improve”, onde os processos são aprimorados.
Para a aplicação do modelo OPM3 a orientação é a sequência de três elementos
chave:
• Conhecimento dos componentes do modelo de maturidade;
• Questionário de Auto-Avaliação do estágio de maturidade da organização;
• Processo De Melhoria contínua.
O elemento inicial do OPM3 é o conhecimento dos elementos básicos que o compõe:
boas práticas geralmente aceitas e experimentadas; capacidades ou pré-requisitos associados a
cada uma das boas práticas; resultados que comprovam a existência de uma ou mais
capacidades; indicadores chave de desempenho (KPIs), que possibilitam medir os resultados
atingidos; caminhos e ligações lógicas que agregam capacidades às boas práticas.
A fase seguinte é da auto avaliação, constituído por um questionário de escolhas
através do qual o usuário analisa e responde sobre a presença ou ausências de processos
formais no gerenciamento de projetos. As respostas dos questionários definem uma lista de
Boas Práticas que seriam recomendadas à organização.
A última etapa é que a organização faça uma análise da lista de Boas Práticas
recomendadas e verifique sua viabilidade e faça a sua priorização, e então e estabeleça um
1Project Management Body of Knowledge
25
plano composto pela melhor sequência de ações de melhoria em busca da elevação do grau de
maturidade.
O ciclo de melhoria contínua é a execução do plano de ação e pela reavaliação
periódica. Desta forma a aplicação do modelo OPM3 tem por objetivo aprimoramento real
dos processos organizacionais relativos ao gerenciamento de projetos buscando resultados
mais adequados e previsíveis.
Diferentemente dos demais modelos de maturidade, onde existe uma categorização
dos níveis de maturidade, normalmente constituído de 5 níveis, no modelo OPM3 não existe
este conceito. A princípio isto seria um ponto negativo neste modelo pois dificulta o
entendimento, benchmarking e o estabelecimento de metas mensuráveis e compromissos para
a melhoria da maturidade organizacional. Ao mesmo tempo esta ausência de categorias evita
que o nível de maturidade seja simplificado em uma nota final, onde uma grande maturidade
em uma determinada área poderia elevar a média e esconder resultados ruins em outras áreas.
A aplicação adequada e a melhoria contínua, através do OPM3, podem trazer resultados muito
positivos à organização.
2.2.4 Outros modelos
Existem ainda outros modelos de maturidade, que serão apenas citados, como o
Kezner’s Project Management Maturity Model (PMMM) do Dr. Kerzner, o Project
Management Maturity Model (PMMM) da PM Solutions, o PRINCE2 Maturity Model
(P2MM).
26
3 METODOLOGIA CIENTÍFICA
3.1 CONSIDERAÇÕES INICIAIS
A empresa objeto de estudo deste trabalho deseja implementar um programa de
melhorias no processo de gerência de projetos, porém sem burocratizar em excesso ou a ponto
de diminuir sua eficiência.
A equipe que desenvolveu este trabalho buscou o estudo e seleção do melhor modelo
de maturidade a ser aplicado e utilizado pela empresa. Após a escolha do modelo de
maturidade o esforço resumiu-se na otimização do questionário de avaliação para determinar
qual o grau de maturidade da empresa, pois tão importante quanto chegar a algum lugar é
necessário saber onde se está. Em seguida foram feitas considerações sobre processos que a
empresa poderia adotar, conforme as respostas que a empresa forneceu no questionário, para
que pudesse aumentar o seu grau de maturidade em gerenciamento de projetos.
3.2 A EMPRESA
Fundada em 1995 a Wasys é uma empresa integradora de soluções de TI.
Desenvolve soluções personalizadas usando as boas práticas de desenvolvimento do mercado,
baseada em tecnologias e metodologias amplamente aceitas. Além disso, a Wasys tem
diversas parcerias estratégicas que visam a distribuição de produtos de software e hardware
necessários à infra-estrutura da solução. Dentre as parcerias de destaque podem-se citar a
IBM, Microsoft e Claro.
Nos treze anos de existência a empresa passou por diversas evoluções e melhorias na
gerência de seus projetos, principalmente buscando a qualificação de seus gerentes de projeto.
3.3 O CONTEXTO
A empresa é basicamente voltada para desenvolvimento de projetos de
desenvolvimento de software ou prestação de serviços de informática. Seus contratos com
clientes possuem as principais características de projetos: são temporários, possuindo um
início e um fim definidos; são planejados, executados e controlados; entregam produtos,
serviços ou resultados exclusivos. A empresa em análise encontra os desafios e problemas
encontrados em outras empresas na implantação e desenvolvimento de projetos.
27
Os projetos de tecnologia da informação, em função das constantes mudanças que o
ambiente de negócios impõe, somado aos constantes avanços e evoluções tecnológicos, têm
que apresentar soluções flexíveis e ágeis. Não existe outro setor que tenha se desenvolvido e
evoluído tanto e em um ritmo tão devastador quanto o de tecnologia (IEEE, 2001).
A empresa vem mudando a sua forma de desenvolvimento e condução dos projetos:
anteriormente vinha de uma metodologia empírica e experimental, agora tem adotado formas
de condução formais baseadas em histórico e também através das metodologias de
gerenciamento de software existentes no mercado. Os processos e metodologias que são
usados para gerenciar projetos são extremamente importantes para aumentar a probabilidade
de sucesso, apesar de haver consciência de seus diretores que isto, por si só, não garante o
sucesso.
3.4 O OBJETIVO
A empresa deseja implementar um programa de melhorias no processo de gerência
de projetos com um objetivo de aumento gradual e constante do grau de maturidade. A
empresa espera, através deste programa, desenvolver uma metodologia de gerência de
projetos que permita um maior controle e proporcione uma menor chance de insucessos nos
seus projetos.
A empresa já possui um processo de desenvolvimento de software documentado e
alinhado com os objetivos de qualidade da empresa, assim o foco de amadurecimento será
basicamente em gerenciamento de projetos.
Existe, porém, uma grande preocupação da empresa em não burocratizar demais os
processos a fim de não perder sua agilidade e também não causar mudanças culturais muito
profundas que venham a trazer problemas motivacionais para a equipe.
3.5 O CENÁRIO ALVO
Para a elaboração do estudo do processo de avaliação de formas de melhorar o grau
de maturidade da empresa é necessário saber a contextualização, ou seja, quais são as
características médias dos projetos desenvolvidos pela empresa.
Atualmente não existe um processo formal de gerenciamento de projetos, sua
condução é feita por procedimentos não padronizados, intuição e experiência. Existem três
gerentes de projetos, conhecedores do PMBoK, que estão na empresa há seis anos, o que
28
proporciona uma boa integração da equipe, além de estarem sintonizados com os objetivos da
empresa.
Durante o ano de 2008 foram desenvolvidos e entregues 33 projetos caracterizados
em desenvolvimento de novos softwares e melhorias de softwares já existentes. De todos os
projetos executados, nenhum estourou o orçamento e apenas dois projetos (6% do total)
tiveram que ter o prazo de entrega renegociado, sendo que um deles teve atrasos na entrega
devido a problemas com o próprio cliente.
Vale destacar que suporte a softwares e manutenções não previstos (e em geral
emergenciais) surgiram entre os projetos, impactando no andamento deles. O volume de
projetos é relativamente constante, seja pelo próprio mercado, seja por negociações com os
clientes, o que não tem gerado uma demanda sazonal ou temporária de contratação de novos
recursos ou colaboradores.
Todo os projetos tiveram características de pequeno porte, demonstráveis pela
métrica da metodologia de desenvolvimento de software Rational Unified Process (RUP),
onde todos limitaram-se em 1.200 Use Case Points ou 20 homens/mês de esforço total. Outra
característica dos projetos é a sua curta duração, entre 45 a 90 dias desde o início do
desenvolvimento até a sua entrega, sendo em geral desenvolvido por equipes de até 5 pessoas.
Desta forma, cada gerente de projeto coordenou três projetos paralelamente, em
média.
Um ponto de destaque dentro da empresa é a integração da equipe de
desenvolvimento, onde a denominação correta a ser utilizada é "time", pois é bastante
comprometida com os projetos que atuam e preocupados com a satisfação do cliente. A
equipe também não tem um problema de Turn Over.
3.6 A ESCOLHA DO MODELO DE MATURIDADE
A escolha do modelo de maturidade foi o Organizational Project Management
Maturity Model (OPM3), do PMI. A grande motivação da escolha foi o fato de ser um modelo
moderno, com grande alinhamento com o PMI e seu PMBoK, pois a empresa já iniciou o
treinamento e difusão do conhecimento do PMBoK entre os gerentes de projeto. Como a
empresa já possui um processo de desenvolvimento de software documentado e alinhado com
os objetivos de qualidade da empresa, a escolha de um modelo de maturidade específico para
a área de tecnologia, como o CMMI, foi descartado.
29
Sendo o objetivo principal da empresa melhorar o seu processo de gerenciamento de
software para se tornar mais eficiente e competitiva, não desejando, neste momento, fazer
comparações de benchmarking com outras empresas e também não deseja obter certificações
em modelos específicos de maturidade, o modelo OPM3 mostrou-se suficiente. O modelo
OPM3 permite obter uma auto-avaliação do grau de maturidade sem classificar em níveis pré-
determinados, e com uma avaliação de maturidade que pode ser elevada à medida que o plano
de melhoria é colocado em prática.
Além de fornecer notas no processo de auto-avaliação, o modelo OPM3, a partir das
respostas das perguntas, seleciona uma sugestão de boas práticas a serem adotadas pela
empresa, alinhadas com o PMI e com sua utilização e aceitação por organizações e gerentes
de projetos. Assim, o OPM3 mais uma vez mostrou-se bastante interessante, pois além da
avaliação fornece insumos básicos para se montar um plano de melhorias, de acordo com as
intenções da empresa.
3.7 A ADEQUAÇÃO DO MODELO OPM3
O modelo OPM3 possui aplicação para empresas de todos os portes, e não só para
projetos, mas também para programa e portfólio. Assim, para a aplicação em pequenas
empresas que desenvolvem projetos de curta duração e de pequeno porte, fez-se necessária
uma adequação do questionário e das sugestões de boas práticas.
O processo de adequação do OPM3 seguiu as seguintes linhas:
a) O foco da empresa é em projetos para empresas contratantes, por isso:
• Boas Práticas referentes a priorização de projetos foram retirados;
• Boas Práticas referentes a Gerenciamento de Programa e Portfólio, inter-
relacionamento entre projetos foram retirados.
b) A equipe de gerenciamento e desenvolvimento de projetos é praticamente fixa, havendo
pouca variação dos membros da equipe (turnover) com o início ou término de projetos, não
sendo a contratação ou montagem de equipe realizada a cada projeto, por isso:
• Boas Práticas referentes a desenvolvimento de equipes foram retirados;
• Boas Práticas referentes a contratação de equipe (Staff) foram omitidos;
• O conjunto de Boas Práticas de gerenciamento de RH foi simplificado.
c) A maioria dos projetos desenvolvidos é de curta duração (3-5 meses), com equipes de 3 a 7
pessoas, e de mesma natureza, havendo muitas características comuns entre os projetos. A
30
maioria do faturamento vem de um portfólio restrito de clientes, com os quais a empresa já
está adaptada (tecnicamente, metodologicamente e relacionalmente), por isso:
• Boas Práticas referentes a planejamento organizacional de projeto foram omitidos;
• O conjunto de Boas Práticas referentes a gerenciamento de comunicação foi
simplificado, focando na comunicação com o cliente, e menos na comunicação
interna;
• O conjunto de Boas Práticas para iniciação, gerenciamento de escopo, custo e tempo
foi simplificado;
• O conjunto de Boas Práticas para gerenciamento de riscos foi simplificado;
• O conjunto de Boas Práticas para definição e utilização de métricas para controle de
todos os processos foi simplificado.
d) A natureza dos projetos raramente demanda aquisições. No processo de aquisição, a
empresa quase sempre faz papel de fornecedora, por isso o conjunto de Boas Práticas
referentes a gerenciamento de aquisições foi simplificado.
e) Os processos de garantia e controle de qualidade, e formalização de entregas seguem um
mesmo padrão aplicado a quase a totalidade dos projetos, ou são definidos pelo próprio
cliente, caso o mesmo possua metodologia própria de desenvolvimento de sistemas, por
isso:
• o conjunto de Boas Práticas de gerenciamento de qualidade foi simplificado;
• o conjunto de Boas Práticas de verificação de escopo foi simplificado.
f) Os objetivos dos projetos se limitam a: lucratividade, conquista de novo mercado e
conquista de espaço em cliente. Por isso o conjunto de Boas Práticas referentes a definição
e acompanhamento de objetivos pelos stakeholders foram minimizados.
3.8 O MODELO SUGERIDO
O modelo OPM3 adequado à aplicação na empresa foi elaborado pelos autores do
presente trabalho. No apêndice I tem-se o questionário a ser aplicado na empresa, com as
perguntas selecionadas e adaptadas pelos autores a partir das perguntas encontradas no
OPM3. Para as perguntas devem ser fornecidas respostas conforme a frequência de ocorrência
da situação na empresa. A tabela 2 ilustra os pesos que foram atribuídos às frequências de
ocorrência na empresa.
31
Tabela 2: Relação de pesos versus utilização
Peso
Frequência de
verificação
0 Nunca
1 Raramente
2 Algumas vezes
3 Metade das vezes
4 Várias vezes
5 Sempre
Fonte: os próprios autores
Todas as perguntas foram relacionadas a áreas de conhecimento do PMBoK, sendo
que algumas das perguntas se referem à cultura organizacional da empresa ou a mais de uma
área de conhecimento. Para estas os autores indicaram um novo código, conforme
demonstrado na tabela 3.
Tabela 3: Relação das Áreas de Conhecimento
Área de
Conhecimento Descrição
4 Integração
5 Escopo
6 Tempo
7 Custo
8 Qualidade
9 RH
10 Comunicação
11 Riscos
12 Aquisições
99 Cultura da empresa – Várias
Fonte: os próprios autores
32
Também houve um relacionamento entre as perguntas e a seu estágio de melhoria
(conforme explicado no item 2.2.3 - O OPM3, páginas 23 e seguintes). Esta relação é
mostrada na tabela 4.
Tabela 4: Relação das Estágios
Estágios Descrição
1 Padronizar
2 Medir
3 Controlar
4 Aprimorar
5
Cultura da empresa –
Várias
Fonte: os próprios autores.
No apêndice II tem-se a lista de boas práticas, selecionadas pelos autores a partir das
boas práticas apresentadas pelo OPM3, com as respectivas áreas de conhecimento e estágio de
maturidade. No apêndice III tem-se a correspondência numérica entre as perguntas e as boas
práticas e no apêndice IV tem-se a lista de perguntas e as boas práticas correspondentes, de
uma forma mais descritiva.
Todo o processo de avaliação foi elaborado de uma forma estruturada, o que permite
que seja facilmente desenvolvido um software específico para aplicação do questionário do
presente trabalho, o que permitiria à empresa constantemente reaplicar esta auto-avaliação e
determinar qual progresso houve na evolução em seu grau de maturidade. O sistema também
poderá fornecer de forma mais simples e rápida (do que a consulta a tabelas impressas) quais
as boas práticas que deveriam ser implantadas na empresa.
33
4 ANÁLISE DOS RESULTADOS
4.1 CONSIDERAÇÕES INICIAIS
O formulário de questionário foi respondido em conjunto pelos três gerentes de
projetos da empresa, o que possibilitou uma maior veracidade e reflexo da visão de cada um
sobre seus projetos e sobre todos os projetos da empresa. No apêndice VI reproduzimos o
questionário respondido.
4.2 RESULTADOS
Os resultados obtidos demostraram que a empresa possui uma baixa maturidade em
gerenciamento de projetos, como já era esperado pelas informações fornecidas antes da
avaliação. Os resultados obtidos por área de conhecimento estão na tabela 5, onde é possível
verificar que existe uma relativa preocupação da empresa em algumas áreas de conhecimento.
A atenção principal da empresa ocorre nas áreas em que há um peso maior em projetos, como
escopo e tempo, porém faltam esforços em outras áreas importantes, como custos,
comunicação e riscos, que poderiam ser um diferencial competitivo no mercado.
Tabela 5: Resultados por Área de Conhecimento
Área de conhecimento Nota
Integração 21,67%
Escopo 23,33%
Tempo 29,09%
Custo 7,69%
Qualidade 12,50%
RH 0,00%
Comunicação 0,00%
Riscos 0,00%
Aquisições 11,43%
Estrutura da Empresa 27,73%
34
Média Geral 13,34%
Fonte: os próprios autores
Outra forma de interpretação dos resultados é separando por estágios de maturidade,
conforme demonstrado na Tabela 6. Verifica-se que a preocupação da empresa com seu grau
de maturidade é coerente, pois a formalização de processos é quase inexistente.
Tabela 6: Resultados dos Estágios de Maturidade
Resultado por domínio
Padronizar 0,83%
Medir 31,67%
Controlar 17,06%
Aprimorar 12,50%
Estrutura da Empresa 39,00%
Fonte: os autores
Os autores do presente trabalho destacam que os resultados mostrados nestas duas
tabelas comprovam que houve bastante coerência no trabalho feito. Os resultados por área de
conhecimento mostram que houve correspondência entre as informações que eram conhecidas
sobre a empresa e as respostas dadas ao questionário. Já as respostas dos estágios de
maturidade comprovaram que a empresa aplica apenas seus conhecimentos empíricos, mas
não possui formalidades em seus projetos, também conforme havia sido informado no perfil
da empresa.
Apesar do relativo sucesso nos projetos desenvolvidos por ela, vale destacar que ela
poderá se beneficiar com a adoção do modelo de maturidade aqui proposto, pois permitirá
avaliar e elaborar um plano estratégico para melhoria dos processos de gerenciamento de
projetos. Um processo de gerenciamento de projetos é uma garantia a mais da continuidade de
sucesso dos projetos, assim como um diferencial competitivo frente aos seus concorrentes.
35
4.3 DISCUSSÃO DOS RESULTADOS
Analisando os resultados obtidos a partir da aplicação do questionário, percebe-se
que a empresa possui diversos pontos onde é possível buscar um aumento de maturidade em
gerenciamento de projetos. Pelo sucesso obtido pela empresa ao longo destes anos de
existência, deduz-se que há um conhecimento sobre a condução de projetos, mas este
conhecimento está limitado à prática diária de tarefas. As melhorias que serão propostas a
seguir auxiliarão a empresa a documentar o conhecimento de toda a sua equipe facilitando a
difusão do conhecimento dos gerentes de projeto, fornecendo um histórico de referência para
consultas e análises, permitindo uma comparação entre os seus projetos e, por fim, permitindo
que a empresa delimite os seus pontos fracos e assim possa promover a sua correção.
As sugestões foram divididas conforme as áreas de conhecimento do PMBoK,
buscando-se abranger todos os estágios de maturidade.
4.3.1 Integração
Os processos de gerenciamento de integração, como o próprio nome diz, são os
responsáveis pela integração das demais áreas de conhecimento e os recursos envolvidos no
projeto. O PMBoK recomenda os seguintes processos na integração do gerenciamento de
projetos:
• Desenvolver o termo de abertura do projeto – desenvolvimento do termo de abertura
do projeto que autoriza formalmente um projeto ou uma fase do projeto.
• Desenvolver a declaração do escopo preliminar do projeto – desenvolvimento da
declaração do escopo preliminar do projeto que fornece uma descrição de alto nível do
escopo.
• Desenvolver o plano de gerenciamento do projeto – documentação das ações
necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares em
um plano de gerenciamento do projeto.
• Orientar e gerenciar a execução do projeto – execução do trabalho definido no plano
de gerenciamento do projeto para atingir os requisitos do projeto definidos na
declaração do escopo do projeto.
• Monitorar e controlar o trabalho do projeto – monitoramento e controle dos processos
usados para iniciar, planejar, executar e encerrar um projeto para atender aos objetivos
de desempenho definidos no plano de gerenciamento do projeto
36
Pela natureza dos negócios da empresa ela pode ser classificada como “Fábrica de
Software”, ou seja, o negócio principal é o desenvolvimento de projetos para clientes. Desta
forma o processo produtivo da empresa são os projetos e o desenvolvimento dos mesmos
exige apenas o envolvimento de membros do departamento de desenvolvimento, que
hierarquicamente estão sobre a mesma diretoria. Em geral os projetos são desenvolvidos por
pessoas focadas apenas no desenvolvimento do mesmo, ou seja, sem outras atividades
rotineiras ou atividades de outros projetos. Desta forma o trabalho do gerente de projetos (GP)
é simplificado nas atividades de gerenciamento de integração, possuindo uma equipe que, por
definição, estará comprometida com o projeto e também não exigindo do GP habilidades
políticas especiais ou necessidade de um Sponsor forte.
Uma das sugestões para a empresa, quanto a área de integração, é que haja um maior
cuidado com a iniciação dos projetos. A etapa de iniciação do projeto envolve atividades do
gerenciamento de integração, que seriam o desenvolvimento do Termo de Abertura do
Projeto, ou project charter, e a Declaração Preliminar do Escopo. Conforme explanado
anteriormente em relação a características dos projetos e da empresa, a recomendação é a
junção dos dois documentos e nominá-lo de Termo de Abertura do Projeto. A função deste
documento é a necessidade do registro formal do início do projeto, da alocação do gerente de
projetos, da equipe envolvida e do escopo preliminar. Recomenda-se que este documento seja
compartilhado com toda equipe envolvida, principalmente com o analista responsável, para
que todos estejam cientes do escopo macro do projeto. O modelo sugerido para este
documento encontra-se no item 8.5 (Error: Reference source not found: Error: Reference
source not found, pag. 144) e deve ser elaborado pelo gerente de projetos a partir das
informações contidas na proposta aceita pelo cliente, assim como informações fornecidas pelo
departamento comercial.
Uma segunda sugestão é que a empresa passe a adotar um plano de gerenciamento
do projeto. O plano de gerenciamento de projeto é o plano global com as instruções para o
gerente e equipe identificarem e formalizarem como desenvolver o produto do projeto. No seu
conteúdo estão as ações necessárias de definição e integração dos diversos planos de
gerenciamento das outras áreas de conhecimento. Também traz como o projeto deve ser
orientado e monitorado, assim como os processos de gerenciamento de mudanças. A
elaboração do plano é de responsabilidade do gerente do projeto, porém deve ser elaborada
em colaboração com os membros da equipe. Para isto podem ser utilizados com entradas os
37
seguintes documentos: Termo de Abertura do Projeto, Orçamento (Linha Base de Custos),
Cronograma (Linha Base de Tempo), e uma Linha Base de Escopo). Através da ligação das
etapas destes diversos documentos, poderá ser criado um Plano de gerenciamento do projeto.
O modelo de plano está descrito no item 8.5 (Error: Reference source not found: Error:
Reference source not found, pag. 145) e deverá ser utilizado pela organização.
Outra sugestão é que haja uma maior orientação dos Gerentes de Projeto da empresa
quanto aos papéis de orientação que são esperados. Mesmo sendo o perfil da empresa possuir
seus gerentes de projeto já familiarizados com as práticas do PMBoK, parece ser interessante
um treinamento sobre as suas responsabilidades enquanto orientadores. O processo de
desenvolvimento de software on demand, em geral, segue alguns passos ou etapas comuns a
todos os projetos, conforme a seguir: levantamento de requisitos, documentação dos
requisitos, análise do sistema a partir dos requisitos, desenvolvimento do sistema a partir da
análise, testes das funcionalidades e entrega do sistema. Para cada uma destas etapas o gerente
de projetos precisa efetuar a orientação da equipe no desenvolvimento das atividades.
Apesar do processo de orientação e controle do projeto depender muito das
características do gerente de projeto de pró-ação, liderança, capacidades, conhecimentos e
diversas outras, algumas orientações básicas são necessárias. Para sua execução precisam dos
seguintes documentos como entrada: Declaração preliminar do escopo, Orçamento (Linha
Base de Custos), Cronograma (Linha Base de Tempo), WBS e Dicionário (Linha Base de
Escopo). As orientações básicas que estão descritas abaixo são as mínimas necessárias:
• Orientação Inicial: para as primeiras atividades do projeto, ou seja, levantamento de
requisitos, apenas um analista ou desenvolvedor principal está envolvido. O gerente de
projeto fazer a orientação para deixar o responsável a par dos objetivos e
principalmente do escopo preliminar do projeto. Também são recomendadas as
orientações necessárias sobre as características do cliente.
• Orientação sobre os requisitos: nas atividades de documentação dos requisitos, análise
do sistema a partir dos requisitos, apenas um analista ou desenvolvedor principal está
envolvido. O gerente deve orientar o responsável para que verifique se os requisitos
levantados estão de acordo com o escopo preliminar e para que reporte todos os
pontos discordantes para que sejam efetuadas as ações necessárias para negociação de
escopo com o cliente.
38
• Orientação inicial da equipe: O gerente de projeto deve orientar toda a equipe de
desenvolvimento no início do processo de desenvolvimento. Esta orientação torna-se
necessária para deixar os responsáveis a par dos objetivos do projeto. Deve ser
dedicada atenção especial ao escopo e cronograma do projeto, destacando os papeis de
cada integrante, suas responsabilidades e os prazos e metas a cumprir.
• Orientação constante da equipe: O gerente de projeto deve orientar toda a equipe de
desenvolvimento durante o desenvolvimento do projeto. Este processo é necessário
para manter o foco da equipe nos objetivos do projeto e dentro do planejamento
inicial.
Quanto à execução do projeto, o gerente deverá executar diversas atividades no
transcorrer do desenvolvimento do projeto para garantir que o plano esteja sendo cumprido e
também que possa ter subsídios para tomar decisões necessárias para que os objetivos do
projeto sejam atingidos. As atividades de controle do projeto que devem ser executadas pelo
gerente de projetos são:
• Processo de aceite de Funcionalidades do Sistema: conforme descrito abaixo no item
de verificação de escopo (pag. 43), o gerente de projeto deve ser responsável pelo
controle do aceite dos entregáveis junto ao cliente.
• Controles dos Processos de Planejamento, Definição e Verificação de Escopo:
conforme descrito abaixo no item de verificação de escopo (pag. 43), o gerente de
projeto deve ser responsável pelo controle do escopo e das atividades executadas pela
equipe.
• Processos de controle de custos: conforme descrito no item 4.3.4, no Error: Reference
source not found (pag. 48) o gerente de projeto deve coletar as informações de
progresso do projeto e efetuar os cálculos do EVA e dos relatórios de desempenho.
• Processos de controle do cronograma: conforme será mencionado no item 4.3.3
(Tempo, pág. 45), a empresa possui já um certo controle sobre o tempo de suas
atividades, sendo necessário pequenos ajustes apenas para que haja informações
históricas adequadas para consultas durante a elaboração de novos projetos;
• Processos de controle da qualidade: serão explicados adiante, no item 4.3.5,
Qualidade, pag. 51;
• Processos de controle dos riscos: conforme será explicado no item 4.3.8 (Riscos, pag.
58), a empresa não possui qualquer controle de riscos, sendo uma grande oportunidade
39
de ganhos de competitividade se um mínimo de processo de gerenciamento de riscos
for implantado;
• Processos de controle integrado de mudanças: conforme será descrito abaixo, o
gerente de projeto deve receber, documentar, analisar e repassar todas as solicitações
de mudanças efetuadas.
• Processos de encerramento do projeto: conforme será descrito abaixo (pag. 40), o
gerente de projeto deve ser responsável por todas atividades de controle da
formalização do encerramento do projeto, liberação de recursos, encerramento do
projeto e documentação das lições aprendidas.
Há também recomendação que o Gerente de Projetos tenha um cuidado especial com
o controle de mudanças. As mudanças do projeto são uma certeza durante a execução do
mesmo e que podem ocorrer por diversos fatores desde a adequação a novas necessidades até
o desconhecimento de todas das necessidades pelo cliente. As mudanças, dependendo da
natureza, podem incorrer em replanejamentos ou retrabalhos. Em projetos de software existe
ainda o agravante da intangibilidade, ou seja, não é algo material ou palpável e novas
necessidades são descobertas após a entrega da primeira versão ou release do sistema. As
mudanças podem surgir ainda de defeitos ou discrepâncias encontradas durante execução do
projeto, na etapa de testes ou homologação do sistema. Todas as mudanças solicitadas devem
ser registradas e documentadas, sejam elas executadas ou não, a fim de que não ocorra uma
nova análise em caso de uma nova solicitação para a mesma mudança. O processo de controle
de mudanças está abaixo descrito. Para um controle de mudanças que seja fácil de
implementar na empresa, sugere-se que sejam utilizados os seguintes documentos como
entrada: Plano de gerenciamento de projeto, Mudanças solicitadas, Informações sobre o
desempenho do trabalho, Reparos recomendados de defeitos, Entregas devidas.
Um procedimento possível para controle de mudanças é o seguinte:
1. Analisar a viabilidade da mudança. Verificar se a solicitação da mudança é procedente
e é viável de ser executada, pois podem haver impedimentos técnicos. Caso não seja
viável o processo de avaliação finaliza. Deve-se envolver a equipe técnica na
avaliação;
2. Analisar a necessidade e justificativa da mudança. Caso a alteração seja viável é
necessário avaliar se ela é necessária e justificável. Solicitações que provocam
alterações nos objetivos do processo devem ser analisadas com cuidado. Caso não seja
40
necessária e nem justificável o processo de avaliação finaliza. Deve-se envolver o
cliente na avaliação, se necessário.
3. Avaliar o impacto. Caso a alteração seja necessária e justificável é necessário avaliar
os impactos que esta alteração provocará inicialmente no escopo, custo e tempo do
projeto. Deve ser também analisado com atenção para os impactos nos riscos do
projeto, pois podem introduzir novos riscos, assim como aumentar a probabilidade e
impacto dos já existentes.
4. Documentar e repassar a análise e impactos ao cliente. Após fazer a análise e ter em
mãos os impactos das alterações é necessário repassá-las ao cliente para sua
apreciação e aprovação ou não. Todas as mudanças aprovadas precisam ter um aceite
formal do cliente.
5. Alterar os planos do projeto. Com a aprovação pelo cliente é necessário alterar os
planos do projeto e repassar as alterações para a equipe e responsáveis.
Com este controle, haverão as seguintes saídas:
• Solicitações de mudanças aprovadas e rejeitadas. As solicitações de mudanças devem
utilizar o modelo descrito no item 8.5 (Error: Reference source not found: Error:
Reference source not found, pag.146);
• Plano de gerenciamento do projeto atualizado;
• Reparo do defeito validado
Por fim, há recomendação que a empresa formalize também os procedimentos para
encerramento de projetos. O processo de encerramento do projeto é necessário para formalizar
que o projeto foi executado a contento sendo necessário liberar recursos alocados e finalizar
contratos. Em caso de projetos desenvolvidos em fases, o processo de encerramento deve
ocorrer a cada fase finalizada. O processo de encerramento do projeto ainda precisa contar
com o aceite formal do cliente da entrega do projeto ou fase do projeto. Uma sugestão para
sua execução é a seguinte:
1. Finalizar todos os itens do sistema após todas as melhorias e alterações solicitadas na
fase de homologação. Fechar versão do sistema e atualizar documentação de análise;
2. Receber o aceite formal da finalização da homologação e início da garantia. Seguir o
processo recomendado pelo Sistema da Qualidade;
3. Encerrar contratos com terceiros. Seguir o processo recomendado pelo Sistema da
Qualidade;
41
4. Registrar as lições aprendidas. Desta forma, além de haver encerramento formal de
todos os contratos, haverá um documento de lições aprendidas. Os registros de lições
aprendidas devem utilizar o modelo descrito no item 8.5 (Error: Reference source not
found: Error: Reference source not found, pag. 148).
No apêndice V são colocados modelos de documentos para as sugestões apresentadas
para o controle de integração.
4.3.2 Escopo
Na área de escopo observa-se que a empresa, embora utilize um processo consistente
para planejar o escopo, não possui um processo padronizado para sua definição. Isto
provavelmente leva a dificuldades em monitorar e controlar os processos referentes a escopo,
mapear objetivos do projeto para os itens do escopo, identificar oportunidades de melhoria e
implementá-las.
Padronizando o processo de definição de escopo, e estabelecendo indicadores e
atividades de controle fundamentadas nesta definição, a empresa poderá ter um salto
qualitativo considerável na sua maturidade referente a esta área de conhecimento.
Como os projetos em questão são de software, grande parte do escopo do projeto
consiste nos seus requisitos de software. Esse aspecto deve ser levado em consideração para
devidamente interligar as boas práticas recomendadas do PMBoK com a realidade de um
processo de engenharia de software.
A primeira sugestão é que a empresa possua um processo de planejamento e
definição do escopo do projeto. Para isto a empresa poderá usar, como insumo, o Project
Charter, onde o escopo preliminar do projeto estará descrito, com as características do
produto, restrições e necessidades específicas da organização e do cliente. Os seguintes passos
podem ser usados neste processo:
1. Criar WBS e dicionário inicial, contemplando o que está especificado no Project
Charter (inclusive a visão básica do produto a desenvolver) mais os artefatos de
gerenciamento conforme metodologia vigente na empresa. Recomenda-se utilização
da forma gráfica da WBS, pois possibilita melhor visualização e entendimento. Para
geração da WBS, pode-se utilizar uma ferramenta de apoio, como o WBS Chart Pro,
da Critical Tools Corporation, ou o Microsoft Visio;
42
2. Realizar sucessivas reuniões entre os Analistas e o cliente, segundo a técnica FAST
(Facilitated Application Specification Techniques), na qual os requisitos serão
solicitados e documentados em formato rascunho em uma série de cenários;
3. Tendo como entrada os cenários documentados nas reuniões FAST, os analistas
traduzem o entendimento dos mesmos através de um conjunto de use cases, conforme
padrão UML, subordinando os cenários a um ou mais use cases definidos em uma
iteração anterior, ou definindo novos use cases. A documentação de use cases é feita
conforme template já em uso pela empresa. Neste processo podem ser identificados
outros itens não previstos no escopo geral do projeto (fora o escopo do produto), como
riscos, necessidade de treinamento, aquisições, testes diferenciados, entre outros;
4. Realiza os passos 2 e 3 em iterações até que a lista de use cases e seus detalhamentos
possibilitem:
• Que o cliente visualize nos use cases todas as funcionalidades que espera do
sistema;
• Que os Analistas estimem o esforço para desenvolvimento das funcionalidades,
provendo entradas para os planejamentos de tempo, custo, RH e outros;
5. Atualizar a WBS com o resultado do levantamento de requisitos, incluindo o escopo
do produto e outros itens do escopo do projeto que tenham sido identificados. O
dicionário da WBS deve ser atualizado, e os pacotes de trabalho referentes aos use
cases devem fazer apontamentos para os documentos de use case correspondentes.
Caso necessário, itens de arquitetura de software adicional devem ser especificados
como pacotes de trabalho abaixo dos respectivos use cases.
6. Especificar os casos de teste de aceitação para cada use cases, os quais servirão como
critério de aceitação dos mesmos. Os casos de teste podem ser divididos em casos de
teste funcionais e casos de teste operacionais, sendo estes últimos para testes de
performance, segurança, estabilidade, entre outros critérios, conforme a complexidade
e criticidade do software;
7. Obter do cliente a formalização do aceite da definição do escopo. Nesta formalização,
o cliente concorda que a WBS, o dicionário e os documentos de use cases representam
todas as funcionalidades desejadas do sistema a ser construído e todas os entregáveis
do projeto como um todo, e que alterações neste escopo estarão sujeitas às regras
43
definidas no controle integrado de mudanças. Neste aceite, o cliente deve formalizar
estar de acordo também com os critérios de aceitação dos entregáveis.
Seguindo-se estes passos, serão produzidos os seguintes documentos: WBS,
dicionário da WBS, documentação de Use Cases, documentação de casos de teste e aceite
formal do cliente (consistente da assinatura dos entregáveis previamente listados).
Uma segunda sugestão é que a empresa formalize o processo de verificação do
escopo. Para isto utilizará os documentos gerados pelo processo de planejamento e definição
do escopo e seguirá os seguintes passos:
1. A equipe libera o sistema (ou parte dele) para que cliente realize os testes definidos na
documentação de casos de teste para o(s) use case(s) em questão;
2. O cliente realiza os testes conforme documentação, reportando irregularidades
encontradas com relação à documentação de casos de teste ou à documentação de
requisitos (use cases);
3. Os defeitos encontrados são contabilizados e reportados para a equipe;
4. A equipe realiza as correções aplicáveis e libera novamente o sistema para testes do
cliente;
5. Os passos 2, 3 e 4 são repetidos até que todos os casos de teste tenham sido testados
com sucesso pelo cliente;
6. Caso o cliente, ao realizar os testes, verifique que o comportamento especificado não
atende suas expectativas, deve solicitar as alterações desejadas através de um change
request (conforme descrito acima, na recomendação de controle de mudanças, pag.
39);
7. Encerrados os testes com sucesso, o cliente deve assinar um formulário de aceitação
para o(s) use case(s) alvo do teste.
Para outros entregáveisa empresa poderá adotar os seguintes passos:
1. A equipe libera o entregável para inspeção do cliente;
2. O cliente realiza inspeção conforme definido pelo item de critérios de aceitação
descrito no dicionário da WBS;
3. Os defeitos encontrados são contabilizados e reportados para a equipe;
4. A equipe realiza as correções aplicáveis e libera novamente o entregável para inspeção
do cliente;
44
5. Os passos 2, 3 e 4 são repetidos até que os critérios de aceitação tenham sido
atendidos, conforme entendimento comum entre cliente e equipe de projeto;
6. Caso o cliente, ao realizar a inspeção, verifique que o entregável, mesmo atendendo
aos critérios pré-definidos, não atende suas expectativas, deve solicitar as alterações
desejadas através de um change request (vide o processo de controle integrado de
mudanças comentado acima, pag. 39);
7. Encerradas as inspeções, o cliente deve assinar um formulário de aceitação para os
entregáveis em questão.
Desta forma serão obtidos os seguintes itens: formulário de aceite assinado pelo
cliente para os itens verificados / testados e change request.
Sugere-se, com base nestes dois processos, que a empresa adote as seguintes
métricas para acompanhamento de seus projetos:
• Percentual de esforço gasto nestas fases com relação ao esforço total do projeto: a
partir da estimativa inicial de esforço do projeto, utilizada para fechar o contrato com
o cliente (o que é feito antes da etapa de planejamento detalhado), pode-se determinar
qual a porcentagem de tempo ou esforço/custo que está sendo gasto com os referidos
processos, comparado com o esforço/tempo total do projeto. Isso possibilitará a
criação de uma base histórica que possibilitará estimativas mais realistas para estas
atividades em projetos futuros. Também possibilitará saber se um projeto está
gastando mais tempo que o normal com algum destes processos, possivelmente
trazendo a tona um problema de projeto que sem esta medição ficaria oculto por mais
tempo, podendo gerar mais prejuízos;
• Relação da Quantidade de Change Requests com o total de Use Case Points
(Complexidade/Tamanho) do Projeto: a medição periódica deste indicador também
possibilitará a geração de histórico e a identificação precoce de problemas,
comparando-se o mesmo com o histórico existente. Além disso, um valor alto para
este indicador apontará prováveis problemas com o processo de definição do escopo;
• Relação da Quantidade de Erros encontrados ao executar os test cases com o total de
Use Case Points (Complexidade/Tamanho) do Projeto: um valor alto deste indicador
apontará prováveis problemas com os processos de controle e garantia de qualidade,
ou ainda do processo de planejamento da verificação do escopo.
45
Como última recomendação desta área, sugere-se que o controle dos processos de
planejamento, definição e verificação de escopo atentem aos seguintes itens:
• Obtenção de aceite formal do cliente para a definição do escopo do projeto antes do
início das atividades de design e construção. Antes deste aceite, todos os documentos
são assinados pelo analista responsável, o qual deverá garantir a consistência dos
mesmos antes de disponibilizar para o cliente; e
• Verificação quinzenal dos indicadores relacionados nas métricas acima.
No apendice V são colocados modelos de documentos para as sugestões apresentadas
para o controle de escopo.
4.3.3 Tempo
Na área de tempo verifica-se que a empresa possui um bom atendimento aos prazos
acordados com os clientes, conforme informações obtidas pelo levantamento do cenário de
empresa. Há ausência, entretanto, de alguns outros controles que poderiam auxiliar a empresa
na execução de seus projetos:
• ausência de métricas para o controle de tempo;
• não há um controle sobre a execução do planejamento executado;
• possui controle de mudanças de calendário, mas não o aplica durante os projetos;
• não há controle sobre os impactos que os riscos poderão gerar no cronograma de
atividades;
• não há histório que permita comparar o que foi planejado com o que foi efetivamente
executado.
Uma primeira sugestão para a empresa é que ela passe a adotar métricas para o
controle da duração das atividades e, assim, possa verificar o andamento de seus projetos e
fazer estimativas sobre suas próximas atividades. Como será explicado em um item seguinte
(item 4.3.4, no Error: Reference source not found, pag. 48) o uso do earned value analysis
(EVA) poderá auxiliar a empresa a controlar seus cronogramas ao mesmo tempo que controla
seus custos.
Outra recomendação é que a empresa implemente efetivamente o seu controle de
mudanças de calendário. Certamente o impacto da implementação desta atividade será
pequeno, já que a empresa trabalha sempre com equipes pequenas e projetos de curta duração.
Os ganhos serão bastante visíveis, entretanto, quando esta prática evitar que o fato de um
46
analista responsável por um determinado projeto apresentar algum contratempo (ou mesmo
deixar a empresa) e descobrir-se que o cronograma que está documentado não corresponde à
realidade do projeto, muito menos ao que foi re-negociado com o cliente.
O questionário também mostrou que não há preocupação da empresa com a análise
dos riscos passíveis de ocorrência no projeto. Como estes riscos poderão, eventualmente,
impactar em cronograma, sugere-se que a empresa atente para as recomendações que serão
feitas no item de riscos (item 4.3.8, Riscos, pag. 58) para que assim seus cronogramas
possuam a flexibilidade de absorver o impacto de riscos negativos que venham a ocorrer sem
que o andamento do projeto seja afetado de maneira intensa.
Por fim, sugere-se que a empresa elabore um histórico de desempenho de projetos
em relação ao tempo gasto em cada pacote de trabalho, armazenando-os em uma planilha de
dados. A consulta a este histórico será bastante útil para as estimativas de prazos feitas para
novos projetos, já que a quantidade de projetos que a empresa elabora a cada ano (e a
informação que há uma certa fidelização dos clientes) indica que muitos projetos poderão ter
atividades em comum.
Desta forma a empresa poderá, após a manutenção de seu histórico, verificar quais
são as atividades que mais consomem tempo em seus projetos, podendo tomar medidas que
diminuam estes prazos. Sendo feito um controle consistente a empresa evitará ter que
depender exclusivamente da experiência de seus funcionários. Poderá, também, promover
treinamentos nas atividades que se mostrarem mais deficientes, ou mesmo comparar os
funcionários entre si para que o profissional com o perfil mais adequado seja incumbido de
realizar as tarefas onde sua performance é melhor.
Não há necessidade de elaboração de documentos específicos para esta área de
conhecimento, além dos que já são utilizados pela empresa. Quanto aos softwares que a
empresa utiliza, o simples acréscimo da coluna "actual duration" no Microsoft Project será
suficiente para um controle inicial do tempo realmente despendido com as tarefas dos
projetos.
4.3.4 Custo
Na área de custos, observa-se bastante foco nos resultados, mas pouca ou nenhuma
padronização de processos para estimativa, monitoramento e controle de custos e de progresso
do projeto durante sua execução. A adoção de um processos baseado em boas práticas do
47
PMBoK para padronizar a orçamento, controle de custos e monitoramento de progresso, e o
conseqüente aumento de maturidade, poderia trazer melhoria na otimização do uso de
recursos humanos, maior previsibilidade financeira e, consequentemente, maior segurança nas
decisões sobre aplicação dos recursos financeiros, resultando em maior lucratividade.
A empresa em estudo, bem como outras do seu perfil, se caracteriza por produção e
fornecimento contínuo de diversos projetos de software de curta duração. Em função disso, os
custos abaixo, e similares, não serão considerados como custos de projeto, mas sim como
custo fixo da própria empresa, para manter sua atividade:
• Instalações físicas, luz, água, telefone e serviço de acesso à internet;
• Estações de trabalho e computadores dos desenvolvedores;
• Servidores internos de desenvolvimento.
Os custos dos projetos consistem basicamente na alocação de tempo dos Gerentes de
Projeto, Analistas de Sistema e Desenvolvedores na execução das atividades do projeto.
Portanto, o foco dentro dos projetos será dado para planejar, estimar e controlar estes custos,
referentes ao esforço de trabalho, baseada no tempo estimado para execução das atividades e
perfil de profissional alocado (GP, Analista, Programador), cada qual com seu respectivo
valor por hora trabalhada.
A primeira sugestão é que haja um processo de planejamento e estimativa de custos
do projeto. São utilizados os seguintes itens como entrada: lista de atividades, alocação de
atividades para perfil de profissional, valor hora para cada perfil profissional e cronograma
detalhado. Recomenda-se que a empresa adote os seguintes passos:
1. Criar plano de gerenciamento de custos conforme modelo padrão;
2. Com base na lista de atividades, alocação e valor/hora, calcular o custo de cada
atividade;
3. Com base no cronograma detalhado e nos custos por atividade, determinar a
distribuição dos custos no tempo dentro do projeto. Com isso obtém-se a linha base de
custos, possibilitando o seu controle no decorrer do projeto;
4. Documentar e Formalizar o Orçamento do Projeto internamente, e verificar desvios
com relação ao valor negociado com o cliente;
5. Caso haja desvios significativos, verificar necessidade de change request ou re-
negociação com o cliente.
48
Assim serão obtidos os seguintes documentos formais: orçamento e linha base de
custos.
Uma segunda sugestão é que a empresa adote um processo de controle de custos do
projeto. Os seguintes itens são necessários como entrada deste processo: orçamento (linha
base de custos), cronograma (linha base de tempo), WBS e Dicionário (linha base de escopo)
e informações coletadas sobre andamento das atividades. Os passos a serem seguidos pela
empresa, que deverão ser repetidos periodicamente, em intervalos definidos conforme o
tamanho e a criticidade do projeto, são os seguintes:
1. Gerente de Projeto coleta informações sobre o andamento das atividades já iniciadas e
não concluídas. Para isso, gera uma tabela conforme documentos sugeridos no
apêndice V (item 8.5.3, Error: Reference source not found, pag.154 e Error: Reference
source not found, pag. 155), a partir do sistema de controle de atividades, e preenche
os estimados para completar o projeto (estimate to complete the project - ETC´s) com
base em informação obtida com os recursos responsáveis por cada atividade;
2. O Gerente de Projeto insere as informações coletadas no sistema de controle
atividades (por exemplo, no Microsoft Project);
3. O Gerente de Projeto utiliza o sistema de controle de atividades para gerar os valores
dos indicadores descritos abaixo, do earned value analysis (EVA), e transcreve os
mesmos em relatório de progresso conforme os indicadores EVA mostrados na Error:
Reference source not found;
4. O Gerente de Projeto analisa os indicadores para identificar possível necessidade de
ações corretivas ou change requests;
5. O Gerente de Projeto dá início a ações corretivas ou change requests, quando
aplicável. Um Change Request, quando aprovado, deverá gerar alteração na linha base
de custos e, provavelmente, nas linhas base de tempo e escopo.
Tabela 7: Indicadores EVA.
49
50
Fonte: os próprios autores
Deste processo serão gerados os seguintes itens: relatório de progresso de custos,
change requests, ações corretivas e linha base de custos atualizada.
Por fim, sugere-se que a empresa adote as seguintes métricas para os processos de
custos:
51
• Percentual de esforço gasto nestas fases com relação ao esforço total do projeto: a
partir da estimativa inicial de esforço do projeto, utilizada para fechar o contrato com
o cliente (o que é feito antes da etapa de planejamento detalhado), pode-se determinar
qual o porcentual de tempo ou esforço/custo está sendo gasto com os referidos
processos, comparado com o esforço/tempo total do projeto. Isso possibilitará a
criação de uma base histórica que possibilitará estimativas mais realistas para estas
atividades em projetos futuros. Também possibilitará saber se um projeto está
gastando mais tempo que o normal com algum destes processos, possivelmente
trazendo a tona um problema de projeto que sem esta medição ficaria oculto por mais
tempo, podendo gerar mais prejuízos;
• Indicadores do EVA: a medição periódica destes indicadores também possibilitará a
geração de histórico, e a identificação precoce de problemas, comparando-se o mesmo
com o histórico existente. Além disso, poderá apontar prováveis problemas com o
processo de estimativa de tempo (e consequentemente de custos) para as atividades, ou
na própria execução das mesmas.
Recomenda-se que a empresa verifique estes indicadores quinzenalmente.
No apendice V são colocados modelos de documentos para as sugestões apresentadas
para o controle de escopo.
4.3.5 Qualidade
Analisando-se os resultados obtidos relacionados às questões de qualidade e de
estrutura da empresa, observou-se que as ações que resultam na qualidade dos serviços desta
têm como origem atitudes individuais de seus profissionais, não existindo um processo
institucionalizado.
Esta é uma excelente oportunidade para aprimorar ainda mais os serviços
desenvolvidos nesta empresa através da canalização dos esforços individuais em prol da
adoção de um sistema de gestão da qualidade que padronize processos objetivando a
constante busca pela qualidade e a melhoria contínua.
Segundo Marshall et al, 20072:"a padronização é de fundamental importância para as organizações. (...) Mas não basta padronizar processos, métodos, peças e componentes. É preciso melhorá-los continuamente. (...) A padronização também é importante para
2 MARSHALL Jr, I.; et al. Gestão da Qualidade. Rio de Janeiro: Editora FGV, 2007 – p. 83 - 84
52
permitir a análise crítica e a consequente melhoria dos procedimentos e métodos da empresa, pois propicia uma perspectiva concreta do que analisar e melhorar."
Como a empresa deseja implementar um programa de melhorias no processo de
gerência de seus projetos sem burocratizar em excesso e como seus profissionais possuem a
cultura de buscar a qualidade em suas atividades, sugere-se implementar um processo de
padronização partindo da forma como as atividades estão sendo desenvolvidas atualmente.
Neste sentido as idéias de Edwards Deming, um dos principais responsáveis pelo
movimento da qualidade no Japão, podem servir de base para a estruturação em questão.
Deming define a qualidade de acordo com as exigências e necessidades do consumidor e
como este está em permanente mudança, os processos em prol da qualidade devem ser
constantemente avaliados e adaptados sendo necessária a adoção de métodos gerenciais que
promovam estes processos.
O Ciclo PDCA ou Ciclo de Deming é um método gerencial para a promoção da
melhoria contínua introduzido no Japão após a guerra. Foi idealizado por Shewhart, na década
de 20, e divulgado por Deming, em 1950. Este ciclo adequa-se às necessidades da empresa
em estudo por ser um método amplamente aplicado para o controle eficaz e confiável das
atividades de uma organização que possibilita a padronização de processos e que, ao tornar as
informações mais entendíveis, diminui a probabilidade de erros nas análises.
Tal ciclo tem por princípio tornar mais claros e ágeis os processos envolvidos na
execução da gestão dividindo-a em quatro principais passos que formam a sigla PDCA
("Plan", planejar; “Do”, fazer ou agir; “Check”, checar ou verificar; “Action”, no sentido de
corrigir ou agir de forma corretiva).
O primeiro passo para a aplicação do PDCA é o estabelecimento de um plano de
ação (disponível no apêndice V, item 8.5.4, Error: Reference source not found, pag.156) que,
neste caso, deverá ser estabelecido com base nas diretrizes ou políticas da empresa e em
informações coletadas através de Brainstorming com os profissionais da empresa. Neste passo
destaca-se o estabelecimento dos objetivos e, com base nos objetivos selecionados, deve ser
feita a escolha do método a ser utilizado para que os objetivos sejam atingidos.
O segundo passo do PDCA é a execução do plano, a implementação do planejamento
realizado e a coleta de dados, ao longo da execução do plano, que serão verificados na
próxima fase. Tais dados devem ser armazenados na planilha de acompanhamento (disponível
no apêndice V, item 8.5.4, Error: Reference source not found, pag. 157).
53
O terceiro passo do PDCA é a análise dos resultados alcançados verificando se o
planejado foi alcançado através da comparação entre as metas estipulados e os resultados
obtidos. Esta análise poderá ser realizada através do Gráfico de Pareto, o que facilita a
priorização, e do Diagrama de Causa e Efeito.
A última fase do PDCA é a realização das ações corretivas, ou seja, a correção das
falhas encontradas no passo anterior e a adoção do que foi planejado e obteve sucesso como
padrão. Depois de realizada a investigação das causas das falhas ou desvios no processo,
deve-se repetir ou aplicar o ciclo PDCA para corrigir as falhas de forma a melhorar cada vez
mais o sistema e o método de trabalho.
A cada giro do Ciclo do PDCA, instala-se uma maior previsibilidade nos processos e
um consequente aumento da competitividade organizacional. Segundo Marshall et al, 20073:
“a previsibilidade acontece pela obediência aos padrões, pois, quando a melhoria é bem-
sucedida, adota-se o método planejado, padronizando-o; caso contrário, volta-se ao padrão
anterior e recomeça-se a girar o PDCA.”
No apendice V são colocados modelos de documentos para as sugestões apresentadas
para o controle de qualidade.
4.3.6 Recursos Humanos
Pelos dados fornecidos pela empresa e confirmados através dos resultados obtidos a
partir da aplicação do questionário, verifica-se que a empresa não possui um controle
arpimorado de Recursos Humanos.
A primeira sugestão, então, é que a empresa desenvolva um plano de cargos e
salários. Um cargo constitui uma unidade da organização e consiste em um conjunto de
deveres e responsabilidades que o tornam separado e distinto dos demais cargos. Na realidade,
os cargos constituem os meios através dos quais a empresa aloca e utiliza os seus recursos
humanos para alcançar objetivos organizacionais por meio de determinadas estratégias. Na
outra ponta, os cargos constituem os meios através dos quais as pessoas excutam as suas
tarefas dentro da organização para alcançar determinados objetivos individuais. Em resumo,
os cargos representam a pedra de toque entre a organização e as pessoas que nela trabalham.
A empresa Wasys poderia formalizar a existência de seus 4 principais cargos:
• Desenvolvedor: desenvolve o sistema em nivel de operação de software;
3 MARSHALL Jr, I.; et al. Gestão da Qualidade. Rio de Janeiro: Editora FGV, 2007 – p. 89 - 90
54
• Analista: analisa os requisitos do cliente e transforma em artefatos que auxiliam o
desenvolvedor e tambem documentam o projeto;
• Testador: testa o sistema e valida-o;
• Gerente: coordena a equipe, coordena cronograma, verifica os riscos e o contato com o
desenvovedor/arquiteto
O desenho contingencial de cargos é dinâmico e privilegia a mudança em função do
desenvolvimento pessoal do ocupante. Em outros termos, permite a adaptação do cargo ao
potencial de desenvolvimento pessoal do ocupante. Essa adaptação contínua é feita através do
enriquecimento do cargo. Enriquecimento de cargo significa a reorganização e ampliação do
cargo para proporcionar adequação ao ocupante no sentido de aumentar a satisfação intríseca
através do acréscimo de variedade, autonomia, significado das tarefas, identidade com as
tarefas e retroação. Segundo a teoria de dois fatores de Herzberg, o enriquecimento de cargo
constitui a maneira de obter satisfação intríseca através do cargo. É que o cargo é pequeno
demais para o espírito de muitas pessoas, e com o passar do tempo precisam ser
redimencionados. O enriquecimento do cargo -ou ampliação do cargo- torna-se a maneira
prática e viável para a adequação permanente do cargo ao crescimento profissinal do
ocupante. Consiste em aumentar deliberada e gradativamente os objetivos, responsabilidades
e desafios das tarefas do cargo para ajustá-los às características do ocupante. O
enriquecimento do cargo pode ser lateral ou horizontal (cargo lateral com a adição de novas
responsabilidades do mesmo nível) ou vertical (carga vertical com adição de novas
responsabilidades mais elevadas).
Sugere-se que a empresa formalize a matriz de responsabilidades de seus cargos. A
matriz de responsabilidades descreve as responsabilidades e funções dos envolvidos no
projeto, tendo por base os papéis identificados em seu organograma. A responsabilidade para
cada cargo de acordo com a atividade pode ser:
• RO – responsável pela operação;
• RC – responsável pelo controle;
• DC – deve ser consultado;
• DI – deve ser informado;
• RA – responsável pela aprovação
No apêndice V (item 8.5.5, Error: Reference source not found, pag.159) há um
exemplo de matriz de responsabilidade de um projeto da empresa estudada neste trabalho
55
Sugere-se, também, que a empresa formalize o processo de mobilização de equipes
para os projetos. Para tanto deve haver uma documentação e controle dos seguintes itens:
• cronograma de alocação: o cronograma de alocação tem como finalidade descrever a
necessidade de profissionais ao longo do tempo, especificando quando serão
solicitados, alocados e desalocados;
• regime de alocação: o regime de alocação descreve a forma como cada profissional
será alocado no projeto, descrevendo o total de horas trabalhadas e o regime de
alocação (parcial ou integral);
• pedido de alocação: o pedido de alocação deverá ser formalizado através do
encaminhamento superintendência competente, conforme política interna, quando
recursos inexistentes ou indisponíveis, e negociado com gerentes competentes, quando
recursos disponíveis em outras áreas.
Observou-se, também, que a empresa poderia ter benefícios em adotar um processo
de desenvolvimento da equipe. Este processo consiste em descrever o plano de
desenvolvimento que será utilizado para aprimorar as competências individuais e de grupo,
objetivando elevar o desempenho do projeto. É recomendável realizar este procedimento para
os funcionários que estão constantemente alocados em projetos de clientes com o qual se
possui um relacionamento duradouro e constante. Este desenvolvimento se faz, inclusive, com
a avaliação profissional dos funcionários, dando feedback para a equipe sobre o seu
desempenho no projeto. A avaliação de desempenho é uma apreciação sistemática do
desempenho de cada pessoa em função das atividades que ela desempenha, das metas e
resultados a serem alcançados e do seu potencial de desenvolvimento. A avaliação de
desempenho é um processo que serve para julgar ou estimar o valor, a excelência e as
qualidades de uma pessoa e, sobretudo a sua contribuição para o negócio da organização. Na
realidade, a avaliação do desempenho é um processo dinâmico que envolve o avaliado e seu
gerente e apresente uma técnica de direção imprescindível na atividade administrativa de hoje.
É um excelente meio através do qual se pode localizar problemas de supervisão de gerência,
de integração das pessoas a organização, de adequação de pessoas ao cargo, de localização de
possíveis dissonâncias e carências de treinamentos e, consequentemente, estabelecer os meios
e programas para eliminar ou neutralizar tais problemas. A avaliação de desempenho constitui
um poderoso meio de resolver problemas de desempenho e melhorar a qualidade do trabalho
e a qualidade de vida dentro das organizações.
56
Por fim, sugere-se que a empresa possua um processo definido para o recrutamento e
seleção de novos funcionários. O processo seletivo baseia-se em dados e informações sobre o
cargo a ser preenchido. As exigências dependem desses dados e informações para que a
seleção tenha maior objetividade e precisão para preencher o cargo. Se de um lado temos o
cargo a ser preenchido, temos, de outro, candidatos profundamente diferentes entre si,
disputando a mesma posição. Nestes termos, a seleção passa a ser configurada basicamente
como um processo de comparação e de decisão. A empresa deverá utilizar, para cada caso,
um tipo diverso de processo seletivo. Para conhecimento, elencamos a seguir os tipos mais
comuns:
• Modelo de colocação: há um só candidato e uma só vaga a ser preenchida por aquele
candidato. Este modelo não inclui a alternativa de rejeitar o candidato. O candidato
apresentado deve ser admitido sem sofrer qualquer rejeição;
• Modelo de seleção: há vários candidatos e apenas uma vaga a ser preenchida. Cada
candidato é comparado com os requisitos exigidos pelo cargo que se pretende
preencher, ocorrendo duas alternativas, apenas: aprovação ou rejeição. Se aprovado, o
candidato deverá se admitido. Se reprovado, o candidato é dispensado do processo
seletivo, pois existem vários outros candidatos para o cargo e apenas um deles poderá
ocupá-lo;
• Modelo de classificação: Existem vários candidatos para cada vaga e várias vagas
para cada candidato. Cada candidato é comparado com os requisitos exigidos pelo
cargo que se pretende preencher. Ocorrem duas alternativas para o candidato: ser
aprovado ou rejeitado para aquele cargo. Se aprovado, é admitido. Se rejeitado, passa
a ser comparado com os requisitos exigidos para outros cargos que se pretende
preencher, até se esgotarem os cargos vagos e as alternativas restantes. Daí a
denominação classificação. Para cada cargo a ser preenchido ocorrem vários
candidatos que disputam, sendo que apenas um deles poderá ocupá-lo, se vier a ser
aprovado.
Tendo sido avaliadas as melhores práticas do OPM3 relacionadas à área de
gerenciamento de RH, as considerações formuladas acima devem ser suficientes para que a
empresa possa formalizar o controle de seus recursos humanos e, ao mesmo tempo, não
introduzir formalismos e burocracias que venham a atrapalhar o bom clima organizacional
existente. A área de recursos humanos é bastante crítica em empresas de pequeno porte, onde
57
há necessidade de um relacionamento bastante pessoal entre os funcionários. Caso a empresa
venha a mudar o seu perfil, aumentando o seu tamanho e a complexidade de seu quadro
funcional, todo um novo estudo deverá ser feito, sendo que as considerações feitas servirão de
ponto de partida.
4.3.7 Comunicação
O PMBoK classifica a área de Comunicação em projetos entre os seguintes grupos
de processos:
1. Planejamento das comunicações: determinar as necessidades de informações e
comunicações das partes interessadas no projeto;
2. Distribuição das informações: colocação das informações necessárias à disposição das
partes interessadas no momento certo;
3. Relatório de desempenho: coleta e distribuição das informações sobre o desempenho.
Inclui relatório de andamento, medição e progresso de previsão;
4. Gerenciar as partes interessadas: gerenciamento das comunicações para satisfazer os
requisitos das partes interessadas no projeto e resolver problemas com elas.
Para a empresa, sugere-se que haja a adoção de um plano de comunicação. O plano
de gerenciamento das comunicações faz parte ou é um plano auxiliar do plano de
gerenciamento do projeto. De acordo com o PMBoK plano de gerenciamento das
comunicações fornece:
• Os requisitos de comunicação das partes interessadas;
• As informações que serão comunicadas, inclusive o formato, conteúdo e nível de
detalhes;
• A pessoa responsável pela comunicação das informações;
• A pessoa ou os grupos que receberão as informações;
• Os métodos ou tecnologias usados para transmitir as informações, como memorandos,
email e, ou, comunicados à imprensa;
• A freqüência da comunicação, como, por exemplo, semanal;
• Os prazos para identificar processos para aumentar o nível e a cadeia gerencial
(nomes) para levar para níveis mais altos problemas que não podem ser resolvidos em
um nível hierárquico mais baixo;
58
• O método para atualizar e refinar o plano de gerenciamento das comunicações
conforme o projeto se desenvolve e avança;
• Glossário da terminologia comum (caso necessário)
Na empresa estudada, é possível identificar os seguintes itens que deverão estar
presentes no plano de comunicação:
1. Principais Stakeholders que precisam fornecer informações: Desenvolvedor, Analista;
2. Principais Stakeholders que precisam receber informações: Cliente, Gerente do
Projeto, Desenvolvedor;
3. Principais informações que precisam ser distribuidas: Andamento dos projetos
(Etapas), orçamento dos projetos (EVA), não conformidades e ações corretivas;
4. Métodos, mídias ou tecnologias a serem utilizadas: email, edital, telefone, reuniões;
6. Métodos para escalação de problemas: relatório de EVA, relatório de não
conformidade, relatório de desempenho (informações e progresso das atividades);
7. Glossário (conjunto de termos a serem utilizados)
Além dos documentos trazidos no apêndice V, de outras áreas de conhecimento,
mostra-se também na pag. 160 um exemplo de "Relatório de Não-conformidades".
4.3.8 Riscos
Quanto ao controle de risco, verifica-se que a empresa não possui controle algum de
risco, o que indica que os problemas são resolvidos conforme surgem. Desta forma não é
gerado nenhum histórico de riscos dos projetos, inclusive para que pudessem ser realizadas
ações preventivas.
O PMBoK apresenta duas modalidades de gerenciamento de riscos: através da
análise qualitativa dos riscos (por exemplo, com conceitos como "alto" ou "baixo" e a análise
quantitativa, onde é verificado a probabilidade de ocorrência de cada risco e o seu impacto.
Apesar de ser mais simples de ser utilizado, principalmente em situações onde não
existe um histórico a fornecer estatísticas mais precisas, não é aconselhado que a empresa
adote a análise qualitativa.
59
Recomenda-se que a empresa inicie sua gerência de riscos com os seguintes passos:
1. Através de reunião com a sua equipe interna, seja feito um levantamento de riscos que
podem ocorrer durante a execução do projeto. Não apenas os riscos negativos (que
trazem atrasos ou perdas financeiras), mas também os riscos positivos, que são as
oportunidades de ganho para a empresa;
2. Elencados os riscos, seja preenchida a planilha que está presente no apêndice V (item
8.5.7, Levantamento de riscos, pag.161) fazendo-se o mapeamento entre os riscos e as
áreas de conhecimento a que se referem;
3. A seguir faz-se uma análise da probabilidade de ocorrência de cada um dos riscos. A
fonte mais confiável seria a opinião de especialistas e os históricos dos projetos;
4. O próximo passo é verificar qual o impacto de cada um dos riscos. Como a empresa
atua com pequenas equipes, fortemente integradas, é interessante analisar não só
impacos financeiros, mas também impactos de cronograma de cada um dos riscos;
5. Calcula-se, então, o impacto previsto de cada um dos riscos (probabilidade x impacto
esperado), para se saber quais serão os impactos esperados em cada um dos riscos.
A empresa também pode atuar na prevenção de riscos. Para isto deverá utilizar os
riscos previstos, selecionar quais serão os riscos onde deseja atuar (seja pelo seu impacto, seja
pela sua probabilidade de acontecimento, ou até mesmo pela experiência anterior em lidar
com aquele risco). A seguir deverá utilizar o documento Mitigação de Riscos (item 8.5.7, pag.
162) para estabelecer o plano de ação que será executado para mitigação dos riscos negativos
(ou potencialização dos riscos positivos).
4.3.9 Aquisições
O PMBoK classifica as aquisições do projeto como uma área de conhecimento
específica e cujos processos estão descritos no capítulo 12: “Gerenciamento de aquisições do
projeto”, onde estão divididos em:
• Planejar compras e aquisições: determinação do que comprar ou adquirir e de quando
e como fazer isso;
• Planejar contratações: documentação dos requisitos de produtos, serviços e resultados
e identificação de possíveis fornecedores;
• Solicitar respostas de fornecedores: obtenção de informações, cotações, preços, ofertas
ou propostas, conforme adequado;
60
• Selecionar fornecedores: análise de ofertas, escolha entre possíveis fornecedores e
negociação de um contrato por escrito com cada fornecedor;
• Administração de contrato: gerenciamento do contrato e da relação entre o comprador
e o fornecedor, análise e documentação do desempenho atual ou passado de um
fornecedor a fim de estabelecer ações corretivas necessárias e fornecer uma base para
futuras relações com o fornecedor, gerenciamento de mudanças relacionadas ao
contrato e, quando adequado, gerenciamento da relação contratual com o comprador
externo do projeto;
• Encerramento do contrato: terminar e liquidar cada contrato, inclusive a resolução de
quaisquer itens em aberto, e encerrar cada contrato aplicável ao projeto ou a uma fase
do projeto.
A aplicação do formulário de avaliação da empresa resultou em respostas, referente a
área de conhecimento Gerenciamento de Aquisições, que permitem afirmar que pela natureza
dos negócios da empresa, na qual pode ser classificada como “Fábrica de Software” que quase
sempre faz o papel de fornecedora e, somada às características dos projetos desenvolvidos,
tem-se a situação onde raramente demandam-se aquisições externas. Desta forma o conjunto
de Boas Práticas referentes a gerenciamento de aquisições não necessita ser implantado em
sua totalidade, pois criar-se-á uma burocracia desnecessária.
As aquisições para a empresa tendem a configurar duas situações principais que são a
aquisição de serviços ou produtos das quais a empresa não tem know-how ou não seja um dos
seus focos de atuação, mas cujo escopo do projeto vem a exigir; e a segunda situação é na
qual apesar da empresa possuir o know-how necessário para o desenvolvimento do projeto,
opta por contratar um fornecedor para desenvolver o projeto em sua totalidade ou de forma
parcial.
Dentro do contexto da empresa os processos onde será dado o foco são: Planejar
Compras e Aquisições e Planejar Contratações, ou seja, a seguinte boa prática será
implementada: “1150 Padronização do processo de Aquisição projeto”. As boas práticas
referentes ao encerramento do projeto, da qual o gerenciamento de aquisição possui
atividades, também serão implantadas e estão descritas no item 4.3.1 (pag. 35) referente ao
gerenciamento de integração do projeto.
61
O processo de planejamento de compras e aquisições é onde é feita a identificação
das necessidades do projeto que serão melhor atendidas através da contratação ou compra de
serviços ou produtos fora da organização. Para esta identificação pode-se utilizar a análise
make-or-buy, que consiste em uma série de ponderações a respeito das diversas necessidades
e pode orientar para executar dentro da organização ou adquirir externamente. O fluxograma
da figura7 deverá ser utilizado pela organização para auxiliar no processo decisório através da
análise make-or-buy.
Figura 7: Fluxograma do processo de decisão make-or-buy(Fonte: os próprios autores)
O processo de planejamento de compras e aquisições deverá utilizar as seguintes
entradas: declaração de escopo, WBS, dicionário da WBS. Os passos a serem seguidos são os
representados na figura 7 acima. Deste processo resultarão os seguintes documentos: plano de
gerenciamento de aquisição, decisões de fazer ou comprar.
Já o processo de planejamento das contratações consiste em elaborar toda a
documentação necessária para a aquisição externa de produtos ou serviços necessários para
atender os requisitos do projeto. É a sequência natural do processo de planejamento das
62
compras e aquisições. As saídas típicas deste processo são os documentos de aquisição,
critérios de avaliação e as declarações de trabalho. Os documentos de aquisição são utilizados
para enviar aos possíveis fornecedores as informações necessárias para que sejam elaboradas
as propostas. Os critérios de avaliação são os conjuntos de critérios para classificar e pontuar
propostas e fornecedores. E a declaração de trabalho é a especificação detalhada dos
requisitos do que está sendo adquirido.
Para a empresa em análise, levando-se em conta o pequeno porte, a reduzida
quantidade e necessidades de aquisições externas, assim como a relação de parceria que
desenvolve com seus fornecedores, o processo de planejamento de contratações deve ser
simples e efetivo. Para os documentos de aquisição devem ser fornecidas informações
suficientes para que o fornecedor possa avaliar custos e formalizar uma proposta. Para a
simplificação do processo optou-se pela junção do documento de aquisição com a declaração
de trabalho. As informações mínimas devem ser: nome do projeto, necessidade, objetivos,
escopo, restrições, premissas, entregáveis, critérios de aceite e matriz de responsabilidades. O
item 8.5.8 (Error: Reference source not found, pag 163) mostra o modelo de Declaração de
Trabalho que deve ser utilizado.
Ao final do processo de planejamento das contratações, o gerente de projetos ainda
deve preencher o plano de gerenciamento das contrações. O item 8.5.8 (Error: Reference
source not found, pag. 164) mostra o modelo de plano de gerenciamento de contrações que
deve ser utilizado.
Pelo fato da empresa não ter um departamento formal de compras e aquisições a
elaboração de critérios de avaliação de propostas e fornecedores é uma atividade
desnecessária, uma vez que a avaliação e escolha do fornecedor é em geral efetuada pelo
gerente de projetos em conjunto com o diretor técnico e o responsável por compras.
Os demais processos de aquisição sugeridos pelo PMBoK (solicitar respostas dos
fornecedores, selecionar fornecedores, administração de contratos) não serão estabelecidos ou
serão utilizados os processos já documentados e utilizados no Sistema de Controle da
Qualidade.
63
5 CONCLUSÕES
O objetivo deste trabalho foi identificar o grau de maturidade da empresa estudada
em gerência de projetos. Para tanto, após entrevistas efetuadas com um de seus sócios-deireto,
foi escolhido o OPM3, do PMI, como modelo de referência para o nível de maturidade, pois a
empresa conhece e utiliza o PMBOK em seus projetos.
Conforme o perfil da empresa, obtido através de levantamento efetuado por um de
seus sócios, foi determinado que o objeto de estudo seriam apenas as Best Practices do OPM3
que fossem relacionadas a projetos, não sendo trabalhadas as que se referem a programa ou
portfólio.
Verificou-se que é possível associar a maior parte das Best Practices com áreas de
conhecimento do PMBOK, restando poucas Best Practices que abrangem mais de uma área
de conhecimento ou que se referem à cultura organizacional da empresa. Facilita-se, assim, o
trabalho de implantação das práticas escolhidas, pois há uma integração mais forte com o
PMBOK.
Dentre estas Best Practices foram selecionadas algumas, reduzindo-se de um total de
208 Best Practices para 88. O critério de seleção foi o perfil de empresa, os profissionais que
a compõe, seu relacionamento com seus clientes e características de seus produtos. Evitou-se,
desta forma, que a empresa fosse avaliada profundamente em relação a áreas de conhecimento
do PMBOK que não são utilizadas em sua atividade. Neste ponto, destacamos a redução
significativa de Best Practices que se relacionam com as áreas de Aquisições, RH, Integração
e Comunicação.
O questionário elaborado conforme as Best Practices escolhidas tras 73 perguntas,
um número maior que o apresentado pelo OPM3 (59 perguntas relacionadas a projetos).
Buscou-se, desta forma, desdobrar alguns assuntos em várias perguntas, obtendo-se uma
avaliação mais precisa do nível de maturidade da empresa em gerenciamento de projetos.
Concluiu-se que a escolha do modelo OPM3 foi bastante coerente com a realidade da
empresa, pois após a aplicação do questionário elaborado verificou-se que as notas obtidas
nas áreas de conhecimento ou nos índices de maturidade da empresa em gerenciamento de
projetos era bastante coerente com o que havia sido levantado através de entrevista.
Por fim, a partir de todos estes dados levantados, foi feita uma análise e apresentadas
sugestões de como a empresa poderia adotar práticas recomendadas pelo OPM3 e pelo
PMBoK para aumentar o seu nível de maturidade. Houve cuidado de não interferir na cultura
64
já existente na empresa, para que não houvesse uma quebra de produtividade ou de confiança
em função de uma formalidade que poderia parecer injustificada.
Só será possível saber do êxito das sugestões feitas após uma nova avaliação da
empresa, em cerca de 6 meses, sendo imprescindível que a empresa implemente as sugestões
ou justifique a sua não utilização.
65
6 POSSÍVEIS DESDOBRAMENTOS
Este trabalho foi além do simples levantamento de dados da empresa apóes o estudos
de modelos de maturidade em gerência de projetos. As sugestões formuladas, a partir da
análise das respostas fornecidas pela empresa, só surtirão efeito após a sua implantação por
um tempo razoável, não sendo esperado grandes alterações em um prazo inferior a seis meses.
A equipe deste trabalho sugere que a empresa refaça sua análise, com auxílio do questionário
elaborado, a cadas semestre, podendo assim avaliar se houveram ganhos com a adoção das
sugestões.
66
7 REFERÊNCIAS BIBLIOGRÁFICAS
BARBOSA, C. et al. Gerenciamento de custos em projetos, Editora FGV, 2007
BARCAUI A, B. et al. Gerenciamento do tempo em projetos - 2ª edição, Editora FGV, 2008
______________ O Desafio do Sucesso em Projetos de Tecnologia da Informação, em Programa de Engenharia de Produção, Universidade Federal do Rio de Janeiro (UFRJ).
CHAVES, L. E. et al. Gerenciamento da comunicação em projetos, Editora FGV, 2007
FAGUNDES, Eduardo Mayer. Capability Maturity Model for Software. Disponível em http://www.efagundes.com/artigos/CMM.htm. Acesso em 28/11/2008.
GASNIER, Daniel G. Guia Prático Para Gerenciamento De Projetos. IMAM, 2003
MARSHALL Jr, I.; et al. Gestão da Qualidade. Rio de Janeiro: Editora FGV, 2007
PASSOS, Maria Luiza Gomes de Souza. Gerenciamento De Projetos Para Pequenas Empresas. Brasport, 2008
PAULK, M. C. et al. Capability Maturity Model for Software, Version 1.1, Technical Report SEI-CMU-93-TR-24, Software Engineering Institute, 1993.
PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute. Newton Square, PA. EUA, 2004.
PRADO, D., ARCHIBALD, R. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anaual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008
___________. Gerenciamento de Portifólios, Programas e Projetos nas Organizações. São Paulo, INDG, 2004.
RAJ,P. P. et al. Gerenciamento de pessoas em projetos, Editora FGV, 2008
SALLES JR, C. A. C. et al. Gerenciamento de riscos em projetos, Editora FGV, 2007
SOTILLE, M. A. et al. Gerenciamento do escopo em projetos - 2ª edição, Editora FGV, 2008
VALLE, A. B. do et al. Fundamentos do gerenciamento de projetos, Editora FGV, 2007
VARGAS, R. V. Gerenciamento de Projetos Estabelecendo Diferenciais. Brasport, 2005
<Listar e descrever os produtos e serviços entregues, referenciando o número dos mesmos no
dicionário da EAP>
2. Observações:
<Descrever as observações pertinentes ao aceite>
152
8.5.3 Custos
Plano de Gerenciamento de Custos
<Nome-Empresa>
• Projeto: <Nome-Projeto>Plano de Gerenciamento de CustosElaborado Por: <Nome e Função>Aprovador 1 (Empresa): <Assinatura>Data:Relação de processos a utilizar
Estimativa de Custos<Particularidades do processo para este projeto>Orçamentação<Particularidades do processo para este projeto>Controle de Custos<Particularidades do processo para este projeto>
• Relação de Relatórios a utilizar<Lista de tipos de relatórios a utilizar, elencando identificação de documentos de template>
• Forma de estimativa<Relacionar particularidades de estimativa de custos do projeto que fujam do processo padrão adotado>
• Indicadores para Controle<Lista de Indicadores, explicando forma de cálculo e coleta de dados, bem como os limites adotados para o projeto em questão >
• Processo de gerenciamento de variações<Quais os procedimentos a adotar no caso de variações/estouro de limites estabelecidos para indicadores>
• Gerenciamento de MudançasProcesso de solicitação de mudanças(Vide área de Gerenciamento de Integração)Template de solicitação de mudanças<Identificação do documento>(Vide área de Gerenciamento de Integração)Descrição/Observação sobre processo de gerenciamento de mudanças<Particularidades deste projeto sobre o processo de gerenciamento de mudanças>(Vide área de Gerenciamento de Integração)
153
Orçamento<Nome-Empresa>Projeto: <Nome-Projeto>OrçamentoDados Coletados Por: <Nome e
Função>Elaborado por: <Nome e Função>Data de Aprovação: __ / __ / ____Orçamento por Recurso
Recurso / Perfil Custo unitário /
Valor Hora (R$)
Quantidade (Horas) Sub-total (R$)
Custo do projeto
Adicional de Risco para Valor Esperado
Reserva Gerencial / Taxa de Administração 5%
Custo Final
Orça
mento por Use Case<local>, em ___ de _________ de _____
Projeto: <Nome-Projeto>Declaração de trabalhoElaborado Por: <Nome e Função>Aprovador 1
(Empresa): <Assinatura>Data:
Necessidade
<Especificar de forma sucinta a necessidade de aquisição>
Objetivos
<Especificar os objetivos da requisição>
Escopo
<Detalhar o escopo da necessidade, expandido e especificando o detalhamento já inserido na
WBS>
Restrições
<Inserir todas as restrições do entregável, sejam técnicas, sejam de prazo>
Premissas
<Inserir todas as premissas do entregável>
Entregáveis
<Inserir todos os produtos e objetivos que deverão ser entregues>
Critérios de aceite
<Inserir todas os critérios de avaliação do entregável e para a sua aceitação>
Matriz de responsabilidades
<Inserir os nomes do Gerente do Projeto, do Diretor técnico e do responsável por compras>
164
Plano de Gerenciamento de Contrações
<Nome-Empresa>
Projeto: <Nome-Projeto>Plano de Gerenciamento de ContraçõesElaborado Por: <Nome e
Função>Aprovador 1 (Empresa): <Assinatura>Data:
Itens e recursos a serem contratados ou adquiridos
<Listar todos os itens a serem contratados ou adquiridos de acordo com a análise make-or-
buy>
Documentação necessária para cada contratação
<Listar para cada item a ser contratado ou adquirido os documentos necessários para a sua
contratação, o documento mínimo e a declaração de trabalho do item>
165
8.6 APÊNDICE VI: QUESTIONÁRIO RESPONDIDO PELA EMPRESA
N. Pergunta
Descrição Nota (0 a 5)
1 A sua organizaçao estabelece e usa padroes de processos de documentacao para a iniciaçao do projeto?
1
2 Há um processo de Planejamento do Escopo do Projeto? 5
3 Há um processo de Padronizaçao do processo de definição do escopo de projeto? 0
4 Existe um processo de Estimativa de Duraçao das Atividades do Projeto? 3
5 Existe um processo de padronização de estimativa de custo do projeto? 0
6 Existe padronização do processo de Aquisiçao projeto? 0
7 Existe padronização do processo de Comunicaçao do projeto? 0
8 Existe padronização do processo de Execução do plano de projeto? 0
9 Existe padronização do processo de Controle Integrado de Mudanças do projeto? 3
10 Existe padronização do processo de Controle de qualidade do projeto? 3
11 São definidos Objetivos dos projetos? 1
12 Existe aprimoramento de qualidade para atingir a satisfaçao do cliente? 0
13 Existe estimativa de duraçao das tarefas do projeto? 5
14 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de iniciação?
0
15 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de escopo?
0
16 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de tempo?
0
17 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de custo?
0
18 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de qualidade?
0
19 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento das aquisições?
0
20 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Recursos Humanos?
0
21 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Riscos?
0
22 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Controle de Mudanças?
0
23 Sua organização aplica controles no acompanhamento da fase de iniciação? 0
24 Sua organização aplica controles no acompanhamento da fase de planejamento de escopo?
0
25 Sua organização aplica controles no acompanhamento da fase de planejamento de tempo?
0
166
N. Pergunta
Descrição Nota (0 a 5)
26 Sua organização aplica controles no acompanhamento da fase de planejamento de custo?
0
27 Sua organização aplica controles no acompanhamento da fase de planejamento de qualidade?
0
28 Sua organização aplica controles no acompanhamento da fase de planejamento das aquisições?
0
29 Sua organização aplica controles no acompanhamento da fase de planejamento de Recursos Humanos?
0
30 Sua organização aplica controles no acompanhamento da fase de planejamento de Riscos?
0
31 Sua organização aplica controles no acompanhamento da fase de planejamento de Controle de Mudanças?
0
32 A organização segue metodologia e procedimentos documentados para Gerência de Projetos?
2
33 A organização apura e documenta o retorno financeiro de projetos? 5
34 A organização apura e documenta o atingimento dos objetivos dos projetos? 2
35 A organização avalia performance individual e de equipe através de um processo formal?
0
36 A organização premia performance individual e de equipe? 0
37 Os objetivos do projeto são usados no acompanhamento do mesmo? O atingimento dos mesmos é usado como critério de sucesso?
3
38 Existe um processo formal para definir se projetos serão ou não executados, se submeterá proposta?
0
39 A organização aplica um processo formal de acompanhamento dos riscos durante a execução do projeto?
0
40 Há um procedimento de controle de riscos durante a execução do projeto? 0
41 O procedimento de controle de riscos durante a execução do projeto é aplicado? 0
42 Há um procedimento para controle e acompanhamento da execução do projeto? 2
43 O procedimento de controle e acompanhamento da execução do projeto é aplicado?
1
44 Há um procedimento para controle de mudanças de calendário do projeto? 3
45 O procedimento de controle de mudanças de calendário do projeto é aplicado? 1
46 É feita uma estimativa de problemas que poderão surgir sobre a estimativa das atividades que compõe o projeto?
1
47 É feita a coleta de informações sobre a correção das atividades que foram estimadas para o projeto?
2
48 São implementadas melhorias na estimativa de atividades dos projetos baseando-se em informações coletadas em projetos anteriores?
1
49 Há um procedimento de controle de mudanças de escopo durante a execução do projeto?
3
50 O procedimento de controle de mudanças de escopo durante a execução do 3
167
N. Pergunta
Descrição Nota (0 a 5)
projeto é aplicado?
51 É feita uma estimativa de problemas que poderão surgir sobre o escopo do projeto?
1
52 É feita a coleta de informações sobre problemas surgidos de escopo mal definido ou de mudanças de escopo?
3
53 São implementadas melhorias no planejamento de escopo e no controle de mudança de escopo dos projetos baseando-se em informações coletadas em projetos anteriores?
0
54 Há um procedimento para elaboração de relatórios de desempenho? 0
55 O relatório de desempenho é feito conforme procedimento definido durante a execução do projeto?
0
56 Há um procedimento para controle de mudanças de custos do projeto? 0
57 O procedimento de controle de mudanças de custos do projeto é aplicado? 0
58 É feita uma estimativa de problemas que poderão surgir sobre a estimativa de custos do projeto?
0
59 É feita a coleta de informações sobre problemas surgidos de custos mal definidos?
0
60 São implementadas melhorias na estimativa de custos dos projetos baseando-se em informações coletadas em projetos anteriores?
0
61 É feita a coleta de informações sobre problemas surgidos na elaboração de relatórios de desempenho?
0
62 São implementadas melhorias na elaboração de relatório de desempenho baseando-se em informações coletadas em projetos anteriores?
0
63 É feita a coleta de informações sobre a ocorrência de riscos e as respostas dadas durante a execução do projeto?
0
64 São implementadas melhorias no levantamento de riscos e no planejamento de respostas a riscos baseando-se em informações coletadas em projetos anteriores?
0
65 Há um procedimento de encerramento de projetos? 3
66 O procedimento de encerramento de projetos é aplicado? 2
67 É feita a coleta de informações sobre problemas surgidos no processo de encerramento do projeto?
0
68 São implementadas melhorias no processo de encerramento do projeto baseando-se em informações coletadas em projetos anteriores?
0
69 Há a coleta de informações de “lições aprendidas” no projeto? 1
70 As informações de “lições aprendidas” são compartilhadas pelas equipes de projetos?
1
71 As informações de “lições aprendidas” são utilizadas em novos projetos? 1
72 É realizado benchmarking para comparar o desempenho de projetos? 3
73 Há apoio da empresa para as equipes de projeto através de suporte técnico ou de um bom ambiente de trabalho?
5
168
9 APÊNDICES POR AUTOR INDIVIDUAL
9.1 DANIELE MARTINS
GESTÃO DE PESSOAS COMO DIFERENCIAL COMPETITIVO
A Gestão de Pessoas apresenta como uma importante ferramenta na busca de bons
resultados e da manutenção de empresas no mercado globalizado. Segundo Vieira (a), “além
dos clientes e dos produtos, sem dúvida alguma, os recursos humanos fazem parte dos
principais ativos das organizações. As pessoas movem as engrenagens da produtividade. O
sucesso dos projetos e também das organizações é determinado pelas atitudes profissionais
das pessoas. Um dos maiores desafios dos gerentes de projetos, sejam eles de tecnologia da
informação ou de outra natureza, é gerenciar efetivamente os recursos humanos.”.
Para gerenciar as pessoas com efetividade é necessário mudar a forma de ver os
funcionários e, consequentemente, de se relacionar com eles. Chiavenato aponta duas formas
distintas de tratar as pessoas que compõem uma empresa, como recursos produtivos ou como
parceiras. Na tabela abaixo vemos as distinções apontadas por este autor.
Tabela 1: Quadro comparativo entre recurso e parceiro. (b)
Neste quadro comparativo observamos as características de cada forma de perceber
as pessoas numa empresa. Ao conceber como recurso, torna-se necessária uma maior
intensidade de ações relacionadas ao gerenciamento para que seja obtido o desempenho
desejado para as atividades, visto que a postura dos recursos é essencialmente passiva. Já, ao
conceber os colaboradores como parceiros, como ressalta Travassos (b), “elas são
fornecedoras de conhecimento, habilidades, competências e, sobretudo, o mais importante: a
inteligência que proporciona decisões racionais e o alcance dos objetivos. Dessa forma, as
169
pessoas deixam de ser meramente recursos e passam a ser parceiras comprometidas com o
desempenho máximo de suas atribuições e com o sucesso do projeto.”
Outro fator que contribui para o gerenciamento de pessoas com efetividade é a
adoção de processos. Conforme o PMBOK® Guide, fazem parte do gerenciamento de
recursos humanos processos que viabilizem a organização e o gerenciamento da equipe
envolvida no projeto. Também destaca que a importância da atribuição de funções e
responsabilidades às pessoas que compõem a equipe para a finalização de projetos com
qualidade. E define os seguintes processos para este gerenciamento:
“9.1 Planejamento de recursos humanos – Identificação e documentação de funções, responsabilidades e relações hierárquicas do projeto, além da criação do plano de gerenciamento pessoal.9.2 Contratar ou mobilizar a equipe do projeto – Obtenção dos recursos humanos necessários para terminar o projeto.9.3 Desenvolver a equipe do projeto – Melhoria de competências e interação de membros da equipe para aprimorar o desempenho do projeto.9.4 Gerenciar a equipe do projeto – Acompanhamento do desempenho de membros da equipe, fornecimento de feedback, resolução de problemas e coordenação de mudanças para melhorar o desempenho do projeto.” (c)
Esses processos não são estáticos, interagindo entre si e com as demais áreas de
gerenciamento e abrem espaços para tornar os recursos humanos peças fundamentais para
uma empresa. Muito se tem debatido sobre o valor dos recursos humanos para as empresas e
sobre formas de transformá-los em aliados nas batalhas diárias em busca de sucesso no
mercado globalizado marcado por constantes mudanças e incertezas. E incertezas, estas que
tornaram o ambiente de trabalho fonte geradora de estresse e, consequente diminuição da
produtividade.
“Em primeiro lugar gostaria de deixar claro que nossa lista das melhores empresas para se trabalhar não é perfeita, e no tocante ao estresse é preciso admitir que são realmente poucas as organizações que são realmente boas em lidar com o mesmo. O que eu tenho visto em relação a este problema na realidade está mais ligado à sensação que as pessoas têm de não estarem com sua vida, e seu trabalho, sob algum grau de controle, do que com a competição interna propriamente dita. E é este aspecto que credencia umas poucas organizações a lidarem eficazmente com o estresse: elas possibilitam que os seus colaboradores tenham a sensação que suas vidas estão razoavelmente sob controle. A competição pode ser até muito saudável, se as pessoas sentirem que naquela organização elas têm controle sobre suas vidas. O que estressa as pessoas num ambiente competitivo é a constatação pelo indivíduo de que a
170
competição não o está levando a lugar algum, que não está gerando resultados positivos. Uma boa empresa para se trabalhar é onde você confia nas pessoas para quem você trabalha (gerentes e dirigentes), tem orgulho e gosta do que faz e gosta e confia nas pessoas com quem trabalha (senso de camaradagem).” Robert Levering (1999)
Nesta resposta dada ao Dr. Paulo Pegado em entrevista realizada durante o Segundo
Encontro de Qualidade de Vida no Trabalho, realizado na USP em 05 de Julho de 1999,
Levering mostra o terreno fértil a ser semeado – investimento no capital humano - afinal são
as pessoas que fazem a diferença para o negócio. Em outras palavras, o estímulo ao
desenvolvimento do se humano transformou-se num investimento de mão dupla, onde ganha
a empresa, que passa a contar com colaboradores mais capacitados, como também o
profissional, que adquire novas competências, sejam essas técnicas ou comportamentais.
Atualmente as organizações que entendem que o Recurso Humano é um dos mais
importantes recursos da organização se não o mais importante recurso, estão se destacando
expressivamente no âmbito do negócio que atuam ganhando posição no mercado ou
consolidando a sua fatia. Destacam se consideravelmente, pois utilizam desse recurso
aplicando os mais modernos métodos de aperfeiçoamento profissional, seleção e estímulo da
motivação, aproveitando o máximo possível do potencial que muita das vezes está ocioso nos
seus quadros de colaboradores que são a essência da organização.
Elevando-se os colaboradores da categoria de “recurso” para a de “ser” humano,
estes passam a sentir-se parte da empresa e a contribuir cada vez mais para o sucesso de
ambos – do profissional e de sua empresa.
Atuando num contexto de globalização, as empresas devem estar constantemente
atentas às mudanças e exigências do mercado, planejando estratégias, investindo – nas
pessoas e em seus processos –, analisando os riscos e as oportunidades. A cada dia é mais
essencial se antecipar às necessidades do mercado para não estar constantemente correndo
atrás de seus concorrentes.
A gestão de pessoas, quando realizada de forma consciente, torna-se uma excelente
vantagem competitiva, já que a satisfação dos colaboradores funciona como fonte de inovação
e de melhoramento contínuo. A empresa pode ter ótimas instalações, produtos úteis e uma
propaganda que marca, contudo se as pessoas que a compõe não se sentirem parte dela, seus
esforços em prol da melhoria contínua, em geral, serão insuficientes para a empresa navegar
pela acirrada batalha no mercado.
171
(a) VIEIRA, Marconi Fábio. Gerenciamento de Projetos de Tecnologia da Informação.
Rio de Janeiro: 2003.
(b) TRAVASSOS, Alexandre. Recursos Humanos: como gerenciá-los em projetos? Ver.
Mundo Project Management. Ano 4, nº 21.
(c) CHIAVENATO, Idalberto. Gestão de Pessoas: o novo papel dos recursos humanos nas
organizações. Rio de Janeiro: 1999.
172
9.2 FERNANDO REZENDE CELESTINO
COMO O CMM PODE COMPLEMENTAR AS BOAS PRÁTICAS DO PMBOK EM
PROJETOS DE SOFTWARE: ÁREAS DE ESCOPO, TEMPO E CUSTO.
Comparando o modelo de maturidade OPM3, apoiado nas boas práticas do PMBOK,
com o modelo de maturidade CMM, com suas próprias boas práticas, observamos que os
mesmos podem se complementar de maneira eficiente para auxiliar uma empresa que realiza
projetos de software a aumentar a sua maturidade. O PMBOK trazendo as práticas para
gerenciamento de projetos independente da sua natureza, e o CMM, criado pelo SEI
(Software Engineering Institute), ajudando a concretizar as práticas indicadas pelo PMBOK
de maneira eficiente para projetos de software.
A figura abaixo mostra o relacionamento entre as áreas de conhecimento do PMBOK
e as áreas de processo do CMM:
Figura 1 Fonte [b]
173
O presente estudo pretende demonstrar algumas formas pelas a área de conhecimento
de Gerência de Escopo do PMBOK pode ser complementada pelas áreas de processo de
Gerência de Requisitos do CMM.
Visão de Gerenciamento de Projetos dentro do CMM
O CMM for Development contém uma área de processo específica para
Gerenciamento de Projetos, a qual indica ferramentas e boas práticas que são as mesmas ou
muito similares às do PMBOK. No entanto, no CMM for Development, essas boas práticas de
projetos estão explicitamente relacionadas a boas práticas de outras áreas de processos,
agrupadas no que é chamado de “Áreas de Suporte e Engenharia” (Engineering and Support
Áreas). Nestas áreas estão as práticas específicas de software.
A figura 2 mostra as áreas de processo de Gerenciamento de Projetos do CMM,
como elas se relacionam, e a ligação com as áreas de suporte e engenharia.
Figura 2 Fonte [a]
174
Os processos de suporte dizem respeito a garantia de qualidade, controle de
mudanças e métricas, como mostrado na figura 3.
Figura 3 Fonte [a]
Os processos de engenharia englobam parte dos processos de definição de escopo
(Requisitos Funcionais e técnicos), e processos de verificação do escopo, como mostrado na
figura 4.
Figura 4 Fonte [a]
Sugestão de uso da área de processo de Gerência de Requisitos do SEI-CMM para
complementar o processo de Definição de Escopo do PMBOK.
175
Os processos de definição de escopo e desenvolvimento de requisitos estão
interligados. Isto se deve ao fato de que o escopo de projetos de software é delineado
principalmente pelos seus requisitos funcionais (Funcionalidade desejada pelo cliente) e não
funcionais (Performance, segurança e outros). [a] [b].
Os projetos de desenvolvimento de software, pelo modelo clássico (Seqüencial), são
divididos nas fases de Análise, Design, Codificação e Testes. Em outras abordagens mais
modernas, como os modelos de prototipação, RAD, espiral, e Extreme Programming, tais
fases também existem mas são repetidas em ciclos sucessivos para garantir melhor
entendimento geral sobre o produto a produzir.[c].
Segundo Pressman [c], O levantamento de requisitos é sempre o primeiro passo em
qualquer atividade de análise de um software. Esta atividade pode ser realizada através de
reuniões entre o cliente e os desenvolvedores/analistas para definir os requisitos básicos do
sistema e do software. Baseado nestes requisitos, o engenheiro de software (Analista), pode
criar um conjunto de cenários, cada qual identificando um uso hipotético do sistema a ser
construído. Estes cenários, geralmente chamados de Use Cases, provêem uma descrição de
como o sistema será usado. [c].
Grande parte das empresas de desenvolvimento de software utiliza a análise
orientada a objetos, na qual a especificação de requisitos através de use cases é amplamente
difundida.
Lembrando que os requisitos do sistema em um projeto de software representam o
escopo do cliente. No entanto, o escopo do projeto não se resume ao escopo do cliente. É
preciso gerar outros produtos e serviços, tais como: treinamentos para equipe do projeto,
plano do gerenciamento do projeto, relatórios de desempenho, contratos, etc.. [e].
Como ferramenta para definir e especificar o escopo do projeto, ambos os guias,
CMM e PMBOK indicam a WBS (Work Breakdown Structure), e um dicionário da WBS.
Estes artefatos deverão revistos e refinados até que o planejamento do projeto possa ser
completado. [e].
176
Segundo o CMM, o desenvolvimento de uma WBS divide o projeto geral em um
conjunto de componentes gerenciáveis interconectados. Tipicamente, a WBS é uma estrutura
orientada a produto que provê um esquema para identificar e organizar as unidades lógicas de
trabalho a serem gerenciadas, chamadas “Work Packages” ou Pacotes de Trabalho. A WBS
provê uma referência, e mecanismo organizacional para atribuir esforço, cronograma e
atribuir responsabilidades, e é usada como o framework para planejar, organizar e controlar o
trabalho feito no projeto. Alguns projetos utilizam o termo “WBS de contrato” para se referir
à parte da WBS que é inserida no contrato (Algumas vezes, toda a WBS). Nem todos os
projetos tem uma WBS de contrato (Ex: Projetos desenvolvidos com fundos internos da
organização).
Para representar o escopo do cliente (Funcionalidades desejadas), a metodologia ágil
de gerenciamento de projetos SCRUM recomenda uma estrutura chamada FBS (Functional
Breakdown Structure) [d]. Neste caso sugere-se usar a FBS como um ramo da WBS completa
do projeto, contemplando desta forma o escopo do cliente e os demais entregáveis
necessários, como os de gerenciamento. Os pacotes da FBS serão os use cases, podendo os
mesmos ter subordinados componentes, e em seguida elementos de design, conforme o nível
de detalhamento desejado para o projeto específico, conforme sua complexidade.
O CMM indica como sub-práticas à prática de definição de escopo na WBS:
1 – Desenvolver a WBS com base na arquitetura do sistema
2 – Identificar os work packages em nível de detalhe suficiente para dar estimativas de
esforço e cronograma, bem como atribuir responsabilidades.
3 – Levar em conta a re-utilização de componentes de software (Identificar produtos de
trabalho que serão reutilizados).
O processo de definição de escopo do CMM: Desenvolvimento de Requisitos
177
O objetivo do Requirements Development (RD) é produzir e analizar requisitos do
cliente, do produto e de componentes do produto. Neste processo, o CMM for Development
procura adequar as práticas consagradas para software no que diz respeito a requisitos, com
projetos para criação de produtos de qualquer natureza, não somente software.
Esta área de processo do CMM descreve 3 tipos de requisitos: Requisitos do cliente,
do produto e de componentes do produto. Em conjunto, estes requisitos endereçam as
necessidades dos stakeholders relevantes, incluindo aqueles pertinentes a várias fases do ciclo
de vida do produto (Ex: Critérios de aceitação de testes), e atributos do produto (Ex:
Segurança, confiabilidade, e manutenibilidade). Requisitos também endereçam restrições
causadas pela seleção de determinadas soluções de design. (Ex: Integração de produtos
comerciais prontos (off-the-shelf).
Todo projeto de desenvolvimento tem requisitos. No caso de um projeto focado em
atividades de manutenção, as mudanças ao produto ou aos componentes do produto são
baseadas em mudanças nos requisitos existentes (Que deram origem ao produto existente), ao
design ou implementação do mesmo.
Requisitos são a base para o design. O desenvolvimento de requisitos inclui as
seguintes atividades:
• Esclarecimento, análise, validação e comunicação de necessidades, expectativas e
restrições do cliente para obter os requisitos do cliente que constituem um
entendimento do que é necessário para satisfazer os stakeholders.
• Relacionar e coordenar necessidades dos stakeholders
• Desenvolver os requisitos de ciclo de vida do produto
• Estabelecer os requisitos do cliente (Funcionalidades esperadas do software).
• Estabelecer os requisitos iniciais do produto e dos componentes do produto de forma
consistente com os requisitos do cliente. (Arquitetura e componentes reutilizáveis).
178
Segundo o CMM, o desenvolvimento de requisitos deve endereçar todos os
requisitos do cliente, e não só requisitos de nível do produto, porque o cliente sempre pode
prover requisitos específicos para o design.
Os requisitos do cliente são refinados em requisitos do produto e dos componentes
do produto. Além dos requisitos do cliente, os requisitos de produto e de componente do
produto são derivados das soluções de design adotadas. Através dos diversos processos do
CMM, onde se refere a produto e componente do produto, o significado desejado engloba
serviços e seus componentes.
A área de processo de desenvolvimento de requisitos inclui 3 objetivos específicos:
1 – Desenvolver requisitos de cliente: Definir um conjunto de requisitos do cliente para usar
no desenvolvimento dos requisitos de produto.
2 – Desenvolver requisitos do Produto: Definir um conjunto de requisitos do produto ou dos
componentes do produto a serem usados no design do produto e seus componentes.
3 – Analisar e Validar Requisitos: Análise de requisitos do cliente, do produto e dos
componentes para definir, derivar e entender os requisitos. As práticas deste objetivo servem
de suporte aos dois primeiros.
Os processos associados ao desenvolvimento de requisitos podem interagir
recursivamente com os processos de solução técnica.
Análises são utilizadas para entender, definir e selecionar os requisitos em todos os
níveis, com base em alternativas concorrentes. Esta análise inclui:
- Análise das necessidades e requisitos para cada fase do ciclo de vida do produto, incluindo
necessidades de stakeholders relevantes, ambiente operacional, e fatores que reflitam
expectativas e satisfação geral do cliente e dos usuários finais, como segurança e economia.
- Desenvolvimento de um conceito operacional
- Definição de todas as funcionalidades requeridas.
179
A definição das funcionalidades, também chamada de Análise Funcional, não deve
ser confundida com análise estruturada em desenvolvimento de software, ou presumir um
design orientado a funcionalidade. Em design de software orientado a objetos, Análise
Funcional diz respeito a definir o que é chamado neste contexto de “Serviços” ou “Métodos”.
A definição de funções, seu agrupamento lógico e a associação entre as mesmas com
requisitos é referido como “Arquitetura Funcional”.
A Análise ocorre recursivamente, em níveis sucessivamente mais detalhados da
arquitetura do produto até que detalhamento suficiente esteja disponível para possibilitar
design, aquisição e testes do produto. Como resultado da análise de requisitos e do conceito
operacional (Incluindo funcionalidade, suporte e manutenção), o conceito do produto produz
mais requisitos derivados, incluindo consideração do seguinte:
- Requisitos de vários tipos
- Limitações Tecnológicas
- Custo e “drivers” de custo
- Restrições de tempo e cronograma
- Riscos
- Problemas e dificuldades implícitos mas não informados explicitamente pelo cliente ou
usuário final.
Sugestão de uso da área de processo de Gerência de Requisitos do SEI-CMM para
complementar o processo de Verificação de Escopo do PMBOK.
Estando o escopo bem definido e especificado, deve ser definido o critério de
aceitação para cada item, conforme indicado pelo PMBOK. Como critério de aceitação para
os itens funcionais, os use cases, geralmente são utilizados testes de aceitação baseados nos
cenários dos use cases [c]. Tais testes devem ser executados por uma equipe do cliente. Os
testes são especificados através de documentos de casos de teste, ou test cases, que definem os
passos que deverão ser executados no sistema para verificar que o mesmo desempenha todas
as funcionalidades acordadas conforme especificado.
180
Conclusão
Estudando o guia CMM for Development, observa-se claramente suas raízes comuns
com o PMBOK, e pode-se tirar proveito do fato do primeiro detalhar mais a maneira de
aplicação das boas práticas a projetos de software, tendo em vista sua origem em projetos
desta natureza (Engenharia de Software).
[a] - CMMI® for Development, Version 1.2, Carnegie Mellon Software Engineering Institute
(SEI)
[b] - Gerência de Projetos de Software CMM & PMBOK, José Ignácio Jaeger Neto, Fernanda
Qualidade da comunicação deve pressupor a personalização do processo em função
das naturais diferenças de diversos quadros de referência, nível de experiência, amplitude de
interesses, motivação, etc. Comunicações feitas para a média do público acabam gerando mais
197
problemas do que benefícios, sem falar do fato de a pasteurização tornar as mensagens
inócuas ou sem impacto.
Bibliografia
SCHNEIDER, Guilherme. O gerente de projetos também cuida da comunicação.
Disponível em http://webinsider.uol.com.br/index.php/2008/11/05/o-gerente-de-projetos-
tambem-cuida-da-comunicacao/. Acesso em 15 de janeiro de 2009.
198
9.5 WALTER RIBEIRO DE OLIVEIRA JR
A ADAPTAÇÃO DA GERÊNCIA DE PROJETOS A CADA PROJETO
É um conceito básico, aprendido logo ao início de qualquer curso de
gerenciamento de projetos que utilize o Project Management Body of Knowledge (PMBoK),
que o PMBoK não é uma metodologia de gerência de projetos. É sim uma coletânea bastante
vasta e aprofundada de experiências de gerenciamento de projetos colhidas ao redor do
mundo, com vários especialistas, e que depois é transformada em um conjunto de melhores
práticas a serem seguidas.
Deste seu caráter de agregação de experiências é que surge sua primeira
característica marcante: um gerente de projetos que esteja frente ao seu primeiro projeto até
poderá saber como conduzir este projetos a partir de experiências anteriores. Não terá sucesso,
entretanto, em adquirir o PMBoK e tentar implantar todas as suass práticas já de início.
Muitos dos conceitos utilizados no PMBoK esperam que haja um conhecimento mínimo, uma
experiência mínima, sobre a gerência de projetos. E isto não se dá a uma dificuldade criada
propositadamente pelo PMI (Project Management Institute). Este conhecimento é necessário
para que a pessoa, ao utilizar as práticas do PMBoK, tenha discernimento em adaptar a sua
realidade ao projeto que está conduzindo. Caso contrário, haverá um sufocamento com a
quantidade de processos existentes, que poderão não ser necessários ao projeto em particular.
A utilização do PMBoK, em sua completude, em projetos de pequeno porte,
poderá resultar em um maior gasto de tempo e recursos com práticas que não terão resultados
concretos ou apreciáveis. Estes mesmos ensinamentos, entretanto, podem ser utilizados
integralmente quando um projeto possui um porte maior, ou mesmo pode-se chegar ao ponto
onde o Gerente de Projeto sinta necessidade de ir além do que o PMBoK apresenta, e assim
acabe por utilizar partes de outros ensinamentos sobre gerenciamento de projetos.
199
1. A integração do PMBoK com metodologias rápidas de de desenvolvimento
Por exemplo, uma das aparentes incompatibilidades que podem existir, para um
Gerente de Projetos, é como desenvolver projetos utilizando metodologias ágeis (por
exemplo, o SCRUM), e ao mesmo tempo tentar aplicar o PMBoK.
A integração entre estes conhecimentos é perfeitamente possível, pois enquanto o
SCRUM poderá ser utilizado para a obtenção das pequenas entregas do projeto, o PMBoK é
utilizado para o gerenciamento de alto nível das atividades. Ou seja, enquanto o SCRUM seria
utilizado para os pacotes de trabalho, o PMBoK seria responsável por cuidar da gerência de
custos, de aquisições, de comunicações, dos riscos (talvez em um nível macro). E assim
poder-se-ia unir o melhor de cada mundo: ao mesmo tempo que se tenha um gerenciamento
ágil e pouco burocrático dos entregáveis, haveria um gerenciamento robusto e bastante
estruturado do projeto como um todo.
E o mesmo se dá à integração com qualquer outra metodologia que vise uma
maior agilidade, ou que seja desenvolvida tendo-se como objetivo apenas um determinado
conjunto de atividades (por exemplo, específico para o desenvolvimento de softwares).
Conforme haja maior conhecimento pelo gerente de projeto, melhores resultados
serão obtidos pela tentativa de integração entre processos de fontes diferentes.
2. A adequação do PMBoK aos projetos de pequeno porte
O mesmo raciocínio aplica-se à utilização do PMBoK em projetos de pequeno
porte, como é o caso da empresa que foi objeto deste estudo. Ao tentar utilizar todas as
recomendações e todos os processos do PMBoK, certamente o Gerente de Projeto (ou sua
equipe) terão que dedicar uma parte de seu tempo, garantindo que hava coerência entre todos
os processos.
200
Se houver, entretanto, discernimento do Gerente de Projeto (o que é conquistado,
em geral, com a experiência e com o estudo), poderá ser feita uma seleção das recomendações
que façam sentido para cada projeto. Desta forma o projeto será beneficiado pela utilização de
práticas já bastante testadas e referendadas, o que aumentará a sua chance de sucesso dentro
das restrições de tempo, custo e escopo.
3. Um "PMBoK" para cada projeto
A atividade de gerenciar um projeto é verificada cotidianamente dentro das mais
diversas áreas, por vezes mesmo sem que o executor tenha consciência que está planejando ou
executando um projeto.
Já a arte de gerenciar projetos é mais restrita. É adquirida por poucos, após muita
dedicação e muita reflexão sobre as experiências havidas. E o que diferencia a atividade da
arte não é simplesmente a obtenção do resultado de sucesso, pois mesmo projetos mal
planejados e mal executados poderão atingir os seus objetivos. A diferença surge quando o
gerente de projeto dispõe de conhecimento e de ferramentas (por exemplo, o PMBoK), e sabe
quando e como utilizar a ferramenta. Assim, para cada projeto, para cada objetivo, para cada
equipe, um conjunto diferente de processos vai sendo utilizada e vai sendo aperfeiçoada. Em
pouco tempo se tem a otimização entre a quantidade de esforço que é utilizada em um
determinado processo (por exemplo, quanto esforço é dedicado às comunicações feitas
durante o projeto) e os resultados que são obtidos.
E mesmo projetos bastante parecidos, inclusive envolvendo as mesmas pessoas,
poderão exigir um conjunto bastante diverso de práticas. Haverão casos onde durante a
execução do projeto é que se perceberá que um determinado processo está sendo necessário, e
então mesmo que com atraso este processo será iniciado. O que fará a diferença será o senso
de oportunidade da utilização da ferramenta no momento adequado, ou mesmo no momento
que ainda é possível e vantajoso o seu uso.
201
4. O PMBoK como troca de experiências
Outra característica interessante do PMBoK, dita ao início mas que será realçada
apenas agora, é que o PMBoK surgiu justamente a partir da troca de experiências entre
gerentes de projeto. Todo o esforço para compilar este conhecimento em uma obra (sujeita a
atualizações constantes, mesmo que espaçadas) decorre unicamente da contínua troca de
experiências entre os gerentes de projeto.
Assim não existem dogmas que sejam insuperáveis, pois o PMI não trabalha com
dogmas. Não há um trabalho único, construído a partir do zero, por uma pequena equipe de
pessoas.
Maior prova é a nova versão do PMBoK, lançada recentemente, que apresenta
mudanças em relação ao PMBoK 3ª edição, de 2004. Por exemplo, houve uma simplificação
no processo de aquisições, com os itens "solicitar respostas de fornecedores" e "selecionar
fornecedores" sendo substituídos apenas pelo item "conduzir aquisições". Ou, em outro
exemplo, a eliminação do processo de "elaboração preliminar de escopo".
Desta forma verifica-se que o PMBoK, que já era bastante completo em sua 3ª
edição, pode ser otimizado e aperfeiçoado com a verifcação de como era feita a sua utilização.
E certamente sofrerá novas revisões no futuro, conforme haja o amadurecimento das práticas
e processos que são recomendados agora.
5. Conclusão
O PMBoK possui um conhecimento enorme compilado em seus processos. Este
conhecimento decorre da troca de experiências entre diversos gerentes de projeto, e a sua
compilação em uma obra. Desta fonte bastante diversificada é natural que existam processos
202
que pareçam não serem úteis em todos os projetos, seja por sua área de atuação, seja por seu
porte.
Cabe ao gerente de projeto saber utilizar todo este conhecimento em cada projeto
que for fazer parte, dando maior ênfase aos processos cujos resultados sejam compensadores,
quando comparados ao esforço necessário ao seu gerenciamento.
Isto também é válido para as integrações que possam se fazer necessárias entre as
recomendações do PMBoK e os conhecimentos oriundos de outras fontes, seja de outras
técnicas de gerenciamento de projetos, seja de metodologias específicas.
Ao saber fazer estas ponderações o gerente de projeto estará mais habilitado a
utilizar os conhecimentos que cada projeto seu exigir, evitando que haja um desperdício
grande de energia em processos que não sejam fundamentais para um determinado projeto.
Referência bibliográfica
BARCAUI, A.. Gerência de Projetos Arte ou Liderança?. Revista Mundo PM, n.09, ano2, jun/jul.2006.
DANTAS, F. Comparativo PMBOK 2004 x PMBOK 2008. Disponível em http://certificacaopmp.wordpress.com/2008/09/01/comparativo-pmbok-2004-x-pmbok-2008/. Acesso em 13 de janeiro de 2009.
PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute. Newton Square, PA. EUA, 2004.
PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute. Newton Square, PA. EUA, 2008.
SOBH, T. e FITSILIS, P. Comparing PMBOK and Agile Project Management software development processes. In: Advances in Computer and Information Sciences and Engineering. Amsterdã, 2008: Springer Netherlands. pags 378-383.
WUTTKE, T.. PMBOK® Guide version 2008. Disponível em http://www.threon.com/en/news/details/article/pmbokR-guide-version-2008/. Acesso em 05 de março de 2009.