Особливості дискавері фази для проєктів: чому це важливо?

• Чому дискавері фаза важлива?
• Наші приклади використання дискавері фази в проєкті
• 5 ключових елементів дискавері фази
• Чекліст дискавері фази проєкту
• Висновок

Коли проєкт із розробки програмного забезпечення вже перебуває в активній фазі, змінювати підходи без збільшення ризиків для термінів і бюджету досить складно. Тому бажано якомога раніше досягти визначеності щодо продукту та його розробки. На щастя, існує ключовий елемент, завдяки якому можна ухвалити попередні рішення, — етап Discovery.

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

Чому дискавері фаза важлива?

У різних проєктах і компаніях можна знайти різні підходи до фази дискавері. І поки одні ставлять під сумнів її необхідність, інші давно впроваджують і відстоюють її, використовуючи для отримання максимальної користі для своїх проєктів.

У SECL Group ми радимо вважати цей етап важливим, коли існує ідея продукту, але не більше того. На цьому етапі залишається нез’ясованим, чи дійсно продукт потрібний, чи можливо його створити, скільки часу та коштів знадобиться для його реалізації тощо. Відповіді на всі ці питання слід отримати якомога швидше.

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

Важливо не плутати цю фазу з етапом UX/UI-дизайну та підготовкою повного технічного завдання. Ця більш просунута стадія настає після дискавері фази, і будь-які ранні ескізи або начерки під час дискавері слід розглядати лише як чорнову ідею, а не як фінальний дизайн.

Дискавері фаза повинна бути лаконічною, щоб отримана інформація залишалася актуальною. Ми вважаємо, що оптимальна тривалість дискавері фази зазвичай становить 1–4 тижні. Однак цей термін може змінюватися залежно від розміру проєкту. На цьому етапі розробники також можуть залучатися як консультанти.

Цілком природно запитати, чи можна пропустити дискавері фазу проєкту або навіть провести її самостійно. На мою думку, за дотримання певних правил — так, це можливо. Головна умова полягає в тому, щоб засновники мали достатню, передусім технічну, експертизу на рівні, який дозволяє їм самостійно провести початкове дослідження та чітко розуміти, як саме проєкт слід розвивати далі.

Дуже часто клієнти приходять до нас із детальним описом своєї ідеї та навіть ескізами інтерфейсу, і в таких випадках цілком можна одразу переходити до етапу UX/UI дизайну. Але водночас бувають ситуації, коли самі засновники не знають, чи можливо реалізувати їхню ідею або чи вистачить їм ресурсів.

Наші приклади використання дискавері фази в проєкті

Дозвольте мені навести реальний приклад дискавері фази з моєї власної кар’єри. 10 років тому я вирішив створити тематичну соціальну мережу для ІТ-спеціалістів. Для початку я хотів використати базу користувачів Linkedin, щоб спростити процес підготовки. Я розумів, що моя цільова аудиторія знаходиться в цій мережі. Тому мені здалася перспективною ідея автоматично розсилати запрошення на мій новий проєкт усім, хто є в LinkedIn.

Але я не знав відповідей на два основні запитання:

• Чи було технічно можливим автоматично надсилати запрошення в LinkedIn?
• Чи було це взагалі законно? Чи порушувалися якісь права під час такого розсилання?

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

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

Для одного з наших клієнтів, Central Spa & Pool Supply, ми мали завдання розробити внутрішню B2B систему для управління дилерами. Спочатку всі ці процеси здійснювалися вручну через електронну пошту, що іноді призводило до втрати даних та інших незручностей. Тому їм було потрібне рішення, яке дозволило б керувати всім автоматично і в єдиній системі. У них був набір завдань, таких як додавання документообігу, реалізація різних рівнів доступу для менеджерів тощо. Нам потрібно було зрозуміти цю бізнес-логіку і перетворити її на працюючий програмний комплекс.

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

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

Спочатку ми витягли звукову доріжку з оригінального відео. Потім за допомогою інструментів розпізнавання мови перетворили її на текст і додали до відео на основі таймкодів. Після цього ми переклали текст за допомогою Google Translate і перетворили його на мовлення за допомогою спеціальних бібліотек. Нарешті, ми замінили оригінальну звукову доріжку на отриману. Використовуючи ці технології, нам вдалося реалізувати проєкт. До розробки цього продукту ми залучили технічних лідерів та архітекторів рішень. Тепер YouTube рекомендує сервіс Vidby як офіційний сервіс перекладу відео.

Коли ми почали працювати над власним стартапом — CountryHelper, то хотіли розробити сервіс для планування подорожей. Під час дослідження конкурентів ми виявили, що на ринку вже існує багато подібних сервісів. Однак лише небагато з них мали якісні та добре продумані карти. Тому ми вирішили створити сервіс для планування подорожей із вбудованою функціональністю карт. 

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

