Arquivo | Profissão RSS feed for this section

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!

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!

%d bloggers like this: