Не можна просто взяти та домовитись, або Історії про складних людей

21 квітня
Еліна Азадова, QA Lead у DataArt
Не можна просто взяти та домовитись, або Історії про складних людей
Я 12 років працюю в IT, понад 8 із них — тестувальником. Координую спільноту QA talk Kherson та проводжу лекції у QA School у Херсоні і Софії. Цю статтю я присвятила роботі з людьми. Всі ми різні, кожен зі своїм настроєм, бажаннями, цілями та характером. Зібрати ідеальну команду для конкретного проекту — велике щастя і велика рідкість. Зазвичай щось обов'язково піде не так.

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

Тотальний контроль

Я потрапляю до нового проекту як QA Lead. Стандартна команда: ВА, QA, команда розробки з девлідом. Все б нічого, але, як виявилось, практично кожна дія у проекті обговорювалась і виконувалась лише зі схвалення девліда, якого для зручності ми назвемо, припустимо, Петровичем. Він же виконував роль проджект-менеджера, безпосередньо спілкуючись із клієнтом.

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

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

Після новорічних свят Петрович вирішив взяти відпустку на... місяць. Клієнт був проти, відпускати ключового фахівця так надовго він зовсім не хотів. Ми хвилювались, як бути далі, хто ухвалюватиме рішення, адже були явні ризики, якщо надовго залишити команду працювати самостійно. З іншого боку, всі чудово розуміли, що потрібно спробувати розірвати складений зв'язок. Це могло вивести команду на більш незалежний рівень та убезпечити нас від ефекту вантажівки. Відпустка Петровича опинилася чудовою нагодою спробувати, до того ж переконати девліда скоротити терміни не вдалося (чи то це було неможливо, чи то інші учасники погано старалися).

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

Було непросто, але ми впоралися. Минув місяць, і ми зрозуміли, що цілком можемо працювати самостійно. Того дня, коли наш Петрович мав вийти з відпустки, нам повідомили, що в наш проект він не повернеться. Без деталей. Хто насправді виступив ініціатором і чому все сталося так швидко, нам залишилося лише здогадуватись.

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

Досвід, який ми винесли:

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

Негативний настрій

Цей випадок стався в іншому проекті, де в нас було декілька невеликих команд і кожна займалась окремим компонентом єдиної системи. Я була QA-лідом однієї з команд.

Звісно, нашою кінцевою метою було зібрати проект разом та забезпечити спільну працездатність компонентів, а не лише окремо. Однак, на жаль, не всі колеги були здатні зазирнути далі задачі, поставленої безпосередньо перед ними. У великих системах такі ризики вимагають особливої ​​уваги: ​​здається, всі працюють, як треба, кожна частина відповідає заявленим вимогам, але система чомусь не злітає.

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

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

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

Досвід, який ми винесли:

  • Емоції (як позитивні, так і негативні) будь-якого члена команди, а тим більше керівника, сильно впливають на всю команду.
  • Люди рано чи пізно дізнаються про те, що ви про них говорите чи говорили.
  • У більшості випадків потрібно просто краще пізнати людину та її мотиви. Можливо, ви маєте спільні проблеми і разом швидше знайдете рішення. Або просто допоможете один одному.
  • Потрібно підтримувати один одного. Багато хто не любить жалість, а ось підтримка однодумців завжди додає сил.

Проблема онлайн-комунікації

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

Уявіть звичайний командний стендап. Ми говоримо про статус задач і поточні проблеми — стандартна ситуація. Черга доходить до Васі, і той, почувши своє ім'я, починає розповідати, як все погано, оскільки в додатку є блокер. Який ми до того докладно обговорили.

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

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

Так, іноді потягом дня прилітає багато листів. Зараз на мою основну адресу приходить по 500 листів на день, не всі вони адресовані особисто мені, але сортувати їх необхідно.

Досвід, який ми винесли:

  • Людям важливий фідбек про роботу. Деякі речі здаються очевидними лише з боку. Фідбек — це окрема розмова, але дозволю собі додати кілька рекомендацій. Продумайте заздалегідь, про що ви будете говорити та як донесете інформацію. Люди по-різному реагують на критику, але в більшості випадків потрібно готуватися до захисної реакції.
  • Негативний фідбек потрібно повідомляти особисто. Ніколи не виносьте його на загальні зідзвони, поважайте своїх колег.
  • Лаяти або хвалити потрібно тільки на підставі фактів. Будь-який висновок потрібно обґрунтувати чіткими прикладами того, що зробила чи не зробила людина. Намагайтеся уникати оціночних суджень.
  • Іноді доводиться пояснювати колегам, як важливо звертати увагу на те, чим живе команда та розробка в принципі.
  • Фільтрація пошти — річ корисна. Не всі повідомлення однаково важливі: до поштової скриньки приходять потоки повідомлень Jira або просто листи FYI, які необов'язково читати негайно.
  • Якщо ви хочете, щоб на ваш лист обов'язково звернули увагу, не потрібно соромитися сказати про це на загальному зідзвоні, в особистому дзвінку або написати в месенджері, яким зазвичай користується ваш колега. Знайдіть точку комунікації, на яку реагує той, хто вам зараз потрібен.

І на останок

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

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    19 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    18 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    10 вересня