# Szoftverfejlesztés megrendelése: hogyan ne csússzon el? URL: https://casterconsulting.hu/szoftverfejlesztes-megrendelese/ Published: 2026-10-15 Updated: 2026-10-15 Author: Caster Consulting > Egy szoftverfejlesztés ritkán a programozáson csúszik el, sokkal gyakrabban azon, hogy a megrendelő és a fejlesztő mást ért ugyanazon a mondaton. Pontos igények, rövid, kipróbálható lépések és egy jó szerződés többet véd, mint bármilyen fix ár. **Rövid válasz: egy szoftverfejlesztés ritkán a programozáson csúszik el, sokkal gyakrabban azon, hogy a megrendelő és a fejlesztő mást ért ugyanazon a mondaton.** Pontos igények, rövid, kipróbálható lépések és egy jó szerződés többet véd, mint bármilyen fix ár. Ha a megrendelő csak az elején és a végén vesz részt a projektben, a végén szinte biztosan meglepetés éri. A legtöbb kkv ritkán rendel szoftverfejlesztést, ezért nincs rutinja benne. A fejlesztő cégnek viszont van. Ez az aszimmetria a leggyakoribb oka annak, hogy a projekt drágább és lassabb lesz a vártnál. Ez a cikk a megrendelő oldaláról mutatja meg, mire figyelj. ## Miért csúsznak el a projektek? Bent Flyvbjerg és Alexander Budzier 1471 IT-projektet elemzett. Az átlagos költségtúllépés 27% volt, ami kellemetlen, de kezelhető. Minden hatodik projekt viszont „fekete hattyú” lett, átlagosan 200%-os költség- és közel 70%-os határidő-túllépéssel. Ezek a ritka kisiklások viszik el a legtöbb pénzt. Az amerikai projektmenedzsment-szervezet, a PMI felmérése szerint a sikertelen projektek közel fele (47%) a pontatlan követelménykezelés miatt nem éri el a céljait. Nem a technológia miatt, hanem mert nem volt világos, mit kell elkészíteni. Az ERP-projekteket vizsgáló Panorama-jelentés is ugyanezt mutatja: a bővülő hatókör, vagyis a menet közben hozzáadott igények a költségtúllépések 20%-áért és a határidő-csúszások 19%-áért felelnek. A három adat ugyanabba az irányba mutat: **a legnagyobb kockázat a homályos és menet közben változó igény.** ## Mielőtt szerződést kötsz ### Írd le az igényt felhasználói szemmel Nem kell műszaki specifikáció. Kell viszont egy leírás arról, ki fogja használni a szoftvert, mit akar vele elérni, és honnan tudja, hogy sikerült. Egy jó forma a felhasználói történet: „Mint raktáros, szeretném a beérkező árut vonalkóddal rögzíteni, hogy ne kelljen kézzel beírnom a cikkszámot.” Minden ilyen történethez tartozzon átvételi feltétel: mikor mondod, hogy kész. Például: „a vonalkód beolvasása után a tétel megjelenik a készletben, és a hibás vonalkódnál a rendszer figyelmeztet.” ### Kérj prototípust Mielőtt egy sor kód elkészül, kérj kattintható prototípust a fő képernyőkről. A felhasználók egy prototípuson percek alatt észreveszik azt, amit egy írott specifikációban hetekig nem. Ez a legolcsóbb hibajavítás az egész projektben. ### Döntsd el, mi a legkisebb működő változat Az első változat legyen szűk: egy folyamat, egy csapat, a legfontosabb funkciók. Minden más egy listára kerül a későbbi bővítésekhez. A kisebb első lépés kisebb kockázat, és hamarabb kiderül belőle, hogy a fejlesztő és a megrendelő jól érti-e egymást. Ha az első változat jól sikerül, a bővítés sokkal pontosabban tervezhető, mert már valós használati tapasztalat áll mögötte, nem feltételezés. ## Fix ár vagy óradíj? **Fix ár:** a megrendelő tudja előre a költséget, de a fejlesztő a kockázatot beárazza, és minden változtatás külön módosítást igényel. Akkor jó, ha az igény pontosan leírható és stabil. **Óradíj (time and material):** rugalmas, a megrendelő csak a ténylegesen elvégzett munkáért fizet, de a végső költség bizonytalanabb. Akkor jó, ha az igény menet közben pontosodik. A gyakorlatban jól működik a kettő keveréke: fix áras felmérés és prototípus, utána óradíjas fejlesztés rövid, fix keretű szakaszokban, mindegyik végén működő, kipróbálható eredménnyel. Így a megrendelő minden szakasz után dönthet: folytatja, irányt vált, vagy leállítja a projektet, és sosem fizet többet egy szakasznál olyasmiért, ami nem működik. ## Hogyan haladj a fejlesztés alatt? ### Rövid ciklusok, működő eredménnyel A Scrum, a legelterjedtebb agilis módszertan hivatalos útmutatója szerint egy fejlesztési ciklus (sprint) legfeljebb egy hónap. Minden ciklus végén van egy ellenőrizhető eredmény (increment), de csak az számít eredménynek, ami megfelel a „kész” közösen elfogadott definíciójának (Definition of Done). Ami nem felel meg, azt nem lehet kiadni, és még a ciklus végi bemutatón sem szerepelhet. Megrendelőként ez neked azt jelenti: kérj kéthetente vagy havonta egy bemutatót működő szoftverről, ne állapotjelentést. Egy működő képernyő többet mond, mint tíz oldal haladási riport. ### Változáskezelés Az igények változni fognak, ez normális. A kérdés az, hogyan. Egy egyszerű szabály: minden új igény egy listára kerül, a fejlesztő megbecsüli, és a megrendelő dönt, hogy bekerül-e, és mi kerül ki helyette. Ami nincs leírva és jóváhagyva, az nem része a projektnek. ### Legyen időd tesztelni A megrendelő oldalán kell valaki, akinek van ideje minden ciklus után kipróbálni az eredményt, és világosan megmondani, mi rossz. A legtöbb egyedi fejlesztés nem azért bukik el, mert a fejlesztők nem tudnak programozni, hanem mert a megrendelő oldalán senkinek nem volt ideje időben megnézni. ## A szerződés: szellemi tulajdon, forráskód, kilépés Ezt a pontot a legtöbb kkv elfelejti, pedig évekre meghatározza a mozgásteret. **Kié a szoftver?** A magyar szerzői jogi törvény szerint munkaviszonyban a munkáltató szerzi meg a munkavállaló által munkaköri kötelességként létrehozott mű vagyoni jogait, ha másként nem állapodnak meg (30. § (1) bekezdés). A szoftver vagyoni jogai átruházhatók (58. § (3) bekezdés). **Külső fejlesztőnél viszont semmi sem automatikus:** a szerződésben kell rögzíteni, hogy a jogok átszállnak rád, vagy milyen felhasználási engedélyt kapsz. A törvény szerint a felhasználási szerződés tartalmát a felek szabadon határozhatják meg (42. §). **Mit kapsz meg?** Rögzítsd a szerződésben: - a forráskód átadását, verziókezelő rendszerben; - a dokumentációt (telepítés, üzemeltetés, architektúra); - a hozzáférést a szerverekhez és a fiókokhoz, a te nevedre; - az adatok tulajdonjogát és exportálhatóságát. **Hogyan lépsz ki?** A brit kormány beszerzési útmutatója két évnél nem hosszabb kilépési lehetőséget és minimális kilépési költséget javasol, világos adat- és szellemi tulajdonjogi feltételekkel. Egy kkv-nak is érdemes ehhez igazodni: ha a fejlesztő cég megszűnik vagy elérhetetlenné válik, a szoftvered ne vesszen el vele. ## Hogyan válassz fejlesztő céget? A legolcsóbb ajánlat ritkán a legolcsóbb projekt. Néhány kérdés, amely többet mond, mint az óradíj: - **Hogyan érti meg az igényt?** Kérdez, vagy azonnal árat ad? Egy jó fejlesztő az első beszélgetésen többet kérdez, mint amennyit mond. - **Mutat-e hasonló, működő projektet,** és beszélhetsz-e egy korábbi megrendelővel? - **Ki dolgozik a projekten?** Ugyanaz a csapat marad végig, vagy cserélődnek az emberek? - **Hogyan kezeli a változásokat** és a csúszást? Van erre leírt folyamata? - **Mi történik az átadás után?** Hibajavítás, támogatás, továbbfejlesztés: milyen feltételekkel? Ha egy ajánlat feltűnően olcsó, kérdezd meg, mi nincs benne. Gyakran a tesztelés, a dokumentáció vagy a változáskezelés marad ki, és ezek később kerülnek elő, drágábban. ## Átadás és utánkövetés A projekt nem az utolsó funkció elkészültével ér véget. Az átadásnál ellenőrizd az átvételi feltételeket, kérd meg a teljes dokumentációt és a hozzáféréseket, és tervezz be egy utánkövetési időszakot, amikor a valós használatból derülő hibákat a fejlesztő gyorsan javítja. A szerződésben érdemes rögzíteni a garanciális hibajavítás idejét és a támogatás reakcióidejét is. ## Amit mi láttunk A csapatunk korábbi projektjei közül több is jól mutatja, mennyit számít az üzleti elemzés és a projektmenedzsment. - **Állatorvosi alkalmazás WeChaten:** egy nemzetközi állategészségügyi vállalat kínai leányvállalatának készült alkalmazás külső állatorvosoknak, hat hónap alatt. Az üzleti elemzést és a projektmenedzsmentet Európából vittük, időeltolódással, kínai nyelvű környezetben. Ilyen helyzetben a pontosan leírt igény és a rendszeres bemutató nem formalitás, hanem az egyetlen közös pont. - **Hatósági dokumentumok kezelése:** a vállalat brazil leányvállalatánál a fájlszerveren tárolt hatósági anyagok és szabályzatok kerültek egy dokumentumkezelő rendszerbe, jóváhagyási folyamattal, verziókezeléssel és lejáratfigyeléssel, 50 felhasználónak. A fejlesztés, az üzleti elemzés és a projektmenedzsment is a csapatunké volt. - **Mobilos audit:** négy európai országban készült webes és mobilos auditrendszer, nyolc hónap alatt, ahol a fejlesztés vezetését, a projektmenedzsmentet és az architektúrát a csapatunk adta. Mindhárom esetben a siker kulcsa nem egy különleges technológia volt, hanem az, hogy az igény világos, a lépések rövidek, és a megrendelő folyamatosan látta az eredményt. ## Figyelmeztető jelek - A fejlesztő hónapokig nem mutat működő szoftvert, csak állapotjelentést. - Az igényekről nincs írásos, jóváhagyott lista. - A szerződésben nem szerepel a forráskód és a jogok sorsa. - A megrendelő oldalán senkinek nincs ideje tesztelni. - Minden változtatás „gyorsan belefér”, írásos döntés nélkül. - A szerverek, a domain és a fiókok a fejlesztő nevén vannak, nem a tiéden, és nem tudod, hogyan férsz hozzájuk. ## Mit tegyél most? 1. **Írd le az igényt felhasználói történetekben,** átvételi feltételekkel. 2. **Kérj kattintható prototípust** a fejlesztés előtt. 3. **Határozd meg a legkisebb működő változatot,** és tedd a többit egy későbbi listára. 4. **Válassz szerződési formát,** például fix áras felmérés, utána óradíjas fejlesztés rövid szakaszokban. 5. **Rögzítsd a szerződésben** a jogokat, a forráskódot, a dokumentációt és a kilépést. 6. **Jelölj ki belső felelőst,** akinek van ideje minden ciklus után tesztelni. 7. **Kérj rendszeres bemutatót működő szoftverről,** ne csak jelentést. Ha szeretnéd, hogy az igények leírásában, a fejlesztő kiválasztásában vagy magában a fejlesztésben segítsünk, nézd meg a [szoftverfejlesztési](/szoftverfejlesztes/) és az [IT tanácsadási](/it-tanacsadas/) szolgáltatásunkat. ## GYIK ### Miért csúsznak el a szoftverfejlesztési projektek? Leggyakrabban a homályos vagy menet közben változó igények miatt. A PMI szerint a sikertelen projektek közel fele (47%) a pontatlan követelménykezelés miatt nem éri el a céljait. ### Fix árat vagy óradíjat válasszunk? Fix ár akkor jó, ha az igény pontosan leírható és stabil. Óradíj akkor, ha menet közben pontosodik. Jól működik a kettő keveréke: fix áras felmérés és prototípus, utána óradíjas fejlesztés rövid, ellenőrizhető szakaszokban. ### Kié lesz a forráskód? Csak az, amit a szerződés rögzít. A magyar szerzői jog szerint a szoftver vagyoni jogai átruházhatók, de külső fejlesztőnél ez nem automatikus. Rögzítsd a jogok átruházását vagy a felhasználási engedélyt, és a forráskód átadását. ### Milyen gyakran kérjünk eredményt a fejlesztőtől? Kéthetente vagy havonta egy bemutatót működő szoftverről. A Scrum-útmutató szerint egy fejlesztési ciklus legfeljebb egy hónap, és minden ciklus végén ellenőrizhető eredménynek kell lennie. ### Mi a legfontosabb a megrendelő oldalán? Egy belső felelős, akinek van ideje minden ciklus után kipróbálni az eredményt és döntéseket hozni. E nélkül a legjobb fejlesztőcsapat is vakon dolgozik. ## Sources - [Flyvbjerg, Budzier – Why Your IT Project Might Be Riskier Than You Think (arXiv 1304.0265)](https://arxiv.org/abs/1304.0265) - [PMI – Requirements Management: A Core Competency for Project and Program Success](https://www.pmi.org/learning/thought-leadership/pulse/core-competency-project-program-success) - [Panorama Consulting – 2017 ERP Report](https://www.panorama-consulting.com/wp-content/uploads/2017/07/2017-ERP-Report.pdf) - [Schwaber, Sutherland – The Scrum Guide (2020)](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf) - [1999. évi LXXVI. törvény a szerzői jogról](https://njt.jog.gov.hu/jogszabaly/1999-76-00-00) - [GOV.UK – Define your purchasing strategy](https://gov.uk/guidance/define-your-purchasing-strategy)