Estudo

de Caso

Gerenciamento Ágil
de Projetos
Professor: Reginaldo Aparecido Carneiro
Unicesumar
2

estudo de
caso

Sobre a Caracterização do Caso, Corforme

Manual.
Classificação do caso: tomando por base a classificação de Gil (2004), o caso é classificado
como análise, pois tem por objetivo desenvolver a capacidade analítica do estudante com
relação ao conteúdo do livro.
Dimensões de análise: o caso tem um grau de complexidade baixa, pois apresenta um
cenário que pode ocorrer no cotidiano das empresas e que levam a tomadas de decisão em
como gerir um projeto de maneira ágil. Pede-se do estudante, o estudo dos processos de
gestão ágil de projetos, bem como a análise de situação-problema para a aplicação prática
das técnicas estudadas na disciplina.

Caso da Empresa “X1 Distribuidora” na Imple-

mentação do Sistema de Gestão Empresarial
Customizada
Em 2010, a empresa X1 Distribuidora iniciou um projeto de implantação de um novo sistema
de gestão empresarial. A empresa buscava no mercado uma implementadora que tivesse
uma solução bastante aderente ao processo da empresa, mas que também fosse possível
customizar algumas partes do sistema que eram bem específicas. Uma vez selecionada, a
empresa que apresentou a melhor proposta, deu-se início ao projeto.
O projeto começou em março de 2010 da maneira tradicional de gestão de projetos,
cuja montagem de todo o planejamento do projeto seguia as melhores práticas segundo o
PMBOK. Havia um escopo contratado, tanto da parte que seria implantada da maneira que
o sistema atendia como a parte que seria customizada. A primeira etapa do projeto foi a de
levantamento de requisitos, depois, a prototipação, o desenvolvimento, os testes unitários,
os testes integrados e, assim, partiria para a capacitação dos usuários finais e, por fim, dado
o go-live (entrada em produção) em paralelo, em que o sistema anterior continuaria sendo
utilizado e o novo sistema sendo executado em paralelo durante 1 mês para depois desligar
o sistema antigo. A implantação seria no estilo “Big Bang”, no dia X, ou dia do Corte, todos os
módulos do sistema entrariam em operação.
 Unicesumar
3

estudo de
caso

O projeto, inicialmente, estava planejado para ser entregue em 10 meses, ou seja, em 9

meses o sistema entraria em produção e mais 1 mês de execução em paralelo, para estabi-
lização do novo sistema. Um prazo bastante ousado, mas com base nas estimativas iniciais
e no escopo contratado, seria perfeitamente possível.
A primeira fase, a de levantamento de requisitos, planejada para durar 3 meses começou
em abril (após 1 mês de planejamento). Iniciada essa etapa, começaram os problemas. O
cliente colocou seus usuários chaves para definir os processos, mas eles mesmos não sabiam
como seria e precisavam, constantemente, solicitar a presença dos diretores nas reuniões de
levantamento. Muitas coisas eram solicitadas, sem se ater ao escopo pré-definido, aparecen-
do um volume muito grande de alterações de escopo no produto, módulos inteiramente
novos surgiram nos levantamentos e o que era para durar 3 meses, levou mais de 6 meses
para finalizar, atrasando todo o cronograma de desenvolvimento e entrega do projeto, mas
o prazo final foi alterado para apenas 1 mês para frente. Para coincidir com o início do ano,
ou seja, o projeto precisava estar pronto para iniciar a operação em 01/janeiro/2011.
Mesmo com os requisitos não finalizados em 100%, os desenvolvimentos do que estava
aprovado, foram sendo realizados, mas os testes eram apenas executados de forma unitá-
ria, pois não tinha como testar todo o processo. O desenvolvimento foi sendo realizado, mas
quando ia para teste do cliente, voltava com diversos problemas. Os problemas eram de in-
terface que não agradava, erros na execução das operações, cadastros que não realizavam
certas validações, muitas delas, que não haviam sido especificadas e nem solicitadas pelo
cliente.
Com todos esses problemas, tanto nos requisitos, como nos desenvolvimentos, ava-
liou-se que não seria possível entregar o produto em janeiro/2011. Foi ai que surgiu a ideia
de se implantar apenas o módulo financeiro (na íntegra) a partir do momento em que ele
ficasse pronto.
A partir desse momento, todo o time de desenvolvimento e consultores concentraram
seus esforços no módulo financeiro, porém, ainda seguindo a forma tradicional de se fazer o
projeto e o desenvolvimento: especificar, desenvolver, testar unitariamente, testar de forma
integrada junto com o cliente, treinar e depois de todo o módulo financeiro pronto, colocar
em produção.
Unicesumar
4

estudo de
caso

