A posztban összefoglalom, hogy milyen hatásai vannak az értékesítési folyamatra, ha egy webes projektet agilis módszertan szerint szeretnénk megvalósítani. A módszertan nyújtotta előnyökről - hátrányokról és az értékesítési folyamat mérföldköveiről lesz szó, illetve arról, hogy ezek hogyan változnak meg és miért. Ha nem ismered, vagy csak szeretnéd gyorsan átfutni, hogy mit is jelent az agilis fejlesztés és azon belül a Scrum, akkor ezt a magyar Wikipédia oldalon, vagy a Scrum Alliance oldalán teheted meg.

Érdekes megfigyelni, hogy egy webes fejlesztési projekt megrendelésekor az ár - határidő páros mellett milyen szempontok szerint hoznak döntést a megrendelők. Rengeteg szempont szóba jöhet kezdve a fejlesztő csapat hozzáállásától a cég méretéig, vagy a megvalósítás során alkalmazott technológiákig.Ritkán szokott szóba kerülni a megvalósítás módszertana, pedig ha kilépünk abból a kliséből, hogy a projekteket waterfall (hagyományos) módszer szerint kell és lehet megvalósítani, akkor rengeteg új lehetőség nyílik meg a megvalósításban, így az értékesítésben is.

1. A módszertan eladása

Magyarországon a nagy fejlesztő cégeket leszámítva egyelőre kevesen ismernek és még kevesebben alkalmaznak agilis módszertant a fejlesztések során, ezért elsőként magát a módszertant kell eladni (a fejezet végén felsoroltam néhány pozitívumot, ami általában mindenkinek felkelti az érdeklődését).

Tapasztalatok szerint néhány mélyreható beszélgetés szükséges hozzá, hogy egy olyasvalaki is  átlássa az agilis fejlesztés és a “megszokott” fejlesztés közötti főbb különbségeket, aki korábban nem foglalkozott a területtel. Erre azonban általában nincs lehetőségünk, néhány percben kell felkelteni annyira az érdeklődést, hogy agilis irányba tudjunk tovább haladni és a megfelelő kulcsgondolatokat, előnyöket elültessük a megrendelő fülében (lásd szintén a fejezet végén). Megint csak nem mindegy, hogy kivel beszélünk: technikai, pénzügyi vagy marketing döntéshozóval, hiszen a lenti érvek közül nem mindegyik lesz ugyanolyan fontos a különböző területekért felelős menedzsereknek.

Érvek az agilis módszertan mellett:

• Rugalmas scope: Nem várja el a módszertan, hogy a legelején ismerjük a részleteit a projektnek, azt viszont igen, hogy az alap funkcionalitás egyértelmű legyen.
• Közvetlen irányítás a projektben: A megrendelők nem csak a tervezés és a tesztelés során találkoznak a fejlesztőkkel és a termékkel. A napi megbeszéléseken részt vehetnek, így egy-egy félreértés alkalmával akár azonnal korrigálhatnak, az iterációk átadása során pedig 2-4 hetente tesztelhetik az új funkciókat.
• Pontos határidők: az iterációk fix ideig tartanak, így nem lehet csúszni velük. Egyes esetekben egy-egy funkció nem készül el teljesen, de mivel prioritások szerint haladunk, a legfontosabbak mindig határidőre elkészülnek és csak az apróságokban lehet csúszás.
• Pontos becslések: Az iteratív fejlesztésnek köszönhetően rövid időszakokat kell csak megbecsülni. Általában az első iterációban pontatlanabb a becslés, a későbbiekben azonban ez nagy mértékben javul, a második-harmadik iterációtól tapasztalataink szerint 10% alatti tévedési pontosság is elérhető.
• Dinamikus változás kezelés: Az iteratív fejlesztésnek köszönhetően folyamatosan tesztelhetők az elkészült funkciók, az újabb ötletek, módosítások pedig folyamatosan beépítetők. Az élesítéssel sem kell megvárni a teljes projekt végét, akár már az első iteráció után publikálhatók a kész funkciók.
• Iteráció teljesítésenként fizetés: teljesített iterációnként kell fizetni, így a költségeket jobban lehet szabályozni és bármikor fel lehet mondani a projektet.

2. Scope pontosítása és “Scrumosítása”

Miután egy első beszélgetés és egy esetleges specifikáció alapján nagyjából tisztázódott a scope, elkezdjük közösen sorra venni a követelményeket, úgynevezett User storykat gyártunk a scope-ból, például: “Én mint felhasználó fel tudjak iratkozni hírlevélre, hogy értesüljek az újdonságokról”. 

A következő lépésben ezekhez a storykhoz prioritásokat rendelünk, ami meghatározza a megvalósításuk sorrendjét. Ez eleinte nehézkes, mivel a megrendelőnek  gyakran minden közel egyformán fontos a projektben (holott a kifejlesztett funkciók egy jelentős részét a felhasználók nem is használják, vagy üzleti szempontból kevésbé fontosak...). 

A rutinos megrendelő (és fejlesztő) a scope pontosítása során megpróbál mindenre előre gondolni: “Ugye ez a funkció illeszthető lesz majd ehhez? Ez hol helyezkedik majd el a felületen?” stb., ez alapvetően egy nagyon jó hozzáállás, csak éppen lehetetlen mindenre előre gondolni, főleg ha az adott funkció csak a 2. vagy 3. iterációban kerül kifejlesztésre, addig pedig rengeteg minden történhet a projekttel.

