Um fluxo de trabalho sem dor para relatórios e resolução de problemas

(Este é um post patrocinado.) Erros, bugs e outros problemas podem surgir no desenvolvimento web. Mesmo que não sejam erros absolutos, os clientes geralmente têm feedback sobre como algo foi projetado, onde foi colocado ou como certos elementos funcionam. É apenas parte do show.

Também pode ser uma parte muito dolorosa do show.

Veja este cenário, por exemplo:

E-mail nº 1 do cliente: “Não consigo mais ver o botão. Você pode, por favor, colocá-lo de volta na página inicial?”

E-mail nº 2 de você: “A qual botão você está se referindo? Você pode me enviar uma captura de tela?”

Você tenta ligar para o cliente, mas recebe o correio de voz.

E-mail nº 3 do cliente: “O botão para agendar uma demonstração”.

Você olha para a captura de tela anexada e vê que a seção Reservar uma demonstração está intacta, mas o botão não aparece. Você abre o site no Chrome e no Safari e o vê nos dois navegadores: um grande botão azul que diz “Agendar Demo”. Você o puxa para cima no seu iPhone e o vê lá também.

E-mail nº 4 de você: "Você pode me dizer em qual dispositivo e navegador você está vendo o problema?"

E-mail nº 5 do cliente: “Meu telefone”.

Você sabe como essa cadeia de mensagens vai e só vai levar à frustração em ambas as extremidades. Sem mencionar o custo para o seu negócio toda vez que você precisar fazer uma pausa no trabalho para tentar interpretar um relatório de bug e depois trabalhar nele.

Então, há o custo de bugs para seus clientes que você tem que pensar. Quando algo dá errado após o lançamento e seu cliente está tentando ativamente enviar tráfego para o site, um bug pode prejudicar suas vendas.

Quando isso acontecer, quem você acha que eles vão atrás?

Um fluxo de trabalho sem dor para relatórios e reparos de problemas

Não importa o tamanho do bug ou problema. Quando é detectado e relatado, ele precisa ser tratado. Há uma série de razões para isso.

Para começar, é a única maneira de fazer com que seu cliente aprove um projeto como concluído. Além disso, a resolução rápida e imediata de bugs leva a um melhor relacionamento com seu cliente, que vê o quanto você investiu na criação de um site impressionante (e livre de erros) para seus negócios. E, claro, quanto mais eficientemente você resolver os erros, mais rápido poderá voltar a terminar este trabalho e passar para outros!

Então, aqui está o que você precisa fazer para lidar com esses problemas de forma mais eficaz e indolor.

1. Atribuir alguém para triagem
2. Use um fluxo de trabalho de resolução de problemas
3. Dê aos seus usuários uma ferramenta de relatório de bugs
4. Dê ao seu Triage Manager uma plataforma de rastreamento
5. Trabalhe em uma plataforma de teste local
6. Sempre feche o loop

1. Designe alguém para fazer a triagem

A primeira coisa a fazer é decidir quem fará a triagem dos problemas.

Se você trabalha por conta própria, essa responsabilidade é sua. Se você trabalha em equipe, deve ir a um gerente de projeto ou líder de desenvolvimento que possa gerenciar os problemas relatados com a mesma eficácia com que gerenciaria a carga de trabalho da equipe.

Esta pessoa será então responsável por:

• Monitoramento de problemas relatados.
• Adicionando os bugs à fila.
• Conduzindo-os através do fluxo de trabalho de resolução.
• Resolvendo e fechando relatórios de bugs.
• Analisando tendências e revisando seus processos para reduzir a probabilidade de que bugs recorrentes apareçam novamente.

Depois de saber quem gerenciará o processo, é hora de projetar seu fluxo de trabalho e criar uma série de ferramentas em torno dele.

2. Use um fluxo de trabalho de resolução de problemas

Seu gerente de triagem não pode fazer isso sozinho. Eles precisarão de um processo que possam seguir de perto para levar cada problema do Ponto A (detecção) ao Ponto B (resolução).

Para garantir que você cobriu todas as etapas, use uma ferramenta de visualização como o Lucidchart para definir as etapas ou estágios do seu fluxo de trabalho.

Aqui está um exemplo de como seu fluxograma pode ficar:

Vamos decompô-lo:

Você começará identificando onde o problema foi detectado e por meio de qual canal foi relatado. Este exemplo não é muito específico, mas digamos que o novo problema detectado foi o mencionado anteriormente: o botão Reservar uma demonstração está ausente na página inicial.

A próxima coisa a fazer é responder à pergunta: “Quem encontrou?” Na maioria dos casos, este será um feedback enviado pelo seu cliente do seu software de rastreamento de bugs (mais sobre isso em breve).

