Kravspecifikation

Formålet med denne hjemmeside er, at give jer, som har en generel forståelse for IT de bedst mulige forudsætninger for at få succes med jeres outsourcing eventyr. Jeg har valgt at skrive denne artikel, fordi jeg ofte er blevet spurgt om hjælp til kravspecifikationer i frb. med outsourcing, og derfor vil jeg gerne have et sted at henvise til med en praktisk vejledning. Når du har læst denne artikel, vil du have et bedre grundlag for at beskrive opgaver på en hensigtsmæssig måde med en simpel kravspecifikation, forstå folkene du handler med og forhandle dig til gode priser.

Jeg har i min dagligdag de sidste tre år beskæftiget mig en del med at outsource mindre IT-projekter, og er derfor ofte blevet mødt med fordomme om, at dette ikke kan svare sig. Denne myte vil jeg godt starte med at aflive. Det kan ofte svare sig at outsource mindre IT-projekter, men det der kan få projekter til at gå skævt er dårlig projektledelse, kravspecifikation eller troen på, at medarbejdere uden indsigt i IT, vil være i stand til at outsource opgaverne. Det kan sammenlignes med at sætte en bager til at fortælle en murer, hvordan et hus skal bygges. Det går som regel bedre, hvis det er en arkitekt, der tegner stregerne - og det samme gør sig gældende indenfor IT-projekter.

Indledning

Helt overordnet bygger det gode samarbejde på gensidig forståelse og respekt mellem køber og sælger. Køber bør i forbindelse med mindre projekter lade leverandøren komme med hensigtsmæssige løsningsforslag, som minder om opgaver leverandøren har udført tidligere. På denne måde føler leverandøren ejerskab til opgaven og binder sig psykologisk til at levere en tilfredsstillende løsning. Når det så er sagt, er det i forbindelse med IT-projekter ekstremt vigtigt, at der er lavet en gennemarbejdet projektbeskrivelse / kravspecifikation. I mange sammenhænge vil der blive refereret til en projektbeskrivelse som en "kravspeficikation." Forskellen på en projektbeskrivelse og en kravspecifikation er, at der i en kravspecifikation stilles krav til, hvilke krav en løsning skal leve op til, samt hvilke ønsker man har til en løsning. I en projektbeskrivelse er der lavet en tidsplan for udførsel af et projekt. En kravspecifikation anvendes, når der skal indhentes priser på en foruddefineret løsning, og en projektbeskrivelse anvendes når der ønskes at løsningen defineres i samarbejde med leverandøren. Uanset hvilken af metoderne man vælger at anvende, er det vigtigt at:

• detaljeringsgraden passer til opgaven
• leverandøren hurtigt kan overskue opgavebeskrivelsen / kravspecifikationen
• der skælnes tydeligt mellem funktionalitet og ikke-funktionalitet

Det er vigtigt at forstå, at der ikke betales for tilbudsgivning på små projekter, og derfor skal der være sammenhæng mellem projektbeskrivelsens omfang og den mulige indtjening for leverandøren, for at opgaven bliver interessant for mange leverandører - og du dermed kan forhandle en god pris.

Kravspecifikationens indhold

Dette er ikke nogen videnskabeligt velovervejet model, men min personlige opfattelse af, hvordan projekter kommer til at lykkes i praksis. Hvis opgavebeskrivelsen / kravspecifikationen indeholder nedenstående punkter i et omfang, der passer til detaljeringsgraden, øger du din chance for at gennemføre et succesfuldt projektforløb markant.

Generel beskrivelse

En generel beskrivelse af opgaven skal indeholde en kortfattet meget overordnet beskrivelse af opgaven. Hvis der er tale om et lille IT-projekt, kan dette typisk klares på få linjer. Formålet med den generelle beskrivelse er, at en leverandør hurtigt kan tage stilling til, om opgaven er relevant, hvis den f.eks. udbydes på en IT-freelancer portal.

Hvis opgaven er designrelateret, er det en super god ide at lave powerpoint skitser, eller mockups i photoshop for at forklare, hvilken retning man ønsker. Visuel kommunikation indeholder ofte meget mere koncentreret information, og derfor skal leverandøren bruge kortere tid på at forstå opgaven.

