eVIR tudásbázis

Ez az oldal csak olvasható. Megtekintheted a forrását, de nem változtathatod meg. Ha úgy gondolod, hogy ez helytelen, kérdezd az Adminisztrátorokat!
===== Hogyan fejlesztünk =====

Az eVIR fejlesztése folyamatosan, az ügyfél igények figyelembe vételével történik. Mivel az eVIR egy általános funkcionalitású, kifejezetten a magyar KKV számára készült vállalatirányítási rendszer, ezért a felhasználása és a fejlesztése is általánosan, de a magyar specialitásokat figyelembe véve történik. 

A rendszernek vannak közös használatú, általános moduljai, amelyeket sokan használnak (pl. számlázás, partnerkezelés, webshop kapcsolatok, rendeléskezelés, stb.). Ezekben történő módosításokat csak korlátozott mértékben végzünk, mert az egyik ügyfelünk szerint nélkülözhetetlenül fontos új funkció egy másik ügyfelünknél könnyen használhatatlan szintre helyezheti a rendszert. Viszont vannak ügyfél specifikus modulok is (főleg az eVIR Custom verzióban), amelyeket csak egyetlen ügyfél számára fejlesztettünk egyedileg. Ezek speciális funkciókkal rendelkeznek, jellemzően kiegészítik az alapmodulokat, kizárólag annál az ügyfélnél található meg aki számára történt a fejlesztés. Ezekben már szabadabban lehet garázdálkodni, de azért a rendszer felépítéséből, adottságaiból, működéséből adódó korlátokat itt is figyelembe kell venni. Az egyedi modulok is a rendszer részei, a verziókezelő rendszerben helyezkednek el, az eVIR alapmoduljainak fejlesztése közben folyamatosan biztosítjuk az egyedi modulok kompatibilitását és szinten tartását is.

A rendszer előfizetési díja nem csak a támogatást tartalmazza, hanem a folyamatosan fejlesztett általános modulok legfrissebb verziójára való jogosultságot is. A fejlesztéseknél emiatt igyekszünk mindig azokat a funkciókat létrehozni és továbbfejleszteni amelyekre vonatkozóan a legtöbb előfizetőnktől érkezik igény. Ha valakinek nincs türelme kivárni azt, hogy a számára fontos funkciók maguktól megjelenjenek a rendszerben, akkor megrendelhet fejlesztéseket. A fejlesztések árképzését nagyon sok minden befolyásolja, projektenként, ügyfelenként,
feladatonként is változik.

Az irányadó nettó óradíj 50 EUR-nak megfelelő HUF. Ezt csak pár órányi, egyszeri tennivaló azonnali elszámolása esetén szoktuk alkalmazni. Nagyobb projektek, hosszabb ideig zajló fejlesztések esetén az alap óradíjból szoktunk jelentős kedvezményeket adni, ami jellemzően 10-20%. 

További csökkenhet az óradíj akkor, ha olyan fejlesztést csinálunk, amire korábban már több ügyfél is jelezte igényét és a fejlesztés elkészülte után azt azonnal több ügyfélnél is bevezetjük, így szétosztva a fejlesztési költségeket ügyfelek között. De ehhez az is hozzátartozik, hogy a fejlesztés nem kizárólag egy ügyél igénye szerint, hanem több ügyfél igényeinek közös halmaza alapján készült specifikáció szerint történik amikor éppen van rá szabad erőforrásunk és sorra kerül.

Nagyobb fejlesztések, hosszabb projektek esetén már nem óradíjas, hanem fejlesztői nap alapú elszámolás történik.
Egy fejlesztői nap 8 munkaórából áll. Akkor szoktunk nap alapú elszámolásra átállni, amikor a fejlesztés ráfordítás igénye meghaladja a 20-25 munkaórát. A fejlesztői nap díja az alap óradíjból 25% kedvezménnyel számolt 8 órányi összeg. A fejlesztői napok állhatnak akár több egymástól független, de záros időn belül egyszerre elszámolandó fejlesztésből is.

Maga a fejlesztés az nem egyenlő a kódolással, azaz nem akkor indul a folyamat, amikor már megvalósítási fázisba kerül a dolog, hanem általában a következő lépésekből áll:
  * 1. követelménymeghatározás / konzultáció / specifikáció készítés
  * 2. tervezés, előzetes műszaki megvalósíthatósági felmérés
  * 3. hatásvizsgálat a módosult és kapcsolódó modulok esetén is
  * 4. fejlesztés / kódolás
  * 5. tesztelés, hibajavítás
  * 6. bevezetés / telepítés
  * 7. dokumentáció készítés / kiegészítés / frissítés

Az 1-3 pontok közötti lépések elvégzése után lehet kb. 80-90%-os pontosságú becslést adni a tervezett munkaórákról.  Ez az első rész nagyon fontos, és akár már a teljes becsült ráfordításigény 30%-át is kiteheti. Ha nem kerül megrendelésre a fejlesztés, akkor sem számlázzuk ki ezeket az órákat ameddig nem kezd rendszeresen ismétlődni az elutasítás. Ezek nélkül csak nagyon nagyságrendi becslést tudunk adni, ami alapján a fejlesztés végösszege akár fele vagy duplája is lehet a becsültnek.

A ráfordítás becslés kizárólag az 1. pontban készült specifikációban leírt dolgokra vonatkozik. Ha a fejlesztés / tesztelés közben derül ki, hogy másra, esetleg további kiegészítésekre van igény, akkor az már nem feltétlenül fér bele az előzetesen becsült ráfordításba, további munkaórák kerülhetnek rá elszámolásra. Másképp fogalmazva az ajánlat pontossága arányos a specifikáció pontosságával. Mivel maga a fejlesztés pontosan a specifikáció alapján történik, ezért kiemelten fontos, hogy részletes, mindenki számára érthető és pontos legyen. Az nem tekinthető garanciális vagy jótállásos problémának, ha egy elkészült fejlesztésnél utólag derül ki, hogy a specifikációban leírtak teljesítésre kerülnek, de "nem erre gondoltam", "de hát szerintem ez természetes, hogy benne van", stb.

----

Egyszerűbb (1-3 munkaórát igénylő) feladatok esetén nem mindig szükséges ezeket a bonyolultnak hangzó köröket minden esetben végigcsinálni. Sok esetben már a tervezéssel, műszaki megvalósíthatósági felméréssel és hatásvizsgálattal eljutunk a feladat 90%-os készültségi fokáig, ahol már nincs értelme ezen a ponton abbahagyni. Ilyenkor egy ajánlat adás megduplázná a feladat ráfordítás igényét, mert ha felfüggesztjük a fejlesztést a megrendelés megérkezéséig, akkor újból felvenni a fonalat több időt igényel, mint befejezni. Ezért ha már kialakult irántunk a bizalom, akkor inkább azonnal meg is csináljuk a fejlesztést, és tájékoztatást adunk arról, hogy 1-2 munkaórát hozzáírtunk az elszámolandó fejlesztésekhez abban az esetben, ha az elkészült fejlesztés teljesíti az igényeket.

----

Nincs olyan, hogy "csak 5 perces" feladat. Még ha maga a tényleges fejlesztői munka tényleg csak 5 perc, a feladat elvégzése akkor is összesen közel egy órát vesz igénybe. Ennek oka igen egyszerű: a fejlesztő kolléga éppen valamelyik fejlesztői környezetben csinál valamit. Ezt a valamit olyan elmenthető állapotba kell hozni, hogy utána visszatölthető és folytatható legyen. A fejében levő gondolatokat, elképzeléseket, kitalált megvalósításokat legalább gondolatébresztő szinten dokumentálni kell. Majd csak ez után történhet meg az 5 perces feladathoz szükséges adott ügyfélre jellemző fejlesztői környezetre váltás, a feladat értelmezése, fejben való átállás. Ha elkészült az 5 perces feladat, akkor azt tesztelni kell a fejlesztői környezetben, megcsinálni hozzá az esetleges telepítői és frissítői adatbázis módosításokat, dokumentálni a változásokat és feltölteni a módosítást a verziókezelő rendszerbe. Ezt követően már az éles rendszerhez hasonló környezetben jön egy végső teszt, és csak ezt követően nyilvánítható késznek a feladat, amit a feladatkezelő rendszerben is le kell zárni a ráfordítás dokumentálásával együtt. Ez után következhet a félbehagyott előző feladat visszatöltése környezetileg és fejben is. Így lesz a nettó 5 percnyi munkából mindennel együtt kb. bruttó 1 órányi feladat.

----