Fastpris programvareutviklingsprosjekter: 3 viktige punkter å huske

Fastpris programvareutviklingsprosjekter: 3 viktige punkter å huske

Det er forskjellige måter å gjennomføre et programvareutviklingsprosjekt på. Disse er hovedsakelig:

1. Dedikert utvikler: Du får en utvikler som bare jobber for deg og organisasjonen din. Vanligvis vil en månedlig pris bli avtalt mellom tjenesteleverandøren og klienten. Utvikleren vil jobbe heltid (ca. 160 timer per måned) for klienten.
2. Menneske-og-materiale / Tid-og-materiale / smidig / utviklingsteam: Her er det avtalt et prosjekt, men utførelsen 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år (en utviklingssyklus som varer rundt en måned) blir utviklingstidene justert. Det er ikke en fast pris, men et grovt budsjett som den skal utvikles etter. Det kan være en grov figur, men det kan også være et mangfold av det budsjett tallet. I store organisasjoner foretrekkes vanligvis denne tilnærmingen.
3. Fast pris: Dette brukes vanligvis i mindre prosjekter, der prisen OG kravene er faste. Denne artikkelen handler om denne typen prosjekter, og hva som må tas i betraktning når man gjennomfører et slikt fastprisprosjekt.

Introduksjon

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

Det ville være ganske tøft å si: “Det vil ta rundt 2 til 8 måneder å utvikle seg, og hver time koster 100 amerikanske dollar. Det kan også være 14 måneder”.

Hvis IT-tjenesteselskapet forteller kunden: “ Det tar 4 måneder og et budsjett på 30 000 amerikanske dollar ”, Kan klientens team ta en beslutning om det.

Det store problemet med det er -> Slik fungerer ikke et programvareprosjekt. Følgende er årsakene:

1. Kravene endres i løpet av prosjektet: Ingen vet, ikke engang klienten, hva alt trenger å være i programvaren / nettløsningen for at den skal lykkes. Vanligvis, bare etter noen få uker, blir den første versjonen eller de første nettbrukergrensesnittene synlige. Det er vanligvis når klienten finner ut “Beklager, det er denne funksjonaliteten, som er av største betydning. Uten denne funksjonaliteten vil ikke prosjektet lykkes”. Men prosjektkostnadene og prosjektgjennomføringen har allerede blitt “fikset” fra begge sider, klienten og IT-tjenesteselskapet. Dette kan være en showstopper.
2. Ingen vet nøyaktig hvor lang tid det tar å utvikle en funksjonalitet: Selv om en programvareutvikler kan gi en omtrentlig figur på hvor lang tid det tar å utvikle en funksjonalitet. Han eller hun vet ikke det nøyaktig. Dette gjelder selv den mest erfarne utvikleren. Derfor: Jo større prosjekt, jo høyere er risikoen for at estimatet er feil. Likevel, med en større buffer i prosjektestimatet, prøver programvareutviklingsselskapet på en eller annen måte å redusere denne risikoen.

Dette betyr at IT-tjenesteleverandøren allerede har risikoen for ikke å vite om estimatet fra utvikleren var riktig, og i tillegg kan klienten be om endringer i prosjektet.

Dette er også grunnen til at en stor prosentandel (rundt 40 til 60 prosent) av alle IT-prosjekter mislykkes, ifølge den mye siterte Chaos Report.

For i et fastprisprosjekt vil ingen gi seg. Kunden ønsker ikke å betale en amerikansk dollar mer «Fordi det ble avtalt en fast pris», og IT-tjenesteleverandøren vil bare insistere på å bygge det som ble avtalt «Fordi kravene ble løst i begynnelsen av prosjektet».

Her noen poeng å huske å få faste prisprosjekter til å fungere

1) Kravene er faste (og etter at disse kravene er fullført, blir nye funksjoner lagt til)

Programvareutvikling trenger ikke å stoppe når først de opprinnelig avtalte funksjonene er utviklet. Når det første prosjektet er ferdig, kan neste trinn diskuteres og utføres.

Tips 1: Kunden må gjøre følgende: Motstå trangen til å stille nye krav til det løpende prosjektet. Selv om du har en sterk følelse av at prosjektet ikke vil være verdt for kundene dine.

Det vil være tøft nok til å få de opprinnelige kravene til å fungere. Ikke legg til det.

2) Tilgjengeligheten til klienten i utviklingsperioden

