Evaldas Urbonas, naujienlaiškių, SMS žinučių ir kitų rinkodaros priemonių automatizavimo platformą vystančios bendrovės „Omnisend“ Produkto direktorius dalinasi patirtimi, kaip sukurti ir vystyti sėkmingą produkto organizaciją.

„IT sektoriuje galima išskirti du organizacijų tipus: produktų ir paslaugų. Bet mano nuomone ir pastarosios kuria produktus. Tik ne visos įmonės gali būti vadinamos produkto organizacijomis. Dalis jų tiesiog pagamina (suprogramuoja) produktą, bet po to jo neprižiūri“, – aiškina pašnekovas.

Kaip pavyzdį jis pateikia įmones, vykdančias viešojo sektoriaus užsakymus. Jos laimi pirkimą ir atlieka užsakomąjį darbą. Kitaip sakant, valstybei parduoda savo darbo valandas. Bet to rezultatas irgi yra produktas – sistema, platforma ar nauja funkcija.

Dirba konvejerio principu

Esminis skirtumas tarp produkto organizacijos ir produktą gaminančios organizacijos yra tai, kaip produktas kuriamas, ir kaip matuojama pažanga.

Darbo valandas parduodančiose įmonėse programuotojas paprastai gauną darbą, jį atlieka ir eina prie kito. Tas pats ir visos organizacijos mastu – atlikusi užsakymą, įmonė fokusuojasi į kitą projektą. Tikslas – padaryti viską kuo pigiau, kuo greičiau ir kad rezultatas atitiktų perkančiosios organizacijos reikalavimus. Kūrėjai dažniausiai nemato, kaip tos sistemos paskui yra naudojamos ir nežino jų silpnųjų vietų, negali jų patobulinti.

Palyginti, produkto organizacijose darbai yra atliekami, perduodami klientams, o įmonė analizuoja, kaip pastarieji naują sprendimą naudoja. Jei norimas rezultatas nepasiekiamas, klientui sukurtas sprendimas yra tobulinamas ir ratas sukamas iš naujo.

„Iš esmės produkto organizacija yra ta, kuri kuria nuosavą produktą ir yra išlaikoma jo naudotojų“, – apibendrina E. Urbonas ir priduria, kad didžioji dalis organizacijų, kai jau uždirba šiek tiek pinigų iš paslaugų, dažniausiai nori imtis kurti nuosavą produktą.

Būtent šiame etape šiandien yra nemaža dalis Lietuvos IT įmonių. Visgi, persiorientuoti ir tapti produkto organizacija nėra lengva. Sėkmės atvejų kol kas tėra vienetai.

Anot jo, problema tampa net tai, kaip formuojamos komandos. E. Urbonas aiškina, kad paslaugų organizacijos dažnai veikia kaip konvejeriai. Analitikai, atlikę savo darbo dalį, perduoda projektą dizaineriams ir eina prie kito projekto. Tą patį padaro dizainerių komanda, programuotojų komanda ir t.t.

Evaldas Urbonas

Tuo metu produkto organizacijų komandas dažnai sudaro visų reikiamų kvalifikacijų specialistai – dizaineriai, analitikai, programuotojai, testuotojai, produktų bei kt. sričių žinovai. Ir kiekviena komanda atsakinga yra už tam tikrą produkto dalį. Pašnekovas pabrėžia, kad tokiu būdu paprastai veikia įmonės, taikančios įgalintų komandų modelį. Tiesa, toli gražu ne visos produkto organizacijos jį taiko.

Įgalintos komandos

Komandų įgalinimas tai pasitikėjimu grįstas vadybos būdas, kai specialistų komandai pačiai paliekama spręsti, kaip kurti vertę klientui ir pasiekti organizacijos iškeltus tikslus.
Pasak E. Urbono, tai vienas iš būdų formuoti produkto organizaciją arba tokia paversti jau veikiančią įmonę.

„Verslas visame pasaulyje šiandien, regis, išgyvena įgalintų komandų bumą. Visgi, įmonių su tikrai įgalintomis ir gerai veikiančiomis komandomis yra nedaug, nes transformuotis ir pereiti nuo konvejerinio tipo gamybos prie įgalintų komandų yra sunku“, – sako ekspertas, ir pabrėžia, kad egzistuoja ir neįgalintos produkto organizacijos.

Pasak jo, mažoms įmonėms bene lengviausia dirbti pagal įgalintos produkto organizacijos modelį, nes visa įmonė dažnu atveju yra viena komanda. Tad sprendimai diskutuojami ir derinami dalyvaujant visiems. Pirmas didelis iššūkis yra pereiti nuo vienos komandos iki dvejų. Antras – užtikrinti tinkamą informacijos sklaidą ir susikalbėjimą, kai komandų įmonėje pasidaro keliolika.

„Kai įmonė auga ir suformuojama antra komanda, iš esmės atsiveria du keliai ir iškyla pasirinkimas. Pirmas kelias – produktų vadovai toliau diriguoja IT orkestrui ir sako, kokias funkcijas kurti. Antras – įmonė komandas įgalina, kaip padarė „Omnisend“, – sako įmonės Produkto direktorius.

Nuo ko pradėti keistis?

Pokyčių sėkmė, anot jo, labai priklauso nuo žmonių ir jų mąstysenos. Esą projektų vadovai žiūri į kalendorių ir planą, o produktų vadovai – į klientą ir verslo rezultatą.

