Service Request Manager no Kanban: o que faz o SRM

O Service Request Manager, ou SRM, é o papel do Kanban que cuida da porta de entrada do sistema: entender o que os clientes precisam, manter as opções organizadas e garantir que a escolha do que entra no quadro siga regras claras, e não a pressão de quem grita mais alto. Em áreas que recebem pedidos de muitos lados, como um escritório de projetos, uma equipe de sistemas ou uma consultoria interna, é a ausência desse cuidado que lota o quadro de trabalho que ninguém priorizou.

A seguir você vê de onde o papel vem, o que o SRM faz no dia a dia, como ele se diferencia do Service Delivery Manager e como saber se a sua equipe precisa de alguém nessa função.

O que é o Service Request Manager

O SRM é um dos dois papéis descritos pela Kanban University para o Kanban Method, ao lado do Service Delivery Manager (SDM). As referências principais são dois textos de David Anderson publicados em janeiro de 2016 no site da Kanban University.

Três pontos desses textos definem o papel:

1. É um papel emergente, não prescrito. Anderson descreve o SRM e o SDM como papéis que surgiram em implantações reais e afirma que continuam sendo sugestões, opções ou ideias, e não papéis obrigatórios do Kanban.
2. Cuida das políticas de seleção. O SRM é quem responde pelas políticas de avaliação de risco, de agendamento, de sequência e de seleção do que entra no sistema, e facilita a decisão sobre esses itens.
3. Facilita a escolha, não decide sozinho. Os textos insistem que o SRM deve ser o facilitador da seleção, e não a pessoa que faz a seleção. A decisão continua sendo coletiva, com as políticas combinadas como base.

Na rotina das cadências, quando o papel existe, o SRM costuma responder pela reunião de reposição e participar da revisão de estratégia e da revisão de riscos.

De onde vem o papel

O Kanban Method parte do princípio de respeitar os papéis e cargos atuais. Por isso, o SRM raramente é uma contratação nova. Segundo Anderson, ele costuma surgir de um intermediário que já existe no fluxo: um engenheiro de vendas, um gerente de contas, um gerente de produto ou, em organizações ágeis, um Product Owner.

A mudança está na forma de atuar. Em vez de ser o "herói" que decide sozinho o que a equipe faz, essa pessoa passa a cuidar das regras que orientam a decisão e a conduzir o processo de escolha. Em implantações menores, o SRM é um conjunto de responsabilidades a mais para alguém da equipe; em organizações que lidam com muita inovação e incerteza, pode virar uma posição própria.

Anderson associa o surgimento do SRM principalmente aos sistemas com Kanban upstream ou de descoberta, em que as ideias e pedidos são avaliados antes do compromisso de entrega. A diferença entre essa parte do fluxo e a de execução está em upstream e downstream no Kanban.

SRM e SDM: quem faz o quê

Anderson registra que, na primeira implantação completa do Kanban Method, em 2007, o papel de SDM era normalmente exercido por um gerente de projetos do escritório de projetos, responsável pela reposição, pelo planejamento de entregas e pela escalada de bloqueios. Quando o SRM existe, a reposição passa para ele. Os detalhes do outro papel estão em Service Delivery Manager: o que faz o SDM, e a visão geral das responsabilidades no método está em papéis no Kanban.

O que o SRM faz no dia a dia

1. Conversa com os solicitantes. Entende o que cada área precisa, por que precisa e quando precisa, e traduz isso em itens que a equipe consegue avaliar.
2. Mantém as opções organizadas. Cuida da lista de ideias e pedidos ainda não comprometidos, descartando o que perdeu sentido. Uma lista de opções que só cresce é sinal de que ninguém está decidindo o que sai.
3. Escreve e revisa as políticas de seleção. Critérios de entrada, ordem de prioridade, como tratar urgências e itens com data fixa. Essas regras podem usar classes de serviço e a noção de custo de atraso.
4. Conduz a reunião de reposição. Apresenta as opções preparadas, lembra as políticas e facilita a escolha do que entra quando há capacidade. O passo a passo da reunião está em Replenishment Meeting.
5. Leva informação às revisões. Mostra na revisão de riscos e na de estratégia o que a demanda está sinalizando: tipos de pedido crescendo, clientes sem atendimento, opções descartadas por falta de capacidade.

Quando a equipe precisa de um SRM

Nem toda equipe precisa de alguém dedicado a esse papel. Os sinais de que vale a pena designar um responsável:

• Pedidos chegam por muitos canais (e-mail, mensagem, corredor) e ninguém tem a lista completa.
• A prioridade muda conforme quem reclama. Sem política combinada, o último pedido urgente sempre fura a fila.
• O quadro enche de itens que nunca andam. Entraram sem análise e ocupam espaço.
• A equipe gasta tempo demais avaliando pedidos que deveriam ter sido filtrados antes.
• Clientes reclamam de falta de resposta, mesmo quando a resposta seria "não agora".

Em equipes pequenas, o SRM costuma ser o próprio coordenador ou o Product Owner atuando com essa lógica. Em áreas com vários serviços, pode ser uma pessoa por serviço ou uma função compartilhada.

Exemplo ilustrativo: escritório de projetos com demanda interna

Imagine um escritório de projetos que recebe pedidos de várias diretorias: novos projetos, mudanças em sistemas, relatórios e estudos. Antes, cada diretor falava diretamente com quem conhecia na equipe, e o quadro tinha dezenas de itens em andamento.

Uma analista sênior, que já fazia o contato com as diretorias, passou a atuar como SRM. Ela reuniu os pedidos numa lista única de opções, propôs critérios de entrada aprovados pelo comitê (alinhamento com metas do ano, prazo regulatório, impacto em mais de uma área) e começou a conduzir uma reunião quinzenal de reposição com representantes das diretorias. Quem decide o que entra é o grupo, com base nas políticas; ela prepara as opções e conduz a conversa.

O exemplo é ilustrativo e não traz resultados medidos. O ponto é a mudança de papel: a mesma pessoa que antes repassava pedidos passa a cuidar das regras e do processo de escolha.

Erros comuns com o papel de SRM

• Transformar o SRM em quem decide tudo. É o "Product Owner herói" que os textos da Kanban University querem evitar. A seleção é facilitada, não imposta.
• Criar um cargo antes de existir o problema. Comece atribuindo as responsabilidades a alguém e formalize só se a demanda justificar.
• Separar o SRM da equipe de entrega. Sem saber a capacidade real, ele promete o que a equipe não consegue cumprir.
• Confundir com gestão de requisições de serviço de TI. Em ferramentas de gestão de serviços de TI, "service request" é um tipo de chamado do usuário. O SRM do Kanban é um papel de gestão do fluxo de demanda, não um módulo de sistema.

Para começar, liste por onde os pedidos chegam hoje à sua equipe e quem, na prática, já decide o que entra. Escreva três critérios de entrada e teste numa reunião de reposição com os principais solicitantes. Para aprender os papéis, as cadências e as políticas do Kanban Method aplicados a projetos, o curso de Kanban da Projeto Diário trabalha esses temas e prepara para a certificação CKMS. A visão geral do método está em o que é Kanban.