Gestão de Produtos Scrum: Guia Completo + Exemplos

O Scrum não é nada de novo no domínio da gestão de produto. A maioria de nós utiliza o Scrum nas nossas empresas e tenta navegar pelos papéis e princípios desta estrutura para alcançar os nossos objetivos.

Infelizmente, é comum as empresas interpretarem incorretamente os princípios do Scrum e utilizá-los de forma inadequada, privando assim os utilizadores dos muitos benefícios do Scrum.

Por isso, este pequeno guia foi criado para o ajudar a utilizar melhor esta estrutura, explicando em que consiste, por que razão existem diferentes papéis no Scrum, quais são as responsabilidades da gestão de produto e como alcançar a excelência na colaboração multifuncional.

O que é o Scrum na gestão de produto?

Muitos de nós gostamos de discutir o papel de um gestor de produto no contexto real dos processos Scrum e da metodologia ágil (por outras palavras, o que o PM faz numa equipa Scrum). Em vez de me limitar a explicá-lo, penso que é mais fácil mostrar-lhe simplesmente onde se encontra o PM no organograma da equipa.

Para este guia, no entanto, quero abordar este tema na direção oposta e mostrar como o Scrum se integra na sua realidade enquanto profissional de gestão de produto e como o pode ajudar a alcançar os objetivos do seu produto.

Quero começar por discutir o efeito dos princípios fundamentais da estrutura Scrum na eficácia do nosso trabalho.

Nota do autor

Se precisar de refrescar a memória sobre estes princípios, a \u003ca href=\u0022https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/\u0022 rel=\u0022noreferrer noopener\u0022 target=\u0022_blank\u0022\u003eAgile Alliance tem um excelente guia\u003c/a\u003e para si.

Provavelmente, o princípio do Scrum mais valioso para nós é a entrega constante de valor aos utilizadores. Quanto mais rapidamente as pessoas conseguirem resolver problemas, melhor será o desempenho do seu produto. Além disso, obtém acesso a opiniões antecipadas de pessoas que utilizaram a funcionalidade num cenário real.

A segunda vantagem que obtém com o Scrum é a flexibilidade. Se a realidade do mercado mudar, pode adaptar-se rapidamente, reformulando completamente a sua lista de pendências do produto e atribuindo novas funcionalidades à sua equipa na iteração seguinte (algo em que a IA no planeamento de iterações pode ajudar).

Estas duas coisas são muito difíceis (ou quase impossíveis) de fazer com estruturas tradicionais como o modelo em cascata, em que tudo é fixo em termos de âmbito e os utilizadores só acedem ao produto no final do SDLC.

Exemplos de sucesso de produtos graças à integração do Scrum

Depois de ter trabalhado com equipas Scrum durante anos, sou totalmente parcial a favor desta estrutura ágil. Por isso, não aceite a minha palavra como verdade absoluta. Em vez disso, vejamos casos reais em que a transição para o Scrum ajudou as equipas de produto a alcançar o sucesso mais rapidamente.

Microsoft Visual Studio: A principal ferramenta de edição de código da gigante tecnológica era famosa pelos seus ciclos repetidos de inferno de produção, com lançamentos cheios de erros e uma frequência de lançamento incrivelmente baixa. A partir do momento em que a equipa de produto começou a tirar partido do Scrum, a empresa registou um aumento acentuado da estabilidade do produto, juntamente com ciclos de lançamento muito mais frequentes — recuperando a sua competitividade no mercado.

Spotify: A adoção do Scrum pelo nosso adorado serviço de transmissão de música é uma das mais famosas do setor. A Spotify teve dificuldades em adaptar-se e crescer com rapidez suficiente para resolver os seus desafios de processos... até a organização adotar o Scrum. No entanto, o que distingue a Spotify é o desenvolvimento do seu próprio modelo de gestão de projetos Scrum, que pressupunha um grupo de equipas ágeis autónomas com acesso a todos os conhecimentos especializados de que necessitavam para experimentar rapidamente e incorporar as opiniões dos utilizadores.

ING: O gigante bancário neerlandês esteve entre as primeiras instituições financeiras a perceber que o futuro da banca é digital. Também percebeu que os seus processos de gestão de projetos muito tradicionais não eram viáveis para o desenvolvimento de software. Por isso, adotou rapidamente metodologias enxutas e Scrum e, sem surpresa, tornou-se líder na banca eletrónica.

Principais papéis na gestão de produto Scrum

Se, enquanto PM, decidir que o Scrum é o caminho a seguir, apresentamos-lhe uma visão geral rápida dos principais papéis nesta estrutura, para o ajudar a distinguir entre o seu papel enquanto gestor de produto e o de responsável pelo produto no Scrum.

Comecemos pelos papéis. Uma equipa Scrum típica é composta pelas seguintes pessoas:

