HTML

Agilitás Blog - az agilitas.hu blogja

Agilis módszertani cikkek, újdonságok, vélemények, intejúk, szoftverek, eszközök és technikák - a gondolkodó, tapasztalt tanácsadók szemével.

Friss topikok

  • kulcsár bence: @Borbándy László: kezdem sejteni, van vagy 4 borbandy laszlo es vagy 6 kulcsar bence a facebookon.... (2013.03.11. 22:51) A UserStory feldarabolás 10 stratégiája
  • Janovszki Zsolt: időnként jó ezt újra meg újra végiggondolni, most pont egy prezentációhoz kellett, gondoltam gondo... (2013.03.04. 23:14) Agile Principles - magyarul
  • kulcsár bence: A cikk célja az volt, hogy a lehető legszélesebb áttekintését adja az agilis szerződéseknek. Jó öt... (2011.02.15. 11:08) Agilis szerződések
  • kulcsár bence: A kérdés jó. Először is tisztázni kell, hogy a csapat agilis csapat-e. A mi esetünkben igen, ami r... (2011.02.08. 23:26) Az önszervező csapat sikerfaktorai
  • Janovszki Zsolt: @sipos_zoli: ott a két pont. Kérlek járuljatok hozzá az átadás dokumentálásához, amire a mai napon... (2010.12.08. 13:01) Szerintem félreértelmezi

Linkblog

Agilis szerződések

2011.02.14. 10:16  kulcsár bence

Az agilis projektek egyik kulcskérdése maga a szerződéses viszony. A következő cikkben Allistair Cockburn számos érdekes szerződéstípust felvonultatva ad áttekintést az agilis projektek szerződés modelljeiről.

Fix ár, fix feladatkör (esetleg fix határidő)

Ez egy régi típusú szerződés: igyekezz legjobb tudásod szerint (mindegy, milyen módszerrel) árajánlatot adni a projektre. Amint benne vagy a projektben, iktass ki mindent, ami fölösleges, használd a legjobb agilis technikákat (lásd még: Process: the 4th dimension), hogy a lehető legjobb eredményt produkálhasd. Tapasztalat szerint az agilis technikák nem befolyásolják egy projekttel kapcsolatos előzetes becsléseket. Leghőbb vágyunk ellenére a projektbecslés még mindig leginkább azon múlik, ki mennyire tapasztalt, milyen megérzései és tippjei vannak. A minden szempontból “fix” projektszerződéseknek akkor van értelme, ha az elvárások nagyon stabilak. Akkor is használnak ilyen szerződést, ha a két fél nem bízik egymásban, noha még egy ilyen megállapodásban is bőven vannak kiskapuk, amikkel bármelyik fél hátrányos helyzetbe hozhatja a másikat, ha éppen ez a célja.

Fix ár, fix feladatkör (esetleg fix határidő), de a megrendelővel együttműködve a feladatkörök átalakíthatók

Kockázatos megoldás, bár már többször láttam sikeresen működni: kétszer kereskedelmi projektekben, és egyszer egy állami projektben. Jeff Patton leírja, hogyan működött együtt a megrendelővel a projekt kezdetén, hogy beazonosítsák az igényeket, kívánságokat és prioritásokat. A projekt előrehaladtával Jeff gondoskodott róla, hogy mindig a legfontosabb elemeken dolgozzanak. Ahogy közeledett a határidő, és világossá vált, hogy néhány részletet még nem sikerült befejezni, Jeff biztosította, hogy kizárólag a legkevésbé fontos területeken maradjanak befejezetlen dolgok. Ez csupa olyasmi volt, ami fölött a megrendelő szemet hunyt, vagy egyszerűen beépítette egy következő szerződésbe.
A fentebb említett állami megrendelés is teljesen fix szerződéssel indult. A csapat szorosan együttműködött a rendszer felhasználóival, és hónapról hónapra képes volt működő, alaposan tesztelt és használható szoftvert szállítani és installálni. Minden szállítás után megbeszélték a felhasználókkal, hogy vajon továbbra is az írott szerződéshez tartsák-e magukat, vagy térjenek el tőle a felhasználók valódi igényeinek megfelelően. Szerintem ez a megbízott cég részéről nagy bátorságra vall, hiszen ha nem lettek volna ilyen jó viszonyban a megrendelővel, akár azt is kockáztathatták volna, hogy nem fogják őket kifizetni. Ebben az esetben azonban az ügyfél annyira elégedett volt a szállított termékkel, hogy minden elvégzett munkát kifizettek a megbízott cégnek. Ez jó példa arra, hogyan lehet egy fix áras, fix feladatkörös és fix határidős szerződést a munka valós idő- és munkaigényének megfelelően rugalmasan kezelni. Veszélyes, de remek stratégia, ha abban a helyzetben vagyunk, hogy kipróbálhassuk.

Fizetés óradíj és dologi költségek alapján

Ebben az esetben minden munkafázist akkor fizetnek ki, amikor elkészült. Nyilvánvalóan ilyen szerződést akkor érdemes használni, ha az elvárások folyamatosan változnak. Egy esetben – amit nem is neveznék projektnek  – az ügyfél szélsőséges módon változtatgatta az elvárásait, akár napokkal a szállítás előtt is. A megbízott cég mindig leszállította, amivel éppen elkészült, az ügyfél pedig teljes mértékben kontrollálni tudta, hogy mi legyen a prioritási lista tetején. Az évek múlásával mindez úgy működött, mint egy kiegyensúlyozott áramlás: a megrendelőhöz mindig eljutott a szükséges szoftver, a megbízott céghez pedig cserébe a pénz.
Ha az ügyfél megbízik a fejlesztő cégben, ez a legegyszerűbb szerződéstípus, amit használni érdemes. A nehézsége mindössze annyi, hogy valóban bizalomra van hozzá szükség. Néhány megbízott cég éppen ezért próbaidőt kér az ügyféltől, ami alatt igyekeznek különféle agilis technikákkal rövid határidő alatt működő szoftvert szállítani, és így elnyerni az ügyfél bizalmát és a későbbi megrendeléseket.

Fix ár és maximum ár

Ez a szerződés stabil elvárásokat feltételez. A “fix ár” a megbízott cég számára garantál egy bizonyos profitot a működési költségeiken és az alvállalkozóiknak kifizetett munkadíjon felül. Egyúttal biztos bevételt garantál a cégnek akkor is, ha a feladatok mennyisége lecsökken, vagy a munka a vártnál hamarabb befejeződik. A “maximum ár” pedig egyfajta költségvetési plafont jelent, amit a megbízott cég akkor sem léphet át, ha a munka lassabban halad a vártnál. Ez tehát a megrendelő számára jelent védelmet. Miután mindkét fél –  a megrendelő és a megbízott cég is  – védve van, nyugodtan törekedhetnek arra, hogy felgyorsítsák a munkát, illetve szükség esetén el tudják fogadni a váratlan nehézségeket.

Fix ár funkciópont- vagy storypoint-egységenként

Ha az ügyfél és a megbízott cég meg tud egyezni a szállítás egységeiben, mint például funkciópontok vagy sztoripontok, ezen egységek alapján is megállapíthatják az árat. Számos szerződés funkciópontokban méri a projektek nagyságát, a leszállított funkciópontokhoz rendeli az egységárat, majd egy hivatalos funkciópont-auditor bevonásával összesíti a projekt végéig leszállított összes funkciópont mennyiségét. A megrendelő így végül ezt a valós összeget fizeti ki, nem pedig az eredetileg becsült összeget. Ez nagyon kedvező szerződési forma, hiszen a megbízott céget arra ösztönzi, hogy minél több funkciópont szállításával növelje a bevételét, a megrendelőnek pedig lehetőséget ad arra, hogy a projekt közben módosítsa az elvárásait. Ugyanez a helyzet az XP-stílusú sztoripontokkal is, azzal az eltéréssel, hogy nem léteznek hivatalos sztoripont-vizsgálók, hogy hitelesítsék a végeredményt. 

