A fixáras szerződés és a ráfordítás alapú elszámolás közötti választást általában kockázati döntésként fogalmazzák meg, ami helyes, és utána azonnal rosszul kezelik, mert mindkét oldal abból indul ki, hogy a kockázat eltűnik, ahelyett hogy csak átkerülne a másik félhez.

Nem tűnik el. Fixáras konstrukcióban a szállító viseli annak kockázatát, hogy a becslés téves, és ezt a kockázatot beárazza a megadott számba. Ráfordítás alapú elszámolásnál az ügyfél viseli. A kérdés soha nem az, hogy melyik megoldás szünteti meg a bizonytalanságot. A kérdés az, melyik fél tudja jobban kezelni, és hogy megéri-e kifizetni az átadás árát.

Az a próba, amely megjósolja, melyik fog működni: le tudja írni, mit jelent az, hogy „kész”, olyan részletességgel, hogy két ember egyetértsen abban, elérték-e ezt az állapotot? Ha igen, a fixár nyitva áll ön előtt, és valószínűleg észszerű is. Ha nem tudja leírni, egy fixáras szerződés nem szünteti meg a kétértelműséget, csupán minden jövőbeli nézeteltérést üzleti alkuvá alakít szakmai beszélgetés helyett.

Mit vesz meg valójában egy fixáras szerződés

Bizonyosságot a számla összegéről, és semmi mást. Kifejezetten nem vesz meg bizonyosságot az eredményről, a határidőről vagy a minőségről, pedig a megrendelők ezeket rendszerint a csomag részének hiszik.

Ára is van. Aki fixáron ajánl, kockázati tartalékot tesz az árba, hiszen a csúszást ő nyeli le, és ennek a tartaléknak a mérete együtt nő azzal, mennyire homályos a specifikáció. Jól körülhatárolt munkánál szerény maradhat. Lazán megfogalmazott munkánál megközelítheti magának a munkának a költségét, és ön akkor is kifizeti, ha a kockázat végül nem következik be.

A második költség viselkedési természetű. Amint az ár rögzül, minden kétértelműség a kevesebb munka irányába dől el, mert immár ott van a szállító érdeke. Ez nem rosszhiszeműség, hanem az az ösztönző, amit maga a szerződés hozott létre. Az a szállító, aki menet közben jobb megoldást vesz észre, nem érdekelt abban, hogy szóba hozza, az az ügyfél pedig, aki rájön, hogy egy követelmény hibás volt, változtatási igénnyel találja szemben magát, nem beszélgetéssel.

A fixár jól működik valóban lehatárolt munkánál: ismert forrású és célú migrációnál, dokumentált API-ra épülő integrációnál, elfogadott terv alapján meghatározott képernyőhalmaznál. Rosszul működik minden olyan feladatnál, amely felderítő jellegű.

Mikor olcsóbb a ráfordítás alapú elszámolás

Az intuícióval szemben gyakran olcsóbb, mert nem fizeti ki a kockázati tartalékot, és nem fizeti ki a változtatási igények kezelését sem.

Ahhoz a munkához illik, ahol a terjedelem jogos okból változni fog: egy első verzióhoz, amelynek iránya attól függ, mit tesznek a felhasználók, egy olyan rendszerhez való integrációhoz, amelyet senki nem dokumentált, egy kódbázis megmentéséhez, amelynek állapota addig ismeretlen, amíg valaki bele nem néz. Mindegyik esetben a fixár valójában egy feltételezés fixára.

Amit az ügyféltől megkövetel, az a figyelem. A ráfordítás alapú elszámolás bevonódás nélkül nyitott számlává válik, a jellemző kudarcforma pedig az a projekt, amely hónapokig fut, miközben senki nem kérdezi meg, mi készült el a múlt héten. A kontroll nem szerződéses, hanem működési kérdés: látható backlog, rendszeres időközönként tartott bemutató, és egy olyan személy az ügyfél oldalán, aki jogosult a prioritások megváltoztatására.

Ha senki nem tudja megadni ezt a figyelmet az ön oldalán, mondja ki nyíltan, mert akkor a ráfordítás alapú elszámolás nem fog jól működni, és ezen semmilyen szerződéses pont nem segít.

Az a forma, amelyet a legtöbb projektnek használnia kellene

Plafonos vagy szakaszokra bontott megállapodás, amely egyik fenti modell sem, és több szoftveres munkához illik, mint bármelyikük.

Plafonos ráfordítás alapú elszámolás. A munkát idő alapján számlázzák, egy megállapodott felső korláttal. Az ügyfél megtartja a rugalmasságot az irányváltásra, a szállító pedig viseli a plafon fölötti maradékkockázatot. Mindkét oldalnak érdeke marad a hatékonyság, amit egyik tiszta modell sem ér el.

Szakaszolt fixár. Egy rövid, fizetett felmérés specifikációt hoz létre, és a megvalósítás csak ezután kap fixáras ajánlatot, valami valóságosra. Ez a fixár őszinte változata, mert a becslés az ismeretlenek csökkentése után születik, nem előtte. A szoftveres ajánlatkérésről szóló útmutatónk leírja, mit kell tartalmaznia ennek a specifikációnak.