Igennem forklaringen af de forskellige underpunkter, vil der blive gennemgået et eksempel med en kontaktformular til en hjemmeside. Dette eksempel er overdrevet i forhold til detaljeringsgraden af denne type opgave, fordi jeg mener at overdrivelse i denne sammenhæng fremmer forståelsen. Eksemplet vil også blive opstillet til sidst i sammenhæng, således det kan bruges direkte som skabelon efterfølgende.

Eksempel på generel beskrivelse:

Kontaktformular til hjemmeside. Formularen består af felter, som kan udfyldes med tekst. Når formularen er udfyldt, skal der sendes en e-mail til personen, der har udfyldt formularen og til hjemmesidens ejer.

Lignende eksempler

Det er sjældent man skriver en kravspecifikation eller projektbeskrivelse, uden at have fået sin inspiration til løsningen et eller andet sted fra. Hvis det f.eks. er en eksakt kopi af en hjemmeside man ønsker udarbejdet, kan man ligeså godt skrive det og henvise til hjemmesiden, i stedet for at bruge en masse tid på at beskrive alle detaljerne. Det kan en kompetent leverandør sagtens sætte sig ind i og deraf afkode funktionaliteten. Det kan spare en del kommunikation senere i processen. Brug powerpoint, word, photoshop eller andre simple programmer til at lave grovskitser.

Eksempel på "lignende eksempler"

Kontaktformularen skal minde om formularen nederst på http://www.foxyform.com/
Her er vedhæftet et screenshot:

Funktionelle krav

I dette afsnit af kravspecifikationen skal funktionaliteten beskrives. Funktionalitet er handlinger, der skal ske pr. automatik. Det vil sige, at der ikke er tale om design, kompatibilitet, teknologivalg, specifikationer eller andre ting. Funktionalitet. Det er meget vigtigt at holde denne del adskilt fra resten, fordi det giver leverandøren mulighed for at komme med input til løsninger, som du ikke selv er klar over findes. I dette eksempel på en kravspecifikation er detaljeringsgraden stærkt overdrevet i forhold til, hvad de fleste udviklere vil have brug for, for at kunne lave en kontaktformular, men af eksemplet kan det forstås, hvad funktionelle krav er.

Eksempel på funktionelle krav

• Når felterne er udfyldte, sendes en e-mail med indholdet af kontaktformularen til e-mail adressen: xyz@123.com.
• Brugeren som har benyttet kontaktformularen modtager en e-mail umiddelbart efter, at beskeden er sendt.
• Alle felter skal udfyldes. Hvis felter ikke er udfylte modtager brugeren en fejlmeddelelse og bliver bedt om at udfylde manglende felter.
• Udfyldt kontaktinformation lagres, såledse det kan anvendes senere.
• Der skal være et felt, som skal udfyldes med kontroldata, der sikrer, at der ikke bliver sendt spam med formularen.
• E-mails afsendt fra kontaktformularen til brugeren skal afsendes med et minuts interval

Ikke-funktionelle krav

Denne del af en kravspecifikation er generelle vejledninger til opgaven, som der ikke skal programmeres funktioner til. Dette kan være svært at gennemskue, hvis ikke man har arbejdet med programmering, men som en tommelfingerregel, er det specifikationer på ting, hvor systemet ikke skal behandle data på den ene eller den anden måde. Det kan f.eks. være grafiske retningslinjer, begrænsninger, miljøvariable eller ikke-målbare krav til løsningens kvalitet.

Eksempel på ikke-funktionelle krav

• Formatering af den sendte e-mail skal være pænt opstillet, når den modtages.
• Kanterne på felterne skal være blå, hex: #2b0097.
• Overskriften på felterne skal være størrelse 11, font: arial.
• Kontaktformularen skal afvikles fra en linux webserver, fordi den eksisterende hjemmeside ligger der. (NB: De fleste som har med IT at gøre ved udemærket godt, at den oplagte løsning så er at anvende en mySQL database til lagring af kontaktinformationerne. Lad leverandøren komme med løsningsforslaget, fordi 1) han føler sig som en ekspert, 2) hvis han ikke kommer med forslaget, kan han sorteres fra.)
• De danske tegn æ ø å Æ Ø Å skal skrives korrekt i de afsendte e-mails.

