Meu chefe decidiu adicionar um campo "pessoa responsável" a todos os relatórios de erros. Como convencê-lo de que é uma má ideia?

Em um dos mais recentes movimentos do "WTF", meu chefe decidiu que adicionar um campo "Pessoa a culpar" ao nosso modelo de rastreamento de bugs aumentará a responsabilidade (embora já tenhamos uma maneira de vincular bugs a recursos / histórias). Meus argumentos de que isso diminuirá o moral, aumentará o apontar com os dedos e não seriam responsáveis ​​por recursos ausentes / incompreendidos relatados como bug não foram ouvidos.

Quais outros argumentos fortes contra essa prática eu posso usar? Existe alguma redação sobre esse tópico que eu possa compartilhar com a equipe e o chefe?

Diga a eles que esse é apenas um nome amador para o campo Causa Raiz usado por profissionais (quando o rastreador de problemas não possui um campo dedicado, pode-se usar comentários para isso).

Pesquisar na web para algo como análise de software bug causa raiz , há uma abundância de recursos para justificar esse raciocínio ^{1 , 2 , 3 , 4 , ...} .

... a causa principal de um defeito nem sempre é um único desenvolvedor (que é o ponto principal desse campo) ...

É exatamente por isso que a "causa raiz" é profissional, enquanto a "pessoa culpada" é amadora. A responsabilidade pessoal é ótima, mas há casos em que ela simplesmente fica "fora" da equipe de desenvolvimento.

Diga ao seu chefe quando não é um único desenvolvedor para culpar, porque campo raiz definitivamente vai cobrir isso ( "erro de codificação feitos por Bob no cometer 1234, perdeu por Jim na revisão 567" ). O objetivo de usar o termo causa raiz é cobrir casos como esse, além de casos fora do escopo da equipe de desenvolvimento.

^{Por exemplo, se o bug foi causado por hardware defeituoso (com a pessoa culpada por alguém de fora da equipe que o comprou e testou), o campo da causa raiz permite cobrir isso, enquanto o "desenvolvedor único culpado" simplesmente quebraria o fluxo de rastreamento de problemas .}

^{O mesmo se aplica a outros erros causados ​​por alguém fora da equipe de desenvolvimento - erros do testador, alteração de requisitos e decisões de gerenciamento. Por exemplo, se a gerência decidir pular o investimento em hardware de recuperação de desastres, "culpar um único desenvolvedor" por uma falta de eletricidade no datacenter simplesmente não faria sentido.}

Outro resultado provável para essa política é que as pessoas não reportarão erros se acharem que podem ser a "pessoa culpada"; portanto, isso reduzirá o número de erros relatados pela equipe.

O principal argumento que eu usaria contra isso é perguntar qual problema ele está tentando resolver. Quase certamente existem maneiras melhores de resolver o mesmo problema.

Por um lado, existe realmente apenas uma pessoa para culpar? Se houver, você está fazendo outra coisa errada. Um bom processo exige um trabalho de um analista, programador, revisor e testador antes de chegar à produção. Se você não está realizando todos esses estágios, talvez seja a solução para o problema que seu chefe está tentando resolver. Se você é quem, então, deve culpar? Pode não ser nenhum deles, pode ser o código legado que é o culpado.

Não é bom ter pessoas mordendo as costas e apontando os dedos, tentando evitar uma marca negra que não desaparece quando estiver definida. Não resolve nada. Muito poucas pessoas são maliciosamente negligentes. Você precisa fazer uma retrospectiva adequada , ver o que deu errado e o que você pode fazer para garantir que não volte a dar errado.

A partir disso, você verá claramente se uma pessoa é regularmente culpada e isso pode ser um problema diferente de se lidar.

O truque para impedir um gerente de criar responsabilidade é oferecê-lo livremente , mas de uma maneira que realmente faça sentido para você.

Há pelo menos três problemas com esse campo.

A primeira é que culpar as pessoas não é bom para a moral. Está bem. Mas talvez ele não se importe com o moral e queira demitir desenvolvedores ruins. Difícil argumentar contra.

O segundo é que acertar esse campo vai ser difícil e um grande desperdício de tempo. É mais complexo do que apenas descobrir quem escreveu o código incorreto. E qualquer informação potencialmente difícil de descobrir pode ser ensacada / enganada. Mas talvez ele esteja preparado para pagar esse custo e auditar as informações. Bem.

