Мій шлях від стажера до керівника аналітики за 4 роки

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Привіт! Мене звати Данило Донєв, я Product Analytics Team Lead на одному з напрямів бізнесу AdConnect в українській продуктовій IT-компанії appflame.

За чотири роки в компанії я пройшов шлях від стажера до керівника команди аналітиків. За цей час зрозумів таку річ — спершу ти доводиш, що вже працюєш на рівні наступної позиції, а вже потім її отримуєш.

Поза роботою я люблю бігати. Кожного року беру участь у благодійному забігу «Десятка Незламності» — якось пробіг 10 кілометрів за 50 хвилин. З минулого літа ще почав займатися вейкбордингом. Це допомагає перезавантажитися після роботи і фізично, і морально.

ЗНО з математики на 200 і вступ у КПІ

Ще в старших класах я знав, що хочу працювати в IT-шці. У принципі, у 2019 році ледь не кожен другий хотів потрапити до IT, але в моєму випадку все склалося органічно. Я навчався в Маріупольському міському ліцеї у фізико-математичному класі. Там я пробував програмувати, створював перші сайти на HTML і кайфував від цього.

Склав ЗНО з математики на 200 балів і на 195 з фізики, тож мені були відкриті всі двері, і я міг обирати будь-який виш. Спершу думав про спеціальність комп’ютерні науки, але зрештою обрав системний аналіз у КПІ через його універсальність і можливість застосовувати знання в різних сферах.

Невдале стажування на тестувальника й пошук себе

Після другого курсу я захотів спробувати себе в тестуванні й навіть подався на стажування Manual QA, до кінця не розуміючи, що це таке. На етапі добору зрозумів, що це точно не моє, і, зрештою, добір не пройшов. Потім почав подавати резюме в різні IT-компанії на посаду продуктового аналітика, хоча тоді ще теж доволі поверхнево уявляв, яка робота на мене чекає. Я щось умів в Excel, трохи працював із базами даних, але цього явно було мало для джуна.

Справжнє розуміння, чим займається аналітик, прийшло вже в appflame. Влітку 2021 року я натрапив на оголошення компанії на DOU про стажування для продуктових аналітиків і вирішив спробувати. Тут мені на руку зіграла математика — під час добору акцент був саме на знаннях із математики, статистики, дискретки та комбінаторики. У цьому я був сильний, а от про SQL, візуалізацію даних, когортний аналіз не знав нічого. Проте, на той момент мені вистачило сильних математичних знань і я потрапив на стажування.

За три місяці стажування я побачив, що роблять аналітики й почав кайфувати від цієї роботи. Я опанував SQL на базовому рівні, почав розуміти, як працює бізнес-модель продукту, побачив, як проводяться A/B-тести і вперше усвідомив, чого очікують від аналітика в продуктовій IT-компанії. До слова, про вимоги до аналітиків-початківців детально розповідав мій колега в цій статті на DOU.

Ініціативність допомогла мені на посаді джуна

На стажування подалися близько сотні людей, але добір пройшли тільки троє і, зрештою, нам усім запропонували офер на позицію Junior Product Analyst в AdConnect.

У той період я почав роботу над новою комбінованою бізнес-моделлю продукту. Моє завдання було в тому, щоб зрозуміти, як відбуваються списання коштів, як налаштовані рекурентні платежі, як у цьому процесі формується юніт-економіка тощо.

Крім цього я долучався до налаштування трекінгу для нових фічей — системи подій і даних, яка допомагає зрозуміти, як користувачі взаємодіють із продуктом: куди натискають, що купують, на якому етапі припиняють користуватися продуктом і таке інше.

До слова, для цієї задачі недостатньо розумітися лише в аналітиці, треба знати й базові принципи роботи Back-end/Front-end, бо серверна частина відповідає за передачу і збереження цих даних, а фронтенд за те, які події можна відстежити на стороні користувача.

Тому на співбесідах я іноді даю задачу аналітикам порахувати, скільки бургерів готує один McDonald’s за день. Це не типова аналітика й ми пояснюємо кандидатам, що питання добре перевіряє, як вони можуть структурувати задачу, які припущення роблять і як крок за кроком доходять до відповіді. Та сама логіка працює і у розробці трекінгу — аналітикам потрібно зрозуміти, який результат хоче отримати бізнес, і вже під це будувати систему збору даних.

Найскладнішим на старті для мене було розібратись у моделі підписки, щоб зробити її водночас зрозумілою для користувача та ефективною для бізнесу. А от можливість працювати з багатьма зонами на продукті мене драйвила.

На проєкті було лише двоє аналітиків — я і моя керівниця, — а тому я мусив навчитися розбиратися в усьому: як працюють платіжки, маркетинг, user retention, продажі тощо. Це дало мені цілісне розуміння бізнесу. Тому я раджу початківцям йти в аналітичні команди до 10 людей, щоби попрацювати в різних зонах одночасно й набути досвіду в кожній із них.

