A korábbi cikkekben megválaszoltunk már két olyan kérdést, amit gyakran feltesznek nekünk ügyfeleink. Beszéltünk már arról, hogy mikor válasszunk egy dobozos szoftver helyett egyedi megoldást, a legutóbbi cikkben pedig arra adtunk választ, hogy kit érdemes ezzel a fejlesztéssel megbízni: szabadúszót vagy fejlesztő céget, esetleg érdemes-e saját fejlesztő csapatot felépíteni.

A mai cikkben ismét egy olyan kérdést válaszolunk meg, amit ügyfeleink mindig megkérdeznek a projekt elején: milyen hosszú ideig tart egy fejlesztési projekt? Szó lesz majd arról, hogy mi történik egy ilyen projekt során, ami időt vesz fel, illetve hogy milyen buktatók lehetnek, amelyek miatt elhúzódhat egy fejlesztés.

Megválaszolni ezt a kérdést nagyjából olyan nehéz, mint arra a kérdésre válaszolni, hogy mennyi idő megépíteni egy házat. Az egyszerű válasz az, hogy minden fejlesztési projekt olyan hosszú, mint amilyen hosszú a követelmények listája. De hogy ne csak általánosságban beszéljünk, hanem konkrétumokat is adjunk, vegyünk 2 mintaprojektet.

Legyen az első mintaprojekt egy 100 m2-es könnyűszerkezetes ház megfelelője a szoftvervilágban: egy egyszerű CRM szoftver egy szolgáltató cégnek, mondjuk egy fröccsöntő műhelynek, ami egyedi termékeket gyárt. Számukra fontos, hogy egy helyen tartsák nyilván az összes ügyféladatot, fel tudjanak tölteni mindegyikhez árajánlatot, majd a megnyert projekteknél számlát kiállítani.

A második projektünk ezzel szemben az egyedi szoftverek kacsalábon forgó kastélya egy forgácsoló üzemnek. Ők a CRM-ben különböző projekteket akarnak már követni, az egyedi megrendeléseken kívül a sorozatban gyártott termékek értékesítését is nyomon szeretnék követni. Az egyszerű számlázás itt már nem elég, pontosan szeretnék látni a költségeiket is és egyéb pénzügyi elemzéseket is. Emellett szükségük van egy beszerzési és raktár modulra, illetve egy termelésirányító szoftverre is, amivel előre be tudják tervezni a gyártási kapacitást. Itt már egy vállalatirányítási rendszerről, vagy ERP-ről beszélhetünk.

Mindkét projekt esetében a szoftverfejlesztés szakaszai ugyanazok lesznek, csak az időtartamuk lesz más. Itt meg kell említeni, hogy többféleképpen is lehet szoftvert fejleszteni, a két legismertebb módja a vízesés modell és az agilis modell.

A vízesés modell esetében a szakaszok egymás után következnek, a folyamat végén pedig kapunk egy kész terméket. Pont úgy, mint ahogy egy ház építése az alaptól indul és a belső simításokkal ér véget. Az agilis modellnek számos előnye van a vízesés modellel szemben, viszont elmagyarázni a pontos folyamatot sokkal bonyolultabb, ezért a következőkben inkább egy vízesés modellben fejlesztett szoftveren illusztráljuk a különböző szakaszokat.

Tervezés és specifikáció

A tervezés és specifikációs szakaszban mérjük fel az igényeket és elemezzük az ügyfél folyamatait. Mi ezt általában úgy csináljuk, hogy minden egyes felhasználó típussal ú.n. stakeholder interjúkat folytatunk. Ilyenkor feltérképezzük, hogy hogyan dolgoznak jelenleg, milyen problémákkal szembesülnek és mit várnak el az új szoftvertől.

Az első projekt esetében interjúkat folytatnánk az ügyfél részéről a projektvezetővel, egy értékesítővel, aki majd használni fogja a szoftvert és esetleg a számlázás miatt egy könyvelővel. A második projekt esetében már komplexebb a helyzet. Mivel többféle jellegű terméket értékesítenek, lehet több értékesítőt kell interjúztatni, továbbá szükség lesz a pénzügyi csapat, a beszerzési osztály, a raktáros, a műszakvezetők és a munkások bevonására is.

Ezt követi a tervezés, mikor az ügyféllel közösen meghatározott problémákra megoldási javaslatokat dolgozunk ki. Ezeket ú.n. felhasználói történetek formájában írjuk le.

Ez az első pont, ahol megcsúszhat egy fejlesztési projekt. Az ügyfelek általában mindent egyszerre szeretnének beletömöríteni egy fejlesztési projektbe, ezért az könnyen költségessé és időigényessé válhat. Ennek elkerülése végett gyakran bevetjük ezen a ponton a MoSCoW technikát. A MoSCoW egy betűszó, 4 lista kezdőbetűiből áll össze. Ez a 4 lista pedig a „Must have", „Should have", „Could have" és a „Won't have", vagyis a nélkülözhetetlen funkciók, fontos funkciók, lehetséges funkciók és a biztosan nem megvalósítandó funkciók.

A felhasználói történeteket ebbe a 4 kategóriába soroljuk a lehető legnagyobb szigorúsággal, eredményképpen pedig egy világos képet kapunk arról, hogy hol érdemes meghúzni a vonalat annak érdekében, hogy a projekt ne fusson ki az idő- és költségkeretből.

A megszűrt felhasználói történeteket egy ú.n. backlogba helyezzük. Ez a backlog, a különböző egyéb dokumentációval és esetleges prototípusokkal lesz a specifikációnk, ami a fejlesztendő feladatok leírását jelenti.

Jöjjön akkor a várva várt rész, a konkrét számok. Eddigi tapasztalataink alapján a teljes tervezési és specifikációs fázis az első projekt esetén 2-4 hét alatt megvalósítható, a második projekt esetében viszont ez már a 6-8 hetet is elérheti, hiszen az interjúk és felhasználói történetek száma is könnyen háromszorosa vagy akár négyszerese lehet az első projektnek.

Design és rendszertervezés

A specifikáció véglegesítését a design és a rendszertervezési szakaszok követik. A rendszermérnökök megtervezik, hogy a szoftverhez milyen technológia és infrastruktúra lesz szükséges, hogyan fognak a különböző szoftvermodulok egymással kommunikálni és hogyan lesznek az adattáblák felépítve. Csupa unalmas dolog.

Eközben a grafikusok sokkal izgalmasabb és látványosabb dolgokkal foglalkoznak: drótvázakat készítenek és megtervezik a felhasználói felületeket, amelyek az ügyfeleket és minket is mindig izgalommal töltenek el, hiszen ezek az első igazán kézzelfogható eredményei a munkának.

Ebben a szakaszban érdemes odafigyelni, hogy minden megfelel-e az elképzeléseinknek – ha módosításra van szükség, akkor azt most tegyük meg. Ugyanis ebben a fázisban még relatív olcsón lehet ezeket a módosításokat eszközölni, később, amikor már a fejlesztés zajlik, sokkal költségesebb bármit is megváltoztatni.

Bár úgy tűnhet, hogy a sok változtatás miatt már itt megcsúszhat a projekt, érdemes rászánni az időt, hiszen a későbbiekben ez sokkal több időveszteséget okozhat.

Ez a szakasz az első projekt esetében tipikusan 2-3 hetet, míg a második projekt esetében 5-6 hetet is igénybe vehet.

Fejlesztés

A következő szakasz a fejlesztés, amikor tulajdonképpen pár fejlesztő kolléga összedugja a fejét és koffeinből kódot varázsolnak. Ez az ügyfelek számára ismét egy kevésbé izgalmas szakasz, hiszen ők már a végterméket várják.

Ezért rossz hír számukra, hogy ez a leghosszabb szakasz. Az első projekt esetében ez 10-15 hét, míg a második projekt esetében ez 30-45 hét is lehet.

Még rosszabb hír, hogy ez a szakasz az, ami a leggyakrabban megcsúszik. Ennek a csúszásnak pedig két fő oka lehet.

Az első okot, a különböző változtatási kérések, azaz change requestek adják, amelyek az ügyfél részéről érkeznek. Ezért amint már említettük, a legegyszerűbb, ha már a design és rendszertervezési szakaszban megejtjük ezeket. Ennek a gyakorlati valószínűsége viszont közel nulla.

Mivel a vízesés modell nagyon mereven kezeli a change requesteket, jobb megoldás lehet ilyen esetekben egy agilis fejlesztés. És mivel már másodszorra hozom fel az agilitást ebben a cikkben, úgy érzem, kénytelen leszek majd ennek a témának egy külön cikket szentelni.

A másik oka a fejlesztési szakaszbeli csúszásoknak az, ha a fejlesztő csapat rosszul méri fel a munka mennyiségét. Ezt okozhatja egy elégtelenül kidolgozott specifikáció, vagy a fejlesztő csapat tapasztalathiánya. Mindkét esetet úgy kerülhetjük el, hogy olyan fejlesztő partnert választunk, akinek van tapasztalata hasonló projektekben és rendelkezik a megfelelő referenciákkal.

Bevezetés

Ha készen vagyunk a fejlesztéssel, akkor következi a bevezetési szakasz. Ebben a szakaszban telepítjük a szoftvert az ügyfél rendszerére, adunk hozzáférést a különböző felhasználóknak és végezzük el a betanítást. Bár nem feltétlenül a bevezetés része, leggyakrabban szintén a fejlesztést követően készül el a rendszer dokumentációja is.

Az első projekt esetében a bevezetésre kb. 1 hét elegendő kéne legyen, míg a második projekt esetében 2-4 hetet is igénybe vehet.

Tesztelés és hibajavítás

Ha megtörtént a bevezetés akkor már csak tesztelés és a hibák javítása maradt hátra. Természetesen már a fejlesztési fázis közben is történik tesztelés a fejlesztő csapat részéről, de minden szoftver esetében előfordulnak olyan hibák és tesztesetek, amelyekre csak akkor derül fény, amikor a végfelhasználók elkezdik a szoftvert használni.

Fontos megjegyezni, hogy amikor a tesztelési szakaszhoz szükséges időről beszélünk, akkor az nem egyezik meg a garanciális periódussal. A tesztelés és hibajavításhoz az első projekt esetében 3-4 hétre, míg a második projekt esetében 6-8 hétre van szükség. Ez idő alatt a fennmaradó hibák többségét javítani lehet, és a szoftver megszakítás nélkül használható lesz, azonban esetenként 1-2 apró hiba még előfordulhat később is.

A projekt után

Az effektív projekt ezzel lezárul. Mint láthattuk az első projekt, egy egyszerű CRM rendszer nagyjából 15 és 25 hét között valósítható meg, míg egy elég magas komplexitású ERP rendszer 45 és 65 hét között valósítható meg reálisan.

Bár a fejlesztési projektnek itt vége van, ezek után egy új projekt indul, ami alatt a szoftvert karban kell tartani és a szoftverfrissítéseket el kell végezni. Sőt, a tapasztalatunk az, hogy maga a fejlesztés sem áll meg itt, hiszen a szoftverben folyamatosan módosításokat kell eszközölni és újabb modulokkal kell bővíteni, hogy megfeleljen az ügyfeleink folyamatosan fejlődő igényeinek.

Reméljük sikerült választ adnunk a kérdésre, hogy mennyi ideig tart egy fejlesztés. Ha van egy ötleted, de tartasz tőle, hogy elhúzódik a fejlesztés, és szeretnéd a tanácsunkat kérni, vedd fel velünk a kapcsolatot.