Як я виросла від QA-інженерки до Head of Delivery

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

Вітаю! Мене звати Ірина Ольховик, я обіймаю посаду Head of Delivery у w7g, компанії з екосистеми продуктових бізнесів Genesis. До цього впродовж п’яти років я працювала QA-інженеркою в аутсорсі й в продукті. Моя кар’єра розпочалася на останніх курсах університету, і чим більше я занурювалася у сферу тестування, тим більше розуміла, що це моє.

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

Як усе починалося: перші кроки в ІТ

Моя університетська освіта — це такий собі коктейль з аналітики та технологій. Навчальна програма спеціальності «Економічна кібернетика» у КНЕУ ім. Вадима Гетьмана поєднувала економіку та технічні дисципліни, тому я мала змогу познайомитися з базами даних, логікою алгоритмів і статистичним моделюванням.

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

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

Тоді напрям QA лише починав набирати обертів, тож не було ані широкого розголосу, ані численних навчальних програм. Нині цей фах часто сприймають як стартову точку входу в ІТ, мовляв, «спершу щось потестую рік, а потім стану розробником». Однак в моєму випадку це був справді свідомий і виважений карʼєрний вибір.

Перша робота й перші виклики

Після пари років в аутсорсі я почала думати над переходом у продукт. Річ у тім, що в аутсорсі твоя залученість у проєкти напряму залежить від того, як компанія домовилася з замовником. Було таке, що на потенційно цікаву роботу доводилося виділяти кілька годин на тиждень, а увесь інший час працювати над монотонними завданнями, де клієнт блокує все через найменші відхилення. В продукті ж фокус більш цілісний: пріоритети визначаються бізнес-цілями, а QA може повністю зануритися в цікаву для себе нішу.

Незабаром трапилася нагода для світчу — і я приєдналася до новоствореного генезійського продукту Keiki, де стала першим QA. Ні шаблонів, ні інструкцій, ні сформованих процесів поки не було. Це означало, що у мене є повна свобода і водночас відповідальність побудувати роботу так, як хочу. Усі системи, якісні флоу і навіть «голос тестування» в продукті — це було моїм завданням із нуля.

Долучайтесь до збору на Павуки Допхіна!

На щастя, робота в продуктовій екосистемі передбачає спілкування та нетворкінг з колегами з інших команд. Вони попри завантаження ділилися досвідом, відповідали на запитання, підкидали рішення — це було надзвичайно цінно. Саме ця культура обміну знаннями — коли можна звернутися до будь-кого в компанії (у межах NDA, звісно) — і є однією з найбільших переваг Genesis.

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

Від софт-лончу до нового рівня відповідальності

Працюючи у Keiki, я познайомилася із майбутньою СЕО w7g Галиною Єфремовою. Коли проєкту було уже пів року, я звернулася до Галини: чи не потрібна їй людина з моїм досвідом. Мені подобалася моя робота у Keiki, але я відчувала, що хочеться нових викликів. Після короткої співбесіди з Галиною ми погодили мій перехід.

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

Ближче до кінця 2022 року моя зона відповідальності почала суттєво виходити за межі QA. Я продовжувала координувати тестування, але також усе частіше брала суміжні задачі: узгоджувала пріоритети, комунікувала з розробкою, допомагала вирішувати неочевидні організаційні моменти. Саме тоді СЕО запропонувала мені спробувати себе в ролі проєктної менеджерки. Подібний світч був і логічним, і трохи лячним.

Почала занурюватися у галузь: опановувала теоретичну базу, прочитала книги про delivery, розібралася з процесами та фреймворками. Але швидко з’ясувалося, що цього недостатньо. Практично кожне нове завдання потребувало ґрунтовніших знань та досвіду. Натомість справжньою опорою стали софт-скіли — комунікація, ownership, здатність швидко навчатися.

Особливу увагу слід було приділити навичкам надання зворотного зв’язку. Це досі зона мого зростання, але саме досвід допоміг зрозуміти: менеджмент — не лише про контроль, а про здатність мотивувати й формувати середовище для зростання.