A questão mais fundamental é que esse campo não será uma boa métrica para ação. Claro, ele terá uma boa classificação de cujo código causa mais defeitos. Mas adivinhe quem estará no topo dessa lista? Provavelmente, o fundador da empresa, ou talvez um dos principais desenvolvedores que tenha uma taxa de defeitos muito baixa, mas seja tão produtivo que ele escreva uma parte desproporcional do código. Então, ele acabará demitindo seu melhor desenvolvedor ou o fará desacelerar tanto que ele não será mais seu melhor desenvolvedor. E o cara que escreve uma linha de código por mês - de preferência comenta - provavelmente será recompensado por seus baixos números de defeitos.

Mais uma falha de métrica de software.

A causa raiz de um defeito em campo nunca é uma única pessoa. Pessoas perfeitamente conscientes cometerão erros, e um processo que espera que sejam infalíveis não é razoável. Se você não estiver verificando alterações nos sistemas de produção antes da implantação, manualmente ou através de testes automatizados, os bugs são inevitáveis.

Errado:

Bob se esqueça de verificar a entrada e o programa falhou ao dividir por zero.

Direito:

O código vulnerável a um erro de divisão por zero não foi detectado antes da implantação. Novos casos de teste foram adicionados para verificar o manuseio adequado de entradas inválidas. O código foi corrigido e todos os novos casos de teste estão passando.

Altere "Pessoa culpada" para "Pessoa elogiada"

A pessoa principal para consertar os bugs recebe o nome dele.

Resposta simples.

O campo "Culpa" será usado para nada além de bode expiatório e apontar os dedos, o moral despencará, a confiança da equipe será destruída e todos tentarão encontrar maneiras de provar que algo não é culpa deles, em vez de consertá-lo. As pessoas também estarão mais inclinadas a ficar caladas sobre bugs, em vez de denunciá-las, porque não querem que um colega tenha problemas. É completamente contraproducente.

O que é mais importante: vitimizar alguém por cometer um erro honesto ou resolver o problema o mais rápido possível?

Seu chefe parece pensar que insetos são um sinal de preguiça ou negligência. Eles não são. Eles são um fato da vida. Quantos patches a Microsoft realiza em um ano?

Se você deseja uma desobediência civil, peça à equipe que concorde em colocar uma lista de todos os desenvolvedores nesse campo para cada bug. Se isso não servir, escreva "Sou Spartacus!" em vez de. O ponto, é claro, é que todos são responsáveis ​​por todos os erros e não ficam felizes em apontar a pessoa que criou qualquer erro.

Outra opção: jogar junto. Não faça nada em particular - apenas faça um bom trabalho e preencha o campo com a maior precisão possível por alguns meses. Depois, explique ao chefe que atribuir a culpa a cada bug deixa todos na equipe infelizes e desconfortáveis. Diga a ele que todos sentem que há pouca correlação entre os bugs criados e qualquer outra coisa (habilidade, esforço, sanidade). (Ajudará se você puder executar alguns números que mostram que realmente não há uma correlação.)

Desobediência Civil Gandhiana: Coloque seu nome em todos os campos (a menos que outros desenvolvedores intensifiquem o nome de seus bugs) e aceite a culpa por todos os erros, sejam eles seus ou não. Nada tornará esse campo ou a idéia de culpar alguém mais inútil do que isso. Se o seu chefe perguntar por que seu nome está presente em todos os campos, você poderá explicar "porque eu não acho que o desenvolvimento seja um jogo de culpa. Se você realmente precisa que as pessoas culpem e crucifiquem, me crucifique por tudo e deixe minha equipe trabalhar pacificamente" . "

Certa vez, um chefe implementou um sistema muito semelhante a esse e, embora não estivesse programando (era um design de impressão para um jornal diário), o conceito e a resposta apropriada são os mesmos.

O que ela fez foi, em vez de adicionar um campo de "pessoa culpada" em nossa papelada, ela deu a cada um dos designers um conjunto de adesivos coloridos. Cada designer recebeu um adesivo colorido diferente e foi instruído que, para qualquer design trabalhado ou até mesmo tocado, o adesivo deve ser adicionado à papelada desse design.

O objetivo declarado do chefe da "iniciativa de adesivos" era estabelecer a fonte de todos os erros de nosso departamento (erros de papelada, erros de gravação, cópia incorreta, essencialmente o equivalente a erros de impressão)

O que fizemos foi dar a cada um dos outros designers um quarto de nossos adesivos, para que cada um de nós tivesse todas as cores e, em vez de colocar apenas a nossa cor em cada design, colocamos as quatro cores dos designers.

