Hvordan vi estimerer prosjekter hos JetBase

Alle vet at nøyaktig estimering av webutviklingsprosjekter er viktig, men spørsmålet er hvordan man oppnår det. Mitt navn er Sergey, og jeg er CTO i JetBase. Hver dag estimerer jeg hundrevis av prosjekter, og på torsdager holder jeg en teamleder-skole, hvor det er egne leksjoner dedikert til estimering.

I vårt byrå har vi utviklet en metodikk for estimering og forfiner den hele tiden. I dag vil jeg gjerne dele mine observasjoner og erfaringer med alle interesserte. Vær forberedt på reelle eksempler fra praksis og ikke minst statistikk og tall.

Jeg skriver denne artikkelen for alle som er interessert i emnet, men primært for mine teamlederkolleger og også for våre kunder som kontakter vår salgsavdeling daglig og ber om priser. Nøyaktig prosjektestimering er avgjørende for disse to kategoriene mennesker.

Jeg har ofte møtt frustrasjonen hos både nybegynnere innen teamledelse og kunder. Nybegynner-teamledere blir frustrerte når de står overfor utilstrekkelige kundedata og er redde for å stille flere spørsmål, mens kundene på sin side blir forvirret når de ser visse tall. Begge trenger perfekt estimering, men er det lett å oppnå? La oss finne ut hva den virkelige historien er.

La oss starte med en historie om en kunde som en gang kontaktet oss og ønsket å lage en sosial plattform lik eksisterende og populære strømmeapplikasjoner som Instagram og TikTok. Kravene som ble gitt, var ganske generelle, slik det ofte er i 95 % av situasjonene, og som vanlig var det ingen omtale av prosjektets forretningsmål.

Det var ikke vanskelig å gjette at prosjektets forretningsmål var annonsesalg. Kundens overordnede ønske var å vite hvor mye tid og penger det ville ta å nå dette målet. Vel, vi kunne gitt omtrentlige tall som 3 år og 1 million dollar, men det er slett ikke vår tilnærming.

Vårt selskaps mål er å levere kvalitetsarbeid, og målet for det tekniske teamet er ikke bare å gi et estimat, men å analysere kravene og skissere prosjektets implementering over tid, i sprinter og faser.

Vi ønsker å evaluere oppgavene som er essensielle for prosjektet, og konsentrere oss om kjernen i prosjektet. Gjennom årene har det blitt klart for oss at denne tilnærmingen er mer realistisk og praktisk enn å gi grove estimater og deretter prøve å passe inn i dem. Dessuten er æraen med nøkkelferdige produktutviklinger forbi.

I dag utvikles alle produkter iterativt, og de utvikler seg i miljøet, i rommet.

Tilbake til kunden som ønsket å lage en plattform som TikTok: For det første mener jeg personlig at det å kopiere andres vei ikke er den mest pålitelige måten. Fra vårt perspektiv foreslår vi å ikke lage en TikTok, med andre ord, ikke nevne det i det hele tatt. I stedet foreslår vi å analysere prosjektet basert på dets kjerne, beskrive dets forretningsmål, adressere brukernes smertepunkter og finne ut hvordan produktet kan løse brukernes problemer.

Med andre ord, lag en MVP, test den, gjør endringer. Først da vil det bli klart hva plattformen faktisk vil representere. Til syvende og sist kan det vise seg å være helt annerledes enn TikTok, kanskje mer som Snapchat.

Nå, la oss komme til kjernen – hvordan estimeringsprosessen ser ut hos JetBase. Vi har tidligere skrevet detaljert om estimering i artikkelen "Estimering av programvareutvikling: En omfattende guide".

Her er de tre hovedstadiene estimeringsprosessen består av (det vil være teori, men etterpå vil du se alt i praksis):

Estimeringsstadier:

Trinn 1. Innhenting av innledende data fra kunden med wireframes, en brief fra JetBase.io

