Tag Archives: SCRUM

A oportunidade pode ser única: vá de Paralelismo (fast tracking)!

17 Nov

Sempre que estou prestes a concluir algum projeto gosto de analisar as principais ações adotadas em seu planejamento e execução para avaliar os resultados efetivamente entregues. Desta vez, construirei essa análise com vocês, aqui neste novo post!

Na publicação passada, quando abordei sobre a Eficácia e Eficiência no Gerenciamento de Projetos (clique para ver), procurei enfatizar a necessidade de concentrar esforços em fazer com que o projeto atendesse não só aos requisitos “burocráticos”, mas, principalmente, àqueles que permeassem a qualidade, expectativas e aprendizado.

Ainda influenciado pelos meus vagos pensamentos deste último post, eu comecei a conjecturar sobre um novo projeto que entra em sua Fase de Encerramento. A proposta do projeto está em desenvolver uma Ferramenta de Gestão de Atendimento ao Cliente. Este projeto não chega a possuir alta complexidade de implementação de suas funcionalidades. Entretanto, tivemos (Equipe do Projeto) que fazer uso de algumas técnicas de GP bem interessantes como, por exemplo, o Paralelismo de algumas atividades da Fase de Execução.

Se a análise deste projeto partisse do proposto de [eficácia + eficiência = efetividade] seria ideal envolver as pessoas que demandaram e ajudaram a construir o projeto.  Não que isto não seja importante, ao contrário: é muito importante!!! No entanto, vou restringir, ao menos por enquanto, à análise do uso da técnica do Paralelismo neste projeto.

Pra começar, recorri ao Guia PMBOK v4 para buscar a definição do que seria a técnica do Paralelismo:

“Uma técnica específica para compressão do cronograma de um projeto que altera a lógica de rede sobrepondo algumas fases que normalmente seriam realizadas em sequência, como a fase de projeto e a fase de construção, ou para realizar atividades do cronograma em paralelo.”

Essa definição não poderia ser melhor!

A história do nosso projeto é bastante simples: as fases de iniciação e planejamento do projeto não foram sobrepostas, ou seja, seguiram bem a metodologia proposta pela empresa. Mas, as Iterações foram reorganizadas de forma a serem paralelizadas. Ao invés de se concluir uma Iteração para então iniciar a próxima, optamos por implementar várias Iterações no mesmo período, mas que seriam complementares entre si.

E por que disso?! PRAZO! PRAZO!! PRAZO!!!

A compressão do cronograma é uma técnica de “redução da duração do cronograma do projeto sem reduzir o seu escopo“.

Lembro que reduzir escopo para alcançar a restrição de prazo nem sempre é uma boa opção: o cliente não vê com bons olhos ter suas necessidades do projeto minimizadas. Ele se sente impotente e, com isso, acaba se afastando do projeto. Em casos assim, é comum utilizar algumas técnicas de Compressão do Cronograma, como a técnica do Paralelismo!

Para que você possa entender melhor o contexto do projeto, nós utilizamos a metodologia da empresa (ativo organizacional) de Gerenciamento de Projetos e Engenharia de Software, a qual estava embasada no Manifesto Ágil. O conceito de ciclos era algo bem forte na metodologia. E para iniciar um próximo ciclo, necessariamente, o anterior deveria estar homologado pelo cliente.

A imagem 1 a seguir demonstra como o projeto foi inicialmente planejado, sem considerar a sobreposição de tarefas:

Imagem 1: execução do projeto de forma linear.

Facilmente, pelo Gráfico de Gantt, podemos constatar as Iterações encadeadas. O Software seria construído de forma incremental. Outra observação que faço está relacionada ao caminho crítico destacado em amarelo, veja como ele foi alterado na imagem abaixo.

Já a imagem 2 demonstra o uso do Paralelismo no projeto para os ciclos de 1 a 5:

Imagem 2: execução do projeto utilizando Paralelismo.

Com essas duas imagens pode-se comparar o quanto o cronograma é modificado e, principalmente, como o caminho crítico é afetado quando utilizamos alguma técnica de compressão do cronograma.

A primeira coisa que me vem à cabeça, quando utilizo a técnica de Compressão do Cronograma, está relacionada à precariedade em seu uso quando temos uma iteração (ciclo) sendo utilizado como insumo para a implementação do próximo ciclo:

1 – A integração do sistema ficou altamente empobrecida. O que gerou dificuldade de compreensão do fluxo de funcionamento do sistema como um todo;

2 – Geração de retrabalho decorrente da integração dos ciclos;

3 – Sensível incremento nos custos do projeto. A linearidade do projeto se perdeu. Novos recursos humanos tiveram que ser adicionados ao projeto para permitir a execução de atividades em paralelo.

4 – As estimativas de duração das atividades foram impactadas, pela falta do insumo para planejamento do próximo ciclo;

5 – Sobrecarga de trabalho para alguns perfis da equipe;

A sobrecarga de alguns perfis como Analista de Testes e o Designer de Interface, se justifica, já que, tiveram que se dividir entre uma e outra iteração. De certa forma, isto os pressionou e comprometeu seus desempenhos. Não havia disponibilidade de contratação ou alocação de outros recursos com este perfil para o projeto.

O versionamento de documentos, a gestão de atividades e priorização ficou dificultada. Muitas vezes, havia necessidade de parar o projeto para sanar dúvidas que deveriam ser respondidas na Homologação de Cada Ciclo desenvolvido anteriormente – lembro que um ciclo serve de insumo para outro.

Naturalmente, o Paralelismo implica em riscos de integração. Quando se utiliza o desenvolvimento simultâneo de ciclos, a integração deve ser muito bem planejada e o custo disso deve ser previamente aprovado. Nem sempre é fácil prever a variação dos custos do projeto quando se utiliza a Compressão do Cronograma!

E o cliente, como fica nesta situação?

É neste ponto que devemos verificar o Custo x Benefício do uso desta técnica de Compressão do Cronograma. O que será escrito aqui não pode ser tratado como regra para todos os projetos, até porque os projetos não são iguais, ok?

O custo do projeto, apesar de ter evoluído, não era algo determinante para continuar ou não o projeto. Basicamente, o esforço de custo estava em alocação de recursos humanos para o projeto. E este custo já estava pago. Se a equipe não fosse alocada para este projeto estaria em outro mais prioritário. Sobre contratos hora homem no serviço público brasileiro, eu publiquei o post que trata deste tema – IN 1 – Procedimentos para o desenvolvimento, disponibilização e uso do Software Público Brasileiro.

No entanto, o cliente enxergou no projeto uma oportunidade de alavancar seu setor de atendimento ao cliente, que até então era precário. Ou seja: o projeto fazia parte de uma estratégia organizacional maior!

Nestes casos, a Gerência do Projeto deve entrar em ação!

Quando se usa o Paralelismo, o cliente tem que está bem mais envolvido do que o normal. É também essencial que o Cliente esteja ciente dos riscos envolvidos nesta operação. Ele deve ser parceiro do projeto!

Para gerenciar as expectativas do cliente, o Gerente de Projetos deve dar autonomia a equipe técnica para resolver questões de implementação e, principalmente, necessita mantê-lo informado da relação de evolução do Escopo x Tempo x Custo. A análise de valor agregado é fundamental para que o cliente veja o quanto a decisão de antecipar o prazo custou ao projeto!

Lembro que a oportunidade para realizar o projeto era única, já que, havia recursos disponíveis, patrocínio e vontade política!

No entanto, mesmo com os entraves apresentados acima, seria o Paralelismo o fim dos tempos no Gerenciamento de Projetos?!

Não! De forma alguma!

Tente enxergá-lo como uma oportunidade. Explico:

Propiciar aos clientes da empresa um atendimento mais qualificado  é algo que deve ser visto como investimento e não custo. O prazo deveria ser atendido, já que a vontade política para realizar o projeto passava por essa restrição. Em qualquer projeto, não se pode perder o patrocínio, ainda mais quando voltado para órgão público.

Neste caso, a Técnica de Compressão do Cronograma baseada no Paralelismo é muito importante.

Aí convenhamos: mesmo com todas as dificuldades no Gerenciamento do Projeto e nos eventuais fracassos obtidos em relação a isso, sob a ótica do cliente o projeto atendeu as expectativas técnicas e negociais, já que cumpriu com seu escopo e com os objetivos políticos determinados para ele.

Veja o porquê do dilema de Eficácia e Eficiência continuou a ventilar os meus pensamentos…

É isso! Continue visitando o blog!

Até a próxima!

P.S.: este blog concorre ao TOP BLOG 2011. Não se esqueça de apoiar!

Scrum Master vs Gerente de Projetos, PMP: Presente e Passado?

4 Jul

Se você ainda não vivenciou uma situação parecida com que vou descrever, então imagine: de um lado um ScrumMaster certificado (CSM) e do outro um PMP, e algumas pessoas em volta observando a discussão de quem é o melhor perfil para gerenciar projetos!!!

Seria mais uma daquelas discussões intermináveis?!

Pensando nisso, resolvi escrever este post: seria o CSM o presente e o PMP o passado na gerência de projetos?

Lembro que a proposta de ser iterativo e incremental, pregada pelo Scrum, não é nova. Há várias metodologias na Engenharia de Software que pregam a construção baseada em ciclos e releases. Não pretendo com isso minimizar a importância do Scrum, ao contrário. Eu vejo a força desta metodologia na forma de organização do time do projeto e na condução das iterações (sprints) durante o desenvolvimento do projeto, além  da questão da qualidade nos produtos desenvolvidos. Realmente acredito nesta proposta! Mas não é isto que torna o ScrumMaster o grande profissional de gerenciamento de projeto.

De acordo com o Scrum Guide de 2010, a equipe Scrum (Scrum teams) é designada para otimizar a flexibilidade e produtividade do projeto; e para este fim, a equipe é auto-organizada, são cross-functional  (time com diferentes experiências e habilidades voltadas para um objetivo comum) e trabalham por interações.

Faz parte da equipe Scrum: o ScrumMaster; o Proprietário do Produto e a Equipe Scrum.

O ScrumMaster é o responsável por garantir que o processo é compreendido e seguido por TODOS.

Atenção! É também premissa básica, super importante, fundamental etc. etc. etc., que o PMP garanta o processo adotado para o gerenciamento do projeto e que todos os envolvidos tenham ciência deste processo e o execute de maneira coerente, ok?!??!

As figuras do Sponsor (PMBOK) e do Proprietário do Produto (Scrum) dão um encaminhamento distinto para a atuação dos dois perfis, veja:

O Proprietário do Produto é o responsável por maximizar o valor do trabalho que o Time SCRUM realiza.  Já o Sponsor, como apontado no PMBOK, é a pessoa ou grupo que fornece os recursos financeiros, em dinheiro ou em espécie, para o projeto.

Fundamentalmente isso já traz uma consequência para a atuação do ScrumMaster e o Gerente de Projetos que se baseia no PMBOK, concorda?

Observe que o Proprietário do Produto atua em conjunto com a equipe para que o projeto atenda aos requisitos necessários. Já  Sponsor é uma espécie de suporte ao gerente de projeto, para tratar de assuntos relacionados à mudança, além de ser o porta-voz do gerente de projetos para os níveis gerenciais mais altos.  Esta diferença é realmente importante e na prática acaba fazendo toda a diferença.

O ScrumMaster de acordo com o Scrum Guide:

  • Trabalha com os clientes e gestão para identificar e indicar um Proprietário do Produto.
  • Ensina o Proprietário do Produto como fazer o seu trabalho. Espera-se que o Proprietário do Produto saiba como conseguir otimizar valor usando Scrum. Se não, temos o ScrumMaster responsável.
  • Pode ser um membro da equipe, por exemplo, um desenvolvedor que executa tarefas no Sprint (iteração)No entanto, isso muitas vezes leva a conflitos quando o ScrumMaster tem que escolher entre remover impedimentos e realizar tarefas.
  • Nunca deve ser o Proprietário do Produto.

O Gerente de Projetos segundo o Guia PMBOK:

  • Pessoa designada pela organização executora para atingir os objetivos do projeto;
  • Sua autonomia depende do tipo de estrutura organizacional que projeto será desenvolvido;
  • Requer habilidades da área específica e das proficiências ou competências de gerenciamento geral;
  • Ter capacidade de realização;
  • Ter liderança;
  • Capacidade de orientar a equipe do projeto ao mesmo tempo em que atinge os objetivos e equilibra as restrições do mesmo;
  • Dependendo do contexto do projeto, o GP poderá determinar a necessidade de um controle mais eficaz sobre certas entregas;
  • Cabe ao Gerente de Projetos e a sua equipe, determinar o método mais apropriado de execução do projeto.
  • Gerenciar as expectativas das partes interessadas;
  • Desenvolve o plano de gerenciamento de projeto e todos os componentes relacionados;
  • Identifica e monitora os riscos;
  • Fornece relatórios precisos e oportunos das métricas do projeto;
  • É o líder responsável pela comunicação com todas as partes interessadas;

