Питання грамотного менеджмента, балансу між хард- і софт-скілами, та професійного підходу до побудови процесів всередині команди хвилюють лідів усіх напрямків. Нещодавно на мітапі у 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 в командах.