Gerente de Projetos e Scrum Master: Sinônimos ou papéis diferentes?
Uma das polêmicas do mundo ágil é em relação à constante comparação entre as funções desempenhadas por um Scrum Master e por um gerente de projetos. São o mesmo profissional ou não? Há espaço para os dois? O Scrum Master é um gerente de projeto ágil? Confira.
Com o advento das metodologias ágeis, torna-se necessário conhecer os papéis e responsabilidades presentes na metodologia. No caso do Scrum, por exemplo, um dos pontos de maior polêmica é o papel desempenhado pelo Scrum Master, que muitas vezes acaba sendo comparado a um tradicional gerente de projetos.
Leia mais no blog: Causas de fracassos em projetos de TI e como as metodologias ágeis poderiam ajudar
O que pensam os agilistas?
Alexandre Magno em seu blog afirma que o papel do Scrum Master está distante do comando e controle, tantos vistos nos gerentes de projetos tradicionais. Segundo ele, o Scrum Master deve incentivar o auto-gerenciamento do time, garantir os caminhos abertos para a comunicação do time (porém, essa também é uma atribuição de um GP), garantir e o auxiliar o time a seguir as práticas do Scrum (um GP tradicional também deve garantir a utilização de métodos e processos), dentre outras. Esta opinião também é compartilhada por Flavio Steffens, no Agile Way. Ele indica que o Scrum Master e Gerente de Projetos são dois conceitos diferentes. De um lado, tem-se o Scrum Master como facilitador do projeto e, de outro lado, o gerente de projetos responsável por gerir o projeto, às vezes abrindo mão do perfil facilitador. Confesso que este ponto me confundiu um pouco, uma vez que o perfil do gerente de projeto também deve assumir um papel de facilitar a execução do projeto, criando meios para que ele seja executado a contento.
Carlos Santos sugere que o papel de GP seja dividido em gerente de pessoas e gerente de produto. Segundo Carlos, o Scrum Master é um líder de pessoas capaz de fazer o processo funcionar de acordo com as regras do framework. Há quem diga, inclusive, que o papel do Scrum Master não é designar tarefas aos desenvolvedores. Seu papel é fazer com que o Scrum “funcione”. Para que esta afirmação seja verdade, é verdade ter 100% da equipe auto-gerenciável. Na prática, sabemos que isso muitas vezes está longe de ser realidade. Talvez essa seja a maior diferença entre as duas funções.
Por outro lado, Mark Levison, no artigo Can Product Owner and Scrum Master be combined? da InfoQ, afirma que “o papel de um Scrum Master normalmente é preenchido por um gerente de projetos” (tradução livre). A mesma opinião é compartilhada pelo Vinícius Teles, ao afirmar em seu blog que “o papel de Scrum Master é tipicamente exercido por um gerente de projeto”.
Leia mais no blog: Os 10 mandamentos do gerente de projetos
E o que pensam os gerentes de projetos tradicionais?
Para colher essa informação, nada melhor do que visitar o site do próprio PMI. Lá, encontrei um artigo escrito por Lisa A. Grant que, além de PMP (Project Manager Professional), é também CSM (Certified Scrum Master). No artigo, Grant afirma que não é possível comparar as funções, uma vez que o Scrum somente é utilizado para desenvolvimento de software. Neste ponto, preciso discordar pois, embora o Scrum tenha sido desenhado inicialmente para software, hoje já vemos casos de sua utilização em outras áreas. Basicamente, a justificativa de Grant está na parte técnica: enquanto o Scrum Master precisa ser técnico para remover os impedimentos técnicos que podem surgir, o gerente de projetos pode ser um generalista. Por outro lado, a autora indica que uma mesma pessoa, se bem trabalhada, poderá desempenhar ambos os papéis.
Leia mais no blog: Prepare-se: Novas certificações Scrum
Conclusões
Ao meu ver, não é possível em equipes de software termos duas pessoas desempenhando papéis similares. Acredito que precise haver uma mudança cultural (como de praxe no Scrum) a fim de sensibilizar os gerentes de projetos tradicionais a se adaptarem aos requisitos de um Scrum Master. Resumindo, embora as atividades sejam diferentes, considero razoável que uma mesma pessoa ocupe o papel de GP e de Scrum Master.
Leia mais no blog: Scrum: modelo, framework ou metodologia?
Uma vez escutei que uma das maiores virtudes de um líder é fazer com que seu time compre suas ideias sem que você as precise impor. O que quero dizer com isso? O gerente não deve largar seu lado controlador, mas as atividades ligadas ao controle e a monitoria devem ser feitas dando o apoio ao time, e não simplesmente controlando. É preciso estar do lado das pessoas e ensiná-las que o controle é necessário, e não para punir.
Afinal, gerenciar é também educar…
PARTICIPE!
E para você, o gerente de projetos tradicional e o Scrum Master possuem as mesmas funções? Uma pessoa pode ocupar ambos os papéis? Dê sua opinião!
Aproveite e continue lendo outros conteúdos relacionados:
- Mudanças na certificação Scrum Master (CSM)
- Os 10 Mandamentos do Gerente de Projetos
- O papel do gerente em times ágeis
- O lado humano do SCRUM
- Prepare-se: Novas certificações Scrum
Tags:Carreira, desenvolvimento de software, gerenciamento de projetos, metodos ageis
Home
Página inicial
Adicionar aos favoritos
RSS
13 comentários
Isso me lembra aquele teste proposto pelo Alexandre Magno… em par, o da frente só pode dar o próximo passo, transpondo os obstáculos, quando o outro fala para que lado seguir; no segundo teste, o da frente dá o próximo passo rumo ao objetivo, pelo lado que ele achar mais confortável, acompanhado pelo outro. A impressão e ojeriza pelos GPs se caracteriza pela imposição, não que isso seja regra.
Tantan,
Um GP não se caracteriza pela imposição. Os que agem dessa forma, tendem ao fracasso.
Ambos os papéis devem ter foco facilitador, a diferença é que o GP, além de facilitar, deve controlar, gerenciar, monitorar etc…
A dúvida é: se o papel de facilitador do GP for bem feito, existe a necessidade de controlar? O que você acha?
Rafael, vou um pouco mais longe nesse seu questionamento. Ambos, gerente de projetos e scrum master exercem papéis e funções complementares, todavia em momento históricos diferentes. O GP nasceu há tempos atrás com exigênicas processuais. O SM nasceu agora, ou melhor, ainda está nascendo. Portanto, traçar um comparativo entre ambos é desigual. O ideal é dizer para o GP aumentar seu angulo de visão e, dizer para o SM que a velocidade do seu comportamento precisa acompanhar a maturidade das pessoas. SM, na minha visão, é uma evolução do comportamento fuzileiro do GP.
Gonzatto,
Como sempre suas participações são de alto nível.
Eu adaptaria uma de suas frases para "dizer para o SM que a velocidade do seu comportamento precisa acompanhar a maturidade das pessoas, processos e métodos". O que acha?
Acho ótimo
O detalhe é que o método é o mesmo. Em síntese observo uma discrepancia, comparar o GP ao SM, são ambientes e momentos divergentes. Manda bala companheiro!
Gonzatto,
A comparação só se faz necessária pois, apesar de ambientes e momentos divergentes:
- eles representam um papel de liderança dentro da equipe;
- o produto final é o mesmo: algo entregável para o cliente no prazo, dentro do custo, respeitando o escopo definido e com a qualidade desejada.
O "gerente de projetos" é um papel batido no liquidificador e salpicado por todos os papeis do Scrum.
O Product Owner faz gerenciamento de projetos pensando principalmente no macrogerenciamento e visão de negócio.
A Equipe faz principalmente o microgerenciamento, identificando riscos, estimando, planejando atividades, etc.
Por fim o ScrumMaster precisa cuidar para que o Scrum funcione. Ou seja, é responsável por negociação/facilitação junto ao cliente, promover comunicação, cuidar dos impedimentos (há até um debate se impedimentos são riscos, mas é outra coisa) e garantir o fechamento do ciclo PDCA promovendo o bom funcionamento das cerimônias do Scrum.
Agora o mais legal disso tudo é que são recomendações, não leis. Ou seja, é preciso experimentar para decidir o que se enquadra melhor em cada equipe em cada caso. Nenhum case de desenvolvimento de software é igual a outro. Pode-se orientar, mas só quem pode afirmar categoricamente o que é certo e errado na sua equipe são os "porcos" que dela participam.
Marcelo,
Você tem razão. Inclusive, é interessante o ponto onde você diz que o fechamento do ciclo PDCA é de responsabilidade do ScrumMaster. Ou seja, neste ponto, ambos desempenham o mesmo papel e possuem a mesma responsabilidade.
O que você acha?
Senhores,
Um detalhe que senti falta em todos os comentários, não discordando de ninguém, mas que diferencia a resposta ao tema principal (GP e SM: Sinônimos ou papéis diferentes?); é que existe uma variável a ser considerada: "O projeto".
Certamente a complexidade e/ou dimensão do projeto justifica a necessidade de se envolver uma ou duas pessoas para assumir estes papéis.
Claro que a capacidade pessoal diferencia a perspectiva de dimensão do projeto, mas certamente ambos profissionais podem conviver em sintonia, sincronizando suas ações – coabitando-se e otimizando suas ações – e isso, sim! Pode ser feito por uma única pessoa, ou não… rs.
Excelentes observações, continuem…
Narciso,
Discordo um pouco de você. O Scrum não cita em nenhum momento a figura do gerente de projetos.
Em projetos maiores, talvez o ideal fosse existir mais de uma equipe utilizando o Scrum. O famoso "Scrum de scrum". Você conhece?
[...] This post was mentioned on Twitter by Gustavo Perdigão and MCP Tecnologia, Cantinho do Agile. Cantinho do Agile said: Gerente de Projetos e Scrum Master: Sinônimos ou papéis diferentes? | Gestão etc http://t.co/E6SAAuO via @rsouzaramos [...]
Rafael,
Gosto desce tema. E acabei no inicio do ano em varioas questionamento sobre, mas vou focar em um que Marcelo citou. Fechar o Ciclo PDCA.
Acho que primeira diferenca e qual tipo de projeto? Em projetos de softwares vem sendo muito utilizada, mas na gerencia o clico de vida(ALM), que consequentemente e “englobado” pela gestao de projeto, programas e portfolio. Lembrei de um experiencia que tive numa pequena software-house que estava estruturando, onde estabelcemos um modelos de interacao, entre “gp” e “scrum”(mas que para os envolvidos estava transparente) ate que durante a execucao percebemos um coisa, que falo a muiiito tempo e que algum tempo vi o Ricardo Vargas falando, se tivesse CNTP para executar esse processo, seja ele scrum, pmi, prince2 vai rodar. Mas isso e um tanto utopico. Foi que descobrimos que nossa equipe nao maturidade de auto-gerencia, estou falando de projeto de TI, onde devido a demanda rapida e escassez de mercado minha equipe tinha uma media de idade de 20 anos. Enfim, considero um boa premissa, o tipo de projeto e diferenciar ciclo de vida de produtos e gp.
Parabens Rafael.
Eduardo,
Você tem toda razão. O importante é sempre identificar o tipo de projeto antes de afirmarmos que algo é melhor que outro.
Inclusive, estou planejando um artigo sobre essa radicalidade de quem pratica agile. Ao meu ver, isso não é bom.
Grande abraço.
Deixe seu comentário