Certo dia, durante uma conversa sobre STATIK (Systems Thinking Approach to Implement Kanban), com colegas da Plataformatec, foi levantada uma dúvida interessante durante esse debate e que pode fazer parte do dia a dia de quem tem adotado as práticas do método Kanban: Qual é a diferença de tipos de demanda e as classes de serviço? Elas querem dizer a mesma coisa, mas com nomes diferentes ou são de fato coisas distintas? Vou tentar explicar para vocês neste artigo.
Mas antes de tudo, vamos falar brevemente do que se trata o STATIK para ficarmos todos na mesma página.
O STATIK trata-se de uma abordagem difundida por David Anderson (autor do método Kanban) e posteriormente por Mike Burrows (autor do livro Kanban from Inside), para compreender como um sistema de trabalho se comporta e como aplicar/melhorar a adoção do Kanban dentro de um produto ou serviço através da execução de alguns passos exploratórios. Segundo David, estes passos não necessariamente precisam ser executados de forma sequencial, mas eles geram insumos e conhecimentos para o processo de melhoria contínua e a adoção propriamente dita do Kanban (podendo, inclusive, serem revisitados conforme a necessidade).
Os passos são:
- Entender o propósito do serviço para o cliente;
- Entender as fontes de insatisfações com o atual sistema de trabalho (internas e externas);
- Analisar as demandas;
- Analisar a capacidade do grupo;
- Analisar e modelar os fluxos de trabalho;
- Criar as classes de serviço;
- Modelar o sistema Kanban;
- Negociar e implementar mudanças através do trabalho colaborativo e feedbacks.
Como podemos ver nesta listagem, encontramos tanto uma etapa relacionada à demanda quanto à classe de serviço (destacados em negrito) e ali os assuntos começam a se misturar. Não entraremos em méritos de exploração a fundo desses dois passos, e sim aprender a diferenciar e entender como as demandas e classes de serviço se relacionam. Quando falamos de demandas, automaticamente lembramos de User Stories, Bugs e afins. Mas, como enquadramos estas demandas de trabalho para que recebam o tratamento adequado em termos de priorização ou urgência?
Vamos por partes:
O que caracteriza os tipos de demandas?
Todo item de trabalho, ou demanda, possui um conjunto de informações que a definem e que podemos chamar de suas características. Dentre essas características podemos destacar a motivação que existe por trás desta tarefa, a natureza do trabalho que será desenvolvido (A criação de algo novo, uma melhoria ou uma correção por exemplo), o solicitante, a persona que irá interagir com o resultado daquele trabalho, dentre outras.
Através desse conjunto de informações, conseguimos agrupar estes itens de acordo com suas semelhanças e damos origem aos tipos de demanda. Utilizando como exemplo demandas de desenvolvimento de software, alguns tipos de demanda que são classicamente utilizados por todos (ou quase todos) os times de desenvolvimento são:
- Funcionalidades – Implementação de um novo requisito de negócio ou funcionalidade em um determinado produto e/ou serviço para entregar valor ao usuário final;
- Bugs/Correções – Correção de algum problema identificado após uma implementação anterior e que possivelmente está impactando em algum tipo de uso em uma ou mais funcionalidades;
- Melhoria Evolutiva – Melhoria em alguma funcionalidade ou comportamento já existente;
- Tarefa – atividade não necessariamente relacionadas a uma funcionalidade em específico (ex.: Criar documentação do projeto).
A utilização ou não destes tipos ou até de algum outro em específico devem ser consideradas mediante ao contexto, necessidade do time ou do escopo de trabalho daquele momento. Existem outros tipos como os Spikes/PoC(Proof of concept), que correspondem a esforços temporários de pesquisa e validação antes de uma implementação efetiva, e que podem ou não fazer sentido dependendo do tipo de atividade que a equipe desempenha. Equipes de outras áreas de negócio como suporte ou vendas, muito provavelmente terão tipos de demandas diferentes a se trabalhar. Resumindo, os tipos de demanda dizem respeitos aos diferentes tipos de trabalhos que uma equipe precisa lidar, de acordo com suas características comuns.
Classes de serviço: O que são? Onde vivem? Do que se alimentam?
Como dito anteriormente, os diferentes tipos de demandas (ou até mesmo diferentes demandas do mesmo tipo) podem exigir diferentes tipos de tratamento de acordo com suas características. É aí que entram as Classes de Serviço. Cada classe de serviço corresponde a uma forma diferente de tratar as demandas de trabalho de um time diferenciando-o em termos de priorização, senso de urgência e fluxo de trabalho baseado nas suas próprias definições. Baseado nas suas próprias definições, nascem o que chamamos de políticas explícitas do processo.
As políticas são regras e acordos definidos pelo próprio time e orientam fluxos de trabalhos dentro do sistema. De acordo com o método Kanban, é importante que todas essas políticas sejam registradas e acessíveis ao time para que todos possam conhecê-las e aplicá-las no dia-a-dia de trabalho. Isto contribuirá para uma melhor gestão de riscos e aumentará a previsibilidade de entrega mediante o seu enquadramento e também trará alinhamento de expectativas com todas as pessoas envolvidas com a demanda.
Existem 4 tipos de classes de serviço que comumente são utilizadas com o método Kanban. São elas:
- Expedite – Itens de grande urgência e que necessitam serem trabalhados e entregues o quanto antes pois podem trazer grandes impactos em pouco tempo. Ex.: Um bug que parou completamente o funcionamento de um e-commerce de larga escala ou uma oportunidade de venda ou criação de um produto que está em alta/tendência no mercado e nas redes sociais;
- Fixed Date (Ou Date-Driven) – Quando a demanda precisa ser entregue até um prazo fixo, geralmente relacionado a uma situação eventual ou sazonal, e que faz sentido apenas ser entregue antes do acontecimento (ex.: Um hotsite de promoções para o dia das mães) ou a algum tipo de implementação regulatória ou legislativa e que pode gerar uma penalidade se não entregue até aquela data.
- Standard – Itens de trabalho comuns orientados segundo uma priorização explícita por algum tipo de critério (urgência, valor de entrega, ordem de pedido etc.) que o time irá trabalhar quando não houver nada com maior urgência (como um item expedite). Ex.: Uma nova funcionalidade de consulta em um sistema ERP.
- Intangibles – Demandas de trabalho que são difíceis de mensurar seus ganhos ou impactos a primeiro momento, mas que a médio ou longo prazo podem tanto causar prejuízos, caso não sejam cumpridos, quanto trazer bons resultados. Ex.: Atualizar documentação do projeto.
Agora algumas ressalvas:
O que quer dizer diferentes fluxos de trabalho? Itens com classes diferentes podem requerer outro tipo de processo em relação a como a demanda vai caminhar até a sua entrega. Para exemplificar melhor a definição apresentada anteriormente vamos imaginar que o processo padrão de um time seja composto da seguinte forma:
Uma nova demanda Expedite chega, e se trata de um bug na aplicação que parou toda a cadeia de produção. Esta tarefa precisa realmente passar por todos estes passos para ser entregue? Aparentemente não. Devido ao seu caráter de urgência e prioridade, ela provavelmente já nascerá como “Pronto p/ fazer” ou um membro do time irá parar sua tarefa atual para assumi-la e fará toda a análise pré-desenvolvimento já na fase de “Em andamento”. E também ao final, possivelmente não precisará de uma aprovação formal para ser submetida em produção.
Então todo bug é Expedite? Não necessariamente. Cabe ao PO ou time analisarem os verdadeiros impactos desta necessidade e mapear a sua criticidade e urgência de entrega frente ao problema que ele pode causar, ponderando também as tarefas que o time já está desenvolvendo.
Preciso seguir à risca e utilizar todas as classes de serviço? Não, isso pode variar conforme o contexto e a necessidade do time ou do negócio. Um time pode trabalhar apenas com Standard e Expedite, por exemplo.
Existem outras classes além destas? Com certeza! Time de diferentes contextos podem trabalhar com classes diferentes e ter explícito suas próprias políticas. Exemplo: Um time de suporte pode trabalhar com tarefas de classes como “Tickets”, “Atendimento VIP” e “Manutenção”.
Inclusive, podem ocorrer situações em que implicitamente algumas demandas são tratadas de forma diferenciada, porém não há uma política explícita para elas. São as chamadas Classes de serviços ocultas.
Um exemplo comum são demandas solicitadas por um CEO e que acabam não sendo encaixadas nas classes utilizadas pelo time, mas ainda sim furam fila na lista de prioridades. Neste caso, elas não atendem todos os requisitos necessários para serem enquadradas como expedites, por exemplo.
Se existe uma certa recorrência deste tipo de situação, é importante destacá-las através de uma classe de serviço para que o time possa de forma explícita e transparente saber como tratá-las e também mensurar quais impactos elas podem estar causando e, assim, poder negociar ou discutir este tipo de situação.
A Relação das Classes de Serviço com o Cost of Delay
O Cost of Delay, ou CoD, traz uma abordagem de caráter econômico de como uma demanda pode impactar financeiramente caso ela não seja entregue ou sofra um atraso no seu prazo ou deadline (ex: seja uma multa/penalidade ou a oportunidade de adquirir receita ou outro tipo de valor), servindo assim como ferramenta de priorização de trabalho e auxílio na tomada de decisão. Dentro do CoD temos algumas formas de exemplificar os diferentes tipos de impacto de acordo com a curva de relação de tempo x custo. Fazendo um paralelo com as classes de serviço exploradas anteriormente nós temos:
Expedite
Demandas priorizadas na classe de serviço expedite tem seu custo crescente de forma vertiginosa em pouco tempo, necessitando urgência no seu tratamento para minimizar o impacto gerado.
Fixed Date
Nesta classe, inicialmente temos um baixo custo devido ao prazo até a data específica, porém conforme esta data limite se aproxima, ela se eleva proporcionalmente ao risco e, quando atingido o deadline, que por sua vez é inegociável, temos uma mudança brusca na curva de custo de impacto até que ela volte a se estabilizar.
Standard
Já para as demandas de classe de serviço standard, o custo cresce de forma linear à medida que existe o atraso/demora na entrega e geralmente não ocorre uma variação no seu cálculo.
Intangible
Devido à dificuldade de mensurar seus impactos, perdas ou ganhos, a curva relacionada a classe de serviço intangível cresce de forma muito lenta mesmo a longo prazo, indicando um baixo risco e grau de impacto, pois possivelmente corresponde a ações de baixa prioridade.
Comparando demandas de diferentes tipos de classes de serviço, temos uma ideia mais clara de quais classes devem ser trabalhadas de forma prioritária devido ao seu impacto. Com demandas de um mesmo tipo (Standard, por exemplo), esta abordagem também te possibilita quantificar estes valores e compará-las entre si a fim de se chegar a uma tomada de decisão sobre quais itens são mais interessantes de se priorizar de acordo com algum ponto de análise (Ex.: receita esperada; redução de custos). Neste artigo escrito por Lucas Colucci, temos alguns exemplos de como calcular e comparar estes custos de atraso.
Conclusão
Vimos então que tipos de demanda e classes de serviço são diferentes categorizações, mas que se correlacionam, e juntas, podem criar um entendimento mais claro de todo um contexto que precisa ser desenvolvido pelo time em um determinado item de trabalho e quais são as políticas que precisam ser seguidas e respeitadas.
Atribuir corretamente as demandas de trabalho aos diferentes tipos de classes de serviço, auxiliará o time no processo de priorização e tomada de decisão quanto ao trabalho a ser feito. Além disso, suportado pelo lado econômico do custo de atraso, o time poderá mensurar o impacto da não entrega de uma demanda. Dessa forma, conseguimos alinhar as expectativas tanto do lado do cliente/solicitante da demanda, fornecendo previsibilidade e alinhando as necessidades desses clientes com as prioridades da empresa, quanto no lado do time, ajudando a controlar de forma saudável o capacity do time de acordo com as classes de serviço e a proporção de demandas existentes.
E você? Já havia utilizado estes conceitos antes? Se sim, houve ganho de valor após sua aplicação?