На початку 2024 року я уже формально перейшла на позицію Head of Delivery. Ми почали шукати зміну на роль QA-ліда — і до команди приєдналася спеціалістка, яка поступово перебрала на себе ці функції. Я ж зосередилася на менеджерських обов’язках, забезпечуючи злагоджену роботу розробки, тестування й сапорту.

Зростання завдяки команді

Я не формувала команду з нуля, оскільки більшість людей працювали в компанії вже давно, ще з тих часів, коли я обіймала посаду QA-інженерки. Однак труднощів із завоюванням авторитету не було, адже це часто не про позицію як таку, а про якості людини: відповідальність, ownership, вміння показувати помітні й вагомі результати, вміння мотивувати команду іти за тобою.

Перехід із QA у менеджмент не спричинив напруги навіть із сеньйорами-розробниками. Причина проста: рішення ухвалюємо колективно. Я спершу слухаю команду, пропоную варіанти, а вже потім об’єдную їх у план, що закриває бізнес-цілі й спрощує роботу фахівців. Так підґрунтя для конфліктів зникає. Утім, «синдром самозванця» інколи давав про себе знати.

Як розвиватися, коли ти Head

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

1. Делегування. У команді точно є люди, яким цікаво робити завдання керівника. Якщо вам цікавий новий напрям, то частину роботи варто передати їм, адже інакше нові завдання і напрями просто не помістяться в графік.
2. Ревізія процесів. Раз на квартал я чесно запитую себе: «Це завдання дійсно має бізнес-цінність чи існує за інерцією?» Усе, що не приносить користі — усуваємо чи автоматизуємо.
3. Автоматизація. Slack-бот, який з опису в чаті формує тікет у Jira — наче дрібниця, але щодня економить десятки хвилин робочого часу. А чим менше роботи «вручну», тим більше часу на стратегічне планування.

Окрім цього, ми періодично обговорюємо із СЕО актуальні виклики або ідеї для розвитку. Часто у подібних діалогах народжуються нові вектори роботи.

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

Поради тим, хто починає кар’єру в ніші QA сьогодні

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

Оберіть фокус. Не хапайтеся за все одразу. Оберіть один напрям — автоматизацію, мобайл, API, тест-дизайн, безпеку — і працюйте з ним. Тоді ви набагато швидше помітите перші результати.

Дивіться на завдання і з погляду користувача, і з погляду бізнесу. Періодично ставте собі питання: «Що я тестую і навіщо?» Що раніше почнете думати подібним чином, то сильнішим фахівцем станете.

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

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

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

P. S. Нижче залишаю список ресурсів, які допомогли пройти кар’єрний шлях від QA до проджект-менеджменту та Head of Delivery.

1. Все почалося із зацікавленості в сертифікаціях з QA. Тут для мене особливо цінною виявилася книжка Advanced Software Testing. Guide to the ISTQB Advanced Certification as an Advanced Test Manager (Rex Black). Я досі періодично до неї повертаюся. Автор ґрунтовно аналізує атрибути багів, що дає змогу ефективно збирати статистику, виявляти першопричини їхньої появи та розробляти методи усунення. Пізніше я перейшла до книг, які більше стосувалися фреймворків Agile та власне процесу delivery.

2. Scrum and XP from the Trenches (Henrik Kniberg). Книга про впровадження методологій Scrum у команді на 40 осіб. Вони також експериментували з практиками XP — різними способами безперервної збірки, парного програмування, розробки через тестування тощо — і думали як поєднати це зі Scrum. Перечитувала це видання щонайменше двічі.

3. Мапа історій користувача. Відкрий правдиву історію, створи саме той продукт (Пітер Ікономі, Джеф Петтон). Це чудова книга, яка в доступній формі пояснює, як успішно втілювати проєкти, використовуючи Story-картки. Ці картки розбивають проєкт на ключові складники, кожен з яких буде готовим до розробки та ітеративного випуску в продакшн.

4. Scrum. Навчись робити вдвічі більше за менший час (Джефф Сазерленд). У книжці йдеться про те, що майже будь-який виробничий процес (наприклад, будівництво будинку) можна організувати за принципами Scrum. Тобто саме ітеративний підхід дозволяє випустити справді актуальний продукт.

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

6. Раджу також звернути увагу на сертифікацію Google Project Management Professional Certificate та PMP Cetification.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.