Skip to content

Mercosul

Mercosul é o único squad com workflow real (Briefing → Análise → Dev → QA → Aprovação cliente → Pré-Pub → Publicação), mas:

  1. Manutenção e Projeto compartilham fases — cards de natureza completamente diferente passam pelo mesmo funil
  2. Taxonomia quebrada — fases duplicadas com typo (“Desenvolvimento Front End” + “Desenvolvimento Front-end” como IDs distintos)
  3. Cards Projeto carregam lead 100-200d — 4 elefantes (Site Logada, Página Serviços, Security, Tech Cast) inflam p85
  4. Aprovação cliente não está sendo usada — só 1 card ativo lá. Time fecha direto sem passar pela fase, mesmo padrão MWM (mas com cerimônia maior antes)
19
cards entregues 6w
16 tracked · 3 untracked
10.5d
Lead mediano
p85 69.2d · max 219d
0d
Wait intake mediano
p85 1.8d · max 31d
1
cards parados em Aprovação cliente
idade med 22d · max 22d

Lead Time Control Chart — Dev → entrega cliente

16 cards · linhas p50/p85 referenciam SLE

Cycle Time Control Chart — Dev → cliente aprovou (status=completed)

16 cards · Cycle − Lead = dias na fila do cliente

Scatter Wait × Lead (log/log)

Cards no canto inferior-esquerdo = saudáveis. Tamanho = horas em Dev.

Distribuição — Lead Time (Observable Plot)

Histograma de lead times. Cauda à direita = outliers.

Distribuição — Wait Intake (escala symlog)

Symlog comprime cauda. Concentração em 0-1d = intake saudável.

Entrega por semana

Cards entregues por semana de delivered_at.

Cards ativos por fase — onde está o WIP agora

237 cards ativos no squad

Horas reais por pessoa nos cards entregues 6w

HoursLogged.executor — bus factor real do squad. Difere de assignee do mart.

  1. Split do board: Mercosul Manutenção × Mercosul Projeto — boards separados, classes de serviço distintas, métricas separadas. Não é refactor de tooling, é mudança de leitura.
  2. Consolidar fases duplicadas “Front End” / “Front-end” (e equivalentes Back End / Back-end / QA / Pré-Publicação). 1 hora de config no Ekyte.
  3. Política aging Briefing > 14d — onde cards do squad ficam parados antes de virar trabalho.
  4. Investigar uso de Aprovação cliente — por que ABM usa e Mercosul não? Diferença de cliente, de gerente, ou de hábito?

O CFD do Mercosul tem duas histórias sobrepostas: a camada fina superior (manutenção) flui rápido — wait→work→completed em poucas semanas. Embaixo, a banda amarela de “wait” engorda e não drena: são os cards de Projeto stuck em Briefing/Análise por 100+ dias. Mesmo board, dois regimes de fluxo incompatíveis.

CFD — Cumulative Flow Diagram (7 snapshots semanais)

Áreas empilhadas = cards em cada categoria por semana. Banda crescente = acúmulo. Banda estável = fluxo. Diagonais paralelas = saudável; bandas divergentes = gargalo formando.

Monte Carlo — forecast a partir do histórico 6w

Section titled “Monte Carlo — forecast a partir do histórico 6w”
Sample base: 19 cards entregues em 42 dias · média 0.45/dia · 36 dias sem entrega · pico 5/dia. 10 000 simulações bootstrap por horizonte. Probabilidades = "qual a chance de entregar pelo menos X".
5
cards em 14d (p50 — chute central)
12
cards em 28d (p50)
p85 ≥ 6 · p95 ≥ 3
18
cards em 42d (p50)
p85 ≥ 11
39d
para entregar 10 cards (p85)
p50 23d · p95 50d

Forecast 4 semanas — distribuição de quantos cards o squad entrega

Bootstrap diário do throughput observado. Verde = mais provável. Vermelho = cauda pessimista (15% das simulações).

Service Level Expectation — Lead Time histórico

SLE empírica: "85% dos cards entregues em ≤ 69.25d" (n=16). Use como contrato com cliente.

Quanto tempo para entregar N cards

Alvo p50 (mediana) p70 p85 p95
5 cards 12d 17d 24d 35d
10 cards 23d 30d 39d 50d
20 cards 45d 56d 67d 81d

p85 = "85% das simulações terminaram em ≤ X dias". Use como compromisso defensável; nunca p50 (50% de chance de furar).

  • 3/19 cards sem TT em fase de trabalho identificável.
  • Agregado mistura Manutenção (~12 cards) com Projeto (~6 cards). Stats medianas sofrem menos; p85/max sofrem muito.
  • 4 cards de “Projeto” (Site Logada, Serviços, Security, Tech Cast) com lead > 70d puxam p85 sozinhos.
  • Sem CardMoved formal, transições intra-board são inferidas via phaseId mudando em TT consecutivos. Cobertura 47% — não usar como argumento de “fluxo” por si só.