Sådan gennemfører du et succesfuldt softwareudviklingsprojekt
Hvorfor så mange softwareudviklingsprojekter løber af sporet
De fleste softwareudviklingsprojekter mislykkes ikke, fordi udviklerne var dårlige til at kode. De mislykkes, fordi kravene var uklare fra starten, fordi kommunikationen brød sammen undervejs, eller fordi ingen tog ejerskab over de beslutninger, der skulle træffes. Det er et mønster, der går igen på tværs af brancher og virksomhedsstørrelser.
Denne guide er til dig, der enten er ved at sætte gang i et nyt softwareprojekt eller overvejer at hyre en ekstern partner. Du får konkrete kriterier at vurdere ud fra, spørgsmål du bør stille, og de faldgruber du skal undgå.
Start med at definere kravene, præcist
Det lyder indlysende, men uklar kravspecifikation er den hyppigste årsag til forsinkelser og overskredne budgetter. Før du taler med en eneste udvikler, bør du kunne svare på disse spørgsmål:
- Hvad skal systemet gøre, konkret og målbart?
- Hvem er slutbrugerne, og hvad er deres tekniske niveau?
- Hvilke eksisterende systemer skal det nye software integrere med?
- Hvad er de absolutte minimumskrav (MVP), og hvad er nice-to-have?
- Hvad er tidsrammen, og er den fleksibel?
Et godt udgangspunkt er at skelne mellem funktionelle krav (hvad systemet skal gøre) og ikke-funktionelle krav (hastighed, sikkerhed, skalerbarhed). Begge dele skal dokumenteres, inden arbejdet begynder.
Vælg den rette udviklingsmetode
Der er ikke én rigtig metode, det afhænger af projektet. Men du bør have en bevidst holdning til det fra starten.
Vandfaldsmodellen
Her planlægges hele projektet på forhånd: krav, design, udvikling, test og lancering følger hinanden i faste faser. Det passer godt til projekter med meget stabile krav og klare deadlines, fx regulerede industrier eller interne systemer med veldefinerede behov.
Agile tilgang
Agile arbejder i korte iterationer kaldet sprints, typisk af en til to ugers varighed. Kravene kan justeres løbende, og du som kunde involveres aktivt i processen. Det passer godt til de fleste kommercielle produkter, særligt når kravene ikke er hugget i sten fra dag ét. Du kan læse mere om, hvordan du bruger Agile metoden i softwareudvikling, hvis du vil dykke dybere ned i tilgangen.
Uanset hvilken metode du vælger, er det afgørende, at alle parter er enige om den, og forstår hvad den kræver af dem.
Sådan vælger du den rette partner eller team
Hvis du ikke selv har et internt udviklingshold, skal du vælge en ekstern partner. Det valg er mindst ligeså vigtigt som selve teknologien. Her er de konkrete ting du skal kigge efter:
Dokumenteret erfaring inden for din type projekt
En partner der har bygget mange e-handelsløsninger er ikke nødvendigvis det rette valg, hvis du har brug for en kompleks backend til databehandling. Bed om referencer fra projekter der ligner dit, og kontakt dem faktisk.
Klar kommunikationsstruktur
Spørg: Hvem er min faste kontaktperson? Hvordan rapporteres fremskridt? Hvad sker der, hvis I opdager at kravene skal justeres? En partner der ikke kan svare klart på det, vil give dig problemer undervejs.
Transparens om teknologivalg
Du bør forstå, på et overordnet niveau, hvilke teknologier der vælges og hvorfor. Undgå partnere der ikke kan eller vil forklare deres valg i forståeligt sprog. Det handler ikke om, at du skal lære at kode, men om at du ikke må ende i en situation, hvor kun én udbyder kan vedligeholde din løsning. Valget af fx backend-teknologi har stor betydning for fremtidig vedligeholdelse og skalerbarhed.
Fast pris eller løbende fakturering?
Begge modeller har fordele. Fast pris giver forudsigelighed, men kræver meget præcise krav på forhånd. Løbende fakturering giver fleksibilitet, men kræver tillid og god opfølgning. Uanset model: sørg for at der altid er et klart estimat og en mekanisme for at godkende ekstraomkostninger.
Planlæg for test, ikke som eftertanke
Test er det element, der oftest trimmes ned, når et projekt er bagud. Det er en af de dyreste beslutninger, man kan træffe. Fejl der opdages under udvikling koster en brøkdel af det, de koster at rette efter lancering.
Du bør sikre dig, at der er planlagt tid og ressourcer til:
- Enhedstest under udviklingen
- Integrationstest, særligt hvis systemet skal tale med andre platforme
- Brugertest med rigtige slutbrugere, inden den endelige lancering
- Sikkerhedstest, hvis løsningen håndterer følsomme data
Spørg din partner direkte: Hvad er jeres teststrategi? Hvem har ansvaret for at rette fejl der opdages efter lancering, og til hvilken pris?
Hosting og infrastruktur er ikke en detalje
Mange projekter fokuserer udelukkende på selve applikationen og overser, at den infrastruktur den kører på, har direkte indflydelse på sikkerhed, ydeevne og driftsstabilitet. Det er særligt relevant, hvis din løsning forventes at skalere eller håndterer personfølsomme oplysninger. Overvejelserne om hosting til webudvikling er værd at sætte sig ind i tidligt i processen.
Hosting bør diskuteres med din partner som en del af arkitekturen, ikke tilføjes som et praktisk spørgsmål til sidst.
Overdragelse og vedligeholdelse efter lancering
Et projekt er ikke færdigt, når det lanceres. Det er her, mange opdager, at de har undladt at aftale noget afgørende: hvem ejer koden, hvem kan vedligeholde den, og hvad koster det at tilføje nye funktioner?
Sørg for at aftalen indeholder:
- Fuld adgang til kildekoden og dokumentation
- Tydelig ejerskabsklausul, koden bør juridisk tilhøre dig som kunde
- En aftalt supportperiode efter lancering
- Klare betingelser for videreudvikling og vedligeholdelse
Overvej også, om din interne organisation er klar til at modtage og driftsafvikle løsningen. Teknisk overdragelse kræver dokumentation og oplæring, ikke bare en adgangskode.
De spørgsmål du altid bør stille en potentiel partner
Inden du underskriver en kontrakt, bør du have klare svar på følgende:
- Kan I vise eksempler på lignende projekter I har gennemført?
- Hvad sker der, hvis vi undervejs ændrer kravene?
- Hvem ejer koden, og hvad er jeres politik om open source-komponenter?
- Hvordan håndterer I sikkerhed og databeskyttelse?
- Hvad dækker prisen præcist, og hvad faktureres separat?
- Hvad er jeres erfaringer med projekter der er løbet af sporet, og hvad lærte I?
Det sidste spørgsmål er undervurderet. En partner der kan tale ærligt om fejlede projekter og hvad de lærte af dem, er langt mere troværdig end én der kun fortæller om succeser.
Kort opsummering: Hvad adskiller de gode projekter fra de dårlige
De softwareudviklingsprojekter der lykkes, har typisk disse ting til fælles: præcise krav fra starten, en bevidst valgt metode, løbende og ærlig kommunikation, systematisk test, og en klar aftale om hvad der sker efter lancering. Det er ikke rocket science, men det kræver disciplin og en partner der tager det seriøst.
Har du et projekt på tegnebrættet og vil have en uforpligtende snak om mulighederne, er du velkommen til at tage kontakt til Sahari, der arbejder med netop denne type opgaver til virksomheder i Danmark.