Ti hogyan kezdtek egy új projectbe?

Mivel pétékás ügyletről van szó, sok értelmét nem látom a szerződésmintának, mert amire az egyik helyből rábólint, az a másiknak nem, vagy nem úgy tetszik, a harmadik meg belevenné még a saját szempontjait, amelyek véletlenül sem ugyanazok, mint amit a negyedik tenne hozzá.
Lakásvásárlási szerződésnek is inkább a szempontjai lényegesek, mert a konkrét minták konkrétan senkinek sem jók.
Itt viszont a szempontokat leírtad: pénz előre vagy folyamatosan, revideálás árazásába/időzítésébe mennyire belevenni, hogy más későbbre tervezett munkáid viszont csúszni/elveszni fognak ezért - "csak" meg kell tudni egyezni.

Egyébként aki úgy kezdi, hogy "egyszerű feladat", az nem szerződő partner, hanem lókupec, és csak akkor szabad vele dílelni, ha nagyon nincs más.

Ha jól tudom, pont az ilyen esetekre jók az agilis módszertanok, pl. scrum.

"1. Ti hogyan, milyen fomában kéritek be Ügyféltől az elvégzendő munka specifikációját?"

Sehogy, leülök a megrendelővel átbeszélni a feladatot és magam specifikálok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem csak a feladatot kell írásban specifikálni, hanem a közös együtt dolgozás módját és az árképzés,
módosítási lehetőséget, szabályát is kell a szerződésben rögzíteni. Fel kell hívni a megrendelő figyelmét, hogy mi van a túlmunka esetén vagy a későbbi átvétel utáni, bevezetéskor kiderülő módosítási igények esetén.

pl:
- ha menet közben felmerül változtatás, akkor azt kategorizálom és meghivatkozom a vállalkozási szerződés idevonatkozó pontját:

1./ kategória: még nem tartok ott és a módosítás nem olyan jellegű, hogy többlet költséget generáljon.

2./ kategória: 5óra plusz munka, amely díja xxx,- Ft a szerződés Y. pontja szerint, kérem az elfogadását.
- Ha elfogadja és írásban visszajelzi, akkor lehet dolgozni és majd számlázni.
- Ha nem fogadja el, akkor: vagy kimarad vagy alternatíva keresése.

3./ kategória: a rendszer alapjait érinti, újra kell írni az egészet.
itt már nagy anyázás van.. rossz volt a specifikáció, félreértés stb...
Azonnali megbeszélés összehívása, olyan kérdésekre válasz keresés:
- ki miben felelős, meghiúsulás, elállás, kártérítés, - ennek az esetnek is szerepelni kell
a szerződésben.

vagyis minden a szerződésen múlik, azt kell jól megírni és nem egyből aláírni..

kieg:
- Szintén magam specifikálok, az ügyfél fogadja el - írásban, hogy erre gondolt.
- Egy listát készítek, hogy milyen infot kell, hogy átadjon a megrendelő,
milyen határidőkkel, hogy el tudjam készíteni a specifikációt v. a munkát.

kieg 2.:

- ha a szerződéskötéskor a tisztelt megrendelő nem fogadja el, hogy lehet pluszmunka, aminek díja van
akkor azzal nem kell foglalkozni és ez már a szerződés kötéskor kiderül..
vagy felvállalod és ennek tudatában dolgozol.

Lehet, hogy csak a sok rossz tapasztalat beszél belőlem, de én ezek szerint az irányelvek szerint járnék el:

