Як відсутність бачення продукту у бізнес-аналітика псує проєкти

Професія бізнес-аналітика (BA) вважається однією з критично важливих для всіх актуальних типів бізнесу. І не дарма, оскільки саме фахівці цього профілю можуть майже зі 100% точністю розрахувати потенціал тієї чи іншої кампанії.

Розробка, випуск продукції, сервісні концепції… Успіх різних ініціатив залежить від того, наскільки якісним буде дослідження експерта та як він розпорядиться його результатами.

Цікавий факт: за даними Mordor Intelligence, прогнозована цінність ринку BA у 2023-му сягне позначки у $88.83 млрд. При цьому подальший розвиток триматиметься на рівні CAGR 8.07%, а вартість ніші у 2028-му досягне $130.95 млрд.

Експерти E5 провели власне дослідження ролі BA в проєктах та розвитку бізнесу в цілому. З матеріалу ви дізнаєтесь відповіді на такі питання:

• Як формується бачення продукту в проєкті?
• Як бачення допомагає мотивувати та підтримати мотивацію команди за принципом: «будуючи храм, а не кладучи цеглу»?
• Як зберігати фокус команди на цілісному баченні продукту, навіть при зануренні в індивідуальні задачі?
• Як уникнути надмірного розширення масштабів продукту на різних етапах проєкту
• Як впевнитись, що функціонал, який ми додаємо, дійсно потрібний і цінний для клієнтів?

Типові ситуації, що виникають у команди, коли відсутнє чітке Product Vision

Без розуміння того, навіщо взагалі проводиться розробка (сьогодні розглядаємо BA в контексті IT), у команди, стейкхолдерів, інвесторів та навіть ЦА можуть виникати питання. Зазвичай негативного характеру, адже немає чіткого уявлення про цілі, цінність, переваги, унікальність та концепцію майбутнього цифрового продукту.

Відповідно, з’являються запитання наступного характеру:

• Від розробника: «Чому взагалі важливий цей продукт та як він може комусь бути потрібним?».
• Від клієнта: «А що це взагалі таке і навіщо ви його створили?». Типова відповідь команди: «Яке ТЗ, таке й ХЗ» (тобто: «Що ви сказали, те ми й зробили»).
• Від усіх, окрім замовника: «Навіщо цей (чи інший) функціонал взагалі додавати в систему?» Стосується спонтанних чи «креативних» концепцій, які випадають з контексту всього проєкту.

Дещо схожі питання, чи не так? Особливо тим, що кожне з них потребує чіткої відповіді про те, чим де-факто має бути актуальний проєкт, його функціонал, дизайн тощо.

Відповідно, це сигналізує про те, що немає сформованого Product Vision або ж що його інтерпретація не відповідає усталеній концепції. Також це індикатор того, що немає саме розуміння Product Vision у команди розробки.

Що таке Product Vision в класичному розумінні?

«Бачення без дії – мрія. Дія без бачення – жахіття». Так звучить японська приказка, і вона доволі точно характеризує цінність Product Vision для проєкту.

Особливо справедлива ця мудрість для IT-проєктів, де часто бувають ситуації, коли немає конкретизації, наприклад:

• що це за розробка;
• навіщо вона потрібна;
• яка цільова аудиторія;
• чим цінний продукт для користувача;
• чому розробляється щось, що не входить в концепцію.

Актуальність описаної проблематики з роками згасає, проте навіть у 2023-му подібні нюанси ще характерні у роботі з замовниками IT-рішень.

Концепція Product Vision полягає у глибшому сприйнятті проєкту чи продукту, ніж лише його «поверхні».

Інтерпретуючи це, можемо зробити два ключові висновки, що однаково правильно характеризують Product Vision:

1. Це опис ідеї та її цінності для потенційної аудиторії, реалізаторів, замовників проєкту.
2. Це наявність чіткого розуміння того, до яких результатів (фінансових чи практичних) має дійти команда, слідуючи певним задекларованим цілям.

Тобто характеристика того, навіщо виконується проєкт, яка його цінність та які результати очікують в підсумку.

Навіщо потрібне Product Vision?

«Концепція без формулювання ключових цінностей та опису ідеї – мрія, яка так і не втілиться в життя». Так можна коротко відповісти на питання: «Навіщо мати та розуміти бачення продукту?».

З практичної точки, Product Vision – це умовний гід, який розставляє орієнтири та пояснює сенс певних дій чи маршруту, його цілей.

