O Product Owner do Scrum e o Service Request Manager do Kanban: o que são, similaridades e diferenças.
Product Owner e Service Request Manager são a mesma coisa?
Nas nossas últimas aulas, alguns alunos trouxeram algumas dúvidas bem interessantes sobre os papéis de produto. A primeira é o que seria o Service Request Manager (SRM) do Kanban. A segunda é qual seria a relação desse papel com o Product Owner (PO) do Scrum. Então resolvi escrever este artigo para tentar elucidar a questão.
Ouça este artigo!
Por que Service (Serviço)?
Antes de analisarmos a descrição do Service Request Manager (SRM), Gerente de Requisição de Serviço na tradução livre, é importante compreender como o Kanban encara o trabalho a ser realizado. Neste método, as unidades organizacionais como times, squads, departamentos e seções prestam serviços umas às outras em um formato de rede.
A organização (seja ela uma empresa, órgão público, ONG etc.) utiliza sua rede de serviços internos para construir produtos ou serviços que atendam às necessidades de seus clientes e partes interessadas (como órgãos regulatórios, investidores e acionistas, por exemplo).
Assim, o conceito de “serviço” no Kanban está intrinsecamente ligado a essa rede da organização. Cada unidade é responsável por prestar serviços a outras unidades e, em nível macro, a organização como um todo entrega serviços aos clientes e partes interessadas. A partir dessa compreensão, já podemos ter uma ideia das responsabilidades do Service Request Manager (SRM).
O livro Kanban Maturity Model (KMM) é fonte deste material e conta também com um site atualizado sobre esse modelo de maturidade..
O Upstream
Além disso, entenda que o Kanban divide seu fluxo de trabalho em duas partes. Temos o Upstream que está relacionado ao trabalho de descoberta dos itens que comporão a solução e o downstream que está relacionado a todas as etapas necessárias para desenvolver e entregar a solução para o cliente. Não entrarei muito nesse tema aqui, pois já escrevi sobre isso no artigo: Fluxo de Trabalho: o upstream, midstream e downstream.
Nós da K21 preferimos dividir o fluxo em três partes. Para nós o downstream do Kanban pode ser subdividido em midstream (construção) e downstream (entrega). Fizemos isso, pois as habilidades para atender esses serviços são tradicionalmente diferentes e em grande parte das empresas desempenhadas por equipes totalmente diferentes.
Já o Kanban não faz tal divisão do downstream. Para ele, passou do Ponto de Comprometimento, tudo é downstream. Como o presente artigo dissertará mais sobre o upstream, utilizarei a definição do downstream do Método Kanban.
Acredito ser importante para as pessoas que trabalham apenas com o Scrum compreender a existência do Upstream. Afinal, é ali que o Product Owner (PO) tem o seu maior trabalho.
Na maioria dos quadros que vemos nas empresas aparece apenas o midstream, alguns com o midstream e downstream e pouquíssimos com o upstream. Os itens aparecem no ponto de compromisso de forma “mágica”. O trabalho necessário para que ele chegasse ali não é mapeado e gerenciado, logo a qualidade dos itens é aleatória. Se você já passou pelo problema de começar a construção e ter que voltar o item porque faltou informação ou abortá-lo no meio do desenvolvimento, pode ser um sinal de que está faltando qualidade na entrada do item no fluxo. Logo, a gestão do upstream poderia melhorar essa qualidade. Essa é a função primária do Service Request Manager (SRM) que discutiremos nos tópicos abaixo.
Muitos times Scrum fazem a reunião de refinamento e não a vinculam ao seu upstream. Na verdade, todo o fluxo de refinanciamento deveria ser mapeado e exposto em um quadro.
Service Request Manager (SRM)
O SRM tem a responsabilidade de ser o gestor de prestação de serviços e gerente de riscos nas atividades de upstream. Suas funções incluem compreender as necessidades e expectativas dos clientes e desenvolver essa compreensão em toda a equipe responsável pelo fluxo. Além disso, deve supervisionar o desenvolvimento de um processo consistente para atender às demandas, incluindo o acordo entre as partes interessadas. O processo deve contemplar políticas claras para triagem das opções (ideias para construção ou melhoria do produto, pedidos dos stakeholders, problemas percebidos ou notificados etc.), gestão das opções ao longo do upstream, avaliação qualitativa, política de descarte daquelas consideradas inadequadas. Além disso, ele se torna o facilitador da Service Request Review (Revisão da Requisição do Serviço) e da seleção de itens de trabalho durante a Reunião de Reabastecimento.
Em organizações com níveis de maturidade mais altos, o SRM facilita a cadência de Risk Review (Revisão de Risco) na parte do upstream e participa da Operations Review (Revisão de Operações). É essencial garantir que as decisões tomadas estejam alinhadas com os objetivos estratégicos da organização. Para desempenhar essa função, o SRM precisa ter um sólido entendimento sobre o negócio em que está inserido, além de boas habilidades de comunicação e negociação.
A posição de SRM, assim como o do Service Delivery Manager (SDM, Gerente de Entrega de Serviço), aquele que cuida do downstream, pode ser uma responsabilidade individual ou um cargo de grupo ou posição na estrutura organizacional.
Product Owner (PO)
De acordo com o Guia do Scrum (p. 7), o Product Owner (Dono do Produto) é o “responsável por maximizar o valor do produto resultante do trabalho do Time Scrum”. Seu trabalho primário é gerir o Product Backlog (Lista de itens de trabalho). Para tal, ele deve:
- Desenvolver e comunicar de forma explícita a meta e visão do produto;
- Criar e comunicar os itens do Product Backlog;
- Ordenar os itens do Product Backlog; e,
- Garantir que o Product Backlog seja transparente, visível e compreensível.
É possível que ele desempenhe essas ações ativamente ou delegue as responsabilidades para outros embora ele seja sempre o responsável primário.
O Guia do Scrum afirma que o Product Owner é uma pessoa, não um comitê. Ele pode até representar as necessidades de múltiplos interessados (stakeholders), porém ele é o decisor pleno do que entra ou sai do backlog.
Semelhanças entre o SRM e o PO
Já que esse é um texto comparativo, vejamos primeiro as similaridades entre o SRM e o PO.
Domínio do negócio
Para que o sucesso seja alcançado em um projeto, é fundamental que tanto o SRM quanto o PO tenham um excelente domínio sobre o negócio em questão. Isso possibilitará que eles possam discutir com eficiência com as partes interessadas, atender as necessidades dos clientes, entender o mercado, a concorrência, as métricas de eficácia e a estratégia organizacional. Ter esse conhecimento fará com que haja mais facilidade em solucionar conflitos entre stakeholders, aproveitar oportunidades e reduzir riscos.
Entenda o domínio de negócio como a área de atuação da sua organização. Por exemplo: Trabalho na informática de um banco, então o meu negócio são as coisas relacionadas ao banco: finanças, contabilidade, economia, marketing etc.
Facilitar que os desenvolvedores entendam sobre o negócio
É importante que o PO e o SRM não se concentrem excessivamente em si mesmos e evitem tornarem-se a “pessoa mais inteligente da sala”. Esse risco acontece quando uma única pessoa concentra todo o conhecimento do negócio, pois as decisões devem passar por ela, tornando-a o gargalo e a muleta do time. A melhor alternativa para otimizar o trabalho em equipe é permitir que todos tenham acesso às informações sobre o negócio e sejam capazes de tomar decisões e contribuir para a construção do produto ou serviço.
Facilitar a comunicação entre os desenvolvedores, pessoal de negócio e clientes.
O PO e o SRM também têm a responsabilidade de facilitar a comunicação entre desenvolvedores com o pessoal de negócio e clientes. A habilidade de comunicação e negociação é fundamental para que haja um bom desempenho das responsabilidades atribuídas aos papéis. Outra semelhança entre ambos é a responsabilidade de manter o backlog abastecido para que as equipes possam construir com eficiência e maximizar o valor entregue para clientes e para a organização.
Habilidades de comunicação e negociação
Além disso, ambos os papéis exigem que a pessoa desenvolva habilidades de comunicação e negociação, que são cruciais para o bom desempenho das responsabilidades atribuídas a ambos.
Maximizar Valor
Ambos têm a responsabilidade de maximizar o valor entregue ao cliente e à organização por meio de métricas, informações, técnicas e ferramentas que transformam ideias em itens de trabalho que agregam valor. Também cabe a eles a responsabilidade de facilitar a criação de critérios para descartar ideias ruins, ou seja, aquelas que não entregam valor ou exigem esforços grandes para um retorno muito baixo.
Diferenças entre o SRM e PO
Uma vez que já discutimos os pontos de semelhança, iremos agora para os pontos em que um se distingue do outro.
Responsabilidade sobre o Product Backlog
A principal diferença tem relação com o backlog. O SRM é um facilitador para a construção do backlog, não sendo necessariamente a pessoa responsável pela criação ou priorização dos itens. Ele ajuda a equipe a pegar uma opção e refiná-la até o ponto de comprometimento e a descartar opções que não agregam valor. Já o PO é o responsável solitário pelo Product Backlog, incluindo a criação e a priorização dos itens, embora essas funções possam ser delegadas. A responsabilidade final (accountability) pelo backlog é totalmente do PO.
No Scrum, o PO cria, prioriza e descarta opções. No Kanban, o SRM facilita a criação, filtragem e descarte amparado por políticas explícitas, métricas e ferramentas. Ao contrário do PO, o “SRM não é o tomador de decisões” (ANDERSON 2016).
Quando surgem os papéis
Quando olhamos o Scrum, vemos que o Product Owner deve existir desde o momento que começamos a adotar o framework. Já no Kanban, essa função não é obrigatória. Tanto ela como suas responsabilidades são emergentes. Se eu tenho um time hoje e não é necessário alguém desempenhar o papel de SRM, não precisa criá-lo para se adequar ao Kanban.
Como escrito pelo David Anderson: “Um SRM provavelmente será necessário quando o contato com os clientes ou solicitantes de serviço for fraco ou distante”. Nesses casos é comum já existir um intermediário entre o cliente e os desenvolvedores. Pode ser um gerente de vendas ou até mesmo alguém definido como “PO”.
Quando assumir as responsabilidades
O Product Owner (PO) já nasce com todas as responsabilidades descritas no guia do Scrum. A delegação é permitida, porém a responsabilidade é total.
O SRM não precisa nascer com todas as responsabilidades apresentadas no KMM. Por exemplo, se o principal problema do time é fazer coisas que não agregam valor, talvez as primeiras responsabilidades desse SRM seja definir o fluxo de Upstream e políticas de descarte. Em um primeiro momento ele pode não conduzir a Reunião de Reabastecimento, por exemplo.
Conclusão
O Método Kanban é sempre evolucionário e, portanto, para utilizá-lo, não é necessário adotar tudo de uma vez. Você não precisa de um SRM até precisar de um SRM. Fazer por fazer seria um incorrer em um risco desnecessário.
Creio que podemos utilizar dois termos para diferenciar um papel do outro. O Product Owner (PO) como o próprio nome diz, é dono do produto enquanto o Service Request Manager (SRM) é o facilitador para a construção do produto.
Acompanhe nossos posts para novidades sobre PO e SRM. Se quiser aprende mais sobre Kanban e Scrum, conheça os nossos treinamentos!
