Ideias, tutoriais e novidades da nossa equipe.
Uma notificação que ninguém usa ensina as pessoas a ignorar a próxima. Como decidi quem fica sabendo de uma mudança numa tarefa no BugDump: destinatários definidos a partir da própria tarefa, nada sobre as suas próprias edições e uma rajada de cliques de triagem enviada como uma notificação só.
Campos personalizados são a funcionalidade que toda equipe pede e depois lamenta. O teste que separa um campo que vale a pena de um que vai estar vazio em seis semanas, e os quatro que se pagam.
Todo bug tracker vem com baixa/média/alta/crítica, e toda equipe as renomeia na cabeça sem dizer nada. Para que serve uma escala de prioridade, quantos níveis você precisa e por que as palavras têm de ser suas.
A maioria dos dashboards de bugs só conta coisas. Os úteis respondem a uma única pergunta: estamos dando conta? Quatro métricas que respondem, as que enganam sem ninguém perceber e uma revisão semanal de cinco minutos montada em cima delas.
Um ID de bug não é o número de uma linha no banco de dados. É uma palavra que as pessoas dizem umas às outras. Por que a numeração por projeto e uma chave curta como BD-42 deixam mais fácil falar sobre os bugs, e os trade-offs por trás do design.
A maioria das equipes não é lenta para decidir quais bugs importam; é lenta em tudo o que fica em volta da decisão. Um fluxo de triagem de bugs que elimina a navegação em vez de pedir que você pense mais rápido.
O design está no Slack, o log está num drive, a especificação está na caixa de entrada de alguém. Por que os anexos de relatórios de bug se espalham por várias ferramentas, quanto isso custa quando o bug volta e como manter cada arquivo no próprio bug.
Como uma agência troca as threads de e-mail sobre bugs por um widget em cada site de cliente: relatórios estruturados, um quadro por projeto e uma entrega limpa.