Não basta escrever seu nome na caixa [Culpa] - colocar o nome de todos que estão na equipe / projeto e garantir que toda a equipe faça o mesmo.

Nós trabalhamos juntos contra a sua maldade orwelliana e, como resultado, acabamos pegando erros uns dos outros e conversando sobre isso e, finalmente, tivemos uma redução significativa nos erros. Ela era uma gerente de merda, porém, e em vez de reconhecer que sua iniciativa acabou nos unindo e aumentando a produtividade, ela se irritou e dissolveu o sistema de adesivos, declarou-o um fracasso e formalmente repreendeu a todos nós.

Isso acabará punindo seu programador mais prolífico. As chances são de que uma ou duas pessoas possam ser os melhores funcionários que trabalharam na maioria dos projetos. Se você tem, em um departamento de 10 pessoas, um codificador que é apenas uma fonte de saída e ele escreve 60% do código da interface, 60% dos bugs estarão no código dele.

Explique que esse sistema faria parecer que a pessoa que escreve mais código é o pior programador e a pessoa que escreve menos código é o melhor programador.

Parece muito quando Scott Adams apontou a falida sabedoria de um Bug Bounty quando o Pointy Haired Boss em Dilbert. Wally anunciou que iria escrever um novo Mini Van para ele ".

Banda desenhada de Dilbert para 13/11/1995 a partir do arquivo oficial de banda desenhada de Dilbert.

Lembro-me de uma vez, quando o esqui na neve, alguém apontou que 'não cair' não era o sinal de um bom esquiador, mas muitas vezes o sinal de um que não tenta nada (ou que realmente não esquia).

Os erros podem ser introduzidos no código por má programação e design inadequado; mas também podem vir como conseqüência de escrever muitos códigos difíceis. Dinging pessoas que produzem mais erros é tão provável Ding desenvolvedores pobres como altamente produtivos.

Parece que seu chefe pode estar frustrado com o número de defeitos. As pessoas do seu grupo são apaixonadas por qualidade? Criar um campo "o quê" para a causa, em vez de um campo "quem", poderia ser mais produtivo. Ex: Alteração de requisitos, falha de projeto, falha de implementação, etc. Mesmo isso falhará, a menos que haja um grupo para melhorar a qualidade do produto.

Talvez você deva considerar "Quem está na melhor posição para corrigir o erro?" Uma parte de mim também sente, você quebrou, você conserta. Deve haver alguma responsabilidade.

Não concordo em manter algum tipo de pontuação. Algumas pessoas criam mais bugs porque trabalham em partes mais complexas do código. Se as linhas de código não são uma métrica útil, duvido que erros por linha de código sejam melhores. O código nunca será verificado.

Em algum momento, um gerente deve saber quem está fazendo seu trabalho e quem não está, bem como, quem faz isso melhor porque o resto da equipe faz.

É estranho que ninguém tenha mencionado isso antes: adicionar essa funcionalidade ao rastreador de bugs motivaria os funcionários a tentarem jogar no sistema .

Esse é um problema comum para abordagens como a que a pergunta apresentou, entre outras idéias semelhantes (pagamento por número de linhas de código, pagamento por número de bugs). Isso incentivará muitos a se concentrarem em obter uma boa pontuação, em vez de resolver problemas relacionados ao software em que estão trabalhando.

Por exemplo, tentar enviar um relatório de erro com uma redação para diminuir a própria culpa e colocá-lo em outra pessoa pode fazer com que os desenvolvedores não entendam a causa do problema (ou o trabalho sendo entregue a outro desenvolvedor que não conhece essa seção de um código tão bom quanto aquele que mais trabalhava nele e que era a principal causa do bug) levando a mais tempo e esforço para corrigir o problema.

Sua pergunta real era sobre como mudar a cultura antes de sair da empresa, convencendo seu chefe de que adicionar uma pessoa para culpar os relatórios de bugs é uma má idéia. Mas é claro que mudar a cultura exige que ele realmente entenda por que essa é uma má idéia.

Esta é uma tarefa difícil. Além da questão de salvar o rosto depois de mudar de idéia, existe o problema básico de que as pessoas que pensam em soluções principalmente em termos de culpa individual geralmente estão bem definidas nessa mentalidade.

Você pediu para escrever sobre esse tópico e o Peopleware vem à mente. É altamente considerado e fala em termos gerais sobre como gerenciar pessoas que fazem trabalhos criativos em que é difícil medir o resultado. O problema é que a leitura não ajuda muito, seu chefe precisaria ler e acreditar em pelo menos uma parte.

