Vanlige feil utviklere gjør når de estimerer tider

Estimeringstider er relativt til hvert utviklingsteam og hver utvikler individuelt. Det er mange faktorer som påvirker disse estimatene, og hvis de ikke tar hensyn til dem, vil de føre til en forsikringskatastrofe i det prosjektet og de vi har på vent.
La oss se de vanlige feilene som utviklere gjør når de estimerer tider i utviklingsprosjekter, for å unngå dem og gjøre et estimat så nær det ideelle scenariet.

Tillitsinstinkt

Estimatene er på en bestemt måte ledsaget av instinkt, som kan foredles med erfaring, og dette er greit for en moden utvikler, men det er ikke det nærmeste anslagene er gjort på en objektiv og effektiv måte.
For dette er det best at vi ser på antall relaterte og vellykkede implementerte prosjekter, på denne måten kan vi få beregninger på hvor lang tid det tok oss med hver av disse og deretter kompilere disse tallene i en rapport.
Det er en praksis som vil ta oss litt lengre tid, men det vil hjelpe oss på to ting; først for å gi et mer nøyaktig estimat basert på tidligere prosjekter og for det andre for å sjekke hvor nøyaktige instinktene våre er.

Ikke spør

Det er en veldig spesiell setning som mange utviklere vil føle seg identifisert med:

 "Hei, jeg trenger et raskt estimat for en innholdsmodul."

Det er i det øyeblikket vi må ta et skritt tilbake og stille oss selv følgende spørsmål:

• Hvilke funksjoner vil den ha?
• Hva blir omfanget, vil det være relatert til andre moduler?
• Mangler det informasjon?
• Trenger jeg å vite noe annet?

Dette er bare noen få, men det er ingen måte at med en så vag idé som at vi kan gjøre et pålitelig estimat, er det derfor vår plikt er å undersøke, stille spørsmål, og at vi ikke er i tvil om det kravet. tid vi kan gi et estimat, resten vil vi bare gjette og bruke magi til å estimere tidspunktene for det samme.

Mentale og kollektive grenser

Dette er noe ganske vanlig og refererer til flere faktorer som indirekte involverer mennesker i miljøet vårt. Vår overordnede ser kravet og kan si det "Det ser ganske greit ut, det skal ikke ta lang tid å implementere det", som vil få oss til å se det optimistisk. Det kan også være slik at en gruppe utviklere er tilstede og det gjøres et gruppeanslag.
Problemet er at de er det "deres" estimater og ikke våre, som estimatet for disse tider vanligvis alltid er nærmere enn det egentlig burde være.

Bli revet med av tidspress

Et konsekvent og pålitelig estimat tar tid, det gjøres ikke i 10 minutter. En klient eller overordnet ønsker kanskje et estimat umiddelbart som er umulig, med mindre det er et veldig lite krav som har et veldefinert omfang.
Hvis vi legger til at vi kan ha et omfattende antall oppgaver som trenger umiddelbar oppmerksomhet, vil våre instinkter fortelle oss at vi ikke kan kaste bort tid på dette estimatet, så det vil være alt annet enn nøyaktig.
Avslutning
Vi har sett de vanligste feilene du gjør i tidsestimater, men hva med løsninger? Det er så enkelt som å endre paradigmene og vite hvordan man skal si nei, på en vedvarende måte og la våre overordnede vite at det er bedre å miste en halv ettermiddag eller til og med en dag med et nøyaktig og pålitelig estimat enn uker eller måneder til har tatt feil vei. Ved å løse denne oppgaven kan du dømme et prosjekt allerede før det har startet.