Ideia principal

Quando um Product Manager sobe um pull request e um desenvolvedor entrevista clientes, a conclusão tentadora é que as responsabilidades se dissolvem junto com os escopos. Acontece o contrário: a confusão dos papéis torna a designação dos responsáveis mais necessária, não menos.

Uma escolha de produto continua sendo uma escolha de produto — visão, posicionamento, coerência, arbitragens, leitura do mercado, sinal do cliente — e cabe ao produto. Uma escolha técnica continua sendo uma escolha técnica — segurança, desempenho, capacidade de aguentar carga, arquitetura, manutenibilidade — e cabe à técnica. Uma escolha de experiência continua sendo uma escolha de experiência — design system, coerência de uso, acessibilidade, nível de exigência — e cabe ao design ou ao front.

A organização que funciona, portanto, não é aquela em que cada um faz tudo no seu canto: é aquela em que cada um pode intervir além do seu domínio inicial porque há responsáveis que estabeleceram os padrões, as proteções e os limites. É a clareza dessas três linhas que autoriza o transbordamento, e não o contrário.

Por que isso importa

Isso inverte uma intuição comum sobre times autônomos: não é apagando as fronteiras que se ampliam as contribuições, é nomeando quem responde pelo quê.

E dá uma ordem de operações a um time que quer abrir: designar os responsáveis primeiro, abrir os escopos depois.

Nuances e limites

Os três domínios não se recortam de forma limpa. Uma escolha de arquitetura compromete o custo das evoluções de produto futuras, uma escolha de experiência impõe restrições técnicas: o responsável decide dentro do seu domínio, ele não decide sozinho o que a decisão produz em outro lugar.

E um responsável pode virar um gargalo: se tudo tem que passar por ele, a função de garantia se transforma em autorização prévia, e a abertura que ela deveria permitir se fecha.

Questões em aberto

• Como um responsável estabelece um padrão explícito o bastante para que as contribuições o sigam sem precisar consultá-lo toda vez?