A sndrome da Bala de Prata na gesto de projetos de TI

Autoria: Flvia Cruz Pereira flav_cp@yahoo.com.br Resumo Tendo em vista a situao do mercado atual onde o foco est cada vez mais voltado para minimizar os custos, as organizaes buscam de forma incessante formas para viabilizar esse objetivo e, em contrapartida, alcanar mais e mais o seu Return of Investiment (ROI). Para que isso seja possvel na prtica, faz-se necessria a utilizao de prticas de gesto de projetos para garantir que essa engrenagem funcione devidamente. Com isso a pesquisa procura desmistificar o mito da Bala de Prata demonstrando que a prtica de gesto de projetos a ser utilizada deve estar bem vinculada com a estratgica da organizao e em conformidade com a necessidade do cliente para garantir uma maior agilidade na sua execuo com eficincia e eficcia, atrelada restrio tripla do projeto: prazo, custo e escopo, no deixando de manter o padro de qualidade necessrio para garantir a sua competitividade. Palavras-chave: Gesto de Projetos, Agilidade, Qualidade. 1 Introduo Na Engenharia de Software, o termo Bala de Prata vem sendo utilizado como direcionamento para uma soluo definitiva do problema: mtodo ou forma capaz de resolver um problema independente de qual seja a sua natureza. Assim como na Engenharia de Software, na Gesto de Projetos, o termo tambm vem sendo muito utilizado e discutido. Com o cenrio mercadolgico em constante mudana devido s inovaes tecnolgicas que nos bombardeiam quase que diariamente, as organizaes precisam mais do que nunca se adequar para garantir a sua competitividade com o foco cada vez mais voltado para o Return on investiment (ROI) e com isso vm empregando grandes esforos para a melhoria de seus resultados agregados aos resultados dos seus clientes. Para isso, faz-se mais que necessrio investir para desenvolver produtos e/ou servios com qualidade respeitando a restrio tripla do projeto: prazo, custo e escopo. Com isso, acredita-se que com um bom processo a chance de se obter o sucesso dos projetos claramente maior. A sndrome da Bala de Prata em gesto de projetos - metodologia que garanta o sucesso de um projeto faz com que especialistas discutam qual a melhor prtica a ser usada com base nesse contexto. De acordo com o Project Management Institute (PMI, 2008), o nvel estratgico (alta administrao) das organizaes vem percebendo os benefcios do uso de boas prticas/metodologias para gerir seus projetos. Estudos comprovam a viabilidade do uso atrelada ao alinhamento estratgico para maximizar o ROI:

Figura 1 % de Sucesso e Insucesso de projetos conforme aderncia/resistncia Fonte: Desenvolvido pelo autor. As prticas mais utilizadas no mercado atualmente so: Guide to the Project Management Body of Knowledge (PMBOK Guide) desenvolvido pelo Project Management Institute (PMI) - um framework de padres de boas prticas de gesto de projetos que descreve normas, mtodos, processos e prticas estabelecidas e o SCRUM - um processo gil que permite manter o foco na entrega do maior valor de negcio, no menor tempo possvel (AMBLER, 2008). Com base nessa premissa, esta pesquisa pretende traar um comparativo entre essas boas prticas mais difundidas para que seja possvel verificar suas caractersticas em comum o que possibilita a convivncia de ambas em um mesmo ambiente organizacional, demonstrando que no existe uma receita de sucesso para o projeto baseado apenas em uma boa prtica utilizada. Sendo assim, o objetivo deste artigo demonstrar a relao entre as prticas do PMBOK Guide e SCRUM na gesto de projetos em TI, descrevendo suas caractersticas predominantes e traando um paralelo entre elas - apresentando os benefcios com a sua aderncia e perspectivas. 2 Referencial Terico 2.1 Porque aplicar a gesto de projetos Projetos existem para viabilizar as estratgias da organizao traduzidas atravs de seus objetivos. Com isso, as organizaes buscam a aplicao de metodologias ou prticas para atingirem as expectativas de todos os envolvidos/interessados no projeto. Essa aplicao nada mais do que criar um processo de padronizao da forma de trabalhar para alcanar os objetivos propostos respeitando a restrio tripla do projeto: prazo, custo e escopo garantindo a qualidade (CARNEIRO, 2006 e KING, 1992). Com base nessas premissas, a organizao deve aplicar uma prtica/metodologia de gesto de projetos que seja alinhada com a sua estrutura: funcional, matricial ou projetizada bem como a sua cultura, em conformidade com o seu planejamento estratgico. Gesto de Projetos a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender seus requisitos. (PMBOK Guide, 2008) Segundo o Standish Group (2006), organizaes americanas gastam mais de US$ 275 bilhes a cada ano em projetos de desenvolvimento de software. Muitos desses projetos iro falhar, e o caos se deve na maioria das vezes falta ou mal uso de uma gesto de projetos. Em conseqncia disso, produzem-se softwares em estoque com um escopo mal planejado, onde na maioria das vezes todas as funcionalidades levantadas no so utilizadas (CHAIRMAN, 2006). 2

