Ideia principal

"Um Product Manager pode subir código para produção?" é uma pergunta mal formulada, porque espera uma resposta única onde o produto não é homogêneo. A pergunta útil é sobre a área: traduções, conteúdos, painéis e telas somente de leitura têm risco baixo; pequenas ações de escrita e alterações de interface bem delimitadas, risco médio; pagamento, permissões, segurança, dados sensíveis, lógica de negócio crítica e arquitetura, risco alto.

Esse recorte não segue as fronteiras dos produtos. Um software regulado contém telas de consulta relativamente seguras; um produto de aparência inofensiva contém uma área muito sensível assim que toca permissões ou uma decisão de negócio irreversível. É a área, portanto, e não o domínio, que fixa o nível de exigência.

A analogia funciona com a chegada de um desenvolvedor júnior: ninguém entrega o motor a ele no primeiro dia, começa-se por escopos simples e amplia-se conforme a competência se comprova. A mesma escada vale para um perfil de produto que constrói — desde que a competência, o contexto e as proteções avancem juntos.

Por que isso importa

Isso substitui um debate identitário por uma decisão praticável: em vez de definir quem tem direito de contribuir, define-se quais áreas estão abertas e sob quais condições.

E protege contra os dois excessos: a proibição geral, que congela a contribuição, e a abertura geral, que deixa alguém alterar uma regra de faturamento no dia em que aprendeu a abrir um pull request.

Nuances e limites

O mapa de riscos tem custo de manutenção, e envelhece: uma área tida como segura fica menos segura assim que uma integração a liga a um fluxo sensível.

E o risco não se reduz à área tocada: uma alteração inofensiva num componente compartilhado se propaga por todo lugar onde ele é reutilizado.

Questões em aberto

• Quem estabelece e mantém atualizado o mapa das áreas de risco, num time em que várias profissões contribuem para o mesmo repositório?