.jpeg)
En aquest article
Les vostres llistes
El backlog RAG s'omple massa ràpid
En quant un pilot mostra potencial, el backlog es dispara: més fonts, més àrees, més prompts, més connectors, més idiomes. El problema no és l'ambició. El problema és perdre criteri i barrejar millores estructurals amb desitjos perifèrics.
El model de prioritats existeix per separar el que habilita valor real del que només engreixa la llista.
Què adapta MoSCoW al context RAG
MoSCoW funciona bé si es reinterpreta amb lents operatives. Must no és el més vistós, sinó el que elimina risc base o desbloqueja utilitat citable. Should millora qualitat o cobertura. Could aporta conveniència. Won't protegeix el focus.
- Must: control de fonts, permisos, avaluació o integració crítica.
- Should: millores de recuperació, cobertura i workflows freqüents.
- Could: extres d'UX o dominis encara no validats.
- Won't: idees interessants sense impacte proper o sense base suficient.
Quatre criteris per puntuar
El model proposa puntuar cada ítem per impacte operatiu, risc mitigat, dependència tècnica i esforç de validació. Aquesta combinació evita prioritzar només el visible o només el fàcil.
El que importa és veure com una tasca mou el sistema complet, no només una demo puntual.
Què sol quedar injustament avall
Permisos, neteja de fonts, observabilitat i loops de feedback solen quedar en segon pla perquè no brillen en presentació. Tanmateix, són els ítems que més eviten deteriorament quan l'ús real creix.
Un backlog madur protegeix primer la fiabilitat abans que l'show.
Com usar la priorització sense rigidesa
El model no pretén congelar el backlog. Pretén donar-li una base comuna de discussió entre negoci, producte i equip tècnic. S'ha de revisar a mesura que canvien ús, corpus o restriccions.
Priorització bona no és la que mai canvia, sinó la que canvia amb criteri explícit.
Desbloquegeu l'article complet
Inicieu la sessió amb el compte de la comunitat Kodex per continuar llegint.
.jpg)