Conteúdo5 seções
Hold: por que o processo é congelado antes de ser medido
Medir um processo que continua sendo mudado produz uma linha de base que não se sustenta. Hold para a deriva o tempo suficiente para obter um número real.
A etapa que ninguém quer pagar
Hold fica entre o diagnóstico e a medição. Não entrega nada. Não produz nenhum diagrama que alguém vá colocar num deck. E é, de forma confiável, a primeira etapa que um cliente pede para pular, com um argumento razoável à primeira vista: o problema está entendido, os candidatos escolhidos, por que não estamos construindo.
Porque o número que justifica a construção ainda não foi tirado, e não dá para tirá-lo contra um alvo móvel.
Processos se mexem enquanto você olha
Toda operação está sendo redesenhada informalmente o tempo todo. Alguém acrescenta uma conferência depois de uma semana ruim. Duas de quatro pessoas adotam um atalho. Um caminho de exceção inventado para um cliente chato é reaproveitado em mais nove.
Nada disso é má conduta. Tudo isso é invisível, porque ninguém anuncia, e tudo isso cai no meio de uma janela de medição.
O resultado é uma linha de base que é a média de dois processos, ponderada por quanto cada um rodou, sem como separá-los depois. Você não vai saber. Vai descobrir depois do go-live, quando a remedição honesta fizer a automação parecer aquilo que rendeu pouco.
O que o Hold congela
A definição, não o trabalho.
- Quais passos estão dentro do fluxo e quais estão fora.
- O que conta como exceção, escrito em vez de subentendido.
- Quem pode mudar qualquer uma dessas coisas enquanto a medição roda.
Em paralelo se fecham os buracos de dados que corromperiam a medição: o campo preenchido metade das vezes, os dois sistemas que discordam sobre o mesmo registro, o carimbo de tempo que registra quando alguém foi lançar e não quando o trabalho aconteceu.
O que quebra sem ela
A falha não é dramática, e é justamente por isso que sobrevive. O projeto anda, o build sai, e em algum ponto do mês dois os números param de bater entre si. A equipe lembra o processo antigo como mais lento do que a base diz. O fornecedor lembra como mais rápido.
Ninguém consegue provar nada, então a discussão é resolvida por hierarquia, e a resposta honesta - que a base foi tirada contra um processo que já não existia - nunca é dita em voz alta porque ninguém tem a evidência para dizê-la.
A alternativa é uma quinzena gasta em nada visível. Essa é a troca, e ela compra a única coisa que faz a medição seguinte valer alguma coisa: um processo que continuará sendo o mesmo quando os números voltarem. A disciplina mais ampla em que isso se apoia está em a auditoria antes da automação.
Onde ela fica
Hold é a segunda de seis etapas. A anterior decide o que vale a pena medir, e como essa decisão é tomada está em o que o mapa do Break mostra. A sequência completa, aplicada a um deploy, está em o protocolo de ponta a ponta.
01O que exatamente está sendo congelado?+
A definição do fluxo, não o trabalho. Ninguém para de fazer o próprio serviço durante o Hold. O que para é o redesenho informal que roda continuamente em quase toda operação: um passo acrescentado em silêncio no mês passado, uma regra que duas de quatro pessoas seguem, um caminho de exceção inventado para um cliente e usado desde então em nove. Essas mudanças costumam ser melhorias, e ainda assim são fatais para uma linha de base, porque o que se mede na semana três não é o que foi mapeado na semana um. O congelamento é uma declaração escrita de quais passos estão no escopo, quais casos contam como exceções e quem pode mudar qualquer uma dessas coisas durante a janela. Ele expira quando o Track termina.
02Por que não medir primeiro e estabilizar depois?+
Porque não dá para desmisturar uma medição. Se o processo mudou no meio da janela, o número que você tem é a média de dois processos ponderada por quanto tempo cada um rodou, e não há como recuperar os componentes depois. Você nem vai saber que aconteceu, porque a mudança não foi anunciada: foi alguém sendo sensato numa terça-feira. O custo de descobrir tarde não é só uma quinzena perdida: é que o build já foi dimensionado contra o número corrompido, e a primeira remedição honesta chega depois do go-live, onde se lê como a automação tendo rendido pouco e não como a base estando errada.
03O Hold chega a mudar o plano do Break?+
Com regularidade, e nas duas direções. Um candidato que parecia viável acaba dependendo de um campo que está preenchido corretamente em cerca de metade das vezes, o que o desce na fila ou o tira dela. Do mesmo modo, um fluxo adiado no Break justamente porque seus dados estavam sujos demais pode virar viável depois que o Hold fechou os buracos, e é repontuado em vez de abandonado. É por isso que a matriz de prioridades do Break é um documento e não uma decisão: ela existe para ser revisada uma vez, sobre evidência, antes de qualquer construção, e nunca mais depois.
04O que o cliente vê pelo dinheiro desta etapa?+
Um escopo escrito para cada fluxo alvo, uma lista dos problemas de dados encontrados e o que foi feito com eles, e uma política de exceções acordada, que costuma ser a primeira vez que alguém escreve o que a equipe já sabe pela metade. Gestores de operações tendem a achar a lista de exceções o artefato mais útil de todo o trabalho, porque é o documento que revela quantos casos especiais o processo carrega em silêncio. É também a razão de o build depois sair no prazo: uma exceção descoberta na semana três é um parágrafo, e a mesma exceção na semana nove é um pedido de mudança.