Figura 2 Funcionalidades desenvolvidas X % Uso Fonte: Standish Group, 2006. 2.1.1 PMI e o PMBOK Guide O Project Management Institute (PMI), fundado em 1969 e sediado na Pensilvnia USA, a mais importante organizao internacional sem fins lucrativos que rene profissionais que trabalham com gesto de projetos de diversas reas. Com o intuito de documentar e padronizar todo o processo de gesto de projetos, o instituto publicou o Guide to the Project Management Body of Knowledge (PMBOK Guide), que vm sofrendo adequaes a fim de se obter uma melhoria contnua na forma de gerir projetos. O PMBOK Guide nada mais do que um guia com um conjunto de boas prticas para gesto de projetos. Na verso mais atualizada 2008, esto integrados 42 processos de gesto agrupados em 5 grupos de processos/fases envolvendo 9 reas de conhecimento. Os processos so agrupados em 5 categorias ou grupo de processos: 1. Iniciao 2. Planejamento 3. Execuo 4. Monitoramento e controle 5. Encerramento Segundo DVILA (2010), os grupos de processos de gesto de projetos tm relao com o conceito do Ciclo PDCA (Plan Planejar, Do Fazer, Check Verificar e Act Agir). O grupo de Planejamento corresponde ao Planejar; Execuo, ao Fazer; e Monitoramento e Controle englobam Verificar e Agir. Alm desses processos, o PMBOK Guide ainda caracteriza os grupos de processos de Iniciao e Encerramento, pois o projeto apresenta um ciclo finito.

Figura 3 Overlap dos processos em um projeto Fonte: PMBOK Guide, 2008.

Ainda conforme DVILA (2010), o PMBOK Guide aborda 9 reas de conhecimento. uma descrio das entradas, ferramentas e tcnicas; e sadas geradas conforme os processos que abrangem cada rea. So elas: 1. Gesto do Escopo: Inclui os processos necessrios para assegurar que o projeto inclui todo o trabalho necessrio, e somente o trabalho necessrio, para completar o projeto com sucesso. 2. Gesto do Tempo: Inclui os processos necessrios para assegurar o planejamento e execuo do projeto em um prazo adequado. 3. Gesto de Custos: Inclui os processos necessrios para assegurar que o projeto possa ser executado dentro do oramento aprovado. 4. Gesto da Qualidade: Inclui os processos necessrios para assegurar que o projeto vai satisfazer as necessidades para as quais foi concebido. 5. Gesto de Integrao: Inclui os processos necessrios para assegurar a unificao, consolidao, articulao e aes integradoras que so essenciais para o trmino do projeto, para atender com sucesso s necessidades do cliente e de outras partes interessadas e para gerenciar as expectativas. 6. Gesto de Comunicaes: Inclui os processos necessrios para assegurar a adequada gerao, disseminao e armazenamento de informaes do projeto. 7. Gesto de Riscos: Inclui os processos relacionados com a identificao, anlise e estabelecimento de contramedidas para os riscos do projeto. 8. Gesto de Recursos Humanos: Inclui os processos necessrios para que se faa o melhor uso dos recursos humanos envolvidos no projeto. 9. Gesto de Aquisies: Inclui os processos necessrios para a aquisio de bens e servios fora da organizao executora do projeto. Cada processo se caracteriza por suas entradas, tcnicas e ferramentas e sadas que so retroalimentados em um ciclo contnuo onde sadas podem alimentar a entradas do prximo processo. Alm disso, as reas de conhecimento abrangem diversos processos, onde o escopo, tempo, custo e qualidade so os principais focos para o objetivo do projeto. Essas premissas so necessrias para garantir a qualidade e recursos humanos, aquisies, comunicaes e riscos so elementos aos quais deve haver constante ateno em um projeto. E Integrao abrange a sincronizao com todas as outras reas.

