Lidando com as expectativas do usuário que não quer fazer o teste final do usuário
Tenho um usuário, de um departamento interno, que solicita várias alterações ou aponta bugs no site da nossa empresa. Temos laços muito estreitos e fortes, mas recentemente eles têm se incomodado com a necessidade de testar essas mudanças. Eles os consideram uma perda de tempo. Um e-mail recente que recebi tinha até esta pequena linha:
Quando você leva um carro para uma garagem para ser consertado, não é solicitado que você faça um teste para verificar se o carro está funcionando
O problema é que seguimos um modelo que, a menos que uma alteração / correção de bug seja uma emergência ou usando procedimentos padrão por escrito (por exemplo, uma alteração de parâmetro padronizado), exigimos teste / confirmação do usuário antes de podermos liberar a alteração ou correção de bug.
Qual a melhor forma de gerenciar as expectativas desse usuário e ainda assim fazer com que os testes sejam concluídos ou confirmados por ele?
Respostas
Não existe uma resposta universal. Digamos que o usuário relate um erro de grafia em uma página da web. "Diz teh onde deveria dizer o ". Você não iria atrasar a implantação dessa única correção esperando que o usuário concordasse que você corrigiu o erro de digitação.
Agora, digamos que o usuário solicitou (como um dos meus uma vez fez) que um botão fosse "dois tons mais claro de azul". Faz sentido pedir a eles que confirmem que você adivinhou corretamente o que isso significa. No entanto, a formulação é a chave aqui: "teste a correção e aprove" implica que você não tem certeza se fez a coisa certa e pode soar um pouco "cabe a você se algo der errado mais tarde". Um mais amigável "pode me dizer se gostou da nova cor" ou "certifique-se de que é o que você queria" ou mesmo "certifique-se de que meu desenvolvedor entendeu você corretamente" não é apenas mais preciso, mas contém a explicação de por que os desenvolvedores estão perguntando para o trabalho de um cliente.
Você também precisa ter certeza de que o cliente entende que você testa seu trabalho e que codificou o que pretendia codificar. O que o cliente está testando é que você entendeu a solicitação. Então, eles pedem para você adicionar uma coluna a um relatório e você se esquece de perguntar onde eles queriam: quando você entrega você diz "Eu adicionei no final" ou "Eu adicionei ao lado da data do pedido" e então peça para eles confirmarem está bem.
Claro, tudo isso é "teste". Olhe para ele e certifique-se de que gostou. Para usar a analogia, se você levasse seu carro para ser pintado de azul, não sairia dirigindo um carro vermelho brilhante sem dizer nada. Então, para tudo menos para emergências absolutas, você conserta ou adiciona o novo, coloca em teste para eles olharem e confirmarem que está bom, aí você coloca no ar. Usar a frase " confirme que é bom " faz muito do que você está procurando:
- contém a suposição de que você fez a coisa certa. "Procurar erros" contém a suposição de que há erros
- não usa um verbo que o cliente está pagando para você fazer, como "testar"
- não usa um verbo que deixe o cliente nervoso em assumir responsabilidades, como "aceitação"
Freqüentemente, adicionamos detalhes específicos às nossas solicitações de teste. Confirme se a formatação na nova coluna é o que você queria. Confirme se o desenvolvedor fez a escolha certa sobre o tamanho da fonte. Basicamente, qualquer decisão que você teve que tomar por si mesmo porque não foi especificada e, por algum motivo, você não perguntou antes de fazer, diga a eles e peça que confirmem. Qualquer coisa que seja ambígua e você não esclareceu antes de codificar, indique agora.
Qual é a melhor maneira de gerenciar as expectativas deste usuário
Compreenda completamente o problema antes de corrigi-lo e teste-o profissionalmente.
Você não deve confiar em um usuário final para o teste, ele deve ser feito por um profissional que tem interesse em garantir que ele esteja livre de erros antes do lançamento.
Você precisa apresentar a etapa de aceitação do usuário como algo que beneficia o cliente, não você.
Você tem falado sobre os benefícios para sua empresa ("exigimos testes do usuário para confirmar que a mudança / bug está funcionando como o usuário espera", "não temos permissão para lançar ao vivo sem a validação do usuário"). Não é surpreendente que o cliente sinta que está fazendo um trabalho para você. Isso, depois (na mente deles) de você ter falhado em atender às necessidades deles em primeiro lugar, liberando algo que não era o que eles queriam!
Você pode começar por explicar que esta é uma parte fundamental do processo que beneficia -los . Imagine o quão pior seria se você lançasse uma "correção" e ela ainda não tivesse sido corrigida, ou funcionando da maneira que eles queriam! Imagine se você acidentalmente piorasse as coisas !
Houve claramente uma falha de comunicação que causou os bugs em primeiro lugar. Se você tivesse entendido perfeitamente o que eles queriam, você mesmo teria testado perfeitamente essas expectativas e lançado algo que era ... perfeito. Eles encontraram um bug. Isso significa que qualquer processo que você tenha para solicitar um recurso e você fornecê-lo, perdeu algo. Não é sensato supor que o processo de relatar o bug e corrigi-lo não pode perder algo também. A coisa sensata a fazer é verificar novamente: "achamos que agora fizemos como você queria, não é?".
Isso é especialmente verdadeiro se eles estiverem pagando por qualquer uma dessas alterações ou correções. Esta é uma oportunidade para eles garantirem que seu dinheiro vale a pena. Se você liberar algo e ainda não for o que eles querem, você terá que passar por todo o processo novamente e carregá-los novamente. Não seria melhor para eles confirmarem a correção antes do lançamento, para que paguem apenas uma vez?
Em qualquer caso, precisa ser explicado a eles como uma oportunidade positiva para eles terem sua contribuição, não um dreno e exigir seu tempo sem nenhum benefício.
FWIW, eu acho uma má ideia argumentar por analogia, como outras respostas fazem, porque você acaba falando sobre algo que não é realmente o problema que você deveria estar falando. Mesmo assim, se eu levasse meu carro para consertar um pneu furado, daria uma olhada no pneu antes de sair dirigindo, para ter certeza de que realmente parecia ter sido consertado. Caso contrário, se eu apenas comecei a dirigir e percebi que estava plano no final da estrada, a garagem poderia dizer que eles fizeram o trabalho certo e o pneu novo deve ter furado depois que eu saí.
Quando você leva um carro para uma garagem para ser consertado, não é solicitado que você faça um teste para verificar se o carro está funcionando
Ah, engraçado. Quando eu levo um carro para um REPARO (e mudanças no site não são de manutenção), que pode incluir coisas encontradas na manutenção, como rolamentos de esferas de um pneu que não são totalmente redondos ...
... toda vez que isso acontecia quando eu pegava o carro, eu realmente era questionado em um test drive com um representante do mecânico (representante como: trabalhador da linha de frente, já que não super pequenos tiros separam os mecânicos do cliente).
Seu cliente parece pensar que as mudanças no site estão funcionando. Este não é o caso. A manutenção seria corrigir bibliotecas. As alterações são semelhantes a reparos ou atualizações em um carro. E o sortimento de que nenhum test drive é feito nesses casos está totalmente errado ou indica o uso de uma oficina mecânica de baixo custo, em minha experiência.
Você deve conversar com o cliente sobre isso. Também sobre o fato de que as atualizações para o fluxo de IU de um site podem não funcionar da maneira que o cliente esperava. Não que você cometa um erro - mas não posso contar quantas vezes uma solicitação de alteração foi seguida por "ah, isso não funciona como eu esperava", embora a alteração tenha sido exatamente o que foi pedido. Pegar isso cedo faz parte de um fluxo de trabalho.
Eu sugiro que você converse com eles e explique que sua comparação é uma falácia que mais aponta para o uso de uma oficina mecânica de baixo custo;)
Eu sou da opinião que você não deve dizer ao usuário para testar os bugs que eles apontaram para você, ou os recursos que eles solicitaram que você / sua empresa escolheu implementar, a menos que você não consiga recriar o bug no seu fim por qualquer motivo.
Quando eles relatarem um bug para você, você deve primeiro recriar o bug antes de implementar uma correção, para saber que realmente corrigiu o bug ... Então, quando a correção do bug for implantada, você pode comunicar ao usuário que uma correção foi implantada.
Se eles solicitarem um novo recurso, você / sua empresa deve obter todos os requisitos / expectativas antes de iniciar qualquer trabalho de implementação efetiva do recurso. Não adivinhando cegamente o que eles querem, implementando e depois pedindo que testem para você.
Você disse:
O problema é que seguimos um modelo que, a menos que uma alteração / correção de bug seja uma emergência ou usando procedimentos padrão por escrito (por exemplo, uma alteração de parâmetro padronizado), exigimos teste / confirmação do usuário antes de podermos liberar a alteração ou correção de bug.
Por que você segue esse modelo? Que requisitos / objetivos este modelo pretende atingir? Quem o instituiu?
Se a ideia é fornecer uma oportunidade para as partes interessadas verificarem a solução, coloque um cronômetro na etapa de verificação das partes interessadas e se a parte interessada não verificou uma solução (que você testou) em 2 semanas, feche o problema / item de trabalho como "completo".
Se a ideia é delegar o teste às partes interessadas, bem, imagino que você precise escalar isso no organograma, uma vez que essa parte interessada em particular não parece acreditar que suas funções incluem realizar os testes que você deseja que façam.
Se você geralmente acredita que está na mesma página com os relatores de problemas quanto aos problemas que eles estão relatando, a estratégia de tempo limite parece ser o melhor caminho a seguir.