
Діскаверіфаза
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 може бути виконано весь дизайн цілком.