Så här uppskattar vi projekt på JetBase

Alla vet att korrekt uppskattning av webbutvecklingsprojekt är viktigt, men frågan är hur man uppnår det. Jag heter Sergey och jag är CTO på JetBase. Varje dag uppskattar jag hundratals projekt, och på torsdagar håller jag en teamledarskola, där det finns separata lektioner dedikerade till uppskattning.

På vår byrå har vi utvecklat en metodik för uppskattning och förfinar den ständigt. Idag skulle jag vilja dela mina observationer och erfarenheter med alla intresserade. Var beredd på verkliga exempel från praktiken och inte mindre statistik och siffror.

Jag skriver den här artikeln för alla som är intresserade av ämnet, men främst för mina kollegor teamledare och även för våra kunder som kontaktar vår säljavdelning dagligen och frågar efter priser. Korrekt projektuppskattning är avgörande för dessa två kategorier av människor.

Jag har ofta stött på frustrationen hos både nybörjare inom teamledning och kunder. Nya teamledare känner sig frustrerade när de ställs inför otillräcklig kunddata och är rädda för att ställa ytterligare frågor, medan kunder i sin tur blir förbryllade när de ser vissa siffror. Båda behöver perfekt uppskattning, men är det lätt att uppnå? Låt oss ta reda på vad den verkliga historien är.

Låt oss börja med en historia om en kund som en gång kontaktade oss och ville skapa en social plattform liknande befintliga och populära streamingapplikationer som Instagram och TikTok. De angivna kraven var ganska allmänna, som så ofta är fallet i 95% av situationerna, och som vanligt nämndes inga affärsmål för projektet.

Det var inte svårt att gissa att projektets affärsmål var reklamförsäljning. Kundens övergripande önskan var att veta hur mycket tid och pengar det skulle ta att uppnå detta mål. Visst, vi kunde ge ungefärliga siffror som 3 år och 1 miljon dollar, men det är inte alls vår approach.

Vårt företags mål är att utföra kvalitetsarbete, och det tekniska teamets syfte är inte bara att ge en uppskattning, utan att analysera kraven och att skissera projektets genomförande över tid, i sprintar och steg.

Vi strävar efter att utvärdera de uppgifter som är väsentliga för projektet, med fokus på projektets kärna. Under åren har det blivit tydligt för oss att denna approach är mer realistisk och praktisk än att ge grova uppskattningar och sedan försöka passa in i dem. Dessutom har eran med nyckelfärdig produktutveckling passerat.

Nuförtiden utvecklas alla produkter iterativt, de utvecklas i miljön, i rummet.

Återgår vi till kunden som ville skapa en plattform liknande TikTok, så anser jag personligen att det inte är den mest pålitliga vägen att kopiera någon annans väg. Från vårt perspektiv föreslår vi att inte göra en TikTok, med andra ord, att inte nämna det alls. Istället föreslår vi att analysera projektet utifrån dess kärna, beskriva dess affärsmål, adressera användarnas smärtpunkter och ta reda på hur produkten kan lösa användarens problem.

Med andra ord, skapa en MVP, testa den, gör ändringar. Först då blir det tydligt vad plattformen faktiskt kommer att representera. I slutändan kan det visa sig vara helt annorlunda från TikTok, kanske mer som Snapchat.

Nu till saken – hur uppskattningsprocessen ser ut på JetBase. Vi har tidigare skrivit i detalj om uppskattning i artikeln “Uppskattning av mjukvaruutveckling: En omfattande guide”.

Här är de tre huvudstegen som uppskattningsprocessen består av (det kommer att finnas teori, men efter det kommer du att se allt i praktiken):

Uppskattningssteg:

Steg 1. Få initial data från kunden med wireframes, en brief från JetBase.io

I detta skede utför vårt utvecklingsteam, ledd av en teamledare, en analys av projektet, vilket innebär inte bara att förstå tekniska aspekter utan också att identifiera projektets kärna. Ofta innebär detta ett affärsmål. Till exempel kan en kund vilja skapa en webbplats för registrering av konferensdeltagare eller en app med rekommendationer för vegetariska recept. I det första fallet är målet biljettförsäljning, och i det andra, prenumerationsförsäljning.

Steg 2. Skapa projektarkitekturen, dela upp den i deluppgifter

Om vi i det första steget, som beskrevs tidigare, vill förstå projektets kärna – den centrala idén – så tar vi här, i det andra steget, denna stora projektidé och bryter ner den i små delar, samtidigt som vi visualiserar de konstruktiva funktionerna. Med andra ord, vi dekomponerar den stora uppgiften i deluppgifter och skapar projektets arkitektur. Detta steg är avgörande och oundvikligt. Det finns många typer av dekomponering i deluppgifter, men det pratar vi om en annan gång.

Att visualisera projektets arbetsflöde och arkitektur ingjuter förtroende hos alla inblandade, särskilt de som investerar betydande medel. På JetBase undertecknar vi kontrakt med våra kunder först efter att noggrant ha skisserat projektets arbetsflöden genom stora, medelstora och små uppgifter. Detta säkerställer lugn för våra kunder och främjar en tydligare förståelse i vårt samarbete.

Steg 3. Projektuppskattning efter arbetsomfattning, roller, ansvar och timmar.

Här börjar det riktiga arbetet – själva uppskattningen. I detta skede måste du aktivera ditt matematiska sinne och inte missa något viktigt; varje numeriskt värde påverkar det slutliga beloppet. Glöm samtidigt inte att projektuppskattning inte bara är vetenskap utan också konst, och mycket kommer att bero på hur du kan se igenom siffrorna och tabellerna projektets kärna, för vilken allt detta noggranna arbete utförs.

Visst måste man lära sig av misstag, men i Teamledarskolan, där jag undervisar på tisdagar, ger jag under en praktisk lektion ett exempel på precis uppskattning. Detta är ett verkligt exempel från JetBase portfölj, där vi uppskattade timmar med yttersta noggrannhet. Ett mirakel? Nej, bara en blandning av vetenskap och konst och mycket noggrant arbete. Det tog oss två veckor för denna uppskattning, och det är en relativt kort tidsram.

Under analysfasen fann vi att projektets kärna är deltagarregistrering för offline-spel. Detta angavs inte explicit i kundens initiala data, men det är avgörande att veta från början. Sedan tog vi dessa initiala data från kunden och deras wireframes, och bröt ner projektet i moduler som beskriver vad som behöver göras på en hög teknisk nivå, till exempel:

• Skapa den initiala applikationen
• Anslut databasen
• Skapa projektentiteter
• Konfigurera externa tjänster etc.

Därefter måste varje modul delas upp i funktioner och underfunktioner med en detaljerad beskrivning för varje på både frontend och backend. Låt oss titta på ett verkligt exempel. Här är en sida från det nämnda projektet.

En oerfaren eller oengagerad teamledare kan uppskatta denna sida grovt och, låt oss säga, tilldela 8 timmars arbete. Man kan förstå deras perspektiv, eftersom kunder ofta kontaktar utvecklare för en snabb och slutgiltig projektsiffra och är ovilliga att vänta under en längre period.

Men på JetBase följer vi inte den approachen. Vi investerar mer tid i uppskattning, men vi uppnår ett mer exakt resultat. Så här ser vår uppskattning för den nämnda sidan ut:

Saken är den att för framtida projektspecialister är det mycket enklare att uppskatta underfunktioner, eftersom det är en tekniskt tydlig och förståelig uppgift som teamledaren identifierar under uppskattningsskedet. Det är här hemligheten med precis uppskattning ligger – i noggrann dekomponering.

Och om du fortsätter att dela upp varje modul som i exemplet med sidan som diskuterats ovan, och sedan beräknar alla risker och relaterade uppgifter, blir resultatet en ren och pålitlig uppskattning.

Nedan kommer jag att ge ett exempel på en dålig uppskattning, och för att avsluta hela berättelsen om god uppskattning kan jag säga att det inte är så svårt att uppnå den så kallade idealiska eller renheten. Det är helt möjligt och till och med nödvändigt för alla deltagare i processen. Som Steve McConnell sa i sin bok "Software Estimation: Demystifying the Black Art":

"En bra uppskattning är en uppskattning som ger en tillräckligt tydlig bild av projektets verklighet för att projektledningen ska kunna fatta goda beslut om hur projektet ska kontrolleras för att nå sina mål."

Innan vi nådde den nuvarande nivån av uppskattningskompetens på JetBase gjorde vi misstag. Vi lärde oss att förbättra oss från dem, och lyckligtvis var det inte för många. Nu kommer jag kort att nämna ett exempel på dålig uppskattning, så att du förstår var riskerna är dolda och varför det är en sorglig historia för både teamet och kunden.

Bakgrund:

En gång kontaktade en kund oss för att skapa en online-lärandeportal för skådespelare och yrkesverksamma inom filmbranschen. Det fanns mycket lite data tillgänglig initialt, men vi uppskattade ändå projektet, vilket resulterade i en fast total uppskattning.

Resultat:

Som jag nämnde tidigare gav vi ett fast pris för projektet. I verkligheten överskred vi dock den uppskattade budgeten eftersom det blev uppenbart att mer tid behövdes för arbetet. Medan vår kund inte invände mot detta, uppstod problemet när de inte gjorde några betalningar för arbetsstadierna (sprintarna), vilket gjorde att de kunde avvisa projektet helt i slutet.

Följaktligen var vi tvungna att göra om hela projektet, vilket krävde dubbel ansträngning, men vi kompenserades inte för vårt arbete. Vi arbetade utan betalning för att skydda vårt rykte, medan vår klient förlorade sin dyrbara tid och blev besviken på sin erfarenhet av webbutveckling. Misstag bör kompenseras.

Var misstagen låg:

• Kunden lämnade otillräckliga uppgifter vid start.
• Vi använde inte agila metoder.
• Kunden betalade inte för arbetsstadier och var därför inte delaktig i interimresultaten.
• Vi angav ett fast pris istället för att uppskatta sprintar (vi kunde ha använt den tidigare beskrivna metoden för noggrann uppskattning).

Angående de två exemplen på uppskattning som presenterats ovan är det tydligt att vissa strategier och metoder är avgörande för en korrekt uppskattning inom webbutveckling.

Från dessa fall framgår flera viktiga slutsatser:

• Fastprissättning bör undvikas då det ofta inte korrekt återspeglar produktens faktiska behov.
• Kundernas önskemål stämmer ofta inte heller överens med projektets verklighet.
• Mer indata vid start leder till bättre uppskattningsnoggrannhet.
• Ju noggrannare uppdelningen av uppgifter, desto mer exakt blir uppskattningen.
• Effektiv kommunikation, som att involvera kunder i regelbundna demoöversikter och planeringssessioner, är avgörande för välgrundade beslut och effektiv produktutveckling.

Dessutom vill jag betona att problemet med exakt uppskattning och, i allmänhet, alla tekniska frågor inte bara är tekniska problem som IT-sektorn bör oroa sig för. Kunder och företag måste också vara involverade; då blir det mer grönt ljus för noggranna uppskattningar, vilket leder till ömsesidig nytta och mindre efterfrågan på klumpiga fastpris-metoder.

Jag hoppas att min artikel var till hjälp för både IT-proffs och intressenter som letar efter ett webbutvecklingsteam. Kontakta oss gärna om du behöver en projektuppskattning – vi gör vårt bästa för att skräddarsy den efter dina specifika behov.

Källa: Business’s ‘It’s not my problem’ IT problem.