Diga-lhes que este é apenas um nome amador para o campo Causa Raiz usado por profissionais (quando o rastreador de problemas não tem campo dedicado, pode-se usar comentários para isso).
Pesquise na web por algo como análise de causa raiz de bug de software , há muitos recursos para justificar esse raciocínio 1 , 2 , 3 , 4 , ... .
...a root cause for a defect is not always a single developer (which is the main point of this field)...
É exatamente por isso que "causa raiz" é profissional, enquanto "culpado" é amador. A responsabilidade pessoal é ótima, mas há casos em que simplesmente fica "fora" da equipe de desenvolvimento.
Diga ao seu chefe que quando houver um único desenvolvedor a culpar, o campo de causa raiz certamente cobrirá esse ( "erro de codificação cometido por Bob em commit 1234, omitido por Jim na revisão 567" ). O ponto de usar o termo causa raiz é cobrir casos como esse, ao longo com casos que saem do escopo da equipe de desenvolvimento.
Por exemplo, se o bug foi causado por hardware defeituoso (com a pessoa culpada por ser alguém fora da equipe que comprou e testou), o campo de causa raiz permite cobrir isso, enquanto "desenvolvedor único culpar "simplesmente quebraria o fluxo de rastreamento de problemas .
O mesmo se aplica a outros erros causados por alguém de fora da equipe de desenvolvimento - erros do testador, alteração de requisitos e decisões de gerenciamento. Digamos que, se a gerência decidir pular o investimento em hardware de recuperação de desastre, "culpar um único desenvolvedor" por uma queda de energia no datacenter simplesmente não faria sentido.