På dette stadiet utfører vårt utviklerteam, ledet av en teamleder, en analyse av prosjektet, som ikke bare innebærer å forstå tekniske aspekter, men også å identifisere prosjektets kjerne. Ofte innebærer dette et forretningsmål. For eksempel kan en kunde ønske å lage en nettside for konferansedeltakerregistrering eller en app med anbefalinger for vegetariske oppskrifter. I det første tilfellet er målet billettsalg, og i det andre, abonnementssalg.

Trinn 2. Skape prosjektarkitekturen, bryte den ned i deloppgaver

Hvis vi i det første stadiet beskrevet tidligere ønsker å forstå prosjektets kjerne – essensen, så tar vi her, på det andre stadiet, denne store prosjektideen og bryter den ned i små deler, samtidig som vi visualiserer de konstruktive funksjonene. Med andre ord dekomponerer vi den store oppgaven til deloppgaver og skaper prosjektets arkitektur. Dette stadiet er avgjørende og uunngåelig. Det finnes mange typer dekomponering til deloppgaver, men det snakker vi om en annen gang.

Visualisering av prosjektets arbeidsflyt og arkitektur skaper tillit hos alle involverte, spesielt de som investerer betydelige midler. Hos JetBase signerer vi kontrakter med våre kunder først etter at vi omhyggelig har skissert prosjektets arbeidsflyt gjennom store, mellomstore og små oppgaver. Dette sikrer ro i sinnet for våre kunder og fremmer en klarere forståelse i vårt samarbeid.

Trinn 3. Prosjektestimering etter omfang, roller, ansvar og timer.

Her begynner prikken over i-en – selve estimeringen. På dette stadiet må du engasjere din matematiske hjerne og ikke gå glipp av noe viktig; hver numerisk verdi påvirker det endelige beløpet. Samtidig må du ikke glemme at prosjektestimering ikke bare er vitenskap, men også kunst, og mye vil avhenge av hvordan du kan se gjennom tallene og tabellene kjernen i prosjektet som alt dette nitidige arbeidet gjøres for.

Man må selvsagt lære av feil, men på Teamleder-skolen, hvor jeg underviser på tirsdager, gir jeg et eksempel på presis estimering under en praktisk leksjon. Dette er et reelt eksempel fra JetBase sin portefølje, hvor vi estimerte timer med ytterste nøyaktighet. Et mirakel? Nei, bare en blanding av vitenskap og kunst og mye nitid arbeid. Det tok oss to uker for denne estimeringen, og det er en relativt kort tidsramme.

Under analysestadiet fant vi ut at prosjektets kjerne er deltakerregistrering for offline-spill. Dette var ikke eksplisitt angitt i kundens innledende data, men det er avgjørende å vite fra starten. Deretter tok vi disse innledende dataene fra kunden og deres wireframes, og brøt prosjektet ned i moduler som beskriver hva som må gjøres på et høyteknologisk nivå, for eksempel:

• Opprette den første applikasjonen
• Koble til database
• Opprette prosjektentiteter
• Sette opp konfigurasjon for eksterne tjenester osv.

Deretter må hver modul brytes ned i funksjoner og delfunksjoner med en detaljert beskrivelse for hver på både frontend og backend. La oss se på et reelt eksempel. Her er en side fra det nevnte prosjektet.

En uerfaren eller uengasjert teamleder kan grovt estimere denne siden og for eksempel tildele 8 timers arbeid. Man kan forstå deres perspektiv, da kunder ofte henvender seg til utviklere for et raskt og endelig prosjekttall og er motvillige til å vente lenge.

Men hos JetBase følger vi ikke den tilnærmingen. Vi investerer mer tid i estimering, men oppnår et mer nøyaktig resultat. Slik ser vår estimering for den nevnte siden ut:

Saken er at for fremtidige prosjektspesialister er estimering av delfunksjoner mye enklere, siden det er en teknisk klar og forståelig oppgave som teamlederen identifiserer under estimeringsstadiet. Det er her hemmeligheten bak presis estimering ligger – i nitid dekomponering.

Og hvis du fortsetter å dekomponere hver modul som i eksemplet med siden diskutert ovenfor, og deretter beregne alle risikoer og relaterte oppgaver, blir resultatet et rent og pålitelig estimat.

