TCC_POS_LUIZ

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL
FACULDADE DE INFORMÁTICA - FACIN
ESPECIALIZAÇÃO EM GERENCIAMENTO DE PROJETOS COM ÊNFASE EM TI

LUIZ HENRIQUE RAUBER RODRIGUES

GESTÃO ÁGIL DE PROJETOS ESTRATÉGICOS: SELEÇÃO, PRIORIZAÇÃO E
EXECUÇÃO DE PROJETOS COM USO DE GESTÃO ESTRATÉGICA,
GERENCIAMENTO DE PROJETOS E MÉTODOS ÁGEIS

Porto Alegre
2011



Monografia apresentada a Faculdade de
Informática da Pontifícia Universidade Católica do
Rio Grande do Sul, Campus Porto Alegre, como
requisito a obtenção do grau de Especialista em
Gerenciamento de Projetos com Ênfase em TI.

Prof. Orientador: Adilson Pize

Porto Alegre
2011



Monografia apresentada a Faculdade de
Informática da Pontifícia Universidade Católica do
Rio Grande do Sul, Campus Porto Alegre, como
requisito a obtenção do grau de Especialista em
Gerenciamento de Projetos com Ênfase em TI.

Aprovada em ______ de ____________________ de __________.

BANCA EXAMINADORA:

___________________________________________
Prof. Adilson Pize - PMI-RS

____________________________________________
Prof. Ms. José Ignácio Jaeger Neto - PMI-RS

_____________________________________________
Prof. Ms. Eduardo Meira Peres - PUCRS

Porto Alegre
2011

Dedico este trabalho a todos que desafiam-se a ideias e
jogam-se a elas contendo primordialmente o
auxílio daquele que deve sempre lhe
apoiar incondicionalmente,
você mesmo.

AGRADECIMENTOS

Parece engraçado, mas é dificil nomear a quem agradecer, pois são tantas
pessoas que passam em nossas vidas, que na grande maioria das vezes, deixam-nos
algum aprendizado que fica guardando em algum canto do cérebro, que por vezes
naquele momento em que se recebeu o conhecimento, ele não foi útil, e até passou
despercebida a sua importância, mas, cedo ou tarde o amadurecimento vem, e se faz
recordar daquele aprendizado, mas infelizmente neste, não fica uma ligação com o cartão
de visitas da pessoa que lhe passou, logo, muitas vezes se tem um conhecimento orfão.
Tentando-se evitar ao máximo esquecer nomes, tenho a preferência de usar
grupos, ais quais todos os presentes são importantes, inclusos aqueles que realmente
impactaram a minha trajetória até o momento.
Sem sombra de dúvidas, o primeiro grupo a quem devo todos os agradecimentos
desde o início da vida é a família, em especial meus pais, Luiz Francisco e Sueli, e a
minha irmã Ana Cristina.
Sou grato a todos os amigos e networking gerado principalmente por:
– Grupo de Usuários de Software Livre Tchelinux.org;
– Aos meus colegas desta 4º turma da pós-graduação;
– Aos amigos desta turma que acreditaram em mim e na ideia de formar o GUGP
(Grupo de Usuários de Gerenciamento de Projetos), e no qual tive o prazer de
conhecer melhor o professor da pós, o colega de coordenação do GUGP, amigo
e orientador para esta monografia, Adilson Pize;
– Ao PMI-RS (Project Management Institute) e a oportunidade de poder contribuir
junto a coordenação do VII Seminário de Gerenciamento de Projetos;
– Ao IIBA (International Institute of Business Analysis) Porto Alegre;
– À vários Grupos de Usuários da Sucesu-RS;

“Tudo no mundo dos negócios ou é um projeto ou
está relacionado a um projeto.”
Paul Dinsmore

“Para projetos diferentes, cuidados diferentes”
Darcy Prado

“Mantenha a Simplificade”
Tom Peters

RESUMO

Apesar das circunstâncias mudarem constantemente, o “jogo de cintura” não é uma
boa tática empresarial, exemplificadamente, citando-se um exemplo de Carlos Alberto
Júlio, seria o mesmo comparando as empresas as pessoas, ao olhar para aquele amigo
boa vida que está torrando o dinheiro dos pais, como sendo sendo aquela empresa que
não planejam novos produtos e limitam-se a copiar os dos concorrentes.
Empresas hoje, devem pensar Estrategicamente, devem Gerenciar seus projetos,
mas para as micro e pequenas, que por muitas vezes nem planejamento estratégico há,
esta é uma arduosa tarefa.
Pensando-se assim, esta monografia foi escrita baseada em estudo bibliográfico
sobre Modelos, Frameworks e/ou Métodos Ágeis de Gerenciamento de Projetos, em
conjunto ao estudo do Guia PMBOK 4º ed, em especial as áreas de Gerenciamento de
Tempo e Comunicação, e sobre Gestão Estratégica no que tange o alinhamento dos
projetos ao contexto da empresa e cultura. Com isso, objetiva-se elucidar uma solução
para a escolha e priorização de projetos alinhados a Gestão Estratégica, e a realização
dos mesmo por Gerenciamento de Projetos com técnicas Ágeis.
Esta solução, objetiva contribuir para que estes tipos de empresas, obtenham
vantagem competitiva, obtendo-se melhores resultados de negócios.

Palavras-chave: Gestão Estratégica. Gerenciamento de Projetos. Métodos Ágeis.

ABSTRACT

Despite the circumstances change constantly, the "belt game" is not a good
business tactic, exemplified, citing an example of Carlos Alberto Julio would be the same
comparing companies to individuals, to look for that good life friend over ride over parents
money, as the company where not planning new products and limited copying of
competitors.
Companies today must think strategically, they must manage their projects, but for
micro and small, that often there is no strategic planning, this is a difficult task.
Thinking thus, this monograph was written based on bibliographic research on
models, Frameworks and / or Agile Project Management, in conjunction with the study of
the PMBOK Guide 4th ed, especially the areas of Time Management and Communication,
and on Strategic Management regarding the alignment of projects to the company context
and culture. Therefore, the objective is to elucidate a solution to the selection and
prioritization of projects aligned with strategic management, and performance of same for
Project Management with Agile techniques.
This solution aims to contribute to these types of companies, to gain competitive
advantage, achieving better business results.

Keywords: Strategic Management. Project Management. Agile.

LISTA DE ILUSTRAÇÕES

Figura 1 - Mapa Mental da Gerência Estratégica …...…................................................... 21
Figura 2 - Mapa Mental da Base Teórica …....................................................................... 28
Figura 3 - Mapa Mental da Base de Práticas …................................................................ 36
Figura 4 - Mapa Mental da Seleção de Projetos …........................................................... 40
Figura 5 - Matriz de Asnoff …............................................................................................ 42
Figura 6 - Matriz SWOT …................................................................................................. 43
Figura 7 - Mapa Mental da Priorização de Projetos …...................................................... 46
Figura 8 - Mapa Mental da Execução de Projetos …........................................................ 48

SUMÁRIO
1INTRODUÇÃO............................................................................................................7
1.1 OBJETIVOS.................................................................................................................10
1.1.1 Objetivo Geral ......................................................................................................10
1.1.2 Objetivos Específicos............................................................................................11
1.2 METODOLOGIAS.....................................................................................................11
1.1.3 Pesquisa Bibliográfica...........................................................................................11
1.1.4 Desenvolvimento dos Processos............................................................................12
1.3 SITUAÇÃO PROBLEMÁTICA..................................................................................13
2REFERÊNCIAL TEÓRICO........................................................................................15
2.1 GESTÃO ESTRATÉGICA..........................................................................................16
2.1.1 Planejamento Estratégico......................................................................................17
2.2 GERENCIAMENTO DE PROJETOS.........................................................................18
2.2.1 Benefícios..............................................................................................................18
2.2.2 Atribuições.............................................................................................................19
2.2.3 PMBOK.................................................................................................................20
2.3 MÉTODOS ÁGEIS......................................................................................................21
2.3.1 Onda Ágil..............................................................................................................22
2.3.2 Manifesto e Metodologias.....................................................................................23
3BASE TEÓRICA DA SOLUÇÃO................................................................................25
3.1 GESTÃO ESTRATÉGICA..........................................................................................25
3.2 PRINCÍPIOS DOS MÉTODOS ÁGEIS......................................................................26
3.3 VALORES DO XP – EXTREMING PROGRAMMING............................................27
3.4 PAPÉIS SCRUM.........................................................................................................29
3.5 ÁREAS DE CONHECIMENTO DO PMBOK............................................................31
4BASE PRÁTICA DA SOLUÇÃO................................................................................33
5SELECIONAR PROJETOS.......................................................................................37
5.1 OBJETIVIDADE NA GESTÃO ESTRATÉGICA.......................................................38
5.2 MATRIZ SWOT DE PROJETOS.................................................................................39
5.3 MENSURAÇÃO............................................................................................................40
5.4 PROJECT BACKLOG.................................................................................................41
6PRIORIZAÇÃO DE PROJETOS...............................................................................43
6.1 CUIDADOS.................................................................................................................44
7REALIZANDO PROJETOS.......................................................................................45
7.1 OBJETIVIDADE NO GERENCIAMENTO DE PROJETOS......................................47
7.2 PRINCIPIOS AGEIS EM GERENCIAMENTO DE PROJETOS ...............................48
7.4 MÉTODOS ÁGEIS EM COMUNICAÇÕES E RECURSOS HUMANOS..................52
8CONCLUSÃO............................................................................................................55
8.1 LIMITAÇÕES ESTUDO...............................................................................................56
8.2 TRABALHOS FUTUROS.............................................................................................56
REFERÊNCIAS...........................................................................................................58

10

1 INTRODUÇÃO

De modo clichê sempre é dito que o concorrente não é mais aquela empresa
a metros da sua, se diz que o concorrente é aquela empresa, não rara vezes,
desconhecida e/ou de outro país, tudo em virtude do cada vez mais mundo
globalizado.
Neste ambiente de economia globalizada, o ambiente das empresas é mais
competitivo, pois, o comércio é relativamente livre de tarifas e demais restrições são
quase artificiais (HITT, 2001), ocorrendo portanto batalhas diárias, não corporais,
que resulte em mortalidade de pessoas, mas sim batalhas entre empresas atrás de
seu retorno financeiro e por consequente, crescimento empresarial.
Do ambiente de antigas batalhas, como as travadas por Sun Tzu, a 2500
anos, se pode fazer uso de suas palavras, de conhecimento popular, “Se
conhecemos o inimigo e a nós mesmo, não precisamos temer o resultado de uma
centena de combates. Se nos conhecemos, mas não ao inimigo, para cada vitória
sofreremos uma derrota. Se não nos conhecemos nem ao inimigo, sucumbiremos
em todas as batalhas.”
Ou seja, o empresário deve conhecer a sua empresa e a dos concorrentes,
mas o principal inimigo é o mercado, deve-se conhecer onde sua empresa está
inserida para assim melhor posicionar suas vantagens, e para tais, criar as melhores
estratégias de crescimento, e com conhecimento sobre Gestão Estratégica, traçar
estas estratégias para o crescimento empresarial, complementando, “A estratégia
nunca foi tão importante quanto no atual ambiente de negócios.” (KAPLAN, 2000,
aba livro).
Através de estratégias, os gerentes planejam objetivos, e destes ações, para
reforçar a posição da empresa no mercado, promover a satisfação dos clientes e
atingir os objetivos de desempenho, (THOMPSON, 2000).
Tais estratégias, traçadas no planejamento estratégico da empresa, com
metas de curto a longo prazo, objetivam que a empresa eleve sua vantagem
competitiva, e “O planejamento estratégico é essencial para a saúde de cada
empresa. Um planejamento estratégico eficaz pode representar, a longo prazo, a
diferenca entre o sucesso e o fracasso.” (KERZNER, 2002, p.107)
A vantagem competitiva pode dar-se por várias fontes, como ter o produto

