Як отримати вимоги до проекту від зацікавлених сторін

Вступ

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

Історії користувачів часто формуються навколо ролі запитувача, того, що вони хочуть і чому вони цього хочуть.

Designmodo

Історії користувачів

Незалежно від того, чи створюєте ви щось абсолютно нове, чи оновлюєте існуючу програму, перший раунд вимог завжди повинен бути врахований історіями користувачів. Незалежно від того, чи ці історії надходять від кінцевих користувачів чи зацікавлених сторін, ви можете зібрати їх у кого завгодно. Мета - охопити їхні очікування щодо того, що буде побудовано, та деталі, як вони хочуть, щоб це функціонувало. Існують різні формати для збору історій користувачів, але всі вони, як правило, охоплюють роль, пов’язану з запитувачем, що хоче ця людина і чому вона цього хоче. Ці історії потрібно буде докладати далі у процесі проектування.

Мозкові штурми

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

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

Альянс ПМ

Оглядові сесії

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

Що включити до щотижневого звіту про стан проекту

Діаграма процесу

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

Продовжуйте запитувати, чому

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