Tag Archives: processos

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!

Por favor, mais Eficácia no Gerenciamento de seus Projetos!

27 Out

A dinâmica da disciplina de Gerenciamento de Projetos é algo realmente apaixonante. A disciplina tem o poder de transformar, diga-se de passagem, com extrema facilidade, o presente em passado e o distante futuro em realidade absoluta. E isto não acontece por acaso: é espantoso e gratificante ver o quanto se estuda os temas relacionados ao Gerenciamento de Projetos.

Não é raro observar o grande número de autores investindo seu tempo em aprimorar a aplicação do Gerenciamento de Projetos nas organizações. Mais do que isso, é muito bom ver que os profissionais que operam o Gerenciamento de Projetos no dia-a-dia têm o prazer em contribuir com a melhoria contínua dos conceitos envolvidos com a matéria.

Até ontem, por assim dizer, havia total foco em atingir, com máxima precisão, os indicadores de custos e tempo propostos para um projeto. Para muitos, projeto bem realizado era aquele que cumpria suas metas de orçamento e prazo com perfeição. Isto não é de todo errado, já que se buscava a eficiência dos projetos.

Entretanto, o Gerenciamento de Projetos se propõe a ser mais do que dar aos GP’s ferramentas administrativas e orçamentárias para planejar e monitorar um projeto. Não que estas ferramentas sejam desnecessárias, ao contrário, são essenciais. Porém, não é o core do Gerenciamento do Projeto. É neste ponto que gostaria de compartilhar algumas posições sobre a Eficiência e a Eficácia no Gerenciamento de Projetos.

Confesso que não é raro eu confundir Eficiência com Eficácia. Mas, quando isso ocorre, sempre recorro a uma citação de Peter Drucker que diz o seguinte:

“A eficácia é o fundamento do sucesso – eficiência é a condição mínima de sobrevivência após o sucesso ter sido atingido. A eficiência se ocupa em fazer as coisas corretamente. Eficácia significa fazer as coisas certas.”

Compreender isso é realmente importante!

A reflexão sobre Eficiência e Eficácia, no entanto, tem seu inicio na verificação do estágio atual de maturidade de Gerenciamento de Projetos em que a organização se encontra: para aquelas organizações que já atingiram seu sucesso inicial, não seria o momento de caminhar em direção à eficácia dos processos de Gerenciamento de Projetos?

É uma questão que parece óbvia…

O Autor Harold Kerzner ensina que há um Ciclo de Vida da Maturidade do Gerenciamento de Projetos na organização, no qual alguns desafios são apontados em cada fase desta maturidade. A imagem abaixo retirada do livro Project Management – a systems approach to planning, scheduling and controlling do autor citado define bem isto:

Compreendido o estágio que o Gerenciamento de Projetos se encontra, agora é hora de pensar na Eficácia do processo!

Já o conceito de Eficiência e Eficácia para o Gerenciamento de Projetos é tratada, de acordo com a autora Johanna E. M. Schönrok, da seguinte forma:

A eficácia do projeto refere-se à reunião da qualidade do produto definida pelas especificações e requisitos e considera-se a eficiência do projeto sendo definida pelo grau de realização do projeto dentro do prazo e orçamento.

Veja o quanto isso é importante: basta cumprir o projeto conforme seu planejamento de custo e prazo para ele ser considerado “realizado com sucesso”?

Em minha opinião não!

Considero que se dar por satisfeito exclusivamente com a Eficiência do Projeto é muito pouco pelo o que se propõe para o Gerenciamento de Projetos.

Gerenciar Projetos é atingir objetivos maiores!

Pouco adianta cumprir o prazo e o orçamento se não atingir aos objetivos especificados, além de não conseguir provar os motivos que deram existência ao projeto.

É preciso pensar a avaliação do projeto de outra forma: eficácia!

Veja: se os objetivos de qualidade e requisitos do projeto foram cumpridos entre 90% a 95% do proposto e, no entanto, o prazo superou as expectativas em 20% o projeto teria fracassado?!

Se olharmos para a eficiência do projeto, a resposta seria sim!

Mas o projeto atingiu 90% a 95% dos requisitos de qualidade proposto!!!!

