Зосередженість на розумінні користувачів та використання ними продукту є найкращим ключем до успіху.
Вперше я навчився програмувати комп’ютери в коледжі у 1970 році. З тих пір я виконував багато ролей у програмній інженерії: розробник, дизайнер, бізнес-аналітик (БA), тестувальник, менеджер проектів, автор документації, менеджер команди, лідер з удосконалення процесів, консультант, тренер та автор. Плюс, звичайно, як і всі ми, я користувач.
Люди іноді запитують мене: «Який найважливіший урок ви засвоїли про розробку програмного забезпечення за весь цей час?» Ось він, урок #4 з 60 уроків у моїй книзі «Перлини розробки програмного забезпечення»:
Підхід до вимог та дизайну, орієнтований на використання (usage-centric approach), задовольнить потреби клієнтів краще, ніж підхід, орієнтований на функціонал (feature-centric approach).
Дозвольте мені описати, чому я вважаю, що це такий важливий принцип.
Проблема фокусу на функціональність
Існує кілька проблем із застосуванням функціонально- (feature-centric) або продукто-центричного (product-centric) підходу до виявлення вимог. Такі запитання користувачам, як «Що ви хочете?» або «Що ви хочете, щоб система робила?» відкривають двері для потоку випадкової інформації, яку важко перетворити на задовільне рішення. Зосередження уваги на функціях може призвести до того, що команда впровадить функціональність, яка не дозволяє користувачам зробити все, що потрібно.
Один з моїх клієнтів-консультантів провів одноденний семінар з приблизно шістдесятьма учасниками, щоб зібрати ідеї для великого нового комерційного продукту. Вони об’єднали результати шести підгруп і назвали це специфікацією вимог. Але це не було нею. Це була суміш фрагментів функціональності, функцій, завдань користувачів, елементів даних, бізнес-правил, обмежень та атрибутів якості, і все це змішане разом без структури чи організації. У суміші з тим рагу було багато сторонньої інформації. Просте прохання людей провести мозковий штурм щодо того, що б вони хотіли бачити в новому продукті, не дало практичних знань про вимоги.
Функціонально-орієнтований підхід також може призвести до реалізації функціональності, якою ніхто не користується, навіть якщо на той час це здавалося гарною ідеєю. У різних джерелах ви можете прочитати, що від 50 до 80 відсотків функцій програмного забезпечення рідко або ніколи не використовуються, тим самим не даючи великої цінності для бізнесу (The Standish Group 2014). З цією проблемою я стикався сам. Один з моїх внутрішніх корпоративних клієнтів попросив мою команду додати нову функцію до програми, яку використовувала його група. Він підкреслив, наскільки необхідною є ця функція, тому ми покірно вбудували цю можливість. Однак, наскільки нам відомо, ніхто ніколи не використовував цю функцію. Я б скептично поставився до наступного запиту цього клієнта на покращення.
Зосередження досліджень вимог на функціях сприяє цьому поширенню сплячої функціональності. Випитування безкінечного списку бажаних функцій у клієнтів просто викликає роздуття функціональності. Отже, як ми можемо уникнути цих пасток?
Цікаво також почитати: Гайд по User Stories для Junior BA
Користувацький досвід – понад усе
Я рекомендую Бізнес Аналітикам змістити розмови про вимоги від самого продукту до того, що користувачам потрібно робити з продуктом. Ми змінюємо акцент з функціональності на використання, з рішення на потреби. Стратегія, орієнтована на використання, допомагає БА та команді розробників швидко зрозуміти контекст та цілі користувача. З цих знань БA може краще визначити, які можливості та характеристики має мати рішення, для кого, чому і коли.
Дослідження, орієнтоване на використання, передбачає невелике, але значне зрушення в питаннях, які БA може задавати під час виявлення. Замість того, щоб запитувати: «Що ви хочете?» або «Що ви хочете, щоб система робила?» БA запитує: «Що вам потрібно зробити з системою?». В результаті цього, розмова визначає завдання або цілі, які користувачі повинні виконати за допомогою рішення.
Користувачі не запускають додаток для використання певної функції; вони запускають додаток для досягнення мети. Щоразу, коли я відкриваю своє програмне забезпечення для бухгалтерського обліку для бізнесу, я маю на увазі певну мету. Можливо, я хочу створити рахунок-фактуру, записати отриманий платіж клієнта, перевипустити свою кредитну картку або оплатити рахунок. Кожна така мета є випадком використання (use case). Я відкриваю додаток і виконую послідовність кроків, яка викликає функціональність, необхідну для виконання завдання. Якщо все буде добре, я успішно досягаю своєї мети та закриваю додаток: місія виконана.
Я знайшов варіанти використання (use cases) ефективним інструментом виявлення вимог з кількох причин.
Фокус на користувача. Варіанти використання – це природний спосіб для користувачів подумати про свої потреби. Користувачам важко сформулювати правильний набір функціональних можливостей для продукту, але їм легко говорити про сценарії використання зі свого повсякденного життя.
Організація. Варіанти використання забезпечують структурований спосіб організації описів пов’язаних функціональних можливостей. Шаблон варіанта використання має розділи, в яких ви можете записувати інформацію, щоб надати настільки детальний, або настільки поверховий опис випадку використання, який ваша команда вважає доцільною (Wiegers and Beatty 2013). Пов’язана функціональність включає опис найбільш типової або стандартної послідовності взаємодії для завдання (нормальний потік) і будь-яких варіацій на цій типовій послідовності (альтернативні потоки). Потім БA опише функціональність, яку має забезпечити рішення, щоб користувачі могли виконувати ці завдання. Належний опис випадку використання також визначає умови помилок, які можуть виникнути, і визначає, як система повинна обробляти їх (потоки винятків).
Розстановка пріоритетів. Найбільш пріоритетними функціональними вимогами є ті, які забезпечують виконання завдань користувача з найвищим пріоритетом. Першими реалізовуйте такі варіанти використання, які будуть частіше використовуватися, використовуватися більшою кількістю людей і більш своєчасні, ніж інші. В рамках одного випадку використання нормальний потік займає першочергове значення разом із супутніми йому винятками. Альтернативні потоки матимуть нижчі пріоритети і часто можуть бути реалізовані пізніше, або, можливо, ніколи.
Дизайн користувацького досвіду (UX). Використання точки зору користувача призводить до кращого дизайну UX. Він може дати уявлення про обмеження запропонованої реалізації, яку ви, можливо, не отримаєте від мислення, орієнтованого на продукт або функції. Ефективний UX-дизайн полегшує потік завдань користувача.
А як щодо User Stories ?
Багато гнучких проектних команд використовують історії користувачів (user stories) як техніку виявлення вимог та їх документування. Але навіть загальне визначення user story сфокусоване на продукті: «Історія користувача описує функціональність, яка буде цінною або для користувача, або для покупця системи, або програмного забезпечення» (Cohn 2004). Історії користувачів також не мають внутрішньої організаційної схеми.
Один великий проект зібрав кілька тисяч історій користувачів від багатьох зацікавлених сторін. Деякі історії були незрозумілими; багато конфліктували з іншими. Деякі з них виглядали як ймовірні дублікати, а треті були дражливо провокуючими, але неповними. Проект мав велику купу неорганізованої інформації різних видів, усі з яких були позначені як історії користувачів. З купи було важко сказати, які фрагменти функціональності пов’язані з завданнями користувача і які історії були лише думками, які люди озвучили.
Деякі з цих історій були орієнтовані на використання, решта – не були. Історії охоплювали широкий спектр деталей, були різного розміру та важливості. Вони варіювалися від «Як користувач, я хочу, щоб екранний шрифт був sans-serif, щоб я міг легко його прочитати» до «Як керівник по заробітній платі, я хочу, щоб система розраховувала податки штату по безробіттю для кожного штату, де у нас є співробітники, щоб ми могли правильно платити податки по безробіттю». Такі історії стосуються не користувачів та їх використання, а функцій та властивостей системи.
До теми – Запис вебінару “User Story чи Use Case?”
Накопичення набору ізольованих фрагментів функціональності вимагає, щоб хтось узагальнив їх знизу вгору, щоб розпізнати теми, пов’язані з завданнями користувача. Це скоріше схоже на те, щоб зібрати пазл, взявши в руки по одному шматочку і сказавши: «Цікаво, куди йде цей шматок». Я вважаю за краще починати з широких штрихів, таких як визначення завдань користувача, а потім поступово вдосконалювати та розробляти їх до менших деталей. Таким чином я менш імовірно пропущу щось важливе, і це завжди означає менше роботи, ніж якби я збирав всю головоломку по одній частині за раз.
Переможець: Фокус на використання
Як функціонально-, так і користувацько-орієнтовані підходи призводять до визначення функціональних вимог, які розробники повинні впроваджувати. Однак фокус на використанні допомагає гарантувати, що ми включимо всі функціональні можливості, необхідні користувачам для виконання своїх завдань, уникаючи при цьому створення надлишкової функціональності. Підхід, орієнтований на використання, підвищує зручність самого використання, оскільки розробники можуть продумано інтегрувати кожен біт функціональності в потік завдань або мету користувача (Constantine and Lockwood 1999).
Я почав застосовувати підхід до розробки вимог, орієнтований на використання, у 1994 році. Я швидко виявив, наскільки він сфокусований і ефективний у порівнянні з моїм попереднім підходом. Навіть якщо ви використовуєте поступовий підхід, а не повністю заповнюєте розширений шаблон варіантів використання, ваше мислення, заточене під використання, призведе до рішень, які в результаті задовольнять потреби клієнтів.
Оригінальна стаття – The Most Important Lesson about Software Development from the Past 50 Years (статтю переклав Вільчавський Іван, редагувала Серебрянська Олександра (Business Analysis Community Kyiv), графіка від Карла Вігерса.