More than WEB development...
Діскавері фаза

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

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

Scroll

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

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

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

    Для успішного виконання Discovery фази потрібні такі фахівці:
  1. Стейкхолдер (з боку Замовника)
  2. Аналітик
  3. UI/UX Дизайнер
  4. Менеджер
  5. Senior developer

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

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

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

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

Чи готові почати розробку проекту?
Введіть своє ім'я*
+380 00 000 00 00*
Вибрати напрямок
Вибрати послуги
Бюджет від:
0тис.$
Коментар до проекту
Натискаючи на кнопку я приймаюумови згоди