Уявіть типову ситуацію на проєкті: два сеньйори (назвемо їх Ігор та Петро) влаштували справжню «холодну війну» через вибір архітектурного підходу. Один категорично виступає за мікросервіси, інший захищає моноліт. Атмосфера в команді миттєво стає токсичною, загальний перформанс летить у прірву, а найближчий реліз опиняється під загрозою зриву.
Як зазвичай реагує Project Manager? Він намагається безпосередньо втрутитися, «помирити» хлопців і фактично виступає суддею в суто технічній суперечці — хоча сам код не пише. У результаті PM витрачає години на нескінченних мітингах і лише погіршує ситуацію, стаючи крайнім у цьому конфлікті.
Тут потрібна зміна парадигми: конфлікт — це не баг системи і не ознака того, що у вашому колективі все погано. Навпаки! Чим швидше розвивається компанія та команда, тим більше конфліктів буде виникати. Рух вперед — це завжди створення чогось нового, чого ще ніхто до вас не описував і не робив. У таких нових ситуаціях неминуче виникають різні погляди спеціалістів, а отже — емоційне та технічне тертя. Якщо ж конфліктів немає взагалі — швидше за все, ваша команда банально стагнує, а не перебуває в гармонії.
Масштаб проблеми ілюструє статистика. Згідно з CPP Global Human Capital Report, співробітники витрачають у середньому 2,8 години на тиждень на розв’язання конфліктів. Це еквівалентно сотням мільярдів доларів оплачених годин на рік (зокрема, у США цей показник сягає $359 млрд). Для PM-а неефективний менеджмент конфліктів — один із головних поглиначів часу. Тому головна думка така: спроба PM-а постійно працювати «вогнегасником» та вручну тушити кожне незадоволення — це гарантований шлях до вигорання. Потрібно не бігати з відром води, а вибудувати систему, яка навчить команду вирішувати ці суперечки самостійно.
Правило «батьків проєкту»: як PM і тімлід ділять зони впливу
PM і тімлід — це не «контролер та виконавець», а повноцінні партнери (своєрідні «батьки проєкту»). Для успішної взаємодії вони мають чітко розподілити території.
Business Zone (зона PM-а): PM відповідає за те, ЩО ми робимо і КОЛИ — пріоритети бізнесу, дедлайни, бюджети.
Tech Zone (зона тімліда): тімлід відповідає за те, ЯК ми це робимо і з якою ЯКІСТЮ — архітектура, код, внутрішні процеси команди.
Головне правило цього тандему: сперечатися можна скільки завгодно за зачиненими дверима. Але перед командою та замовником PM і тімлід завжди демонструють єдину позицію. Якщо команда бачить, що «батьки» говорять різне — делівері проєкту моментально паралізується.
А як бути з конфліктом пріоритетів, коли бізнес вимагає фічі, а команда — час на техборг? Це абсолютно конструктивний конфлікт, а не бійка. Тімлід не має права ставити ультиматуми бізнесу (на кшталт «погоджуся, тільки якщо…» або «ми так робити не будемо»). Він повинен перекласти проблему техборгу мовою бізнесу: показати гроші, ризики, час завантаження системи або ймовірність падіння. Якщо лід переконав — PM захищає цей час перед клієнтом; якщо ні — тімлід поступається.
Від рефері до тренера: зброя, яку PM має передати тімліду
Задача тімліда (із подачі PM) — не загасити конкретну суперечку власноруч, а навчити команду вирішувати конфлікти самостійно. PM не повинен втручатися напряму, а має підштовхнути ліда діяти як тренер.
Ось у чому різниця концепцій:
- Рефері: вирішує проблему за команду → команда залишається слабкою та інфантильною.
- Тренер: дає інструменти та вчить команду домовлятися → команда стає автономною та сильною.
Згідно з концепцією Social Deskilling Шеррі Теркл, сучасні люди втрачають навичку розмовляти віч-на-віч та вирішувати тертя без посередників. Щоб виправити це, озбройте ліда трьома інструментами.
Інструмент 1. Позиції vs інтереси (як копати глибше)
Позиції (те, що говорять): «Я хочу моноліт!» vs «Я хочу мікросервіси!» — на цьому рівні примирити сторони неможливо.
Інтереси (чого насправді бояться/хочуть): «Я боюся, що ми не впораємося зі складністю» vs «Я боюся, що ми будемо повільно релізити». З глибинними інтересами вже можна працювати і шукати компромісне рішення.
Інструмент 2. Модель Томаса-Кілмана (TKI) в IT-координатах
Це стандартна науково обґрунтована сітка оцінки конфліктної поведінки за двома шкалами: напористість (assertiveness) та співпраця (cooperativeness). Ось як пояснити 5 стилів реакції через призму розробки:
- Акула (конкуренція): корисно, коли горить прод і немає часу на дискусії — треба жорстке авторитарне рішення.
- Ведмедик (пристосування): корисно, коли розробник зрозумів, що його ідея помилкова, або коли питання архітектури критичніше для колеги, ніж для нього.
- Черепаха (уникнення): коли емоції палають — беремо таймаут на 1-2 години, щоб охолонути й не наламати дров.
- Лисиця (компроміс): швидке рішення «ти мені — я тобі», коли повна перемога обох сторін неможлива через брак часу.
- Сова (співпраця): довгий, дорогий, але найкращий win-win для стратегічних рішень.
Інструмент 3. Конструктивний фідбек: мова фактів замість ярликів
Конфлікт неможливо розібрати конструктивно, якщо сторони переходять на особистості, маніпулюють або використовують оціночні ярлики. Тімлід (та й сам PM) має спілкуватися виключно мовою сухих фактів, без моралізаторства чи спроб «вгадати мотиви» розробника.
Формула конструктивного зворотного зв’язку: Факт → Наслідок → Очікування (Fact → Consequence → Expectation).
Погано (як зазвичай кажуть): «Ти постійно токсичиш на Code Review та заважаєш команді працювати!» — це ярлик і напад, який викликає лише опір та закритість.
Добре за формулою (мова фактів): «Ти назвав архітектурний підхід колеги „дитячим садком“ у коментарях до пул-реквесту → через це розробник закрився, а команда втратила пів дня на суперечки в чаті → я очікую, що надалі вся критика буде конструктивною, без оціночних суджень і суто по суті коду».
Пастка «няньки» та тімліда, який «просто хоче кодити»
PM не повинен знати та розбирати проблеми кожного розробника окремо — це пряма робота тімліда. PM, який бере це на себе, підриває авторитет ліда та знищує власний час.
Реальний кейс: на одному з останніх виступів на PM Day до мене підійшла PM-ка й поділилася своїм «досягненням». Вона розповіла, що сама веде три команди (загалом близько 15 людей), з кожним розробником особисто проводить регулярні 1-on-1, вникає в усі міжособистісні суперечки та намагається тримати руку на пульсі абсолютно всього. Наслідки передбачувані: особистого життя немає взагалі, робота перетворилася на пекло в режимі 24/7, а вигорання — питання найближчих місяців. Тим часом її три тімліди повністю усунулися від управління командою — вони просто пишуть код. Висновок: вона власноруч виростила пасивних лідів та прирекла себе на вигорання, замість того щоб делегувати внутрішній менеджмент за призначенням.
Тут яскраво проявляється проблема «тімліда-кодера»: часто розробника роблять тімлідом за технічну крутість, але він боїться людей, уникає конфліктів, ховається за код і каже: «Нехай PM з ними розбирається, я хочу просто писати код».
Рішення для PM-а — провести відверту розмову. Тімлід — це не просто Senior з преміальним тайтлом, а мультиплікатор команди. Його робота — люди, 1-on-1, атмосфера та вирішення внутрішніх тертів. Якщо він категорично не хоче цього робити — треба чесно перевести його на позицію Tech Lead або Architect (де він пише код), а на роль тімліда знайти того, хто готовий працювати з людьми.
Поки бізнес-школи пишуть про ідеальні команди, на практиці PM-и часто змушені працювати з технічно сильними спеціалістами, які абсолютно не вміють комунікувати, працювати в команді та екологічно вирішувати конфлікти. Якщо ваш тімлід — геніальний розробник, який ховається за код від будь-якої складної розмови, допоможіть йому вирости. Саме цьому присвячений мій авторський курс «Ефективний тім-лід» у FoxmindEd — 30 років в IT, з яких 15 тімлідом і 10 директором, тому там немає теорії заради теорії, тільки те, що реально працює.
Світ змінився: PM-у більше не потрібно бути «нянькою з батогом». Його головний важіль впливу на атмосферу в техкоманді — це здорове партнерство з тімлідом.