Під час одного з найбільш продуктивних періодів у моїй кар’єрі розробника програмного забезпечення я створив кілька застосунків для вченого на ім’я Шон у дослідницькій лабораторії великої компанії. Шон був єдиним користувачем; я був усією командою розробки програмного забезпечення. Я виконував усі завдання, необхідні для створення застосунку: розробка вимог, проектування інтерфейсу користувача та програми, кодування, тестування та документація.
Ми з Шоном сиділи на відстані десяти футів один від одного. Я був надзвичайно продуктивним, оскільки ми могли часто, неформально та швидко взаємодіяти. Я міг показати йому, над чим працюю, отримати відповіді на свої питання та його відгуки щодо ідей інтерфейсу користувача. Така близькість та той факт, що лише Шон надавав дані для проєкту, дозволяли нам співпрацювати в маленьких, швидких циклах. Нам не потрібні були письмові вимоги, адже я міг швидко отримувати необхідні деталі від нього.
Моя робота з Шоном була ідеальним середовищем для розробки програмного забезпечення: один розробник плюс один замовник, що сидять поруч. Але це також рідкість. Більшість проєктів мають багато замовників, згрупованих у кілька класів користувачів (часто в різних місцях), численні джерела вимог та кілька осіб, які приймають рішення. Команда розробників може складатися як із кількох людей в одному місці, так і з сотень у різних локаціях. Такі значно складніші проєкти потребують інших способів наблизити голос замовника до розробника, щоб отримувати вимоги, встановлювати пріоритети, комунікувати зміни та ухвалювати рішення.
Шляхи комунікації
Якщо ви не створюєте програмне забезпечення для себе, вам завжди доведеться мати справу з розривом між зацікавленими сторонами, які мають потреби, та розробниками, які створюють рішення. Кожна команда розробників повинна налагодити ефективні шляхи комунікації між цими двома групами. Ваші варіанти залежать від кількості учасників, їхнього місця розташування, рівня взаєморозуміння між спільнотами та навичок команди розробки.
Рисунок 1 демонструє кілька моделей комунікації, які з’єднують голос замовника з вухом розробника. Моя ситуація з Шоном ілюструє модель A — пряму взаємодію між користувачем і розробником. Такий підхід мінімізує потребу в письмових вимогах і зменшує ризик непорозумінь, за умови, що розробник і користувач говорять однією мовою в межах проєкту. Проте в більшості випадків у процес будуть залучені посередники.
Рисунок 1. Різні шляхи комунікації можуть з’єднати голос замовника з вухом розробника.
Багато користувачів із різними потребами не можуть напряму спілкуватися з розробниками — це призведе до хаосу. В такому випадку на розробників лягає тягар узгодження суперечливих запитів та визначення пріоритетів. Щоб впоратися з такою різноманітністю, я та багато моїх клієнтів-консультантів успішно використовували підхід B, показаний на Рисунку 1.
Аналіз зацікавлених сторін зазвичай виявляє кілька класів користувачів із відмінними потребами. Представники різних класів можуть використовувати різні функції продукту, виконувати різні завдання, мати різну частоту використання або інші відмінності. Визначивши свої класи користувачів, вам потрібно вирішити, хто саме буде виконувати роль голосу замовника для кожної групи.
Продуктові чемпіони
У моделі B основним каналом передачі інформації про вимоги є один або кілька ключових представників користувачів, яких називають продуктовими чемпіонами, вони співпрацюють з одним або кількома бізнес-аналітиками (BA). Продуктові чемпіони володіють знаннями у своїй доменній області та розуміють бізнес-цілі проєкту. Вони взаємодіють з іншими представниками свого класу користувачів для збору вимог, отримання відгуків про ідеї та інформування інших користувачів про хід проєкту. Бізнес-аналітик допомагає подолати комунікаційний розрив між продуктовими чемпіонами та командою розробників.
Звичайно, комунікація також здійснюється в зворотному напрямку відносно стрілок, показаних на Рисунку 1. Коли розробники — або будь-хто інший, залучений у комунікаційний процес — мають питання або потребують уточнень, їм потрібно звертатися до джерела вимоги, щоб їх вирішити. Корисно записувати, звідки надійшла кожна вимога, щоб розробники могли швидко отримати необхідні відповіді.
Інші шляхи комунікації вимог
Компанії, які створюють комерційні продукти, часто використовують шлях комунікації C. Маркетинговий відділ оцінює потреби ринку та потенціал продажів нового або вдосконаленого продукту. Маркетинг може співпрацювати з продуктовим менеджером, який несе основну відповідальність за визначення характеристик продукту, що забезпечать бізнес-успіх. Організація може розподілити обов’язки з визначення продукту різними способами між функціями маркетингу та управління продуктом.
Продуктовий менеджер виконує функції, які бізнес-аналітик (BA) здійснює в ІТ-проєкті. Ось коротке визначення ролі продуктового менеджера:
Продуктовий менеджер відповідає за виведення на ринок диференційованого продукту, який задовольняє потребу ринку та представляє життєздатну бізнес-можливість. Ключовим елементом ролі продуктового менеджера є забезпечення того, щоб продукт підтримував загальну стратегію та цілі компанії.
Проєкти, що слідують гнучкому підходу до розробки (agile), часто використовують шлях комунікації D (на Рисунку 1). Власник продукту (PO) формує бачення та ціль продукту, створює та комунікує зміст беклогу продукту. PO визначає дорожню карту, за якою продукт поступово еволюціонує від концепції до ранніх випусків і зрілого продукту, що приносить цінність клієнту. Таким чином, PO виступає голосом замовника.
Якщо PO не є експертом у всіх областях, які представляють користувачі, відповідальний власник продукту буде шукати поради в таких людей, як продуктові чемпіони, згадані раніше. У методології Scrum власник продукту — це одна особа, яка несе повну відповідальність за управління змістом беклогу продукту, навіть якщо частину роботи делегує іншим. PO також взаємодіє з маркетингом та бізнес-менеджерами, враховуючи їхній внесок у пріоритетний беклог історій.
Деякі agile-команди визнають цінність наявності досвідченого BA, який працює разом з PO. Якщо обидві ролі присутні, BA часто діє як розширення або заміна PO. Власник продукту може делегувати частину обов’язків, наприклад роботу з певними класами користувачів, бізнес-аналітику. Тоді BA відповідає за всі аспекти цієї області, за винятком пріоритизації вимог з інших областей, що залишається у компетенції PO.
Іноді власник продукту більше орієнтований на продукт і ринок, тоді як BA більше орієнтується на технічну сторону, створюючи вимоги до рішень на основі вимог користувачів. Ця модель представлена як шлях E на Рисунку 1. В інших випадках все навпаки. Природа їхньої співпраці залежить від того, як власник продукту вважає, що BA може принести найбільшу користь проєкту.
Застереження
Усі комунікаційні шляхи на Рисунку 1, крім A, передбачають наявність одного або декількох посередників між зацікавленими сторонами, які мають потреби, та постачальниками рішень. Кожен додатковий шар посередників збільшує ймовірність непорозумінь, неправильного тлумачення та комунікаційних помилок.
Кожен такий шар також вимагає додаткової документації у певній формі — з використанням поєднання діаграм для відображення загальної картини та тексту для деталей. Важливими стають визначення, тому може знадобитися глосарій. Кожна команда проєкту повинна ретельно зважити ці питання при виборі шляхів комунікації вимог.
Подолання розриву
Незалежно від того, як називається роль — бізнес-аналітик, інженер з вимог, продуктовий менеджер, власник продукту, розробник чи щось інше — усі проєкти повинні з’єднувати користувачів продукту з його творцями. Назва посади менш важлива, ніж наявність цієї ролі та чітке визначення її обов’язків і повноважень.
Особи, які виконують цю функцію, повинні мати відповідні знання, навички, досвід та особисті якості для роботи як із замовниками, так і з розробниками. Вони повинні вибудовувати відносини, засновані на взаємній довірі та повазі з обома спільнотами.
Ефективний розвиток вимог гарантує, що розробники чують голоси замовників голосно та чітко. Ці зв’язки можуть визначити, чи стане проєкт великим успіхом, чи так і не буде завершений.
Оригінальна стаття – Communicating Requirements: From Voice of the Customer to Ear of the Developer, переклад – Олександра Горлович, ревью – Іван Вільчавський. Зображення з оригінальної статті.