Er arbejdet med kravspecifikationen noget, I nedprioriterer, når I starter på udviklingen af et IT-projekt? Eller måske noget I springer helt over, fordi I bare arbejder super agilt? Fungerer det godt for jer? Udarbejdelsen af en kravspecifikation er nogle steder blevet en overset disciplin. Med dette indlæg vil jeg gerne argumentere for, at kravspecifikationen er en forudsætning for, at du får succes med dit IT projekt – og ikke en fase, der kan springes over ved at arbejde agilt.
Kravspecifikationen kan have fået et dårligt ry, fordi den forbindes med en fastlåst specifikation af arkitektur, teknologi og funktionalitet. Den forbindes ofte med vandfaldsmodellen, som er en af de mest traditionelle, men også mest udskældte, metoder til projektledelse . I vandfaldsmodellen er det den første fase ”udarbejdelse af kravspecifikationen”, som definerer, hvad projektet skal ende med og modellen tillader ikke ændringer undersvejs. Når vi nogle gange hører om, at det går galt i offentlige IT-projekter, der arbejder efter vandfaldsmodellen, er det ikke fordi, man har udarbejdet en kravspecifikation, men fordi man ikke tillader ændringer undervejs i IT-projektet.
Den diametralt modsatte metode til vandfaldsmodellen er den meget succesfulde agile metode, som næsten alle udviklingsprojekter har adopteret. De fleste, der er involverede i IT projekter, kender til Scrum-metodikken og arbejder med løbende prioritering af opgaver, alt efter hvad der giver mest værdi for forretningen. Scrum skaber en iterativ proces, der tager hensyn til, at man ikke kan specificere alt fra starten af projektet. Man arbejder i iterationer, indtil man har et tilfredsstillende produkt, og det er i dette agile setup, at man skal være opmærksom på ikke at springe kravsspecifikationen over.
Det bedste af to verdener
Kan kravspecifikationen og analysefasen bruges i en mere positiv agil ramme, hvor du ikke behøver at låse alle krav fast og køre dit projekt efter en vandfaldsmodel? Ja selvfølgelig. IT-projekter er komplekse, og netop derfor bør du lave et grundigt analysearbejde og specificere kravene, inden du går i gang. Du skal dog samtidig give plads til ændringer, når du bliver klogere undervejs. Kravspecifikationen i den indledende fase bør betragtes som et startpunkt for designet af løsningen og ikke ses som et færdigt ”blueprint” på løsningen.
I en kravspecifikation bør du være meget detaljeret omkring beskrivelsen af forretningens målsætninger, krav og succeskriterier, men kun specificere løsning, arkitektur, teknologi og funktionalitet på et overordnet forretningsmæssigt niveau. Det er først, når udviklere får fingrene i koden, at de sidste detaljer falder på plads, og det er først, når forretningen får demonstreret løsningen, at de ser, hvordan løsningen tager sig ud i sin helhed.
I ”Design Thinking”, som Sopra Sterias Lean NEXT model bygger på, ligger den ideelle løsning imellem, hvad der er ”Desirable”, ”Viable” og ”Feasible. Det er nemlig ikke nok at tænke på hvilke features, man vil have (”Desirable”), men ligeså nødvendigt at sikre sig, at det er muligt at udvikle og vedligeholde løsningen på en effektiv måde. Løsningskrav (”feasible”) og løsningsdesign (”viable”) er derfor en vigtig del af kravspecifikationen. Du er ofte nødt til at genbesøge forretningens krav og så måske gå på kompromis med nogle af dem, efter du har snakket med udviklere og IT arkitekter omkring, hvad der er teknisk muligt, holdbart og gennemførligt. Udarbejdelsen af kravspecifikationen er ikke en lineær proces.
Involvér de rette personer i dit projekt
Det er en klar fordel for jeres projekt, hvis personen der udarbejder kravene, er en del af projektet gennem hele dets levetid for at sikre, at IT-udvikling bliver drevet af forretningens målsætninger og succeskriterier. Det bidrager til at minimere risikoen og øge kvaliteten af det endelige produkt.
Hvis du arbejder med implementering af IT-projekter, ved du, hvor svært det kan være at få forretningen til at omstille sig til at tage en ny IT-løsning i brug. Dette er ofte fordi, de ikke har været en del af processen fra start. Her vil arbejdet med kravsspecifikationen også indebære inddragelse af alle væsentlige interessenter og give dem en naturlig følelse af ejerskab omkring projektet. Hvis du inddrager de rette interessenter i starten af projektet, øger du chancen for at få den værdi ud af projektet, som du havde regnet med.
Agilitet og kravspecifikationen går fint hånd-i-hånd
I Sopra Steria arbejder vi både med ”den klassiske tilgang til kravspecifikationen” og med behovsanalyse som en del af vores Lean NEXT model. Lean NEXT modellen, bygger på principper fra både Design Thinking og Lean Startup og egner sig specielt godt til projekter, hvor du f.eks. skal lave en helt ny service eller innovere et eksisterende produkt og har et behov for en eksperimenterende tilgang.
Det behøver ikke tage flere måneder at udarbejde en kravspecifikation og man kan, hvis man er bekymret for tiden, sørge for at ”timeboxe” denne fase af projektet. I vores Lean NEXT model ”timeboxer” vi fasen med behovsafklaring og løsningsdesign til at vare 5 uger. Disse fem uger kan klart være med til at afgøre dit projekts succes, da det er min erfaring at denne i høj grad er afhængig af, hvorvidt du har styr på kravene eller ej. Manglende seriøst arbejde med kravspecifikationen kan være årsag til mange fejlede IT-projekter, ligesom manglende agilitet kan. Lad være med at tænke på de to arbejdsbegreber som ”enten eller” – tænk i stedet ”både og”.
At analysere, beskrive og modulere krav, samt vurdere det nødvendige detaljeniveau kræver en vis erfaring. Står du over for en større digital transformation eller et IT-projekt, hvor du har brug for at få styr på kravene, rådgiver vi jer gerne, ligesom vi også kan varetage selve udarbejdelsen af kravene for jer eller i samarbejde med jer.
Hold øje med bloggen, hvor jeg i mit næste indlæg, vil dykke ned i arbejdet med kravspecifikationen og gennemgå hvilke aktiviteter i bør gennemløbe for at udarbejde en brugbar en af slagsen.