Estranhamente, como o problema aqui é mais sobre pessoas do que sobre relatórios de bugs, ele possivelmente pertence mais ao Local de Trabalho do que a Programadores. Mas o sucesso dos projetos de software geralmente é bastante rastreável à interação social humana, portanto, as respostas reais geralmente são principalmente sobre coisas que transcendem o software.

Minha única outra sugestão, meio séria, é dizer (ou convencer um colega de trabalho a dizer, desde que você planeja sair) que você está disposto a assumir total responsabilidade pelo sucesso do projeto, e seu nome sempre deve estar em campo , já que mesmo que alguém cometa o erro diretamente, você assumiu a responsabilidade de garantir que todos da equipe realizem um trabalho de qualidade.

É um absurdo, é claro, como você pode apoiar isso, mas algumas pessoas (especialmente as que são grandes culpadas) realmente comem isso. Ronald Reagan costumava aceitar publicamente a responsabilidade pessoal toda vez que algum membro de seu governo era pego em um escândalo (e havia muitos) e na verdade isso funcionava muito bem politicamente todas as vezes. A melhor parte para você é que a responsabilidade geralmente não traz consequências reais, elas apenas pensam que você é um cara de pé por assumir a responsabilidade.

Ou talvez não seja assim que vai acontecer. Não faz sentido para mim, por isso é difícil prever quando isso funcionará, mas eu testemunhei isso funcionar quando parecia que não havia negócios (no local de trabalho, não apenas no exemplo de Reagan).

As pessoas não vão ao trabalho com a intenção de cometer erros, e qualquer estratégia estabelecida para atribuir especificamente culpa pelo que pode ou não ter sido erro humano é ridícula - para não mencionar extremamente pouco profissional.

No mínimo, uma "parte responsável" designada para assumir o comando e "consertar" o problema, ou elaborar um plano para rastrear e / ou impedir a ocorrência de eventos semelhantes, seria boa. Às vezes, a solução nada mais é do que treinamento adicional. Já trabalhei em várias empresas nas quais fazia parte da descrição do seu trabalho, para obter uma educação sobre "empresa paga / tempo da empresa". Um local até construiu um "centro de treinamento" inteiro, que a faculdade local "empresta" ocasionalmente, para seus cursos de tecnologias industriais.

Eu trabalho em um ambiente de fabricação nos últimos 20 anos, onde erros de programação não apenas causam erros, eles destroem fisicamente as coisas e / ou pior, prejudicam as pessoas. No entanto, uma constante em todos os campos de fabricação que se mantém forte é que nunca há, sob nenhuma circunstância, alguém para culpar. Porque é um defeito no sistema, puro e simples - não um defeito nas pessoas. Veja dessa maneira - o uso do corretor ortográfico - uma ferramenta altamente eficaz para os menos afortunados na área do virtuosismo textual, ou talvez apenas para aqueles que trabalham um pouco demais ... mas de maneira alguma um método de culpa ou responsabilidade.

Um ambiente de trabalho, não importa de que tipo ou para que finalidade serve, é um sistema. Um sistema composto de componentes individuais, que, se "afinados" adequadamente, funciona em total harmonia - ou alguma aparência disso.

Leitura sugerida por parte do seu chefe: Os 7 hábitos das pessoas altamente eficazes

Parece que ele poderia usar um pouco de humildade, se não uma verificação da realidade. Ele faz parte da equipe, assim como todos os outros, e precisa entender isso - ou simplesmente não vai funcionar e, no final, ele estará segurando a sacola de qualquer maneira.

Sugestões de leitura e / ou pesquisa de sua parte:

Analise 5 por que análise, análise de causa raiz ... qualquer coisa que o coloque em uma posição melhor para oferecer uma solução, não um problema . E sua discordância com seu chefe é apenas isso, um problema, não uma solução. Ofereça a ele algo melhor, algo que faça sentido, e até esteja preparado para permitir que ele aceite o crédito pela ideia.

No momento, não parece que ele esteja preparado para consertar qualquer coisa, porque ele não tem um entendimento firme do que está quebrado, se houver algo quebrado - além da mentalidade "eu sou o chefe".

Boa sorte! Espero que você consiga superar isso, de uma maneira que seja aceitável para todos, especialmente nesses tempos.

EDIT: Pessoalmente, a partir de minha própria experiência ... "Vá em frente, me culpe. Porque com certeza, eu vou consertá-lo, e no caminho, quando acontecer novamente, quem estará lá para salvar o dia? Sim, você adivinhou ... eu, com um grande sorriso. "

