Agile projektai ir fiksuotos kainos, laiko bei funkcionalumo sutartys

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!

iron_triangle

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šą):

# Funkcionalumas Dydis istorijų taškais (Story Points)
1 Pagrindinių paslaugų peržiūra/užsakymas

20

2 Įvairūs prisijungimo prie sistemos būdai /vartotojų teisių valdymas

15

3 Sąskaitų pateikimas

10

4 Apmokėjimas už paslaugas

15

5 Papildomos paslaugos (pvz. lojalumo programos)

10

 

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” (http://scrum.blogas.lt/pirmas-blynas-iskeptas-27.html). 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

Tagged with: , , ,
Posted in Agile
6 comments on “Agile projektai ir fiksuotos kainos, laiko bei funkcionalumo sutartys
  1. Sergejus says:

    Vaidai,

    o kas jeigu vykdymo metu paaiškėja, kad vertinimas, pvz., Sąskaitų pateikimo modulio yra dvigubai didesnis? Kaip šiuo atveju elgtis, nes projektas jau parduotas už tuos 10 taškų?

  2. Sveikas Sergejau,

    Dėkui už klausimą.

    Nors ir nemandagu, bet atsakysiu į klausimą klausimu: o ką darote dabar, dirbant pagal standartinius metodus, kai projekto vykdymo metu paaiškėja jog pradinis įvertinimas buvo neteisingas? Taigi ką darote dabar, tą teks daryti ir dirbant pagal Agile 😉 (tartis su klientu, mesti papildomų resursų iš savo kišenės ir t.t.).

    Ką noriu pasakyti, kad Agile metodai tikrai nepadeda geriau vertinti užduočių dydžio, ypač prieš projektui prasidendant, kai mažiausiai žinoma apie ką jis, kokios technologinės kliūtys gali būti, kokie žmonės iš tikrųjų prie jo dirbs ir pan. Jei prižadėjote klientui funkcionulmą padaryti per x laiko, o iš tikrųjų jį reikia daryti 2x laiko, tai čia jau reikia užduočių vertinimo problemą spręsti. Ką Agile metodai padeda, tai labai anksti pamatyti ar tie pradiniai įvertinimai iš tikrųjų atitinka realybę ir į tai anksti reguoti.

    Aišku, vėliau, kai jau gaunamas kliento pasitikėjimas, ir kai jis patikės jog jūs sąžiningai dirbate pagal jo aukčiausius prioritetus ir mokės jums pagal funkcionalumą, derinti tokius apimčių pokyčius bus daug lengviau. Bet kaip minėjau, reiktų apie tai galvoti kaip galimą ateities viziją, bet to pasiekti tikrai užtruks laiko.

    Vaidas

  3. Mantas K. says:

    Dažnu atveju sudarant fiksuotos kainos, laiko ir apimties kontraktą, nepavyks išvengti analizės kaip savarankiško etapo. Ir tai daryti teks iš savo kišenės. Pardavimo sąnaudos..

    Juk tiek WBS, tiek ir įverčius reikia įtraukti į kontraktą dar prieš konstravimą. O klientai retai mėgsta projektą išskaidyti į du atskirus etapus su atskirais biudžetais: analizė + konstravimas. Ypač mažesnės apimties projektuose.

    Balansavimas tarp BDUF ir JIT.. Ko gero, tikras „agile“ projektinėje veikloje įmanomas tik po kontrakto pasirašymo.

  4. Sveikas Mantai,

    Tu visiškai teisus, jei klientas įverčius reikalauja įtraukti į kontraktą, analizės fazės neišvengsim. Būtent tai ir norėjau akcentuoti straipsinyje, kad projekto inicijavimas/pradžia/sutarties pasirašymas nelabai skiriasi ar jį planuojame vykdyti pagal standartinius ar pagal Agile metodus. Todėl baimė, kad reikia kažkaip kitaip pasirašinėti sutartis, jei norime vykdyti projektus pagal Agile, yra nepagrįsta.

    Mano nuomone, “tikras Agile”, kai galima praktiškai iš viso nedaryti Big Design Up Front (BDUF), o tiesiog susitarti dėl Produkto užduočių sąrašo (Product Backlog) ir jį detalizuoti Just In Time (JIT), įmanomas, bet vėliau, įgijus kliento pasitikėjimą. Tai patvirtina ir daugybė kitų užsienio kompanijų patirtis (case studies).

    Bet pirma išmokime patys dirbti (vykdyti projektus) pagal Agile metodus, o tada jau bus galima daugiau pakalbėti kaip įtraukti klientus kad visas projektas nuo pat pradžių (idėjos) iki pabaigos būtų “tikras agile” 🙂

    Vaidas

  5. Lukas Simokaitis says:

    O kaip siūlytumėte elgtis valstybinių projektų atveju, kai yra skelbiamas viešas pirkimas ir yra įrašomos sąlygos pateikti analizės dokumentą tokia data, o programavimą atlikti vėliau, kas yra “pure waterfall”. Klientas, o tokių būna, netgi norėtų dirbti iteratyviai tačiau čia koja kiša inspekcijos, kurios tikrina viešojo pirkimo įsipareigojimus bei vertina jų kokybę. Manau tokiu atveju sunku ką nors sugalvoti, nes įmonė irgi nenorės pradėti darbų konstravimo šalia analizės, nes už juos tuo metu niekas nemokės. Tiesiog įdomu ar esate su tuo susidūręs ir ką bandėte keisti?

  6. Sveikas Lukai,

    Ne, asmeniškai su valstybiniais projektais, kurie čia turbūt turimi galvoje, susidūręs nesu. Tačiau esu skaitęs/klausęs/diskutavęs su kolegomis užsienyje kaip jie susitvarko su tokiomis situacijomis.

    Esme yra paprasta: mus aplinka apriboja (įstatymai, tvarkos ar politika įmonėje etc.) ir mes galime būti Agile tiek, kiek tos tvarkos leidžia. Tad jeigu tavo aprašomu atveju klientas pagal įstatymą reikalauja analizės fazės, tai teks ją daryti. Vėl, kodėl negalima jos daryti iteratyviai, su tarpfunkcine komanda, pristatyti klientui dalimis? t.y naudoti visas geras Agile praktikas? O veliau, patvirtinus analizę ir pradėjus developmentą vėl pereiti prie tikro Agile proceso?

    Tad tikrai galima taikyti Agile praktikas ir procesą ir prie “sunkesnių” procesų reikalaujamų iš klientų. Be abejo, bus gaminama artefaktų kurie neneša klientui tiesioginės naudos (gaminsime išmetimui). Galime tai rodyti klientui, sakyti kiek jis galėtų sutaupyti ir už tuos pinigus sukurti naudingo produkto. Bet jei jis norės dokumentų ir už juos mokės užsispyręs, tai to pakeisti nelabai išeis 😉

    Tikiuosi atsakiau į klausimą. Jei ne, patikslink.
    Vaidas

1 Pings/Trackbacks for "Agile projektai ir fiksuotos kainos, laiko bei funkcionalumo sutartys"
Artimiausios mokymų klasės
Data Mokymai - Lektorius
2017 m. gruodžio 14-15 d. Certified Scrum Master (CSM) - Alexey Krivitsky (anglų kalba)
2017 m. gruodžio 14-15 d. Certified Agile Leadership CAL1 - Angel Diaz-Maroto (anglų kalba)
2018 m. sausis 18-19 d. Certified Scrum Product Owner (CSPO) - Lasse Ziegler (anglų kalba)
2018 m. sausio 26 d. Agile projektų valdymo pagrindai - Vaidas Adomauskas (lietuvių kalba)
2018 m. vasario 8-9 ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas (lietuvių kalba)
2018 m. Management 3.0 Change and Innovation Practices
2018 m. Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas (lietuvių kalba)
2018 m. Better Retrospectives - Jeff Campbell (anglų kalba)
2018 m. Kanban System Design (KMP I) - Gaetano Mazzanti (anglų kalba)
Visi mokymai
Archives
Categories
Kontaktai

Viešos mokymų klasės:
E-paštas: mokymai (at) agilecoach.lt
Mob. tel.: 8 686 32487

Konsultacijos ir mokymai įmonėms:
E-paštas: vaidas (at) agilecoach.lt
Mob. tel.: 8 686 32487