• Mestre de Scrum: Esta pessoa ajuda a equipa a seguir as regras do Scrum e a otimizar os seus processos.
• Responsável pelo produto: Esta pessoa representa o negócio e os utilizadores na equipa Scrum. Os responsáveis pelo produto são donos do backlog e definem os objetivos dos sprints e as prioridades das histórias.
• Equipa Scrum: Os seus programadores, designers, profissionais de garantia de qualidade e outros especialistas que constroem o produto.

No que diz respeito à equipa Scrum, pode ter muitos outros tipos de especialistas. O conceito de equipas multifuncionais pressupõe que a equipa é independente em termos de acesso a conhecimentos especializados. Assim, por exemplo, se o seu produto depender muito de análise de dados, pode também ter um analista de dados na equipa.

Gestor de produto vs. responsável pelo produto: qual é a diferença?

A definição de responsável pelo produto que apresentei pode causar-lhe alguma confusão, uma vez que soa muito semelhante ao que um gestor de produto normalmente faz.

Então, neste caso, qual é a diferença entre gestor de produto e responsável pelo produto?

Para compreender a diferença, vejamos primeiro as principais responsabilidades de cada um.

Gestores de produto

• Realizar a descoberta do produto e compreender as necessidades e dificuldades dos clientes.
• Definir a visão do produto e a direção que a equipa deverá seguir.
• Criar soluções de produto que possam satisfazer as necessidades dos clientes.
• Liderar o processo de entrega do produto.
• Aperfeiçoar o produto em pequenos incrementos com base no feedback dos clientes e na tomada de decisões orientada por dados.
• Gerir a visão e a execução do produto em toda a empresa e entre as diferentes áreas.

Responsáveis pelo produto

• Criar e manter o backlog do produto.
• Atuar como fonte única de informação relativamente à estratégia, ao design e à lógica de negócio para a equipa Scrum.
• Dar prioridade aos itens do backlog do produto e esclarecer à equipa o que é importante.
• Definir critérios de aceitação para as funcionalidades e aceitar os resultados do sprint com base nesses critérios.
• Desbloquear os membros da equipa, esclarecendo os requisitos e resolvendo os problemas relacionados com os mesmos.
• Participar nos eventos Scrum e representar a voz do negócio e dos clientes na equipa.

Como podemos ver, a maioria de nós faz coisas que podem ser encontradas em ambas as listas. Isto é perfeitamente normal e comum, uma vez que muitos de nós desempenham simultaneamente as funções de gestores de produto e de responsáveis pelo produto.

A diferença fundamental entre os dois é que a gestão de produto é uma profissão e um conjunto de competências, enquanto a responsabilidade pelo produto é uma função na equipa Scrum.

Mas o que significa isso?

Significa que o responsável pelo produto não precisa de ser um gestor de produto. Numa pequena startup, onde tem o CEO juntamente com três programadores, o CEO assumirá a função de responsável pelo produto, fornecendo aos programadores um backlog priorizado.

A situação oposta também é possível. Pode ser gestor de produto e não ser responsável pelo produto. Sou um bom exemplo disso, uma vez que uma das minhas equipas anteriores não utilizava Scrum. Sem Scrum, não havia responsável pelo produto na equipa. No entanto, seguíamos os princípios Lean e Agile.

Para lhe proporcionar uma melhor compreensão da diferença entre os dois, apresentamos uma comparação lado a lado do que fazem.

Mas qual era o objetivo de ter uma função especial na equipa Scrum? Não poderiam simplesmente colaborar com gestores de produto que não fazem parte da equipa? Gosto muito da forma como Teresa Torres responde a esta questão.

Assim, a principal razão para existir uma função específica de produto na equipa Scrum é contribuir com conhecimento e experiência internos sobre o produto e reforçar ainda mais a sua multifuncionalidade. 

Como o gestor de produto interage com as equipas Scrum

Partindo do princípio de que decidiu seguir o caminho do Scrum, terá de saber como ser membro da equipa e como colaborar com os seus colegas. Permita-me apresentar uma breve visão geral disso para cada evento Scrum e artefacto.