I et fastprisprosjekt vil IT-serviceselskapet tildele (i mindre prosjekter) en til tre utviklere, en teamleder, en prosjektleder og designer.

Når prosjektet starter, vil ting gå fort, og tid skal ikke kastes bort.

Spesielt viktig: Hvis IT-teamet har spørsmål om en oppgave eller trenger tilbakemelding, bør det gjøres tilgjengelig av klienten så snart som mulig. Det verste som kan skje er hvis utviklingsteamet må vente i to dager på tilbakemelding fra klienten og sitte inaktiv på den tiden.

Hvis utviklingsteamet sitter inaktiv, blir den tiden vanligvis trukket fra det faste tidsbudsjettet, og teamet prøver å fullføre oppgavene i gjenværende tid. Noe som vanligvis ikke er en god idé, men kanskje den eneste veien videre.

Derfor, for å dra nytte av utviklingsteamet og deres tid, må klienten være lett tilgjengelig for spørsmål fra IT-tjenesteleverandøren.

Tips 2: Den beste løsningen for dette vil være: Kunden tilbyr et dedikert kontaktpunkt, som er tilgjengelig i løpet av utviklingstiden, gjennom hele utviklingsperioden. For eksempel vil John Smith fra klienten være tilgjengelig fra 01. Juli til 30. August. På denne tiden vil John Smith være tilgjengelig via Skype eller Slack Chat og kan svare på spørsmålene fra utviklingsteamet.

3) Gi innhold i tide

I noen tilfeller kreves det at klienten leverer tekster, videoer, bilder og andre typer innhold eller materiale.

Dette forhåndsavtalte innholdet bør leveres i tide.

I noen tilfeller har utviklingsselskapet muligheten for foreløpig å bruke dummytekster eller dummyinnhold.

Men for riktig produksjon, er innholdet nødvendig i noen tilfeller.

Tips 3: Sørg for å ha innholdet (som tekster eller bilder) klart når utviklingsteamet ber om det.

Merk: Det kan også være relatert til å gi godkjenning, å gå videre med en oppgave eller med et prosjektdokument som må signeres.

4) Unngå: «Men dette var en del av kravet» Argumenter (ytterligere viktig tips)

I virkeligheten kan kravene aldri forstås eller skrives helt ut ved prosjektstart.

Programvareutviklingsteamet jobber vanligvis med noen eksempler på nettadresser som sendes av klientene, ett eller to online møter og noe skriftlig materiale som e-post eller PDF-filer.

Det er vanligvis en generell forståelse av hovedfunksjonalitetene, men ikke det 100 prosent klare bildet.

Dette kan brukes av begge, utviklingsselskapet til å si “ Men dette var ikke en del av kravet, dette koster ekstra ”Eller klienten å si“ Men dette var en del av det opprinnelige kravet, vi vil absolutt ha dette gratis ”.

Tips 4: Det må være generell rettferdighet på begge sider. Verdien for pengene skal være der. Men på den andre siden skal det ikke være så uoppnåelig med en oppgave, slik at utviklingsselskapet ikke har noe overskudd i det hele tatt fra prosjektene.

Merk: Generelt bør klienten (i tilfelle han ikke er IT-ekspert) stole på utviklingsprosedyren som IT-selskapet foreslår.

Konklusjon

Den bedre måten å gå på programvareprosjekter er med den dedikerte utvikleren eller dedikerte utvikleren / Agile tilnærmingen. Men dette er ikke mulig for noen selskaper på grunn av begrensninger i budsjettet.

Derfor tilbyr mange IT-tjenesteselskaper muligheten for faste priser.

For klienten er det viktig å merke seg at når prisen er fast, så er også kravene faste. Ofte forveksles fast pris med en “All-You-Can-Eat-Buffet”, hvor du betaler en gang og kan spise (utvikle) så mye du vil. Tvert imot er det mer som et “A-La-Carte” -menyalternativ, hvor du bestiller biffen til 5 amerikanske dollar, hvis du vil ha pommes frites med det, må du betale 2 amerikanske dollar ekstra.

Men også: Programvareutvikling og tilberedning av måltider er forskjellige. For når du lager en biff, er innspillene ganske klare. I programvareutvikling er dette ikke alltid tilfelle.

Tipsene i denne artikkelen vil bidra til å gjøre prosjekter med fast pris til en suksess.

Interessante artikler:

Hvordan få fastprisprosjekter til å fungere for deg

Utfordringer innen utvikling av programvare med fast pris

Bilder: Canva

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.