На позиції джуна я також багато пропрацював над налаштуванням процесу A/B-тестування. Гадаю, що це був один із найкорисніших проєктів, який мені вдалося тоді реалізувати для команди. Раніше під кожен тест ми робили окремий звіт. Будь-яка зміна запиту або оновлення звіту займала пів дня в одного аналітика. До того ж, не було змоги одразу моніторити тест після запуску, щоби перевіряти, чи все працює. А окремий звіт на кожен тест змушував і менеджера, й аналітика витрачати зайвий час на перевірку. Тож я вирішив оптимізувати роботу й розробити один спільний звіт для всіх тестів. Оскільки більшість із них мають схожі умови запуску, я створив єдину систему, яка покрила 80 % всіх можливих варіантів тестів.

Логіка звіту була така:

• в одній таблиці зберігаються всі поточні спліти та їхні умови;
• щодня скрипт перевіряє кожного користувача й визначає, у який тест і яку групу він потрапив;
• для кожного такого запису автоматично збираються потрібні метрики залежно від умов;
• до цих даних ми додали статистичні моделі, які показують значимість результатів і скільки ще має тривати тест.

Приємним бонусом стала можливість бачити аналітику зі процесу А/B-тестування: кількість запущених тестів, % success rate, на які зони проводили тести й таке інше.

Інший кейс стосувався роботи тестувальників, хоч це не було моєю прямою зоною відповідальності. Через велику кількість паралельних тестів їм було складно потрапити в потрібні комбінації змін (інтерфейсу або функціональності продукту), — тож я запропонував автоматизувати цей процес, щоби пришвидшити тестування.

На Jupyter Notebook написав квазі-сайт, де можна було обрати кількість тестів, у які треба потрапити, і, відповідно, групи цих тестів. Потім скрипт автоматично створював нові тестові акаунти один за одним, доки не знаходив той, що потрапляв у потрібний тест і групу.

Це було не дуже елегантне, але швидке рішення. Й особливо цікаве мені з погляду роботи над продакшн API й написання коду (на той момент я робив це вперше й ще без допомоги АІ).

Уже на новому проєкті, до якого я долучився згодом, ми запустили цей процес правильно з погляду Back-end і тестування — з використанням фіче-флагів і можливості їх змінювати по API.

Цей досвід показав мені, що на початку кар’єри не варто обмежуватися своїми прямими обов’язками. Якщо бачите проблему, кажіть про неї, пропонуйте рішення і це 100 % зіграє вам на руку в майбутньому.

Як я став першим аналітиком на новому проєкті й життя заграло новими барвами

Приблизно через півтора року я перейшов на позицію Middle. Цей процес дещо затягнувся через повномасштабну війну та невизначеність. У мене трохи просів перформанс, бо не було мотивації на тлі того, що відбувалося в країні. Але згодом ситуація стабілізувалася.

Перехід на нову позицію був органічним, адже на той момент я вже запустив декілька продуктових тестів, покращив сплітування (систему розподілу користувачів між тестовими групами), оптимізував платіжні процеси й таке інше. Але найбільше на підвищення все ж вплинуло те, що я сам виявляв проблемні зони на проєкті й закривав їх.

На рівні Middle я, зокрема, оптимізував логіку списань коштів для користувачів із підпискою. Проблема була в тому, що частина з них переставала активно користуватися продуктом і було ризиковано й далі списувати з них кошти, бо через це росли скарги й погіршувалося ставлення до продукту.

Я зробив так, щоби з активних користувачів кошти й далі списуватися за планом, а для неактивних списання припинялися або вимикалися. У результаті ця оптимізація скоротила кількість звернень у банк від наших користувачів із проханням повернути кошти й час команди на опрацювання цих заявок.

Також, через Similarweb я провів глибокий аналіз аналітики конкурентів — зібрав різні дані, щоб краще розуміти, як працює ринок. У результаті ми стали краще розуміти структуру ринку, канали залучення, демографії і потреб користувачів у ніші.

Через рік я вперше задумався про звільнення і перехід в іншу компанію, бо хотів працювати з новими бізнес-моделями. Але ця ідея дуже швидко стала неактуальною, адже в межах AdConnect ми почали запуск нового бізнесу — дейтинг-продукту, на якому я працюю зараз.

Мене тоді підвищили до Senior і я став першим аналітиком на цьому проєкті. Це повністю змінило фокус моєї роботи — можливість разом із командою будувати бізнес із нуля мене дуже змотивувала.

Частина команди AdConnect

На проєкті я почав закладати схему даних для майбутньої аналітики, створював перші репорти, оцінював окупність проєкту й таке інше. Також, оскільки я був першим аналітиком на проєкті, я почав займатися наймом нових людей і лідив команду ще на позиції Senior.

