Hoje em dia ainda vejo empresas tratando o gerenciamento de projetos como algo engessado, como algo tradicional e com restrições.

• Se você não utilizar tal metodologia não vai dar certo.
• Se você não for certificado não vai conseguir.
• Se você não seguir o que os especialistas falam não vai conseguir.

Que visão é essa?

Gerir projetos é muto mais do que metodologia.

Atualmente gerencio projetos em uma empresa da área de TI, onde aplico o que funciona!

Aplico o que minha equipe necessita, o que meu cliente precisa para ter os melhores resultados.

Utilizo práticas que combinam com o resultado que quero alcançar.

Gerenciar projetos é muito mais do que delegar tarefas para a equipe, gerenciar projetos é malabarismo constante de avaliação de prioridades, avaliação de recursos, prazos, riscos, resolução de problemas, entre tantas coisas que fazemos.

E quando temos a necessidade de gerenciar vários projetos ao mesmo tempo, e manter tudo alinhado, fica muito clara a necessidade da colaboração e da comunicação, alinhar equipe e interessados no projeto em busca do melhor resultado.

Gerentes de projeto não são independentes, nem fazem milagres, são totalmente dependentes do feedback das suas equipes e dos clientes. A comunicação tem papel chave nas tomadas de decisões, na identificação de riscos, na aprovação de solicitações.

Use modelos, mas não esqueça que de nada adianta a melhor metodologia se não tem profissionais comprometidos com o que fazem. Metodologias não salvam projetos. Projetos são etapas que possuem inicio e fim, e precisam de profissionais envolvidos com o que fazem.

De nada adianta ter um gerente de projetos certificado em várias tecnologias, se o mesmo não consegue se comunicar com eficaz com seu time de desenvolvimento. De nada adianta ter conhecimento das melhores práticas, se na hora de por a “mão na massa” não sabe qual a melhor decisão tomar.

Antes de entrar nessa linha de gestão de projetos, só enxergava pessoas com o perfil “gerentão”, sim, aquele que pensa que manda em todo mundo e que não faz nada para o bem do seu time e da organização. Depois que tive contato com essa área, conheci várias pessoas que estão envolvidas e conseguem fazer um ótimo trabalho deixando de lado aquela velha visão de um gerente de projetos que não faz nem a metade do que promete, e que sequer se importa de verdade com as pessoas envolvidas nos projetos que gerencia.

E essa experiência firma mais minha visão, de que boas metodologias não vão te salvar, se você não souber articular, perceber as atitudes, as emoções das pessoas envolvidas, se você não sentir na pele o que sua equipe está sentindo, não vai conseguir bons resultados.

Pessoas são a chave para o sucesso. Esqueça o gerentão, e direcione o foco na sua equipe, na boa comunicação com os envolvidos, na colaboração entre as funções. Nos resultados que podem ser alcançados se você conseguir liderar de forma saudável, sem prepotência, sem arrogância, apenas sendo um líder. Onde as pessoas acreditam no que você faz, e fazem junto com você, e o melhor de tudo, gostam do que fazem.

Me arrisco a falar que se você conseguir perceber as limitações da sua equipe, perceber as necessidades, se comunicar de forma clara, e dar autonomia para o time na medida que o mesmo for adquirindo maturidade, as coisas vão dar certo.

Nessa área, onde os riscos são gigantes e as pessoas são imprevisíveis, o melhor a fazer é manter a sinergia do time, alinhar os objetivos e por a mão na massa, de verdade.

Você pode me xingar no Twitter!

Existem distintas formas de se acompanhar o andamento de um projeto. Praticamente cada modelo de gerenciamento sugere sua própria forma de seguir de perto como anda o desenvolvimento das tarefas. Gráfico de Gantt, gráfico focado em produtividade do Kanban e etc… são apenas algunas exemplos do que é utilizado hoje no acompanhamento de projetos em TI. Acredito que a maioria dos leitores esteja acostumada e familiarizada com os gráficos de Gantt. Apesar de serem bastante difundidos e utilizados mundo afora, pessoalmente julgo que esse método de acompanhamento funciona muito bem quando o foco são datas de entrega ou planejamentos de longo prazo. Quando focamos no acompanhamento da produtividade de uma equipe no dia-a-dia, o gráfico burndown do SCRUM e o baseado na produtividade do Kanban se mostram muito mais robustos e evidentes.

Para este post, vou focar no gráfico de burndown. Neste gráfico, o eixo horizontal representa os dias de duração de uma sprint e o eixo vertical a quantidade de tarefas que ainda não foram cumpridas dentro do espaço de tempo determinado. Dessa forma, todos os dias a gerência da equipe pode verificar a produtividade do dia anterior e qual a meta que precisa ser alcançada para que todas as tarefas que ainda restam consigam ser finalizadas no prazo.

Acredito que a maior dificuldade para a equipe de gestão de um projeto SCRUM é saber interpretar os dados que lhe são mostrados no gráfico e como repassar essas informações preciosas para o product owner do projeto ou o cliente em questão. Sprint passada enfrentei um problema similar. Algumas alterações no burndown não foram bem interpretadas pelo product owner do projeto. Percebi que, apesar de atingir muito bem seu objetivo, algum tipo de informação relevante estava faltando ali. É como se a informação estivesse na frente dos nossos olhos, mas a nossa forma de pensar estivesse bloqueando o real entendimento.

Decidi então adicionar uma nova curva ao burndown. Ao invés de mostrar somente a curva da quantidade de tarefas “queimadas” durante os dias da sprint, coloquei também uma nova curva onde apresentávamos a evolução do número total de tarefas. Pode parecer estranho para alguns, mas no SCRUM as tarefas que devem ser executadas em cada iteração podem variar de acordo com a demanda. Durante uma sprint, podemos tanto remover como adicionar novas tarefas e justamente essa visibilidade foi a que senti que estava faltando no burndown do meu projeto. Uma descida mais suave no gráfico de produtividade não significa que a equipe teve uma baixa produtividade, mas sim a influência do incremento do número de tarefas a serem executadas naquele período.