Пропустити навігацію EPAM

Управління учасниками проєкту (стейкхолдерами) під час фази Discovery. Карти впливу.

Лайфхаки
  • Design
  • Project Management
  • Delivery Management

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

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

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

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

Перший випадок — новачок.

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

Організуйте зустріч із цим спеціалістом та проведіть невеличку підготовку. Вам знадобиться створити дошку для спільного користування, де Y відповідатиме за рівень впливу, а Х — за зацікавленість. 

Ділимо дошку на чотири блоки: моніторинг, інформування, задоволення та активна взаємодія.

Високий вплив / високий інтерес — це ваші найважливіші учасники, яких варто повідомляти про всі зміни та активно залучати в процес.

Високий вплив / низький інтерес — цих учасників треба тримати в курсі, бо, можливо, вони захочуть внести зміни.

Низький вплив / високий інтерес — тримайте цих людей в курсі оновлень, вони завжди готові допомогти, якщо потрібно.

Низький вплив / низький інтерес — зазвичай, вам не потрібно повідомляти їх про зміни, але, наприклад, під час тестування оновлень вони можуть бути корисними.

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

Другий випадок — нинішній учасник проєкту.

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

Після створення карти, затвердіть її у вашого менеджера, оскільки вона може бути суб'єктивною та підходити лише для вашого відділу. Однак об’єктивна ситуація може трошки відрізнятися. Відповідно, загальні рішення приймаються по-іншому. Таку карту слід зберігати в спільній базі знань або базі знань вашого відділу, наприклад, у Confluence.

Також часто можна зустріти просто таблиці з інформацією про проєкт та описом певних ролей. Чи варто робити таку карту у цьому випадку? Тут все дуже суб'єктивно і залежить від обставин. Іноді буде легше додати обов'язки до наявної таблиці та вирішити, які питання ставити цьому спеціалісту. Але якщо їх багато або обов'язки перекриваються, то це картографування буде відмінним доповненням.

Спростіть собі життя

Щоб виконувати роботу на високому рівні та відповідати вимогам клієнта, важливо мати чітку картину всіх елементів взаємодії. Люди, їх обов‘язки та робочі групи — це ключова частина цього процесу. Тож, створення карт впливу може спростити та прискорити процес комунікації та прийняття рішень. А також дозволить уникати відволікання учасників питаннями, які не стосуються їхньої роботи, та спростить вашу роботу в цілому. Таким чином, інвестиції вашого часу та ваші зусилля можуть позитивно позначитися на робочому процесі та, безумовно, виправдаються.

Першоджерело: Platea Design Community.

Підписатися на новини

Чудово! Ми вже готуємо добірку актуальних новин для вас :)

Вибачте, щось пішло не так. Будь ласка, спробуйте ще раз.

* Обов'язкові поля

*Будь ласка, заповніть обов’язкові поля

Вакансії EPAM Ukraine у Київ | Львів | Харків | Дніпро | Вінниця | Івано-Франківськ | Одеса | Чернівці | Хмельницький | Рівне | Ужгород | Тернопіль | Луцьк за напрямком Java | JavaScript | .NET | DevOps | Experience Design | Software Testing | Business Analysis | Python| Big Data | Mobile | Solution Architect | Ruby on Rails у містах за напрямком Java вакансії Київ | Java вакансії Харків | Java вакансії Львів | Java вакансії Вінниця | Java вакансії Одеса | Java вакансії Івано-Франківськ | Java вакансії Чернівці | Java вакансії Хмельницький | Java вакансії Рівне | Java вакансії Ужгород | Java вакансії Тернопіль | Java вакансії Луцьк | JavaScript вакансії Київ | JavaScript вакансії Харків | JavaScript вакансії Львів | JavaScript вакансії Вінниця | JavaScript вакансії Одеса | JavaScript вакансії Івано-Франківськ | JavaScript вакансії Чернівці | JavaScript вакансії Хмельницький | JavaScript вакансії Рівне | JavaScript вакансії Ужгород | JavaScript вакансії Тернопіль | JavaScript вакансії Луцьк | DevOps вакансії Київ | DevOps вакансії Харків | DevOps вакансії Львів | DevOps вакансії Вінниця | DevOps вакансії Одеса | DevOps вакансії Івано-Франківськ | DevOps вакансії Чернівці | DevOps вакансії Хмельницький | DevOps вакансії Рівне | DevOps вакансії Ужгород | DevOps вакансії Тернопіль | DevOps вакансії Луцьк