Projektinės arba konvejerinės IT organizacijos transformaciją į produkto kompaniją jis siūlo pradėti suformuojant įmonėje nedidelę, 5–7 žmonių, komandą, sudarytą iš produkto vadovo ir dizainerio, inžinierių (programuotojų, testuotojų) ir klientų aptarnavimo specialisto.

Asociatyvi nuotrauka

Pašnekovas per dešimtmetį sukaupta patirtimi neseniai dalijosi nuotoliniame produktų vadovų ir specialistų bendruomenės renginyje „Mapping product development“.
Jis pasakojo apie startuolio, kuris vystė rezervacijų sistemą grožio paslaugų įstaigoms, transformaciją.

„Ankstyvajame etape mes daugiausia kliaudavomės nuojauta, sprendimams priimti beveik nenaudodavome duomenų ir nė kiek neeksperimentuodavome. O pažangą vertinome pagal tai, kiek planuotų funkcijų sukūrėme ir paleidome, kiek aktyvių vartotojų ir rezervacijų turėjome“, – prisimena pašnekovas.

Minėtieji rodikliai augo, tačiau įmonė greitai pastebėjo, kad kartu sparčiai daugėja ir neatliktų darbų, o klientai neretai skundžiasi, kad vizitai pas tą patį grožio specialistą rezervuojami iškart keliems skirtingiems klientams. Netrukus paaiškėjo, kad pažangai matuoti pasirinkti netinkami kriterijai, kurių akcentavimas sudarė klaidingą progreso įspūdį.

Svarbu ne kiek, o ką padarai

„Tai supratę, ėmėme siekti, kad komandos taptų atsakingos už savo produkto dalis ir sėkmę imtų matuoti pagal klientui suteiktą vertę (ji, savo ruožtu, matuojama pagal tai, kaip ir kiek klientas naudojasi produktu) ir verslo rezultatą, o ne sukurtų funkcijų ar atliktų darbų kiekį“, – pasakoja E. Urbonas.

Pokyčiai atnešė ir kitų naudingų rezultatų. Visi įmonėje tiksliai žinojo, kas atsakingas už konkrečią produkto dalį ar funkciją. Be to, tapo lengviau planuoti, nes visos komandos prioritetus pradėjo nustatinėti tik savo srityje. Susiaurėjus atsakomybių sričiai, inžinieriai ir produkto specialistai turėjo galimybę geriau įsigilinti ir labiau suprasti savo sritis.

„Omnisend“ Produkto direktorius išskyrė svarbiausius veiksnius, būtinus, kad įgalintų komandų modelis veiktų. Jo teigimu, tai yra vadovų pasitikėjimas komanda klientų problemų identifikavimas ir supratimas, duomenimis grįsti sprendimai, aiškus kiekvienos komandos tikslas ir nepriklausomybė nuo kitų komandų.

„Viskas prasideda nuo vadovų, jie turi atitinkamai mąstyti ir planuoti. Reikia nuosekliau priimti duomenimis grįstus sprendimus, ir parinkti tinkamus sėkmės matavimo kriterijus. Reikia leisti žmonėms rizikuoti, veikti be baimės. Vadovai turi pasitikėti komanda, nurodyti jai aiškų kursą ir užtikrinti stabilumą, o ne nurodyti kokias funkcijas kurti. Taip pat labai svarbu, kad tas kursas būtų parenkamas pagal kliento problemas, kurias galite išspręsti“, – teigia E. Urbonas.

Programuotojas

Atsisakė plėtros kalendorinių planų

Jis priduria, kad reikėjo atsisakyti kas ketvirtį sudarinėtų verslo plėtros kalendorinių planų (angl. roadmap), kuriuose įmonė numatydavo, kokias funkcijas ketina sukurti.

„Daugelis yra pratę prie planų, ir aiškiai laike išdėliotų darbo etapų. Tačiau neretai būna sunku numatyti, kiek užtruks išspręsti vieną ar kitą kliento problemą. Ypač, kai matuojami tikslai, susiję su klientų elgsena. Todėl nustojome sudarinėti produkto funkcijų kūrimo kalendorinius planus su datomis. Ne visiems tai buvo patogu. Rinkodaros ir pardavimų komandos prarado įprastus savo įrankius. Tačiau, pradėjus dažniau komunikuoti apie darbų eigą, problema išsisprendė“, – pasakoja E. Urbonas.

Taip pat būtina užtikrinti, kad komandos bendradarbiaus ir susikalbės.
E. Urbonas pabrėžia, kad produkto organizacijai labai naudingas dalykas yra tikslų nustatymo metodika OKR (angl. Objectives and Key Results). Svarbu tik tinkamai pasirinkti esminių siektinų rezultatų matavimo detalumą: jei norimas rezultatas apibūdinamas per siaurai, komandai iš esmės pasakoma, ką daryti, o produkto organizacijose to reikėtų vengti.

Kita vertus, jei rezultatas apibūdinamas per plačiai, komanda gali nebūti pajėgi efektyviai išsigryninti ir susiaurinti kryptį, kuri turės didžiausią įtaką rezultatui.

Bendrai kalbant, pereiti prie produkto organizacijos modelio nėra lengva, ypač didesnėms įmonėms. Bet tai nėra neįmanoma. Gali tekti paeksperimentuoti, kai ko atsisakyti ir pakeisti vadybos įpročius. Visgi, šį modelį taikančios įmonės vienbalsiai sako: verta. O jų rezultatai tai patvirtina.

Gintautas Degutis yra reputacijos agentūros „Winning“ projektų vadovas.