Діскаверіфаза

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

Головне - у Discovery фазі - довірити її професіоналам!

Повернутись

Scroll

Discovery фаза знижує витрати і ризики

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

Як підсумок Discovery фази - стає зрозумілим обсяг робіт, стек технологій, методологія ведення проєкту, необхідна команда, способи і терміни його реалізації.

Стейкхолдер (з боку Замовника)
Аналітик
UI/UX Дизайнер
Менеджер
Senior developer

Усі вони в нас у штаті.

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

Mind Map: Візуалізація вимог у діаграмі зв'язків допомагає зрозуміти масштаб проєкту, кількість ролей і модулів, а також визначити межі майбутнього проєкту. З нею простіше розгледіти одразу непомітні завдання, побудувати взаємозв'язки, відстежити суперечності та вимоги, що дублюються.
Діаграма BPMN: Формалізація вимог у такому вигляді допомагає чітко зрозуміти взаємодію користувачів один з одним і побачити можливі "білі плями", які в іншому артефакті ми могли просто не помітити. На цьому етапі явно вказується, як саме система працює: звідки в ній з'являються дані, відправні точки для дій і процесів, як саме користувач приходить до мети і чи не занадто довгим виходить шлях.
User Story/Functional Requirements (історія користувача/функціональні вимоги): Стислий опис функції або функціональності з погляду кінцевого користувача, який детально описує, що має бути на проєкті реалізовано.
Non-Functional Requirements (нефункціональні вимоги): Визначають атрибути якості, якими повинна володіти програмна система, такі як продуктивність, безпека, масштабованість і зручність використання.
Request-Response Model (модель "запит-відповідь"): Модель зв'язку клієнт-сервер, це документ, що конкретизує вимоги до інтеграції зі сторонніми системами і сервісами: що саме розроблювана нами система повинна запросити у сервісу (які поля) і що ми отримаємо від нього у відповідь.
Дослідження вузьких місць:Пошук вузьких місць і можливих рішень. Вузькі місця можна розглядати в спектрі від суто бізнес-орієнтованих до суто технічних. В особливих випадках - симбіоз того й іншого. Наприклад, платіжні системи.
Wireframes: Уявлення з низькою точністю макета, дизайну і функціональних можливостей користувацького інтерфейсу, що використовується для розуміння того, як здійснюватиметься навігація проєктом цілком.
Design Concept (Концепція дизайну): Проєктування і відтворення декількох ключових елементів дизайну, що відображають основну ідею проєкту, ключові компоненти дизайну і успадковану згодом стилістику.
Clickable Prototype: Інтерактивне моделювання кінцевого продукту з високою точністю, що використовується для тестування і перевірки користувацького досвіду.
Презентація: Візуальне представлення цілей, перебігу та результатів проєкту, що використовується для донесення інформації про проєкт до зацікавлених сторін. Можемо включити в пул робіт, щоб допомогти замовнику презентувати ідею стейкхолдерам.
План проєкту: План, що описує цілі, завдання, ресурси і терміни проєкту, який використовується для управління і відстеження прогресу. Створюється, щоб дати розуміння необхідних розробницьких ресурсів і транслювати терміни виконання завдань замовнику.
Груба оцінка для розроблення: Попереднє оцінювання часу та вартості, необхідних для розроблення програмної системи, що використовується для планування та розподілу ресурсів.

Кожен з артефактів деталізується необхідною мірою для того, щоб виконати поставлені перед Discovery фазою завдання. Наприклад, у межах User Story/Functional Requirements може бути написано докладне ТЗ, а в межах Design Concept може бути виконано весь дизайн цілком.

Основні етапи Discovery-фази

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

Залежно від особливостей проєкту деякі необов’язкові етапи можуть пропускатися або обєднуватися. Однак, на відміну від типового спрощеного підходу, наша методика Discovery може містити до 12 етапів, що дозволяє ретельніше визначити функціональні вимоги, врахувати бізнес-процеси та усунути невизначеності на старті. Такий глибокий аналіз мінімізує ймовірність непередбачених завдань у майбутньому та суттєво заощаджує ресурси під час розробки.

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

Артефакти Discovery-фази та їхня цінність

Під час Discovery-фази ми створюємо низку артефактів – кожен із них важливий для розуміння проєкту і слугує основою для наступного етапу розробки:

Mind Map (карта думок)

Діаграма BPMN

User Stories / Functional Requirements

Non-Functional Requirements (нефункціональні вимоги)

Request-Response Model (модель «запит-відповідь»)

Аналіз вузьких місць

Wireframes (каркасні прототипи екранів)

Design Concept (концепція дизайну)

Clickable Prototype (інтерактивний прототип)

Презентація проєкту

План проєкту

Груба оцінка розробки

01/

Mind Map (карта думок)

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

Кожен із зазначених артефактів опрацьовується рівно в тій мірі, яка необхідна для досягнення цілей Discovery-фази. Ми гнучко підходимо до глибини опрацювання: наприклад, за потреби за результатами підготовки User Story та функціональних вимог може бути одразу написано детальне технічне завдання, а етап Design Concept при достатньому часі та бюджеті може включати створення дизайну всіх основних екранів. Такий підхід забезпечує баланс між швидкістю та деталізацією – ви отримуєте максимум користі від кожного етапу без зайвої роботи.

Канали комунікації та взаємодія з клієнтом

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

Прозора комунікація протягом усього процесу – наш пріоритет. За кожним проєктом закріплюється досвідчений менеджер, який координує спілкування та забезпечує обмін інформацією. Ми використовуємо зручні для вас канали: регулярні відеоконференції (Zoom, Microsoft Teams тощо) для обговорення ключових етапів, корпоративні месенджери (наприклад, Slack) та електронну пошту для оперативних питань і обміну матеріалами. Ви завжди будете в курсі поточного стану робіт: ми надаємо звіти про прогрес, демонструємо проміжні результати (наприклад, mind map, схеми, прототипи) та збираємо ваші відгуки на кожному етапі.

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

Питання та відповіді

Чому необхідна Discovery-фаза?

Скільки часу займає проведення Discovery-фази?

Що я отримаю в результаті Discovery-фази?

Чи обов’язкова Discovery-фаза для типових або невеликих проєктів?

Чи можна використовувати вже наявні у замовника матеріали в Discovery-фазі?

Технологічний стек у Discovery-фазі

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

Інструменти бізнес-аналізу та моделювання

Для опису процесів та структур даних ми використовуємо нотації та засоби моделювання, такі як BPMN (Business Process Model and Notation) для бізнес-процесів, діаграми зв’язків (Mind Map) для ідей і вимог, UML для моделювання компонентів системи. Це дозволяє формалізувати ваше завдання та візуалізувати ключові аспекти ще на етапі аналітики.

Засоби прототипування та дизайну

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

Системи управління проєктами та документацією

Весь прогрес Discovery-фази прозоро фіксується за допомогою інструментів, таких як Jira, Confluence, Trello, Notion. У них ми ведемо беклог вимог, протоколюємо результати зустрічей, зберігаємо всі артефакти. Ви за необхідності отримуєте доступ до цих просторів, щоб бачити актуальну документацію та статуси задач у режимі реального часу.

Засоби комунікації

Для взаємодії з вами ми гнучко використовуємо зручні канали – корпоративні месенджери (Slack, Microsoft Teams), електронну пошту, відеоконференції (Zoom, Google Meet). Наша мета – бути завжди на зв’язку та швидко обмінюватися інформацією. Також ми можемо інтегруватися у вашу екосистему комунікацій, якщо у компанії прийняті певні інструменти (наприклад, працювати у вашому Slack-просторі або зв’язуватися у MS Teams).

Технології розробки

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

Стек Технологій

Front-end

Back-end

БД та аналітика

Мобільні додатки

Розгортання та Моніторинг

Bootstrap

HTML 5

React.js

Figma

Modern Web App

d3.js

Redux

JavaScript

Web Sockets

Backbone.js

SCSS

CSS 3

Переглянути всі технології

Чи готові почати розробку проекту?

Почніть з якісної Discovery-фази! Зв’яжіться з нами або залиште заявку – і команда SKALAR проведе для вас комплексну передпроєктну аналітику. Ми допоможемо формалізувати ваші ідеї, визначити всі вимоги та підготувати чіткий план реалізації. Отримайте максимальну визначеність і впевненість в успіху свого IT-проєкту ще до початку розробки!