Figura 4 Sinergia das reas de conhecimento Fonte: Mrcio D'vila, 2010. 2.1.2 Metodologia gil e o manifesto gil indiscutvel o fato de que as organizaes esto buscando todas as formas para minimizar seus custos. O cenrio mercadolgico atual faz com que cada vez mais as 4

organizaes invistam em prticas que minimizem seus custos e maximizem o ROI para se manterem competitivas. Nesse contexto, as metodologias geis como o prprio nome j diz, pregam a agilidade, esto ganhando mais e mais espao dentro das organizaes (AMBLER, 2008). A metodologia gil prev iteraes contnuas em prazos curtos ao decorrer de todo o projeto, visando garantir maior controle e previsibilidade. Em fevereiro de 2001, dezessete agilistas se reuniram e discutiram uma alternativa para a e melhoria de processos que j existiam at ento. Com a colaborao de todos, foram levantados alguns princpios relacionados agilidade (SCHWABER, Ken et al., 2001): Maior prioridade satisfazer o cliente, atravs da entrega adiantada e contnua de software de valor; Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento. Processos geis se adequam a mudanas, para que o cliente possa tirar vantagens competitivas; Entregar software funcionando com freqncia, na escala de semanas at meses, com preferncia aos perodos mais curtos; Pessoas relacionadas a negcios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto; Construir projetos ao redor de indivduos motivados, dando a eles o ambiente e suporte necessrio confiando que faro seu trabalho; O mtodo mais eficiente e eficaz de transmitir informaes para, e por dentro de um time de desenvolvimento, atravs de uma conversa cara a cara; Software funcional a medida primria de progresso; Processos geis promovem um ambiente sustentvel. Os patrocinadores, desenvolvedores e usurios, devem ser capazes de manter indefinidamente, passos constantes; Contnua ateno a excelncia tcnica e bom design aumentam a agilidade; Simplicidade: a arte de maximizar a quantidade de trabalho que no precisou ser feito; As melhores arquiteturas, requisitos e designs emergem de times autogerenciveis; e Em intervalos regulares, o time reflete em como ficar mais efetivo, ento, se ajustam e otimizam seu comportamento de acordo. Indivduos e interao entre eles mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; e Responder a mudanas mais que seguir um plano.

A partir da, nasceu o manifesto gil, que prega que:

Ou seja, mesmo havendo valor nos itens direita, os itens esquerda so mais valorizados.

