Autor: João Grabosque
🏥 Um hospital não trata todas as suas demandas (pacientes) da mesma forma e prioridade, pelo contrário, ele possui um processo de triagem bastante robusto e racional para identificar a criticidade e risco envolvido e é baseado nessa classificação que ele sabe quem precisa passar na frente de quem e como deve tratar cada caso.
🚑 Um paciente que chega com uma fratura exposta certamente passará na frente de outro que chegou primeiro mas que está apenas com uma dor de cabeça. Sem falar que o processo de atendimento de ambos será bastante diferente também.
Na maioria dos hospitais hoje, o processo de classificação de riscos utilizado é o Protocolo de Manchester, que dentre tantas coisas, existe para tentar garantir uma maior eficácia e imparcialidade do atendimento além de contribuir também para um sistema de trabalho mais eficiente e previsível.
No Kanban, exercitamos essa mesma essência por meio da utilização de Classes de Serviço que classificam as demandas de acordo com o perfil de risco e o Custo do Atraso (Cost of Delay) associado.
💸 O conceito de Custo do Atraso aqui está relacionado a quanto perdemos ou deixamos de ganhar por atrasar a entrega de determinada demanda. Ele nos ajuda a entendermos de uma forma racional qual o momento mais adequado para iniciarmos cada demanda nos baseando em critérios econômicos e no impacto que elas geram no negócio.
O Kanban sugere quatro classes que você pode utilizar conforme fazem sentido para seu contexto ou até mesmo implementar outras que melhor atendam suas necessidades.
🎁 Classe Standard (Padrão)
Representam a maior parte das demandas que lidamos no dia a dia e possuem um custo de atraso moderado que cresce linearmente com o passar do tempo, sem muitas variações e portanto, toleram prazos de entrega mais longos. Ex: uma nova funcionalidade que deve trazer mais eficiência operacional ao produto.
📆 Classe Fixed Date (Data-Fixa)
Representam demandas onde o custo do atraso está diretamente ligado a uma data fixa pré determinada, geralmente relacionada a uma situação sazonal ou eventual. Essas demandas normalmente não agregam valor se entregues antes da data, porém em caso de não cumprimento dela o custo sobe rapidamente ou perdem o sentido de serem entregues. Ex: demandas regulatórias com multa atrelada ou lançamentos em dias comemorativos, como black friday, dia das mães…
❔ Classe Intangible (Intangível)
Representam demandas onde é difícil avaliarmos seus ganhos e impactos hoje, mas que a médio ou longo prazo sabemos que tendem a causar prejuízo ou trazer bons resultados, dependendo do caso. Elas possuem um perfil de risco baixo onde a curva do seu custo do atraso cresce lentamente e por isso, são tratadas como menor prioridade. Ex: dívidas técnicas existentes no código fonte do produto.
🚨 Classe Expedite (Urgente)
Representam demandas onde o custo do atraso sobe rapidamente em pouquíssimo tempo, exigindo uma maior urgência e atenção para minimizar o impacto gerado (a famosa “onça pegando fogo”). Devido a essa sua característica elas devem ser executadas imediatamente podendo, inclusive, furar a fila e passar na frente das demais. Ex: um bug crítico que impede o funcionamento completo do sistema em produção.
🚧 Além de passarem na frente das demais furando, inclusive, o limite de WIP se necessário, Expedites devem ser gerenciados com o máximo de atenção de forma a não pararem em filas de espera e, se possível, avançarem por um fluxo mais curto, contendo apenas as etapas imprescindíveis.
⚠️ Mas cuidado! Sacrificamos muitas coisas em prol de encurtar significativamente o lead time dessas demandas e isso tem um custo alto e sofremos os efeitos disso, portanto, devemos usar essa classe com bastante consciência.
“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the development mindset of an organization.” – Don Reinersten
Na Prática
📌 Importante lembrar que as classificações e o custo do atraso de uma determinada demanda não são imutáveis, ou seja, podem apresentar mais de um comportamento durante o seu ciclo de vida, exigindo assim que alteremos sua classe e consequentemente a forma como devemos tratá-las dentro do fluxo conforme as circunstâncias vão mudando.
Exemplo: uma demanda regulatória que nasceu como Fixed Date pode se tornar Expedite caso a data limite seja ultrapassada e uma penalização seja aplicada para cada dia em atraso.
📌 Outro ponto fundamental é não confundir as classes de serviço com os tipos de demandas (work item types), como defeitos, melhorias, suporte, etc. Esses descrevem uma outra categorização também necessária mas que não está diretamente relacionada ao perfil de risco e demais conceitos que vimos até aqui. Sendo assim, podemos ter melhorias de classe Expedite ou defeitos em produção de classe Standard sem nenhum problema.
“Como um guia geral, você deve oferecer no máximo seis classes. Será muito complicado administrar e operar muitas delas. O número de classes deve ser pequeno o bastante de maneira que todos possam lembrar-se de todas elas, e o suficiente para oferecer flexibilidade na resposta às demandas do cliente.” – David Anderson
🧐 Assim como no hospital usam pulseiras coloridas para facilitar a visualização das diferentes classificações de risco, no Kanban sugerimos alterar a cor dos cartões ou até mesmo separá-los em raias diferentes de acordo com cada classe. Veja o exemplo abaixo:
Conclusão
📝 No final das contas, as Classes de Serviço devem descrever um conjunto de políticas que determinam a forma como as demandas deverão ser priorizadas e tratadas dentro do nosso fluxo de trabalho para atendermos as diferentes expectativas dos clientes, levando em consideração o impacto no negócio, o valor agregado, o risco e o custo do atraso.
🚀 Essas políticas favorecem o processo de priorização, diminuem o custo de coordenação e potencializam o trabalho em equipe, pois todos passam a saber exatamente o que precisam fazer em cada caso e os impactos envolvidos em cada um deles.
😉 Se você ainda não utiliza o conceito de Classes de Serviço mas se interessou, considere começar aos poucos, incorporando gradativamente cada uma das classes que você julgar necessário e acompanhando evidências dos resultados obtidos por meio delas.
João Grabosque é Agile Coach, especialista em Métricas de Fluxo e responsável pelo curso Métricas Ágeis – Do Zero ao Avançado.
Amigo, colega de trabalho e aluno de André Suman, escreveu de forma voluntária para este blog.