Como lidar com um colega de trabalho que me culpou pelo bug que foi culpa dele

Algumas pessoas têm tendência para atribuir agressivamente a culpa a outras, a fim de desviar a atenção de si próprias. Uma vez que também é relativamente novo, deve ter sido muito conveniente para ele fazer o que fez.

Aqui vai o meu conselho. Escreva um e-mail, descreva qual foi a questão, como chegou à causa raiz, qual foi a solução final para ela e como pode ser evitada no futuro. Inclua todos os interessados neste e-mail.

No final deste e-mail, escreva algo nestas linhas,

XYZ,

Pode acrescentar estes passos na documentação apropriada ou no documento de Procedimentos Operacionais Padrão para este pedaço de código?

Desta forma “não está a apontar um dedo” para ele, mas está a chamar explicitamente a atenção para o facto de ele ser o proprietário deste pedaço de código e, portanto, responsável por ele. Apelar é importante porque nem todos (especialmente os gestores superiores) vão abrir qualquer ligação à base de código para ver de quem foi o compromisso.

Um pouco duro, mas ele merece-o.

Construí uma carreira em que não me refiro a jogar o jogo da culpa, mas a verdade é que os humanos ouvem a voz mais alta. No entanto, se te envolveres na defesa, ele vai puxar-te para baixo até ao seu nível e vencer-te com experiência.

Se conseguires encontrar um, precisas de um campeão. Idealmente, este deve ser o teu treinador, mas por vezes, é mais um programador bem respeitado. Eles irão bater para que você cale o barulhento. Tudo o que tem de fazer é ter uma discussão privada com eles sobre os factos (não a culpa) do que fez para resolver o problema e como eles gostariam que procedesse para que, da próxima vez que algo estiver errado com o serviço, o problema possa ser encontrado e resolvido mais rapidamente. Isso pode envolver escrever um pequeno utilitário de testes que teste o serviço directamente (sem utilizar o código dos outros programadores), ou algum registo ou algo assim, para que a questão “nós contra eles” possa ser determinada muito rapidamente. Se eles souberem quem estava realmente em falta, podem limpar o seu nome sem que você entre em conflito directo com o alto.

Eu sempre me inclinei para trás para evitar colocar outros programadores na defesa. Já disse coisas como “Estou a ter dificuldades em duplicar o problema, podem dizer-me que chamadas estão a fazer para o serviço e o que estão a receber de volta para que eu possa testar o serviço correctamente”? Se o programador se incomoda em dar-lhe vestígios de registo das chamadas e respostas reais, pergunte o que esperava receber de volta. No entanto, na maioria das vezes, o programador irá apenas mostrar-lhe o seu código. Nesse caso, por vezes é possível detectar o problema. Mesmo que o faça, mesmo assim não os chame para fora. Eles têm de ser eles próprios a encontrar o problema. Peça-lhes para passarem o código por um depurador e pergunte inocentemente o que contém uma determinada variável numa determinada linha de código. Eu poderia continuar, mas já percebemos a ideia.

É uma tradição muito boa na indústria das TI (e em algumas outras, como a aviação) que quando alguém encontra um problema, todos trabalham em conjunto para encontrar uma solução e, idealmente, para encontrar a causa raiz para que os processos possam ser melhorados, mas ninguém fica com culpas pessoais ou sofre sanções por cometer o erro. O resultado é que as pessoas são abertas e honestas quanto aos seus erros, em vez de tentarem encobri-los, o que é para benefício de todos.

Parece que há pessoas na sua loja que não compraram para esta cultura, e isso é algo que precisa da atenção da gerência.

Creio que deve ter uma conversa com o seu gestor sobre a forma como as questões são tratadas, especialmente questões prioritárias que têm impacto na experiência do utilizador.

Neste caso tem 2 sistemas a comunicar entre si e de repente a comunicação deixa de funcionar. Quando a comunicação falha, é importante que ambas as partes olhem para ambos os sistemas. Todos colocam o foco no seu serviço, levando-os a não investigar as coisas no seu fim. O maior desperdício de tempo na resolução de uma questão é tentar descobrir o que há de errado com uma parte ** que está de facto a funcionar como deveria**.

Estas são, no entanto, experiências de aprendizagem. Aposto que agora sabe perfeitamente como resolver os problemas do seu serviço. Tente estabelecer um plano de resolução de problemas com base na sua experiência e dê um dos primeiros passos para ter a certeza de que é realmente o seu serviço que está a falhar (“O serviço funciona sendo chamado de outra página?”, “O serviço está a falhar parcial ou totalmente?”). Você é O tipo do serviço web, pode ter um pouco de confiança no seu trabalho.

Tente esquecer o facto de que foi realmente o seu código que falhou. Tentar chamá-lo a atenção para isso é um pouco mesquinho. Ele não deveria ter colocado tanto o foco em si desde o início. Veja-o como uma questão geral dentro da empresa com a resolução de um problema e trate-o como tal com o seu gerente. Você também não sabe se era realmente o seu código, ele também poderia tê-lo copiado de outra secção escrita por um colega.

Penso que a sugestão de falar com o seu gerente é boa. O seu gerente precisa de saber que foi injustamente acusado.

Mas, para além disso, está a ser testado. O seu instinto inicial está certo; tem de responder, senão vai ficar pior. Eu enviava-lhe um e-mail directamente e informava-o que o problema estava no seu código e que, desta vez, não contou a ninguém a não ser ao seu gerente, a quem tinha de contar para se proteger. E, por último, diga-lhe que, se ele o fizer novamente, você irá a público.

Estou um pouco atrasado para a pergunta aqui, mas a par dos conselhos muito bons da resposta do Edgar, há uma segunda parte.

Se você enviar uma comunicação a dizer que encontrou o problema e anotar onde ele foi resolvido, então os outros desenvolvedores provavelmente saberão onde está o problema (isto é bom), mas a gerência provavelmente não saberá.

Fazê-lo assim significa que você fez um favor a este tipo - ele chamou-o publicamente, você encontrou o problema, resolveu-o e não o deixou cair com a gerência. Construir uma confiança como esta com os seus colegas de trabalho vai deixá-lo em boa posição a longo prazo.

Nota lateral ligeira - isto obviamente depende ligeiramente da natureza da falha que encontrar no seu trabalho. Se o que encontrar for tão tremendamente errado que indique incompetência da parte deles, talvez queira aumentar a sua incompetência para o seu gerente - eles vão querer saber e você está a construir confiança com eles também.

Sugiro que durma sobre o assunto antes de responder aos aspectos pessoais da situação. Se resolveu o problema e pôs as coisas a funcionar novamente, continua a ser “o homem”. Depois de descansar um pouco, será mais fácil ser gracioso.

Embora a questão principal já tenha sido longamente abordada em outras fontes - o outro tipo que o assedia - gostaria de apontar outra perspectiva.

A correção foi feita no código que o outro tipo possuía, mas na maioria das vezes o serviço poderia ter evitado uma questão maior ao ser mais conservador no tratamento dos pedidos dos clientes. Será que valida as entradas? Comunica algum erro de tempo de execução? Existe um ambiente de teste (isto também se aplica ao consumidor)? Por vezes, um problema no serviço estava apenas à espera de vir à tona, por isso eu diria que só porque foi feita uma correcção num local, não significa que essa seja a história toda. Além disso, para questões como esta, há mais do que apenas código. Há também o processo.