- itt írta már valaki, hogy először egyeztess, utána ennek megfelelően elsődleges specifikáció, rendszerterv, stb., ha ezt elfogadják, akkor lehet menni tovább.
- Ha megvan, hogy mi a szerződés tárgya, akkor szerződéskötés, a szerződés része a részletes és pontos specifikáció (olyan szintig, hogy mondjuk a login screen-en a mezők neve mellett a "login" vagy a "felhasználónév" szöveg szerepeljen), ami innentől kőbe van vésve, hogy mit kell csinálnod. ha menet közben jut eszébe, hogy alma helyett körtére vágyik, akkor nyugodtan lehet neki mondani, hogy almára szerződtetek, de persze rugalmasak vagytok módosíthattok szerződést és specifikációt, ami viszont az árat is módosíthatja. Mert ha kiderül, hogy az eredeti zsebóra helyett toronyórát akar, az neked is jelentős többletköltség. De ha csak másik lánccal szeretné a zsebórát, az még bele is férhet az eredeti árba.
- fontos, hogy amikor egy mérföldkőhöz értek íratsd alá velük a teljesítési igazolást!!! Ez nagyon fontos, nem szabad kihagyni! Enélkül hiába számlázol, hivatkozhat arra, hogy nem megfelelően teljesítettél, nem veszi át, nem hajlandó kifizetni, stb. és jól megszívod.
- Én minden mérföldkőnél számláznék, mert egyrészt kisebb pénzeket könnyebb behajtani/behajtatni.
Másrészt, ha már az első részteljesítésnél bajok vannak a fizetéssel, az előjel, hogy jó lesz óvatosnak lenni. És így ha esetleg meghíusul a projekt, akkor pedig nem buksz el egy teljes projektnyi időt, pénzt és energiát, tehát a saját károdat tudod ezzel csökkenteni. Ha megcsinálod egyben az egész projektet, leadod és b@sznak kifizetni, ami Magyarországon inkább "üzemszerű működés", mint néha előforduló probléma, akkor azon kívül, hogy egy fillért se látsz a projektből, még jókora károd is lesz. Mert a projekt alatt felhasznált erőforrásokat (rezsi, munkabér, alvállalkozók díja, esetleg beszerzett hardverek költsége, stb.) részben vagy egészben ki kell fizetned, bevételed meg nulla.
- Az meg alap dolog, gondolom mondanom sem kell, hogy _mindent_ dokumentálj írásban, hogy legyen nyoma, főleg a megrendelővel történt kommunikációt. Egyrészt, hogy tudd kezelni a helyzetet, hogy ha kezdődik, hogy a telefonba nem azt mondta, nem úgy kérte, stb. történet. Másrészt ha jogi útra terelődik a dolog nem fizetés miatt, akkor tudd bizonyítani, hogy pl. bizony te a szerződés szerint teljesítettél.

Az ilyen "csak egy egyszerű feladat" szokott az esetek 99%-ában odáig fajulni, hogy a végén azon kapod magad, hogy egy két óra alatt összerakható alkalmazás helyett már mondjuk egy komplett vállalatirányítási rendszert próbálnak lefejlesztetni veled, a kétórás munka áráért. Szóval ezzel csak nagyon nagyon óvatosan! Welcome to Hungary, Neo! :(

Mostanság van egy hetidíjam, és megbecsülöm, hogy hány hétbe kerül egy adott feladatkupac. A becslés általában fél/egy hétig tart. Természetesen fizetős. Aki kifizeti ezt az első etapot, az kap egy dokumentációt a további munkákról, hét/feladatokra lebontva. Szorozhat, hogy mennyibe kerülne nálam, vagy használja a feladatlistát egyéb vállalkozók beszervezésére/alkudozásra. Többnyire képtelenek/nem akarják átlátni/összegyűjteni az igényhez kapcsolódó feladatokat, nekik már sok segítség ez a lista is. :)

Túl sokan próbáltak már túl sok dolgot kapni az elején kialkudott pénzért, aminek a vége csak bosszúság volt mindkét részről.

subs

Én arra felé szoktam terelni a dolgokat, hogy minél többet tudjak a problémáról mire szerződéskötésre kerül sor. A tervezés első fázisát így kockáztatod, hogy ingyen lesz, de kevésbé futsz zátonyra.
Ha van a projektben olyan technológia, amivel még nem dolgoztam (vagy még senki sem csinált a világon hasonlót), és ezért kockázati tényezőnek tűnik, akkor azt a technológiát még a megbeszélések alatt megpróbálom megismerni, akár tech-demó szintjéig is eljuttatni. Ezt egyedül szoktam csinálni akár durva túlórázással is. Ha ezt megcsinálod, akkor jobban tudsz időt becsülni is, illetve tudod ha nemet kell mondani. Ez igencsak költséges rövid távon, és a bebukott projekteket "továbbképzéshez" kell könyvelnem magamban, de hiszek ebben.