As funções do Proprietário do Produto e do ScrumMaster são bem definidas e claras. Já o PMBOK dá ao gerente de projetos a responsabilidade sobre atividades que poderiam ser compartilhadas com o Sponsor do Projeto.

Resultado disso na prática:

Bom, aí penso que nem todos os projetos cabem, unicamente, em um ou em outro perfil. O contexto mais uma vez vai direcionar qual a melhor forma de orientar e conduzir os trabalhos.  O momento atual do manifesto ágil é muito bom, mas não significa que a filosofia PMI seja ultrapassada, afirmar isso, a meu ver, seria leviano.

Os profissionais PMP passam por um regime mais rigoroso de certificação que os certificados ScrumMaster, isto tem que ser levado em consideração ao avaliarmos os perfis. 

O IT-Management, baseado em uma pesquisa realizada pelo site de empregos de TI, Dice Learning, publicou sobre as certificações percebidas como de grande valor, e a certificação PMP aparece no topo, sendo que a CSM nem na lista aparece. Pense nisso!

O mercado, no entanto, quer alguém que responda com mais agilidade e seja menos burocrático ou estritamente metodológico. Por muitas vezes, já presenciei gestores importantes referindo-se aos PMP’s como “grandes burocratas de alto custo”.  Vejo como demasiadamente dura a afirmação.

Talvez, digam isso por perceberem que os profissionais que conduzem projetos, baseados no manifesto ágil, dão maior foco nos resultados funcionais do projeto. No entanto, vejo que os PMP’s, para projetos de alta criticidade, que requerem maior controle de custos, riscos e recursos, são os mais adequados.

Para que funcione bem, o Scrum requer uma equipe mais experiente, que saiba como se auto-organizar e que tenha em seu “líder” alguém que seja um facilitador para os problemas que surgem no dia-a-dia do projeto e garanta o processo. Por mais belo que isso seja na teoria, nem sempre é fácil de realizar na prática.

Finalizando: nem o PMP é passado e nem o CSM é o presente. Ambos são realidades! Quem é melhor… Aí é uma discussão interminável, do tipo projetista JAVA  vs projetista C#…

Abraços e até a próxima!

Ei, Gerentes de Projetos e Analistas de Negócio! Qual o futuro de vocês?

19 Maio

Se no post “PMO. O que eu tenho haver com isso?” eu comentei que o tema “escritório de projetos” era algo que em determinadas situações eu não gostava de discutir, o assunto de hoje já me traz muita motivação.  Não sei se o ensejo para tanta motivação gira em torno das áreas de tecnologias (re)inventarem profissões a cada nova onda ou se o estímulo vem da minha própria necessidade de sobrevivência.

Enfim, o fato é que ao acompanhar o mercado de empregos, as necessidades de clientes, as demandas de cursos e das minhas próprias necessidades,  percebi o quanto as habilidades e técnicas de algumas profissões podem ser realizadas por um mesmo profissional.

Recentemente, recebi um e-mail, de uma importante autora americana ligada à área de gerenciamento de projetos, oferecendo cursos de aperfeiçoamento profissional. Entre os cursos estava um que me chamou a atenção, chamava-se: “Project Manager or Business Analyst: Who Am I?”

A oferta deste curso foi o estímulo necessário para compartilhar com você alguns pontos de vista a respeito “de quem sou eu”…

  • Um dado rápido: nas décadas de 80 e 90 havia uma figura muito importante chamada de Analista de Sistemas. Este profissional era o responsável por levantar e modelar sistemas baseados em regras de negócios. Havia também o programador, o cara que só codificava e era movido a escrever códigos. Logo, o mercado percebeu que muitos profissionais que modelavam sistemas também programavam e, até,  gostavam disso. Logo veio a demanda do PROGRAMALISTA. Se você é profissional de TI, com certeza irá se lembrar disso. Era O famoso dois em um a preço de um (que persiste até hoje).

E quanto a nós (gerentes de projetos) e aos Analistas de Negócio? Continuaremos a ser dois profissionais distintos ?

Será possível que um profissional desenvolva habilidades comuns aos dois perfis e se dê bem com isso?

(é verdade que são questões não muito fáceis de serem respondida…e eu não tenho a soberba de achar que tenho a resposta.)

