Os “bugs” por projeto são um mau sinal?


29

É um mau sinal se os usuários enviarem relatórios de erros por itens projetados?

Isso normalmente significa que o aplicativo é confuso ou pouco claro, ou devo apenas atribuir um erro pontual ao usuário, a menos que seja especificamente indicado?

(Na verdade, não tenho esses relatórios. Essa é uma pergunta puramente hipotética sobre se a existência de "bugs" planejados é ou não uma coisa ruim.)


19
Talvez alguns dos programadores do Lotus Notes gostariam de comentar, já que a resposta padrão é "não é um bug, é um recurso que você não entende".
James Anderson

5
Sugere-me que os requisitos do usuário dados aos desenvolvedores não correspondem ao que os usuários pensam que pediram.
temptar

7
@temptar "É o que eu pedi, mas não é o que eu queria."
StuperUser

5
Recentemente, recebi um item de trabalho "bug" para um comportamento que era exatamente, especificamente, o que foi explicitamente explicitado na especificação (e que havia sido discutido durante a fase de especificação). Embora o comportamento possa muito bem ter sido inesperado do ponto de vista do usuário (uma configuração específica, que foi prestada atenção em outro lugar, estava sendo ignorada), se a especificação literalmente quase disser "vamos ignorar isso por enquanto para economizar tempo", então, para mim, não é um bug, mas uma solicitação de alteração. Certamente, um bom argumento poderia ser feito para querer que isso mudasse, mas não chame isso de bug .
a CVn

7
@ Dunk: implementei um sistema que assumia 24 horas todos os dias, porque não conseguimos convencer o cliente da existência do horário de verão. Eles simplesmente não acreditariam que existem dias com 25 horas. Isso é um bug no programa?
MSalters 01/09/11

Respostas:


54

Isso é um mau sinal? Eu acho que é um aviso que vale a pena examinar, mas também acho que isso acontecerá.

Quando as pessoas enviam qualquer tipo de feedback para mim, tento filtrá-lo em três grupos:

  • Insetos
  • Solicitações de recursos
  • Comunicação incorreta

Insetos

Os erros são quando algo obviamente não funciona da maneira que você esperaria, nem da maneira que o usuário esperaria. Tipo, ele me pediu meu nome, digitei "Scott", apertei enter e disse: "Oi Joe!"

Solicitações de recursos

É como "Eu sei que nunca conversamos sobre isso, mas o programa pode deduzir com os gestos do mouse que sou canhoto e mover o botão OK para o lado esquerdo da tela?" É quando o comportamento atual corresponde às expectativas do usuário e do usuário , mas eles desejam alterar a expectativa.

Comunicação incorreta

É quando você espera um resultado de um cenário, mas o usuário espera um resultado diferente. Às vezes, isso se torna uma solicitação de recurso, se eles simplesmente não comunicaram suas expectativas, mas pensaram que sim. Às vezes, isso se torna um erro se sua expectativa estiver errada.

No entanto, muitas vezes você sabe que o usuário não tem. E se eles dissessem: "Nesta tela, posso adicionar um registro para mim duas vezes com o mesmo nome e sobrenome! Isso é obviamente um bug!" Sua resposta pode ser: "Existem muitas pessoas no mundo com o mesmo nome e sobrenome, portanto não exigimos que essa combinação seja única. Temos uma tarefa de limpeza que é executada à noite e envia por e-mail um relatório de possíveis duplicatas para atendimento ao cliente quando achar que detecta uma duplicata com nome e endereço semelhantes e solicita que eles a verifiquem manualmente ".

Portanto, você deve ler todos os relatórios de erros, mas os sistemas mais complexos terão relatórios de erros que são realmente apenas solicitações de recursos ou possivelmente uma comunicação incorreta dos requisitos. Não entender a complexidade subjacente do mundo real é provavelmente a maior fonte desses problemas.


3
A falta de comunicação também inclui a falta de lembrança (ou simples esquecimento) das expectativas que foram comunicadas e acordadas.
Peter Taylor

1
Grandes distinções, mas ainda acho que o aplicativo deve tentar explicar a falta de comunicação, se puder. Com várias pessoas com o mesmo nome, o aplicativo pode dizer: "Nós já temos 3 John Smiths, você tem certeza de que não é um deles" com a opção 'Não, eu tenho certeza que essa é uma nova John Smith'.
Alex Andronov

@Alex Andronov - uma falha de comunicação não significa que não há uma ação a ser tomada: altere a documentação, dicas de ferramentas etc., atualize o material de treinamento ou, possivelmente, apenas uma breve explicação e siga em frente.
Scott Whitlock

7

Isso não foi abordado nas respostas anteriores até agora, então acrescentarei que também pode ser um sinal de uma base de usuários ignorantes. Não uso a palavra "ignorante" de maneira depreciativa ou condescendente, apenas como forma de expressar que eles não têm conhecimento ou educação adequada em seu domínio ou das complexidades do próprio software.

A maioria dos usuários não sabe o quão complicado é o software para atender a certos requisitos. Algo no sentido de 80% do esforço entra em apenas 20% da funcionalidade (casos adicionais e de exceção).

Às vezes, eles não entendem por que o software inerentemente precisa se comportar de uma certa maneira, muitas vezes para evitar uma infinidade de defeitos ou corrupção de dados, etc.

Isso não é preocupante, pois fica melhor com documentação e comunicação claras e concisas.


2
+1, mas observe a diferença entre complexo e complicado ... O software não precisa ser nada complicado, mas muitas vezes é muito complexo.
Marjan Venema

Isso é verdade. O caso mais comum que encontro é o de os usuários não perceberem a diferença entre os relacionamentos muitos-para-um e muitos-para-muitos. Uma solicitação comum que recebo é: "você pode fazer o relatório mostrar o número do pedido no cabeçalho?" e tenho que explicar que, embora em cerca de 95% dos casos haja apenas um número de pedido nas coisas em que trabalham, há muitos casos em que a consulta pode incluir dados em vários pedidos. Então, tenho que perguntar: você deseja que eu liste todos os números de pedidos no cabeçalho separados por vírgulas ou deseja o número do pedido em cada linha de detalhe no relatório?
Scott Whitlock

@ScottWhitlock Sim, é a mesma coisa. Um bom desenvolvedor ou analista de negócios, então, não deve apenas fazer o que o cliente pede, mas tentar descobrir o principal problema que está enfrentando, pelo motivo de ter feito essa solicitação em primeiro lugar. Depois de identificar o problema deles, você pode identificar uma solução adequada e escrever requisitos ou histórias de usuários apropriados.
maple_shaft

5

Se você tiver um usuário especialista em seu campo, poderá ter um grande problema. Imagine um contador que descobre que seu software, por padrão, não está seguindo os procedimentos gerais de contabilidade ou um engenheiro que descobre que você tem uma fórmula incorreta. Isso não deve ser muito difícil de pesquisar para ver se eles estão corretos. Redesenhe e corrija-o, se necessário - rápido.

Uma opinião sobre um recurso específico da interface do usuário ou um campo que eles acham que deve ter um símbolo de moeda ou alguma outra formatação deve ser considerada, pelo menos até você receber mais feedback. Pesquisando isso pode ser um pouco mais difícil.


1
Não há uma resposta única, então, suponho. Deve ser avaliado caso a caso. Eu imaginei isso.
Maxpm 01/09/11

5

Erros projetados na minha experiência significam que seus casos de uso não se encaixam em seus usuários reais. Tente ler sobre o uso de usuários reais para seus casos de uso (basta dar nomes a eles e uma descrição em miniatura que maravilha a qualidade dos casos de uso.)

Quando fornecedores proeminentes de sistemas operacionais dizem "esse comportamento é planejado", geralmente tinham em mente a facilidade de implementação ou a vantagem comercial. Se esse não é o seu caso, tente descobrir o conjunto de habilidades e o relacionamento reais dos usuários com o seu software. Eles usam o dia todo? Para se divertir ? Uma vez por semana porque substituiu os formulários TPS?


5

A interface do usuário deve seguir O princípio do mínimo de espanto - relatórios repetidos de erros em um recurso que funciona como projetado são uma indicação de que esse princípio não foi cumprido corretamente.


3
Ou, existe um grupo de usuários dividido. Por exemplo, digamos que seu aplicativo da web imite uma área de trabalho. Você espera que fechar uma janela feche o programa? Sim para usuários do Windows, não para usuários do Mac.
keppla

