Meu chefe decidiu adicionar um campo de “pessoa para culpar” a cada relatório de bug. Como posso convencê-lo de que é uma má ideia?

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.}

Outro resultado provável para tal política é que as pessoas não reportarão o erro se acharem que podem ser a "pessoa a quem culpar", por isso reduzirá o número de erros reportados pela equipe.

O argumento principal que eu usaria contra ele seria perguntar qual problema ele está tentando resolver. Há quase certamente melhores maneiras de resolver o mesmo problema.

Por um lado, há realmente apenas uma pessoa para culpar? Se houver, você está fazendo algo errado. Um bom processo leva um trabalho através de um analista, um programador, um revisor e um testador antes que ele chegue à produção. Se você não está fazendo todos esses estágios, talvez essa seja a solução para o problema que seu chefe está tentando resolver. Se você é então qual é o culpado? Pode não ser nenhum deles, pode ser o código legado que é o culpado.

Não adianta ter pessoas mordendo os dedos para trás e apontando, tentando evitar uma marca preta que não desaparece depois de 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 isso não vai dar errado novamente.

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

O truque para impedir um gestor de criar responsabilidade é oferecer gratuitamente , mas de uma maneira que realmente faça sentido para você.

Existem pelo menos três problemas com esse campo.

A questão mais fundamental é que esse campo não será uma boa métrica para agir. Claro, ele terá uma ótima classificação de cujo código causa a maioria dos defeitos. Mas adivinha quem vai estar no topo dessa lista? Provavelmente o fundador da empresa, ou talvez um desenvolvedor de ponta que tenha uma taxa de defeitos muito baixa, mas seja tão produtivo, escreva uma parte desproporcional do código. Então ele vai acabar demitindo seu melhor desenvolvedor, ou fazer com que ele diminua tanto que ele não é 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 números baixos de defeitos.

Ainda outra falha na métrica de software.

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

Errado:

Bob forget to check input and the program crashed dividing by zero.

direita:

Code vulnerable to a divide by zero error was not detected before deployment. New test cases have been added to verify proper handling of invalid input. Code was corrected and all new test cases are passing.

Altere "Pessoa para culpar" para "Pessoa para elogiar"

A pessoa principal para corrigir os erros recebe o seu nome.

Resposta simples.

O campo "Culpa" será usado apenas para bodes expiatórios e dedadas, a moral cairá, 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 quietas sobre os bugs, em vez de denunciá-los, porque não querem que um colega entre em problemas. É completamente contraproducente.

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

Seu chefe parece achar que os insetos são um sinal de preguiça ou desleixo. Eles não são. Eles são um fato da vida. Quantas correções a Microsoft faz em um ano?

Se você está pronto para uma pequena desobediência civil, faça com que a equipe concorde em colocar uma lista de todos os desenvolvedores nesse campo para cada bug. Se isso não couber, escreva "I'm Spartacus!" em vez de. O ponto, é claro, é que todos vocês são responsáveis por todos os bugs, e você não está feliz em ter que apontar o indivíduo que criou qualquer bug.

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. Então explique ao chefe que atribuir culpa a cada bug deixa todo mundo na equipe infeliz e desconfortável. Diga a ele que todos vocês sentem que há pouca correlação entre os bugs criados e qualquer outra coisa (habilidade, esforço, sanidade). (Isso ajudará se você puder executar alguns números que mostram que realmente não existe uma correlação.)

Desobediência Civil em Gandhian: Coloque seu nome em todos os campos (a menos que outros desenvolvedores aumentem e coloquem seus nomes em seus bugs), e aceite a culpa por cada bug, seja ele seu ou não. Nada renderá esse campo ou a ideia de culpar alguém mais inútil que isso. Se seu chefe perguntar por que seu nome está em todos os campos, então você pode explicar "porque eu não acho que desenvolvimento é um jogo de culpa, se você realmente precisa culpar pessoas e crucificar, então me crucifique por tudo e deixe minha equipe trabalhar pacificamente "

Uma vez eu tive um chefe implementando um sistema muito semelhante a este, e embora não fosse programação (era 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 para culpar' 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 projeto trabalhado ou até mesmo tocado, o adesivo deve ser adicionado à documentação do projeto.

A meta declarada do chefe para "a iniciativa do adesivo" era estabelecer a fonte de todos os erros do nosso departamento (erros na papelada, erros de impressão, cópia incorreta, essencialmente o equivalente impresso de erros)

O que fizemos foi dar a cada um dos outros designers um quarto dos 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, colocássemos as quatro cores dos designers.

Não escreva seu nome apenas na caixa [Blame] - coloque o nome de todos que estão na equipe / projeto e certifique-se de que toda a equipe faça o mesmo.

Trabalhamos juntos contra a sua vagabundagem orwelliana e, como resultado, acabamos pegando os erros uns dos outros e conversando uns com os outros sobre isso e, finalmente, tivemos uma redução significativa nos erros. Ela era uma gerente de sh * t e, em vez de reconhecer que sua iniciativa acabou nos unindo e aumentando a produtividade, ela conseguiu tudo, desmantelou o sistema de adesivos e declarou que era um fracasso e repreendeu formalmente todos nós.

Ele acabará punindo seu programador mais prolífico. As probabilidades 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 escreveu 60% do código da interface, então 60% dos bugs estarão em seu código.

Explique que este sistema faria parecer que a pessoa que escreve o maior número de códigos é o pior programador, e a pessoa que escreve menos código é o melhor programador.

Isso soa muito como quando Scott Adams apontou a sabedoria fracassada de um Bug Bounty quando o chefe de cabelo pontudo em Dilbert. Wally anunciou que iria "escrever-lhe um novo Mini Van".

Banda desenhada de Dilbert para 13/11/1995 do arquivo oficial de tiras de quadrinhos de Dilbert.

Os erros podem ser introduzidos no código por programação deficiente e design pobre; mas, eles também podem vir como conseqüência de escrever muitos códigos difíceis. Dinging pessoas que produzem o maior número de bugs é tão provável que os desenvolvedores pobres de Ding sejam 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 que' para a causa em vez de um campo 'quem' pode ser mais produtivo. Ex: Mudança 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ê devesse olhar para ele como "Quem está na melhor posição para corrigir o bug?" Uma parte de mim também sente, você quebrou, você consertou. Deve haver alguma responsabilidade.

Eu 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 bugs por linhas de código sejam melhores. O código nunca será verificado.

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

É estranho que ninguém tenha mencionado isso antes: Adicionar tal funcionalidade ao rastreador de bugs motivaria os funcionários a tentarem rodar o sistema .

Este é um problema comum para abordagens como o que a pergunta apresentou, entre outras idéias similares (pagando pelo número de linhas de código, pagando pelo número de erros). 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 bug com uma redação para diminuir sua própria culpa e colocá-lo em outra pessoa pode levar os desenvolvedores a entender mal a causa do problema (ou o trabalho que está sendo dado a outro desenvolvedor que não sabe essa seção de um código tão bom quanto aquele que estava trabalhando nele e quem foi a principal causa do bug) levando a mais tempo e esforço para corrigir o problema.

Sua pergunta atual foi sobre como mudar a cultura antes de deixar a empresa, convencendo seu chefe de que adicionar uma pessoa para culpar o campo por relatos de bugs é uma má ideia. Mas é claro que mudar a cultura exige que ele realmente entenda por que essa é uma má ideia.

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

Você pediu para escrever sobre esse assunto e Peopleware vem à mente. É altamente considerado e fala em termos gerais sobre como gerenciar pessoas fazendo trabalho criativo, onde a saída é difícil de medir. O problema é que a leitura não ajuda muito, seu chefe teria que lê-lo e acreditar em pelo menos parte dele.

Estranhamente, como o problema aqui é mais sobre pessoas que relatórios de bugs, muito possivelmente pertence mais a Workplace que a Programmers. Mas o sucesso dos projetos de software geralmente é muito rastreável para a interação social humana, então as respostas reais são geralmente sobre coisas que transcendem o software.

Minha única outra sugestão, meio séria, é dizer (ou convencer um colega a dizer, desde que você planeje sair) que você estão dispostos a assumir total responsabilidade pelo sucesso do projeto , e seu nome deve sempre entrar em campo, pois, mesmo que outra pessoa tenha cometido o erro diretamente, você assumiu a responsabilidade de garantir que todos na equipe realizem um trabalho de qualidade.

É um absurdo, claro, como você poderia ter feito isso, mas algumas pessoas (especialmente pessoas que são grandes culpadas) realmente comem essas coisas. Ronald Reagan costumava aceitar publicamente a responsabilidade pessoal toda vez que um membro de sua administração era apanhado em um escândalo (e havia muito poucos) e na verdade funcionava muito bem politicamente todas as vezes. A melhor parte para você é que a responsabilidade geralmente vem sem conseqüências reais, eles só pensam que você é um cara de pé para assumir a responsabilidade.

Ou talvez não seja assim. Não faz nenhum sentido para mim, por isso é difícil para mim prever quando vai funcionar, mas eu testemunhei o trabalho quando parecia não ter nenhum negócio fazê-lo (no local de trabalho, não apenas no exemplo de Reagan).

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

No mínimo, uma "parte responsável" designada para assumir e "corrigir" o problema, ou apresentar um plano para rastrear e / ou impedir que eventos semelhantes ocorram, seria boa. Às vezes, a solução nada mais é do que treinamento adicional. Eu trabalhei para várias empresas onde fazia parte da sua descrição de trabalho, para obter uma educação "empresa paga / tempo da empresa". Um lugar até construiu um "centro de treinamento" inteiro, que a faculdade local "toma emprestado" ocasionalmente, para seus cursos de tecnologias industriais.

Eu trabalhei em um ambiente de produção nos últimos 20 anos, onde os erros de programação não apenas causam erros, eles destroem fisicamente as coisas e / ou pior, eles prejudicam as pessoas. No entanto, uma constante em todos os campos de produção que é strong, é que nunca há, em nenhuma circunstância, alguém para culpar. Porque é um defeito no sistema, claro e simples - não um defeito nas pessoas. Olhe para isto desta maneira - o uso do corretor ortográfico - uma ferramenta altamente eficaz, para aqueles menos afortunados na área de virtuosismo textual, ou talvez apenas aqueles pouco trabalhados demais ... mas de modo algum 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 corretamente "afinados", funciona em total harmonia - ou alguma aparência de tal.

Sugestão de leitura na 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, como todos os outros, e precisa perceber isso - ou simplesmente não funciona, e no final, ele estará segurando a sacola de qualquer maneira.

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

Veja em 5 por que análise, análise de causa raiz ... qualquer coisa que coloque você em uma posição melhor para oferecer uma solução, não um problema . E seu desacordo com seu chefe é apenas isso, um problema, não uma solução. Ofereça-lhe algo melhor, algo que faça sentido e até esteja preparado para permitir que ele assuma o crédito pela ideia.

Neste momento, parece que ele não está preparado para consertar nada, porque ele não tem uma compreensão firme do que está quebrado, se há alguma coisa quebrada - além de sua mentalidade de "eu sou o chefe". .

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

EDIT: Pessoalmente, da minha própria experiência ... "Vá em frente, me culpe. Porque com certeza, eu vou consertar isso, e na estrada, quando isso acontecer de novo, quem estará lá para salvar o dia? sim, você adivinhou ... eu, com um grande sorriso. "

Para a responsabilidade, eu não desejaria um campo person to blame , eu desejaria um campo Person who knows the code ou um campo person who can fix , para que eu soubesse para onde enviar o tíquete de suporte.

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

Diga a ele que "culpa" é negativa. Mude para "pessoa para consertar" e, ao menos, ela é enquadrada de maneira positiva, e o mesmo trabalho ainda é feito. Como as pessoas podem trabalhar se estão sendo "culpadas" ?!

Se meu chefe fizesse isso, o seguinte aconteceria, nesta ordem exata:

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

2) Toda vez que um bug é relatado com uma pessoa para culpar, o nome do meu chefe aparece lá, e um comentário sobre o motivo pelo qual um processo ruim na equipe é responsável por ele. E CC isso para seu chefe (de preferência em um lote). Você tem testes de unidade? Se não, então isso significa que o processo dev está quebrado, portanto, o bug. Você tem um teste de integração automatizado constante com todos os sistemas externos? Então o processo de desenvolvimento está quebrado, assim o bug. Você tem a capacidade de tornar cada ambiente idêntico em produção via script para não permitir erro humano? Então o processo de desenvolvimento está quebrado, assim o bug. Um desenvolvedor é terrível? Então o critério de contratação é ruim, assim, a culpa do chefe. Todos os desenvolvedores estão cometendo erros estúpidos devido à falta de descanso porque estão trabalhando 12 horas por dia? Então o processo de desenvolvimento está quebrado. Como você pode ver, 100% dos bugs são culpa do chefe.

Como uma observação: Todo bom gerente de desenvolvimento está ciente do que escrevi acima. E as estratégias ágeis são destinadas a apontar para o chefe ou seus / suas supperiors porque dev está a abrandar: Olha, 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, em seguida, revisitemos esse problema para 30%. etc.

Infelizmente, parece que você não tem um bom gerente por causa do campo. Então eu sugiro fazer (1) e não trazê-lo para o gerente (exceto na sua entrevista de saída)

Parece que seu chefe não tem um profundo conhecimento de software e talvez ele também não tenha a intenção de fazê-lo. Então ele tem uma língua diferente, uma cultura diferente.

Sair de um emprego para um problema como este, antes mesmo de tentar avançar para uma solução, é simplesmente ser um desistente. Parar é desistir. Não pare 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 ele é o chefe, o primeiro passo aqui seria tentar falar com ele em seu idioma. O que quero dizer com linguagem? 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, não funciona e não se pode continuar nesse negócio por muito tempo sem amá-lo ou ser completo ... você preenche os espaços em branco ...

Ele, no entanto, vê as coisas de maneira muito diferente. Com cada relatório de bug, enquanto a maioria de nós fica animado para fazer a coisa funcionar melhor (não, mesmo que às vezes seja muito estressante, nós amamos problemas, apenas admita!), Ele vê isso como um fracasso, uma medida de ser mal sucedido. A primeira coisa que ele deveria querer entender é que os bugs são bons. Bugs faz os clientes amarem a empresa. (Agora esta é a sua língua) Quando um cliente relata um bug, ou quando o encontramos, depois de resolvido, é muito melhor do que nunca. Bugs criam lealdade do cliente (estou falando sério!), Bugs criam uma ótima desculpa para a comunicação entre o consumidor e o produtor do software.

