Nas organizações é comum que as pessoas assumam papéis ao longo de suas carreiras. Na Gestão de Projetos, alguns dos papéis que se consagraram foram: Gerente de Projetos, Time de Projetos, Analista de Negócios, Gerente de Programa e outros. A agilidade, no geral, adotou os papéis do Scrum, com algumas variações: Scrum Master, Agile Master, Agile Coach, Product Owner, Product Manager, Desenvolvedor. O Kanban também tem alguns papéis, mas uma forma diferente para adotá-los e defini-los. Este artigo apresenta os 3 papéis que hoje figuram no Kanban: Flow Manager, Service Request Manager (SRM) e Service Delivery Manager (SDM).
Neste artigo
Observações gerais sobre os papéis no Kanban
Evolucionário
O Kanban é um método que presa pela evolução em detrimento a revoluções. Em termos práticos uma revolução seria chegar na organização hoje, jogar todos os papéis que existem fora e a partir da data X, só utilizaremos os papéis do novo método de trabalho.
Isso provoca uma resistência enorme, até mesmo impeditiva. As pessoas vão se sentir pessoalmente agredidas visto que estaríamos pegando anos de estudo, o cartão de visitas, todo seu currículo e dizendo: "isso não serve para mais nada. Toma aqui sua nova identidade".
Com Kanban nada será atirado pela janela do dia para noite. Se os papéis existem e eles funcionam, ótimo. Vamos tratar das coisas que realmente valem a pena ser melhoradas. Quando surgir a necessidade que pode ser resolvida por algum dos papéis do Kanban, voltaremos a conversar.
O nome não importa tanto
É comum que com a introdução de um novo método de trabalho, as pessoas busquem criar uma identidade com os papéis definidos pelos métodos. Antes da agilidade tomar a dimensão atual, era comum vermos diversos cursos preparando pessoas para terem a certificação de Project Management Professional (PMP). Após o Scrum ganhar o mercado chegaram novas certificações como o Certified Scrum Product Owner (CSPO) e o Certified Scrum Master.
Porém se você pesquisar por treinamentos de Kanban Flow Manager, Kanban Service Request Manager, ou Kanban Delivery Manager você não irá encontrar. Isso acontece porque o Kanban inverte um pouco a ordem da coisa. Se você tem alguma pessoa ou grupo que execute as responsabilidades desses papéis, você até pode nomeá-los com a nomenclatura do Kanban, porém não há nenhuma obrigação. Por exemplo, se em um fluxo já há alguém que desempenha o papel de Product Manager e tem as responsabilidades de um Service Request Manager (SRM), não há necessidade de mudar o nome do papel. Pode continuar a ser o Product Manager.
Papéis aparecem apenas nos níveis de maturidade mais altos
No artigo Gestão de Projetos e Kanban Maturity Model (KMM): O que tem a ver?, José Jr apresentou o KMM. Não irei reapresentá-lo aqui, mas, resumidamente, é um modelo em que serve para avaliar qual seria o nível de maturidade da adoção de Kanban em uma organização. Ele é composto de diversos níveis que vão de zero até seis.
O nível zero é o caos, as coisas acontecem, mas não se sabe como. No nível 1 passamos a conhecer o fluxo de trabalho, normalmente o Kanban passa a ser adotado por times da organização, mas de forma isolada. No nível 2 começamos a focar no cliente e entender que a entrega muitas vezes dependerá da junção de vários fluxos. Por exemplo, os fluxos dos times começam a ser integrados. É apenas no nível 2 que aparece o primeiro papel de Flow Manager. Antes disso, não há agrupamentos de responsabilidades com um título específico.
Entretanto, eu gostaria de deixar claro que isso é uma observação e não uma regra. Trago a frase apresentada no KMM+ (acesso pago): “Em algumas organizações, observamos a emergência de um papel de Gerente de Fluxo (Flow Manager) no Nível de Maturidade 2”. Isso significa que não há um impedimento para organizações com Nível de Maturidade 1 terem o Gerente de Fluxo, assim como não obriga organizações com Nível de Maturidade 2 a terem um. Depende da necessidade.
Pode ser mais do que uma pessoa
Dependendo do método escolhido, um papel poderá ser ocupado apenas por uma pessoa. Por exemplo, no Scrum, se temos 1 Product Backlog, temos 1 Product Owner (PO). Se temos 1 Time Scrum, temos 1 Scrum Master (SM). Já o Kanban admite que a adoção do papel pode ser através de uma pessoa, de um grupo, um cargo ou uma função. Depende da cultura organizacional.
Não é o único pescoço "torcível"
É interessante perceber que o Kanban evita ao máximo ter o que o David Anderson chama de: "single wringable neck". Que poderia ser traduzido para algo como: o único pescoço "torcível". Na prática o que queremos evitar é que a responsabilidade resida exclusivamente sobre uma pessoa, pois no sucesso ela seria engrandecida, mas no fracasso ela teria o seu pescoço torcido.
Por isso os papéis do Kanban dificilmente colocam algo como: o SRM é o responsável pelo upstream ou o SDM é o responsável pelo downstream. Ao invés disso, aparece responsabilidades como: supervisionar, facilitar, auxiliar, ajudar etc.
Visto tudo isso, vamos aos papéis em si.
Gerente do Fluxo (Flow Manager)
O Gerente de Fluxo costuma aparecer no Nível de Maturidade 2. Nesse nível já focamos no cliente e buscamos alinhar os fluxos para que consigamos entregar o serviço que resolve a necessidade desse cliente. Diga-se de passagem, levar tal compreensão para o time é fundamental para quem desempenha este papel.
O Gerente não gerencia com sentimentos. Emoções são muito boas, mas quando estamos lidando com muitas pessoas, o correto é ser objetivo e utilizar métricas. Nós citamos algumas delas nessa sequência de artigos: Fluxo de Trabalho: o upstream, midstream e downstream; Métricas Ágeis comuns ao upstream, midstream e downstream; Métricas Ágeis: Upstream; e Métricas Ágeis: Midstream e Downstream.
Quem desempenhar esse papel também deve ser o facilitador da Reunião Kanban do Fluxo de Trabalho (Workflow Kanban Meeting). Esta é uma reunião que costuma surgir também no Nível de Maturidade 2. Ela se sobrepõe à Team Kanban Meeting e é utilizada para acompanhamento do trabalho entre os fluxos dos times envolvidos no serviço. O que queremos é que as passagens de bastões entre os fluxos sejam o mais suave possível.
Além disso, esse papel é o facilitador para compreender as solicitações do cliente. Parece um Product Owner (PO), mas não é. O PO é o responsável pelo backlog. O Gerente de fluxo tem a responsabilidade de facilitar a construção e gestão do backlog que no Kanban pode ser chamado de Piscina de Opções.
Ele também é o facilitador da resolução de bloqueadores e problemas, levando em consideração que esses podem ultrapassar a barreira do time. Logo, a pessoa que estiver com essa responsabilidade deve ter poder de atuar além do escopo de um time. Bloqueador é tudo aquilo que impede um item de trabalho de prosseguir sua caminhada no fluxo para as próximas etapas. Por exemplo: falta de assinatura que já deveria ter acontecido, descoberta tardia de que o item de trabalho ainda não foi realmente entendido, falta de algum serviço que já deveria ter sido providenciado etc.
Gerente de Solicitação de Serviço (Service Request Manager)
Também conhecido pela sua sigla inglesa, SRM, é um papel que surge normalmente no Nível de Maturidade 3. Ele é a pessoa ou grupo responsável por facilitar o upstream. Poderíamos resumir suas responsabilidades como o conjunto de atividades necessárias para que as demandas dos clientes (opções) sejam corretamente compreendidas até se tornarem itens de trabalho comprometidos ou serem descartados.
No artigo: O Product Owner do Scrum e o Service Request Manager do Kanban: o que são, similaridades e diferenças, escrevo sobre como esse papel se parece com o do Product Owner do Scrum, porém possui diferenças de grande relevância.
Assim como o Flow Manager, o SRM tem que levar às pessoas envolvidas no fluxo de trabalho a necessidade e expectativas do cliente. Cabe a ele também avaliar e trabalhar para reduzir os riscos do serviço que está sendo prestado pelos times
O SRM deve supervisionar a construção do upstream juntamente com as pessoas responsáveis pelo fluxo de trabalho. Embora não seja ele o criador, ele tem muito trabalho. Por exemplo, buscar acordos entre os stakeholders, ajudar na definição de políticas de gestão das opções (gestão do backlog).
Além disso, é a pessoa que facilitará três cadências específicas:
- Revisão da Requisição de Serviço (Service Request Review). Serve para entender o estado dos pedidos que estão no upstream e definir se eles devem ir até o Ponto de Comprometimento, serem descartados ou aguardar novas informações antes de continuar a se movimentar no fluxo.
- Reunião de Reabastecimento (Replenishment Meeting). O objetivo é selecionar junto com o cliente e pessoal de negócio quais são as próximas solicitações que serão tratadas.
- Revisão de Risco (Risk Review). É uma cadência que costuma a aparecer em empresas com Nível de Maturidade 4 na adoção do Kanban. Seu objetivo é identificar e responder a riscos relacionados à entrega de serviço da organização.
Gerente de Entrega de Serviço (Service Delivery Manager)
Também conhecido pela sua sigla em inglês, SDM. É um papel complementar ao SRM. Ele é o facilitador do downstream. Sua principal atribuição é supervisionar a entrega do serviço adequado ao propósito do cliente (fit-for-purpose service delivery). Ele ajuda a garantir que a entrega seja suave através do sistema Kanban que pode incluir a coordenação entre diversos fluxos de diversos times. Inclusive é ele que conduz ações que visam melhorar o sistema para tornar a entrega mais eficaz.
Está também no seu guarda-chuva de responsabilidades orientar as pessoas na identificação, análise e solução de bloqueadores que estejam impedindo o andamento dos itens. Além de ser embasado com muitas métricas para avaliar itens mais lentos e aqueles que estejam gerando retrabalho e refluxo.
Cabe a ele também supervisionar se as dependências que existem no fluxo estão sendo geridas. Por exemplo, o Time A que depende do Time B. Caso não estejam e estas causem atrasos que ultrapassem os acordos de nível de serviço (Service Level Agreement, SLA) cabe a ele também supervisionar o tratamento de tais disfunções.
Além disso ele também pode ser tornar o facilitador de duas cadências:
- Reunião de Planejando da Entrega (Delivery Planning Meeting) que objetiva planejar e monitorar a entrega das soluções para os clientes
- Revisão da Entrega do Serviço (Service Delivery Review) que tem como objetivo examinar e aperfeiçoar a eficácia dos serviços prestados.
Conclusão
Como podemos perceber, o Kanban tem um tratamento um pouco diferente de seus papéis. Eles não são obrigatórios, mas emergem conforme a necessidade aparece. Também é perceptível que todos estão vinculados ao Fluxo de Trabalho e para poder desempenhá-los bem, temos que evoluir no conhecimento sobre o método e a gestão de fluxo.
Espero que este artigo tenha ajudado e se quiser saber mais sobre esse método veja os nossos treinamentos de Kanban System Design (KSD) e Kanban Systems Improvement (KSI).
¡Hasta luego!
