Ideia principal

Avaliar saídas probabilísticas, manter uma memória de produto consultável, escrever uma documentação utilizável tanto por uma máquina quanto por um humano, manter um repositório legível, formular critérios de aceitação nítidos, orquestrar o encadeamento de ferramentas: nada disso é novo. Esses trabalhos já existiam, dispersos, sustentados por quem tinha tempo, e ninguém perdia grande coisa ao negligenciá-los.

Assim que um time coloca agentes para trabalhar, eles deixam de ser periféricos. A qualidade do contexto fornecido determina a qualidade do que é produzido, e um contexto que ninguém mantém degrada todas as saídas ao mesmo tempo. O que era zelo vira condição de funcionamento.

Essas necessidades não viram necessariamente cargos. Elas viram responsabilidades que precisam ser atribuídas — e a pergunta feita a um time equipado não é mais "quem faz o quê?", mas "quem julga, quem constrói, quem garante, quem avalia, quem mantém a memória, quem orquestra?".

Por que isso importa

Isso explica por que dois times com as mesmas ferramentas obtêm resultados muito diferentes: a diferença não está na ferramenta, está no que ninguém tinha a incumbência de sustentar.

E dá uma lista de responsabilidades a atribuir explicitamente antes de constatar a ausência delas, em vez de depois de uma saída errada ter ido para produção.

Nuances e limites

Tornar essas responsabilidades visíveis não diz como equipá-las. Um time que as atribui sem liberar o tempo correspondente obtém uma lista de donos nominais e o mesmo abandono de antes.

E algumas dessas cargas são transitórias: a confiabilidade das ferramentas avança, e uma responsabilidade de avaliação dimensionada para o estado atual dos modelos pode ficar desproporcional.

Questões em aberto

• Quais dessas responsabilidades ganham em ser sustentadas por uma pessoa dedicada, e quais se degradam assim que saem do time que produz?