Hvordan vurdere en estimering av programvarekostnad (for ikke-tekniske personer)

Hvordan vurdere en estimering av programvarekostnad (for ikke-tekniske personer)

Det er ganske vanskelig å evaluere et programvareprosjekt og sette en prislapp på det.

I artikkelen noen utfordringer og hvordan du går frem for å vurdere estimater av programvarekostnader.

Introduksjon

I følge kaosrapporten, som ofte siteres, mislykkes rundt 30 prosent av alle programvareprosjekter. Det betyr at enten prosjektvarigheten blir for lang eller at budsjettet ikke blir holdt.

Her noen utfordringer i programvareprosjekter:

1) Vanskelig å sjekke de nøyaktige kravene

Hvis du vil bygge et spesialbygget stort hus, kan en pris bare fastsettes hvis alle deler av arbeidet er riktig vurdert. Opp til den siste skruen, som skal brukes.

Arkitekten vil lage en plan med en nøyaktig plan, der hele huset replikeres enten på papir eller ofte i dag som 3D-modell. Og i disse programmene kan det beregnes hvor mange skruer osv. Som skal til for å bygge huset.

Med denne informasjonen er det mulig å gi et nøyaktig estimat for husbyggingsprosjektet.

Men vi vet også: I veldig store byggeprosjekter er prisantydningene vanligvis ikke riktige. Og det som skulle koste 500 millioner euro, vil til slutt koste 5 milliarder euro eller mer. Berlin lufthavn, Elbphilharmonie i Hamburg og sentralstasjonen i Stuttgart, Tyskland er tre eksempler, i de fleste tilfeller ble kostnaden redusert med en milliard euro eller mer.

For sentralstasjonen i Stuttgart var gebyret for arkitekten rundt 36 millioner euro. Selv om arkitekten fikk betalt et så høyt beløp. Prosjektets kostnadsberegning ble redusert med rundt 1 milliard euro.

Lignende utfordringer kan sees i programvareprosjekter.

Spesielt når ikke-tekniske personer er involvert i å videreformidle kravene til programvaren eller webprosjektet. Vanligvis vil prosjektbeskrivelsene bare ha noen få linjer i en e-post. Eller en telefonsamtale der den nødvendige løsningen er beskrevet.

Noen eksempler på nettsteder vil bli gitt som referanse. Ikke sjelden har disse eksempler på nettsteder blitt bygget over mange år og kostet hundretusenvis av euro, noen ganger millioner.

Men budsjettet for webapplikasjonen eller programvareløsningen vil være rundt 4’000 til 40’000 Euro, og det skal bygges innen 2 måneder, maksimalt 3 måneder. (Dette er ønsket vanligvis av ikke-IT-personen som spør om prisen).

Virkeligheten er denne: Uten et detaljert forespørselsdokument fra klienten, som vil være rundt 10 til 50 sider og et detaljert forslag opprettet av IT-selskapet, basert på det etterspurte dokumentet, kan en pris for prosjektet ikke fastsettes.

Og selv om det er et eksakt forslagsdokument. Vanligvis endres kravene i løpet av prosjektet, noe som gjør denne øvelsen med å lage forslag, som kan ta uker, en unødvendig oppgave.

2) Endring av krav underveis i prosjektet

Det er nesten ikke noe IT-prosjekt, der det opprinnelig siterte programvareprosjektet forblir det samme under prosjektet.

Årsaken er at kun når programvaren begynner å få form, klienten innser at det mangler noen viktige ting, uten som prosjektet ikke kan lykkes, og programvaren ikke vil hjelpe forretningsprosessene.

Men hva om det er avtalt en fast pris? Hvordan kan IT-tjenesteleverandøren tillate endringer under prosjektet. Dette er nesten umulig, for da vil IT-tjenesteleverandøren ikke tjene noe overhodet.

På den andre siden vil klienten insistere på den faste prisen og si at “For denne lille endringen er det ikke nødvendig å endre budsjettet. Denne forespørselen om liten endring kan du legge inn det første tilbudet ”.

Og her er vanligvis hvor dilemmaet starter. Denne diskusjonen om endringsforespørsler vil fortsette og fortsette. Og prosjektet vil bli sittende fast.

Dermed er det alltid bedre å holde prosjektbudsjettet flytende. Der klienten betaler så mye, som programvareutviklingen krever. -> Selvfølgelig kan dette virke «som en himmel for programvareselskapet» for klienten, fordi han / hun vil tro at de vil gjøre flere timer enn nødvendig.

Men sammenlign det med en restaurant. Hvis du bestiller en ekstra coca cola eller en ekstra biff, må du også betale for den ekstra tingen. Hvorfor skal det være annerledes i programvareutvikling? Spesielt innen IT der timepriser vanligvis er mye høyere.

3) Vanskeligheter med å forstå kompleksiteten i programvareutvikling av ikke-IT-personen

Det er vanligvis veldig vanskelig å forstå for en ikke-IT-person å forstå kompleksiteten i programvareutvikling.

«Min venn bygget dette nettstedet på en dag, og det har mange funksjoner. Hvorfor trenger du som ekspert mer enn 6 måneder for å utvikle disse funksjonene?»

Mest sannsynlig brukte vennen noen Content Management System som WordPress eller Drupal og brukte noen standard plugins, som vanligvis gir mange funksjoner. Men dette er ikke tilpassede programvareløsninger laget for vennen. Dette er systemer og plugins som brukes av vanligvis tusen og hundre tusen mennesker, som har lignende krav. Dette er ikke skreddersydde løsninger.

Men: Å bygge disse pluginene krevde sannsynligvis rundt 2 til 5 eller flere utviklere på heltid i flere måneder eller til og med år. Så selv om vennen bruker tilsynelatende enkle løsninger. De er opprettet i en veldig kompleks programvareutvikling.

Så i tilfelle klienten har noen krav som kan oppfylles av disse plugins og «ferdige løsninger». Da er det bedre å bruke dem. Men i de fleste tilfeller er ikke disse «ferdige» programvaresystemene det kunden krever.

Det beste eksemplet er Googles søkemotor. På fronten (det brukeren ser) er det bare en søkefelt og to knapper. Så en ikke-IT-person vil si «det kan bare ta en uke å utvikle dette. Det er bare en søkefelt og to knapper ”. I virkeligheten er det mange «skjulte» backend-funksjoner, som er utviklet av tusenvis og tusenvis av utviklere, og det gjennom mange år.

Avhengig av kompleksiteten, behovet for skalerbarhet etc. i klientprosjektet, kan programvareutviklingen ta mer tid enn forventet.

Mulige løsninger

Det er noen løsninger hvordan en ikke-IT-person kan nærme seg henvendelsen til IT-tjenesteleverandøren.

1) Involver en programvareutvikler

Ideelt sett ville det være en egen programvareutvikler eller IT-ekspert, som kunne kryssjekke estimatet fra IT-tjenesteselskapet.

Vanligvis vil den programvareutvikleren råde seg til å holde prosjektomfanget fleksibelt, slik at endringer kan imøtekommes.

Hvis estimeringen fra programvareselskapet er sannsynlig, vil programvareutvikleren gi grønt lys.

På den måten, som en intern ansatt vurderer prosjektet, vil ikke-IT-personen også være overbevist om innsatsen som er involvert for utviklingen.

2) Bruk av dedikert utvikler

En dedikert utvikler, er en utvikler som blir gitt til klienten på heltid.

Fordelen med dette er at utvikleren jobber tett med klienten og også med teamet til klienten. Dette øker gjennomsiktigheten. Og klienten eller teamet kan stille spørsmål og få svar i sanntid.

Denne modellen fungerer på forskjellige måter:

• På stedet: IT-serviceselskapet ber utvikleren om å gå til klientstedet og jobbe i klientens lokaler.
• IT-outsourcing: Et team av utviklere jobber i lokalene til IT-serviceselskapet.
• Nearshore Outsourcing: Den dedikerte utvikleren jobber hos en IT-tjenesteleverandør i et nærliggende land. For Sverige ville det være Polen eller Ukraina. For Japan vil det være Malaysia eller Kina.
• Offshore outsourcing: Her sitter utvikleren i lokalene til et programvareselskap i et langt borte land. Eksempler er India, Pakistan, etc. Men ordene Nearshore eller Offshore kan brukes om hverandre. Det kommer an på hvor klienten befinner seg. Hvis klienten er i Japan, er India et Nearshore Outsourcing-reisemål.

Klienten kan bruke den dedikerte utvikleren så lenge han / hun vil. Til prosjektet er ferdig. I tilfelle prosjektet tar for lang tid. Klienten og teamet kan diskutere med utvikleren hvilken vei å gå for å nå målene raskere.

3) Unngå stive faste prisprosjekter

En fast pris er vanligvis ikke en god idé. Bare hvis prosjektet er veldig lite. Som en nettside eller lignende.

Faste priser kan føre til et falskt håp om at alt vil bli gjort, innenfor den prisen. (Selv All-You-Can-Eat fungerer ikke på den måten. Du kan spise så mye du vil, men bare til ett måltid. Ikke i flere dager. Men det er hva kundene forventer når de får en fast pris i programvare utvikling)

Bedre å gå for en smidig prising, hvor programvareleverandørens tid og krefter blir godtgjort, i henhold til hvor mye krefter som går med i utviklingen.

Eller bruk en dedikert utvikler eller et team av dedikerte programvareprofesjonelle til å jobbe med prosjektet ditt.

Konklusjon

Mange programvareprosjekter mislykkes bare, fordi det er mangel på forståelse, hva tilpasset programvareutvikling innebærer. Tilsynelatende enkle prosjekter, kan ta uker og måneder.

Derfor må det foretas en vurdering av klienten. Hva er kostnadsområdet for programvareutvikling, og hva er forretningsverdien skapt av det. Er forretningsverdien skapt, mye høyere enn budsjettet som trengs for programvareutviklingen? Bra, da er det bra å gå. Start prosjektet.

Hvis forretningsverdien som er opprettet og kostnadene ikke samsvarer. Da er det kanskje bedre å fortsette å bruke manuelle løsninger, Excel-filer eller standard programvare eller webløsninger, som kan abonneres, ved å betale en lav månedlig avgift.

Ser frem til en interessant diskusjon.

Interessante lenker:
Hvorfor estimater ikke kan være en god idé
Myten om estimering av programvare forklart

Forfatteren: Sascha Thattil jobber på Software-Developer-India.com som er en del av YUHIRO Group. YUHIRO er en tysk-indisk bedrift som tilbyr programmerere til IT-selskaper, byråer og IT-avdelinger.