Jeg har arbejdet med it- og softwareudvikling i 15 år og har flere gange stået i en situation, hvor der er opstået en konflikt mellem udvikleren (leverandøren) og den virksomhed (kunden), som har bestilt arbejdet. Jeg har siddet på flere sider af bordet: Dels har jeg ejet et udviklingsfirma, hvor jeg har repræsenteret både udviklere og kunder, dels har jeg selv købt udvikleres arbejde til min egen virksomhed. Jeg har derfor en bred forståelse for og erfaring med de konflikter, der kan udspringe af udviklingsarbejde, og for, hvordan man optimerer et samarbejde. Den viden vil jeg gerne dele med dig, uanset om du er udvikler, køber af udvikling eller selv har et udviklingsfirma.

I dette blogindlæg forklarer jeg, hvorfor konflikterne opstår, og hvordan de kan undgås. Man skal nemlig forholde sig til et hav af faldgruber og udfordringer.

Derfor opstår konflikter
Konflikter opstår, fordi der kan være langt imellem det, der efter udviklerens mening skal kodes, og det, der efter kundens mening skal leveres. For mange mennesker er koder og teknik en black-box, og de har kun en begrænset viden om, hvor tidskrævende udvikling er. Samtidig kan det være svært for udvikleren at estimere tidsforbruget i forbindelse med en opgave – medmindre han tidligere har kodet et fuldkommen tilsvarende projekt, og kunden leverer en komplet liste med selv de mindste detaljer. Mange tror, at estimater i forbindelse med it-projekter holder, men de kan som en gylden regel ganges med 3. Og selv det tal kan overskrides, for selve kodningen er kun en del af et it-projekt. Der skal også udarbejdes en beskrivelse af, hvordan det skal kodes (altså en kravspecifikationsplan), der skal ske testning samt den endelige finpudsning. Af disse årsager kan det dels være svært at få en fast pris, dels være vanskeligt at sætte en deadline. Den erfarne udvikler har som udgangspunkt bedre forudsætninger for at beregne tidsforbruget ved en opgave, især hvis han har kodet et lignende projekt før, men selv i disse tilfælde kan der opstå problemer. Ofte kræver løsningen også integration med 3. parter, hvor det kan være en udfordring for både udvikler eller kunde, hvem der skal stå på mål for teknikken, kvaliteten og mangler fra denne parts side. Netop fordi der er så mange ubekendte, fordres der et stærkt, tillidsfuldt og nært samarbejde mellem udvikleren og kunden, hvis projektet skal blive en succes. Det er nødvendigt at have en fælles forståelse for udfordringerne, når tingene tager længere tid end forudset, eller man ikke har indregnet alt det, der kan ske undervejs.

Den evige black-box
Eftersom arbejdet med software for den ikke it-kyndige er en black-box, kan en udvikler altid henvise til, at en opgave har taget længere tid end forventet og dermed sende aben videre til kunden. Omvendt kan kunden bede om, at en funktion skal kunne mere end det leverede. Eftersom aftalen er så åben for fortolkning, kan han hævde, at udvikleren burde have taget højde for dette og hint. Og det er vel en af de mest almindelige konflikter mellem koder og kunde: Koderen har brugt mere tid end forventet, mens kunden synes, at det er gået for langsomt, og at der stadig mangler nogle funktioner.

Et af de største problemer er, at udviklere ofte tager timebetaling i stedet for at give et fast tilbud baseret på kundens krav. I kundens øjne bliver det derfor en elastisk aftale. Der kan også opstå en uoverensstemmelse, hvis kunden har en fast liste med funktioner. Hvis disse funktioner ikke er beskrevet i dybden med ”usynlige” detaljer og grænsetilfælde, kan det for udvikleren blive en uendelig arbejdsopgave.

Det farlige og umulige estimat
Udviklere hader estimater, for der er så mange ubekendte, og hvis man som kunde ønsker færre af dem, må man acceptere, at udvikleren foretager en omfattende undersøgelse, før han kan skrive en komplet kravspecifikationsplan. Min erfaring er dog, at kunden ikke ønsker at betale for en sådan indledende undersøgelse. Udvikleren må derfor finde en stor del af sine løsninger løbende, og grænsetilfældene kan oftest først identificeres, når han går i gang med at kode. Derfor ender det gerne blot med en overordnet aftale om, hvad der forventes leveret, hvilket er opskriften på konflikter.

Nedfæld en kravspecifikationsplan, som accepteres af udvikleren
De bedste aftaler, jeg har indgået, og som ikke er endt med et halvfærdigt eller ikke-eksisterende stykke software, har bestået i en kort og klar opgavebeskrivelse i et sprog, som jeg som slutkunde har forstået, efterfulgt af løbende updates og konkrete præsentationer af softwaren.

Et eksempel på en funktion kunne lyde således: ”Jeg skal bruge en simpel loginside, som følger branchestandarderne”. Det er en bred beskrivelse, men den indbefatter en mængde indforståede ting som fx:

– At man kan logge ind med navn eller e-mail

– At man kan få sin kode tilsendt, hvis man har glemt den

– At man har en bruger og et kodeord.

Hvis ovenstående skulle beskrives, så der hverken var rum for misforståelser eller fortolkning, ville det let kunne fylde en halv til en hel A4-side, og så begynder det at blive omfattende. Omvendt skal man som udvikler være påpasselig med en for åben kravspecifikationsplan, især hvis man ikke kender kunden på forhånd. Som beskrevet ovenfor kan man ende i en situation, hvor kunden aldrig bliver tilfreds.

Ud over en plan for udviklingen skrevet i et letforståeligt sprog er det vigtigt, at udvikleren accepterer denne liste, så han kan stille de kritiske spørgsmål, inden aftalen indgås, og forventningerne afstemmes. Det er selvfølgelig umuligt at forudse alle de problemer, der kan opstå undervejs, men for både udvikler og kunde er det klogt at gennemdrøfte den overordnede kravspecifikationsplan, som danner grundlaget for den endelige aftale. Der skal ikke være tale om en dybtgående undersøgelse, men om en dialog, hvor udvikleren kan stille de rette spørgsmål, og kunden beskriver, hvad der ønskes leveret. Den tid er godt givet ud for begge parter.

Selvom det er svært at estimere tidsforbrug, er det et vigtigt led i en sådan aftale. Dermed kan kunden selv vurdere, hvor væsentlig en funktion er. Hvis udvikleren fx mener, at en funktion vil tage 24 timer at levere, kan kunden overveje, om den er så nødvendig, at der skal ofres tre arbejdsdage på den.

Løs konflikten med advokater og gør jer selv til tabere
Når konflikten så alligevel opstår, er det oplagt at lade to advokater fra hver side af bordet udrede uenigheden. Her er det dog min erfaring, at dette er den dyreste løsning, hvor kun advokaterne vinder. Det er ofte den absolut bedste løsning, hvis man kan blive enige mellem hinanden og anskue konflikten så nøgtern og objektiv som muligt: Hvad blev der aftalt, hvor må man selv give efter og hvor er der punkter, hvor man skal have noget fra modparten. Alt for mange forhandlinger sker med egoet som frontfigur i stedet for at tilsætter fairness og forståelse for begge sider af bordet. Derfor: Lyt, lyt, lyt og stil tingene op i forhold til fakta med mindst mulige følelser indblandet. På den måde vil man ikke alene kunne gå hvert til sit på en god måde, hvor løsningen tager udgangspunkt i fakta, man vil også gøre det på den billigste måde.

Betaling
Det er oplagt at betale løbende for det udførte arbejde. Men som kunde bør du kun acceptere dette, hvis du løbende kan se, at udvikleren er på rette vej, og du får mulighed for at teste dele af softwaren. Jeg har ofte oplevet, at en udvikler efter sin egen opfattelse har arbejdet i mange, mange timer, mens der ikke er skyggen af kode at se. Jævnfør eksemplerne ovenfor kan udvikleren jo altid hævde, at de mange timer er gået med at undersøge ting eller på møder med samarbejdspartnere, der måske er involveret i det endelige stykke software. Sagen er bare, at du som kunde i sidste ende forventer et konkret produkt, ikke et stykke papir med utallige konsulenttimer, som er brugt på undersøgelser – altså medmindre det er det, du har bestilt.

I skal være alignet fra starten
Hvis du vil undgå disse udviklerkonflikter, skal I være alignet fra starten. I skal tage udgangspunkt i en kravspecifikationsplan, som beskriver dine forventninger til slutproduktet. Denne plan skal være udarbejdet sammen med udvikleren, så I begge har en forståelse for, hvad der skal leveres. Først når I er enige om dette, og det er nedfældet i en plan, har du et godt udgangspunkt for at undgå konflikter. Uden dette essentielle dokument vil din dag næsten med garanti blive fyldt med ærgrelser.

 

Gå aldrig glip af et blogindlæg – tilmeld dig mit nyhedsbrev.

Leave a Reply