Projektutvecklingsprojekt med fast pris: 3 viktiga punkter att komma ihåg
Det finns olika sätt att genomföra ett programvaruutvecklingsprojekt. Dessa är främst:
- Dedikerad utvecklare: Du får en utvecklare som bara arbetar för dig och din organisation. Vanligtvis kommer ett månadspris att avtalas mellan tjänsteleverantören och klienten. Utvecklaren kommer att arbeta heltid (cirka 160 timmar per månad) för klienten.
- Människa-och-material / Tid-och-material / smidig / utvecklingsteam: Här avtalas ett projekt, men genomförandet kommer att göras av ett tvärvetenskapligt team av projektledare, scrummasters, affärsanalytiker, affärsutvecklare, programvara / webbutvecklare, programvarutestare etc. Här används ofta en Agile-metodik och efter varje vår (en utvecklingscykel som varar cirka en månad) justeras utvecklingstiderna. Det är inte ett fast pris, utan en grov budget enligt vilken den kommer att utvecklas. Det kan vara en grov siffra, men det kan också vara en multipel av den budgeten. I stora organisationer föredras vanligtvis detta tillvägagångssätt.
- Fast pris: Detta används vanligtvis i mindre projekt där pris OCH kraven är fastställda. Den här artikeln handlar om denna typ av projekt och vad som måste beaktas vid genomförandet av ett sådant fastprisprojekt.
Introduktion
Många små till medelstora företag har en budget för att genomgå programvaruprojekt. Särskilt i icke-IT-företag är kunskapen om mjukvaruprojekt begränsad. De föredrar att ha ett fast pris där projektledaren inom dessa företag enkelt kan kommuniceras till företagets VD eller ledning.
Det skulle vara ganska svårt att säga: ”Det tar cirka 2 till 8 månader att utvecklas och varje timme kostar 100 dollar. Det kan också vara 14 månader”.
Om IT-tjänsteföretaget säger till kunden, “ Det tar fyra månader och en budget på 30 000 US dollar ”, Kan kundens team fatta beslut om det.
Det stora problemet med det är -> Så här fungerar inte ett mjukvaruprojekt. Följande är anledningarna:
- Kraven ändras under projektet: Ingen vet, inte ens klienten, vad allt behöver vara i programvaran / webblösningen för att den ska lyckas. Vanligtvis först efter några veckor blir den första versionen eller de första webbanvändargränssnitten synliga. Det är vanligtvis när klienten får reda på ”Oj, det finns denna funktionalitet, som är av yttersta vikt. Utan denna funktionalitet kommer inte projektet att lyckas”. Men projektkostnaden och projektgenomförandet har redan ”fixats” från båda sidor, klienten och IT-tjänsteföretaget. Detta kan vara en utställningspropp.
- Ingen vet exakt hur lång tid det tar att utveckla en funktionalitet: Även om en programutvecklare kan ge en ungefärlig bild av hur lång tid det tar att utveckla en funktionalitet. Han eller hon vet inte det exakt. Detta gäller även för den mest erfarna utvecklaren. Därför: Ju större projekt, desto högre är risken att uppskattningen är fel. Fortfarande, med en större buffert i projektuppskattningen, försöker programvaruutvecklingsföretaget på något sätt mildra denna risk.
Detta innebär att IT-tjänsteleverantören redan har risken att inte veta om utvecklarens uppskattning var korrekt, och dessutom kan klienten be om ändringar inom projektet.
Detta är också anledningen till att enligt den mycket citerade Chaos-rapporten misslyckas en stor andel (cirka 40 till 60 procent) av alla IT-projekt.
För i ett fastprisprojekt vill ingen ge efter. Kunden vill inte betala en US-dollar mer ”Eftersom ett fast pris överenskommits”, och IT-tjänsteleverantören kommer att insistera på att bara bygga det som överenskommits ”Eftersom kraven fastställdes i början av projektet”.
Här är några punkter att komma ihåg att få fastprisprojekt att fungera
1) Kraven är fasta (och först efter att dessa krav har avslutats läggs nya funktioner till)
Programutveckling behöver inte stoppas när de ursprungligen överenskomna funktionerna har utvecklats. När det första projektet är klart kan nästa steg diskuteras och utföras.
Tips 1: Klienten behöver göra följande: Motstå uppmaningen att ställa nya krav i det pågående projektet. Även om du har en stark känsla av att projektet inte kommer att löna sig för dina kunder.
Det kommer att vara tillräckligt tufft för att de ursprungliga kraven ska fungera. Lägg inte till det.
2) Kundens tillgänglighet under utvecklingsperioden
I ett fastprisprojekt kommer IT-tjänsteföretaget att fördela (i mindre projekt) en till tre utvecklare, en teamledare, en projektledare och designer.
När projektet startar går saker snabbt och tiden bör inte slösas bort.
Särskilt viktigt: Om IT-teamet har frågor om en uppgift eller behöver feedback, bör den göras tillgänglig av klienten så snart som möjligt. Det värsta som kan hända är om utvecklingsteamet måste vänta i två dagar på kundfeedback och sitta tomgång under den tiden.
Om utvecklingsteamet sitter inaktivt dras den tiden vanligtvis från den fasta tidsbudgeten och teamet försöker slutföra uppgifterna under återstående tid. Vilket vanligtvis inte är en bra idé, men kanske den enda vägen framåt.
För att kunna dra nytta av utvecklingsteamet och deras tid måste kunden vara lätt tillgänglig för frågor från IT-tjänsteleverantören.
Tips 2: Den bästa lösningen för detta skulle vara: Klienten tillhandahåller en särskild kontaktpunkt, som är tillgänglig under utvecklingstider, under hela utvecklingsperioden. Till exempel kommer John Smith från klienten att vara tillgänglig från 01. Juli till 30. Augusti. Under den här tiden kommer John Smith att vara tillgänglig via Skype eller Slack Chat och kan svara på frågorna från utvecklingsteamet.
3) Ge innehåll i tid
I vissa fall är klienten skyldig att tillhandahålla texter, videor, bilder och andra typer av innehåll eller material.
Detta förutbestämda innehåll bör tillhandahållas i tid.
I vissa fall har utvecklingsföretaget möjlighet att använda dummytexter eller dummyinnehåll för tillfället.
Men för korrekt produktion behövs innehållet i vissa fall.
Tips 3: Se till att ha innehållet (som texter eller bilder) klart när utvecklingsteamet ber om det.
Obs: Det kan också vara relaterat till att ge godkännande, att gå vidare med någon uppgift eller med något projektdokument som måste undertecknas.
4) Undvik: ”Men detta var en del av kravet” Argument (ytterligare viktigt tips)
I verkligheten kan kraven aldrig förstås helt eller skrivas ner i början av projektet.
Programvaruutvecklingsteamet arbetar vanligtvis med några exempel på webbadresser som skickas av klienterna, ett eller två online-möten och något skriftligt material som e-post eller PDF-filer.
Det finns vanligtvis en allmän förståelse för de viktigaste funktionerna, men inte den 100 procent tydliga bilden.
Detta kan användas av båda, utvecklingsföretaget för att säga ” Men detta var inte en del av kravet, det kostar extra ”Eller klienten att säga” Men detta var en del av det ursprungliga kravet, vi vill definitivt ha det gratis ”.
Tips 4: Det måste finnas allmän rättvisa på båda sidor. Valuta för pengarna borde finnas där. Men på andra sidan borde det inte vara så ouppnåeligt av en uppgift, så att utvecklingsföretaget inte har någon vinst alls från projekten.
Obs: I allmänhet bör klienten (om han inte är IT-expert) lita på det utvecklingsförfarande som IT-företaget föreslår.
Slutsats
Det bättre sättet att gå till programvaruprojekt är med den dedikerade utvecklaren eller dedikerade utvecklaren / Agile-metoden. Men detta är inte möjligt för vissa företag på grund av budgetbegränsningar.
Därför erbjuder många IT-tjänsteföretag möjlighet till fasta priser.
För klienten är det viktigt att notera att när priset är fast, så är kraven också fasta. Ofta misstas fast pris med en ”Allt-du-kan-äta-buffé”, där du betalar en gång och kan äta (utveckla) så mycket du vill. Tvärtom är det mer som ett “A-La-Carte” -menyalternativ, där du beställer biffen för 5 US-dollar, om du vill ha pommes frites måste du betala 2 US-dollar extra.
Men också: Utveckling av programvara och förberedelse av måltider är olika. För när du skapar en biff är ingången ganska tydlig. I programvaruutveckling är detta inte alltid fallet.
Tipsen i den här artikeln hjälper till att göra projekt med fast pris till en framgång.
Intressanta artiklar:
Hur man får fastprisprojekt att fungera för dig
Utmaningar i utveckling av mjukvara med fast pris
Bilder: Canva
Författaren: Sascha Thattil arbetar på Software-Developer-India.com som är en del av YUHIRO Group. YUHIRO är ett tysk-indiskt företag som tillhandahåller programmerare till IT-företag, byråer och IT-avdelningar.
Lämna ett svar