Målbare krav til kvaliteten

Denne del af kravspecifikationen beskriver, hvordan kvaliteten af løsningen skal være. Det er vigtigt at kravene er målbare således, at der ikke kan opstå diskussion om, hvorvidt en løsning lever op til disse.

Eksempel på målbare krav

• Kontaktformularens html og css skal w3 validere.
• Ingen inline styling i html-koden.
• Vises identisk i alle mulige browser/styresystem/skærmopløsningskombinationer på http://browsershots.org

Udvidelsesmuligheder

Få tænkt tankerne om, hvordan projektet kan udvikle sig, hvis det går godt, og der pludselig bliver travlt. Det kan være meget omkostningstungt at ombygge et system, hvis det først er lavet - eller hvis der bliver valgt en løsning, hvor man køber et eksisterende system. Hvis der er taget højde for, at man f.eks. ønsker at udvide sit koncept med flere sprog, er det ofte en meget god ide at have dette tænkt ind fra starten. Et andet område som jeg ofte har set glemt, er versionering - hvad gør man, hvis man pludselig ønsker at gendanne en tidligere version af sit system? Få det skrevet ind som en del af kravspecifikationen fra starten, således en leverandør kan holdes op på at skulle levere det på et senere tidspunkt.

Eksempel på udvidelsesmuligheder

• Det skal være muligt at tilføje flere felter, som enten kan være tekst felter eller radio buttons
• Kontaktformularen skal på simpel vis kunne tilpasses til at blive administreret af et CMS system i fremtiden

Projektafgrænsninger

Dette afsnit skal beskrive præcist hvornår leverandørens arbejde er færdigt. Dette skal beskrives i kravspecifikationen, fordi man i nogle kulturer har leveret varen, når man sender første udkast til en løsning, og i andre kulturer forventes det, at der nærmest er et uendeligt antal korrekturgange. Det her er meget vigtigt at få defineret, således leverandøren kan give en fornuftig pris på opgaven ud fra definitionen. Det er hverken sjovt for dig som kunde, at få præsenteret en højere pris midt i processen, eller for leverandøren, som skal kommunikere det. Respektér leverandørens overordnede tanker, hvis der er tale om kreativt arbejde. Det skulle nødigt gå som det gør her. Tegneserien rammer ikke ved siden af, hvordan det ofte går i projekter i virkelighedens verden.
Følgende områder kan være en god ide at beskrive:

• Antal iterationer til korrektur.
• Hvis ansvar er det, hvis forskellige dele af projektet mislykkes?
• Særligt ved større opgaver er det vigtigt at få defineret, "hvad" der indgår i projektet. F.eks. kan det ikke forventes, at der indgår mulighed for at udsende et nyhedsbrev, fordi man bestiller en ny hjemmeside - men nogle vil forvente det, fordi deres hidtidige hjemmeside har haft denne funktion.
• Ændringer i opgaven i forhold til udgangspunktet. (man bliver klogere i processen osv.) hvad koster det

Eksempel på projektafgrænsninger

• Al funktionalitet skal være som beskrevet i de målbare krav. Dette er leverandørens ansvar.
• Der skal være én korrekturgang, hvor udseende og placering af eventuelle elementer kan tilpasses. Der udarbejdes af køber en liste med rettelser, som skal implementeres.

Efterfølgende support

Nogle firmaer leverer varen billigt og lever derefter af support. Det er ofte firmaer, hvor der bliver solgt en løsning til meget få kr. pr måned. Hvis ikke der er en skriftlig aftale på dette, skal du være afklaret med at betale en meget høj pris pr. påbegyndt time (f.eks. hvis telefonen skal besvares). Hvis du finder en leverandør, som har lige netop den løsning du søger, men du er i tvivl om supporten, så tag telefonen og ring til en af de kunder, som leverandøren fremhæver på sin referenceside og spørg dem, hvordan supporten er. Er der tale om et mindre projekt, så få afklaret helt specifikt, hvor mange timers support, der kan forventes inden det betegnes som et nyt projekt på en ny regning.

Udvælgelse af samarbejdspartner

