Методи збору вимог або «Як зрозуміти, що хоче замовник?»

Дана стаття буде корисна аналітикам, так і менеджерів, що займаються збором і аналізом вимог. У ній описано основні методики збору вимог, а також їх плюси і мінуси. Можливо, щось ви вже застосовували на практиці, а про щось, можливо, не знали. Загалом, ця стаття для всіх тих, хто вже займається бізнес — аналізом або тільки планує поповнити ряди аналітиків.

Збір вимог — це один з найбільш важливих етапів процесу створення будь-якої інформаційної системи, будь то десктопное, веб або мобільний додаток або ж просто доробка вже існуючого рішення. Перш, ніж почати збирати вимоги, необхідно виявити всіх зацікавлених осіб (стейкхолдерів), які будуть користуватися системою. Чим точніше буде цей список, тим повніше будуть вимоги. Отже, для початку, розглянемо хто ж такі стейкхолдери.

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

Існує безліч різних технік збору вимог, які допоможуть краще зрозуміти, що ж хоче замовник.
Розглянемо основні з них трохи докладніше:

Анкетування


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

Анкетування використовується для того, щоб підтвердити або деталізувати раніше відомі вимоги, вибрати параметри для рішень.

Найвідомішим прикладом анкетування може бути «Бриф на розробку сайту — анкета містить перелік основних вимог та інформацію про майбутнє сайті.

Переваги:

  1. Висока швидкість отримання результатів.
  2. Порівняно невеликі матеріальні витрати.
Недоліки:

  1. Даний метод не підходить для виявлення неявних вимог.
  2. При складанні опитувальника фізично неможливо врахувати всі необхідні питання.


Інтерв'ю


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

Даний спосіб застосовується, в основному, для отримання інформації з будь-якої конкретної теми і/або уточнення вимог.

Багатьом може здатися цей спосіб досить легким, але це не так. Провести гарне інтерв'ю досить складно. Ви повинні гнучко реагувати на реакцію інтерв'юйованого і в разі необхідності змінювати порядок заготовлених питань або їх формулювання. Не забудьте включити диктофон під час інтерв'ю або вести нотатки.

З плюсів:

  1. Можливість задавати питання в довільній послідовності.
  2. Можливість використовувати допоміжний матеріал.
  3. Аналіз невербальної реакції опитуваного людини, дозволить зробити додатковий висновок про достовірність його відповідей.
З мінусів:

  1. Інтерв'ю забирає досить багато часу і сил.
  2. Додатковою складністю є одержання однакових відповідей від інтерв'юйованого.


Автозапис


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

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

Прикладом такого методу може бути робота з концепцією або баченням проекту (сам Замовник любить називати це — «ТЗ»), яку він надіслав вам на момент початку робіт по аналітиці.

Перевага:

  • Допомагає краще зрозуміти складні процедури або процеси.
Недолік:

  • Даний метод сильно залежить від досвіду Замовника, а також від його вміння формулювати і висловлювати свої думки.


Вивчення існуючої документації
image

Дана методика може бути використана при наявності в організації документації, яка може допомогти у визначенні потреб Замовника. Приклади документації включають в себе: регламенти,
опису процесів, структура організації, специфікації продукту, різні процедури, стандарти та інструкції, шаблони документів і т. д.

Виявлені вимоги є основою для подальшого аналізу і повинні бути деталізовані.
Дана методика застосовується, наприклад, при автоматизації усталених в організації регламентованих бізнес процесів.

Плюс:

  • Швидке отримання інформації.
Мінус:

  • Даний спосіб не застосуємо при наявності в компанії тільки базових документів (або при їх повній відсутності) або, якщо в компанії Замовника не підтримується актуальність документації.


Повторне використання специфікації


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

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

В більшості випадків лише частина документації актуальна для нового проекту, тому потрібна ретельна перевірка вимог на відповідність поточним цілям і завданням Замовника.

Перевага:

  • Скорочення часу на розробку документації.
Недоліки:

  • Висока вартість першого проекту.
  • Зайва деталізація вимог, може привести до їх дорогим змін у майбутньому.


Представник замовника у компанії розробника


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

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

На додаток можна сказати, що наявність представника замовника у компанії розробника є одним з головних правил Agile.

Перевага:

  • Швидке отримання зворотного зв'язку та інформації від Замовника.
Недоліки:

  • Достатньо висока ціна для Замовника.
  • Витрати часу на адаптацію працівника.


Робота «в полі»


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

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

Переваги:

  1. Дозволяє наочно побачити проблему і розробити найбільш оптимальний варіант її вирішення.
  2. Допомагає найбільш точно зібрати вимоги, спостерігаючи за роботою співробітників.
Недоліки:

  1. У процесі спостереження можуть бути упущені деякі альтернативні сценарії бізнес-процесу.
  2. застосувати на секретних підприємствах або небезпечних (шкідливих) виробництвах.


Навчання


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

Метод корисний, коли процеси і діяльність співробітників Замовника важко описати з допомогою інших методів або Замовник не може надати адекватне опис вимог.

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

Перевага:

  • Дозволяє зрозуміти складний бізнес процес, що дозволяє запропонувати найкраще рішення.
Недоліки:

  • Висока вартість і тривалість.
  • Метод непридатний на небезпечних (шкідливих) виробництвах.


Мозковий штурм
image

Мозковий штурм — найбільш часто використовуваний метод одержання вимог, які пов'язані з новими або погано вивченими напрямками діяльності організації Замовника або функціями системи.

Він дозволяє зібрати безліч ідей від різних зацікавлених осіб (стейкхолдерів) в найкоротші терміни і практично безкоштовно.

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

Плюси:

  • Дозволяє генерувати безліч (у тому числі і нестандартних) варіантів рішень, а також дозволяє учасникам розвивати ідеї один одного.
Мінуси:

  • Учасники мозкового штурму повинні бути мотивовані на ідеї.
  • застосувати в розподілених командах.


Нараду


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

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

Наради є однією із ключових практик в Agile, оскільки в них беруть участь всі сторони, зацікавлені в розвитку проекту і вирішення проблеми.

Плюси:

  • Дозволяє розвивати і деталізувати вимоги, визначити пріоритети.
Недоліки:

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


Use case


Use cases або варіанти використання дозволяють зібрати і сформувати функціональні вимоги від особи учасників Діаграми варіантів використання визначають межі рішення і показують зв'язку з зовнішніми системами і учасниками.

Метод дозволяє деталізувати вимоги з точки зору користувачів, а також допомагає уточнити і систематизувати функціонал, який потрібно реалізувати.

Плюси:

  • Дозволяє опрацювати всі варіанти розвитку сценарію (основної та альтернативні сценарії)
Мінуси:

  • Метод не застосуємо для збору нефункціональних вимог.


Епілог
Комбінування методик дозволяє підвищити ефективність збору вимог, а так само уникнути їх втрати.
При зборі вимог необхідно пам'ятати, що важливими є не тільки функціональні вимоги (ЩО робить система), але і нефункціональні (ЯК система це робить).

Ретельно зібрані вимоги мінімізують ризики проекту, оскільки дозволяють сформувати чіткий і зрозумілий базис для розробки системи.

Інформація для статті взято з навчального посібника з підготовки до сертифікації REQB Certified Professional Requirements for Engineering (Базовий рівень).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.