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
