Szoftverfejlesztési szerződés paraméterek

Én azt mondanám, hogy pontosan kéne definiálni a dolgokat. Azt viszont bele lehet venni, hogy ha segfault-ol, az bug.

Irass a megrendelovel egy rendszertervet, amiben pontosan megjelolitek, hogy mi a software elvart mukodese. Miutan kialakult a vegleges, olyan szerzodest kell kesziteni, amiben ez benne van. Es ha kesobb akar valamit, hogy az mondjuk ellenorizze, hogy pl. a pirsoka nem legalis nev, az szerzodesmodositas. De persze en nem ertek hozza, szal most joesellyel nagy hulyeseget irtam :)

Persze ha a spec. nem egyertelmu, akkor nyilvan azt nem kell elfogadni.

Hali!

A speckó sosem elég részletes (legalábbis a tapasztalat ezt mutatja). :-)

Ilyenkor jól jöhet, ha beleteszed a szerződésbe, hogy a nem egyértelműen vagy nem elég pontosan meghatározottt részleteknél fenntartod a jogot, hogy a speckót a magad felfogásában értelmezd és eszerint dolgozz. Persze ilyenkor is kell egyeztetni velük amikor kiderül egy ilyen probléma, de jó, ha az ilyen esetek kezelésének a szerződésben is van nyoma. Egy ilyen akkor lehet kellemetlenebb a számodra, ha valami tisztázatlan részlet kapcsán komoly pluszmunka jelentkezik, mert pl. kiderült, hogy amit ők ott elképzeltek, az még további két hónap kemény kódolást igényel a te általad elképzelt egyszerű megoldás helyett. Ekkor lehet arra hivatkozni, hogy az idő- és költségbecslésedet az egyszerűbb verzióra számoltad, és lehet kiegészítő megállapodást kötni. Vagy áttenni egy következő verzióba a feature-t, ha ez megoldható.

További módszer lehet, hogy a becslésedebe explicit beleteszel egy 5-20%-os ráhagyást (feature buffer) pont az ilyen esetek kezelésére. Ezt természetesen az eredeti becslés teljes idején felül (ami ugye már eleve tartalmazza a 2.5-ös szorzót).

-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "