Ideia principal

Um product manager que trabalha há três anos com o mesmo desenvolvedor não precisa escrever o que precisaria escrever para um desenvolvedor que chegou há três meses. Um time que se fala todo dia pode deixar certas coisas no oral; um time novo, distribuído ou metido em um assunto arriscado precisa explicitar mais. A quantidade de texto necessária não é uma propriedade do assunto, é uma função do que os dois lados já têm em comum.

Daí vem o desvio simétrico ao das três linhas largadas: impor modelos em todo lugar, acrescentar campos, transformar cada cartão em um mini-dossiê, escrever para se proteger em vez de escrever para trabalhar. Referências como a Definition of Ready e a Definition of Done ajudam enquanto continuam vivas; passam a atrapalhar assim que substituem o julgamento sobre o que o outro já sabe.

Por que isso importa

Isso explica por que um padrão de escrita importado de um time para outro fracassa com tanta frequência: ele carrega uma quantidade de texto calibrada para um contexto compartilhado que aqui não existe.

Isso também aponta a variável que importa acompanhar. Um turnover, uma chegada, uma passagem para o trabalho distribuído aumentam a necessidade de escrita sem que nenhum assunto tenha mudado.

Nuances e limites

O contexto compartilhado torna a escrita menos necessária para o time atual, não para o que vier depois. Um ticket compreendido por duas pessoas já não é compreendido pela terceira que chega, nem pelo mesmo time seis meses depois.

E a avaliação do que já é "compartilhado" é otimista por natureza: quem escreve superestima o que o outro tem na cabeça.

Questões em aberto

• Como detectar que o contexto compartilhado caiu, antes que os mal-entendidos apareçam no trabalho entregue?