Hvorfor jeg ikke skriver kravspecifikationer

Som leder og direktør har jeg i mange år bestilt IT-løsninger på den måde, man skal: behov, kravspecifikation, tilbud, projekt, leverance. Det tog måneder, og resultatet ramte sjældent præcist. Ikke fordi leverandøren var dårlig, men fordi vi beskrev noget, ingen af os havde set endnu.

Specifikationen er det dyreste trin

En omfattende kravspecifikation låser løsningen fast, før nogen har prøvet den. Den kan tage uger at skrive og prissætte, før arbejdet begynder. Når leverancen kommer, har forretningen flyttet sig, og ændringer koster ekstra, fordi de ligger uden for det aftalte.

Det værste er ikke prisen. Det er, at specifikationen tvinger forretningen til at gætte. De bedste idéer til et værktøj kommer, når man står med første version i hånden og ser, hvad der mangler.

Hvad der har ændret sig

Med AI-assisteret udvikling kan én person, der forstår både forretningen og systemerne, bygge en fungerende første version på den tid, det før tog at holde det første afklaringsmøde. Det er et paradigmeskift i systembranchen, både i tid og i omkostninger. AI ændrer også, hvad systemet kan levere: ikke blot KPI'er, historiske grafer og prognoser, men analyser, prioriteringer og konkrete oplæg til handling for den enkelte bruger hver dag. I den virksomhed, jeg ledede, er en bookingløsning gået fra samtale til drift på to dage, en afgrænset første CRM-version fra designskitse til intern afprøvning på én dag, og en produktionsapp fra eksport af den gamle til drift på ti.

Det ændrer rækkefølgen. Først samtalen, en time eller to. Så første version i virksomhedens eget miljø med virksomhedens egne data. Så gennemgang med dem, der skal bruge den. Det, der før var en specifikation, bliver til rettelser i et kørende system, som brugerne kan afprøve.

Hvad det kræver af ejerlederen

Det kræver tre ting: adgang til systemerne, hvor læseadgang er nok til at begynde, én kontaktperson, der kan svare og træffe mindre beslutninger, og cirka en time om dagen i den første uge til at se, prøve og give tilbagemeldinger.

Til gengæld er forløbet opdelt, så du kan tage stilling igen efter afdækningen og efter første version. Der er ingen kontrakt på måneders arbejde og intet implementeringsprojekt, fordi første version er afgrænset til et kort forløb. Videreudvikling og forankring aftales særskilt.

Kravspecifikationen er erstattet af strategiske forretningsmål

Det eneste, jeg skriver ned på forhånd, er de strategiske forretningsmål. Hvad skal være anderledes i forretningen, når systemet virker? Hvilket tal skal flytte sig? Målene fylder få linjer og holder hele vejen, fordi det er dem, løsningen bygges efter og måles på. Tekniske krav dokumenteres, når løsningen tager form.