Néhány tanács a szerződéshez - amit más nem írt még:
* A nem fizetés esetére írt kamatnak nagyobbnak kell lenni a jegybanki alapkamatnál, mert a jegybanki alapkamat kisebb, mint a bankokban elérhető hozam :-).
* Ha előír a szerződés olyat, hogy nem dolgozhatsz konkurrenciának x ideig, akkor azt meg kell fizettetni.

Lean, Scrum, Agile... erre felé kell terelni az ügyfelet. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Előttem szólok sok okosat leírtak, így igyekszek röviden válaszolni.
Az egyszerű feladat sose egyszerű.

1. Az ügyfél általában nem tudja, hogy mit akar pontosan, nem képes megfogható definíciókat adni. Ezért előbb meg kell ismerned az ügyfeled, az ő tevékenységét, céljait. Ez után jöhet a konkrét projekt felvázolása, amikor is neked kell kérdésekkel rávezetned az ügyfelet az elérendő célok konkrét megfogalmazására. Akár 50-100 kérdést is fel kell tenned, amíg kialakul egy kép az ügyfélben. Természetesen ezt a specifikáció készítést is be kell építeni a árba. Viszont nem érdemes az árajánlati fázisban teljes specifikációt készítened. Egyrészről ez időrabló, másrészről az ügyfélben kialakuló kép elég gyorsan változhat a kérdések hatására.
2. A szerződés változó - kinek mi tetszik. Mindenképp megfogható konkrétumokkal kell megtölteni a szerződést. Pl: "divatos megjelenésű weboldal" - ez nem konkrét, túlságosan megengedi a megrendelő és fejlesztő szárnyalását is. Nem baj, ha 30-40 oldalas a szerződés. Ezzel csak bebiztosítod magad.
3. Ez feladat és ügyfélfüggő. Nagy projekt esetén érdemes mérföldkövekre bontani. 10-20e Ft-os darabokra semmiképp se vágj fel egy 1 millió Ft-os projektet :).
Előleget nem érdemes kérni - esetleg ha tárgyi eszköz beruházás, kapcsolódó szolgáltatás is része a projektnek (pl: szerver vásárlás, licenszek beszerzése stb.).
4. Itt jön képbe a jó specifikáció. Nyilván apróbb változtatásokat érdemes belevenni az eredeti szerződésbe és árajánlatba (pl: egy gomb színe változtatásra kerül). Ha nagyobb változás jön képbe (pl: xy modul kifejlesztése/rendszerhez illesztése), akkor ezt egy új szerződéssel tudjátok legegyszerűbben kezelni. Ekkorra már úgyis jobban ismered az ügyfelet, a projekt sarokpontjait, így könnyebben is tudod árazni, mint az elején.
5. Sajnos kivédeni nehezen tudod. Nem minden feladatot tudsz/érdemes alvállalkozónak adni. Pl: a hardveres infrastruktúrát kompletten kiadhatod alvállalkozónak, nem kell különösképpen beavatnod őt a szoftveres részletekbe. Viszont mondjuk egy új modul/funkció mentén nem feltétlen érdemes alvállalkozósdit játszani. Arról nem is beszélve, hogy itt is szerződések kellenek, felelősségi és hatásköri vonalakat kell definiálnod, ami előhozhatja későbbiekben a problémákat (pl: licenszelési kérdések, adatvédelem, későbbi hibajavítás stb.). Bizalom nélkül az alvállalkozósdi nem megy...

Az egésznek az alapja a párbeszéd írásban és szóban is. Az árazás tekintetében pedig adj súlyt a feladatnak, ne hagyd, hogy lehúzzanak. Éreztetsd az ügyféllel a projekt komolyságát, alkalmazz olyan árakat és feltételeket, amelyek kölcsönösen elégedetté tesznek téged és az ügyfeled is. Árazhatsz óradíj és teljesítménydíj alapon is - projektfüggő.
Ha azt érzed, hogy a projekt hosszú távra szól, akkor ennek megfelelően alakítsd a feltételeket is.

