Medir o sistema, não as pessoas: um case para SDMs

Há alguns anos assumi a agilidade de uma estrutura global de engenharia, uma operação de venda direta ao consumidor com roadmap agressivo para o ano, que não tinha como responder à pergunta mais básica de gestão: estamos dando conta? Este ensaio conta como mapeei essa estrutura, desenhei quatro KPIs de fluxo (Workload, Team Overhead, Productivity e Efficiency) e implementei o processo que os sustentava. É um relato para Service Delivery Managers, enterprise agilists e qualquer gestor ou especialista que precise criar visibilidade onde hoje só existe opinião - e emplacar práticas numa estrutura que resiste a elas.

O SDM, ou Service Delivery Manager, é o papel do Método Kanban que responde pela saúde do serviço que um time entrega: cuida do fluxo, do risco e das cadências, e mede o sistema de produção em vez das pessoas que o tocam. É a cadeira de onde escrevo este case.

O cenário: todo mundo “usava Kanban”

Eram cerca de oito times de produto, organizados em value streams numa topologia orientada a serviço, cuidando de uma plataforma de e-commerce global. Se você perguntasse a qualquer time qual era o método de trabalho, a resposta vinha sem hesitar: Kanban. Na prática, os times trabalhavam de maneira ametódica: o que existia era um quadro com colunas. Sem políticas explícitas, sem limite de WIP, sem métricas, sem cadências de revisão. Chamar isso de Kanban, e pronto, é uma falácia que merece um ensaio próprio; por ora, interessa o que ela custava.

O custo era visibilidade. Ninguém sabia dizer se o ritmo de entrega estava bom ou devagar, se a capacidade dos times comportava o roadmap, se fazia sentido pedir mais pessoas ou montar mais times. As conversas com a gestão eram disputas de percepção: quem contava a melhor história saía com a prioridade.

E havia uma pergunta que quase ninguém fazia: os times estão sobrecarregados? Essa preocupação era minha e dos desenvolvedores - de mais ninguém. Mas quem gerencia entrega não pode tratar sobrecarga como sentimentalismo. Um sistema saturado entrega menos, erra mais e queima as pessoas que você vai precisar no trimestre seguinte. Numa estrutura com tantos times, confiar que tudo estava sendo bem priorizado, bem entendido e bem desenvolvido não era um luxo que podíamos pagar.

Antes das métricas, um princípio

Eu poderia ter começado plugando uma ferramenta no Jira e despejando dashboards sobre os times. É o erro mais comum, e o assessment que conduzi me convenceu a não cometê-lo. A decisão de desenho que veio antes de qualquer fórmula foi esta: medir o sistema, não as pessoas.

Disso decorre quase tudo:

• Nada de story points. Velocity mede acordo interno de estimativa, não capacidade de entrega. Eu queria métricas de fluxo: contagens e tempos que o próprio quadro produz. Menos agilidade lúdica, mais agilidade enterprise: adaptativa, acionável, objetiva.
• Carga de trabalho com o mesmo peso das métricas de resultado. Perseguir produtividade e eficiência sem olhar a saúde do sistema de produção não se sustenta. Se workload não estiver no mesmo painel, o painel vira chicote.
• Time se compara com o próprio histórico. Cada sistema de produção tem características próprias; comparar o time A com o time B é estatística de corredor. A primeira camada de leitura é sempre o contexto do time; depois o value stream, depois a estrutura.

Quatro KPIs que times de engenharia entendem

Os quatro indicadores eram calculados por mês fechado, time a time, a partir dos status do Jira, com uma ferramenta de analytics de fluxo fazendo a coleta. O resultado não era um número solto: era uma classificação em faixas, que qualquer gestor lia de relance e qualquer desenvolvedor sabia explicar.

Uma ressalva antes das fórmulas: as faixas abaixo foram calibradas para aquele contexto, observando o histórico daqueles times. Copie o desenho, não os números.

1. Workload - o sistema está cheio demais?

Mede quanto trabalho está nas mãos do time em relação ao tamanho dele. A conta usa apenas os status de codificação (de “em desenvolvimento” até “pronto para build”), porque o ponto de vista aqui é o time de desenvolvimento.

