O projeto não termina no Figma

Já entreguei projeto impecável que foi ao ar irreconhecível. A culpa não era de quem implementou. Era minha, por ter entregado um arquivo em vez de um sistema.

Arquivo mostra um estado. Sistema explica a regra. Quando só existe o estado, cada situação nova vira uma invenção de alguém no meio do caminho, sem que essa pessoa tenha contexto para inventar bem.

A pergunta que separa um do outro é simples: o que acontece com esse componente quando o texto tem o triplo do tamanho? E quando o campo dá erro? E quando não tem dado nenhum?

Se a resposta não está no que eu entreguei, alguém vai decidir. E vai decidir com pressa, no fim da sprint.

ENTREGA NÃO É UM MOMENTO, É UMA FASE

Parei de tratar a entrega como um e-mail com link. Ela é uma fase do projeto, com tempo previsto no orçamento, porque sem esse tempo ela acontece de qualquer jeito, só que de graça e mal.

Nessa fase eu documento estado vazio, estado de erro, limite de caractere, comportamento em tela estreita e o que é regra contra o que é exemplo. Essa última distinção é a que mais evita retrabalho.

Também combino o que pode ser decidido sem mim. Não por controle, mas o contrário: quanto mais claro o que é livre, menos gente trava esperando resposta.

VOLTAR DEPOIS É PARTE DO SERVIÇO

Marco uma revisão algumas semanas depois de no ar. Não para fiscalizar ninguém, para ver o que a realidade fez com o projeto.

É sempre a hora mais útil do trabalho inteiro. Aparece o texto que ninguém previu, a tela que virou improviso, a regra que era clara para mim e não era para mais ninguém.

Anoto tudo e levo para o projeto seguinte. Metade do que eu sei hoje sobre entregar bem veio dessas visitas, não de estudar processo.

O trabalho que fica é o que sobreviveu ao contato com o mundo. O resto é portfólio.