Ezekere a felvetésekre ezt szoktuk válaszolni: “Ezen nem kell most ilyen részletesen gondolkozni. Tudjuk, hogy lesz egy ilyen feladat, nagyjából ismerjük a követelményeket, de részletesen ráérünk majd akkor megtervezni a működést és designt, amikor megtervezzük az adott iterációt - Lehet, hogy addigra (2-3 hónap múlva) ti is máshogy látjátok majd optimálisnak a működését”

Ki ne szeretne ilyet hallani, hogy nem kell előre mindent kitalálni? A legjobb benne az, hogy ráadásul még igaz is: felesleges részletesen megtervezni valamit, aminek az alapjait nem ismerjük 100%-osan, hiszen a változáskezelés költségeinek pontosan az ilyen információhiányos tervezés adja ki a jelentős részét. 

Általában ennek a szabadságnak a felismerése ad egy lökést a megrendelőnek (product owner) és elkezd ráérezni a tervezés ízére: iterációkba (sprintekre) darabolja a projektet és a User storykat (funkciókat) üzleti értékük szerint priorizálja be.

3. Árazás és ajánlatadás

A hagyományos projektekben általában a funkciókat szoktuk beárazni. Az agilis módszertanokban azonban többnyire erőforrás-ráfordítás alapján árazunk, azaz fejlesztési iterációkat adunk el és a megrendelő dönti el, hogy egy iterációban mit és milyen sorrendben kell lefejleszteni. Ez azt jelenti, hogy az idő, a költség és a minőség adott, mivel az iterációk fix ideig tartanak, fix létszámmal, a minőségen pedig feltehetően senki nem akar rontani... 

Tehát egyedül a scope-ot tudjuk rugalmasan kezelni: a legnagyobb kihívást az jelenti, hogy elfogadjuk/elfogadtassuk: üzletileg értékesebb 7 jól működő funkciót lefejleszteni, mint 10 közepesen jót.

Ez természetesen nem jelenti azt, hogy vaktában elkezdünk fejleszteni és majd meglátjuk hány iterációban valósítjuk meg a scope-ot: az igények felmérése után felmérhető a munka nagyságrendje, azaz hogy hány ember hány iterációban tudja megvalósítani a leírtakat, az egyes iterációkban pedig mindig lehetőség nyílik az újra priorizálásra, hogy a büdzséből a legértékesebb funkciókat valósítsuk meg.

A módszertanból következik, hogy nem lehet az óraszámokkal és az óradíjjal játszani: teljes mértékben transzparens árazási struktúra szerint adunk ajánlatot, hiszen a megrendelőnek mindig világos, hogy hány ember és mennyi ideig dolgozik majd a projekten.

4. Szerződéskötés

Gyakran felmerül a kérdés, hogy hogyan lehet szerződni egy olyan fejlesztési munkára, aminek nem definiált a pontos scope-ja, csak a határideje és a büdzséje.

Mi ezt úgy szoktuk megoldani, hogy a projekt indításakor egy keretszerződést kötünk, amiben általánosan összefoglaljuk a Megrendelő és Vállalkozó (Szolgáltató) kötelezettségeit. E mellett minden egyes iteráció indításkor egy egyedi szerződésben határozzuk meg, hogy az adott időszakban hány fejlesztő, milyen feladatokat lát el és pontosan milyen funkcionalitást fog kifejleszteni. Tehát a scope mindig definiálásra kerül, de pontosan csak a sprint indításakor határozzuk meg ezeket.

Összefoglalás

Értékesítés szempontjából a legfontosabb érték az, hogy a megrendelőt az ajánlatadás során mélyen bevonjuk a projektbe: a saját elképzelései szerint priorizálhat, ütemezheti a feladatokat, így érzelmileg is kötődni fog hozzá. (tudjuk, hogy gyakran a fejlesztő cég diktál, az ügyfél pedig követ - ez látszólag kényelmes, mivel a megrendelőnek nem kell sokat gondolkoznia és a fejlesztők is a számukra kényelmes mederben tarthatják a fejlesztéseket, de utólag ebből mindig problémák adódnak). 

A Scrum természetesen nem elegendő egy projekt megnyeréséhez, de sok esetben kínál olyan alternatívát, ami illeszkedik a megrendelő igényeihez. Ilyen eset például a szolgáltatások fejlesztése, ahol a körülmények és igények folyamatosan változnak. Különösen igaz ez az indulást követő időszakra, amikor az alapötletek helyességéről visszajelzéseket szerzünk: a Scrum segít, hogy alacsony költség mellett rövid idő alatt indítsuk majd be a szolgáltatást és a lényeges pontokra fókuszáljunk.

Ez a poszt természetesen nyitva hagy még rengeteg kérdést, legközelebb az árazási konstrukciókról és a becslési technikákról fogok írni.

Ha szeretnél találkozni és megvitatni agilis kérdéseket, vagy csak tájékozódnál a témában, látogass el a Budapes Agile Meetup Group oldalára és eseményeire.

A témában még érdekes bejegyzéseket ugyanezen az oldalon itt olvashatsz: http://www.meetup.com/AgileHungary/messages/boards/thread/9713039