Segundo a Scrum Alliance (organizao para promover, apoiar e gerar recursos aos agilistas - termo usado para designar os adeptos da metodologia), existem vrias metodologias no mercado atualmente, mas a mais utilizada vem sendo o Scrum. 2.1.2.1 Scrum Em 1993, Jeff Sutherland, Ken Schwaber e John Scumniotales usaram o Scrum pela primeira vez na organizao Easel Corporation, incorporando os conceitos da metodologia gil Lean. A partir disso, fundaram a Scrum Alliance. Aps dois anos, Ken Schwaber formalizou a nova metodologia e ajudou a divulg-la para as organizaes voltadas, principalmente, para o desenvolvimento de software. Segundo SCHWABER (2004), o nome Scrum vem da prtica esportiva Rugby que significa uma jogada envolvendo todos para que faam fora simultaneamente para que possam pegar a bola do time adversrio. Abstraindo o conceito para o mundo dos softwares, o Scrum um processo emprico de gesto e controle de projetos. De acordo com COHN (2010), a metodologia cr que devido complexidade, escopo, mudanas de requisitos, urgncia e necessidade de demonstrar valor (ROI) mais rpido, fica quase inconcebvel desenvolver software utilizado o modelo cascata, ou seja, desenvolver todo o software de uma nica vez. Com isso, o desenvolvimento iterativo e incremental uma estratgia de planejamento (que segue alinha dividir para conquistar), onde o software construdo em partes, ou seja, em Sprints (iteraes), onde a cada Sprint tem como meta a entrega de valor (parte do software funcional) at completar o software. Ainda segundo COHN (2010), para garantir o controle e previsibilidade desse processo, existem as cerimnias: 1. Reunio Diria: um encontro entre o Scrum Master, o Time e qualquer pessoa interessada no projeto com o timebox (tempo) de 15 minutos onde cada membro do time dar as suas impresses a respeito do projeto, respondendo a trs perguntas importantes: a. O que eu fiz desde a ltima reunio diria? b. O que eu pretendo fazer at amanh? c. Tem alguma coisa impedindo o meu trabalho? 2. Planejamento da Sprint: esta reunio ocorre no primeiro dia de cada Sprint. dividida em duas partes: no primeiro momento o Product Owner, o Scrum Master e o Time discutem sobre as funcionalidades potencialmente designadas para a determinada Sprint e no segundo momento, o Scrum Master e o Time estimam o tempo para o desenvolvimento de cada funcionalidade atravs da Planning Poker (prtica que auxilia na estimativa das funcionalidades pontuando o seu tamanho conforme a srie de Fibonacci). 3. Reviso da Sprint: esta reunio ocorre no ltimo dia da Sprint e representa o momento que o Time e o Scrum Master demonstram o seu desempenho atravs do Burndown Chart e as funcionalidades potencialmente entregveis executadas para o Product Owner e demais interessados, se houver. 4. Retrospectiva da Sprint: uma reunio entre Scrum Master e o Time onde duas perguntas so feitas: a. O que foi bom durante a Sprint? (Interno: Time/ Externo: Product Owner) 6

b. O que pode ser melhorado? (Interno: Time/ Externo: Product Owner) A partir da elaborado um plano de ao para atacar o que pode ser melhorado na prxima Sprint. Contemplam os artefatos: 1. Product Backlog: lista de funcionalidades a serem desenvolvidas ao longo do projeto distribudas em Sprints. 2. Sprint Backlog: lista de funcionalidades detalhadas no dia de planejamento envolvendo o Product Owner, o Scrum Master, o Time e demais interessados, a serem desenvolvidas ao longo da Sprint. O mundo ideal seria ter o maior nvel de detalhes para poder mensurar a complexidade das atividades para que se possa fazer estimativas mais assertivas e garantir uma boa velocity do Time garantindo a boa produtividade e uma boa previsibilidade das entregas. 3. Burndown: grfico demonstrativo do andamento das atividades da Sprint (Planejado X Realizado) a ser acompanhado durante todo o projeto e exibido na Reviso da Sprint. O andamento do projeto estar diretamente relacionado boa gesto do controle da produtividade do Time. Existem os papis: 1. Product Owner (PO): pode ser o financiador ou um importante interessado no projeto. Suas principais responsabilidades so: definir as funcionalidades do produto; concentrar as informaes vindas de usurios, stakeholders ou do mercado de maneira que se obtenha uma viso nica dos requisitos do sistema; priorizador do Product Backlog; ter autonomia para alterar as prioridades fora da Sprint. 2. Scrum Master (SM): desempenha o papel de lder, gerenciando os interesses do Product Owner mediante o Time. Numa abordagem tradicional, o Scrum Master seria um Gerente de Projetos, porm, essa nomenclatura foi substituda para diferenciar o foco de liderana necessrio para que um processo emprico funcione. Suas principais responsabilidades so: Atuar como facilitador; Remover Impedimentos; Garantir que o processo est sendo respeitado; Auxiliar o Product Owner a maximizar o ROI a cada entrega ao fim das Sprints. 3. Equipe Scrum (Time): Grupo de profissionais especialistas diretamente ligados ao trabalho a ser feito para garantir a entrega do projeto com todas as suas funcionalidades necessrias. Suas principais caractersticas so: Multifuncional; Formado por at 7 pessoas; Auto-gerencivel.

