O período acelerado de transformação digital fez com que muitas empresas tradicionais sentissem a necessidade de implementar uma estrutura ágil, por meio dos chamados métodos ágeis — mesmo em meio a estruturas funcionais. O Scrum é um desses métodos que, na verdade, tem muito mais a ver com uma estrutura de trabalho (framework).
Ele propõe que um projeto seja dividido em vários ciclos de atividade para gestão do desenvolvimento de produtos. O framework é formado por equipes multidisciplinares com autonomia para tomar decisões, monitorar e controlar alinhamentos.
E traz consigo papéis como Product Owner, Scrum Master, Agile Coach, entre outros, que estão sendo incorporados às equipes praticamente do dia para a noite. Resultado: um cenário de dúvidas para as áreas de RH e Remuneração.
- Como uma estrutura funcional conversa com uma matricial?
- Qual é a estrutura hierárquica a ser seguida?
- Como podemos entregar uma estrutura de pagamento para times que funcionam dessa forma? (Responderemos na parte 2/2)
- Qual é a base para a Remuneração e o pacote de benefícios? (Responderemos na parte 2/2)
Não dá para responder a essas questões sem uma análise histórica do que esses papéis representam.
O antes e o depois do Scrum Agile
Até hoje você pode desenvolver um produto com PMBOK (Project Management Body of Knowledge), só nunca deixe de considerar a aderência desse conjunto de práticas às dinâmicas contemporâneas que circundam o produto (projeto) que tem em mente. De toda forma, para o racional que queremos desenrolar aqui, temos no PMBOK o gerente de projeto como um protagonista e é nesse ponto que temos boas diferenças conceituais para o Scrum, por exemplo.
O gerente de projetos tem como responsabilidade fazer a gestão mais estratégica com os clientes, patrocinadores e stakeholders, monitorar os indicadores dos projetos, selecionar e adquirir recursos (financeiros, humanos e materiais), atender o escopo e o prazo acordados, gerenciar conflitos, comunicar decisões e resultados.
Em resumo: tem que fazer a macrogestão, a microgestão e ser responsável pelos processos. Invariavelmente, as três atribuições não tinham o mesmo peso na balança. O Scrum veio, então, com a proposta de distribuir esses papéis para equilibrar a balança e haver uma boa gestão de projetos — tentando eliminar ao máximo o conflito de interesses.
A macrogestão passou para o Product Owner (PO), profissional que representa os interesses de todos os envolvidos, define as funcionalidades do produto e as prioriza de acordo com o valor do negócio. Dirige a visão de onde querem chegar e atualiza os roadmaps. Esse papel, de forma bem simplista, quebra um grande projeto em pequenos pedaços, ordena as prioridades, mas garante que você tem condições de experimentar o produto em cada um desses pedaços que vão sendo construídos.
A microgestão ficou na própria auto-organização dos próprios desenvolvedores (responsáveis pela construção desses “pedaços” do produto que vêm como demanda do PO) e o Scrum Master entrou para monitorar o andamento do processo e o desempenho das equipes. Ele facilita os sprints, dá liberdade para os times, disponibiliza os recursos necessários, engaja a equipe, trabalha em parceria com o Product Owner e elimina empecilhos.
São esses os papéis principais em uma estrutura flexível e ágil para a gestão de projetos, que divide muito bem a função do gerente de projetos no PMBOK. Mas, é agora que você não pode se confundir entre a função e o papel:
Product Owner e Scrum Master são papéis, e não cargos!
Claro que essa é uma das leituras, compartilhada pela equipe da Carreira Muller e por Alexandre Magno, Head of Digital Transformation que trabalha desde a década de 90 com métodos ágeis e é autor de Como Tirar seu Projeto do Papel com Scrum.
Ao passo que esses papéis surgiram em meio a uma transformação, eles têm de ser flexíveis o suficiente para um escopo, considerando um ambiente complexo. Por isso, não é recomendado que eles se tornem um cargo, pois, se um dia você quiser mudar do Scrum para um outro framework, ou método, encontrará barreiras na própria estrutura de cargos (cultura), que se tornou uma estrutura rígida. Tornar papéis em cargos é acabar com a flexibilidade dessa estrutura de trabalho, já que esses papéis não têm necessariamente indivíduos fixos.
Na 85ª edição do Quinto Dia Útil, Alexandre Magno traz luz para os setores de Remuneração e RH desenvolverem suas estruturas de cargos e salários em meio às estruturas matriciais. Há 4 dicas importantes:
1ª) Não se apaixone por métodos, nem se apegue a eles.
2ª) Entenda se o mercado é estável ou complexo (volátil) antes de implementar uma metodologia ágil. Isso é determinante.
3ª) O método ágil não veio inviabilizar o PMBOK: eles devem coexistir, levando em conta que a aplicação de cada um é mais ou menos favorável – dependendo do cenário que circunda o projeto.
4ª) Uma estrutura ágil tende a ser mais cara que uma estrutura tradicional (funcional), haja vista a possibilidade de atuações diversas (fique ligado que falaremos mais sobre isso na parte 2/2).
É um episódio que não dá para perder! Clique aqui e confira!
