Centenas de tickets por lançamento, enfim contados

Não economiza um dia de trabalho de ninguém

E é justamente esse o ponto. Ele responde uma pergunta que a operação não sabia responder sobre si mesma.

Duas leituras de um lançamento

Peguei os tickets de correção de uma marca e montei duas visões deles. A primeira contava, página por página, quantas correções foram necessárias, quantas eram prioridade, quantas viraram ticket, quantas eram bug. A segunda media tempo: quanto as correções levaram, separado por tipo, por prioridade e por tipo de página. Juntas, foram os primeiros números que alguém teve sobre o que um lançamento custa de verdade.

De uma aba para um painel para um app

Aquilo virou um painel do trabalho de uma pessoa, semana a semana e mês a mês: páginas atualizadas, SLA, tempo de entrega, erros e os bloqueios que vinham de fora do time. Depois virou um web app, feito em Apps Script, onde cada um vê os próprios tickets contra KPIs que nós mesmos escolhemos.

Dois deles carregam quase tudo. Acerto de primeira conta os tickets que não precisaram de retrabalho, o que é outra pergunta, bem diferente de quão rápido eles fecharam. E um sistema de pontos de complexidade dá preço ao trabalho, então um time com vinte tickets difíceis para de parecer mais leve que um time com trinta fáceis.

O que isso dá para quem gerencia

Produtividade por quadrante, quais stakeholders geram mais retrabalho, que tipo de tarefa come mais tempo, de onde os atrasos estão realmente vindo. Nada disso deixa um processo mais rápido. O que faz é tornar a operação discutível: feedback deixa de se apoiar em impressão, pedido de headcount deixa de se apoiar em tom de voz, e a conversa entre áreas passa a ter alguma coisa além do que cada um lembra.