Bob Martin ötlete

Bob Martin az Object Mentor-tól közzétett egy érdekes variációt: azt javasolja, a szerződő felek állapítsanak meg egy alapdíjat sztoripontonként, plusz egy átlagosnál alacsonyabb (közel önköltséges vagy az alatti) óradíjat. Ez a megbízott céget arra ösztönzi, hogy mielőbb szállítson, miközben bizonyos fokú védelmet ad arra az esetre, ha a munka a vártnál lassabban halad. Bob Martin így fogalmaz:
”Célszerű megegyezni abban, hogy a megrendelő a befejezett pontok alapján fizet egy meghatározott összeget, plusz egy bizonyos óradíjat minden munkaóra után. Vegyünk például egy projektet, amely 1000 pontból áll. Tételezzük fel, hogy ez a munkamennyiség egy négyfős csapat által heti 50 pontos sebességgel végezhető el. Mindezek alapján ez a projekt 80 ember/hét időtartamig fog tartani. Száz dolláros óradíjjal így tehát a projekt végösszege 320,000 dollár lenne. Most csökkentsük le az óradíjat 30 dollárra, és kérjünk a megrendelőtől 224 dollárt pontonként. Ennek az eredménye igen érdekes lehet: ha a munka valóban 80 ember/hét időtartamig tart, akkor ugyanannyiba fog kerülni. Ha 100 ember/hét időtartamig tart, akkor 344,000 dollárba kerül majd. Ha vizsont csak 70 ember/hétig tart, akkor a végső ára 308,000 dollár lesz. Érdemes megfigyelni, hogy mindez apró különbség ahhoz képest, hogy az időtartamok mennyire eltérőek. Továbbá azt is érdemes észrevenni, hogy a megbízott céget ez a konstrukció erőteljesen arra ösztönzi, hogy hamar befejezze a munkát, hiszen ez növeli a valós óradíjának az összegét.”
Én magam még nem láttam ezt a modellt működés közben, de többektől nagyon kedvező visszajelzéseket hallottam róla.  

Kockázati tőke-alapú finanszírozási modell

Ez bármelyik fentebb leírt szerződéshez felhasználható. Ebben a konstrukcióban a megrendelő egy bizonyos mennyiségű elvégzett munka alapján fizet, a megbízott cégnek pedig eredményeket kell produkálnia, ha több pénzt szeretne kapni. Az ügyfél így bármikor csökkentheti a veszteségeit, ha nem kapja meg a várt eredményeket. Továbbá, minden egyes munkaperiódus után lehetősége van arra, hogy változtasson a szerződés feltételein. A munkaperiódusok eredményének nem kell feltétlenül működő szoftvernek lennie, lehet akár egy írásos tanulmány vagy egy requirements document, vagy bármi, amit a megrendelő választ.  
A kockázati tőke-alapú finanszírozási modell jól működik agilis szolgáltatók esetében, hiszen ők hozzá vannak szokva, hogy működő és használható szoftvert szállítsanak, mégpedig hamar és rendszeresen.  
Személy szerint érthetetlennek tartom, hogy azok a kockázati tőke-finanszírozók, akiknek az induló (start up) projektjeit eddig láttam, nem használták ki a fent leírt modellt annyira, amennyire az agilis csapatok. A tőke-finanszírozók általában szemet hunynak afölött, ha az evaluation markerek időben túl távol esnek egymástól. Pedig, ha a kifizetést havonkénti szállításokhoz kötnék, az a fejlesztő csapatot (start-up team) arra ösztönözné, hogy átgondolja, mennyi munkát is tud hónapról hónapra elvégezni. A havonkénti fejlődés alapján pedig a finanszírozóknak világos képet adhatna arról, hogy milyen is a megbízott cég (start-up company) valós haladási üteme.

Inkrementális szállítás és -fizetés

Ez a “fix ár/feladatkör és határidő”, valamint a “fix ár/maximum ár” jellegű szerződésekben használható. A megrendelő ebben az esetben elvárja, hogy inkrementális módon megkapja az általa megrendelt, integrált és tesztelt rendszereket, amelyeket minden szállításkor szintén inkrementális módon saját maga is tesztel, és a megbízott céget abban az esetben fizeti ki, ha a tesztek sikeresen lezajlottak. Ezt a modellt használták egy repülőtér-építési projektben, vaalmint a  “Solystic’s French Post Office” szerződésben. Mindkét projekt vezetője arról számolt be, hogy ez a konstrukció csodálatosan motiválta a beszállító céget. Persze mindehhez nélkülözhetetlen, hogy a megrendelő tisztában legyen az inkrementális fejlesztés mibenlétével, és el tudja végezni az időről időre esedékes teszteket.

Jonathan House ötlete

Fix ár, plusz 5% bónusz, ha időben szállítanak, vagy fix ár és 5% levonás, ha csúszik a projekt.

Variáció az óradíj- és dologi költségek-alapú fizetésre

A kiszámlázható munkaórák itt egy fix tartományban változhatnak (pl. havonként 180-240 óra az egész csapatnak), hogy elejét vegyék a korlátlan költekezésnek. Némi lehetőség itt is van arra, hogy szükség esetén megnöveljék az óraszámot és ezzel az árat, illetve ne történjen túlszámlázás, ha kevesebb munkaórára volt szükség. 

Határozatlan munkamennyiség szállítása határozatlan időpontban

Ez önmagában is hatalmas témakör, amelyről a következő linken olvashatunk bővebben: Indefinite Delivery, Indefinite Quantity or IDIQ contracts

Norvég PS 2000 sztenderd szerződés

“Ennek a szoftverfejlesztési szerződésnek a lényege, hogy olyan mechanizmusokat bocsát az ügyfél és a fejlesztő cég rendelkezésére, amelyekkel közös egyetértésre juthatnak, valamint tartalmaz egy rugalmas iteratív modellt, amely alapján a fejlesztés során figyelembe lehet venni a felmerülő bizonytalanságokat és kockázatokat.”  
    •    Lépésről lépésre történő iteratív fejlesztési modell, amellyel fel lehet használni a követelményekről és a nehézségekről útközben megszerzett tudást és tapasztalatokat
    •    Szoros együttműködés a beszállító cég és az ügyfél között
    •    Beépített ösztönzők és szankciók, valamint target pricing
    •    Konfliktuskezelési módszerek egy szakértő mediátor bevonásával”
Ezt a szerződést meg kell rendelni (néhány ezer norvég koronába kerül).

Target-Cost szerződés

Idézet: http://www.sparkboxx.com/sparkboxx/types-of-contracts.html “Ebben a szerződésben kitűznek egy kezdeti funkcionális célt, majd konzultációk segítségével meghatározzák, mennyi forrást és időt lenne célszerű befektetni ahhoz, hogy megvalósuljanak a kezdeti specifikációk. A funkcionalitáshoz kapcsolódó cél alapján megállapítanak egy kezdeti árat, amelyre rászámolnak egy bizonyos összeget váratlan helyzetekre, valamint profitot. Ha az ügyfél a projekt során megváltoztatja a munka kiterjedését, vagy ha váratlan követelmények merülnek fel, a megnövekedett költségeket (additions) három csoportba oszthatjuk: (Horowitz 2005): hibajavítások, pontosítások és teljesítményfokozások (enhancements).
Az eredeti cikk a céláras szerződésről angolul itt olvasható:  http://cyrusinnovation.com/downloads/agile2005_cyrusinnovation_targetcostcontracts_paper.pdf
 

Forrás

2 komment

Címkék: agile contract

A bejegyzés trackback címe:

http://agilitas.blog.hu/api/trackback/id/tr202497971

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

akocsis · http://akocsis.blog.hu 2011.02.14. 11:40:11

