Питання грамотного менеджмента, балансу між хард- і софт-скілами, та професійного підходу до побудови процесів всередині команди хвилюють лідів усіх напрямків. Нещодавно на мітапі у MacPaw Space зустрічалися QA-ліди великих українських продуктових компаній. Керівники з AMO, Quarks, MacPaw і Uklon обговорювали найбільш гострі теми, що стосуються управління напрямом тестування. Найцікавіше із доповідей спікерів — у нашому конспекті.
Помилки QA лідів
Помилка перша. Найняти не ту людину
Якщо ви єдиний QA-фахівець на проєкті, і маєте бюджет на другого спеціаліста, то саме ви будете тим, хто найматиме його. Що може піти не так? Людина виявиться не підходящою. По-перше, я б радив найняти ту людину, з якою вам особисто буде зручно працювати і спілкуватись. По-друге, ґрейд нового фахівця має відповідати вашому. Так колега зможе замінити вас у виконанні будь-якої таски за необхідності.
Помилка друга. Неправильне планування
Якщо ви долучаєтесь, наприклад, до великого проєкту, і вам потрібно найняти вже не одного, а 3-10-15 тестувальників, то проблема може виникнути інша. Нагірше, що може статись, — неправильно сплановане навантаження і невірно визначена кількість людей, яких потрібно найняти та який у них має бути ґрейд. Якщо ви не впевнені, що зможете все грамотно розпланувати, варто звернутись по допомогу до менеджера з досвідом.
Помилка третя. Радикальні зміни
Якщо ви приходите в уже сформовану команду як QA-лід, можлива помилка — одразу намагатись змінити усі процеси і підходи, які були налаштовані до вас. Спочатку покращуйте щось лише точково і спостерігайте, як все працює. Окрім цього, я б радив провести one-to-one з кожною людиною з команди, спитати її думку — що заважає, що допомагає, що можна покращити. Так ви зможете зібрати основні проблеми, пріоритезувати їх, і вже потім планувати зміни.
Помилка четверта. Страх делегування обов'язків
Як зрозуміти, що у вас проблеми з делегуванням? Ви ловите себе на таких думках:
«лише я знаю, як краще». Пам'ятайте що, на жаль, лід із більшою ймовірністю втрачає технічні навички, тому ваші колеги скоріш за все, знають краще, що треба робити.
«без мене все зламається». Це означає, що ви не довіряєте команді повністю. Такий підхід може спричинити «тепличні» умови для команди, коли лід все «розрулює». Ймовірніше, за таких умов команда припинить розвиватися.
Помилка п’ята. Мікроменеджмент
Мікроменеджмент — це руйнівне управління, від якого страждають усі сторони. Основна задача ліда — дивитись на ситуацію дещо відсторонено, згори, щоби прийняти максимально релевантне рішення. Вам не потрібно вирішувати проблеми за людей, бо це не закінчується ніколи.
Часто мікроменеджмент виникає через недовіру до фахівців. Коли ви починаєте дуже сильно контролювати кожен крок спеціалістів, то витрачаєте свій час неефективно та заважаєте їм виконувати свої прямі обов’язки. А у людей від надмірного контролю з'являється відчуття, що вони не справляються, і їх перформанс ще більше просідає.
Помилка шоста. Неприйняття рішень
Мозок людини працює таким чином, що якщо якусь проблему довго не вирішувати, то починає здаватися, що вона якось вирішиться сама. Головна помилка — коли не приймаються рішення, що вже давно назріли. Як переформувати команду, і чи варто це робити, як відмовитись від певного фреймворку чи підходу до тестування, які ще наче працюють, але вже застарілі, чи варто підвищувати людину в посаді та зарплатні, чи варто звільняти людину, чи вона може змінитись і адаптуватись до вимог проєкту і компанії, чи варто назначати черговий мітинг чи можна обійтись електронною поштою? І ще мільйон різних запитань.
Головний обов'язок ліда — прийняття рішень. Якщо вам здається що ваші рішення — неправильні або не найкращі, скоріше за все, ви на вірному шляху, тому що це свідчить про те, що ви рефлексуєте над ними. Інколи варто просто прийняти рішення, подивитись його на результат, відкоригувати за необхідності та рухатись далі.
Горизонтальна система керування тестуванням
Концепція гільдій
Ще коли я лише починав працювати, мене дивувало, що в IT-галузі іноді на одного інженера — два або й більше менеджерів. Нині, в якості ліда, я потроху формую бачення, як зробити так, щоб це нормально працювало.
В Quarks структура влаштована таким чином: є три великі команди — продуктова, маркетингова і tech team. В межах перших двох команд у нас є декілька автономних кросфункціональних тімок. Що вони собою представляють? Це команда, де є PM, який вирішує, що робити, які таски тощо. Також там є технічні спеціалісти: аналітики, дизайнери, фронтенд- та бекенд-фахівці, QA.
Ще є команда tech team, якою керує CTO. В ній окремо є DevOps, сервісні команди, а також фронтенд,- бекенд- і QA-ліди. Я в якості QA-ліда керую як своєю командою автомейшена, так і по горизонталі всім QA-напрямком нашої компанії. Що це значить? PM в кожній кросфункціональній команді вирішує завдання, пов'язані більше з продуктовим навантаженням, який функціонал буде робитись, яка буде його пріоритетність. А я більше відповідаю зе те, як саме це має бути зроблено.
Таким чином QA-інженер в команді має два керівника — PM і ліда QA-напрямку. Саме тому це називається горизонтальною системою або системою гільдій.
Переваги горизонтальної організаційної структури:
кожною гільдією керує лід, який розуміє специфіку роботи фахівців;
кросфункціональна команда орієнтується на свої результати та процеси, їй не потрібно узгоджувати свій флоу з іншими командами;
PM команди сконцентрований на продуктових задачах;
система «стримувань і противаг». Ніхто не керує всім одноосібно, є декілька центрів прийняття рішень, а це мінімізує ризики;
більш об'єктивна оцінка перформансу технічних спеціалістів;
уніфікація підходів та стеку технологій.
Основні складнощі в системі гільдій
Важливо, щоб PM та QA-лід працювали в унісон, розуміли один одного, або хоча б не заважали.
Кожна команда має свій темп, і це певною мірою може гальмувати уніфікацію. Треба шукати компроміс між усіма учасниками, аби уніфікація відбувалася, не ламаючи процеси нікому.
PM команд мають різний рівень технічних скілів. Важливо комунікувати всі свої рішення та доносити до PM, чому ми робимо саме так.
Лід гільдії повинен мати прокачані технічні і комунікативні скіли, тому що більшість проблем і труднощів виникають саме через брак комунікації і досвіду у когось із команди.
Основні напрямки роботи QA-ліда гільдії
Постійний контроль слідування побудованому флоу тестування.
Створення єдиного центра керуванням тестуванням в компанії.
Комунікація та роз’яснення процесів, інструментів та всього, що стосується QA.
Уніфікація підходів. Це дає змогу суттєво заощадити час і кошти.
Оцінка роботи QA в командах.
Місія, візія і фейли
Що таке місія і чим вона вам допоможе?
Місія – певне розуміння того, чим ви будете займатись на тій чи іншій посаді. Як її сформулювати? Відповісти на питання: що ви робите, як ви це робите і навіщо.
З ростом і зміною ваших зон відповідальності, зміною команди або проєкту буде трансформуватись і ваша візія.
Коли я був інженером, після рев’ю я отримував фідбек про те, що треба розвиватись, шукати свій шлях, вірний вектор руху і таке інше, але що саме треба робити — було незрозуміло. Коли я став лідом, я усвідомив, що це і є моя місія — створити прозорі умови для розвитку інженерів в компанії з дотриманням справедливості по відношенню до компанії. Тобто щоби не лише люди зростали, а й компанія також отримувала профіт.
Візія: тримати у фокусі
Якщо з місією ви працюєте кожен день, тому що це і є ваша робота, то візія — це така собі лінія горизонту, яка майорить десь далеко, але саме вона змушує вас рухатись і приймати ті виклики, які кидає вам індустрія.
Як не втратити візію в рутині? Ви маєте постійно перевіряти, наскільки ваша візія відповідає візії компанії, потребам продукту, індустрії. Її треба постійно розширяти, змінювати відповідно до обставин. Маєте сформулювати те, що ваша візія має дати сьогодні, щоб ви опинились в майбутньому там, куди ви плануєте прийти. Візія — це ваше завтра.
Нині моя візія як ліда — рухатися в сторону спрощення з урахуванням тої цінності для бізнесу, яку ми можемо давати як інженери.
Три фейли і три уроки, що вони принесли
Люди не читають думок. Коли я починав лідити команду, у мене було море ентузіазму, багато ініціатив, я хотів все змінити. Так сталося, що, проговоривши свою місію, візію із тимлідом, я не отримав апрув від своєї команди. Насправді, я навіть не розповів їм про свої ініціативи. Мені здавалось, що все всім очевидно. Тож, коли я почав впроваджувати зміни, то зіштовхнувся із нерозумінням команди.
Варто детально пояснювати команді ваш план — що і для чого, створити умови, щоб вони теж могли контрибьютити і бути залученими у реалізацію цієї стратегії. Вам потрібно мати чіткий роадмеп та надавати регулярні апдейти.
Будь-які зміни потребують детального планування. Одного разу до мене прийшов один з інженерів і запропонував використати новий трендовий фреймворк. Я подумав — класно. Мені здавалось що це буде корисно і для розвитку команди, і для продукту. Але сталося зовсім по-іншому. Через деякий час частина команди, яка здійснювала цей перехід, мігрувала на інші ролі або у інші продукти. Ми опинились у ситуаціі, коли ми сидимо з новим проєктом, і в нас не так багато інженерів, які можуть використовувати його для роботи.
Перш ніж робити серйозні зміни, які можуть вплинути на швидкість делівері продукту, треба оцінити наскільки ці зміни актуальні і потрібні зараз, чи зможете ви знайти спеціалістів, чи зможуть вони не лише підтримувати, а і розвивати продукт.
Не толерувати те, що погано працює. Спочатку я був лідом однієї команди, потім — додалась друга, потім ще і ще. В одному продукті в мене було 5 QA-команд, які були досить розрізненими. Я побачив, що такому хаосі це не буде працювати ефективно — були проблеми з документацією, процесами, підходами, із взаємодією QA між собою.
Якщо бачите проблему з процесами, не тягніть із рішенням. Може статися, що люди просто не дочекаються поки ви проблему вирішите, і підуть. Також не бійтесь обговорювати проблеми прямо із командою та менеджментом.
Комплексний підхід до проведення співбесід
У 2021 році Uklon почала швидко зростати: збільшилися поточні команди, одночасно створювалися нові. Нам потрібні були нові фахівці. Щобільше співбесід ми проводили, тим більше бачили, що наш підхід до інтерв’ювання кандидатів не працює.
В нас був шаблон розмови, зосереджений на технічних питаннях, їх зазвичай багато в інтернеті. Рішення про найм ми приймали в залежності від професійних скілів. Здавалося б логічно, але це було нашою помилкою. Люди, яких ми обирали таким чином, відмінно підходили нам за професійним рівнем, проте не співпадали ані за цілями, ані за цінностями.
Тож деякий час пішов на аналіз та зміну підходу. Я почав аналізувати: що QA-інженери роблять щодня? Приймають рішення — від малих до великих: коли почати тестування, що покривати тестами, які інструменти використовувати в роботі тощо. І я прийшов до того, що підхід кандидата до вирішення завдань для нас має бути важливішим за досвід роботи.
Звісно, в новому шаблоні співбесіди технічні запитання нікуди не ділися, але вони стали мати другорядне значення. Нині основний блок запитань у нас на інтерв’ю — про прийняття рішень.
Кожному кандидату я пропоную уявити певну ситуацію, наприклад:
Інженер взяв задачу в роботу, але її опису немає. Як це можна виправити?
Підходить дедлайн релізу, але баги не закінчуються. Що робити?
Інженер працює над пріоритетними задачами, але його відволікають. Як змінити ситуацію?
Відповіді на такі запитання показують:
чи замислювався кандидат над процесами, в яких він працює;
чи раніше приймав кандидат рішення самостійно;
чи він працював зі своїми помилками;
чи може він нести відповідальність за себе та команду.
Технічні запитання. Копайте вглиб
Оскільки технічні скіли ми у будь-якому випадку маємо оцінити, то для цього блоку співбесіди теж склали декілька вимог до інтерв’юерів:
Уникати заготовленого списку запитань на співбесіді. Складати кастомізований список під кандидата — його скіли, досвід тощо.
Мати заздалегідь розроблені плани співбесід для кандидатів будь-якого рівня.
Під час інтерв’ю орієнтуватися на сильні, а не на слабкі сторони кандидатів.
Ми визначили для такі масивні розділи, які важливі для нас: мобільне тестування, бекенд тестування і веб. В залежності від потреб, від команди, куди ми берем інженера, ми можемо спитати:
Технічну частину співбесіди ми починаємо тепер окремого масивного блоку — чи то мобільне тестування, чи то бекенд-тестування або веб, — в залежності від позиції, на яку наймаємо. Далі під час розмови заглиблюємося в конкретну тему і намагаємося зрозуміти все, що кандидат про неї знає.
Практикуємо щирість
Ми хотіли, щоби наша співбесіда не була допитом. Кандидат в стресі не може адекватно оцінити свої знання і нормально відповісти на питання. Йому має бути комфортно протягом всієї розмови. Якщо він не знає відповіді на запитання або не розуміє його належним чином, я відповідаю на це питання, тим самим показуючи йому, що я від нього очікую. Це класно налаштовує кандидата далі.
Тож в новій ітерації нашого підходу до співбесід ми вирішили, що віддаємо частину контролю кандидату, аби він:
розумів хід співбесіди;
отримував відповіді на свої питання
міг розраховувати на якісний і своєчасний фідбек.
Повний запис мітапу QA-лідів дивіться тут:
