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


695

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?


79
Ei pessoal, eu sou o "chefe" que introduziu o campo WTF. É aqui porque eu adicionei um "Peson a culpa" campo ao nosso sistema de rastreamento de bugs: news.ycombinator.com/item?id=4179298
Jason

98
"Eu poderia ter nomeado algo mais politicamente correto para que o sentimento não se machuque? Claro. Mas qual é a graça disso? O objetivo era conscientizar o número de bugs de produção após cada lançamento, por que não usar uma dose pequena? vergonha pública por uma boa medida? E, para ficar claro, o objetivo do campo e, em última análise, o objetivo da métrica, não é identificar a causa do bug. Merda acontece e temos coisas melhores a fazer. a métrica é um lembrete para que cada desenvolvedor melhore todos os dias ". --- Acho que todas essas "razões" estão inerentemente erradas.
ulty4life

31
@ Jason, em vez de inventar os campos de Jira, considere contratar um ou dois testadores . No entanto, no seu caso, ter um campo de causa raiz (não importa como você o nomeie) me parece de pouca importância porque você já criou uma conexão entre a ausência de testadores e o aumento de bugs de produção .
Gnat

68
@ Jason O bug está no código, não em um desenvolvedor. Você deve ser uma dessas pessoas que pensa que as revisões de código são para revisar os desenvolvedores, não o código.
Danny Varod

81
Seu chefe é o "pessoa para culpar", preencha seu nome em sempre e ver como ele gosta;)
dukeofgaming

Respostas:


676

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.


13
Este é um bom argumento. No entanto, a causa principal de um defeito nem sempre é um único desenvolvedor (que é o ponto principal desse campo). Como resultado, identificar um único desenvolvedor responsável por um defeito causa mais danos do que benefícios, IMO.
MK_Dev 28/06

326
+1 para redirecionar ideia do chefe em algo mais produtivo (sempre mais fácil de vencer uma batalha dessa forma)
benzado

16
"Causa raiz" também abrange (espero que a maioria!) Casos em que ninguém é o único culpado, coisas como "falha no software do fornecedor", "erro na documentação da API", "Maior volume que o esperado".
James Anderson

29
Ótimo. Até o seu exemplo para uma única pessoa responsável apresenta duas pessoas, ilustrando perfeitamente a estupidez do exercício.
precisa

15
Não se esqueça de que "causas contribuintes" também seriam úteis, pois geralmente são mais fáceis de fazer. Por exemplo, se "causa raiz" foi "erro de codificação na confirmação 5678" e "causa contribuinte" foi "confirmação 5678 não foi revisada porque os requisitos chegaram tarde demais", você não pode evitar todos os erros de codificação, mas pode ser mais rigoroso atraso na entrega na próxima vez que os requisitos forem atrasados.
Jan Hudec

272

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.


300
Bem, o chefe ficará feliz! Haverá menos relatórios de erros e, portanto, a qualidade deve ter aumentado.
precisa

5
O chefe provavelmente está pagando pelo desempenho e um dos principais indicadores de desempenho é o número de bugs relatados. Espero que ele / ela compartilhe seu bônus para a equipe de desenvolvimento no final do ano.
precisa

54
Por experiência, este não é um resultado "provável", é 100% absolutamente certo de que isso acontecerá, porque os desenvolvedores são pessoas inteligentes. O que você verá também é um aumento enorme no tempo gasto discutindo violentamente com os testadores que seus "bugs" não são bugs.
Joris Timmermans

A pessoa que está reportando o erro provavelmente não será a pessoa que root causeeu quero dizer sobre tentar encontrar um erro em seu próprio código após 36 horas de escrever código nesta semana?
Malachi

141

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


5
Um processo realmente bom evita que o analista e o programador sejam duas pessoas diferentes - minhas experiências com analistas que não podem programar e programadores que não podem analisar foram muito ruins. No entanto, marque +1 na sua resposta.
Doc Brown

@DocBrown bem, minhas experiências com analistas e programadores como duas pessoas diferentes têm sido bastante positivas até agora. Embora, no meu caso, tenham sido analistas que entendam a lógica do programa e programadores que possam participar da análise :) #
3013

@gnat: IMHO, com o analista sendo um dos programadores da sua equipe, pode melhorar a velocidade e a qualidade do desenvolvimento em uma ordem de magnitude.
Doc Brown

3
Este livro irá ajudá-lo a encontrar as palavras para defender seu terreno amazon.com/The-Power-Positive-No-Relationship/dp/0553384260/...
zundarz

2
O link para "oferecê-lo gratuitamente" está quebrado.
Tom Fobear

79

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.


16
Estou surpreso que mais ninguém tenha mencionado o fato de que analisar o histórico de um erro nas tentativas de atribuir culpas será uma enorme perda de tempo. Se nenhum outro argumento for mordido, isso deve acontecer.
a CVn

