Ha szoftverfejlesztéssel foglalkozol, valószínűleg elég sűrűn ütközöl ebbe a problémába. Ebben az iparágban, még ha vannak is standardok és kész megoldások, nem lehet listaárakból kiindulni, és sajnos nincs zsebből előhúzható one-size-fits-all termék.
A helytelen esztimáció következményeit senkinek nem kell bemutatnunk. Fontos tehát arra törekedni, hogy a szoftverfejlesztési projektek becslései a lehető legreálisabbak legyenek.

• Miért olvasd el, ha szoftverfejlesztéssel foglalkozol?
  Mert ebben a cikkben megosztunk néhány gyakorlati technikát és hasznos tippet, amelyek segítségével pontosabb és megbízhatóbb becsléseket készíthetsz.
• Miért olvasd el, ha szoftverfejlesztő céggel tervezel együtt dolgozni?
  A folyamatot a leendő ügyfeleknek is érdemes megismerni, mert így jobban megértik, hogy mit miért kérdez vagy kér tőle a fejlesztőcég, illetve reális elvárásokat támaszthatnak a teljes projektet tekintve. Megérthetik, hogy mi alapján készül el egy árajánlat, hogyan számolja ki a fejlesztőcég a munkára adott árat.

Miért lényeges a becslés bármely szoftverfejlesztési projekt esetében?

Statisztikák szerint a fejlesztési projektek nagy százaléka kudarcot vall a helytelen becslések miatt – azaz vagy a fejlesztés ideje, vagy a költsége, vagy a tartalma nem az elvárások szerint alakult. Ismerjük a viccet, “a mi cégünk olcsón, gyorsan és pontosan dolgozik – Ön ebből kettőt választhat”.
Első ránézésre könnyen tűnhet úgy, hogy a tervezési szakasz csak fölösleges plusz idő és költség, azonban ha jobban a mélyére ásunk, nyilvánvaló lesz, hogy az ebben a szakaszban befektetett erőforrások igenis megtérülnek a projekt teljes élettartama alatt. Ezért tehát a megfelelő becslés a projektmenedzsment eljárások egyik kulcsfontosságú eleme, ami valóban megéri az időt és az energiát.

Mi az a projektbecslés?

A projektbecslés a költségek kiszámításának és előrejelzésének folyamata, amelyek a sikeres megvalósításhoz szükségesek. A szoftverfejlesztésben a becslések a szükséges erőfeszítések legreálisabb mértékének előrejelzését jelentik, amelyeket a termék fejlesztésébe kell fektetni. Ez az információ lehetővé teszi annak meghatározását, hogy hogyan árazzuk be a munkát, hány szakember fog dolgozni majd rajta, és végül mennyi idő szükséges mindehhez.

Pontos becslés: Bonyolult, de elengedhetetlen feladat

Mivel a becslések általában hiányos, pontatlan ismeretekre és a jövőre vonatkozó feltételezésekre épülnek, mindegyik tartalmaz némi bizonytalanságot. Nem létezik pontos, egyértékű becslés.

A hagyományos „vízesés” megközelítés azt feltételezi, hogy minden, a fejlesztéshez kapcsolódó specifikációt előzetesen meg kell adni, a becslési folyamat kezdetén. Ma azonban már egyre többen választják az agilis módszertant. A megbízók szeretnének azonnal fejest ugrani a munkába, egy röviden felvázolt követelménylista után, majd menet közben új funkciókat hozzáadni. Így hamar piacra kerülnek az MVP-k (Minimum Viable Products – minimálisan életképes termékek), érkeznek a visszajelzések, a termék pedig ezek alapján folyamatosan alakul, bővül. Az ilyen körülmények között a tervezés és a becslés igen nagy kihívást jelenthet. Tehát a kulcskérdés ebben az esetben: „Hogyan lehet ezeket a bizonytalanságokat kezelni és a lehető legreálisabbá tenni a becslést?”

A becslési folyamat

Az alábbiakban bemutatunk egy általános folyamatot — onnan  kezdve, hogy megismerjük az ügyfél elvárásait, egészen a végső esztimáció elkészítéséig.

1. Előkészítés

Első lépésként a lehető legtöbb információt begyűjtjük a projektről, és beleássuk magunkat az ügyfél főbb kihívásaiba, hogy világos képet kapjunk az üzleti és fejlesztési céljairól. Az információszerzésnek két fő forrása lehet:

• Online videóhívások és megbeszélések: általános beszélgetés a projekt céljáról
• Az ügyfél által biztosított dokumentumok és adatok: briefek, specifikációk, vázlatok, drótvázak, use case-ek, user story-k, analitikák stb.

Ezek mind segítenek abban, hogy pontosabban megértsük a feladatot, és meg tudjuk becsülni a termék fejlesztési költségeit. Minél több információval rendelkezünk ebben a szakaszban, annál pontosabb lesz a becslésünk. Az alábbi kérdésekre próbálunk választ kapni a kezdeti szakaszban:

– Milyen problémát old meg a termék a vásárlói számára?
– Mik a termék főbb funkciói?
– Milyen platformokra épül majd a termék (web, mobil, back-end)?
– Milyen meglévő komponensek vagy rendszerek állnak már rendelkezésre?
– Melyek a legfontosabb felhasználási eseteket?
– Hogyan rangsorolnák a termék jövőbeli funkcióit?
– Van meghatározott technológiai stack, amit használni kell a projekthez?
– Mi az elvárt időkeret a projekthez?
– Ismert a projektre szánt költségvetés?

Ha már biztosak vagyunk abban, hogy minden információ a rendelkezésünkre áll, áttérhetünk a következő fázisra.

2. A megfelelő csapat összeállítása

A szükséges információk összegyűjtése után kiválogatjuk azokat a releváns szakembereket, akik a legnagyobb szaktudással rendelkeznek az adott területen. A becslési feladatokért felelős csapat általában senior szintű szakemberekből áll, mint például:

– CTO
– Senior back-end fejlesztő
– Senior front-end fejlesztő
– Egyéb szakemberek igény szerint: projektmenedzser, UX/UI tervező, QA szakember, technikai író stb.

A legtöbb esetben azok a szakemberek, akik a becslést végzik, később a projektfejlesztő csapat részét képezik. A csapattagok kiválasztásának kulcsfontosságú kritériumai a következők:

– Szakmai szaktudás: releváns tapasztalat a konkrét technológiákkal és hasonló projektekkel való munkában.
– A projekt mielőbbi elindításának lehetősége.
– Egyéb tényezők: ügyfél időzónájában való jelenlét, teljes- vagy részmunkaidős foglalkoztatás, nyelvismeret stb.

Pro tipp: A megfelelő csapat összeállítása az egyik legérzékenyebb kérdés. Az ügyfél biztos akar lenni abban, hogy a legjobb szakembereket kapja, akiknek megfelelő szakértelme van a projekt sikeres teljesítéséhez. Ez garantálja számára a várt minőséget és a végtermék zökkenőmentes leszállítását. Az ügyfelek azt is szeretnék, hogy „valódi emberekkel” találkozzanak,”, különösen a becslési szakaszban, így jobban megérthetik, kikkel fognak dolgozni a projekt során. 

3. A projekt scope és méret meghatározása

A becslési folyamat következő lépése a szoftver követelményeinek pontosítása. A projekt céljának elérése érdekében mérföldkövekre bontjuk a munkát, amelyek feladatokra, alfeladatokra stb. oszlanak. A mérföldköveket általában egy nagyobb egység teljesítése vagy egy projektfázis elérése jelenti.Általában egy fejlesztési projekt az alábbi szakaszokat és az azokhoz kapcsolódó feladatokat tartalmazza.

• Feltárási fázis: dokumentáció elemzése, harmadik féltől származó szoftvereszközök kiválasztása, integrációs lehetőségek vizsgálata, drótvázak előkészítése (ha nem az ügyfél biztosítja), specifikáció elkészítése stb.
• Tervezési fázis: együttműködés az ügyfél kijelölt képviselőivel, amely kitérhet akár a designra, márkaarculatra is, és UX és UI tervezést, prototípuskészítést is magában foglal stb.

Ebben a két fázisban a csapattagok belső meetingeket szerveznek, hogy megvitassák a projekt követelményeit, megosszák véleményüket és ötleteket vázoljanak fel. A kutatási és elemzési fázis végén a csapat a következő eredményeket adja át a potenciális ügyfélnek:

• Architektúra és infrastruktúra terv
• Ajánlott technológiai stack
• Mockupok és drótvázak (ha nem az ügyfél biztosítja)
• Javasolt csapat
• Megközelítő ütemtervek
• Projekt előkészítési fázis: infrastruktúra felállítása, környezetek telepítése, biztonsági konfigurálás stb.
• Fejlesztési fázis: a specifikáció és a meghatározott tech stack alapján a funkciók fejlesztése.
• Tesztelési fázis: funkcionális tesztelés, használhatósági tesztelés, felhasználói elfogadási tesztelés (UAT).
• Átadási fázis: dokumentáció és szellemi tulajdon átadása, a megoldás bevezetése, áruházakban való közzététel, szükség esetén oktatás és bemutató.
  
  Egy másik fontos kérdés, hogy rögtön a teljes funkcionalitás lefedése a cél, vagy induljunk esetleg először egy MVP-vel. Az ügyfeleink nagy része általában ezt a megoldást választja. Tapasztalataink alapján azt javasoljuk, hogy a másodlagos prioritással rendelkező funkciókat nem érdemes beépíteni az első verzióba, inkább az MVP-re koncentráljanak, különösen, ha:

– A projekt követelményei még nem egyértelműek
– A termék piaci illeszkedése még nem validált
– Gyorsan kell hozzáadni és tesztelni a funkciókat
– Korlátozott a költségvetés
– Minél előbb ki kell lépni a piacra a konkurencia előtt

Ennél a szakasznál fontos megjegyezni, hogy itt van egy éles határ az egyes esetek között.

• Bizonyos ügyfelek, projektek esetében elképzelhető, hogy már az előkészítő szakaszban megkapunk minden információt, ami szükséges ahhoz, hogy elkészítsük a projekt esztimációját (pl. Az ügyfél korábban már elkészített egy szakmai szempontból is megfelelő technikai specifikációt, vagy rendelkezik már UX/UI tervekkel stb.). Esetleg az ajánlat megszerzése érdekében az ajánlat készítője eldöntheti, hogy saját idejét és energiáját milyen mértékig fekteti bele abba a munkába, amit még nem garancia, hogy az ügyfél el fog fogadni, és meg fog rendelni. Ilyenkor tehát az ebben a szakaszban leszállítandó elemek már vagy nagyjából kész vannak és elérhetők, vagy további beszélgetések során kinyerhetők anélkül, hogy az ügyfél ezt a tervezést külön megrendelné.
• Az összetettebb, hosszabb feltárást és tervezést igénylő projektek esetében viszont még csak a tervezési szakasz nagysága becsülhető fel, a fejlesztési szakaszra még csak nagyságrendi becslés készíthető, hiszen a tervezési szakasz során kapjuk meg a választ azokra a kérdésekre, amik a teljes árat és a projekt scope-ot befolyásolják.

Pro Tip: A projekt terjedelmének meghatározásakor nagyon hasznos lehet, ha vizualizálunk minden szükséges feladatot, több szintre bontjuk azokat, és grafikusan ábrázoljuk. Ehhez a Miro platformot javasoljuk használni. A Miro segítségével kialakítjuk a projekt hierarchikus struktúráját, ami megkönnyíti egy összetett projekt átlátását, és biztosítja, hogy minden rész-feladat teljesüljön.

4. PERT-módszerrel történő projektbecslés

A részletes feladatbontás után a PERT (Program Evaluation and Review Technique) módszerrel pontosabb becslést készítünk. Az optimista, pesszimista és a legvalószínűbb forgatókönyv figyelembevételével számolhatjuk ki a reális költségbecslést. Az eredményes becslést a következő képlettel számoljuk:

(optimista + pesszimista + (4 x legvalószínűbb)) / 6 = várható becslés

Optimista forgatókönyv: 10 nap (beleértve 10 nap backend és 9 nap frontend fejlesztést. A két csapat párhuzamosan dolgozik).
Pesszimista forgatókönyv: 20 nap (beleértve 20 nap backend és 18 nap frontend fejlesztést.
Legvalószínűbb forgatókönyv: 16 nap (beleértve 16 nap backend és 15 nap frontend fejlesztést.
Várható becslés: (10 + 20 + (4 x 16))/6 = 15,67 nap

Ez a módszer figyelembe veszi a feladatok bizonytalanságait és kockázatait, és bár időigényesnek tűnik, magas fokú pontosságot biztosít.

5. Idővonal grafikon készítése

Miután meghatároztuk az egyes feladatokhoz és mérföldkövekhez szükséges összes időt, felépítjük a projekt idővonalát. Az összes feladatot sorba rendezzük, igazítjuk azok időtartamát, és hozzáadjuk a mérföldköveket. Ez a vizualizáció hasznos a több párhuzamos csapatot igénylő projektek esetében, illetve az egymástól függő feladatok ábrázolására, mivel gyorsan áttekinthetővé teszi az időbeli eloszlást.

6. Költségek kiszámítása

Miután megbecsültük az elvégzendő munka óraszámát, elérkezik a projekt költségének kiszámítása. A teljes projektköltséget úgy számítjuk ki, hogy a becsült munkaórák számát (amelyeket a PERT módszerrel határoztunk meg) megszorozzuk a vonatkozó óradíjakkal. A könnyebb számítás érdekében nézzük meg a következő példát:

– Egy munkaóra = egy órányi megszakítás nélküli szakértői munka.
– Egy nap = egy standard 8 órás munkanap.

Az IT projektekben az óradíjak a szakember szakmai kategóriájától függően változnak, amelyet a feladatai, tapasztalata és a készségeinek egyedisége határoz meg, így egy junior programozó óradíja nem egyezik meg egy senior programozóéval. Ezért a projekt költségének kiszámításakor figyelembe vesszük, hogy az egyes kategóriák óraszámát a megfelelő óradíjjal kell szorozni.

Összes költség = (SZ1 x H1) + … + (SZn x Hn)
Ebben a képletben az SZ1 az 1. kategóriájú szakember óradíja, a H1 pedig a becsült munkaórák száma az adott kategóriában.

Konkrét példa:
Egy szoftverprojekt becslése után az alábbi számokat kaptuk:

Kategória	Óradíj	Óraszám
Senior backend fejlesztő	40$ / óra	100
Medior frontend fejlesztő	35$ / óra	80
Medior UX/UI designer	30$ / óra	50

A projekt teljes költsége:
100×40 + 80×35 + 50×30 = $8,300

7. Mi következik ezután?

Az összes adat és számítás elkészítése után az eredményt tetszőleges formájú ajánlatként prezentáljuk az ügyfélnek, akivel lehetőség szerint érdemes személyesen is átbeszélni annak tartalmát, így lehetőség van a kérdések megvitatására és szükség esetén akár a prioritások újragondolására is.

+1. Post-Implementation Review (PIR)

Bár a PIR (Post-Implementation Review) már nem része a becslési folyamatnak, mégis kulcsfontosságú szerepet játszik a projekt utóéletében. A PIR lehetőséget biztosít arra, hogy a cég felmérje, hol becsülte túl vagy alul a feladatokat, és milyen tanulságokat vonhat le a jövőbeni projektek számára. Ezáltal folyamatosan fejlesztheti becslési módszereit, javíthatja a hatékonyságot, és minimalizálhatja a későbbi kockázatokat, hogy minden projekt egyre pontosabb és sikeresebb legyen.