Розгляньмо приклад: є концепція продукту (сервісу), скажімо, поштовий клієнт, що в перспективі має вийти на рівень Google. У вас є кілька варіантів дій: використати простий технологічний стек, випустивши IT-рішення раніше, або ж витратити більше часу на стек, що масштабується, орієнтуючись на подальші потреби цього типу продукту.

Залежно від того, яким є бачення ідеї (короткострокова чи довгострокова перспектива), ви можете виставити пріоритети та сфокусуватись на важливих актуальних аспектах розробки.

І, навпаки, коли це бачення відсутнє, ви будете постійно змінювати концепцію, наприклад, адаптуючись до трендів ринку. В якому з цих випадків ви отримаєте позитивний результат? Звісно ж, у першому, оскільки матимете можливість інтерпретувати актуальні тенденції та інтегрувати їх в усталене й зрозуміле Product Vision.

Це все щодо теоретичної сторони питання. Тепер пропонуємо розглянути концепцію Product Vision з практичного боку.

Кейси з Product Vision в контексті ролі BA в IT-проєкті

Концепція зрозуміла, проте як вона інтегрується в процеси розробки аналітики, планування та керування проєктами? Хитрість полягає в тому, що спочатку з’являється ідея, яка обробляється, описується та доводиться до майже практичного гайда. Тобто містить ключові питання:

• Що ми робимо?
• Навіщо ми це робимо?
• Кому ми це робимо?
• Для кого ми це робимо?
• Який результат маємо отримати?

Єдиний нюанс: для довготривалих (масштабних) проєктів перегляд «візії» продукту між циклами (етапами) проєкту – норма IT-індустрії. Тобто спочатку команда може створювати умовний поштовий клієнт, який до стадії MVP трансформується в бізнес-платформу чи просто отримає додатковий функціонал.

Проте початкова концепція та бачення необхідні, щоб побудувати органічні процеси й отримати можливість правильно керувати проєктом, інтегруючи нові ідеї чи позбуваючись від застарілих (непопулярних) рішень.

Тому пропонуємо вам кілька прикладів того, як відбувається робота з Product Vision впродовж всього проєкту.

Запуск проєкту, його початкова стадія

Зазвичай вже на початку роботи виникають певні проблеми, наприклад, відсутність розуміння командою того, що створюється і навіщо. Традиційна відповідь керівників звучить так: «Просто робіть та не ставте дурних запитань».

І це те, що може буквально поставити хрест на проєкті, оскільки працівники не розуміють його суті, що обертається проблемами для життєздатності продукту.

«Щоб запустити роботу над продуктом, необхідно мінімум два компоненти: бачення продукту та Product Backlog», – Schwaber. Це суть Scrum-методології, яка має нівелювати описану вище проблему.

Для старту проєкту критично важливим є бачення продукту, а також його відтворення в документації. Необов’язково все прописувати вручну. Зараз існує безліч відповідних шаблонів, які можна використати, щоб донести цінність та суть ідеї її реалізаторам. Також потрібно включити наступне:

• Цілі проєкту.
• Завдання.
• Опис бачення кінцевого результату.
• Кейси використання продукту.
• Функціонал.
• Цільова аудиторія.

Щоб описати бачення продукту, досить однієї-двох сторінок, де будуть вказані наведені вище пункти, а також терміни та бюджет проєкту (за умови, що потрібно працювати ще й з інвесторами). Цього вистачить не лише для запуску роботи, але і для інших потреб, наприклад, онбординг нових експертів.

Типовий макет Product Vision (by Roman Pichler)

Vision Statement  Стисле викладення ключових тезисів з бачення продукту.
Цільова група Сегментація користувачів, яким буде цікавий конкретно цей продукт. Вікова група, потреби, уподобання тощо.	Потреби Чим корисний продукт для ЦА. Закриває певні потреби, надає альтернативу (продукту), є нішевим чи поєднує ряд фішок.	Продукт Переваги продукту. Кілька особливостей, що демонструють основні фішки майбутнього рішення та його цінність.	Цінність Що продукт дає компанії. Репутаційні переваги, фінансові, дебют в певній ніші, лідогенерація, популярність.

Наведений тут приклад не є остаточним варіантом реалізації документа з бачення продукту. Він взагалі може бути багаторівневим, де залежно від, наприклад, ЦА, може змінюватись весь контекст наступних пунктів. Чим масштабніший продукт – тим більше розгалужень та шарів він може мати.

