{"id":10623,"date":"2021-06-30T14:49:47","date_gmt":"2021-06-30T12:49:47","guid":{"rendered":"https:\/\/www.software-developer-india.com\/fastpris-programvareutviklingsprosjekter-3-viktige-punkter-a-huske\/"},"modified":"2025-01-02T07:06:07","modified_gmt":"2025-01-02T05:06:07","slug":"fastpris-programvareutviklingsprosjekter-3-viktige-punkter-a-huske","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/no\/fastpris-programvareutviklingsprosjekter-3-viktige-punkter-a-huske\/","title":{"rendered":"Fastpris programvareutviklingsprosjekter: 3 viktige punkter \u00e5 huske"},"content":{"rendered":"\n

Fastpris programvareutviklingsprosjekter: 3 viktige punkter \u00e5 huske<\/h2>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n

Det er forskjellige m\u00e5ter \u00e5 gjennomf\u00f8re et programvareutviklingsprosjekt p\u00e5. Disse er hovedsakelig:<\/p>\n\n

    \n
  1. Dedikert utvikler:<\/strong> Du f\u00e5r en utvikler som bare jobber for deg og organisasjonen din. Vanligvis vil en m\u00e5nedlig pris bli avtalt mellom tjenesteleverand\u00f8ren og klienten. Utvikleren vil jobbe heltid (ca. 160 timer per m\u00e5ned) for klienten.<\/li>\n\n\n\n
  2. Menneske-og-materiale \/ Tid-og-materiale \/ smidig \/ utviklingsteam:<\/strong> Her er det avtalt et prosjekt, men utf\u00f8relsen vil bli gjort av et tverrfaglig team av prosjektledere, scrum-mestere, forretningsanalytikere, forretningsutviklere, programvare \/ webutviklere, programvaretestere, etc. Her brukes ofte en smidig metodikk, og etter hver v\u00e5r (en utviklingssyklus som varer rundt en m\u00e5ned) blir utviklingstidene justert. Det er ikke en fast pris, men et grovt budsjett som den skal utvikles etter. Det kan v\u00e6re en grov figur, men det kan ogs\u00e5 v\u00e6re et mangfold av det budsjett tallet. I store organisasjoner foretrekkes vanligvis denne tiln\u00e6rmingen.<\/li>\n\n\n\n
  3. Fast pris:<\/strong> Dette brukes vanligvis i mindre prosjekter, der prisen OG kravene er faste. Denne artikkelen handler om denne typen prosjekter, og hva som m\u00e5 tas i betraktning n\u00e5r man gjennomf\u00f8rer et slikt fastprisprosjekt.<\/li>\n<\/ol>\n\n

    Introduksjon<\/strong><\/h3>\n\n

    Mange sm\u00e5 og mellomstore selskaper har et budsjett for \u00e5 gjennomg\u00e5 programvareprosjekter. Spesielt i ikke-IT-selskaper er kunnskapen om programvareprosjekter begrenset. De foretrekker \u00e5 ha en fast pris der prosjektlederen i disse selskapene lett kan kommuniseres til konsernsjefen eller ledelsen i selskapet.<\/p>\n\n

    Det ville v\u00e6re ganske t\u00f8ft \u00e5 si: \u201cDet vil ta rundt 2 til 8 m\u00e5neder \u00e5 utvikle seg, og hver time koster 100 amerikanske dollar. Det kan ogs\u00e5 v\u00e6re 14 m\u00e5neder<\/i>\u201d.<\/p>\n\n

    Hvis IT-tjenesteselskapet forteller kunden: \u201c Det tar 4 m\u00e5neder og et budsjett p\u00e5 30 000 amerikanske dollar<\/i> \u201d, Kan klientens team ta en beslutning om det.<\/p>\n\n

    Det store problemet med det er -> Slik fungerer ikke et programvareprosjekt. F\u00f8lgende er \u00e5rsakene:<\/p>\n\n

      \n
    1. Kravene endres i l\u00f8pet av prosjektet:<\/strong> Ingen vet, ikke engang klienten, hva alt trenger \u00e5 v\u00e6re i programvaren \/ nettl\u00f8sningen for at den skal lykkes. Vanligvis, bare etter noen f\u00e5 uker, blir den f\u00f8rste versjonen eller de f\u00f8rste nettbrukergrensesnittene synlige. Det er vanligvis n\u00e5r klienten finner ut \u201cBeklager, det er denne funksjonaliteten, som er av st\u00f8rste betydning. Uten denne funksjonaliteten vil ikke prosjektet lykkes<\/i>\u201d. Men prosjektkostnadene og prosjektgjennomf\u00f8ringen har allerede blitt \u201cfikset\u201d fra begge sider, klienten og IT-tjenesteselskapet. Dette kan v\u00e6re en showstopper.<\/li>\n\n\n\n
    2. Ingen vet n\u00f8yaktig hvor lang tid det tar \u00e5 utvikle en funksjonalitet:<\/strong> Selv om en programvareutvikler kan gi en omtrentlig figur p\u00e5 hvor lang tid det tar \u00e5 utvikle en funksjonalitet. Han eller hun vet ikke det n\u00f8yaktig. Dette gjelder selv den mest erfarne utvikleren. Derfor: Jo st\u00f8rre prosjekt, jo h\u00f8yere er risikoen for at estimatet er feil. Likevel, med en st\u00f8rre buffer i prosjektestimatet, pr\u00f8ver programvareutviklingsselskapet p\u00e5 en eller annen m\u00e5te \u00e5 redusere denne risikoen.<\/li>\n<\/ol>\n\n

      Dette betyr at IT-tjenesteleverand\u00f8ren allerede har risikoen for ikke \u00e5 vite om estimatet fra utvikleren var riktig, og i tillegg kan klienten be om endringer i prosjektet.<\/p>\n\n

      Dette er ogs\u00e5 grunnen til at en stor prosentandel (rundt 40 til 60 prosent) av alle IT-prosjekter mislykkes, if\u00f8lge den mye siterte Chaos Report.<\/p>\n\n

      For i et fastprisprosjekt vil ingen gi seg. Kunden \u00f8nsker ikke \u00e5 betale en amerikansk dollar mer «Fordi det ble avtalt en fast pris», og IT-tjenesteleverand\u00f8ren vil bare insistere p\u00e5 \u00e5 bygge det som ble avtalt «Fordi kravene ble l\u00f8st i begynnelsen av prosjektet».<\/p>\n\n

      Her noen poeng \u00e5 huske \u00e5 f\u00e5 faste prisprosjekter til \u00e5 fungere<\/h3>\n\n

      1) Kravene er faste (og etter at disse kravene er fullf\u00f8rt, blir nye funksjoner lagt til)<\/strong><\/h3>\n\n

      Programvareutvikling trenger ikke \u00e5 stoppe n\u00e5r f\u00f8rst de opprinnelig avtalte funksjonene er utviklet. N\u00e5r det f\u00f8rste prosjektet er ferdig, kan neste trinn diskuteres og utf\u00f8res.<\/p>\n\n

      Tips 1: Kunden m\u00e5 gj\u00f8re f\u00f8lgende:<\/strong> Motst\u00e5 trangen til \u00e5 stille nye krav til det l\u00f8pende prosjektet. Selv om du har en sterk f\u00f8lelse av at prosjektet ikke vil v\u00e6re verdt for kundene dine.<\/strong><\/p>\n\n

      Det vil v\u00e6re t\u00f8ft nok til \u00e5 f\u00e5 de opprinnelige kravene til \u00e5 fungere. Ikke legg til det.<\/p>\n\n

      2) Tilgjengeligheten til klienten i utviklingsperioden<\/strong><\/h3>\n\n

      I et fastprisprosjekt vil IT-serviceselskapet tildele (i mindre prosjekter) en til tre utviklere, en teamleder, en prosjektleder og designer.<\/p>\n\n

      N\u00e5r prosjektet starter, vil ting g\u00e5 fort, og tid skal ikke kastes bort.<\/p>\n\n

      Spesielt viktig: Hvis IT-teamet har sp\u00f8rsm\u00e5l om en oppgave eller trenger tilbakemelding, b\u00f8r det gj\u00f8res tilgjengelig av klienten s\u00e5 snart som mulig. Det verste som kan skje er hvis utviklingsteamet m\u00e5 vente i to dager p\u00e5 tilbakemelding fra klienten og sitte inaktiv p\u00e5 den tiden.<\/p>\n\n

      Hvis utviklingsteamet sitter inaktiv, blir den tiden vanligvis trukket fra det faste tidsbudsjettet, og teamet pr\u00f8ver \u00e5 fullf\u00f8re oppgavene i gjenv\u00e6rende tid. Noe som vanligvis ikke er en god id\u00e9, men kanskje den eneste veien videre.<\/p>\n\n

      Derfor, for \u00e5 dra nytte av utviklingsteamet og deres tid, m\u00e5 klienten v\u00e6re lett tilgjengelig for sp\u00f8rsm\u00e5l fra IT-tjenesteleverand\u00f8ren.<\/p>\n\n

      Tips 2: Den beste l\u00f8sningen for dette vil v\u00e6re:<\/strong> Kunden tilbyr et dedikert kontaktpunkt, som er tilgjengelig i l\u00f8pet av utviklingstiden, gjennom hele utviklingsperioden. For eksempel vil John Smith fra klienten v\u00e6re tilgjengelig fra 01. Juli til 30. August. P\u00e5 denne tiden vil John Smith v\u00e6re tilgjengelig via Skype eller Slack Chat og kan svare p\u00e5 sp\u00f8rsm\u00e5lene fra utviklingsteamet.<\/p>\n

      \n
      \"\"<\/a><\/figure>\n<\/div>\n

      3) Gi innhold i tide<\/strong><\/h3>\n\n

      I noen tilfeller kreves det at klienten leverer tekster, videoer, bilder og andre typer innhold eller materiale.<\/p>\n\n

      Dette forh\u00e5ndsavtalte innholdet b\u00f8r leveres i tide.<\/p>\n\n

      I noen tilfeller har utviklingsselskapet muligheten for forel\u00f8pig \u00e5 bruke dummytekster eller dummyinnhold.<\/p>\n\n

      Men for riktig produksjon, er innholdet n\u00f8dvendig i noen tilfeller.<\/p>\n\n

      Tips 3: S\u00f8rg for \u00e5 ha innholdet (som tekster eller bilder) klart n\u00e5r utviklingsteamet ber om det.<\/strong><\/p>\n\n

      Merk: Det kan ogs\u00e5 v\u00e6re relatert til \u00e5 gi godkjenning, \u00e5 g\u00e5 videre med en oppgave eller med et prosjektdokument som m\u00e5 signeres.<\/p>\n\n

      4) Unng\u00e5: «Men dette var en del av kravet» Argumenter (ytterligere viktig tips)<\/strong><\/h3>\n\n

      I virkeligheten kan kravene aldri forst\u00e5s eller skrives helt ut ved prosjektstart.<\/p>\n\n

      Programvareutviklingsteamet jobber vanligvis med noen eksempler p\u00e5 nettadresser som sendes av klientene, ett eller to online m\u00f8ter og noe skriftlig materiale som e-post eller PDF-filer.<\/p>\n\n

      Det er vanligvis en generell forst\u00e5else av hovedfunksjonalitetene, men ikke det 100 prosent klare bildet.<\/p>\n\n

      Dette kan brukes av begge, utviklingsselskapet til \u00e5 si \u201c Men dette var ikke en del av kravet, dette koster ekstra<\/i> \u201dEller klienten \u00e5 si\u201c Men dette var en del av det opprinnelige kravet, vi vil absolutt ha dette gratis<\/i> \u201d.<\/p>\n\n

      Tips 4: Det m\u00e5 v\u00e6re generell rettferdighet p\u00e5 begge sider.<\/strong> Verdien for pengene skal v\u00e6re der. Men p\u00e5 den andre siden skal det ikke v\u00e6re s\u00e5 uoppn\u00e5elig med en oppgave, slik at utviklingsselskapet ikke har noe overskudd i det hele tatt fra prosjektene.<\/p>\n\n

      Merk: Generelt b\u00f8r klienten (i tilfelle han ikke er IT-ekspert) stole p\u00e5 utviklingsprosedyren som IT-selskapet foresl\u00e5r.<\/p>\n\n

      Konklusjon<\/strong><\/h3>\n\n

      Den bedre m\u00e5ten \u00e5 g\u00e5 p\u00e5 programvareprosjekter er med den dedikerte utvikleren eller dedikerte utvikleren \/ Agile tiln\u00e6rmingen. Men dette er ikke mulig for noen selskaper p\u00e5 grunn av begrensninger i budsjettet.<\/p>\n\n

      Derfor tilbyr mange IT-tjenesteselskaper muligheten for faste priser.<\/p>\n\n

      For klienten er det viktig \u00e5 merke seg at n\u00e5r prisen er fast, s\u00e5 er ogs\u00e5 kravene faste. Ofte forveksles fast pris med en \u201cAll-You-Can-Eat-Buffet\u201d, hvor du betaler en gang og kan spise (utvikle) s\u00e5 mye du vil. Tvert imot er det mer som et \u201cA-La-Carte\u201d -menyalternativ, hvor du bestiller biffen til 5 amerikanske dollar, hvis du vil ha pommes frites med det, m\u00e5 du betale 2 amerikanske dollar ekstra.<\/p>\n\n

      Men ogs\u00e5: Programvareutvikling og tilberedning av m\u00e5ltider er forskjellige. For n\u00e5r du lager en biff, er innspillene ganske klare. I programvareutvikling er dette ikke alltid tilfelle.<\/p>\n\n

      Tipsene i denne artikkelen vil bidra til \u00e5 gj\u00f8re prosjekter med fast pris til en suksess.<\/p>\n\n

      Interessante artikler:<\/p>\n\n

      Hvordan f\u00e5 fastprisprosjekter til \u00e5 fungere for deg<\/a><\/p>\n\n

      Hvordan gjennomf\u00f8res et fastprisprosjekt?<\/a><\/p>\n\n

      Bilder: Canva<\/p>\n\n

      \n
      \n
      \"\"<\/figure>\n<\/div>\n

      Forfatteren: Sascha Thattil jobber p\u00e5 Software-Developer-India.com som er en del av YUHIRO Group. YUHIRO er en tysk-indisk bedrift som tilbyr programmerere til IT-selskaper, byr\u00e5er og IT-avdelinger.<\/p>\n