Ключові представники користувачів — лідери продукту — можуть донести голос клієнта до вуха розробника
Основним принципом деяких гнучких підходів до розробки програмного забезпечення є передумова, що для кожного проекту потрібен постійний клієнт на місці (on-site customer), який тісно співпрацює з командою розробників і буквально сидить поруч з нею. Обґрунтування слушне. Лише обізнані та уповноважені представники клієнтів можуть відповісти на запитання та конкретизувати вимоги високого рівня. Якщо вони не можуть отримати своєчасні відповіді чи роз’яснення, розробники повинні зробити найкращі припущення щодо того, що, на їхню думку, хочуть клієнти. “Правильні” клієнти також можуть надати швидкий відгук про запропоновані інтерфейси користувача, прояснити непорозуміння та вирішити конфліктні вимоги та пріоритети.
Я повністю підтримую передумову про тісне, постійне залучення відповідних представників клієнтів до проектів. У більшості випадків різні зацікавлені сторони також повинні надати свій внесок. Моє занепокоєння щодо фрази “клієнт на місці” просто полягає в тому, що вона є одниною. Це означає, що доступна одна особа, яка має достатньо знань, досвіду та повноважень для прийняття рішень щодо вимог для всієї спільноти користувачів. Часто очікується, що власник продукту (PO) виконуватиме цю роль у гнучкому проекті. У цій статті описаний більш ефективний підхід до пошуку буквального голосу замовника та залучення клієнтів до проекту.
Класи користувачів і лідери продуктів
Більшість продуктів мають кілька різних класів користувачів, кожний з яких має дуже різні потреби. Певні групи — привілейовані класи користувачів — будуть важливішими за інші для успіху бізнесу проекту. Іноді класи користувачів — це навіть не люди: це інші інформаційні системи або апаратні компоненти, які отримують послуги від системи, яку ви створюєте. Таким класам користувачів також потрібен голос, щоб говорити про їхні потреби. Зрідка хтось може представити потреби всіх цих різноманітних класів користувачів і належним чином збалансувати їхні інтереси.
Більш реалістичний підхід полягає в тому, щоб залучити невелику кількість лідерів продукту, щоб служити ключовими представниками користувачів. Тридцять п’ять років тому моя група програмного забезпечення в компанії Kodak з великим успіхом запровадила підхід лідера продукту. У цій моделі потік вимог об’єднує одного або кількох бізнес-аналітиків, які працюють з одним або кількома лідерами продукту:
Мал. 1 Вимоги до схеми комунікації
Для початку знайдіть одного продукт-лідера для кожного основного класу користувачів. Деякі особи можуть належати до кількох класів користувачів і дійсно можуть задовольняти потреби всіх цих груп. В інших ситуаціях великий клас користувачів може бути розділений на підкласи.
Я зіткнувся з цією ситуацією під час проекту, який створював інформаційну систему для відстеження використання хімікатів. Наш найбільший клас користувачів складався з кількох сотень хіміків. Ми знайшли хіміка на ім’я Дон, який міг би задовольнити більшості вимог для звичайних потреб цих користувачів. Дон був лідером продукту, основним посередником між хіміками та бізнес-аналітиками (я, колишній хімік-органік, до речі). Дон спілкувався зі своїми колегами, щоб визначити вимоги, запропонувати ідеї, сформулювати відповідні бізнес-правила та вирішити суперечливі вхідні дані.
Класна стаття: Вебінар “Артефакти бізнес аналітика: темплейти та приклади”
Проте під час цього проекту ми дізналися, що певні групи хіміків мають певні спеціалізовані потреби. Тому ми залучили кількох інших представників для роботи з Доном, щоб забезпечити повне покриття вимог спільноти. Якщо ця група не могла дійти згоди щодо якогось питання, телефонував Дон. Хтось має приймати такі рішення, і краще, якщо це зробить обізнаний і поважний представник користувача, ніж БА або розробники.
У цьому ж проекті ми мали ще три важливі, але набагато менші класи користувачів. Ми знайшли одного лідера продукту, який мав представляти кожну з цих груп. Ці чотири лідери продукту разом служили нашим «голосом клієнта». Цей підхід до вимог став значним внеском в успіх цього проекту.
В ідеалі ваші лідери будуть працювати разом з аналітиками та розробниками протягом усього проекту, щоб вони могли швидко відповідати на запитання та надавати деталі, яких бракує у письмових вимогах. Це основна мета принципу “клієнта на місці”, і це може значно прискорити прогрес. Жоден із наших лідерів продукту ніколи не витрачав більше чверті свого часу на роботу над нашими програмними проектами. Вони не були поруч із командою розробників, хоча і були достатньо доступними, щоб надати швидкий зворотний зв’язок у разі потреби.
Я спілкувався з багатьма бізнес-аналітиками, розробниками та кінцевими користувачами з різних компаній, які випробували модель лідеру продукту. Вони незмінно повідомляють, що підхід був дуже успішним за умови дотримання наступних чотирьох умов:
- Правильні люди беруть на себе роль лідера продукту;
- Кожен чемпіон розуміє і бере на себе відповідальність.
Розділ 6 моєї книги «Вимоги до програмного забезпечення», 3-е видання, описує типову діяльність лідера продукту; - У кожного лідера є час для виконання завдання;
- Кожен лідер має повноваження приймати обов’язкові рішення на рівні вимог користувача.
Сама по собі наявність клієнта на місці не гарантує успіху. Колись у моєї колеги Джулії був лідер продукту, який працював разом із розробниками, але не мав великої цінності як спеціаліст. Як сказала Джулія: «він сидів посеред нас і все одно міг нас усіх уникати». Джулія замінила його новим лідером, який працював набагато ефективніше і робив свій внесок у формування напрямку проекту. Мораль цієї історії полягає в тому, що представники ваших клієнтів повинні взяти на себе зобов’язання надавати необхідний вам внесок у проект, а також вони повинні виконувати свою роботу.
До теми – Аналіз стейкхолдерів: модель значущості (Salience Model).
Сурогатні користувачі
Лідер ідеального продукту — це фактичний член класу користувачів, який він або вона представляє. Це не завжди можливо, особливо при створенні комерційних продуктів для безликого ринку. Можливо, вам знадобиться використовувати сурогати замість справжніх представників користувачів. Можливо, цю роль може виконати менеджер продукту (Product Manager) або місцевий експерт із предметної теми може говорити від імені користувачів, таким чином виступаючи в ролі лідера продукту. Проте слідкуйте за такими сурогатами користувачів:
Колишні члени класу користувачів. Якщо лідерами вашого продукту є колишні, а не нинішні користувачі, запитайте себе, чи не виник з часом розрив між їхнім досвідом і потребами сучасних користувачів. Їхнє розуміння може бути застарілим. Однак вони могли б добре працювати, якщо вони все ще спілкуються з поточними користувачами або якщо домен програми змінюється повільно.
Коли ми встановлювали найкращих продуктів для системи відстеження хімічних речовин, про яку я згадував раніше, менеджер хімічного складу сказав мені: «Я був хіміком-лаборантом, перш ніж отримати цю роботу, тож можу надати вам їхні вимоги. Вам не потрібно спілкуватися з іншими хіміками». Вона помилялася. Вона була ідеальним лідером продукту для класу користувачів хімічних складів, але вона не дуже добре розуміла, як інші хіміки в компанії повинні використовувати систему сьогодні. Я подякував їй за пропозицію, але потім вишикував інших представників хіміків, описаних вище.
Менеджери реальних користувачів. Менеджерам іноді незручно делегувати повноваження щодо прийняття рішень звичайним користувачам. Часто вони також не бажають, щоб їхні цінні співробітники витрачали багато часу на роботу з командою програмного забезпечення як лідери продукту. Я чув, як менеджери казали: «Я сам виконував цю роботу десять років. Я можу розповісти вам усе, що вам потрібно знати».
І тут є дві проблеми. По-перше, ці менеджери, ймовірно, не є поточними членами класу користувачів. По-друге, зайняті менеджери майже не мають часу, щоб присвятити його серйозній роботі з розробки вимог. Краще, щоб менеджери надали вхідні дані щодо бізнес-вимог (чому ми беремо проект, бізнес-цілі, рішення щодо масштабів) і попросили їх визначити деяких поточних членів класу користувачів, щоб зробити свій внесок у вимоги користувачів (випадки використання, історії користувачів, бізнес-процеси для підтримки, характеристики якості системи).
Зверніть увагу: Збір вимог онлайн: як аналітику знайти підхід до віддаленого замовника
Розробники програмного забезпечення, які вважають, що можуть говорити від імені користувачів. Це не буде працювати. Частіше навіть розробники зі значним досвідом у домені виявлять, що реальні користувачі нового продукту матимуть іншу — і більш надійну — точку зору. Звичайно, якщо продукт призначений для використання розробниками програмного забезпечення, ваші власні розробники можуть бути чудовими представниками користувачів. Навіть у такому випадку проведіть ретельний аналіз класу користувачів і переконайтеся, що хтось зможе виступати за кожного з них.
Тепер почуйте це
Ваші зацікавлені сторони можуть вагатися, чи варто, щоб обізнані користувачі витрачали час на роботу над вимогами з аналітиками. Ось як я це бачу. Зрештою ви отримаєте відгуки клієнтів. Набагато менш болісно отримувати це на ранній стадії та на постійній основі під час розробки. Альтернативою є дочекатися, доки продукт вийде в продакшн, і почати збирати скарги на все, що не так, або чого бракує. Тоді ви витратите багато незапланованого часу, грошей і доброї волі на вирішення цих проблем. Це не розумний спосіб створення програмного забезпечення.
Я стикаюся з багатьма командами, які хотіли б більше залучити клієнтів, але яким навмисно заблоковано спілкування з реальними користувачами. Це викликає особливе занепокоєння, коли замовник сам не є кінцевим користувачем, але заважає розробникам безпосередньо взаємодіяти з користувачами.
В інших випадках ніхто не хоче витрачати час на роботу з командою розробників над визначенням вимог, оцінкою прототипу чи іншими взаємодіями. Якщо ваші клієнти не хочуть співпрацювати, щоб переконатися, що продукт відповідає їхнім потребам, я ставлю під сумнів їхню відданість успіху проекту.
В ідеальному світі один справжній користувач, який працює повний робочий день, справді сидів би в полі зору — «на виду» — розробників, готових миттєво висловитися від імені всієї спільноти користувачів. Насправді в більшості ситуацій це малоймовірно. Більш реалістичною є така схема: керівник проекту, бізнес-аналітик або власник продукту (Product Owner) повинен зібрати невелику групу лідерів продукту, які можуть правильно інтерпретувати та збалансувати потреби класів користувачів, які вони представляють. Тісна співпраця з лідерами продуктів допоможе вам максимально наблизити голос замовника до вуха розробника.
Оригінальна стаття – Hearing the Voice of the Customer: The Product Champion Approach, переклад Олександра Серебрянська (Business Analysis Community Kyiv), ревью – Іван Вільчавський, зображення з сайту freepik.com.