Statistika rodo, kad apie ¾ programinės įrangos projektų nepasiekia užsibrėžtų tikslų - vėluoja, viršija biudžetą arba visiškai sužlunga ir yra nutraukiami. Apklausos rodo, kad didžioji dalis problemų identifikuojama reikalavimų apibrėžimo ir valdymo srityje. Reikalavimai neteisingai suprantami dėl nepakankamo vartotojo įtraukimo, jie nepilnai arba nevienareikšmiškai apibrėžiami, todėl keičiasi projekto eigoje. Pagal reikalavimus vertinama projekto apimtis ir kaštai, planuojamos veiklos bei sekamas progresas.
Paprastai reikalavimų pasikeitimų kaina smarkiai išauga projektui pereinant į vėlesnes fazes, kadangi gali tekti taisyti daug jau sukurtų artefaktų: susijusių reikalavimų aprašymus, projektavimo modelius, programinį kodą. Dėl šių priežasčių tradiciniai reikalavimų inžinerijos principai siūlo išsamiai dokumentuoti reikalavimus, siekiant sumažinti reikalavimų pasikeitimų tikimybę, bei taikyti apibrėžtas procedūras pakeitimų valdymui: pateikimui, vertinimui bei realizavimui.
Reikalavimų dokumentavimas
Reikalavimų dokumentavimui paprastai yra paruošiami dokumentų šablonai bei jų pildymo taisyklės ir pavyzdžiai. Įvairūs procesai, pvz. RUP (Rational Unified Process), siūlo reikalavimų dokumentavimo metodikas bei reikalavimų dokumentų šablonus, kuriuose apibrėžta struktūra ir pateikiami nurodymai, ką kiekviename skyriuje reikėtų rašyti. Reikalinga vieninga dokumentavimo sistema: šablonai, apibrėžiantys dokumentų struktūrą bei stilių, užpildymo taisyklės, pavyzdiniai dokumentai, dokumentų peržiūros ir taisymo taisyklės.
Daugelyje Lietuvoje įgyvendinamų programinės įrangos kūrimo projektų yra taikomi tik keli dokumentavimo būdai. Dažniausiai yra ruošiamos funkcinės reikalavimų specifikacijos, kuriose aprašomos produkto funkcinės savybės (features) arba panaudos atvejai (use cases), reikalavimai detalizuojami naudojant grafinės vartotojo sąsajos prototipus. Dažnai svarbiausi ar sunkiai suprantami iš tekstinio aprašymo reikalavimai atvaizduojami UML arba paprastomis diagramomis.
Efektyviai reikalavimų analizei reikalingi darbuotojai, turintys atitinkamą sistemų analitiko specializaciją. Kuriant „MagicDraw UML“, kiekvienos versijos naujas funkcionalumas yra išskaidomas į savybes (feature) arba modulius (jeigu tai yra nauja dalis, kuri gali būti gerai atskirta nuo esančio funkcionalumo). Kiekvienai daliai paskiriamas atsakingas analitikas, kuris ruošia atskirą reikalavimų dokumentą: aprašo realizavimo reikalavimus, ypatingą dėmesį skiria vartotojo sąsajai, naudojimo patogumui (usability) ir nefunkciniams reikalavimams. Vėliau analitikas seka jam priskirto funkcionalumo realizavimo procesą, konsultuoja programuotojus ir kokybės inžinierius. Atsakomybė ir kontrolė padeda geriau realizuoti reikalavimus ir paruošti kokybiškesnį produktą.
Vizijos dokumentas yra vienas svarbiausių reikalavimų dokumentų. Jis padeda užsibrėžti projekto tikslą, ir viso projekto vykdymo metu padeda nenukrypti į šoną. Dažnai reikalavimai yra keičiami dėl to, kad jie buvo aprašyti nevienareikšmiškai ir skirtingai suprasti skirtingų žmonių, dalyvaujančių projekte. Reikalavimų daugiareikšmiškumo padeda išvengti dalykinės srities sąvokų žodynas. Jis padeda užtikrinti, kad vartotojas bei sistemos kūrėjas naudotų tą pačią terminologiją, išvengti programinės įrangos kūrėjų nesusišnekėjimo su vartotoju bei įsigilinti į dalykinę sritį.
Sudaromas dalykinės srities grafinis modelis, aprašytas statinėmis ir dinaminėmis UML diagramomis. Modeliuojami dalykinės srities terminai, jų tarpusavio ryšiai bei scenarijai, kaip vykdomos tikslinės veiklos. Aprašomi sistemos funkciniai reikalavimai: kokias funkcijas turi atlikti kuriama sistema, ir kaip šios funkcijos turi būti atliekamos. Dokumentuojant sistemos reikalavimus galima įtraukti ir vartotojo sąsajos eskizus. Vartotojo sąsajos eskizai padeda klientui lengviau suprasti reikalavimus, jis lengviau įsitraukia i reikalavimų rinkimo bei analizės procesą. Reikalavimai detaliau išsiaiškinami dar reikalavimų rinkimo fazėje, ir išvengiama reikalavimų pasikeitimų vėlesnėse sistemos kūrimo fazėse.
Nepaisant išsamaus aprašymo, dažnai kyla įvairių nesusipratimų ir klausimų, kurie nebuvo išspręsti rašant reikalavimus. Taip pat neretai kyla esminių nesutarimų, dėl reikalavimų pakeitimų ir programinio kodo perdarymų priežasčių. Norint sumažinti tokių pasikeitimų, reikalingos reikalavimų dokumentų peržiūros prieš pradedant projekto realizavimą. Reikalavimus ir jų siūlomus pakeitimus visų pirma peržiūri analitikų vadovas, techninis projekto vadovas bei kokybės grupės vadovas. Mūsų patirtis rodo, kad efektyviausiai reikalavimai peržiūrimi ir išanalizuojami tuomet, kai kokybės inžinieriai testavimo planus parengia pagal aprašytus reikalavimus. Kadangi neišsamiai ar neaiškiai parašyti reikalavimai sukelia daug klausimų, jie išsprendžiami dar prieš realizuojant projektą.
Pavyzdžiui, kuriant „MagicDraw UML“, analitikas aprašo kiekvienos funkcionalumo savybės reikalavimus atskirame dokumente, kurį programuotojai naudoja realizuodami tą savybę.
Nors ir išsamiai dokumentuojant reikalavimus, beveik visada projekto eigoje atsiranda daugiau ar mažiau pakeitimų. Kuo vėliau įvyksta pakeitimas, tuo didesnė yra jo įgyvendinimo kaina. Pakeitimai taip pat turi įtakos projekto apimčiai ir darbų tvarkaraščiams, todėl reikia juos įvertinti, priimti arba atmesti, suskirstyti pagal prioritetus, tikrinti jų realizavimą.
Agile metodika
Šiuo metu sparčiai populiarėja „Agile“ procesai, siūlantys kuo mažiau dėmesio skirti dokumentavimui. Programinė įrangą kuriama trumpomis iteracijomis, o vartotojo poreikiai išsiaiškinami bendraujant tiesiogiai. Tarpinių programinės įrangos versijų vertinimas atliekamas kiekvienos iteracijos pabaigoje. Reagavimą į pakeitimus nei plano vykdymą. Reikalavimų pakeitimai yra priimtini netgi vėlyvose projekto fazėse.
Agile metodikos schema
Nors „Agile“ siūlomi metodai gali būti labai efektyvūs, tačiau jie reikalauja visiškai kitokio programinės įrangos kūrimo proceso, jo planavimo, valdymo ir finansavimo. Visų pirma, „Agile“ metodai pagrįsti tuo, kad programinės įrangos kūrimas yra apmokamas už trumpo periodo iteracijas pagal dirbtų valandų skaičių. Daugelyje projektų toks požiūris nėra priimtinas, nes iš anksto nustatomas viso projekto biudžetas, pagal numatytus reikalavimus skelbiami konkursai programinei įrangai kurti. Taip pat sunku įtraukti vartotoją, kai jam pateikiamos dažnai atnaujinamos programinės įrangos versijos.
Tai ypač keblu, kai kalbama apie kritines arba svarbias verslo valdymo sistemas (bankinės, gamyklų valdymo, apskaitos sistemos), kurių galutiniai vartotojai neturėtų dirbti su tarpinėmis neišbaigtomis programinės įrangos versijomis. Be to praktikoje dažniausiai yra labai sunku, o kartais ir neįmanoma, įtraukti vartotojus ir verslo atstovus į kasdienius programinės įrangos kūrimo procesus.
Bendraujant gyvai galima išsiaiškinti daug detalių, tačiau nedokumentuota informacija paprastai yra įvairiai interpretuojama ir kinta ją perduodant. Greitai reaguoti į pakeitimus ir atsisakyti formalaus reikalavimų pakeitimų valdymo galima tik tuomet, kai pakeitimai yra nežymūs. Tačiau stambesni pakeitimai turi būti apsvarstomi, įvertinami, jiems turi būti suteikiami prioritetai. Dideli pakeitimai lemia ne tik vykdomo projekto apimtį, darbų tvarkaraščius, bet ir produkto išleidimo į rinką laiką.
Dėl minėtų priežasčių „Agile“ metodai labiau tinkami naujiems produktams kurti bei vykdyti vidinius projektus, kur galutinius vartotojus gali pakeisti kompanijos darbuotojai. Šiuo atveju prioritetų suteikimas ir pakeitimų valdymas tampa mažiau formalus, nes yra lengviau valdyti projekto apimtį, tvarkaraščius ir biudžetą. Nors „Agile“ metodai beveik idealiai tinka produktams, vidiniams projektams ir atviro kodo sistemoms kurti, tačiau užsakomiems projektams jų tiesiogiai taikyti neverta, nes nėra tenkinamos dauguma potencialios sėkmės sąlygų.
Kaip pranešime žiniasklaidai teigia Lina Bisikirskienė, IT įmonės „Cognizant“ verslo analitikė, technologijų srities mokslų daktarė, taip, „Agile“ padeda sustyguoti nemažą kiekį iššūkių, susijusių su informacinių technologijų IT (ir ne tik) projektais bei produktais. Taigi, renkantis ar man „Agile“ tinka ir, ar šią metodiką galima pritaikyti mano organizacijoje, reikia atsakyti į klausimą - tai su kokiais iššūkiais mes susiduriame ir, ar jie yra tie, kuriuos sprendžia „Agile“?
„Agile“ skatina turėti greitą sukurto funkcionalumo patekimą pas vartotoją (gali būti galutinis, gali būti bandomosios versijos), pavyzdžiui, rečiausiai tai galėtų būti kartą į dvi savaites, o geriausiu atveju - iškart, kai funkcionalumas pilnai sukuriamas. Tokiu būdu galima patikrinti ar jis duoda tą naudą, kurios tikėjomės ir, ar sprendžia problemą, kurią turėjome. Iš projektų įmonėje esu pastebėjusi, jog tik greitas grįžtamasis ryšys (pavyzdžiui, dvisavaitinis) leidžia ieškoti naujų sprendimų, jei esami neveikia. Jei darbai vyksta ketvirčiais ar pusmečiais, jei grįžtamojo ryšio nėra, jo vengiame ar visai neturime, tai „Agile“ pas jus, deja, nėra.
Šie principai galioja tiek organizacijose, kurios vysto IT produktus, tiek organizacijose, kurioms reikia IT produktų, bet juos užsisako ar perka iš kitų tiekėjų. Darbo principų bei mąstymo sustygavimas leidžia judėti į priekį. Jei turime dvi konfrontuojančias puses, kurios baksnojasi pirštais, tai sėkmingo produkto neturėsime.
Mūsų patirtis rodo, kad pasitikėjimas kuriamas nuo mažų dalykų, nedidelio projekto, žingsnis po žingsnio sustyguojantis lūkesčius ir kartu kuriant produktą bei pasitikrinant ar pasiekėme tai, ko norėjome. Nepamirštant, kad visada yra tikimybė, kad reikės keisti planus gavus gyžtamąjį ryšį. Niekam nepatinka būti kaltu dėl sprendimo, kuris buvo priimtas ir vėliau keičiamas. Vis dėlto, jei tai komandinė atsakomybė ir susitarimas, kad to neišvengsime darbuojantis, tai ir lūkesčių konflikto nebelieka.
Komandos dažnai susiduria su situacijomis, kad galutinis produktas yra netinkamas, o pinigų ir laiko yra išleista labai daug. Paslaptis labai paprasta - kai netinkamai užduodame klausimus, tai ir gauname netinkamus atsakymus apie kuriamą produktą. O produkto viziją, o kartais net ir sprendimą, nustato organizacijos vadovas (gali būti ir departamento vadovas). Vizijos nebuvimas yra kritinė problema, tačiau ir jos turėjimas yra ne pilna informacija, kurios reikia. Organizacijos vadovas turi gebėti perteikti, kodėl tokia vizija buvo suformuota, kokia organizacijos istorija lėmė jos atsiradimą. Tai gali būti paremta vertybėmis, klientų lūkesčiais.
Komandoms nereikia kurti šios informacijos, bet ją žinoti yra labai svarbu, tai leidžia suprasti kontekstą. Dažna klaida pasitaiko tuomet, kai vadovas turi sprendimo viziją ir jos laikosi, net jai ir nepasiteisinus. Komanda, suprasdama problemą ir kontekstą, gali gerokai efektyviau rasti tinkamą sprendimą. Kuo efektyviau gauname grįžtamąjį ryšį, tuo greičiau suprantame ar pasirinktas kelias buvo teisingas.
Dar viena svarbi rolė yra produkto vadovas, kurio darbas gali labai skirtis skirtingose organizacijose, nes sudėlioti procesai nėra vienodi. Vis dėlto, jam turi būti keliami labai aiškūs lūkesčiai susiję su produktu - tai žmogus, kuris turi apie produktą žinoti viską ir gebėti tą informaciją iškomunikuoti, tačiau tai nėra žmogus, kuris turi sukurti produktą vienas pats. Jo pagrindinis tikslas yra transformuoti organizacijos vadovo idėją į problemą, kuriai komanda suras technologinį sprendimą. Kuo daugiau informacijos bus perteikta, tuo tikslesnį sprendimą gali komanda surasti.
Tiek produkto vadovas, tiek komanda turi puikiai pažinoti savo klientus, jų įpročius, girdėti jų norus bei juos analizuoti viso produkto kontekste. Tiesioginis klientų norų pildymas dažnai lemia produkto fokuso pametimą. Taigi, apie produktą mums reikia suprasti ne tik funkcionalumą (ar mes galime jį įgyvendinti), bet taip pat ar jo reikia klientams, ar jie mokės juo naudotis ar iš jo organizacija gali uždirbti pinigus. Žinant atsakymus į šiuos klausimus, kyla mažiau nusistebėjimų, kodėl vadovai priėmė sprendimą eiti pigesniu keliu arba pakeisti prioritetų sąrašą.
Komanda geba mokytis iš savo klaidų, keistis žiniomis, generuoti idėjas, bendradarbiauti su klientais. Tai yra įgalinta komanda (angl. empowered team). Tikriausiai nereikia sakyti, koks būna priešingas rezultatas.
Tokie organizaciniai modeliai kaip „Lean“ ir „Agile“ šiandien jau tapo gan įprastais terminais ne tik vadybos mokslinėje literatūroje, bet ir praktikoje. KTU mokslininkų tyrimai rodo, kad tinkamai pasirinktas organizacijos valdymo modelis gali teigiamai paveikti įmonės finansus ir padidinti simbolinius pasiekimus suinteresuotųjų šalių atžvilgiu. Pasak mokslininkų, svarbiausia - organizaciją vystyti kryptingai. Todėl taikyti visus modelius vienu metu nerekomenduojama.
Neseniai išleistoje monografijoje KTU mokslininkai aptaria dažniausiai Lietuvoje pasitelkiamus įmonių organizavimo modelius ir jų poveikį įmonės veiklos sėkmingumui. Pastebėta, kad aukšti kokybės ir inovatyvumo pasiekimai susiję su finansinių pajamų augimu. Skaitmenizacijos gebėjimai lemia didesnį įmonių produktyvumą.
Monografijoje aptariami populiarūs organizaciniai šablonai, jų paplitimas bei galima nauda: „Lean“, kurio pagrindinis tikslas - pasiekti aukštą kokybę su mažomis gamybos sąnaudomis; „Agile“ - pasiekti tokią situaciją, kad kiekvienas klientas gautų tai, ko nori, t. y. prisitaiko prie jų poreikių ir norų.
Tyrimas atskleidė, kad labiausiai organizacijoje paplitusios „Lean“ praktikos - jas taiko 50 proc. Lietuvos pramonės įmonių. 20 proc. organizacijų vadovaujasi „Agile“ metodika ir tik mažiau nei 5 proc. Lietuvos pramonės skaitmenizacijos lygis, M. Vilko teigimu - vidutinis, lyginant su kitomis Europos šalimis. Tačiau kitų tyrimų duomenys rodo, kad jaunuose šalyse, taip pat ir Lietuvoje, veikiančios organizacijos sparčiau įgyja skaitmeninimo kompetencijas.
Remdamiesi tyrimo išvadomis, monografijos autoriai neskatina įmonių taikyti dviejų ar net visų trijų modelių vienu metu ir pasirinkti vieną iš jų. Tačiau, pavyzdžiui, taikydama „Lean“ modelį ir realizavusi dalį tikslų, įmonė turi galimybę ugdyti kompetencijas, susijusias su kitais modeliais.
„Mūsų tyrimai rodo, kad finansinis augimas susijęs su organizacijos veiklos kokybe, gebėjimu diegti naujoves. Skaitmeninimo kompetencijos leidžia pasiekti didesnį našumą visuose organizacijos modeliuose“.
Kanban metodas
„Kanban“ - tai paprasta produktų kūrimo metodologija, pagrįsta nuolatiniu pristatymu. Plačiąja prasme „Kanban“ yra metodas, padedantis darbo procese pastebėti kliūtis bei jas spręsti. Tai ir vienas iš Agile projektų valdymo metodų. Įprastai Agile metodologija organizacijose diegiama siekiant efektyviau organizuoti procesus ir greičiau pateikti vertę vartotojams. Jos pagalba, naudojant konkrečius metodus, įmonės mokosi tinkamai planuoti, sekti projektus, jų apimtis, skiriamą laiką.
Kanban lentos pavyzdys
Vienas iš Agile principų teigia, kad vertė klientui turi būti pateikta kuo trumpesniais laikotarpiais, dėl to dideli projektai ir darbai yra skaidomi į mažas dalis. Tai leidžia projektą vykdyti ne visą vienu metu, o suskaido jį į atskirus etapus, naudojant detalų planą. Agile metodai, tarp jų ir „Kanban“, sudaro galimybę įgyvendinti geresnę bei patogesnę kontrolę, kuri užtikrina ne tik skaidrumą organizacijoje, grįžtamąjį ryšį, bet ir aukštą kokybę.
Tokie principai taikomi ir „Kanban“ metode. Tačiau, norint vadovautis būtent juo, reikia laikytis ir specifinių pagrindinių taisyklių. Visų pirma, vienu metu atliekamų darbų kiekis privalo būti limituojamas. Antra, didelę reikšmę vertėtų skirti vizualinei pusei. Tam, kad Kanban metodas būtų efektyvus, visas darbo procesas turėtų būti vizualizuotas. Nepaisant to, kad tai - nesudėtingas ir patogus metodas, dalis žmonių, nesilaikydami kurios nors iš paminėtų taisyklių, nepasiekia norimų rezultatų.
Kaip ir minėta, taikant „Kanban“ metodą didelę svarbą turi procesų vizualizavimas. Tam, kad tai padaryti būtų galima kuo paprasčiau ir tikslingiau, naudojama planavimo lenta. Norint pradėti naudotis šiuo įrankiu, svarbus pasiruošimo procesas. Visų pirma, reikėtų suskirstyti baltą lentą į tris stulpelius. Pirmąjį stulpelį pavadinkite „Reikia padaryti“, antrąjį - „Daroma“, o trečiąjį - „Atlikta“.
Paruoštoje lentoje pirmiausia reikėtų pažymėti dalykus, kuriuos reikia įgyvendinti. Tai padaryti galima užrašant juos markeriu arba tiesiog klijuojant lipnius lapelius su konkrečia užduotimi. Šiame stulpelyje darbai turėtų būti formuluojami su veiksmažodžiu. Čia svarbu paminėti, kad tin dažnai pasitaiko klaida, kuomet visas projektas įkeliamas kaip viena užduotis ir tai - ydinga praktika.
Tuomet, kai esate pasiruošę atlikti konkrečią užduotį iš pirmojo stulpelio, perkelkite ją į antrąjį stulpelį. Dirbant užduotys natūraliai nuolat keliauja iš kairės į dešinę lentos pusę. Užduoties pasirinkimas ir jos perkėlimas į antrąjį stulpelį automatiškai priverčia darbus prioretizuoti. Taip pat tai padeda nuolat peržiūrėti reikiamų atlikti darbų sąrašą. Šie paprasti veiksmai užtikrina viso proceso sklandumą.
Trys paminėti stulpeliai - tik pradžia. Tuomet, kai priprasite naudotis lenta, pridėkite naujų stulpelių. Pavyzdžiui, atspindinčių, kokie darbai laukia toliau (užduotims, kurias reikia atlikti, tačiau ne šiuo metu). Pildant lentą svarbu nepasimesti ir nepamiršti, kad vienas esminių darbų žymėjimo principas - užduočių rūšiavimas ir jų atvaizdavimas nuo paties svarbiausio iki mažiausią svarbą turinčio darbo.
Dauguma „Kanban“ metodo „naujokų“ savo planavimo kelią pradeda su balta lenta, lipniais lapeliais. Esant poreikiui yra ir įvairiausių elektroninių (online) Kanban įrankių, kuriuose taip pat galima atvaizduoti komandos “work flow”.
Lean, Agile ir skaitmenizacija
Apibendrinant galima teigti, kad organizacijos, siekiančios efektyviai valdyti turtą, turėtų atsižvelgti į šiuos aspektus:
- Lean: Orientuotas į aukštą kokybę ir mažas gamybos sąnaudas.
- Agile: Orientuotas į kliento poreikius ir greitą prisitaikymą prie besikeičiančių reikalavimų.
- Skaitmenizacija: Leidžia pasiekti didesnį našumą visuose organizacijos modeliuose.