Figura 8 A engrenagem Scrum Fonte: Mike Cohn, 2010. 3 Paralelo PMBOK Guide X Scrum 3.1 Procedimentos Metodolgicos Atravs de uma leitura, anlise e interpretao do material bibliogrfico estudado relacionado s duas metodolgicas abordadas, esta pesquisa pretende dar uma resposta para uma questo que vm sendo abordada em vrios fruns relacionados gesto de projetos. Baseando no contedo abordado, a idia agregar o conhecimento voltado para a possibilidade de gerar uma discusso para se chegar a um discernimento para a construo de fundamentos e opinies prprias. O estudo comparativo entre as prticas do PMBOK Guide e do Scrum permite que se faa uma anlise aberta das diferenas, semelhanas, aderncias e perspectivas atravs das informaes analisadas e propostas. 4 Anlise de Dados No cenrio de mercado atual, possvel perceber que as organizaes de diversas reas de negcio vm investindo cada vez mais na gesto de projetos. Mas ainda sim, podemos perceber que os adeptos de metodologias geis esto mais concentrados em um nicho de mercado: TI. Levando em considerao estruturas organizacionais projetizadas onde a autonomia de tomada de decises dos responsveis est diretamente relacionada aos projetos, mas acima de tudo respeitando as estratgias da organizao, podemos perceber que ainda sim existem algumas semelhanas entre as formas de gesto descritas anteriormente apesar de terem um direcionamento e origem distintos: Caractersticas
Ter definido a priori Responsvel pela organizao executora para atingir os objetivos do projeto Principais artefatos Grupo de Programa/ Projetos Freqncia de Reunies de status

PMBOK Guide
Escopo. Gerente de Projetos.

Scrum
Tempo (Sprints). Scrum Master.

Start-Up do projeto

WBS (Work Breakdown Structure) e Plano do Projeto. Programa/ Portiflio de Projetos. Dependendo da complexidade/ necessidade do projeto, alinhar a freqncia. Reunio de Kick-off.

Product Backlog e Sprint Backlog. Scrum of Scrums. Dirias.

Planejamento da Sprint.

Entrega do produto

No encerramento do projeto.

Encerramento do Projeto Principais Ferramentas de Indicadores de Desempenho

Escopo

Lies aprendidas. EVA (Estimated Value Agregated), Grficos e Relatrios via MSProject, Curva S, Status Report. Definido na fase de Incio do projeto e formalizado atravs da WBS (Work Breakdown Structure). Detalhado para a realizao do projeto como um todo. Monitorao constante para no aferir o custo planejado. Constante verificao e validao das sadas dos processos. Anlise e controle dos riscos em todo o ciclo de vida do projeto. Formal e documentada. Papis bem definidos.

Entregveis Parciais conforme priorizao (por Sprints). Retrospectiva da Sprint. Burndown Chart.

Definido de forma macro na fase de Incio do projeto. No Planejamento da Sprint os requisitos so detalhados e priorizados. Detalhado e orientado a entregas (por Sprints). Maior controle em funo da agilidade de se incorporar mudanas. Constante verificao e validao das atividades durante a Sprint. Anlise e controle dos riscos em todo o ciclo de vida do projeto. Colaborativa. Equipe multidisciplinar e auto-gerencivel. Informal e voltil.

Tempo Custo

Qualidade

Riscos

Comunicao Recursos Humanos Aquisio Integrao

Controle por contrato bem definido e documentado. Plano do Projeto detalhado e Facilitao. monitorado durante todo o projeto.