Em seguida, você entrará nos vários estágios pelos quais seus problemas passarão:

Essa é a parte do processo em que o gerente de triagem determinará a gravidade do problema de um botão Reservar uma demonstração ausente (que é "Grave", pois custará as conversões do cliente). Eles então passarão para o desenvolvedor para verificá-lo.

Dependendo de quantos desenvolvedores ou especialistas no assunto estão disponíveis para resolver o problema, você também pode querer dividir este estágio com base no tipo de bug (por exemplo, funcionalidade quebrada versus atualizações de design).

Independentemente disso, uma vez que o bug foi verificado e em que contexto (como se fosse apenas no iPhone 7 ou anterior), o ticket é movido para “Em andamento”.

Por fim, seu fluxograma deve detalhar as etapas subsequentes para problemas que podem ser resolvidos:

Você pode nomear essas etapas como quiser. No exemplo acima, cada etapa explica muito especificamente o que precisa acontecer:

• Novo problema
• Em andamento
• Teste
• Consertar
• Verificar
• Resolver
• Fechar o ciclo.

Para simplificar as coisas, você pode usar um fluxo de resolução como este:

• Novo problema
• Façam
• Fazendo
• Feito
• Arquivo.

Independentemente de como você optar por configurar seu fluxo de trabalho de patch, apenas certifique-se de que o patch de bug seja testado e verificado antes de fechar o ticket.

3. Dê aos seus usuários uma ferramenta de relatório de bugs

Quando se trata de escolher uma ferramenta de relatório de bugs para o seu site, você quer uma que facilite para sua equipe e clientes deixar feedback e ainda mais fácil para você processá-lo.

Uma dessas ferramentas que faz isso bem é chamada BugHerd.

Basicamente, o BugHerd é uma maneira simples para pessoas não técnicas relatarem problemas para você visualmente e contextualmente. Como não há necessidade de treinar os usuários sobre como entrar na ferramenta de relatório de bugs ou usá-la, é menos uma coisa que você tem que gastar seu tempo neste processo.

Além do mais, BugHerd poupa você do trabalho de ter que lidar com o incessante vai-e-vem que ocorre quando o feedback é comunicado verbalmente e fora de contexto.

Com o BugHerd, no entanto, os usuários deixam comentários no site com a mesma facilidade com que deixam uma nota adesiva em sua mesa. Além disso, o feedback é fixado no local exato onde o bug existe.

Deixa eu te mostrar como funciona:

Quando você adiciona o site do seu cliente ao BugHerd (é o primeiro passo), você será solicitado a instalar a extensão do navegador BugHerd. É isso que permite ao BugHerd fixar a barra de feedback no site.

Se parece com isso:

Essa barra de feedback fixada torna incrivelmente fácil para os clientes deixarem comentários sem realmente alterar o site ao vivo.

É assim que o pop-up do rastreador de bugs se parece:

Como você pode ver, é um formulário muito simples. E, realmente, tudo o que seus clientes precisam fazer é selecionar o elemento na página que contém o bug e inserir os detalhes. O restante pode ser preenchido pelo seu gerenciador de triagem.

À medida que novos comentários são adicionados, os comentários são fixados na página onde foram deixados. Por exemplo:

Você também notará na captura de tela acima que as tarefas que receberam um nível de gravidade estão marcadas como tal. Eles também são listados de cima para baixo em quão críticos eles são.

Do seu lado, você tem a opção de onde visualizar seus comentários. Você pode abrir o site e revisar as notas fixadas em cada página. Ou você pode acessar o aplicativo BugHerd e revisar os comentários do seu quadro Kanban:

Por padrão, todos os bugs entram no Backlog para começar. É trabalho do seu gerente de triagem preencher cada bug com detalhes ausentes, atribuir a um desenvolvedor e movê-lo pelas etapas para a resolução.

Dito isto, o BugHerd assume muito do trabalho mais tedioso de capturar relatórios de bugs para você. Por exemplo, quando você clica em qualquer um dos bugs relatados em seu quadro Kanban, esta barra lateral “Detalhes da tarefa” aparecerá:

Esse painel fornece detalhes extras sobre o problema, mostra uma captura de tela de onde ele existe no site e também informa quem deixou o comentário.

Além disso, BugHerd captura “Informações Adicionais”:

Dessa forma, você não precisa se preocupar com o fato de o cliente não fornecer o contexto completo do problema. Esses detalhes informam em qual dispositivo e navegador eles estavam, quão grande era a tela e qual resolução de cor eles estavam visualizando.

Você também dá uma olhada no código do elemento buggy. Se houver algo realmente quebrado ou codificado incorretamente, você poderá localizá-lo daqui.