Se este percentual foi acordado entre cliente e executor, o projeto foi realizado de uma maneira correta! Pois ele foi eficaz!

Outro aspecto que chamo a atenção é quanto a Gerência de Recursos Humanos em projetos. Uma das vertentes do Gerenciamento de Projetos está na disseminação do conhecimento. A organização que já se encontra em fase avançada de maturidade consegue reter e disseminar o conhecimento adquirido ao longo do desenvolvimento do Projeto. Ao fazer com que a equipe do projeto se desenvolva durante a realização do Projeto, a organização também se torna eficaz.

Veja que este aspecto de mensurar aprendizagem nem sempre é tão simples, mas é um critério tão importante quanto os critérios de custos e prazo. Ter metas relacionadas ao desenvolvimento de Recursos Humanos e de registro e disseminação de Lições Aprendidas também faz que o projeto seja norteado pela eficácia e não somente pela eficiência.

Para muitos o que foi dito é óbvio, mas penso que estamos a evoluir para explorar a potencialidade do Gerenciamento de Projetos de forma completa. E no dia que isso acontecer, teremos organizações melhores e mais adequadas ao mundo atual.

Entretanto, o caminho da eficácia é longo, mas, possível!

Até a próxima!

Referências:

A TI é o foco? Cuidado ao responder.

2 Set

Não restam dúvidas que a área de tecnologia da informação (TI) é dinâmica e de vanguarda. E por isso, gostaria de compartilhar uma inquietude: se estamos envolvidos em uma área que olha sempre pra frente, que precisa a todo instante de recursos financeiros e ao mesmo tempo não gosta de ser identificada com uma área que consume muito pra pouco, então porque as estruturas de TI são semelhantes (para não dizer idênticas) a de outros setores, como contabilidade, RH, financeiro, etc.?

Antes de olharmos para metodologias e frameworks de governança, como ITIL e CoBiT, é necessário dizer qual será o posicionamento da TI frente às outras unidades de negócio da organização.

Basicamente: ela será descentralizada ou centralizada?

Isto é algo que realmente importa. Definir como a TI está situada dentro da empresa é fundamental. Acredito que muito se gasta com a TI por ela não ter o posicionamento correto. Ou seja, o modelo de outras unidades não serve para a TI!

Geralmente, os profissionais de TI e, especialmente, os Gerentes de Projetos, relacionam-se com pessoas de diversas áreas de conhecimento, principalmente por que precisamos entender o que e como fazem, para então propormos a melhor solução.

Isso traz a nossa área uma característica muito, mas muito especial: ela tem os profissionais que entendem como as unidades de negócio da empresa trabalham e como elas podem se integrar. A TI não é  fim nela mesmo. Engana-se o profissional que acha que isso é diferente.

Como consequência disso…Nós conhecemos os processos, melhor de que qualquer um! Isto é um fato!

Bom, mas o que isso tem haver com que coloco sobre a TI ser o foco?

Dizer que a TI é suporte parece ser simples, não é? E você com certeza já escutou isso em várias palestras, seminários, programas de auditório, entre outros meios…

Então, se somos meio, porque centralizamos a nossa gestão?

Onde quero chegar com essa conversa: os clientes conhecem do seu negócio e nós conhecemos os caminhos para que eles produzam de maneira mais eficaz e eficiente. Sendo assim, porque cada unidade de negócio não ter sua equipe de TI dedicada?!

Evidente que esta teoria não é minha. Muitos autores já propõe um modelo descentralizado de TI. Antes realmente achava essa ideia absurda, mas atualmente vejo que ela pode ser a saída.

Muitos Gerentes de Projetos tem o sonho de trabalhar em uma estrutura totalmente projetizada, acham que este é o caminho do sucesso. Mas sabemos as desvantagens que este tipo de estrutura pode trazer.

Estas mesmas desvantagens, como: perda de conhecimento, alto custo com equipes, dificuldade em se ter padrões e integrar soluções, desmotivação da equipe, etc. também acontecerão se a TI for descentralizada.

No entanto, pense comigo: se focamos nas unidades que tem prioridade de orçamento e projetos, consequentemente, a empresa, no sentido global, alcançará os resultados de maneira mais rápida e com maior qualidade. Com a TI não deve haver intermediários. A TI é meio, certo?! Não se pode ter uma estrutura totalmente funcional para a organização da TI.