Hasznos lenne ezen ötletek mellé gyakorlati tanácsokat is adni, illetve lokalizálni ezeket az európai, illetve a magyar viszonyokra.
Ugyanakkor sok esetben úgy tűnik, hogy az ügyfél elvárásai, nézőpontja nem elég hangsúlyos, mintha abból indulnánk ki hogy az ügyfélnek minden jó amit javaslunk neki.

Pár megjegyzés:

Fizetés óradíj és dologi költségek alapján: Nem biztos, sőt feltehetőleg biztosan nem fog az ügyfél ilyenbe belemenni egy új, ismeretlen IT cég esetén. Meg lett említve a bizalom, bizony ez a kulcsa.

Fix ár és maximum ár: Ez a típus mintha Európában nem terjedt volna el, éppen ezért nem biztos, hogy a beszerzés vevő lesz rá.

Fix ár funkciópont- vagy storypoint-egységenként: Ez csak egy illúzió. Mi csinálunk FPA-t, tudom hogy mennyire nem valósak a számok, biztosan nem akarnék egy projektet fiktív mérőszámok alapján fizetni.

Bob Martin ötlete: Az ötlet jó, csak hát ugye kicsi az esélye, hogy erről valaki az ügyfelét meggyőzze.

Kockázati tőke-alapú finanszírozási modell: Ez nem ötlet, hanem ténylegesen ez van. A multik diverzifikálják a beszerzéseket, még a hosszú távú megállapodások is tartalmaznak review vagy renewal ciklusokat. Ha valaki nem jól teljesít, akkor kevesebb megrendelést kap a következő ciklusra, vagy esetleg egyáltalán nem.
Nem szoftvert veszünk, hanem munkaerőt, de azt sem fix mennyiségben hanem megállapodunk óradíjakról, aztán annyit kérünk amennyit akarunk. Ha jó a kapcsolat, akkor sokat, ha nem megy jól, akkor keveset.

Inkrementális szállítás és -fizetés: Jó ötlet és gigaprojekteknél tényleg ez a járható út. De a többi esetben az ügyfél inkább a végén fizetne, amikor ténylegesen megkapta amit kért.

Jonathan House ötlete: Jonathan House feltalálta a spanyolviaszt. Úgy hívják, hogy kötbér.

kulcsár bence 2011.02.15. 11:08:33

A cikk célja az volt, hogy a lehető legszélesebb áttekintését adja az agilis szerződéseknek. Jó ötletnek gondolom, egy majdani magyar és/vagy európai gyakorlat áttekintését bár ez nyilván egy nagyobb kutatómunka.

Talán annyit fűznék hozzá, hogy Jonathan House nem teljesen a spanyolviaszt találta fel, hiszen -5% mellett időben teljesítés esetén egy extra bonus +5% szerepel. Van olyan ügyfelem ahol ennek a modellnek egy verzióját alkalmazzák release elszámolásra és motivációra. Ilyenkor a fix ár+5% nem a projekt keret, hanem az általános velocity-hez képest egy nagyobb csapatsebességre számolt munkamennyiség elvégzésére vonatkozik.

Legegyszerűbben úgy képzelhető el, hogy belső fejlesztőcsapat fix havibérért dolgozik. A ScrumMaster tisztában van a csapat sebességével, restrospective-re mindig kiszámolja. A következő release-re 5%-kal nagyobb velocity-re kalkulálják az elvégzendő munka mennyiségét. Ha release-re az összes UserStory-t sikerül teljesíteni, akkor fix ár (havibérek) + 5% bér jár. Ha pedig nem sikerül, akkor csak a havibérek. Itt egyértelműen pozitív motivációra használják a modellt akár a kötbér elhagyásával, mivel a ScrumMaster a csapat és a ProductOwner mindig megteszik a folyamatjavítási lépéseket.

Érdekes belső megrendelői aspektus lehet, hogy a velocity növelés arányát és a jutalombér növelés arányát nem egyenes arányban határozzák meg. Pl. (10% - 8.5%) vagy (10% - 14%) az utóbbi pl. egy time-to-market szituációt erősíthet.