Консультант і автор Тім Лістер визначає успіх проєкту як “виконання всіх вимог і обмежень, які очікують стейкхолдери”. Кожна команда, розробляючи програмне забезпечення чи інший продукт, повинна визначити своїх стейкхолдерів і взаємодіяти з ними, щоб зрозуміти вимоги та обмеження, а також їхні пріоритети та інші занепокоєння.
Хто такі стейкхолдери?
Стейкхолдер або зацікавлена сторона (англ. stakeholder) – це будь-яка особа чи група, яка активно залучена до проєкту, на яку впливає проєкт або яка може впливати на напрямок проєкту. Взаємодія між стейкхолдерами та проєктом може бути різноманітною. Деякі стейкхолдери просто отримують результати проєкту як даність. Інші глибоко формують вимоги, а є й ті , хто може змінити або навіть зупинити проєкт.
Стейкхолдери можуть бути внутрішніми для команди проєкту, належати до організації-розробника або бути зовнішніми для організації. На Рисунку 1 показано деякі типові спільноти стейкхолдерів, які повинні враховувати більшість команд розробників програмного забезпечення. Можуть бути й інші, залежно від категорії продукту: корпоративна інформаційна система, комерційний програмний додаток, урядова система або фізичний продукт, що містить вбудоване програмне забезпечення.
Рисунок 1. Різні стейкхолдери висувають вимоги, які проєкт повинен задовольнити, та обмеження, яких він повинен дотримуватися.
-
Supporters – підтримувачі (особи чи організації, які підтримують проєкт або ініціативу).
-
Maintainers – утримувачі або зберігачі (особи або групи, що відповідають за забезпечення сталого функціонування чи управління в рамках проєкту чи бізнес-процесу).
-
Regulators встановлюють правила і норми для регулювання.
-
Certifiers визначають, чи відповідають продукти чи послуги цим встановленим стандартам.
Ці ролі є важливими в бізнес-середовищі для забезпечення відповідності і сталого функціонування в рамках правових і комерційних вимог.
Ідентифікація та аналіз стейкхолдерів
Команда повинна з самого початку широко охопити ідентифікацію потенційних груп стейкхолдерів. Не дивуйтеся, якщо ви створите страхітливо довгий список. Потрібно докладати зусиль для ідентифікації та розуміння ваших стейкхолдерів. Однак це краще, ніж пропустити важливу спільноту і потім робити корективи.
Кінцеві користувачі і потенційні клієнти є основними джерелами вимог до продукту. Клієнт, який вказує, вибирає або оплачує продукт, не завжди використовує його особисто і може мати неправильні уявлення про те, що потрібно спільноті користувачів для виконання їхніх завдань.
У багатьох продуктах є різноманітні кінцеві користувачі. Для спрощення дослідження вимог варто групувати користувачів за класами, які мають різні потреби. Користувачі можуть навіть не бути людьми, а пристроями або іншими програмними системами, що взаємодіють з вашим продуктом. Вам необхідно виявити осіб, які можуть представляти вимоги від імені таких нелюдських компонентів.
Зазвичай ми думаємо про прямих користувачів, які взаємодіятимуть із продуктом безпосердньо, але можуть бути і непрямі користувачі. Непрямі користувачі можуть надавати дані, які надходять в інформаційну систему, або вони можуть отримувати результати системи, навіть якщо вони самі не генерують ці результати. Я був залучений до корпоративної системи метрик, яка об’єднувала дані з десятків проєктів і генерувала щомісячні звіти, що розповсюджувалися серед багатьох менеджерів. Ці менеджери були непрямими користувачами — вони не взаємодіяли з метриками безпосередньо. Проте як аудиторія для звітів системи вони були основними стейкхолдерами.
Колега коротко описав непрямого користувача: «Ваш клієнт після закінчення проєкту залишається вашим клієнтом». Щоб ідентифікувати непрямих користувачів, вийдіть на один або два рівні за межі безпосереднього контексту програми, щоб побачити, які групи людей та інші системи потребують представлення.
Крім того, визначте несприятливі класи користувачів, яким ви не хочете використовувати систему, наприклад зловмисники, хакери та інші виробники зловмисного програмного забезпечення. Вони не є стейкхолдерами — вони не нададуть вимог чи обмежень, — але вам потрібно передбачити та перешкодити їхнім злим намірам.
Розгляньте наступні запитання щодо кожної визначеної групи стейкхолдерів. Ви можете знайти мій контрольний список запитань для визначення стейкхолдерів і контрольний список питань для характеристики стейкхолдерів як корисні нагадування, а також простий шаблон профілів стейкхолдерів як місце для запису відповідної інформації про стейкхолдерів.
Хто вони? Опишіть кожну групу стейкхолдерів, щоб усі учасники проєкту знали, хто вони такі. Описи стейкхолдерів потенційно можна повторно використовувати в кількох проєктах організації.
Наскільки вони зацікавлені? Подумайте про те, наскільки сильно результат проєкту вплине на групу та наскільки вони хочуть брати участь у проєкті. Вам потрібно буде дізнатися про очікування, інтереси, занепокоєння, обмеження та страхи кожної групи стейкхолдерів.
Який вплив вони мають на проєкт? Визначте, які рішення кожний стейкхолдер може приймати, а які ні. Які групи мають найбільшу владу над проєктом? Які їхні погляди та пріоритети? Вам особливо потрібно буде залучити ті групи, які мають високий інтерес до проєкту та високий ступінь контролю над ним.
З ким було б найкраще поговорити? Визначте відповідних представників кожної спільноти, з якими працюватимете. Вони мають бути джерелами остаточної інформації.
Де вони? Виявлення вимог (requirements elicitation)— це ітеративний процес, який потребує кількох зустрічей. Найлегше буде отримати інформацію від стейкхолдерів, якщо у вас є прямий доступ до окремих членів. Якщо ви цього не зробите, вам доведеться встановити механізми та протоколи міжміського зв’язку.
Що мені від них треба? Визначте інформацію, рішення та дані, які вам знадобляться від кожної групи. Це розуміння допоможе вам вибрати найкращі способи отримати цю інформацію в потрібний час. Що стосується класів користувачів, вам потрібно буде зрозуміти їхні вимоги до користувачів — те, що має дозволяти їм робити створене вами рішення (what the solution you’re building must let them do) — а також їхні очікування щодо якості (quality expectations). Деякі групи зацікавлених сторін будуть накладати обмеження, яких проектна команда повинна дотримуватися. Обмеження можуть охоплювати кілька категорій, включаючи такі:
-
Фінансові, часові та ресурсні обмеження
-
Діючі політики, регламенти, стандарти та інші бізнес-правила
-
Сумісність з іншими продуктами, системами або інтерфейсами
-
Юридичні або контрактні обмеження
-
Вимоги до сертифікації
Обмеження в можливостях продукту (тобто функціонал, який не буде включено)
Що їм потрібно від мене? Деяким зацікавленим сторонам потрібно просто бути поінформованими про значущі питання, які їх стосуються, тому вам потрібно дізнатися, яка інформація є актуальною для кожної групи. Інші можуть вимагати перегляду вимог, щоб переконатися, що вони відповідають відповідним політикам або обмеженням. Працюйте зі своїми зацікавленими сторонами, щоб зрозуміти, що вони очікують від вас, так само як ви спілкуєтеся з ними про свої очікування. Велика частина успішної співпраці полягає в тому, щоб будувати та підтримувати взаємну довіру через ефективне спілкування.
Як і коли мені з ними взаємодіяти? Як тільки ви зрозумієте, з якими представниками стейкхолдерів ви можете взаємодіяти, обдумайте найкращі способи співпраці з ними для обміну інформацією, необхідною вам обом. Якщо ви не можете отримати доступ до реальних представників певного класу користувачів, розгляньте можливість створення персонажів (personas), уявних людей, які будуть заміняти реальних людей.
Які стейкхолдери найважливіші при вирішенні конфліктів? При вирішенні конфліктуючих вимог і прийнятті пріоритетних рішень оцініть, який результат найбільше відповідає бізнес-цілям проекту. Певні класи користувачів можуть бути пріоритетними перед іншими, тому що задоволення їхніх потреб більше сприяє успіху бізнесу, ніж виконання вимог інших класів. Використовуйте ранній аналіз стейкхолдерів, щоб зрозуміти ці пріоритетні проблеми, замість того, щоб чекати, доки ви зіткнетеся зі своїм першочерговим конфліктом.
Ключем до успішної розробки програмного забезпечення є тісна постійна взаємодія з ключовими представниками користувачів. Після того, як ви визначили ваші важливі класи користувачів, вам потрібно знайти конкретних осіб, які зможуть достовірно представити потреби та інтереси кожного класу. Я називаю цих ключових представників користувачів чемпіонами продукту (product champions). Модель чемпіона продукту ефективно використовується в багатьох організаціях, щоб донести голос клієнта до вуха розробника.
Рішення, рішення та ще раз рішення
Визначення осіб, що приймають рішення, є ключовим елементом успішного проєкту. У деяких випадках це може бути одна особа, наприклад, спонсор проєкту або продакт овнер. Цей підхід є найбільш ефективним, за умови, що ця особа має необхідну інформацію для прийняття відповідних рішень і є доступною для швидкого прийняття їх, коли це необхідно. Частіше всього, необхідно визначити вірну групу осіб для прийняття кожної категорії рішень. Групове прийняття рішень займає більше часу, але краще відображає сукупний набір інтересів у досягненні цілей проєкту.
Особи, які відповідають за прийняття рішень, що охоплюють кілька стейкхолдерських спільнот, повинні базувати свої рішення на бізнес-цілях проекту. Ці цілі, візійна заява, обмеження проекту та інші бізнес-вимоги зазвичай фіксуються в візійному документі та обсягу проекту або у статуті проекту (templates available). Проєкт без чітких бізнес-вимог має мало підстав для прийняття — і обгрунтування — значущих рішень.
Кожна команда повинна визначити, хто буде приймати рішення з різних питань, найкраще перед тим, як вони стикаються з першим важливим рішенням. Визначення осіб, що приймають рішення, забезпечує можливість прийняття рішень на найнижчому рівні. Кожна група також повинна домовитися про те, як вони досягатимуть своїх висновків — яке правило або правила прийняття рішень вони застосовуватимуть (upon how they will reach their conclusions) — і про шлях вперед, якщо вони не зможуть вирішити питання.
Ми всі тут за одне
Це означає, що ми всі тут на одній стороні. Не завжди можливо задовільнити всіх стейкхолдерів результатами проєкту. Напруга між учасниками може перерости у конфліктну ситуацію, коли люди працюють на користь своїх інтересів. Розвиток співпраці зі стейкхолдерами є важливим кроком до досягнення успіху. Оскільки у майбутньому може знадобитися співпраця з тими самими людьми, бажанно з перших кроків встановити ефективні комунікаційні зв’язки і взаємну повагу.
Оригінальна стаття – Searching for Stakeholders: A Vital Key to Success, переклад – Галина Остапенко, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальне фото з статті.
Додаткові матеріали з книги Карла Вігерса та Кандас Хокансон:
