Végtelenül bosszant, hogy a mai napig szinte minden ajánlat kérés fix árat kér egy fixnek gondolt terjedelemre. Csak hát fix terjedelem nem létezik.
Hahó világ! Ideje felébredni!
Olyan projektet már láttam, amelyik a tervezett költségből valósult meg. Ez teljesen kezelhető. Olyan projektet is láttam már, amelyik határidőre elkészült. Tulajdonképpen segített a projektben a lényegre összpontosítani, hogy tartani kellett a szoros határidőt. Olyan projektet még soha nem láttam, amelyikben az készült el, amit az ajánlat adáskor az ügyfél kért. Soha. Never, ever. Nem létezik!
Nem, ez nem az ügyfél hibája!
Amikor a házunkat újítottuk fel, 180cm szélesre mértem a konyhát. Az pont jó, befér a két oldalán egy-egy 60cm széles szekrény sor. Remek alaprajzot eszeltem ki. Kár, hogy nem volt a falon vakolat. Mire lett vakolat, már csak 175cm volt a szélesség. Az nem zavart volna, ha csak 55cm a távolság a két szekrény között – kicsit szűk, na és, majd nem táncikálunk. Viszont nem lehetett volna a hűtőszekrény, a mosogató gép és a sütő ajtaját eléggé kinyitni, hogy ki lehessen húzni a mélyhűtő fiókot, a mosogató tálcát és a tepsit. Szerencsére, erre a konyhaszekrény megrendelése előtt rájöttem, így csak az addigra már elkészült villany, víz és lefolyó kiállásokat kellett áthelyeztetni az új terv szerint. És ez csak egy konyha volt, amit semmilyen API-hoz nem kell illeszteni.
Nem lehet egy projekt elején megmondani, mi lesz a projekt terjedelme, mert a szoftver fejlesztés egy komplex tevékenység: bizonyos mértékig tervezhető, de mindig van előre nem látható tényező. Tulajdonképpen minden tudás munka ilyen.
Mindig van előre nem látható tényező
Ez azért van így, mert egy egészen apró változás a projekt egyik felén hatalmas változásokat eredményezhet valahol máshol. Mint 5 cm vakolat, ami miatt át kellett alakítani a víz, lefolyó és elektromos hálózatot. Vagy, amikor csak egy mezőt kell felrakni valahova a képernyő közepébe.
Ugyancsak előre nem látható feladatokat eredményez, hogy valójában nagyon korlátozottan tudjuk elképzelni, milyen lesz az adott funkció, amikor kész lesz.
Az állás.hu fejlesztésekor elképzeltünk egy szuper algoritmust a hirdetések és az álláskeresők párosítására. Amikor először kipróbáltuk komplett hülyeségeket ajánlott. Géplakatos legyek vagy markoló kezelő. Köszi. Aztán megnéztük, hol csúszik el az elmélet, és módosítottunk az algoritmuson. Aztán ugyanez még vagy hússzor.
A kiváló kezdeti elképzeléseink a gyakorlatban vagy működnek, vagy nem. Inkább nem.
Az ügyfél azért sem tudja a terjedelmet jól meghatározni, mert
- Nem tudja, a piacon mi fog működni. Még én is nagyon bizonytalan vagyok azzal kapcsolatban, mennyire jók ezek a cikkek, vagy akár egyes mondatokat ne húzzak-e ki.
- Ebből is adódóan az ügyfél szükségképpen csapong. Az egyik héten az egyik funkcióról érzi, ettől lesz a termék sikeres, a másik héten egy másikba szeret bele. Arról nem is beszélve, amikor több érdekelt is van.
- Nem tudja, hogyan kell jól követelményt elemezni. Azt érti, szükség van felhasználókra, meg jogosultságra, de arra már nem gondol, hogy a létrehozott felhasználó rekordokat ki fogja megszüntetni, kell-e archiválni, vagy mi történjen, ha valaki minden super admint letöröl?
- Az előre nem látható tényezők mennyisége a projekt mérettel exponenciálisan nő.
Mennyi tartalékot kell számolnom?
Egy hónapos projekt esetén 10% tartalék elegendő ahhoz, hogy az előre nem látható tényezők kezelhetők legyenek. Egy három hónapos projekt esetén már 20-25%-nyi előre nem látható feladattal kell számolni, egy féléves projektben pedig 40-50% tartalék szükséges. Ha most 1000 napos méretűnek látszik a feladat, akkor 1400-1500 napnyi lesz, mire elkészül. Még nagyobb projekten ez még durvább: egy egész éves projekten 100% tartalékra van szükség.
Ekkora tartalékkal nem lehet projektet nyerni, kisebb tartalékkal meg nem lehet kezelni a felbukkanó, előre nem látott feladatokat. Kivéve, ha minden felbukkanó feladat esetén megpróbáljuk eladni, ez nem volt benne az eredeti vállalásba, ezért az ügyfélnek még kell fizetni, és csúszik a határidő is, de az ezzel járó folyamatos veszekedés vállalhatatlan, felesleges stressz.
Én nem vagyok hajlandó állandóan az ügyféllel veszekedni arról, mi volt benne és mi nem! Nem normális így dolgozni sem nekem, sem az ügyfélnek.
Azért kellemetlen, hogy nem lehet előre megmondani, mi lesz a projekt terjedelme, mert így az ügyfél nem tudja ellenőrizni, azt kapja-e a pénzéért, amit ígértünk, amikor megállapodtunk. Megismétlem, mert ez elég durva:
Az ügyfél nem tudja ellenőrizni, azt kapja-e a pénzéért, ami jár!
Nem tudja. Nincs esélye. Végül mindig teljesen más készül el, mint, amire az ajánlatot adtuk az almát meg hiába hasonlítjuk a körtéhez. A fix ár – fix terjedelem típusú megállapodás azt az illúziót adja a megrendelőnek, képes ellenőrizni, nehogy becsapják, de ez csak illúzió, mert a terjedelem nem tud fix lenni, és emiatt az ár sem lesz végül fix. Ez fix.
Mit tehet az ügyfél, aki mégsem akarja ész nélkül kiadni a pénzét?
Válasszon érték vezérelt fejlesztést rögzített költség korláttal. Mint csomagolás a bőröndbe. Mindig azt fejlesztjük, ami éppen a legfontosabb. Kis részfeladatokra bontjuk a terjedelmet, hogy könnyen tudjuk a kis részeket egymáshoz viszonyítani, priorizálni. Minden iteráció után kész szoftvert szállítunk, ami így mindig az addig létrehozható legfontosabb funkciókat tartalmazza. Sok rövid iterációt használunk (pl.: egy hetes sprinteket), így hamarabb tudunk irányt váltani.
Az elszámolás idő alapú, az ügyfél annyit fizet, amennyit dolgozunk – és ezt ellenőrizni is tudja! Nincs veszekedés, mi volt benne és mi nem. Nem gond, ha mindig van egy jobb ötlet, mert az ügyfél bármikor dönthet úgy, inkább más a fontos és mi folyamatosan segítünk neki, tényleg a lényegre, az értékre összpontosítani. Végül a legjobb szoftver készül el, ami az adott pénzből kihozható és még azt is megteheti, hamarabb megállítja a projektet, ha az már elérte a célját, mert minden iteráció után kész szoftvert kap, amit elvihet, használhat. A szerződésben van felső költség korlát, és készítünk egy erőforrás és költség tervet, amelyből minden iteráció után látszik hogyan fogy a keret és mi várható.
Ha pedig nem tudunk jól együtt működni, vagy az ügyfélnek nem jó az, ami készül – és ez fix terjedelmes projektnél is előfordul – akkor sem nem ragad bele egy rossz szerződésbe.
Dobjuk el, a fix terjedelmet és csináljuk a projekteket értékre összpontosítva!
Utóirat.
Ha mindez tetszik, de nem tudod, mit tegyél
- Ha megrendelő vagy, és érdekelne az érték vezérelt fejlesztés, de nem tudod, hogyan kezdj hozzá, keress meg, szívesen segítünk akár eset tanulmányokkal, akár tanácsadással, akár projekt megvalósítással is, ha értünk az adott területhez.
- Ha fejlesztő vagy és nem tudod, hogy csináljatok érték vezérelt projektet, keress meg, szívesen segítünk, akár a konkurenseinknek is, mert közös érdekünk, hogy minél jobban elterjedjen az érték vezérelt szemlélet. Mi jó projekteket szeretnénk csinálni, jó termékeket létrehozni és nem az ügyfelekkel alkudozni. Szívesen adunk tréninget, coachingot és konkrét valós példákon keresztül tudjuk bemutatni az értékvezéreltséget a gyakorlatban.
- Ha szeretnél segíteni, hogy elterjedjen az országban az érték vezérelt szemlélet, akkor oszd meg a cikket minél több ismerősöddel.