«Для когось це виглядає дико: як це застрягнути на одному місці?». Історія кар'єрного злету IT-фахівчині, яка вже 10 років працює в одній компанії й вважає за щастя потрапити в IT відразу після вишу

Усе тимчасове — постійне

Я навчалася у харківському ВНЗ на перекладача та справді мала амбіції стати саме ним, а не вчителькою. На п’ятому курсі шукала підробіток на період, поки не знайду постійну роботу перекладачем. Так і потрапила до компанії HOSTiQ, де працюю уже 10 років.

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

Перша робота у відділі CS

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

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

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

Згодом я зайняла позицію shift-lead — керівниця зміни. У підтримці, яка працює 24/7, є кілька чергових змін. Спеціалісти спілкуються з клієнтами, обробляють їхні запити, надають відповіді. Поруч завжди має бути людина, яка приймає рішення, несе відповідальність. Також ставала у пригоді моя англійська. Наприклад, були ситуації, коли є збій у роботі сайтів, і він на боці дата-центру. Треба було їм дзвонити в іншу країну, спілкуватися англійською, розпитувати, що ж там не так з сервером чи з мережею — чому воно не працює. Це один з випадків, коли було потрібно на зміні комунікувати не з клієнтами.

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

Перекваліфікація та старт роботи у QA

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

Стартувати допоміг мій супервайзер — він був дуже зацікавлений, щоб у мене все вийшло, бо від цього залежала і його «доля», так він міг швидше перейти на фултайм у розробники.

На той момент я починала з «настільної книги» QA — «Тестирование.dot.com». Книга простою мовою пояснювала «етику» тестування. Далі прослухала онлайн-курси з теорії. Були й відвідування конференції та онлайн-лекції, звісно. Але все одно головним для QA — ставлення до роботи. Можна як «Отче наш» знати теорію, проте лінуватись витратити зайвий час на те, щоб розібрати фічу до молекул.

Залаштунки роботи тестувальниці 

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

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

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

Словом робота цікава, майже детективна, проте я переросла позицію Middle QA. Щоб перейти на позицію Lead мені забракло сміливості та уявлення того, як буду розвивати цей напрям і працювати з командою. Тому пішла іншим шляхом.

Чому і як перейшла до бізнес-аналізу, і що це взагалі таке

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

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

Моє бажання збіглось із баченням керівника і він допомагав мені у розвитку цієї ролі в команді. Спершу я просто коригувала ТЗ, а потім повністю перейшла в окремо виділену позицію бізнес-аналітика. Для цього проходила курси з практичними завданнями впродовж 3 місяців і загалом відвідувала тематичні онлайн-навчання.

Зараз я залучена у всі нові задачі, які приходять до відділу Development: коригую опис поставлених задач, уточнюю вимоги, складаю додаткові документи — business requirements document, де описані багаторівневі цілі проєкту. У масштабних чи середніх проєктах взаємодію з архітектором.

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

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

Які вміння та інструменти, здобуті під час роботи в QA, стали в пригоді у бізнес-аналізі

Хороша новина: їх доволі багато! Тому тримайте перевірений перелік головних навичок, які цінні як для QA, так і BA:

• Root cause analysis — у бізнес-аналітиці як і QA треба вміти копати, як та такса на пляжі, до причини помилки та розбирати фічу до кісточок;
• Уміння зрозуміло викласти технічну документацію;
• Сильні знання доменної області;
• Техніки тест-дизайну допомагають на етапі написання ТЗ;
• Критичне мислення. Переконана, що поставити під сумнів написане — зовсім не погана риса;
• Потрібно не боятись ставити питання та надавати правильне на свою думку рішення;
• Уміння працювати з gray-box та комунікація із програмістами, щоб вони розповіли логіку роботи тієї чи іншої фічі.

Труднощі під час переходу на нову позицію

Як уже казала, позиції BA у компанії до цього не було. Тому я не мала на кого орієнтуватися. Були теоретичні знання з курсів: як має бути, і реальні процеси компанії, в які це все потрібно було інтегрувати. Не одразу вималювалися межі обов’язків бізнес-аналітика з тим же проджект-менеджером та навіть архітектором, що теж було нелегким.

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

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

Поради людям, які планують перейти з однієї посади на іншу

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

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

«Ми вас ощасливимо оффером попрацювати на нас безплатно, а тоді, може, приймемо на роботу». Айтівці діляться історіями про пошук роботи з прифронтових міст

По темi

«Ми вас ощасливимо оффером попрацювати на нас безплатно, а тоді, може, приймемо на роботу». Айтівці діляться історіями про пошук роботи з прифронтових міст

Ким станеш, якщо працювати в одній компанії 10+ років? Ось 10 історій фахівців, які виросли з джунів до менеджерів топрівня з одним роботодавцем. Спойлер: у продукті кар’єра розвивається швидше

По темi

Ким станеш, якщо працювати в одній компанії 10+ років? Ось 10 історій фахівців, які виросли з джунів до менеджерів топрівня з одним роботодавцем. Спойлер: у продукті кар’єра розвивається швидше

Читайте головні IT-новини країни в нашому Telegram

По темi

Читайте головні IT-новини країни в нашому Telegram

Підключай Megogo зі знижками за акційними тарифами.

від 99 гривень на місяць