Webtown blog

Gondolataink cikkekbe rendszerezve

null Hogyan öli meg a kalkuláció alapú projekt beszerzési megközelítés a vállalatok versenyképességét?

Vrana Zoltán

Hogyan öli meg a kalkuláció alapú projekt beszerzési megközelítés a vállalatok versenyképességét?

A szoftverfejlesztési beszerzések világában sem mindenki számára egyértelmű, hogy a beszerzési folyamat milyen hatással tud lenni a projekt értékteremtő képességére, a fejlesztendő termék minőségére, hasznosságára. Kézenfekvő megközelítésnek tűnik, hogy ha szeretnénk beszerezni valamit, akkor pontosan tudni akarjuk, hogy mit fogunk kapni. Ez rendben is van például egy szerver esetében, de a szoftverek világa más… Ássunk is egy kicsit mélyebbre!

Mit is jelent a kalkuláció alapú projekt beszerzési megközelítés?

A kalkuláció alapú projekt beszerzésnek azt hívom, amikor az ajánlat alapja egy részletes követelmény felmérés, és annak kimenete egy mindenre kiterjedő követelmény specifikáció dokumentum. Erre a dokumentumra általában úgy tekintenek ebben a beszerzési megközelítésben, mint amely alkalmas arra, hogy megfelelő inputként szolgáljon a fejlesztési költség pontos meghatározásához.

Az ilyen beszerzésben résztvevő ajánlattevők ennek az elvárásnak eleget is tesznek, így ennek köszönhetően rögzítésre kerül a megvalósítandó szkóp (követelmény specifikáció) és annak költsége (fejlesztési ajánlat). Mivel az utóbbi általában embernap alapú, így úgy tűnhet, hogy ezen információ alapján a határidő is kiszámítható és rögzíthető.

Egy valós példán keresztül megérthetjük, hogy a kalkuláció alapú projekt beszerzési megközelítés milyen hátrányokkal jár a megrendelő számára.

Alapos felmérés alapján megszületik egy kalkulált ajánlati ár

Ügyfelünk részletes követelmény elemzést végzett a szervezetén belül az induló fejlesztési projektjéhez, melynek eredményeként elkészült egy 72 oldalas követelmény specifikáció. A dokumentum elkészítése az ügyfél információi szerint körülbelül 0,5-1 évig tartott. Minden érintett üzleti területtel egyeztetve alakult ki a végső tartalma, azaz a fejlesztési projekt “véglegesnek” vélt szkópja. Ez a követelmény specifikáció dokumentum adta a beszerzési eljárás szakmai részét.

Amikor a beszerzési eljárás elindult, akkor a Webtown vállalati és projekt kultúrája még más volt: vízesés módszertan szerint szerveztük a projektjeinket. 

Az ajánlat úgy készült, hogy egy vezető fejlesztő átnézte a követelmény specifikációt, eldöntötte, hogy mi az ami “out of the box” kiszolgálható, és mi az amelyhez egyedi fejlesztés szükséges. Az egyedi fejlesztések ráfordítását is megbecsülte embernapban. 

Így tettünk az említett példa projektben is.

Az ajánlat elkészült, minden követelmény mellett szerepelt a vezető fejlesztő által megbecsült “pontos” fejlesztési ráfordítás, illetve, hogy mi az, amit “out of the box” tervezünk megoldani.

Ezen információk alapján kialakult egy projekt szintű fejlesztési díj, és természetesen egy vállalt határidő. Fix szkóp, fix díj, fix határidő. Így megfeleltünk a kalkuláció alapú projekt beszerzés elvárásainak.

Az ajánlat kiküldésének dátuma és a fejlesztés megkezdésének dátuma között eltelt idő, mely magában foglalta az ajánlati szakaszt, a szerződéses tárgyalásokat, a szerződéskötést, szakmai egyeztetéseket, a fejlesztés megkezdésének előkészületeit további 1,5 évet vett igénybe.

Ezen a ponton körülbelül 2-2,5 éves előkészületnél járt a projekt, azaz eltelt 2-2,5 év, hogy egy sor kód sem született. Viszont ránézésre a projekt egy nagyon jól átgondolt, előkészített projektnek mutatta magát.

A projektet megnyertük.

