Classes de serviço e seus 4 principais arquétipos

Compartilhe

Classes de serviço e seus 4 principais arquétipos

27/09/23 - 9 minutos de leitura

Olho para o meu backlog e vejo dezenas de itens e tenho que priorizar o que está ali. Como fazer. Existem diversas formas. Já falamos sobre algumas delas: esforço e valor esperado, itens técnicos vs. itens de negócio, projeto de dados, Retorno sobre o investimento (RoI), backlog de demandas regulatórias e o Cost of Delay que serve de base para as Classes de Serviço. Já escrevemos como utilizar a inteligência coletiva para priorização e até mesmo sobre priorização em recrutamento e seleção.

O que são as classes de serviço

O que é serviço

Chamamos de serviço o trabalho que é prestado por um time, squad, unidade ou, até mesmo, um indivíduo para resolver a necessidade de um cliente. Seja interno ou externo. Se você é de um time de desenvolvimento de software, seu cliente são as pessoas que têm o problema que seu software resolve. O serviço que você presta é o desenvolvimento dessa solução.

Se seu time produz filmes para cinema, seus clientes são as pessoas que gostam daquele tipo de filme, têm a necessidade de se entreter e seu serviço é a produção do filme. Se você trabalha na Gestão de Pessoas (RH), seu time presta serviços que atendem as necessidades dos funcionários, estagiários e terceirizados daquela empresa. Tudo é um serviço, por isso temos as classes de serviço.

Definição das classes de serviço

As classes de serviço ou em inglês Class of Service, também conhecidas pelo acrônimo CoS são formas de classificar os itens de trabalho em relação ao risco que temos em não concluirmos em tempo hábil ou atrasarmos sua entrega. É a resposta à pergunta: Quanto eu perco se atrasar a entrega?

De acordo com a Kanban University são: níveis de serviço específicos definidos por políticas e aplicados aos itens de trabalho.

Os 4 arquétipos de classes de serviço mais utilizados

Tentarei explicar os 4 arquétipos das classes de serviço através de alguns exemplos ao longo desta seção. Nos quatro apresento também o gráfico comum que nos auxilia a definir em que tipo de classe está o nosso serviço. Para ler esses gráficos perceba o seguinte. No Eixo X você tem o tempo e no Eixo Y o Custo de Atraso (Cost of Delay). Quando a reta anda para a esquerda, o tempo está passando e não entregamos o item de trabalho que estamos analisando. Quando a reta anda para cima, significa que estamos aumentando o nosso risco de deixar de ganhar dinheiro ou até mesmo tomar um grande prejuízo.

Intangível (Intangible)

A primeira que nós temos é a intangível. São aqueles itens de trabalho que não sabemos qual o impacto que eles trarão se atrasarmos sua entrega. Merecem atenção porque muitas das vezes são aquelas atividades que as pessoas dizem que não têm valor. Entretanto, isso não é verdade, pois o fato de não conseguirmos mensurar, não significa que o item não tem valor.

Quer um exemplo? Em desenvolvimento de software muitas das vezes tomamos alguns atalhos (eufemismo para gambiarra) para poder entregar as demandas em tempo hábil. Temos um código-fonte que funciona, mas é aquele código-fonte que converte outros desenvolvedores. Quando eles abrem esse código-fonte cheio de "atalhos" as expressões são tipo: "Meu Deus do céu, como isso está em produção?", "Jesus, quem escreveu isso?". Neste último caso, o pior é quando descobrimos que fomos nós mesmo que escrevemos. Isso gerou até um meme: 

Homem branco, cabelo preto, vestido de terno cinza e gravata azul, olhando para a tela do notebook com a mão no queixo. Atrás dele uma estante com 3 prateleiras e cada uma com dois ou três fichários azuis. Na imagem aparece a frase: Quando escrevi esse código só eu e Deus entendíamos o que ele fazia. Agora, só Deus sabe.
Meme das dívidas técnicas

