Hur man bedömer en uppskattning av programvarukostnad (för icke-tekniska personer)

Hur man bedömer en uppskattning av programvarukostnad (för icke-tekniska personer)

Det är ganska svårt att utvärdera ett mjukvaruprojekt och sätta en prislapp på det.

I artikeln några utmaningar och hur man går igenom bedömning av programvarukostnader.

Introduktion

Enligt kaosrapporten, som ofta citeras, misslyckas cirka 30 procent av alla programvaruprojekt. Det betyder att antingen projektets varaktighet blir för lång eller att budgeten inte hålls.

Här några utmaningar i mjukvaruprojekt:

1) Svårt att kontrollera de exakta kraven

Om du vill bygga ett specialbyggt stort hus kan ett pris bara fastställas om varje del av arbetet bedöms korrekt. Upp till den sista skruven, som kommer att användas.

Arkitekten kommer att skapa en plan med en exakt plan, där hela huset replikeras antingen på papper eller ofta idag som 3D-modell. Och i dessa program kan det beräknas hur många skruvar etc. som behövs för att bygga huset.

Med denna information är det möjligt att ge en exakt uppskattning av husbyggnadsprojektet.

Men vi vet också: I mycket stora byggprojekt är prisuppskattningarna vanligtvis inte korrekta. Och vad som skulle kosta 500 miljoner euro kommer att kosta 5 miljarder euro eller mer. Berlins flygplats, Elbphilharmonie i Hamburg och centralstationen i Stuttgart, Tyskland är tre exempel, i de flesta fall minskade kostnaden med en miljard euro eller mer.

När det gäller centralstationen i Stuttgart var avgiften för arkitekten cirka 36 miljoner euro. Även om arkitekten fick ett så högt belopp. Uppskattningen av projektets kostnad minskade med cirka 1 miljard euro.

Liknande utmaningar kan ses i programvaruprojekt.

Särskilt när icke-tekniska personer är involverade i att vidarebefordra kraven för programvaran eller webbprojektet. Vanligtvis kommer projektbeskrivningarna bara några rader i ett e-postmeddelande. Eller ett telefonsamtal där den önskade lösningen beskrivs.

Några exempel på webbplatser kommer att ges som referens. Inte sällan har dessa exempelwebbplatser byggts under många år och kostat hundratusentals euro, ibland miljoner.

Men budgeten för webbapplikationen eller mjukvarulösningen kommer att ligga runt 4 000 till 40 000 euro och den ska byggas inom två månader, högst 3 månader. (Det är vanligtvis den icke-IT-personens önskan som frågar om priset).

Verkligheten är denna: Utan ett detaljerat förfrågningsdokument från klienten, som kommer att vara cirka 10 till 50 sidor och ett detaljerat förslag som skapats av IT-företaget, baserat på det förfrågade dokumentet, kan ett pris för projektet inte fastställas.

Och även om det finns ett exakt förslagsdokument. Vanligtvis ändras kraven under projektet, vilket gör denna övning av skapande av förslag, vilket kan ta veckor, en onödig uppgift.

2) Ändrade krav under projektet

Det finns nästan inget IT-projekt där det ursprungligen citerade mjukvaruprojektet förblir detsamma under projektet.

Anledningen är att kunden först först när programvaran börjar forma, att det saknas några viktiga saker, utan vilka projektet inte kan lyckas och programvaran inte hjälper affärsprocesserna.

Men tänk om ett fast pris har överenskommits? Hur kan IT-tjänsteleverantören tillåta ändringar under projektet. Detta är nästan omöjligt, för då kommer IT-tjänsteleverantören inte att göra någon vinst alls.

På andra sidan kommer kunden att insistera på det fasta priset och säga att ”För denna lilla förändring finns det inget behov av att ändra budgeten. Denna lilla ändringsförfrågan kan du lägga i den ursprungliga offerten ”.

Och här är vanligtvis där dilemmaet börjar. Denna diskussion om ändringsförfrågningar kommer att fortsätta och fortsätta. Och projektet kommer att fastna.

Således är det alltid bättre att hålla projektbudgeten flytande. Där kunden betalar så mycket som mjukvaruutvecklingen kräver. -> Naturligtvis kan detta verka ”som en himmel för mjukvaruföretaget” för klienten, för han / hon kommer att tro att de kommer att göra fler timmar än nödvändigt.

Men jämför det med en restaurang. Om du beställer en extra coca cola eller en extra biff, måste du också betala för den extra saken. Varför ska det vara annorlunda vid programutveckling? Särskilt inom IT där timpriserna vanligtvis är mycket högre.

3) Svårigheter att förstå komplexiteten i programvaruutveckling av icke-IT-personen

Det är vanligtvis mycket svårt att förstå för en icke-IT-person att förstå komplexiteten i mjukvaruutveckling.

”Min vän byggde den här webbplatsen på en dag och den har många funktioner. Varför behöver du som expert mer än 6 månader för att utveckla dessa funktioner?”

