Modelo de tempo v2
Modelo definido em sessão Gabriel + Ana 2026-06-02 (consultoria ABM).
Princípio
Section titled “Princípio”O tempo de um card tem três zonas distintas que precisam ser medidas separadamente:
[ Wait Intake ] → [ Lead Time (fluxo ativo) ] → [ Pós-entrega ] Criar Nova Execução / Dev / QA Aprovação cliente task / Briefing / Ajustes (gargalo cliente)Fórmulas
Section titled “Fórmulas”| Métrica | Fórmula | Significado |
|---|---|---|
| delivered_at | MIN(completed_at, entered_Aprovação_cliente) | Quando valor passou pro cliente — o que vier primeiro |
| Wait Intake | entered_dev_or_exec − created_at | Fila pré-trabalho. Não conta em Lead/Cycle |
| Lead Time | delivered_at − entered_dev_or_exec | Dev → entrega cliente |
| Cycle Time | completed_at − entered_dev_or_exec | Dev → cliente aprovou formalmente |
| Aprov age | today − entered_Aprovação_cliente (só status=active) | Fila do cliente segurando aprovação |
Cycle − Lead = dias na fila do cliente até closure formal.
Categorização de fases
Section titled “Categorização de fases”Wait (não conta em Lead/Cycle)
Section titled “Wait (não conta em Lead/Cycle)”ID | Nome (ABM/MWM) | Nome (Mercosul) ---|---|--- 46467 | Criar Nova task | — 47236 | Briefing | — 47479 | — | Briefing 47519 | — | Nova Task 47520 | — | Análise 47480 | — | Kick-off
Work (conta em Lead/Cycle)
Section titled “Work (conta em Lead/Cycle)”ID | Nome ---|--- 47478 | Execução 47203 | Desenvolvimento 47204 | QA (ABM) 47532 | Ajustes 47521, 47486 | Desenvolvimento Front-End (Mercosul, 2 IDs por typo) 47522, 47497 | Desenvolvimento Back-End (Mercosul) 47487, 47523 | QA (Mercosul) 47484 | Design (Mercosul) 47483 | Documentação (Mercosul) 47491, 47526 | Pré-Publicação (Mercosul)
Delivered (= delivered_at)
Section titled “Delivered (= delivered_at)”ID | Nome ---|--- 47205 | Aprovação cliente (ABM/MWM) 47525, 47489 | Aprovação Cliente (Mercosul)
Post (fora do escopo)
Section titled “Post (fora do escopo)”ID | Nome ---|--- 47206, 47527 | Publicação 47496, 47529 | Monitoramento 47528, 47495 | Divulgação 47488 | Aprovação Desenvolvimento 47494 | Aprovação Documentação
Caveats importantes
Section titled “Caveats importantes”Lead ≈ Cycle (limitação de dados)
Section titled “Lead ≈ Cycle (limitação de dados)”entered_dev_or_exec é proxy via primeira HoursLogged em fase de trabalho (não temos CardMoved formal independente). Por isso, em quase todos os cards, entered_dev_or_exec ≈ first_HoursLogged_in_work_phase → Lead ≈ Cycle.
A diferença real só aparece em cards que tiveram fase de Aprovação cliente registrada antes do completed (raro em MWM/Mercosul, comum em ABM).
Cards untracked
Section titled “Cards untracked”Cards sem HoursLogged em fase de trabalho identificável são excluídos de Lead/Cycle. Em MWM isso corresponde a 78% dos cards (board usado como lista, cards fecham em “Criar Nova task” sem fase intermediária). Não é erro do modelo; é uma descoberta sobre o uso real do board.
Wait Intake negativo
Section titled “Wait Intake negativo”Em poucos cards o entered_work_first aparece anterior ao created_at — provavelmente bug de sincronização Ekyte. Tratado como max(0, wait_intake_d).
Squads usam Aprovação cliente de forma desigual
Section titled “Squads usam Aprovação cliente de forma desigual”- ABM: 46 cards atualmente em Aprovação cliente. Protocolo usado de fato.
- MWM: 0 cards. Fase ignorada.
- Mercosul: 1 card. Fase ignorada.
O modelo v2 explicita essa diferença em vez de homogeneizar.