Mas vou compartilhar com vocês o que pensei: como para os GP’s tem o guia PMBOK, os Analistas de Negócio tem o guia BABOK. Ambos são padrões reconhecidos internacionalmente que descrevem áreas de conhecimentos, atividades, tarefas e as habilidades necessárias para se tornarem profissionais de GP ou de Análise de Negócio.

A respeito, o Guia BABOK define a Análise de Negócios como sendo um “conjunto de atividades e técnicas utilizadas para servir como ligação entre as partes interessadas, no intuito de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam a organização alcançar suas metas”.

Ainda neste Guia é citado que o Analista de Negócios é “o responsável por desvendar as verdadeiras necessidades das partes interessadas, não simplesmente seus desejos explícitos. Em muitos casos, o analista de negócios irá trabalhar também para facilitar a comunicação entre unidades organizacionais”.  Lembro que é atribuição básica do gerente de projetos a atividade de comunicação.

De acordo com Guia BABOK qualquer um pode ser Analista de Negócios, desde que execute as tarefas descritas no Guia.

Então calma! Este ponto é  importante: se qualquer um pode executar as tarefas do Analista, então o Gerente de Projetos não poderia desenvolver alguma atividade deste profissional?  Ou melhor, ele já não desenvolve algumas tarefas do escopo do analista?

Se formos simplistas e pragmáticos, colocaremos cada “macaco em seu galho”. Não misturaremos as coisas, certo?

Mas, FELIZMENTE, a área de TI não nos permite ser assim. Seria um retrocesso ir de encontro com a própria inovação que permeia a tecnologia da informação  e a demanda do mercado.

O que quero chamar atenção é que já existe (e isso é bem real) a necessidade do gerente de projetos saber mais do que “apenas” gerenciar projetos. É necessário que ele entenda do negócio, que construa a solução em conjunto com os demais analistas e engenheiros do projeto. O gerente de projetos moderno não se limita a planejar e monitorar o projeto, ele ajuda a entender os requisitos e as necessidades do negócio.

Sim! É neste ponto que vejo que as coisas podem se misturar.  O Gerente de Projetos e o Analista de Negócios podem ser a mesma pessoa. Até vejo que é bem mais fácil o Gerente de Projetos integrar as habilidades do Analista do que o contrário, mas de qualquer forma, os papéis podem se misturar…

Não resista!

As metodologias ágeis já sugerem isso. O gerente do projeto é mais um papel dentro da equipe e ele tem a responsabilidade de propor a melhor solução e a melhor maneira de fazer essa solução. A ideia do CHEFE da equipe, a meu ver, é ultrapassada.

Só para fechar, os profissionais que tiveram a visão de programar e fazer análise permaneceram no mercado por mais tempo. Os profissionais de gerenciamento de projetos e de análise de negócios que querem ter a empregabilidade em alta também devem abrir seus horizontes e agregar valor ao seu portfólio de conhecimentos e habilidades. E, para isso, nada como agregar competências!

É isso! Abraços e até a próxima!

PMO. O QUE EU TENHO HAVER COM ISSO?

3 Maio

O escritório de projetos (PMO – Project Management Office) é um tema recorrente em congressos, workshops, fóruns e por aí vai. Confesso que tenho até me afastado das discussões que envolvem este tema.

Explico: primeiro que é uma discussão sem fim sobre os reais benefícios que ele gera; segundo que cada empresa tem sua cultura e realidade e, portanto, não teremos modelos de escritório de projetos que sirvam para todas as organizações; e, por fim, nada é mais chato do que comparar um caso de “sucesso” com outro caso de “sucesso” que ninguém saiba exatamente do que se trata.

Oras, então porque falar sobre PMO neste post? Continue lendo que você vai entender!!

http://www.thepmoblotter.org/

imagem retirada de: http://www.thepmoblotter.org/

O engraçado, apesar de tudo, é que gosto muito do tema, exatamente por ele não ter uma fórmula pronta. Ou seja, é uma ideia em construção!

E o melhor: demoraremos muito tempo em ter um modelo único, pronto e consolidado, isso se conseguirmos ter algum.

