Duascentas posicións no backlog, a máis antiga de hai ano e medio. Xa ninguén lembra quen a rexistrou nin se o problema ao que se refire aínda existe. Cada semana entran máis peticións das que o equipo pecha, e cada conversa sobre prioridades remata igual: todo é importante, así que nada o é. Se dirixes unha empresa ou respondes dun produto, unha lista así non é un problema técnico. É un problema de decisión. E pódese resolver sen contratar tres programadores máis.
Antes de acelerar, delegar ou recortar nada, hai que clasificar o backlog. Non pola data de rexistro nin por quen reclama o seu máis alto.
Paso 1: divide as peticións en catro cestas
A primeira clasificación faise segundo os efectos no negocio, non segundo a dificultade técnica:
- Críticas para os ingresos: peticións que bloquean as vendas, a atención ao cliente ou a facturación. Cada día de demora ten un custo calculable.
- Compliance con prazo firme: KSeF, GDPR, EU AI Act. A data límite non negocia, e a multa pode ser máis alta ca o custo de todo o cambio.
- Quality-of-life: non bloquean nada directamente, pero custan tempo da xente a diario. Copiar datos a man, un informe montado nunha folla de cálculo, atallos aos que todos se afixeron.
- Nice-to-have: ideas que hai un ano parecían boas e polas que ninguén volveu preguntar desde entón.
Dos nosos proxectos sae unha observación simple: a última cesta adoita ser o 30–50% de toda a lista. Bórraa sen medo. Se algunha idea é realmente necesaria, volverá soa, e cunha xustificación mellor ca a primeira vez.
Paso 2: engade o segundo eixe, é dicir, quen debería facelo
Para as peticións que sobreviviron ao primeiro corte, fai a segunda pregunta: a súa realización require un coñecemento profundo do teu dominio ou é traballo estándar de enxeñaría? Engadir un campo a un formulario, unha integración por API, un informe novo, unha migración de datos, probas de regresión: todo iso é igual nunha empresa de transporte e nun almacén farmacéutico. A lóxica de prezos, o algoritmo de planificación de rutas, as regras de scoring de clientes: iso non o fará ben ninguén que non coñeza o teu negocio.
Destes dous eixes nace unha matriz que ordena as decisións:
- Urxente e estándar: o mellor candidato para delegar nun socio externo. Entrada e saída ben definidas, pouco contexto tribal.
- Urxente e de dominio: o equipo propio, de inmediato. Aquí non hai atallos.
- Non urxente e estándar: delegar por lotes, cando se xunte un paquete con sentido.
- Non urxente e de dominio: aprazado conscientemente, cunha data concreta de revisión no canto do eterno «algún día».
Un erro frecuente: delegar ao revés
E aquí unha opinión, formada en proxectos de modernización: moitas empresas reparten o traballo exactamente ao revés. As tarefas difíciles, de dominio, entréganas fóra porque «non temos xente para iso», e os cambios simples gárdanos na casa porque parecen baratos. O efecto é dobremente malo. O socio externo pasa anos aprendendo un dominio que a empresa debería controlar ela mesma, porque é a súa vantaxe competitiva. E o senior propio queima semanas engadindo campos a formularios, un traballo que faría calquera executor solvente. O núcleo de dominio mantense in-house mesmo cando avanza máis lento. O traballo estándar entrégase sen sentimentalismos.
Como saber que o backlog sanea
O número de posicións na lista di pouco. Dúas métricas dino case todo:
- A idade da petición activa máis antiga. Se baixa de 18 meses a 3, a cola móvese de verdade. Se sobe, a clasificación foi cosmética.
- O lead time, é dicir, a mediana do tempo desde a petición ata o cambio funcionando en produción. É a única medida que o negocio sente.
A iso, un test de control: o balance entre o que entra e o que se pecha no mes. Mentres entre máis do que sae, ningunha priorización abondará — hai que aumentar a capacidade ou recortar con máis decisión. Unha advertencia: estas métricas son fáciles de enganar. Borrar peticións vellas só para mellorar o gráfico ordena o informe, non a empresa.
Onde encaixa ESKOM AI neste esquema
Nesta división do traballo ocupamos a columna dereita da matriz: asumimos os cambios estándar, as integracións entre sistemas e a automatización das probas de regresión, e o teu equipo segue sendo o dono do núcleo de dominio. Un proceso baseado nun equipo de axentes de IA especializados, cun alcance completo de probas automáticas (unitarias, de integración, E2E, de interface, de seguridade e de rendemento), permite pechar unha petición típica da cesta «traballo estándar» en días ou semanas; sobre de onde sae esa velocidade escribimos no texto como a IA acurta o tempo de realización dos cambios. Con franqueza: as primeiras semanas de colaboración son máis lentas, porque temos que coñecer o teu sistema e o teu contorno. Ese custo de entrada recupérase coas peticións seguintes, así que para unha única corrección menor este modelo non ten sentido. Para un fluxo de cambios teno, e moito.
Por onde comezar este venres
Bloquea unha hora no calendario e percorre a lista cunha folla de cálculo ao lado: catro cestas e despois o segundo eixe. Tras esa hora saberás tres cousas: que borrar, que facer con medios propios e que se pode delegar fóra desde xa. E se queres percorrer esta clasificación con alguén que a fixo moitas veces, concerta unha consulta gratuíta a través do formulario en eskom.ai/pl/kontakt. Ven co export do backlog. Sairás cunha lista ordenada e cunha forquita realista de tempos para as peticións que se poden delegar de inmediato.