
Vienas protingas žmogus yra pasakęs: „protingas žmogus pirma galvoja, o po to daro“. Tai yra esminis sakinys, apibūdinantis, kodėl IT (ir ne tik IT) projektuose, prieš pradedant daryti, taip svarbu gerai suplanuoti. Arba, kaip sako Lietuvių liaudies patarlė: devynis kartus atmatuoti, o dešimtą kirpti.
IT projektai kaip statybos. Negalima uždengti stogo, kai nėra sienų. Labai svarbu gerai pasiruošti. Kuo geresnis pasiruošimas, tuo sklandžiau vyks statybų procesas, tuo mažiau bus streso eigoje, tuo didesnė tikimybė, kad tiek jūs, tiek užsakovas liksite patenkinti bendradarbiavimu.
Yra parašyta daugybė knygų, sukurta skirtingų metodikų, kaip optimaliai valdyti IT projektus, kaip jiems pasiruošti ir t. t. Jos tikrai veikia, bet ne visada. Su kuo daugiau įvairių klientų tenka dirbti, startuoti su skirtingais projektais ir pan., tuo dažniau pastebiu, kad negalima aklai laikytis įsikibus vienos ar kitos metodikos, o reikia atsižvelgti į klientą ir žinoti, kada ir ką taikyti, o kada aplinkybės nėra tinkamos.
Šiame straipsnyje nerašysiu vadovėlinių teorijų (nieko prieš jas neturiu), tačiau pasidalinsiu praktiniais patarimais, kokius momentus yra svarbiausia aptarti su klientu prieš pradedant projekto įgyvendinimą, kad jis „nenuvažiuotų nuo bėgių“.
Turinys:
- Projektas (produktas)
- Laikas
- Pinigai
- Rolės
- Projekto sėkmė
- Esminiai pavojai
- Komunikacija
- Pasiruošimo darbai
- Apibendrinimas
Projektas (produktas)
Pradėsime nuo standartinių kiekvieno projekto sudedamųjų dalių, kurių viena yra produktas – tai, ką norime sukurti.
Dažnai mūsų įsivaizdavimas ir kliento įsivaizdavimas, kaip turi atrodyti galutinis produktas, gali labai skirtis. Statybose, kad visiems būtų aišku, kas bus pastatyta, pradžioje yra daromos vizualizacijos ir brėžiniai. Tada tiek užsakovas, tiek jūs galite suvokti, kaip atrodys statinys, nebereikia kurti to savo galvoje. Tam pačiam tikslui pasiekti IT labai padeda prototipų kūrimas arba dizaino parengimas. Matant realų vaizdą, žymiai lengviau susitarti, ar tai, kas nupiešta, yra tai, ką abi pusės įsivaizduoja.
Taip pat čia labai svarbu abiems pusėms aiškiai iškomunikuoti, koks projekto tikslas. Žinant tikslą bus žymiai lengviau nuspręsti, kokias priemones reikia pasirinkti tam tikslui pasiekti ir kaip atrodys galutinis produktas. Įsivaizduokite, kad jūs – statybininkas, o užsakovas jums sako: „man čia reikia pastato su stogu, kad per viršų nelytų“. Pastatote jam dviaukštį gyvenamąjį namą, o po to sužinot, kad reikėjo viso labo garažo, kur laikyti automobilį, kad tiesiog lauke nestovėtų.
Taigi, žinant projekto tikslą, galime nuspręsti, kokias priemones naudosime, kad tą tikslą pasiektume. Čia yra labai svarbus momentas, kad dažnai jūsų įsivaizdavimas ir užsakovo įsivaizdavimas, kokių priemonių reikia, gali kardinaliai skirtis. Šioje vietoje labai svarbu, kad abiems pusėms būtų aišku, kokios priemonės bus panaudotos pasiekti tikslą. Nuo to vėliau priklausys ir kaina, ir laikas, reikalingas projektui įgyvendinti.
Labai dažnai, ypač didesniuose projektuose, žymiai lengviau su klientu apsitarti projekto tikslą, nei suderinti, kas tame projekte turi būti, kad pasiekti tą tikslą. Klientas mano, kad reikia ir to, ir ano, ir tokios funkcijos, ir dar tokios, o dėl trečios išvis negali apsispręsti, jam reikia pasitarti su kitais skyriais ir pan. Ir taip procesas gali išsitęsti labai ilgai. Atrodo, puiku, viską detaliai išnagrinėsime, o tada jau pajudėsime, bet.. laikas eina, o taip niekaip ir nepajudame. Šioje vietoje, bent jau mums, dažnai padeda ekspertizė. Galvoje turiu tai, kad greičiausiai, jei klientas nusprendė su mumis kurti projektą, jis mumis pasitiki ir mato mus kaip ekspertus. Jei ne, tada man neaišku, kodėl rinkosi tokią įmonę. Kaip ekspertai, visada galime patarti, kad ši ar kita funkcija nėra svarbi pradiniame etape ir dabar, kad pasiektume mūsų tikslą, žymiai svarbiau pradėti nuo darbų x.
Laikas
Kai žinome, koki pastatą norime pastatyti, galime visą statybų procesą padalinti į dalis. IT projektuose tai būtų viso darbo (angl. scope) suskirstymas į etapus (angl. sprints). Kodėl tai yra labai svarbu? Tai leidžia mums nusistatyti aiškius terminus, kada ir kas turi būti atlikta. O tai savo ruožtu leis sekti, ar mums pavyksta laikytis to, ką nusistatėme. Taip pat tai padės bendraujant su klientu. Mūsų klientas turi aiškiai žinoti, kada ir kas bus padaryta. Kokiais etapais dirbsime, kokie kiekvieno etapo pabaigos terminais. Viską aiškiai suderinus, nebus taip, kad būsite apkaltinti, kodėl darbai x nepadaryti, o klientas greičiausiai neturės nepagrįstų reikalavimų jums, matydamas, kas ir kokiais laiko intervalais bus atliekama.
Pinigai
Žinant, kas turi būti atlikta, kada turi būti atlikta, galite preliminariai apsibrėžti, už kokius pinigus tai bus atlikta. Aiškus viso projekto darbų suskirstymas į mažesnes dalis ir tų dalių apibrėžimas laike leis jums tiksliai susitarti dėl apmokėjimo sąlygų. Pvz. baigiame 1 sprint’ą, jame atliekame tokius ir tokius darbus, pristatome atliktus darbus klientui, gauname apmokėjimą.
Kalbant apie pinigus, labai svarbu ne tik aiškiai su klientu susiderinti kainas už darbus, kuriuos atliksite, bet ir aiškiai sutarti, kaip, kokiais terminais bus apmokama už atliktus darbus.
Rolės
Kitaip tariant – kas už ką atsakingas. Šioje vietoje dažniausiai yra dvi pusės: IT įmonė ir klientas.
Tai labai svarbu, ypač didesniuose projektuose. Apie tai jau net esame šiek tiek rašę (nuoroda į straipsnį). Abiems pusėms turi būti labai aišku, kas yra atsakingi asmenys tiek IT įmonės, tiek kliento pusėje. Klientas turi aiškiai žinoti, su kuo jis bendraus ir kokiems asmenims galės užduoti klausimus, susijusius, pvz., su pinigais, kam galės užduoti klausimus, susijusius su technine projekto dalimi ir pan. IT įmonė turi aiškiai suprasti, ko reiktų klausti ir iš ko tikėtis atsakymų kliento pusėje.
Projekto sėkmė
„Ką jūs laikysite sėkmingai įgyvendintu projektu?“ Tai turbūt vienas iš esminių klausimų, kurį galite užduoti savo klientui dar prieš pradedant visus darbus. Tai kertinis klausimas, kuris padės suprasti, kaip mąsto klientas. Tai taip pat ir klausimas, kurį turi gerai apgalvoti ir sau atsakyti pats klientas.
Žinoma, agile metodologija sakysite, dirbame sprint’ais, tad spėsime pamatyti eigoje, kad klientas ne taip įsivaizduoja projektą. Taip, jei kliento galvoje sėkmingas projektas yra toks projektas, kuris turi x funkcijas, tada gal ir spėsite. Tačiau jei klientas įsivaizduoja, kad sėkmingas projektas yra projektas, kuris padės jam pritraukti naujų klientų? Gal tokiu atveju pati marketingo dalis yra tiek pat svarbi, kiek ir IT. Gal netgi marketingo dalis yra svarbesnė. Galite sakyti, o prie ko čia IT ir marketingas. Mes kuriame produktą, o kiti jį promotina. Taip, jūs iš principo teisus, bet tikslas juk yra ne būti teisiam, o susikalbėti, kad kartu dirbant pasiektumėte bendrą tikslą. Jei dar prieš projektui startuojant sugebėsite aiškiai su klientu apibrėžti sėkmingo projekto kriterijus, žymiai geriau suprasite, ko klientas tikisi, ir iš savo pusės galėsite pasiūlyti geresnius sprendimus tam tikslui pasiekti. Galu gale, žymiai sumažės tikimybė, kad sukursite tokį produktą, kuris iš techninės pusės kaip ir nepriekaištingas, bet neatlieka savo paskirties. Sutaupysite ne tik piniginių resursų, išvengsite streso ir įtampos.
Esminiai pavojai
Dauguma projektų turi vienokių ar kitokių pavojų. Labai svarbu juos identifikuoti ir padaryti žingsnius, užbėgant jiems už akių. Pvz. matote, kad įmonė, su kuria dirbsite, yra labai didelė. Vienas iš pavojų tokiu atveju gali būti, kad laiku negausite atsakymų į klausimus. Tokiu atveju klientui aiškiai, ne tik žodžiu, bet ir raštu turėtume iškomunikuoti, kad jums labai svarbu laiku gauti informaciją, nes nuo to priklauso projekto eiga ir atliekami darbai. Jei klientas šito nesupras, jo galvoje gali būti vaizdas, kad jūs kažko nepadarote, jis juk gali nesuprasti, kad negalima kurti B funkcijos, prieš tai nesukūrus A funkcijos, o kad sukurtumėte A, jums ir reikalingi atsakymai. Jei aiškiai identifikavę šią riziką iškomunikuosite procesą klientui, žymiai didesnė tikimybė, kad laiku gausite atsakymus ir išvengsite bereikalingo streso ir konfrontacijos su klientu, net jei tų atsakymų negausite. Tiesiog bus žymiai paprasčiau paaiškinti, kodėl procesas sustojo.
Komunikacija
Kiekvieno projekto pasiruošimo stadijoje, pagrindinis komponentas yra komunikacija. Kuo daugiau projekte dalyvaujantys žmonės supras apie tai, kas ir kaip vyks, tuo geriau jie galės susidoroti su sunkumais, kurie iškils. Tai ypatingai svarbu, kai projektą kuria ne vidinė įmonės komanda, o iš šalies samdyta IT įmonė. Ji dažniausiai negali būti įmonės viduje ir matyti visko iš vidaus.
Kalbant apie komunikaciją, labai svarbu susitarti, kokiais kanalais ir kada ji vyks. Tai gali būti paprastas Skype chat, kur abi pusės galės rašyti eigoje iškylančius klausimus, tai gali būti sukurta Microsoft Teams grupė. Visa esmė, kad tai būtų aptarta ir aišku abiems pusėms. Taip pat labai dažnai projektuose neužtenka vien tik tekstinio susirašinėjimo, kartais iškyla tokių klausimų, kuriuos žymiai lengviau ir greičiau aptarti skambučio metu. Labai svarbu dėl to susitarti su klientu. Informuoti, kad toks poreikis gali būti, o dar geriau iš anksto suderinti laiką, pvz. vieną sykį per savaitę, kada su klientu susiskambinsite ir kalbėsite gyvai.
Laikas, reikalingas pasiruošimo darbams
Projektą reikėjo sukurti VAKAR. Tikriausiai pažįstama situacija. Arba projektas turi būti paruoštas masiniam naudojimui už 3 mėn. Šis noras yra suprantamas: greičiau paleisime projektą, anksčiau pradėsime uždirbti pinigų, aplenksime konkurentus, kol jie dar nepaleido panašaus projekto ir pan. Tačiau, kiek teko pastebėti, dažnai šis noras prasilenkia su realybe. Nėra net vizualizacijų, ką statysime, turime tik viziją, kurią dar reikia paversti raidėmis, skaičiais, paveikslėliais. Iš mūsų praktikos, pasiruošimo darbai yra tiesiogiai proporcingi projekto dydžiui ir įmonės, su kuria bus dirbama, dydžiui. Dažnai jie užima 30–50 % laiko, skirto visam projektui. Pvz., jei tai 6 mėn. projektas, pasiruošimas realiems darbams gali trukti 2–3 mėn. Gali pasirodyti labai daug, bet nepamirškime, kad dažnai daug niuansų viduje turi išsispręsti pats klientas. Taip pat yra žymiai geriau skirti 2–3 mėn. pasiruošimui, nei 6 mėn. projektą kurti 12 ar daugiau mėnesių, o blogiausiu atveju ir išvis neužbaigti, nes nuo pat pradžių buvo neteisingai sustatytas procesas. Sėkmingas projektas – tai kruopštaus planavimo pasekmė.
Ar gali didelis ir sudėtingas projektas startuoti greit? Gali, jei bus išpildyta viena sąlyga – klientas bus kruopščiai atlikęs namų darbus iš savo pusės. Deja, taip būna retai.
Yra ir kitas būdas – startuoti greit ir neišdiskutavus visų klausimų, tačiau tokiu atveju reikia būti nusiteikus, kad gali kilti situacijų, kuriose kažkas turės už tai sumokėti. Gal tai bus IT įmonė, kuriai reikės perrašyti dalį kuriamo projekto funkcionalumo, nes jis ne taip veikia, gal tai bus klientas, kuriam teks už tai sumokėti. Galbūt net ir ne vieną kartą.
Apibendrinimas
Apie kiekvieną iš aukščiau išvardintų punktų būtų galima parašyti po atskirą ilgą straipsnį. Smulkiai aprašyti, kokias priemones naudoti komunikacijai, kaip identifikuoti pavojus ir t. t. Tačiau šio straipsnio tikslas yra ne apkrauti technine informacija, o priversti susimąstyti ir labai grubiai apžvelgti kertinius momentus, kuriuos laikydami galvoje galėsite išvengti daugybės nemalonių situacijų savo projekte.
Sėkmingo pasiruošimo ir gerų projektų!
———
Jums taip pat gali būti įdomu paskaityti: