Você está na página 1de 13

LIÇÕES APRENDIDAS COM A IMPLANTAÇÃO DA

METODOLOGIA SCRUMPS

Priscila Soares Elpo


Contato: priscilaelpo@gmail.com

Resumo

As pessoas estão constantemente buscando a melhor maneira de fazer suas atividades, tanto em
suas vidas pessoais quanto profissionais. Isso requer, quando se trata de uma organização, da
elaboração de uma metodologia adequada para o consequente gerenciamento de seus projetos.
Entretanto, há uma grande falha nas bibliografias com relação ao como implantar uma
metodologia de projetos. Quais as primeiras etapas para implantar uma metodologia de
projetos? Que erros podem acontecer? São perguntas difíceis de responder que em algum
momento já foram feitas por quem está estruturando a sua maneira de agir. Por esse motivo, o
presente estudo apresenta as lições aprendidas com a implantação de uma metodologia
envolvendo o framework Scrum, através da observação e dos dados colhidos durante as
reuniões de retrospectiva do processo, sendo um dos fatores importantes para o sucesso de uma
metodologia, o respeito à cultura organizacional.

Abstract

People are constantly searching for the best way to do their activities, both in their personal
lives and professional. This requires, when it comes to an organization, the development of an
appropriate methodology for the subsequent management of their projects. However, there is a
major flaw in the bibliographies regarding how to deploy a project methodology. What are the
first steps to implement a project methodology? What mistakes can happen? These are difficult
questions to answer that at some point they have been made by those who are structuring their
way of acting. For this reason, this study presents the lessons learned from the implementation
of a methodology involving the Scrum framework, through observation and data gathered
during retrospective meetings of the process, one of the important factors for the success of a
methodology, respect to the organizational culture.

Palavras-chave: gerenciamento de projetos; metodologias de projetos; Scrum; lições


aprendidas

1. Introdução