O fato é que mesmo com essa estratégia, ainda ocorreram problemas, iguais aos anterio-
res. Problemas de interface, requisitos não mencionados que precisavam ser contemplados
e, por conta do tempo que estava demorando, surgiam novas ocorrências que precisam ser
previstas no sistema em desenvolvimento.
Após 4 meses de trabalho no módulo financeiro, ele estava pronto e poderia entrar em
produção. Foram realizados os treinamentos aos usuários finais, colocado para rodar em
paralelo e posto em produção. Ele ainda não estava estável e a equipe precisava, constante-
mente, arrumar algum problema e ao mesmo tempo, desenvolver todo o restante do sistema
(compras, vendas, logística, faturamento, CRM, estoque e um módulo inteiro de controle de
ordens de serviço).
Foi nesse momento que a gestão do projeto decidiu mudar o rumo do projeto. No meio
do projeto, após a implantação do módulo financeiro, optou-se em adotar as práticas ágeis
para desenvolver todos os outros módulos do sistema.
Nesse momento, o gerente do projeto fez um encerramento parcial do projeto, elencan-
do tudo que foi entregue até o momento, o que estava fora do escopo, o que foi entregue
do escopo contratado, incialmente, e, assim, formalizando-se o encerramento do projeto,
para que fosse possível iniciar um novo projeto, como se estivessem começando o projeto
de implantação do sistema de gestão na empresa X1 Distribuidora.
Para que esse novo projeto fosse iniciado, sem ônus adicionais para a X1 Distribuidora, o
gerente do projeto listou todos os itens que ainda não haviam sido entregues no projeto an-
terior e montou a primeira versão do Backlog do Produto. O segundo passo foi transformar
os requisitos já levantados em histórias de usuário, para que antes de iniciar o desenvolvi-
mento, o produto fosse revisado pelo cliente, avaliando se os requerimentos permaneciam
os mesmos ou se precisariam de ajustes. Com essa ação, já foi possível eliminar muitos pro-
blemas, pois como o projeto já estava a mais de 12 meses em andamento, muitos requisitos
levantados no segundo mês de projeto, precisavam ser ajustados, pois a realidade da empresa
mudou neste período. Assim, já se percebeu o primeiro ganho em implantar o método ágil
para este projeto.
 Unicesumar
5

estudo de
caso

O método ágil utilizado foi o framework Scrum, com alguns conceitos do Kanban. Assim,
definiu-se um ciclo de 2 semanas para cada Sprint, assim, o usuário já recebia uma versão
nova do sistema, com as implementações a cada duas semanas e não precisava esperar tudo
ficar pronto para poder capacitar os usuários e testar a solução.
Nesse momento, já percebeu-se o segundo ganho. Com entregas menores, os usuários
deixavam duas sextas-feiras livres no mês, para poder testar e ver o que foi feito nas duas
semanas que se passaram e também, deixavam as segundas livres para revisar os requisitos
e priorizar o backlog. Assim, eles conseguiam ver a evolução dos desenvolvimentos, avaliar
se estava ficando bom ou não, em termos de tela, validações e requerimentos e já poderiam
testar a solução, mesmo que parcialmente.
A partir daí, foram eleitas datas de implantação de cada módulo separadamente. Quando
o módulo atingia um grau de implementação, suficiente para colocá-lo em produção, ele
era atualizado no ambiente de produção e dava-se início às operações no sistema, sem pre-
cisar que tudo ficasse pronto para depois poderem colher os benefícios do sistema.
Durante a execução, sugiram muitas coisas novas que precisam ser feitos, aumentando
mais ainda o escopo, porém o cliente ficava satisfeito, pois as implementações eram feitas
conforme havia a necessidade, ou seja, o cliente priorizava o que tinha que ser feito, primei-
ramente, e, a cada Sprint ele, podia mexer nessas prioridades. Isso, no método tradicional,
ele não tinha autonomia e viu-se, aqui, o terceiro ganho.
Como o módulo financeiro já estava em produção, os erros precisavam ser corrigidos de
forma ágil. Então, o gerente do projeto e o time resolveram deixar um tempo sobrando em
cada Sprint, para correção de bugs. Dessa forma, o que eles se comprometiam a entregar
não seria comprometido se erros fossem encontrados nos módulos já em produção. Com
essa medida, foi possível resolver erros dos módulos e não afetar as entregas e em alguns
casos, entregas eram antecipadas, pois a equipe começou a trabalhar de forma mais ágil e
com menor incidência de erros no sistema, já que os requisitos estavam mais bem definidos.
O cliente acompanhava de perto as entregas antes de ir para produção. Aqui, percebeu-se
mais dois ganhos, antecipação de entregas e redução da quantidade de erros em produção.
Unicesumar
6

estudo de
caso

Após 6 meses, o desenvolvimento e a implantação dos demais módulos foi encerrada,

ou seja, em metade do tempo da primeira fase do projeto original, que só implantou o fi-
nanceiro, foi possível entregar todo o restante do projeto, que representava 60% do esforço
total, conseguindo, ainda, entregar mais funcionalidades do que estava no escopo inicial,
com satisfação maior do cliente, pois, agora, tinha um sistema alinhado com a realidade da
empresa, sendo possível acompanhar mais de perto todo o processo nos últimos 6 meses.
A empresa de consultoria, com o sucesso neste e outros projetos, resolveu mudar a abor-
dagem de gestão de projeto, saindo do modelo tradicional e utilizando métodos ágeis de
gestão de projeto para todos os projetos de seu portfólio.

Conclusão
Conclui-se, que, neste projeto, pelo fato de ser um projeto grande e complexo, a adoção dos
métodos ágeis foi primordial para a recuperação do projeto, que estava fadado ao fracasso.
Ao final de 1 ano, somente um módulo conseguiu entrar em produção, porém, quando mu-
dou-se o rumo do projeto, adotando práticas ágeis, o projeto foi finalizado em 6 meses. O
gerente de projeto teve que encerrar o projeto antigo e iniciar um novo, como se estivesse
começando do zero, mas isso foi necessário para que pudesse ser medido o que faltava ser
entregue, mudar a forma de controle das entregas e medir a performance do time. O time
do projeto (time Scrum) comprou a ideia e se comprometeu, totalmente, com o projeto e
isso, também, foi fator decisivo para que a segunda etapa do projeto desse certo.
Sem dúvidas os métodos ágeis são ideais para ambientes aonde os requisitos e priorida-
des se alteram, constantemente, pois facilitam essa mudança de rumo de forma ágil.