11

mais bem feito do mercado, ser capaz de proporcionar serviço superior ao cliente,
obter custos mais baixos que os rivais, estar em uma localização geográfica mais
conveniente, tecnologia patenteada, características e estilos mais atraentes para o
comprador, nome de marca bem conhecido e reputação, e “proporcionar um valor
maior pelo dinheiro (combinação de boa qualidade, bom serviço e preço aceitável)”,
(THOMPSON, 2000, p. 153), sendo outra vantagem o menor tempo de
desenvolvimento, teste e adequações, pois “um concorrente pode lançar
antecipadamente um produto similar e com melhor competitividade. Uma
modificação na legislação pode tornar o produto obsoleto” (PRADO, 2004, p. 196),
onde nesta vantagem, o uso de Gerenciamento de Projetos tende a impactar
positivamente.
O Gerenciamento de Projetos é aliado para este desempenho de lançamento
em menor tempo, sendo que a vantagem competitiva é que quanto mais cedo for
encerrado com sucesso um projeto, e lançado o seu produto, melhor tende a ser o
seu resultado em termos de inovação, market share e oportuniza iniciar antes um
processo de melhoria continua deste produto.
E, Gerenciamento de Projetos, (DINSMORE, 2010), não está mais sendo
utilizado apenas para projetos de engenharia de construção, como em sua origem,
mas sim tendo utilização nas empresas de todos os tipos, por diversas razões. E
este é o que às está alavancando ao sucesso, elas utilizam gerenciamento de
projetos como uma estratégia gerencial abrangente, e não apenas para gerenciar
projetos isolados.
Mas, antes de realizar os projetos, deve-se saber selecionar os projetos que
estão alinhados a estas estratégias, e selecionar projetos considerando-se apenas o
o projetos de modo isolado, eleva a possibilidade de não se obter bons resultados a
longo prazo na organização, além de que “os custos e benefícios de projetos de TI,
frequentamente, são afetados por outros projetos.” (JAEGER, 2010, p. 29)
Esta seleção de projetos de acordo com a estratégica empresarial é um dos
temas desta monografia, após, a priorização de execução dos projetos e o
gerenciamento deste projetos, de forma ágil, para alcançar os objetivos no menor
tempo possível.
O Gerenciamento de Projetos, também conceituado como Gestão de
Projetos, apesar que tais nomeações, por outros autores, é dada como não sendo

12

compatíveis, mas tal discussão não será abordada neste trabalho, usando-se aqui
como nomes similares.
Portanto, por Kerzner (2002, p.46), “Nenhuma empresa no mundo abandonou
a gestão de projetos depois de ter passado a utilizá-la. A razão para isso é que este
sistema realmente funciona!”
Os projetos, tanto na linha estratégica como isolados, quando bem
gerenciados, tendem para que a empresa atinja suas metas, mas se esses projetos
forem mal conduzidos, a tendência é de declínio empresarial. Portanto, é uma forte
justificativa para aumentar a capacidade para gerenciar projetos da organização.
(DINSMORE, 2010).
Focando-se em projetos relativos a Tecnologia da Informação nesta
monografia, no Gerenciamento de Projetos, vincula-se os Métodos Ágeis para
Desenvolvimento de Software, que são “maneiras melhores de desenvolver
software” (MANIFESTO ÁGIL, 2001), possuindo um conjunto de Princípios e
Práticas altamente adaptáveis, para se gerar mais resultado em menos tempo.
E esta adaptabilidade é importante, principalmente em TI, onde materiais que
usamos para criar o produto final são conforme Schwaber (2004, p. 1)
“extremamente voláteis”, como, ainda do mesmo autor “requisitos de utilização para
um programa que os usuários ainda têm que ver, a interoperação de programas de
outros sinais com o programa em questão, e a interação dos organismos mais
complexos do planeta - as pessoas.”
Dentre os Métodos Ágeis, há várias metodologias, mas utilizadas como objeto
deste estudo, apenas a Scrum e a Extreme Programming, apresentadas
posteriormente, sendo reutilizada de tais, conceitos e práticas.
A agilidade na execução de projetos, entregando produtos em menor prazo,
principalmente sobre os projetos de Tecnologia da Informação, é uma vantagem
competitiva muito impactante, em que deve-se ao fato que as janelas de
oportunidade serem cada vez menores, ou seja, poucos dias separam um
lançamento de um novo produto de um total sucesso, à um retumbante fracasso.

1.1 OBJETIVOS

13

1.1.1 Objetivo Geral

Com a citação de Joel Baker, “Visão sem ação é só um sonho; ação sem
visão é um passatempo; visão e ação juntas podem mudar o mundo” no filme o
Enigma dos Paradigmas, retirado de (JÚLIO, 2005, p.31), exemplifica-se o uso do
conhecimento de Gestão Estratégica como visão e Gerenciamento de Projetos como
ação.
Sobre ambos modelos de gestão, objetiva-se apresentar ao término deste
trabalho, uma solução para identificar os projetos que se alinham ao planejamento
estratégico da empresa, onde além da seleção dos mais aptos, se fazer a
priorização e otimizar a execução destes projetos, com Gerenciamento de Projetos
apoiados com técnicas Ágeis.
Em Gerenciamento de Projetos, o processo pretende contribuir para, com a
inclusão de técnicas Ágeis, agilizar, em especial, a comunicação dos recursos
humanos e o tempo de realização dos projetos.
Os processos estão pensados sobre micro e pequenas empresas,
principalmente às de TI, (BNDES, 2011; SEPRORGS, 2011), pois “Normalmente as
pequenas empresas tem mais facilidades para alcançar a excelência em gestão de
projetos via planejamento estratégico”, (KERZNER, 2002, p.113).
Informalmente falando, pretende-se demostrar uma solução para “fazer o
projeto certo”, e depois “fazer certo o projeto”.
Entende-se por solução, neste caso, não uma metodologia a ser seguida,
mas sugestões que podem ser usadas como processos padrões, principalmente
focado em micro e pequenas empresas, mas que pode ser repensado e
principalmente adaptado, citando-se “Todas as metodologias são baseadas no
medo. Tentam criar hábitos que impedem os seus medos de se tornar realidade.”
(BECK, 2000, p. 165), logo, deve-se encarar a adaptabilidade para segurança.

1.1.2 Objetivos Específicos

Os objetivos específicos são:

14

− Revisão bibliográfica sobre Gestão Estratégica;
− Revisão bibliográfica sobre Gerenciamento de Projetos;
− Revisão bibliográfica sobre o Guia PMBOK, 4º edição;
− Revisão bibliográfica sobre Métodos Ágeis;
− Revisão bibliográfica de Cases de Gestão Estratégica;
− Revisão bibliográfica de Cases de Gerenciamento de Projetos;
− Revisão bibliográfica de Cases de Métodos Ágeis;
− Desenvolver e apresentar neste trabalho, uma solução para seleção
projetos;
− Desenvolver e apresentar neste trabalho, uma solução para priorização de
projetos;
− Desenvolver e apresentar neste trabalho, uma solução para a execução e
gerenciamento ágil de projetos.

1.2 METODOLOGIAS

1.1.3 Pesquisa Bibliográfica

A pesquisa científica para trabalhos de conclusão de curso é dividida em
vários métodos para aquisição de conhecimento, onde, neste trabalho fez-se uso
principalmente de Estudo de Casos para fomentar conhecimentos para o
desenvolvimento da solução, além de Revisão Bibliográfica para a parte teórica.
Para a Revisão Bibliográfica, foi selecionado obras de Gestão Estratégica,
Planejamento Estratégico, Administração de Negócios, Gerenciamento de Projetos e
Metodologias Ágeis, que possuem, ou objetividade, como livros práticos, ou que
possuem Estudos de Casos.
Alguns conceitos de Métodos Ágeis, e por consequente, práticas, princípios e
Estudos de Caso, provem de sites na internet, além de livros.
A partir de livros, e neles a partir de estudos de casos, relatos e referências,
como os presentes em (DISNORE, 2010), (KERZNER, 2002), (KAPLAN, 2001),
(VARGAS, 2009), (PRADO, 2004), (SCHWABER, 2004), (BECK, 2000) foi analisado:

15

− Maturidade;
− Situação Inicial;
− Situação Atual;
− Melhorias;
− Práticas

1.1.4 Desenvolvimento dos Processos

A partir do aprendizado na Pesquisa Referêncial, foi desenvolvido conceitos,
sobre processos e práticas, para uso dentro dos modelos de Gestões estudados por
este trabalho, para que possam gerir, unidas, resultados positivos para as
organizações.
Com a frase de Tom Peters, “Mantenha a Simplificade”, em mente, pretende-
se a maior objetividade possível, presente até na esquematização dos processos.
A esquematização do processos é apresentada com o uso de mapas mentais,
“Mapas mentais, também conhecidos como mindmaps, são
considerados um padrão mundial para criação, gerenciamento e
comunicação de idéias. Os mapas mentais apóiam a organização de
idéias, de conhecimento através de uma visualização intuitivia e
amigável, além de possuir grande versatilidade visual.
Mapas mentais se iniciam com uma idéia central, onde todos os
ramos do mapa significam uma decomposição da idéia principal em
idéias relacionadas, baseadas em um modelo visual de pensamento.
O pensamento visual é um conceito baseado nas pesquisas de com
o cérebro humano funciona, onde se busca o estímulo do senso
visual e tátil, de modo a aumentar a criatividade e o entendimento
das partes em um todo unificado, reduzindo o tempo de
desenvolvimento e entendimento de idéias.” (VARGAS, 2009)
Os mapas mentais, que também serão usados em outras partes deste
trabalho para explicitação de outros conhecimentos, foram todos desenvolvidos
usando a ferramenta VYM (View your Mind), cujo desenvolvimento foi iniciado por
Uwe Drechsel mas hoje disponível livremente em
http://sourceforge.net/projects/vym/.

16

1.3 SITUAÇÃO PROBLEMÁTICA

