Hvorfor er beregninger af softwareudviklingsopgaver regelmæssigt ude af en faktor 2-3?

Hvorfor er beregninger af softwareudviklingsopgaver regelmæssigt ude af en faktor 2-3?

Dette er et svar på Quora-spørgsmålet: Hvorfor er estimater ikke nøjagtige?

Der er flere faktorer for dette. Her er nogle almindelige:

1) Kunden er ikke-teknisk og føler “alt er let”

At udvikle en software er ikke så let som det ser ud.

Selvom det ser let ud, er det nogle gange bedre at udelade visse opgaver.

• For at tage en analogi:

Der er en enorm bakke, og vi skal bygge et jernbanespor. Udviklerne vil rådgive: ”Undgå bedre bakken og bygg sporet omkring bakken. På denne måde sparer vi 5 måneders ekstra arbejde ”.

Her ville det være indlysende, at det vil meget mere tid at bore en tunnel gennem bakken, og klienten ville acceptere “arbejdet rundt”.

• Lad os nu se på softwareudvikling:

Udvikleren siger: ”Det ville være bedre kun at have en mobilversion med en skærmstørrelse og en desktopversion med en skærmstørrelse. Vi bør undgå at have en mobilapp og også undgå et helt responsivt design, fordi det ikke ser godt ud ”.

Her vil klienten sandsynligvis sige: ”Hvorfor? Andre websteder er også lydhøre og kan skifte til alle skærmstørrelser. Det er en let opgave. ”

Men: Der kan være flere og gode grunde til, at udvikleren har foreslået dette. Måske ser et responsivt design ikke godt ud eller professionelt. Især nogle knapper kan let malignere osv. Osv.
Så hvad der nu sker, er at udvikleren vil 1) opbyg siden til at reagere og 2) øger timerne.

• For timeforøgelsen vil der ikke være nogen accept fra klienten: ”Hvorfor flere timer? Det er let, ikke? “
• Når opgaven er udført, vil klienten se på hjemmesiden med sin mobil og vil sige: ”Alt er forkert justeret, når jeg tjekker siden på mobil. Hvorfor? Jeg betalte meget mere og nu dette? ”.

Hvis klienten havde accepteret den tidligere måde at gøre det på (ikke-responsivt, med kun to versioner), ville hjemmesiden have været billigere (færre timer), og det ville være helt fint på næsten enhver mobilskærm og desktop-browser.

Hovedproblemet her er også: Det er ikke godt at argumentere med nogen. Især at argumentere med klienten er ikke en god idé. Så udvikleren / tjenesteudbyderen vil altid sige “Ja, du har ret, lad os gøre det på den måde”.

Og når først klienten ikke er rigtig tilfreds, skal udvikleren igen tage skylden (selvom han / hun ved, at det ikke var hans skyld, men at kravet var på en sådan måde).

2) Det er ikke muligt at tage meget tid på at estimere nøjagtigt

I den virkelige verden vil et softwarefirma modtage anmodninger om softwareapplikationer dagligt eller ugentligt.

Hvis hver anmodning ville blive estimeret nøjagtigt, ville udviklerne ikke have andet at gøre end at oprette nøjagtige estimater. De ville ikke være i stand til at arbejde på rigtige projekter, fordi det er meget tidskrævende at oprette disse nøjagtige estimater.

Så hvad der faktisk sker, er: De vil se på projektet og “estimere” den nødvendige tid. At det er derfor, det kaldes et “estimat”, fordi det ikke er nøjagtigt.

Også: Kunden selv er ikke interesseret i at vente i en eller flere uger på at specificere kravet. Der oprettes højst et 5-siders dokument, og det vil være grundlaget for udviklingen.

3) Hvert krav ændres under projektet

Jeg kan godt lide at citere Andrew Rose fra Quora-tråden / linket fra begyndelsen af denne artikel:

”Uanset hvor stort eller lille et projekt er, vil der altid være noget, der kommer op, når du starter projektet. Mere sandsynligt vil mange ting komme op. Det er bare dyrets natur. Som produktchef er dit job at arbejde sammen med dine kunder for at komme med det, de har brug for og er villige til at betale for. Du skal også komme med det, du med rimelighed kan levere med hjælp fra dine udviklere. Når du arbejder på at opfylde disse mål, får du ændringer i omfanget, forkerte tidsestimater og nogle gange ændringer i de mennesker, der arbejder på at gennemføre projektet. ”

Mange ting ændrer sig under projektet. Som Andrew nævnte, vil ikke kun kravene ændre sig. Selv folk går måske ind i andre projekter inden den aktuelle projektafslutning.

Her en analogi:

En 100 meter sprinter træner i 10 år for at køre 100 meter på under 10 sekunder.

På sprintdagen, siger klienten, har vi også brug for 5 forhindringer undervejs.

Så vil sprinteren sige, “men så kan jeg ikke køre den under 10 sekunder”, og klienten vil sige “for hvad har du trænet de sidste 10 år, bedes du gøre det under 10 sekunder”.

Den samme ting også i softwareprojekter. Klienter og projektledere vil indføre nye krav, fordi ”Åh, jeg har glemt denne meget vigtige funktionalitet. Det skal være i softwaren, ellers vil det ikke være nyttigt for os ”.

Disse kravændringer kommer normalt under hele projektet. Det er som at tilføje en dam, en mur, en stige osv. I vejen for sprinteren og forvente, at han / hende stadig gør det under 10 sekunder.

4) Arkitektur ikke kontrolleret korrekt

Især når ting ikke gøres fra bunden, og der bruges tredjepartsværktøjer (WordPress, TYPO3, Drupal, Magento, Shopware og mange andre), og de skal tilpasses til at gøre noget særligt, det kan komme til forkerte skøn .

I disse tredjepartsværktøjer kan vi ikke bare ændre alt, hvad vi ønsker. Enkle ting som URL-strukturen eller andre ting skal følges.

Som i punkt 1) i denne tekst er ikke alt let at implementere. Når det først er konstateret, at den nuværende arkitektur i tredjepartssystemet ikke understøtter en bestemt funktionalitet, er det altid bedre at undgå den specifikke funktionalitet og bruge et arbejde, der gør det samme job, men ved hjælp af den eksisterende arkitektur.

Bemærk: Dette problem / problem opstår også, hvis projektet udføres fra bunden med værktøjer som PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js osv. Og nogle indledende, forkerte antagelser blev lavet om systemets arkitektur.

5) “En sætning” eller “et ord” viser stop

Jeg havde allerede nævnt eksemplet på det 5-siders dokument, som leveres af klienten. Når udviklingen er næsten færdig eller i gang, vil klienten sige: ”Der mangler en vigtig funktionalitet. På side 3 på linje 22 nævnes det, at vi har brug for – et rapporteringsværktøj – ”.

Men at bygge dette rapporteringsværktøj, som kun nævnes kort i dokumentet, tager i sig selv det samme beløb som hele projektet. Og fordi “rapporteringsværktøjet” er nævnt i dokumentet, vil kunden selvfølgelig insistere på implementeringen.

6) At vinde projektet

Lad os antage, at du har en fornemmelse af, at mange virksomheder byder på det samme projekt. Nu vil du bestemt ikke være det forslag, der opkræver det højeste antal timer. Du vil være den, der viser det laveste antal timer. Hvis en klient kan vælge mellem 100 timer og 500 timer, vil alle bestemt vælge de 100 timer.

I virkeligheden, i en ideel verden, har alle brug for det samme antal timer. Så selvom 100 timer blev citeret, vil det ende med at blive 500 timer.

7) Ukendte / ventetider

Der er flere ukendte i softwareprojekter:

• a) Teknologiændring: Hvis et af udviklingsværktøjerne (f.eks. Android) får en større opdatering, skal der gøres mere arbejde for at indarbejde disse teknologiske ændringer.
• b) Teammedlemmernes erfaring: Hvis en seniorudvikler arbejder på projektet, vil det tage kortere tid, hvis det er en juniorudvikler, vil det sandsynligvis tage mere tid.
• c) Feedback kommer sent: Kunder er normalt ikke meget interesserede i projektet, de vil have gode resultater. Så når kunden kontaktes under projektet, er de muligvis ikke villige til at give et svar inden for en time. Det kan tage flere dage. I løbet af denne tid vil projektet ligge tomgang, og tjenesteudbyderen kan endda opkræve timer i løbet af den tid, hvis udviklerne sidder inaktive på grund af forsinkelsen i svarene.

8) Projektet er for stort til at kunne estimeres korrekt

Lad os antage, at opgaven er en, der har brug for flere udviklere over en periode på flere måneder.

Det er næsten umuligt at nedbryde opgaverne i så små stykker arbejde for at få det rigtige skøn.

De andre ting, der er nævnt i denne artikel, vil naturligvis også spille en rolle.

Konklusion

Den bedste tilgang er:

• Lav et omtrentligt skøn
• Nævn, at det er bedst at reducere funktionaliteterne, hvis projektet tager for lang tid og tager mange timer (fx lav en prioritetsliste med funktionaliteter, gør kun den vigtigste)
• Brug den smidige metode til udvikling og fakturering

Hvis du ønsker en nøjagtig pris / timer, er det normalt kun muligt i mindre projekter, som varer nogle få uger.

Andre interessante artikler om emnet:
Sådan estimeres softwareudviklingsprojektet i mandlige timer realistisk
Hvorfor softwareudvikling tidsestimering ikke fungerer og alternative fremgangsmåder

Billedkilde: Flickr.com/ Michael Kappel / Judit Klein / Markus Spiske

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.