Tabela 1 PMBOK Guide X Scrum. Fonte: Desenvolvido pelo autor. Com base no levantamento das informaes supracitadas, possvel perceber que ambas as metodologias possuem caractersticas muito semelhantes pois metodologias nascem para melhorar as que j existem. Nesse caso, porm, cada uma possui um direcionamento: enquanto as prticas do PMBOK Guide pregam a interao da organizao em um nvel mais estratgico e formal, o Scrum norteia a operacionalizao do processo da gesto de projetos de maneira informal e colaborativa. Sendo assim, possvel dizer que, diante dessa anlise, o Scrum indiretamente uma forma customizada das boas prticas abordadas no PMBOK Guide mesmo que o Scrum no seja originada diretamente do PMBOK Guide. As prticas podem ser complementares, onde pontos falhos de uma podem ser supridos por pontos fortes da outra. Ainda sim, ao passo que o Scrum prega que sua aplicao tenha que necessariamente estar em conformidade com a forma que proposta, ou seja, by the book, o PMBOK Guide d o livre arbtrio ao gerente de projetos com a colaborao da equipe, definir os processos apropriados a serem utilizados no projeto de acordo com sua visibilidade e complexidade. 5 Consideraes Finais A gesto de projetos definitivamente um dos caminhos mais indicados para se obter melhores resultados, mas preciso utiliz-lo de maneira adequada s necessidades de cada 9

projeto. O processo no deve ser engessado, deve ser um apoio para garantir que seja intrnseco s atividades que iro ser desenvolvidas ao longo do projeto e esse suporte dar condies efetivas para que as organizaes conquistem seus objetivos estratgicos. Para isso, preciso tambm considerar as caractersticas prprias de capa projeto: o escopo, o custo, o prazo, a natureza, a complexidade e a importncia do projeto respeitando a cultura, o processo e a estratgia de negcios da organizao. Alm disso, de extrema importncia selecionar as ferramentas, mtodos e tcnicas mais adequadas para cada situao. As organizaes no devem se deixar levar pelo modismo ou pensar que pode dar certo se j existe outra organizao trabalhando de determinada maneira. Esse um processo de constante aprendizagem e entendimento da necessidade e estrutura da organizao, seus clientes e o mercado. No h uma frmula de sucesso, ou seja, a sndrome da bala de prata da melhor metodologia em gesto de projetos no passa de uma lenda. Cabe s pessoas abstrarem o melhor de cada uma em benefcio da organizao e em conseqncia de seus projetos. Esse um caminho a ser seguido que visa sinergizar a melhoria contnua com o uso de ferramentas, mtodos e tcnicas que envolvem um processo de gesto de projetos com qualidade para garantir o diferencial competitivo envolvendo o nvel estratgico, ttico e operacional da organizao, para alinhar as necessidades/ expectativas Planejamento Estratgico, com a operacionalizao das aes estratgicas como meio de alcanar os objetivos para se atingir os resultados com o ROI esperado. Referncias bibliogrficas - AMBLER, S. W., Has Agile Peaked?. Disponvel em: <http://www.drdobbs.com/>. Acesso em: 26/04/2010. - CARNEIRO, Margareth F.S., Metodologia de Gerenciamento de Projetos. Disponvel em: <http://www.pmkb.com.br>. Acesso em: 26/04/2010. - CHAIRMAN, J. J. Standish Group Study <http://www.standishgroup.com>. Acesso em: 26/04/2010. Reported. Disponvel Disponvel em: em:

COHN, Mike., Uma introduo ao Scrum. <http://www.mountaingoatsoftware.com>. Acesso em 26/04/2010. - DVILA, Mrcio. PMBOK Guide e Gerenciamento de Projetos. Disponvel em: 26/04/2010.

<http://www.mhavila.com.br/topicos/gestao/pmbok.html>.

Acesso

em:

- KING, David., PROJECT MANAGEMENT MADE SIMPLE - A Guide to Successful Management of Computer Systems Projects. ISBN: 0137177291, Prentice Hall, 1992. - PMI Project Management Institute, Um Guia do Conhecimento em Gerenciamento de Projetos PMBOK Guide Quarta Edio. ISBN: 9781933890708., PMI, 2008. - PMI Project Management Institute. Disponvel em: <http://www.pmi.org>. Acesso em 18/05/2010. - SCHWABER, Ken et al., O manifesto gil. Disponvel em: <http://agilemanifesto.org/>. Acesso em: 26/04/2010. - SCHWABER, Ken., Agile Project Management with Scrum. ISBN: 073561993x., Microsoft Press, 2004. - SCRUM Scrum Alliance. Disponvel em: <http://www.scrumalliance.org>. Acesso em 26/04/2010.

10