Kravspesifikasjonens tid er forbi

(publisert i Computerworld 16. april 2010)

Skriving av kravspesifikasjoner er en selvfølgelig del av de fleste IT-prosjekter. De fleste av oss hater oppgaven, men vi ser på det som noe som er helt nødvendig. Men hva om hele ideen med kravspesifikasjoner er feil? Hvordan skulle IT-systemer utvikles hvis man ikke hadde kravspesifikasjoner?

Nå regner jeg med at mange tenker: «herregud, så naivt» eller «det blir kaos». Kravspesifikasjonen er jo selve fundamentet som definerer hva et prosjekt skal oppnå. Selv de som har gått over til smidig utvikling vil nok synes at dette er å gå for langt. Smidig utvikling er for så vidt basert på ideer om kontinuerlig forandring samt bruk av erfaring for å tilpasse målene. Eksperter på smidig utvikling anbefaler generelt at man holder kravspesifikasjonen på en mer overordnet nivå og at man er åpen for å forandre på kravene underveis. Det er likevel en stor forskjell på å skrive en mindre detaljert kravspesifikasjon og å ikke skrive den i det hele tatt.

Skillet mellom hva og hvordan

Ta følgende påstand: «Kunden beskriver hva som ønskes og leverandøren finner ut hvordan dette skal realiseres». Dette er for mange intuitivt korrekt. Problemet med intuisjon er at den ikke altid er til å stole på. Ting som høres intuitivt riktige ut kan fortsatt være helt feil. Kjernen i påstanden over er ideen om at hva du ønsker kan separeres fra hvordan det løses. Dette er dessverre en illusjon. Hva du ønsker deg er i høgste grad avhengig av hvordan det løses.

En tidsreise

Anta at du sitter i et møterom. Du er en del av en gruppe som skriver kravspesifikasjonen for domstolenes nye saksbehandlingssystem. Systemet må kunne lagre informasjon om hver sak som blir behandlet av en domstol. Men hva med video? Skal systemet kunne lagre en video fra hver rettssak? Jeg gjetter at gruppen etter en kort diskusjon kommer frem til at dette er et «Må krav» alternativt et «Bør krav». Verdien av å lagre video fra rettsaker er åpenbar og kostnadene er ikke spesielt store.

Nå kommer det uventede. Når du var på vei inn i møterommet ble du transportert 40 år tilbake i tiden. Du tror det er 2010 men de andre i rommet vet at det er 1970. Når du har vant deg ved de rare frisyrene og klærne så fokuserer du på kravene. Du foreslår at systemet burde lagre video fra hver rettssak. De andre ser på deg som om du har blitt helt sprø. Det er helt urealistisk å tro at systemet skal klare ditt krav til en rimelig kostnad.

Man kan selvfølgelig også tenke seg at du ble transportert 40 år frem i tiden. Når du foreslår at lagring av video kunne være en god ide så blir de andre like vantro, men av helt motsatt grunn. I en tid der kostnaden for lagring av video er null finnes det ikke noen grunn til å diskutere hvorvidt det er kostnadsmessig forsvarlig å gjøre det.

Du synes kanskje at video eksemplet er urettferdig. Det finnes jo mange krav som er like aktuelle i dag som for 40 år siden. Spørsmålet er om disse kravene hadde vært aktuelle 50 år tilbake. Krav er «selvfølgelige» når teknologien bak dem er velkjent. Vi «vet» at lagring av korte tekster er så og si kostnadsfritt. Det har vært sant lenge. Men hva med de ting som akkurat nå er i ferd med å bli enkle? Den snabbe teknologiske utviklingen gjør at kunder risikerer å overse muligheter gjennom å ikke ta med krav for ting de tror er alt for kostbare. Andre krav kan være utdaterte. Hvor mange systemer som bygges i dag har det tvilsomme kravet om å kunne håndtere fax?

Alternativer til kravspesifikasjonen

Hva er da alternativet til å lage en kravspesifikasjon? Jeg foreslår at man går til et noe uventet sted for inspirasjon, reklamebransjen. Når en kunde skriver kontrakt med et reklameselskap så er det som oftest ikke for et prosjekt. Kontrakten legger i stedet grunnlaget for en relasjon over flere år. Reklameselskapet jobber sammen med kunden og studerer hva den gjør og ønsker å få til i fremtiden. Fra dette formuleres ideer som utarbeides i samarbeid med kunden. En del av disse ideene leder til prosjekter, andre er mer åpne. Over tid vil kunden bruke et antall (usikre) måleparametere for å vurdere hvor godt reklameselskapet lykkes med å hjelpe kunden oppnå sine mål. Mesteparten av de mål kunden er opptatt av er ikke relaterte til et prosjekt, de er formulert i termer av selve forretningen.

Hvordan skulle IT-bransjen se ut om den fungerte på denne måten. I stedet for å skrive kravspesifikasjoner ville kunder beskrive hvordan forretningen fungerte i dag og hvilke overordnede mål de hadde for fremtiden. Hvis en kunde planla å bruke en ekstern leverandør ville valget primært være basert på leverandørens evne til å hjelpe kunder å oppnå sine mål. Leverandører ville jobbe aktivt med kundene for å beskrive hva som burde gjøres. Alt dette ville ha krevd en annen type leverandør. En som ikke var fokusert på «prosjektet». En som visste at IT systemer kan skape problemer og ikke bare løse dem. Og kanskje viktigst av alt, en som rakst identifiserte nye muligheter som kunden burde benytte seg av.