Entregar é um hábito

Existem engenheiros que entregam e engenheiros que quase entregam. A distância entre eles não é talento. Pela minha experiência, em muitos projetos e muitos times, não é nem esforço. É um hábito, e hábitos podem ser construídos de propósito.

Quero descrever o hábito com a maior precisão possível, porque "só entrega logo" é conselho inútil. Ninguém decide não entregar. Decide fazer mais uma coisa antes, e a mais uma coisa não tem fim.

Defina "pronto" antes de começar

O engenheiro que quase entrega começa com uma ideia do que a funcionalidade deveria ser e vai refinando enquanto constrói. Pronto é uma sensação. O engenheiro que entrega escreve, antes da primeira linha, o que "pronto" significa: qual usuário consegue fazer qual coisa, verificado como. Pronto é uma frase numa página.

Parece burocrático e leva uns cinco minutos. Muda tudo, porque quando vem a tentação de acrescentar mais uma coisa, você olha a frase e vê que a coisa não está nela. Vai para a lista da próxima vez. O trabalho atual é entregue.

Entregue a menor coisa que seja verdadeira

Aprendi isso numa bancada de conserto muito antes de escrever código. Você não conserta tudo na placa e depois testa. Conserta um defeito, liga, e vê se era aquele. Mudança pequena, retorno imediato, próxima mudança.

Em software o mesmo ritmo é assim: a menor fatia que um usuário real consegue tocar vai para produção primeiro. Não a funcionalidade inteira. A primeira parte verdadeira dela. Um formulário que salva mas ainda não valida. Um endpoint que devolve dados reais para um cliente. Cada fatia ensina algo que o plano não sabia, e cada fatia é um deploy, então o caminho de deploy fica aquecido e sem susto.

Torne o release entediante

Times que entregam raramente têm ritual de release, noite de release, pessoa do release. Times que entregam com frequência não têm nada disso, porque lançar é tão rotineiro que não tem cerimônia. Se o seu release é um evento, você vai evitá-lo, e evitar é como a funcionalidade quase pronta cresce por três meses.

O trabalho prático aqui é infraestrutura, e vale fazer antes da funcionalidade: um comando para subir, um comando para reverter, um health check que diga em um minuto se o deploy está saudável. Com isso no lugar, entregar uma mudança pequena dá menos aflição do que não entregar.

Pare de polir o que ninguém viu

Perfeccionismo é o principal inimigo desse hábito, e digo isso como alguém que é descrito como obcecado por detalhes. A diferença é para onde vai o detalhe. Sou obsessivo com a correção do que sai: a migração é reversível, o timeout existe, o erro é tratado. Tento não ser obsessivo com a completude do que sai. Correto e pequeno vence completo e não lançado.

O teste que uso: algum usuário real já viu isso? Se não, o polimento é especulativo. Você está decidindo o que importa sem a única fonte de informação que diria.

A parte que se acumula

É por isso que é hábito e não técnica. Cada vez que você entrega, a próxima entrega fica um pouco mais fácil. O caminho de deploy está mais aquecido, a definição de pronto mais natural, o medo menor. Cada vez que você adia, acontece o contrário. A branch cresce, o merge assusta mais, a funcionalidade acumula escopo, e o próximo adiamento fica mais provável.

Depois de repetições suficientes, o hábito vira identidade. Você é a pessoa que entrega. As pessoas te trazem trabalho porque sabem que vai sair do outro lado. Essa reputação, na minha carreira, valeu mais do que qualquer tecnologia que conheço.

Então comece esta semana. Pegue a coisa que você está quase terminando. Escreva uma frase que defina pronto. Corte tudo que não está na frase. Entregue. Depois faça de novo na quinta.