Em suma, o BugHerd é uma ótima ferramenta para simplificar o que todos precisam fazer de todos os lados e garantir que cada solicitação seja atendida em tempo hábil.

4. Dê ao seu Triage Manager uma plataforma de rastreamento

Se você deseja manter esse fluxo de trabalho o mais simples possível, pode usar o painel BugHerd para rastrear e gerenciar suas solicitações:

Seu gerente de triagem e equipe de desenvolvimento provavelmente desejarão usar algo para complementar os recursos de relatório de bugs do BugHerd. Mas boa sorte pedindo ao seu cliente que use uma plataforma como o Jira para ajudá-lo a gerenciar bugs.

Nesse caso, recomendo adicionar outra ferramenta a esse fluxo de trabalho.

Felizmente para você, o BugHerd se integra perfeitamente a softwares de rastreamento de problemas e helpdesk como Jira, Zendesk e Basecamp, para que você não precise se preocupar em usar várias ferramentas para gerenciar diferentes partes do mesmo processo. Assim que a conexão for feita entre suas duas plataformas, qualquer tarefa criada no BugHerd será automaticamente copiada para o seu centro de resolução de problemas.

Agora, se há uma ferramenta que sua equipe já está usando, mas com a qual o BugHerd não se integra diretamente, tudo bem. Você pode usar o Zapier para ajudá-lo a se conectar com ainda mais plataformas.

Por exemplo, é fácil criar instantaneamente um “zap” que copia novas tarefas do BugHerd para seus cartões do Trello. E tudo acontece de dentro do BugHerd!

Uma vez que a conexão é feita, seu gerenciador de triagem pode começar a trabalhar na plataforma de gerenciamento de tarefas ou de rastreamento de problemas de sua escolha. Nesse caso, é isso que acontece quando o Zapier conecta o BugHerd e o Trello:

Esta é uma nova tarefa que acabei de criar no BugHerd. Em segundos, o cartão foi colocado no projeto e lista exatos do Trello para o qual configurei o zap:

Isso tornará o trabalho do seu gerente de triagem muito mais fácil, pois ele não será limitado pelos estágios disponíveis no BugHerd e ainda terá todas as mesmas informações prontamente ao seu alcance.

5. Trabalhe em uma plataforma de teste local

Quando os bugs são relatados, você não deseja testar e implementar as correções assumidas no site ativo. Isso é muito arriscado.

Em vez disso, trabalhe na resolução de problemas de uma plataforma de teste local. Este artigo tem algumas ótimas sugestões sobre ferramentas de desenvolvimento local para WordPress que você pode usar para isso.

Essas ferramentas permitem que você:

• Faça rapidamente uma cópia do seu site.
• Reproduza o bug com as mesmas condições do servidor.
• Teste as possíveis correções até encontrar uma que funcione.

Só então você deve trabalhar para corrigir o bug no site.

6. Sempre feche o loop

Finalmente, cabe ao seu gerente de triagem encerrar cada questão formalmente.

Primeiro, eles devem informar ao cliente (ou visitante) que relatou originalmente o problema que ele foi resolvido. Esse tipo de transparência e responsabilidade dará à sua agência uma aparência mais polida, ajudando você a criar confiança com clientes que podem ficar nervosos ao descobrir bugs em primeiro lugar.

Uma vez que as coisas são fechadas do lado do cliente, o gerenciador de triagem pode arquivar o relatório de bug.

Mas não deve terminar aí.

Assim como os gerentes de projeto tradicionais, um gerente de triagem deve acompanhar regularmente as tendências, bem como a gravidade geral dos bugs encontrados em seus sites. Os dados podem revelar que há um problema mais profundo em jogo. Dessa forma, sua equipe pode se concentrar em resolver o problema subjacente e parar de gastar tanto tempo reparando os mesmos tipos de bugs e problemas.

Empacotando

Pense em todas as maneiras pelas quais problemas e bugs podem ser relatados: por meio de um formulário de contato, por e-mail, por telefone, por bate-papo ou, pior ainda, em um fórum público como a mídia social.

Agora, pense em todas as diferentes pessoas que podem relatar esses problemas para você: sua equipe, o cliente, um cliente do seu cliente, uma pessoa que o encontrou aleatoriamente enquanto olhava o site e assim por diante.

Existem muitas variáveis ​​nessa equação, o que torna fácil perder de vista as questões em aberto. Pior, quando o feedback é vago, subjetivo ou incapaz de explicar sem qualquer contexto, torna-se muito difícil resolver os problemas completamente ou em tempo hábil.

No entanto, com o sistema certo de relatórios, rastreamento e organização de feedback, você pode colocar ordem nesse caos e eliminar de forma mais eficaz os bugs encontrados em seu site.