Duzentos itens no backlog, o mais antigo com ano e meio. Já ninguém se lembra de quem o registou nem se o problema a que se refere ainda existe. Todas as semanas entram mais pedidos do que a equipa fecha, e cada conversa sobre prioridades acaba da mesma forma: tudo é importante, logo nada é. Se dirige uma empresa ou responde por um produto, uma lista destas não é um problema técnico. É um problema de decisão. E resolve-se sem contratar três programadores adicionais.
Antes de começar a acelerar, delegar ou cortar seja o que for, o backlog tem de ser ordenado. Não pela data de registo, nem por quem reclama mais alto pelo que é seu.
Passo 1: divida os pedidos em quatro cestos
A primeira triagem faz-se pelos efeitos no negócio, não pela dificuldade técnica:
- Críticos para a receita: pedidos que bloqueiam as vendas, o apoio ao cliente ou a faturação. Cada dia de atraso tem um custo mensurável.
- Compliance com prazo firme: KSeF, RGPD, Regulamento da IA. A data-limite não negoceia, e a coima pode ser superior ao custo de toda a alteração.
- Quality-of-life: não bloqueiam nada diretamente, mas custam todos os dias o tempo das pessoas. Recopiar dados à mão, o relatório montado numa folha de cálculo, os desenrascanços a que todos se habituaram.
- Nice-to-have: ideias que há um ano pareciam boas e pelas quais, desde então, ninguém perguntou.
Dos nossos projetos resulta uma observação simples: o último cesto representa muitas vezes 30–50% de toda a lista. Apague-o sem medo. Se alguma ideia for mesmo necessária, voltará por si, e com uma justificação melhor do que à primeira.
Passo 2: acrescente o segundo eixo, ou seja, quem deve fazer isto
Para os pedidos que sobreviveram ao primeiro corte, faça a segunda pergunta: a execução exige conhecimento profundo do seu domínio ou é trabalho de engenharia padrão? Acrescentar um campo a um formulário, integrar via API, um relatório novo, migração de dados, testes de regressão: tudo isto é igual numa transportadora e num armazenista farmacêutico. A lógica de preços, o algoritmo de planeamento de rotas, as regras de scoring de clientes: isso ninguém fará bem sem conhecer o seu negócio.
Destes dois eixos nasce uma matriz que ordena as decisões:
- Urgente e padrão: o melhor candidato à delegação num parceiro externo. Entrada e saída bem definidas, pouco contexto tribal.
- Urgente e de domínio: equipa própria, já. Aqui não há atalhos.
- Não urgente e padrão: delegar em lotes, quando se juntar um pacote com sentido.
- Não urgente e de domínio: adiado conscientemente, com uma data concreta de revisão em vez do eterno «um dia».
Erro frequente: delegar ao contrário
E aqui uma opinião, formada em projetos de modernização: muitas empresas dividem o trabalho exatamente ao contrário. Entregam para fora as tarefas difíceis e de domínio, porque «não temos gente para isto», e guardam as alterações simples, porque parecem baratas. O resultado é duplamente mau. O parceiro externo passa anos a aprender o domínio que a empresa devia controlar sozinha, porque é a sua vantagem competitiva. E o senior da casa queima semanas a acrescentar campos a formulários, ou seja, trabalho que qualquer fornecedor sólido faria. Mantenha o núcleo de domínio in-house mesmo quando avança mais devagar. Entregue o trabalho padrão sem sentimentalismos.
Como saber que o backlog está a sarar
O número de itens na lista diz pouco. Duas métricas dizem quase tudo:
- A idade do pedido ativo mais antigo. Se cai de 18 meses para 3, a fila está realmente a andar. Se cresce, a triagem foi cosmética.
- Lead time, ou seja, a mediana do tempo entre o registo e a alteração a funcionar em produção. É a única medida que o negócio sente.
Junte-lhe um teste de controlo: o saldo entre entradas e conclusões no mês. Enquanto entrar mais do que sai, nenhuma priorização chega — é preciso aumentar a capacidade ou cortar com mais coragem. Uma ressalva: estas métricas enganam-se facilmente. Apagar pedidos antigos só para melhorar o gráfico arruma o relatório, não a empresa.
Onde entra a ESKOM AI neste esquema
Nesta divisão de trabalho, ocupamos a coluna direita da matriz: assumimos as alterações padrão, as integrações entre sistemas e a automatização dos testes de regressão, enquanto a sua equipa continua dona do núcleo de domínio. Um processo assente numa equipa de agentes de IA especializados, com uma bateria completa de testes automáticos (unitários, de integração, E2E, de interface, de segurança e de desempenho), permite fechar um pedido típico do cesto «trabalho padrão» em dias ou semanas; sobre a origem dessa rapidez escrevemos no texto como a IA encurta o tempo de execução das alterações. Com honestidade: as primeiras semanas de colaboração são mais lentas, porque temos de conhecer o seu sistema e o seu ambiente. Esse custo de entrada paga-se a partir dos pedidos seguintes, pelo que, para uma única correção pequena, este modelo não faz sentido. Para um fluxo contínuo de alterações, faz muito.
Por onde começar já nesta sexta-feira
Bloqueie uma hora no calendário e percorra a lista com uma folha ao lado: quatro cestos, depois o segundo eixo. Ao fim dessa hora saberá três coisas: o que apagar, o que fazer com meios próprios e o que pode ser entregue para fora desde já. E se quiser percorrer esta divisão com alguém que já o fez muitas vezes, marque uma consulta gratuita através do formulário em eskom.ai/pl/kontakt. Venha com o export do backlog. Sairá com a lista ordenada e intervalos de tempo realistas para os pedidos que podem ser delegados de imediato.