Para tudo que se faça, desde uma faxina em casa até o projeto de
desenvolvimento de um novo produto por uma grande indústria, existe uma
metodologia a ser utilizada para a execução e o alcance do objetivo a que se destina. De
acordo com o PMBOK (2013), metodologia é “um sistema de práticas, técnicas,
procedimentos e regras usado pelas pessoas que trabalham em uma disciplina”. Ou seja,
nada mais é do que a maneira ou o como se irá trabalhar para alcançar determinado
objetivo. No caso de uma faxina é o como se irá realizar essa faxina: por onde se irá
começar? Que recursos serão necessários? Quais atividades estarão envolvidas? Qual a
ordem das atividades? Quais as técnicas a serem utilizadas? No caso de um projeto,
envolve os procedimentos, os processos, os documentos que irão nortear o planejamento
e gerenciamento desse projeto, da sua fase de iniciação até a fase de encerramento.
Existem diversos tipos de metodologias para projetos, como: a metodologia em
cascata e a metodologia ágil.
O método em cascata, é o método mais tradicional e é assim chamado pelas
atividades seguirem uma ordem de execução, somente uma sendo executada após a
anterior ter sido concluída, formando, assim, uma cascata ao compor o gráfico de Gantt.
Isso quer dizer que esse modelo possui "fases bem definidas, desde o planejamento,
sendo esse seu maior foco"” Nesse modelo, todas as atividades e requisitos já são
planejados já na etapa de planejamento.
O método ágil surgiu a partir de um manifesto ágil, onde o foco passava do
processo para as pessoas, buscando diminuir os desperdícios e os excessos. Dessa
maneira, esse método "desenvolve em etapas, entregando uma parte a cada ciclo
iterativo (Sprint), possibilitando que os requisitos sejam alterados ao longo do projeto,
adequando-os as mudanças (...) e necessidades do cliente". (ESPINHA)
Uma das maiores diferenças que existem entre os dois métodos, é que no método
em cascata o cliente tem acesso ao produto, apenas no final, quando o mesmo é
concluído. No método ágil, por sua vez, o cliente tem acesso ao produto a cada Sprint,
onde é entregue um módulo do mesmo.
Entretanto, não há como falar que uma metodologia é melhor ou superior a
outra. Dependendo do tipo de projeto, uma pode ser mais adequada do que a outra.
Contudo, há a possibilidade de usá-las em conjunto, além de adaptá-las a outras
metodologias e processos, como o Modelo de Referência para Melhoria do Processo de
Software Brasileiro - MPS.SW. Foi através da união dessas diferentes metodologias:
PMBOK + framework Scrum + MPS.SW que surgiu a metodologia SCRUMPS.SW.
Mas afinal, o que é uma metodologia? Dinsmore et al (2007), classificam como
sendo a conciliação do conhecimento, do método, dos processos e das ferramentas.
Além disso, consideram como "fundamental para a adoção de gerenciamento de
projetos".
Não basta apenas criar uma metodologia adequada. É necessário prestar atenção
na maneira com que se fará a implementação. "A estratégia de implementação deve ser
feita de forma a abraçar todos esses aspectos, sendo paulatina, na ordem coerente com
as necessidades da empresa e estar alinhada com o Planejamento Estratégico"
(DINSMORE et al; 2007).
Para implantar com sucesso uma metodologia de gerenciamento alguns passos
são discutidos pelas literaturas, como: criar uma cultura de gestão de projetos, treinar a
equipe, definir metas, delegar tarefas e utilizar softwares gerenciadores de projetos. Para
criar essa cultura de gestão de projetos, Roberto Espinha (2014), diz que é necessário
“estabelecer protocolos padronizados para a condução das atividades na empresa (...),
melhorar a definição e controle do escopo dos projetos corporativos, diminuindo assim
a necessidade de retrabalho”. Entretanto, o como realizar essas tarefas obtendo o menor
impacto na cultura da organização não é retratado, causando dificuldades para os
Gerentes de Projetos implantarem metodologias adequadas.
O “be-a-bá” do que deve ter uma metodologia de projetos: quais processos? Que
tipos de documentações devem ter? É algo comentado e conhecido em diferentes
materiais, artigos, estudos, guias… Entretanto, a execução real, o como se irá colocar
tudo isso em prática não é um assunto convencionalmente discutido e abordado, sempre
restando aquelas dúvidas: por onde começar? Devemos implantar todos os processos
juntos? Deve haver uma implantação parcial dos processos? Qual irá primeiro? Qual a
sequência melhor? Deve-se levar em consideração a opinião da equipe técnica, a qual
terá o suporte dos processos para desempenhar de maneira mais efetiva e produtiva as
suas atividades?
A partir de uma análise e observação do ambiente de estudo, analisando as
consequências de cada ação ao longo de doze meses, busca-se com o presente artigo
identificar as lições aprendidas ao implantar a metodologia SCRUMPS.SW.

2. Gestão de Projetos Tradicionais x Gestão de Projetos Ágeis

Uma metodologia de projetos é o trabalho em conjunto de conhecimento,


método, processos e ferramentas (Dinsmore et al; 2007), sendo fundamental para a
gestão de projeto. Dessa maneira, é importante conhecer o que é o gerenciamento de
projetos para compreender a real importância de uma metodologia de projetos
adequada.
Para Fabio Cruz (2013), “O gerenciamento de projetos é a aplicação controlada e
coordenada de conhecimento, habilidades, ferramentas e técnicas aos eventos do projeto
a fim de atingir seus objetivos". Ou seja, partindo do conceito de uma metodologia, o
gerenciamento de projetos, nada mais é do que a aplicação controlada de uma
metodologia aos eventos dos projetos com o intuito de alcançar seus objetivos. Assim
sendo, a gestão de projetos visa colocar em prática a metodologia definida.
Portanto, é de suma importância a escolha correta e adequada de uma
metodologia para a organização. Existem diferentes vertentes com relação as
metodologias para gerenciamento de projetos, existindo duas metodologias que se
destacam: cascata e ágil. O método em cascata é marcado pela utilização do Guia
PMBOK, já o método ágil se baseia, tanto no manifesto ágil, quanto no Scrum Guide.
De acordo com Fabio Cruz (2013), “o Guia PMBOK abrange todas as áreas do
gerenciamento de projetos e busca sugerir boas práticas para todas as etapas de um
projeto, do início ao fim. É um excelente Guia, porém possui algumas fraquezas, além
de não ser uma metodologia”. Entretanto, existem muitas pessoas que acabam
interpretando o Guia PMBOK de maneira errada, uma vez que visa apenas sugerir boas
práticas, não dizendo que essas práticas são obrigatórias em um projeto. O que cada um
irá utilizar em sua metodologia, depende de inúmeros fatores, variando, assim, de
organização para organização, de acordo com as suas necessidades.
“O principal ponto a ser observado para o entendimento da abordagem
apresentada aqui é que o Guia PMBOK sugere “o que deve ser feito”, mas não descreve
“como deve ser feito” (CRUZ, 2013). Nesse momento, surge uma grande dificuldade,
relacionada a implantação das sugestões realizadas, como se irá trabalhar essas boas
práticas? Como se irá inserir elas dentro do contexto e da cultura da organização?
Por outro lado, a metodologia ágil sugere diferentes frameworks para colocar em
prática o manifesto ágil. Um desses frameworks é o Scrum, muito conhecido e um dos
mais simples para se colocar em prática dentro de uma organização, contribuindo para
criar a cultura de projetos, bem como, a cultura ágil.

O Scrum sugere um excelente conjunto de conceitos e práticas


que se encaixa perfeitamente no desenvolvimento de produtos,
propondo um autogerenciamento dinâmico, versátil e altamente
adaptável que se torna muito eficiente durante a execução de
projetos que possuem como objetivo final a entrega de um ou
mais produtos (CRUZ, 2013)

Entretanto, o Scrum deixa a desejar em alguns pontos, como o fato de não


contemplar algumas áreas fundamentais de um projeto. Dessa maneira, a utilização do
Guia PMBOK alinhado com o framework Scrum, contribui para uma gestão de projetos
mais completa, uma vez que os pontos fortes se somam e os pontos fracos acabam por
se anular.

3. Implantando uma nova metodologia

O Gerenciamento de Projetos traz inúmeros benefícios a uma organização,


como, por exemplo:

(1) clara definição do escopo dos serviços a serem prestados e a


gestão do escopo previamente definido; (2) compartilhamento
de informações do projeto, incluindo, cronograma, plano de
comunicação e critérios de aceite; (3) uso de indicadores que
permitem avaliar o progresso dos projetos, possibilitando
posteriores análises de causas-raiz de problemas e consequente
endereçamento de soluções. (FILHO, 2014)

Em algumas organizações não há a constituição de um Escritório de Projetos


(PMO - Project Management Office), ou como cita Armando Terribili Filho (2014) "ou
ainda, uma existência embrionária na organização".
Um PMO "é o departamento responsável por definir e manter os padrões de
gerenciamento de projetos na empresa, a fim de otimizar o controle e a execução de
propostas da organização como um todo ou de uma área específica" (REIS, 2015)
O que acontece, com a inexistência de um PMO formado ou se quer sua ideia
iniciada, "é que cada profissional atua no gerenciamento de projetos, o faz da melhor
maneira que pode, entretanto, de forma pouco estruturada, utilizando critérios e
controles próprios" (FILHO, 2014).
As consequências desse tipo de ação são inúmeras e são citadas por Armando
Terribili Filho (2014), como sendo:
inexistência de padrões quanto ao uso de metodologias,
processos, ferramentas e documentação; ausência no uso de
indicadores de monitoração dos projetos; pouca ou nenhuma
sistematização de captura e divulgação de boas práticas (sejam
internas ou externas à organização); indefinição quanto aos
cursos necessários à capacitação e desenvolvimento de
habilidades de um Gerente de Projetos, etc.

Ou seja, ter uma metodologia de projetos, estruturada, mesmo que sem a


existência de um PMO propriamente dito, facilita o gerenciamento de projetos, pois fará
com que haja uniformidade nos projetos, bem como padrões nos usos de metodologias,
ferramentas e documentações. É o processo embrionário para futuramente a organização
possuir um PMO. Com um Escritório de Projetos, a organização passa a ter um
Gerenciamento de Projetos mais estruturado, o que é de suma importância para a
mesma.

O PMO precisa ser criado, seja por meio da promoção de um


profissional interno, pela contratação de um profissional de
mercado, com apoio de uma consultoria ou não. Só com a
atuação sistemática de um Escritório de Projetos a organização
obterá padronização dos processos, cultura única e ganho de
escala no planejamento e execução de seus projetos. Desta
forma, poderá o PMO caminhar para se tornar uma área de
importância estratégica na organização. (FILHO, 2014)

Portanto, a criação de um PMO servirá como papel fundamental para a


implantação da metodologia e, consequentemente, a aplicação do Gerenciamento de
Projetos, uma vez que ambos estão interligados.

4. SCRUMPS (SCRUM + MPS.BR)

A metodologia SCRUMPS, foi a metodologia escolhida para o gerenciamento de


projetos da empresa Cianet. Ela une as cerimônias do Scrum, os critérios do MPS.SW,
bem como os processos principais do PMBOK. Essa metodologia foi elaborada de
acordo com a cultura da organização, bem como, levando em consideração as
necessidades da mesma.
Sua elaboração teve início em dezembro de 2014, contando com uma série de
análises através de observação, entrevistas e questionários, visando detectar eventuais
problemas existentes nos projetos e maneiras de solucioná-los com a escolha da
metodologia mais adequada.
O processo de implantação foi dividido em etapas. Como não existia nenhuma
estruturação formal e nenhum processo de planejamento e gerenciamento de projetos,
visou-se minimizar os impactos culturais que a adoção de uma metodologia poderia
gerar.
Como o projeto em questão já estava em andamento, sendo difícil realizar a
etapa de planejamento, optou-se por corrigir eventuais falhas durante o processo de
execução do mesmo. Por se tratar da parte prática do projeto, o "como fazer", o
framework Scrum foi escolhido como uma ferramenta de trabalho, sendo adequado a
realidade da organização.
Aos poucos, o processo sofreu algumas alterações, conforme o processo de
Retrospectiva Scrum, visando a melhoria constante do processo, com base nos erros e
nos acertos. Atualmente, está em fase de melhoria do processo.

5. As lições aprendidas com a implantação do Scrumps.SW

Foram listadas 11 lições aprendidas com a implantação so Scrumps.sw, ao longo


da sua implantação nos últimos 15 meses.

1) A metodologia deve se adaptar as pessoas e ao processo que já ocorre, mesmo


que informalmente e não o inverso, evitando uma quebra cultural muito grande.
A primeira lição aprendida é sobre a elaboração de uma metodologia. É
importante que a metodologia seja elaborada de acordo com a cultura já existente,
respeitando os processos informais. Dessa maneira, a metodologia deve levar em
consideração as necessidades e expectativas dos envolvidos, visando construir algo que
venha a ser útil. Isso facilita a diminuição do choque cultural que possa existir com a
implantação de novos procedimentos e novas documentações, pois levará em
consideração a opinião dos envolvidos.
Isso foi realizado na metodologia SCRUMPS.SW, pois levou-se em
consideração a opinião de cada um dos envolvidos, através de entrevistas, questionários
e observação, elaborando uma metodologia que visasse suprir as necessidades tanto
gerenciais, contendo informações sobre o projeto, estruturando entregas, obtendo dados
através de indicadores, bem como facilitando o trabalho dos responsáveis pela execução
das tarefas.

2) Iniciar todas as cerimônias de uma vez: não!


A segunda lição refere-se a necessidade de ir com calma, uma vez que irá se
mexer com a cultura organizacional. Empurrar o processo inteiro de uma vez não fará
com que o mesmo tenha sucesso, mas aumentará as chances de as pessoas não se
adaptarem e o mesmo ir caindo no desuso aos poucos. Assim, deve-se saber onde se
quer chegar com a metodologia, mas levar em consideração as necessidades listadas
para realizar os incrementos de cerimônias gradualmente.
Por exemplo, na metodologia SCRUMPS.SW, iniciou-se o processo em etapas.
Na primeira etapa contou-se com apenas duas cerimônias: a de Planejamento e a de
Retrospectiva. Na segunda etapa, iniciou-se com algumas reuniões de acompanhamento.
Por último, acrescentou-se as reuniões de Verificação da Sprint.

3) Não iniciar com Reuniões Diárias


Isso está relacionado a questão cultural. Em uma organização onde não se estão
acostumados a ter uma organização de projetos e reuniões formalizadas de
acompanhamento, as Reuniões Diárias podem ser vistas como algo desnecessário. É
necessário ir com calma e fazer o Time perceber a importância dessas reuniões para,
então, aumentar sua periodicidade.
Na metodologia SCRUMPS.SW, o time decidiu, inicialmente, a frequência das
reuniões de acompanhamento, as quais ocorriam duas vezes na semana. A seguir, após
algum tempo, o próprio time sentiu necessidade de melhorar sua comunicação e
entendeu o porquê de realizar Reuniões Diárias.

4) A ideia de estimativas por esforço gera grande desconforto e dúvidas na


equipe
A equipe leva algum tempo para entender as estimativas e entrar em acordo. No
caso da equipe da Cianet, utilizando a metodologia SCRUMPS.SW, levou cerca de 3
Sprints para começar a criar um padrão dentro da própria Equipe. Inicialmente, dividiu-
se o time de execução em dois. Em ambos os times observou-se a mesma média de
Sprints para começar a haver uma padronização das pontuações.
Não são poucas as dúvidas relacionadas a utilização de estimativas em horas. É
importante lembrar que dependendo da equipe, poucas vezes se realiza apenas uma
tarefa por vez. Por exemplo, enquanto um script de teste é rodado, outras atividades
podem ser executadas em paralelo. Como justificar a utilização real de horas para cada
atividade dessas? Ao estimar o esforço, as pessoas começam a pensar em tudo que
devem fazer para realizar determinada atividade, contribuindo, inclusive, para a quebra
das atividades em porções menores.

5) Sprint com time-boxed determinado


É interessante no começo da implantação deixar aberto o time-boxed, pois
facilita para a compreensão do comportamento da equipe para entregar um determinado
backlog. Aos poucos fica claro quanto tempo de fato é necessário para cumprir o
objetivo de uma Sprint. É importante relembrar que o processo deve se adaptar ao Time
e auxiliar as atividades deles e não vir a ser algo que possa atrapalhar seu desempenho.
Deixando aberto o time-boxed, facilita a auto-estima da equipe diante dos novos
desafios, uma vez que eles estão se acostumando as atividades de planejamento,
discussão de funcionalidades, quebra de atividades em porções menores, estimar as
atividades, realizar as reuniões de acompanhamento, ter um objetivo e um prazo
definido para entrega desses objetivos, bem como, acompanhar indicadores de
desempenho. No começo, é muita coisa para a equipe assimilar e é importante manter as
coisas com "rédeas mais soltas", afim de deixar a equipe ir testando, conhecendo, se
adaptando e sentindo os novos processos, para, a seguir, ir começando a estruturar
melhor o time-boxed, bem como outras regras.

6) Não ser exatamente cíclico, com as cerimônias ocorrendo na ordem exata


Pelo Scrum, a ordem exata das cerimônias são: Planejamento, Reunião Diária,
Verificação da Sprint, Retrospectiva Scrum e Planejamento novamente. Ou seja, o
Planejamento da próxima Sprint tende a ocorrer apenas após o final da Sprint atual.
Contudo, algumas atividades de início não serão terminadas durante a Sprint e
ficarão pela metade. A equipe não irá parar de fazer essa atividade, porque a Sprint
terminou. Portanto, é importante iniciar o planejamento da próxima Sprint antes da
finalização da anterior, para não deixa um tempo “limbo” entre elas e com isso,
atividades deixarem de ser documentadas ou não serem documentadas corretamente,
podendo influenciar nos indicadores de velocidade da equipe, por exemplo.

7) Tempo das reuniões


