Hvorfor det koster å beskrive løsningen
Et krav som sier hvordan, gjør tre ting samtidig, og alle tre er uheldige.
- Du utelukker bedre alternativer. Leverandøren har kanskje en ferdig komponent som løser behovet på en time. Har du spesifisert en annen mekanisme, må den bygges fra bunnen.
- Du overtar ansvaret. Har leverandøren bygget nøyaktig det du beskrev, og det ikke løser problemet, er det din regning. Beskriver du behovet, er det leverandørens ansvar at løsningen faktisk dekker det.
- Du låser deg til i dag. Løsninger eldes fort. Behov gjør det sjeldnere.
Testen: still spørsmålet «hvorfor?»
Ta et hvilket som helst krav og spør hvorfor det står der. Fortsetter du å få meningsfulle svar, er du fortsatt i løsningsrommet. Når svaret blir en forretningsmessig grunn du ikke kan grave videre i, er du framme ved behovet.
«Systemet skal ha en eksportknapp til Excel.»
Hvorfor? «Fordi controller skal viderebehandle tallene.»
Hvorfor i Excel? «Fordi det er slik hun jobber i dag.»
Hva må hun oppnå? «Avstemme mot regnskapet hver måned.»
Det siste svaret er behovet. Kanskje er svaret fortsatt en Excel-eksport — men kanskje er det en ferdig avstemmingsrapport som gjør hele manuelle jobben overflødig. Det finner du bare ut hvis du lot spørsmålet stå åpent.
Eksempler
Systemet skal ha en nedtrekksmeny der brukeren velger avdeling.
Systemet skal sende e-post til saksbehandler når en sak endres.
Systemet skal lagre dokumenter i en mappestruktur per år og måned.
Brukeren skal kunne knytte en registrering til én av virksomhetens avdelinger, og feilvalg skal kunne rettes uten å slette registreringen.
Saksbehandler skal bli varslet om endringer på egne saker innen 15 minutter, gjennom en kanal brukeren selv kan velge.
Et dokument skal kunne gjenfinnes ut fra dato, sak og dokumenttype uten at brukeren kjenner lagringsstrukturen.
Når du likevel skal spesifisere løsningen
Regelen er ikke absolutt. Det finnes fire situasjoner der det å låse løsningen er riktig, og da skal du gjøre det bevisst og begrunne det i dokumentet:
- Interoperabilitet. Skal systemet snakke med noe som allerede finnes, er protokollen et reelt krav. «Skal integreres mot Altinn» er et behov, ikke en løsning.
- Regelverk. Krever loven en bestemt mekanisme — for eksempel innlogging på et gitt sikkerhetsnivå — er den mekanismen kravet.
- Forvaltbarhet. Har dere fem systemer på samme teknologi og én driftsavdeling, er teknologivalget et reelt virksomhetsbehov. Skriv det som det: begrunnet i forvaltning, ikke i preferanse.
- Eksisterende lisenser. Har dere allerede betalt for en plattform, er det legitimt å kreve at den brukes.
Når du låser en løsning, ta med én setning om hvorfor. Det hindrer at kravet blir slept videre til neste anskaffelse lenge etter at grunnen falt bort — som er en av de vanligste måtene kopierte kravlister oppstår på.