{"id":10670,"date":"2021-06-30T14:51:22","date_gmt":"2021-06-30T12:51:22","guid":{"rendered":"https:\/\/www.software-developer-india.com\/fastpris-softwareudviklingsprojekter-3-vigtige-punkter-at-huske\/"},"modified":"2025-01-02T07:05:07","modified_gmt":"2025-01-02T05:05:07","slug":"fastpris-softwareudviklingsprojekter-3-vigtige-punkter-at-huske","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/da\/fastpris-softwareudviklingsprojekter-3-vigtige-punkter-at-huske\/","title":{"rendered":"Fastpris Softwareudviklingsprojekter: 3 vigtige punkter at huske"},"content":{"rendered":"\n

Fastpris Softwareudviklingsprojekter: 3 vigtige punkter at huske<\/h2>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n

Der er forskellige m\u00e5der at udf\u00f8re et softwareudviklingsprojekt p\u00e5. Disse er hovedsageligt:<\/p>\n\n

    \n
  1. Dedikeret udvikler:<\/strong> Du f\u00e5r en udvikler, der kun arbejder for dig og din organisation. Normalt aftales en m\u00e5nedlig pris mellem tjenesteudbyderen og klienten. Udvikleren vil arbejde p\u00e5 fuld tid (ca. 160 timer om m\u00e5neden) for klienten.<\/li>\n\n\n\n
  2. Menneske-og-Materiale \/ Tid-og-Materiale \/ Agil \/ Udviklingsteam:<\/strong> Her er der aftalt et projekt, men udf\u00f8relsen vil blive udf\u00f8rt af et tv\u00e6rfagligt team af projektledere, scrummasters, forretningsanalytikere, forretningsudviklere, software \/ webudviklere, softwaretestere osv. Her anvendes ofte en Agile-metode, og efter hvert for\u00e5r (en udviklingscyklus, der varer omkring en m\u00e5ned) justeres udviklingstiderne. Det er ikke en fast pris, men et groft budget, if\u00f8lge hvilket den vil blive udviklet. Det kunne v\u00e6re en grov figur, men det kunne ogs\u00e5 v\u00e6re et multiplum af dette budgettal. I store organisationer foretr\u00e6kkes denne tilgang normalt.<\/li>\n\n\n\n
  3. Fast pris:<\/strong> Dette bruges normalt i mindre projekter, hvor prisen OG kravene er faste. Denne artikel handler om denne type projekter, og hvad der skal tages i betragtning, n\u00e5r man udf\u00f8rer et s\u00e5dant fastprisprojekt.<\/li>\n<\/ol>\n\n

    Introduktion<\/strong><\/h3>\n\n

    Mange sm\u00e5 til mellemstore virksomheder har et budget til at gennemg\u00e5 softwareprojekter. Is\u00e6r i ikke-it-virksomheder er viden om softwareprojekter begr\u00e6nset. De foretr\u00e6kker at have en fast pris, hvor projektlederen inden for disse virksomheder let kan kommunikeres til administrerende direkt\u00f8r eller ledelse.<\/p>\n\n

    Det ville v\u00e6re ret sv\u00e6rt at sige: \u201dDet tager cirka 2 til 8 m\u00e5neder at udvikle sig, og hver time koster 100 amerikanske dollars. Det kan ogs\u00e5 v\u00e6re 14 m\u00e5neder<\/i>\u201d.<\/p>\n\n

    Hvis it-serviceselskabet fort\u00e6ller klienten, \u201c Det tager 4 m\u00e5neder og et budget p\u00e5 30.000 amerikanske dollars<\/i> \u201d, Kan klientens team tr\u00e6ffe en beslutning om det.<\/p>\n\n

    Det store problem med det er -> S\u00e5dan fungerer et softwareprojekt ikke. F\u00f8lgende er \u00e5rsagerne:<\/p>\n\n

      \n
    1. Krav \u00e6ndres under projektet:<\/strong> Ingen ved, ikke engang klienten, hvad alt skal v\u00e6re i softwaren \/ webl\u00f8sningen for at det skal lykkes. Normalt f\u00f8rst efter et par uger bliver den f\u00f8rste version eller de f\u00f8rste webbrugergr\u00e6nseflader synlige. Det er normalt n\u00e5r klienten finder ud af \u201cUps, der er denne funktionalitet, som er af st\u00f8rste betydning. Uden denne funktionalitet bliver projektet ikke en succes<\/i>\u201d. Men projektomkostningerne og projektudf\u00f8relsen er allerede “rettet” fra begge sider, klienten og it-serviceselskabet. Dette kan v\u00e6re en showstopper.<\/li>\n\n\n\n
    2. Ingen ved pr\u00e6cis, hvor lang tid det tager at udvikle en funktionalitet:<\/strong> Selvom en softwareudvikler kan give et omtrentligt tal p\u00e5, hvor lang tid det tager at udvikle en funktionalitet. Han eller hun ved det ikke n\u00f8jagtigt. Dette g\u00e6lder for selv den mest erfarne udvikler. Derfor: Jo st\u00f8rre projekt, jo st\u00f8rre er risikoen for, at estimatet er forkert. Stadig med en st\u00f8rre buffer i projektestimatet fors\u00f8ger softwareudviklingsfirmaet p\u00e5 en eller anden m\u00e5de at afb\u00f8de denne risiko.<\/li>\n<\/ol>\n\n

      Dette betyder, at it-tjenesteudbyderen allerede har en risiko for ikke at vide, om udviklernes sk\u00f8n var korrekt, og p\u00e5 toppen af det kan klienten muligvis bede om \u00e6ndringer inden for projektet.<\/p>\n\n

      Dette er ogs\u00e5 grunden til, at if\u00f8lge den meget citerede Chaos-rapport mislykkes en stor procentdel (omkring 40 til 60 procent) af alle it-projekter.<\/p>\n\n

      For i et fastprisprojekt \u00f8nsker ingen at give efter. Klienten \u00f8nsker ikke at betale en US-dollar mere \u201dFordi der blev aftalt en fast pris\u201d, og IT-tjenesteudbyderen vil kun insistere p\u00e5 at bygge det, der blev aftalt \u201cFordi kravene blev l\u00f8st i starten af projektet\u201d.<\/p>\n\n

      Her er nogle punkter, du skal huske at f\u00e5 faste prisprojekter til at fungere<\/h3>\n\n

      1) Kravene er faste (og f\u00f8rst efter afslutningen af disse krav tilf\u00f8jes nye funktioner)<\/strong><\/h3>\n\n

      Softwareudvikling beh\u00f8ver ikke at stoppe, n\u00e5r f\u00f8rst de oprindeligt aftalte funktionaliteter er blevet udviklet. N\u00e5r det oprindelige projekt er afsluttet, kan det n\u00e6ste trin diskuteres og udf\u00f8res.<\/p>\n\n

      Tip 1: Kunden skal g\u00f8re f\u00f8lgende:<\/strong> Modst\u00e5 trangen til at stille nye krav i det igangv\u00e6rende projekt. Selvom du har en st\u00e6rk fornemmelse af, at projektet ikke vil v\u00e6re v\u00e6rd for dine kunder.<\/strong><\/p>\n\n

      Det bliver sv\u00e6rt nok til at f\u00e5 de oprindelige krav til at fungere. Tilf\u00f8j ikke til det.<\/p>\n\n

      2) Kundens tilg\u00e6ngelighed i udviklingsperioden<\/strong><\/h3>\n\n

      I et fastprisprojekt vil IT-serviceselskabet allokere (i mindre projekter) en til tre udviklere, en teamleder, en projektleder og designer.<\/p>\n\n

      N\u00e5r projektet starter, g\u00e5r tingene hurtigt, og tiden b\u00f8r ikke spildes.<\/p>\n\n

      Is\u00e6r vigtigt: Hvis it-teamet har sp\u00f8rgsm\u00e5l om en opgave eller har brug for feedback, skal det g\u00f8res tilg\u00e6ngeligt af klienten s\u00e5 hurtigt som muligt. Den v\u00e6rste ting, der kan ske, er, hvis udviklingsteamet skal vente i 2 dage p\u00e5 klientfeedback og sidder inaktiv i den tid.<\/p>\n\n

      Hvis udviklingsteamet sidder inaktiv, tr\u00e6kkes den tid normalt fra det faste tidsbudget, og teamet fors\u00f8ger at afslutte opgaverne i den resterende tid. Hvilket normalt ikke er en god id\u00e9, men m\u00e5ske den eneste vej frem.<\/p>\n\n

      Derfor, for at drage fordel af udviklingsteamet og deres tid, skal kunden v\u00e6re let tilg\u00e6ngelig for sp\u00f8rgsm\u00e5l fra it-tjenesteudbyderen.<\/p>\n\n

      Tip 2: Den bedste l\u00f8sning til dette ville v\u00e6re:<\/strong> Klienten leverer et dedikeret kontaktpunkt, som er tilg\u00e6ngeligt i l\u00f8bet af udviklingstiden, under hele udviklingsperioden. F.eks. Vil John Smith fra klienten v\u00e6re tilg\u00e6ngelig fra 01. Juli til 30. August. P\u00e5 dette tidspunkt vil John Smith v\u00e6re tilg\u00e6ngelig via Skype eller Slack Chat og kan besvare sp\u00f8rgsm\u00e5lene fra udviklingsteamet.<\/p>\n

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

      3) Giv indhold i tide<\/strong><\/h3>\n\n

      I nogle tilf\u00e6lde er klienten forpligtet til at levere tekster, videoer, billeder og andre typer indhold eller materiale.<\/p>\n\n

      Dette forud aftalte indhold skal leveres til tiden.<\/p>\n\n

      I nogle tilf\u00e6lde har udviklingsselskabet mulighed for at bruge dummy-tekster eller dummy-indhold indtil videre.<\/p>\n\n

      Men for korrekt output er indholdet n\u00f8dvendigt i nogle tilf\u00e6lde.<\/p>\n\n

      Tip 3: S\u00f8rg for at have indholdet (som tekster eller billeder) klar, n\u00e5r udviklingsteamet beder om det.<\/strong><\/p>\n\n

      Bem\u00e6rk: Det kan ogs\u00e5 v\u00e6re relateret til at give godkendelse, at g\u00e5 videre med en opgave eller med et projektdokument, der skal underskrives.<\/p>\n\n

      4) Undg\u00e5: \u201cMen dette var en del af kravet\u201d Argumenter (yderligere vigtigt tip)<\/strong><\/h3>\n\n

      I virkeligheden kan kravene aldrig forst\u00e5s eller skrives fuldt ud i starten af projektet.<\/p>\n\n

      Softwareudviklingsteamet arbejder normalt med nogle eksempler p\u00e5 webadresser, der sendes af klienterne, et eller to onlinem\u00f8der og noget skriftligt materiale som e-mails eller PDF-filer.<\/p>\n\n

      Der er normalt en generel forst\u00e5else af de vigtigste funktionaliteter, men ikke det 100 procent klare billede.<\/p>\n\n

      Dette kan bruges af begge, udviklingsselskabet til at sige \u201c Men dette var ikke en del af kravet, det koster ekstra<\/i> \u201dEller klienten at sige\u201c Men dette var en del af det oprindelige krav, vi \u00f8nsker det helt sikkert gratis<\/i> \u201d.<\/p>\n\n

      Tip 4: Der skal v\u00e6re generel retf\u00e6rdighed p\u00e5 begge sider.<\/strong> V\u00e6rdien for pengene skal v\u00e6re der. Men p\u00e5 den anden side skal det ikke v\u00e6re s\u00e5 uopn\u00e5eligt med en opgave, s\u00e5 udviklingsselskabet slet ikke har nogen fortjeneste fra projekterne.<\/p>\n\n

      Bem\u00e6rk: Generelt b\u00f8r klienten (hvis han ikke er IT-ekspert) stole p\u00e5 den udviklingsprocedure, der foresl\u00e5s af IT-firmaet.<\/p>\n\n

      Konklusion<\/strong><\/h3>\n\n

      Den bedre m\u00e5de at g\u00e5 til softwareprojekter er med den dedikerede udvikler eller dedikerede udvikler \/ Agile tilgang. Men dette er ikke muligt for nogle virksomheder p\u00e5 grund af budgetbegr\u00e6nsninger.<\/p>\n\n

      Derfor giver mange it-serviceselskaber mulighed for projekter med fast pris.<\/p>\n\n

      For klienten er det vigtigt at bem\u00e6rke, at n\u00e5r prisen er fast, s\u00e5 er kravene ogs\u00e5 faste. Ofte forveksles fast pris med en “alt-du-kan-spise-buffet”, hvor du betaler en gang og kan spise (udvikle) s\u00e5 meget som du vil. Tv\u00e6rtimod ligner det mere en \u201cA-La-Carte\u201d menuindstilling, hvor du bestiller b\u00f8f til 5 amerikanske dollars, hvis du vil have fries med det, skal du betale 2 amerikanske dollars ekstra.<\/p>\n\n

      Men ogs\u00e5: Softwareudvikling og forberedelse af m\u00e5ltider er forskellige. Fordi n\u00e5r du opretter en b\u00f8f, er indgangen ret klar. I softwareudvikling er dette ikke altid tilf\u00e6ldet.<\/p>\n\n

      Tipene i denne artikel hj\u00e6lper med at g\u00f8re projekter med fast pris til en succes.<\/p>\n\n

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

      S\u00e5dan f\u00e5r du fastprisprojekter til at fungere for dig<\/a><\/p>\n\n

      Hvordan k\u00f8rer et fastprisprojekt?<\/a><\/p>\n\n

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

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

      Forfatteren: Sascha Thattil arbejder p\u00e5 Software-Developer-India.com, som er en del af YUHIRO Group. YUHIRO er en tysk-indisk virksomhed, der leverer programm\u00f8rer til IT-virksomheder, agenturer og IT-afdelinger.<\/p>\n