Por responsabilidade, eu não gostaria de um person to blamecampo, gostaria de um Person who knows the codecampo ou um person who can fixcampo, para saber para onde enviar o tíquete de suporte.

Isso agilizaria o processo de correção do bug e daria responsabilidade, como matar dois coelhos com uma cajadada só. Eu pessoalmente traria isso a ele e deixaria que ele decidisse se isso ajudaria a aumentar o moral e a responsabilidade sem fazer com que alguém se sentisse falhado. Testes extremos não detectam todos os erros, caso contrário, não haveria relatórios de erros.

Diga a ele que "culpa" é negativa. Altere para "pessoa para consertar" e, pelo menos, será enquadrado de maneira positiva, e o mesmo trabalho ainda será realizado. Como as pessoas podem trabalhar se estão sendo "culpadas" ?!

Se meu chefe fizesse o seguinte, nesta ordem exata:

1) Eu começaria imediatamente a procurar um novo emprego.

2) Toda vez que um bug é reportado a uma pessoa culpada, o nome do meu chefe aparece lá e um comentário sobre por que um processo ruim da equipe é responsável por isso. E CC isso para seu chefe (de preferência em um lote). Você tem testes de unidade? Caso contrário, significa que o processo de desenvolvimento está quebrado, daí o erro. Você tem testes de integração automatizados constantes com todos os sistemas externos? Então, o processo de desenvolvimento é interrompido, daí o erro. Você tem a capacidade de tornar todos os ambientes idênticos na produção via script para não permitir erros humanos? Então, o processo de desenvolvimento é interrompido, daí o erro. Um desenvolvedor é terrível? Então o critério de contratação é ruim, portanto a culpa é do chefe. Todos os desenvolvedores estão cometendo erros estúpidos devido à falta de descanso porque trabalham 12 horas por dia? Então o processo de desenvolvimento é interrompido.

Como uma observação lateral: Todo bom gerente de desenvolvimento está ciente do que escrevi acima. E as estratégias ágeis têm como objetivo apontar para o chefe ou seus superiores porque o dev está diminuindo a velocidade: Veja, estamos gastando 50% do nosso tempo consertando bugs. Vamos analisar as estratégias para reduzi-las, para que possamos gastar 40% do tempo corrigindo bugs e revisar novamente esse problema, atingindo 30%. etc.

Infelizmente, parece que você não tem um bom técnico por causa do campo. Então, sugiro fazer (1) e não trazer o assunto ao gerente (exceto na entrevista de saída)

Parece que seu chefe não tem um conhecimento profundo do software e talvez ele também não pretenda. Então ele tem uma língua diferente, uma cultura diferente.

Abandonar um emprego por um problema como esse, antes mesmo de tentar avançar para uma solução, é apenas desistir. Sair é sair. Não desista até que ele tenha certeza de que você nunca poderá se entender. Para ter certeza disso, você deve primeiro tentar.

Como ele não conhece nossa língua e é o chefe, o primeiro passo aqui seria tentar falar com ele em sua língua. O que quero dizer com idioma? Vamos pensar juntos:

Nós, pessoas de software, a maioria de nós ama o trabalho que fazemos, temos uma conexão profunda com o que estamos fazendo. Caso contrário, ele não funciona e não se pode continuar neste negócio por um longo tempo sem amá-lo ou ser um completo ... você preenche os espaços em branco ...

Ele, no entanto, vê as coisas de maneira muito diferente. A cada relatório de erro, enquanto a maioria de nós se empolga em fazer a coisa funcionar melhor (não, mesmo que às vezes seja realmente muito estressante, gostamos de problemas, apenas admita!), Ele vê isso como uma falha, uma medida de ser mal sucedido. A primeira coisa que ele deve entender é que os bugs são bons. Bugs faz com que os clientes amem a empresa. (Agora, esse é o idioma dele) Quando um cliente relata um erro, ou quando o encontramos, depois de resolvido, é muito melhor do que a situação que nunca aconteceu. Os bugs criam a lealdade do cliente (estou falando sério!), Os bugs criam uma ótima desculpa para a comunicação entre o consumidor e o produtor do software.

Para "aumentar o lucro dos bugs", você deve oferecer relatórios de bugs ainda mais abertos. Com cada relatório de bug e sua solução rápida, limpa e boa, os clientes sentem e veem que "uau, esses caras são incríveis! Eles trabalham muito. Olhe para essas coisas que estão resolvendo. Não sabíamos que o software era tão complexo coisa!" blá blá e blá ...