Google Maps стягує плату за кожен тип даних окремо, що призводить до значних витрат. Ми дослідили різні карти та вирішили, що можемо взяти лише карти вулиць з Google Maps з нашими власними об’єктами та областями, доданими контент-менеджером. Потім ми накладаємо геолокації об’єктів з інших сервісів, таких як OpenStreetMap, що значно зменшує вартість API та робить технічну реалізацію цього проєкту можливою.

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

5 ключових елементів дискавері фази

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

1. Дослідження ринку та цільової аудиторії.

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

2. Основні бізнес-процеси та користувацький потік.

Тут важливо структурувати всю накопичену інформацію, привести все в зрозумілий порядок. Дуже корисною буде візуалізація у вигляді діаграм або таблиць, до яких ви будете повертатися на наступних етапах проєкту. Я рекомендую використовувати готові перевірені інструменти. Наприклад, Business Model Canvas – управлінський шаблон для опису бізнес-моделі. Досить детально змоделювати бізнес-процеси можна за допомогою Business Process Model and Notation (BPMN).

3. Опис функціональності та можливостей продукту.

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

4. Планування технічної реалізації проєкту.

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

5. Час і вартість проєкту, склад команди та необхідні спеціалісти.

Усі розрахунки все одно будуть приблизними, і ви зможете деталізувати та уточнити їх пізніше. Однак ви точно отримаєте розуміння ймовірних термінів і вартості проєкту.

Звичайно, це лише приблизний перелік кроків етапу Discovery. Період дослідження та мозкового штурму є досить індивідуальним, як і кожен проєкт веб-розробки. Головне — постійно оцінювати кожен крок, зроблений під час етапу Discovery, з точки зору його переваг для наступних етапів розробки.

Дозвольте проілюструвати, що я маю на увазі, на типовому прикладі. В одному з моїх стартапів у мене з’явилася ідея створити рішення для туристів на основі карт. Щоб не зіпсувати цю круту ідею, потрібно було ретельно продумати, як її реалізувати.

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

Уявіть, що могло б статися, якби ми не провели такий продуктивний етап Discovery? Швидше за все, у майбутньому ми б допустили багато помилок, понесли б зайві витрати і лише згодом дійшли б правильних висновків. Могла б виникнути ситуація, коли замість покращення нашого проєкту нам довелося б витрачати зайвий час на виправлення недоліків на ходу.

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

Я також наполегливо раджу ретельно фіксувати все, що буде запропоновано та обговорено під час заходів етапу Discovery. Ідеться не лише про документи, а й про всі артефакти. Навіть відеозаписи інтерв’ю та зустрічей можуть виявитися корисними. Не можна виключати, що до деяких раніше висловлених ідей та аргументів доведеться повернутися пізніше.

Чекліст дискавері фази проєкту

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

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

Що я не рекомендую робити під час дискавері фази? Я вважаю, що не варто поспішати й намагатися створити клікабельний прототип на цьому етапі. Це пояснюється тим, що застосування зазначених вище аналітичних інструментів недостатнє для ретельного опрацювання UX/UI. Тому, якщо ви зробите клікабельний прототип на цьому етапі, ризик помилок буде досить високим.

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

Можуть також виникати ситуації, коли ви вже сформували загальний опис проєкту, але у вас залишаються певні сумніви або питання, які потребують уточнення. Наприклад, ви не можете вирішити, чи можливо реалізувати конкретну функцію. Для вирішення таких завдань немає сенсу проводити або продовжувати етап Discovery. Усе, що потрібно зробити, — це звернутися до професійної команди розробників і поставити їм ці питання. Якщо йдеться про веб-проєкт, ви можете написати нам, і ми порадимо, як краще діяти. Часто ми робимо це безкоштовно.

Знання того, як проводити Discovery, надає вам ще один інструмент для керування розробкою програмного забезпечення. Іноді Discovery може бути не для нового незалежного проєкту, а доцільно проводити його під час створення нового напряму в існуючому проєкті. Discovery також ідеально підходить для будь-якого повороту або різкої зміни концепції стартапу, коли фактично відбувається перезапуск проєкту. У таких випадках Discovery можна провести у скороченій формі, оскільки більшість необхідної інформації вже буде доступна. Але сам підхід залишатиметься ефективним і корисним.

Співпраця між засновниками та розробниками є критично важливою на всіх етапах проєкту, і етап Discovery не є винятком. Я раджу звертатися до команд, що спеціалізуються на певних галузях, особливо до тих, які мають власні стартапи. Такі колективи вже матимуть готові відповіді на багато ваших питань, що зробить ваш етап Discovery більш продуктивним. Можливо, вам навіть не доведеться проходити цей етап повністю, оскільки ви отримаєте корисну інформацію ще під час обговорень із розробниками. Насправді я рекомендую обговорювати проєкт із кількома командами, оскільки це допоможе зрозуміти, хто з потенційних підрядників має найбільшу експертизу та зможе найкраще допомогти вам.

На основі розглянутих питань, а також питань, що виникли у вашому конкретному випадку, ви можете створити чеклист етапу Discovery. Це допоможе підсумувати проміжні результати, упорядкувати всю зібрану інформацію та уникнути прогалин у описі вашого продукту.

Висновок

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

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