У контексті цього виникає ще одне питання: «А хто ж цим має займатися?». Хтось зі стейкхолдерів, зокрема:

• Product Manager;
• Product Owner;
• Business Analyst;
• Агент замовника;
• Project Manager (ситуативно).

Ці ролі мають право (розуміння та досвід) формувати бачення продукту та презентувати його (попередньо узгодивши з керівництвом).

Розробка та реалізація

Створення продукту – це комплексний та тривалий процес. Відповідно, з часом фокус (бачення та розуміння концепції) дещо згасає, що призводить до нових проблем.

Наприклад, з мотивацією команди, яка дещо знизилась, порівняно з моментом запуску проєкту, для якого було сформовано якісне бачення. Ба більше, навіть BA за певний період забуває, з чого все почалося і куди прямує.

Щоб не допускати такого розвитку подій чи хоч знаходити опору в подібних ситуаціях, варто вибудовувати (та підтримувати) ієрархію. Як в документації, так і в процесах, які фахівець виконує в межах посадових обов’язків.

Структурована ієрархія дозволить розуміти та бачити мету продукту впродовж всього часу роботи над ним. Вона може мати такий вигляд (приклад):

Потреби користувачів чи ринку
Ціль 1				Ціль 2				Ціль 3
Епік 1.x		Епік 1.y		Епік 2.x		Епік 2.y		Епік 3.x		Епік 3.y
Feature 1.x.1	Feature 1.x.2	Feature 1.y.1	Feature 1.y.2	Feature 2.x.1	Feature 2.x.2	Feature 2.y.1	Feature 2.y.2	Feature 3.x.1	Feature 3.x.2	Feature 3.y.1	Feature 3.y.2

Завдяки подібній архітектурі BA може швидко знайти ланцюжок, що проведе його від актуальної (маленької) задачі до глобальної мети. Власне, це і є частковою панацеєю для фахівців, що хочуть утримати фокус на Product Vision чи хоча б відновлювати його протягом всього періоду розробки.

User Centric Approach

Ще одним методом тримати фокус є розгляд продукту очима клієнта (кінцевого користувача). Ця концепція дозволяє концентрувати увагу на тому, що дійсно важливо для проєкту (його UX чи проблематика, яку він має закрити).

Такий підхід відносно непогано реалізується через User story, де, наприклад, BA ставить себе на місце користувача та описує, що б він хотів бачити в продукті. Сюди входять: вимоги до IT-рішення, можливо, ідеї, які б органічно вписувались в концепцію, сценарії застосування ПЗ для нівелювання «болей» користувачів тощо. А також опис, «чому» те чи інше відповідає вимогам (побажанням).

Розглядаючи User story як інструмент керування фокусом, варто зазначити, що для ефективного його застосування потрібна емпатія та вміння відігравати певну роль. Це дасть можливість визначити цінність продукту для користувача та правильно донести її команді, мотивувавши її на якісну роботу.

Scope creep

Уявіть собі умовну середину циклу розробки, під час якої замовник пропонує вам (делегує) створити нові фічі (що не вписуються в концепцію проєкту, не кажучи вже про Product Vision). Трапляється збій, під час якого акценти зміщуються в сторону нового функціоналу, а ключовий (навколо якого базувалося все IT-рішення) здвигається.

Чи можна в такій ситуації утримати фокус? Так, якщо ви отримуєте чіткі та аргументовані вказівки з поясненням, чому саме потрібно реалізувати це в рамках продукту.

Scope creep в житті

Прикладів Scope creep навіть зараз існує безліч. Проте доволі яскраво згадується ситуація нульових та програма Nero. Початкова концепція цього ПЗ полягала в записуванні компакт-дисків, знімання з них образів та монтування у віртуальному просторі.

Її доля склалася не найкращим чином тоді, коли студія вирішила перетворити класичну Nero в «комбайн» з безліччю функцій. Цими діями вона відштовхнула тих, кому дійсно був потрібен простий та зручний інструмент, проте так і не змогла отримати нову аудиторію.

Така ось історія про зсування фокуса у перспективного і популярного гравця ринку нульових.

Traceability

Ще одна типова для процесу розробки ситуація, коли з’являється нова функція в проєкті, якої не було в баченні та в концепції. Наприклад:

Ціль 1

Ціль 2

Ціль 3

Епік 1.x

Епік 1.y

Епік 2.x

Епік 2.y

Епік 3.x

Епік 3.y

Feature 1.x.1

Feature 1.x.2

