Cuprins 6 secțiuni
Metoda MoSCoW este o tehnică de prioritizare în care sortezi cerințele unui proiect în patru grupe: Must have, Should have, Could have și Won't have. Literele „o” din mijloc au fost adăugate doar ca denumirea să sune a cuvânt, ele nu înseamnă nimic. Metoda a apărut în dezvoltarea de software, dar funcționează oriunde ai mai multe dorințe decât timp sau bani: lansarea unui site, organizarea unui eveniment, renovarea unui sediu.
Valoarea ei nu stă în etichete, ci în conversația pe care o obligă. Atunci când toate cerințele sunt „urgente”, echipa nu poate decide nimic. MoSCoW forțează o alegere și o face vizibilă pentru toată lumea, mai ales pentru cel care a cerut proiectul.
Ce înseamnă fiecare categorie MoSCoW?
Fiecare categorie răspunde la o întrebare diferită despre ce se întâmplă dacă cerința lipsește la lansare. Definițiile de mai jos sunt cele folosite, de regulă, în metodele agile.
| Categorie | Semnificație | Test simplu |
|---|---|---|
| Must have | fără ea, rezultatul nu este util sau legal | „Putem lansa fără asta?” Nu. |
| Should have | aduce valoare mare, dar există o soluție temporară | „Putem lansa fără, cu o ocolire?” Da, dar cu durere. |
| Could have | de dorit, cu impact mic dacă lipsește | „Observă cineva dacă lipsește?” Puțin. |
| Won't have (this time) | convenit că nu intră în această etapă | „Nu acum, poate mai târziu.” |
Observă formularea „this time”: Won't have nu înseamnă „niciodată”, ci „nu în această versiune”. Ea ajută la dialog, pentru că beneficiarul nu simte că cererea lui a fost respinsă, ci amânată.
Cum aplici MoSCoW pas cu pas?
Aplici metoda într-un atelier scurt, cu beneficiarul și cu echipa, în aproximativ o oră pentru o listă de câteva zeci de cerințe. Dacă lista este mai lungă, o împarți pe teme.
- Strânge cerințele într-o singură listă, formulate clar, câte una pe rând. Dacă lipsesc, folosește ca punct de pornire pachetele din WBS: cum împarți proiectul în pachete de lucru.
- Stabilește criteriile de decizie înainte de a vorbi despre cerințe: obligații legale, valoare pentru client, dependențe tehnice, cost.
- Începe cu Won't have. Pare ilogic, dar e cea mai eficientă ordine: îi liniștește pe participanți că nu vor fi forțați să facă totul.
- Apoi stabilește Must have, strict. Fiecare Must trebuie să treacă testul „fără asta nu lansăm”.
- Împarte restul între Should și Could.
- Verifică proporțiile (vezi mai jos) și redu Must dacă sunt prea multe.
Regula proporțiilor
O recomandare des întâlnită în practică este ca cerințele Must să nu depășească aproximativ jumătate din efortul total estimat. Restul este spațiu de manevră: dacă ceva întârzie, sacrifici din Should sau Could, nu din obligatoriu. Când tot ce ai pus la Must consumă 90% din timp, proiectul nu are nicio marjă.
Cum arată prioritizarea pe un exemplu concret?
Să luăm lansarea unui magazin online pentru o firmă mică de produse artizanale.
- Must have: catalog de produse cu poze, coș de cumpărături, plată cu cardul, ramburs, termeni și condiții, politica de confidențialitate.
- Should have: filtre după preț și categorie, e-mail automat de confirmare a comenzii.
- Could have: listă de dorințe, recenzii ale clienților, ambalaj cadou ca opțiune.
- Won't have (acum): aplicație mobilă, program de puncte de loialitate, traducere în alte limbi.
Observă că „termeni și condiții” este Must nu pentru că aduce vânzări, ci pentru că o activitate comercială online are obligații de informare. Un Must poate veni din lege, din siguranță sau din logica produsului, nu doar din dorința clientului.
Sfat: Când un participant insistă că ceva este Must, cere-i să descrie ce s-ar întâmpla concret în prima zi fără acea funcție. Dacă răspunsul este „am lucra mai greu, dar am merge”, e Should.
Ce greșeli strică metoda?
Cea mai frecventă greșeală este inflația de Must: cerințele sunt etichetate obligatorii din teama de a le pierde. O listă în care 80% sunt Must nu mai este o prioritizare, ci o listă de dorințe cu etichete.
Alte capcane:
- Decizii luate de o singură parte: dacă prioritizezi doar în echipa tehnică, vei afla la lansare ce conta pentru client.
- Lipsa unui criteriu comun: fiecare folosește propria definiție de „important”.
- Categorii rămase neschimbate toată viața proiectului: dacă un risc nou apare, un Should se poate transforma în Must sau invers.
- Fără Won't have: dacă nu spui clar ce nu faci, domeniul crește pe nesimțite, iar Scope creep: cum previi extinderea necontrolată a proiectului descrie exact acest mecanism.
Cum o folosești în proiecte agile și în cele clasice?
În proiectele agile, MoSCoW se aplică pe backlogul produsului, iar elementele Must formează de obicei primele sprinturi; despre roluri și evenimente vezi Scrum pe înțeles: roluri, sprinturi și ceremonii. În proiectele clasice, aplici metoda o singură dată, la definirea domeniului, și o recitești când apar modificări; compară cele două abordări în Agile și Waterfall: comparație între metodologiile de proiect.
Un detaliu util este să păstrezi lista Won't have vizibilă. Când peste două luni cineva cere o funcție din ea, nu începi o discuție de la zero: arăți că a fost deja discutată și că poate intra într-o etapă viitoare, cu alt buget. Aceeași logică de prioritate stă și în matricea urgent–important din Matricea Eisenhower: cum separi urgentul de important, aplicată însă la sarcinile personale. Pentru panorama planificării, vezi Managementul de proiect: ghid complet pentru începători.
Pe aceeași temă, citește și Povești utilizator: cum le scrii și le accepți corect.
Întrebări frecvente
MoSCoW înseamnă ceva legat de orașul Moscova?
Nu. Numele este doar un acronim pronunțabil, format din inițialele celor patru categorii, cu două litere „o” adăugate pentru ușurința pronunției.
Câte cerințe ar trebui să fie Must have?
Ca reper de lucru, Must ar trebui să ocupe cel mult jumătate din efortul total. Dacă depășești, nu mai ai spațiu de manevră când apar întârzieri.
Cine decide categoriile?
Decizia o iau împreună beneficiarul sau sponsorul și echipa. Beneficiarul știe valoarea, echipa știe costul și dificultatea; fără ambele, rezultatul este părtinitor.
Se poate schimba prioritatea unei cerințe pe parcurs?
Da, dar printr-o decizie explicită. Cerințele noi se prioritizează la fel ca cele vechi, iar în locul lor trebuie să iasă altceva dacă termenul și bugetul rămân aceleași.
Ce fac cu cerințele Won't have?
Le păstrezi într-o listă separată, pentru etapele viitoare. Lista arată că cererile au fost auzite și amânate conștient.