Sørg altid for, at undersøge mindst tre alternative leverandører, når du vil outsource et projekt. Gå altid efter den leverandør, hvor kemien passer bedst, og hvor det virker som om, at vedkommende ønsker at løse opgaven bedst muligt. Det kan ofte tolkes ud af kvaliteten af den kommunikation, som leverandøren sender. Der er stor forskel på et copy-paste tilbud, der lægger op til at man kan kontakte, og en a4 side, hvor der er taget stilling til det konkrete projekts kravspecifikation. Med mindre prisforskellen er voldsom stor, så vælg den, der viser mest engagement for projektet. Hvis prisforskellen er meget stor, så undersøg flere alternativer. Det kan meget hurtigt blive dyrt, at vælge den billigste. En god tommelfingerregel for at identificere en god leverandør er, at tilbudsmaterialet mindst skal matche projektbeskrivelsen i sidetal.

Betaling og psykologi

Når projekter outsources, er der næsten altid to parter, der løber en risiko. Kunden løber en risiko i fht. at få sit projekt udarbejdet i tilfredsstillende kvalitet til tiden, samt hvad der sker efter projektet er afsluttet. Leverandøren løber en risiko i forhold til, at kunden ikke betaler for udført arbejde, stjæler produceret indhold, kommer med uendelig mange rettelser eller skifter leverandør midt i forløbet.
Seriøse leverandører vil ofte kræve en del af beløbet inden projekter påbegyndes. Dette må ikke afskrække - det sender blot et signal om, at leverandøren har tænkt sig at levere. Betal dog aldrig over 25 % forud. Der skal være en fornuftig motivation for leverandøren til at gøre arbejdet færdigt. Betal heller aldrig forud, hvis ikke leverandøren har sat sig konkret ind i projektets kravspecifikation og kommet med løsningsforslag.
Hvis opgaven er outsourcing af en stor mængde rutinearbejde til et lavtlønsområde, så tilbyd at de får en stor del, f.eks. 50 % ekstra, for arbejdet, hvis det bliver leveret uden, at der skal laves rettelser. Det kan sagtens svare sig, at få disse typer opgaver leveret i en kvalitet, hvor der ikke skal laves kvalitetskontrol til danske lønninger. Betal aldrig det sidste beløb, hvis der handles med disse områder, før hele ordren er leveret.
Hvis du som kunde får leveret et stykke arbejde, som er bedre end forventet, og kemien er god, så overvej at betale leverandøren ekstra, for at holde på vedkommende. Mange leverandører sorterer deres kunder efter, hvem der betaler bedst.

Afslutning

Du har nu fået en introduktion til at skrive en kravspecifikation til mindre IT-projekter. Har du i forvejen en fornuftig indsigt i IT, så kast dig ud i det. Begynd med mindre projekter, hvor du har råd til at tage tabet, hvis det går galt. Der kan være rigtig meget at hente økonomisk ved at få projekterne leveret fra de rigtige leverandører. Jeg har selv efterhånden opbygget et globalt omfattende netværk af leverandører, hvor jeg ved lige præcis, hvor jeg skal sende hvilke typer opgaver hen. Det kan ofte svare sig for mig, at sende opgaver ud, som tager 5-10 timer at løse. Det kan lade sig gøre, fordi der er opbygget et tillidsforhold mellem leverandørerne og mig som kunde. Jeg har også nogle gange siddet i den anden rolle, og løst opgaver for andre, hvis ikke jeg selv har haft nok at lave i mit daglige virke.
Skulle du få brug for et råd, eller har du en kommentar til denne vedledning i at lave en simpel kravspecifikation, så er du velkommen til at skrive til mig på info(at)kravspecifikation.com. - eller fang mig p Ivræksætter forummet Amino

Du kan støtte op om denne side ved at linke til den, så flere finder den. For at linke til siden kan du kopiere og indsætte følgende kode:

Jeg anbefaler i øvrigt at anvende Scriptlance til at finde freelancere, som jeg selv har haft fantastiske erfaringer med. Husk dog, at der er brodne kar alle steder, hvor der er så stort udbud.


Jeg håber du har fået det ud af denne side, som du kom efter. Ha' en super dag! :-)