Філасофіяй DevOps, калі распрацоўка злучаецца з абслугоўваннем ПЗ, ужо нікога не здзівіш. Набірае сілу новы трэнд - DevOps 2.0 або BizDevOps. У ім у адзінае цэлае зліваюцца ўжо тры кампаненты: бізнэс, распрацоўка і падтрымка. І як у DevOps'e інжынерныя практыкі кладуцца ў аснову сувязі распрацоўкі і падтрымкі, так і ў биздевопсе аналітыка бярэ на сябе роля "клею", які аб'ядноўвае распрацоўку з бізнэсам.
Жадаю адразу прызнацца: аб тым, што ў нас атрымаўся самы сапраўдны биздевопс, мы пазналі толькі цяпер, пачытаўшы разумныя кнігі. Яно неяк само склалася дзякуючы ініцыятыве супрацоўнікаў і несуцішнай страсці да паляпшэнняў. Цяпер аналітыка – гэта частка вытворчага працэсу распрацоўкі, якая значна скарачае завесы зваротнай сувязі і рэгулярна забяспечвае інсайтамі. Раскажу падрабязна, як у нас усё ўладкована.
Недахопы класічнага DevOps
Калі задумваюцца новыя кліенцкія прадукты, бізнэс стварае ідэальную мадэль паводзінаў кліентаў і разлічвае на добрую канверсію, на базе чаго будуе свае бізнес-мэты і вынікі. Каманда распрацоўшчыкаў са свайго боку імкнецца зрабіць вельмі добры, якасны код. Падтрымка ж спадзяецца на поўную аўтаматызацыю працэсаў, на лёгкасць і зручнасць суправаджэння новага прадукта.
Рэальнасць часцей за ўсё складаецца такім чынам, што кліенты атрымліваюць даволі складаны працэс, бізнэс упіраецца ў нізкую канверсію, каманды распрацоўкі выпускаюць фікс за фіксам, а падтрымка тоне ў струмені зваротаў ад кліентаў. Знаёма?
Корань зла тут крыецца ў доўгай і няякаснай пятлі зваротнай сувязі, закладзенай у працэс. Бізнэс і распрацоўнікі пры зборы патрабаванняў і атрыманні зваротнай сувязі падчас спрынтаў маюць зносіны з абмежаванай колькасцю кліентаў, якія моцна ўплываюць на лёс прадукта. Часта тое, што важна для аднаго, зусім не характэрна для ўсёй мэтавай аўдыторыі.
Разуменне таго, ці ў правільным кірунку ідзе развіццё прадукта, прыходзіць разам з фінансавымі справаздачамі і вынікамі маркетынгавых даследаванняў праз месяцы пасля запуску. Ды і яны з-за абмежаванасці выбаркі не даюць магчымасці праверкі гіпотэз на вялікім аб'ёме кліентаў. Увогуле, атрымліваецца доўга, недакладна і неэфектыўна.
Трафейны інструмент
Мы знайшлі добры спосаб адысці ад гэтага. Інструмент, які раней дапамагаў толькі маркетолагам, у нас патрапіў у рукі бізнэсу і распрацоўнікам. Мы пачалі актыўна выкарыстоўваць web-аналітыку для таго, каб глядзець на працэс у рэальным часе, тут і зараз разумець, што адбываецца. На аснове гэтага планаваць сам прадукт, яго раскочванне на вялікі аб'ём кліентаў.
Калі плануецца нейкае паляпшэнне прадукта, можна адразу паглядзець, з якімі метрыкамі яно злучана, і як гэтыя метрыкі ўплываюць на продажы, на важныя для бізнэсу характарыстыкі. Так можна адразу адсеяць гіпотэзы з нізкім эфектам. Ці, напрыклад, выкаціць новую фічу на статыстычна значную колькасць карыстачоў і ў рэжыме рэальнага часу пасачыць за метрыкамі, зразумець, ці ўсё працуе, як задумвалася. Не чакаць зваротнай сувязі ў выглядзе зваротаў ці справаздач, а тут жа самім адсочваць і аператыўна карэктаваць працэс стварэння прадукта. Мы можам выкаціць новую фічу, праз тры дні ўжо сабраць статыстычна дакладныя дадзеныя, зрабіць змены яшчэ за тры дні - і вось за тыдзень гатовы выдатны новы прадукт.
Можна адсачыць усю варонку, усіх кліентаў, якія ўвайшлі ў кантакт з новым прадуктам, выявіць кропкі, у якіх варонка рэзка звужалася, і разабрацца ў прычынах. І распрацоўшчыкі, і бізнэс зараз сочаць за гэтым, гэта частка штодзённай працы. Яны бачаць адзін і той жа кліенцкі шлях, і разам могуць генераваць ідэі і гіпотэзы па паляпшэнні.
Такая інтэграцыя бізнесу і распрацоўкі разам з аналітыкай дае магчымасць ствараць прадукты бесперапынна, якія пастаянна аптымізаваць, шукаць і бачыць вузкія месцы, увесь працэс у цэлым.
Уся справа ў складанасці
Калі мы ствараем новы прадукт, то пачынаем не з чыстага ліста, а ўбудоўваем яго ва ўжо існуючае хітраспляценне сэрвісаў. Прымяраючыся да новага прадукта, кліент часцей за ўсё кантактуе з некалькімі падраздзяленнямі. Ён можа пагутарыць з супрацоўнікамі кантакт-цэнтра, з мэнэджэрамі ў офісе, можа звярнуцца ў падтрымку, у анлайн-чаты. З дапамогай метрык мы можам убачыць, напрыклад, якая нагрузка на кантакт-цэнтры, як лепш апрацоўваць уваходныя запыты. Мы можам зразумець, колькі людзей даходзіць да офіса, і падказаць, як далей кансультаваць кліента.
З інфармацыйнымі сістэмамі ўсё сапраўды гэтак жа. Наш банк існуе ўжо больш за 20 гадоў, за гэты час створаны і да гэтага часу функцыянуе вялікі пласт разнастайных сістэм. Узаемадзеянне паміж бэкэнд-сістэмамі бывае часам непрадказальным. Напрыклад, у нейкай старажытнай сістэме па вызначаным полі ёсць абмежаванні па колькасці знакаў, і часам гэта фарбуе новы сэрвіс. Адсачыць баг стандартнымі спосабамі даволі цяжка, а з дапамогай web-аналітыкі - элементарна.
У нас дайшло да таго, што мы сталі з усіх задзейнічаных сістэм забіраць і аналізаваць тэксты памылак, якія паказваюцца кліенту. Аказалася, што многія з іх састарэлі, а мы нават уявіць сабе не маглі, што яны неяк удзельнічаюць у нашым працэсе.
Праца з аналітыкай
У нас web-аналітыкі і SCRUM-каманды распрацоўшчыкаў знаходзяцца ў адным памяшканні. Яны ўвесь час узаемадзейнічаюць адзін з адным. Калі трэба, спецыялісты дапамагаюць наладзіць метрыкі або выгрузіць даныя, у асноўным самі члены каманд працуюць з сэрвісам аналітыкі, там нічога складанага.
Дапамога патрабуецца, калі, да прыкладу, патрэбны нейкія залежнасці, дадатковыя фільтры па абмежаваным тыпе кліентаў або крыніц. Але ў бягучай архітэктуры мы рэдка з гэтым сутыкаемся.
Цікава, што ўкараненне аналітыкі не запатрабавала ўстаноўкі новай IT-сістэмы. Мы выкарыстоўваем тое ж самае ПЗ, з якім раней працавалі маркетолагі. Трэба было толькі ўзгадніць яго выкарыстанне і ўкараніць яго ў бізнэсе і распрацоўцы. Вядома, мы не маглі проста ўзяць тое, што ёсць у маркетынгу, прыйшлося ўсё пераналадзіць нанова і ўжо маркетынгу даць доступ у новае асяроддзе, каб яны былі з намі ў адным інфармацыйным полі.
У будучыні мы плануем купіць палепшаную версію ПЗ для вэб-аналітыкі, якое дазволіць спраўляцца з нарастальнымі аб'ёмамі апрацоўваных сесій.
Таксама ў нас актыўна ідзе працэс інтэграцыі web-аналітыкі і ўнутраных баз даных з CRM, уліковых сістэм. Аб'яднаўшы дадзеныя, мы атрымліваем поўнае ўяўленне аб кліенце ва ўсіх патрэбных разрэзах: па крыніцах, тыпах кліентаў, прадуктам. BI-сэрвісы, якія дапамагаюць візуалізаваць дадзеныя, хутка стануць даступныя ўсім падраздзяленням.
Што ў нас у выніку атрымалася? Фактычна мы зрабілі аналітыку і прыняцце рашэнняў па ёй часткай вытворчага працэсу, што і дало бачны эфект.
Аналітыка: не наступайце на граблі
Ну і напрыканцы жадаю падзяліцца парадамі, якія дапамогуць вам пазбегнуць набіванні гузоў падчас выбудоўванні биздевопса.
- Калі аналітыку не атрымоўваецца зрабіць хутка, значыць, вы робіце не тую аналітыку. Трэба ісці па простым шляху ад аднаго прадукта, а далей маштабаваць.
- У вас абавязкова павінна быць каманда ці чалавек, які добра разумее будучую архітэктуру аналітыкі. Трэба яшчэ на беразе вызначыцца, як вы будзеце маштабаваць аналітыку, інтэграваць яе ў іншыя сістэмы, перавыкарыстоўваць дадзеныя.
- Ня генеруйце лішнія дадзеныя. Web-статыстыка - гэта апроч карыснай інфармацыі яшчэ і велізарная памыйніца з няякаснымі і лішнімі дадзенымі. І гэтае смецце будзе замінаць пры прыняцці рашэнняў і адзнацы, калі няма выразных мэт.
- Не рабіце аналітыку дзеля аналітыкі. Спачатку мэты, выбар прылады, і толькі потым - аналітыка толькі там, дзе гэта дасць эфект.
Матэрыял падрыхтаваны сумесна з Чабатар Вольгай ().
Крыніца: habr.com