Az egyedi szoftverfejlesztés ára elsősorban attól függ, milyen üzleti feladatot kell megoldani, hányféle felhasználó dolgozik a rendszerben, milyen adatokat kezel, és mennyire összetett integrációkat igényel. A fejlesztés költsége nem egyetlen „programozási óradíjból” áll: a tervezés, a felület kialakítása, a tesztelés, az üzemeltetés és a későbbi módosítások ugyanúgy a teljes ráfordítás részei. Hiteles árat konkrét követelmények és vállalási feltételek alapján lehet becsülni.
Amikor egy cég először érdeklődik saját szoftver iránt, gyakran azt kérdezi: „nagyjából mennyibe kerül egy ilyen rendszer?” Érthető kérdés, de önmagában kevés a válaszhoz. Két hasonló külsejű alkalmazás mögött egészen eltérő adatkezelés, jogosultsági logika és üzleti folyamat lehet. A célszerű cél ezért nem egy gyorsan bemondott összeg, hanem egy átlátható becslés és egy olyan induló változat, amelynek a haszna ellenőrizhető.
Mi számít egyedi szoftvernek, és miért nehéz általános árat mondani?
Egyedi szoftver lehet belső ügyviteli rendszer, ügyfélportál, foglalási alkalmazás, saját CRM, több szolgáltatást összekötő automatizáció vagy előfizetéses webalkalmazás. Egyes megoldások csupán néhány jól körülhatárolt munkafolyamatot kezelnek; mások egész szervezetek napi működésének központi elemei. A képernyők száma csak az egyik szempont, és önmagában nem jó mércéje az összetettségnek.
Például egy adatlap megjelenítése egyszerű feladat lehet, ha az adatok egyetlen táblából érkeznek. Ugyanaz az adatlap komolyabb fejlesztést igényelhet, ha több rendszerből kell összegyűjteni az adatokat, ellenőrizni kell a jogosultságokat, naplózni a módosításokat, és kapcsolatkimaradás esetén is követhető állapotot kell fenntartani. A felhasználó ugyanazt az oldalt látja, a háttérműködés mégis sokkal összetettebb.
A követelmények pontossága közvetlenül befolyásolja a becslést
A fejlesztés előkészítésekor nem kell feltétlenül kész műszaki dokumentációval érkezni. Azt viszont tudni kell, kik használják majd a rendszert, milyen feladatokat végeznek, és mi történjen sikeres vagy sikertelen műveletnél. Minél több lényeges döntés marad tisztázatlan, annál szélesebb bizonytalansággal lehet csak becsülni az időt és a költséget.
A „legyen ügyfélkezelés” követelmény helyett használhatóbb például ez: „az értékesítő rögzíthessen egy érdeklődőt, rendeljen hozzá felelőst, és a vezető lássa, mely ajánlatokra várunk választ”. Ebből már lehet adatmodellt, képernyőket, jogosultsági szabályokat és tesztelhető elfogadási feltételeket készíteni.
Az előkészítés nem kidobott idő. Segít felismerni a felesleges funkciókat és a rejtett függőségeket. Sok esetben már ekkor kiderül, hogy a teljesen egyedi rendszer helyett egy kész alkalmazás integrálása vagy egy kisebb bővítmény is megfelelő volna.
Ehhez a kész rendszer és az egyedi szoftver közötti választás szempontjai segítenek eldönteni, melyik megoldást érdemes egyáltalán beárazni.
Funkciók, jogosultságok és üzleti szabályok
Az egyik legfontosabb költségtényező az üzleti logika összetettsége. Egy egyszerű nyilvántartás kevesebb döntési szabályt igényelhet, mint egy több lépcsős jóváhagyási folyamat. Ha eltérő szerepkörök dolgoznak az adatokkal, pontosan meg kell határozni, ki mit láthat, módosíthat vagy hagyhat jóvá. Az adminisztrátor jogosultsága nem feltétlenül azonos a cégvezetőével, a külső partner pedig általában csak a saját adatait érheti el.
Az összetett szabályok ne csak a felületen működjenek. A rendszernek a háttérben is meg kell akadályoznia a jogosulatlan műveleteket. Emellett kezelni kell az egyidejű módosításokat, a hiányos adatokat és a hibás állapotokat. Ezek a feladatok fontosak, de az első látványterv alapján gyakran láthatatlanok, így könnyű alábecsülni a ráfordítást.
Integrációk és adatmigráció: a rejtett munkák
Ha az új szoftvernek számlázóhoz, fizetési szolgáltatóhoz, raktárhoz, levelezéshez vagy vállalatirányítási rendszerhez kell csatlakoznia, a fejlesztés nem áll meg egy API-kérés elküldésénél. Tisztázni kell az adatok tulajdonosát, a frissítési irányt, az azonosítók kezelését, a hibákat és az újrapróbálási szabályokat. Egy rosszul megtervezett kapcsolat duplikált vagy elveszett adatokat okozhat.
Régi rendszer kiváltásakor az adatmigráció külön feladat. Meg kell vizsgálni az adatminőséget, a hiányzó vagy következetlen rekordokat, a dokumentumokat, az archiválási igényeket és a lehetséges leállási időt. A „csak át kell másolni az adatokat” kijelentés gyakran figyelmen kívül hagyja a tisztítást és az ellenőrzést. A migráció után egyeztetni kell például a rekordok számát, a kritikus mezőket és a fő felhasználói folyamatokat.
Felület, használhatóság és tesztelés
Az egyedi szoftver értéke nem pusztán abban áll, hogy minden gomb működik. A munkatársaknak gyorsan és hibamentesen kell elvégezniük a feladataikat. A felhasználói felület megtervezéséhez szükséges lehet a szerepkörök, a gyakori feladatok és a nehéz helyzetek feltárása. Egy bonyolult alkalmazásnál a felhasználói teszt sok későbbi problémát előzhet meg.
A minőségellenőrzésnek része lehet az alapfunkciók tesztelése, az integrációk próbája, a jogosultságok vizsgálata, a mobilos működés és az adatvesztési helyzetek kezelése. Nem reális azzal kalkulálni, hogy egy rendszer attól elkészült, hogy a fejlesztő gépén egyszer sikeresen lefutott. A hibajavítás és az átadás előtti ellenőrzés a projektterv része legyen.
Az első verzióhoz tudatosan kevesebb képernyőt és funkciót is választhatsz, ha ezzel a legfontosabb üzleti folyamat már működtethető. Ez nem félkész terméket jelent, hanem szűkebb, egyértelműen vállalt funkciókört.
Egyszeri fejlesztési díj és folyamatos működtetési költség
A projekt kezdő költségvetésén túl számolni kell a szerverrel, adatbázissal, mentésekkel, megfigyeléssel, licencekkel, külső szolgáltatások használati díjaival és a biztonsági frissítésekkel. Ha az alkalmazást sokan használják, vagy nagy mennyiségű adatot dolgoz fel, az infrastruktúra igénye is változhat. Az éves fenntartás tehát nem egyetlen, minden projektre alkalmazható százalék.
Érdemes legalább három időtávban gondolkodni: mennyi kell az első használható verzióhoz, mennyi a várható első éves teljes költség, és milyen továbbfejlesztésekre lehet szükség a következő két-három évben. A szoftver akkor térülhet meg, ha a ténylegesen felszabaduló kapacitás, a hibák csökkenése vagy az új szolgáltatás értéke indokolja a teljes ráfordítást.
Hogyan készülhet átlátható becslés?
A részletes becslésben külön kell kezelni a tervezést, a fejlesztési feladatokat, a tesztelést, az integrációkat, a migrációt és az átadást. Minden becsléshez érdemes feltételezéseket és kizárásokat írni: például biztosít-e a megrendelő rendezett adatállományt, elérhető-e a külső rendszer dokumentációja, és hány körben történik a jóváhagyás.
Egy egyszerű, kizárólag szemléltető számítás megmutathatja a logikát. Tegyük fel, hogy egy projektet a tervezés, fejlesztés, tesztelés és átadás négy nagy munkacsomagjára bontunk. Ha az egyes csomagok becsült időigénye 4, 20, 6 és 3 munkanap, összesen 33 munkanap adódik. Ez nem általános fejlesztési normatíva vagy piaci adat; csupán példa arra, miért kell a háttérfeladatokat is figyelembe venni. Egy valódi projektben a becslési egységek és a szükséges tartalék is más lehet.
Kockázatok esetén célszerű szakaszos vállalást kialakítani. Először a legbizonytalanabb üzleti vagy technikai kérdést érdemes tisztázni, csak utána véglegesíteni a nagyobb fejlesztési ütem költségét. A látszólag pontos, de megalapozatlan egyösszegű ajánlat gyakran több vitát szül, mint egy őszintén bemutatott becslési tartomány és annak feltételei.
Mi csökkentheti a költséget a minőség feláldozása nélkül?
A leghasznosabb költségcsökkentés rendszerint a nem szükséges funkciók elhagyása. Ha egy munkafolyamat három hónapig kézzel is biztonságosan kezelhető, nem biztos, hogy az első verzióban automatizálni kell. Ugyanakkor nem célszerű spórolni a jogosultságokon, az adatmentésen vagy az alapvető hibakezelésen: az ezekből fakadó kockázat később jóval nagyobb lehet.
Segíthet az is, ha a vállalkozás már az elején megjelöli a döntéshozót, időben visszajelzést ad a tervekre, és valós tesztadatokat biztosít. Egy projektet a későn módosuló igények, az egymásnak ellentmondó elvárások és az elhúzódó jóváhagyások is drágíthatnak. Ezek szervezési kérdések, nem kizárólag fejlesztői feladatok.
Mire figyelj, amikor több ajánlatot hasonlítasz össze?
- Azonos funkciókra, felhasználói szerepekre és integrációkra vonatkoznak-e az ajánlatok?
- Szerepel-e a tervezés, tesztelés, adatmigráció és dokumentáció?
- Mi történik, ha egy külső szolgáltatás működése eltér a feltételezésektől?
- Hogyan kezelik az új igényeket, változtatásokat és elfogadási feltételeket?
- Kinek a feladata a tárhely, a mentés, a frissítés és a későbbi támogatás?
- Mi lesz átadva a megrendelőnek, és hogyan vehető át a rendszer fejlesztése?
Az egyedi szoftver ára tehát nem egyetlen rejtélyes szám. A jó költségbecslés megmutatja, miből áll a munka, mely feltételek mellett érvényes, milyen kockázatok maradtak és hogyan lehet fokozatosan értéket teremteni.
Ha saját üzleti rendszert tervezel, a KovaBuild egyedi szoftverfejlesztési szolgáltatásánál a munkafolyamatokból és a szükséges integrációkból kiindulva lehet olyan követelménylistát kialakítani, amelyre már értelmezhető ajánlat készülhet.