Desde que me tornei um desenvolvedor de software e usei sistemas de rastreamento de bugs, temos enfrentado o mesmo problema fundamental em todos os projetos em que trabalhamos: como o senhor distingue bugs de solicitações de recursos?
Claro, há alguns travamentos óbvios que são claramente bugs. Mas isso representa talvez 10% daquilo com que o senhor lida diariamente, e os verdadeiros bugs que impedem o uso normal do sistema são erradicados rapidamente, para que o projeto inteiro não fracasse. O restante das entradas em seu sistema de rastreamento de bugs, a grande maioria, existe em uma terra cinzenta e incerta de ninguém. Os usuários relataram um bug? Não exatamente. Os usuários estão solicitando um recurso novo ou aprimorado? Não exatamente. Bem, qual é o recurso?
É um problema insolúvel. Além disso, acho que a maioria dos sistemas de controle de bugs falha porque eles nos fazem fazer as perguntas erradas. Eles forçam o senhor a escolher um lado. Hatfields vs. McCoys. Coca-Cola vs. Pepsi. Bug vs. Solicitação de recurso. É uma decisão dolorosa e arbitrária, porque, na maioria das vezes, é a ambos. Não há diferença entre um bug e uma solicitação de recurso do ponto de vista do usuário. Se o senhor quiser fazer algo com um aplicativo (ou site) e não puder fazê-lo porque esse recurso não está implementado, qual é a diferença entre isso e não poder fazer algo devido a uma mensagem de erro?
Veja um exemplo: O Visual Studio não usa a fonte correta ao criar aplicativos do Windows. Isso é um bug ou uma solicitação de recurso?
Pessoalmente, considero isso um bug. Acho que a Microsoft também considera, pelo menos em teoria, porque tem sido no sistema de controle de bugs Connect da Microsoft há mais de quatro anos. Quando você cria um aplicativo Windows, não espera que ele use a fonte padrão do sistema operacional subjacente em que está sendo executado, a menos que você tenha dito explicitamente o contrário? Bem, adivinhe o que acontece quando o senhor cria um novo formulário no Visual Studio 2008 e instancia um controle de rótulo.
Festejem como se estivessem em 1996, pessoal, porque os senhores terão a MS Sans Serif e a os senhores vão gostar. Esse é o padrão para cada novo formulário. Não importa que cada novo aplicativo que o senhor criar se pareça com – deixe-me colocar isso da forma mais delicada possível – ass.
Aqui está uma comparação entre um rótulo com a fonte padrão e um rótulo que foi explicitamente definido com a fonte padrão da GUI.
A julgar pelos aplicativos que usei, a maioria dos desenvolvedores do Windows não está nem aí para o design. Isso é ruim. O que é ainda pior é saber que esse mesmo descuido com o design vem na caixa de cada cópia do Visual Studio desde 2002.
É claro que as questões de design são tão subjetivas. Se ao menos houvesse alguma fonte definitiva que pudéssemos consultar sobre a questão do uso adequado de fontes GUI do Windows. Algum tipo de padrão de referência, por assim dizer. Como, por exemplo, o principais regras para a experiência do usuário do Windows Vista da Microsoft:
- Usar o tema Aero e a fonte do sistema (Segoe UI)
- Use controles e caixas de diálogo comuns
- Use a moldura padrão da janela, use o vidro criteriosamente
Há 12 regras no total, mas a regra que estou procurando está bem no topo — os aplicativos devem usar a fonte do sistema.
A hilaridade dessa lista já é meio que evidente, já que escrevi um post inteiro lamentando a falta geral de ajuste e acabamento no Windows Vista. Não pude deixar de rir da regra número 12: Reservar tempo para o “ajuste e acabamento”! Agora há uma regra que a Microsoft deveria ter levado a sério ao desenvolver o Windows Vista. Entenda que tudo isso vem de um cara que gosta de Vista.
Mas estou divagando.
Apesar de o comportamento da fonte do Windows Forms no Visual Studio 2008 contradizer o regra número um das próprias diretrizes de design da Microsoft, esse “bug” não foi corrigido por mais de quatro anos. Ele foi silenciosamente reclassificado como uma “solicitação de recurso” e efetivamente ignorado. Afinal de contas, nada está quebrado: usar a fonte errada não causou nenhuma falha no aplicativo nem perda de produtividade. Por outro lado, imagine quantos aplicativos da BigCorpCo foram criados desde então que violam as próprias regras de design da Microsoft para sua plataforma. Seja porque os desenvolvedores não perceberam que a fonte do aplicativo não correspondia ao sistema operacional, seja porque não tiveram tempo para escrever o código de solução alternativa necessário para que o aplicativo fizesse a coisa certa.
Sim, isso é uma coisa pequena. E tenho certeza de que corrigi-lo não resultaria na venda de mais um milhão de licenças do Visual Studio para a BigCorpCo, e é por isso que isso ainda não aconteceu.
Mas a pergunta permanece: isso é um bug ou uma solicitação de recurso?
Uma de minhas coisas favoritas sobre o UserVoice — que usamos para o Stack Overflow, é a forma como ele intencionalmente confunde a linha entre bugs e solicitações de recursos. De qualquer forma, os usuários nunca entendem a diferença e, o que é pior, os desenvolvedores tendem a usar essa divisão como uma cunha contra usuários. Coloque as coisas que o senhor não quer fazer no balde de “solicitação de recurso” e passe a ignorá-las para sempre. Argumente com veemência e em alto e bom som que algo relatado como “bug” claramente não o é, e talvez o senhor não precise trabalhar para corrigi-lo. Se o senhor parar de dividir o mundo em bugs e solicitações de recursos, essas duas patologias de projeto desaparecerão.
Gostaria que, como setor, pudéssemos passar menos tempo brigando com unhas e dentes pelas definições, colocando meticulosamente o feedback nas categorias “bug” ou “solicitação de recurso”, e mais tempo fazendo algo construtivo com o feedback de nossos usuários.