Para "aumentar o lucro de 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 vêem "uau, esses caras são incríveis! Eles trabalham muito duro. Veja essas coisas que eles estão resolvendo. Nem sabíamos que o software era tão complexo coisa!" blá blá e blá ...

Faça seu movimento, fale em seu idioma. Bugs são ótimos para uma empresa de software, não um problema. Eles nos fazem viver.

Para a ética da equipe, a eficiência ou qualquer tipo de conversa que você fizer poderia funcionar do jeito oposto que você pretendia. Se você quiser sair, ele vai pensar "aha, minha solução começou a funcionar desde o primeiro dia! Links ruins já começaram a cair por si mesmos antes de serem expostos!" Ele acredita em sua ideia de encontrar os bad boys na empresa e é muito difícil convencê-lo do contrário. Especialmente quando você pode ser um daqueles garotos maus!

Então, concentre-se em seu problema real: Bugs. Mostre a ele que os erros podem ser muito úteis. Sem problemas, um relacionamento é chato. Tudo o que não te mata te faz mais strong. Cada bug é uma ótima oportunidade que você pode usar para aumentar a felicidade do cliente.

Isso é apenas uma coisa que você pode dizer. Pense sobre suas preocupações e você encontrará muitos outros itens para adicionar à sua lista. O GOLDEN KEY é oferecer algo alternativo em vez de lutar com a ideia dele!

Se você está fazendo Agile, e parece que você é do comentário features / stories . A pessoa para culpar seria a pessoa do controle de qualidade que deixou o erro passar, ou o dono do produto / cliente que aceitou o recurso / história como completo com o bug nele.

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

This is like blaming a typesetter for misspellings and other things that a proofreader should have found but missed. The typesetter made the misspelling, but the proofreader missed it, so it is the proofreader to blame for the mistake making to print, not the person that made the error in the first place.

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

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

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

O resultado é que os desenvolvedores assumem maior responsabilidade, se sentem mais confiantes e haverá menos bugs no código de produção.

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

Usando um desses dois argumentos, veja se você consegue persuadir seu chefe de que ter o campo "a quem culpar" como um campo de seleção única seria enganoso; e, portanto, é necessário certificar-se de que o campo "a quem culpar" seja de múltipla seleção. Depois de conseguir isso, garanta que, para cada bug, o nome de todos esteja no campo. Seu chefe acabará vendo que qualquer reportagem no campo é fútil.

Para dar crédito ao chefe, o conceito de "atribuição de culpas" já está embutido em ferramentas como SVN , e o uso apropriado dos dados pode ser construtivo para os desenvolvedores em "descobrir com quem falar" durante a depuração, por exemplo: link

Embora eu concorde com a resposta do gnat acima que um campo Root Cause é uma coisa boa, esta não é a mesma informação, e "desnormalizando" o campo às vezes atribui o nome do desenvolvedor anterior ) para a fonte afetada e, às vezes, ter uma descrição técnica (por exemplo, "não escalar para 10000 usuários") vai enlamear as águas. Eu defendo manter um campo de Causa Raiz claramente uma descrição técnica (por exemplo, mesmo quando um erro claro do programador, tenha detalhes de captura como "IndexOutOfRange Exception when fooData = 999") feedback útil quando revisado em massa, e permitir que algumas ações corretivas sejam tomadas para resolver classes inteiras de problemas com alterações de arquitetura ou estrutura (por exemplo, melhorando classes de contêiner personalizadas, entrega de exceções de nível superior)

Dito isso, adicionar um campo Person to Blame claramente pode enviar uma mensagem muito ruim e uma mensagem destrutiva para uma equipe de software que a gerência deseja destacar e punir desenvolvedores individuais que quebram códigos com mais frequência. Suspeito que o gerente acredite que esse escrutínio público fará com que os desenvolvedores sejam mais cuidadosos e autorreguladores para evitar que seus nomes apareçam nesse "muro da vergonha" e não entendem por que os desenvolvedores se sentiriam ameaçados por isso, especialmente se fossem adicionados genericamente para cada relatório de bug.

Os problemas para adicionar isso como um campo de bug / métrica potencial são fáceis de começar a enumerar:

1. Os bugs são altamente variáveis em dificuldade para serem resolvidos, e uma estatística simples de contagem de bugs / desenvolvedor não refletirá isso.
2. Os desenvolvedores são altamente variáveis em capacidade "" "" "" "" "" "
3. Muitos sistemas de software têm componentes que precisam de refatoração, no entanto, a reconfiguração de componentes legados (principalmente se a base legada não tiver instalações limitadas para testes unitários) introduzirá inicialmente bugs. É provável que os desenvolvedores sejam desencorajados dessa atividade "boa", se houver um estigma / medo associado à geração de novos bugs (mesmo que sejam triviais para resolver e o resultado final seja uma grande melhoria no sistema).
4. Os testadores podem arquivar um número altamente variável de erros relacionados ao mesmo problema, resultando em contagens de erros altamente distorcidas / desenvolvedor, a menos que uma análise mais detalhada seja feita.

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

De volta ao ponto de vista do chefe, tudo bem se ele quiser descobrir se há desenvolvedores que estão quebrando o código repetidamente e tentar fazer alguma coisa (esperançosamente construtiva) 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 conectadas à equipe, participando da maioria das reuniões da equipe, integrando (cuidadosamente) informações aprendidas em reuniões individuais com os membros da equipe e familiarizando-se com os subsistemas em o código (mesmo que eles não possam ler o código).

Apenas deixe ir. Seu chefe vai descobrir por conta própria que isso causa um problema, se isso acontecer.

Deixa ser franco, você tem uma opinião e ele também. Ele é o seu manager e a opinião dele é a que vence.

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

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

Naquele momento, quando realmente contar, você não quer que o chefe se lembre de que você foi a pessoa que ativamente sabotou sua ideia de "pessoa para culpar".

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

Economize o estresse e a pressão nas mesas para decisões que durarão muito mais tempo.

Diga ao seu chefe que desenvolver-se em equipe precisa de habilidades sociais. Ele pode até acenar com a cabeça.

Mas o problema é que isso é algo com o qual os desenvolvedores são extremamente ruins. Adicionar ferramentas que sugerem culpa é mais importante do que a análise adequada do problema é contraproducente.

Em vez disso, você precisa de incentivos para melhorar as habilidades sociais, e a infra-estrutura de comunicação que você deve apoiar. Por exemplo, cite-a positivamente: cite uma pessoa responsável por uma passagem, que cuida dela.

Comece também com revisões de código para aprender um com o outro. Isso poupa as culpas mais tarde.

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

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

Eu vejo duas possibilidades aqui: ele quer ser capaz de punir as pessoas que cometem erros, ou ele simplesmente não pensou sobre isso. Deixe-o saber que a percepção para todos será que ele pretende punir aqueles que cometem erros. Pergunte se essa é a cultura que ele quer incentivar.

meu chefe decidiu que adicionar um campo "Person To Blame" ao nosso modelo de acompanhamento de bugs aumentaria a responsabilidade

Na minha experiência, quando a gerência quer "tornar as pessoas mais responsáveis", o que elas querem dizer é que elas querem ser capazes de punir pelo fracasso. Seja para demitir pessoas de baixa performance, ou simplesmente deixá-los entrar na revisão salarial anual ("Desculpe, Bob, você teve 17 bugs sinalizados como sua culpa, e isso ultrapassou o limite de 15"), é punição.

Ele provavelmente dirá "Oh, não, nós 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 use. Ele quer selecionar em um determinado critério ("Mostre-me todos os bugs abertos no subsistema criador de relatórios"), para que você possa trabalhar em coisas, ou para obter dados agregados ("Qual subsistema teve mais bugs "), para que você possa fazer uma análise post-mortem. Será que ele visualiza algum tipo de painel de falhas onde as pessoas podem ser humilhadas publicamente?

Então, o que ele pretende? Ele quer ser capaz de dizer "Mostre-me todos os erros que são culpa do Bob?" Por quê? Ou ele quer ser capaz de dizer "Mostre-me quem é a culpa a maior parte do tempo?" Por quê? O primeiro não é significativo e o segundo é apenas punitivo. Ou a terceira opção é que ele não tem um motivo real.

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

Eu acredito que o aspecto chave a ser observado aqui é quão aberta a comunicação está na equipe em relação ao 'chefe' e o contrário. Apontar os dedos nunca é bom, no entanto, do ponto de vista de 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-lhe uma lista de verificação para que ele se lembre de como seu código deve ser e como ele deve testá-lo).

Do ponto de vista do desenvolvimento, 'culpar' já está incorporado em uma ferramenta mainstream como SVN, portanto, eu realmente não vejo nenhum mal em ir "John, por favor, conserte o pedaço de porcaria que você escreveu" e colocando um nome ao lado dele. O JIRA também incorpora o nome de uma pessoa quando você registra um bug (no entanto, o campo não é realmente destinado à pessoa responsável por ele, mas é bastante para que alguém conserte).

Aqui está a coisa, como muitos mencionados acima por muitos, se um bug surgir, é uma responsabilidade compartilhada: do desenvolvedor, aos testadores, ao QA, aos gerentes. Se o seu chefe, em algum momento, lida com um cliente irritado pelo telefone com coisas do tipo: "Eu sinto muito, John nunca testou isso corretamente", então eu definitivamente estaria procurando outro emprego. Um bom chefe deve ir "nós vamos cuidar disso". Sem nomes, sem apontar o dedo, apenas soluções.

Mais uma vez, acredito que é tudo sobre comunicação. Talvez a única coisa que seu chefe queira fazer seja 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 dizendo, nós cartazes / leitores) a menos que você fale com seu chefe e toda a sua equipe.