Fixár ütemenként. Minden szakasz külön kap ajánlatot és külön megállapodást. Így darabokban kap költségvetési kiszámíthatóságot, és megmarad a leállás joga, ami az ügyfél legértékesebb joga, és pontosan az, amit a hosszú fixáras szerződések elvesznek.

A közös szál mindig ugyanaz: a becslés pontossága óriásit javul, amint a munka egy része elkészült. Az üzleti konstrukciót úgy felépíteni, hogy ezt kihasználja, többet ér bármelyik szerződéses pontnál.

Hol buknak el valójában a fixáras projektek

Nem az áron. A terjedelem és a változtatás határán.

Minden fixáras projekt termel változtatási igényeket, mert a specifikációk azelőtt születnek, hogy bárki használta volna a terméket. A megállapodás egészsége teljes egészében azon múlik, hogyan kezelik ezeket, ez pedig attól függ, mennyire pontosan határozták meg a terjedelmet az elején, nem pedig bárki jóindulatától.

Két dolog csökkenti a súrlódást. Rögzítsék írásban, mi történik egy változtatással: ki bírálja el, milyen alapon árazzák be, és mennyi időn belül. Emellett tartson tartalékot az ügyfél oldalán is, mert az a fixár, amely mellett nincs ügyféloldali változtatási keret, minden új felismerést vitává alakít.

A másik gyakori kudarc az átvétel. Ha a szerződés nem határozza meg, hogyan kell igazolni az elkészülést, a végszámla véleményekről szóló alkuvá válik. Írja le az átvételi feltételeket a terjedelem mellé, és részesítse előnyben azokat a feltételeket, amelyeket valaki tesztelni tud, azokkal szemben, amelyeket valakinek meg kell ítélnie.

Hogyan döntsön a gyakorlatban

Kérdezze meg, mi az, ami valóban ismeretlen. Ha a válasz az, hogy „nagyon kevés”, a fixár észszerű, és számítson rá, hogy ezért a bizonyosságért kockázati tartalékot fizet. Ha nagyon sok minden ismeretlen, a fixár csupán műszaki bizonytalanságot alakít üzleti súrlódássá.

Ezután kérdezze meg, mit tud felügyelni. A ráfordítás alapú elszámolás jutalmazza a figyelmet, és bünteti annak hiányát. A fixár hétről hétre kevesebbet kér öntől, viszont sokkal többet az elején, a specifikációban, ahol a hibák olcsóbbak, de nehezebben vehetők észre.

Végül kérdezze meg, mennyit ér a bizonyosság. Néha egy felügyelőbizottságnak egyetlen számra van szüksége, és a kockázati tartalék tisztességes ár ezért. Ez jogos indok a fixár választására, és jóval jobb indok annál a hitnél, hogy a fixár megszünteti a kockázatot.

A Mecanik mind a három konstrukcióban dolgozik a szoftverfejlesztési szolgáltatása keretében, és leggyakrabban a szakaszolt változatot ajánlja. A két hét felmérés után készült becslés mindkét fél számára többet ér annál, amely előtte készült.

Gyakran ismételt kérdések

Biztonságosabb a fixáras szerződés, mint a ráfordítás alapú elszámolás? Kiszámíthatóbb, ami nem ugyanaz. A fixár a becslési kockázatot a szállítóra hárítja, aki azt kockázati tartalékként beárazza, tehát ön akkor is megfizeti, ha a kockázat nem következik be. Bizonyosságot vesz a számla összegéről, nem az eredményről, a határidőről vagy a minőségről.

Mikor olcsóbb a ráfordítás alapú elszámolás? Akkor, ha a terjedelem jogos okból változni fog: egy első verziónál, amelynek iránya a felhasználói viselkedéstől függ, egy nem dokumentált rendszerhez való integrációnál, vagy olyan kódbázison végzett munkánál, amelynek állapota addig ismeretlen, amíg valaki bele nem néz. Ilyenkor megspórolja a kockázati tartalékot és a változtatási igények többletköltségét is, mert a fixár itt egy feltételezés fixára lenne.

Mi a plafonos ráfordítás alapú elszámolás? Idő alapján számlázott munka, megállapodott felső korláttal. Az ügyfél megtartja a rugalmasságot az irányváltásra, miközben a szállító viseli a plafon fölötti kockázatot. Mindkét félnek érdeke marad a hatékonyság, amit sem a tiszta fixár, sem a tiszta ráfordítás alapú elszámolás nem ér el.

Miért futnak félre a fixáras szoftverprojektek? Szinte mindig a terjedelem és a változtatás határán, nem az áron. A specifikációk azelőtt születnek, hogy bárki használta volna a szoftvert, ezért a változtatási igények elkerülhetetlenek. Az egészség azon múlik, hogy előre megállapodnak-e abban, ki bírálja el a változtatást és hogyan árazzák be, valamint hogy az ügyfél tart-e saját tartalékkeretet.

Bele kell írni az átvételi feltételeket a szerződésbe? Igen, közvetlenül a terjedelem mellé. Ha nincs meghatározva, hogyan kell igazolni az elkészülést, a végszámla véleményekről szóló alkuvá válik. Részesítse előnyben a tesztelhető feltételeket a megítélést igénylőkkel szemben, mert a tesztelhető feltétel lezárja a vitát, a megítélésen alapuló pedig elnyújtja.