Часто кажуть, що вимоги стосуються того, ЩО, а дизайн — того, ЯК. Є дві проблеми з цим спрощеним розмежуванням.
По-перше, здається, що існує якась реальна чітка межа між вимогами та дизайном. Її не існує. Насправді різниця між вимогами та дизайном — це нечітка сіра зона, а не чітка чорна лінія. Я вважаю за краще сказати, що вимоги мають підкреслювати, що, а дизайн має підкреслювати, як.
Часто буває корисно зробити кілька попередніх кроків у простір рішень і вивчити всі можливі варіанти дизайнів, які могли б задовольнити деякі ваші вимоги. Це дослідження допомагає оцінити ясність, правильність, повноту та здійсненність цих вимог. Прототипування є цінною технікою для внесення попередніх проб у проект. Отримання відгуків про прототипи користувальницького інтерфейсу є чудовим способом підтвердити, що ваші дослідження вимог на правильному шляху.
Друга проблема полягає в тому, що як одного спостерігача є що для іншого. Це справді питання абстракції. Малюнок 1 ілюструє шкалу абстракції для послідовності переходу від деякої мотивації для виконання проекту програмного забезпечення до деталей того, як саме реалізовано програмне забезпечення. Ви можете розглядати кожну пару суміжних кроків у цій шкалі як тип інформації на вищому рівні абстракції та тип інформації на нижчому рівні.
Рисунок 1. Рівні абстракції в розробці програмного забезпечення.
Подивіться на друге поле зверху. Якщо ми запитали: «Що користувач зможе робити з цим продуктом?» ми можемо придумати кілька варіантів використання продукту, які дають цінні результати. Якщо ми потім запитаємо: «Як ми дозволимо користувачеві виконувати ці випадки використання?» ми могли б створити список конкретних функцій продукту, функціональних вимог і характеристик, як показано в третьому полі внизу. Ця інформація відповідає на питання «Що повинен створити розробник?» Ця послідовність зв’язків «що/як» продовжується до найнижчого рівня абстракції.
Ідеї рішень і обмеження дизайну
Проблема специфікації вимог і дизайну полягає не в тому, що чи як буде створюватися. Річ у тому, щоб відрізнити реальну потребу користувача від лише одного можливого опису того, як розумний розробник може задовольнити цю потребу.
Включення ідеї рішення у вимогу накладає обмеження на проектування. Запитане рішення описує один із способів задовольнити певну вимогу. Можливо, це не єдиний, найкращий або навіть хороший спосіб. Зосередження на рішеннях маскує основну вимогу. Через це розробнику може бути важко зрозуміти, що насправді намагається зробити користувач, щоб він міг знайти найкращий спосіб відповідати цим очікуванням.
Законні обмеження дизайну цілком доречні. Розробники повинні про них знати. Включення обґрунтування накладених обмежень разом із вимогою може випередити запитання, які можуть виникнути, коли розробники замислюються над тим, чи мають вони будь-яку свободу проектування. Ризик полягає в тому, що обговорення вимог буде зосереджено на рішеннях, про які думав клієнт або бізнес-аналітик, і накладатиме непотрібні обмеження. Це розчаровує розробника і часто призводить до неоптимального результату. Одна з моїх клієнтів-консультантів описала свій досвід роботи з такою ситуацією:
«Одна з найбільших проблем, яку я маю з персоналом служби підтримки клієнтів, полягає в тому, що вони зосереджені саме на рішенні. Вони тісно співпрацюють із клієнтом і замість того, щоб зрозуміти бізнес-проблему чи потребу клієнта, вони негайно зосереджуються на вирішенні. Ми просто витратили 30 годин часу компанії на зустрічі по одному спеціальному проєкту, тому що спеціаліст служби підтримки клієнтів запропонував рішення та не поділився відповідними бізнес-вимогами з бізнес-аналітиком. Це було дуже неефективно та сильно розчарувало учасників зустрічі».
Мене більше влаштовують обмеження дизайну, вбудовані у вимоги, коли вказуються вдосконалення, які мають бути внесені в існуючу систему. Існуюча реальність поточного продукту обов’язково накладає багато обмежень. Нові продукти розробки також підлягають обмеженням, наприклад, коли новий продукт є частиною існуючої екосистеми або будується на загальній платформі продукту.
Розробники повинні поважати архітектуру та умови зовнішнього інтерфейсу, вбудовані в поточний продукт. Ви не хочете, щоб дизайнери придумували інтерфейси, які радикально відрізняються від тих, з якими користувачі вже знайомі, якщо тільки новий досвід користувача явно не є більш ефективним для нього самого (принаймні, коли вони до нього звикають).
Замість того, щоб зациклюватися на тому, чи ця інформація є вимогами чи дизайном, пам’ятайте про ключову мету розробки вимог: чітке та ефективне спілкування.
Остерігайтеся передчасного наголосу на рішенні, яке не всебічно розглядає проблему, яку потрібно вирішити, і переконайтеся, що вказане рішення є адекватним.
Підказки рішення
Окрім звернення до “що”, вимоги мають сформулювати ще й “чому”, коли замовник потребує, щоб система включала певні можливості чи характеристики. Це розуміння допомагає бізнес-аналітику виявити, коли саме обговорюється рішення, а не вимога, що має призвести до обговорення основної потреби, яка призвела до запропонованого рішення. Ідея рішення є відправною точкою для бізнес-аналітика для глибшого розуміння того, чого клієнт насправді намагається досягти. Можливо, ідея рішення чудова, але, в той же самий час, вона неоптимальна або занадто вузька за обсягом. Розуміння того, “чому”, допомагає уникнути передчасного потрапляння в кут обмежень.
До теми: Запис вебінару “Кращі практики взаємодії бізнес аналітика і UI-UX дизайнера”
Питати “чому?” кілька разів часто є хорошим способом досягти цього розуміння. Аналітик повинен визначити, яка з наведених нижче ситуацій підходить, коли він виявляє запропоноване рішення.
-
Чи саме це рішення спало на думку того, хто його озвучив?
-
Це єдине можливе рішення (справжнє обмеження)?
-
Чи той, хто озвучив рішення більше зацікавлений у дослідженні рішень (що весело), ніж у розумінні проблеми (що важко)?
-
Чи може це рішення якимось чином вирішувати неправильну проблему?
-
Чи хтось вважає, що це необхідне рішення з якоїсь невідповідної причини, як-от помилкове припущення чи застарілий бізнес-процес?
-
Чи варта ідея рішення того, щоб передати її розробникам як пропозицію, а не як обов’язкову вимогу?
Однією з ознак того, що обговорення перемістилося в простір рішень, є те, що клієнт вимагає використання певних технологій або елементів керування інтерфейсу користувача без чіткого обґрунтування. Нижче наведено кілька прикладів, більшість із яких взято з реальних проектів.
«Калькулятор дефектів має бути написаний у Excel». Щоразу, коли аналітик чує таку вимогу, він повинен запитати: «Чому?» Чому Excel? Можливо, є чудова причина, і в цьому випадку було б цілком доцільно включити технологічне обмеження у вимогу (разом із поясненням). Але, можливо, у використанні Excel немає нічого чарівного чи важливого, і розробники повинні вільно досліджувати інші можливі рішення.
«На передній панелі повинна бути встановлена головна кнопка ввімкнення/вимкнення живлення». Подальше обговорення може виявити пояснення, чому потрібен такий точний підхід до проектування. Можливо, це потрібно для сумісності з існуючим продуктом, або, можливо, воно відповідатиме відповідному стандарту чи вимогам безпеки.
Зверніть увагу: Скетч-нотування для бізнес-аналітиків (і не тільки)
«Якщо тиск у резервуарі перевищує 40,0 фунтів на квадратний дюйм, система має засвітити жовтий попереджувальний індикатор тиску». Аналітик може запитати, чи слід зробити цю вимогу більш загальною, щоб дозволити розробнику розглянути різні способи сповіщення оператора про високий тиск у баку. Але клієнт може сказати: «Ні, на консолі оператора є жовтий індикатор тиску саме для цієї цілі, і краще, щоб він загорівся, якщо тиск перевищує межу». Це вагома причина включити обмеження дизайну як частину вимоги.
«Користувач натискає «ОК», щоб надіслати запит». Ця вимога передбачає наявність кнопки «ОК». Можливо, було б зрозуміліше, якби на кнопці було написано «Надіслати запит». Якщо ви додаєте вдосконалення до існуючого інтерфейсу користувача, добре, якщо вимога включає точну дію користувача. Але якщо ви вказуєте новий продукт, уникайте таких обмежень параметрів інтерфейсу користувача. Можливо, було б доцільніше використовувати взаємодію дотиком або розпізнавання мови. Більш загальна вимога може бути такою: «Користувач повинен мати можливість надіслати запит». Конкретику цієї дії залишає на розсуд дизайнера.
«Диспетчер фонових завдань має відображати повідомлення про помилки в рядку стану (status bar)». Якщо в програмі вже є рядок стану для повідомлень, це правильна вимога. Але що, якщо ще не було прийнято рішення включити рядок стану в інтерфейс користувача? Ця вимога накладає обмеження на дизайн, що виключає інші способи, які розробник може уявити для представлення повідомлень про помилки.
Проблеми перед вирішенням
Витрачений час на детальне вивчення основної вимоги, що лежить в основі представленого рішення, може окупитися. Давно, ще до багатозадачності ПК, моя група програмного забезпечення написала програму для керування деяким лабораторним обладнанням. Один користувач попросив нас написати спливаючий калькулятор для цього програмного забезпечення для керування. Розробник цього проекту подумав: «Круто! Я хотів би написати програму для калькулятора спливаючих вікон».
Але потім ми ще трохи подумали про це. Користувачеві потрібно було виконати обчислення, поки комп’ютер був зайнятий роботою лабораторного обладнання. Ми дійшли висновку, що було б дешевше купити кожному з наших 150 користувачів справжній калькулятор. Це рішення було не таким цікавим, як написання спливаючого калькулятора, але воно було набагато дешевшим.
Будь-який підхід задовольнив би потреби клієнта. І це суть розробки програмного забезпечення.
Оригінальна стаття – The Fuzzy Line Between Requirements and Design, переклад Олександра Серебрянська (Business Analysis Community Kyiv), ревью – Іван Вільчавський. Оригінальне зображення від автора.