O gerente de projetos, com certa experiência, sabe que para o projeto dar certo, ele dependerá muito do seu esforço pessoal e do comprometimento da equipe com o trabalho a ser desenvolvido. E quando o GP descobre isso, o PMO poderá ficar a ver navios. Se o escritório tem o objetivo de consolidar uma metodologia por toda a organização, o gerente de projetos pode ser seu algoz, pois ele irá fazer do jeito que ele acredita ser certo e não que alguém acredita que seja. Pode soar estranho… mas continue lendo.

O PMO quando posicionado em nível elevado na estrutura organizacional da empresa, pode muitas vezes ter uma visão muito macro das dificuldades setoriais em que os gerentes de projeto estão envolvidos. Já os gerentes de projetos, conhecem como poucos a cultura do seu setor/área dentro da organização. E isso torna a informação assimétrica em favor do gerente de projetos, principalmente, quando ele não faz parte do escritório de projetos.

  • Outra coisa que me questiono muito é quando um escritório de projetos é implantado sem o cuidado de se ter desenvolvido um plano estratégico para ele.
  • Qual a visão, missão, objetivos e metas deste escritório?

Todos na organização têm conhecimento sobre a visão e as metas de curto, médio e longo prazo deste escritório?  Lembro que muitas vezes nem mesmo o plano estratégico da empresa é conhecido por todos.

Ainda nesta linha, vejo muitos escritórios com o objeto de sua existência muito grandioso, o que tende a perder o foco no médio prazo. Em organizações que não tem cultura de gerenciamento de projetos é fácil tornar o PMO alvo de criticas por aqueles que o vêem como um ameaçador ou frustrar àqueles que o viam com solução para seus problemas.

E não é muito difícil adivinhar porque isso ocorre: não há entregas de curto prazo que mostrem os benefícios reais de se ter o escritório.

Volto a dizer: começar pequeno e bem planejado é fundamental.

Em 2009/2010 fiz um estudo sobre implantação de PMO’s no serviço público brasileiro e ao final dele constatei algo que meu orientador já me questionava: afinal pra que serve um PMO? Que benefícios ele traz? PRA QUÊ PRECISAMOS DISSO? Confesso que não consegui responder em sua totalidade estes questionamentos, algo que me frustrou.

Pra não dizer que sou pessimista quanto à implantação de um escritório de projetos, vou indicar quatro pontos que penso que não podem faltar quando se pensa em realizar um PMO:

  1. Defina os resultados de curtíssimo prazo (eu disse CURTÍSSIMO PRAZO) e que gere benefícios para toda organização. Dê visibilidade e atenda as expectativas iniciais.
  2. Reúna pessoas que compartilhem das propostas do gerenciamento de projetos. Envolva, principalmente, os gestores que se animam com a ideia!
  3. Desenvolva competências (e isso não pode ser feito depois da implantação). As competências preparam o ambiente para consolidar a infraestrutura do PMO quando ele for implantado. Você já terá pessoas que compartilham suas idéias! Ou seja, você terá seguidores!!!!!
  4. Não subestime o estado atual do processo em que as pessoas trabalham. Muitas vezes o inicio da maturidade do processo pode estar na consolidação dos processos que já são realizados há anos pela empresa.

Por fim, gostaria de dizer que acredito nos escritórios como disseminadores da cultura de gerenciamento de projetos, como estimuladores do processo de aprendizagem e de controle dos registros de lições aprendidas. Claro que vários outros objetivos podem ser contemplados, mas aí, uma nova discussão se inicia…

Abraços!!!

Case Projeto Automação BPM: PMBOK e o Manifesto Ágio, mistura possível?

19 Abr

No post deste mês gostaria de escrever sobre algo que pudesse conciliar teoria com prática e, ao mesmo tempo, fosse conciso e prazeroso de ser lido. Foi aí que, pra variar, em conversas “informais” com amigos ligados ao gerenciamento de projetos e outros da engenharia de software, surgiu à ideia de falar sobre os ingredientes que utilizei para gerenciar um projeto de Automação de Processos (BPM) em um órgão público de Brasília. Esses ingredientes foram às práticas do Guia PMBOK v4 e o Manifesto Ágil, mais precisamente as ideias propostas pelo SCRUM.

Só para contextualizar, o projeto de Automação BPM já vinha se arrastando na empresa há alguns anos e vários tipos de recursos já haviam sido despendidos. No entanto, os resultados práticos da automação não aconteceram. Ou seja, os processos já tinham sido modelados “as/is” e diagnosticados para uma melhoria “to/be”, mas TUDO estava em grandes mapas plotados ou na ferramenta utilizada para modelagem. A automação em si, não havia acontecido. Para agravar a situação, temos uma característica básica quando trabalhamos com processos, eles são vivos e não estáticos que perduram ao longo dos anos. Ao contrário disso, eles se modificam!

