Как намерихме страхотен начин да свържем бизнеса и DevOps

Философията на DevOps, когато разработката се свързва с обслужването на софтуер, вече не изненадва никого. Нараства нова тенденция — DevOps 2.0 или BizDevOps. В него в едно цяло се съединяват вече три компонента: бизнес, разработка и поддръжка. И както в DevOps инженерните практики легитимират връзката между разработката и поддръжката, така и в биздевопс аналитиката поема ролята на "лепило", обединяващо разработката с бизнеса.

Искам да призная веднага: за това, че имаме истински биздевопс, разбрахме едва сега, прочитайки умни книги. То е така, както се е получило благодарение на инициативата на служителите и неутолимата страст към подобрения. Сега аналитиката е част от производствения процес на разработката, значително съкращаваща цикълните обратни връзки и редовно предлагаща инсида. Ще обясня подробно как всичко е устроено при нас.

Недостатъци на класическия DevOps

Когато се замислят нови клиентски продукти, бизнесът създава идеален модел на поведение на клиентите и разчита на добра конверсия, на базата на което изгражда своите бизнес цели и резултати. Екипът на разработчиците от своя страна се стреми да създаде много добър, качествен код. Поддръжката пък се надява на пълна автоматизация на процесите и на леснотата и удобството при обслужването на новия продукт.

Реалността често се оформя така, че клиентите получават доста сложен процес, бизнесът се сблъсква с ниска конверсия, екипите по разработка пускат корекции една след друга, а поддръжката е затрупана от потока запитвания от клиенти. Звучи познато?

Коренът на злото тук се крие в дълга и некачествена обратна връзка, заложена в процеса. Бизнесът и разработчиците при събиране на изисквания и получаване на обратна връзка по време на спринтовете комуникират с ограничен брой клиенти, които силно влияят на съдбата на продукта. Често нещата, които са важни за един, съвсем не са характерни за цялата целева аудитория.
Разбирането за това, дали развитието на продукта върви в правилната посока, идва заедно с финансовите отчети и резултатите от маркетинговите изследвания месеци след пускането. Дори и те заради ограничеността на извадката не предлагат възможност за проверка на хипотези с голям обем клиенти. Общо взето, се получава бавно, не точно и неефективно.

Трофейният инструмент

Ние намерихме добър начин да се освободим от това. Инструментът, който по-рано помагаше само на маркетолозите, сега попада в ръцете на бизнеса и разработчиците. Започнахме активно да използваме уеб аналитика, за да наблюдаваме процеса в реално време, тук и сега да разберем какво се случва. На базата на това да планираме самия продукт, неговото представяне на голям брой клиенти.
Ако се планира някакво подобрение на продукта, можете веднага да видите с какви метрики е свързано и как тези метрики влияят на продажбите и на важните за бизнеса характеристики. По този начин можете веднага да отсеете хипотезите с нисък ефект. Или, например, да представите нова функция на статистически значим брой потребители и в реално време да наблюдавате метриките, да разберете дали всичко работи както е планирано. Не да чакате обратна връзка под формата на запитвания или отчети, а веднага сами да следите и бързо да коригирате процеса на създаване на продукта. Можем да представим нова функция, след три дни вече да съберем статистически валидни данни, да направим промени още след три дни — и ето, след седмица имаме отличен нов продукт.

Можем да проследим цялата воронка, всички клиенти, които са влезли в контакт с новия продукт, да открием точките, в които воронката рязко се стеснява и да разберем причините. Както разработчиците, така и бизнесът сега следят за това, то е част от ежедневната работа. Те виждат един и същ клиентски път и заедно могат да генерират идеи и хипотези за подобрение.

Тази интеграция между бизнеса и разработката, заедно с аналитиката, дава възможност да се създават продукти непрекъснато, постоянно да се оптимизират, да се търсят и виждат проблемните места, целия процес в цялото.

Всичко е в сложността

Когато създаваме нов продукт, започваме не от чисто лист, а го вграждаме в вече съществуващия сложен набор от услуги. Докато се свиква с новия продукт, клиентът най-често комуникира с няколко подразделения. Може да се свърже с служителите на контактния център, с мениджърите в офиса, може да се обърне към поддръжката, в онлайн чатове. С помощта на метрики можем да видим, например, каква е натовареността на контактния център, как по-добре да обработваме входящите запитвания. Можем да разберем колко хора стигат до офиса и да подскажем как да продължим да консултираме клиента.

С информационните системи е точно така. Нашата банка съществува вече повече от 20 години, през които е създадена и все още функционира голяма част от разнородни системи. Взаимодействието между бекенд системите понякога е непредсказуемо. Например, в някаква стара система по определено поле има ограничения за броя на символите, и понякога това предизвиква срив на новия сервиз. Откриването на бъгове по стандартните методи е доста сложно, а с помощта на уеб аналитиката — елементарно.

При нас стигнахме до там, че започнахме да събираме и анализираме текстовете на грешките от всички включени системи, които се показват на клиента. Оказа се, че много от тях са остарели, а дори не можехме да си представим, че те някак участват в нашия процес.

Работа с аналитиката

При нас уеб аналитиците и екипите от разработчици, работещи по методологията SCRUM, са в едно помещение. Те постоянно взаимодействат помежду си. Когато е необходимо, специалистите помагат за настройване на метрики или извличане на данни, а основно другите членове на екипите работят със сервиза за аналитика, там няма нищо сложно.

Помощ е необходима, ако, например, са нужни определени зависимости, допълнителни филтри по ограничен тип клиенти или източници. Но в текущата архитектура рядко се сблъскваме с това.

Интересно е, че внедряването на аналитиката не изискваше инсталация на нова IT система. Използваме същия софтуер, с който преди работеха маркетолозите. Нужно беше само да се съгласим за неговото използване и да го внедрим в бизнеса и разработката. Разбира се, не можехме просто да вземем това, което имат маркетолозите, трябваше всичко да се пренастрои и на маркетолозите да се предостави достъп до новата среда, за да бъдат с нас в едно информационно поле.

В бъдеще планираме да закупим подобрена версия на софтуера за уеб аналитика, който ще ни позволи да се справим с нарастващите обеми на обработваните сесии.

Също така активно протича процес на интеграция на уеб аналитиката и вътрешните бази данни от CRM, счетоводни системи. Обединявайки данните, получаваме пълно представяне на клиента във всички нужни разрези: по източници, типове клиенти, продукти. BI услугите, които помагат за визуализиране на данни, скоро ще станат достъпни за всички подразделения.

Какво постигнахме в крайна сметка? Всъщност направихме анализа и вземането на решения по него част от производствения процес, което доведе до видим ефект.

Анализа: не стъпвайте на мотиката

И накрая, искам да споделя съвети, които ще ви помогнат да избегнете натрупването на удари в процеса на изграждане на биздевопс.

1. Ако не можете да направите анализа бързо, значи правите неправилен анализ. Трябва да следвате простия път от един продукт и след това да мащабирате.
2. Задължително трябва да имате екип или човек, който добре разбира бъдещата архитектура на анализа. Трябва още преди началото да се определите как ще мащабирате анализа, как ще го интегрирате в други системи и как ще преиспользвате данните.
3. Не генерирайте излишни данни. Уеб статистиката — това освен полезна информация е и огромна сметища с некачествени и излишни данни. И този отпадък ще пречи при вземането на решения и оценките, ако нямате ясни цели.
4. Не правете анализа заради анализа. Първо целите, избор на инструмент, а след това — анализ само там, където ще има ефект.

Материалът е подготвен съвместно с Чеботарь Ольгой (olga_cebotari).

Източник: habr.com