Hold budgettet som forstegangskøber af programmeringsydelser

Som førstegangskøber af programmeringsydelser kan det være svært at gennemskue, hvor meget et IT-projekt vil koste. Jeg giver her mine bud på, hvordan du får din programmør til at give dig en mere realistisk pris.

Af Kristian Just Iversen

Med ideen til sit IT-projekt på plads melder sig hurtigt spørgsmålet: hvad vil det koste at få programmeret?

Sammenstødet mellem to forskellige verdener kan give unødvendige overraskelser og kan betyde, at man som kunde ender med en fornemmelse af, at man ikke fik hvad man bestilte, eller at det blev dyrere, end man havde fået stillet i udsigt.

Det er mit mål med denne artikel som programmør at bidrage med viden, der hjælper til et bedre samarbejde mellem programmør og kunde.

Programmørens forbandelse

Det er vigtigt at forstå, at det som udgangspunkt er meget vanskeligt for en programmør at gætte prisen på en udviklingsopgave.

Dette skyldes, at programmering ikke blot er timevis indtastning af kode. Det er i ligeså høj grad en tænkeopgave. Mit bud er, at 30-50 % af en programmørs tid går med at udtænke, hvordan programmet skal skrives.

På tidspunktet hvor programmøren skal give sit overslag eller tilbud, har han derfor af gode grunde ikke det totale overblik over, hvor mange timer projektet tager at lave. Ellers ville programmøren allerede have udført op mod halvdelen af arbejdet!

Et overslag vil derfor altid blive givet med stor usikkerhed og risiko for, at tidsforbruget vil være helt anderledes.

Et tilbud vil omvendt næsten altid være en dyrere løsning for kunden, da programmøren her vil dække sig ind for ikke at miste penge.

Ved større projekter kan det betale sig at allokere mange timer til estimering af projektets omfang.

I almindelighed bør det derimod ses som en fælles opgave at opkvalificere programmørens gæt.

Her er et par tips til, hvordan I øger nøjagtigheden af et overslag ved at opkvalificerer programmørens gæt.

Tip 1: start til slut

Sørg for, at programmøren har kendskab til projektet fra den overordnede idé til den detaljerede beskrivelse af delopgaverne. Ikke enten eller.

Chancen for, at programmøren selv kan gætte en funktions ønskede adfærd optimeres, når han kender jeres tanker bag projektet.

Sætter I programmøren ind i jeres ambitioner med projektet, kan der også allerede fra start laves en struktur, der sparer jer mange ekstra timer, når I påbegynder næste fase.

Tip 2: branchekendskab

Er dit IT-projekt henvendt til en speciel branche, så afsæt tid med programmøren til at forklare om branchens kunder, der skal benytte projektet.

Bliver jeg som programmør bedt om at lave en portal omkring hundetræning, ved jeg intet om det. Det er første gang jeg er inde på det marked. Alle mine kunder er i forskellige brancher, og der er forskellige “ubekendte variable” i de forskellige brancher.

Branchekendskabet hjælper os med at forstå dem, der skal bruge systemet.

Tip 3: kravspecifikation

I tilbudsgivning vil programmøren typisk arbejde ud fra en positiv afgrænsning.

Der gives altså kun tilbud på de opgaver, der er beskrevet. Programmøren kan ikke altid selv gætte sig til, om der er nogle funktioner, der mangler - heller ikke selvom de kan synes åbenlyse. Det er dig som kunde, der bestemmer, hvilke funktioner der skal udvikles.

Sørg derfor for, at alt er med i kravspecifikationen. En hjælp til dig selv kan være at udarbejde skitser af webapplikationen og “lege” bruger, der benytter siden. Har du overset en knap/funktion, vil det hurtigt blive opdaget.

En gennemlæsning af tilbuddet er sjældent tilstrækkeligt til at fange evt. manglende funktioner.

Psykologisk pres

Det er forståeligt, at man som kunde kan være i en situation, hvor man gerne vil have det billigst muligt. Men modsat den gængse opfattelse, så arbejder programmøren ikke hurtigere af forudgående forespørgsler som fx “Det tager vel ikke så lang tid?” eller andre sjove formuleringer, der har til formål at påvirke timeforbruget.

Sig som kunde ligeud, hvis en delopgave tog længere tid, end du havde regnet med. Eller spørg om forventet tidsforbrug inden en opgave påbegyndes. Det psykologiske pres kan kun ende med at påvirke slutproduktet negativt.

Prioriter

Denne burde give sig selv. Desværre er der flere, der snakker om at prioritere, end der gør det.

Hvis du har mange opgaver, som du alle sammen ønsker udviklet i første version af dit projekt, er risikoen, at der ikke kommer nok fokus på projektets mest basale funktioner.

Det kan vise sig, at kunden savner flere detaljer i de funktioner, der fik dem til at købe dit produkt i første omgang. Dette viser sig først, når du åbner sluserne til omverdenen. Du og programmøren har i mellemtiden været mere optaget af at udvikle nice-to-have-funktioner, og har derfor overset detaljerne, hvilket kan være katastrofalt. Slutkunden er helt ligeglad med dine nice-to-have-funktioner, hvis de funktioner, som de kommer til at bruge 80 % af deres tid på i dit produkt, har irritationsmomenter.

Forventningafstem kommunikationen

Er programmøren gået ud af en tangent, som du ikke havde ønsket?

Ville du gerne have testet en funktion, inden programmøren åbnede op for udviklingen af den næste bunke opgaver?

Forventningsafstem på forhånd, hvor meget information du vil have fra programmøren. Hvis du ønsker at følge udviklingen tæt, så bed om at blive opdateret, hver gang en delopgave er færdig. Du kan også bede programmøren opdatere dig på tidsforbruget for fx hver 5. eller 10. time, så du har en mulighed for at følge med.

Gør omvendt klar, hvis du ikke er interesseret i at høre den tekniske forklaring, hver gang en opgave er fuldført - så sparer du også programmørens tid.

Vedligeholdelsesomkostninger

Skal dit produkt blot teste markedet og derefter smides ud, eller skal samme kode være grundlag for dit projekt om 5 år?

Det er nemt (og billigt) at skrive kode, der virker. Det tager længere tid at skrive kode, der er nemt at udvikle videre på og vedligeholde.

Undgå altid førstnævnte. Tvinger du alligevel din programmør til at gøre det hurtigere end godt er, så vær opmærksom på, at det giver bagslag, når du vil udvikle fase 2, 3, 4 osv.

Konklusion

Som førstegangskøber af programmeringsydelser kan du få en mere realistisk pris ved at bidrage med at opkvalificere programmørens tidsestimater.

Giv programmøren den viden, der gør, at I er på bølgelængde og tænker de samme tanker omkring projektet og dets funktioner.

Det er min opfattelse, at mange konflikter omkring pris kan undgås igennem en god kommunikation og med en fælles indsats omkring programmørens vidensniveau.

Husk dog, at det kan også være, at din samarbejdspartner blot er doven. Så er det op til dig at holde ham i ørerne eller finde en anden :-)

Hvad er dine erfaringer med samarbejde bestiller og programmør imellem? Jeg tilføjer gerne flere tips til artiklen.

Fra kommentarerne:

- Mark's pointer med kompetence og brugertest er jeg helt enig i, kan være med til at holde prisen på et IT-projekt, og bør derfor overvejes.