é muitas vezes o grito de guerra que os engenheiros de software usam para minimizar a urgência da questão de um cliente. Afinal de contas, não há tempo para adicionar novos recursos quando olhamos para o interminável registro de bugs que nos enfrenta.
para os engenheiros de software dos EUA, a diferença entre um bug e uma solicitação de recursos é cristalina. Um bug é uma discrepância entre como o código está realmente funcionando e como o nosso código foi destinado a funcionar. Um pedido de recurso requer um novo código para satisfazer um caso que não pode ser tratado pela base de código atual.Este tipo de processo de pensamento sempre nos leva à questão mais geral de como software como DoneDone deve ser usado. Sua organização deve usar um tipo de software para logar bugs, outro tipo de software para gerenciar tarefas futuras, e ainda outro tipo de software para rastrear pedidos de recursos?
A antiga pergunta…
Nós gastamos muita energia mental tentando peneirar problemas registrados por um cliente ou cliente, tentando determinar se a gente joga um problema para o “bug” bucket ou o “pedido de recurso” balde. Para o trabalho de consultoria, quando estamos trabalhando fora de um acordo pré-definido de como o software deve se comportar, isso faz sentido. Os pedidos de recurso podem exigir um custo adicional.
mas, quando se trata apenas da pura prática de construir um bom software, particularmente se estamos trabalhando em nossos próprios produtos, quanto devemos nos importar em categorizar um problema desta forma?
deixamos tecnicalidades (e Tecnologia) se intrometerem na solução de problemas.Robert Martin (também conhecido como Tio Bob) fala muito sobre software. Ele considera a Web meramente um mecanismo de entrega e nada mais. Não é a experiência do usuário final, e não é o propósito do software. É apenas um pequeno detalhe estúpido. No entanto, quando nós programadores programamos, a arquitetura de nossas aplicações é totalmente influenciada pelo fato de que é uma aplicação Web.
o Tio Bob diz para esquecer os detalhes idiotas da mesma forma, e se considerássemos o termo que usamos para “uma coisa que precisa ser feita” como um detalhe Idiota?
do ponto de vista da pessoa que registra essa “coisa”, realmente importa para ela que ela está pedindo um novo recurso versus descobrir um bug? Ela só quer que o seu problema seja resolvido por outro ser humano, e de preferência, para saber quando o seu problema pode ser resolvido.Você pode ser capaz de ver a tecnicidade mais obviamente se deixarmos o mundo do software. Quando o canalizador chegar para arranjar o chuveiro, imagino que não te importes com os detalhes. Se a cabeça do chuveiro foi instalada incorretamente (bug) ou se a junta está quebrada (bug) ou se a fita Teflon estava faltando de um tubo barato (característica), tudo que você se importa é quanto tempo ele vai demorar para corrigir e quanto você será cobrado.Erro ou pedido? São ambos. E não importa.Na semana passada, somos a Mammoth released Kin, uma ferramenta de software de RH para pequenas empresas. O Kin dá-lhe uma forma simples de rastrear os pedidos de dispensa de cada empregado. Uma coisa que Kin não faz agora é distinguir fins de semana e feriados de dias de trabalho. Então, se você queria tirar uma semana inteira durante o dia de ação de Graças, você precisa digitar manualmente a quantidade de horas que você está pedindo fora.
a equipe já recebeu alguns pedidos para que a família faça esse rastreamento automaticamente. Na verdade, está na fila de lançamento. Mas, quando está logado, em qualquer lugar que está logado, deve a equipe do Kin considerá-lo um bug, um pedido de recurso, uma tarefa, ou um item por-fazer?Chamando meu tio Bob, minha resposta é simples: não importa como você classifica o pedido. É só um detalhe estúpido.Isso não quer dizer que não devemos classificá-lo. A equipe Kin pode marcar o problema sob “pedido de recursos” e trabalhar em Corrigir problemas mais críticos primeiro (como um usuário com um problema de autorização). Isso é bom e dandy, e uma abordagem válida.
no Entanto, seria um erro assume automaticamente todas as coisas-nós-chamada-recurso-pedidos são menos urgentes do que todas as coisas-nós-chamada-de bugs. Isso faz com que o pequeno detalhe de como classificamos a questão seja a peça central para quando a resolvermos. Não devia ser assim. Em última análise, todos estes pedidos são simplesmente coisas que precisam de resolução.
deixe o detalhe técnico ser o detalhe estúpido
para esse fim, o rótulo que damos a todos estes pedidos é em grande parte sem importância. O que importa mais é que alguém está a atendê-los e há uma ideia geral de quando esses pedidos serão atendidos. O que importa mais é que 33% mais usuários irão se beneficiar do Item A sendo abordado versus Item B. independentemente do tipo de coisa Item A ou Item B é, o Item A é mais valioso para abordar. É isso. Nada mais.Então, da próxima vez que você estiver gastando muito tempo com categorizando tarefas, bugs, pedidos de recursos, e itens por-fazer, lembre-se de esquecer as tecnicalidades. São apenas os detalhes idiotas.
Inscreva-se numa Conta do DoneDone em 30 segundos. Queres ler mais de Ka Wai Cheung? O novo livro de Ka Wai sobre o programador moderno, o código do desenvolvedor, está disponível em eBook e print. Você pode segui-lo no Twitter @developerscode.
