Simyl
simylflow
Início do Curso
Módulo 2: Visualizando Trabalho e Fluxo
Lição 4 de 5
12 min

Classes of Service

Tratando diferentes tipos de trabalho de acordo com seu custo de atraso.

1Além dos Números de Prioridade

A priorização tradicional (P1, P2, P3 ou Alta/Média/Baixa) tem problemas:

  • Tudo se torna "alta prioridade"
  • As prioridades não refletem a realidade econômica
  • Não há política clara sobre como lidar com cada nível

Classes de Serviço resolvem isso categorizando o trabalho com base nas consequências econômicas do atraso—o custo de atraso.

As quatro classes padrão são:

  1. Urgente: O atraso tem custo severo e imediato
  2. Data Fixa: O atraso após um prazo tem custo severo
  3. Padrão: O custo de atraso é linear (espera maior = proporcionalmente pior)
  4. Intangível: O custo de atraso não é claro ou é muito baixo

A Ideia Central

Classes de Serviço não são sobre o quão importante o trabalho é—são sobre o quão sensível ao tempo ele é. Uma funcionalidade criticamente importante sem prazo é Padrão, não Urgente.

2Classe Urgente

Definição: Trabalho onde o atraso tem consequências imediatas e severas.

Exemplos:

  • Produção está fora do ar
  • Vulnerabilidade de segurança descoberta
  • Prazo regulatório amanhã
  • Cliente importante prestes a cancelar

Políticas para Urgente:

  • Máximo de 1 item urgente por vez
  • Abandona todo o resto (até os limites de WIP)
  • Deve ser trabalhado ativamente até a conclusão
  • Requer autorização explícita (não autoatribuído)
  • Aciona análise de causa raiz depois (por que isso foi urgente?)

O teste: Se você completasse este trabalho em 2 dias em vez de 1 dia, algo terrível aconteceria? Se sim, pode ser urgente. Se não, provavelmente é Padrão.

Sinais de alerta de abuso:

  • Mais de 10% do trabalho é urgente
  • A fila de urgente nunca está vazia
  • As pessoas usam urgente para pular a fila

3Classe Data Fixa

Definição: Trabalho que deve ser concluído até uma data específica, após a qual perde valor significativo.

Exemplos:

  • Funcionalidades para promoção da Black Friday
  • Prazo de conformidade regulatória
  • Compromisso de lançamento com parceiro
  • Demo de conferência

Políticas para Data Fixa:

  • Deve ter data explícita anexada
  • Priorizado mais cedo com base nos requisitos de lead time
  • Pode reservar capacidade para garantir conclusão
  • Check-ins regulares conforme o prazo se aproxima

O insight chave: Trabalho de Data Fixa precisa começar mais cedo, não se mover mais rápido. Se seu lead time médio é 10 dias, um item de Data Fixa com prazo em 12 dias deve começar agora, não em 2 dias.

Diferente de Urgente, Data Fixa não abandona tudo—apenas garante que o trabalho comece cedo o suficiente para terminar no prazo.

Boa Gestão de Data Fixa

Uma funcionalidade de conformidade tem prazo em 3 semanas. O lead time médio é 2 semanas. A equipe começa agora, monitora o progresso e tem margem para problemas.

Má Gestão de Data Fixa

Uma funcionalidade de conformidade tem prazo em 3 semanas. A equipe trata como 'ainda não urgente' e começa com 1 semana restante. Heroísmo se segue.

4Classe Padrão

Definição: Trabalho onde o custo de atraso é aproximadamente linear—esperar mais é proporcionalmente pior, mas não catastrófico.

Exemplos:

  • A maioria do desenvolvimento de funcionalidades
  • Correções normais de bugs
  • Melhorias internas
  • Solicitações de clientes sem prazos rígidos

Políticas para Padrão:

  • FIFO (primeiro a entrar, primeiro a sair) dentro da classe
  • Sujeito aos limites normais de WIP
  • Sem tratamento especial

Este é seu padrão. A maioria do trabalho deve ser Padrão. Se suas filas de Urgente e Data Fixa estão constantemente cheias, algo está errado—seja com seu sistema ou com como o trabalho é classificado.

5Classe Intangível

Definição: Trabalho onde o custo de atraso não é claro, é muito baixo ou só se manifestará no futuro distante.

Exemplos:

  • Redução de débito técnico
  • Melhorias de documentação
  • Pesquisa exploratória
  • Funcionalidades "bom ter"
  • Manutenção proativa

Políticas para Intangível:

  • Prioridade menor que Padrão
  • Pode ter alocação de capacidade dedicada (ex: 20%)
  • Funciona como "preenchimento" quando nada mais está esperando
  • Revisado regularmente—ainda vale a pena fazer?

A armadilha: Trabalho Intangível nunca é feito porque o trabalho Padrão é infinito. Solução: alocar capacidade explícita. "Gastamos 15% da capacidade em débito técnico" protege este trabalho.

A outra armadilha: Trabalho Intangível é na verdade valioso, apenas com retorno atrasado. Ignorá-lo cria problemas depois. Rastreie-o separadamente para ver se você está investindo o suficiente.

Se você não fez nenhum trabalho Intangível em um mês, provavelmente está acumulando dívida invisível. Reserve tempo para isso intencionalmente.

6Implementando Classes de Serviço

Opção 1: Raias por classe Mais visual e clara. Quatro raias horizontais, o trabalho flui da esquerda para a direita dentro de cada raia. Urgente no topo, Intangível embaixo.

Opção 2: Cor ou tag do cartão Menos impacto visual, mas funciona quando você já usa raias para outra coisa.

Opção 3: Quadro de urgente separado Algumas equipes puxam trabalho urgente para um quadro dedicado de "sala de guerra" até ser resolvido.

Políticas a estabelecer:

  • Como o trabalho é classificado? (Quem decide, quais critérios?)
  • O trabalho pode mudar de classe? (Geralmente: subir é fácil, descer requer discussão)
  • Qual capacidade vai para cada classe?
  • Com que frequência a classificação é revisada?

Comece simples: Apenas Urgente e Padrão. Adicione Data Fixa quando tiver trabalho realmente orientado a prazos. Adicione Intangível quando estiver pronto para proteger trabalho de investimento.

Principais Conclusões
  • Classes de Serviço categorizam trabalho por custo de atraso, não importância
  • Urgente, Data Fixa, Padrão e Intangível têm políticas diferentes
  • A maioria do trabalho deve ser Padrão—se não for, algo está errado
  • Trabalho Intangível precisa de capacidade protegida ou nunca acontece
Armadilhas Comuns a Evitar
  • Marcar tudo como Urgente (derrota o propósito)
  • Não alocar capacidade para trabalho Intangível
  • Tratar classes como prioridade em vez de sensibilidade ao tempo
  • Perder prazos de Data Fixa por não começar cedo o suficiente