Construir um produto que pode salvar vidas muda como você prioriza bugs

Todo projeto tem bugs. A diferença é o peso que cada bug carrega dependendo do que o produto faz.

No BloodLink, uma plataforma de doação de sangue, aprendi isso na prática.

Um bug de layout é incômodo. Um bug que faz uma notificação de candidatura não chegar para o responsável da campanha é diferente. Se alguém criou uma campanha urgente, um doador compatível se candidatou, e o responsável nunca viu porque a notificação falhou, isso tem consequências reais.

Isso muda como você pensa sobre prioridade.

O que mudou na prática

Comecei a classificar os bugs por impacto no fluxo principal: alguém cria campanha, alguém se candidata, responsável confirma. Qualquer coisa que interrompe esse fluxo vai para o topo da lista, independente de quão pequena pareça tecnicamente.

Bugs visuais, textos errados, comportamentos estranhos em casos extremos ficam para depois. Não porque não importam, mas porque a hierarquia ficou mais clara.

O lado inesperado

Essa clareza de propósito também reduziu a paralisia de decisão. Antes eu ficava em dúvida sobre o que trabalhar. Agora a pergunta é simples: isso afeta alguém que está tentando encontrar um doador de sangue com urgência?

Se a resposta for sim, é prioridade. Se não, espera.

Não sei se isso é uma boa prática de engenharia ou só uma consequência do domínio do problema. Mas funcionou para mim.