Faça a sua jogada, fale no idioma dele. Os bugs são ótimos para uma empresa de software, não um problema. Eles nos fazem viver.

Para ética da equipe, eficiência ou qualquer tipo de conversa que você daria, poderia funcionar da maneira oposta à pretendida. Se você quiser sair, ele pensará "aha, minha solução começou a funcionar desde o primeiro dia! Links ruins já começaram a cair sozinhos antes de serem expostos!" Ele acredita em sua idéia de encontrar os bandidos na empresa e é muito difícil convencê-lo do contrário. Especialmente quando você pode ser um daqueles meninos maus!

Então, concentre-se no seu verdadeiro problema: Bugs. Mostre a ele que os erros podem ser muito úteis. Sem problemas, um relacionamento é chato. Tudo o que não mata te fortalece. Todo bug é uma grande oportunidade que você pode usar para aumentar a satisfação do cliente.

Isso é apenas uma coisa que você pode dizer. Pense nas preocupações dele e você encontrará muitos outros itens para adicionar à sua lista. A CHAVE DOURADA é oferecer algo alternativo ao invés de brigar com a ideia dele!

Se você está fazendo o Agile, e parece que você é do comentário sobre recursos / histórias . A pessoa a quem culpar seria a pessoa de controle de qualidade que deixou escapar o erro ou o Dono / Cliente do produto que aceitou o recurso / matéria como completo com o erro nele.

Eu escrevi de volta no dia, aqui está a minha opinião.

É como culpar um tipógrafo por erros de ortografia e outras coisas que um revisor deveria ter encontrado, mas perdeu. O tipógrafo cometeu o erro de ortografia, mas o revisor o perdeu, por isso é o revisor o culpado pelo erro cometido na impressão, não a pessoa que cometeu o erro.

Em um ambiente ágil, é responsabilidade do pessoal do controle de qualidade detectar erros (bugs) e é responsabilidade do proprietário do produto não aceitar coisas que não estão corretas. São dois níveis de leitores de prova que devem isolar os desenvolvedores das coisas que são lançadas, e é a única maneira que qualquer coisa deve ser classificada como um bug em um ambiente Agile.

Acho que seu gerente está tentando resolver um problema com a solução errada. Acho que talvez exista um problema em que muitos bugs estejam sendo liberados e seu gerente queira que os desenvolvedores tomem mais propriedade e responsabilidade com relação ao código que escrevem.

Usar o desenvolvimento orientado a testes e configurar um servidor de integração contínua (como Jenkins ) ajudará a resolver esse problema, sem introduzir o "jogo da culpa". Um servidor de integração contínua é importante para isso, porque quando alguém confirma um código que "quebra a compilação", um email é enviado para a equipe, mostrando a pessoa responsável. Como esse código não foi lançado em um ambiente de produção, esse tipo de culpa é mais proativo e encorajador (e divertido!).

O resultado é que os desenvolvedores terão mais propriedade, se sentirão mais confiantes e haverá menos erros no código de produção.

Saliente que, se o erro de uma única pessoa faz com que um bug acabe na produção, há algo errado com sua metodologia ou com a maneira geral de desenvolver software. Saliente que impedir que os bugs cheguem à produção é de responsabilidade de toda a equipe.

Usando um desses dois argumentos, veja se consegue convencer seu chefe de que ter o campo "quem culpar" como um campo de seleção única seria enganoso; e que, portanto, é necessário garantir que o campo "quem culpar" seja um campo de seleção múltipla. Depois de conseguir isso, garanta que, para cada bug, o nome de todos esteja em campo. Seu chefe acabará vendo que qualquer relatório em campo é inútil.

Para dar algum crédito ao chefe, o conceito de "atribuição de culpa" já está incorporado em ferramentas como SVN , e o uso apropriado dos dados pode ser construtivo para os desenvolvedores "descobrirem com quem conversar" durante a depuração, por exemplo: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Embora eu concorde com a resposta do gnat acima de que um campo Causa Raiz é uma coisa boa, essa não é a mesma informação e "desnormalizar" o campo para às vezes atribuir o (s) nome (s) do desenvolvedor anterior para a fonte afetada e às vezes ter um A descrição técnica (por exemplo, "não foi dimensionada para 10000 usuários") apenas enlameará as águas. Eu defenderia manter uma causa raizcampo claramente uma descrição técnica (por exemplo, mesmo quando ocorre um erro claro do programador, ele captura detalhes como "IndexOutOfRange Exception when fooData = 999") resolver classes inteiras de problemas com alterações na arquitetura ou na estrutura (por exemplo, aprimorando classes de contêineres personalizadas, tratamento de exceções de nível superior)

Dito isso, adicionar claramente um campo Pessoa a culpar pode enviar uma mensagem muito ruim e destrutiva para uma equipe de software que o gerenciamento deseja destacar e punir os desenvolvedores individuais que quebram o código com mais frequência. Suspeito que o gerente acredite que esse escrutínio público fará com que os desenvolvedores sejam mais cuidadosos e se auto-regulem para evitar colocar seus nomes nesse "muro da vergonha", e não entende por que os desenvolvedores se sentiriam ameaçados por isso, especialmente se for adicionado. genericamente a todos os relatórios de erros.

É fácil começar a enumerar os problemas de adicionar isso como um campo de erro / métrica em potencial:

1. Os erros são altamente variáveis ​​em dificuldade de resolução, e uma estatística simples da contagem / erro de desenvolvedores não reflete isso.
2. Os desenvolvedores são altamente variáveis ​​em capacidade "" "" "" "" "" ""
3. Muitos sistemas de software possuem componentes que precisam ser refatorados, mas a refatoração de componentes herdados (principalmente se a base herdada não possui / possui instalações limitadas de teste de unidade) introduzirá inicialmente erros. É provável que os desenvolvedores desanimam com essa atividade "boa", se houver um estigma / medo associado à geração de novos bugs (mesmo que sejam triviais de resolver e o resultado final seja uma grande melhoria no sistema).
4. Os testadores podem registrar um número altamente variável de bugs relacionados ao mesmo problema, resultando em contagens / desenvolvedores altamente distorcidos, a menos que uma análise mais detalhada seja feita.

Essa é apenas a ponta do iceberg. Combine-os com quem aponta para quem esperava o comportamento da API, resultados esperados incorretos nos testes e problemas "anteriores da cadeia" com requisitos ausentes / incorretos, e deve ser óbvio que uma métrica como essa está condenada como sem valor (a menos que o objetivo é prejudicar o moral e causar um êxodo em massa.)

De volta ao ponto de vista do chefe, não há problema em querer descobrir se há desenvolvedores que estão quebrando o código repetidamente e tentar fazer algo (espero que construtivo) sobre isso. Tentar obter essas informações adicionando um campo aos relatórios de bugs não fornecerá informações significativas pelos motivos listados acima. Na minha experiência, essas informações podem ser aprendidas estando conectadas à equipe, participando da maioria das reuniões da equipe, integrando (cuidadosamente) as informações aprendidas em reuniões pessoais ocasionais com os membros da equipe e familiarizando-se com os subsistemas em o código (mesmo se eles não puderem ler o código).

Apenas deixe ir. Seu chefe descobrirá por si próprio que, se isso acontecer, causa um problema.

Vamos ser francos, você tem uma opinião e ele também. Ele é seu gerente e sua opinião é a que vence.

Sim, você pode entrar em guerra por esse problema, mas vale a pena? Duvido que dure mais de três meses antes de cair em desuso.

Mas sabotar ativamente isso ou gritar sobre isso apenas consome capital político que é melhor economizado para pedir esse tempo extra, próximo aumento, promoção ou quando uma decisão realmente crítica do projeto será tomada.

Naquele momento, quando realmente importa, você deseja que o chefe se lembre de que você foi a pessoa que sabotou ativamente sua ideia de "pessoa culpada".

Respeite o escritório, mesmo que não respeite a decisão.

Economize o estresse e a pressão nas decisões que serão muito mais duradouras.

Diga ao seu chefe que o desenvolvimento em uma equipe precisa de habilidades sociais. Ele pode até concordar.

Mas o problema é que isso é algo com que os desenvolvedores são extremamente ruins. Adicionar ferramentas que sugiram culpar é mais importante do que a análise adequada de problemas é contraproducente.

Em vez disso, você precisa de incentivos para melhorar as habilidades sociais, e a infraestrutura de comunicação que você possui deve dar suporte a isso. Por exemplo, faça uma cunhagem positiva: nomeie uma pessoa responsável por um ticket, que cuide dele.

Comece também com revisões de código para poder aprender umas com as outras. Isso poupa as culpas mais tarde.

Envie-lhe esta pergunta SO. Se ele estiver aberto à razão, os comentários aqui fornecerão verificações de sanidade para o seu raciocínio. Se ele não for razoável, é improvável que você o convença por razões que façam sentido. Além disso, ele poderá ler os motivos fora de uma conversa (o que às vezes pode ser mais convincente devido à motivação removida de "estar certo" no calor de uma conversa).