Десь за рік проєкт запустився і досяг перших цілей. У березні 2024 року прийшли перші користувачі, а згодом ми вийшли на цільовий LTV/CAC — тобто дохід із користувача почав кратно перевищувати витрати на його залучення. Це підтвердило, що ми готові до масштабування.

Через пів року я обійняв посаду Deputy Team Lead, а віднедавна — Analytics Team Lead. Фактично, свою позицію я заслужив заздалегідь — показав результат, який мені згодом підтвердили просуванням. Як на мене, це дуже крута і правильна модель, коли ти не отримуєш підвищення наперед, а доводиш, що вже готовий до наступного рівня.

Те, що мене наразі мотивує в роботі, — це можливість подальшого зростання команди й загалом проєкту. Дейтинг-ринок доволі великий і ми розуміємо, як можемо масштабуватися.

Яких аналітиків потребує ринок

Найм людей у команду — це дуже ресурсозатратний процес, який до того ж часто невидимий для інших. Багато часу йде на те, щоби підготуватися до інтерв’ю, познайомитися з кандидатом, зрозуміти, які питання ставити, порефлексувати і прийняти рішення.

На початку мені дуже допомогли внутрішні навчання в appflame із найму, адже в університеті такого не вчать, і я спершу не знав, на що звертати увагу. Із часом для себе я виокремив три головні критерії в доборі кандидатів у команду:

1. мотивація: чому людина хоче працювати саме в аналітичній команді;
2. хардскіли: знання SQL, вміння інтегрувати ШІ в роботу, бізнес-кейси. Якщо це позиція Junior, то здебільшого розпитую кандидата про навчальний досвід, позаурочну активність, у Middle — про попередній практичний досвід;
3. проактивність: під час випробувального терміну для мене важливо побачити, що кандидат вміє самостійно знайти проблему у своїй зоні й запропонувати рішення, а не чекати інструкції на кожен день.

Також, зараз кандидатам на аналітичні позиції недостатньо знати синтаксис Python чи SQL. Хороший фахівець мусить мати ширше мислення: розуміти, як працює Data Science, алгоритми, які метрики варто аналізувати. Код сьогодні може написати ШІ, але саме аналітик визначає, що запитувати і як інтерпретувати результат. Водночас фундаментальними залишаються такі базові речі, як реляційна модель даних та принципи візуалізації.

До слова, ми в appflame час від часу проводимо стажування для початківців, а також наші колеги долучаються викладачами до зовнішніх курсів і подій. Зараз у нас проходить стажування з Email Marketing, до якого долучилося пʼять початківців.

Узяти в команду людину зі стажування для мене значно простіше, ніж кандидатів по стандартному флоу найму, адже всі учасники вже пройшли добір — їхні хардскіли підтверджені, а мені залишається зрозуміти, чи збігаємося ми за цінностями.

Як працює аналітична команда на нашому проєкті

Сьогодні моя команда — це шість людей разом зі мною. У травні до нас ще доєднався Data Scientist, адже задачі стають складнішими, зокрема щодо прогнозування доходу та персоналізації досвіду користувача.

Аналітична команда на нашому проєкті

Перед собою і командою ставлю кілька ключових завдань на найближчі пів року:

1. забезпечити подальше зростання бізнесу завдяки аналітичним рішенням і ефективним продуктовим тестам. Зокрема підвищувати нашу верхньорівневу метрику — збільшувати % користувачів, які знайшли партнера для спілкування і певний час із ним поспілкувалися;
2. повноцінно інтегрувати AI в аналітику. Ми плануємо демократизувати дані, щоб аналітика не була єдиним джерелом інформації, а керівники команд і маркетологи могли самостійно отримувати бізнес-висновки;
3. точніше оцінювати окупність маркетингу й краще розуміти, які канали й аудиторії приносять бізнесу найбільшу цінність. Це доволі нетривіальна задача, бо значна частина нашого доходу приходить від невеликої частки платників із дуже високим LTV.

Кожні чотири місяці наш бізнес визначає цілі і ключові метрики (OKR) для всіх напрямів, включно з аналітикою. Далі ми з командою розподіляємо задачі, складаємо приблизний роадмап із термінами й фіксуємо все в особистих цілях кожного — ці цілі відкриті для всієї компанії.

Та складність у тому, що контекст в аналітиці часто змінюється. З’являються нові задачі й тому стратегічні цілі іноді доводиться відкладати. Наприклад, виникає потреба з’ясувати причину зниження метрики й запропонувати, як повернутися до попередніх значень. Це не окей, тому я щомісяця переглядаю план, щоб зрозуміти, чому деякі цілі не вдалося досягти. Якщо операційка витісняє стратегічну роботу, то, значить, я збудував неправильну систему. Але бувають ситуації, коли поточне завдання є критично важливим, і тоді переорієнтація — це окей.

