Підготовка до discovery з боку бізнес-аналітика Kirill Belyavsky
- Oleh Voroniak
- 18 січ.
- Читати 15 хв
Як готуватися до фази Discovery — напевно, цьому я присвячу найбільше часу, тому що, на мій погляд, це важливо. Розглянемо відмінності між Discovery на локації (on-site) і віддалено (off-site). Через останні події, пов'язані з пандемією коронавірусу, багато фаз Discovery доводиться проводити віддалено, тому торкнемося й цієї частини.
Фаза Discovery — це тема, яка захоплює розуми всіх бізнес-аналітиків без винятку. Я часто чую на співбесідах, що люди кажуть: "Мене приваблює Discovery, я хочу займатися Discovery, брати участь у Discovery". І це зрозуміло, адже це відкриття чогось нового.
Discovery — це завжди складне, важливе завдання, яке часто також пов’язане з візитами до клієнта, подорожами, відрядженнями. Не дивно, що ця тема викликає багато інтересу. Давайте визначимося, що таке Discovery, розберемося в термінах і поговоримо про ключові аспекти.
Discovery — це обов’язковий і найважливіший етап розробки, на якому визначаються вимоги, аналізуються поставлені цілі, формується пропозиція щодо технічної реалізації, фіксуються межі проєкту і, зрештою, оцінюється вартість розробки. Це ключовий момент. Під час Discovery ми намагаємося знизити рівень невизначеності, який зазвичай є дуже високим на початку. Завдання бізнес-аналітиків і всіх учасників цієї фази полягає в тому, щоб зменшити цю невизначеність до мінімуму.
Один із можливих варіантів циклу проєкту виглядає наступним чином: усе починається з того, що до нас звертається клієнт. Його можна назвати потенційним клієнтом, або лідом — це неважливо. Головне, що клієнт шукає підрядника для реалізації свого IT-рішення, яке допоможе йому покращити бізнес.
На цьому етапі часто формується запит на пропозицію (RFP — Request for Proposal) від клієнта. Потім проводиться передпроєктна фаза (pre-sale), за нею — Discovery, де визначається все необхідне для проєкту.
Далі бажано створити концепцію проєкту та презентувати її клієнту. Якщо все добре, то ми переходимо до етапу розробки (delivery), починаємо створювати продукт, тестуємо його. У деяких випадках це може призводити до підтримки продукту (support), а цикл проєкту може продовжуватися практично нескінченно, особливо якщо потрібні доопрацювання або підтримка.
Однак може бути ситуація, коли деякі етапи, наприклад, концепція або Discovery, пропускаються, якщо це фіксований проєкт із чітким бюджетом і дедлайнами. У таких випадках проєкт розробляється, видається у світ і, можливо, підтримується, хоча підтримка не завжди є обов’язковою.
Може статися, що клієнт відхилить концепцію через недостатній бюджет або інші причини. У таких випадках весь процес може не розпочатися. Тому важливо ретельно працювати над першими етапами, оскільки без них складно уявити все інше.
На етапі перепродажу (pre-sale) зазвичай ми отримуємо від клієнта документ (RFP) із зазначенням його очікувань від продукту, бізнес-цілей, бачення, архітектурних обмежень і ризиків. Добре, якщо відразу зрозумілі бюджет і терміни реалізації. Клієнт після цього очікує пропозицію, як наша команда може це реалізувати.
На виході з цього етапу ми повинні запропонувати клієнту пропозицію (proposal), яка включає наше бачення проєкту, технології, архітектурне бачення та склад команди. На цьому етапі ключова мета — переконати клієнта провести Discovery для більш детального аналізу його вимог та створення точного плану з оцінками та архітектурним баченням.
На вході для фази Discovery є те, що отримано на етапі Pre-Sale: підготовча робота, шаблони та інші матеріали. Усе це є основою для роботи. На виході ми повинні отримати конкретну пропозицію, оцінку (estimate), бачення та обсяг робіт (vision and scope), а також архітектурне бачення (architecture vision) для реалізації проєкту. Окрім цього, формується концепція самого продукту.
Тимчасові рамки Discovery
Он-сайт + офсайт: Частина команди працює на локації клієнта, потім повертається і завершує Discovery віддалено. Такий процес зазвичай займає 2 тижні на локації + 2-4 тижні віддалено, залежно від складності проєкту.
Чистий офсайт: Уся робота виконується віддалено. Це займає більше часу, але терміни залежать від складності системи та обсягу проєкту.
Основні учасники Discovery
MUST HAVE: Бізнес-аналітик та архітектор — ключові учасники. Відсутність одного з них значно підвищує ризик невдачі.
Дизайнери — залучаються, якщо продукт має орієнтацію на користувацький досвід (User Experience). Для внутрішніх корпоративних продуктів UX може бути не ключовим.
Менеджери проєктів або engagement managers — допомагають у процесах координації.
Експерти в конкретній галузі (Subject Matter Experts) — залучаються, якщо проєкт потребує специфічних знань (наприклад, з роботи з даними).
Партнери — іноді клієнт приходить через партнерські стосунки. Такий партнер може брати участь у Discovery, посилюючи комунікацію.
Підготовка до Discovery
Підготовка — це найважливіший етап, який визначає якість Discovery і, відповідно, продукту.
Головним артефактом підготовки до Discovery є адженда (agenda) – порядок денний, який визначає, чим саме займатиметься команда під час Discovery. Для її підготовки потрібні два ключових елементи:
1. Дослідження (Research)
Це "домашня робота" аналітика перед Discovery. Вона включає:
Вивчення клієнта: розуміння компанії, її бізнес-моделі, структури та ключових аспектів.
Аналіз конкурентів і ринкових умов.
Оцінка бізнес-домену: якщо можливо, побудова концептуальної моделі домену, визначення основних проблем, які можуть перетинатися з викликами клієнта. Це допоможе виглядати професійніше в очах клієнта і полегшить спілкування.
Огляд найкращих практик і технологій: використання досліджень великих аналітичних компаній, які можуть бути доступні онлайн.
Перевірка документації: усе, що було отримано на етапі Pre-Sale (RFP, список стейкхолдерів, технічні вимоги тощо), необхідно проаналізувати, щоб підготуватися до комунікації з клієнтом.
2. Заплановані результати
Чітке визначення, що команда повинна отримати на виході з Discovery:
Результати, які відповідають цілям Discovery.
Бачення продукту, оцінки, архітектурне бачення тощо.
Особливості планування адженди
Врахування доступності стейкхолдерів: переконатися, що ключові особи будуть доступні в необхідний період. Відомі випадки, коли команда приїжджала на Discovery, але стейкхолдери були відсутні через інші зобов’язання.
Узгодження планів із усіма учасниками команди.
Виклики та несподіванки
Відсутність ключових осіб: важливо заздалегідь узгодити їхню присутність. Наприклад, через несподівані події, як-от аудит або поглинання, Discovery може бути скасованим або перенесеним.
Складний домен: якщо домен незрозумілий або дуже складний, необхідно:
Максимально підготуватися через дослідження.
Залучити Subject Matter Experts (експертів із конкретної галузі).
Використовувати доступні ресурси, зокрема аналітичні звіти.
Чому провальні Discovery трапляються?
Недостатня підготовка.
Неправильні оцінки.
Завищені очікування клієнта.
Відсутність структури та плану.
Провальні Discovery призводять до дуже негативних наслідків, зокрема:
Невірні оцінки: Помилки в оцінюванні проєкту можуть створити проблеми на подальших етапах розробки.
Завищені очікування клієнта: Якщо очікування клієнта не відповідають реальності, це може спричинити розчарування.
Розчарування клієнта: Недотримання домовленостей чи незадовільні результати створюють ризик втратити клієнта.
Головні уроки з провалів Discovery:
Планування доступності стейкхолдерів:
Необхідно заздалегідь переконатися, що ключові особи з боку клієнта будуть доступні у визначений час.
Наприклад, був випадок, коли команда прибула до офісу клієнта, але всі ключові працівники поїхали на конференцію, що зробило Discovery неефективним.
Узгодження планів команди:
Плани всіх учасників Discovery повинні бути узгоджені. Наприклад, не повинно бути ситуацій, коли один учасник проводить активність із клієнтом, а іншого чекають на паралельну зустріч.
Домашня робота:
Аналітики мають ретельно вивчити клієнта, його бізнес-модель, структуру, конкурентів і ринок.
Розуміння бізнес-домену клієнта допомагає зменшити розрив між очікуваннями клієнта та реальністю.
Адаптація до змін:
Бувають непередбачувані ситуації, як-от аудит або поглинання компанії, що змушують переносити Discovery. Наприклад, у разі таких змін потрібно бути гнучкими та готовими до перенесення процесів.
Планування результатів (Planned Deliverables) під час Discovery є ключовим аспектом, оскільки саме результати визначають успішність цього етапу. Результати повинні включати конкретні артефакти та знання, яких очікує клієнт, і залежать від поставлених цілей Discovery.
Важливість цілей Discovery
Цілі Discovery визначаються через розуміння того, що клієнт хоче отримати:
Які результати очікуються?
Які артефакти та знання потрібні для прийняття рішень?
Чому важливо це виконати саме зараз?
Фреймворки для планування Discovery
Seven Dimensions Framework:
Один із підходів, описаний у книзі "Discover to Deliver". Книга коротка (приблизно 90 сторінок) і доступно пояснює процес Discovery.
Чотири домени бізнесу:
Розділення на чотири основні аспекти:
Бізнес: Розуміння бізнес-цілей і процесів.
Дані: Інформація, необхідна для підтримки рішень.
Технології: Технологічні інструменти та інфраструктура.
Додатки: Інформаційні системи та програмні рішення.
Власні підходи:
Створення персоналізованих фреймворків, які відповідають вашим специфічним завданням.
Чотири основні напрями дослідження під час Discovery
Бізнес-вимоги:
Поділ бізнес-цілей на дві основні категорії:
Рішення проблем: Низький прибуток, відтік клієнтів, неефективні процеси, помилки, низька зацікавленість у продукті.
Використання можливостей: Розширення ринку, створення нового продукту, залучення нових категорій клієнтів.
Змішані ситуації: У багатьох випадках бізнес одночасно вирішує проблему та використовує можливості.
Головне питання: Навіщо? Що клієнт хоче отримати, за що він готовий платити?
Якщо є можливість, важливо зайнятися моделюванням бізнес-процесів. Якщо ж детальне моделювання недоступне, хоча б задокументуйте ключові процеси, які призводять до певних результатів. Це допомагає визначити ключові бізнес-драйвери та операційну модель компанії, тобто як вона функціонує.
Важливі аспекти:
Критерії успіху (Success Factors):
Визначте, що клієнт вважає успіхом для проєкту.
Визначте, як вимірюватиметься досягнення успіху.
Користувачі та ролі (Users and Roles):
Аналізуйте, хто і як використовуватиме рішення.
Розгляньте ключові сценарії використання (use cases), які дозволяють досягати бізнес-цілей.
Зв'яжіть сценарії з бізнес-процесами та критеріями успіху.
Вимоги стейкхолдерів:
Ідентифікуйте ключових стейкхолдерів і зрозумійте їхні очікування.
Визначте, які "болі" продукт має вирішувати для кожного стейкхолдера.
Пов’яжіть ці вимоги із загальними бізнес-цілями та критеріями успіху.
Унікальні особливості (Features):
Визначте, чим продукт відрізняється від поточних рішень або рішень конкурентів.
Ці особливості повинні забезпечувати досягнення бізнес-цілей і приносити унікальну цінність.
Використовуйте ці особливості для визначення пріоритетів, орієнтуючись на те, які з них мають найбільший вплив на успіх проєкту.
Коли ми говоримо про основні інтерфейси, важливо одразу визначити, хто братиме участь у процесі, скільки є сторін і які їхні ролі. Це допомагає чітко структурувати майбутнє рішення.
Основні інтерфейси в додатках
Наприклад, у додатку для доставки їжі можна виділити чотири ключові інтерфейси:
Користувач — людина, яка замовляє їжу.
Кур'єр — той, хто доставляє їжу.
Ресторан — місце, де готують їжу.
Адміністративна група — команда, яка наповнює контентом додаток.
Кожен із цих інтерфейсів фактично представляє окремий мікро-додаток для своєї аудиторії, і ці аспекти потрібно визначити якнайшвидше. Це також пов’язано з ключовими сценаріями використання, стейкхолдерами та фічами продукту.
Важливі аспекти роботи з інтерфейсами:
Відмінності між інтерфейсами:
Кожен інтерфейс повинен відповідати своїй цільовій групі.
Інтерфейси мають якісно відрізнятися від існуючих рішень, щоб забезпечити конкурентну перевагу.
Дані:
Визначте, які дані є у вашому продукті, як вони рухаються між учасниками.
Для цього корисно використовувати:
Flow-діаграми — показують, як дані переміщуються між системами.
Data dictionary — каталог даних, який описує, які об’єкти даних існують, хто їх створює, хто використовує і для чого.
Інтеграції:
З’ясуйте, чи будуть у продукті інтеграції зі сторонніми системами.
Визначте, які зовнішні сервіси будуть впливати на рішення, щоб забезпечити бізнес-цілі.
Атрибути якості
Одна з найважливіших, але часто забутих частин Discovery — це атрибути якості. Вони визначають нефункціональні вимоги продукту.
Чим атрибути якості відрізняються від функціональних вимог?
Функціональні вимоги: що саме продукт повинен робити (наприклад, можливість додавання товару в кошик).
Атрибути якості: як продукт це робить (наприклад, швидкість завантаження сторінки, стійкість до навантаження).
Приклади атрибутів якості:
Продуктивність (швидкість роботи).
Безпека (захист даних).
Масштабованість (здатність підтримувати зростання користувачів).
Юзабіліті (зручність використання).
Визначення атрибутів якості на ранніх етапах допомагає уникнути значних проблем на пізніших стадіях проєкту. Ці характеристики є ключовими для створення продукту, який не лише задовольняє функціональні потреби, але й є конкурентоспроможним на ринку.
Нефункціональні вимоги та їх значення
Нефункціональні вимоги відображають атрибути якості продукту, які залежать від контексту використання. Наприклад:
У фінансових системах (банківських додатках) безпека (security) є надзвичайно важливою. Це включає шифрування, складні паролі та обмежений доступ.
У додатках для замовлення їжі безпека менш критична, а акцент може бути на зручності й простоті використання.
Для біржових додатків продуктивність (performance) є ключовим атрибутом, оскільки швидкість виконання транзакцій безпосередньо впливає на бізнес.
У внутрішніх корпоративних додатках, наприклад для компанії, яка займається торгівлею малорухомими товарами, продуктивність може бути менш важливою.
Нефункціональні вимоги як конкретні метрики
Нефункціональні вимоги є вимірюваними та відповідають на питання "як?". Наприклад:
Атрибут якості: продуктивність.
Нефункціональна вимога: "Всі транзакції в додатку повинні виконуватися не більше ніж за 3 секунди."
Рекомендації щодо роботи з нефункціональними вимогами
Не запитуйте клієнта прямо:
Зазвичай клієнт не може одразу відповісти, які саме вимоги потрібні.
Наприклад, якщо спитати, якою має бути швидкість транзакцій, клієнт може сказати: "Як у Google". Це занадто абстрактна відповідь.
Пропонуйте рішення:
Сформуйте реалістичні параметри та представте їх клієнту.
Наприклад: "Якщо транзакція виконується за 3 секунди, це буде нормально?"
Узгоджуйте прийнятність:
Разом із клієнтом визначте, що є прийнятним рівнем для кожного атрибута якості.
Інші аспекти
Технології:
Дізнайтеся, які технології клієнт хоче використовувати або вже використовує.
Наприклад, клієнти можуть орієнтуватися на популярні технології, як-от блокчейн, навіть якщо їхня цінність для проєкту є спірною.
Обмеження (Constraints):
Враховуйте бізнесові обмеження: стандарти, регуляції, галузеві або організаційні правила.
Це критично для відповідності рішення потребам клієнта.
Solution Landscape:
Використовуйте структурований підхід для аналізу проєкту через призму атрибутів якості, нефункціональних вимог, обмежень і технологій.
Це допоможе створити повне уявлення про продукт і його контекст.
Важливо розуміти, які нефункціональні вимоги є критичними для кожного типу системи. Робота з атрибутами якості та обмеженнями має бути чітко структурованою, із залученням клієнта до погодження реалістичних параметрів. Це дозволяє створити рішення, яке відповідає потребам бізнесу, враховуючи реалії технологій і галузевих стандартів.
Project Landscape і його значення в Discovery
Discovery може відбуватися в різних умовах і для різних цілей, і це суттєво впливає на підхід та результати. Залежно від контексту, Project Landscape може бути включений або ні.
Види Discovery:
Discovery як частина передпродажного процесу:
Іноді Discovery використовується як спосіб залучення клієнта. Компанія може навіть запропонувати провести Discovery безкоштовно, щоб укласти контракт на подальшу розробку.
У таких випадках важливо зосередитися на Solution Landscape:
Сформувати чітке бачення рішення.
Максимально точно вгадати потреби клієнта та створити якісний концепт продукту.
Discovery у рамках існуючого контракту:
Якщо клієнт уже уклав контракт або погодився працювати з компанією, Discovery стає контрольованим процесом для забезпечення подальшого співробітництва.
У таких випадках ключовими аспектами є:
Визначення процесів комунікації.
Розробка структури та життєвого циклу вимог.
Завдання бізнес-аналітика під час Discovery
Процеси комунікації:
Створення плану комунікації (communication plan):
Формат спілкування (зустрічі, Zoom, електронна пошта тощо).
Частота зустрічей.
Узгодження способів обміну інформацією (наприклад, документи чи системи для спільної роботи).
Управління вимогами:
Формат вимог:
Використовуватимуться user stories, use cases чи інший підхід.
Визначення структури вимог (наприклад, документ, система управління вимогами).
Життєвий цикл вимог:
Як вимоги визначаються, перевіряються та підтверджуються.
Що відбувається з вимогами після їх виконання.
Аналіз процесів клієнта:
Спостереження за тим, як клієнт зараз працює з існуючими додатками або системами (observations).
Участь у презентаціях або візитах, організованих клієнтом.
Визначення доступності стейкхолдерів:
Переконатися, що всі ключові учасники (стейкхолдери) будуть доступні у потрібний час.
Узгодити плани та активності учасників Discovery.
Резюме
Адженда Discovery:
Ключовий артефакт, що включає:
План усіх активностей.
Узгодження між учасниками процесу (бізнес-аналітики, архітектори, дизайнери, стейкхолдери).
Врахування доступності стейкхолдерів і синхронізація їхніх планів.
Додаткові активності:
Можливість проведення спостережень за роботою клієнта.
Участь у візитах або презентаціях.
Врахування контексту:
Чи є Discovery частиною передпродажного процесу чи вже укладеного контракту.
Адаптація підходів залежно від обставин.
Підготовка до Discovery: практичні аспекти
1. Час роботи клієнта
Узгодьте години роботи клієнта та офісу. Наприклад, якщо клієнт починає роботу о 10:00, а ви плануєте почати об 9:00, це може викликати незручності.
Уникайте затримки клієнта після завершення його робочого часу.
2. Тривалість роботи з клієнтом
Рекомендовано планувати не більше 4 годин роботи з клієнтом на день:
Клієнт має інші завдання, і повне зайняття його часу може викликати незадоволення.
Більше 4 годин роботи стає неефективним через втому учасників.
3. Час на синхронізацію
Потрібен час для обробки зібраної інформації.
Синхронізація між:
Командою на локації (on-site).
Командою, яка залишилася віддалено (off-site). Наприклад, віддалена команда може працювати над прототипами, поки on-site команда проводить зустрічі.
4. Час на обід
Забезпечте час для обіду. Голодні учасники менш продуктивні, і робота затягується.
5. Щоденне підведення підсумків
Наприкінці кожного дня підводьте підсумки з клієнтом:
Формально: короткий звіт або лист із виконаними завданнями.
Неформально: презентація або обговорення прогресу.
6. Не плануйте важливі активності на останній день
Останній день часто є хаотичним через збори, організаційні моменти тощо.
Уникайте планування воркшопів чи критичних активностей на цей день.
Робота зі стейкхолдерами
Чи завжди вдається зібрати всіх потрібних стейкхолдерів?
Ні, це рідкість. Однак якісна підготовка значно підвищує шанси.
Визначте ролі, які потрібні: наприклад, експерт із безпеки, спеціаліст із бізнес-процесів тощо.
Поясніть клієнту, чому потрібна участь кожного з цих людей. Клієнт зацікавлений в успіху проєкту та допоможе.
Підготовка шаблонів (Templates) перед Discovery
Одним із ключових етапів підготовки до Discovery є створення шаблонів для документів та артефактів, які можуть знадобитися під час роботи з клієнтом. Це дозволяє значно полегшити процес, зменшити час на створення документації та продемонструвати професійний підхід.
Типи шаблонів, які варто підготувати:
Презентації:
Про компанію: Знайомство з вашою організацією та підходом до бізнес-аналізу.
Про бізнес-аналіз: Пояснення ролі бізнес-аналітика, якщо клієнт не повністю розуміє цю функцію.
Про техніки: Наприклад, короткі презентації про те, як працюють воркшопи, щоб підготувати клієнта до сесій.
Документи:
Vision and Scope Template: Основний документ, який підсумовує бачення та обсяг роботи.
Mind-maps: Для відображення знань про домен або бізнес клієнта.
Опитувальники: Попередньо підготовлені анкети для збору інформації.
Business Model Canvas: Якщо ви працюєте над бізнес-моделлю.
Stakeholder Register: Шаблон для реєстрації стейкхолдерів.
Глосарій (Glossary): Для опису термінів і понять, специфічних для домену клієнта.
Для воркшопів:
Quality Attributes Templates: Список основних атрибутів якості для конкретної індустрії.
Workshop Templates: Шаблони для структурування воркшопів.
Формати вимог:
User Stories: Шаблони для документування вимог користувачів.
Use Cases: Шаблони сценаріїв використання.
Data Dictionaries: Каталоги даних з поясненнями.
Інше:
Примірники документів: Наприклад, зразки специфікацій, які допоможуть зрозуміти очікувану структуру документів.
Пропозиції: Шаблони бізнес-пропозицій для клієнта.
Важливість узгодження та перевірки
У процесі воркшопів чи сесій часто з'являються суперечливі погляди від різних стейкхолдерів.
Щоб уникнути плутанини, важливо:
Синхронізувати позиції стейкхолдерів.
Використовувати воркшопи для вирішення конфліктів і з'ясування істини.
Перевіряти отримані факти з різними учасниками, щоб уникнути хибних висновків.
Підготовка — це наш ключ до всього. Власне, як буде виглядати процес.
Він приблизно виглядає так. Основні артефакти, які мають у нас бути на виході. У нас, як у бізнес-аналітиків, є кілька етапів взаємодії з клієнтом. Ми обговорюємо всі аспекти, розповідаємо про наші плани, розуміємо, що ці плани, найімовірніше, трохи зміняться.
Отже, у нас є kick off.
Потім, як правило, ми починаємо з бізнес-кейсу або визначення бізнес-проблем. Це важливо як для бізнес-аналітика, так і для архітектора, дизайнера й усіх інших учасників. Бізнес є основою всього того, що ми будемо робити далі. Тому нам важливо дуже добре розуміти ці бізнес-питання. Чудово, якщо ми зможемо залучити максимальну кількість decision maker.
Важливо окреслити саме цей бізнес-кейс, описати проблему, яку ми будемо вирішувати. Чудово, якщо в цей момент ми одразу отримаємо підтвердження від клієнта. Це можна зробити в будь-який можливий спосіб, щоб мати основу для подальшої роботи.
Далі ми будемо працювати з функціональними вимогами, а також з не функціональними вимогами. Ми проведемо quality attribute workshop, швидше за все, разом із архітектором. І вже після цього архітектор часто продовжує роботу самостійно. Але важливо, що ми щодня синхронізуємось, аби тримати наше розуміння на одному рівні, працюючи в паралельному режимі.
Ми займаємося функціональними вимогами, а також не функціональними. Якщо це потрібно, також працюємо з особливими вимогами до бізнес-аналітичного процесу. На виході ми повинні мати попередній план (draft BA plan). Було б чудово, якби після кожної зустрічі ми готували підсумок або узагальнення (summary): що ми дізналися, які рішення ухвалили, які ключові знахідки виявили під час discovery-фази. На цьому етапі важливо мати чітке бачення (draft vision scope), яке можна передати команді.
Далі йде offside-процес, де опрацьовуються вимоги, уточнюються деталі, створюється концепція проєкту. Концепція може бути у формі прототипу (інтерактивного або статичного), презентації з архітектурним баченням, основними функціями, планом реалізації (roadmap), складом команди та іншими деталями, необхідними для переходу до етапу delivery.
Тепер хотів би поділитися кількома порадами з власної практики щодо проведення discovery-фази.
Принцип перший: будьте готові до того, що все піде не за планом. Навіть якщо ви ретельно підготуєте план, реальність завжди вносить свої корективи. Але підготовка все одно необхідна, бо вона дозволяє мінімізувати наслідки непередбачених змін. План не має бути детальним до годин, але має включати основні сесії та ключові deliverables.
Принцип другий: у роботі з вимогами краще охоплювати ширший контекст, ніж заглиблюватися в деталі одного аспекту. Наприклад, замість детального аналізу одного кейсу, краще на 20-40% опрацювати всі ключові кейси. Це дозволить створити реалістичні оцінки.
Принцип третій: співпрацюйте з архітектором як команда. Якщо архітектор і бізнес-аналітик працюють ізольовано, це призводить до розбіжностей у розумінні бізнесу та технічної частини, що погіршує результати discovery і delivery. Архітектура має ґрунтуватися на бізнес-вимогах, адже основна мета — допомогти бізнесу заробляти гроші.
Що стосується роботи зі складними доменами, бізнес-аналітикам важливо зрозуміти основну бізнес-модель: як бізнес отримує гроші, хто платить і за які послуги. Бізнес-модель є базовою для будь-якого домену. Вона включає створення додаткової вартості, канали передачі грошей та послуг. Розуміння цієї суті дозволяє надалі деталізувати специфічні аспекти домену.
Під час роботи над складними доменами рекомендую створювати концептуальні моделі, які допомагають візуалізувати ключові бізнесові сутності та їхні зв’язки. Крім того, необхідно підтримувати постійну синхронізацію знань із архітектором протягом усього періоду discovery.
Один із прикладів концептуальної моделі з моїх проєктів: це основні бізнесові сутності та їхній вплив одна на одну. На основі цього ми можемо створити ERD-діаграму, щоб зрозуміти, як ці сутності будуть інтегровані у нашу систему. Деякі з них можуть розділитися на декілька інших сутностей у процесі. Цей перехід від бізнесу до системи має супроводжувати бізнес-аналітик. Саме він забезпечує це розуміння.
Важливо також визначати так звані SOR (sources of requirements) або архітектурні драйвери. Це можуть бути бізнес-кейси, функції, атрибути якості, нефункціональні вимоги, обмеження, ризики тощо. Наприклад, драйвери можуть стосуватися продуктивності, складності кейсів, безпеки тощо.
Ще один важливий момент для успішного discovery — це розуміння бізнесової термінології. Часто в бізнесі одні й ті ж сутності називають різними термінами залежно від того, хто про них говорить. Це може створити хибне враження, що мова йде про різні речі, або, навпаки, що одна назва стосується однієї сутності, хоча насправді це різні аспекти. Щоб уникнути плутанини, завжди ставте уточнювальні питання. Якщо ви чуєте термін вперше, не соромтеся запитати: "Вибачте, я не знайомий із цим терміном, чи могли б ви його пояснити?" Це абсолютно нормально і є частиною професійної роботи. Для уникнення плутанини важливо створювати словник термінів (glossary) та підтримувати його актуальність. Це допомагає синхронізувати терміни та їхнє розуміння між різними учасниками проєкту.
Перехід до завершальної частини discovery передбачає створення ключових артефактів.
З боку аналітика — це vision scope, з боку архітектора — architect vision. Залежно від потреб клієнта, це може бути прототип, клікабельний макет, презентація або документ із описом концепції.
Основна проблема, особливо в великих компаніях, — це передача знань між командами. Discovery часто виконує одна команда, а delivery — інша. Це створює ризики втрати контексту та непорозумінь. Тому важливо документувати всі ключові аспекти та забезпечувати їхнє передавання наступній команді.
Чому так відбувається? Тому що discovery — це надзвичайно відповідальний процес, і компанії хочуть довіряти його сеньйорам, тобто експертам, які вже зарекомендували себе в цій сфері. Однак, сеньйорів зазвичай не так багато, тому їх використовують на таких критичних етапах.
Delivery зазвичай передають менш досвідченим фахівцям, що є підходом до оптимізації ресурсів. Ресурси, звісно, — це люди. Цей підхід не ідеальний, але зрозумілий. Проблема в тому, що під час передачі знань щось може бути втрачено.
Як цього уникнути? Ось кілька порад:
Підтвердження результатів із клієнтом Той, хто проводив discovery, має переконатися, що зібрані результати є правильними і відповідають потребам клієнта. Іноді, якщо цей етап пропускають, можна зібрати неправильну або неповну інформацію.
Детальна документація Документація має бути створена так, щоб її могли зрозуміти інші люди. Використовуйте зрозумілі описи, розшифровуйте скорочення та додавайте легенду, якщо це потрібно.
Якісна передача знань Передавайте інформацію детально. Перевірте, чи отримувач зрозумів усе. Наприклад, попросіть його пояснити ключові моменти, бізнес-цілі або функції. Якщо є записи зустрічей, поділіться ними, щоб отримувач міг повернутися до них.
Доступність для запитань Залишайтеся доступними для отримувача інформації, якщо у нього виникнуть запитання через кілька тижнів.
Різниця між On-Site та Off-site discovery Пандемія змусила перейти до офсайт-формату, і це вплинуло на організацію воркшопів. В онсайт-форматі можна легко зібрати всіх в одній кімнаті, забезпечити необхідні матеріали (стікери, маркери, дошки) та підтримувати концентрацію. У офсайт discovery потрібно переконатися, що всі учасники мають доступ до інструментів (наприклад, онлайн-дошок), знають, як ними користуватися, і забезпечити інструкції чи навчальні сесії.
Фасилітація Незалежно від формату, важливо мати фасилітатора, який слідкує за дотриманням правил воркшопу, залученістю учасників та структурованим збереженням результатів.
Підтвердження результатів воркшопу Це є важливим етапом як для онсайт, так і для офсайт discovery. Учасники, які не були присутні на воркшопі, мають отримати ключові результати та розуміти їх.
Проблема залученості в офсайт discovery Учасники можуть відволікатися на сторонні завдання, і це значно ускладнює процес. Фасилітатору необхідно слідкувати за тим, щоб всі були зосереджені на воркшопі.
Джерело:
Коментарі