Você também pode tentar mudar isso. O campo pode ser "possíveis etapas para evitar a ocorrência de um bug semelhante" ou algo mais curto para esse efeito. Em seguida, você pode reunir soluções e votar em quais delas implementar para melhorar seu local de trabalho. Talvez uma abordagem orientada à solução seja mais produtiva e provavelmente melhor recebida (desde que haja um acompanhamento real na revisão das sugestões).

Vejo duas possibilidades aqui: ele quer ser capaz de punir as pessoas que cometem erros, ou simplesmente não pensou nisso. Que ele saiba que a percepção de todos será que ele pretende punir aqueles que cometerem erros. Pergunte a ele se essa é a cultura que ele deseja incentivar.

meu chefe decidiu que adicionar um campo "Pessoa culpada" ao nosso modelo de rastreamento de bugs aumentará a responsabilidade

Na minha experiência, quando a gerência quer "tornar as pessoas mais responsáveis", o que elas querem dizer é que elas podem exigir a punição pelo fracasso. Seja para demitir artistas de baixo desempenho ou apenas deixá-los na revisão salarial anual ("Desculpe, Bob, você teve 17 erros assinalados como sua culpa, e isso está acima do limite de 15"), é uma punição.

Ele provavelmente dirá "Ah, não, não queremos isso", então pergunte a ele como esses dados serão usados. Lembre-o de que você não adiciona pontos de dados a um banco de dados, a menos que você o utilize. Ele deseja selecionar um determinado critério ("Mostre-me todos os bugs abertos no subsistema criador de relatórios"), para que você possa trabalhar nas coisas ou para obter dados agregados ("Qual subsistema teve mais bugs "), para que você possa fazer uma análise post-mortem. Ele prevê algum tipo de bolsa de fracasso em que as pessoas possam ser humilhadas publicamente?

Então, o que ele pretende? Ele quer poder dizer "Mostre-me todos os bugs que são culpa de Bob?" Por quê? Ou ele quer dizer "Mostre-me quem é o culpado na maioria das vezes?" Por quê? O primeiro não tem sentido e o segundo é apenas punitivo. Ou a terceira opção é que ele não tem um motivo real.

Admito que há a possibilidade de ele estar procurando os programadores da equipe que precisam de ajuda para melhorar suas habilidades. Nesse caso, existem maneiras melhores de capturar essas informações que não criam uma cultura de apontar o dedo.

Acredito que o principal aspecto a ser observado aqui é como a comunicação é aberta na equipe em relação ao "chefe" e vice-versa. Apontar o dedo nunca é bom, no entanto, da perspectiva do gerenciamento, se um de seus desenvolvedores se deparar com o mesmo problema várias vezes, talvez seja hora de intervir e tentar ajudá-lo a superar esse problema repetitivo (por exemplo, John não está testando corretamente) o código: 3 erros de produção nos últimos 3 meses, vamos dar a ele uma lista de verificação para que ele se lembre de como seu código deveria ser e como ele deve testá-lo).

Do ponto de vista do desenvolvimento, 'culpar' já está incorporado a uma ferramenta convencional como o SVN; portanto, não vejo mal algum em dizer "John, por favor, conserte essa porcaria que você escreveu" e colocando um nome ao lado de isto. O JIRA também incorpora o nome de uma pessoa quando você arquiva um bug (no entanto, o campo não é realmente destinado à pessoa responsável por isso, é muito importante que alguém o conserte).

Porém, como muitos mencionados acima por muitos, se surgir um erro, é uma responsabilidade compartilhada: do desenvolvedor, aos testadores, ao controle de qualidade e aos gerentes. Se, em algum momento, seu chefe lida com um cliente irritado por telefone com coisas como " Sinto muito, John nunca testou isso corretamente ", então eu definitivamente estaria procurando outro emprego. Um bom chefe deve ir "vamos cuidar disso". Sem nomes, sem apontar o dedo, apenas soluções.

Mais uma vez, acredito que é tudo uma questão de comunicação. Talvez a única coisa que seu chefe queira fazer é ver quem está tendo problemas na equipe de desenvolvimento ou que tipo de problemas a equipe está tendo (talvez para sessões de treinamento?), Mas não acho que você descobrirá exatamente o que está por trás dele. decisão (ou melhor, nós pôsteres / leitores), a menos que você fale com seu chefe e com toda a equipe.