Da conhecida questão de “fazer certo o projeto certo”, comumente
mencionado por Gerentes de Projetos em bate-papos de networkings, surgiu a ideia
da realização deste trabalho de conclusão de curso.
Atualmente, (KERZNER, 2002), Gerenciamento de Projetos está alinhando a
Gestão Estratégica de uma empresa apenas quando a mesma possui uma alta
maturidade em Gestão por Projetos, que (DINSMORE, 2010) conceitua por abranger
conceitos como a governança de projetos, gerenciamento de portfólios de projetos,
gerenciamento de programas e o gerenciamento de projetos em sí.
Por (KERZNER, 2002), uma empresa de alta maturidade possui uma
metodologia de Gerenciamento de Projetos já implementada e funcionando ao
mínimo a 2 anos, além dos demais conceitos, enquanto uma de maturidade mais
baixa, ainda não está com tais conceitos nem instituídos.
Normalmente, as que estão em nível de maturidade mais baixo, (KERZNER,
2002), infelizmente, não tem uma aplicação tanto da Gestão Estratégica, quanto do
Gerenciamento de Projetos, uma falha grave, pois o Gerenciamento de Projetos está
se tornando parte da filosofia gerencial das organizações, assim com a qualidade
total, a satisfação dos clientes ou a administração enxuta, o mesmo, está se
tornando inerente, devendo fazer parte integrante da empresa, pois é uma forma
consagrada de atingir metas (DINSMORE, 2010).
Como situação problema, notou-se, principalmente em empresas
classificadas como de maturidade mais baixa, duas necessidades, a primeira de um
processo simples para se identificar projetos que estejam alinhados a estratégia da
empresa, de acordo como cita Kerzner (2002, p. 130), “Aquilo que uma empresa
deseja fazer nem sempre é o que ela pode fazer e, normalmente, o maior obstáculo
está na disponibilidade e qualidade dos recursos necessários.”
E posteriormente, realizar o gerenciamento otimizado deste projeto com a
ajuda de técnicas ágeis, que além de tender a se obter o produto deste projeto em
menor tempo, em teoria usa menos recursos.
Neste trabalho, as empresas tidas como de baixa maturidade , e nas quais os
processos estão pensados, são as micro e pequenas empresas, especialmente as
de TI, (BNDES, 2011; SEPRORGS, 2011),

17

2 REFERÊNCIAL TEÓRICO

Indiscutivelmente a quem acompanha o estudo/ emprego de Gestão
Estratégica, Gerenciamento de Projetos e Métodos Ágeis, sabe que são assuntos
que estão presentes na maioria das conversas em eventos na área de
Gerenciamento de Projetos e TI, locais onde o autor deste trabalho sempre tentar

18

estar presente, podendo citar que os relatos vão de conceituais à práticos.
Mas apenas ter o emprego de tais Gestões e/ou Métodos, não garante o
sucesso, necessita-se que sua implantação esteja operacional, necessita-se ter
estratégias traçadas, pois sem haver planejamentos, torna-se mais difícil se prever
inovações, que normalmente garantem a desejada vantagem competitiva em relação
a concorrência, e sem o uso de gerenciamento de projetos, pode-se não obter
sucesso no desenvolvimento desta inovação.
Antes de qualquer aplicação da solução proposta, é importante que a
empresa já tenha alguma experiência mínima em Gestão Estratégica, ao mínimo em
Planejamento Estratégico, pois “a fase de planejamento é a mais importante de
qualquer tipo de projeto. Em teoria, o planejamento adequado é garantia do sucesso
de um projeto.” (KERZNER, 2002, p.178)
Depois, de uma análise sobre a empresa, "Concentre-se nos pontos fortes,
reconheça as fraquezas, agarre as oportunidades e proteja-se contra as ameaças "
(SUN TZU, 500 a.C.), e a implantação de um processo organizado, não apenas um
modelo, pois a maturidade vem de fazer sempre certo, em referêncial e resumo ao
porque de um processo e não somente um modelo, usa-se a citação:
“Pesquisa entre 275 gestores de portfólio mostrou que a capacidade
de executar a estratégia é mais importante do que a qualidade da
estratégia em sí. Estes gerentes citaram a implementação da
estratégia como o fator mais importante na avaliação da gerência e
da corporação. Essa descoberta parece surpreendente, pois nas
últimas duas décadas os teóricos em gestão, os consultores
gerenciais e a imprensa especializada se concentraram em como
desenvolver estratégias capazes de gerar desempenho superior.
Aparentemente, a formulação da estratégia nunca foi tão relevante”
(KAPLAN, 2000. p.11)
Citando-se (THOMPSON, 2000, p.2), “Em verdade, uma boa estratégia e uma
boa execução da estratégia são os sinais mais confiáveis de uma boa gerência.”
Para contextualizar melhor o estado da arte destas gestões, e servir de ponto
inicial para a busca de maiores conhecimentos sobre ambas, a seguir será
mencionado sobre Gestão Estratégica, Gerenciamento de Projetos e Métodos Ágeis,
que elucidarão, onde objetivamente serão conceituados, para facilitar o
entendimento da solução proposta para escolha e realização de projetos.

19

2.1 GESTÃO ESTRATÉGICA

Do famoso conto de fadas Alice no País das Maravilhas, de Lewis Carrol, há
sempre a lembrada converse entre os personagens Alice e o Gato de Cheshire,
onde a mesma encontrando-se perdida e pede ao gato qual caminho tomar, o
mesmo ao indagá-la sobre para onde ela quer ir, recebe a resposta que não sabe,
logo, o felino lhe responde basicamente um “tanto faz”, nos dando o conceito de
que, se não se sabe para onde quer ir, tanto faz o caminho.
Este “onde chegar” é o objetivo do planejamento estratégico, incluso na
Gestão Estratégica que possui por objetivo monitorar o “caminhar” até o objetivo.
Conceitualmente reforçado em (FGV, 2009), por assim definir a Gestão
Estratégica, é um “processo contínuo de determinação da visão, da missão e dos
objetivos da organização, em consonância com seus valores, no contexto de seu
ambiente competitivo de atuação, visando à formulação, à implementação e ao
controle de estratégias apropriadas para assegurar o sucesso da organização.”
Em Gestão Estratégica, em especial para este trabalho, é importante haver
um pré-conhecimento sobre Planejamento Estratégico, pois dos objetivos, ou metas,
ali traçados para o negócio da empresa, que virão as estratégias e as ações que
resultarão em projetos para serem gerenciados, como Prado (2004, p. 29) “a origem
dos projetos nas empresas é muito diversificada, mas existe uma forte ligação com a
origem das metas capazes de atender à estratégia de negócios da empresa”.
Kerzner (2002, p. 107) afirma “O planejamento estratégico é essencial para a
saúde de cada empresa. Um planejamento estratégico eficaz pode representar, a
longo prazo, a diferenca entre o sucesso e o fracasso.”
A Gestão Estatégica, é dada valor a este trabalho, pela questão que a maioria
das organizações de hoje opera por meio de unidades de negócio, ponto de vendas
pequenos, representantes, ou seja, de equipes descentralizadas, muito mais
próximas dos clientes do que o pessoal das grandes organizações. Essas
organizações reconhecem que a vantagem competitiva deriva mais do de recursos
intangíveis, como conhecimento, capacidades e relacionamentos criados pelos
empregrados, do que de investimentos em ativos físicos e do acesso ao capital.
Portanto, a implementação da estratégica exige que todas as unidades de negócio,

20

unidades de apoio e empregados estejam alinhado e conectados com a estratégia.
(KAPLAN, 2000).
E com normal rapidez das mudanças e na tecnologia, na concorrência e nos
regulamentos, a formulação e a implementação da estratégia devem converter-se
em processo contínuo e participativo. As empresas de hoje necessitam de uma
linguagem para a comunicação tanto da estratégia, como dos processos e sistemas
que contribuem para a implementação da estratégia, quem geram feedback sobre a
estratégia. O sucesso exige que a estratégia se transforme em tarefa cotidiana de
todos os envolvidos, (KAPLAN, 2000), de todos os stakeholders (recursos humanos
diretamente envolvidas ou impactados por projetos).

2.1.1 Planejamento Estratégico

O planejamento estratégico não é apenas um plano de objetivos, estratégias
e ações, ele envolve “quem nós somos, o que fazemos e para onde estamos
direcionados” (THOMPSON, 2000, p. 14), sendo assim uma soma de vários pontos
que levam a estratégica formulada pensando-se no negócio para, o sucesso do
negócio, (THOMPSON, 2000) define 5 atividades, denominadas por ele como
“Tarefas da Gerência Estratégica”, onde, o mapa mental a seguir faz uso do
demostrado em (THOMPSON, 2000, p. 14).

Figura 1. - Mapa Mental da Gerência Estratégica

21

Fonte: O autor (2011) baseado em (THOMPSON, 2000, p. 14)

2.2 GERENCIAMENTO DE PROJETOS

Reiterando-se de conceitos básicos para o bom entendimento, como a
definição de projeto sendo “um esforço temporário empreendido para criar um
produto, serviço ou resultado exclusivo. A sua natureza temporária indica um início e
um término definidos” presente no Guia PMBOK (PMBOK, 2008, p. 440) para o
Gerenciamento de Projetos, onde trata-se então que Gerenciamento de Projetos é a
aplicação de conhecimento, habilidades, ferramentas e práticas às atividades do
projeto a fim de atender aos seus requisitos.
O Gerenciamento de Projetos é a atividade do Gerente de Projetos, que por
sua vez o (PMBOK, 2008, p. 13) define em “a pessoa designada pela organização
executora para atingir os objetivos do projeto.”
Em (DINSMORE, 2010), simplifica em sua obra que tudo no mundo dos
negócios ou é um projeto ou está relacionado a um projeto, e que centenas de
atividades realizadas no dia a dia das empresas estão diretamente relacionadas com
projetos.

2.2.1 Benefícios

Em (VARGAS, 2009) explicita que dentre os principais benefícios da utilização
do gerenciamento de projetos, podem-se destacar, resumidamente:
− Supresas negativas durante a execução dos trabalhos;

22

− Permite desenvolver diferenciais competitivos e novas técnicas, uma vez
que toda a metodologia está sendo estuturada;
− Prevê as situações desfavoráveis que poderá ser encontradas, para que
ações preventivas e corretivas possam ser tomadas antes que essas
situações se consolidem como problemas;
− Adapta os trabalhos ao mercado e ao cliente;
− Disponibiliza os orçamentos antes do início dos gastos;
− Agiliza as decisões, já que as informações estão estruturadas e
disponibilizadas;
− Aumenta o controle gerencial de todas as fases implementadas devido ao
detalhamento ter sido realizado;
− Facilita e orienta as 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;
− Otimiza a alocação de pessoas, equipamentos e materiais necessário;
− Documenta e facilita as estimativas para futuros projetos.
O gerenciamento de projetos tem sido constantemente mencionado na
literatura de negócios, seja que nível for, pois não é por acaso que é a forma de
fazer com que as coisas sejam melhor feitas (DINSMORE, 2010).
No mesmo contexto de Dinsmore, Kerzner (2002, p. 32) enfatiza que “As
empresas que optaram por utilizar uma metodologia de gestão de projetos
perceberam, em seguida, que o potencial de benefícios existente era bem maior do
que o originalmente visto como possível.”

2.2.2 Atribuições