Por mais que isso possa parecer subversivo, a ideia tem que ser discutida. Dê para cada unidade de negócio a sua equipe de TI. As reclamações que somos inoperantes vão diminuir sensivelmente. Indo além: os responsáveis pelas áreas que atualmente só demandam, passam a ser responsáveis pelo sucesso ou fracasso da equipe e do projeto. Para mim isso é fundamental!

E nós como ficamos?

Os gerentes de projetos, com o apoio de um PMO, será o elo entre a operação e a gestão de TI.

Por falar em gestão de TI, ela deve estar preocupada com:

  • Metodologias;
  • Padrões e padronização;
  • Integração;
  • Estabelecimento de políticas;
  • Acompanhamento de portfólio;
  • Suporte;
  • Busca por novas tecnologias, pesquisa…; e
  • Desenvolvimento humano.

Indo um pouco além, penso que nem sobre o investimento a Gestão de TI deverá ser responsável. A organização, neste caso, contará com um BELO de um PLANEJAMENTO ESTRATÉGICO que alinhe as unidades e direcione os recursos. Por isso, a organização será responsável pelo investimento e não um ou outro gestor.

Alerto para que isso não deva ser interpretado com um sonho, mas sim com uma premissa! Planejamento é obrigação e não acessório.

Para finalizar, recentemente li um artigo sobre “quais os três cargos de TI que devem sobreviver no futuro” e pensei: a TI descentralizada está cada vez mais próxima, ou melhor, já é uma realidade!

Se você tem uma opinião diferente ou concorda comigo, opine!!!

Abraços e até a próxima!

———————————————————————–

Sobre este assunto visite:

http://www.malima.com.br/article_read.asp?id=634

http://blog.opus-software.com.br/?p=170

http://olhardigital.uol.com.br/negocios/digital_news/noticias/quais_os_3_cargos_de_ti_que_devem_sobreviver_no_futuro

http://www.bain.com/bainweb/PDFs/cms/Public/Voce_tem_organizacao_de_ti_certa_Portuguese.pdf

http://www.tiespecialistas.com.br/2011/01/repensando-ti-na-estrutura-organizacional/

Imagem retirada de:

http://promoview.com.br/artigos-e-cronicas/131368-um-show-no-atendimento-por-paulo-araujo/

Comece seu projeto pelo inicio!

13 Jun

O título parece ser  redundante?   Só parece  …. e você vai compreender o porquê (se você continuar lendo, claro!)

Por incrível que pareça começar o projeto pelo seu inicio é muitas vezes uma tarefa árdua, e o pior… em diversas situações este fato (de iniciar pelo inicio) é totalmente negligenciado por nós e pelos patrocinadores do projeto. O agravante para nós é que aceitamos a “imposição” do “execute já!“, sem muitas vezes argumentar.

Por isso, o que quero mostrar a você neste post é a importância do pré-projeto. Espero que ao final da leitura você se sinta motivado a mobilizar os principais interessados do projeto para que deem a ênfase necessária a esta fase.

Veja algumas interessantes definições sobre os processos de iniciação, segundo o guia PMBOK v4:

  • “o uso do processo de iniciação no início de cada fase ajuda a manter o foco do projeto na necessidade empresarial para o qual o mesmo foi criado”
  • “os processos de iniciação podem ser executados por processos organizacionais, de programas ou portfólios externos ao escopo de controle do projeto.”

Veja o exemplo que é dado no guia:

  •  antes de iniciar um projeto, a necessidade de requisitos de alto nível pode ser documentada como parte de uma iniciativa organizacional maior.”

Só este exemplo contextualiza tudo que penso sobre a importância de um início bem realizado!

Mas apresento algumas atividades, que se você fizer, aumentará as chances de sucesso do projeto:

  • Primeiro: identificar staekholders tenha parceiros, gere comprometimento!
  • Segundo: mapear a origem da demanda do projeto – compreenda a necessidade do negócio e dê importância aos objetivos estratégicos.
  • Terceiro: realizar uma análise de viabilidade técnica para implantar o projeto – será se é possível fazer o que estão querendo? O custo de pesquisa não será maior do que o retorno do produto final?