Mielőtt megkezdtük volna a fejlesztést, még a szerződéskötés előtt sikerült agilis keretrendszerbe transzformálni az együttműködést. A követelmény specifikációt “kezdeti” product backlog-ként kezeltük, mely nem volt más, mint egy ajánlás a szkópra vonatkozóan.

Az operatív munkához felállt a Scrum Team, az együttműködés és a fejlesztés megkezdődött.

Az első élesíthető release fejlesztése körülbelül 1 évet vett igénye. Ennek okaira ebben a cikkben nem térnék ki, talán majd egy másik cikkben feldolgozzuk ezt is. :)

Go to Market időre való hatás

Az első ötlet megszületésétől az első élesítésig eltelt idő, vagyis a Go to Market idő ebben az esetben minimum 3 év volt. Ha belegondolunk, hogy 3 év alatt mi minden tud történni, változni, akkor könnyen belátható, hogy ez nagyon-nagyon sok idő, főleg a digitális csatornák területén.

Ennyi idő alatt egy teljes piac tud átalakulni: új versenytársak jelennek meg, a meglévők jelentőset innoválhatnak, a felhasználói szokások és igények tudnak gyökeresen megváltozni, de akár a meglévő piacvezető szerepet is el lehet veszíteni ennyi idő alatt.

A tervezett szkóp megvalósulási aránya

Még egy tény adat, amely mutatja ennek a 3 évnek az eredményét.

Az eredetileg felmért, dokumentált, véleményezett és elfogadott, valamint megbecsült, ajánlati kalkulációba bevont követelmények 30%-a készült el a projektben. Hozzá kell tenni viszont, hogy teljesítésre kerültek olyan követelmények is bőven, amelyek nem szerepeltek az eredeti követelmény specifikációban.

Mindezek oka, hogy a nagyon alapos követelmény felmérés és elemzés ellenére a tervezési és beszerzési szakasz közel 2 éve alatt a valós felhasználói igények jelentősen megváltoztak. Másik ok az volt, hogy a 30%-nyi átadott követelmény komplexitása jóval nagyobb volt, mint azt korábban bárki is gondolta, így nagyobb ráfordítással lehetett csak kiszolgálni az amúgy is megváltozott igényeket.

A következmények...

Az eredetileg felmért, dokumentált, véleményezett és elfogadott, valamint megbecsült, és ajánlati kalkulációba bevont követelmények 70%-ára fordított megrendelő és szállító oldali erőforrás, idő és pénz tisztán veszteség volt mindkét fél számára.

Ráadásul ez a megközelítés jelentősen megnövelte a GO TO MARKET időt, mely akár jelentős versenyhátrányt is okozhatott volna, vagy talán okozott is.

Hogy a projekt sikeres volt-e? Attól függ mi alapján szeretnénk ezt eldönteni.

Ha azt nézzük, hogy az eredeti követelmény specifikációban leírt összes követelmény nem lett leszállítva az adott pénzügyi keretből, az adott határidőre, akkor a projekt nem volt sikeres.

Ha azt nézzük, hogy a termékfejlesztés agilis keretrendszerbe való szervezése lehetővé tette ügyfelünk számára, hogy menet közben értékesebb követelményekre fordítsa a projekt pénzügyi forrásait, valamint a végtermék, bár kevesebb funkciót tartalmazott, sokkal jobban reagált az aktuális igényekre, piaci állapotokra, felhasználói viselkedésre, akkor a projekt sikeresnek volt mondható.

Mit tudunk tenni, hogy a negatív következményeket elkerüljük?

Amennyiben elfogadjuk azt, hogy a követelmények gyorsan változnak a jelenlegi piaci környezetben, és képesek vagyunk olyan termékfejlesztési együttműködést kialakítani, amely a változásokra jól reagál, akkor a fenti valós példában megjelenő 2-2,5 éves előkészítési fázist drasztikusan le tudjuk csökkenteni.

Az agilis termékfejlesztési megközelítés, az agilis követelménykezelési technikák segítenek abban, hogy gyorsan produktívba lehessen állítani a termékfejlesztésünket, azaz egy rövid előkészítési szakaszt követően képessé válunk arra, hogy iterációnként működő szoftvert szállítsunk.