Então vocês consertam erros sem tentar descobrir o histórico e a causa raiz? Nesse ponto, você está corrigindo sintomas e possivelmente ignorando problemas essenciais legítimos. Se, na verdade, é um problema com uma pessoa, ajuda saber por que a pessoa cometeu o erro para que possa ser corrigido. Se houver hardware defeituoso, isso pode ser trocado por algo mais estável.
314 Jordan

Eu estou bem em culpar / elogiar pessoas. Mas isso deve ser feito com muito cuidado, porque é fácil causar problemas piores ao fazê-lo do que o problema original. O campo "culpado" não parece uma abordagem "muito cuidadosa".
Ptyx

68

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.


6
Ainda melhor: diretrizes / padrões de codificação e listas de verificação de revisão de código atualizadas para evitar que isso aconteça novamente.
Oddthinking

E daí que os erros são inevitáveis? O que há de errado em culpar alguém por eles? Acho que a sua opção 'Errado:' é mais clara que a opção 'Certo:'. O errado é realmente simples. O 'Certo:' um é prolixo.
Adam Bruss

3
@ Adam: minha resposta não aborda diretamente sua pergunta exata "O que há de errado em culpar alguém ...?"
Kevin cline #

54

Altere "Pessoa culpada" para "Pessoa elogiada"

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


9
Eu não acho que isso responda à pergunta. É um bom sentimento, mas não fornece argumentos contra esse campo.
Bryan Oakley

21
Além disso, você conhece um cara vai introduzir centenas de erros "acidentalmente", em seguida, corrigi-los todos, esperando que algum gerente idiota vai ser burro o suficiente para pensar que ele é o melhor bug-fixer ...
MGOwen

Muitas vezes, você quer saber quem escreveu o código e quem está melhor qualificado para corrigi-lo, se der errado. Parte da reação da "pessoa culpada" é que isso implica que alguém é culpado.
Muz

49

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?


8
+1, uma cultura de culpa sempre leva a uma cultura de manter o silêncio sobre bugs e esperando outra pessoa avisos ninguém
Carson63000

45

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


15
Gostaria de votar no primeiro parágrafo, mas o segundo me parece questionável. Na minha experiência, o tipo de pessoa que sugere idéias como um campo de culpa não é o tipo de pessoa que se preocupa em deixar as pessoas desconfortáveis.
GordonM

@GordonM Realmente depende da personalidade do chefe. Um tipo de cara sem sofrimento e idiota pode não parecer gentil com a abordagem de Spartacus, mas ainda pode estar disposto a admitir que o campo cria mais problemas do que benefícios. Se o OP e a equipe mostrarem que respeitam o chefe o suficiente para tentar sua ideia, ele pode respeitá-los o suficiente para ouvir quando mais tarde lhe disserem que isso não parece útil. Além disso, ele pode saber algo que o OP não sabe, como por exemplo, que ele herdou dois perdedores de outra equipe e quer estar em posição de coletar algumas métricas.
Caleb

3
Além disso, a equipe ainda sofrerá. Tudo apenas para provar que o chefe estava errado?
amigos estão dizendo sobre oleg V.

29
Eu sempre colocava o nome do gerente lá. "Em qualquer organização, o trabalho cai no fundo, enquanto a responsabilidade flutua no topo".
David Schmitt

3
@ David: Tanto o creme quanto a escória flutuam para o topo. Com o que você está lidando na sua organização?
Donal Fellows

32

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.


1
A sua história foi engraçada e quase responde à pergunta. Você pode ajustar o tom e a linguagem para uma leitura mais positiva. Caso contrário, você continuará recebendo votos negativos. (I upvoted sua resposta.)
Evik James

20

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.


20

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.


19

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.


19

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


18

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


+1 por sugerir uma explicação positiva de como gerenciar profissionais da informação, em vez de apenas atacar essa ideia.
Oddthinking

14

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


"coloca você em uma posição melhor para oferecer uma solução, não um problema." - sim, que é o ponto principal deste post. Eu não esperava que explodisse assim.
MK_Dev

No final, será um sucesso da equipe ou um fracasso da equipe - e não importa qual seja o curso da ação (incluindo o jogo da culpa) não funcionará, ou até será uma má idéia, se não for seguida até fruição ou falha. Em outras palavras, a alternativa ao motim pode ser de fato seguir o plano de seus chefes, com participação ativa de todos - em direção à inevitável coleta de dados concretos, para pesar a favor ou contra, continuando nesse caminho da razão.
tahwos

10

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.


9

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" ?!


2
Você não pode "consertar uma pessoa" ...
SandRock

