UNIVERSIDADE SÃO JUDAS TADEU
Curso de Pós-Graduação
Gerência de Projetos com Ênfase nas Práticas do PMI
Vanessa Rodrigues de Lima
Conceitos e métodos utilizados em gerenciamento de
projetos
São Paulo
2009
UNIVERSIDADE SÃO JUDAS TADEU
Curso de Pós-Graduação
Gerência de Projetos com Ênfase nas Práticas do PMI
Vanessa Rodrigues de Lima
Conceitos e métodos utilizados em gerenciamento de
projetos
Monografia apresentada ao curso de
Gerência de Projetos com Ênfase nas
Práticas do PMI da Universidade São
Judas Tadeu como requisito parcial para
conclusão do curso de especialização em
2009
Orientador: Prof. Nelson Rosamilha
São Paulo
2009
UNIVERSIDADE SÃO JUDAS TADEU
Curso de Pós-Graduação
Gerência de Projetos com Ênfase nas Práticas do PMI
Vanessa Rodrigues de Lima
Conceitos e métodos utilizados em gerenciamento de
projetos
Monografia apresentada ao curso de
Gerência de Projetos com Ênfase nas
Práticas do PMI da Universidade São
Judas Tadeu como requisito parcial para
conclusão do curso de especialização em
2009.
Aprovada em Outubro de 2009.
Orientador: Prof. Nelson Rosamilha
4
AGRADECIMENTOS
A minha família pelo incentivo a fazer um curso de Pós-Graduação
Ao meu noivo pela paciência e compreensão no decorrer do curso
Ao meu grupo de estudo (Fernanda Pereira, Fernanda Mendes, Ricardo Henrique e João) pela
amizade, companheirismo e pela troca de conhecimento.
Aos meus professores do curso por dividirem comigo e meus colegas de sala suas
experiências e conhecimentos agregando ainda mais o nosso saber.
Ao meu professor orientador Nelson Rosamilha que me ajudou no desenvolvimento da minha
monografia desde a idéia inicial.
5
RESUMO
LIMA, Vanessa Rodrigues de. Conceitos e métodos utilizados em gerenciamento
de projetos. Curso de gerenciamento de projetos com ênfase no PMI da
Universidade São Judas Tadeu. São Paulo p.65, 2009
Esta pesquisa teve por objetivo demonstrar que a necessidade de um
gerenciamento de projetos eficaz tem importância fundamental para o sucesso de
projetos, uma vez que a incerteza é inerente a todo projeto, tornando este tipo de
gerenciamento relevante. Independente do método escolhido para gerenciar o
projeto, tradicional ou ágil, o importante utilizá-los para garantir um maior
planejamento e controle das atividades.
Observamos que as organizações estão mais apoiadas em modelos
tradicionais durante o gerenciamento de seus projetos, porém os métodos ágeis estão
ganhando espaço principalmente em projetos de desenvolvimento de software as
quais são estruturadas de modo a atender a natureza mutável e dinâmica do processo
de concepção do sistema.
Não podemos afirmar e nem garantir qual método é o melhor para utilização,
pois dependem de um conjunto de fatores que podem levar o projeto ao sucesso
assim como levá-lo ao fracasso. Dependem da organização, seu segmento, sua
estrutura, os envolvidos e o projeto a ser gerenciado.
Palavras chaves: Gerenciamento de projetos, PMBOK, SCRUM, Métodos ágeis,
Métodos Tradicionais.
6
ABSTRACT
LIMA, Vanessa Rodrigues. Concepts and methods used in project management.
Course on project management with emphasis on the PMI of São Judas Tadeu
University. Sao Paulo p.65, 2009.
This study aimed to demonstrate the need for an effective project
management is crucial for project success, since uncertainty is inherent in every
project, making this type of management relevance. Regardless of the method
chosen to manage the project, traditional or agile, it's important to use them to ensure
a better planning and control activities.
We observed that more organizations are relying on traditional models for
managing their projects, but the agile methods are gaining ground mainly in projects
of software development which are structured to meet the changing nature and
dynamics of the system design.
We can not claim nor guarantee that the best method is to use, because they
depend on a number of factors that could cause the project to success and take it to
failure. Depend on the organization, its industry, its structure, stakeholders and the
project to be managed.
Key words: Project management, PMBOK, SCRUM, Agile methods, traditional
methods.
7
SUMÁRIO
1INTRODUÇÃO
10
2OBJETIVO
11
3REFERENCIAL TEÓRICO
12
3.2O que é projeto?.....................................................................................................12
3.3Gerenciamento de um Projeto...............................................................................13
3.4Duração do projeto................................................................................................14
3.5O ciclo de vida do projeto.....................................................................................14
3.6Fases do ciclo de vida do projeto..........................................................................15
3.7Benefícios em Gerenciar projetos.........................................................................18
3.8Porque os projetos fracassam?...............................................................................19
3.9Administração, Gerencia e Gestão........................................................................19
4A EVOLUÇÃO DO GERENCIAMENTO DE PROJETOS..............................21
4.1A evolução no gerenciamento de projetos.............................................................21
4.2O Moderno Gerenciamento de Projetos – MGP....................................................23
5CONCEITOS IMPORTANTES EM PROJETOS..............................................25
5.1As Lições Aprendidas............................................................................................25
5.2Benchmarking........................................................................................................26
5.2.1Tipos de Benchmarking......................................................................................29
5.3PMBOK.................................................................................................................29
5.4PMI 33
5.5Melhoria Continua.................................................................................................33
6MATURIDADE E MELHORES PRÁTICAS.....................................................35
6.1Melhores Práticas em Gestão de Projetos.............................................................35
6.2Maturidade na gestão de Projetos..........................................................................37
7METODOLOGIA
38
7.1Sobre Metodologia................................................................................................38
7.2Benefícios de uma metodologia – padrão.............................................................40
7.3SCRUM.................................................................................................................41
7.3.1Breve História................................................................................................42
7.3.2Como funciona o Scrum?..............................................................................42
7.3.3Níveis de planejamento.................................................................................43
7.3.4Papéis e responsabilidades............................................................................45
7.3.5Ferramentas utilizadas..................................................................................46
7.3.6Prós na utilização do Scrum.........................................................................47
7.3.7Contras na utilização do Scrum...................................................................49
8GERENCIAMENTO DE TEMPO.......................................................................50
8.1Introdução..............................................................................................................50
8.2Gerenciamento Ágil...............................................................................................50
8.3Gerenciamento de Projetos Tradicional................................................................51
8.4Gestão de Tempo pelo PMBOK............................................................................51
9COMPARAÇÃO DA GESTÃO DE TEMPO NOS MÉTODOS AGIL E
TRADICIONAL
53
9.1Estimativa da duração das atividades....................................................................53
8
9.1.1Estimativa no Gerenciamento Ágil..............................................................53
9.1.2Estimativa das durações das atividades – Gerenciamento Tradicional...55
9.2Controle do Cronograma ou atividades.................................................................56
9.2.1Controle do Cronograma – Gerenciamento tradicional............................57
9.2.2Gráfico de Burndown – Gerenciamento ágil..............................................57
9.3Estimando dias X horas.........................................................................................59
10 CARACTERISTICAS DOS MÉTODOS AGIL E TRADICIONAL.............60
10.1Características do Gerenciamento Tradicional....................................................60
10.2Características do Gerenciamento Ágil...............................................................60
11 CONCLUSÃO
62
12 REFERÊNCIAS BIBLIOGRÁFICAS..............................................................64
ÍNDICE DE FIGURAS
Figura 1: Classificação por duração - FONTE: (KEELLING, 2002)..................14
Figura 2: Macroprocesso no desenvolvimento do projeto – FONTE: Gestão de
Projetos (MENEZES, 2003)
16
Figura 4: Interação de grupos de processos em um projeto – Fonte PMBOK 3
ed., 2004
18
9
Figura 5: Áreas de conhecimento – FONTE: Manual Prático do Plano de
Projeto (VARGAS, 1998)
31
Figura 6: Mapeamento entre os processos, os grupos de processos e as áreas de
conhecimento de gerenciamento de projetos – Fonte (PMBOK 3ed., 2003).......33
Figura 7: Fatores a serem considerados para melhoria continua – FONTE: As
Melhores práticas (KERZNER, 2006)....................................................................34
Figura 8: Projetos fracassados em empresas com gestão de projetos – FONTE:
As melhores práticas (KERZNER, 2006)...............................................................36
Figura 9: As fases do ciclo de vida da maturidade de um projeto – FONTE: As
melhores práticas (KERZNER, 2006)....................................................................38
Figura 10: Principais modelos de melhores práticas - FONTE: Implantando a
Governança de TI
40
Figura 12: Níveis de planejamento do SCRUM.....................................................44
Figura 13: Taskboard
46
Figura 14: Taskboard com o gráfico de Burndown..............................................47
Figura 15: Comparação entre os modelos Ágil e Tradicional..............................51
Figura 16: Gráfico de Burndown............................................................................58
Figura 17: Sinais de alerta no gráfico de Burndown.............................................59
Figura 18: Quadro Comparativo entre as áreas de conhecimento no
gerenciamento tradicional e ágil 62
10
1
INTRODUÇÃO
Desenvolvido pelo Project Management Institute – PMI®, o PMBOK (Project
Management Body of Knowledge) é utilizado cada vez com mais frequência por
gerentes de projetos em diferentes segmentos de empresas. O PMBOK é um conjunto
de boas práticas e conhecimentos em gerência de projetos compilados na forma de um
guia conhecido como o Guia do Conjunto de Conhecimentos em Gerenciamento de
Projetos, ou Guia PMBOK®.
Os processos de gerenciamento descritos pelo PMBOK são genéricos e amplos de
forma que pode ser usado para qualquer tipo de projeto. O segredo está em saber
adaptar e usar as práticas da melhor forma possível para o projeto e/ou empresa em
questão.
O Scrum é um modelo também utilizado como um guia de boas práticas para o alcance
de objetivos em gerenciamento de projetos. Conhecido por ser uma metodologia ágil, o
Scrum foi criado e está mais voltado para a área de desenvolvimento de software e hoje
em dia está ganhando visibilidade em organizações de diferentes segmentos e vem se
tornando popular a cada dia. Isso porque devido a constantes mudanças que ocorrem
nos projetos está despertando um grande interesse em desenvolvimento ágil nas
aplicações.
O ponto-chave para diminuir a lacuna existente entre o uso das abordagens “tradicional”
e “ágil” está em considerar, na escolha de uma ou de outra, as características do projeto
a ser desenvolvido, ou seja, buscar aplicar a metodologia correta para o trabalho a ser
realizado. (KNIBERG, 2004)
De acordo com KERZNER, talvez o maior benefício de uma metodologia seja a
aceitação e o reconhecimento que encontram entre seus clientes.
A abordagem ágil (SCRUM), assim como a abordagem tradicional (PMBOK), possui
características positivas e negativas, sendo que a principal diferença entre as duas está
no conjunto de pressupostos de cada uma. É possível afirmar, ainda, que existe uma
sinergia muito grande entre as duas metodologias, ou seja, uma pode complementar a
outra.
11
2
OBJETIVO
Este trabalho tem como objetivo explanar idéias sobre modelos, metodologias, melhores
práticas e conceitos relacionados a projetos que estão sendo utilizados pelas empresas
em diferentes segmentos para gerenciar projetos e garantir qualidade nos processos. Ao
final do trabalho será comparada a área de conhecimento de tempo do modelo PMBOK
(gerenciamento tradicional) com o Scrum (gerenciamento ágil em projetos) para
identificarmos as diferenças e semelhanças entre um e outro.
12
3
REFERENCIAL TEÓRICO
3.1
Porque gerenciar projetos
Inúmeros são os fatores eu nos impulsionam a criar desenvolver e gerenciar projetos.
Alguns desses fatores podem ser perceptíveis a olho nu, dada a voracidade dos
movimentos presentes no ambiente. Outros fatores são menos perceptíveis. Precisam da
observação cuidadosa do gestor para perceber qual tipo de sistema produtivo ele tem em
suas mãos para que faça uma escolha adequada da metodologia e das ferramentas a
serem empregadas em sua gestão. Identificar uma atividade inovadora trabalhá-la
adequadamente são atribuições que um gestor deve ter.
Fatores internos que demandam projetos nas organizações:
•
Melhoria em produto, novo produto, melhoria interna, mudança organizacional,
produto único, gestão estratégica da empresa, trabalhando com prazos e recursos
limitados compartilhando recursos escassos.
•
Mudanças externas que impactam as organizações e seus colaboradores bem
como promovem a estruturação e o desenvolvimento de projetos
•
Parcerias, crise do Estado, iniciativa privada, distribuição de renda,
desintermedição, desverticalização, preservação ambiental, competitividade e
globalização (MENEZES, 2003).
3.2
O que é projeto?
Definição para projetos segundo o PMI “um empreendimento único que deve apresentar
um inicio e um fim claramente definido e que conduzido por pessoas possa atingir seus
objetivos respeitando os parâmetros de prazo custo e qualidade”.
Nessa definição, vários elementos importantes devem ser ressaltados. O primeiro deles
é que um empreendimento, portanto deve envolver uma série de movimentos e ações
para que possa vir à tona. Alguém deve responsabilizar-se por empreendê-lo: o gerente
do projeto.
Todo projeto deve ter seu inicio bem definidos para que as organizações ou unidades de
uma organização que participem dele possam firmemente reservar recursos para
poderem participar – com uma data definida – do projeto. A sinalização de seu fim
13
serve para marcar a liberação dos recursos para suas unidades ou organizações de
origem.
A definição clara de seu objetivo é fundamental para que todos os participantes possam
“olhar para o mesmo norte”, para a mesma referência e somar seus esforços numa única
direção e sentindo.
Já os parâmetros de prazo, custo e qualidade devem servir como guias permanentes
durante o desenvolvimento do projeto. Mantê-los plenamente atendidos é uma tarefa
árdua não para o gestor do projeto, mas também para todos os especialistas que delem
participam. Gerir esforços para que isso aconteça é fundamental (MENEZES, 2003)
3.3
Gerenciamento de um Projeto
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e
técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento
de projetos é realizado através da aplicação e da integração dos seguintes processos de
gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e
controle, e encerramento. O gerente de projetos é a pessoa responsável pela realização
dos objetivos do projeto.
Gerenciar um projeto inclui:
•
Identificação das necessidades
•
Estabelecimento de objetivos claros e alcançáveis
•
Balanceamento das demandas conflitantes de qualidade, escopo, tempo e custo
•
Adaptação das especificações, dos planos e da abordagem às diferentes
preocupações e expectativas das diversas partes interessadas.
Os gerentes de projetos freqüentemente falam de uma “restrição tripla”—escopo, tempo
e custo do projeto—no gerenciamento de necessidades conflitantes do projeto. A
qualidade do projeto é afetada pelo balanceamento desses três fatores. Projetos de alta
qualidade entregam o produto, serviço ou resultado solicitado dentro do escopo, no
prazo e dentro do orçamento. A relação entre esses fatores ocorre de tal forma que se
algum dos três fatores mudar, pelo menos um outro fator provavelmente será afetado.
Os gerentes de projetos também gerenciam projetos em resposta a incertezas. Um risco
14
do projeto é um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou
negativo em pelo menos um objetivo do projeto.
O termo “gerenciamento de projetos” às vezes é usado para descrever uma abordagem
organizacional ou gerencial do gerenciamento de projetos e de algumas operações já em
andamento, que podem ser redefinidas como projetos, o que também é chamado
“gerenciamento por projetos”. Mais organizações estão usando o “gerenciamento por
projeto”. Isso não significa dizer que todas as operações podem ou devem ser
organizadas em projetos. Embora um entendimento de gerenciamento de projetos seja
essencial para uma organização que esteja utilizando o “gerenciamento por projetos”,
uma discussão detalhada da abordagem em si está fora do escopo desta norma.
(PMBOK 3ed., 2004).
Quando um projeto é bem estruturado e se desenvolve tranquilamente, seus desafios
podem ser estimulantes e prazerosos, mas sendo mal definido ou mal gerenciado pode
se tornar um pesadelo para todos os envolvidos, resultar em desastre financeiro e
prejudicar muitas carreiras promissoras (KEELLING, 2002)
3.4
Duração do projeto
A classificação dos projetos tem a ver com as práticas de seus patrocinadores e
proprietários. Por conveniência, muitas pessoas classificam os projetos em termos de
duração.
As três mais comuns são ilustradas na figura a seguir.
Curto Prazo
Longo Prazo
Até 2 anos
1mês à 1 ano
Ano 0
1
Mais de 2 anos Médio
Prazo
2
3
4
5 ...
Figura 1: Classificação por duração - FONTE: (KEELLING, 2002)
3.5
O ciclo de vida do projeto
10
15
Todo projeto passa por uma série de fases desde sua concepção até seu ponto de
conclusão. Cada fase tem suas próprias necessidades e características. À medida que o
projeto passa por essas fases, o montante cumulativo de recursos e tempo despendido
aumentará e o prazo e recursos restantes diminuirão.
Esta série de fases é conhecida como ciclo de vida do projeto. A compreensão do ciclo
de vida é importante para o sucesso na gestão de projetos, porque acontecimentos
significativos ocorrem em progressão lógica e cada fase deve ser devidamente planejada
e administrada. A familiaridade com o ciclo de vida do projeto capacita os envolvidos a
entender a seqüência lógica dos eventos a reconhecer limites ou “marcos” e, a saber, em
que ponto se encontra o projeto no continuum de atividades que se sucedem desde o
inicio até o fim. Ajuda o gerente a prever as mudanças de estilo e ritmo, o aumento da
pressão à medida que as despesas se acumulam e o tempo e os recursos se reduzem a
reconhecer quando e devem fazer inspeções espaciais revisões ou reavaliações de
prioridades e a entender as necessidades de cada fase.
O ciclo de vida também torna-se um instrumento de qualidade. Isso se aplica a
condução do projeto em si já que as expectativas de qualidade são estabelecidas entre
uma fase e outra, e aos seus deliverables ou produtos, onde o ciclo de vida fornece
pontos de referência para confirmação da qualidade do produto. Muitos problemas de
qualidade de projeto podem ser previstos por uma sólida avaliação de viabilidade de
riscos na fase conceitual e por um planejamento cuidadoso e especificações precisas na
fase de planejamento (KEELLING, 2002).
3.6
Fases do ciclo de vida do projeto
O objetivo da administração dos projetos e o de alcançar controle adequado do projeto
de modo a assegurar sua conclusão no prazo e no orçamento, obtendo a qualidade
estipulada. Podemos afirmar que o desenvolvimento de um projeto ocorre mediante os
vários processos básicos que se sobrepõem. Esses processos são demonstrados na figura
a seguir. As flechas indicam trocas de informações e documentos entre diversos
macroprocessos. (MENEZES, 2003)
Iniciação
Planejamento
Controle
Execução
Encerramento
16
Figura 2: Macroprocesso no desenvolvimento do projeto – FONTE: Gestão de Projetos (MENEZES, 2003)
Genericamente o ciclo de vida de um projeto pode ser dividido em fases características
•
Iniciação: Fase inicial do projeto, quando uma determinada necessidade é
identificada e transformada em um problema estruturado a ser resolvido por ele.
Nessa fase, a missão e o objetivo do projeto são definidos bem como as
melhores estratégicas são identificadas e selecionadas.
•
Planejamento: E a fase responsável por detalhar tudo aquilo que será realizado
pelo projeto incluindo cronogramas, interdependências entre as atividades,
alocação de recursos envolvidos, analise de custos e etc. para que, no final dessa
fase os planos auxiliares de comunicação, qualidade, risco, suprimentos e
recursos humanos também são desenvolvidos.
•
Execução: E a fase que materializa tudo aquilo que foi planejado anteriormente.
Qualquer erro cometido nas fases anteriores fica evidente durante essa fase.
Grande parte do orçamento e do esforço do projeto e consumida nessa fase.
•
Controle: E a fase que acontece paralelamente ao planejamento operacional e a
execução do projeto. Tem como objetivo acompanhar e controlar aquilo que está
sendo realizado pelo projeto, de modo a propor ações corretivas preventivas no
menor espaço de tempo possível após a detecção da anormalidade. O objetivo do
controle e comparar o status atual do projeto com o status previsto pelo
planejamento tomando ações corretivas em caso de desvio.
•
Finalização: E a fase quando a execução dos trabalhos é avaliada através de uma
auditoria interna ou externa, os livros e documentos do projeto são encerrados e
todas as falhas ocorridas durante o projeto são discutidas e analisadas para que
erros similares não ocorram em novos projetos conhecido como lições
aprendidas. (VARGAS, 1998).
17
Figura 3: Nível típico de custos e de pessoal do projeto ao longo do seu ciclo de vida – FONTE: PMBOK 3ed, 2004
18
Figura 4: Interação de grupos de processos em um projeto – Fonte PMBOK 3 ed., 2004
Os projetos podem ser aplicados em praticamente todas as áreas de conhecimentos
humano incluindo os trabalhos administrativos, estratégicos e operacionais bem como a
vida pessoal de cada um. As principais características dos projetos são a temporariedade
e a individualidade do produto ou serviço a ser desenvolvido pelo projeto, a
complexidade e a incerteza.
Temporariedade significa que todo o projeto apresenta um inicio e um fim definido, ou
seja, é um evento com duração finita determinada em seu objetivo. Individualidade do
produto ou serviço significa realizar algo que não tenha sido realizado antes. Como o
produto de cada projeto é único suas características precisam ser elaboradas de maneira
progressiva de modo a garantirem as especificações do produto ou serviço
desenvolvido. (VARGAS, 1998)
3.7
Benefícios em Gerenciar projetos
•
Evitar surpresas durante a execução;
•
Permite desenvolver diferenciais competitivos e novas técnicas uma vê que
toda a metodologia está sendo estruturada.
•
Antecipa as situações desfavoráveis que poderão ser encontradas para que
ações preventivas e corretivas possam ser tomadas antes que essas situações
se consolidem como problema.
•
Adaptar os trabalhos ao mercado consumidor e ao cliente
•
Disponibilizar os orçamentos antes do inicio dos gastos
•
Agiliza as decisões já que as informações estão estruturadas e
disponibilizadas.
19
•
Aumenta o controle gerencial de todas as fases a serem implementadas
devido ao detalhamento ter sido realizado.
•
Facilita e orienta a revisões da estrutura do projeto que forem decorrentes de
modificações no mercado ou no ambiente competitivo, melhorando a
capacidade de adaptação do projeto.
3.8
•
Otimiza a alocação de pessoas, equipamentos e materiais necessários.
•
Documenta e facilita as estimativas para futuros projetos. (VARGAS, 1998)
Porque os projetos fracassam?
Os projetos fracassam ou são abandonados por diversas razões e muitos resultam apenas
em sucesso parcial, quando os objetivos não são alcançados no prazo os custos sobem
alem dos limites aceitáveis, ou os níveis estipulados de qualidade ou realização ficam
comprometidos.
Os grandes projetos do passado eram notoriamente arriscados. O fracasso em fornecer
em resultado condizente com as expectativas ou de concluir o projeto no prazo e dentro
do orçamento era comum e quanto maior o projeto maior o receio da escalada nos
custos. Muitos empreendimentos ambiciosos eram abandonados a um custo elevado
após esforço prolongado, outros eram concluídos a um custo muito maior que seu
orçamento original (por exemplo Opera, em Sydney e o Eurotúnel). Nos últimos anos
importantes lições foram aprendidas houve grandes avanços nas técnicas de
administração. (KEELLING, 2002)
3.9
Administração, Gerencia e Gestão
Administração Gerencia e Gestão são sinônimos que estão diferindo apenas quanto ao
nível em que se aplicam em uma organização.
Administrar: e seus derivados (administrador, administração), referem-se aos problemas
típicos das organizações: finanças (contabilidade, taxas e impostos etc.),
pessoal
(efetivo, contratações, direitos e deveres etc.), patrimônio (imóvel, maquinas, veículos)
vendas etc.
Gerenciar e seus derivados (gerente, gerenciamento, gerencia) referem-se às ações
situadas em um nível especifico da organização: seja um departamento: gerencia de
20
produção, gerencia de marketing seja um projeto gerencia de projeto ou no mais
elevado nível voltado para a interação da organização com o ambiente: gerencia
estratégica.
Gerir e seus derivados (gestor, gestão) referem-se, no âmbito do projeto ou no da
administração da organização, a parcela das atribuições do gerente do projeto ou do
administrador, respectivamente. No projeto a gestão é uma das partes da gerencia,
geralmente delegada pelo gerente. Algumas delas são objeto e títulos das normas ISSO,
abrangendo toda a organização como a da qualidade (família de normas ISSO 9000), a
gestão ambiental (família de norma ISSO 14000); ou no âmbito do projeto, como a
gestão da qualidade do projeto (norma ISSO 10006), a gestão da configuração (norma
ISSO 10007) etc.
Gerenciamento é uma disciplina uma área de conhecimento: gerenciamento estratégico,
gerenciamento de projeto, gerenciamento de marketing etc. E gerencia é uma função em
que se aplicam objetivamente os conhecimentos, habilidades e recursos de um dado
gerenciamento: gerencia estratégica, gerencia de projeto, gerencia de marketing.
Assim o gerenciamento estratégico é uma arte e a ciência de formular, implementar e
avaliar linhas de ação multidepartamentais referentes as interações da organização com
seu ambiente para atingir seus objetivos de longo prazo, relativos a seus produtos,
mercado, clientes, concorrentes, sociedade etc.
E gerencia estratégica é a aplicação dos conhecimentos, habilidades e recursos do
gerenciamento estratégico em uma organização.
De forma idêntica, o gerenciamento de projetos pressupõe em conseqüência a definição
de um conjunto de conhecimentos, enquanto a gerencia de projetos consiste na
aplicação destes conhecimentos apoiada por habilidade e aptidões do gerente, para
conduzir um determinado projeto.
Renomadas instituições internacionais dispõem de definições precisas destes
conhecimentos e, com base nelas, certificam profissionais em gerencia de projeto.
Todas elas, entretanto, estão desenvolvendo esforços para unificar conceitos, critérios,
metodologias etc. a fim de uniformizar a profissão de gerente de projeto. Entre elas,
citam-se duas de maior expressão: o Project Management Institute- PMI que edita
“a Guide to Project Management Body of knowledge – PMBOK Guide e o
21
internacional Project Management Association – IPMA, que publica o “IPMA
Competence Baseline”. (VALERIANO, 2001)
4
4.1
A EVOLUÇÃO DO GERENCIAMENTO DE PROJETOS
A evolução no gerenciamento de projetos
Foi mencionado que uma organização tem, alem da gerencia estratégica, a gerencia
administrativa e a operacional, e que a solução dos problemas existentes em cada um
destes níveis pode envolver criação ou alteração de operações correntes (administrativas
e de produção), alterações estruturais e funcionais na organização etc. Para cada uma
destas soluções será necessário criar um ou mais projetos específicos. Para
administração de projetos foram desenvolvidos conhecimentos, habilidades, ferramentas
e técnicas em um processo denominado de administração de projetos ou gerenciamento
de projetos. (VALERIANO, 2001)
A história nos relata grandes feitos da humanidade que podem ser classificadas como
projetos. Para melhor clareza, convém repetir que o projeto é um empreendimento
temporário realizado para criar um produto ou serviço singular.
Com muita probabilidade, os mais antigos projetos deviam estar voltados para as
necessidades mais básicas, como o preparo e execução de uma campanha de caçada, a
instalação de uma agricultura e criação de dispositivos e sistemas de segurança ou de
defesa. Todos estes empreendimentos, ainda que primitivos, eram premidos por prazos
para alcançar objetivos preestabelecidos e tinham algum tipo de organização e de
administração.
Por ser singular, o produto do projeto distingui-se, de alguma forma, de todos quantos
os precederam e por ser temporário, todo projeto tem inicio e término definido.
Grandes construções da antiguidade, criaturas dos respectivos projetos, são as pirâmides
do Egito e as dos maias, a Grande Muralha da China. Mais atuais, citam-se o Canal de
Suez e do Panamá, o túnel sob o canal da Mancha e o oleoduto Trans-Alasca.
Notáveis expedições foram de cuidadosos projetos, sejam aqueles que criáramos
veículos utilizados (vikings e portugueses, por exemplo) sejam os que prepararam
22
empreendimentos propriamente ditos, como as viagens pioneiras de Magalhães e
Colombo, as explorações submarinas e da estratosfera do Prof. Piccard, (August Piccard
– 1884 a 1962 – físico e professor suíço, foi a primeira pessoa a explorar a estratosfera
ao ultrapassar 16.000 metros de altitude em uma câmara pressurizada, suspensa por
balão – 1932) para citar apenas estas, precursoras dos foguetes e das naves das
explorações espaciais. (VALERIANO, 2001)
As características de unicidade do produto e da temporariedade dos projetos os
distinguem dos demais resultados e das outras atividades exercidas em uma organização
por serem estas repetitivas, com produtos ou serviços extremamente iguais e uma vez
iniciados a produção, não haver prazo estabelecido para terminá-la. Um aspecto crítico
para o sucesso dos projetos é o da sua administração ou gerencia de projetos, definida
como sendo a “aplicação de conhecimentos, habilidades e recursos nas atividades de um
projeto a fim de atingir e exceder as necessidades e as expectativas das partes
interessadas” (PMBOK 3ed., 2004).
O gerenciamento de projeto evoluiu muito impelido pelas pressões cada vez mais fortes,
para um estágio de larga aplicação em quase todas as formas de atuação humanas. Podese dizer que a evolução do gerenciamento de projetos comporta três períodos
1. Gerenciamento empírico baseado nas qualidades inatas do gerente e de seus
auxiliares ou nos procedimentos precedentes muito mais como “arte”, como
“sentimento”do que como “técnica”. Foram o caso dos “arquitetos”e dos
“construtores”das grandes obras da antiguidade e da Idade Média, os feitos dos
grandes chefes militares e dos notáveis exploradores.
2. Gerenciamento clássico ou tradicional, geralmente considerado aquele a partir
das décadas de 1940 ou 1950, com os empreendimentos predominantemente de
engenharia, nas áreas de defesa, na aeronáutica e, mais recentemente, na
espacial. São projetos estruturados e planejados, executados e controlados, nos
quais o gerente, administrando os recursos humanos e materiais, emprega
processos existentes ou criados especialmente para o uso no projeto, com vistas
a obter o produto com o desempenho especificado, dentro dos limites de custos
previstos e no prazo esperado. Em geral, aqui os projetos são essencialmente
técnicos, de grande complexidade e caracterizados pelos altos custos, pelo vulto
dos problemas envolvidos e pelos prazos relativamente longos.
23
3. Mais recentemente (inicio da década de 1009), teve começo o chamado moderno
gerenciamento de projetos – MGP. Voltado para uma ampla gama de aplicações,
esse tipo de abordagem gerencial perdeu o caráter tipicamente técnico e vem
sendo usado em toda sorte de problemas empresariais. Tem-se revelado
ferramenta extraordinária e vem permitindo as organizações responder com
extrema rapidez as solicitações e pressões de seu ambiente próximo ou remoto,
devido principalmente ao rápido ciclo de vida dos produtos a velocidade da
evolução tecnológica e a acirrada competição, já em caráter global.
(VALERIANO, 2001)
4.2
O Moderno Gerenciamento de Projetos – MGP
As técnicas
os processos de gerenciamento de projetos passaram então a ser
empregados nos problemas mais diversos, como nas mudanças da estratégia, nas
alterações organizacionais, nos recursos humanos, nos desenvolvimentos de novos
processos e como antes, nos desenvolvimentos de novos produtos. A duração e os
custos dos projetos são, em sua maioria, muito inferiores aos dos projetos tradicionais.
No gerenciamento tradicional, ainda desprovido dos meios eletrônicos de coleta e
tratamento de dados e difusão de informações, o gerente era assoberbado pela profusão
de tarefas para controlar os cronogramas, os orçamentos e os recursos, em adição a
coordenação de sua equipe no sentido de alcançar o objetivo de seu projeto. Com o
crescente uso dos PCs, de redes apropriadas e de software possantes, o gerente de
projetos passa a dispor de mais tempo para estender seus cuidados em outras direções.
A descentralização, o gerenciamento simultâneo (ou engenharia simultânea), a gestão da
qualidade e a gestão ambiental também largamente aplicado nos projetos, com
criteriosa delegação de atividades administrativas e técnicas especializadas e
caracterizam o gerente de projeto como um especialista técnico, sendo cada vez mais
um administrador e coordenador de processos, de pessoas e de equipes. Juntando estas
evoluções com as necessidades de pronta resposta das organizações as oportunidades e
ameaças cada vê mais freqüentes, o resultado foi o progressivo emprego dos recursos e
atividades de gerenciamento de projeto nos assuntos empresariais.
Em conseqüência, os modernos projetos passam a envolver muitas outras entidades
alem daquelas que eram objeto de consideração no tradicional gerenciamento de
projetos. Assim, o MGP, muito mais amplo que seu predecessor, tem um universo de
24
interesses mais abrangente. O gerenciamento tradicional girava entre desempenho
(necessidade do cliente), custos e prazos, enquanto o MGP, alem desses requisitos
preocupa-se em satisfazer e exceder as necessidades e expectativas de todas as partes
interessadas a começar pelo cliente, o moderno gerenciamento de projetos tem suas
preocupações também voltadas para os objetivos da própria organização, a para os
membros da equipe do projeto, para os patrocinadores e financiadores, para os
fornecedores, para os parceiros, para as organizações associadas e para a sociedade
como um todo.
Ao se despir de forma progressiva do caráter essencialmente técnico observado no
gerenciamento tradicional, consolida-se o moderno gerenciamento de projetos, cada vez
mais voltado para os problemas da organização. A convergência dos interesses da
administração da organização (gerenciamento estratégico, administrativo e operacional)
fez do gerenciamento de projeto uma tarefa familiar aos administradores e gerentes
funcionais. Cada vez mais, pessoas com experiência na administração das empresas e na
de negócios foram assumindo encargos de gerentes de projetos. Passando a ser
extensamente aplicado na administração das operações correntes com os processos e as
técnicas de planejamento e execução de projetos, o moderno gerenciamento de projetos
emerge simultaneamente. Em uma espécie de simbiose, com o que se costuma chamar
de administração por projetos.
A globalização e a expressão do emprego do gerenciamento de projetos, agora com
procedimentos uniformes, permitem a colaboração de equipes distantes em torno de um
só projeto. A web, a internet, os softwares de gerenciamento e as ferramentas de
comunicações visuais mais recentes proporcionam eficiência às equipes virtuais, com
extraordinário rendimento. O gerenciamento de projetos fica insensível à distância,
funcionando 24 horas por dia, com apoio de todos os recursos modernos.
Além disso, a grande utilização de equipes dotados de grande autonomia faz com que os
conhecimentos e habilitações gerenciais sejam disseminados por todos os participantes.
Afinal, cada parte do projeto, como se verá mais adiante, tem todas as características de
um projeto e isto conduz ao fato de que cada responsável por uma destas partes
constitutivas tem atribuições de gerente desta parte, observadas as escalas.
Como na história Patinho Feio, o gerenciamento de projetos, uma estranha,
incompreendida e espancada atividade que tentava se impor nas organizações
25
tradicionais, passa a assumir uma posição de reconhecido e respeitado instrumento
capaz de proporcionar as prementes mudanças cada vez mais freqüentes e urgentes nas
áreas estratégicas, operacionais e técnicas, e vem sendo extensivamente utilizado hoje
nas mais diferentes entidade com grandes corporações e pequenos empreendimentos;
empresas industriais, comerciais, financeiras e bancárias; instituições religiosas, sociais
e agências de governo. Desta forma, o MGP está evoluindo com muito vigor, em razão
das experiências e dos desafios que vem enfrentando. Uma visão do gerenciamento de
projeto no futuro próximo vem sendo objeto de vários estudos, congressos e seminários.
(VALERIANO, 2001)
5
5.1
CONCEITOS IMPORTANTES EM PROJETOS
As Lições Aprendidas
Para as organizações que estão constantemente envolvidas com novos projetos, e,
naturalmente, com problemas em cada um deles, desde a fase inicial até seu
encerramento, nada mais recomendável que procurar extrair o máximo das lições
aprendidas. Consistem elas na coleção organizada de erros e acertos, práticas
recomendadas e a evitar fatores determinantes de sucesso ou de fracasso fruto da
experiência constantemente atualizada e destinada a usos futuros.
Cada organização deve estabelecer a metodologia mais adequada para identificar erros e
acertos e fatores determinantes de sucesso ou fracasso. Basicamente pode-se resumir em
dois processos:
1. Um deles consiste em proceder uma avaliação crítica no término de cada projeto
ou no fim de cada importante fase dos projetos mais longos, para levantar os
erros e acertos, e principalmente, suas causas aprendendo assim as lições
oferecidas pela experiência. Estas avaliações geralmente contam com elementos
estranhos ao projeto, com suas experiências anteriores e suficiente isenção para
detectar fatos que poderiam passar despercebido pelo pessoal do projeto.
2. O outro reside na elaboração de um questionário a ser preenchido pelos gerentes
e membros de sua equipe periodicamente recolhidos para análise, avaliação e
adoção. O questionário deve orientar para fatos e resultados relevantes e
observados, ocorridos e ameaçados, prevenidos etc. e seus resultados (positivos
26
ou negativos). A escolha de palavras-chave permite agrupá-la para facilitar a
recuperação e o exame posteriores.
Estas lições aprendidas são ensinamentos que devem ser cuidadosamente catalogados,
avaliados, armazenados e difundidos a todos os participantes nos projetos. Devem-se
explorar os fatores de sucesso e não repetir os erros que foram feitos. O erro ou acerto é
o ponto de chegada. Deve-se tomar o caminho certo para repetir os acertos e evitar as
trilhas que conduzem a erros. (VALERIANO, 2001)
5.2
Benchmarking
Constitui uma modalidade especial de aprendizado direcionada a revelação das
melhores práticas de uma organização plenamente reconhecida como o número um de
seu ramo, de seus pais ou mesmo do mundo. No intuito de possibilitar, a quem inicia
este tipo de estudo como resultado final um quadro esclarecedor de que poderia ser
modificado melhorado na organização por intermédio da comparação com a empresa
referencial que foi objeto da investigação. (ARAUJO, 2007)
Benchmarking é um processo sistemático e contínuo de avaliação dos produtos,
serviços e processos de trabalho das organizações que são reconhecidas como
representantes das melhores práticas com a finalidade de comparar desempenhos e
identificar oportunidades de melhoria na organização que está realizando (ou
monitorando). (Fonte SITE WIKIPÉDIA)
Para Robert Camp (1993), considerado pai do benchmarking, diz que a essência da
tecnologia reside nos ensinamentos de um general chinês Sun Tzu e na palavra de
origem japonesa dantotsu. O autor acredita na veracidade do ditado atribuído ao
general de que o conhecimento sobre si mesmo e sobre o inimigo é capaz de garantir a
vitória de cem batalhas. Explorando as idéias de Sun Tzu, Camp salienta a
aplicabilidade ao mundo dos negócios, desta estratégia de guerra. Já quanto à expressão
dantotsu, o autor, traduzindo seu significado como “ser o melhor dos melhores”.
Conceituando como um processo positivo e proativo endereçado a transformação que
introduza uma performance otimizada na empresa, parte de uma definição tripla sobre
27
a tecnologia voltada para a investigação como método de aperfeiçoamento. (ARAUJO,
2007)
Com relação a pratica ou desempenho da empresa, em oposição a manter se equiparado
a concorrência, é um meio poderoso de preparar o terreno para mudança. Ao medir o
desempenho “dos melhores do ramo” sua pesquisa de benchmarking pode transformar
um contexto de mudança plausível num verdadeiro grito de guerra. O que pode ter de
parecido para alguns grupos de interesses uma simples questão interna a ser solucionada
no ritmo adequado, ou que não merecia atenção nenhuma, pode transformar-se em um
problema urgente em termos de sobrevivência competitiva. Daí a importância e o
interesse em benchmarking. A utilização de benchmarking externo poderá trazer
insights de oportunidades de melhoria. Oferece também um forte componente para
preparação do terreno de mudanças. À medida que o valor do benchmarking tornou-se
amplamente conhecido como ferramenta necessária, sua sofisticação e utilidade
cresceram substancialmente. Atualmente não basta mais levantar meia dúzia de dados
estatísticos de produtividade externa para justificar comparação direta. (PRICE
WATERHOUSE, 1990)
O benchmarking está diretamente relacionado com o planejamento estratégico para
gestão de projetos e pode ter um efeito pronunciado sobre a base corporativa
dependendo da rapidez com que as mudanças são implementadas. Nos últimos anos, as
empresas descobriram que as melhores práticas podem ser comparadas com as
organizações que não necessariamente se enquadram em sua linha de atuação.
Redes para fins de benchmarking no escritório de projetos poderão fazer parte do
futuro próximo da maioria das empresas. As redes de escritório de projetos poderiam
transpor setores e continentes. Alem disso torna-se comum até mesmo para
concorrentes o compartilhamento de conhecimentos em gestão. Entretanto, atualmente,
parece que a maioria do benchmarking em gestão de projetos está sendo realizada por
organizações totalmente voltadas para essa atividade. Tais organizações cobram uma
taxa por seus serviços e conduzem simpósios para seus associados, compartilhando
dados sobre as melhores práticas em gestão de projetos. Alem disso disponibilizam
serviços de banco de dados para que uma organização possa se comparar com
•
Outras organizações do mesmo setor;
•
Outras organizações de diferentes setor;
28
•
Outras respostas de funcionários na mesma organização;
•
Outras organizações de acordo com o tamanho;
•
Outras organizações de acordo com o tamanho do projeto.
Algumas organizações oferecem uma grande resistência ao benchmarking. Os
argumentos a essa prática seriam, entre outros:
•
Não se aplica a nossa empresa nem ao nosso setor
•
Não foi criado aqui
•
Estamos indo bem! Não precisamos disso
•
Vamos fazer o melhor sozinho
•
Por que mexer em algo que está indo bem?
Devido a essas preocupações, o benchmarking pode ser uma atividade de alto risco em
vista do temor diante das mudanças que podem ser recomendadas (KERZNER, 2006)
O benchmarking é uma das mais antigas ferramentas de gestão. O seu propósito é
estimular e facilitar as mudanças organizacionais e a melhoria de desempenho das
organizações através de um processo de aprendizagem. Isto é feito de duas maneiras:
1 – Identificando resultados excelentes, geralmente mensurados através de
métricas ou indicadores. Tais resultados servem de estímulo para os esforços de
melhoria e dão uma garantia que, através de esforços inteligentes, tais resultados
poderão ser igualados.
2 – Identificando as chamadas melhores práticas que, geralmente com alguma
adaptação à cultura e às peculiaridades da organização, podem servir de
referência para uma mudança que leve a melhores resultados.
O objetivo principal de se fazer benchmarking é implementar mudanças que levem a
melhorias significativas nos produtos e processos da organização e, consequentemente,
nos seus resultados. Qualquer organização, pública ou privada, com ou sem fins
lucrativos, de qualquer setor ou porte, pode utilizá-lo para entender e melhorar os seus
processos.
O benchmarking é uma das formas mais eficazes de se estabelecer metas e tem um
efeito motivacional grande junto às equipes
29
5.2.1
•
Tipos de Benchmarking
Benchmarking competitivo
Caracteriza-se por ter como alvo específico as práticas dos concorrentes. Na prática,
é o menos usual uma vez que é quase impossível que as empresas se prestem a
facilitar dados que estão ligados diretamente com a sua atividade à concorrência.
Por isso muitas vezes é necessário contratar uma consultora externa para obter
informações sobre o Benchmarking Competitivo.
• Benchmarking interno
A procura pelas melhores práticas ocorre dentro da própria organização em unidades
diferentes (outros departamentos, sedes, etc.). Tem como vantagens a facilidade para
se obter parcerias, custos mais baixos e a valorização pessoal interna. A grande
desvantagem é que as práticas estarão sempre impregnadas com os mesmos
paradigmas. Este é o tipo mais utilizado.
• Benchmarking genérico
Ocorre quando o benchmarking é baseado num processo que atravessa várias
funções da organização e pode ser encontrado na maioria das empresas do mesmo
porte, como por exemplo, o processo desde a entrada de um pedido até a entrega do
produto ao cliente. É neste tipo de benchmarking que encontramos a maioria dos
exemplos práticos e onde as empresas estão mais dispostas a colaborar e a ser mais
verdadeiras.
• Benchmarking funcional
Baseado numa função específica, que pode existir ou não na própria organização e
serve para trocarmos informações acerca de uma atividade bem definida como, por
exemplo, a distribuição, o faturamento ou embalagem. Alguns autores vinculam o
conceito
de
benchmarking
funcional
ao
benchmarking
genérico,
pela
possibilidade dos mesmos serem utilizados sem se levar em consideração a
concorrência direta da organização que aprende ou patrocina o estudo e a
organização "investigada". (Fonte SITE WIKIPÉDIA)
5.3
PMBOK
O Project Management Body Of Knowledge ou simplesmente PMBOK Guide é o
principal documento de referência do PMI, embora não seja o único.
30
Como o próprio nome em português diz, ele é “Um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos”. Está atualmente na terceira edição,
lançada em 2004. Como ele mesmo descreve o seu objetivo é:
“O principal objetivo do Guia PMBOK® é identificar o subconjunto do Conjunto de
conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa
prática. “Identificar” significa fornecer uma visão geral, e não uma descrição completa.
“Amplamente reconhecido” significa que o conhecimento e as práticas descritas são
aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso
geral em relação ao seu valor e sua utilidade. “Boa prática” significa que existe acordo
geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem
aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa
prática não significa que o conhecimento descrito deverá ser sempre aplicado
uniformemente em todos os projetos; a equipe de gerenciamento de projetos é
responsável por determinar o que é adequado para um projeto específico.” (PMBOK
3ed., 2004). No PMBOK Guide encontram-se muitas definições e práticas que guiam
na gerência de projetos em geral.
O guia procura identificar e descrever aquela parte do PMBOK que é geralmente aceita.
Significa nesse caso que os conhecimentos e práticas descritos são aplicáveis a maioria
dos projetos na maioria das vezes e que há um consenso amplamente difundido sobre
seu valor e utilidade.
Geralmente aceita não significa, entretanto que os conhecimentos e práticas descritos
devem ser praticados uniformemente em todos os projetos, a equipe de gerencia do
projeto é sempre responsável pela escolha daquilo que é mais apropriado para o projeto.
Alem disso o PMBOK Guide pretende fornecer também uma terminologia comum
dentro da profissão e práticas para a linguagem oral e escrita sobre gerenciamento de
projetos.
ESCOPO
CUSTO
PRAZO
As áreas do gerenciamento de projetos descrevem o gerenciamento de projetos em
termos de seus processos componentes. Esses processos podem ser organizados em
nove áreas integradas como ilustrado na figura a seguir.
RH
RISCOS
INTEGRAÇÃO
QUALIDADE
AQUISIÇÕES
COMUNICAÇAO
31
Figura 5: Áreas de conhecimento – FONTE: Manual Prático do Plano de Projeto (VARGAS, 1998)
Cada um desses processos tem um detalhamento especifico e uma abrangência própria,
porém está integrado a todo o momento com os demais formando um todo único e
organizado. (VARGAS, 1998). A figura abaixo exibe o mapeamento dos 44 processos
de gerenciamento de projetos nos cinco grupos de processos e nas nove áreas de
conhecimento em gerenciamento de projetos.
32
33
Figura 6: Mapeamento entre os processos, os grupos de processos e as áreas de conhecimento de gerenciamento de projetos
– Fonte (PMBOK 3ed., 2003)
5.4
PMI
O PMI é uma associação mundial sem fins lucrativos com foco exclusivo em
Gerenciamento de Projetos. Sua origem se deu em 1969 nos EUA através de cinco
SP, 2008). O PMI é líder mundial no desenvolvimento de padrões para a prática de
Gerenciamento de Projetos. Sua principal publicação é um guia com práticas de
gerência de projetos chamado de “A Guide to the Project Management Body of
Knowledge” ou mais popularmente PMBOK Guide (PMI-SP, 2008). Olhando para a
história cronológica do PMI pode-se perceber a evolução do gerenciamento de projetos
nas empresas pelo mundo inteiro e o quanto que a internet contribuiu para este
crescimento. Iniciando em 1969 com cinco associados, no final da década de 70,
aproximadamente 10 anos após, o número havia crescido para pouco mais de 2.000
associados. Em 90 esse número havia aumentado para 8.500. No início dos anos 2000 já
eram mais de 50.000 associados e hoje, em apenas oito anos, esse número já passa de
270.000 (PMI-SP, 2008).
5.5
Melhoria Continua
Considerando que o escritório de projetos é um repositório de propriedade intelectual
em gestão de projetos, ele detém a melhor posição para identificar oportunidades de
aperfeiçoamento
continuo.
Como
ponto
de
partida,
as
oportunidades
aperfeiçoamento continuo podem ser classificadas como mostra a figura abaixo.
de
34
Figura 7: Fatores a serem considerados para melhoria continua – FONTE: As Melhores práticas (KERZNER, 2006)
Atividades típicas de cada categoria poderiam ser:
•
Melhoria de processos existentes

