Будь-який проєкт починається з дослідження ідеї. Тому на старті необхідно провести бізнес-аналіз, щоб дізнатись, наскільки продукт може стати успішним. У статті розглянемо, як виглядає старт проєкту з погляду бізнес-аналітика (БА), та обговоримо його роль і зони відповідальності на початковому етапі роботи.
Початок проєкту для аналітика: чому це важливо та складно?
Аналітик на старті обов’язково повинен розібратися з тим, що за продукт планується створити, навіщо та кому він буде потрібен. Також варто приділити увагу внутрішнім процесам розробки та взаємодії з зацікавленими особами.
Зазвичай БА тісно співпрацює з продакт-менеджером чи продакт-овнером. Синергія цих фахівців забезпечує всестороннє дослідження ідеї та її життєздатності перед стартом, а також допомагає визначити найкращі технічні методи реалізації. Отже, аналітику потрібно бути готовим до великої кількості переговорів з різними спеціалістами.
Зверніть увагу. На деяких проєктах з обмеженим бюджетом роль бізнес-аналітика частково закриває проджект-менеджер.
Основні задачі БА на старті:
- Початковий аналіз. Розуміння цільової аудиторії – це вже 70% успіху майбутньої розробки. Тому одна з основних задач фахівця – проаналізувати ідею, щоб зрозуміти, чи варто з нею стартувати. Тут необхідно дослідити інтереси клієнтів та відібрати найзручніші рішення для закриття їхніх потреб.
- Налагодження комунікації. Фахівцю слід чітко розуміти, хто замовник, хто – стейкхолдери проєкту, а хто – виконавці. Далі йому варто налаштувати з ними та між ними комунікацію, щоб зрозуміти, як бачить ідею кожен з учасників.
- Організація процесів. Аналітик також є відповідальним за налагодження процесів збору і фіксування вимог. Він повинен задокументовувати їх, аби потім передати команді розробки.
Найбільша складність у роботі БА – це те, що йому потрібно одночасно розумітися і на бізнес-процесах, і на технологіях розробки. Це гарантує ґрунтовне дослідження успішності ідеї та вимог щодо її реалізації.
Далі ми детальніше розглянемо три ключові зони відповідальності бізнес-аналітика.
1. Продукт: що розробляємо і навіщо?
Аналітик може бути залучений до проєкту на різних стадіях. Виділимо дві найрозповсюдженіші:
- Discover – клієнт звертається вперше і має лише загальне бачення ідеї. Тому фахівець повинен з нуля сформувати визначення та вимоги до майбутнього продукту й уявлення про те, як його втілити в життя.
- Deliver – клієнт сам чи у співпраці з консультантом компанії сформував певну систему, за якою має створюватися проєкт, ще до приходу аналітика. Тоді фахівцю потрібно проаналізувати наявну інформацію та провести додаткове вивчення продукту.
Корисно. Книга «Discover to Deliver», видана EBG Consulting, розповість вам все, що потрібно знати про роботу на діскавері-фазі.
На етапі вивчення продукту бізнес-аналітику важливо з’ясувати його сутність та мету. Для цього необхідно:
- визначити бачення кінцевого продукту, щоб знати, куди рухатися;
- описати функціональну декомпозицію для кращого розуміння деталей проєкту;
- розробити дорожню карту, щоб дізнатися, в якій черговості буде реалізуватися продукт.
Розглянемо трішки детальніше кожен з цих аспектів.
Бачення продукту
На старті проєкту БА важливо спрямувати зусилля на ключові аспекти. Product Vision Board, запропонований Романом Піхлером, стає відмінним інструментом для цього.
Таблиця допоможе у компактній формі зібрати всі важливі компоненти для бізнес-аналізу:
- візія продукту;
- цільова аудиторія та її потреби;
- переваги продукту;
- бізнес-цілі.
Product Vision Board допомагає не лише отримати чітке уявлення про продукт, але й взаємозв’язати його функції з реальними вимогами користувачів та стратегією бізнесу. Це ефективний спосіб оцінити, чи допоможуть нові функції досягти поставлених бізнес-цілей та вирішити потреби кінцевих клієнтів.
Отже, для більш ефективної роботи використовуйте техніки аналізу та спілкуйтеся з представниками бізнесу і команди розробки. Такий підхід допоможе вам визначити цілі та розставити пріоритети на старті проєкту.
Як відсутність бачення продукту у бізнес-аналітика псує проєкти
Функціональна декомпозиція
Бізнес-аналітик повинен розуміти, що беклог продукту схожий на живий організм, який постійно еволюціонує. З огляду на різноманітність практик, таких як Scrum або Kanban, беклог може ускладнити відстеження прогресу. Тому рекомендуємо використовувати функціональну декомпозицію як стартову точку проєкту.
Заздалегідь зафіксувавши структуру системи в деревоподібному вигляді, розбиту на модулі та деталі, бізнес-аналітик може забезпечити чітке уявлення про те, що має бути реалізовано. Ця структура дозволяє побачити, як різні частини системи взаємодіють між собою та як відповідають на ключові потреби користувачів.
Крім того, така композиція надає можливість лінкувати структуру з беклогом відповідної системи на трекінговій платформі (наприклад, у Jira), щоб слідкувати за прогресом. Такий підхід допомагає уникнути проблем, коли беклог змінюється та розширюється з кожним спринтом. Це створює стабільну основу для подальшого вивчення продукту.
Дорожня карта
На початкових мітингах з зацікавленими сторонами аналітик розпочинає формування деревоподібної структури, відзначаючи всі частини системи, їхні взаємозв’язки та ключові функції. Це дозволяє визначити основні деталі, які потрібно реалізувати. Тому створення дорожньої карти – один з ключових етапів при роботі з проєктом. Таку карту можна візуалізувати за допомогою будь-якої Mind map. Наприклад, чудовим інструментом є Xmind, де також легко створити чітку функціональну декомпозицію на ранніх етапах.
Дорожня карта допомагає зафіксувати бачення пріоритетів та перспектив розвитку продукту. Вона не лише служить інструментом для відстеження прогресу, але й дозволяє синхронізувати зусилля між різними командами та визначити зв’язки між усіма частинами системи.
Робота з дорожньою картою допомагає розв’язати питання, ким і коли буде виконаний кожен компонент продукту. Ця ініціатива дозволяє враховувати нові фічі чи зміни в ієрархії. Таким чином, вона стає не тільки ефективним інструментом для керування проєктом, але й зручним засобом комунікації з усіма зацікавленими сторонами. Все це сприяє забезпеченню успішного старту розробки продукту.
2. Зацікавлені особи: з ким співпрацюємо?
Робота з зацікавленими особами, або стейкхолдерами, є надзвичайно важливою на початку будь-якого проєкту. Взаємодія з ними визначає ефективність процесів та має величезний вплив на подальші дії БА.
Стейкхолдери не тільки ставлять вимоги до розробки, але й можуть впливати на майбутнє проєкту. Пропустивши інтереси чи вимоги хоча б однієї зацікавленої особи, ви ризикуєте отримати серйозні проблеми на подальших етапах. Тому бізнес-аналітику важливо чітко визначити ролі та шляхи взаємодії зі стейкхолдерами. Це допоможе уникнути непорозумінь та затримок під час безпосередньої розробки продукту.
Таким чином, до роботи зі стейкхолдерами потрібно відповідально підходити від самого початку проєкту, визначати їхні очікування та вплив, створювати відкритий і прозорий процес взаємодії.
Рекомендуємо вам сформувати реєстр стейкхолдерів з відміткою про їхні очікування та вплив. Регулярно переглядайте та оновлюйте цей список, а також активно взаємодійте з кожним представником. Адже комунікація та розуміння очікувань визначають успіх вашої спільної роботи.
Не менш важливо з’ясувати й те, з якою групою зацікавлених осіб ви працюєте: з технічною чи з бізнес-орієнтованою. Це допомагає адаптувати підхід та вибрати більш ефективний спосіб комунікації.
Коротко розглянемо ключових представників, з якими може співпрацювати БА:
- Бізнес-аналітики з сусідніх команд, які здатні запропонувати слушні ідеї й погляди, допомогти в розробці кращих рішень.
- Кастомери, які, хоч і не є безпосередніми користувачами системи, мають величезний вплив на її функціонал. Розробка продукту повинна враховувати їхні очікування та інтереси, оскільки будь-які помилки можуть знизити успішність проєкту.
- Зовнішні консультанти, експерти в ніші бізнесу та інші представники, які мають ключові знання про продукт. Це сприяє кращому розумінню та імплементації функціонала системи.
- Регулятори – невіддільна частина стейкхолдерів, з якими потрібно співпрацювати, щоб кінцевий продукт відповідав всім юридичним нормам та законам.
- Постачальники, тестувальники та інженери з контролю якості, завдяки яким забезпечується відповідність продукту встановленим технічним стандартам.
- Спонсори, що визначають стратегічні рішення та надають бюджет. Співпраця з ними – це ключовий фактор вдалого розвитку проєкту.
Як бачимо, саме комплексний підхід до роботи з різноманітними зацікавленими особами на старті дозволяє бізнес-аналітику зібрати повний перелік вимог та очікувань.
3. Процес: як будемо взаємодіяти для досягнення результату?
Запуск розробки продукту будується на задокументованих вимогах та базі знань, які бізнес-аналітик збирав на попередніх етапах роботи. Тому для досягнення найкращих результатів важливо навчитися правильно управляти вимогами.
Керувати процесом та вимогами легше, якщо орієнтуватися на тип проєкту. Розглянемо декілька можливих варіантів:
Довготривалий проєкт
Тут варто приділити особливу увагу організації документації. Через тривалість проєкту важливо вести систематичні та легкі для розуміння записи, які відображатимуть стан роботи над продуктом протягом всього періоду співпраці.
Time and Material (T&M)
У проєктах T&M визначення вимог та управління змінами стає ключовим елементом. Будь-які зміни можуть бути виконані швидко, але важливо, щоб вони відповідали стратегічним цілям продукту.
Проєкт з фіксованим Scope та бюджетом
У подібних Scope-проєктах першочергово БА орієнтується на обсяг та бюджет. Тому тут важливими аспектами є управління змінами та урахування того, за чий рахунок вони виконуються.
Scrum-проєкт
У Scrum-розробках, особливо короткотривалих, слід визначити, яким чином виявлятимуться вимоги. Адже часті ітерації потребують швидкої ідентифікації та збору вимог для більш ефективного створення продукту.
Agile-проєкт
У цьому випадку вимоги можуть часто змінюватися. Тому слід робити акцент на визначенні пріоритетів та гнучкому управлінні змінами для адаптації до нових вимог під час розробки.
Отже, залежно від контексту проєкту, можливо виділити найбільш критичні аспекти управління вимогами. Важливо зауважити, що гнучкість у підході може бути ключовою управлінською стратегією задля успішності проєкту.
Розглянемо також основні рекомендації для грамотного управління вимогами на старті проєкту:
- Регулярні зустрічі в календарі. Забезпечте стабільні мітинги з ключовими стейкхолдерами чи Product Owner для ефективного виявлення та узгодження вимог. Це зробить процес більш прозорим та швидким.
- Гнучке управління змінами. У проєктах з короткими ітераціями або Agile-підходом приділяйте увагу гнучкому управлінню змінами. Вимоги можуть варіюватися, тому важливо вміти адаптуватися до них.
- Одна відповідальна особа. Намагайтеся визначити одну людину (наприклад, основного стейкхолдера чи Product Owner), яка прийматиме фінальні рішення щодо пріоритетів та змін. Це допоможе уникнути конфліктів і пришвидшить прийняття рішень.
- Визначення пріоритетів без термінів важливості. Коли в розмові йдеться про пріоритети, уникайте термінів «важливо» та «неважливо». Замість цього говоріть про те, що потрібно в першу, а що – в другу чергу. Це полегшує прийняття рішень щодо проєкту.
- Активне питання. Коли ви визначаєте вимоги, питайте про їх важливість для стейкхолдерів. Так вам легше буде зрозуміти їхні потреби та правильно розставити пріоритети.
Усі ці поради є основою для успішного управління вимогами на початковому етапі проєкту. Вони допомагають бізнес-аналітику організувати прозорий, ефективний та гнучкий старт роботи над продуктом.
Підсумуємо
На старті проєкту вам важливо провести глибокий аналіз бізнесу, щоб зрозуміти бачення продукту, створити декомпозицію та розробити дорожню карту. Основні етапи роботи бізнес-аналітика також включають погодження з зацікавленими особами, визначення їх повноважень та очікувань.
Розуміння специфіки продукту дозволяє вибрати оптимальний підхід до управління вимогами. Встановлюючи комунікацію та розставляючи пріоритети, ви разом з командою можете створити ефективну стратегію керування проєктом та досягти бажаного успіху.
Якщо вам необхідно структурувати зання та здобути нові практичні навчики у бізнес аналіз, запрошуємо вас на курс Business Analysis Intensive Online . Business Analysis Intensive Online – це грнутовний курс, протягом якого ми розберемо велику кількість аспектів професії бізнес-аналітика та процесу створення вимог до програмного забезпечення.
