Аналітик — арбітр між бізнесом, проектуванням і розробкою, який періодично зміщується в ту чи іншу сторону, але при цьому утримує процес створення мобільного продукту в поле здорового глузду. Він забезпечує комунікацію між всіма учасниками процесу, транслюючи знання від однієї групи в іншу, щоб висунуті гіпотези і прийняті згодом рішення були забезпечені достатньою кількістю інформації.
- Бізнес — завжди думає про досягнення своїх KPI, але рідко розуміє складність розроблюваної системи і зручність для користувачів.
- UX-проектувальник — завжди думає про користувача, іноді на шкоду бізнесу. Не завжди явно розуміє мету бізнесу і намагається нав’язувати свої ідеї.
- Розробник — думає, як зробити все класно з точки зору архітектури системи і програмного коду. Намагається приміряти користувальницькі сценарії на себе, але є технічно підкованим людиною, що не властиво для більшості користувачів.
Якщо про передачу вимог від рівня бізнесу до системного рівня сказано чимало і виробився певний інструментарій, то ось які артефакти використовувати для взаємодії і передачі знань між бізнесом, аналітиком та UX-проектуванням — питання відкрите. Цією темою я продовжую цикл статей з бізнес-аналізу в розробці мобільного.
У нас успіхом проекту вважається не тільки добре написане додаток, який містить в собі 0 критичних дефектів і реалізує все, що потрібно бізнесу, але й добре продумана логіка взаємодії користувача з додатком, якість підготовленої дизайн-концепції, яка буде залучати клієнтів. Роль бізнес-аналітика в компанії з’явилася відносно недавно, якщо брати до уваги інші напрямки (такі як розробка дизайн). Процес притирання був хворобливим, зі сльозами і соплями.
Часто виникали проблеми такого характеру:
- Вимоги дуже детальні і не дають простору, щоб розвернутися. В результаті ми часто отримували дизайн, який відрізнявся від затверджених замовником вимог. Іноді замовник був цьому радий. Адже красиві дизайн-концепції, оформлені відповідним чином, набагато більш наочні і зрозуміліше, ніж набір хитромудрих бізнес-процесів, які транслюються в сценарії.
- Вимог недостатньо, щоб підготувати дизайн. В результаті ми отримували затримки по термінах, зрушування віх за проектами, постійний сварки між бізнес-аналітиком і дизайнером, які відстоювали різні точки зору бізнесу і користувачів. Ми повинні розуміти, що у всьому має бути компроміс. Бізнес-цілі досягаються за рахунок реалізації користувацьких цілей. Якщо користувачеві додаток цікаво, то він буде сприяти нам у досягненні цілей бізнесу.
Для того, щоб взаимодейтсвие між BA, UX-проектуванням і кінцевим клієнтом проходилло гладко й ефективно, ми використовуємо набір артефактів.
Установча зустріч між дизайнерами, аналітиками, PM-ами
На самому початку наше завдання зрозуміти, як ми будемо рухатися, і що на думку команди може викликати найбільші проблеми на етапі підготовки дизайну. Як правило, стартуємо ми одночасно, але попередньо визначаємо фронт робіт. Весь продукт можна розділити на три частини:
- Опції особливі, зі складною бізнес-логікою. У замовника є уявлення як це повинно працювати і ці знання потрібно отримати. Аналітик в першу чергу починає роботу за завданнями такого типу. Невизначеності потрібно зняти в першу чергу, якщо цього не зробити, то про подальших роботах і мови бути не може.
- Функції, які повинні бути зручні для користувача. Замовник має своє уявлення, але чекає від нас експертизу як зробити краще. Такі завдання віддаються UX — проектувальника, який готує концепції TO BE.
- Функції, які повторюються з додатка до додатка. Як правило вони вже описані у вигляді вимог, є уявлення, яким буде дизайн, готовий код для реиспользования. Такі речі відкладаються на останні етапи проекту і можуть виконуватися дизайнером і аналітиком практично паралельно з періодичної синхронізації.
У випадку з функціями першого типу для передачі знань між учасниками команди ми використовуємо ряд артефактів.
Діаграма бізнес-процесів
Ми застосовуємо BPMN діаграма для опису бізнес-процесів замовника. Їх перевага полягає в тому, що вони прості для читання і чітко фіксують послідовність основних кроків, які повинні бути дотримані. Вони легко сприймаються замовником (у деяких компаніях є стандартом) і зрозумілі дизайнерам.
Кожна діаграма обов’язково забезпечується текстом. Текстовий супровід описує всі кроки більш детально і фіксує вимоги бізнесу, які неможливо відобразити графічно, а також дані, які задіяні в тій чи іншій процедурі бізнес-процесу.
Приклади даних і логічна модель даних
Важливим для дизайнерів є не тільки дотримання бізнес логіки, але й розуміння з якими даними доведеться мати справу. Буде зручно переглядати список з 3 найменувань. Думаю, що так. А якщо цих найменувань 1000, підійде все той же простий список? Для передачі даних у нас прийнято використовувати такі артефакти:
- Логічну модель даних
- Приклади даних
Логічна модель допомагає зрозуміти, які основні сутності будуть задіяні в програмі, з чим доведеться працювати користувачу. Які атрибути даних сутностей, що важливо підкреслити, а що навпаки користувачеві нецікаво і показувати не будемо. Як було доведено практикою, однієї логічної моделі недостатньо. Важливо ще розуміти сам контент — як він виглядає і яку інформацію несе для користувача. Саме тому кожна модель даних забезпечується плоскими таблицями, які пояснюють, що це за сутність, скільки їх може бути у користувача, дають текстовий опис атрибутів сутності і приклад того, «як це реально виглядає».
NB! Важливо пам’ятати один момент. Аналітик повинен вчасно виявляти та сигналізувати про майбутні зміни у вимогах PM-у проекту. Передати знання у вигляді діаграм бізнес-процесів і логічної моделі з прикладами даних недостатньо. Важливо розуміти, що отримана інформація адекватно сприймається учасниками команди.
Інтелект-карта
У нас виробилася така практика: після того, як UX-проектувальник вивчив всі отримані матеріали і задав необхідні запитання аналітику, він готує інтелект-карту з набором функцій і можливостей, які ляжуть в основу майбутнього дизайну. Після підготовки інтелект-карта обговорюється спільно з аналітиком. На цьому етапі потрібно переконатися, що всі все розуміють однаково, і немає ніяких різночитань.
Інтелект-карта майбутнього набору функцій, які UX-проектувальник хоче включити в дизайн
Фінальний набір екранів і валідація
Перед показів дизайн замовнику ми в обов’язковому порядку проводимо валідацію командою. Розробники перевіряють майбутнє додаток на реалізацію, аналітики — на відповідність бізнес-логікою та очікуванням замовника. І тільки після затвердження всіма учасниками процесу дизайн відправляється на затвердження з замовником.
Підсумуємо
Описаний набір артефактів і взаємодій допомагає аналітику полегшити обмін інформацією між бізнесом та UX-проектуванням і робить комунікацію гранично ефективною. Установчі зустрічі і побудова інтелект-карти дозволяють команді синхронізуватися всередині себе і зводять до мінімуму виникнення різночитань і непорозуміння між учасниками процесу. А це — одна з головних складових успіху всього проекту в цілому.