Já se pode imaginar qual era a missão? Fazer acontecer à automação de pelo menos uma área negócio da empresa. Então vamos lá: restrição de prazo, custo, recursos e baixíssima credibilidade dos tomadores de decisão quanto ao projeto e a estima da equipe bem abalada. Este era o cenário. E para apimentá-lo, havia um ponto fundamental, este era o primeiro projeto da área de TI que seguiria uma metodologia de gerenciamento de projetos que havia sido elaborada pelo escritório de projetos recém-implantado. Ou seja, o cliente interno não tinha a cultura dos projetos de TI serem desenvolvidos de forma estruturada. Mas este era o cenário e tínhamos que encará-lo!

Os ingredientes propostos pelo SCRUM e o PMBOK v4 se casaram bem à medida que colocamos a força de cada um no seu devido lugar. Para ilustrar, utilizarei o cronograma, a EAP e o Product Backolog para demonstrar como os dois “paradigmas” podem funcionar juntos.

Acreditei naquilo que o PMBOK talvez tenha de melhor: os processos de iniciação, planejamento, gestão de mudanças e monitoramento do projeto. Não é porque deve ser “ágil” que o projeto não deva ser planejado. Lembrando que o conceito de “ágil” no manifesto não se refere à velocidade, rapidez de entrega, mas sim, de agilidade em resposta a mudança. E como não poderia ser diferente, os órgãos públicos exigem, por força de lei, forte controle de custos e prazos, além dos recursos humanos envolvidos. O Guia PMBOK é uma boa sugestão para ser utilizado para estes casos.

clique para ampliar

Primeira coisa: eu precisava saber se os processos mapeados para a automação continuavam válidos. Foi aí que entrou o processo de iniciação e a atividade de análise de documentação pré-projeto, previsto no PMBOK. Daí foi possível compreender o escopo e, consequentemente, foi hora de definir o product backlog do projeto. Sim, este conceito vem do SCRUM e tem objetivo similar ao da EAP. Tanto que fiz um product backlog para a execução e a EAP para a gerência do projeto. Duplo trabalho? Claro que não! A EAP é uma ótima ferramenta de comunicação com os gestores do projeto e o product backlog é excelente para lidar com a equipe técnica e o “product owner” do projeto. Mais do que isso, no caso desta empresa pública, em que o projeto foi desenvolvido, há uma metodologia de gestão de projetos em que  a EAP é um artefato obrigatório, já o product backlog foi algo acrescentado pela circunstância do projeto.

clique para ampliar

A execução do projeto foi toda direcionada para que  o manifesto ágil prega: desenvolvimento iterativo, incremental e equipe pequena (havia 4 pessoas voltadas a execução).  Toda a execução foi divida em sprints com igual período de execução. Minha função na execução do projeto era de um facilitador junto à equipe técnica e perante a gestão da empresa, eu era o gerente de projetos que controlava custo, tempo, recursos, escopo, mudanças e realizava a comunicação. O prazo definido pela equipe, a partir da definição do product backlog e do sprint backlog, se fez totalmente compatível com a restrição de prazo que havia para o projeto. Outra iniciativa que trouxe do SCRUM foi a realização das reuniões diárias com a equipe. A reunião propicia excelentes resultados junto à própria equipe, que não fica ilhada em demandas isoladas. As reuniões criam o senso de equipe, pois todos sabem o que está acontecendo e, mais do que isso, se propõe em fazer um ajudar ao outro.

clique para ampliar

Em fim, qual o grande barato disso: é possível adequar dois paradigmas e obter bons resultados. Os projetos críticos, com altos níveis de riscos, não podem ser planejados exclusivamente com base em requisitos funcionais. Deve-se, por exemplo, levar em consideração as etapas da área de conhecimento de riscos, que por sinal é bem descrita no guia PMBOK.

Como já disse aqui, ter a perspicácia do que utilizar e quando utilizar pode levar o projeto ao sucesso. As ideias dos paradigmas do Guia PMOBK e do Manifesto Ágil podem ser trabalhadas em conjunto sim!

Até a próxima!

%d bloggers like this: