Fastpris Softwareudviklingsprojekter: 3 vigtige punkter at huske

Fastpris Softwareudviklingsprojekter: 3 vigtige punkter at huske

Der er forskellige måder at udføre et softwareudviklingsprojekt på. Disse er hovedsageligt:

1. Dedikeret udvikler: Du får en udvikler, der kun arbejder for dig og din organisation. Normalt aftales en månedlig pris mellem tjenesteudbyderen og klienten. Udvikleren vil arbejde på fuld tid (ca. 160 timer om måneden) for klienten.
2. Menneske-og-Materiale / Tid-og-Materiale / Agil / Udviklingsteam: Her er der aftalt et projekt, men udførelsen vil blive udført af et tværfagligt team af projektledere, scrummasters, forretningsanalytikere, forretningsudviklere, software / webudviklere, softwaretestere osv. Her anvendes ofte en Agile-metode, og efter hvert forår (en udviklingscyklus, der varer omkring en måned) justeres udviklingstiderne. Det er ikke en fast pris, men et groft budget, ifølge hvilket den vil blive udviklet. Det kunne være en grov figur, men det kunne også være et multiplum af dette budgettal. I store organisationer foretrækkes denne tilgang normalt.
3. Fast pris: 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år man udfører et sådant fastprisprojekt.

Introduktion

Mange små til mellemstore virksomheder har et budget til at gennemgå softwareprojekter. Især i ikke-it-virksomheder er viden om softwareprojekter begrænset. De foretrækker at have en fast pris, hvor projektlederen inden for disse virksomheder let kan kommunikeres til administrerende direktør eller ledelse.

Det ville være ret svært at sige: ”Det tager cirka 2 til 8 måneder at udvikle sig, og hver time koster 100 amerikanske dollars. Det kan også være 14 måneder”.

Hvis it-serviceselskabet fortæller klienten, “ Det tager 4 måneder og et budget på 30.000 amerikanske dollars ”, Kan klientens team træffe en beslutning om det.

Det store problem med det er -> Sådan fungerer et softwareprojekt ikke. Følgende er årsagerne:

1. Krav ændres under projektet: Ingen ved, ikke engang klienten, hvad alt skal være i softwaren / webløsningen for at det skal lykkes. Normalt først efter et par uger bliver den første version eller de første webbrugergrænseflader synlige. Det er normalt når klienten finder ud af “Ups, der er denne funktionalitet, som er af største betydning. Uden denne funktionalitet bliver projektet ikke en succes”. Men projektomkostningerne og projektudførelsen er allerede “rettet” fra begge sider, klienten og it-serviceselskabet. Dette kan være en showstopper.
2. Ingen ved præcis, hvor lang tid det tager at udvikle en funktionalitet: Selvom en softwareudvikler kan give et omtrentligt tal på, hvor lang tid det tager at udvikle en funktionalitet. Han eller hun ved det ikke nøjagtigt. Dette gælder for selv den mest erfarne udvikler. Derfor: Jo større projekt, jo større er risikoen for, at estimatet er forkert. Stadig med en større buffer i projektestimatet forsøger softwareudviklingsfirmaet på en eller anden måde at afbøde denne risiko.

Dette betyder, at it-tjenesteudbyderen allerede har en risiko for ikke at vide, om udviklernes skøn var korrekt, og på toppen af det kan klienten muligvis bede om ændringer inden for projektet.

Dette er også grunden til, at ifølge den meget citerede Chaos-rapport mislykkes en stor procentdel (omkring 40 til 60 procent) af alle it-projekter.

For i et fastprisprojekt ønsker ingen at give efter. Klienten ønsker ikke at betale en US-dollar mere ”Fordi der blev aftalt en fast pris”, og IT-tjenesteudbyderen vil kun insistere på at bygge det, der blev aftalt “Fordi kravene blev løst i starten af projektet”.

Her er nogle punkter, du skal huske at få faste prisprojekter til at fungere

1) Kravene er faste (og først efter afslutningen af disse krav tilføjes nye funktioner)

Softwareudvikling behøver ikke at stoppe, når først de oprindeligt aftalte funktionaliteter er blevet udviklet. Når det oprindelige projekt er afsluttet, kan det næste trin diskuteres og udføres.

Tip 1: Kunden skal gøre følgende: Modstå trangen til at stille nye krav i det igangværende projekt. Selvom du har en stærk fornemmelse af, at projektet ikke vil være værd for dine kunder.

Det bliver svært nok til at få de oprindelige krav til at fungere. Tilføj ikke til det.

2) Kundens tilgængelighed i udviklingsperioden

I et fastprisprojekt vil IT-serviceselskabet allokere (i mindre projekter) en til tre udviklere, en teamleder, en projektleder og designer.

Når projektet starter, går tingene hurtigt, og tiden bør ikke spildes.

Især vigtigt: Hvis it-teamet har spørgsmål om en opgave eller har brug for feedback, skal det gøres tilgængeligt af klienten så hurtigt som muligt. Den værste ting, der kan ske, er, hvis udviklingsteamet skal vente i 2 dage på klientfeedback og sidder inaktiv i den tid.

Hvis udviklingsteamet sidder inaktiv, trækkes den tid normalt fra det faste tidsbudget, og teamet forsøger at afslutte opgaverne i den resterende tid. Hvilket normalt ikke er en god idé, men måske den eneste vej frem.

Derfor, for at drage fordel af udviklingsteamet og deres tid, skal kunden være let tilgængelig for spørgsmål fra it-tjenesteudbyderen.

Tip 2: Den bedste løsning til dette ville være: Klienten leverer et dedikeret kontaktpunkt, som er tilgængeligt i løbet af udviklingstiden, under hele udviklingsperioden. F.eks. Vil John Smith fra klienten være tilgængelig fra 01. Juli til 30. August. På dette tidspunkt vil John Smith være tilgængelig via Skype eller Slack Chat og kan besvare spørgsmålene fra udviklingsteamet.

3) Giv indhold i tide

I nogle tilfælde er klienten forpligtet til at levere tekster, videoer, billeder og andre typer indhold eller materiale.

Dette forud aftalte indhold skal leveres til tiden.

I nogle tilfælde har udviklingsselskabet mulighed for at bruge dummy-tekster eller dummy-indhold indtil videre.

Men for korrekt output er indholdet nødvendigt i nogle tilfælde.

Tip 3: Sørg for at have indholdet (som tekster eller billeder) klar, når udviklingsteamet beder om det.

Bemærk: Det kan også være relateret til at give godkendelse, at gå videre med en opgave eller med et projektdokument, der skal underskrives.

4) Undgå: “Men dette var en del af kravet” Argumenter (yderligere vigtigt tip)

I virkeligheden kan kravene aldrig forstås eller skrives fuldt ud i starten af projektet.

Softwareudviklingsteamet arbejder normalt med nogle eksempler på webadresser, der sendes af klienterne, et eller to onlinemøder og noget skriftligt materiale som e-mails eller PDF-filer.

Der er normalt en generel forståelse af de vigtigste funktionaliteter, men ikke det 100 procent klare billede.

Dette kan bruges af begge, udviklingsselskabet til at sige “ Men dette var ikke en del af kravet, det koster ekstra ”Eller klienten at sige“ Men dette var en del af det oprindelige krav, vi ønsker det helt sikkert gratis ”.

Tip 4: Der skal være generel retfærdighed på begge sider. Værdien for pengene skal være der. Men på den anden side skal det ikke være så uopnåeligt med en opgave, så udviklingsselskabet slet ikke har nogen fortjeneste fra projekterne.

Bemærk: Generelt bør klienten (hvis han ikke er IT-ekspert) stole på den udviklingsprocedure, der foreslås af IT-firmaet.

Konklusion

Den bedre måde at gå til softwareprojekter er med den dedikerede udvikler eller dedikerede udvikler / Agile tilgang. Men dette er ikke muligt for nogle virksomheder på grund af budgetbegrænsninger.

Derfor giver mange it-serviceselskaber mulighed for projekter med fast pris.

For klienten er det vigtigt at bemærke, at når prisen er fast, så er kravene også faste. Ofte forveksles fast pris med en “alt-du-kan-spise-buffet”, hvor du betaler en gang og kan spise (udvikle) så meget som du vil. Tværtimod ligner det mere en “A-La-Carte” menuindstilling, hvor du bestiller bøf til 5 amerikanske dollars, hvis du vil have fries med det, skal du betale 2 amerikanske dollars ekstra.

Men også: Softwareudvikling og forberedelse af måltider er forskellige. Fordi når du opretter en bøf, er indgangen ret klar. I softwareudvikling er dette ikke altid tilfældet.

Tipene i denne artikel hjælper med at gøre projekter med fast pris til en succes.

Interessante artikler:

Sådan får du fastprisprojekter til at fungere for dig

Udfordringer inden for udvikling af software til fast pris

Billeder: Canva

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.