Ideia principal

Uma regra transversal pode perfeitamente ser escrita no corpo de um cartão do Jira, em um comentário de especificação ou em uma linha de roadmap. Ali ela é exata, datada, encontrável pelo seu autor. E também está fora do alcance de todos os que ela diz respeito: o suporte que vai responder ao cliente, o comercial que vai prometer, o time que vai construir outra coisa seis meses depois.

Cada artefato tem um público e uma vida útil próprios. Um ticket se dirige a quem executa e morre na entrega. Uma roadmap se dirige a quem quer conhecer o horizonte e é reescrita a cada trimestre. Uma especificação se dirige a quem constrói um perímetro determinado. Colocar uma regra válida para a empresa inteira em um deles é dar a ela a audiência e a expectativa de vida deles — ou seja, torná-la inoperante em todo o resto.

O efeito é assimétrico e enganoso: a decisão existe, está escrita, dá para reencontrá-la se você souber onde procurar. Nada sinaliza que ela sumiu, já que ela não sumiu.

Por que isso importa

Isso dá um critério de arrumação que não depende do conforto do autor: um conteúdo vai para o lugar cuja audiência e duração correspondem às dele, não para o lugar onde você estava escrevendo.

E explica também por que uma organização pode ter tudo escrito e não saber nada: a questão não é saber se uma decisão está documentada, mas se ela está documentada onde quem depende dela vai lê-la.

Nuances e limites

A arrumação errada às vezes não tem consequência: uma regra que na verdade só diz respeito a um time está bem colocada nas ferramentas dele, mesmo que tenha a aparência de um princípio.

E um registro separado não garante a visibilidade: uma decisão guardada no lugar certo mas nunca anunciada continua desconhecida de quem não tem o hábito de ir até lá.

Questões em aberto

• Como identificar as decisões estruturantes já enterradas nos tickets e nas especificações de um time, sem reler tudo?