Dependendo do tamanho das equipes e da quantidade de trabalho envolvido,
bem como do tempo de cada Sprint, os tempos sugeridos para cada cerimônia
representam uma parcela significativa dos projetos, podendo prejudicar o desempenho
da equipe. Por exemplo, em Sprints de 2 semanas, as reuniões de Planejamento,
Verificação da Sprint e Retrospectiva Scrum não podem passar de 1 hora, podendo se
unir a Verificação da Sprint com a Retrospectiva Scrum.
Para o Scrum Guide, em uma Sprint de duas semanas, o ideal é uma Reunião de
Planejamento de 2 horas. Revisão da Sprint, de 1 hora. Retrospectiva Scrum, uma hora
e meia. Dessa maneira, totaliza-se quatro horas e meia de reunião, além das Reuniões
Diárias. Considerando o modelo não cíclico, isso significaria um percentual
considerável semanal. Dessa maneira, cada reunião deve durar no máximo uma hora,
sendo comum levar menos tempo, totalizando, no máximo quatro horas.
Além disso, vale destacar que ao dividir as cerimônias em porções menores e
mais focadas, o tempo necessário diminui, bem como a produtividades das reuniões
aumentam.

8) Não enfiar tudo goela abaixo


A equipe já possui uma cultura informal de trabalho, sendo as mudanças vistas
com dificuldade, mesmo que para auxiliar o seu trabalho. Dessa maneira, o período de
adaptação e para que o time possa ver os frutos dessas alterações no seu desempenho, é
necessário ir com calma. Até que o time tenha se adaptado com uma alteração e venha
demonstrar, através das Reuniões de Retrospectiva Scrum que estão prontos para novas
alterações, as mesmas não devem ser realizadas. Isso, porque a equipe precisa
compreender a importância de cada alteração no processo e de cada cerimônia a ser
incluída, para poder se seguir para a próxima. Caso se realizem muitas alterações de
uma única vez, a equipe poderá acabar "se engasgando" com tantas informações e
perdendo a sua produtividade ou mesmo criando uma aversão as alterações, dificultando
sua manutenção.
É importante compreender que a própria equipe irá buscar novos desafios,
aperfeiçoando-se constantemente. Como o framework Scrum é marcado pela melhoria
contínua, a própria equipe ao se adaptar às pequenas mudanças que vão sendo
implantadas, irá ver os impactos positivos que essas mudanças causam na sua
produtividade e no seu desempenho, observando que podem ser melhores e, dessa
maneira, irão iniciar a busca contínua pelas melhorias.
Trata-se de um processo natural, o qual ocorre em equipes que possuem as
características necessárias para serem um Time de Desenvolvimento do Scrum, Isso
ocorre, pois a equipe quer ser boa também e possui os mesmos interesses que a
organização, que o Scrum Master, que o Product Owner e que os próprios clientes.
Assim, o que quer que possa melhorar o seu desempenho, bem como se
apresentar como uma alternativa para facilitar o seu trabalho, melhorar suas entregas e
suas estimativas, é bem visto e desejado. Portanto, aos poucos a equipe compreende a
importância de determinadas cerimônias e vai sentindo falta de outro itens, sejam
processos, documentações ou até reuniões. Logo, implantar aos poucos, para a equipe ir
se adaptando e melhorando, é como um ciclo PDCA, onde todos aprendem
constantemente, mas tudo ao seu tempo.

9) A equipe não aceitará quieta e dirá não muitas vezes


Discussões serão levantadas sobre o processo, principalmente nas primeiras
Sprints. Durante erros, o processo será sempre o culpado. Haverá resistência para se
adaptar e aceitar o processo. Não será apenas elaborar o processo e implantar e achar
que isso tudo irá ocorrer conforme o planejado. Não importa o quanto se acredite no
processo e o quanto se tente manter as regras, haverão discussões sobre o processo e
muitos questionamentos sobre o real benefício do Scrum.
Além disso, a cada nova alteração, a primeira reação da equipe será dizer não
para, a seguir, tentar entender de fato o que é essa alteração e que benefícios poderá
trazer.

10) As equipes não tendem a ser multidisciplinares de começo.