Integração de um novo software ou atualização do existente

Uso e aplicação mais fáceis das ferramentas existentes

Melhor interface cliente/provedor

Convencer a outras organizações internas a utilizarem a metodologia
gestão de projetos
•
Processos integrados

Integração de outros sistemas, tais como gerenciamento de riscos e de
mudanças, ao sistema de gestão de projetos

Integração de outros bancos de dados da corporação a um sistema
integrado de internet disponível para todos.

Integração ou maior compatibilização dos bancos de dados de clientes e
provedores com o banco de dados da empresa.
•
Questões Culturais

Melhor gerenciamento de mudanças necessárias no comportamento
organizacional.
35

•
Superação de barreiras culturais
Benchmarking
 Aperfeiçoamentos no processo de benchmarking
 Aumento do número de parceiros para benchmarking
•
Questões administrativas

Melhorias na responsabilidade pelos projetos

Aperfeiçoamentos
no
gerenciamento
de comunicações
com os
interessados nos projetos

Projeções de futuros níveis de habilidade de recursos versus as
capacidades atuais. (KERZNER, 2006).
6
6.1
MATURIDADE E MELHORES PRÁTICAS
Melhores Práticas em Gestão de Projetos
Muitas empresas consideram alguns dos principais fatores críticos do sucesso e
indicadores de desempenho como sendo as melhores práticas. As melhores práticas são
atividades ou processos reutilizáveis que continuamente agregam valor ao produto final
dos projetos. As melhores práticas também podem aumentar a probabilidade de sucesso
de cada projeto. Mas, enquanto tudo isso soa como algo ideal, persiste a questão
fundamental de quem define o que é ou não é uma boa prática.
As melhores práticas são definidas internamente na empresa, observando-se o que
funcionou bem e o que tem maior probabilidade de funcionar bem no futuro se for
repetido em todos os projetos e com vários clientes. Uma empresa identificou uma
questão crítica na relação entre qualidade e satisfação do cliente. A empresa concentrouse intensamente na qualidade dos projetos quando descobriu que estava sacrificando a
satisfação do cliente para melhorar a qualidade. Quando os administradores
reorientaram seu foco para satisfação do cliente, perceberam que a qualidade também
havia melhorado. Portanto, a empresa concluiu que a satisfação do cliente era agora
36
uma das melhores práticas da empresa. Todo o pessoal da empresa foi então instruído a
concentrar-se na satisfação do cliente.
O que funciona bem como melhor prática em uma empresa pode não funcionar do
mesmo modo em outra. Por exemplo, se estivéssemos nos comparando com a empresa
mencionada, poderíamos erroneamente concluir o foco no cliente em vez de na
qualidade deveria ser uma das melhores práticas em nossa empresa. Entretanto, nossa
empresa poderá, com isso, piorar em qualidade em vez de melhorar.
As melhores práticas podem aparecer nas relações de trabalho, no desenho de modelos e
na forma como as metodologias de gestão de projetos são usadas e implementadas. As
melhores práticas podem acontecer em qualquer lugar.
Para chegar a maturidade e a excelência na gestão de projetos, não devemos deixar as
coisas ao acaso nem a partir para experiências de tentativas e erros. Ao contrário, deve
haver um processo estruturado em que os funcionários possam ver a luz no fim do túnel.
Se os fatores críticos para o sucesso e os principais indicadores de desempenho puderem
ser identificados com antecedência, haverá boas chances de que um processo para a
maturidade e excelência possa ser definido. (KERZNER, 2006)
Figura 8: Projetos fracassados em empresas com gestão de projetos – FONTE: As melhores práticas (KERZNER, 2006)
37
6.2
Maturidade na gestão de Projetos
É importante compreender que todas as empresas atravessam seus próprios processos de
maturidade, e que se trata de um processo que deve preceder a excelência. A curva do
processo de aprendizado para a maturidade é medida em anos. As empresas
comprometidas com a utilização da gestão de projetos poderão ter a sorte de atingir a
maturidade em cerca de dois anos, enquanto uma empresa típica pode levar até cinco
anos.
Em determinadas culturas, define-se maturidade como cabelos brancos, calvície e idade.
Em gestão de projetos, nada mais longe da realidade. A maturidade em gestão de
projetos é o desenvolvimento de sistemas e processos que por natureza repetitivas e
garantem alta probabilidade de que cada um deles seja um sucesso. Apenas aumentam a
sua probabilidade.
Uma empresa pode ser madura em gestão de projetos e não ser excelente. A definição
de excelência vai além da definição de maturidade. Quando as empresas desenvolvem
sistemas e processos maduros, surgem dois benefícios adicionais: primeiro, o trabalho é
executado com o mínimo de mudanças de escopo; e segundo, os processos são
definidos de maneira a causarem o mínimo de problemas para o negocio principal da
empresa.
A figura abaixo mostra as fases do ciclo de vida para a maturidade em gestão de
projetos. Praticamente todas as empresas que alcançaram algum grau de maturidade
passaram por essas fases. A cultura da organização e a natureza do negocio irão ditar o
tempo gasto em cada uma delas. (KERZNER, 2006)
38
Figura 9: As fases do ciclo de vida da maturidade de um projeto – FONTE: As melhores práticas (KERZNER, 2006)
7
7.1
METODOLOGIA
Sobre Metodologia
A metodologia, por definição, significa o estudo dos métodos, ou “receita”, para as
etapas a serem seguidas em um determinado processo, e são fundamentais para o
desenvolvimento dos projetos, desde que bem aplicados de acordo com as necessidades
da empresa e do projeto, pois não existe uma receita perfeita para todos.
Observando projetos bem sucedidos, mesmo aqueles que ocorreram antes da formação
do conceito de gerenciamento de projeto, nos perguntamos o que fez estes projetos
obterem sucesso? E tudo se resume a uma única resposta: Pessoas. Pessoas
competentes, com domínio de conhecimento na área em que atuavam e muito bom
senso, o que é diferente de senso comum, e trabalhando sempre em equipe, visando o
sucesso do resultado dela como um todo.
Processos são fundamentais para uma empresa, mas aqueles que são automatizados, as
máquinas que cuidem deles. Cada empresa deve desenvolver seus próprios processos
para cada projeto, lançando mão ou não das teorias existentes para as metodologias. Um
modelo tem como objetivo estabelecer - com base em estudos, históricos e
conhecimento operacional – um conjunto de "melhores práticas" que devem ser
utilizadas para um fim específico, podendo nem sempre ser a melhor opção, o que deve
ficar a cargo de cada um determinar se determinada prática é a melhor ou não, deve ser
usada ou não.
39
Algumas empresas não possuem metodologias a serem seguidas, ou então utilizam
metodologias extremamente complicadas e burocráticas, dificultando assim o trabalho
de seus funcionários. Muitas das empresas têm suas funções a serem seguidas, porém
não existe uma forma de executá-las, onde implica desde comunicação de informações
do trabalho a ser executado até o cronograma a ser cumprido. Por esses motivos
questiona-se quais os fatores de sucesso e fracasso na implantação de gestão de projetos
em pequenas empresas. Com organização, planejamento, metas e prazos bem definidos,
a empresa já tem um bom começo para obter sucesso em seu projeto. O mercado atual
está muito exigente e, portanto as empresas devem produzir trabalhos de qualidade com
agilidade e rapidez, a fim de satisfazer o cliente.
De acordo com os autores do livro “Implantando a Governança de TI”, Aguinaldo
Fernandes e Vladimir de Abreu (2006), existem alguns modelos que sustentam as
melhores práticas para se trabalhar com tecnologia da informação (TI), por exemplo.
Estes modelos vêm surgindo e sendo elaborados nas ultimas décadas, sendo alguns
originados, derivados e ou evoluídos de outros modelos.
Desta forma, cria-se a idéia de que se têm os modelos que se destacam formando uma
carteira de modelos de melhores práticas. O quadro a seguir destaca estes modelos.
Modelo de melhores práticas
COBIT – Control Objectives for
Information and
related Technology
Escopo do modelo
Modelo abrangente aplicável para a auditoria e
controle de processos de TI, desde o
planejamento da tecnologia até a monitoração
e auditoria de todos os processos.
CMMI – Capability Maturity Model
Desenvolvimento de produtos e projetos de
Integration
sistema de software.
ITIL – Information Technology
Infraestruture Library
Infra-estrutura de tecnologia da informação
(serviços de TI, segurança, gerenciamento da
infraestrutura, gestão de ativos e aplicativos
etc.).
BS 7799, ISO/IEC 27001 e ISO/IEC
Código de prática para a gestão da segurança
17799
da informação Segurança da informação.
Modelos ISO – International
Sistema de qualidade, ciclo de vida de
Organization for Standardisation
software, teste de software etc.
40
PRINCE2 - Project in controlled
Project in controlled enviroment Metodologia
enviroment
PMBOK - Projetc Management Body
de gerenciamento de projetos.
of Knowledge
Base de conhecimento em gestão de projetos.
Metodologia ágil em gerenciamento de
SCRUM
projetos
Metodologia para melhoramento da qualidade
Six Sigma
de processos.
SAS 70 – Statement on Auditing
Standards for services
Regras de auditoria para empresas de serviços.
Figura 10: Principais modelos de melhores práticas - FONTE: Implantando a Governança de TI
7.2
Benefícios de uma metodologia – padrão
Para as empresas capazes de entender a importância de uma metodologia-padrão, os
benefícios são inúmeros. Elas podem ser classificadas como benefícios de curto e de
longo prazo. Os de curto prazo têm uma boa descrição nas palavras de Michael
Peplowski, da ISK Biosciences:
•
Diminuição do tempo de ciclo e dos custos
•
Planejamento realistas com grandes possibilidades de atingir o
cronograma previsto
•
Melhor comunicação quanto ao “quê”se espera dos grupos e “quando”
•
“Feedback” conhecimento adquirido ou lições aprendidas
Estes benefícios de curto prazo têm seu foco nos KPIs, ou melhor, na execução da
gestão de projetos. Os benefícios de longo prazo parecem focar mais os fatores críticos
de sucesso (CSFs) e a satisfação dos clientes. Os benefícios de longo prazo no
desenvolvimento e na execução de metodologias universais incluem:
•
Maior rapidez na entrega ao mercado mediante controles mais rígidos
•
Redução global dos riscos no programa
•
Melhor gerenciamento do risco, que conduz a uma melhor tomada de
decisões
•
Aumento da confiança e satisfação do cliente, que conduz ao aumento
dos negócios e a expansão das responsabilidades para a categoria
principal de provedores
41
•
Ênfase na satisfação do cliente e no valor agregado, ao invés de disputas
internacionais entre os grupos em detrimento as disputas internas entre
grupos funcionais
•
Comparações de desempenho (benchmarking) e aperfeiçoamentos
continuados se tornam mais fáceis e rápidos.
Talvez o maior benefício de uma metodologia de classe mundial seja a aceitação e o
reconhecimento que encontram entre seus clientes. Se um dos clientes importantes
desenvolverem sua metodologia própria, ele pode “forçá-lo”a aceitá-la e utilizá-la como
condição para continuar sendo seu provedor. Mas se for possível provar ao cliente que
se dispõe de metodologia superior ou igual à dele, essa metodologia será aceita e o
ambiente de confiança será ainda maior.
O desenvolvimento de uma metodologia padrão que abarque a maioria dos projetos de
uma empresa e seja aceita por toda a organização é um empreendimento difícil. A parte
mais árdua provavelmente será garantir que a metodologia sustente a cultura da
organização e as metas e objetivos estabelecidos pela administração. As boas
metodologias devem ser flexíveis. (KERZNER, 2006)
7.3
SCRUM
Uma metodologia ágil para gerenciar e controlar projetos, baseada em ciclos de 30 dias
chamados Sprints, onde se trabalha para alcançar objetivos bem definidos. Estes
objetivos são representados no Product Backlog, uma lista de coisas para fazer que é
constantemente atualizada e repriorizada.
Uma de suas principais características é aumentar a comunicação e maximizar a
cooperação no projeto entre os envolvidos.
Scrum permite manter o foco na entrega do maior valor de negócio, no menor tempo
possível. Isto permite a rápida e contínua inspeção do software em produção (em
intervalos de duas a quatro semanas). As necessidades do negócio é que determinam as
prioridades do desenvolvimento de um sistema. As equipes se auto organizam para
definir a melhor maneira de entregar as funcionalidades de maior prioridade. Entre cada
duas a quatro semanas todos podem ver o real software em produção, decidindo se o
mesmo deve ser liberado ou continuar a ser aprimorado por mais um “Sprint”, e
obrigatoriamente atende estas especificações:
42
1. Atender o propósito solicitado
2. Ser inteligível.
3. Suficientemente preciso.
4. Suficientemente consistente.
5. Suficientemente detalhado.
6. Provedor de um valor positivo.
7. Ser o mais simples possível.
No SCRUM, o sistema é entregue quando não existirem mais itens no Product Backlog
a serem desenvolvidos.
7.3.1
Breve História
Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em
empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka
no artigo "The New New Product Development Game" (Harvard Business Review,
Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e
multidisciplinares (cross-functional) produziram os melhores resultados, e associaram
estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do
jogo em certos casos). Jeff Sutherland, John Scumniotales e Jeff McKenna
documentaram, conceberam e implementaram o Scrum na empresa Easel Corporation
em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka.
Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em
desenvolvimento de software em todo o mundo.
7.3.2
Como funciona o Scrum?
Definição do Backlog: todas as funcionalidades ou mudanças no produto são definidas
pelo Product Owner no Product Backlog.
Esta lista é priorizada para refletir a
necessidade dos clientes ou demandas do mercado. Os itens do topo da lista são
destacados para serem entregues no final do próximo Sprint.
43
Product Backlog: É uma lista que formaliza todos os requisitos de um produto
priorizados que se pretende fazer ou que se precisa construir no projeto. Cada item desta
lista representa um requisito funcional, ou requisito não funcional, ou questão de
tecnologia / infra-estrutura. Os itens com maior prioridade nesta lista são os requisitos
mais desejados do produto. Num projeto real, o Product Backlog nunca é finalizado.
Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos
podem aparecer, requisitos existentes podem perder prioridade e podem até serem
eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta
lista, somente o Product Owner pode priorizar o Backlog.
Atualização do Product Backlog: O Product Owner é responsável por re-priorizar
toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado
motivado pelos mais prioritários itens.
Figura 11: Ilustração do processo Scrum
7.3.3
Níveis de planejamento
O processo SCRUM possui 5 níveis de planejamento:
44
Figura 12: Níveis de planejamento do SCRUM
•
Nível 1 – Visão do Produto: Neste nível são definidas todas as características do
produto que se quer desenvolver.
•
Nível 2 – Roadmap do Produto: Neste nível o produto é dividido em releases
para que sejam desenvolvidos pela equipe.
•
Nível 3 – Release: Neste nível é realizado um plano de desenvolvimento para
cada release, um release pode ser desenvolvido usando mais de uma sprint
(iteração).
•
Nível 4 – Sprint (Iteração): Neste nível é definida todas as tarefas que serão
realizadas em uma sprint (iteração).
•
Nível 5 – Daily (Diário): Neste nivel é definido como será o trabalho em cada
dia de execução do sprint, bem como relatar o que deu certo e errado nas
tarefas.
45
Andamento do Sprint: durante o Sprint, os itens do Product Backlog que devem ser
entregues são agora tratados no Sprint Backlog. As tarefas agora são responsabilidade
da Equipe, que tem autonomia para decidir como elas devem ser executadas.
Reuniões diárias: o Scrum Máster se reúne diariamente com a Equipe em um mesmo
horário, para que se reporte:
- O que foi feito ontem?
- O que se pretende fazer hoje?
- Quais são os impedimentos que estão atrapalhando a execução das tarefas?
Revisões: no final do Sprint a Equipe demonstra os resultados para o Product Owner e
demais interessados, de forma que os itens do Backlog considerados prontos e então
possa se iniciar um novo Sprint.
7.3.4
Papéis e responsabilidades
Scrum Team
- Equipe constituído de 5-9 pessoas
- Responsável pela entrega das tarefas
- Não há papeis definidos dentro da equipe
- A equipe define tarefas e atribuições
- Mantém o Sprint Backlog
- Conduz a Sprint Review
Product Owner
- Define a Visão do produto
- E o representante do cliente
- Define e prioriza os recursos do produto
- Gerencia os Backlogs do produto.
Scrum Master
- É um facilitador, não um administrador
- Mantém os gráficos do Sprint Burndown
- Conduz a retrospectiva de Sprint no final de um Sprint.
- Realiza diariamente 15 min de reuniões com a equipe.
- Auxilia o Produtc Owner a maximizar o retorno do investimento.
46
7.3.5
Ferramentas utilizadas
Taskboard: Quadro visível a todos contendo objetivos do sprint, itens de backlog,
tarefas em andamento, itens finalizados e gráficos diários do Sprint Burndown
Figura 13: Taskboard
Cada linha no Quadro de Tarefas é um item do Product Backlog (neste exemplo,
estórias). Durante a Reunião Sprint Planning a equpe define os itens do Product
Backlog que eles conseguem concluir durante o próximo Sprint. Cada item do Product
Backlog é desdobrado em vários itens de Sprint Backlog. Cada um deles é
representado por um cartão de tarefa que é colocado no Quadro de Tarefas na coluna "A
fazer".
Burndowm: O gráfico de Burndown é uma forma visual e rápida de enxergar o status
atual do projeto. Ele possui uma estrutura simples, onde:
- Eixo X: representa os dias do sprint
- Eixo Y: representa o trabalho restante
O trabalho restante pode ser definido de acordo com a sua necessidade. Algumas
pessoas utilizam pontos, algumas pessoas utilizam horas, outros dias e assim por diante.
47
O uso com pontos, geralmente ocorre com a atualização do gráfico apenas quando uma
user story é finalizada. Ou seja, teoricamente teremos um gráfico cuja linha será
horizontal até a finalização de uma tarefa, algo mais ou menos com está apresentado
abaixo:
Figura 14: Taskboard com o gráfico de Burndown
7.3.6
Prós na utilização do Scrum
São utilizados indivíduos e relacionamentos ao invés de processos e ferramentas e
equipes
pequenas
que
resultam
maior
compartilhamento
de
informações.
É quase desnecessário dizer que num projeto de software os indivíduos são mais
importantes que ferramentas e processos. Apesar de todo mundo concordar com isso, a
prática é mais rara.
As chances de sucesso em um projeto são muito maiores em times onde há uma boa
comunicação, onde há entendimento e cooperação mútua.
O Fortalecimento do Trabalho em Equipe gera:
•
Mais Comprometimento
•
Maior Produtividade
•
Mais Visibilidade
48
•
Mais Assertividade nas Estimativas
•
Maior Satisfação do Cliente
Com uma versão funcional do produto, o cliente pode interagir e avaliar o software.
Sentir como o software funciona, mesmo que seja apenas uma pitada, como um
pequeno trailer do filme. O gerente de produto pode usar o software para avaliar se suas
expectativas foram cumpridas e se a sua forma de comunicação com o time foi
eficiente.
Do ponto de vista técnico, o time de desenvolvimento pode provar que a arquitetura e
tecnologias usadas para desenvolver o produto são funcionais, sem contar com a
satisfação que é ter algo concreto para mostrar ao final de cada Sprint. Como numa
guerra, cada Sprint terminado é uma batalha vencida e uma coleção de batalhas
sucedidas na maioria das vezes leva à vitória.
Ter um software funcionando ao final de cada Sprint é uma das peças chaves do
SCRUM. Um Sprint ou interação é um intervalo geralmente de duas a quatro semanas
onde o desenvolvimento de software ocorre. Algumas vantagens deste ciclo interativo
são:
•
O conjunto de tarefas a ser cumprido é menor, o que os torna mais fácil discutir,
priorizar, entender, estimar e executar;
•
O acompanhamento do andamento do projeto é simplificado e mais eficiente, já
que trabalha com um número reduzido de tarefas;
•
Ao final de cada sprint, o desempenho do projeto é visível para todos e pode ser
facilmente comunicado para a gerência, que por sua vez tem a chance de fazer
correções e tomar melhores decisões sobre o produto.
•
Ao final de cada sprint, o time também tem a oportunidade de avaliar o que deu
certo e errado e fazer melhorias para a próxima interação, ficando mais eficiente
a cada novo ciclo.
Em um projeto SCRUM, o cliente é parte integral do time, trabalhando diariamente com
os desenvolvedores e Scrum-Master (Scrum-Master é uma posição semelhante ao
gerente de projetos). No projeto ideal, o Scrum-Master e desenvolvedores não
precisam nunca tomar uma decisão sobre uma regra de negócio, pois o cliente está
sempre disponível. O cliente está sempre envolvido, esclarecendo regras de negócio,
participando da demonstração do software ao final de cada Sprint, oferecendo
49
feedback e atento às mudanças e suas conseqüências. O time consegue trabalhar e
concentrar esforços no que é realmente importante no momento.
As mudanças são uma das poucas coisas que podemos ter como certeza no início de
cada projeto. Planejamento é importante, uma metodologia ágil reconhece isso, mas o
mais importante é que o time possa absorver as mudanças que tornam o produto final
melhor. A cada novo Sprint, o “Product Owner” tem a chance de alterar a prioridade
ou adicionar novas tarefas a serem executadas durante o Sprint. Vale à pena ressaltar
que o time de desenvolvimento tem total controle sobre o número de itens a serem
trabalhados durante o Sprint, baseados no tamanho das tarefas e duração do Sprint.
É errôneo pensar que SCRUM, por exemplo, não enfatiza planejamento. A diferença é
que o planejamento é dividido em vários Sprints. Se há a necessidade, por exemplo, de
integração com um sistema legado, o planejamento de tal atividade acontece durante o
Sprint, onde os detalhes são levantados, a prioridade é definida e o real valor para o
negócio entendido. Se a tarefa é muito complexa, ela pode ser dividida em sub-tarefas
que são então alocadas em dois ou mais Sprints, onde no primeiro faz-se o
planejamento e no segundo acontece a execução.
7.3.7
•
Contras na utilização do Scrum
Suporte
limitado
para
ambientes
de
desenvolvimento
distribuído
Equipes distribuídas geograficamente tem maior dificuldade de iterações diárias.
Nestes casos é necessário o uso sistemático de fórum, chat ou outros que
permitam boa iteração da equipe.
•
Dificuldade de adaptação por causa do velho hábito ainda fizemos algumas
estimativas pensando em quem iria fazer cada atividades quando o ideal seria
estimar sem esse direcionamento.
•
Utilização de ferramentas específicas Em locais em que não há espaço para
quadro branco, é necessária a utilização de ferramentas SCRUM para cadastrar e
gerenciar os Backlogs e atividades dos Sprints, o que acaba tirando um pouco
do dinamismo do SCRUM.
50
8
GERENCIAMENTO DE TEMPO
8.1
Introdução
O tempo é um item cuja disponibilidade deve ser rigidamente administrada no projeto.
A gestão de tempo depende de muito sincronismo das atividades dos vários agentes do
projeto. No âmbito do projeto, há uma crítica seqüência de interações em que
fornecedores internos precisam abastecer clientes internos de produtos, serviços,
informações etc. Assim, torna-se necessário observar um perfeito ajustamento de todos
os processos produtivos desde entregas de insumos, duração das atividades e dos
procedimentos de transformação, transportes diversos e etc. Se toda a gestão de tempo
puder ser resumida em poucas palavras, pode-se dizer que ela consiste no cuidadoso
preparo de um cronograma e no seu criterioso controle, para que o projeto seja
concluído no tempo previsto. (VALERIANO, 2005)
A abordagem ágil (SCRUM), assim como a abordagem tradicional (PMBOK), possui
características positivas e negativas, sendo que a principal diferença entre as duas está
no conjunto de pressupostos de cada uma. É possível afirmar, ainda, que existe uma
sinergia muito grande entre as duas metodologias, ou seja, uma pode complementar a
outra.
8.2
Gerenciamento Ágil
O gerenciamento ágil surgiu a partir dos conceitos de desenvolvimento rápido como
uma alternativa para tratar com o ambiente competitivo do mercado atual que exige
resultados imediatos, sob condições de altas incertezas e constantes mudanças.
O gerenciamento ágil fundamenta-se pelo planejamento rápido, com reuniões intensivas
e com a participação de todos os envolvidos com o objetivo de obter o plano do projeto
aprovado e pela participação efetiva do cliente em todas as fases do projeto atuando na
definição, validação e aprovação do trabalho a ser realizado em conjunto com a equipe
do projeto, pelo ambiente de colaboração entre os membros da equipe e pela rápida
incorporação de alterações durante o ciclo de vida do projeto. (RIBEIRO, 2007)
51
8.3
Gerenciamento de Projetos Tradicional
O gerenciamento de projetos tradicional baseia-se em processos bem definidos e
documentados que passam por melhorias contínuas nas diversas organizações. No
gerenciamento tradicional o foco está no processo, portanto o suporte gerencial, a
comunicação e a infra-estrutura organizacional são requisitos chaves para o sucesso do
empreendimento. (BOEHM, 2002)
Características
Modelo ágil
Modelo Tradicional controlado
Premissa fundamental
Ênfase na agilidade
Ênfase no controle operacional
Condução dos trabalhos
Baseado em processos empíricos
Baseado em processos formais
Escopo da solução
Centradas no desenvolvimento
Englobam todas as disciplinas
Profundidade da
abordagem
Definir apenas o quê deve ser feito
Definir o quê e como deve ser
feito
Foco dos profissionais
Atuação local (por projeto)
Atuação global (por disciplina)
Abordagem estratégica
Atender melhor o curto prazo
Atender melhor o longo prazo
Palavras chaves
Pessoas, feedback, adaptação
Maturidade, estrutura,
padronização
Modelos de
implementação
Xp, scrum, fdd, apm, lean, crystal e
dsdm
CMMI, RUP, ITIL, ISO, PMI
Frase que resume sua
filosofia
Aproxime sua equipe do cliente,
Não podemos melhorar o que não
simplifique o projeto e aumento sua podemos controlar
produtividade
Figura 15: Comparação entre os modelos Ágil e Tradicional
8.4
Gestão de Tempo pelo PMBOK
Os processos de definição e estimativa de esforço e duração das atividades são comuns
aos dois métodos, que irão diferir na forma de elaboração do cronograma.
A elaboração de um cronograma detalhado de todas as atividades para a execução do
projeto é uma característica do método tradicional. Porém, em função do tempo
disponível ou das incertezas que envolvem o projeto torna-se uma projeção, sujeito a
constantes alterações que podem levar a perda do controle do prazo ou insegurança por
parte dos envolvidos.
No método ágil o cronograma é orientado ao produto que será produzido em cada
iteração, que é planejada de acordo com a prioridade funcional definida pelo cliente.
52
Estas iterações devem ter duração de duas e quatro semanas para atender rapidamente às
necessidades do cliente. Nesta situação o prazo final não está claramente definido. No
entanto, como o cliente recebe produtos constantes de acordo com sua própria
orientação, há uma redução dos conflitos pela cumplicidade no processo.
O gerenciamento de tempo do projeto inclui os processos necessários para realizar o
término do projeto no prazo. Os processos de gerenciamento de tempo do projeto
incluem os seguintes:
•
Definição da atividade – identificação das atividades específicas do
cronograma que precisam ser realizadas para produzir as várias entregas do
projeto.
•
Seqüenciamento de atividades – identificação e documentação
das
dependências entre as atividades do cronograma.
•
Estimativa de recursos da atividade – estimativa do tipo e das quantidades de
recursos necessários para realizar cada atividade do cronograma.
•
Estimativa de duração da atividade – estimativa do número de períodos de
trabalho que serão necessários para terminar as atividades individuais do
cronograma.
•
Desenvolvimento do cronograma – análise dos recursos necessários, restrições
do cronograma, durações e seqüências de atividades para criar o cronograma do
projeto.
•
Controle do cronograma – controle das mudanças no cronograma do projeto
Esses processos interagem entre si e também com processos de outras áreas de
conhecimento. Cada processo pode envolver o esforço de uma ou mais pessoas ou de
grupos de pessoas, com base nas necessidades do projeto. Cada processo ocorre pelo
menos uma vez em todos os projetos e ocorre em uma ou mais fases do projeto, se o
projeto estiver dividido em fases. Embora os processos sejam apresentados aqui como
componentes distintos com interfaces bem definidas, na prática eles podem se sobrepor
e interagir . (PMBOK, 2003)
Vejamos algumas situações nas duas formas de gerenciamento tanto tradicional quanto
ágil.
53
9
COMPARAÇÃO DA GESTÃO DE TEMPO NOS MÉTODOS
AGIL E TRADICIONAL
9.1
Estimativa da duração das atividades
9.1.1
Estimativa no Gerenciamento Ágil
No Scrum é utilizado uma forma diferente de estimar o tempo usando uma técnica
chamada planning poker.
Estimar é uma atividade da equipe – cada membro é freqüentemente envolvido pra
estimar cada estória. Por que?
•
Quando vamos planejar, normalmente nós não sabemos exatamente quem vai
implementar quais partes de quais estórias.
•
Estórias normalmente envolvem diversas pessoas e diversos tipos de expertise
(design de interface de usuário, codificação, teste, etc).
•
Para prover uma estimativa, o membro da equipe precisa de algum tipo de
entendimento do quê trata a estória. Pedindo para todos estimarem cada item,
nós nos certificamos que cada membro da equipe compreende do que cada item
se trata. Isso aumenta a probabilidade de que os membros se ajudarão durante o
sprint. Isso também aumenta a probabilidade de que questões importantes sobre
a estória surjam cedo.
•
Quando pedimos que todos estimem uma estória, freqüentemente descobrimos
discrepâncias onde duas pessoas da equipe têm estimativas bastante diferentes
para a mesma estória. Esse tipo de coisa é melhor ser descoberto e discutido o
quanto antes.
Se você pedir à equipe para que gere uma estimativa, normalmente a pessoa que melhor
entende a estória será a primeira a revelar a sua. Infelizmente, isso afetará fortemente as
estimativas de todo o resto. Há uma técnica excelente para evitar isso – ela é chamada
planning poker.
Cada membro da equipe recebe um baralho de 13 cartas. Sempre que uma estória deve
ser estimada, cada membro escolhe uma carta que representa a sua estimativa de tempo
(em pontos por estória) e coloca-a virada para baixo sobre a mesa. Quando todos os
membros da equipe tiverem feito sua estimativa, as cartas são reveladas
simultaneamente. Dessa forma, cada membro da equipe é forçado a pensar por si
próprio ao invés de basear-se na estimativa de outra pessoa. Se houver uma grande
divergência entre duas estimativas, a equipe discute as diferenças e tenta chegar a uma
54
visão comum do trabalho envolvido na estória. Eles podem fazer algum tipo de
decomposição de tarefas. Depois disso, a equipe faz novamente à estimativa. Esse
processo é repetido até que as estimativas de tempo cheguem a uma convergência, isto
é, todas as estimativas sejam aproximadamente a mesma para cada estória.
É importante lembrar aos membros da equipe que eles devem estimar a quantidade total
de esforço envolvido na estória. Não é somente “a sua” parte do trabalho. O testador
não deve somente estimar a quantidade de esforço de teste. (KNIBERG, 2004)
Agora imagine que cada membro da equipe é a realização de um baralho de
cartas, contendo os seguintes cartões:
O Product Owner diz:
Mais uma vez, a equipe começa a pensar quanto tempo a história vai tomar.
55
Desta vez ninguém se arrisca a falar sem pensar. Em vez disso, todos têm de apresentar
um cartão de face para baixo, contendo sua estimativa. Todo mundo tem de apresentar
um cartão, por isso, “D” e “E” despertam. “D” admite que ele estava dormindo.
Todas as cartas são viradas simultaneamente, revelando todas as estimativas.
Divergência em especial em “A” e “C”. Há a necessidade de discutir essa história e por
que as suas estimativas são tão diferentes. Após alguma discussão, “A” percebe que ele
se esqueceu de algumas tarefas importantes que devem ser incluídas na história. Já, “C”
percebeu que incluiu tarefas a mais. Após o debate (3 minutos no total) é feita outra
rodada, até que as estimativas tenham a mesma história.
Convergência Eles concordam que uma estimativa de 5 deve estar perto o suficiente.
Próxima história.
9.1.2
Estimativa das durações das atividades – Gerenciamento Tradicional
Este processo objetiva os tempos necessários a execução das atividades já dispostas em
suas precedências no diagrama de rede do projeto. O processo de estimativa das
56
durações das atividades é muito iterativo com o processo precedente e com o de gestão
dos recursos.
•
Entradas:
A lista de atividades provem do processo anterior e as hipóteses e restrições e os
dados históricos são elementos auxiliares. As necessidades de recursos foram
levantadas ao se determinar as declarações de trabalho e devem ter por base as
atividades atualizadas. As disponibilidades de recursos foram levantadas nas
declarações de trabalho e, se for o caso deve-se considerar as atualizações das listas
de atividades. O correto conhecimento das disponibilidades de recursos e da
avaliação de sua eficácia são fatores de grande importância para a estimativa da
duração das atividades
•
Recursos e atividades
As estimativas de duração das atividades são expressas em unidades de tempo (em
dias ou semanas) e podem vir acompanhadas de indicativos de tolerância ou faixas
de tempo mais prováveis como, por exemplo, 10 dias + ou – 2 ou então em
porcentagem, 20 dias + ou – 10%. Entre os principais meios que permitem avaliar a
duração das atividades estão a opinião de especialistas, as estimativas por analogia e
outras atividades e métodos de simulação, segundo os quais é atribuída a cada
atividade uma distribuição estatísticas de durações conforme várias hipóteses e, por
processamento matemático, são determinadas as prováveis durações para todo o
projeto.
•
Saídas
Como resultado deste processo, obtem-se as estimativas de durações de atividades
acompanhadas das hipóteses e restrições e demais bases das estimativas
encontradas. As estimativas geralmente são figuradas no diagrama de rede do
projeto ou em gráficos de barra. (VALERIANO, 2002)
9.2
Controle do Cronograma ou atividades
57
9.2.1
•
Controle do Cronograma – Gerenciamento tradicional
As entradas são provenientes dos processos:
o Definição das atividades
o Seqüenciamento das atividades
o Estimativo de recursos das atividades
o Estimativa das durações das atividades
o Desenvolvimento do cronograma
•
Recursos e Atividades
O sistema de controle de mudanças do cronograma aplica os procedimentos de
mudanças estabelecidos no plano da gestão do cronograma. Este sistema inclui os
documentos apropriados, define as pessoas autorizadas a participar das mudanças e
procede ao rastreamento das mudanças. Ele é parte integrante do sistema geral de
controle de mudanças do projeto. Como conseqüência dos resultados obtidos,
expressos pelas medidas de desempenho e conseqüentes mudanças do cronograma,
estas podem dar origem a replanejamento do projeto com reflexos em outras
gestões, como a do pessoal, dos recursos, dos custos.
O controle de cronograma de projeto foi pioneiro no emprego de software em
gerenciamento de projetos, destinados a automatizar os trabalhos manuais
anteriores.
•
Saídas
O principal resultado deste processo são as atualizações do cronograma, dando
origem as atualizações dos cronogramas subsidiários do projeto. Outras saídas são
as ações corretivas e preventivas e as valiosas lições aprendidas como já enfatizado.
(VALERIANO, 2002)
9.2.2
Gráfico de Burndown – Gerenciamento ágil
Como funciona o gráfico de burndown, vejamos um gráfico de burndown:
58
Figura 16: Gráfico de Burndown
Este gráfico mostra que:
No primeiro dia do sprint, 1 de agosto, a equipe estimou que havia aproximadamente
70 pontos por estória de trabalho a serem feitos. Isso foi na verdade a velocidade
estimada de todo o sprint.
Em 16 de agosto a equipe estimou que havia aproximadamente 15 pontos por estória de
trabalho a serem feitos. A linha de tendência tracejada mostra que eles estão
aproximadamente dentro do prazo, isto é, neste ritmo eles completarão tudo até o final
do sprint.
Nós pulamos os finais de semana no eixo-x, uma vez que o trabalho raramente é
executado aos finais de semana. Nós costumávamos incluir finais de semana, mas isso
tornaria o gráfico de burndown um pouco confuso, já que o mesmo ficaria “reto ” nos
finais de semana e isso poderia parecer um sinal de alarme. (KNIBERG, 2004)
Sinais de alarme do quadro de tarefas
Uma olhada rápida no quadro de tarefas daria a qualquer um uma indicação de quão
bem o sprint está progredindo. O scrum master é responsável por garantir que a equipe
haja quando surgirem sinais de alarme como:
59
Figura 17: Sinais de alerta no gráfico de Burndown
9.3
Estimando dias X horas
Na maioria dos livros e artigos sobre Scrum, você vai encontrar que as tarefas são
estimadas em horas, e não em dias. Costumávamos fazer isto. Nossa formula geral era:
1 homem-dia = 6 horas-homem reais. Atualmente deixamos de fazer assim, pelo menos
na maior parte de nosso grupo, pelas seguintes razões:
•
As estimativas em homem-hora eram muito granulares, e isto provocava uma
tendência a estimar muitas tarefas de 1-2 horas e a conseqüente micro gerencia.
•
De qualquer forma, como todos estavam pensando em temos de homens-dias, e
simplesmente multiplicavam por 6 antes de escrever homem-hora. “Hmmmm,
esta tarefa deve gastar um dia.
60
•
Bom, tenho que escrever horas, então escrevo 6 horas”. Duas unidades
diferentes podem causar confusão. “Esta estimativa é em homem-hora ou
homem-dia?
Assim, atualmente usamos o homem-dia para todas as nossas estimativas (embora
continuemos chamando de pontos por estória - story points).
Nosso menor valor é 0,5, isto é, qualquer tarefa que é menor que 0,5 será eliminada,
combinada com outras tarefas ou receberá o valor de 0,5. (Não tem problema
superestimar um pouco). Simples e elegante.
O ponto-chave para diminuir a lacuna existente entre o uso das abordagens “tradicional”
e “ágil” está em considerar, na escolha de uma ou de outra, as características do projeto
a ser desenvolvido, ou seja, buscar aplicar a metodologia correta para o trabalho a ser
realizado. Os projetos que têm como natureza a inovação tecnológica inviabilizam o uso
da abordagem tradicional (PMBOK), pois o risco de ser necessário alterar um produto
depois da conclusão de uma fase de seu ciclo de vida é bastante alto. A abordagem ágil
(SCRUM) consegue uma adaptação muito fácil nesses casos de mudança (seja de
requisitos ou de escopo do projeto). (KNIBERG, 2004)
Por outro lado, a abordagem tradicional é mais adequada para projetos que necessitam
de um forte planejamento e muita disciplina no processo, mas ela não promove uma
ampla comunicação entre os membros de equipes diferentes e seus gerentes, o que
também representa uma característica de modelo centralizado. (Kleber Nardi)
10 CARACTERISTICAS DOS MÉTODOS AGIL E TRADICIONAL
10.1 Características do Gerenciamento Tradicional
O objetivo principal do gerenciamento tradicional está relacionado ao processo que
suporte o desenvolvimento e permita o controle dos problemas durante o ciclo de vida
do projeto (Nerur et al., 2005). A partir das informações históricas e da repetição obtémse a melhoria da capacidade do processo através da padronização, medição e controle do
projeto (Boehm, 2002).
10.2 Características do Gerenciamento Ágil
61
A base do gerenciamento ágil está em responder rapidamente as alterações, na
confiança nos membros da equipe e na realização de entregas freqüentes ao cliente
permitindo estabelecer um ambiente colaborativo e integrado para a realização do
projeto.
A flexibilidade do método sugere sua aplicação em ambientes de projetos que tenham
restrição de prazo, onde exista um nível elevado de incertezas e com alterações
constantes. Além disso, considera-se recomendável sua utilização em projetos que
tenham entre 5 a 10 pessoas devido ao nível mínimo de documentação que é produzido.
O planejamento deve ser realizado de forma rápida com a participação efetiva de todos
os envolvidos. O gerente do projeto conduz reuniões com todas as pessoas interessadas
no projeto de forma a obter o consenso em relação ao plano do projeto e o
comprometimento de todos. Da mesma forma que no gerenciamento tradicional,
alterações substanciais no projeto podem gerar novas reuniões de planejamento.
A equipe trabalha em grupos pequenos junto com o cliente. Os requisitos a serem
implementados em cada ciclo são avaliados em conjunto e as decisões tomadas de
forma colaborativa entre todos os envolvidos. O gerente de projetos exerce o papel de
facilitador ou coordenador (Nerur et al., 2005).
O cliente deve ser membro efetivo da equipe com conhecimento e domínio do processo
de negócio que está sendo construído e com poder de decisão sobre as questões e
alterações que surgirem durante a fase de construção.
A comunicação é interpessoal e informal e o conhecimento é implícito, ou seja, está
com cada membro da equipe. Para minimizar o impacto é recomendável a troca dos
grupos de desenvolvimento nas iterações.
62
Figura 18: Quadro Comparativo entre as áreas de conhecimento no gerenciamento tradicional e ágil
11 CONCLUSÃO
Gerenciamento de projeto está sendo cada vez mais abordado no mundo corporativo. O
uso de técnicas, metodologias, modelos e certificações ou uso de termos como “melhor
63
prática”, “Benchmarking” e “Lições aprendidas” estão sendo cada vez mais procurados
e utilizados pelas organizações. As empresas utilizam dessas técnicas para capacitar
seus recursos, aprimorar o produto final, melhorar atendimento, melhorar resultados, se
tornar reconhecido no mercado e etc., para fazer com que sua marca se torne mais
valorizada por seus clientes e apresentem um alto nível de qualidade. O modelo ou
metodologia a seguir não importa desde que se encaixe na estrutura. Neste trabalho
podemos observar que nenhuma metodologia é melhor que a outra e sim depende do
segmento que empresa possui. Para algumas empresas o método tradicional é mais
eficaz do que o método ágil, mas nada impede a organização tente utilizar qual quer que
seja a prática.
Observamos também que a comunicação é um fator muito importante na implantação
dessas técnicas, pois todos os envolvidos devem seguir em busca do mesmo objetivo
para no final gerar bons resultados. Todos devem participar!
O Scrum não é muito utilizado no Brasil, mas está começando a ganhar seu espaço. As
empresas estão querendo trabalhar com um modelo que seja tão rápido quanto às
constantes mudanças que acontecem nos projetos, para isso escolhem o modelo ágil.
Encontramos a prática desse modelo em projetos de desenvolvimento de software, pois
software é desenvolvido em funcionalidades e o Scrum possui essa característica de
trabalhar em partes. O único problema é o prazo de entrega, por entregar em
funcionalidades/partes pode ser que o tempo se prolongue mais do que o esperado.
Não foram identificadas na pesquisa desse trabalho relatos de problemas relacionados
ao tempo ou a qualquer outra área de conhecimento, ao contrário, as pessoas escrevem
artigos, relatam suas experiências e seus conhecimentos para que as empresas tentem
utilizar o método ágil. Acredito que como o Scrum está ganhando espaço agora é cedo
para encontrarmos “lições aprendidas” principalmente em áreas não relacionadas a
desenvolvimento de software.
Independente da escolha, o importante e que o projeto seja gerenciado a fim de
proporcionar melhoria nos processos e bons entregáveis, fazendo com que a empresa se
destaque e desenvolva no mercado.
64
12 REFERÊNCIAS BIBLIOGRÁFICAS
BARBOSA, Adriane Monteiro Cavalieri; DINSMORE, Paul Campbell. Como se
tornar um profissional em gerenciamento de projetos : livro base de "preparação
para certificação PMP - project management professional".
Rio de Janeiro:
Qualitymark, 2004.
CAMP, Robert C. Benchmarking : o caminho da qualidade total: identificando,
analisando e adaptando as melhores praticas da administração que levam a
maximização da performance empresarial . São Paulo, SP: Pioneira, cl993.
CAMP, Robert C. Benchmarking dos processos de negocios : descobrindo e
implementando as melhores praticas.
Rio de Janeiro: Qualitymark, 1996.
GIDO, Jack; CLEMENTS, James P. Gestão de projetos.
São Paulo: Thomson,
2007.
KEELLING, Ralph. GESTÃO projetos: uma abordagem global. São Paulo, SP:
Saraiva, 2002.
KERZNER, Harold. Gestão de projetos: as melhores práticas. 2. ed Porto Alegre:
Bookman, 2006.
MASSOT, Eduardo Villela de Andrade. Artigo Metodologias em Gerenciamento de
Projetos e sua implantação em tecnologia da informação (TI). UNESA, Rio de
Janeiro
MAXIMIANO, Antonio Cesar Amaru. Administração de projetos : como transformar
idéias em resultados . São Paulo: Atlas, 1997
MENEZES, Luís César de Moura. Gestão de projetos.
2003.
2. ed. São Paulo: Atlas,
65
PRINCE WATERHOUSE. Mudando para melhor: as melhores praticas para
transformar sua empresa. São Paulo, SP: Atlas, 1997.
RIBEIRO, André Luis Dias; ARAKAKI, Reginaldo. Artigo Gerenciamento de
Projetos Tradicional x Gerenciamento de Projetos Ágil: Uma Análise Comparativa.
Escola Politécnica da Universidade de São Paulo
TAVARES, Aleckssandro. Monografia apresentada na disciplina de Trabalho de
Conclusão de Curso I, sob orientação do Prof. Daniel Wildt.
UM GUIA do conjunto de conhecimento do gerenciamento de projetos: guia PMBOK.
3. ed. Pennsylvania: Project Management Institute, 2004.
VALERIANO, Dalton L. Gerência em projetos : pesquisa, desenvolvimento e
engenharia. São Paulo: Makron Books, 1998.
VARGAS, Ricardo Viana. Manual prático do plano de projeto : utilizando o
PMBOK 2000. Rio de Janeiro: Brasport, 2003
XAVIER, Carlos Magno da Silva. Gerenciamento de projetos: como definir e
controlar o escopo do projeto. São Paulo: Saraiva, 2006.
Sites visitados:
•
MASSOT, Eduardo <http://www.administradores.com.br/producao_academica/
metodologias_em_gerenciamento_de_projetos_e_sua_implantacao_em_tecnologia_
da_informacao_ti/475/> Consultado em Abril de 2009
•
BARBI, Fernando <http://www.microsoft.com/brasil/msdn/Tecnologias/Carreira/
GerencProjetos.mspx> Consultado em Abril de 2009
•
<http://www.tenstep.com.br/br/TenStepPB/open/5.0.htm> Consultado em Abril de
2009
•
FUSCO, Camila <http://governanca.wordpress.com/2008/03/18/scrum-a-novagestao-de-projetos/> Consultado em Maio de 2009’
66
•
JUNIOR, Nelson Abu Samra Rahal <http://blogdoabu.blogspot.com/2009/04
/scrum-e-pmbok-comunicacao.html> Consultado em Maio de 2009
•
<http://www.cassao.eti.br/portal/scrum> Consultado em Junho de 2009
•
COSTA, André da Silva <http://onnclick.net/blog/?p=523> Consultado em Junho de
2009
•
SOARES, Franklin de Oliveira <http://sbpcnet.org.br/livro/60ra/resumos/resumos /
R1118-1.html> Consultado em Julho de 2009
•
PACHECO, Diego ttp://imasters.uol.com.br/artigo/12893/gerencia/gerenciamento
_de_niveis_com_scrum_e_rup_-_parte_01/> Consultado em Julho de 2009
•
PACHECO, Diego <http://www.slideshare.net/diego.pacheco/planejamento-niveis1263533> Consultado em Julho de 2009
•
PACHECO, Diego <http://diego-pacheco.blogspot.com/2009/03/no-final-dascontas-ainda-e-o-pdca.html> Consultado em Julho de 2009
•
CAMPOS, Cesar <http://portal.cseg.eng.br/cesarcampos/index.php?
option=com_content&view=articl
e&id=6:gerenciamento-agil-de-projetos-de-
desenvolvimento-de-software&catid=1:artigos&Itemid=2> Consultado em Julho de
2009
•
<REIS, Adriana. <http://www.adrianareis.pro.br/contato.html> Consultado em
Julho de 2009
•
PMI-SP: <http://www.pmisp.org.br/instituto.asp>. Consultado em julho de 2009
•
<http://onnclick.net/blog/?p=523>