Az egyik fejlesztői Facebook csoportban jött szembe egy poszt egy megrendelő és egy fejlesztő közötti vitás ügyről. Ami igazán meglepett, az nem is maga a történet volt, hanem a kommentek mennyisége és tartalma. Elképesztő, hányan vágnak bele rosszul egy ilyen projektbe – és aztán csodálkoznak, hogy baj lesz belőle. Az alábbi írás mindkét félnek szól, a megrendelőnek és a kivitelezőnek is.
Úgyhogy a korábbi tapasztalataim alapján, az eredeti poszt alatti kommentek fényében össze is írtam pár pontot egy facebook poszt formájában, ezt most megosztom (picit átszerkesztett formában) itt is. Aki most indulna neki egy fejlesztésnek (vagy már benne van), annak talán hiánypótló lesz.
1. A projekt – avagy hogyan NE kezdj bele
a.) Ha van egy ötleted, az még nem projekt. Előbb nézd meg, megvalósítható-e. Van-e rá időd, pénzed, energiád?
b.) Minden projekt csúszik. Egy jó részük soha nem is készül el. Számolj minimum 30% ráhagyással – időben és költségben is.
c.) Legyen specifikáció. Üzleti terv. Projektterv. Ha nem tudod, hogyan kell, akkor az első lépés, hogy valaki segít ebben.
d.) Kerüld az „ide kéne még egy gomb” típusú gondolkodást. Egyetlen plusz funkció komoly pénz lehet. Ne ezen menjen el a projekt.
e.) A wireframe, a layout és a design legyen kész már a specifikációval. Ne ötletelj menet közben – mert úgyis fogsz, és az nagyon drága lesz.
f.) Ne dőlj be annak, hogy „ez 10 óra alatt megvan”. Akinek 15 000 Ft-os óradíja van, az nem fog 150 000 Ft-ért neked dolgozni.
g.) És ha neked 15 000 Ft-os óradíjad van, ne is vállalj ilyen melót.
h.) MVP-ben gondolkodj (Minimum Viable Product). Ne akarj mindent egyszerre. A bukás egyik biztos receptje.
i.) Dokumentálj mindent, még a kávészünetben elsuttogott ötleteket is. Egy év múlva senki nem fog emlékezni, mit értett félre.
j.) A kód legyen dokumentálva, kommentelve. Ha fejlesztőt elüti a villamos, ne álljon meg a világ.
2. A szerződés – ne spórold meg
a.) Mindig legyen szerződés! Nem nagy ügy, de rengeteg fejfájástól kímél meg.
b.) A specifikáció a szerződés kötelező melléklete.
c.) Csak írásban lehessen módosítani a szerződést – és ezt tartsátok is be.
d.) Legyenek mérföldkövek és azokhoz kötött kifizetések.
e.) Határidők, teljesítés meghatározása. A teljesítési igazolást csak akkor írd alá, ha tényleg kész van, amit kértek.
f.) Legyen kötbér – pl. napi 1-2%, minimum 10 000 Ft.
g.) De legyen a kötbér maximalizálva is (pl. a projekt értéke vagy annak egy része).
h.) Ha kötbér van, legyen előleg is – 10-30-50%, a projekt méretétől függően.
i.) A szellemi tulajdon kérdését pontosan rendezzétek. Mikor, mi kerül kinek a tulajdonába, mit jelent a „tulajdon” (pl. módosíthatóság)?
j.) Verziókezelés, hozzáférés. Ez nem utólagos vita tárgya, hanem előre tisztázandó.
3. A háttér – ellenőrizz, ne bízz vakon
a.) Kérj referenciát – és ellenőrizd is le.
b.) Nézd meg a fejlesztő cég pénzügyi hátterét. Hiába a 43M Ft-os kötbér, ha egy 3M-s Kft. van mögötte.
c.) A megbízót is nézd meg. Egy 500 000 Ft-os éves forgalmú cég ne adjon 40 milliós megbízást.
d.) Legyen gyanús, ha egy projektet „az előző fejlesztő miatt” kell befejezni.
e.) Ha a fejlesztő minden korábbi ügyfelére panaszkodik – szintén legyen gyanús.
f.) Nézd meg a kommunikációs készségeket is. Ha valaki nem tud normálisan beszélni, abból csak szenvedés lesz a projekt.
4. A vitás helyzetek – készülj fel, hogy lesznek
a.) Bárkivel bármi történhet. Fogadd el: minden projekt kockázatos.
b.) Ne utólag sírj – írj le előre mindent.
c.) Panaszkodhatsz, de vigyázz: még az igazság közlése is jogsértő lehet, ha valakinek a jó hírnevét sérti.
d.) Kártérítést csak konkrét, bizonyított kárra lehet kérni. Elmaradt haszon? Lelki sérelmek? Nehéz ügy.
e.) Pereskedés? Minimum 1-2 év. Ha idáig jutottatok, már kármentés van. Próbálj megegyezni. Ne igazságot keresni, hanem megoldást.
f.) Nem, nem törölheted le a rendszert, ha nem fizetnek. Hacsak nincs benne a szerződésben. Szóval legyen benne.
g.) Ha nincs projektmenedzser, legyen valaki, aki viszi a projektet. Különben szétesik.
h.) Ne gondold, hogy „úgyis tudja, mire gondoltam”. SEMMI SEM EVIDENS. Minden legyen leírva, mintha egy űrlénynek magyaráznád.
Ha csak egy dolgot viszel el ebből a listából: minden sikeres projekt a tervezésnél dől el. És minden balhé ott indul, hogy valamit nem beszéltek meg rendesen.
Ha szeretnéd, szívesen írok belőle egy letölthető ellenőrzőlistát vagy projektindító segédletet is.
You said:
túlságosan átfogalmaztad. Csak kicsit tördeld ha kell, meg javítsd az elütéseket
ChatGPT said:
Rendben, íme a blogposzt minimálisan formázva és az elütések javításával, az elején a kért átfogalmazással:
Amikor egy fejlesztési projekt félremegy – pár gondolat a gyakorlatból
Az egyik fejlesztős Facebook csoportban volt 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 értesz 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.
j.) Legyen jól dokumentálva és kommentelve a kód, hogy ha elüti a villamos a fejlesztőt, akkor lehessen folytatni.
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 a 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ámolj 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 stb., 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átozható 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. 🙂