Varför är uppskattningar av programvaruutveckling regelbundet av med en faktor 2-3?

Detta är ett svar på Quora-frågan: Varför är uppskattningarna inte exakta?

Det finns flera faktorer för detta. Här är några vanliga:

1) Kunden är icke-teknisk och känner att ”allt är enkelt”

Att utveckla en programvara är inte så enkelt som det ser ut.

Även om det ser enkelt ut är det ibland bättre att utelämna vissa uppgifter.

  • För att ta en analogi:

Det finns en enorm kulle och vi måste bygga ett järnvägsspår. Utvecklarna kommer att ge råd: ”Bättre undvik kullen och bygg banan runt kullen. På detta sätt sparar vi 5 månaders extra arbete ”.

Här skulle det vara uppenbart att det kommer mycket mer tid att borra en tunnel genom backen och kunden går med på ”arbetet runt”.

  • Låt oss nu titta på mjukvaruutveckling:

Utvecklaren säger: ”Det vore bättre att bara ha en mobilversion med en skärmstorlek och en stationär version med en skärmstorlek. Vi bör undvika att ha en mobilapp och också undvika en helt responsiv design, för det ser inte bra ut ”.

Här kommer klienten troligen att säga: ”Varför? Andra webbplatser är också lyhörda och kan ändras till alla skärmstorlekar. Det är en lätt uppgift. ”

Men: Det kan finnas flera och bra anledningar till varför utvecklaren har föreslagit detta. Kanske ser en lyhörd design inte bra ut eller är professionell. Speciellt vissa knappar kan lätt skadas etc. etc.
Så nu kommer det att hända att utvecklaren kommer att göra det 1) bygga sidan lyhörd och 2) kommer att öka timmarna.

  • För timmeökningen kommer inte klienten att acceptera: ”Varför fler timmar? Det är enkelt, eller hur? ”
  • När uppgiften är klar kommer klienten att titta på webbplatsen med sin mobil och säga: ”Allt är feljusterat när jag kollar webbplatsen på mobil. Varför? Jag betalade mycket mer och nu det här? ”.

Om klienten hade gått med på tidigare sätt att göra det (icke-responsivt, med bara två versioner), skulle webbplatsen ha varit billigare (mindre timmar) och det skulle vara helt bra på nästan alla mobilskärmar och stationära webbläsare.

Huvudfrågan här är också: Det är inte bra att argumentera med någon. Det är inte bra att argumentera med klienten. Så utvecklaren / tjänsteleverantören kommer alltid att säga ”Ja, du har rätt, låt oss göra det på det sättet”.

Och när klienten inte är riktigt nöjd, bör utvecklaren åter ta skulden (även om han / hon vet att det inte var hans fel, men att kravet var på ett sådant sätt).

2) Det är inte möjligt att ta mycket tid att uppskatta exakt

I den verkliga världen kommer ett mjukvaruföretag att få förfrågningar om programvaror dagligen eller varje vecka.

Om varje begäran skulle uppskattas exakt, skulle utvecklarna inte ha något annat att göra än att skapa exakta uppskattningar. De skulle inte kunna arbeta med riktiga projekt, eftersom det är mycket tidskrävande att skapa de exakta uppskattningarna.

Så vad som faktiskt händer är: De kommer att titta på projektet och ”uppskatta” den tid som behövs. Att det är därför det kallas en ”uppskattning”, för den är inte exakt.

Dessutom: Klienten själv är inte intresserad av att vänta på en eller flera veckor för att specificera kravet. Högst ett 5-sidigt dokument skapas och det kommer att ligga till grund för utvecklingen.

3) Alla krav ändras under projektet

Jag gillar att citera Andrew Rose från Quora-tråden / länken från början av denna artikel:

”Oavsett hur stort eller litet ett projekt är kommer det alltid att finnas något som kommer upp när du startar projektet. Mer troligt kommer många saker att komma upp. Det är bara odjurets natur. Som produktchef är ditt jobb att arbeta med dina kunder för att komma fram till vad de behöver och är villiga att betala för. Du måste också komma på vad du rimligen kan leverera med hjälp av dina utvecklare. När du arbetar för att uppfylla dessa mål stöter du på ändringar i omfattning, felaktiga tidsberäkningar och ibland förändringar hos de personer som arbetar för att slutföra projektet. ”

Många saker förändras under projektet. Som Andrew nämnde kommer inte bara kraven att förändras. Även människor kan gå in i andra projekt innan det pågående projektet är klart.

Här en analogi:

En 100 meter sprinter tränar i 10 år för att köra 100 meter på under 10 sekunder.

På sprintdagen, säger klienten, behöver vi också 5 hinder längs vägen.

Då kommer sprintern att säga, ”men då kommer jag inte att kunna köra den under 10 sekunder” och klienten kommer att säga ”för vad tränade du de senaste 10 åren, vänligen gör det under 10 sekunder”.

Samma sak också i mjukvaruprojekt. Kunder och projektledare kommer att införa nya krav eftersom ”Åh, jag glömde den här mycket viktiga funktionen. Det måste finnas i programvaran, annars kommer det inte att vara användbart för oss ”.

Dessa kravändringar kommer vanligtvis under hela projektet. Det är som att lägga till en damm, en vägg, en stege osv. I vägen för sprinteren och förvänta sig att han / hon fortfarande gör det under 10 sekunder.

4) Arkitekturen är inte korrekt kontrollerad

Speciellt när saker inte görs från grunden och verktyg från tredje part (WordPress, TYPO3, Drupal, Magento, Shopware och många andra) används och de bör anpassas för att göra något särskilt det kan komma till fel uppskattningar .

I dessa tredjepartsverktyg kan vi inte bara ändra allt vi vill. Enkla saker som URL-strukturen eller andra saker måste följas.

Som i punkt 1) i denna text är inte allt lätt att implementera. När det väl har konstaterats att den nuvarande arkitekturen för tredjepartssystemet inte stöder en specifik funktionalitet är det alltid bättre att undvika den specifika funktionaliteten och använda ett arbete som gör samma jobb utan att använda den befintliga arkitekturen.

Obs! Det här problemet / problemet kommer också att uppstå om projektet görs från grunden med verktyg som PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js, etc. och några initiala, felaktiga antaganden. gjordes om systemets arkitektur.

5) ”En mening” eller ”ett ord” visar stopp

Jag har redan nämnt exemplet på det 5-sidiga dokumentet, som kommer att tillhandahållas av klienten. När utvecklingen nästan är klar eller pågår kommer kunden att säga: ”Det saknas en viktig funktion. På sidan 3 på rad 22 nämns att vi behöver – ett rapporteringsverktyg – ”.

Men att bygga detta rapporteringsverktyg, som bara nämns kort i dokumentet, tar i sig samma belopp som hela projektet. Och eftersom ”rapporteringsverktyget” nämns i dokumentet kommer klienten naturligtvis att insistera på dess implementering.

6) Vinn projektet

Låt oss anta att du har en känsla av att många företag bjuder på samma projekt. Nu vill du definitivt inte vara det förslag som tar ut högsta antal timmar. Du vill vara den som visar det lägsta antalet timmar. Om en klient kan välja mellan 100 timmar och 500 timmar kommer definitivt alla att välja 100 timmar.

I verkligheten, i en idealvärld, behöver alla samma antal timmar. Så även om 100 timmar citerades kommer det att bli 500 timmar.

7) Okända / väntetider

Det finns flera okända i mjukvaruprojekt:

  • a) Teknikförändring: Om ett av utvecklingsverktygen (t.ex. Android) får en större uppdatering måste mer arbete göras för att införliva dessa tekniska förändringar.
  • b) Teammedlemmarnas erfarenhet: Om en seniorutvecklare arbetar med projektet tar det kortare tid, om det är en juniorutvecklare, kommer det troligen att ta mer tid.
  • c) Feedback kommer sent: Kunder är vanligtvis inte mycket intresserade av projektet, de vill ha bra resultat. Så när kunden kontaktas under projektet är de kanske inte villiga att svara inom en timme. Det kan ta flera dagar. Under den tiden kommer projektet att vara inaktivt och tjänsteleverantören kan till och med ta ut timmar under den tiden, om utvecklarna sitter i viloläge på grund av fördröjningen i svaren.

8) Projektet är för stort för att kunna uppskattas korrekt

Låt oss anta att uppgiften är en, som behöver flera utvecklare under en period av flera månader.

Det är nästan omöjligt att bryta ner uppgifterna i sådana små bitar av arbetet, för att få rätt uppskattning.

De andra sakerna som nämns i denna artikel kommer naturligtvis också att spela en roll.

Slutsats

Det bästa tillvägagångssättet är:

  • Gör en ungefärlig uppskattning
  • Nämn att det är bäst att minska funktionerna, om projektet tar för lång tid och tar många timmar (t.ex. skapa en prioriterad lista över funktioner, gör bara den viktigaste)
  • Använd den smidiga metoden för utveckling och fakturering

Om du vill ha ett exakt pris / timmar är det vanligtvis bara möjligt i mindre projekt som kommer att pågå några veckor.

Andra intressanta artiklar om ämnet:
Hur man uppskattar programvaruutvecklingsprojekt i arbetstimmar realistiskt
Varför mjukvaruutveckling fungerar inte tidsberäkning och alternativa metoder

Bildkälla: Flickr.com/ Michael Kappel / Judit Klein / Markus Spiske


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

Denna webbplats använder Akismet för att minska skräppost. Lär dig hur din kommentardata bearbetas.