Szoftverfejlesztés megrendelése: hogyan ne csússzon el?

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?

Írd le az igényt felhasználói történetekben, átvételi feltételekkel.
Kérj kattintható prototípust a fejlesztés előtt.
Határozd meg a legkisebb működő változatot, és tedd a többit egy későbbi listára.
Válassz szerződési formát, például fix áras felmérés, utána óradíjas fejlesztés rövid szakaszokban.
Rögzítsd a szerződésben a jogokat, a forráskódot, a dokumentációt és a kilépést.
Jelölj ki belső felelőst, akinek van ideje minden ciklus után tesztelni.
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 és az IT tanácsadási 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.