WIP/Dev = média de WIP no período ÷ quantidade de devs no time

A faixa ótima fica perto de um item por pessoa - e não é coincidência. Acima disso, o esforço se espalha em threads paralelas, o senso de prioridade se dilui e o modo “apagar incêndio” vira rotina. Workload foi o KPI que transformou a sobrecarga de impressão em dado: em vez de “o time parece afogado”, passamos a dizer “este time está Very Heavy há dois meses”.

2. Team Overhead - quanto trabalho espera depois do código?

Aqui chamei de overhead tudo o que já saiu da mão de quem codifica mas ainda não chegou à produção: filas de build, testes integrados, aprovação, UAT. A mecânica é a mesma do Workload, trocando os status observados.

PC WIP/Dev = média de WIP pós-codificação no período ÷ quantidade de devs

Quanto menor, melhor. E overhead alto raramente é culpa do time de desenvolvimento: ele denuncia gargalos a jusante (ambientes, aprovações, janelas de deploy) e antecipa retrabalho e deploys arriscados. Foi o KPI que tirou discussões de “o time está lento” e as colocou onde pertenciam: no desenho do fluxo depois do código.

Esse KPI não nasceu de catálogo. Nasceu de um comportamento que eu via todo mês: quando as demandas entravam na fila de UAT, os times mergulhavam nas demandas novas e subestimavam a chance de o trabalho “quase pronto” voltar - vez ou outra havia ajustes a fazer, os tais defects. Nas estimativas de esforço e de concorrência de trabalho, os devs tinham um viés de desconsiderar exatamente o que eles mesmos haviam colocado na fila para UAT. Era essencial parar de começar e começar a terminar. Mas também não podíamos nos dar ao luxo de deixar desenvolvedores parados, esperando os testes completos dos seus itens em UAT; estávamos entre a cruz e a espada. A regra de ouro que combinamos: o que está mais à direita do board tem prioridade, porque o WIP precisava diminuir sempre que possível.

Havia ainda um agravante: as subidas eram represadas em releases. E pra mim, trabalho só acaba quando está em produção, funcionando adequadamente. Enquanto espera a release, o item carrega potencial de retrabalho - e a organização inteira tinha um viés gigantesco de ignorar isso. Quando esse trabalho aparecia, era contado como trabalho oculto que minava a produtividade: uma carga ingrata, porque o que estava planejado atrasava por causa dele, mas importante e necessária. Criei na estrutura duas consciências que não existiam: a de que os itens de uma release têm potencial de gerar trabalho, e a de que essa etapa do ciclo de vida do software não pode ficar sem gestão nem visibilidade. O Team Overhead foi a forma de dar número a isso.

3. Productivity - comparado com quem? Com o próprio time

Vazão (throughput) do mês comparada com a vazão do mês anterior. Simples assim, e é proposital: o índice não compara times entre si, compara o time com o registro dele.

Prod Index = TP do mês ÷ TP do mês anterior

O contexto define o que é bom. Time recém-formado deveria alternar entre Stable e Increase: está construindo ritmo. Time maduro e sem turnover tende a Stable, e está tudo bem: estabilidade é o que torna previsão possível. Um Decrease isolado é conversa; três seguidos são diagnóstico.

Esse desenho não passou sem briga. A pressão era contínua, vinda da governança geral da organização, dos stakeholders e da minha própria liderança: réguas padronizadas de entrega, que todos, todos os times deveriam seguir e pelas quais seriam medidos. Mas eu conhecia o que diferenciava cada time, do básico ao estrutural - a quantidade de pessoas, a stack, se era front ou back, se era um time de plataforma ou de orquestradores superdependente de times de fora da nossa estrutura, se cuidava de uma engine sem dependência de ninguém. Defendi, contra-argumentei, nadei contra a maré, trouxe dados e narrativa direto das trincheiras. Régua única compraria uma falsa sensação de conforto por conformidade: a aparência de padronização implementada, produzindo métricas de vaidade, não acionáveis.

