Tilbage til blog

MoSCoW: Den simple metode der redder softwareprojekter

Max Omika • 7 min læsetid

Jeg så et projekt gå ned i flammer sidste år.

Teamet havde alt: talent, budget, god stemning. De havde også en feature-liste der voksede for hver uge. Hvert møde tilføjede nye "must haves". Hver gang konkurrenterne lancerede noget, blev det til et nyt krav. Seks måneder senere byggede de stadig på version 1, mens pengene fossede ud.

Problemet var ikke de enkelte features. Hver for sig gav de fin mening. Problemet var, at ingen turde sige nej. Når alt er lige vigtigt, bliver ingenting færdigt.

Fire kasser – ingen undskyldninger

MoSCoW-metoden er fra 1994, og den virker stadig. Navnet er en huskeregel for fire kategorier: Must have, Should have, Could have, Won't have. Hver feature ryger i præcis én kasse. Ingen "medium prioritet". Ingen "ret vigtig". Fire valg, og du skal tage et.

Must have er det absolutte minimum. Uden disse features giver dit produkt ikke mening. Et bookingsystem der ikke kan tage imod bookinger er ikke et bookingsystem – det er en dyr fejlmeddelelse.

Should have gør produktet bedre, men du kan lancere uden. Brugerne ville savne dem, men de ville stadig kunne bruge systemet. Tænk SMS-påmindelser eller detaljeret statistik.

Could have er kirsebærrene på toppen. Dark mode. Badges. Deling til sociale medier. Rart at have, men ingen vælger dit produkt på grund af dem.

Won't have er det vigtigste – det er de features du aktivt vælger ikke at bygge lige nu. AI-anbefalinger. Multi-sprog. Enterprise-funktioner. Ved at skrive dem ned undgår du diskussionerne om seks måneder. "Det har vi allerede talt om – det kommer i version 2."

Sådan gør du det i praksis

De fleste forstår kategorierne med det samme. Det svære er at bruge dem ærligt.

Start med at liste alt. Features, ønsker, drømme, vanvittige idéer. Skriv det hele ned uden at sortere.

Stil derefter det ubehagelige spørgsmål: Hvad er det absolutte minimum for at nogen vil betale for det her? Ikke hvad der gør det lækkert. Ikke hvad konkurrenterne har. Hvad gør det brugbart nok til at folk åbner tegnebogen?

Det er dine Must haves. Der bør ikke være mange – fem til syv er typisk. Har du tyve Must haves, prioriterer du ikke. Du laver bare en liste med labels.

Resten sorterer sig selv med enkle spørgsmål:

Tommelfingerregel: Must haves fylder omkring 60% af dit budget. Should haves 20%. Could haves 15%. Resten bliver dokumenteret, men ikke bygget.

Hvis dine Must haves allerede sprænger budgettet, har du to valg: Få flere penge, eller vær mere ærlig om hvad der virkelig er nødvendigt.

De fire klassiske fejl

Fejl 1: Must have-eksplosionen Alle vil have deres feature i den vigtigste kategori. "Men brugerne forventer det!" siger de. Måske. Men at forvente noget og ikke kunne bruge produktet uden det er to helt forskellige ting.

Fejl 2: Tom Won't have-liste Hvis du ikke aktivt fravælger noget, prioriterer du ikke. Du håber bare, at det hele kan nås. Det kan det ikke. Nye features sniger sig altid ind – medmindre du har sagt nej på forhånd.

Fejl 3: Du prioriterer for dig selv, ikke brugeren Det du synes er vigtigt matcher ikke nødvendigvis brugerens behov. En feature der giver mening i dit regneark kan være ligegyldig for dem der bruger systemet dagligt.

Fejl 4: Du gør det én gang og glemmer det Krav ændrer sig. Det du troede var kritisk viser sig at være overflødigt. Det du troede var nice-to-have bliver pludselig afgørende. Genbesøg prioriteterne løbende – særligt når brugerfeedback begynder at tikke ind.

Et eksempel fra virkeligheden

Du bygger et bookingsystem til en frisør. Ejeren har idéer. Personalet har meninger. Du kunne bygge features i et år.

Strip det ned:

Must have:

Should have:

Could have:

Won't have:

Nu har du en plan. Byg det nødvendige. Lancér. Få feedback. Tilføj Should haves baseret på hvad brugerne faktisk efterspørger.

Det handler om at vælge

MoSCoW handler ikke om features. Det handler om fokus.

Alle succesfulde produkter startede mindre end deres skabere drømte om. De havde storslåede visioner, men de lancerede noget småt og brugbart først. Resten kom senere – baseret på viden i stedet for gætværk.

At prioritere er at sige nej, så du kan sige ja til det der betyder noget. Det er ubehageligt. Du skal forsvare dine valg. Du skal fortælle folk at deres yndlingsfeature må vente.

Men alternativet er værre: projekter der aldrig bliver færdige, budgetter der forsvinder, teams der brænder ud.

De bedste teams jeg har set behandler prioritering som en disciplin, ikke en opgave. De genbesøger deres MoSCoW-fordeling jævnligt. De fejrer features der ryger i Won't have lige så meget som dem der ryger i Must have. De ved, at bygge mindre ofte er vejen til at levere mere.

Prøv Max og få hjælp til prioritering der fører til færdige projekter.