Correção de bugs raramente é divertido. Isso é especialmente verdadeiro para erros que você não criou.

Se você trabalhar em um aplicativo estabelecido, há uma boa chance de que um bug de produção tenha sido introduzido por alguém que não é você. No entanto, alguém, mais provavelmente você, precisa corrigi-lo. Além disso, bugs de produção geralmente exigem atenção imediata e colocam pressão extra sobre você para corrigi-los. Tudo isso torna a correção de bugs de produção nada divertida.

Felizmente, existem várias maneiras de lidar com a correção de bugs de produção, de modo que é um pouco menos chato para todos os envolvidos. Infelizmente, nenhum desses caminhos é muito bom.

Um por todos e todos por um

Uma abordagem é fazer com que todos sejam responsáveis pela correção dos defeitos de produção. Assim, todos os engenheiros podem trabalhar em qualquer defeito relatado no campo.

O apelo principal dessa abordagem é a justiça. Quando todos estiverem em uma fria para bugs de produção, nenhuma pessoa (ou um pequeno grupo de pessoas) fica “presa” corrigindo o fluxo aparentemente interminável de bugs, enquanto os outros estão vivendo a boa vida trabalhando em novos recursos.

Fazer esse trabalho, na realidade, não é trivial, pois pode ser desordenado e te distrair. Se você está no meio da elaboração de um modelo de domínio para um recurso novo e complexo, interromper o trabalho para corrigir um bug urgente, como os do IE7, não é o ideal para a produtividade. A troca de contexto pode sair cara.

Em cima disso, fazer compromissos de entrega confiáveis se torna muito difícil. Quero dizer, imagine que você esteja a meio caminho através de uma iteração quando de repente a coisa esquenta e você tem 2 defeitos urgentes que devem ser corrigidos ontem. O que acontece com esses 20 pontos da história que você pensou que estavam sendo facilmente feitos?

Claro, você poderia tentar planejar melhor. Você poderia experimentar e escolher bugs que estejam, pelo menos, se aproximando do que você está fazendo atualmente. E, desde que você já esteja “nos bastidores”, corrigir algumas extremidades soltas não deve ser muito ruim.

Infelizmente, você raramente tem o luxo de decidir a ordem em que corrige bugs de produção. Mais provável é o cenário onde os seus clientes decidem com base em quão difíceis são os problemas.

O lobo solitário

Outra ideia é revezar um ou dois engenheiros fora da equipe principal para se concentrarem em correção de bugs. Dessa forma, a dificuldade ainda está espalhada uniformemente por toda a equipe, mas não é tão perturbadora.

A dificuldade com essa abordagem é fazer as transições de forma ininterrupta. Imagine uma situação em que você obtém um novo bug alguns dias antes de você ter programado a liberação do suporte de produção. À primeira vista, o bug parece razoável e você decide assumir.

Avance dois dias. Corrigir o bug se transformou em uma escavação arqueológica. Você meio que descobriu por onde começar corrigi-lo, mas provavelmente está a dias de realmente terminar. E agora você tem que parar e liberar.

O que acontece com o bug? Bem, você poderia tentar fazer com que o engenheiro que chegasse retomasse de onde você parou. Ou você poderia deixá-lo desfrutar da mesma jornada de descoberta e de dificuldade pela qual você acabou de passar. De qualquer maneira, não há uma sobrecarga de transição não-trivial.

“A Band of Brothers”

Finalmente, você pode ter uma equipe dedicada a corrigir bugs de produção. Esta abordagem é o meio termo entre todo mundo fazendo isso e apenas uma pessoa. E, como a maioria dos motivos “meio termo”, ele tem algo para todos não gostarem.

Primeiro, há um sentimento distinto entre os devs que estão em uma equipe não ser diferente de ser enviado para Gulag. Isso é especialmente verdadeiro se você tiver uma base de código hostil com a qual lidar.

Em segundo lugar, porque essa equipe não participa ativamente no desenvolvimento de feature, há uma tendência para desconectar. Depois de um tempo, você verá que a compreensão da pilha de tecnologia não é tão profunda, práticas dev não são seguidas rigorosamente etc.

Pensamento final

Corrigir bugs de produção pode ser difícil, não importa qual estrutura organizacional você adota. Seu desafio é descobrir maneiras para torná-lo menos difícil, talvez até mesmo agradável. Mas isso é assunto para outro artigo.

***

Texto original disponível em http://tatiyants.com/production-bugs-whos-responsibility-are-they/