Feature 1.y.1

Feature 1.y.2

Feature 2.x.1

Feature 2.x.2

Feature 2.y.1

Feature 2.y.2

Feature XYZ

Feature 3.x.1

Feature 3.x.2

Feature 3.y.1

Feature 3.y.2

В якийсь момент додається умовна Feature XYZ, яка не відноситься ні до якого епіка та не стосується жодної цілі. Її можна вирізати з проєкту, проте далеко не завжди. В цьому випадку потрібно переглянути Product Vision та включити сюди новий функціонал, провівши його від глобальної ідеї до певного місця в ієрархії.

UAT and Delivery Phase

Проблеми з Product Vision на релізі виправити найважче. Лінійна залежність притаманна й розробці: чим далі проєкт від початкової стадії, тим складніше та дорожче виправляються помилки.

Розглянемо кілька ситуацій, притаманних IT-індустрії.

Проблема №1. Відкладання релізу

Коли продукт вже має виходити в продакшен (реалізований функціонал, дедлайн), команда підсвідомо готується до його публікації в мережі (Google Play/AppStore тощо). Водночас замовник просить додати ще кілька «незначних» фіч, які хоч і не суттєво впливають на строки випуску IT-рішення, проте їх потік здається нескінченним.

Проблема №2. Реліз тут і зараз

Протилежна ситуація, коли продукт має запас часу на шліфування або просто ще не досяг фінальної стадії, але замовник (чи хтось з менеджменту) форсує випуск цифрового рішення. Виникає дисонанс, коли з одного боку швидкий реліз дасть можливість отримати фідбек та пофіксити критичні недоліки, але з другого – може зовсім знищити проєкт.

Розв’язання проблем №1 та №2

MVP (Minimum Viable Product) – це концепція, яка дозволяє закласти цінність в продукт на ранніх етапах його готовності та випустити його в продакшен з мінімальним, але корисним функціоналом. Далі ж йде цикл CI/CD в рамках SDLC, який забезпечує подальші модернізацію та масштабування IT-рішення.

Для MVP існує окрема концепція формування Product Vision, яка складається з:

• цілей,
• цінностей,
• фокусу.

Для кожної наступної ітерації (значної) формується окрема модель, яка має презентувати команді й користувачам, чому саме цей реліз потрібно провести саме зараз.

Окрім цього, потрібна дорожня карта, яка не лише показуватиме етапи розвитку та модернізації продукту, але і матиме «еластичність». Тобто враховуватиме відгуки користувачів, наприклад:

• чи потрібна конкретна функція;
• яку фічу додавати в продукт пріоритетніше;
• скільки готова чекати аудиторія: фокус на швидкість або якість;
• що саме є цінним для клієнтів;
• як часто мають бути релізи нових версій.

Навіть якщо проєкт не має на меті випуск MVP, а фокусується одразу на додаванні всього функціоналу в продукт, техніка планування MVP стане в пригоді для формування чіткого та зрозумілого Product Vision.

Jobs To Be Done

На перший погляд, концепція User cases, а тим паче на фінальному етапі, некоректна. Проте це далеко не так. Модель дозволяє правильно розставити пріоритети як розробки, так і подальшої підтримки IT-рішення.

Все тому, що вона фокусує увагу на дійсно важливих для кінцевого користувача речах, у нашому випадку – функціях та UX. Це допомагає окреслити актуальну кінцеву мету розробки (MVP) та розставити пріоритети на подальший розвиток проєкту.

Підсумуємо

Щоб не зіпсувати проєкт і випустити цінний та корисний для всіх зацікавлених сторін цифровий продукт, вам знадобиться Product Vision. Проте навіть після створення топового бачення та його опису навіть в автора (можливо, BA) виникають проблеми з фокусуванням на ньому впродовж всього процесу розробки.

Для ефективної розробки IT-рішення фахівці E5 рекомендують:

• чітко визначити бачення продукту;
• застосовувати техніки для фокусування;
• підтримувати фокус команди на Product Vision впродовж всього циклу розробки.

Повторюйте ці процеси для кожної нової фічі, нагадуйте собі про цінність та трендовість майбутнього продукту. Це допоможе утримувати увагу на баченні IT-рішення та форсувати його поширення як у команді, так і за її межами.

Хочете дізнатись більше про Product Vision та роль BA? Відвідайте профільний ресурс E5 та візьміть участь у вебінарах, конференціях, навчальних курсах.

E5 – драйвер вашого професіоналізму!