• Scrum diário (também conhecido como reunião diária): O trabalho mais importante que realiza durante estas reuniões com duração limitada é responder às questões relacionadas com o produto colocadas pela sua equipa de desenvolvimento e remover bloqueios.
• Reunião de planeamento do Sprint: Aqui, é a pessoa que define o objetivo do Sprint, esclarecendo claramente as suas expectativas relativamente às funcionalidades que espera disponibilizar.
• Retrospectiva do Sprint: Os processos que utiliza para disponibilizar prioridades e requisitos à equipa podem determinar o sucesso ou o fracasso da sua eficácia. Assim, pode utilizar esta reunião para recolher feedback da equipa e melhorar os seus processos.
• Revisão do Sprint: Aqui, a sua tarefa é aceitar as funcionalidades concluídas do Sprint e fornecer à equipa feedback sobre o seu trabalho.
• Refinamento do produto: É responsável por esta reunião e deve utilizar o tempo que lhe é dedicado para discutir as prioridades e os detalhes das histórias de utilizador que tem para a equipa. Incentive sempre a equipa a questionar os seus requisitos e a encontrar “erros do produto” que tenha deixado passar.
• Backlog do produto: É da sua responsabilidade gerir o backlog do produto e mantê-lo limpo e priorizado, uma vez que a equipa irá basear nele o seu Sprint.
• Backlog do Sprint: Este não é da sua responsabilidade. O seu principal ponto de colaboração consiste em orientar a equipa para selecionar as histórias certas para o backlog do Sprint, de modo a garantir que consegue alcançar o objetivo do seu Sprint.

Além disso, realizará outros tipos de trabalho relacionado com o produto, como a gestão das partes interessadas ou a descoberta do produto. Enquanto membro da equipa Scrum, a sua tarefa é manter a equipa a par das necessidades das partes interessadas e dos utilizadores depois de as ter esclarecido.

Por exemplo, se entrevistar um utilizador e descobrir que a experiência de utilizador do seu fluxo de início de sessão é, de um modo geral, confusa, é importante partilhar esta informação com a equipa para garantir que presta atenção a essa parte nos Sprints seguintes.

Melhores práticas para a gestão de produtos Scrum

Embora a gestão de produtos pareça fácil quando vista através da perspetiva do Scrum (e do desenvolvimento Ágil em geral), cometemos frequentemente muitos erros durante o nosso trabalho nas nossas equipas auto-organizadas.

Por isso, apresentamos algumas boas práticas de Scrum que podem ajudá-lo a evitá-los:

• Defina expectativas claras: O maior erro que pode cometer é fornecer à sua equipa prioridades e requisitos vagos. A falta de clareza é uma das principais causas de atrasos no desenvolvimento e de tensão entre si e a equipa. Em breve, analisaremos em profundidade como alcançar este objetivo.
• Não abuse da adaptabilidade: Ter a capacidade de mudar de rumo é ótimo, mas só pode fazê-lo no backlog do produto, não no backlog do Sprint. Assim que o Sprint começar, não adicione nem remova histórias. Isso perturba os planos e o progresso da sua equipa e conduz a Sprints inacabados.
• Crie um ambiente emocionalmente seguro: É um membro da equipa, não o chefe. Por isso, não pressione a sua equipa para assumir compromissos maiores ou terminar mais cedo. Os guias do Scrum em todo o mundo, incluindo o da Scrum.org, dão grande importância à manutenção de relações saudáveis com os seus colegas de equipa, uma vez que esta é uma das pedras basilares de um trabalho de equipa eficaz.

Estas três boas práticas são as mais importantes, com base na minha experiência. No entanto, se quiser obter mais dicas sobre fluxos de trabalho Ágil e boas práticas de Scrum para gestores de produto, consulte o nosso guia separado sobre gestão de produtos Ágil.

Gerir eficazmente o backlog do produto

Como referi anteriormente, fornecer clareza à sua equipa é uma das tarefas mais importantes de um gestor de produto. A boa notícia é que o seu backlog do produto é provavelmente a melhor ferramenta para o conseguir. Por isso, apresentamos algumas dicas de gestão do backlog do produto para o ajudar:

Sessões de refinamento: Por muito bem que escreva as suas histórias de utilizador, irá deixar aí “erros” e quererá que a sua equipa de desenvolvimento os verifique e assinale. Há também o facto de não ser programador e poder escrever requisitos difíceis de implementar. Mais uma vez, a sua equipa irá informá-lo disso durante o processo de refinamento.

Técnicas de priorização: Tire partido dos numerosos quadros de priorização para compreender quais as funcionalidades que são mais importantes do que outras. A minha preferência pessoal é o MoScoW, pela sua simplicidade.

Alinhamento com o roteiro e a visão: Os épicos e as histórias no seu backlog devem representar os objetivos gerais do produto e as métricas que pretende alcançar. Por isso, certifique-se de que revê constantemente o seu roteiro quando adiciona algo ao backlog.

Alinhar as partes interessadas no Scrum

A essência do papel de um gestor de produto no Scrum é ser, essencialmente, o elo de ligação entre a equipa auto-organizada e o mundo exterior, sejam utilizadores, partes interessadas ou outras equipas.

Assim, para além de desempenhar as suas funções habituais de gestão das partes interessadas enquanto gestor de produto, também precisa de transmitir essa informação à sua equipa e vice-versa. Haverá também situações em que precisará de transmitir informações da equipa às partes interessadas.

