Tai neįmanoma! Tai nesuderinama su Agile principais! Klientai visada reikalauja apibrėžti kainą, laiką ir funkcionalumą sutartyse, tad mes negalime būti Agile! Ar tikrai tai tiesa?? Siūlau panagrinėti pavyzdį kaip Agile metodus galima taikyti net jei klientai reikalauja fiksuotų sutarčių. Dar daugiau, pasirodo mes net turėsime šį tą papildomo pasiūlyti klientui!
Standartinė sutartis, bet su papildomomis naudomis klientui
Tarkime, klientas mums atsiuntė pasiūlymo prašymą (Request For Proposal). Mes, kaip ir visada, atlikę preliminarią analizę įvertiname projekto funkcionalumą, apimtį ir reikalingus resursus. Remiantis šiais duomenimis esame pasiruošę pateikti siūlymą ir pagal jį pasirašyti sutartį. Taigi kol kas, viskas kaip esame pratę. Dabar galėtume pasirašyti sutartį, tiesiog ją vykdyti pagal Agile metodus, išnaudodami jų teikiamas naudas vykdymui. Bet jei jau kalbame apie sutartis, o ne jų vykdymą, prieš pasirašant atlikime dar šiuos veiksmus.
Kartu su klientu visą funkcionalumą prioretizuokime pagal jo svarbą klientui. T.y. sutartyje esantis funkcionalumo sąrašas turi būti išdėstytas tokia tvarka, kur aukščiausiai stovėtų pats vertingiausias, o žemiau mažiau vertingas ir t.t (Scrum terminais kalbant, sukurkime produkto užduočių sąrašą). Pavyzdžiui, jei kuriame savitarnos sistemą, sąrašas galėtų atrodyti taip (realiame gyvenime jis bus žymiai detalesnis): pagrindinių paslaugų peržiūra/užsakymas; įvairūs prisijungimo prie sistemos būdai/vartotojų teisių valdymas; sąskaitų pateikimas; apmokėjimas už paslaugas; papildomos paslaugos (pvz. lojalumo programos). Atkreipkite dėmesį, kad labai svarbu prioretizuoti pagal vertę klientui, o ne techninius aspektus. Pvz. mūsų pavyzdyje daugelis techninių žmonių tikriausiai pirmu prioritetu rinktųsi prisijungimo funkcionalumą. Bet kokia iš jo vertė klientui? Gal paprasto prisijungimo su vartotojo vardu peržiūrėti paslaugoms pradžiai užtenka, o vėliau galima pagalvoti apie sudėtingesnius prisijungimus per bankus ir pan.
Kitas svarbus momentas yra prioretizuoto funkcionalumo dydžio įvertinimas. Tikriausiai jūs jau esate tai padarę (nes tik taip galėjote nuspręsti kiek laiko užtruks projektas), tad šiame žingsnyje tiesiog įrašykite tą dydį šalia funkcionalumo. Aš dėl paprastumo naudosiu reliatyvius dydžius – istorijų taškus (Story Points), bet jei jūs turite įvertinimus žmogaus valandomis ar žmogaus savaitėmis, šie skaičiai taip pat puikiai tiks.
Taigi po šių dviejų žingsnių turime tokį prioretizuotą ir įvertintą mūsų pavyzdinį savitarnos sistemos funkcionalumo sąrašą (prodkto užduočių sąrašą):
Ką mums duoda tokios formos sąrašo turėjimas sutartyje? Pirmiausiai, tai mums yra labai aiškus sistemos kūrimo planas. Dirbant pagal Agile principus, mes pilnai įgyvendinsime pirmą funkcionalumą, ir tik kai jis bus pilnai baigtas (Done) imsimės sekančio. Taigi mes kursime nuolat augančią funkcionalumo prasme sistemą, kuri visada bus paleidžiama (Potentially Shippable).
Antra, mes galime įtašyti dvi papildomas naudas klientui į sutartį:
Klientas turi teisę projekto metu iškeisti dar nepradėtą funkcionalumą į tokio pat dydžio naują funkcionalumą. Pavyzdžiui, jei projekto viduryje, klientas sugalvojo jog vietoj „Papildomų paslaugų” funkcionalumo jo klientai labiau būtų patenkinti „Užklausų klientų aptarnavimo skyriui” funkcionalumu. Atlikus įvertinimus paaiškėjo, jog abu funkcionalumai yra maždaug 10 istorijų taškų dydžio. Taigi nekeičiant sutarties terminų ir sąlygų klientas gali tiesiog padaryti šį pakeitimą.
Klientas turi teisę nutraukti projektą anksčiau laiko, jei jis nuspręs, kad įgyvendinto funkcionalumo užtenka, kad projektas būtų sėkmingai baigtas. Nutraukiant projektą, klientas turi sumokėti x% neatliktų darbų vertės. Paklausite kaip tai įmanoma? Prisiminkime statistiką paminėtą 10 skaidrėje straipsnyje Pirmas blynas iškeptas. 64% funkcionalumo sistemose yra retai arba niekada nenaudojami. Šis funkcionalumas dažniausiai kuriamas tik todėl, kad vykdytojai liepia klientams surašyti į reikalavimus viską ką tik jie galėjo sugalvoti, nes vėliau „bet koks pokytis kainuos labai brangiai”. Kaip žinote, taikant Agile metodus yra kitaip. Pilnai pabaigtas funkcionalumas kuriamas funkcija po funkcijos. Taigi, tarkim mūsų pavyzdiniu atveju, įgyvendinus pirmas 4 funkcijas klientas nusprendžia, jog penktąja „papildomų paslaugų” funkcija, iš tikrųjų, naudosis labai mažai klientų ir neverta dabar jos kurti. Taigi jis gali nuspręsti paleisti sistemą be šio funkcionalumo, mums tiesiog sumokant x% nuo neatliktų darbų (nes reikia perskirstyti žmones ir pan.). Man mokymuose diskutuojant su Ken Schwaber ir šveicarų IT įmonių darbuotojais, kurie taiko tokio tipo sutartis paaiškėjo, kad neretai sistemos paleidžiamos įgyvendinus ~60% aukščiausio prioriteto funkcionalumo. Tad galite paskaičiuoti kiek pinigų galėtų sutaupyti klientai. Ir be abejo, sutaupytus pinigus jie norės vėl išleisti įgyvendinant naujas projektus su jūsų įmone!
Apmokėjimo už įgyvendintą funkcionalumą sutartis
Įgijus kliento pasitikėjimą keliais sėkmingais projektais, galima žengti žingsnį toliau. Galima susitarti su klientu kad projekto funkcionalumo sąrašas (produkto užduočių sąrašas) yra jo atsakomybė. Klientas jį valdo, prioretizuoja, keičia. Vykdytojas funkcionalumą visada įgyvendins pagal sąrašą nuo viršaus. Taigi ir mokėti klientas turės pagal įgyvendintą funkcionalumą. Tai leidžia klientui būti visiškai lanksčiam su reikalavimais (produkto užduočių sąrašu), turėti nuolat augančią ir paleidžiamą sistemą, ir mokėti dalimis. Dirbant pagal Agile metodus sugebame lengvai susitvarkyti su greitai kintančiais sistemos reikalavimais, nuolat kurti tai kas klientui naudingiausia ir nuolat gauti pajamas!
Agile naudojimas fiksuotų sutarčių projektuose, tai tiesiog papildomos naudos visiems
Taigi, kaip matote, Agile metodus galima puikiai naudoti ir fiksuotose sutartyse. Visas Agile suteikiamas lankstumas gali būti tiesiog įrašytas kaip papildoma nauda klientui. Tada jis sprendžia ar ta nauda naudotis ar ne. Užsienio kompanijų patirtis rodo, kad tokios pridėtinės naudos ir kuria geriausius santykius su klientais bei abipusį pasitikėjimą. Įmonės, gebančios dirbti pagal Agile metodus ir siūlančios tokias naudas klientams, tampa patraukliausios. Tad ar yra įmonių norinčių tokiomis tapti Lietuvoje? ;)
*Įdomus straipsnis šia tema anglų kalba: http://www.tinypm.com/papers/tinypm_atw_series_fixed_price.pdf