Discovery Phase
Етап планування — дуже важливий процес у розробці веб-продукту, адже він значно підвищує шанси успішної реалізації бізнес-ідеї. Мета етапу відкриття - початкове дослідження проекту, налагодження комунікації та пошук оптимальних інструментів реалізації.
Навіщо потрібен етап Discovery Phase?
Багато представників малого бізнесу змушені закриватись ще в перший рік існування. Згідно до досліджень Bureau of Labor тільки 2 з 10 бізнесів продовжують існування протягом першого року та далі. Тобто для побудови успішного та прибуткового бізнесу мати блискучу ідею недостатньо.
Важливо зібрати всі вихідні дані та правильно їх проаналізувати, виявити потенційні ризики та сформулювати всі майбутні кроки, що приведуть до бажаного результату з найменшими витратами.
Для успішної реалізації бізнес-ідеї важливо пройти етап discovery phase. Якісне та проаналізоване технічне завдання - перший необхідний крок до розробки прибуткового продукту. Наша команда допоможе, зібрати всі необхідні аналітичні дані, а також допоможе якісно сформулювати перелік функціональних вимог для розробки продукту.
Discovery phase дозволить уникнути небажаних витрат, пов’язаних з розробкою сформувати чітке уявлення не тільки майбутнього результату, а й процесу.
Software Requirements Specification
Специфікація вимог програмного забезпечення (Software Requirements Specification, SRS) - це документ, який описує всі функції та вимоги до програмного продукту. В процесі розробки цей документ також називають технічним завданням. Зміст цих документів регламентується різними стандартами, хоча вони й виконують майже однакову функцію - детальний опис вимог та цілей розробки.
Процес реалізації етапу відкриття
-
Визначення цілей
Це перший та надважливий етап, під час якого формулюються пріоритетні цілі. Саме вони впливають на кожне рішення, що приймається в процесі роботи над проектом. На цьому ж етапі відбувається пошук можливих шляхів їх реалізації та обираються оптимальнійші з них. Визначення цілей розробки грунтується на аналітиці та ринкових дослідженнях, а не припущеннях.
-
Етап збору вхідних даних
ППід час цього етапу ми займаємося підготовкою та подальшим аналізом даних, що є принциповими для визначення майбутнього вектору руху роботи над проєктом. Наші фахівці досліджують бізнес-оточення майбутнього продукту та основних конкурентів, що допомагає оцінити можливі бізнес-ризики та уникнути пов’язаних з ними небажаних витрат. Під час нього формуються принципи взаємодії вашої команди та команди розробників. Для наших фахівців дуже важливо побудувати комфортний та продуктивний робочий процес, що базується на довірі та взаємоповазі.
-
Розробка специфікації
Полягає у зборі, описі та систематизації функціональних та нефункціональних вимог до майбутнього продукту на базі аналітичних досліджень. Специфікація створюється з урахуванням оцінки ризиків.
-
Створення архітектури веб-продукту
Під час цього етапу наші фахівці описують структурні елементи продукту, їх взаємодію та надають рекомендації щодо створення технічного завдання. Створення архітектури також містить моделювання загроз, що пов’язані з взаємодією користувачів з веб-сервісом (Наприклад, під час створення архітектури сторінки для оформлення замовлення враховуються можливі загрози щодо захисту персональних даних клієнта.)
-
Узагальнення
На основі усіх отриманих методологій оцінюється об’ємність проєкту, часові рамки, витрати на розробку та складається уявлення про склад команди фахівців що працюватимуть над його реалізацією.
Результат проведення етапу
Необхідні кроки для збору вимог, реалізація яких передбачає роботу у рамках Agile-методологій (Scrum або Kanban).
Аналіз вимог
Ми збираємо та аналізуємо всі дані про проєкт та дані про загальне становище ринку. Виходячи з потреб майбутнього бізнесу складаємо перелік вимог, робимо візуалізацію необхідних процесів за допомогою блок-схем та діаграм та першу приблизну оцінку витрат на майбутній продукт.
Моделювання рішеннь
Це процес переходу від приблизної оцінки до точної. Маємо вже чітко сформульований план майбутніх дій та визначену конфігурацію бажаної команди. Повністю сформульовані функціональні та нефункціональні вимоги.
Дизайн
Наша команда підготує концепції майбутнього дизайну.
Які документи буде отримано в результаті Discovery phase?
- Детальне технічне завдання з зафіксованими усіма ключовими обов'язками та аспектами, що мають значення у процесі розробки.
- Функціональні вимоги — характеристики, яким повинен відповідати сайт. Складаються з вимог користувачів, системних та бізнес-вимог. Вони відображають те, як саме повинна працювати система та як вона відповідатиме на окремі дії користувача. Наприклад: процес реєстрації оформлення замовлення.
- Нефункціональні вимоги — характеристики, що не пов'язані з функціоналом та взаємодією користувачів з веб-продуктом, але необхідні для його якісної роботи. Наприклад: вимоги до швидкості завантаження, захисту персональних даних, тощо.
Це фундаментальний документ, що складається після збору та систематизації загальних вимог до розробки. Він містить:
Вимоги до майбутнього продукту можуть мати вигляд діаграм, блок-схем та інших інструментів графічної візуалізації даних.
Це вже приблизна схема майбутнього продукту. Вона служить орієнтиром для команди, допомагає звіритися та синхронізувати уявлення про результат розробки замовника та команди. Warframe може мати різний ступінь деталізації в залежності від потреб. Він також може бути зроблений для шляху користувача, для однієї чи всіх сторінок.
Ви матимете детальний кошторис, де обчислюється сума витрат за весь майбутній проєкт та кожен блок розписаний за статтями майбутніх видатків. Розробка цього документа допомагає оптимізувати процес, та уникнути зайвих витрат.
Цей документ містить рекомендації щодо майбутнього складу команди. Фіксуються дані про те, наймання яких саме фахівців є доцільним.
- Детальне технічне завдання з зафіксованими усіма ключовими обов'язками та аспектами, що мають значення у процесі розробки.
- Функціональні вимоги — характеристики, яким повинен відповідати сайт. Складаються з вимог користувачів, системних та бізнес-вимог. Вони відображають те, як саме повинна працювати система та як вона відповідатиме на окремі дії користувача. Наприклад: процес реєстрації оформлення замовлення.
- Нефункціональні вимоги — характеристики, що не пов'язані з функціоналом та взаємодією користувачів з веб-продуктом, але необхідні для його якісної роботи. Наприклад: вимоги до швидкості завантаження, захисту персональних даних, тощо.
Це фундаментальний документ, що складається після збору та систематизації загальних вимог до розробки. Він містить:
Вимоги до майбутнього продукту можуть мати вигляд діаграм, блок-схем та інших інструментів графічної візуалізації даних.
Це вже приблизна схема майбутнього продукту. Вона служить орієнтиром для команди, допомагає звіритися та синхронізувати уявлення про результат розробки замовника та команди. Warframe може мати різний ступінь деталізації в залежності від потреб. Він також може бути зроблений для шляху користувача, для однієї чи всіх сторінок.
Ви матимете детальний кошторис, де обчислюється сума витрат за весь майбутній проєкт та кожен блок розписаний за статтями майбутніх видатків. Розробка цього документа допомагає оптимізувати процес, та уникнути зайвих витрат.
Цей документ містить рекомендації щодо майбутнього складу команди. Фіксуються дані про те, наймання яких саме фахівців є доцільним.
Чому не варто ігнорувати етап планування?
Процес відкриття грунтується на регулярній взаємодії та спілкуванні замовника та команди фахівців. Це допоможе вам оцінити як працює наша команда, визначитися чи влаштовує вас наш досвід та підхід до розробки проекту. Результати етапу відкриття можна використовувати для співпраці з іншими постачальниками програмного забезпечення у майбутньому.
У процесі відкриття беруть участь бізнес-аналітики, менеджери проєктів, UI/UX-дизайнери, спеціалісти з маркетингу, технічні розробники, та тестувальники. Таким чином ви отримуєте максимально якісні та точні попередні аналітичні дослідження.
Ви отримуєте чіткий план вашого проекту, завдяки якому забезпечується дотримання встановлених строків реалізації проєкту, та визначених бюджетів розробки.
Результати фази відкриття можна використовувати для попередніх демонстрацій майбутнього проєкту, що допоможе вам залучати нових інвесторів або демонструвати його майбутнім користувачам у якості анонсу.
Різниця Discovery Phase та A request for proposal
Фактично, фаза відкриття та запит на пропозицію є різними етапами розробки. Як вже було зазначено, Discovery Phase - це перший етап процесу розробки, коли визначається цілі, формуються функціональні та нефункціональні вимоги та складаються фундаментальні документи (такі як специфікація) на основі яких будується увесь робочий процес.
Своєю чергою, RFP — це офіційний запит організації-замовника на отримання пропозицій від потенційних компаній-виконавців. Запит на пропозицію містить у собі цілі, завдання, вимоги та бажаний бюджет проєкту. У відповідь на цей документ розробнику пропонується надати детальні пропозиції з описом майбутнього процесу та можливими шляхами задоволення потреб клієнта.
Доцільним є видача запита на пропозицію вже після етапу планування, оскільки у такому випадку клієнт вже має чітко сформульовані вимоги та усвідомлює цілі проекту.
Завдяки RFP замовник має змогу оцінити різні компанії розробників і зупинити свій вибір на тій, що пропонує найкращі рішення для задоволення потреб проєкту.