Sådan vurderes en estimeret softwareomkostning (for ikke-tekniske personer)

Det er ret svært at evaluere et softwareprojekt og sætte en pris på det.

I artiklen nogle udfordringer, og hvordan man går frem til vurdering af softwareomkostningsestimater.

Introduktion

Ifølge kaosrapporten, som ofte citeres, fejler omkring 30 procent af alle softwareprojekter. Det betyder, at enten projektets varighed bliver for lang, eller at budgettet ikke holdes.

Her er nogle udfordringer i softwareprojekter:

1) Vanskeligt at kontrollere de nøjagtige krav

Hvis du vil bygge et specialbygget stort hus, kan en pris kun fastsættes, hvis hver del af arbejdet vurderes korrekt. Op til den sidste skrue, som skal bruges.

Arkitekten opretter en plan med en nøjagtig plan, hvor hele huset replikeres enten på papir eller ofte i dag som 3D-model. Og i disse programmer kan det beregnes, hvor mange skruer osv. Der skal bruges til at bygge huset.

Med disse oplysninger er det muligt at give et nøjagtigt skøn over husbygningsprojektet.

Men vi ved også: I meget store byggeprojekter er prisestimaterne normalt ikke korrekte. Og hvad der skulle koste 500 millioner euro, koster 5 milliarder euro eller mere. Berlin lufthavn, Elbphilharmonie i Hamborg og hovedbanegården i Stuttgart, Tyskland er tre eksempler, i de fleste tilfælde var omkostningerne reduceret med en milliard Euro eller mere.

For hovedbanegården i Stuttgart var gebyret for arkitekten omkring 36 millioner euro. Selvom arkitekten fik betalt et så stort beløb. Anslået projektomkostningsberegning var omkring 1 mia. Euro.

Lignende udfordringer kan ses i softwareprojekter.

Især når ikke-tekniske personer er involveret i at videregive kravene til softwaren eller webprojektet. Normalt vil projektbeskrivelserne kun få linier inde i en e-mail. Eller et telefonopkald, hvor den nødvendige løsning er beskrevet.

Nogle eksempler på websteder gives som reference. Ikke sjældent er disse eksempelwebsteder bygget i mange år og koster hundreder af tusind euro, undertiden millioner.

Men budgettet for webapplikationen eller softwareløsningen vil være omkring 4’000 til 40’000 Euro, og det skal bygges inden for 2 måneder, maksimalt 3 måneder. (Det er normalt ønsket fra den ikke-it-person, der spørger om prisen).

Virkeligheden er denne: Uden et detaljeret forespørgselsdokument fra klienten, der vil være omkring 10 til 50 sider og et detaljeret forslag oprettet af it-firmaet, baseret på det forespurgte dokument, kan en pris for projektet ikke bestemmes.

Og selvom der er et nøjagtigt forslagsdokument. Normalt ændres kravene under projektet, hvilket gør denne øvelse af oprettelse af forslag, som kan tage uger, til en unødvendig opgave.

2) Ændring af krav under projektet

Der er næsten intet it-projekt, hvor det oprindeligt citerede softwareprojekt forbliver det samme under projektet.

Årsagen er, at kun når softwaren begynder at få form, klienten genkender, at der mangler nogle vigtige ting, uden hvilke projektet ikke kan blive en succes, og softwaren ikke hjælper forretningsprocesserne.

Men hvad hvis der er aftalt en fast pris? Hvordan kan it-tjenesteudbyderen tillade ændringer under projektet. Dette er næsten umuligt, for da tjener it-tjenesteudbyderen slet ikke noget.

På den anden side vil klienten insistere på den faste pris og siger, at ”For denne lille ændring er der ikke behov for at ændre budgettet. Denne lille ændringsanmodning kan du indsætte i det oprindelige tilbud ”.

Og her er normalt hvor dilemmaet starter. Denne diskussion om ændringsanmodninger vil fortsætte og fortsætte. Og projektet sidder fast.

Således er det altid bedre at holde projektbudgettet flydende. Hvor kunden betaler så meget, som softwareudviklingen kræver. -> Selvfølgelig kan dette virke “som en himmel for softwarefirmaet” for klienten, fordi han / hun vil tro, at de vil gøre flere timer end nødvendigt.

Men sammenlign det med en restaurant. Hvis du bestiller en ekstra coca cola eller en ekstra bøf, skal du også betale for den ekstra ting. Hvorfor skulle det være anderledes i softwareudvikling? Især inden for it, hvor timepriser normalt er meget højere.

3) Vanskeligheder med at forstå kompleksiteten af softwareudvikling af ikke-it-personen

Det er normalt meget vanskeligt at forstå for en ikke-it-person at forstå kompleksiteten af softwareudvikling.

“Min ven byggede dette ene websted på en dag, og det har mange funktioner. Hvorfor har du som ekspert brug for mere end 6 måneder til at udvikle disse funktioner?”

Mest sandsynligt brugte venen noget Content Management System som WordPress eller Drupal og brugte nogle standard plugins, som normalt bringer mange funktioner. Men dette er ikke brugerdefinerede softwareløsninger lavet til venen. Det er systemer og plugins, der normalt bruges af tusindtusindvis af mennesker, der har lignende krav. Disse er ikke specialfremstillede løsninger.

Men: At bygge disse plugins krævede sandsynligvis omkring 2 til 5 eller flere udviklere på fuld tid i flere måneder eller endda år. Så selvom veninden bruger tilsyneladende enkle løsninger. De er skabt i en meget kompleks softwareudvikling.

Så hvis klienten har nogle krav, der kan opfyldes af disse plugins og “færdige løsninger”. Så er det bedre at bruge dem. Men i de fleste tilfælde er disse “færdige” softwaresystemer ikke, hvad klienten kræver.

Det bedste eksempel er Googles søgemaskine. I frontenden (hvad brugeren ser) er der kun en søgefelt og to knapper. Så en ikke-it-person ville sige ”det kunne kun tage en uge at udvikle dette. Der er kun en søgefelt og to knapper ”. I virkeligheden er der mange “skjulte” backend-funktioner, som er udviklet af tusinder og tusinder af udviklere, og det gennem mange år.

Afhængigt af klientprojektets kompleksitet, skalerbarhed osv. Kan softwareudviklingen tage mere tid end forventet.

Mulige løsninger

Der er nogle løsninger, hvordan en ikke-it-person kunne henvende sig til forespørgslen til it-tjenesteudbyderen.

1) Involver en softwareudvikler

Ideelt set ville der være en intern softwareudvikler eller IT-ekspert, der kunne krydstjekke estimatet fra it-serviceselskabet.

Normalt vil den softwareudvikler råde til at holde projektets omfang fleksibelt, så ændringer kan imødekommes.

Hvis softwarevirksomhedens skøn er plausibel, giver softwareudvikleren grønt lys.

På den måde, som en intern medarbejder vurderer projektet, vil ikke-it-personen også være overbevist om indsatsen for udviklingen.

2) Brug af dedikeret udvikler

En dedikeret udvikler er en udvikler, der leveres til klienten på fuld tid.

Fordelen ved dette er, at udvikleren arbejder tæt sammen med klienten og også med klientens team. Dette øger gennemsigtigheden. Og klienten eller teamet kan stille spørgsmål og få svar i realtid.

Denne model fungerer på forskellige måder:

  • På side: IT-serviceselskabet beder udvikleren om at gå til klientens placering og arbejde hos klienten.
  • IT-outsourcing: Et team af udviklere arbejder i IT-servicevirksomhedens lokaler.
  • Nearshore Outsourcing: Den dedikerede udvikler arbejder hos en it-tjenesteudbyder i et nærliggende land. For Sverige ville det være Polen eller Ukraine. For Japan ville det være Malaysia eller Kina.
  • Offshore outsourcing: Her sidder udvikleren i et softwarevirksomheds lokaler i et langt væk land. Eksempler er Indien, Pakistan osv. Men ordene Nearshore eller Offshore kan bruges om hverandre. Det afhænger af, hvor klienten er placeret. Hvis klienten er i Japan, er Indien en Nearshore Outsourcing-destination.

Klienten kan bruge den dedikerede udvikler, så længe han / hun ønsker det. Indtil projektet er færdigt. Hvis projektet tager for lang tid. Klienten og teamet kan diskutere med udvikleren, hvilken vej de skal gå for at nå målene hurtigere.

3) Undgå stive faste prisprojekter

En fast pris er normalt ikke en god idé. Kun hvis projektet er meget lille. Ligesom et websted på en side eller lignende.

Faste priser kan føre til et falsk håb om, at alt vil blive gjort inden for den pris. (Selv alt-du-kan-spise fungerer ikke på den måde. Du kan spise så meget som du vil, men kun til et måltid. Ikke i flere dage i træk. Men det er, hvad kunderne forventer, når de får en fast pris i softwareudvikling)

Bedre at gå efter en smidig prisfastsættelse, hvor softwareudbyderens tid og kræfter aflønnes alt efter, hvor meget indsats der går i udviklingen.

Eller brug en dedikeret udvikler eller et team af dedikerede softwareprofessionelle til at arbejde på dit projekt.

Konklusion

Mange softwareprojekter fejler bare, fordi der mangler forståelse, hvad brugerdefineret softwareudvikling indebærer. Tilsyneladende nemme projekter kan tage uger og måneder.

Derfor skal der foretages en vis vurdering af klienten. Hvad er omkostningsområdet for softwareudvikling, og hvad er forretningsværdien skabt af det. Skabes forretningsværdien meget højere end det budget, der er nødvendigt til softwareudviklingen? Godt, så er det godt at gå. Start projektet.

Hvis den oprettede forretningsværdi og omkostningerne ikke stemmer overens. Så måske er det bedre at fortsætte med at bruge manuelle løsninger, Excel-filer eller standardsoftware eller webløsninger, som kan abonneres, ved at betale et lavt månedligt gebyr.

Ser frem til en interessant diskussion.

Interessante links:
Hvorfor estimater måske ikke er en god idé
Myten om softwarestimater forklaret


Forfatteren: Sascha Thattil arbejder på Software-Developer-India.com, som er en del af YUHIRO Group. YUHIRO er en tysk-indisk virksomhed, der leverer programmører til IT-virksomheder, agenturer og IT-afdelinger.

Skriv et svar

This site uses Akismet to reduce spam. Learn how your comment data is processed.