Uma das discussões mais acaloradas quando se fala em gerenciamento de projetos que usam metodologias ágeis é sobre as atribuições e responsabilidades do Gerente de Projetos.
Tenho visto muitas discussões com pontos de vista interessantes e razoáveis, outras com argumentos que beiram o fanatismo, já que a grande a questão que suscita tanta polêmica é sobre a necessidade ou não de um Gerente de Projetos em projetos desse gênero. Os argumento de quem defende a não existência de um Gerente de Projetos são vários: o time é auto-gerenciável, o Scrum Master ajuda a remover os impedimentos, os requisitos a serem entregues são aqueles priorizados pelo cliente, e por aí vai…
No entanto entendo que a participação de um Gerente de Projetos possa contribuir muito para o projeto, uma vez que um maior controle na gestão do mesmo se traduz em eficiência e efetividade. Além disso, o gerente de projetos vai se concentrar em itens que nem sempre o time ou o Scrum Master podem ou tem condições de cumprir, tais como:
- controle de alocação dos recursos;
- gestão de riscos, comunicação e contratos;
- interface com clientes internos e externos;
- responsabilidade formal pelo projeto junto à gerência executiva;
- alinhamento do projeto à direção estratégica da empresa.
Eu vejo pelo menos três papéis diferentes que o Gerente de Projetos pode desempenhar em um projeto com metodologia ágil:
- Gerente de Projetos é o Scrum Master
Nesse caso, além das atividades relacionadas ao gerenciamento do projeto em si, o gerente de projetos desempenha o papel do Scrum Master no time. Indicado para projetos menores ou menos complexos (menores que 4 sprints, ou menos de 1000 homem-horas, etc.), com a vantagem de aproximar e dar visibilidade ao GP das atividades desenvolvidas no dia-a-dia do projeto. Exige uma maior alocação do GP, pois a dedicação a todos os aspectos do projeto deve ser considerada.
- Gerente de Projetos é o Product Owner
Indicado para projetos maiores em que o cliente não esteja diretamente envolvido na execução do projeto. O Gerente de Projetos tem o controle do backlog e, através da interface com os stakeholders, prioriza os itens a serem entregues. A vantagem dessa configuração é que o Gerente de Projetos pode dar o viés necessário ao projeto para que ele se alinhe aos objetivos estratégicos da empresa.
- Gerente de Projetos não desempenha nenhum dos papéis do Scrum
Mesma situação anterior, mas com um cliente exercendo papel ativo como Product Owner. Indicado para projetos estratégicos, muito grandes ou muito complexos, onde o gerente de projetos se concentra na gestão dos stakeholders e aspectos administrativos e de controle do projeto.
Independente da configuração utilizada a presença de um Gerente de Projetos sempre vai contribuir para um melhor desempenho do projeto em si através da adoção de métodos eficazes de planejamento e controle.
Gerenciamento Estratégico 
Concordo que há muito fanatismo quando se fala em Agile. Ainda vai ser preciso derrubar muitos mitos.
Não é verdade que no Scrum não há gerente de projetos. Quem diz isso não leu o primeiro parágrafo do capítulo 3 do célebre livro do Ken Schwaber, Agile Project Management with Scrum:
“Why did I choose a strange name like “ScrumMaster” for the person who facilitates Scrum projects? Why didn’t I continue to use the standard title “project manager”? I wanted to highlight the extent to which the responsibilities of the ScrumMaster are different from those of a traditional project manager. This difference in terminology is symbolic of a drastic change managers must make to their approach if they are to effectively manage Scrum projects.”
Estou totalmente de acordo que é necessário uma mudança de postura do gerente de projetos, mas essa mudança não é exclusividade do Scrum–Livros como O Monge e O Executivo também mostram essa necessidade. Aliás, eu acho que mudanças de nome de coisas já conhecidas é um dos pontos fracos do Scrum. Em vez de aprimorar e evoluir os conceitos já existentes tenta-se destruir tudo o que existe para construir algo “novo”. Desperdício!
Se o Scrum Master é o gerente do projeto as duas outras possibilidades acabam sendo invalidadas, ou quase. É comum o GP/SM assumir funções de Product Owner. O mesmo Ken Schwaber diz na página 6 do seu Guia Scrum (versão em português): “O ScrumMaster trabalha com os clientes e a gerência para identificar e designar um Product Owner. O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que eles saibam como conseguir otimizar valor através do Scrum. Se eles não souberem, consideramos o ScrumMaster responsável.”. Tá, isso contradiz o que o próprio guia fala (“O ScrumMaster nunca deve ser o Product Owner.”), acho difícil ter responsabilidade de PO sem ser PO, mas é essa a idéia.
A terceira possibilidade também é válida mas vendo por um outro ângulo. É normal e previsto no PMBOK que projetos de grande porte se dividam em subprojetos. Neste caso o gerente do subprojeto/Scrum Master irá responder para o gerente do projeto, que por sua vez irá coordenar todas as interdependências entre os subprojetos, provavelmente em áreas diferentes. Mas o Scrum Master ainda é um GP.
Pode ser um perigo ter um profissional apenas treinado em Scrum (16 horas) à frente de um projeto. Esse risco é compensado pela recomendação popular de apenas rodar Scrum em projetos pequenos. Aí fica fácil! Mas se os projetos crescem em porte e desafio isso é insuficiente, eles irão exigir profissionais com maior senioridade e maior capacitação que executem de forma eficiente todas as atividades de gerenciamento de projetos, incluindo aí os ítens citados no artigo.
Oi Renato,
Antes de mais nada, obrigado pelo comentário.
Concordo com seu ponto de vista sobre o papel do Scrum Master, ele é responsável por manter o projeto nos trilhos. No entanto eu acho um pouco arriscado fazer uma relação direta entre o SM e GP, uma vez que o papel de Scrum Master pode ser representado por qualquer membro do time (que tenha o treinamento de 16 horas que você menciona). Como o GP tem a responsabilidade formal pelo projeto eu defendo que ele deve ser um profissional capacitado para tanto, com formação e experiência compatíveis com a responsabilidade a ele apresentada.
Em meus projetos eu já atuei como SM, como PO, e como SM e PO ao mesmo tempo, e conheço pessoas que gerenciaram projetos maiores sem desempenhar nenhum dos papés (cujos subprojetos foram gerenciados por SMs). A maior diferença, na minha opinião, é o quão envolvido na execução você vai estar. o Scrum Master está envolvido nas decisões técnicas e problemas que afetam o dia-a-dia do projeto, isso é possível em projetos menores mas seria muito complicado em projetos de maior volume. Por esse motivo eu mencionei a possibilidade de o GP desempenhar o papel do PO como forma de representar os “olhos” do cliente no projeto.
Abraço,
Eamon
De qualquer forma
Bom seu post… simples e direto.
Pessoal que costuma se dizer “agilista” é bastante contra a existência do papel de gerente de projetos. Chegando a dizer que se você possui um GP na equipe então não pode ser ágil (?)
Se a equipe é interna a figura pode até ser substituída totalmente pelo Scrum Master. Quando se fala em ambiente de outsourcing e/ou fábrica de software, eu acho a atuação de um gerente de projetos muito bem-vinda.
Em um time ágil, o GP assume funções que não devem ser de responsabilidade do time, como: Gestão financeira, comunicação executiva com o cliente, gestão do portfólio de projetos, etc.
O que o cara deve separar muito bem é apenas a questão do “comando-controle”. Em um ambiente ágil esse tipo de postura não cola. O cara vai precisar aprender a não querer centralizar tudo e tomar decisões sozinho.
Mas isso não é nem o caso de ser ágil ou não. É importante que o GP tenha o perfil de líder. Se o cara tem esse perfil conseguirá trabalhar com um time ágil facilmente e vai ajudar muito.
Abs
André Nascimento
Oi André,
Eu acho que as duas “tribos” conseguem conviver bem, só é preciso um pouco de boa vontade 🙂
Você tocou no ponto certo, certas atividades são de responsabilidade do Gerente de Projetos e seria complicado alguém no time desempenhar essas funções. Se paralelamente às suas responsabilidades o GP desempenha o papel de SM ou PO é só uma questão de configuração do time, e isso varia de projeto para projeto…
Só devemos ter o cuidado de evitar os pré-conceitos, no fundo esses são os desafios do gerenciamento.
Abraço,
Eamon
Time multi-funcionais possuem capacidade para fazer tudo que é necessário para o projeto. Se há burocracias e gargalos organizacionais a serem cumpridos alguém faz isso. Sim, pode ser um GP.
* controle de alocação dos recursos;
Equipes alocadas não precisam disso…
* gestão de riscos, comunicação e contratos;
Se a gestão de riscos e comunicação não estiver com a equipe é algo muito ruim.
* interface com clientes internos e externos;
Gerente proxy é uma aberração para métodos ágeis. Conversa face a face deve ser prioridade.
* responsabilidade formal pelo projeto junto à gerência executiva;
A equipe é responsável, sob todos os aspectos. Desenvolvedores não são crianças.
* alinhamento do projeto à direção estratégica da empresa.
O Product Owner deve ter esse alinhamento. Se ele não tiver nada poderá salvar o projeto…
Agile não é só Scrum. O fato de não ter Gerente de Projetos não significa que não há Gestão. No Scrum a gestão está lá… só não existe um papel central como GP.
Oi Rodrigo,
Minha visão é um pouco diferente da sua, eu não acho que o GP vai ser simplesmente um gestor de “burocracias e gargalos operacionais”, e sim um facilitador para que o time possa desempenhar seu papel. Se isso inclui o exercício dessas interfaces ou não, depende de cada empresa e projeto, e faz parte do trabalho – alguém tem de fazer…
Como eu mencionei no post, muitas vezes o time ou o Scrum Master não tem condições de assumir algumas das responsabilidades no projeto, então alguém deve fazer isso. Se o GP desempenha o papel de SM ou PO entendo que a responsabilidade seja dele e pronto, problema resolvido. No entanto, casa não haja pessoas com as “habilidades” (corro o risco de ser mal interpretado pela escolha da palavra, mas não achei outra melhor) necessárias no time essa necessidade vai ter de ser suprida por alguém, que é a situação descrita no terceiro bullet. Por exemplo, conheço excelentes Scrum Masters que não tem o menor desejo de cuidar do controle financeiros do projeto…
Só para manter a discussão fluindo seguem meus comentários sobre as suas ponderações:
* controle de alocação dos recursos;
Equipes alocadas não precisam disso…
[Eamon] OK, se assumirmos que sempre teremos uma equipe “fixa” para desenvolvimento de projetos. No entanto, a maioria das empresas que eu conheço usam uma estrutura matricial e os recursos são alocados para os projetos (infelizmente, muitas vezes em mais de um projeto), e toda essa negociação tem de ser feita por alguém (normalmente o GP).
* gestão de riscos, comunicação e contratos;
Se a gestão de riscos e comunicação não estiver com a equipe é algo muito ruim.
[Eamon] OK para gestão de riscos, mas alguns aspectos da comunicação tem de estar centrada em alguém (emissão de relatórios de progresso, por exemplo). O mesmo vale para a gestão de contratos.
* interface com clientes internos e externos;
Gerente proxy é uma aberração para métodos ágeis. Conversa face a face deve ser prioridade.
[Eamon] A idéia aqui não é um gerente proxy, e sim alguém que tem a visibilidade e propriedade para fazer essas interfaces: talvez um membro do time não possa fornecer o tipo de informações que um diretor executivo necessita para medir o retorno financeiro do projeto, só para citar um exemplo.
* responsabilidade formal pelo projeto junto à gerência executiva;
A equipe é responsável, sob todos os aspectos. Desenvolvedores não são crianças.
[Eamon] Concordo com sua colocação, mas meu ponto é que alguém tem que se responsabilizar pelo todo, não apenas pelo entregável. É a velha história de que cachorro com muitos donos morre de fome…
* alinhamento do projeto à direção estratégica da empresa.
O Product Owner deve ter esse alinhamento. Se ele não tiver nada poderá salvar o projeto…
[Eamon] Concordo parcialmente. O PO deveria dar ter esse alinhamento, mas muitas vezes ele acaba mais orientado à estratégia do projeto. Minha idéia aqui é a de alguém que consegue interpretar a estratégia da empresa e influenciar o projeto para que esse venha a ajudar a empresa a atingir seu objetivo. Pode ser o SM, pode ser o PO, ou mesmo um membro do time …
Abarço,
Eamon
Concordo com o Eamon, desculpe Rodrigo.
Vou contar minha estória, afinal nada como casos reais para ilustrar certas coisas.
Vamos aos fatos;Sou gp PMP.Estamos implantando Scrum em nossa empresa.Somos uma software house.
O início do processo de implantação foi muito bacana, pois vimos claramente que pra execução os nossos tempos de entrega e qualidade deram um salto enorme.
O cliente adorou.
A equipe então nem se fala…era o fim dos chefes, agora ela tem o poder.O PMBOK é atrasado, etc…Foi bem interessante ver a mudança de comportamento.Algo beirando o hilário devo dizer.
Pois muito bem, foram formados vários times para diversos projectos.
O Cliente sempre era o mesmo.OK.
Faz parte do projeto as reuniões com uma comissão do cliente que avalia o andamento dos projetos e faz considerações.
O cliente estava habituado a figura de dois ou três gestores nestas apresentações.Isto foi substituido por reuniões com o product owner e o scrum master junto do cliente.
O resultado foi uma catástrofe.Ao serem questionados sobre alguns pontos quem não eram do seu domínio, como contratos, riscos, questões legais, formatos de comunicação ou mesmo uma correção na gramática da apresentação, os desenvolvedores perdiam a cabeça,gaguejavam, se enrolavam , em resumo, o cliente esmagava-os como baratas.
A questão da colaboração em relações cliente-empresa terceira, é muito delicada.O cliente colaborador,prestativo,etc., se torna egoísta e manipulativo quando se trata de pagar mais, ou ter que se explicar para um superior porque uma funcionalidade não entrou no sprint da semana ou mesmo no product backlog.Para o cliente ou PO no nosso caso dizer ao seu superior (estrutura matricial) que precisa de mais dinheiro para terminar o projecto porque surgiram idéias legais no projeto é um problema e eles com certeza atacam o lado mais fraco.O fornecedor.
Porém defendo fortemente o uso de scrum em ambiente de manutenção.Acho também que o scrum não pode ser desvirtuado , como tenho visto aqui.
Devemos usar o que ele tem de melhor, a colaboração,espirito de equipe, entregas mais curtas e mudanças mais flexíveis.
Mas achar que desenvolvimento de software é só isto, é a certeza de muitos problemas pela frente.
Sou favorável da idéia de usar o melhor de dois mundos, sem que sejam desvirtuados valores.
Usar scrum para geram como product um documento,tela,layout ou algo assim, pra mim é uma heresia…o princípio : entregue algo funcionando, palpável…
Enfim defendo o uso de ambos , mas sempre me interessa o milagre e não o nome do santo.
Oi André,
Muito obrigado por ilustrar a discussão com sua estória…
Eu concordo plenamente com você, devemos usar o melhor dos dois mundos para conseguir sempre o melhor resultado. O que serve para você talvez não sirva pra mim, mas se isso fizer com que seus projetos corram melhor eu não vejo por quê não deva ser usado.
Abraço,
Eamon