A década de 1990 foi chamada, eles querem o processo de relatório de bugs de volta

O desenvolvimento de software melhorou 100 vezes desde que a internet foi inventada, mas a forma como as pessoas relatam bugs não mudou desde a década de 1990. Alguma vez você já experimentou este? Um engenheiro pega um tíquete e, após alguma investigação, determina que funciona bem para eles e não tem informações suficientes para reproduzir o bug. Eles adicionam um comentário ao ticket, passam para uma tarefa diferente e esperam que o relator do bug forneça mais informações. Esse ciclo se repete várias vezes, e cada vez que há uma nova informação no ticket, o engenheiro tem que lembrar onde parou e tentar retomar o fio da meada. Mudanças de contexto como essa são dolorosas para os engenheiros, e o processo típico de relatório de bugs parece ser o garoto-propaganda desse tipo de aborrecimento. A vida real de um bug Imagine que um colega de trabalho relata um problema de login no canal de engenharia do Slack e alguns engenheiros abandonam tudo para investigar. Apesar de seus melhores esforços, eles não conseguem replicar o problema. Eles solicitam mais informações, como o tipo de navegador e dispositivo. Em seguida, eles instruem o funcionário a tentar várias etapas de solução de problemas, como limpar o cache e atualizar a página. Os bate-papos assíncronos geralmente consomem uma hora ou mais. Eventualmente, a equipe de engenharia precisa agendar uma chamada de depuração com o funcionário para tentar identificar o problema em seu computador. Durante a chamada, o funcionário compartilha sua tela e os engenheiros o orientam sobre como abrir as guias do console e da rede nas ferramentas de desenvolvimento para discernir o que está acontecendo. Por fim, os engenheiros veem que há um erro 401 na guia de rede, que diz "senha incorreta". Em essência, o problema não era que o login estava quebrado, era que o front-end falhou em exibir a mensagem de erro "senha incorreta" e exibi-la para o usuário. Um simples erro de front-end que deveria levar cinco minutos para ser identificado e resolvido custou a alguns engenheiros a tarde. hora de mudar O processo de relatório de bugs de hoje permanece arcaico. Desde a década de 1990, o mundo inventou mensagens instantâneas como o Slack e videochamadas como o Zoom e adotou o trabalho remoto globalmente. A comunicação de bugs tornou-se digital. O rastreamento de bugs mudou de arquivos gravados para tíquetes do Jira. E, no entanto, os relatórios de bugs ainda estão cheios de idas e vindas incômodas que desperdiçam tempo de engenharia. Todos nós já experimentamos a frustração de lidar com relatórios de bugs pouco claros que carecem do contexto necessário para resolver o problema. É por isso que, há um ano, alguns de nós começaram a imaginar uma maneira melhor. E se pudéssemos construir uma nova ferramenta que modernizasse os relatórios de bugs e pudesse resolver o problema de relatórios de bugs pouco claros, reduzir a necessidade de comunicação de ida e volta e economizar tempo e energia dos engenheiros? E assim, a ideia de nasceu. Uma ferramenta projetada para tornar o processo de relatório de bugs mais produtivo e eficiente. Queríamos criar uma solução que ajudasse os engenheiros a resolver bugs técnicos, não problemas de comunicação. Geléia Portanto, decidimos criar uma ferramenta que permitisse a qualquer pessoa, independentemente de sua formação técnica, capturar dados técnicos contextuais avançados sobre bugs, para que os engenheiros pudessem identificar e resolver problemas rapidamente. Queríamos criar uma ferramenta que facilitasse a vida dos engenheiros e, ao mesmo tempo, ajudasse as pessoas que relatam problemas a eles a serem mais eficazes. Conforme desenvolvemos e testamos o Jam no início do ano passado, vimos o potencial que ele tinha para acelerar a maneira como nossa própria equipe trabalha. Por exemplo – pegue este Jam de um bug em nosso próprio código. Em vez de precisar ligar para depurar ao vivo, nossos engenheiros puderam ver qual era o problema, diretamente do próprio relatório de bug. Começamos a compartilhar o Jam com outras equipes de engenharia e ficamos muito empolgados com a resposta. Ramp, T-Mobile e Dell estavam entre os primeiros a adotar o Jam e forneceram um feedback inestimável que nos ajudou a moldar o produto. Repetindo a opinião deles, agora estamos orgulhosos de dizer que o Jam tem mais de 14.000 usuários e continua crescendo. Mas nosso trabalho está longe de terminar. Sabemos que o processo de relatório de bugs pode ser uma grande fonte de frustração para os engenheiros e estamos empenhados em mudar isso. Se você está farto de relatórios de bug pouco claros, convidamos você a dar uma chance ao Jam e nos contar o que você pensa. Temos a missão de construir um futuro melhor para a engenharia e precisamos do seu feedback para que isso aconteça. Você pode entrar em contato comigo pessoalmente em dani@jam.dev e se juntar a nós nesta jornada.