O estabelecimento de um projeto, advem de várias razões e objetivos, como
redução de custos, posicionamento de mercado, obtenção de economia de escala,
lançamento de novos produtos ou tecnologias, melhora de sistemas atuais,
implementação de processos de mudança organizacional, desenvolvimento sobre
requisição de novos softwares.
Ao Gerenciamento de Projetos, é atribuido inúmeros sucessos na realização

23

de projetos, de infindáveis áreas, onde além de que, por direcionamento e disciplina,
o próprio gerenciamento acaba tornando-se um diferencial além do produto, pois
“todos os projetos oferecem oportunidades de inovação, dependendo da orientação
que estiver sendo seguida.” (JAEGER, 2010, p. 29)
Estes sucessos, advém de centenas de pequenos projetos ocorrendo em
paralelo com as operações rotineiras da maioria das organizações, e elas estão
empregando técnicas e métodos de gerenciamento de projetos com estrondoso
sucesso. Estes processos, portanto, têm um pouco de projetos e um pouco de
operação rotineira. Por (PRADO, 2004), chama-se a isto de Gerenciamento por
Projetos (Management by Projects), que têm permeado setores normalmene
avessos a adminstração mais “quantificada”, como o de Recursos Humanos, sendo
este uma das áreas de estudo desta monografia.
Esta mistura, está transformando o Gerenciamento de Projetos, conforme
afirma Prado (2004, pg 25) em uma “boa prática da administração”, e esta é a
tendência gerencial mais marcante nas organizações atualmente, que para Tom
Peters, em Career Suvival Guide. Publicado pela revista Exame de Agosto de 1997,
p. 109, “o trabalho por projetos é o futuro da empresa”.

2.2.3 PMBOK

O PMBOK Guide (Project Management Book of Knowledgment), ou, Guia
PMBOK (Guia do Conhecimento em Gerenciamento de Projetos), é uma obra criada
pelo PMI (Project Management Institute), no qual é base para todo e qualquer
assunto referênciado em Gerenciamento de Projetos (PMBOK, 2008)
O livro define um ciclo de vida do projeto, divido em Início do Projeto,
Organização e Preparação, Execução do Trabalho do Projeto e Encerramento do
Projeto, dentro deste ciclo estão os os grupos de processos, que são Processos de
Iniciação, Planejamento, Execução, Monitoramento e Controle, e por fim o de
Encerramento (PMBOK, 2008).
E dentro destes processos, estão as 9 áreas de Conhecimento (PMBOK,
2008):
− Gerenciamento de Integração;

24

− Gerenciamento do Escopo;
− Gerenciamento do Tempo;
− Gerenciamento dos Custos;
− Gerenciamento da Qualidade;
− Gerenciamento dos Recursos Humanos;
− Gerenciamento das Comunicações;
− Gerenciamento dos Riscos;
− Gerenciamento das Aquisições;
A partir dele que se iniciou os estudos para esta monografia, baseando-se
principalmente na área de Recursos Humanos e a de Comunicações.
Todo projeto, como já mencionando, tem um ínício e um fim, portanto, a
solução proposta está dentro deste ciclo de vida na caracterização do projeto, nas
não dentre estes grupos, e sim apenas 3, Seleção, Priorização e Execução.
Salientando-se, que a solução proposta e o guia PMBOK, não são
excludentes.

2.3 MÉTODOS ÁGEIS