O fato é que o software funciona, resolve o problema do cliente, porém é como se fosse um prédio erguido sobre palafitas. Se não consertarmos, mais cedo ou mais tarde, vai desmoronar tudo.

Outras profissões têm problemas similares: professores que devem atualizar seu material, motoristas que devem fazer a revisão de seus veículos, especialistas em processos que têm que revisar aquele procedimento estabelecido em 1995. Até mesmo você que deveria fazer aquele check-up da sua saúde e fica adiando a ida ao médico.

Perceba que todos esses itens têm valor. Se não consertar logo o software a manutenção e evolução dele será impossível. Se o professor não revisar o material ensinará um conteúdo irrelevante ou até mesmo errôneo. Se o motorista não revisar seu veículo, "vai dar pt." (perda total). Se o pessoal de processo não revisar aumentaremos desnecessariamente nossos custos podendo levar a empresa à falência. Você, se não fizer o seu check-up, pelo menos tenha a decência de fazer um plano funerário. Não deixe despesas para a família.

Arquétipo da classe de serviço Data Fixa. Um gráfico cujo eixo X é o atraso e o eixo Y é o custo de atraso.  A linha vai em zero até a metade do gráfico, tem uma mudança brusca para cima e termina
Arquétipo Intangível

Você pode não saber quando esses eventos acontecerão e não consegue dimensionar exatamente o resultado, mas você sabe que acontecerão. Olhando para o gráfico temos o seguinte. O Custo de Atraso é baixo durante a maior parte do tempo, pois o impacto do evento ainda não aconteceu. Todavia, uma vez que ele acontece, o custo aumenta exponencialmente.

Padrão (Standard)

Geralmente é o arquétipo mais comum em um backlog. Você consegue mensurar o impacto de não entregar o item em determinada data. 

Imagine que você é o responsável por lançar um novo produto de seguro de vida para clientes premium na sua fintech. Sua empresa estima que esse novo produto gerará uma receita de $10 milhões em três meses. Não é um produto novo para o mercado, pois várias empresas do setor financeiro já o oferecem e você também já oferece outros produtos similares. Também não há um evento de lançamento agendado.

Se você lançar o produto em julho, você ganha os $10 milhões até setembro. Se lançar em outubro, você ganhará $9,7 milhões até dezembro. A exposição ao risco sempre existe. O fato de atrasarmos a entrega produz perdas. Por exemplo, se você só lançar em março do próximo ano, você só conseguirá $6 milhões, pois seus clientes não ficaram parados, a inflação não ficou parada, seus concorrentes não ficaram parados. Haverá perdas.

Arquétipo da classe de serviço Data Fixa. Um gráfico cujo eixo X é o atraso e o eixo Y é o custo de atraso.  A linha faz uma curva S
Arquétipo Padrão

Aqui vemos no gráfico que o custo de atraso de não entregarmos o item aumenta de forma inicialmente suave. Quanto mais tempo, maior a exposição a risco e menor o resultado que receberemos.

Data Fixa (Fixed Date)

A data fixa é exatamente o que o nome diz. O item de trabalho deverá ser entregue até uma data exata. Tal data pode ser definida de diversas formas. Por exemplo:

  • um contrato assinado que afirma que os itens A, B e C devem ser entregues até o dia X; 
  • um evento sujeito a modificações, por exemplo, final da Copa do Mundo, Grande Prêmio de Fórmula 1 em Interlagos, Olimpíadas;
  • uma data que não é sujeita a modificações: Natal, Ano Novo, dia das mães, pais, crianças etc.;
  • agendamento feito por instâncias superiores. Por exemplo, a empresa marcou um megaevento de lançamento do produto que seu time desenvolveu para o dia X em Armação dos Búzios, Rio de Janeiro com transmissão online para todo Brasil e contará com diversas pessoas convidadas.
  • A previsão de um evento futuro: ocupar todo o espaço de armazenamento do computador, temporada de furacões na Flórida e Caribe, mudanças de taxa de juros.