Algo que sempre procuro realizar quando vou fazer um projeto, seja ele de qual tipo for, é questionar sobre como planejar alguma coisa, se:

Eu não sei o que querem,

Eu não sei quem são as pessoas que querem e para quê querem,

E se é possível ser feito.

A fase de iniciação e os processos que a suportam servem exatamente pra isso: levantar todas as informações necessárias para iniciar o projeto, ou seja, preparar o terreno para dar o passo seguinte –  planejamento do projeto.

Bom, e o Termo de Abertura do Projeto?

Para quem faz a prova de certificação PMP sabe que a coisa mais importante  – para efeitos de prova – do Termo de Abertura é a FORMALIZAÇÃO da indicação do Gerente de Projetos para o projeto. Até considero isso uma premissa. Mas o problema neste posicionamento é que, ao meu ver,  restringe o  valor ao Termo de Abertura do projeto.

Explico:

Novamente citando o guia, “o Termo de Abertura é o documento que formalmente autoriza um projeto ou uma fase e a documentação dos requisitos iniciais que satisfaçam as necessidades e expectativas das partes interessadas.”

Veja como o pré-projeto é importante!

Este termo, depois de preenchido e assinado, é que vai demonstrar todo o entendimento prévio daquilo que se consolidou da pesquisa inicial sobre o projeto.

Mas aí vem a pergunta: quem é o responsável por coletar todas as informações a serem consolidadas para se autorizar o projeto, já que não se tem, AINDA, um gerente de projetos formalizado para isso?

Antes, vamos combinar uma coisa: nem tudo é responsabilidade do gerente de projetos, ok?

Lembro que: só há gerente de projetos se houver projeto e eu estou falando de uma etapa que antecede ao projeto.

Para isso, nada mais justo que o patrocinador – apoiado por perfis estratégicos e técnicos – ou um comitê levante essas informações. Deste comitê não poderia sair o GP do projeto? Em minha opinião, sim!

O que pretendo mostrar a você é que o planejamento do projeto é fundamental, não restam dúvidas! Só que, tão fundamental quanto o planejamento é saber o que planejar.

Este é o principal objetivo do pré-projeto. É neste período que os objetivos principais são definidos. O planejamento deve estar voltado a viabilizar o alcance destes objetivos. O erro, geralmente cometido, está no fato do planejamento ser realizado “apenas” para viabilizar a execução do projeto.

O planejamento não é algo solto, ele tem origem… a fase de iniciação. É nesta fase que o planejamento, mesmo que indiretamente, se inicia.

Aí vem a questão do primeiro parágrafo: iniciar um projeto já com a indicação do gerente de projetos e a ele apenas fornecer as restrições de prazo e custo, além de uma visão bem mais ou menos do escopo é o correto?

Muitas vezes é assim que um projeto inicia. Não pelo começo, mas pelo meio ou pelo fim…

Talvez você já tenha vivido a experiência do “patrocinador” dizer: “execute! Você foi escolhido porque acreditamos em seu trabalho!”.

A questão não é acreditar ou não no trabalho de alguém, mas sim de possuirmos informações suficientes para atingir aos objetivos propostos.

Muitos projetos fracassam ou gastam mais tempo que o necessário com o planejamento porque não se tem as questões preliminares básicas respondidas.

Para finalizar, pense sempre e indague seus “admiradores” sobre as questões abaixo:

  • Existe um plano maior de onde originou a demanda para este projeto?
  • Por que querem (área, gerente, presidente, empresa) o projeto?
  • Quais os objetivos e metas que se pretendem alcançar com este projeto?
  • O que realmente pensam que deve ser produzido? Qual o resultado que esperam?
  • Há viabilidade técnica de se fazer o que querem?
  • Quem é a comunidade impactada pelo projeto? (nunca se esqueça disso)
  • Quem está interessado neste projeto? (nunca se esqueça disso)
  • Qual o resultado financeiro que se espera com o projeto? (muito importante!)

Respondidas essas perguntas, vamos iniciar o projeto. Bem-vinda a fase de planejamento!

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!

%d bloggers like this: