forrás: Facebook

Született itt egy poszt egy megrendelő és egy fejlesztő közötti vitás kérdésről. Egészen meglepett a kommentek száma és tartalma, látva, hogy mennyien kezdenek bele rosszul egy ilyen projektbe. Most összeírok pár pontot a tapasztalataim alapján, a kommentekben írt esetek fényében úgy gondolom, hogy hiánypótló lesz.

1. A projekt

a.) Ha van egy ötleted, az még nem projekt. Mielőtt bármihez kezdenél, gondold át a megvalósíthatóságot, rendelkezésre álló erőforrásokat, időt, stb.

b.) Minden projekt csúszik, a projektek egy jó része sosem készül el. Érdemes rászámolni minimum(!) 30%-ot ráhagyásnak mind időben, mind pénzben egy projektre (az se baj ha ennél többet számolsz rá).

c.) Tervezz meg mindent, készíts specifikációt, legyen üzleti terved, stb. Ha nem értessz hozzá, akkor legyen az a 0. lépés, hogy valakit felkérsz, hogy készítsen specifikációt és projekttervet.

d.) Kerüljük el az “ide kéne még egy gomb ami azt csinálja…” dolgokat, mert aztán lesz értetlenkedés, hogy miért kerül plusz egy gomb 700 000 Ft-ba… Ebből lesznek az összeveszések.

e.) A wireframe, layout, design legyen meg a specifikációval együtt, ne menet közben ötletelj, sőt menet közben NE ötletelj. Úgyis fogsz menet közben ötletelni, szóval most szólok, hogy márpedig menet közben ötletelni meglepően drága lesz.

f.) Ne hidd el, hogy valami 10 óra alatt készen lesz. Vagy 150 000 Ft-ért készen lesz. Akinek 15 000 Ft-os órabére van az 150 000 Ft-ért le sem ül veled egyeztetni.

g.) Ha 15 000 Ft-os órabéred van nehogy leülj egyeztetni 150 000 Ft-ért…

h.) MVP-ben gondolkodj. Ne egyből a végleges, minden funkcióval telepakolt változatot akarj – ez tipikus bukó. Legyen egy minimálisan működőképes termék (Minimum Viable Product), amit gyorsan le lehet tesztelni, és amiből tanulni lehet.

i.) Dokumentálj mindent. Még ha csak egy megbeszélésen hangzott el egy apró részlet, akkor is legyen nyoma írásban. Egy év múlva senki nem fog emlékezni, mit ígért vagy értett félre.

2.) A szerződés

a.) Mindig legyen szerződés! Nem egy nagy cucc megírni és sokszorosan megtérül.

b.) A szerződés KÖTELEZŐ melléklete a specifikáció!

c.) A szerződést csak írásban lehessen módosítani és ezt tartsátok is be

d.) Legyenek mérföldkövek, és azokhoz kötött pénzügyi teljesítés

e.) Legyenek egyértelmű határidők, legyen egyértelmű, hogy mi számít teljesítésnek. A teljesítési igazolás nem egy plusz bürokratikus fecni, csak akkor írjuk alá ha tényleg igazolhatóan teljesítve lett az adott feladat

f.) Legyen kötbér. Mondjuk a napi kötbér legyen projekt értékének 1-2%-a, de minimum 10 000 Ft/nap

g.) Legyen maximalizálva a kötbér, mondjuk a projekt teljes összegében, vagy annak valamennyi százalékában

h.) ha kötbér is van, előleg is legyen. Akár 10-30-50%. A projekt méretétől függően.

i.) Szellemi tulajdonról rendelkezni kell. Pontosan tisztázni kell, hogy mikor kerül a forráskód, grafika, dokumentáció stb. tulajdonba, illetve mit jelent a tulajdon (pl. módosíthatóság, újrafelhasználás joga). Itt szokott lenni a legtöbb félreértés.

j.) Verziókezelés, hozzáférés. Egyre több vita van abból, hogy a fejlesztő nem adja át a kódot, vagy a staging szerverhez sincs hozzáférés. Ezeket előre rendezni kell.

3.) A háttér

a.) kérj referenciát és ellenőrizd is le

b.) ellenőrizd le a fejlesztő céges hátterét (hiába tartozik majd 43M Ft kötbérrel, ha egy 3M Ft Kft aminek a teljes vagyona 700 000 Ft…)

c.) ellenőrizd le a megbízót is. Ő se egy 500 000 Ft-os éves forgalmú Kft-vel bízzon már meg egy 40 milliós projektre

d.) Legyen gyanús ha megkezdett projektet kell befejezned mert az előző fejlesztő “hülye/szemét/megbízhatatlan” volt

e.) Legyen gyanús ha a fejlesztő panaszkodik a régebbi megbízókra

f.) Ne csak technikai, hanem kommunikációs készségeket is nézz. Hiába profi fejlesztő valaki, ha nem tud hatékonyan kommunikálni, a projekt garantáltan stresszes és lassú lesz.

4.) A vitás helyzetek

a.) Mindig közbejöhet valami, bármelyik félnek. Piaci, technológiai változások, magánéleti problémák, stb. Mindkét félnek van kockázata, ezt el kell fogadni!

b.) Ne utólag vergődj. Legyen a szerződésben leírva MINDEN.

c.) Ha rossz tapasztalatod volt egy céggel/megbízóval/alvállalkozóval vagy bárkivel, megírhatod, de szálmoj vele, hogy akár a valós tények közlésével is megsértheted valakinek a jó hírnevét

d.) Kártérítést csak bizonyítottan okozott kárért kérhetsz. Elmaradt haszonért, mindenféle lelki bántalmakért nagyon nehéz lesz.

e.) Pereskedni 1-2 év minimum, ha mindkét fél konstruktív. Ne pereskedj, egyezzetek meg ha lehet. Ha itt tart a dolog, akkor már kármentés van, minimalizáld a károdat, ne megnevelni próbáld a másikat, ne az igazságot keresd, hanem a pénzedet! Vagy tudd és fogadd el, hogy igazságot osztani drága lesz és nem térül meg se időben, se pénzben.

f.) Nem, nem törölheted le a weboldalt/alkalmazást satöbbi ha nem fizet a megbízó! Kivéve, ha a szerződés ezt külön rendezi. Szóval rendezze. Vegyétek bele, hogy nem fizetés esetén korlázozható a szolgáltatás, vagy, hogy a szoftver tulajdonjoga csak a végszámla kifizetését követően kerül a megbízó tulajdonába

g.) Ha nincs projektmenedzser, akkor valaki legyen, aki végigviszi a projektet. A megrendelő nem mindig jó ebben, a fejlesztő sem mindig akar ezzel foglalkozni. Ha nincs egy “feje” a projektnek, szétesik.

h.) Ne gondold, hogy a másik fél “úgyis tudja, mire gondolsz.” A legtöbb vita abból van, hogy nem ugyanazt értik egy-egy funkció vagy cél alatt. Nincs olyan, hogy valami evidens. SEMMI SEM EVIDENS! Minden legyen úgy leírva a specifikációban, mintha egy űrlénynek lenne elmagyarázva. Ami nincs így leírva azt számold bele a kockázataidba, mert nem biztos, hogy a másik félnek is evidens