Troligtvis använde vän en del Content Management System som WordPress eller Drupal och använde några vanliga plugins, som vanligtvis ger många funktioner. Men det här är inte anpassade mjukvarulösningar gjorda för kompisen. Det är system och plugins som vanligtvis används av tusentals hundratusentals människor, som har liknande krav. Dessa är inte skräddarsydda lösningar.

Men: Att bygga dessa plugins krävde troligen cirka 2 till 5 eller fler utvecklare på heltid i flera månader eller till och med år. Så även om kompisen använder till synes enkla lösningar. De har skapats i en mycket komplex mjukvaruutveckling.

Så om klienten har några krav som kan uppfyllas av dessa plugins och ”färdiga lösningar”. Då är det bättre att använda dem. Men i de flesta fall är dessa ”färdiga” mjukvarusystem inte vad kunden kräver.

Det bästa exemplet är Googles sökmotor. I fronten (vad användaren ser) finns det bara ett sökfält och två knappar. Så en icke-IT-person skulle säga ”det kan bara ta en vecka att utveckla detta. Det finns bara ett sökfält och två knappar ”. I verkligheten finns det många ”dolda” backendfunktioner, som utvecklas av tusentals och tusentals utvecklare och det under många år.

Beroende på komplexiteten, behovet av skalbarhet etc. i klientprojektet kan programutvecklingen ta mer tid än förväntat.

Möjliga lösningar

Det finns några lösningar för hur en icke-IT-person kan närma sig förfrågan till IT-tjänsteleverantören.

1) involvera en programutvecklare

Helst skulle det finnas en egen mjukvaruutvecklare eller IT-expert som skulle kunna korsa kontrollen av IT-tjänsteföretaget.

Vanligtvis rekommenderar den programutvecklaren att hålla projektets omfattning flexibel så att ändringar kan tillgodoses.

Om programvaruföretagets uppskattning är rimlig kommer programutvecklaren att ge grönt ljus.

På det sättet, som en intern anställd utvärderar projektet, kommer den icke-IT-personen också att vara övertygad om insatserna för utvecklingen.

2) Användning av dedikerad utvecklare

En dedikerad utvecklare, är en utvecklare som tillhandahålls till klienten på heltid.

Fördelen med detta är att utvecklaren arbetar nära klienten och även med klientens team. Detta ökar transparensen. Och klienten eller teamet kan ställa frågor och få svar i realtid.

Denna modell fungerar på olika sätt:

• På plats: IT-tjänsteföretaget ber utvecklaren att gå till klientens plats och arbeta hos klienten.
• IT-outsourcing: Ett team av utvecklare arbetar i IT-tjänsteföretagets lokaler.
• Nearshore Outsourcing: Den dedikerade utvecklaren arbetar hos en IT-tjänsteleverantör i ett närliggande land. För Sverige skulle det vara Polen eller Ukraina. För Japan skulle det vara Malaysia eller Kina.
• Offshore outsourcing: Här sitter utvecklaren i ett programvaruföretags lokaler i ett fjärran land. Exempel är Indien, Pakistan, etc. Men orden Nearshore eller Offshore kan användas omväxlande. Det beror på var klienten är belägen. Om klienten är i Japan är Indien ett Nearshore Outsourcing-mål.

Klienten kan använda den dedikerade utvecklaren så länge han / hon vill. Till projektet är klart. Om projektet tar för lång tid. Klienten och teamet kan diskutera med utvecklaren vilken väg att gå för att nå målen snabbare.

3) Undvik styva fastprisprojekt

Ett fast pris är vanligtvis inte en bra idé. Bara om projektet är mycket litet. Gilla en webbplats på en sida eller liknande.

Fasta priser kan leda till ett falskt hopp om att allt kommer att göras, inom det priset. (Även allt-du-kan-äta fungerar inte så. Du kan äta så mycket du vill, men bara för en måltid. Inte för dagar i rad. Men det är vad kunderna förväntar sig när de får ett fast pris i mjukvaruutveckling)

Bättre att gå till en smidig prissättning, där programvaruleverantörens tid och ansträngningar betalas ut, beroende på hur mycket ansträngning som går till utvecklingen.

Eller använd en dedikerad utvecklare eller ett team av dedikerade programvarupersonal för att arbeta med ditt projekt.

Slutsats

Många programvaruprojekt misslyckas bara, eftersom det saknas förståelse för vad anpassad programvaruutveckling innebär. Verkligen enkla projekt kan ta veckor och månader.

Därför måste vissa bedömningar göras av klienten. Vad är kostnadsintervallet för mjukvaruutveckling och vilket affärsvärde skapas av det. Skapas affärsvärde, mycket högre än den budget som behövs för mjukvaruutvecklingen? Bra, då är det bra att gå. Starta projektet.

Om det skapade affärsvärdet och kostnaden inte stämmer överens. Då är det kanske bättre att fortsätta använda manuella lösningar, Excel-filer eller standardprogramvara eller webblösningar, som kan prenumerera, genom att betala en låg månadsavgift.

Ser fram emot en intressant diskussion.

Intressanta länkar:
Varför uppskattningar kanske inte är en bra idé
Myten om programvaruuppskattningar förklaras

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.