Um fato conhecido no framework Scrum é a multidisciplinariedade do time,
contribuindo para a agilidade do mesmo. Entretanto, no começo, é raro se ter um time
realmente multidisciplinar. Aqui, vale a pena atentar que existem dois tipos de
multidisciplinariedades defendidos: o time por si ser multidisciplinar, o que indica ter
pessoas especialistas de cada coisa e as pessoas serem multidisciplinares.
Inicialmente, começou-se o processo com o time sendo multidisciplinar e
acreditou-se que isso bastaria. Entretanto, ao longo da implantação da metodologia
SCRUMPS, observou-se a dificuldade que estava trazendo nas Sprints, bem como, aos
poucos, a própria equipe começou a sentir essa dificuldade. Então, começou-se a avaliar
a multidisciplinariedade por pessoa e a própria equipe começou a buscar por isso, uma
vez que alguns gargalos foram surgindo, de atividades que dependiam de pessoas
específicas, não mais pertencendo ao time.

11) É necessário muita paciência


Além de muita paciência, é necessária perseverança, comunicação com a equipe
e adaptação a todo momento. Não se pode desanimar diante das dificuldades que forem
surgindo, mas utilizá-las para melhorar o processo e ir adaptando o mesmo a equipe.

6. Conclusão

A cada dia que passa torna-se mais importante ter uma Gestão de Projetos
consolidada na empresa, seja qual for o tipo de serviço ou produto que a mesma oferece.
Entretanto, de nada adianta se ter uma cultura de Gestão de Projetos se não existir uma
metodologia para amparar os processos de Gestão.
Essa metodologia deve ser elaborada levando em consideração a cultura e os
processos informais já existentes dentro da organização, de maneira a suavizar os
impactos culturais que essas mudanças podem trazer.
Além disso, pouco se fala sobre as Lições Aprendidas ao implantar uma nova
metodologia e em que pontos deve-se tomar cuidado e para o que deve-se estar pronto.
Inicialmente, deve-se estar pronto para corrigir as falhas que forem surgindo
durante a implantação e execução da metodologia, bem como estar atento às sugestões
que forem dadas. Também é necessário estar preparado para a resistência às novas
alterações.
Uma boa maneira de diminuir as resistências é realizar mudanças graduais e
adaptar os processos a sua realidade. O Guia Scrum não dita regras de como o
framework deve ser utilizado, mas serve como um guia indicando melhores práticas.
Contudo, cabe a cada organização avaliar quais as melhores práticas para si.
Portanto, o ponto alto dessas lições aprendidas é observar a cultura da
organização e adaptar a Gestão de Projetos, a metodologia a ser utilizada e os processos
e etapas de implantação à realidade da própria empresa. Afinal, cada organização é um
organismo vivo que funciona de maneiras diferentes e essa propriedade única, essa
característica que o torna um organismo próprio deve ser respeitada!

7. Referências

CRUZ, Fabio. Scrum e Agile em Projetos: Guia Completo. Rio de Janeiro: Brasport,
2015.

DINSMORE, Paul Campbell et al. Projetos Brasileiros: Casos Reais de


Gerenciamento. São Paulo: Brasport, 2007. 278 p.

ESPINHA, Roberto Gil. Implementando uma metodologia de gestão de projetos:


Saiba como preparar a sua empresa. Disponível em:
<http://artia.com/blog/implementando-uma-metodologia-de-gestao-de-projetos-saiba-
como-preparar-a-sua-empresa/>. Acesso em: 20 fev. 2016.

PMI. Um guia do conhecimento em gerenciamento de projetos. Guia PMBOK. 5. Ed.


Project Management Institute, 2008

REIS, Thiago. Project Management Office: tudo o que você precisa saber. 2015.
Disponível em: <http://www.projectbuilder.com.br/blog-pb/entry/projetos/project-
management-office-tudo-o-que-voce-precisa-saber>. Acesso em: 14 fev. 2016.

SUTHERLAND, Jeff. Scrum: A arte de fazer o dobro na metade do tempo. São Paulo:
Leya, 2014.

TERRIBILI FILHO, Armando. Estratégias para a criação de um Escritório de


Projetos. 2014. Disponível em: <http://www.impariamo.com.br/base-de-
conhecimento/artigos/gerenciamento-de-projetos/escritorio-de-projetos-pmo/item/333-
estrategias-para-a-criacao-de-um-escritorio-de-projetos>. Acesso em: 15 fev. 2016.