Проте, у нас не було ситуації, коли б команда не закривала свої цілі, бо неефективно працює. Здебільшого причина в неправильному плануванні або зовнішніх факторах. Наприклад, якось ми двічі переносили задачу «Покрити трекінгом певну велику компоненту». Проблема була в тому, що ми формулювали її як технічну — «Додати трекінг» — а не через бізнес-результат: «Трекінг і звіт дозволять менеджеру краще приймати рішення, і метрика Y зросте на N%».

Це нагадало, чому в OKR є «Key Result». Додати трекінг, побудувати модель, зробити звіт, висунути гіпотезу — це не результат. Аналітик часто зупиняється на цьому етапі, але ж відповідальність на цьому не закінчується.

Раз на тиждень ми також проводимо сінки з командами — окремо з маркетингу і продукту — щоб актуалізувати завдання. Можна назвати це плануванням спринта, але я не дуже вірю, що в аналітиці працюють спринти:) Завжди є щось додаткове, що потрібно вирішувати терміново. План на початку тижня має бути, але треба бути готовими, що в середу зʼявиться задача від CEO, маркетингу або продукту, яка має вищий пріоритет, бо напряму впливає на гроші.

Тренди в аналітиці і вплив ШІ на професію

Ми зараз на порозі великих змін у професії. ШІ-моделі вже на рівні з Junior аналітиками можуть збирати дані, опрацьовувати їх і робити висновки. Із часом їхня точність тільки зростатиме.

Вміння працювати із ШІ для новачків стає обов’язковим хардскілом на рівні з SQL. Можливо, навіть SQL згодом перейде на другий план, і не буде потреби його вивчати поглиблено.

Проте, роль людини в аналітиці залишатиметься критично важливою. Потрібно розуміти продукт, логіку тестування гіпотез, бізнес-контекст, правильно формулювати питання, а також помічати причинно-наслідкові зв’язки й ухвалювати рішення на основі неповної інформації. Так, ШІ може видавати поради, але аналітики мають їх перевіряти.

Початківцям я б радив не зациклюватися на окремих інструментах (як от Python й SQL), а розвивати широке розуміння — які підходи, моделі й алгоритми розвʼязують різні типи задач. Три практичні поради, як це зробити:

1. постійно декомпозувати задачі. Якось заради розваги я задався питанням «Скільки готель Х приносить доходу за 1 рік». Це доволі цікава вправа, що дозволяє розбити питання на залежні метрики, які вже простіше порахувати і принаймні прикинути порядок доходу;
2. вивчати базові класи методів. Не потрібно знати всі алгоритми глибоко, але важливо розуміти, коли потрібна регресія, коли класифікація, коли causal inference, коли A/B-тест, коли прогноз часових рядів, а коли достатньо когортного аналізу;
3. тренувати критичне мислення до даних. Хороший аналітик має постійно питати, чи повні дані, чи немає лагів, чи не змінилася логіка трекінгу, чи не змішалися різні когорти, чи не пояснюється результат випадковістю або зовнішніми чинниками. Перевіряти висновки на упередження. Бачите в новинах графік? Перевірте, чи не маніпулюють вісями, або чи справді ідеться про причину й наслідок у дослідженнях на кшталт вживання червоного вина та здоров’я серця.

Фахівцям, які хочуть керувати аналітичними командами, раджу будувати гарні стосунки з іншими керівниками. Так ви зможете перейняти досвід і порадитися в складних питаннях із тими, хто вже пройшов через певні виклики.

Взагалі нетворкінг дуже важливий. Нещодавно я брав участь у конференції з UKRSIBBANK. Було цікаво бачити, що підходи в різних індустріях, як от банкінг і IT, часто перетинаються. Ми дискутували на різні теми, у чомусь наші погляди збігалися, у чомусь — ні. Але саме в цьому і є цінність нетворкінгу.

На події від appflame і UKRSIBBANK

Якщо озиратися назад, то я зрозумів, що якби мені знову довелося обирати напрям для професійного розвитку, я б знову обрав аналітику. Але паралельно ще б розвивався в продуктовому менеджменті, щоб краще розуміти бізнес-контекст. Адже аналітик, який розуміє продуктову логіку, краще бачить, які зміни можуть вплинути на поведінку користувачів, де є ризик локальної оптимізації, а де є можливість для росту продукту.

Ще зрозумів для себе, що часта зміна компаній — не єдиний спосіб швидко розвиватися в кар’єрі. Навіть у межах одного бізнесу можна отримувати нові задачі, більше відповідальності й поступово зростати, якщо активно включатися в роботу команди та впливати на результат. Бо саме під час виконання задачі у вас прояснюється найбільше контекстів і можливостей знайти щось таке, що оптимізує роботу або вплине на бізнес-метрики. Цим варто користуватися.