1
Temos o campo "pessoa para consertar". Não é o suficiente
MK_Dev

9

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)


8

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!


5
Não é o autor do voto negativo, mas a pergunta disse explicitamente que foram feitas várias tentativas para convencer o chefe de que era uma má ideia; portanto, o segundo parágrafo da sua resposta não era apropriado.
Larry Coleman

8
Eu discordo muito da noção de que há algo errado em deixar um emprego quando a empresa está fazendo as coisas de uma maneira idiota. Não é seu problema consertar a empresa. Se a minha demissão confirma a lógica do próprio chefe aos olhos dele, é problema dele; parou de ser minha no momento em que saí pela porta.
Nate CK

Prefiro tentar resolver o que puder. Em tal situação, se eu desistir, a empresa ficará sem solução, pelo menos por mim. Se eu posso consertar algo facilmente, em vez de começar do zero, prefiro tentar consertar. Para mim, nessa situação específica, trata-se de calcular a diferença de esforço, tempo e estresse / investimento psicológico de qualquer maneira que seja necessária e também o resultado que posso alcançar ... Muito obrigado pelo seu comentário. É bonito que todos nós temos diferentes visões de mundo :)
hasanyasin

Obviamente, se eu quisesse desistir, este post não existiria. Com isso, @hasanyasin, obrigado pela perspectiva pós - interessante. O chefe, no entanto, é uma pessoa de tecnologia / software / desenvolvedor, o que apenas torna esse problema mais problemático.
MK_Dev

@hasanyasin Sobre a bondade de insetos - É excelente! Estou triste por não poder colocar duas votações! Eu também vou usá-lo!
Gangnus

8

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.


3
Para piorar a situação, os desenvolvedores agora também são responsáveis ​​pelo controle de qualidade. Eu sei ...
MK_Dev

Que atitude perturbadora.
PDR

1
Agilizando, toda a equipe é "a pessoa responsável". O time ágil valoriza a equipe em detrimento dos indivíduos e é toda a equipe que desenvolve o aplicativo; portanto, todo bug é o problema de toda a equipe. Pense na situação em que uma construção falha em um servidor de IC. Toda a equipe deve parar de trabalhar e ver se o que precisa ser feito. Pelo menos é o que deveria ser!
Sgoettschkes

@Sgoettschkes teoricamente, eu concordo com você 100%, a equipe como um todo é responsável pelo produto que é produzido. Mas se você está tentando destacar um indivíduo específico, as pessoas que verificam o trabalho são as mais responsáveis ​​por deixá-lo escapar.

7

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.


Eu concordo com sua primeira declaração 100%. Essas foram minhas palavras quando falei sobre o assunto.
MK_Dev

7

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.


6

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


6

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.


+1 para uma solução sensata (embora eu adicionei uma resposta do meu próprio) :-)
Homer6

2
Esse tipo de pessoa assume polidez e sensibilidade pela fraqueza. A próxima vez que ele virá com algo muito pior. E ficará ainda menos ansioso para ouvir opiniões. Mesmo agora, ele diz que machucar as pessoas é divertido. Se você trabalhar em conjunto com essas pessoas, terá que se tornar um sádico também ou masoquista.
Gangnus

5

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.


Lembre-o de que, na maioria dos casos, ele pode ser o culpado. Pressão de tempo, membro da equipe, prioridades gerenciadas, ferramentas selecionadas / aprovadas ...
BillThor

Oh cara, eu conheço desenvolvedores. Eles costumam procurar a causa por outra pessoa. E eles não têm vergonha de argumentar. Eu diria que os desenvolvedores precisam procurar proativamente melhorar suas habilidades sociais e sua responsabilidade. O campo da culpa pode ser apenas um sintoma de que, no processo de desenvolvimento, algo está errado. Aposto que os desenvolvedores têm sua responsabilidade nesse problema. O gerente também parece que os insetos estão crescendo sobre suas cabeças. Portanto, é melhor que eles façam alguma análise por que o bugrate os afastou do desenvolvimento focado.
hakre

4
-1 por sugerir isso developer == no social skills. Os dois não têm nenhuma relação completa. Você pode ser bom em um, ou ambos, e ser ruim em um, ou ambos, e não há conexão.
Daenyth

@Daenyth: Foi uma provocação, tão legal que vejo você sendo provocada. Claro que essas correlações naturalmente não são verdadeiras, e é burro dizer isso (preconceito). No entanto, muitas vezes os desenvolvedores não têm habilidades sociais. Especialmente aqueles que trabalham em uma empresa que é gerenciada da maneira descrita pelo OP, eu diria.
hakre

@hakre: Se é o caso em que ele trabalha, em seguida, é só porque os mais hábeis deixaram a empresa devido à gestão
Daenyth

2

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


1

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.


-3

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.