Constata-se através de relatórios como o Chaos Report (STANDISH, 2009)
que os projetos de desenvolvimento de softwares falham na ordem de 24%, sendo
os 76% restantes em projetos encerrados com sucesso e os que foram
finalizados, mas em termos de Gerenciamento de Projeto fracassaram, e o
relatório The State of Agile Development, publicado no 3rd Annual Survey
(VERSIONONE, 2008), apresenta que 55% dos projetos que usam Métodos Ágeis
estão entre 90% e 100% de sucesso (RODRIGUES, 2010).
Com tais números, é possível salientar porque 76% das empresas
consultadas no relatório IT Governance and Project Management Survey (DR
DOOB'S, 2009) adotaram técnicas dos métodos ágeis em 1 ou mais projetos.
Os Métodos Ágeis são uma coleção positiva de valores, princípios e práticas,
ou técnicas, de metodologias usadas desde a década de 90 para
desenvolvimento de software, época na qual projetos de TI (Tecnologia da

25

Informação) sofriam duras críticas e eram considerados sempre falhos, pois havia
um maior desenvolvimento do hardware em relação aos softwares que os mesmos
teriam que utilizar, (COHEN, 2004).
Inúmeros livros e artigos surgem constantemente com comparações,
avaliações, pontos de vista favoráveis ou não, a aplicabilidade dos Métodos Ágeis
em relação ao Guia PMBOK (PMBOK, 2008), sendo em (SLIGER, 2006) afirmado,
“que apesar das diferenças de filosofias entre PMI e Agile, muitas das práticas do
(PMBOK, 2008) são compatíveis com as práticas ágeis”.
Em (KOCH, 2004) há uma comparação completa dos processos do (PMBOK,
2008) com as práticas dos Métodos Ágeis, concluindo que “Nada nas Metodologias
Ágeis é incompatível com os processos do PMBOK” e que “pode ser oportuno
reforçar as Metodologias Ágeis com processos do PMBOK, porém somente onde
realmente necessário e sem comprometer a agilidade”.
Os métodos ágeis possuem embasamento em 12 recomendações,
denominadas Princípios para o Desenvolvimento Ágil de Software (PRINCÍPIOS
ÁGEIS, 2001). Estes essencialmente ressaltando valores ao qual ajudam não
apenas projetos para desenvolvimento de software, mas acredita-se que todo e
qualquer tipo de projeto.

2.3.1 Onda Ágil

Os Métodos Ágeis, ou também nominados de Agile, surgiram com o intuito de
desenvolvimento mais rápido e eficaz de softwares, proporcionando entregas mais
rápidas em detrimento de menos processos da Engenharia de Software (MAGELA,
2006).
O desenvolvimento de software, orientado por práticas ágeis de forma
fortemente organizada como há atualmente, data do ano 2001 (HISTÓRIA
MANIFESTO, 2001), onde 17 profissionais da TI e outros simpáticos à causa,
observaram a necessidade de uma documentação formal que guiasse o
desenvolvimento ágil, criando assim o Manifesto Ágil (MANIFESTO, 2001) e os 12
Princípios (PRINCÍPIOS ÁGEIS, 2001).
Os marcos iniciais, e mais conhecidos, que levaram a criação deste consórcio
de profissionais e da (AGILE ALLIANCE, 2010), foram o projeto gerido por Kent

26

Beck no qual criou o XP (Extreme Programming), o Chrysler Comprehensive
Compensation System, comumente chamado de C3 (C3, 1995) e o do United
Overseas Bank, no qual Peter Coad e Jeff de Luca implementaram o FDD (Feature-
Driven Development) publicado pela primeira vez em (COAD, 1998).
A Onda Ágil é facilmente perceptível na quantidade crescente de eventos
sobre o assunto, (RODRIGUES, 2010), exemplificando-se 2 deles do ano 2010, o
ocorrido em Junho, Agile Brazil 2010 em Porto Alegre – RS, que teve mais de 700
inscritos (AGILE, 2010) e em Maio ocorreu o Maré de Agilidade em Belo Horizonte –
MG, com mais de 300 inscritos (MARÉ, 2010), havendo ainda grupos de usuários
como o Guma-RS, (GUMA, 2010), que planejou 10 eventos gratuitos para 2010.

2.3.2 Manifesto e Metodologias

As Metodologias Ágeis, podem ser explicadas com o embasamento do
manifesto feito pela maioria dos seus autores, que é:
“Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano”
(MANIFESTO ÁGIL, 2001)
Há hoje, inúmeras metodologias dadas como ágeis, sendo as principais
Extreme Programming (XP), Scrum, DSDM, Adaptive Software Development,
Crystal, Feature-Driven Development, Pragmatic Programming e Lean, mas, foram
objetos de estudo para uso neste trabalho apenas, Extreme Programming (XP) e
Scrum.
Dize-se para Scrum, mas serve para XP, que seus fundamentos filosóficos
têm foco na capacitação da equipe de desenvolvimento e em satisfazer os clientes,
mas tendo Scrum atenção especial para a sua cultura gerencial que está enraizada
em ajudar os outros a atingir seus objetivos, e XP focando em suas ferramentas
técnicas são focados em ter decisões baseadas em fatos através de um processo de
aprendizagem. Conforme Mary Poppendieck. (SCHWABER, 2004, pg xiv) “Quando
todos esses fatores estão no lugar, é difícil para Scrum não para ter sucesso.”

27

3 BASE TEÓRICA DA SOLUÇÃO

Para este trabalho, foi feita uma extensa revisão bibliográfica, que resultou no
mapa mental a seguir, onde é explicitada a parte teórica da solução.
Esta monografia, não enfoca diretamente sobre todos os assuntos expostos,
sendo sugerida o apronfudamento através das referências deste trabalho.
Toda a base da solução está no compromentimento, portanto, assim em

28

especial tais áreas:

Figura 2. - Mapa Mental da Base Teórica

Fonte: O autor (2011)

Para exemplificação do comprometimento, faze-se uso deste interessante
conto presente em (SCHWABER, 2004, p. 7)
“Uma galinha e um porco estão andando pela estrada. A galinha diz
para o porco, "você quer abrir um restaurante comigo?" O porco
considera a pergunta e responde, "sim, eu gostaria disso. Como você
quer chamar o restaurante?" e a galinha responde, "Presunto e
Ovos!" O porco pára, pára e responde: "Pensando bem, eu não acho
que eu quero abrir um restaurante com você. Eu estaria
comprometido, mas você só estaria envolvido.”

3.1 GESTÃO ESTRATÉGICA

A Gestão Estratégica para o objetivo desta monografia, foi usada basicamente
para aquela expressão popular “Um olho no peixe e outro no gato?”, ou seja, o
nosso objetivo, o sucesso do projeto, está cercado de perigos, o lucro que se almeja,
é o mesmo que o concorrente quer.
Além do básico, deve-se saber aonde se quer ir, e como se chegar, com a
maior probabilidade de acerto possível, Beck (2000, p. 43) diz que “O primeiro passo
é decidir sobre o âmbito. O que é isso que vamos tentar prescrever? Que tipos de
problemas que vamos abordar e que tipos de problemas vamos ignorar?”
Logo, planejamento é importante, e estratégias mais ainda, não é porque o
projeto anterior foi bem sucessido, que o próximo será, é perigoso imaginar que
sendo feito de uma maneira mais “folgada” que tudo vai correr às mil maravilhas
(PRADO, 2004), o área de Gestão Estratégica nos ensina que o planejamento

29

estratégico deve ser um guia, visto, revisto, atualizado, e como Kerzner (2002. p.
114) afirma, “O planejamento estratégico eficaz para a gestão de projetos é uma
tarefa interminável.”
O uso de Gestão Estratégica esta mais alinhado na solução focando no
sucesso empresarial mais do que do próprio projeto, ficando assim compravada a
questão do foco em micro e pequenas empresas.
O Gerenciamento de Projetos, para empresas que nem do Planejamento
Estratégico fazem uso, tende a não ter o sucesso impactante ao qual é possível.
Para as empresas, este é o primeiro passo para a maturidade que Kerzner
(2002) avalia as empresas, e o primeiro passo para que esta solução da monografia
possa ter bons resultados.
A “Estratégia se faz com planejamento e Execução. É crucial investir tempo e
recursos financeiros em estratégia. Deve-se criar o hábito de pensar em estratégica”
(JÚLIO, 2005, p. 29)

3.2 PRINCÍPIOS DOS MÉTODOS ÁGEIS

Os princípios dos Métodos Ágeis, (PRINCÍPIOS ÁGEIS, 2001) assim como
em sua essência, tem uso no objetivo nesta monografia na questão de mudança de
valores, de pensamento sobre ações e ao trabalho realizado dentro e fora do
empreendimento, projetos, equipes.
Os 12 Princípios estudados são:
− Nossa maior prioridade é satisfazer o cliente, através da
entrega adiantada e contínua de software de valor.
− Aceitar mudanças de requisitos, mesmo no fim do
desenvolvimento. Processos ágeis se adequam a mudanças, para
que o cliente possa tirar vantagens competitivas.
− Entregar software funcionando com freqüencia, na escala de
semanas até meses, com preferência aos períodos mais curtos.
− Pessoas relacionadas à negócios e desenvolvedores devem
trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
− Construir projetos ao redor de indivíduos motivados. Dando a
eles o ambiente e suporte necessário, e confiar que farão seu
trabalho.

30

− O Método mais eficiente e eficaz de transmitir informações
para, e por dentro de um time de desenvolvimento, é através de uma
conversa cara a cara.
− Software funcional é a medida primária de progresso.
− Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser capazes de
manter indefinidamente, passos constantes.
− Contínua atenção à excelência técnica e bom design,
aumenta a agilidade.
− Simplicidade: a arte de maximizar a quantidade de trabalho
que não precisou ser feito.
− As melhores arquiteturas, requisitos e designs emergem de
times auto-organizáveis.
− Em intervalos regulares, o time reflete em como ficar mais
efetivo, então, se ajustam e otimizam seu comportamento de acordo.
(PRINCÍPIOS ÁGEIS, 2001)
Agem diretamente para mudanças, ou conforme Dinsmore (2010, p. 41) “Para
que a gestão por projetos seja eficaz, são necessárias mudanças na estrutura e na
cultura da organização, no seu estilo gerencial e fluxo de informações.”

3.3 VALORES DO XP – EXTREMING PROGRAMMING

Comumente dize-se que uma pessoa que não é socialmente compatível com
as demais, ou diretamente, uma má pessoa, não tem valores, logo, eles são
importantes.
A solução proposta, como já percebida em relação aos Princípios Métodos
Ágeis, tende a atuar na mudança comportamental de todos os envolvidos, sejam
eles da diretoria da empresa à equipe de projeto.
Beck (2000, p. 73) inicia a menção dos valores do XP, metodologia por ele
criada, fazendo alusão a “aprendendo a dirigir”, onde “lembra-nos a fazer muitas
mudanças pequenas e nunca tirar os olhos da estrada.”
Os valores por ele agregados ao XP são “Os quatro valores – comunicação,
simplicidade, feedback e coragem – nos dão os critérios para uma solução de
sucesso.” (Beck, 2000, pg 37)
Mas, poderiam ser também os 4 valores do Kerzner, pois ele afirma “A cultura

31

de gestão de projetos que dá resultados é aquela baseada em confiança,
comunicação, cooperação e trabalho em equipe.” (KERZNER, 2002, p.153).
Em uma comparação básica, a comunicação de Beck é a mesma
comunicação de Kerzner, a simplicidade pode ser a cooperação, o feedback é o
trabalho em equipe e a coragem, claro que a confiança.
Abaixo, cito os valores do XP, explicação e aplicação:
Comunicação: Um projeto não pode terminar bem se os envolvidos não se
comunicam satisfatóriamente, diz Beck (2000, pg 29-30) “Problemas em projetos
podem invariavelmente ser traçados quando alguém não conversa com álguem se
não for sobre alguma coisa importante.”
O Guia PMBOK (PMBOK, 2008) usa a área de conhecimento Gerenciamento
das Comunicações do projeto em seus 5 processos, mas nesta aplicação, ela vai
além de só comunicação, estaria principalmente bem alinhada a área de
conhecimento do Gerenciamento dos Recursos Humanos, além das demais.
A comunicação é aplicada no sentido amplo de manter todos os envolvidos,
os stakeholders, informados sobre os objetivos e resultados.
Simplicidade: É um conceito amplo e comumente tido como fácil, assim como
a comunicação, mas não é, a simplicidade não é fácil, eis um dos motivos que micro
e pequenas empresas acabam não dando certo.
Comumente, elas tornam a burocratizar processos, encher de práticas ou
sub-processos, que os tornão enfadonhos e fazem com que as mesmas os
abandonem, e dentro do projeto, o líder do mesmo, como em XP chamado de
Coach, deve inicialmente perguntar “qual é a coisa mais simples que poderia
funcionar?” (BECK, 2000, p. 30), e assim deve ser, em se tratando de projetos de TI,
ao qual a solução foi pensada, isso torna-se mais fácil com o uso de algumas
práticas, posteriormente mencionadas.
No mesmo valor, inclue-se que que é melhor fazer uma coisa simples hoje, e
um pouco mais amanhã, assim custará menos para alterá-lo, e torna-se assim mais
simples de se fazer, do que fazer uma coisa mais complicada e demorada que
nunca venha a ser usado (BECK, 2000).
Feedback: O feedback, ou em português poderia ser algo como retorno de
conhecimento, pode ser explicitado como “Reacções concretas sobre o estado atual
do sistema é absolutamente impagável. Otimismo é um risco ocupacional de

32

programação. Feedback é o tratamento” (BECK, 2000, p. 31).
Este valor contribui significativamente nos demais, pois quanto mais feedback
tiver, mais fácil é se comunicar. E quanto mais os stakeholders se comunicam,
melhor tende a ser o senso comum do que pode ser simples. (BECK, 2000, p. 32).
A aplicação de feedback é justamente ser um motivo para a comunicação,
que acaba gerando um maior comprometimento de todos, para assim se elevar a
confiança no projeto, a coragem.
Coragem: É o mais inintendível dos valores, mas tornando o conceito simples,
é acreditar, ter confiança no envolvimento mútuo dos stakeholders no projeto, algo
como, se o líder do mesmo tiver coragem, os demais vão por em produção.
A aplicação gira em torno de que, o Gerente do Projeto, o Líder Técnico,
Coordenador, XP Coach, Scrum Master, ou nome a ser usado, tenha auto-confiança
e passe a mesma adiante, criando uma motivação acima dos conhecidos, por
exemplo, na Teoria de Moslow (PRADO, 2004, p. 221), Tipo Gerencial (PRADO,
2004, p. 222) ou a Teoria Higiênico/ Motivadora de Herzberg (PRADO, 2004, p. 223).
Em Dinsmore (2010) é mencionado que encontrar as hipóteses certas e
torná-las conhecidas a todo o pessoal envolvido são tarefas teoricamente fáceis,
assim enfatizando a comunicação e simplicdade, mas o trecho “assegurar que os
membros de uma equipe de remadores estejam dentro do barco antes de
começarem a remar.” (Dinsmore, 2010, p. 178) exemplifica todas as demais, em
uma equipe de remadores, há de se ter os 4 valores para o sucesso.

3.4 PAPÉIS SCRUM

O Scrum, é tido como um Método Ágil mais focado em Gerenciamento,
principalmente pela questão de não se focar tanto em práticas de desenvolvimento
como o XP (Extreme Programming), no caso, sendo-as mais específicas ainda para
o desenvolvimento de software.
Em Scrum, foi criado 3 papéis, na verdade, apenas um nomeamento
diferenciados, sendo eles Product Owner, o Team (Equipe), e o Scrum Master, e
todas as responsabilidades do gerenciamento do projeto são dividas entre estes 3
papéis, (SCHAWBER, 2004, p. 6), sendo tais responsabilidades individuais
parecidas com as do Analista de Negócios, a Equipe, e o Gerente do Projeto.

33

O Product Ower (Proprietário do Produto em uma tradução) é o responsável
por representar os interesses de todos com uma participação no projeto e seu
sistema resultante.
Basicamente, o Product Owner consegue financiamento inicial e permanente
para o projeto, criando requisitos gerais para o projeto, analisa o retorno do
investimento (ROI), além de estar a parte de objetivos e planos de lançamento.
Ele é o representante do sponsor, patrocinador, do projeto, atuando junto a
equipe de desenvolvimento, sendo o único papel que realmente trabalha como no
Scrum, com a única ressalva de não ser o único detentor do Project Backlog, este
pertende a todos os stakeholders.
O Team, ou Equipe, são os responsáveis pelo desenvolvimento. Prioriza-se
práticas dentro das Equipes, como serem auto-gerenciaveis, auto-organizadas e
multi-funcionais, e ela é responsável por descobrir como transformar o que há no
Product Backlog em um incremento de funcionalidade dentro de uma iteração, e
gerenciar seu próprio trabalho. Os membros da equipe são coletivamente
responsáveis pelo sucesso de cada iteração e do projeto como um todo, assim como
o fracasso, na solução desta monografia, o Team, são todos os stakeholders.
O Scrum Master é o responsável pelo processo do Scrum, mantendo unidos
Team e Product Owner e demais envolvidos no projeto, e para assegurar que todos
sigam as regras e práticas do Scrum, no caso, este papél tem uma modificação
neste processo, já que não há o processo Scrum, atuando como o Gerente de
Projetos.
Em uma analogia presente em (DINSMORE, 2010), os papéis, os envolvidos
em todo o projeto, que já deve estar dentro de um plano estratégico para a
organização, devem trabalhar em conjunto, comparando a eficácia da formação em
'V' dos gansos, na consideração do alinhamento estratégico de projetos, “O trabalho
em conjunto e a recíproca contra correntes adversas, tanto entre gansos como entre
projetos estratégicos, criam uma sinergia que os leva eficazmente a seus destinos”
(DINSMORE, 2010, p. 40)

3.5 ÁREAS DE CONHECIMENTO DO PMBOK

O Guia PMBOK (PMBOK, 2008) está divido em 9 Áreas de Conhecimento,

34

aos quais se foi feita uma analogia a cada Princípio dos Métodos Ágeis, aplicadas
mais a seguir.
Estas Áreas de Conhecimento fazem uso nesta solução no sentido de serem,
sem exceção, partes importantes do Gerenciamento de Projetos, mas, pela solução
ser simplificada, nem todas são adaptadas e recebem maior atenção como o
Gerenciamento das Comunicações e o Gerenciamento dos Recursos Humanos.
O Gerenciamento dos Recursos Humanos, que o PMBOK (PMBOK, 2008)
define como “inclui os processos que organizam e gerenciam a equipe do projeto”,
assim como o Gerenciamento das Comunicações, explicitado pelo PMBOK
(PMBOK, 2008) como “inclui os processos necessários para assegurar que as
informações do projeto sejam geradas, coletadas, distribuídas, armazenadas,
recuperadas e organizadas de maneira oportuna e apropriada”, estão inclusos
dentre os conceitos tanto dos Valores do XP quanto dos Princípios dos Métodos
Ágeis.
Ambas áreas, são vitais para a estratégia, e a mudanças também nestas tem
resultados mais perseptíveis, a estratégia exige mudanças em praticamente todas
as partes da organização, e a estratégia demanda trabalho em equipe para a
coordenação das mudanças (KAPLAN, 2000).
Motiva os esforços da aplicação da solução desta monografia sobre estas
duas áreas, por acreditar que sobre tais o impacto de mudanças tende a ser maior,
ainda mais se levado em consideração o percentual de investimento em recursos
financeiros frente as demais áreas, visto que tirando práticas que podem ser feitas,
como treinamentos e consultorias externas, o restante está baseado em ações
comportamentais.

35

4 BASE PRÁTICA DA SOLUÇÃO

A base prática da solução proposta, faz uma miscelânea direta de tarefas
presentes nos Métodos Ágeis e citadas para modelos de gestões, como Gestão
Estratégica e/ou Empresarial.
O objetivo é tornar mais simples as centenas de atividades realizadas no dia a
dia das empresas que estão diretamente relacionadas com projetos. (DINSMORE,
2010), assim, tendo a facilitar o gerenciamento para os projetos atingirem suas
metas, o que é vital para a empresa.
O mapa mental a seguir demostra algumas das práticas sugestionadas.

Figura 3. - Mapa Mental da Base de Práticas

36


Mapas Mentais: Como já informado nesta monografia, os mapas mentais são
formas de criar e expressar conhecimento, usando os 2 lados do cérebro, facilitando
assim tanto a explicitação, como o entendimento do conhecimento criado/ exposto.
Matriz de Ansnof: A também chamada de Matriz Produto/Mercado,
caracterizada por ter seus 4 quadros em Penetração do Mercado, Desenvolvimento
do Produto, Desenvolvimento do Mercado e Diversificação.
É um modelo gráfico que pode ser utilizado para determinar oportunidades de
crescimento de unidades de negócio de uma empresa, e o uso dela nesta solução
não sai deste contexto, onde é usada para avaliar se o produto resultante do projeto,
é ou não favorável ao atual momento da empresa.
Matriz SWOT: A bem conhecida matriz de Strengths (Forças), Weaknesses
(Fraquezas), Opportunities (Oportunidades) e Threats (Ameaças), que muitos
atribuem a criação a professores de Hardvard, mas pelo conceito tão simples e
aplicável, pode ser fato de sua origem ser de 500 a.C por Sun Tzu onde afirmou
“Concentre-se nos pontos fortes, reconheça as fraquezas, agarre as oportunidades e
proteja-se contra as ameaças”.
Ela tem a sua aplicação nesta solução para mensuração dos projetos que
melhor tendem a resultar melhor Retorno sobre o Investimento (ROI).
Project Backlog: Os requisitos levantados pelo Product Owner, a “lista de
requisitos” é chamado de Product Backlog no processo do Scrum, onde o Product
Owner é responsável por usar o Product Backlog para garantir que a funcionalidade
mais valiosa seja produzida, o que é conseguido através da frequente reanálise do

37

Product Backlog, sendo os mais importantes para serem usados na próxima
iteração.
O Project Backlog tem o mesmo conceito, mas ao invés de requisitos, são os
Projetos provenientes das Ações, que derivam das Estratégias para obtenção dos
Objetivos do Planejamento Estratégico.
No Project Backlog, além da Lista de Projetos, destes estão os Requisitos,
logo, o Product Backlog, e também a mensuração de Business Value, ou, o Valor de
Negócio, que é a melhor forma encontrada para pontuar a importância de um
projeto, sendo tal usado para pontuar em Scrum e XP, o valor de cada requisito do
Product Backlog.
O Business Value é um valor constante, da soma de interesses do sponsor,
Product Owner e possivelmente os demais stakeholders, onde tudo dentro do
conceito da solução, é adaptável a empresa em questão, sendo que foi pensando
sendo ROI / Recursos financeiros a serem investidos em projetos.
Sprint Planning: Também conhecido como “Jogo do Planejamento”, é onde os
stakeholders, ou Product Owner, Scrum Master e o Team, definem o que será feito
na iteração de desenvolvimento do Software, sendo que nesta solução, será
também usado em consonância ao Project Backlog, além do Product Backlog.
Integração Contínua: Esta em Desenvolvimendo de Software é a cada parte
desenvolvida do software, esta ser já aglutinada ao restante, simples, e isto gera
uma melhor métrica sobre o desenvolvimento total, assim como evita a redundância
e sobreescrita de informações, em Gerenciamento de Projetos, basta a troca da
palavra Software por Projeto.
Ritmo Sustentável: O trabalho de desenvolvimento do projeto não deve ser
moroso, desmotivante para os stakeholders, deve-se manter elevada a moral da
equipe, e o Gerente do Projeto, Scrum Master, tem de saber lidar com os desafios
diários do projeto e com conflitos dentro da equipe, que infelizmente ocorrem, como
Prado (2000, p. 220) afirma “É também fundamental manter sempre alta a motivação
das pessoas, mesmo os momentos de crises agudas, quando tudo parece indicar
que o projeto será um fracasso.”
Conteúdo Coletivo: Basicamente é não esconder informações, entrando no
sentido que todos os envolvidos, são responsáveis pelo projeto, são stakeholders,
logo, devem saber dos sucessos e fracassos do mesmo, mas sobre divulgar a

38

estratégia a empregados e o medo de vazamento de informações em (KAPLAN,
2000, p. 23) menciona “Brian Baker, da Mobil, assim responde a esse
questionamento: “O conhecimentode nossa estratégia de pouco adiantará aos
concorrentes, se não souberem executá-la. Por outro lado, não temos condições de
executar a estratégia se nosso pessoal desconhecê-la. É um risco que precisamos
assumir.”
Equipe Auto-organizável: Para alguns isto é uma utopia, mas é possível uma
equipe de desenvolvimento se organizar sozinha, sabendo fazer o que cada um vai
fazer em seu turno de trabalho, uma das práticas essenciais para que esta prática se
realize é a construção de um Quadro de Kanban. Esta base prática se alinha
diretamente na solução proposta por esta monografia no sentido de que, por ser
focada a empresas cujo os recursos financeiros são escassos e principalmente,
pequenas equipes de trabalhos.
Também auxilia para esta etapa da solução, o nivelamento dos recursos, ou
seja, quem possui um nível maior de conhecimento trabalhar junto a quem possui
menos, fazendo com que um complemente o outro, Prado (2004, p. 114) diz que “o
nivelamento de recursos procura minimizar a existência de recursos ociosos durante
a execução do projeto”.
Retrospectiva/ Feedback: São 2 práticas dos Métodos Ágeis, usadas nesta
solução de forma conjunta, tanto a retrospectiva, que é distribuir as informações
positivas e negativas entre os stakeholders, como o feeback que seria o repasse de
resultados atuais, atuam conjuntamente, e o interessante para a moral da equipe é
como Prado (2004, p. 217) mencioa “Lembre-se: é uma festa e não uma reunião de
trabalho. Premiações podem ocorrer, mas, preferencialmente, forneça prêmios a
equipes e não a indivíduos. O final de um projeto de sucesso merece, então, uma
comemoração formal.”
Stand-up Meeting: Pequenas reuniões, diárias, curtas, envolvendo a grande
maioria dos stakeholders, onde é passado informações sobre o andamento do
projeto, o que foi feito anteriormente e o que será feito no futuro, sendo mais
específico, pode até ser o que ocorreu ontem e o que será feito hoje, também sendo
uma importante oportunidade pra demostração de resultados, uma pequena
comemoração de resultados intermediários, que é importante para manter a moral
da equipe alta. (PRADO, 2004)

39

Outras práticas e até processos podem ser somandos, como por exemplo,
técnicas de liderança para atuar junto ao Gerente do Projeto, são importantes, para
facilitar a manter o equilíbrio das tensões entre estabilidade e mudança (KAPLAN,
2000).
O importante em termos de práticas, é que auxiliem para sobressair as
vantagens advindas de um projeto bem gerenciado, em que a execução não diferirá
significativamente do planejamento. Onde neste, da melhor forma possível, atender
aquilo que o cliente deseja, “por meio do gerenciamento de projetos há mais
chances de termos clientes satisfeitos.” (PRADO, 2004, pg 20)
E em pró a esta adaptação a realidade da empresa, contribui Prado (2004, p.
187) com “Gerentes diferentes conduzem seus trabalhos de maneira diferente.
Projetos diferentes são executados de maneira diferente. Empresas diferentes
possuem culturas diferentes.”

5 SELECIONAR PROJETOS

“Fazer o Projeto Certo” poderia ser também o título deste capítulo, onde nesta
monografia, a solução é explicitada no mapa mental a seguir:

Figura 4. - Mapa Mental da Seleção de Projetos

40


Escolhas devem sem feitas de acordo com o que, primeiramente, se pode
alcançar ao momento, então, deve-se haver adaptações e mudanças, avaliar o
produto que trará mais retorno ao negócio, nesta ideia, cita-se Fernando Pessoa em
artigo de 1926 “A essência do comércio” que diz “se queremos servir os outros, nós
é que devemos pensar como eles.”, Foco do Cliente e não Foco no Cliente (JÚLIO,
2005)
Não é possível realizar todos os projetos, e os critérios de escolha envolvem
fatores que contribuam, preferêncialmente, o mais positivamente possível ao
negócio, “Esses fatores estão diretamento ligados aos objetivos da organização e,
geralmente, são relacionados ao produto do projeto e aos benefícios que esse
produto trará para a organização.” (JAEGER, 2010, p.33)
O produto do projeto, não necesáriamente é algo que será vendido em
prateleira por exemplo, tudo depende dos objetivos traçado no planejamento
estratégico, o próprio replanejamento pode ser um projeto, pois a estratégica é um
processo contínuo, a paisagem competitiva se encontra em constante mudança.
(KAPLAN, 2000).

5.1 OBJETIVIDADE NA GESTÃO ESTRATÉGICA

41

De acordo como mencionado na introdução, objetiva-se tornar simples e
adaptável principalmente às pequenas e médias empresas a solução exposta neste
trabalho.
A primeira parte para a solução funcionar, é a empresa fazer uso de Gestão
Estratégica, ter ao menos os conceitos de Visão, pois, pior que uma estratégia
simplificada é não ter estratégia nenhuma, como referenciado em (JÚLIO, 2005),
não tem visão do negócio, equivale a navegar sem bússola, ou, um avião que voa
10 minutos no sentido contrário de sua rota, que está 20 minutos mais longe do
destino desejado.
Todos os envolvidos na estratégica da empresa devem estar cientes da
mesma, em uma exemplificação bem clara, a prática do Conteúdo Coletivo, assim
como a Retrospectiva, sendo que a a implementação da estratégia requer atenção e
foco contínuos na iniciativas e na execução das mudanças, em constante medição
com os resultados almejados.(KAPLAN, 2000)
Em termos de solução, a Objetividade se dá à partir diretamente para o
Planejamento Estratégico, para que deste saia os Objetivos, do mesmo as
Estratégias, para assim Ações e Projetos.
Nas ações, há o que se quer, o produto A, ao exemplo, e em outra teriamos o
produto B, e C, D, por sequência, e qual o mais adequado a ser realizado?
A objetividade desta resposta está no uso de alguma ferramenta para simples
análise dos projetos, sendo a sugestionada nesta solução a Matriz de Ansnoff, onde
são equacionados o Produto em Relação ao Mercado, levando-se em consideração
a Novos Produtos/ Mercados ou já Existentes, e a avaliação sobre pontos como
Penetração de Mercado, Desenvolvimento de Produtos, Desenvolvimento de
Mercado e diversificação.

Figura 5. - Matriz de Asnoff

42

Fonte: WIKIPÉDIA (2011)a

Os Mapas Mentais contribuem neste processo de Objetividade ao
Gerenciamento de Projetos no que tange a simplificação de demostrar, os recursos
e requisitos necessários para a realização do mesmo.
Assim como no uso de uma EAP (Estrutura Analítica de Projeto), por
(PMBOK, 2008), o uso do Mapa Mental, possibilita conhecer as necessidades para o
projeto, e com isso ser possível a sua orçamentação, tendo-se assim o custo do
mesmo, que é a base para a seleção desta solução, sendo normalmente financeiro o
principal impedimento de novos projetos nas empresas.
Este recurso da criação dos Mapas Mentais dos Projetos, contribui também
para se obter outras informações muito importantes a cerca do projeto, como o
Tempo previsto para sua realização, os Riscos pelos quais ele pode passar, além de
todo a parte de necessidades como Aquisições e Contrações de Recursos
Humanos.
Desta parte da Seleção, objetiva-se ter como resultados o custo que terá para
a realização do Projetos, junto a Matriz de Asnoff para cada projeto

5.2 MATRIZ SWOT DE PROJETOS

A matriz SWOT, como já mencionada na parte das práticas, não é novidade, e
sua adaptação para além de análise de ambientes de planejamento estratégico e

43

gestão.
Em (JULIO, 2005), o mesmo até faz uso de uma adaptação dela para o
planejamento pessoal, ocupando os quadrados com campos como Pessoal,
Familiar, Trabalho, Dinheiro.
Mas o objetivo da mesma aqui é com os tradicionais campos, ou seja, matriz
de Strengths (Forças), Weaknesses (Fraquezas), Opportunities (Oportunidades) e
Threats (Ameaças).

Figura 6. - Matriz SWOT

Fonte: WIKIPÉDIA (2011)b

A aplicação da mesma será sobre cada Projeto, ou seja, deseja-se saber o
que o projeto pode acrescentar, não somente o produto, pois ao exemplo, o
desenvolvimento de um projeto pode ser mais interessante que o próprio produto
final, como o aprendizado de uma nova tecnologia que é requisito para o produto.

5.3 MENSURAÇÃO

Querendo-se ou não, por muitas vezes o que acaba primordialmente
impedindo um projeto de ser realizado, é o custo, coisa que as vezes o barra antes
mesmo de iniciar.

44

Para pequenos negócios então, este é um dado vital, e ninguém domina um
negócio se não domina seus números, (JÚLIO, 2005),
A mensuração para a seleção vem de uma equação, cujo o resultado não é
exato, mas sim como o nome diz, se obtem uma mensuração, uma medida, um
referêncial para a tomada de decisões.
A equipe do projeto, os stakeholders, primordialmente Product Owner, já
devem ter em mãos o SWOT dos Projetos, o Custo dos Projetos, e quanto de
recurso financeiro que o poderá ser usado para a realização dos projetos.
A primeira análise sugestionada pela solução é uma comparação dos
resultados da SWOT de cada projeto com o Custos dos mesmo, a partir disto, é
possível se obter quanto, em termos financeiros, vale cada ponto de Business Value.
Destes, em uma simples divisão, já que agora são apenas números, pela
quantidade de recursos financeiros, se obterá a quantidade de Business Value que
poderão ser realizados.
Logo, sabe-se quantos Business Value podem ser realizados e quanto que
cada projeto vale neste termos, que são aglutina mais do que apenas o valor
financeiro para execução do projeto, mas sim, o seu potencial de Strengths (Forças),
Weaknesses (Fraquezas), Opportunities (Oportunidades) e Threats (Ameaças).
Basicamente é trabalhar com Alinhamento e Foco (KAPLAN, 2000)

5.4 PROJECT BACKLOG

O Project Backlog, a exemplo do Product Backlog do Scrum, é um arquivo de
informações.
O Product Backlog, compreende, basicamente uma listagem de requisitos a
serem implementados.
O Project Backlog, compreende, basicamente uma listagem de projetos a
serem realizados.
Dentro do Pacote do Project Backlog, considerando-se assim que o mesmo
não é apenas uma listagem, consta-se os resultados das Matrizes Asnoff dos
Produtos, das Matrizes SWOT dos Projetos, e claro, a Mensuração dos Projetos.
Deste Project Backlog que serão retirados e priorizados os projetos a serem
realizados nas etapas seguintes.

45

6 PRIORIZAÇÃO DE PROJETOS

Apenas selecionar não basta, dificilmente um pequeno negócio terá
condições de realizar todos os projetos selecionados em paralelo, ou seja, terá que
os mesmo serem feitos em fila, logo, precisa-se priorizar aqueles que melhor

46

atendam as necessidades.
O mapa mental a seguir elucida a priorização para esta solução proposta.

Figura 7. - Mapa Mental da Priorização de Projetos


O Project Backlog é onde estão salvas todas as informações mais relevantes
sobre os projetos, como o resultados das Matrizes Asnoff dos Produtos resultates
dos projetos, a Matriz SWOT dos Projetos, e a Mensuração em Business Value dos
mesmo.
O processo de Priorização é muito mais uma análise do que uma fórmula
pronta, a exemplo do que o Product Owner trabalha sobre o Product Backlog, neste
por ser uma quantidade maior de informações, e de interesses, deve ser analisado
pelos principais stakeholders.
Uma forma para esta análise é a sugestionada Project Sprint Planning, que a
exemplo do Sprint Planning do Scrum, é fazer uma análise do que será feito
posteriormente, no caso, qual projeto será realizado.
As informações essenciais para este Project Sprint Planning, com
participação essencial do Product Owner, são todas as constantes no Project
Backlog, de onde pode-se fazer uma comparação auxiliar dos resultados das
Matrizes Asnoff dos Produtos em relação ao Business Value dos Projetos.

6.1 CUIDADOS

A Priorização é o que pode definir o sucesso do negócio, realizar o
alinhamento de projetos exige um caminho coerente entre as estratégias

47

determinadas pela empresa e as ações tomadas pelas equipes de projeto.
(DISMORE, 2010)
Os resultados começam a se materializar à medida que os projetos são
tocados, (DINSMORE, 2010), mas começar por aquele que melhor atende o Retorno
de Investimento (ROI), será um diferencial, onde pode haver a boa consequência de
um projeto render recursos financeiros para ser feito outro projeto, quem sabe
aumentando até o Project Backlog, o tema clássico do gerenciamento de projetos, a
realização de tarefas dentro do cronograma e do orçamento e de acordo com
padrões de qualidade, está diretamente ligado à atual preocupação com fazer as
coisas mais rapidamente, com menor custo e melhor
Assim que priorizados, passe-se a execução, onde vem a parte mais
complicada, a comunicação, que “na gestão por projetos abrange o espectro que vai
desde o alinhamento de metas empresariais, até comunicação interpessoal.”
(DINSMORE, 2010, p. 177).

7 REALIZANDO PROJETOS

Complementa-se a frase “Fazer o projeto certo, e fazer certo o projeto” com
este capítulo, onde pela exemplificação do mapa mental a seguir, demostra como
esta solução sugestiona que seja feito o Gerenciamento de Projeto.

48

Figura 8. - Mapa Mental da Execução de Projetos


Em todas as ações desta etapa, nota-se a presença de iterações entre os
stakeholders do projeto, pois “Os projetos acontecem porque as pessoas os fazem
acontecer” (DINSMORE, 2010, p. 112).
E são as pessoas a parte de recursos que mais tende a complicar a atividade
do Gerente de Projetos, Prado (2004, p. 196) cita as palavras de Maquiavel, 1514
que “Não há nada mais difícil de planejar, de sucesso mais duvidoso, nem mais
perigoso de gerenciar do que a criação de um novo sistema. A causa reside em que
o iniciador atrai a si a antipatia dos que lucrariam pela preservação do velho sistema
e tem a seu lado apáticos defensores que seriam beneficiados pelo novo sistema.”
As práticas, objetivam auxiliar o Gerente de Projetos e equipe responsável.
O Project Sprint Planning, a exemplo do que ocorre no Sprint Planning do
Scrum, ou no Planning Poker (Jogo do Planejamento do XP), é jogar com as
atribuições que se têm para se selecionar o que pode ser realizado, no caso, é fazer
uma análise sobre as informações que se tem dos projetos, que nesta
representação, é a entrada de informações provenientes da etapa de Priorização.
Dada a sequência de realização dos Projetos, pela etapa anterior, é feito
então um Sprint Planning do Projeto que será executado.
Nesta fase de Sprint Planning, ocorre como no Scrum, com o diferencial da
presença obrigatória de todos os stakeholdes, em especial quem está diretamente
ligado ao desenvolvimento do Projeto, pois com o uso de resultados como o Mapa
Mental do Projeto, feito anteriormente, haverá a possibilidade de já ser atribuida, ou
se assim melhor ocorrer, a alocação autônoma de atividades para cada integrante
do Team, em um planejamento mais ajustado ao que vai efetivamente, realizado,

49

como “Uma gestão de projetos bem sucedida exige planejamento e coordenação
extensivos” (KERZNER, 2002, p.18)
O resultado desta fase do Sprint Planning, é a sub-divisão do Projeto em
várias partes menores, onde basicamente é que cada terminal do Mapa Mental,
torne-se um semi-produto do Produto final do Projeto, em termos de TI, alinhado ao
desenvolvimento de software, ser o Projeto for a construção de um Sistema ERP,
cada terminal do Mapa Mental será uma parte deste, que estará ligada a cada uma
das áreas do ERP.
Tendo-se o Projeto selecionado, e exemplificando com a máxima de Júlio
Cézar, 54 a.C, “Dividir para Conquistar”, é feita a divisão de um grande projeto em
vários pequenos projetos, armazenados como no Scrum, no Product Backlog, a
serem realizado em partes, conforme o planejamento do Sprint Planning, em uma
linguagem focada ao Gerenciamento de Projetos, é a divisão de um grande escopo
em pequenos escopos, tendo atenção ao que deve ser feito, como o Dinsmore
(2010, p. 105) menciona “gerenciamento do escopo é o alicerce para outras
habilidades essenciais do gerenciamento de projetos”.
A prática essencial, modificada nesta solução, é a apresentação do
andamento do projeto, representada pelo quadro de Kanban, basicamente divido em
3 colunas, To Do (A fazer), Doing (Em Andamento), e Done (Realizado).
A coluna do To Do, sugestiona-se que seja usado o Terminal do Mapa Mental,
ou seja, a ação planejada a ser realizada.
Esta prática do Quadro Kanban, pode ser comparada a Gestão à Vista
indicada por Kerzner, que “se consegue mostrar, para todas os envolvidos,
aspectos-chaves do projeto. O meio físico geralmente é uma parede, onde são
colocados os gráficos e tabelas de acompanhamento.” (KERZNER, 2002, p. 53), a
comparação dos resultados é a mesma, que “A gerência à vista cria um clima de
realismo e de desafio” (KERZNER, 2002, p. 53), sendo principalmente útil para
manter os stakeholders informados do andamento do projeto, e também, citando
Kernzer (2002, p. 217) “é um dos principais recursos para manter a equipe
compromissada com as metas do projeto. A consequência de seu uso é que por
estarem sempre cumprindo as metas, a motivação da equipe e sua moral sempre
estarão altos.”
Para esta etapa de Execução, assim como nas demais, outras ações podem,

50

e até devem, ser inseridas, um modelo que pode ter o seu conceito inserido é o
PDCA, de Plan (Planejar), Do (Fazer), Check (Ajustar/ Checar) e, Action (Ação/
Fazer), Kerzner (2002, p. 47) enfatiza muito seu uso, mencionado em seu livro “o
modelo PDCA (Plan, Do, Control e Action) foi desenvolvido por Shewhart em 1924,
divulgado por Deming e aperfeiçoado no Japão. Seu uso, inicialmente, foi no cenário
de operações rotineiras”, e termina o comparando ao PMBOK “O modelo PMBOK,
desenvolvido para o cenário de projetos, é de autoria do Comitê de Padronização do
PMI e sua primeira versão surgiu em 1987. Observe, assim, que ambos tratam de
um conceito universal: gerenciamento.”

7.1 OBJETIVIDADE NO GERENCIAMENTO DE PROJETOS

A proposta desta solução, contempla a objetividade muito além do
Gerenciamento de Projetos, não se pensando apenas em projetos isolados, ou mas
sim em um todo, em toda a empresa, por isso também o foco em pequenas e
médias.
O sucesso da empresa, depende não do sucesso de apenas um projeto, ou
de um interesse, apenas um objetivo, mas de vários, de um contínuo fluxo de
sucessos, Kerzner (2002, p. 54) diz que “o sucesso é mensurado tanto pelo
atingimento do desempenho em pontos de interesse para a empresa como um todo
como pela conclusão de um projeto especifico.”
Mas, do mesmo Kerzner (2002, p. 54) “A definição de excelência em gestão
de projetos deve ir muito alem da experiência e sucesso.”
A objetividade é o sucesso em fazer da melhor forma e no menor tempo
possível o projeto, de acordo com o Gerenciamento de Projetos, e pontos como os
do trecho a seguir, auxiliam principalmente em que o Gerente de Projeto, que
trabalhará sobre esta solução proposta nesta monografia, deverá também ter
atenção:
“Em pesquisa que envolveu 100 gerentes de projetos, H.J. Thamhain
e D. L. Wilemon (Conflict Management in Project Life Cycles, em
Sloan Management Review, Summer, 1975) identificaram sete fontes
potenciais de conflito, conforme mostramos a seguir por ordem de
importância:

51

1 - Conflitos sobre prazos.
2 - Conflitos sobre prioridades do projeto.
3 - Conflitos sobre recursos de mão-de-obra.
4 - Conflitos sobre procedimentos administrativos.
5 - Conflitos sobre procedimentos administrativos.
6 - Conflitos sobre personalidade.
7 - Conflitos sobre custos”
Do mesmo estudo, os autores mostram que algumas
recomendações auxiliam o gerente a minimizar conflitos. Dentre elas,
citam-se:
1 - Planos claramente definidos e divulgados;
2 - Responsabilidades claramente definidas e divulgadas;
3 - Procedimentos administrativos escritos, bem detalhados e
divulgados;
4 - Manutenção de um ambiente de trabalho de baixa tensão;
5 - Divulgação da importância do projeto para os objetivos da
organização.” (PRADO, 2004, p. 200)
A objetividade, além de ser focada no sentido de fazer rápido e bem, deve ser
também em cada vez melhor, mas tendo-se o cuidado principal de não tornar lento o
processo destas etapas de Seleção, Priorização e Execução.

7.2 PRINCIPIOS AGEIS EM GERENCIAMENTO DE PROJETOS

Os 12 princípios dos Métodos Ágeis é uma coleção de bons argumentos para
se somar a cultura da empresa, as etapas da solução proposta, não fluirão bem se
os stakeholders não estiverem comprometidos com os objetivos.
Estes princípios, aliados aos Valores, anteriomente citados, sejam os
explicitados pelo XP e Kent Beck (2002) ou de Kerzner (2002) contribuem para o
sucesso.
A citação, do mesmo autor desta monografia, referencia o Príncipio Ágil e a
Área de Conhecimento do Guia PMBOK (PMBOK, 2008) com o qual se faz a sua
aplicação, apresentado originalmente no artigo (RODRIGUES, 2010).
O objetivo deste texto não é comparar as Práticas dos Métodos Ágeis
com o Guia PMBOK, mas sim apresentar estes 12 Princípios e
aplicá-los nas áreas de conhecimento apresentadas no Guia PMBOK
com intuito de enriquecer o Gerenciamento de Projetos e não

52

somente a parte proposta pela Declaração da
Interdependência (DOI, 2005) para o Gerente de Projetos.
O Gerente de Projetos deve cercar-se de todos os meios que possam
ajudá-lo em sua tarefa, assim sendo, trazendo os 12 Princípios Ágeis
para dentro do Gerenciamento de Projetos. Pode-se definir que o 1º
Princípio, “Nossa maior prioridade é satisfazer o cliente através da
entrega contínua e adiantada de software com valor agregado”
(PRINCÍPIOS ÁGEIS, 2001), resulta em ter-se uma possível
diminuição de um grande projeto, para vários subprojetos, para
assim, como ocorre no desenvolvimento de software, tornar mais fácil
conseguir mensurar erros que possam estar acontecendo, assim
como o principal, ir fomentando o patrocinador dos recursos
financeiros já aplicados no projeto.
A aplicabilidade deste princípio ao (PMBOK, 2008) está em
todas as áreas de conhecimento como o Gerenciamentos de
Integração, Gerenciamentos de Escopo, Gerenciamentos de Tempo,
Gerenciamentos de Custos, Gerenciamentos de
Qualidade,Gerenciamentos de Recursos Humanos, Gerenciamentos
de Comunicações, Gerenciamentos de Riscos e Gerenciamento das
Aquisições. É o uso da antiga frase de origem romana, “dividir para
conquistar”.
O 2º Princípio, “Mudanças nos requisitos são bem-vindas,
mesmo tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das mudanças visando vantagem competitiva para o
cliente” (PRINCÍPIOS ÁGEIS, 2001), pode tornar-se o mais lucrativo
em sua aplicação ao Gerenciamento de Integração, Gerenciamento
de Escopo, Gerenciamento de Mudanças, e também ao
Gerenciamento da Qualidade, (PMBOK, 2008), fazendo a aplicação
deste princípio no pressuposto de que todas as mudanças de
requisitos sugeridas são benéficas, algumas inaplicáveis no projeto
atual, no entanto, passíveis em uma extensão do projeto. Deixa,
portanto, precedentes para um novo contrato, somando-se ainda a
questão a visão de mudanças estar alinhada a geração de novos
conhecimentos que sempre são reutilizáveis, referenciando-se a
Gestão de Conhecimento (BUKOWITZ, 2002).
O 3º Princípio, “Entregar frequentemente software
funcionando, de poucas semanas a poucos meses, com preferência
à menor escala de tempo”, (PRINCÍPIOS ÁGEIS, 2001), é facilmente
confundível com o 1o Princípio citado em termos de Gerenciamento

53

de Projeto, mas conceitualmente encara-se como ser mais fácil achar
problemas em um pequeno pedaço de um subprojeto do que no
projeto inteiro, facilitando o Gerenciamento de Riscos do Projeto,
assim como a área de Gerenciamento de Tempo, (PMBOK, 2008),
convergindo no grupo de processos do Gerenciamento de
Cronograma visando maior controle sobre o Gerenciamento do
Projeto.
O 4º Princípio, “Pessoas de negócio e desenvolvedores
devem trabalhar diariamente em conjunto por todo o projeto”,
(PRINCÍPIOS ÁGEIS, 2001), reforça o uso de comunicação
constante entre Stakeholders e/ou Patrocinador com a equipe do
projeto, especialmente o Gerente de Projetos, (PMBOK, 2008), tendo
pelo Gerenciamento de Comunicações, (PMBOK, 2008), sua
organização, facilitando as partes interessadas identificadas nos
processos de iniciação, o repasse de conhecimento sobre aquilo que
realmente necessitam e querem, facilitando o Gerenciamento de
Riscos, (PMBOK, 2008).
O 5º Princípio, “Construa projetos em torno de indivíduos
motivados. Dê a eles o ambiente e o suporte necessário e confie
neles para fazer o trabalho”, (PRINCÍPIOS ÁGEIS, 2001], deve ser
parte do Gerenciamento de Recursos Humanos do (PMBOK, 2008),
mas também presente em todos os demais, o trabalho deve ser
motivado e pode ser por ações de união entre os colaboradores,
benefícios, ou simplesmente evitando horas extras desnecessárias. É
fazer com que o colaborador trabalhe gostando do que está fazendo,
sendo tal princípio diretamente presente em grandes empresas da
área de TI, como em (GOOGLE, 2010) que informa que "No Google,
sabemos que cada funcionário tem algo importante a dizer e que
cada um deles é parte integrante de nosso sucesso".
O Princípio 6, “O método mais eficiente e eficaz de transmitir
informações para e, entre, uma equipe de desenvolvimento é através
de conversa face a face”, (PRINCÍPIOS ÁGEIS, 2001), pelo (PMBOK,
2008), trata sobre o Gerenciamento de Comunicações do Projeto,
sobre dar mais atenção a transferência de informações pessoalmente
do que via outra meio, assim contribuindo para inúmeras ferramentas
importantes para um Gerente de Projetos, como Marketing de
Relacionamento (MCKENNA, 1997).
O 7º Princípio, “Software funcionando é a medida primária de
progresso”,(PRINCÍPIOS ÁGEIS, 2001), atua como um milestone,

TCC_POS_LUIZ

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a TCC_POS_LUIZ

Semelhante a TCC_POS_LUIZ (20)

Mais de Luiz Henrique Rauber Rodrigues

Mais de Luiz Henrique Rauber Rodrigues (20)

TCC_POS_LUIZ