Pra você ter uma noção do absurdo que seria: eu tinha um time de orquestradores com cycle time na casa dos 23 a 30 dias e um time de front, cuidando de componentes web, com cycle time de 3 a 5 dias. Daria para medir os dois pela mesma régua? Claro que não. A alternativa que propus foi a verificação histórica de cada time pelas próprias métricas, com uma coleta de dados de fluxo e de entregas que eu vinha preparando desde o ano anterior. Com ela, os perfis dos times foram mapeados de verdade, e a evolução pôde ser proposta time a time - com base no histórico e nas narrativas das SDRs, onde os envolvidos traziam à tona os aprendizados, facilidades e dificuldades.

4. Efficiency - quanto da vazão é corroída por problemas?

Qualidade é fator de eficiência: cada pausa para corrigir é capacidade que deixou de virar entrega. O índice relaciona a vazão do período (TP, throughput: itens entregues no mês) com os problemas que surgiram nele, separados em dois tipos: bugs (problemas de itens já entregues, que voltam para o quadro) e defects (sub-bugs de itens ainda em desenvolvimento).

Cada tipo vira uma razão: quantos problemas líquidos apareceram para cada item entregue no mês. Líquidos porque desconto os que foram cancelados pelo caminho - abertos por engano, duplicados ou inválidos. São dois números irmãos, um para bugs e outro para defects, cada um dividido pela vazão:

TP/NBR (bugs) = (bugs novos - bugs cancelados) ÷ TP TP/NDR (defects) = (defects novos - defects cancelados) ÷ TP Ineff Index = (TP/NDR × 2 + TP/NBR) ÷ 3

O nome veio do dashboard e engana à primeira vista: apesar do “TP” na frente, a conta divide o saldo de problemas pela vazão, não o contrário. Leia cada razão como “bugs (ou defects) líquidos por item entregue”. Se um time fechou 20 entregas e acumulou 4 bugs líquidos no mês, seu TP/NBR é 0,2 - um bug para cada cinco itens, ou 20%. O Ineff Index só junta as duas razões numa nota só, dando peso dobrado ao defect.

Os defects pesam dois terços do índice de propósito: eles falam do fluxo de agora, enquanto bugs costumam falar de entregas passadas. Um time com Ineff Index alto está acelerando em piso escorregadio: há esforço, mas pouca tração.

Aqui também nadei contra a maré. A governança queria medir eficiência contando bugs, e pronto: quantos bugs por feature, quantos bugs por time. Voltei atrás e indaguei os conceitos: o que significa ser eficiente? Não é rapidez - é executar da melhor forma, sem esforço nem custo desnecessário. Se a esteira de desenvolvimento fosse fluida, com demandas bem documentadas e sem ambiguidade sobre o que era esperado, devs e QAs produziriam mais e com mais qualidade. Por isso reforcei a cultura de logar defects. Quando o QA apenas falava o problema para o dev resolver, o insumo se perdia: ninguém entendia o que, normalmente, era um problema de qualidade do desenvolvimento, portanto de fluidez, portanto de eficiência. Defects colocavam custo operacional e fricção no processo; trazer à tona seus motivos e suas estatísticas era crucial.

O efeito apareceu nas SDRs, as revisões mensais de que falo adiante: passamos a discutir os defects das demandas, tirar aprendizados e parar de sofrer com certas causas raízes (ou, no mínimo, mitigá-las bastante).

A leitura é em composição

Nenhum desses KPIs diz muita coisa sozinho. Workload Heavy + Productivity Decrease sugere saturação: o sistema está cheio e por isso entrega menos; a resposta é limitar WIP, não cobrar ritmo. Workload Optimal + Productivity Decrease pede outra conversa: algo mudou no time ou na demanda. Productivity Increase + Efficiency Low é o falso positivo clássico: a vazão subiu empurrando problema para frente. Quem lê um indicador isolado e age sobre ele costuma piorar o sistema que diz gerenciar.

A implementação é o produto

Se eu tivesse apenas publicado essas fórmulas numa wiki, este ensaio não existiria. O que fez os KPIs funcionarem foi o que veio antes e ao redor deles.

