Jei reikėtų įvardinti vieną šiuolaikinio verslo burtažodį, tai, turbūt, būtų „lankstumas“. Jį prisijaukinti mokosi ir didelės tarptautinės organizacijos, kurių struktūra ir darbo principai iš pirmo žvilgsnio gali atrodyti intertiški. Kai kurios jų viduje kuria startuolių principu veikiančias komandas, kurioms suteikia daugiau veikimo laisvės ir galimybių eksperimentuoti. Kita vertus, šios komandos gali naudotis kompanijos žiniomis ir finansiniais ištekliais, kurių patys startuoliai neretai stokoja.
„NorthStar“ – toks pavyzdys, veikiantis „Danske Bank“ viduje. Su komanda per pusmetį sukūrėme automobilių lizingo sprendimą, leidžiantį automobilį įsigyti per mažiau nei 2 minutes, šiandien sėkmingai naudojamą Švedijoje ir netrukus startuosiantį Danijoje bei Norvegijoje.
Tarptautinėje komandoje kurtas projektas ne tik suteikė vertingos patirties, bet ir leido geriau suprasti, kokie principai kuriant produktą ar paslaugą pasiteisina praktikoje, o ko geriau atsisakyti. Per 6 mėnesius paaiškėjo sena tiesa – kad geriausiai mokomės iš klaidų. Svarbiausia – laiku jas atrasti.
Pirmoji pamoka: pradėkite kuo anksčiau
Kiekvieno produkto vystymą sudaro daugybė etapų. Patirtis rodo, kad testavimą būtina pradėti vos žengus pirmuosius žingsnius. Ankstyvas testavimas padeda išvengti vadinamojo „drugelio efekto“ – pirminiame etape pastebėtam netikslumui išspręsti užtenka vos penkių minučių ir, atvirkščiai, jei sistema jau veikia, tai gali pareikalauti ir kelių dienų ar net savaičių. Juolab, kad niekas jau neatsimins tikslių vieno ar kito sprendimo kūrimo aplinkybių.
Be testavimo neapsieina nė vienas šiuolaikinių technologijų sprendimas, todėl jo nesiėmus projekto pradžioje, teks imtis paskutinę dieną. O, kaip žinia, paskutinę dieną prieš produkto paleidimą ir taip bus ką veikti.
Tikrinant paskutinę minutę reikia ne tik daugiau žmogiškųjų ir technologinių išteklių, išauga ir klaidų, vėlavimo tikimybė. Tiek projekto pradžioje, tiek pabaigoje testuojami net patys smulkiausi procesai – tai daryti kur kas efektyviau kiekviename produkto ar paslaugos vystymo etape.
Antroji pamoka: žvilgtelėkite, kaip problemas sprendžia pasaulio lyderiai
Ėmę vystyti „NorthStar“ produktą, turėjome įtemptą pusės metų grafiką ir iš pradžių „pražiopsojome“ kelis dalykus, į kuriuos turėjome pirmiausia atkreipti dėmesį. Kartais testavimą sąmoningai palikdavome vėlesniam laikui. Paaiškėjus, kad daugybė smulkmenų neveikia, teko dirbti viršvalandžius. Prariję karčią piliulę, ėmėme dairytis, ko gali pamokyti pasaulinių kompanijų patirtis. Naudodamiesi gerąja „Facebook“ ir „Google“ praktika, naujuose projektuose automatinius testavimus diegiame jau pirminiuose produkto kūrimo etapuose.
Kita „Google“ ir „Facebook“ pamoka, atrodytų, net prieštarauja situacijai rinkoje – šios ir kitos technologijų milžinės tiesiog neturi atskiros testuotojo rolės. Jos vadovaujasi principu, kad kiekvienas komandos narys yra atsakingas už nepriekaištingą produkto kokybę. Taip atsakomybė už patikrą išlieka, tačiau ji proporcingai paskirstoma visiems komandos nariams – nuo programuotojo iki pardavimų specialisto.
Beje, semiantis patirties, neužtenka žvalgytis į pasaulio technologijų milžinus. Reikia domėtis ir pažangiausiais, nuolat tobulėjančiais testavimo įrankiais. Kai kurie iš jų padeda užbėgti problemoms už akių ir rasti sprendimą dar iki joms iškylant.
Trečioji pamoka: kuo daugiau įvairovės – tuo stipresnis produktas
Testavimas kuriant pažangius sprendimus neišvengiamas, tačiau atskira tuo užsiimanti testuotojų komanda nebūtina. Mano įsitikinimu, dirbant „Agile“ principu, nedidelėje komandoje tik užtestavimą atsakingi specialistai gali įnešti daugiau sumaišties negu naudos. Kai kiekvienas komandos narys įsitraukia į visus procesus, reikia kur kas mažiau derinimų, mažiau laiko sugaištama diskusijoms. Papildoma grandis gali išbalansuoti šią struktūrą, o ir pats testuotojas gali jaustis ne savo rogėse.
Jei programinės įrangos kūrėjai niurzga, kad testavimas yra nemaloni procedūra, reikia siųsti žinutę, jog tai galimybė tobulėti, įvertinti savo įgūdžius ir mokytis iš klaidų. Be to, kai į patikros procesą įsitraukia kiekvienas komandos narys, susidaro kur kas palankesnės sąlygos sukurti geresnį, labiau vartotojų poreikius atliepiantį produktą ar paslaugą. Komandai apie tai reikia kalbėti ne būtinybės, o galimybių terminais.
Taip pat svarbu – kad produkto bandymo procese dalyvautų ir už verslo procesus atsakingi žmonės, mat įvairovės kriterijus galioja kalbant tiek apie profesinę kompetenciją, tiek apie asmenines savybes. Tai padeda vystant produktą – kas pro akis prasprūsta vienam, neliks nepastebėta kitų. Dar geriau, jei sudaromos galimybės kompetencijomis dalintis su tarptautine komanda.
Kurdami automobilių lizingo sprendimą, nuotoliniu būdu dirbome su Skandinavijos šalimis, tad teko ne tik prisiminti anglų kalbos žinias, bet ir pasitelkti vaizdo konferencijas, o rytus pradėti nuo apžvalginio susirinkimo...ant sofos. Jo metu telekonferencijos būdu visi apžvelgdavome produkto vystymo būseną, kilusius iššūkius ir artimiausias užduotis.
Ketvirtoji pamoka: įvertinkite produkto pristatymo laiką
Dažna situacija – besibaigiant darbo savaitei pas programuotojus ateina žmogus iš verslo ar pardavimų skyriaus ir ragina leisti produktą šeštadienį. Jis įsitikinęs, kad savaitgalį sprendimas bus naudojamas mažiau, tad be didelių dramų galima patogiai išspręsti iškilusius nesklandumus.
Nurodymus vykdėme tik pirmą kartą – paleidus bet kokį produktą, programuotojai turi būti budrūs ir pasiruošę iškart spręsti kilusią problemą. Todėl laisvadieniai tam tinkami mažiausiai.
Programinio sprendimo paleidimas nėra lyg šviesos jungiklio spustelėjimas: vos produktas pradeda veikti, programuotojai turi stebėti pirmuosius jo žingsnius, rinkti grįžtamąjį ryšį ir nedelsiant taisyti pastebėtas klaidas. Dirbdami išmokome pamoką, todėl savo produktus įprastai leidžiame savaitės pradžioje. Tuomet turime visą savaitę stebėti, kaip jam sekasi ir tuo pat metu reaguoti į iškilusias problemas neaukodami laisvadienių.
Penktoji pamoka: pasitikėkite automatiniais sprendimais, tačiau ne aklai
Net ir už paties pažangiausių dirbtinio intelekto ar informacinių technologijų sprendimų vis dar slepiasi žmogus ir jo gebėjimai. Nors didžioji testavimo dalis jau automatizuota (štai „Google“ automatizuota net 95 proc. kodo testavimų), paskutinį sprendimą priima programuotojas arba testuotojas. Išlaikyti ryšį su tikrove būtina, ypač, kai vartotojų lūkesčiai paslaugoms ir jų teikėjams auga, įmonės siekia suteikti kuo geresnę patirtį savo klientams.
Kuriant sudėtingas daugiapakopes sistemas nesėkmės neišvengiamos, tačiau svarbu, kad ir jos duotų pridėtinę vertę. Suklysti pirmą kartą nėra nuosprendis – tai reikėtų vertinti kaip pamoką, tam tikrą „reality check“. Tik nuo jos supratimo priklauso, ar analogiškos klaidos bus išvengta ateityje ir, galų gale, kiek sėkmingas bus jūsų sukurtas produktas.
„NorthStar“ – toks pavyzdys, veikiantis „Danske Bank“ viduje. Su komanda per pusmetį sukūrėme automobilių lizingo sprendimą, leidžiantį automobilį įsigyti per mažiau nei 2 minutes, šiandien sėkmingai naudojamą Švedijoje ir netrukus startuosiantį Danijoje bei Norvegijoje.
Tarptautinėje komandoje kurtas projektas ne tik suteikė vertingos patirties, bet ir leido geriau suprasti, kokie principai kuriant produktą ar paslaugą pasiteisina praktikoje, o ko geriau atsisakyti. Per 6 mėnesius paaiškėjo sena tiesa – kad geriausiai mokomės iš klaidų. Svarbiausia – laiku jas atrasti.
Pirmoji pamoka: pradėkite kuo anksčiau
Kiekvieno produkto vystymą sudaro daugybė etapų. Patirtis rodo, kad testavimą būtina pradėti vos žengus pirmuosius žingsnius. Ankstyvas testavimas padeda išvengti vadinamojo „drugelio efekto“ – pirminiame etape pastebėtam netikslumui išspręsti užtenka vos penkių minučių ir, atvirkščiai, jei sistema jau veikia, tai gali pareikalauti ir kelių dienų ar net savaičių. Juolab, kad niekas jau neatsimins tikslių vieno ar kito sprendimo kūrimo aplinkybių.
Be testavimo neapsieina nė vienas šiuolaikinių technologijų sprendimas, todėl jo nesiėmus projekto pradžioje, teks imtis paskutinę dieną. O, kaip žinia, paskutinę dieną prieš produkto paleidimą ir taip bus ką veikti.
Tikrinant paskutinę minutę reikia ne tik daugiau žmogiškųjų ir technologinių išteklių, išauga ir klaidų, vėlavimo tikimybė. Tiek projekto pradžioje, tiek pabaigoje testuojami net patys smulkiausi procesai – tai daryti kur kas efektyviau kiekviename produkto ar paslaugos vystymo etape.
Antroji pamoka: žvilgtelėkite, kaip problemas sprendžia pasaulio lyderiai
Ėmę vystyti „NorthStar“ produktą, turėjome įtemptą pusės metų grafiką ir iš pradžių „pražiopsojome“ kelis dalykus, į kuriuos turėjome pirmiausia atkreipti dėmesį. Kartais testavimą sąmoningai palikdavome vėlesniam laikui. Paaiškėjus, kad daugybė smulkmenų neveikia, teko dirbti viršvalandžius. Prariję karčią piliulę, ėmėme dairytis, ko gali pamokyti pasaulinių kompanijų patirtis. Naudodamiesi gerąja „Facebook“ ir „Google“ praktika, naujuose projektuose automatinius testavimus diegiame jau pirminiuose produkto kūrimo etapuose.
Kita „Google“ ir „Facebook“ pamoka, atrodytų, net prieštarauja situacijai rinkoje – šios ir kitos technologijų milžinės tiesiog neturi atskiros testuotojo rolės. Jos vadovaujasi principu, kad kiekvienas komandos narys yra atsakingas už nepriekaištingą produkto kokybę. Taip atsakomybė už patikrą išlieka, tačiau ji proporcingai paskirstoma visiems komandos nariams – nuo programuotojo iki pardavimų specialisto.
Beje, semiantis patirties, neužtenka žvalgytis į pasaulio technologijų milžinus. Reikia domėtis ir pažangiausiais, nuolat tobulėjančiais testavimo įrankiais. Kai kurie iš jų padeda užbėgti problemoms už akių ir rasti sprendimą dar iki joms iškylant.
Trečioji pamoka: kuo daugiau įvairovės – tuo stipresnis produktas
Testavimas kuriant pažangius sprendimus neišvengiamas, tačiau atskira tuo užsiimanti testuotojų komanda nebūtina. Mano įsitikinimu, dirbant „Agile“ principu, nedidelėje komandoje tik užtestavimą atsakingi specialistai gali įnešti daugiau sumaišties negu naudos. Kai kiekvienas komandos narys įsitraukia į visus procesus, reikia kur kas mažiau derinimų, mažiau laiko sugaištama diskusijoms. Papildoma grandis gali išbalansuoti šią struktūrą, o ir pats testuotojas gali jaustis ne savo rogėse.
Jei programinės įrangos kūrėjai niurzga, kad testavimas yra nemaloni procedūra, reikia siųsti žinutę, jog tai galimybė tobulėti, įvertinti savo įgūdžius ir mokytis iš klaidų. Be to, kai į patikros procesą įsitraukia kiekvienas komandos narys, susidaro kur kas palankesnės sąlygos sukurti geresnį, labiau vartotojų poreikius atliepiantį produktą ar paslaugą. Komandai apie tai reikia kalbėti ne būtinybės, o galimybių terminais.
Taip pat svarbu – kad produkto bandymo procese dalyvautų ir už verslo procesus atsakingi žmonės, mat įvairovės kriterijus galioja kalbant tiek apie profesinę kompetenciją, tiek apie asmenines savybes. Tai padeda vystant produktą – kas pro akis prasprūsta vienam, neliks nepastebėta kitų. Dar geriau, jei sudaromos galimybės kompetencijomis dalintis su tarptautine komanda.
Kurdami automobilių lizingo sprendimą, nuotoliniu būdu dirbome su Skandinavijos šalimis, tad teko ne tik prisiminti anglų kalbos žinias, bet ir pasitelkti vaizdo konferencijas, o rytus pradėti nuo apžvalginio susirinkimo...ant sofos. Jo metu telekonferencijos būdu visi apžvelgdavome produkto vystymo būseną, kilusius iššūkius ir artimiausias užduotis.
Ketvirtoji pamoka: įvertinkite produkto pristatymo laiką
Dažna situacija – besibaigiant darbo savaitei pas programuotojus ateina žmogus iš verslo ar pardavimų skyriaus ir ragina leisti produktą šeštadienį. Jis įsitikinęs, kad savaitgalį sprendimas bus naudojamas mažiau, tad be didelių dramų galima patogiai išspręsti iškilusius nesklandumus.
Nurodymus vykdėme tik pirmą kartą – paleidus bet kokį produktą, programuotojai turi būti budrūs ir pasiruošę iškart spręsti kilusią problemą. Todėl laisvadieniai tam tinkami mažiausiai.
Programinio sprendimo paleidimas nėra lyg šviesos jungiklio spustelėjimas: vos produktas pradeda veikti, programuotojai turi stebėti pirmuosius jo žingsnius, rinkti grįžtamąjį ryšį ir nedelsiant taisyti pastebėtas klaidas. Dirbdami išmokome pamoką, todėl savo produktus įprastai leidžiame savaitės pradžioje. Tuomet turime visą savaitę stebėti, kaip jam sekasi ir tuo pat metu reaguoti į iškilusias problemas neaukodami laisvadienių.
Penktoji pamoka: pasitikėkite automatiniais sprendimais, tačiau ne aklai
Net ir už paties pažangiausių dirbtinio intelekto ar informacinių technologijų sprendimų vis dar slepiasi žmogus ir jo gebėjimai. Nors didžioji testavimo dalis jau automatizuota (štai „Google“ automatizuota net 95 proc. kodo testavimų), paskutinį sprendimą priima programuotojas arba testuotojas. Išlaikyti ryšį su tikrove būtina, ypač, kai vartotojų lūkesčiai paslaugoms ir jų teikėjams auga, įmonės siekia suteikti kuo geresnę patirtį savo klientams.
Kuriant sudėtingas daugiapakopes sistemas nesėkmės neišvengiamos, tačiau svarbu, kad ir jos duotų pridėtinę vertę. Suklysti pirmą kartą nėra nuosprendis – tai reikėtų vertinti kaip pamoką, tam tikrą „reality check“. Tik nuo jos supratimo priklauso, ar analogiškos klaidos bus išvengta ateityje ir, galų gale, kiek sėkmingas bus jūsų sukurtas produktas.
