Як донести ключовий меседж, якщо він тоне між мемом у Slack і обговоренням піци? Що робити, коли всі начебто погоджуються зі словами PM, але фінальне рішення ухвалити не можуть? Як написати апдейт у два речення, якщо в голові тисяча й одна думка? Або як делікатно нагадати про задачу вчетверте, не виглядаючи при цьому як колектор?
Анастасія Горова, PMO Partner в Intellias, знає, як розв’язувати ці ситуації на практиці.
Що робити, коли всі «в принципі згодні» з рішенням, хоча фінально його так і не ухвалили?
Якщо дзвінок тривав годину, а люди розійшлися без жодного рішення — це ознака поганої фасилітації. Перш ніж організовувати зустріч, PM має чітко розуміти її мету: з чим конкретно він хоче вийти з цієї дискусії. Мій підхід завжди ґрунтується на чіткому плані, фіксації домовленостей і подальших кроках.
Крок 1. План зустрічі. Складаю список ключових питань, які мають бути розв’язані. Визначаю рішення, які обов’язково потрібно ухвалити. Це допомагає не збиватися з теми та фокусувати дискусію на результаті.
Крок 2. Під час зустрічі: фокус на результаті. Кожне питання обговорюється з метою конкретного рішення. Якщо виникають ризики або сумніви — одразу фіксую їх у нотатках, щоби повернутися до цього пізніше.
Крок 3. Комунікація підсумку. Наприкінці зустрічі завжди проговорюю вголос: що вирішено, а які моменти залишилися відкритими. Обов’язково уточнюю next steps: хто що робить і який дедлайн.
Крок 4. Підсумок для команди. Після зустрічі надсилаю всім учасникам короткий підсумок з ухваленими рішеннями, зафіксованими ризиками, а також відкриті питання, конкретні дії та відповідальних.
Щоб уникнути повторних зустрічей та нескінченних переписок, використовую RAID-лог — стандартний інструмент проєктного управління:
Як написати повідомлення у 2 речення, якщо в голові багато думок?
У мене колись був підлеглий PM — розумний, класний спеціаліст. Але, намагаючись донести важливу інформацію, він писав керівництву клієнта цілі лонгріди. І люди йому часто просто не відповідали — бо часу читати, розуміти й перетравлювати довгі тексти ні в кого немає.
Тому вміння сформулювати коротко — що потрібно зробити, коли та чому це важливо — це окремий важливий скіл. У цьому допомагає принцип піраміди Мінто: спочатку головне — потім усе інше. Як це виглядає на практиці:
Наприклад:
❌ «Ми обговорювали задачу, там є кілька варіантів, і ще є залежність від команди Х…»
✅ «Потрібно обрати варіант А до п’ятниці, щоб не зсунути реліз. Деталі — нижче».
Хто хоче — дочитає повідомлення до кінця, а не по діагоналі, але навіть швидке сканування вже має давати розуміння суті.
Також для скорочення думки можна використовувати AI, навіть безплатну версію ChatGPT. Промпт може виглядати так:
«Скороти до 1–2 речень текст. Постав головне на початок. Додай заклик до дії. Аргументацію та несуттєві деталі — окремим абзацом після решти тексту». Або просто: «Структуруй за принципом піраміди Мінто».
Чітко сформульований запит у 5–7 слів підвищує шанс отримати відповідь вчасно приблизно на 80%.
Як нагадати про задачу вчетверте, але не звучати як колектор?
Якщо це внутрішня команда — PM тут лідер, стосунки неформальні, і надсилати запит навіть 30 разів — цілком нормально. Складніше, коли справа стосується топменеджменту або клієнта.
Проте навіть у таких випадках я раджу не боятися здатись нав’язливим. У мене навіть є керівник на рівні senior leadership, яка сама каже: «Якщо вам щось потрібно — діставайте мене хоч з-під землі». Краще здатися колектором і досягти результату, ніж бути занадто ввічливим і завалити проєкт.
Як формулювати нагадування ефективно:
#1. Говоріть мовою клієнта або команди.
❌ Не «Нам потрібне ваше рішення, бо інакше ми не зможемо…»
✅ А «Якщо це рішення не буде прийнято, ви не отримаєте те, що вам потрібно».
Людина реагує на свої проблеми, а не на чужі.
#2. Завжди конкретика: що саме потрібно зробити, до якого часу, що станеться, якщо це не відбудеться. Що абстрактніший запит, то легше його ігнорувати — аж до моменту ескалації.
#3. Комунікуйте без паніки, але чітко: дедлайн, наслідки, конкретні дії — все в одному повідомленні. Завдання PM — не доводити до пожежі, а передбачливо формулювати чіткий запит.
Це не гарантує 100% відповіді, якщо людина свідомо уникає контакту. Але принаймні ви зробите все зі свого боку, щоб знизити ризики зриву завдання.
Як сказати «ми не встигаємо» так, щоб це не звучало як катастрофа?
Коли приходите до клієнта з поганою новиною, будьте максимально обʼєктивними та безпристрасними. Жодної паніки або довгих вибачень — просто констатуєте факт:
— що саме не встигаєте
— на скільки затримка
— що це означає в перспективі
Наступний крок — план. Не зупиняйтеся на проблемі. Одразу показуйте, що вже зроблено, що відбувається зараз і що ще потребує рішення.
Додайте рекомендацію. Не обмежуйтесь варіантами «А» і «Б». Скажіть: «Ми розглянули обидва варіанти й рекомендуємо ось це, ось чому». Це показує, що ви не просто повідомили про проблему, а вже думали, як її розв’язати.
Загалом це правильна механіка стосунків зі стейкхолдером, не лише в ситуаціях, коли не встигаєте в попередньо обговорені дедлайни. Коли ви даєте вибір — залучаєте стейкхолдера до рішення. Він стає співучасником, а не постраждалим. І тоді він сам уже думає «як нам разом із цим впоратись».
Що робити, коли людина погоджується на словах, але саботує на ділі?
Саботаж зазвичай відбувається з трьох причин:
Перший крок — розмова сам на сам. При цьому важливо йти на зустріч без тиску й без позиції «тобі треба зробити, і це не обговорюється». Дозвольте людині самостійно проговорити, що їй потрібно зробити та як вона це бачить.
Другий крок — конкретика й фіксація. Зафіксуйте факт: домовились про це — і разом визначте, що людина бере в роботу й до якого часу.
Третій крок — публічне зобов’язання. Коли людина сама артикулює, що має зробити, особливо при інших, це значно підвищує ймовірність того, що дедлайн буде дотриманий. Небажання підвести людей і страх публічного провалу вшито в нас і часто працює як важіль.
Як комунікувати ризики так, щоб вас почули до того, як вони стануть проблемами?
Що конкретніше сформульований ризик, то вищі шанси, що вас почують до того, як він перетвориться на пожежу. Наприклад, «Якщо клієнт не дасть дозволу, ми можемо не встигнути доробити фічу в строк» — це не ризик. Людина читає і не розуміє, що саме станеться, коли та як потрібно реагувати.
Базова формула для комунікації ризиків:
✅ Наприклад: якщо погодження від вендора затримується пізніше за 10 березня → тестування опиняється під загрозою → це призведе до затримки наступного релізу.
Далі потрібно розробити action plan. Не просто повідомити про ризик, а запропонувати варіанти розв’язання. Адже рішення має приносити той, хто приносить ризик, а не чекати, що керівництво вигадає вихід.
Що робити, коли люди читають повідомлення, але не відповідають?
Навіть коли ви надсилаєте чіткий лаконічний запит, що не потребує роздумів, а лише «так/ні» або «варіант А / варіант Б», — повідомлення все одно можуть годинами висіти без відповіді в корпоративному чаті. Пінгування колег не допомагає, особисті звернення ігноруються — і тоді потрібно діяти інакше.
— Зайти через іншу людину. Не через прямого керівника, а через того, хто має з цим колегою регулярний робочий контакт і може м’яко підсвітити ваш запит.
— Вибір часу повідомлень. Плануйте пінги заздалегідь — наприклад, на 9 ранку, щоб це було першим, що людина побачить, коли відкриє корпоративний месенджер або почне перевіряти пошту.
— Проговорюйте правила комунікації в команді. Важливо не лише домовитися про комфортний формат взаємодії, але й окремо визначити винятки: коли позаплановий контакт припустимий, а коли — ні. Наприклад, у моїй команді дзвінки у вихідні не є нормальною практикою. Але ми заздалегідь узгодили, що в критичних ситуаціях такий контакт можливий.
Як написати статус за проєктом так, щоб його прочитали, а не просто поставили «лайк»?
Якщо вам поставили емоджі — це вже непогано. Бо дуже часто статуси проєкту не читають взагалі. І причина в тому, що статус фокусується не на речах, важливих саме для цих людей, є занадто низькорівневим або просто розмитим і без конкретики.
Моє правило — зменшувати відстань між людиною та інформацією. Навіть якщо статус оформлений як окремий звіт або презентація, я не змушую людину самостійно шукати в ньому суть. На початку я даю стислий статус із найважливішою інформацією: поточний стан, ключові зміни, ризики, критичні моменти й те, яка дія або рішення потрібні далі. Цю ж думку дублюю в листі або повідомленні, а в сам звіт уже йдуть по деталях.
Людина не має відкривати три лінки або переходити до вкладень у листі, щоб зрозуміти, чого від неї хочуть. Це як заголовок у новині: відкрив — і вже все зрозуміло. Хочеш більше — читаєш далі.
Як відмовити клієнту або стейкхолдеру, щоб не зіпсувати відносини?
В ІТ (і не тільки) дуже часто стаються ситуації, коли потрібно сказати «ні». Клієнт просить функціональність поза межами домовленого обсягу робіт, стейкхолдер — скоротити строки або взяти в роботу те, на що немає ресурсу. І кожен такий момент — точка відліку, яка може вплинути на подальшу взаємодію. Невдале формулювання — і замість партнерства ви отримуєте недовіру або пасивну агресію. Тому важливо прокачувати вміння правильно відмовляти.
В Україні часто комунікація дуже прямолінійна: «ні, це проблема», «ні, так не можна». Для частини культур — наприклад, у Східній Європі або Німеччині, де цінується прямота й конкретика без завуальовувань, — це нормально. А ось для британців або американців це звучить різко й часто сприймається як небажання допомогти.
Краще працює інший підхід — спочатку важливо показати, що ви справді почули запит і розумієте, чому це важливо для людини. Далі — окреслити ризики або обмеження, які не дозволяють просто сказати «так».
Після цього варто взяти невелику паузу на аналіз та одразу позначити дедлайн, коли ви повернетеся з відповіддю. Це створює відчуття контролю та знімає напругу. А вже потім давати відповідь.
Є два робочих сценарії: ви або пропонуєте компромісний варіант, або даєте аргументоване «ні», пояснюючи, чому саме та які є альтернативи. Людина значно легше приймає відмову, коли бачить, що ви не відмахнулись, а справді намагалися знайти рішення.
Окрема складність тут у тому, що одні й ті самі слова можуть сприйматися дуже по-різному. Американці, наприклад, рідко критикують прямо — багато що доводиться зчитувати між рядків. Британці можуть ще більш завуальовано дати зрозуміти, що щось не так. І для джунів це часто пастка: здається, що «все ок», поки раптом не виявляється, що зовсім не ок.
Що почитати:
«Культурна карта. Бар’єри міжкультурного спілкування в бізнесі», Ерін Меєр
Global Dexterity: How to Adapt Your Behavior Across Cultures without Losing Yourself in the Process, Andy Molinsky
The Pyramid Principle, Barbara Minto
«Важкі діалоги. Що і як говорити, коли ставки високі», Керрі Паттерсон
