Hvorfor er beregninger av programvareutviklingsoppgaver regelmessig av en faktor 2-3?

Hvorfor er beregninger av programvareutviklingsoppgaver regelmessig av en faktor 2-3?

Dette er et svar på Quora-spørsmålet: Hvorfor er estimater ikke eksakte?

Det er flere faktorer for dette. Her er noen vanlige:

1) Kunden er ikke-teknisk og føler at «alt er enkelt»

Å utvikle en programvare er ikke så lett som det ser ut.

Selv om det ser enkelt ut, er det noen ganger bedre å utelate visse oppgaver.

• For å ta en analogi:

Det er en enorm bakke, og vi må bygge et jernbanespor. Utviklerne vil gi råd: “Bedre unngå åsen og bygg banen rundt bakken. På denne måten sparer vi 5 måneders ekstra arbeid ”.

Her vil det være åpenbart at det vil mye mer tid å bore en tunnel gjennom bakken, og klienten vil godta «arbeidet rundt».

• La oss nå se på programvareutvikling:

Utvikleren sier: ”Det ville være bedre å bare ha en mobilversjon med en skjermstørrelse og en stasjonær versjon med én skjermstørrelse. Vi bør unngå å ha en mobilapp og også unngå en fullstendig responsiv design, fordi det ikke vil se bra ut ”.

Her vil klienten sannsynligvis si: “Hvorfor? Andre nettsteder er også responsive og kan endres til alle skjermstørrelser. Det er en enkel oppgave. ”

Men: Det kan være flere og gode grunner til at utvikleren har antydet dette. Kanskje et responsivt design ikke vil se bra ut eller profesjonelt. Spesielt noen knapper kan lett ondartes, etc. etc.
Så hva som nå vil skje er at utvikleren vil 1) bygge siden responsiv og 2) vil øke timene.

• For timeforhøyelsen vil klienten ikke akseptere: “Hvorfor flere timer? Det er lett, ikke sant? «
• Når oppgaven er fullført, vil klienten se på nettstedet med mobilen og si: “Alt er feiljustert når jeg sjekker siden på mobil. Hvorfor? Jeg betalte mye mer og nå dette? ”.

Hadde klienten sagt ja til tidligere måte å gjøre det på (ikke-responsivt, med bare to versjoner), ville nettstedet vært billigere (mindre timer), og det ville være helt greit på nesten alle mobilskjermbilder og stasjonære nettlesere.

Hovedproblemet her er også: Det er ikke bra å krangle med noen. Spesielt å krangle med klienten er ikke en god idé. Så utvikleren / tjenesteleverandøren vil alltid si «Ja, du har rett, la oss gjøre det på den måten».

Og når klienten ikke er veldig fornøyd, bør utvikleren igjen ta skylden (selv om han / hun vet at det ikke var hans skyld, men at kravet var på en slik måte).

2) Det er ikke mulig å ta lang tid på å estimere nøyaktig

I den virkelige verden vil et programvareselskap motta forespørsler om programvare hver dag eller ukentlig.

Hvis hver forespørsel ble estimert nøyaktig, ville utviklerne ikke ha annet å gjøre, enn å lage nøyaktige estimater. De ville ikke være i stand til å jobbe med virkelige prosjekter, fordi det er veldig tidkrevende å lage de nøyaktige estimatene.

Så hva som faktisk skjer er: De vil se på prosjektet og «estimere» tiden det trengs. At det er grunnen til at det kalles et «estimat», fordi det ikke er nøyaktig.

Også: Kunden selv er ikke interessert i å vente i en eller flere uker med å spesifisere kravet. På det meste blir det laget et 5-siders dokument, og det vil være grunnlaget for utviklingen.

3) Hvert krav endres i løpet av prosjektet

Jeg liker å sitere Andrew Rose fra Quora-tråden / lenken fra begynnelsen av denne artikkelen:

”Uansett hvor stort eller lite et prosjekt er, vil det alltid være noe som dukker opp etter at du har startet prosjektet. Mer sannsynlig vil mange ting komme opp. Det er bare dyrets natur. Som produktsjef er jobben din å samarbeide med kundene dine for å finne på det de trenger og er villige til å betale for. Du må også finne på det du med rimelighet kan levere med hjelp fra utviklerne dine. Når du jobber for å tilfredsstille disse målene, får du endringer i omfang, feil tidsestimater, og noen ganger endringer i menneskene som jobber med å fullføre prosjektet. «

Mange ting endrer seg i løpet av prosjektet. Som Andrew nevnte, vil ikke bare kravene endres. Selv folk kan gå inn i andre prosjekter før prosjektet er ferdig.

Her en analogi:

En 100 meter sprinter trener i 10 år for å løpe 100 meter på under 10 sekunder.

På sprintdagen, sier klienten, trenger vi også 5 hindringer underveis.

Da vil sprinteren si, «men da vil jeg ikke kunne kjøre den under 10 sekunder», og klienten vil si «for hva trente du de siste 10 årene, vennligst gjør det under 10 sekunder».

Det samme også i programvareprosjekter. Klienter og prosjektledere vil innføre nye krav fordi “Å, jeg glemte denne veldig viktige funksjonaliteten. Det må være i programvaren, ellers vil det ikke være nyttig for oss ”.

Disse kravendringene kommer vanligvis i løpet av hele prosjektet. Det er som å legge til en dam, en vegg, en stige osv., I veien for sprinteren, og forventer at han / hun fortsatt vil gjøre det under 10 sekunder.

4) Arkitektur ikke sjekket ordentlig

Spesielt når ting ikke blir gjort fra bunnen av og tredjepartsverktøy (WordPress, TYPO3, Drupal, Magento, Shopware og mange andre) brukes, og de bør tilpasses for å gjøre noe spesielt det kan komme til feil estimater .

I disse tredjepartsverktøyene kan vi ikke bare endre alt vi ønsker. Enkle ting som URL-strukturen eller andre ting må følges.

Som i punkt 1) i denne teksten er ikke alt lett å implementere. Når det er funnet ut at den nåværende arkitekturen til tredjepartssystemet ikke støtter en spesifikk funksjonalitet, er det alltid bedre å unngå den spesifikke funksjonaliteten og bruke et arbeid som gjør den samme jobben, men ved å bruke den eksisterende arkitekturen.

Merk: Dette problemet / problemet vil også oppstå hvis prosjektet gjøres fra bunnen av med verktøy som PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js, etc. og noen innledende, gale antakelser ble laget om systemets arkitektur.

5) «En setning» eller «ett ord» viser stopper

Jeg hadde allerede nevnt eksemplet på 5-siders dokumentet, som blir levert av klienten. Når utviklingen nesten er ferdig eller i gang, vil klienten si: ”Det mangler en viktig funksjonalitet. På side 3 på linje 22 nevnes det at vi trenger – et rapporteringsverktøy – ”.

Men å bygge dette rapporteringsverktøyet, som bare nevnes kort tid i dokumentet, vil i seg selv ta like mye som hele prosjektet. Og fordi «rapporteringsverktøyet» er nevnt i dokumentet, vil klienten selvfølgelig insistere på implementeringen.

6) Vinne prosjektet

La oss anta at du har følelsen av at mange selskaper byr på det samme prosjektet. Nå vil du definitivt ikke være forslaget som tar høyest antall timer. Du vil være den som viser det laveste antall timer. Hvis en klient kan velge mellom 100 timer og 500 timer, vil definitivt alle velge de 100 timene.

I virkeligheten, i en ideell verden, trenger alle like mange timer. Så selv om 100 timer ble sitert, vil det ende opp med å være 500 timer.

7) Ukjente / ventetider

Det er flere ukjente i programvareprosjekter:

• a) Teknologiendring: Hvis et av utviklingsverktøyene (f.eks. Android) får en større oppdatering, må det gjøres mer arbeid for å innlemme disse teknologiske endringene.
• b) Teammedlemmers erfaring: Hvis en seniorutvikler jobber med prosjektet, vil det ta kortere tid, hvis det er en juniorutvikler, vil det sannsynligvis ta mer tid.
• c) Tilbakemelding kommer sent: Klienter er vanligvis ikke så mye interessert i prosjektet, de vil ha gode resultater. Så når klienten blir kontaktet under prosjektet, er de kanskje ikke villige til å gi svar innen en time. Det kan ta flere dager. I løpet av den tiden vil prosjektet ligge inaktiv, og tjenesteleverandøren kan til og med lade timer i løpet av den tiden, hvis utviklerne sitter inaktiv på grunn av forsinkelsen i svarene.

8) Prosjektet er for stort til å bli estimert riktig

La oss anta at oppgaven er en, som trenger flere utviklere over en periode på flere måneder.

Det er nesten umulig å bryte ned oppgavene i slike små biter av arbeid, for å få riktig estimat.

De andre tingene som er nevnt i denne artikkelen vil selvfølgelig også spille en rolle.

Konklusjon

Den beste tilnærmingen er:

• Gjør et omtrentlig estimat
• Nevn at det er best å redusere funksjonalitetene, hvis prosjektet tar for lang tid og tar mange timer (f.eks. Lag en prioritert liste over funksjonaliteter, gjør bare den viktigste)
• Bruk den smidige metoden for utvikling og fakturering

Hvis du vil ha en nøyaktig pris / timer, er det vanligvis bare mulig i mindre prosjekter, som vil vare noen uker.

Andre interessante artikler om emnet:
Hvordan estimere programvareutviklingsprosjekt i arbeidstimer realistisk
Hvorfor tidsutvikling for programvareutvikling ikke fungerer og alternative tilnærminger

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

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.