business
Nem mindent egyszerre — a fokozatos szoftverkészítés
A telefon szól, az ügyfél kérdez valamit egy korábbi rendelésről — de hol is volt az az e-mail? A kolléga elment szabadságra, és vele együtt ment a fejében minden, amit ő tudott az aktuális ügyfelekről. Az Excelből hárman is dolgoznak egyszerre, és nem világos, melyik a friss verzió. Ismerős? Ez a legtöbb kis- és középvállalkozás napi valósága. Egy jól megtervezett szoftver pont ezeket a fájdalmakat tudja megszüntetni — átláthatóbbá, szervezettebbé, gyorsabbá teszi a munkát.
A vállalkozó nem szakember a szoftverkészítésben — és nem is kell hogy az legyen. Egyszerűen szeretné, hogy a cégében rendben menjen a munka: átláthatóan, szervezetten, kevesebb hibával. Amikor eldönti, hogy szoftvert szeretne, általában van fejében egy kép arról, mit kellene tudnia — ez viszont ritkán teljes, és gyakran a részletekben pontatlan. Itt jön be a fejlesztő szerepe — nem csak megírja, amit kérnek, hanem segít is eldönteni, mit érdemes kérni.
Két szélsőség, amibe a vállalkozó belecsúszhat
Az egyik: mindent egyszerre. A vállalkozó úgy gondolkodik, hogy ha már szoftvert csinálunk, legyen benne minden — minden lehetséges funkció, minden későbbi igény, minden „jó lenne, ha”. Egyszerre, alaposan, hogy később ne kelljen vele foglalkozni. Egy ilyen csomag jellemzően sokmilliós, és hónapokig tart. A munka elindul, a kollégák várják, és egy év múlva még mindig minden félkész. Ami elkészült belőle, abból sok olyan, amit a gyakorlatban nem is használnak — mert a tervezés idején még senki nem tudhatta, mi lesz tényleg fontos.
A másik: csak gyorsan legyen kész. A vállalkozó azt mondja, „nem kell tökéletes, csak menjen, majd később javítjuk”. Ez az első hónapban tényleg gyorsabb. A negyedikben már lassabb, mint amilyen lett volna, ha eleinte is rendben épül. A nyolcadikra a fejlesztő szabadkozik, hogy „ez a kód már nem bírja, az egészet újra kell írni” — és a vállalkozó megint a nulláról indulhat.
A jó út: lépésenként, közös tervezéssel
A jó út a két szélsőség között van: nem mindent egyszerre, de nem is kapkodva. Lépésenként, gondosan tervezve, de gyors első eredményre fókuszálva. Induljunk el egy-két fontos funkcióval — pont annyival, amennyi a vállalkozás napi életét rendben tartja. Az alap legyen szilárd és jól megtervezett, hogy a következő funkciók is hozzátehetők legyenek, ha valóban felmerül az igény, és onnan rétegenként bővüljön.
És ami sokakat meglep: a költségeket is szét lehet osztani
A lépésenkénti építkezésnek van egy másik, gyakran figyelmen kívül hagyott előnye: nem kell egyszerre fizetni egy nagy csomagot. Ha először csak az alapra köt szerződést a vállalkozás, akkor a kiadás is csak az alapra szól. A bővítések önálló döntések — minden egyes lépésnél új szerződés, új ütemezés, új költség. Az alap egy teljes értékű szoftvermegoldás, ami önmagában is működik és napi szinten szolgálja a vállalkozást.
Az „alap” az a legkisebb kerek egész, ami önmagában is értéket ad a felhasználónak. Nem prototípus, nem demó — működő szoftver, amit egy ügyfél tényleg használhat. De minden, ami nem feltétlenül kell az induláshoz, kimarad belőle.
Az alap három tulajdonsága
- Magában is működik — ha holnap senki nem ír hozzá újabb funkciót, akkor is használható.
- Egy konkrét fájdalmat orvosol — a vállalkozás napi gondjából vesz le valamit. Nem szépészet, hanem „ezt mindenképp kell”.
- Szigorú elhagyás — minden olyan funkció kimarad, ami csak „ha már úgyis fejlesztünk, csináljuk meg ezt is” alapon kerülne be.
Mi nem alap?
Egy klasszikus félreértés: az ügyfél az „alapot” összekeveri a „demóval”. A demó csak látszat — egy szép képernyő, ami nem csinál semmit. Az alap valódi szoftver, ami valódi adatokat kezel.
Egy másik gyakori hiba: az alapot túl nagyra szabják. Ha az alap 18 funkcióból áll, az nem alap — az egy teljes rendszer első kiadása. A jó alap 1–3 funkcióból áll, és pár hét alatt elkészül.
Egy gyakorlati elv
Ha az ügyfél azt mondja, „de nekünk kell a felhasználói szerepkörök kezelése is”, kérdezz vissza: „Az induláskor hány különböző szerepkör lesz? 2? 3?”. Ha 2, akkor lehet, hogy nem kell külön rendszer — egy „admin / nem admin” kapcsoló elég. A teljes szerepkör-rendszer (Role-based Access Control) a 2. vagy 3. fokozatba való.
1. példa — egy fogorvosi rendelő időpontfoglalója
A vállalkozás: egy magán fogorvosi rendelő. A fájdalom: a recepciós napi 50 telefonhívás miatt nem ér rá a tényleges feladataira.
- Az alap (1–2 funkció): a páciens egy weboldalon kiválaszt egy szabad időpontot, megadja a nevét és telefonszámát, és lefoglalja. A rendelő egy egyszerű felületen látja a foglalásokat — naptár-szerű nézet, mai nap kiemelve.
- Mi nem kell az alaphoz: SMS-emlékeztető, e-mail-megerősítés, online fizetés, NAV-számlázás, többnyelvűség, mobil-app, naptár-szinkron, kezelés-történet, beteg-portál.
- 2. fokozat: automatikus SMS-emlékeztető 24 órával előtte, e-mail-megerősítés foglaláskor.
- 3. fokozat: Google Calendar összekötés, hogy a fogorvos saját naptárában is ott legyenek az időpontok.
- 4. fokozat: beteg-portál, online fizetés, NAV-számla.
2. példa — egy építőipari KKV ügyfél-nyilvántartója
A vállalkozás: egy 8 fős építőipari cég, ami családi házakat újít fel. A fájdalom: az ügyfelek adatai szétszórva — Excel, e-mail, papír, WhatsApp.
- Az alap: egyszerű űrlap új ügyfél felvételéhez (név, cím, telefon, igény, érdeklődés dátuma); kereshető lista, és részletes nézet ügyfelenként, ahol jegyzetek, fájlok és dátumok rögzíthetők.
- Mi nem kell az alaphoz: automatikus ajánlat-küldés, számlázás, mobil-app, többnyelvűség, fejlett szűrők, tömeges e-mail, kimutatások.
- 2. fokozat: dokumentumok feltöltése (helyszín-fotók, ajánlatok, szerződések) ügyfelenként.
- 3. fokozat: sablon-alapú ajánlat-készítés, e-mail-küldés egy gombra.
- 4. fokozat: kapcsolat egy NAV-számlázó rendszerrel (pl. Számlázz.hu, Billingo).
3. példa — egy belső admin-felület élő listával
A vállalkozás: egy webshop tulajdonos, aki napi 200 megrendelést kap. A fájdalom: az új rendelések kézi kezelése — e-mailek, kinyomtatás, szállítólevél.
- Az alap: egy belső felület, ahol az új rendelések azonnal megjelennek; egy gomb, amivel feldolgozottnak jelölhető és nyomtatható a szállítólevél.
- Mi nem kell az alaphoz: raktárkészlet-kezelés, futárszolgálat-összekötés, csomag-követés, vevő-értesítések, kimutatások, többfős hozzáférés-kezelés.
- 2. fokozat: futárszolgálat (DPD, GLS, Foxpost) értesítése, vevőnek küldött követő-link.
- 3. fokozat: raktárkészlet-kezelés, vissza-szinkronizálva a webshoppal.
- 4. fokozat: bonyolultabb kimutatások, többfős hozzáférés saját jogosultságokkal, AI-alapú forgalom-előrejelzés.
Itt egy kicsit műszakibb leszünk, de csak annyira, amennyire szükséges. Egy szoftver három fő rétegből áll, és ezt érdemes érteni vállalkozóként is — mert ez segít megérteni, milyen árajánlat reális, és mire mennek el a költségek.
1. A felhasználói felület (frontend)
Ez az, amit a felhasználó lát és használ — a böngészőben megjelenő képernyők, gombok, űrlapok. Ezen a rétegen dől el a felhasználói élmény. Ha lassú, ha bonyolult, ha ronda — a felhasználó nem fogja használni, akármilyen jó is mögötte a szoftver.
2. A háttér (backend)
Ez a felhasználó számára láthatatlan rész. A backend tárolja az adatokat, kiszolgálja a felület kéréseit, küldi az e-maileket, számolja a kimutatásokat. Gyakran a legdrágább rész — itt él az üzleti logika és a biztonsági követelmények.
3. Az adatbázis
Itt élnek a tartós adatok — az ügyfelek nevei, az időpontok, a megrendelések, a fájlok. Az adatbázis az egyetlen rész, ahol egy hiba akár tartós kárt okozhat — ezért nagy figyelmet igényel. Az adatbázis-választás (PostgreSQL, MySQL, Firestore, MongoDB) sokat befolyásol a későbbi bővíthetőségben.
A három réteg együtt
Amikor egy felhasználó egy időpontot lefoglal: a felület elfogadja a kattintást, elküldi a backendnek, a backend ellenőrzi, hogy szabad-e még az időpont, ráírja az adatbázisra, és válaszol a felületnek. Ez fél másodperc alatt lezajlik — de három réteg dolgozik együtt.
Az egyik első és legfontosabb döntés: hol fog futni a szoftver. A felhő-szolgáltatás (cloud) annyit jelent, hogy a szoftver egy nagy szolgáltató (Google, Amazon, Microsoft) gépein fut, nem a sajátodon. Te bérelsz tőlük annyi gépi erőforrást, amennyi szükséges, és csak azért fizetsz.
A felhő előnyei egy KKV-nak
- Nem kell szervert venni — egy szerver vásárlása 500 ezer–1 millió forint, plusz havi áram és karbantartás.
- Nem kell karbantartani — biztonsági frissítések, tűzfal, vírusvédelem a szolgáltató felelőssége.
- Magától bővül és csökken — ha holnap 10× annyi felhasználód lesz, a felhő nem omlik össze.
- Beépített biztonsági mentés — a fontos adatok automatikusan többszörözve vannak több helyen.
- Csak a használat után fizetsz — egy ritkán használt belső admin-felület havi költsége akár pár száz forint.
Mikor lehet mégis indokolt a saját szerver?
- Jogi kötöttségek — pl. egészségügy, banki, gyermekvédelem, ahol az adat nem hagyhatja el az országot vagy a céget.
- Nagyon nagy, állandó terhelés — ha egy szoftver 24/7 magas terhelésen fut sok éven át, sajáton hosszú távon olcsóbb lehet.
- Meglévő szerver-park — ha már van mit használni, néha gazdaságosabb azt bővíteni.
Egy KKV induló projektnél szinte mindig a felhő a jobb választás. A „de én mindent saját kézben akarok tartani” érv érzelmileg érthető, de a gyakorlatban nem éri meg — a tényleges kezelés továbbra is a fejlesztő-csapat dolga, csak a hardver más tulajdonosé.
A jó kialakítás olyan, hogy nem kell minden új funkcióhoz az egészet újraépíteni. A háttér úgy van megtervezve, hogy „lyukai” legyenek, ahol új modulok beilleszthetők — anélkül, hogy a meglévő részekhez hozzá kéne nyúlni.
Mit jelent ez a gyakorlatban?
Maradjunk a fogorvosi időpontfoglalónál. Ha jól van megtervezve, akkor a következő funkciók már új modulokként tehetők hozzá: az SMS-emlékeztető figyel a holnapi időpontokra és kiküldi az SMS-t; az e-mail-megerősítés a foglaláskor reagál; a Google Calendar-összekötés átküldi a foglalásokat a Google-nek. Egyik új modul sem nyúl hozzá a meglévő foglalási kódhoz.
Az „események” elve
A modern építkezésekben gyakran használt minta: a fő rendszer „eseményeket” hirdet ki (új foglalás létrejött, új ügyfél felvéve, új megrendelés érkezett). Ezekre az eseményekre más modulok feliratkozhatnak — de a fő rendszert nem érdekli, ki figyeli őket. Két előnye van: a fő rendszer kódja nem nő minden új funkcióval, és ha egy modult le kell venni, a fő rendszer ezt nem érzi meg.
Egy egyszerű kép
Képzeld el úgy, mint egy raktárt. A fő rendszer a raktár, ahol a dolgok történnek (új doboz érkezett, doboz elment). A modulok a raktár mellett álló segédek, akik figyelnek bizonyos eseményekre — egyik az érkezésekről számláz, másik az elszállításokról értesít. Ha egy segéd elmegy, a raktár tovább működik. Ha új segéd jön, csak figyel — nem szól bele a raktár dolgába.
Az egyik leggyakoribb buktató: a szoftver úgy van megírva, hogy szorosan függ egy konkrét szolgáltatótól vagy eszköztől. Évekkel később, amikor azt akarod, hogy másra váltsanak — kiderül, hogy az „egy kis átköltöztetés” valójában fél éves projekt.
Néhány klasszikus eset
- SMS-szolgáltató — a szoftver egy konkrét SMS-cég felületére van szabva. Árváltozásnál vagy megszűnésnél heteket vesz igénybe az átállás.
- Felhő-szolgáltató — a szoftver egy konkrét felhő (pl. AWS) belső szolgáltatásait használja. Másra váltás (Google Cloud, Azure) nagy átalakítás.
- Számlázó-rendszer — a szoftver közvetlenül a Számlázz.hu API-jára épül. Billingo-ra váltás újraírást jelent.
- NoSQL adatbázis — egy konkrét felhő-adatbázisra (pl. Firestore) épült rendszer áttelepítése klasszikus PostgreSQL-re komoly munka.
Hogyan védekezzünk ellene?
Nem úgy, hogy teljesen elkerüljük — az lehetetlen. Hanem úgy, hogy a fő üzleti logika tőle elválasztva íródjon meg, és a külső szolgáltatás csak egy „cserélhető” részegységként legyen jelen. Konkrét példa: ahelyett, hogy a szoftver közvetlenül a Számlázz.hu felületét hívná mindenhol, készítünk egy „számla-küldő” modult, aminek egyetlen feladata a számla-kibocsátás kezelése. A többi rész nem tudja, hogy a háttérben Számlázz.hu vagy Billingo dolgozik. Ha cserélni kell, csak ezt az egy modult írjuk át.
Kérdezd meg ezt
Egy árajánlat-egyeztetésnél kérdezd meg a fejlesztőt: „Ha 2 év múlva váltunk SMS-szolgáltatót, az mennyi munka?”. Ha a válasz „pár nap, csak a beállításokat kell módosítani”, akkor jó. Ha a válasz „hú, az komoly munka, mert mindenhol benne van a kódban”, akkor ott rossz a kialakítás.
Az integráció (összekapcsolás) annyit jelent, hogy a saját szoftvered egy másik, már létező rendszerrel beszélget. Ha az új ügyfél felvételénél a szoftver magától ráírja a NAV-számlázó rendszerre, az egy integráció. Ha egy időpont-foglalás magától megjelenik a Google Calendarban, az is.
Jellemző külső kapcsolatok egy magyar KKV szoftverében
- Számlázz.hu, Billingo, KBOSS — számla-kibocsátás, NAV-bejelentés. Mindenkinek, aki számláz.
- Google Calendar, Outlook — naptár-szinkronizáció. Időpont-alapú szolgáltatóknak.
- Mailchimp, Brevo, SendGrid — tömeges e-mail-küldés. Hírlevélhez.
- Twilio, BulkSMS — SMS-küldés. Emlékeztetők, megerősítések.
- K&H, OTP, Stripe, Barion — online fizetés. Webshop, előfizetés-alapú szolgáltatás.
- DPD, GLS, Foxpost API — csomag-kezelés, követés. Webshop.
- Excel, CSV import-export — adat-ki és bevitel. Szinte mindenkinek.
A „megírjam vagy kapcsoljam be?” kérdés
Egy klasszikus kísértés: a fejlesztő úgy érzi, „a számlázást is meg tudnám írni magamnak”. Pedig a Számlázz.hu bekapcsolása egy hetes munka, a saját számlázó-megírás (NAV-bejelentéssel együtt) sok hónap. Az alapelv: amit valaki más jól csinál, azt ne írd meg újra. Magadnak megírni csak azt érdemes, ami a saját üzleti logikád — amitől a vállalkozásod egyedi.
Egy fejlesztővel beszélgetni nem könnyű, ha a téma műszaki. De van pár kérdés, amit nyugodtan feltehetsz, és a válaszokból sok mindent megtudsz arról, mennyire átgondolt a tervezés.
- „Mi a legkisebb verzió, amit ki tudunk adni 8 héten belül?” — Ha nem tud konkrét választ adni, ott nincs jó tervezés.
- „Mit hagyjunk ki az első verzióból, ami később bekerülhet?” — Ezzel teszteled, mennyire képes rangsorolni.
- „Ha 2 év múlva váltunk SMS-szolgáltatót, az mennyi munka?” — Ezzel ellenőrzöd, hogy nem ragad-e be a szoftver egy szolgáltatóhoz.
- „Hova kerülnek az adatok, és én hogyan férek hozzájuk?” — Az adat a tied, hozzá kell tudnod férni a fejlesztőtől függetlenül is.
- „Mi van, ha 3 év múlva másik fejlesztőre váltok?” — Mennyire átadható a kód.
- „Hogyan lesz tesztelve a szoftver?” — Az automatikus tesztek nem luxus, fél éven túli projektnél szinte kötelező.
- „Mi lesz a havi üzemeltetési költség?” — Felhő-bérlet, harmadik féltől szolgáltatások, licencek; KKV-szoftvernél jellemzően havi 20–100 ezer forint.
Egy intő jel
Ha egy fejlesztő minden kérdésre csak műszaki szakszókkal válaszol, és nem a vállalkozás szempontjából (idő, költség, kockázat), akkor valószínűleg nem fog tudni veled értelmesen beszélgetni a projekt során sem. A jó fejlesztő képes „lefordítani” a műszaki kérdéseket vállalkozói nyelvre.
A fejlesztési költség
Egy reálisan tervezett alap (1–3 funkció), egyszerűbb felülettel:
- Egy szabadúszó fejlesztő — bruttó 1,5–3 millió forint, 6–10 hét.
- Egy kis fejlesztői csapat (2–3 fő) — bruttó 3–6 millió forint, 4–8 hét.
- Egy nagyobb ügynökség — bruttó 5–10 millió forint, 6–12 hét.
A bővítések rétege átlagosan az alap 30–50%-a, fokozatonként, attól függően, milyen összetett.
A havi üzemeltetési költség
- Felhő-bérlet — havi 5–30 ezer forint kis projektnél, 30–150 ezer forint közepesnél.
- Harmadik féltől szolgáltatások (SMS, e-mail, fizetés) — kis használatnál 0–10 ezer Ft, közepesnél 10–50 ezer Ft.
- Karbantartás, hibajavítás, kis fejlesztés — havi 50–250 ezer forint, attól függően, milyen aktív a projekt.
Egy első évre kb. 200–500 ezer forint havi költséget érdemes betervezni egy átlagos KKV-szoftverhez. Ha valaki ennél sokkal kevesebbet ígér, vagy hiányzik valami a számításból, vagy a karbantartás minősége nem lesz megfelelő.
A „mentőöv” csomag
Sok fejlesztő (közöttünk mi is) ad „mentőöv” típusú csomagot — havi átalány, amiért egy meghatározott óraszám karbantartás, hibajavítás és kis fejlesztés van benne. Ez sokkal kiszámíthatóbb, mint óránként számlázni — és arra is jó, hogy a szoftver „életben maradjon” akkor is, ha pár hónapig nincs aktív fejlesztés.
1. „Csináljuk meg az egészet, hogy ne kelljen később.” A klasszikus. A teljes csomag mindig drágább, lassabb, és sok olyat tartalmaz, amire a felhasználó nem is fog rákattintani. Az „alap + bővítés” megközelítés kevesebb pénzt költ rosszul.
2. „A barátom unokaöccse az IT-s, ő majd megírja.” Egy alkalmi, oldalprojekt-szerű fejlesztés ritkán végződik jól vállalkozási környezetben. Ha félig kész marad — ami a megszokott eset —, a vállalkozónak nincs kihez fordulnia.
3. „Csak egy egyszerű weboldalt akarunk.” Az „egyszerű weboldal” gyakran egy fél webshop és egy admin-felület együtt — csak a vállalkozó még nem mondta ki. Ha első körben nem tisztázzátok pontosan, mit jelent az „egyszerű”, az árajánlat háromszorosa lesz a vártnak.
4. Nincs tervezve a karbantartás. A szoftver nem festmény — nem készül el „véglegesen”. Hibák jönnek elő, az operációs rendszerek frissülnek, a szolgáltatók árat változtatnak. Ha nincs havi keret a karbantartásra, a szoftver lassan elfogy alóla.
5. Az adat „bent ragad”. Egy év múlva a vállalkozó váltani szeretne — kiderül, hogy az adatok formátuma egyedi, kinyerni nehéz. Az adat-hozzáférést és az exportálhatóságot már a tervezésnél tisztázni kell.
6. Nincs felhasználói teszt az induláskor. Ezt sokkal jobb a fejlesztés közben, valódi felhasználókkal tesztelve észrevenni — nem az indulás után.
A szoftver-projekt ritkán azon bukik, hogy a fejlesztő nem tud kódolni. Sokkal gyakrabban azon, hogy nem voltak tisztában a célokkal, a fontossági sorrenddel, vagy a folyamattal.
Ez a cikk egy keret volt — egy gondolkodási háló. A következő cikkekben az itt érintett egyes témákat egyenként mélyítjük el, mindig a vállalkozó szemszögéből, műszaki részletek nélkül.
Mit érdemes magaddal vinni innen?
- Ne akarj egyszerre mindent. Egy 1–3 funkciós alap, ami pár hét alatt elkészül és tényleg használatba kerül, többet ér, mint egy 30 funkciós csomag, ami 8 hónapig készül.
- Tervezd meg a bővülés útját, de ne építsd meg előre. A háttér úgy legyen kialakítva, hogy a következő funkciók beilleszthetők legyenek — de csak akkor építsd meg őket, ha tényleg igény mutatkozik rájuk.
- Kérdezz a fejlesztődtől. A jó fejlesztő tud vállalkozói nyelven beszélni, és örül, ha érdekli a folyamat. A „nem érted úgyis” típusú válasz mindig intő jel.
A következő cikkek
- Hogyan írjunk specifikációt — milyen szempontok szerint határozzuk meg, mit szeretnénk a fejlesztőtől.
- Adatok és adatbázis — mi a jó modell egy ügyfél-nyilvántartáshoz.
- A felhasználói felület — mi alapján dönt egy felhasználó, hogy folytatja-e a használatot az első percekben.
- Jogosultságok és biztonság — ki láthatja az ügyfél adatait, és hogyan védjük meg.
- Számlázás, fizetés, automatizálás — hogyan kapcsolódjunk be a magyar vállalkozói világba.
- Külső kapcsolatok — Google, NAV, banki rendszerek, futárszolgálatok.
- Karbantartás és üzemeltetés — mi van akkor, ha „kész” a szoftver.
Beszélgessünk az induló lépésről
Ha bármelyik témában konkrét kérdésed van, vagy egy projekt-ötleted már kész és csak a következő lépést keresed, szívesen átbeszéljük együtt. A jó kezdés a leghasznosabb dolog, amit egy szoftver-projekt elejére tehetsz. info@zs-soft.hu