A nulladik kör egy becslés, hogy mennyibe kerülhet a projekt. Általában már ettől a számtól elalélnak és csak nagyon kis százalék kezdi el a megvalósulást. Nagyjából konkrét példa: "szeretnénk N darab szerver, backuppal minimum 10/7-es felügyelettel és következő munkanapi hibaelhárítással". Na itt már a vállalható szerverek árától hanyatt szoktak esni, pedig nem is pakoljuk meg őket észnélkül. :) Aztán kiderül, hogy a valakicsodájuk remek árat adott N darab desktop pc-re, mint szerverre és viccesen alacsony telepítési és karbantartási díjra.

A munkadíjat mindíg adott munkafázishoz kötjük, több okból is. Az egyik, hogy folyamatosan kell finanszírozni a projekt kivitelezését is és igazán kevés hazai engedheti meg magának, hogy milliókat finanszírozzon előre. (Aki már próbált komoly szervert venni, csak úgy beesve az ajtón az tudja, hogy előre utalás van mindenhol...). A másik a bizalom, mert akármilyen remek partner, már a 100e nettó körüli számlákkal is könnyen lehet probléma és remekül ki lehet kötni, hogy ha a részszámla fizeteséssel "X napon túli késedelembe esik", akkor leáll a projekt és a végső határidő is rögtön ennyivel módosul.

A felmerülő újabb kivánságok, mint extrák szerepelnek az eredeti tervhez képest, egyedi árral. Ha nem extra dolgok, pl. "jah persze legyen HTTPS is", akkor semmi, nem egy meghatározó tényező, persze a szimpatikusnak vélt tanusítványt fizeti a T. megrendelő.

Alvállalkozóból csak régi megbízhatóval dolgozunk, akit már előtte is ismertünk. :) (Tudom, valahogy akkor is meg kellett ismerni, hát nem könnyű...)

Az ilyen "szerződésminta", meg egyéb minták gyűjtése nem fog előre vinni. Tessék szépen kiokoskodni. A magyarorszag.hu van egy halom minta mindenféle szerződési témában, azok jó kiindulópontok. A konkrét munkát meg csak te fogod tudni. Fix szerződés 200e nettó felett kell hivatalosan, de 100e-től, illetve ügyféltől függően ajánlott.

Illetve a másik oldalról, amikor kiadtunk egy fejlesztést (tanulságos volt):

- készítettünk egy pdf fájlt, elég részletesen leírva, hogy mit akarunk
- meghirdettük a feladatot, vázlatosan leírva, hogy miről van szó
- a jelentkezőknek elküldtük a pdf-et
- a reakciókból már nagyjából sejthető volt, hogy felfogták-e, hogy mit akarunk
- hárman jelentkeztek személyes konzultációra, egyiknek olyan kérdései voltak, ami alapján egyértelmű volt, hogy nem érti, hogy mit akarunk, a másik marha drágán vállalta volna (úgy rémlik), a harmadik tulajdonképpen nem kérdezett semmit, csak megcsinálta határidőre a specifikációnak megfelelően.

A tanulság az volt, hogy a bitre egyező pdf-ből melyik fejlesztő(cég) mit szűrt le. Nem állítom, hogy a másik két cég nem értett volna hozzá, ám az egyértelmű volt, hogy kivel tudunk együtt dolgozni, ki érti meg, hogy mit és hogyan akarunk. És szerintem elég egyértelműen fogalmaztunk a pdf elkészítésekor.

Illetve az is tanulságos volt, hogy - legalábbis az egyik cég - erőltette a saját elképzelését, azaz helyből rettenet drágán fejlesztettek volna egy javás szervervalamit, javás klienssel, holott nekünk a célunk egyáltalán nem ez volt (tisztán html a kliensoldalon, a lehető legkevesebb js, ami egy verzióval később kissé eltolódott a js felé), és nem nagyon vette figyelembe, hogy mi mit akarunk. A nyertes cég meg kb. csak annyit kérdezett, hogy van-e valami nyelvi elvárásunk amit szeretnénk, mert nekik van egy javaslatuk, de ahhoz nem ragaszkodnak.

Sajnos a harmadik cég (fő?) fejlesztője mára már kilépett, és már csak hobbiból folytat fejlesztői munkát, tudományos pályán él tovább.