Hvordan vi estimerer projekter hos JetBase

Alle ved, at nøjagtig estimering af webudviklingsprojekter er vigtig, men spørgsmålet er, hvordan man opnår det. Mit navn er Sergey, og jeg er CTO hos JetBase. Hver dag estimerer jeg hundredvis af projekter, og om torsdagen underviser jeg i en team lead-skole, hvor der er separate lektioner dedikeret til estimering.

I vores bureau har vi udviklet en estimeringsmetode og forfiner den konstant. I dag vil jeg gerne dele mine observationer og erfaringer med alle interesserede. Vær forberedt på virkelige eksempler fra praksis og ikke mindre statistik og tal.

Jeg skriver denne artikel for alle, der er interesserede i emnet, men primært for mine kolleger team leads og også for vores kunder, der dagligt kontakter vores salgsafdeling og anmoder om priser. Nøjagtig projektestimering er afgørende for disse to kategorier af mennesker.

Jeg har ofte oplevet frustrationen hos både nybegyndere inden for teamledelse og kunder. Nyankomne team leads føler sig frustrerede, når de står over for utilstrækkelige kundedata og er bange for at stille yderligere spørgsmål, mens kunderne til gengæld er forvirrede, når de ser visse tal. Begge har brug for perfekt estimering, men er det let at opnå? Lad os finde ud af, hvad den virkelige historie er.

Lad os starte med en historie om en klient, der engang kontaktede os og ønskede at oprette en social platform, der lignede eksisterende og populære streamingapplikationer som Instagram og TikTok. De krav, der blev fremsat, var ret generelle, som det ofte er tilfælde i 95% af situationerne, og som sædvanligt var der ingen omtale af projektets forretningsmål.

Det var ikke svært at gætte, at projektets forretningsmål var annoncesalg. Klientens overordnede ønske var at vide, hvor meget tid og penge det ville tage at nå dette mål. Nå, vi kunne give omtrentlige tal som 3 år og 1 million dollars, men det er slet ikke vores tilgang.

Vores virksomheds mål er at udføre kvalitetsarbejde, og den tekniske teams opgave er ikke kun at give et estimat, men at analysere kravene og skitsere projektets implementering over tid, i sprints og faser.

Vi sigter mod at evaluere de opgaver, der er essentielle for projektet, med fokus på projektets kerne. Gennem årene er det blevet klart for os, at denne tilgang er mere realistisk og praktisk end at give grove estimater og derefter forsøge at passe ind i dem. Desuden er æraen med udvikling af nøglefærdige produkter forbi.

I dag udvikles alle produkter iterativt, og de udvikler sig i miljøet, i rummet.

Tilbage til klienten, der ønskede at oprette en platform som TikTok: For det første mener jeg personligt, at det ikke er den mest pålidelige måde at kopiere andres sti. Fra vores perspektiv foreslår vi ikke at lave et TikTok, med andre ord, slet ikke at nævne det. I stedet foreslår vi at analysere projektet ud fra dets essens, beskrive dets forretningsmål, adressere brugernes smertepunkter og finde ud af, hvordan produktet kan løse brugernes problemer.

Med andre ord, skab en MVP, test den, foretag ændringer. Først da bliver det klart, hvad platformen faktisk vil repræsentere. I sidste ende kan den vise sig at være helt anderledes end TikTok, måske mere som Snapchat.

Nu til sagens kerne – hvordan estimeringsprocessen ser ud hos JetBase. Vi har tidligere skrevet detaljeret om estimering i artiklen "Estimering af softwareudvikling: En omfattende guide".

Her er de tre hovedfaser, estimeringsprocessen består af (der vil være teori, men derefter vil du se det hele i praksis):

Estimeringsfaser:

Fase 1. Indhentning af indledende data fra klienten med wireframes, en brief fra JetBase.io

I denne fase udfører vores team af udviklere, ledet af en team lead, en analyse af projektet, der ikke kun indebærer en forståelse af tekniske aspekter, men også identifikation af projektets kerne. Ofte indebærer dette et forretningsmål. For eksempel kan en klient ønske at oprette en hjemmeside til registrering af konferencedeltagere eller en app med vegetariske opskriftsanbefalinger. I det første tilfælde er målet billetsalg, og i det andet abonnementer.

Fase 2. Oprettelse af projektarkitektur, nedbrydning i underopgaver

Hvis vi i den første fase, der er beskrevet tidligere, ønsker at forstå projektets essens – kernen, så tager vi her, i den anden fase, denne store projektidé og bryder den ned i små dele, samtidig med at vi visualiserer de konstruktive funktioner. Med andre ord dekomponerer vi den store opgave i underopgaver og skaber projektets arkitektur. Denne fase er afgørende og uundgåelig. Der er mange typer af dekomponering i underopgaver, men det taler vi om en anden gang.

Visualisering af projektets arbejdsgang og arkitektur skaber tillid hos alle involverede, især dem, der investerer betydelige midler. Hos JetBase underskriver vi kun kontrakter med vores klienter efter omhyggeligt at have beskrevet projektets arbejdsgange gennem store, mellemstore og små opgaver. Dette sikrer ro i sindet for vores klienter og fremmer en klarere forståelse i vores samarbejde.

Fase 3. Projektestimering efter arbejdsomfang, roller, ansvarsområder og timer.

Her begynder prikken over i'et – den egentlige estimering. I denne fase skal du engagere dit matematiske sind og ikke overse noget vigtigt; hver numerisk værdi påvirker det endelige beløb. Glem samtidig ikke, at projektestimering ikke kun er videnskab, men også kunst, og meget vil afhænge af, hvordan du kan se gennem tallene og tabellerne essensen af det projekt, som alt dette omhyggelige arbejde udføres for.

Man skal selvfølgelig lære af fejl, men i Team Lead Skolen, hvor jeg underviser om tirsdagen, giver jeg under en praktisk lektion et eksempel på præcis estimering. Dette er et virkeligt eksempel fra JetBases portefølje, hvor vi estimerede timer med den største nøjagtighed. Et mirakel? Nej, bare en blanding af videnskab og kunst og en masse omhyggeligt arbejde. Det tog os to uger til denne estimering, og det er en relativt kort tidsramme.

Under analysefasen fandt vi ud af, at projektets kerne er deltagerregistrering til offline spil. Dette blev ikke eksplicit angivet i klientens oprindelige data, men det er afgørende at vide fra starten. Derefter tog vi disse indledende data fra klienten og deres wireframes og brød projektet ned i moduler, der beskriver, hvad der skal gøres på et højteknologisk niveau, for eksempel:

• Opret den indledende applikation
• Forbind database
• Opret projektentiteter
• Konfigurer eksterne tjenester mv.

Dernæst skal hvert modul nedbrydes i funktioner og underfunktioner med en detaljeret beskrivelse for hver på både frontend og backend. Lad os se på et virkeligt eksempel. Her er en side fra det nævnte projekt.

En uerfaren eller uengageret team lead ville måske estimere denne side groft og, lad os sige, afsætte 8 timers arbejde. Man kan forstå deres perspektiv, da klienter ofte henvender sig til udviklere for at få et hurtigt og endeligt projektbeløb og er tilbageholdende med at vente i længere tid.

Men hos JetBase følger vi ikke den tilgang. Vi investerer mere tid i estimering, men vi opnår et mere præcist resultat. Her er, hvordan vores estimering for den nævnte side ser ud:

Sagen er, at for fremtidige projektspecialister er estimering af underfunktioner meget enklere, da det er en teknisk klar og forståelig opgave, som team leaden identificerer under estimeringsfasen. Det er her hemmeligheden bag præcis estimering ligger – i omhyggelig dekomponering.

Og hvis du fortsætter med at dekomponere hvert modul som i eksemplet med den side, der er diskuteret ovenfor, og derefter beregner alle risici og relaterede opgaver, er resultatet en ren og pålidelig estimering.

Nedenfor vil jeg give et eksempel på en dårlig estimering, og for at afslutte hele historien om god estimering kan jeg sige, at det ikke er så svært at opnå det såkaldte ideal eller renhed. Det er fuldt ud muligt og endda nødvendigt for alle deltagere i processen. Som Steve McConnell sagde i sin bog "Software Estimation: Demystifying the Black Art":

"Et godt estimat er et estimat, der giver et tilstrækkeligt klart billede af projektets virkelighed til at give projektledelsen mulighed for at træffe gode beslutninger om, hvordan projektet skal styres for at nå sine mål."

Før vi nåede det nuværende niveau af estimeringsekspertise hos JetBase, begik vi fejl. Vi lærte at forbedre os fra dem, og heldigvis var der ikke for mange. Nu vil jeg kort nævne et eksempel på dårlig estimering, så du forstår, hvor risiciene er skjult, og hvorfor det er en trist historie for både teamet og klienten.

Baggrund:

Engang henvendte en klient sig til os for at skabe en online læringsportal for skuespillere og professionelle i filmbranchen. Der var meget få data tilgængelige i starten, men vi estimerede alligevel projektet, hvilket resulterede i et fast samlet estimat.

Resultat:

Som jeg nævnte tidligere, gav vi en fast pris for projektet. I virkeligheden endte vi dog med at overskride det estimerede budget, fordi det blev tydeligt, at der var brug for mere tid til arbejdet. Selvom vores klient ikke protesterede mod dette, opstod problemet, da de ikke foretog nogen betalinger for arbejdsfaserne (sprints), hvilket gjorde det muligt for dem at afvise projektet fuldstændigt til sidst.

Følgelig måtte vi lave hele projektet om, hvilket krævede dobbelt så stor indsats, men vi blev ikke kompenseret for vores arbejde. Vi arbejdede uden betaling for at beskytte vores omdømme, mens vores klient mistede deres dyrebare tid og blev skuffet over deres erfaring med webudvikling. Fejl bør kompenseres.

Hvor fejlene var begravet:

• Klienten fremlagde utilstrækkelige data i starten.
• Vi brugte ikke agile metoder.
• Klienten betalte ikke for arbejdsfaser, så var ikke involveret i midlertidige resultater.
• Vi gav en fast pris i stedet for at estimere sprints (vi kunne have brugt den nøjagtige estimeringsmetode beskrevet tidligere).

Med hensyn til de to eksempler på estimering, der er givet ovenfor, er det tydeligt, at visse strategier og praksisser er afgørende for en nøjagtig estimering inden for webudvikling.

Fra disse tilfælde fremgår flere centrale konklusioner:

• Estimering med fast pris bør undgås, da det ofte ikke afspejler produktets faktiske behov nøjagtigt.
• Kunders anmodninger stemmer ofte heller ikke overens med projektets virkelighed.
• Flere inputdata i starten fører til bedre estimeringsnøjagtighed.
• Jo mere omhyggelig opdelingen af opgaverne er, jo mere nøjagtig vil estimeringen være.
• Effektiv kommunikation, såsom at involvere kunder i regelmæssige demo-overblik og planlægningsmøder, er afgørende for informeret beslutningstagning og effektiv produktudvikling.

Derudover vil jeg understrege, at problemet med nøjagtig estimering og generelt eventuelle tekniske problemer ikke kun er tekniske problemer, som IT-sektoren skal bekymre sig om. Kunder og virksomheder skal også involveres; så vil der være mere grønt lys for omhyggelige estimater, hvilket fører til gensidig fordel og mindre efterspørgsel efter klodsede fastpristilgange.

Jeg håber, at min artikel var nyttig for både IT-fagfolk og interessenter, der leder efter et webudviklingsteam. Du er velkommen til at kontakte os, hvis du har brug for en projektestimering – vi vil gøre vores bedste for at skræddersy den til dine specifikke behov.

Kilde: Virksomheders 'det er ikke mit problem' IT-problem.