O fato é que está fora do seu domínio alterar a data acordada. 

Dia 25 de dezembro será Natal quer você queira ou não. Quer seu time tenha terminado o produto prometido ou não

Avelino F. Gomes Filho

Arquétipo da classe de serviço Data Fixa. Um gráfico cujo eixo X é o atraso e o eixo Y é o custo de atraso.  A linha vai em zero até a metade do gráfico, tem uma mudança brusca para cima e permanece na horizontal após isso.
Arquétipo Data Fixa

O Custo de Atraso aqui são nulos até a data fixada. Quando chegamos nela, elas consomem tudo de uma tacada só. Em outras palavras, todos os riscos se concretizam podendo inclusive tornar a conclusão da demanda irrelevante.

Acelerado (Expedite)

Comumente chamados como fura-filas. São itens tão urgentes que se não o fizermos, os riscos aos quais ficamos expostos aumenta de forma significativa. Por exemplo:

  • um erro no sistema que está impedindo o acesso dos clientes;
  • a descoberta de que um concorrente lançará um novo produto e dominará o mercado de forma que a entrada da nossa empresa será muito difícil, quiçá impossível;
  • um evento externo inesperado que criou uma oportunidade de mercado. Por exemplo: nos centros das grandes cidades, os vendedores ambulantes que aparecem com guarda-chuvas no momento que a primeira gota toca o chão;
  • sua empresa está sendo “cancelada” nas redes sociais;
  • uma falha de segurança gravíssima que foi descoberta.

Quando a dona Expedite te chamar, pare tudo e veja o que ela pediu.

Avelino F. Gomes Filho
Arquétipo da classe de serviço Data Fixa. Um gráfico cujo eixo X é o atraso e o eixo Y é o custo de atraso.  A linha é uma progressão linear de 10º. Sobe de forma muito íngrime e termina.
Arquétipo Expedite

Perceba que a subida do custo de atraso é linear, íngreme e começa a partir do dia zero. Se não o atendermos com máxima urgência as consequências poderão ser catastróficas ou veremos a concorrência surfando em um oceano azul.

O que o Lead Time tem a ver com a classe de serviço?

Em outros artigos falamos sobre a importância do Customer Lead Time e também de outras medições de Lead Time. Aqui serei sucinto e direi que o seu Customer Lead Time é o tempo decorrido desde o recebimento da demanda até a sua entrega. É muito importante saber qual o seu Customer Lead Time para poder definir em qual arquétipo de classe de serviço você deverá enquadrá-la.

Histograma de Customer Lead Time

Veja o Histograma de Customer Lead Time abaixo. 

Histograma de customer lead time. Sua leitura  é explicada no parágrafo abaixo. Temos no eixo X quantos dias durou o Customer Lead Time. No Eixo Y a quantidade de itens entregue no período. São eles: 0 entre 1 e 3, 4 em 4 dias, 7 em 5 dias, 12 em 6 dias, 11 em 7 dias, 14 em 8 dias, 18 em 9 dias, 20 em 10 dias, 28 em 11 dias, 26 em 12 dias, 18 em 13 dias, 14 em 20 dias, 10 em 15 dias, 16 em 6 dias, 4 em 17 dias, 1 entre 17 e 18 dias, 0 entre 20 e 21 dias e finalmente 1 entre 22 e 23 dias. Melhor caso = 4 dias, Moda = 11 dias, Mediana = 11 dias, Percentil 80 = 17 dias, Percentil 90 = 19 dias. 23 dias é o pior caso.
Histograma de Customer Lead Time

A leitura do histograma é a seguinte: no Eixo X temos os Customer Lead Times em dias. O Eixo Y é a quantidade de itens que foram entregues dentro daquele Customer Lead Time. Exemplo de leitura: 4 itens foram entregues em 4 dias, 7 itens foram entregues em 5 dias, 12 itens foram entregues em 6 dias. 

O histograma acima te dá algumas informações relevantes sobre o histórico desse time. Vamos a algumas delas:

  • Eles não entregam nada em menos de 4 dias (Melhor caso)
  • O período entre recebimento e entrega mais comum são 11 dias (moda)
  • Com 80% de probabilidade o time entrega um item em até 17 dias (Percentil 80 → P80)
  • Se tivermos mais aversão a riscos, com 90% de probabilidade o time entrega um item em até 19 dias (Percentil 90 → P90)

Classificando

O time recebeu uma demanda e deverá entregá-la em exatamente 45 dias. Olhando para o histograma, percebemos que 90% das vezes entregamos nossos itens em até 19 dias. Seria razoável classificar essa demanda como Data Fixa, pois, geralmente, levamos menos da metade do tempo para entregar itens similares a esse. 

O time recebe no mesmo dia outra demanda. Essa deve ser entregue em no máximo 12 dias. Agora temos um Expedite. Pois só conseguimos fazer uma entrega em até 12 dias 50% das vezes que tentamos (Mediana).

Os itens não são estáticos e mudam de classe

É interessante notar q ue os itens não são estáticos. Não é porque o item nasceu intangível que ele morrerá intangível. Imagine o seguinte caso, sabemos que a infraestrutura do software que desenvolvemos não é das melhores. Hoje, ela aguenta o número de clientes que temos, porém se conseguirmos mais clientes, ela poderá ruir. Já que não sabemos o impacto e não compreendemos exatamente quanto tempo será necessário para o evento acontecer, a demanda “Melhorar a infraestrutura do software” foi classificada como intangível.

Passado algum tempo, passamos a ter mais conhecimento sobre o produto e descobrimos que não fazer a demanda supracitada nos deixará exposto a um risco de $X e a cada semana que não fizermos essa melhoria o risco será acrescido em $X+1. Agora que o impacto é conhecido, a demanda se torna padrão.

Continuamos ignorando, o software cresceu, ganhou novas funcionalidades e novos clientes. O time de desenvolvimento fez uma análise e concluiu que, se mantido o crescimento, a infraestrutura entrará em colapso em 90 dias. Baseado no histograma acima, podemos definir que o item agora é um data fixa, pois sabemos a data do evento negativo.

Entretanto, continuamos ignorando o problema, já temos muitos clientes reclamando de lentidão e falhas no sistema são constantes. Começamos a perder clientes de forma vertiginosa. Agora, o mesmo item que nasceu como intangível se tornou um expedite.

Conclusão

Neste artigo vimos o que são classes de serviços, seus arquétipos e como classificar os itens de trabalho do seu backlog. Também vimos a introdução de uma ferramenta, o Histograma de Customer Lead Time que nos auxilia tanto na classificação, quanto na previsibilidade de entrega dos itens do nosso backlog. Espero ter ajudado. 

Dá uma olhada nesse vídeo para ver o bom uso de Classes de Serviço

K21 na Lean Kanban Brazil 2017 como utilizamos as classes de serviço para equilibrar orizontes de planejamento.

Quer saber mais sobre esse tema, faça o nosso treinamento de Team Kanban Practitioner ou Kanban System Design. Te vejo lá.

Compartilhe

Escrito por

Avelino Ferreira Gomes Filho

Trainer na K21


Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21
Esta postagem se encontra sob a licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Artigos relacionados

Cost of Delay para priorização de demandas
13/09/23
10 minutos de leitura
Eu acho que… Os riscos do achismo em projetos
05/10/18
5 minutos de leitura

    Receba mais conteúdos K21

    Deixe seu nome e email que nós te deixamos por dentro de tudo que rola por aqui.

    Ao informar meus dados, eu concordo com a Política de Privacidade.