Filas têm uma propriedade incômoda: o tempo de espera cresce de forma desproporcional quando a ocupação se aproxima da capacidade total. Um time de seis pessoas com duzentos itens abertos vive dentro dessa matemática. Tudo entra, nada sai da lista, e a entrega de qualquer coisa nova passa a depender menos da complexidade técnica do que da posição na fila.
Jean Pierre Lessa e Santos Ferreira, especialista em tecnologia, software e inteligência artificial, menciona que o problema raramente é de ordenação, e sim de excesso de trabalho aceito. Definir prioridades no desenvolvimento de software começa por admitir a capacidade real. Depois disso, o critério de ordenação passa a fazer diferença, e dois deles disputam a fila na maioria das empresas.
Ordenar por esforço entrega velocidade, não valor
O critério do esforço é o mais popular porque produz sensação de progresso. O time escolhe os itens pequenos, fecha quatorze ajustes no mês e apresenta um gráfico bonito. Enquanto isso, o relatório que o time comercial pede há dois trimestres continua parado, porque nunca vence a comparação com cinco tarefas de duas horas cada.
A preferência tem uma explicação razoável. Item pequeno traz menos incerteza, menos discussão com outras áreas e menos risco de estourar o ciclo, o que torna a escolha confortável para quem responde pela entrega. O efeito colateral aparece depois: o valor se acumula em cantos desconexos do produto, e o item grande nunca começa, porque começar exige perder a comparação uma vez.
Ordenar por custo do atraso muda a fila inteira
Um relatório manual que consome vinte horas semanais do financeiro tem preço conhecido. Cada semana sem ele custa aquelas vinte horas, e a conta acumula sozinha. Jean Pierre Lessa e Santos Ferreira comenta o custo do atraso como a pergunta que ordena melhor uma fila de desenvolvimento: quanto a empresa perde por semana enquanto aquilo não existe.
O critério fica operacional quando se divide esse custo pelo tamanho do item. A razão mais alta vai primeiro, o que explica por que uma tarefa pequena com perda semanal clara passa à frente de um projeto grande com benefício vago. Há um efeito secundário útil: item cujo custo de atraso ninguém consegue descrever costuma não merecer lugar na lista.
O que nenhum dos dois critérios resolve?
Dependência técnica não se dobra a cálculo de valor. Um item com perda semanal alta que depende de uma migração de banco só pode ser feito na ordem que a arquitetura permite, e forçar a sequência costuma custar mais do que esperar. Itens muito incertos também escapam da conta, e o caminho é reservar algumas horas para investigar antes de estimar qualquer coisa.
Sobre esse ponto, Jean Pierre Lessa e Santos Ferreira observa que manutenção e dívida técnica perdem toda comparação direta, porque nenhum cliente as pede pelo nome. A saída praticada por times estáveis é reservar uma fatia fixa da capacidade de cada ciclo para esse trabalho, combinada antes de o ciclo começar, em vez de submeter cada correção à mesma disputa que as funcionalidades enfrentam.
Prioridade é o que sobrevive à semana ruim
O teste real acontece na quarta-feira, quando um diretor pede algo com urgência. Se o pedido entra e nada sai da lista, não havia prioridade; havia uma lista de desejos com aparência de plano. A regra que sustenta a decisão é simples de enunciar e difícil de cumprir: entrou um item, saiu outro, com o nome de quem aprovou a troca.
Escrever o critério muda o tom da conversa. A discussão deixa de girar em torno de quem tem mais influência na reunião e passa a girar em torno do que a conta mostra, o que também protege o time de decidir por cansaço. Priorizar bem não acelera o desenvolvimento de software; apenas garante que a velocidade existente seja gasta no lugar certo.