1
@ Keppla - você faz um bom argumento. Você não pode agradar a todos, portanto, no caso de "bugs", como os mencionados aqui, é necessária uma investigação para garantir que você não receberá mais relatórios de bugs após a "correção" do que antes.
Joris Timmermans

1
talvez, mas é muito mais poderoso citar os dados de "centenas de pessoas registraram bugs nisso!" do que ter alguns usuários raivosos dizendo que você violou a interpretação pessoal deles do Princípio Mágico da Mínima Surpresa e eles estão surpresos. Estou um pouco cansado deste último, já que o "espanto" de um homem é o "direto" de outro homem.
Jeff Atwood

@ Jeff Atwood - como diz o ditado "uma andorinha não faz verão", "um relatório de bug não implica um erro de design". Um único relatório de bug sobre algo que é um recurso não é motivo para um reprojeto, e mesmo vários relatórios sobre um recurso comum não significam necessariamente que a maioria dos usuários não ficaria mais feliz sem uma "correção". Especialmente se o seu lançamento original já é popular e as pessoas estão acostumadas a usá-lo "dessa maneira".
Joris Timmermans

2

Existem dois tipos de erros: a funcionalidade não corresponde às intenções do programador ou a funcionalidade não corresponde aos requisitos. Os programadores tendem a se concentrar no primeiro em detrimento do último. Simplificando, se seus usuários estão relatando muitos "bugs designados", seus requisitos não são o que você pensa que são.


2

Não necessariamente. Pode ser que o bug relatado esteja em uso do software que está fora do escopo definido originalmente. Considere o software projetado para executar A, B e C (para um exemplo trivial, desenhe linhas, triângulos e retângulos). Se D é o próximo passo lógico (por exemplo, pentágonos), o usuário pode assumir que deve fazer isso também, e que não fazer isso é um bug. Mas se isso estiver fora do escopo original, não será um erro. Em vez disso, poderia ser um descuido (bug) no design, ou uma área cinza nas especificações, ou um conjunto diferente de suposições feitas pelo desenvolvedor e pelo usuário.

(Editar - adicionei meu comentário à resposta de acordo com a sugestão de @Marjan Venema.


Realmente não vejo isso sendo marcado como um relatório de erro. Mais como uma sugestão ou solicitação de recurso. (Embora, com alguns sistemas de rastreamento de bugs, possa contar como um de qualquer maneira).
Maxpm

1
Eu concordo, na maioria das vezes, mas pode significar uma supervisão (bug) no design, ou uma área cinza nas especificações, ou um conjunto diferente de suposições feitas pelo desenvolvedor e pelo usuário.
James McLeod

1
James, se você adicionar esse comentário à sua resposta, toda a resposta se tornará melhor.
Marjan Venema

1

Eu acredito que é um mau sinal, principalmente devido ao fato de que o design não é genérico e os requisitos dos usuários não são totalmente compreendidos / analisados.

Eu vejo duas categorias de design: - Design por acidente. - Design por intenção.

O design por acidente leva a esses problemas com frequência e não pode sustentar.


1

Eu gostaria de adicionar à resposta do maple_shaft sobre a "ignorância" dos usuários. Você também deve ter em mente que 90% dos usuários se preocupam apenas com a própria experiência e a maneira de usar o sistema. Eles não se importam com outros usuários, por que deveriam? É nosso trabalho como designers / desenvolvedores receber contribuições de todos os diferentes tipos de usuários e criar algo que se adapte a todos da melhor maneira possível. Na maioria das vezes, você não consegue otimizar a solução para todos.

Mas é claro que você precisa ler e avaliar os comentários de seus usuários! Afinal, eles são aqueles que usam sua criação!


0

Os usuários que enviavam as solicitações de bugs geralmente não eram consultados sobre o design, portanto, não é de surpreender que eles vejam as coisas como bugs que foram decisões deliberadas de design. Para um usuário, qualquer coisa que não funcione conforme o esperado é um bug.

Descobri que o problema geralmente é um sinal de que o BA ou o PM só obtêm requisitos de gerentes e não de usuários reais. O que os gerentes esperam do sistema geralmente é muito diferente do que as pessoas que inserem os dados realmente precisam. Fui ensinado a coletar dados diretamente dos usuários reais, mas a maioria dos bacharéis nos quais tenho encontrado ultimamente só fala com gerentes (e geralmente com gerentes relativamente seniores).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.