Nedenfor vil jeg gi et eksempel på en dårlig estimering, og for å avslutte hele historien om god estimering kan jeg si at det ikke er så vanskelig å oppnå det såkalte idealet eller renheten. Det er fullt mulig og til og med nødvendig for alle deltakere i prosessen. Som Steve McConnell sa i sin bok "Programvareestimering: Avmystifisering av den svarte kunsten":

"Et godt estimat er et estimat som gir en klar nok oversikt over prosjektets virkelighet til å gjøre det mulig for prosjektledelsen å ta gode beslutninger om hvordan prosjektet skal kontrolleres for å nå sine mål."

Før vi nådde det nåværende nivået av estimeringsekspertise hos JetBase, gjorde vi feil. Vi lærte å forbedre oss fra dem, og heldigvis var det ikke for mange. Nå skal jeg kort nevne et eksempel på dårlig estimering, slik at du forstår hvor risikoene er skjult og hvorfor det er en trist historie for både teamet og kunden.

Bakgrunn:

En gang kontaktet en klient oss for å lage en online læringsportal for skuespillere og fagfolk i filmbransjen. Det var svært lite data tilgjengelig i utgangspunktet, men vi estimerte likevel prosjektet, noe som resulterte i et fast totalestimat.

Resultat:

Som jeg nevnte tidligere, ga vi en fast pris for prosjektet. I realiteten endte vi imidlertid opp med å overskride det estimerte budsjettet fordi det ble klart at mer tid var nødvendig for arbeidet. Selv om vår klient ikke protesterte mot dette, oppsto problemet da de ikke foretok noen betalinger for arbeidsstadiene (sprintene), noe som gjorde at de kunne avvise prosjektet fullstendig til slutt.

Følgelig måtte vi gjøre hele prosjektet på nytt, noe som krevde dobbel innsats, men vi ble likevel ikke kompensert for arbeidet vårt. Vi jobbet uten betaling for å ivareta vårt omdømme, mens vår klient mistet verdifull tid og ble skuffet over sin erfaring med webutvikling. Feil bør kompenseres.

Hvor feilene var begravet:

• Kunden ga utilstrekkelige data i starten.
• Vi brukte ikke smidige metoder.
• Kunden betalte ikke for arbeidsstadiene, og var dermed ikke involvert i midlertidige resultater.
• Vi ga en fast pris i stedet for å estimere sprinter (vi kunne ha brukt den nøyaktige estimeringsmetoden beskrevet tidligere).

Med hensyn til de to estimeringseksemplene ovenfor er det tydelig at visse strategier og praksiser er avgjørende for nøyaktig estimering innen webutvikling.

Fra disse tilfellene kommer flere viktige konklusjoner frem:

• Fastprisestimering bør unngås, da det ofte ikke nøyaktig gjenspeiler produktets faktiske behov.
• Kundenes forespørsler stemmer ofte heller ikke overens med prosjektets realitet.
• Flere inndata i starten fører til bedre estimeringsnøyaktighet.
• Jo mer nitid oppgavedekomponeringen er, desto mer nøyaktig blir estimatet.
• Effektiv kommunikasjon, som å involvere kunder i regelmessige demo-gjennomganger og planleggingsmøter, er avgjørende for informert beslutningstaking og effektiv produktutvikling.

I tillegg ønsker jeg å understreke at problemet med nøyaktig estimering og, generelt, eventuelle tekniske problemer ikke bare er tekniske problemer som IT-sektoren bør bekymre seg for. Kunder og bedrifter må også involveres; da vil det være mer grønt lys for nitidige estimater, noe som fører til gjensidig nytte og mindre etterspørsel etter klønete fastpris-tilnærminger.

Jeg håper artikkelen min var nyttig for både IT-fagfolk og interessenter som leter etter et webutviklingsteam. Du er velkommen til å kontakte oss hvis du trenger et prosjektestimat – vi vil gjøre vårt beste for å tilpasse det til dine spesifikke behov.

Kilde: Bedriftens ‘Det er ikke mitt problem’ IT-problem.