QA у великій компанії vs. QA у стартапі: де спеціаліст швидше зростає

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

Привіт, мене звати Микита Жуков. Я — Quality Assurance Engineer у стартапі Brighterly від venture builder SKELAR. Ми будуємо закритий маркетплейс для навчання дітей математиці.

Відколи я змінив велику продуктову компанію на стартап, одне питання не дає мені спокою: «Чому я не знав цього раніше?». Але якщо задуматись трохи ретельніше, то насправді всі, хто дивився серіал Silicon Valley, мають досить правдиве уявлення, як функціонує стартап-комʼюніті (хто б міг подумати, що кінороби створять реалістичну картинку).

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

Дисклеймер: я ніколи не працював у сервісних компаніях, а мав справу тільки з продуктами, тому всі думки, факти і висновки ґрунтуються на порівнянні продуктових компаній.

Перший день у компанії та стартапі

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

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

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

А мій перший день у стартапі виглядав так:

1. Інтро-сінк з лідом.
2. Отримання всіх необхідних доступів (до години часу).
3. Перша задача.

Дуже показовим був перший дейлік. Під час обговорення стало зрозуміло, що в команді розробки вже є готова задача з підключення нової платіжної системи. І лід каже: «О, чудова задача для Микити». Відчуваєте різницю? Два тижні штудіювання документації та перевірка надважливої бізнес-фічі у перший день. Тоді я зрозумів, що потрапив у інший світ.

Основні відмінності робочих процесів

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

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

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

Загалом обов’язки будуть виглядати саме так, як розповідають на курсах, пишуть в інтернеті чи показують на YouTube: перевіряти готові до тестування таски, підтримувати документацію, ганяти час від часу регресії. І в цьому немає нічого поганого, бо QA знає, що робив вчора, і знає, що буде робити сьогодні та завтра. Все максимально зрозуміло.

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

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

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

Окей, але в чому це буде виражатися для тебе як QA?

• Ти стаєш точкою входу. Крім виконання прямих обов’язків, ти — ще й людина, яка знає продукт краще за будь-кого. Тепер, окрім частини механізму розробки, ти ще служиш технічною підтримкою для внутрішніх користувачів.
• Ти повинен бути готовим взяти на себе роль абсолютно будь-кого: бізнес-аналітика, продакта, реліз-менеджера та будь-кого іншого.
• Дивитися на задачу не тільки з технічного боку, а й з продуктового. Оскільки ти користуєшся продуктом буквально більше за всіх, до тебе в будь-який момент може прийти продуктове «просвітлення», яке обов’язково потрібно передати команді.

Ось чим конкретно я займаюся:

• Моніторинг загального стану системи (графіки у Grafana, консоль Google Cloud, дашборди в Amplitude, що побудовані для виявлення технічних проблем).
• Побудова відповідних дашбордів.
• Загальні QA-обов’язки (перевірка готових задач, багрепортинг, складання і підтримка тестової документації тощо).
• Реліз-менеджмент, тобто контроль того, що йде в реліз сьогодні, а що ні. Якщо щось планувалося раніше, але не потрапляє сьогодні — повідомити про це стейкхолдерів. Також я підпушую розробників, коли є потреба звернути увагу на важливу задачу, що потрібна сьогодні, запуск пайплайну (у народі: «натискання кнопки»).
• Виявлення всіх проблем, які приходять від будь-якого відділу (CSM, Sales, аналітики, продуктологи тощо).
• Оунерство задач у випадках, коли задача внутрішня (адмінка, аналітика) і може прийти від зацікавлених осіб одразу на розробку, оминувши продуктову команду.

Різноманітно, чи не так?

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

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

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

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

Рецензент статті — Геннадій Міщевський.