Assessment de verdade, com todas as funções do fluxo. Antes de implementar qualquer coisa, sentei com quem vivia cada etapa do trabalho, do upstream ao downstream: gerentes de projeto, gerentes de produto, arquitetos de solução, gerentes de engenharia, desenvolvedores, lideranças. Mapeei como a demanda nascia, por onde passava, onde esperava. Cada métrica foi ajustada e combinada com essas pessoas antes de existir em dashboard. Métrica imposta vira teatro: ou é ignorada, ou é gameada.

Treinamento em trilha, não em palestra. Montei uma trilha com três degraus: gestão de fluxo e Método Kanban para todos (o básico que ninguém tinha); previsibilidade via forecasting com métricas acionáveis; e módulos de aprofundamento para os gestores da estrutura, cobrindo as práticas de métricas e previsibilidade em detalhe. Cada pessoa sabia quais métricas existiam, como eram colhidas e como interpretá-las, direto ou em composição. Quem não entende a métrica tem medo dela.

Cadência: a Service Delivery Review. Implementei SDRs recorrentes, a cadência do Kanban que olha para a saúde do serviço que o time presta. Sempre sobre o mês fechado, com dados preparados antes da reunião: cycle time no percentil 85 (total, pré-desenvolvimento e desenvolvimento), aging do WIP, eficiência de fluxo, taxa de chegada contra taxa de entrega. O time olhava para os itens reais daquele período e discutia como estava trabalhando. A métrica não era a estrela da reunião; era o ponto de partida da conversa.

E eu fazia questão de que a SDR fosse agenda da squad inteira. Antes, as retrospectivas eram só do dev team e amétódicas: as três coluninhas de “o que foi bem, o que foi mal, plano de ação”, sem olhar para o trabalho. Os tais defects ocultos, quando vinham à tona na narrativa de um dev, chegavam ao designer, ao QA ou ao PM por telefone sem fio. Todos podiam e deviam estar naquela agenda de inspeção e adaptação, ouvindo em primeira mão, sem ruído, entendendo as dores do meio produtivo e onde os processos precisavam melhorar. Foi uma mentalidade que me esforcei para aculturar na estrutura. E consegui.

Um time enxuto de agilidade. Eu liderava um grupo pequeno de agilistas que cobria os times com um plano de práticas mínimas: SDRs recorrentes e olho na saúde do fluxo. Não havia agilista por squad, e não fez falta: com método claro e métricas combinadas, pouca gente sustenta muita estrutura. O Kanban Maturity Model serviu de mapa nas decisões de profundidade; o processo foi customizado para os desafios daquela estrutura, não transplantado de um livro.

O que fica para um SDM

Se eu tivesse que reduzir essa experiência a uma sequência reutilizável:

1. Mapeie antes de medir. Assessment com cada função do fluxo, upstream ao downstream. O desenho dos KPIs sai daí, não do benchmark da moda.
2. Combine antes de implantar. Métrica acordada gera conversa; métrica imposta gera defesa.
3. Meça fluxo, não pessoas. WIP, vazão, tempos, problemas. Nenhum indicador individual: o sistema é a unidade de gestão.
4. Classifique em faixas, não em metas numéricas. “Optimal” e “Heavy” orientam decisão; “WIP/Dev 1,47” vira meta a ser gameada.
5. Leia em composição. Um KPI isolado mente com facilidade; quatro juntos contam uma história.
6. Treine quem vai interpretar. A trilha de treinamento vale tanto quanto a fórmula.
7. Dê cadência. Sem uma SDR recorrente, métrica é foto na parede. Com ela, é instrumento de navegação.

O resultado mais valioso não apareceu em dashboard nenhum: as conversas mudaram. Pedir mais pessoas deixou de ser queda de braço e virou análise de capacidade. Sobrecarga deixou de ser queixa e virou faixa vermelha num painel que a gestão acompanhava. Não saímos dali com times perfeitos - saímos com uma estrutura capaz de se enxergar. Para quem gerencia entrega, esse é o primeiro KPI que importa.

E se você é o SDM ou o especialista tentando emplacar algo parecido na sua estrutura, use este case sem cerimônia. Liderança rígida, com pouca vontade de entender antes de prescrever, raramente amolece com teoria; amolece com dado, com narrativa vinda das trincheiras e com um caminho que já funcionou em algum lugar.