Um bom exemplo é o surgimento de desafios técnicos, como problemas de integração contínua, que podem afetar o calendário ou o âmbito de uma determinada funcionalidade. É algo que precisa de discutir com as partes interessadas e, ou aceitar o novo calendário/âmbito, ou encontrar uma solução diferente (por exemplo, reforçar a equipa com mais conhecimentos especializados relacionados com essa questão).

Também há situações em que a sua equipa pode ter tido uma ideia interessante para uma funcionalidade ou uma solução que vale a pena acrescentar ao roteiro. Mais uma vez, transmite esta informação às partes interessadas e decide se a adiciona ou não ao seu plano.

A importância do planeamento de roteiros Ágeis no Scrum

Embora não façam diretamente parte do Scrum, os roteiros Ágeis são uma das ferramentas que tornam o Scrum possível. Afinal, de que serve o planeamento iterativo se estiver a utilizar o modelo em cascata para o seu produto em vez de um roteiro Ágil?

Nesse caso, aquilo a que chama estratégia de produto Scrum seria simplesmente dividir um plano predefinido e fixo, com um ciclo de vida de desenvolvimento de software clássico, em partes de 2 semanas (ou com a duração dos seus sprints). Assim, para tornar o Scrum significativo para a sua equipa, precisa de realizar um planeamento interativo Ágil e de criar um roteiro capaz de mudar ao longo do tempo.

Agora, para associar corretamente o seu roteiro Ágil aos processos Scrum da sua equipa, sugiro que faça o seguinte:

• Ligue os itens do roteiro (normalmente Épicos) às histórias de utilizador na lista de trabalho pendente do produto. Desta forma, existe uma ligação direta entre o seu trabalho tático (histórias) e a sua estratégia (roteiro).
• Apresente o seu roteiro à equipa Scrum. Desta forma, saberão para onde o produto está a avançar e terão em conta as próximas funcionalidades ao conceberem a arquitetura da interface ou do servidor.
• Aproveite ferramentas especializadas como Jira, Monday.com e Clickup para simplificar o seu processo de planeamento do roteiro e de gestão da lista de trabalho pendente.

Quanto ao último ponto, estas três ferramentas são as que utilizei na prática. No entanto, existem muitas outras ferramentas de gestão de produtos que pode considerar utilizar em alternativa.

Desafios da gestão de produtos Scrum

Embora o Scrum seja uma excelente estrutura para alcançar os objetivos do seu produto, a utilização desta estrutura apresenta o seu próprio conjunto de desafios, tais como:

• A sua equipa ou as partes interessadas podem não compreender em que consiste o Scrum. Isto pode, obviamente, levar a problemas significativos na adoção do Scrum, como a recusa em utilizar determinados artefactos. Recomendo que se antecipe a este problema ilustrando o «estado final» desejado, mostrando como serão a equipa e o fluxo de trabalho quando a estrutura estiver totalmente implementada.
• As pessoas (e você) podem ficar confusas acerca do seu papel na equipa e fora dela. Todas as empresas onde trabalhei ao longo da minha carreira tinham a sua própria interpretação do que faz um PO de Scrum. É melhor estabelecer claramente o que é — e o que não é — para a sua equipa.
• O âmbito das funcionalidades em que trabalha tende a expandir-se interminavelmente. Não é de surpreender que isto facilite muito a entrada num território de expansão descontrolada do âmbito. As equipas Scrum precisam de ser implacáveis relativamente ao que aceitam fazer e ao que recusam.
• O roteiro pode facilmente sair do rumo. Ao ter uma equipa relativamente independente, que pode escolher em que trabalhar, pode acabar por vê-la desenvolver coisas que não fazem parte do seu roteiro. Manter o objetivo final claramente em foco é fundamental para evitar esta armadilha.

Embora estes desafios sejam bastante comuns, a boa notícia é que o gestor de produto só precisa de alguns sprints para compreender o processo Scrum e ultrapassar a grande maioria deles. Para quem pretende formalizar os seus conhecimentos, aprender como tornar-se mestre de Scrum pode proporcionar aos líderes uma vantagem credível na orientação das suas equipas ao longo da estrutura.

Conclusão

O Scrum é uma das melhores dádivas para os gestores de produto. Graças ao equilíbrio entre ser Ágil a longo prazo e rigoroso em iterações curtas, pode evitar o caos de um processo de desenvolvimento Ágil sem estrutura, mantendo simultaneamente a capacidade de alterar o rumo do seu produto com base na resposta do mercado.

Esperamos que tenha gostado do nosso guia. Se assim for, não se esqueça de subscrever a nossa newsletter para obter mais recursos e guias sobre gestão de produtos, bem como os podcasts, as entrevistas e outros conteúdos mais recentes de líderes e especialistas do setor.