7 tipp a kiszámítható és eredményes IT-projekthez

Az e-commerce szegmensben végbemenő változások gyors reagálásra késztetik a kereskedőket, ami azzal is jár, hogy az informatikai fejlesztéseket a lehető leghamarabb kívánják meglépni. Hogyan lehet kiszámíthatóan megvalósítani az IT-fejlesztéseket, hogy ne legyenek költségesebbek és egyúttal ne tartsanak tovább az előzetes várakozásokhoz képest?

Ezen a 7 tényezőn csúszik el a legtöbb IT-fejlesztési projekt

Akár webshop készítés, mobil applikáció fejlesztés, avagy weboldal indítás előtt áll az ügyfél, legfőbb vágya, hogy a projekt gyorsan végigmenjen és ne fusson ki az előre betervezett büdzséből. A LogiNet elmúlt években szerzett tapasztalatai alapján, ha erre a 7 tényezőre odafigyel a vállalat, akkor költség és időtáv oldaláról kiszámíthatóbbá lehet tenni a projekteket. Íme Máriás Zsigmondnak, a LogiNet ügyvezetőjének a tanácsai.

1. Hiányos vagy hiányzó üzleti specifikáció

Az üzleti igény pontos leírása a specifikációs szakasz során készül el, a fejlesztési csapat ebből becsüli meg a munkaigényét, egy IT beszállító ebből számolja ki, hogy mennyi idő alatt tudja leszállítani a projektet. Ha kellően részletes a specifikáció, akkor pontosabb a költség- és átfutás becslése, ami tervezhetőbb eredményt jelent. Ha nincs specifikáció, akkor a fejlesztés során rengeteg ad hoc döntés születik, ami kiszámíthatatlanná teszi a fejlesztést.

A specifikáció írás talán a legmagasabb hozzáadott értékű munka a projekt során, mégis vannak olyan tévhitek, hogy az üzleti igény egyeztetése csak felesleges időhúzás, a tényleges munkának a programozás számít. Ha pedig agilisan fejlesztünk, akkor nincs is szükség specifikációra.

Tippek ennek elkerüléséhez:

• Ragaszkodjunk a különböző részletezettségű specifikációra a projekt különböző periódusaiban.
• Ne legyen cél a legelején az utolsó szögig mindent megtervezni, de ne maradjanak fehér foltok.
• Pár napnyi specifikálással több hónapnyi programozást megspórolhatunk.
• Ügyfélként készüljünk fel rá, hogy döntéseket kell hoznunk, és erre szánjunk időt.

2. Menet közben változó igények, prioritások

A projekt megvalósítása során elkerülhetetlenül módosulnak az igények, ami adódhat a piaci, környezeti változásokból. Előfordulhat az is, hogy újabb igények merülnek fel, avagy elhibázott a koncepció, el nem varrt szálak vannak, netán kifelejtettek belőle valamit.

A problémát az jelenti, ha a változások ad hoc jönnek, hiszen ez komoly időzítési és minőségi problémákat okozhat.

Tippek ennek elkerüléséhez:

• Fontos a specifikáció a projekt elején, hiszen így tudjuk, mihez képest változtatunk.
• Az új igényekről készüljön hatáselemzés.
• MVP szemlélet (Minimum Viable Product, a leggyorsabban elkészíthető első üzemképes prototípus): azzal induljon el a cég, ami mindenképpen szükséges az üzleti működéshez, és ehhez ragaszkodni kell (ügyféloldalon is).
• Világos priorizálási feltételek, CR folyamat (Change Request, változási kérelem) legyen kialakítva.
• Backlog (az elvégzendő feladatok teljes listáját tartalmazza) építés a későbbiekre, folyamatos fejlesztésre vagy további fázisokra készülve.
• Ha egy szoftver-terméket vezet be a cég, akkor gyorsabb tud lenni, hiszen sok-sok mérnökévnyi fejlesztési munka eredményét kaphatja meg azonnal (nem kell az első emeletről indulni, a hetedikről könnyebben jut el a tizedikre). Ám érdemes az igényeinek megfelelő terméket keresni, a bevezetett rendszert egy konzultáció keretében előbb megismerni, gap analízist végezni, azaz, az eltéréseket (egyedi igényeket) meghatározni és kompromisszumokat hozni a költségkeret tartásához.

3. Alulbecsült az integrációhoz kapcsolódó feladatok, szereplők száma

Az informatikai infrastruktúrát alkotó elemek összekapcsolása, együttműködő rendszerré alakítása fontos tényező: webshop szoftvereknél elsősorban az ERP-vel, CRM-el, számlázóval, szállítmányozó rendszerekkel, marketing automatizációs rendszerekkel kell integrálódni.

Nem működik az a szemlélet, hogy ha eddig is rá volt kapcsolódva valami a meglévő infrastruktúrára, akkor nem lehet gond egy újabb rendszerrel. Ilyenkor áll elő az a helyzet, hogy nem mérjük fel előzetesen, hogy más vállalati szoftvereink kompatibilisek-e az új webáruházunkkal, számos felesleges változtatási munka kerül be a projektbe.

Tippek ennek elkerüléséhez:

• Ismerjük fel, hogy ez egy többszereplős projekt.
• Vonjuk be már a projekt kezdetekor a többi rendszer beszállítóját.
• Tervezzük meg közösen a másik beszállítóval a tesztelés menetét, legyen erre idő dedikálva.

4. Alulbecsült migráció, adatfeltöltés feladata

Zöldmezős (teljesen új rendszer) kialakításánál ez kevésbé jellemző probléma. Ám előfordul az a helyzet, hogy a régebbi rendszerből az új rendszerbe több adatot kell átvinni (felhasználók, termékek, korábbi rendelések, marketing kampányok, URL-ek, képek, contentek, felhasználó preferencia, stb.) és ennek az erőforrását gyakran alulbecsülik a vállalatok. Általában azt gondolják, hogy elegendő lesz 1-2 excelt átküldeni, az adatokat majd gyorsan feltölti a fejlesztő és ezzel kész is a folyamat. A gyakorlatban azonban ez komoly csúszást okoz.

Tippek ennek elkerüléséhez:

• Már az elején szükséges megtervezni az áthozott adatok körét.
• Bizonyosodjunk meg arról, hogy az adatok kinyerhetőek-e az előző rendszerből.
• A feltöltésre megfelelő kapacitásokat kell biztosítani (idő, munkaerő).
• A feltöltésre a kevésbé képzett munkaerő is megfelelhet.

5. Agilitás, agilis projektszervezés helytelen alkalmazása

A cégek általában azt gondolják, hogy ha agilis metódusban folyik a fejlesztés, akkor nincs is szükség specifikációra, az üzleti igény egyeztetése csak időhúzás, a programozás a tényleges munka. A valóságban azonban azzal a helyzettel találhatja magát szembe a vállalat, hogy ha a fejlesztő elkészíti azt, amit szeretne, nem tudja megmondani mikorra és mennyiért, vagy ha tudja, hogy mikorra és mennyiért, nem tudja pontosan megmondani az eredményt.

Tippek ennek elkerüléséhez:

• Lehet jól agilis projektet csinálni, de: az ügyfél részéről is komoly dedikáció szükséges ehhez (Product Owner szerepkör biztosítása vevő oldalán).
• Okosabb megközelítésnek tűnik, ha az agilis metódikából merítünk, de tudjuk, hogy azt miért tesszük. Például a szakaszos szállítással, gördülő tervezéssel jobban lehet reagálni a változásokra, a demok, retrok, standupok révén biztosított, hogy nem haladunk sokáig a rossz irányba, a priorizálás jobb change management-et biztosít, az MVP szemlélettel jobban meghatározható a célpont, és az aktív ügyfélkommunikációval megoldott a transzparencia.

6. Ügyfél oldalon hiányzó dedikáció

A projekt során számos döntést kell meghozni (igények, migráció, scope változás, priorizálás), amelynek érdekében az ügyféloldalon szükséges egy olyan csapat megléte, amely megfelelő felhatalmazással és dedikációval rendelkezik. Egy fejlesztési projekt ugyanis nem csak IT-projekt, hanem üzleti is, mégis gyakori, hogy az üzleti terület nincs képviseltetve a projektben.

Tippek ennek elkerüléséhez:

• Elengedhetetlen az ügyféloldali hozzáértő csapat, akinek dedikált ideje van a projektre (IT és üzleti terület metszete)
• Megfelelő eszkalációs fórumok, amelyeken rendszeresen, strukturáltan egyeztetnek a szereplők.
• Projekt indulásakor a várható erőforrásokat (idő, pénz, ügyféloldali támogatás) tisztázni kell.

7. Erőforrás problémák (beszállítói - ügyféloldali)

A csúszások számottevő részét ez okozza. Ha az imént említett hat okból kifolyólag a projekt elkezd csúszni, akkor az erőforrás problémákat okozhat akár beszállítói, akár ügyfél oldalon (a projekthez dedikált szereplőknek már más feladatot kellene csinálniuk), ami pedig előrevetíti a projekt további csúszását. 

Tippek ennek elkerüléséhez:

• Tervezetten legyen elérhető a hozzáértő csapat mind ügyfél, mind beszállítói oldalon.
• Legyen erőforrás tervezés és azt érintse a változáskezelés. Az ütemezés változása is változásnak számít, erre is fel kell készülni.