Példa SOW webes fejlesztőhöz: teljes fixed-price projekt

Miért kell szilárd SOW-t írni egy webes fejlesztési fixed-price projekthez?

Amikor egy cég egy független webes fejlesztőre vagy ügynökségre bízza a fixed-price módban történő projektet, nagy a kísértés egy egyszerű árajánlat vagy e-mail cseréken alapulni. Mégis ez az egyik fő forrása a vitáknak a tech ügyfél-szolgáltató viszonyban: rosszul meghatározott projekthatókör, vitatott szállítások, a forráskódra vonatkozó jogok nem pontosítottak. A Statement of Work (SOW) az a szerződéses dokumentum, amely lehetővé teszi e kockázatok megelőzését azáltal, hogy artikuláltan formalizálja, hogy ki mit kell tegyen, mikor és mely siker kritériumok alapján.

Egy fixed-price projektben — szemben a resource sharing módszal — a szolgáltató egy adott eredményre kötelezettséget vállal fix áron. A szerződés éppen ezen jellege miatt még kritikusabb a SOW megírása: minden szürke zóna olyan nézeteltérésé válik, hogy mi volt „benne" vagy sem a hatókörben. 2024-ben, a Conseil national des barreaux éves jelentése szerint az informatikai szolgáltattatási szerződésekhez kapcsolódó kereskedelmi viták a francia kereskedelmi bíróságok előtti B2B viták több mint 18%-át jelentették.

Ebben az útmutatóban egy teljes webes fejlesztő SOW-mintapéldát részletezünk egy fixed-price projekthez, amely a szállítások, az elfogadási kritériumok, a szellemi tulajdon és a forráskód-átruházást tartalmazza. Az alapok alaposabb megismeréséhez javasoljuk, hogy keresse fel a SOW teljes útmutatóját: minta, záradékok és elektronikus aláírás.

---

A SOW tipikus szerkezete webes fejlesztőhöz fixed-price projektben

Egy jól strukturált SOW logikus felépítést követ, amely az általánostól a konkrét felé halad. Íme az egy webes fejlesztési projekthez szükséges alapvető szekciók.

1. Fejléc és a felek azonosítása

A dokumentum a két fél pontos azonosításával kezdődik: a megrendelő (ügyfél vállalat, az jogi forma, SIREN szám, képviselő és tisztsége felsorolásával) és a szolgáltató (független fejlesztő vagy cég). Továbbá pontosítva:

• A SOW száma (különösen ha egy MSA — Master Services Agreement keretébe illeszkedik)
• A hatálybalépés dátuma
• A projekt várható időtartama
• A projekt referense az ügyfél és a szolgáltató oldalán

Ez a szekció sablonnak tűnhet, de vitás esetben meghatározó: megállapítja a szállítások validálásra és módosítások aláírására felhatalmazott együttműködőket.

2. Hatókör és szállítások leírása

Ez a dokumentum szíve. Egy webes fejlesztési fixed-price projekthez a hatókört szinte műszaki pontossággal kell leírni.

Minta szövegezés egy e-commerce webalkalmazáshoz:

> A Szolgáltató feladata az e-commerce webalkalmazás megtervezése, fejlesztése és szállítása, responsiv megjelenéssel, Next.js 14-re (React framework) épülve, Node.js/Express back-end REST API-hoz csatlakozva, Stripe integrációval az online fizetéshez. Az alkalmazás az alábbi modulokat tartalmazza majd: termékkatalógus (akár 5000 tételig), bevásárlókosár, 3 fázisú konverziós csatorna, biztonságos ügyfélterület (JWT), adminisztrációs irányítópult.

Mindegyik szállítást külön fel kell sorolni az alábbival:

• Megnevezése (pl.: „Felhasználó hitelesítési modul")
• Funkcionális leírása (mit csinál, nem hogy van megvalósítva)
• Tervezett szállítási dátuma (vagy fázisok / sprintek szerinti ütemezés)
• Szállítási formátuma (Git repo, staging URL, ZIP fájl, műszaki dokumentáció)

Az összetett projekteknél ajánlatos egy funkcionális követelmény specifikációt (CDC) vagy Agile felhasználó sztorikat csatolni, amelyekre a SOW kifejezetten hivatkozik.

3. Elfogadási kritériumok: hogyan validálni mindegyik szállítást?

Ez a legtöbben elhanyagolt és legvitatottabb szekció. Az elfogadási kritériumok objektíven meghatározzák azokat a feltételeket, amelyekben az ügyfél elismeri, hogy egy szállítás megfelel.

Minta elfogadási kritériumok egy webalkalmazáshoz:

| Szállítás | Elfogadási kritérium | |---|---| | Hitelesítési modul | Bejelentkezés/kijelentkezés funkcionális Chrome, Firefox, Safari (N-1 verzió). Válaszidő < 800 ms. Egység tesztek ≥ 80% kód lefedettség. | | Konverziós csatorna | JavaScript hibaarány = 0 szimulált terhelés alatt (200 egyidejű felhasználó Lighthouse-on). | | Admin irányítópult | CSV export funkcionális. Helyes megjelenítés 1280 × 720 px felbontáson minimum. | | Műszaki dokumentáció | Teljes README.md fájl, architektúra diagram megadott, környezeti változók dokumentálva. |

A SOW-nak továbbá meg kell adnia:

• A recepció eljárása: ki teszteli, milyen eszközökkel, milyen időn belül a szállítás után (pl.: az ügyfél 10 munkanap áll rendelkezésére a validálásra vagy írásban megfogalmazott fenntartások nyújtására)
• A fenntartások kezelése: kisebb fenntartások (kozmetikai hibák) nem blokkolják a fizetést; nagy fenntartások (nem funkcionális funkcionalitás) felfüggesztik a fizetést a javításig
• A hallgatás egyetértést jelent: a recepció időszaka lejárta után írott visszajelzés nélkül a szállítás elfogadottnak számít

Ez a formális elfogadás mechanizmus kulcsfontosságú fixed-price szerződésben. A recepciós jegyzőkönyvek aláírásának automatizálásához sok DSI mostanában az elektronikus aláírást használja a vállalat keretében, amely az eIDAS rendelet szerint ugyanolyan bizonyító értékkel bír, mint a kézírásos aláírás.

4. Pénzügyi feltételek és fizetési mérföldkövek

Egy fixed-price projektben a fizetési szerkezet általában az projekt előrehaladásához kapcsolódik, nem a fordított idő alapján.

Minta fizetési terv egy 24 000 € HT projekthez:

• 30% a SOW aláíráskor: 7 200 € HT (előlegzés, a tervezési/arhitektúra fázist fedezi)
• 30% az 1. sprint szállítása után (1-4 szállítások validálva): 7 200 € HT
• 25% a 2. sprint szállítása után (5-8 szállítások validálva): 6 000 € HT
• 15% a végső recepció és termelésbe helyezés után: 3 600 € HT

A SOW meghatározza a késedelmi szankciók a szolgáltató oldalán (pl.: 0,5% az összes összegből hetente a késés után, maximálisan 10%) és a késedelmi szankciók az ügyfél oldalán a validálási visszajelzésekre (pl.: a globális határidő meghosszabbítása a validálási késés időtartamával).

5. Szellemi tulajdon és forráskód-átruházás

Ez a szakasza minden webes fejlesztési szerződésnek a jogi értelemben legérzékenyebb része. Az alapértelmezésben a francia jogban (Szellemi Tulajdon Kódex, 111-1. cikk), a szellemi munka szerzője — beleértve a szoftvert — megtartja a jogokat, még a szállítás és fizetés után is. Más szavakkal, kifejezett átruházási záradék nélkül, az ügyfél fizet a fejlesztésért, de jogi értelemben nem tulajdonosa a kódnak.

Egy jól megírt SOW-nak teljes átruházási záradékot kell tartalmaznia. Íme egy minta szövegezés:

> A megállapodott ár teljes kifizetése ellenében a Szolgáltató kizárólagos és végleges jogot cédál az Ügyfélnek a jelen SOW keretében kifejlesztett eredeti Szállítások összes vagyoni jogaihoz, beleértve a reprodukciós, előadási, adaptációs, fordítási, módosítási és kereskedelmi kihasználási jogokat, a világon mindenütt és a szerzői jogok védelme teljes jogi időtartamára vonatkozóan.

A SOW-nak továbbá meg kell különböztetnie:

• A tulajdonosi kód (kifejezetten erre a projektre fejlesztve → az ügyfélre ruházódik)
• A harmadik fél komponensei (keretrendszerek, nyílt forráskódú kódtárak → a szolgáltató garantálja az alkalmazandó licencek betartását)
• A szolgáltató eszközei és módszerei (tudásanyag, boilerplatesek → a szolgáltató tulajdona marad)
• Nyílt forráskódú függőségek: felsoroljuk az összetevőket és azok licenceit (MIT, Apache 2.0, LGPL…) a licenc-megsértés elkerülésére

Az innovatív fejlesztéseket magában foglaló misszióknál, amely szabadalmaztatható vagy szoftverként védhető, kérjük keresse fel az INPI hub-ot: aláírás, bejelentés és tanúsítvány a fejlesztési fázisban szereplő jogok biztosítására.

Végül, a SOW-nak tartalmaznia kell egy forráskód-letét záradékot, ha az ügyfél biztosítani kíván magát a szolgáltató meghibásodása ellen: a kód előre meghatározott feltételek alatt egy harmadik fél bizalmi személynél kerül letételre és felszabadításra (a szolgáltató felszámolása, az SLA-ban szereplő mulasztás stb.).

---

Szükséges kiegészítő záradékok egy webes fejlesztési SOW-ban

Bizalmasság és beépített NDA

A szolgáltató érzékeny információkhoz lesz hozzáférése: műszaki architektúra, ügyfél-adatok, termék roadmap. A SOW-nak tartalmaznia kell egy bizalmassági záradékot (vagy hivatkoznia kell egy külön aláírt NDA-ra), amely fedezi:

• Az kötelezettség időtartama (általában 3-5 év a misszió befejezése után)
• A bizalmas információk meghatározása
• A kivételek (már nyilvánosított információ, egy harmadik féltől jogszerűen szerzett)
• Az adatok visszaadásra vagy megsemmisítésére vonatkozó kötelezettségek a szerződés végeztével

Garanciák és az utólagos karbantartás

Fixed-price módban a rejtett hibákra vonatkozó jogi garancia alkalmazandó, de a SOW pontosítja annak működési hatókörét:

• Jó működésre vonatkozó garancia: X hónapig a végső recepció után, a szolgáltató ingyenesen javít minden, a fejlesztésével kapcsolatos hibát (az ügyfél által végrehajtott módosítások vagy nem validált függőség-frissítések kivételével)
• SLA javítás: kritikus hiba 24 munkaóra alatt javítva; nagy hiba 72 óra alatt; kisebb hiba a következő ciklusban integrálva
• Garancia kizárások: az ügyfél által a kódra végzett módosítások, a szolgáltató által nem validált függőség-frissítések

Alvállalkozás és emberi erőforrások

Az ügyfélnek tudnia kell, hogy a szolgáltató szerződheti-e ki a fejlesztések egy részét vagy egészét. Ha előzetes jóváhagyási záradék szükséges (különösen bizalmasság vagy GDPR megfelelőség miatt), azt a SOW-ban kell szereplnie. A kritikus misszióknál néhány ügyfél a fejlesztők explicit megnevezésére és az egyedi módosítás esetén a csapat megváltoztatásának előzetes jóváhagyására insiszt.

A külföldi szolgáltatókkal vagy többrészes kontextusban aláírt SOW-k esetén az eIDAS-nak megfelelő elektronikus aláírási megoldás Certyneotól lehetővé teszi a távelérésű aláírást az EU 27 tagállamában elismert bizonyító értékkel.

---

Legjobb gyakorlatok a SOW véglegezéséhez és aláírásához

Felülvizsgálat és módosítási folyamat

Az aláírás előtt a SOW-t felül kell vizsgálnia:

1. A műszaki projektmenedzser az ügyfél oldalán (a működési hatókör validálása)
2. A jogtanácsos vagy pénzügyi igazgató (a pénzügyi záradékok, IP és szankciók validálása)
3. Az információbiztonság felelőse, ha személyes vagy érzékeny adatok feldolgozása történik (GDPR megfelelőség)

A projekt alatt a hatókörben történő bármely módosítás egy Change Order (módosítás) által aláírt és formalizált módosítást igényel, amely megadja a határidőre és az árra gyakorolt hatást. Aláírt módosítás nélkül bármely módosítási kérés a hatókörön kívülinek számít.

A SOW elektronikus aláírása

A SOW kézírás aláírása időigényes papír-oda-vissza és hibaforrás. Az eIDAS rendeletnek megfelelő fejlett vagy minősített elektronikus aláírás számos döntő előnyt kínál az ilyen típusú dokumentumhoz:

• Megerősített bizonyító érték: minősített időpecsét, a aláírók pontos azonosítása
• Gyorsaság: egy SOW-t percek alatt aláírható, még egy otthon dolgozó vagy külföldön dolgozó szolgáltatóval
• Automatikus archiválás: az aláírt dokumentum hamisíthatatlanul konzerválódik
• Verzió-követés: elkerüli egy régi verzió aláírásának veszélyét

Az elektronikus aláírási megoldások összehasonlítása segítségül szolgál a SOW-jaihoz illő aláírási szint kiválasztásához. Az 50 000 € feletti misszióknál vagy kiterjesztett IP-cession-záradékokat érintő projekteknél a minősített aláírás (az eIDAS legmagasabb szintje) ajánlott.

A dokumentum-előállítás felgyorsítására saját AI-alapú szerződés-generátorunk lehetővé teszi, hogy percek alatt személyre szabott SOW-vázlatot készítsen a projekt paraméterei alapján.

Alkalmazandó jogi keret a webes fejlesztési SOW-kra

Polgári törvénykönyv és szerződés kötelező ereje

A SOW előre egy szerződés a francia Polgári Törvénykönyv 1101. cikke értelmében: „A szerződés egy vagy több fél között létrehozott megállapodás, amely kötelezettségek létrehozása, módosítása, átruházása vagy kioltása céljából létesül." Az 1103. cikk kimondja: „A jogszerűen kötött szerződések a szerződő felek számára törvény helyett vétendők." Amint mindkét fél aláírta, a SOW jogi értelemben kötelező, beleértve annak mellékleteeit, műszaki részleteit és szállítási táblázatait.

A SOW elektronikus aláírása a Polgári Törvénykönyv 1366-1367. cikkeiben szabályozott, amely egyenlő bizonyító értéket ismer az elektronikus iratnak, amennyiben az aláíró személyazonossága megfelelőképpen azonosított és a dokumentum integritása garantált.

eIDAS-rendelet n° 910/2014 és ETSI szabvány

Az európai vállalatok közötti elektronikus SOW-aláíráshoz az eIDAS-rendelet (n° 910/2014 az Európai Parlament és a Tanács) három elektronikus aláírási szintet határoz meg: egyszerű, fejlett és minősített. A fejlett elektronikus aláírás (SEA) az ETSI EN 319 132 (XAdES) és ETSI EN 319 122 (CAdES) szabványokon alapul, amelyek garantálják a dokumentum integritását és az aláíró azonosítását. Nagy pénzügyi kockázatú szerződéses kötelezettségekhez vagy szerzői jogok átruházási záradékait magában foglaló projektekhez a minősített aláírás (SEQ), egy minősített bizalmassági szolgáltatás szolgáltatójánál (PSTQ) kibocsátott tanúsítvánnyon alapulva, bejelentve az európai bizalmi listán (TSL), ajánlott.

Szellemi Tulajdon Kódex (CPI)

A forráskódra vonatkozó jogok átruházása a Szellemi Tulajdon Kódex által szabályozva. A CPI 111-1. cikke a szerzőt és a vagyoni jogokat szellemi munka szerzőjeként állapítja meg, beleértve a szoftvereket (CPI 112-2, 13°). A vagyoni jogok átruházásának a CPI 131-3. cikke szerint kifejezetten meg kell neveznie mindegyik átruházott jogot, a területet, az időtartamot és a kihasználás módját. Ha egy SOW elhagyja az egyik szükséges információt, a szerződés vonatkozó záradéka lehet érvénytelen egy bíróság előtt, a jogok a szolgáltatóhoz maradnak.

Továbbá, egy alkalmazott által az alkalmazottak során létrehozott szoftver az alkalmazottnak tartozik (CPI 113-9. cikk). Ez a szabály nem vonatkozik az független szolgáltatókra, így szükségszerűen kell egy szerződés szerinti átruházási záradéknak lennie.

GDPR (n° 2016/679 rendelet) és adatfeldolgozás

Ha a szolgáltató az ügyfél nevében személyes adatokat dolgoz fel (pl.: ügyféladatok kezelése egy CRM fejlesztéséhez), a GDPR 28. cikke szerinti adatfeldolgozónak minősül. A SOW-nak ezután egy adatkezelési megállapodást (DPA) kell tartalmaznia vagy hivatkoznia kell, amely meghatározza: a feldolgozás jellegét és célját, az érintett adatok kategóriáit, a technikai és szervezeti biztonsági intézkedéseket, valamint a szolgáltató kötelezettségeit az adatvédelmi incidens esetén. Enélkül a ügyfél és a szolgáltató a CNIL szankciójának rizikójában állnak, amely a globális éves nettó bevétel 4%-ét is elérheti.

Kereskedelmi jog és szerződés szerinti felelősség

A szállítások vagy határidők megsértése esetén a szolgáltató szerződés szerinti felelőssége a Polgári Törvénykönyv 1231-1. és követkető cikkei alapján állapítható meg (régi 1147. és további cikkek). A felelősségi korlátok záradékai (pl. számlázott hónapok X-szerese) érvényesek szakemberek között, azzal a feltétellel, hogy nem üríti ki a szerződést lényegéből (Polgári Törvénykönyv 1170. cikk).

Felhasználási esetek: a webes fejlesztő SOW gyakorlatban

Eset 1 — Egy SaaS scale-up egy saját számlázási modul fejlesztésére szerződik

Egy B2B SaaS scale-up, amely HR-menedzsment szoftvert ad ki, körülbelül 40 alkalmazottal és 500 aktív ügyféllel, szeretné externalizálni egy automatikus számlázási modul fejlesztését, amelyet az alapvető produktumára integrál. A fix áras költségvetés 35 000 € HT 4 hónap fejlesztésre.

Formalizált SOW nélkül az első hetek feltárják a nagy eltéréseket: a szolgáltató úgy véli, a Stripe API-integráció nincs a hatókörben, míg az ügyfél azt hallgatólagosan benne lévőnek tartja. A vita egy 8000 €-s túllépésről a 2. sprint alatt kitör.

Egy szóló szállítási táblázatot, pontos elfogadási kritériumokat és kifejezetten tartalmazott harmadik féles integrációk listáját tartalmazó strukturált SOW-val ezt a vitát elkerülik. A Change Order záradék aláírt módosítást igényel bármely hatókör-kiegészítéshez. Az ilyen kontextusban tapasztalt eredmények: a projekt során a viták csökkenése 70-85% és a termelésbe helyezésig 2-3 heti nyereség, a SYNTEC Numérique 2023 felmérése szerint.

Eset 2 — Egy ipari csoport biztosítja a jogokat egy egyedi ERP-hez

Egy közepes méretű ipari csoport (körülbelül 800 alkalmazott, 3 termelési hely) egy webes fejlesztési ügynökségtől egy saját ERP-rendszer fejlesztésére szerződik 180 000 € HT-ert. A misszió 18 hónapig tart. A projekt vége felé az ügynökség egy konkurens által felvásárolva. A csoport akkor jól vesz észre, hogy az eredeti szerződés szellemi tulajdon záradéka nem fedte az alvállalkozóként a projektben szereplő két szabadúszó által fejlesztett modulok jogainak cédálását.

Egy jól megírt SOW előírta volna: az összes szállítást, beleértve az alvállalkozók által előállítottakat, fedező cession-záradékot, a fő szolgáltató kötelezettségét egyenértékű cessions elvégzésére az alkalmazottaitól, és egy kód-letét mechanizmust a kontroll megváltoztatásakor. A droit du numérique-ban szakosodott ügyvédi irodák által dokumentált hasonló helyzetekben a viták és a részleges újrafejlesztés költsége rendszeresen meghaladja a projekt költségvetésének 30%-át.

Eset 3 — Egy digitális ügynökség standardizálja a SOW-okat az eladások felgyorsításához

Egy 15 főből álló webes ügynökség évente átlagosan 25 fixed-price projektot valósít meg, 8000-60 000 € HT költségvetéssel. A vezetés azt tapasztalja, hogy az SOW tárgyalása és aláírása az ügynökség és jogi részből átlagosan 4 óra/projekt, körülbelül évi 100 óra elveszítve.

A standardizált SOW-minta alkalmazása, minden egyes misszió típushoz (vitrin weboldal, webalkalmazás, e-commerce, API) illeszkedő záradék-generátor és az elektronikus aláírás telepítése az dokumentumok távelérésű véglegezésére, az ügynökség ezt az időszakot 45 percre csökkenti SOW-nként. 25 éves projekt alapján körülbelül 55 órát nyernek vissza, vagyis egy hét-munka nyeresége. Az elektronikus aláírás a küldés és az effektív aláírás közötti időszakot 8 napból átlagosan kevesebb, mint 24 óránkénti időre csökkenti, gyorsítva a projektindítást és javítva a pénzáramlást.

Összegzés

Egy teljes webes fejlesztő SOW-t megírni egy fixed-price projekthez nem adminisztratív formalitás: ez az a dokumentum, amely megalapozza a szerződéses viszonyt, amely megelőzi a szállítások körüli vitákat, garantálja a forráskód hatékony cédálását és mindkét felet védi az esetleges nézeteltérésben. A SOW-jainak viadalapozása az öt oszlop — felek azonosítása, szállítások hatóköre, objektív elfogadási kritériumok, ütemezett pénzügyi feltételek és részletezett szellemi tulajdon záradékok — körül az azt adja a projektnek a legjobb esélyeket, hogy zökkenőmentesen haladjon.

A Certyneo minden lépésben támogat: a draft generálásától az AI-alapú szerződés-generátoron az eIDAS-nak megfelelő elektronikus aláírásig a platformon, az aláírt dokumentumok biztonságos archiválásán keresztül. Fedezze fel ajánlatainkat a Certyneo díjszabása oldalon és kezdje el a misszióit ma biztosítani.