Kravspecifikation: Dit vigtigste dokument (som de fleste springer over)

Du kender scenariet:

Du sidder til møde med en udvikler. I dit hoved er app'en krystalklar. Du kan se det hele – hvordan brugerne klikker rundt, hvor knapperne sidder, hvad der sker når nogen logger ind første gang.

Udvikleren nikker. "Det lyder godt. Vi går i gang."

To måneder senere får du det færdige produkt. Og det er... forkert. Teknisk set virker det. Men det er ikke det du bad om. Det føles ikke rigtigt. Flowet er mærkeligt. Der mangler ting du troede var indlysende.

Hvad skete der?

Ingen kunne læse dine tanker

Det lyder banalt, men det er kernen i problemet: Du havde et klart billede i hovedet. Udvikleren havde et andet. I snakkede forbi hinanden uden at vide det.

Det sker hele tiden. Og det er dyrt. Ikke bare i penge, men i tid, frustrationer og ødelagte relationer til leverandører der "ikke forstod hvad du mente."

En kravspecifikation er løsningen. Det er et dokument der beskriver hvad du vil bygge – så præcist at der ikke er plads til misforståelser.

Hvad er det egentlig?

Tænk på det som opskriften til din software.

Hvis du beder nogen lave din bedstemors frikadeller uden en opskrift, får du noget der minder om frikadeller. Måske. Med lidt held.

Men med en præcis opskrift – mængder, temperaturer, stegetid – får du det samme resultat hver gang.

En kravspecifikation gør det samme for software. Den beskriver:

• Hvad systemet skal kunne
• Hvem der skal bruge det
• Hvordan det skal opføre sig
• Og lige så vigtigt: hvad det ikke skal kunne

Når alle arbejder ud fra samme dokument, sker der noget magisk: Udvikleren ved hvad du forventer. Du kan sammenligne tilbud, fordi alle prissætter det samme. Og når der opstår uenighed, har I noget konkret at pege på.

70% fejler – og det handler ikke om kode

Undersøgelser viser at omkring 70% af softwareprojekter ikke når deres mål. De bliver forsinkede. De sprænger budgettet. De bliver droppet halvvejs. Eller de lanceres – og så bruger ingen dem.

Det vilde er, at det sjældent handler om teknologien. Koden virker som regel fint.

Problemet ligger i starten. I de tidlige samtaler, hvor man antog ting i stedet for at skrive dem ned. Hvor "vi er enige" betød at begge parter havde hver deres forestilling.

Jeg har set projekter hvor kunden bad om "et simpelt bookingsystem" – og endte med en fuldblæst markedsplads med betalingssystem, anmeldelser og integration til fem forskellige kalendere.

Hvorfor? Fordi ingen skrev ned hvad "simpelt" betød.

Hvad skal en god spec indeholde?

En stærk kravspecifikation starter med det store billede: Hvilket problem løser du? Og for hvem?

Ikke: "En app til at holde styr på vaner."

Men: "Et værktøj der hjælper travle mennesker med at bygge bedre rutiner – uden at det føles som endnu en opgave på to-do-listen."

Derfra går du ned i detaljen:

Hvem er brugerne? De har forskellige behov. Den nye bruger vil have hjælp til at komme i gang. Power-brugeren vil have genveje. Administratoren vil have overblik.

Hvad skal de kunne gøre? Det er her user stories kommer ind. Konkrete beskrivelser af hvad hver brugertype skal opnå: "Som ny bruger vil jeg hurtigt kunne oprette min første vane, så jeg kan komme i gang uden at føle mig overvældet."

Hvad er vigtigst? Alt kan ikke bygges på én gang. Så du prioriterer: Must have (uden dette virker produktet ikke), Should have (vigtigt, men ikke kritisk dag ét), Could have (lækkert at have), Won't have (det venter vi med – for nu).

Hvad med det tekniske? Hvor hurtigt skal siderne loade? Hvor mange brugere skal det kunne håndtere? Hvad sker der hvis noget går ned? Det er ikke funktioner, men det påvirker alt.

"Det lyder dyrt"

Traditionelt koster det 35.000-100.000 kr. at få lavet en ordentlig kravspecifikation. Plus uger af møder og revisioner.

Det var derfor vi byggede Max. Samme struktur, samme kvalitet – men gennem en samtale du kan klare på en halv time. Du svarer på spørgsmål om din idé, og Max omsætter det til et dokument udviklere faktisk kan bruge.

Tre klassiske fejl

1. Vage formuleringer. "Brugervenlig" betyder ingenting. "Brugere kan oprette en konto på under 2 minutter med email eller Google" kan du faktisk bygge og teste.

2. For teknisk for tidligt. Du behøver ikke bestemme database eller framework. Du skal beskrive resultater: "Skal virke på iPhone og Android." Lad udviklerne finde ud af hvordan.

3. Alt er lige vigtigt. Hvis alt er kritisk, er intet kritisk. Du udskyder bare de svære valg til de bliver dyre. Vær ærlig om hvad version 1.0 virkelig har brug for.

Det handler om at tænke først

En god kravspecifikation garanterer ikke succes. Software er kompliceret, og ting kan stadig gå galt.

Men den tvinger dig til at tænke tingene igennem før du bruger penge. Nogle gange afslører processen at idéen skal justeres. Nogle gange viser det sig at det "simple" projekt faktisk er ret komplekst.

Begge dele er værdifulde opdagelser – så længe du gør dem mens ændringer stadig er billige.

Prøv Max og få en professionel kravspec på 30 minutter. Dit fremtidige jeg vil takke dig.