Десяток стейкхолдерів, у кожного свої вимоги й жодного чіткого «ок, робимо так». Для project-менеджера узгодити все з усіма виглядає як пройти тест на стресостійкість. Для одного стейкхолдера щось критично, інший каже «це не потрібно», третій мовчить тижнями, а потім повертається з фразою: «Я щойно подивився — мені не подобається». Що саме не подобається — питання відкрите. З таких ситуацій народжуються жарти: «Як заапрувити ідею з 10 стейкхолдерами? Просто не показувати їм цю ідею».
В цій статті ми з Head of Project Management and Delivery Олексієм Лещинським розібрались, як все-таки узгоджувати ідеї/вимоги/будь-що з різними стейкхолдерами — особливо коли їх дуже багато.
Скоро в Олексія стартує курс «Проджект-менеджмент PRO» в Laba.
Масштабний проєкт і багато стейкхолдерів: з чого почати PMʼу?
Найважливіше — домовлятися на старті:
— як ухвалюються рішення
— хто їх погоджує
— які є механізми ескалації (що ми робимо, коли домовитися не виходить? Хто підключається, якщо стейкхолдери не можуть дійти згоди? Скільки часу команда намагається закрити питання самостійно, перш ніж підіймати його на рівень вище?)
В корпоративному середовищі завжди є хтось, хто має достатній рівень повноважень, щоб ухвалити остаточне рішення. Якщо не домовились на одному рівні — є ескалація: рівень вище, ще вище, аж поки не буде відповіді.
Ще на етапі ініціації проєкту треба зрозуміти, для чого він створюється і кому він потрібен. Саме з цими стейкхолдерами працюйте першочергово та фіксуйте домовленості щодо ключових вимог.
Усі зацікавлені сторони прагнуть, щоб реалізували саме їхні очікування, але між ними часто виникають конфлікти. Якщо ці деталі не зафіксувати «на березі», далі буде складніше.
Як класифікувати стейкхолдерів у великих проєктах?
Модель з концентричними колами добре працює як відправна точка: вона допоможе швидко зрозуміти, хто найближче до проєкту, а хто — в ширшому полі впливу, та обрати стиль комунікації
Але пам’ятайте, що це не класифікація «раз і назавжди» і точно не організаційна схема. Це радше карта місцевості, яка дозволяє зорієнтуватися перед тим, як переходити до детальної роботи зі стейкхолдерами.
Коли є базове розуміння екосистеми, наступний крок — класифікувати стейкхолдерів за впливом і зацікавленістю, а не за посадою або рівнем у структурі. Саме тут з’являються моделі Power-Interest / Power-Influence, де Power — це те, наскільки ця людина може вплинути на рішення, пріоритети або зупинити проєкт, а Interest/Influence — зацікавленість або залученість. Вони дозволяють зробити сегментацію стейкхолдерів та визначити, як взаємодіяти з кожним із них:
🤝 активно працювати (manage closely)
😃 тримати задоволеними
🔍 моніторити
📣 або інформувати
Але для масштабних і складних проєктів цього може бути недостатньо. Тому на практиці використовують Stakeholder Engagement Assessment Matrix (матриця оцінки залучення стейкхолдерів). Вона дозволяє подивитися не лише на вплив стейкхолдера, але й на його поточне ставлення до ініціативи.
Тут важливо зафіксувати Current State (поточна реальність) і чесно відповісти собі, до якого Desired State (бажаний стан) ми хочемо прийти. Цінність цієї матриці — не в таблиці як такій, а в усвідомленні: з ким потрібно почати працювати вже зараз, щоб не отримати ескалацію тоді, коли часу вже не буде.
Далі розробляються конкретні кроки й стратегії, щоби перевести стейкхолдера до бажаного стану: наприклад, від нейтрального до підтримувального, або від «резистента» до «нейтрального».
На цьому ж рівні можна використовувати RACI-матрицю:
✅ R — Responsible (Відповідальний). Людина або команда, яка безпосередньо виконує завдання. Наприклад, розробник, який реалізує фічу, або дизайнер, що готує макет.
🏆 A — Accountable (Відповідальний за результат / затверджує). Людина, яка несе фінальну відповідальність за виконання завдання та його якість. Саме вона підписує або затверджує результат. У команді має бути лише один Accountable на завдання, щоб уникнути плутанини.
💬 C — Consulted (Консультований). Люди або команди, в яких запитують думку чи експертну інформацію. Це двостороння комунікація: їхню думку враховують, але рішення ухвалює Accountable.
📢 I — Informed (Інформований). Ті, кого потрібно тримати в курсі, але від них не вимагається активна участь або погодження. Наприклад, менеджер суміжного відділу, який хоче отримувати оновлення про прогрес.
Якщо попередні інструменти відповідають на запитання «з ким та як працювати?», RACI допомагає чітко зафіксувати «хто за що відповідає». В масштабних проєктах це зменшує кількість конфліктів та прибирає «сірі зони», де відповідальність розмита між кількома ролями. В підсумку ці підходи працюють разом: від загальної карти стейкхолдерів — до конкретних дій та рішень у щоденній роботі.
Як PMʼу працювати зі складним фідбеком стейкхолдерів (коли на проєкті їх 10)?
Дуже типова ситуація: стейкхолдер каже «мені не ок», але не формулює критерії, не дає альтернатив і блокує подальші дії. За фразою «мені не ок» може ховатися страх репутаційних ризиків, боротьба за вплив або небажання брати відповідальність.
У таких випадках я не намагаюсь переконати або, ще гірше, «продавити» узгодження. Мій підхід — перевести емоцію в параметри та зрозуміти реальні причини такого ставлення. Комунікувати напряму, особливо наживо, коли можливо. Використовувати активне слухання та оцінювати невербальні сигнали. Ставити запитання, виявляти приховані мотиви. Що можна запитати в стейкхолдера:
— Які ризики ви в цьому бачите?
— Що саме викликає сумнів?
— Який сценарій для вас неприйнятний і чому?
— За яких умов це стало б ок?
— Це про зміст рішення чи про наслідки для вас? (Це запитання можна ставити не всім і не завжди 🙂 Кому не варто: в кого роль не передбачає оцінку наслідків, а тільки зміст — до прикладу, технічний експерт, який фокусується на реалізації конкретного завдання. Також не варто тим, хто не ухвалює рішень і не несе відповідальності за наслідки).
Що ще допомагає перевести «мені не подобається» в конкретні вимоги:
#1. Обмежувальні запитання. Що в цьому рішенні точно неприйнятно для вас? Що ми точно не маємо робити, навіть якщо це виглядає логічно з нашого боку? Який сценарій ви вважаєте найгіршим і чого нам варто уникнути за будь-яку ціну? Якщо подивитись від зворотного: що точно не має бути результатом цього рішення?
#2. Альтернативи (2–3 варіанти). Особливо це рятує в дизайні — зоні суб’єктивності, де часто звучать формулювання на кшталт «це не відображає наш бренд».
Іноді в команді з’являється думка: «Може, просто зробимо і покажемо результат?» Це може спрацювати, коли ризик обмежений, рішення легко відкотити, а очікування зафіксовані, навіть якщо точних вимог ще немає.
Але він перетворюється на токсичний, коли обходить відповідальних, створює репутаційні або інші неприємності, веде до перевитрат часу чи бюджету і підриває довіру в команді. Треба розпізнавати ці межі та ухвалювати рішення так, щоб одночасно зберегти й безпеку, і ефективність проєкту.
Коли все high priority: як PM наводити порядок у пріоритетах?
У великих проєктах майже завжди звучить: «у нас усе high priority». Для мене це означає одне — пріоритетів немає. Тому далі про системний підхід:
📌 Прив’язка до бізнес-цілей. Якщо вимогу неможливо чітко прив’язати до бізнес-результату — це не high priority. Що саме зміниться для бізнесу, якщо ця вимога буде реалізована?
Наприклад, компанія запускає новий модуль у CRM. Одна фіча пропонує змінити колір кнопок у формі — вона приваблива, але не впливає на продажі або швидкість обробки лідів. Інша фіча автоматично вивантажує дані для звітності фінансового відділу — вона скорочує час обробки та зменшує ризик помилок. Перша фіча — nice-to-have, друга — high priority.
⏰ Реальні дедлайни (time-box). Потрібно відрізняти бажані дати від тих, які неможливо посунути. Регуляторні вимоги (нові правила, нова валюта, новий план рахунків), фінансові обмеження (бюджет є тільки цього року), календарні події (запуск до «чорної п’ятниці») — це не питання домовленостей. Якщо проєкт не встигне до такої дати, він буде завершений лише формально, але вже не матиме бізнес-цінності. Саме ці дедлайни часто знімають суперечки в стилі «нам важливо все».
🔗 Залежності. Якщо одна вимога тягне за собою іншу, це швидко проявляється в класичних зв’язках start-start, start-finish. Наприклад, фронтенд може початися лише після того, як зафіксований бекенд-контракт, а тестування — паралельно з розробкою, але тільки після першої стабільної версії.
🎯Must have, Should have, Could have, Won't have. Відкидаємо емоції та визначаємо пріоритети за реальною цінністю для бізнесу.
— Must have — обов’язково, без цього проєкт не працює.
— Should have — важливо, але не критично.
— Could have — добре буде мати, якщо дозволяє час і ресурси.
— Won't have — взагалі не потрібно робити зараз.
Цей підхід чудово поєднується з гнучкими agile- і продуктовими підходами: замість будувати великий моноліт, рухаємося ітеративно — proof of concept → MVP → релізи → поступове нарощування функціонала.
Бізнес-стейкхолдери зазвичай підтримують такий підхід. Разом із продакт-менеджером можна визначити, що піде в перший реліз, що в другий, а що в третій.
Бажаєте отримувати дайджест статей?
