Dues-centes posicions al backlog, la més antiga de fa un any i mig. Ja ningú no recorda qui la va obrir ni si el problema al qual es refereix encara existeix. Cada setmana arriben més peticions de les que l'equip tanca, i cada conversa sobre prioritats acaba igual: tot és important, així que res no ho és. Si dirigeixes una empresa o ets responsable d'un producte, una llista així no és un problema tècnic. És un problema de decisió. I es pot resoldre sense contractar tres programadors més.
Abans de començar a accelerar, delegar o retallar res, cal ordenar el backlog. No per data d'entrada ni segons qui reclama més fort el que és seu.
Pas 1: divideix les peticions en quatre cistelles
La primera ordenació es fa segons l'impacte de negoci, no segons la dificultat tècnica:
- Crítiques per als ingressos: peticions que bloquegen les vendes, l'atenció al client o la facturació. Cada dia de retard té un cost quantificable.
- Compliance amb data límit ferma: KSeF, RGPD, el Reglament europeu d'intel·ligència artificial (EU AI Act). La data límit no es negocia, i la sanció pot ser més alta que el cost de tot el canvi.
- Quality-of-life: no bloquegen res directament, però cada dia costen temps a la gent. Copiar dades a mà, l'informe muntat en un full de càlcul, les solucions provisionals a què tothom s'ha acostumat.
- Nice-to-have: idees que fa un any semblaven bones i per les quals ningú no ha tornat a preguntar des de llavors.
Dels nostres projectes en surt una observació simple: l'última cistella sovint és el 30–50% de tota la llista. Esborra-la sense por. Si alguna idea és realment necessària, tornarà sola, i amb una justificació millor que la primera vegada.
Pas 2: afegeix el segon eix, és a dir, qui ho hauria de fer
Per a les peticions que han sobreviscut a la primera retallada, fes-te una segona pregunta: l'execució requereix un coneixement profund del teu domini o és feina d'enginyeria estàndard? Afegir un camp a un formulari, una integració via API, un informe nou, una migració de dades, proves de regressió: tot això és igual en una empresa de transport i en un majorista farmacèutic. La lògica de preus, l'algorisme de planificació de rutes, les regles de scoring de clients: això no ho farà bé ningú que no conegui el teu negoci.
D'aquests dos eixos en surt una matriu que ordena les decisions:
- Urgent i estàndard: el millor candidat per delegar a un soci extern. Entrada i sortida ben definides, poc context tribal.
- Urgent i de domini: l'equip propi, immediatament. Aquí no hi ha dreceres.
- No urgent i estàndard: delegar per paquets, quan se n'hagi acumulat un lot amb sentit.
- No urgent i de domini: ajornat conscientment, amb una data de revisió concreta en lloc de l'etern «algun dia».
Un error freqüent: delegar a l'inrevés
I aquí una opinió, formada en projectes de modernització: moltes empreses reparteixen la feina exactament al revés. Les tasques difícils, de domini, les envien a fora perquè «no tenim gent per a això», i els canvis senzills se'ls queden perquè semblen barats. El resultat és doblement dolent. El soci extern es passa anys aprenent un domini que l'empresa hauria de controlar ella mateixa, perquè és el seu avantatge competitiu. I el sènior propi crema setmanes afegint camps a formularis, una feina que faria qualsevol proveïdor solvent. El nucli de domini, mantén-lo in-house encara que vagi més lent. La feina estàndard, delega-la sense sentimentalismes.
Com saber que el backlog es va sanejant
El nombre de posicions a la llista diu poca cosa. Dues mètriques ho diuen gairebé tot:
- L'edat de la petició activa més antiga. Si baixa de 18 mesos a 3, la cua realment gira. Si puja, l'ordenació va ser cosmètica.
- El lead time, és a dir, la mediana del temps entre la petició i el canvi funcionant a producció. És l'única mesura que el negoci nota.
I un test de control: el balanç d'entrades i tancaments del mes. Mentre n'arribin més de les que se'n tanquen, cap priorització no serà suficient — cal augmentar la capacitat o retallar amb més valentia. Una advertència: aquestes mètriques són fàcils d'enganyar. Esborrar peticions velles només per millorar el gràfic ordena l'informe, no l'empresa.
On és ESKOM AI en aquest esquema
En aquest repartiment de feina ocupem la columna dreta de la matriu: assumim els canvis estàndard, les integracions entre sistemes i l'automatització de les proves de regressió, i el teu equip continua sent el propietari del nucli de domini. Un procés basat en un equip d'agents d'IA especialitzats, amb un ventall complet de proves automàtiques (unitàries, d'integració, E2E, d'interfície, de seguretat i de rendiment), permet tancar una petició típica de la cistella «feina estàndard» en dies o setmanes; d'on surt aquesta velocitat, ho vam explicar al text com l'IA escurça el temps d'execució dels canvis. Siguem honestos: les primeres setmanes de col·laboració són més lentes, perquè hem de conèixer el teu sistema i el teu entorn. Aquest cost d'entrada es recupera amb les peticions següents, així que per a una única correcció menor aquest model no té sentit. Per a un flux de canvis, en té molt.
Per on començar aquest divendres
Bloqueja una hora al calendari i repassa la llista amb un full de càlcul al costat: quatre cistelles, després el segon eix. Al cap d'aquesta hora sabràs tres coses: què esborrar, què fer amb recursos propis i què es pot delegar a fora des d'ara mateix. I si vols repassar aquesta classificació amb algú que ho ha fet moltes vegades, demana una consulta gratuïta a través del formulari a eskom.ai/pl/kontakt. Vine amb l'exportació del backlog. En sortiràs amb la llista ordenada i amb forquilles de temps realistes per a les peticions que es poden delegar immediatament.