Управління проєктом розробки сайту для салону краси

Кравець, Денис Юрійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7031
Title:	Управління проєктом розробки сайту для салону краси
Authors:	Рудницька , Юлія Володимирівна Кравець, Денис Юрійович
Keywords:	управління проєктом;розробка;веб-сайт;WBS;backend-розробка
Issue Date:	30-Dec-2025
Abstract:	Кваліфікаційна робота присвячена управлінню проєктом розробки сайту для салону краси. Робота є актуальною, оскільки провівши аналіз салонів краси в інтернет доступі було зрозуміло що не всі сайти відповідають вимогам. Метою кваліфікаційної роботи магістра роботи є дослідження та удосконалення методів і стратегії управління проєктом розробки сайту для салону краси, що дозволить оптимізувати бізнес-процеси та поліпшити обслуговування клієнтів. Об’єктом дослідження виступає процес розробки і впровадження інформаційних систем в веб салони краси. Було використано методи проектного менеджменту згідно PMBОК і методи оцінювання ефективності та прибутковості проектних інвестицій. Наукова новизна одержаних результатів полягає у тому, що було удосконалено методологію управління розробкою web-орієнтованих систем, що забезпечує більш ефективне керування подібними проектами. Практична значимість даної роботи полягає в тому, що теоретичні положення та висновки знайшли своє безпосереднє застосування в ході управління проєктом розробки сайту для салону краси. Аналіз бізнес-процесів салону краси виявив потребу в автоматизації ключових процесів. Огляд існуючих рішень показав відсутність повної кастомізації та інтегрованих CRM-систем, що обґрунтовує необхідність розробки індивідуального веб-сайту. Порівняльний аналіз методологій управління проєктами обґрунтував вибір гібридного підходу, що поєднує стратегічне планування PMBOK з гнучкістю Scrum. Інтеграція десяти двотижневих спринтів із структурованим плануванням забезпечує баланс між передбачуваністю, контролем бюджету та адаптивністю до змін вимог.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/7031
Appears in Collections:	126 Інформаційні системи та технології (IT Project Management)
Files in This Item:
File	Description	Size	Format
РЕП_МАГ_Кравець_МІТ-2411.pdf Restricted Access		1.31 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІЕРСИТЕТ 
 
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
 
 
Кафедра інформаційних технологій проектування 
 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
 
магістра 
 
 
на тему: «Управління проєктом розробки сайту для салону краси» 
 
 
 
 
Виконав: здобувач другого 
(магістерського) рівня вищої освіти 
___2__курсу, групи ____МІТ-2411____ 
Спеціальності 126 Інформаційні системи та 
технології ОП «IT Project Management» 
Кравець Денис Юрійович 
 
Керівник:  
доктор філософії, старший викладач кафедри 
інформаційних технологій проектування 
Рудницька Юлія Володимирівна 
 
Рецензент:  
к.т.н., доцент кафедри інформаційних технологій  
Черкаського національного  
університету ім. Б.Хмельницького 
Стабецька Тетяна Анатоліївна 
 
 
Черкаси – 2025 року 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
                                                                                                                  (повна назва) 
Кафедра інформаційних технологій проектування 
                                                                                                                  (повна назва) 
Освітньо-кваліфікаційний рівня магістр 
                                                                                                                  ( назва) 
Спеціальність  126 «Інформаційні системи та технології» 
 (шифр і назва) 
                                                                                    
 ЗАТВЕРДЖУЮ 
 Завідувач кафедри  ІТП  
  Тетяна 
ПРОКОПЕНКО 
 «____» ________________ 2025 року 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ МАГІСТРА 
Кравцю Денису Юрійовичу 
(прізвище, ім’я, по батькові) 
1. Тема роботи Управління проектом розробки сайту для салону краси  
 
Керівник Рудницька Юлія Володимирівна, доктор філософії, старший 
роботи викладач кафедри інформаційних технологій проектування 
                                   ( прізвище, ім’я, по батькові, науковий ступінь, вчене звання) 
Затверджено наказом Черкаського державного технологічного університету від  
«   07   » Жовтня         2025 року №307/03-03 
2. Строк подання здобувачем 03 грудня 2025 р. 
роботи 
3. Вихідні дані до роботи стандарти управління проектами; процеси управління проектом; 
вимоги до керівника проекту; управління командою проекту; календарне планування 
Проекту;підходи до управління проектом розробки сайту салону краси 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) 
ВСТУП → РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ → Огляд бізнес-процесів салону краси 
→ Огляд існуючих рішень для салонів краси → Порівняльний аналіз розглянутих аналогів → 
Формування вимог веб-сайту салону краси → Висновки до розділу 1 → РОЗДІЛ 2 ДОСЛІДЖЕННЯ 
МЕТОДІВ УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ ВЕБ-САЙТУ → Огляд сучасних методологій 
управління проєктами → Порівняльний аналіз методологій для проєктів веб-розробки → 
Обґрунтування вибору методології для проєкту розробки → Висновки до розділу 2 → РОЗДІЛ 3 
УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ САЙТУ САЛОНУ КРАСИ → Управління змістом та 
предметною областю проєкту → Формування структури декомпозиції робіт (WBS) → Управління 
часом проєкту → Розробка розкладу проєкту → Scrum-планування: спринти та їх структура → 
Управління вартістю проєкту → Управління якістю проєкту → Управління ризиками проєкту → Вибір 
технологій веб-розробки → Технології backend-розробки → Додаткові технології та сервіси → 
Висновки до розділу 3 → ВИСНОВКИ → СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, 
плакатів) 
1) Гистограма ризиків 
2) Діаграма Ганта 
3) ієрархічна діаграма WBS 
6. Консультанти розділів роботи 
Розділ Прізвище, ініціали та Підпис, дата 
посада консультанта 
  завдання завдання 
видав прийняв 
    
    
    
    
7. Дата видачі завдання                     13 вересня 2023 року      
 
КАЛЕНДАРНИЙ ПЛАН 
Строк 
№ Назва етапів 
виконання етапів Примітка 
з/п кваліфікаційної роботи 
роботи 
1.1 Постановка задачі 15.09.2025 виконано 
1.2 Підготовка завдання 18.09.2023 виконано 
1.3 Погодження завдання 20.09.2023 виконано 
1.4 Затвердження завдання 25.09.2023 виконано 
2 Основна стадія   
2.1 Підбір матеріалів 29.09.2023 виконано 
Оцінка можливих варіантів вирішення 06.10.2023 
2.2 виконано 
поставленої задачі 
2.3 Розрахунок параметрів рішення завдань 11.10.2023 виконано 
2.4 Вибір кінцевого варіанту рішення проекту 16.10.2023 виконано 
Оформлення первісної редакції  
3  
кваліфікаційної роботи 
3.1 Заключна стадія 30.10.2023 виконано 
Узгодження щодо прийнятих проектних 13.11.2023 
3.2 виконано 
рішень  
3.3 Попередній захист кваліфікаційної роботи 01.12.2025 виконано 
3.4 Затвердження кваліфікаційної роботи 11.12.2023 виконано 
3.5 Рецензування кваліфікаційної роботи 12.12.2023 виконано 
3.6 Захист кваліфікаційної роботи 17.12.2025 виконано 
 
Здобувач вищої освіти   ______________________                     Кравець Д.Ю.     
             (підпис)                                                  (прізвище та ініціали) 
 
Керівник роботи             ______________________                      Рудницька Ю.В.     
              (підпис)                                                  (прізвище та ініціали) 
  
АНОТАЦІЯ 
Структура та обсяг роботи. Пояснювальна записка складається з 3 розділів, 
викладена на 46 сторінках, містить 6 рисунків, 8 таблиць, 40 використаних джерела, 
без додатків. 
Кваліфікаційна робота присвячена управлінню проєктом розробки сайту для 
салону краси. Робота є актуальною, оскільки провівши аналіз салонів краси в 
інтернет доступі було зрозуміло що не всі сайти відповідають вимогам. 
Метою кваліфікаційної роботи магістра роботи є дослідження та 
удосконалення методів і стратегії управління проєктом розробки сайту для салону 
краси, що дозволить оптимізувати бізнес-процеси та поліпшити обслуговування 
клієнтів. Об’єктом дослідження виступає процес розробки і впровадження 
інформаційних систем в веб салони краси.  
Було використано методи проектного менеджменту згідно PMBОК і методи 
оцінювання ефективності та прибутковості проектних інвестицій. 
Наукова новизна одержаних результатів полягає у тому, що було 
удосконалено методологію управління розробкою web-орієнтованих систем, що 
забезпечує більш ефективне керування подібними проектами. 
Практична значимість даної роботи полягає в тому, що теоретичні положення 
та висновки знайшли своє безпосереднє застосування в ході управління проєктом 
розробки сайту для салону краси. 
Аналіз бізнес-процесів салону краси виявив потребу в автоматизації 
ключових процесів. Огляд існуючих рішень показав відсутність повної кастомізації 
та інтегрованих CRM-систем, що обґрунтовує необхідність розробки 
індивідуального веб-сайту. 
Порівняльний аналіз методологій управління проєктами обґрунтував вибір 
гібридного підходу, що поєднує стратегічне планування PMBOK з гнучкістю 
Scrum. Інтеграція десяти двотижневих спринтів із структурованим плануванням 
забезпечує баланс між передбачуваністю, контролем бюджету та адаптивністю до 
змін вимог. 
SUMMARY 
Structure and scope of the work. The explanatory note consists of 3 sections, 
presented on 46 pages, contains 6 figures, 8 tables, 40 references, without appendices. 
The qualification work is devoted to project management of website 
development for a beauty salon. The work is relevant, as an analysis of beauty salons 
available online revealed that not all websites meet the requirements. 
The purpose of the master's qualification work is to research and improve 
methods and strategies for managing the website development project for a beauty 
salon, which will optimize business processes and improve customer service. The 
object of research is the process of development and implementation of information 
systems in web-based beauty salons. 
Project management methods according to PMBOK and methods for evaluating 
the effectiveness and profitability of project investments were used. 
The scientific novelty of the obtained results lies in the fact that the methodology 
for managing the development of web-oriented systems was improved, providing more 
effective management of similar projects. 
The practical significance of this work lies in the fact that theoretical provisions 
and conclusions found their direct application in the course of managing the website 
development project for a beauty salon. 
Analysis of beauty salon business processes revealed the need for automation of 
key processes. Review of existing solutions showed the lack of full customization and 
integrated CRM systems, which justifies the need for developing a custom website. 
Comparative analysis of project management methodologies justified the choice 
of a hybrid approach that combines PMBOK strategic planning with Scrum flexibility. 
Integration of ten two-week sprints with structured planning ensures a balance between 
predictability, budget control, and adaptability to changing requirements. 
  
ЗМІСТ 
ВСТУП ............................................................................................................ 3 
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ............................................. 6 
1.1. Огляд бізнес-процесів салону краси ................................................... 6 
1.2. Огляд існуючих рішень для салонів краси ......................................... 8 
1.3. Порівняльний аналіз розглянутих аналогів ..................................... 10 
1.4. Формування вимог веб-сайту салону краси. .................................... 11 
Висновки до розділу 1 .............................................................................. 13 
РОЗДІЛ 2 ДОСЛІДЖЕННЯ МЕТОДІВ УПРАВЛІННЯ ПРОЄКТОМ 
РОЗРОБКИ ВЕБ-САЙТУ ............................................................................. 14 
2.1. Огляд сучасних методологій управління проєктами ....................... 14 
2.2. Порівняльний аналіз методологій для проєктів веб-розробки........ 17 
2.3. Обґрунтування вибору методології для проєкту розробки ............. 19 
Висновки до розділу 2 .............................................................................. 24 
РОЗДІЛ 3 УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ САЙТУ САЛОНУ 
КРАСИ .......................................................................................................... 26 
3.1. Склад учасників та їх ролі у проєкті ................................................ 26 
3.2. Формування структури декомпозиції робіт (WBS) ......................... 27 
3.3. Управління часом проєкту. ............................................................... 29 
3.4 Розробка розкладу проєкту ................................................................ 30 
3.5 Scrum-планування: спринти та їх структура ..................................... 31 
3.6 Управління вартістю проєкту ............................................................ 32 
3.7. Управління якістю проєкту ............................................................... 33 
3.8. Управління ризиками проєкту .......................................................... 35 
3.9. Вибір технологій веб-розробки......................................................... 37 
3.10 Технології backend-розробки ........................................................... 39 
3.11. Додаткові технології та сервіси ...................................................... 40 
Висновки до розділу 3 .............................................................................. 42 
ВИСНОВКИ ................................................................................................. 44 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ..................................................... 47 
2 
 
ВСТУП 
 
Цифрова трансформація бізнесу змінила правила гри для підприємств 
сфери послуг. Салон краси без власного сайту сьогодні — як магазин без вивіски. 
Клієнти шукають послуги в Google, порівнюють ціни онлайн, читають відгуки. 
Якщо салону немає в інтернетідля потенційного клієнта його просто не існує. 
Але створити сайт — лише половина справи. За статистикою Standish 
Group, тільки 29% ІТ-проєктів завершуються вчасно, в межах бюджету і з 
очікуваним результатом. Решта або затягуються, або коштують дорожче, або 
взагалі не відповідають тому, що хотів замовник.  
Чому так відбувається? Найчастіше — через відсутність системного 
підходу до управління проєктом. Власник салону знає свій бізнес, але не знає, як 
контролювати розробників. Розробники вміють писати код, але не завжди 
розуміють специфіку beauty-індустрії. Без чіткого плану, розподілу 
відповідальності та контролю якості проєкт перетворюється на хаос. 
Салони краси мають свої особливості. Їм потрібна не просто "візитка в 
інтернеті", а робочий інструмент: онлайн-запис з урахуванням графіка кожного 
майстра, нагадування клієнтам про візит, програма лояльності, портфоліо робіт. 
Готові рішення рідко враховують усі ці нюанси. Тому питання грамотного 
управління розробкою індивідуального сайту набуває особливої ваги. 
Відгуки оставлені клієнтами є візиткою до самого салону, чим і буде 
виділятись веб сайт. 
Зручний запис до майстра, та нагадування в смс та емейл форматі. Дуже 
потрібна річ яка присутня не на всіх сайтах салонів краси. 
Дизайн сайту простий та зрозумілий куди зайти та що нажати допоможе 
навігація по сайту та підказки. 
Актуальність теми. Сайт будь-якої організації є її візитівкою. Стильний 
дизайн, продуманий функціонал та зручна навігація позитивно впливають на 
залучення нових та утримання існуючих клієнтів. Не менш важливим є і вдало 
спроектована бекенд архітектура сайту та серверне налаштування, що позитивно 
3 
 
впливає на його швидкодію. Грамотне управління проектом з розробки сайту 
враховує всі вище перелічені особливості створення веб ресурсу і дозволяє 
ефективно використовувати наявні ресурси для досягнення оптимального 
результату. Таким чином тема даної кваліфікаційної роботи «Управління 
проєктом розробки сайту для салону краси» є актуальною. 
Мета роботи полягає у побудові ефективного процесу управління 
проєктом розробки сайту для салону краси шляхом адаптації сучасних 
методологій управління проєктами та обґрунтованого вибору технологічного 
стеку на основі аналізу специфічних вимог предметної області. 
Для досягнення поставленої мети необхідно вирішити наступні задачі:  
- проаналізувати предметну область; 
- виявити ключові бізнес-процеси; 
- дослідити існуючі рішення для салонів краси; 
- провести порівняльний аналіз існуючих рішень; 
- сформувати вимоги до веб-сайту салону краси; 
- дослідити сучасні методології управління проєктами 
- провести порівняльний аналіз методологій для веб-розробки; 
- обґрунтувати вибір оптимальної методології управління проєктом; 
- розробити структуру управління проєктом, включаючи планування 
змісту, часу, вартості, ресурсів, ризиків та комунікацій; 
- провести порівняльний аналіз та обґрунтувати вибір технологічного 
стеку; 
Об'єкт дослідження — процес управління проєктом розробки веб-сайту 
для підприємств сфери послуг. 
Предмет дослідження — методи, інструменти та технології управління 
проєктом розробки сайту для салону краси. 
Методи дослідження. У роботі застосовано комплекс методів наукового 
дослідження, що забезпечує всебічний аналіз проблеми та обґрунтованість 
отриманих результатів. Для аналізу предметної області використано методи 
системного аналізу та декомпозиції, що дозволило структурувати бізнес-процеси 
4 
 
салону краси та виявити ключові точки автоматизації. Метод системного аналізу 
передбачає розгляд об'єкта дослідження як цілісної системи взаємопов'язаних 
елементів, що дозволяє виявити синергетичні ефекти та потенційні вузькі місця. 
Для планування проєкту застосовано методи PMBOK, зокрема структура 
декомпозиції робіт (WBS) для ієрархічного розподілу обсягу проєкту, метод 
критичного шляху (CPM) для визначення мінімальної тривалості проєкту та 
ідентифікації критичних задач. Елементи Scrum-методології забезпечують 
гнучкість реагування на зміни вимог. Для аналізу факторів якості використано 
діаграму Ісікави (причинно-наслідкову діаграму). 
Економічну ефективність оцінено за допомогою методів інвестиційного 
аналізу, що включають розрахунок чистої приведеної вартості (NPV), 
внутрішньої норми дохідності (IRR), терміну окупності та аналізу чутливості 
ключових параметрів до зміни вхідних умов. 
Структура роботи. Кваліфікаційна робота складається зі вступу, трьох 
розділів, висновків, списку використаних джерел та додатків. Загальний обсяг 
роботи становить 46 сторінок основного тексту, містить 6 рисунків, 8 таблиць. 
Список використаних джерел включає 40 найменування. 
У першому розділі проводиться аналіз предметної області салонів краси, 
досліджуються існуючі рішення для автоматизації бізнес-процесів, виконується 
SWOT-аналіз проєкту, аналізуються сучасні технології веб-розробки та 
обґрунтовується вибір технологічного стеку. 
У другому розділі описується структура управління проєктом відповідно 
до стандартів PMBOK, включаючи управління змістом, часом, вартістю, 
ресурсами, якістю з побудовою діаграми Ісікави, ризиками та комунікаціями. 
У третьому розділі проводиться оцінювання економічної ефективності 
проєкту, техніко-економічне обґрунтування та аналіз чутливості ключових 
показників. 
  
5 
 
РОЗДІЛ 1 
АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ 
 
 
Сучасний ринок цифрових рішень для салонів краси пропонує велику 
кількість готових платформ, однак їх універсальність далеко не завжди 
відповідає реальним потребам конкретного бізнесу. Кожен салон має власні 
особливості організації роботи, підходи до обслуговування клієнтів та внутрішні 
правила управління, які складно реалізувати в межах стандартних програмних 
продуктів. 
У зв’язку з цим все більшої актуальності набуває розробка індивідуального 
програмного рішення. Хоча такий підхід потребує значніших початкових 
інвестицій і тривалішого періоду впровадження (від 3 до 6 місяців), він відкриває 
можливості для створення системи, повністю адаптованої до потреб конкретного 
салону краси. 
Індивідуальна розробка дозволяє точно відобразити бізнес-процеси 
закладу, реалізувати унікальні механізми роботи з клієнтами, системи лояльності 
та розподілу навантаження між майстрами. Окрім цього, вона забезпечує 
гнучкість інтеграції з зовнішніми сервісами та повний контроль над збереженням 
і використанням даних, що є критично важливим фактором у сучасних умовах 
цифрової безпеки. 
 
1.1. Огляд бізнес-процесів салону краси 
Салон краси є підприємством сфери послуг, основною діяльністю якого є 
надання косметологічних, перукарських, манікюрних та інших послуг з догляду 
за зовнішністю клієнтів. Сучасний салон краси функціонує як складна система 
взаємопов'язаних процесів, ефективність яких безпосередньо впливає на 
прибутковість бізнесу та рівень задоволеності клієнтів. 
Серед бізнес-процесів салону є управління записами клієнтів. Цей процес 
охоплює прийом заявок на надання послуг через різноманітні канали — телефон, 
6 
 
месенджери, соціальні мережі та особисте відвідування. Адміністратор повинен 
враховувати, хто з майстрів вільний, яку послугу надає кожен спеціаліст, скільки 
часу займе процедура. Окрім того, необхідно організувати нагадування клієнтам 
про заплановані візити та оперативно обробляти скасування і переноси записів. 
За статистикою галузі, від 10 до 15% клієнтів забувають про свій запис, що 
призводить до прямих фінансових втрат салону. 
Безпосереднє надання послуг становить ядро діяльності салону. Майстер 
консультує клієнта, виконує роботу відповідно до стандартів якості та фіксує 
надані послуги для подальшого обліку. На перший погляд, процес виглядає 
простим. Проте якщо помножити його на 10-15 клієнтів на день з різними 
послугами різної тривалості, отримаємо складну логістичну задачу, яка потребує 
автоматизації. 
Управління взаємовідносинами з клієнтами є критично важливим для 
довгострокового успіху салону. Хороший салон знає своїх клієнтів: хто коли 
приходив, що замовляв, які має вподобання. Ця інформація — золото для 
бізнесу: вона дозволяє персоналізувати обслуговування, пропонувати релевантні 
послуги та формувати лояльність. Реалізація програм лояльності у вигляді 
знижок, бонусних систем та акцій без автоматизації перетворюється на хаос з 
паперовими картками і записами в блокноті. 
Маркетинговий напрямок діяльності охоплює формування та підтримку 
іміджу салону, ведення соціальних мереж із демонстрацією портфоліо робіт, 
проведення рекламних кампаній та управління репутацією через роботу з 
відгуками. Фінансовий облік забезпечує розрахунки з клієнтами, облік витрат на 
матеріали, аналіз прибутковості послуг і майстрів. Управління персоналом 
доповнює цю систему процесами планування робочого часу та мотивації. 
Проведений аналіз показує, що значна частина цих процесів може бути 
автоматизована за допомогою веб-технологій, що обґрунтовує необхідність 
створення спеціалізованого сайту. 
 
 
7 
 
1.2. Огляд існуючих рішень для салонів краси 
MAIJA 
Сайт maija.ua — це офіційний вебресурс салону краси Maija Beauty Space. 
Він створений для того, щоб клієнт швидко отримав повну інформацію про 
салон, його послуги та спеціалістів. Сайт виконує роль онлайн-візитки, 
допомагає формувати позитивний імідж салону та залучати нових клієнтів. 
 
  
Рисунок 1.1 – Головна сторінка сайту maija.ua 
 
На сайті можна знайти детальний опис салону, перелік послуг та їх 
вартість, профілі майстрів та контактні дані. Дизайн сучасний і мінімалістичний, 
із великими фотографіями, зрозумілою структурою та інтуїтивною навігацією. 
Сайт адаптований для мобільних пристроїв, має можливість онлайн-запису та 
швидкого зв’язку з салоном. 
Крім цього, на сайті розміщені актуальні акції та новини салону, що сприяє 
залученню клієнтів і підтриманню їхньої зацікавленості. 
 
PIED-DE-POULE 
Сайт p-de-p.com є офіційним вебресурсом салону краси Pied-de-Poule 
Beauty Salon. Він створений для того, щоб клієнти могли швидко ознайомитися 
8 
 
з послугами салону та отримати всю необхідну інформацію про роботу закладу.  
Сайт виконує роль онлайн-візитки, сприяє формуванню довіри до салону та 
залученню нових клієнтів. 
 
  
Рисунок 1.2 – Головна сторінка сайту p-de-p.com 
 
На сайті розміщено перелік послуг салону, їхні ціни, інформацію про 
команду майстрів та контактні дані. Дизайн сучасний та стильний, із великими 
фотографіями інтер’єру та робіт майстрів, зрозумілою структурою та простою 
навігацією. Сайт адаптований для мобільних пристроїв, містить онлайн-запис і 
можливість швидкого зв’язку з салоном. 
Крім того, на сайті представлено новини, акції та спеціальні пропозиції, що 
допомагає підтримувати інтерес клієнтів. 
 
AVENTIN 
Сайт aventin.com.ua є офіційним вебресурсом салону краси Авентін, який 
діє у місті Львів. Він створений для того, щоб клієнт отримав повну інформацію 
про салон, спектр послуг, профілі майстрів та можливості обслуговування. 
Сайт сприяє формуванню позитивного іміджу салону та залученню нових 
відвідувачів завдяки продуманому представленню інформації. 
 
9 
 
 
Рисунок 1.3 – Головна сторінка сайту 
 
На сайті розміщено перелік послуг салону — від перукарських та 
косметологічних процедур до манікюру та педикюру, а також контакти й адресу 
салону у Львові. Дизайн і структура сторінок дозволяють легко знайти необхідну 
інформацію, зокрема контакти, графік роботи та опис напрямків обслуговування. 
Сайт адаптований для мобільних пристроїв і допомагає користувачеві швидко 
ознайомитися з послугами салону та зв’язатися для запису.  
 
1.3. Порівняльний аналіз розглянутих аналогів 
На ринку представлено значну кількість готових рішень для автоматизації 
діяльності салонів краси. Для систематизації порівняння обрано три провідні 
платформи представлені в таблиці 1.1. 
 
Таблиця 1.1 
Порівняльний аналіз для салонів краси 
Критерій / Сайт MAIJA  Pied-de-Poule  Авентін  
Онлайн-запис ✓ ✓ ✓ 
Мобільний додаток ✗ ✗ ✗ 
CRM / управління 
клієнтами ✗ ✗ ✗ 
SMS/Email 
нагадування ✓ ✓ ✗ 
10 
 
Сучасний, 
Дизайн мінімалістичний Сучасний, стильний Сучасний, зручний 
Перелік послуг, Перелік послуг, 
Перелік послуг, майстри, майстри, ціни, акції, майстри, ціни, 
Контент ціни, акції, новини новини контакти 
Навігація Інтуїтивна Логічна Не зручна 
Адаптивність / 
мобільні пристрої ✓ ✓ ✓ 
Новини, акції, портфоліо Новини, акції, Контактна форма, 
Додаткові функції робіт портфоліо робіт графік роботи 
 
На основі проведеного аналізу можна виділити наступні недоліки та 
обмеження розглянутих сайтів салонів краси: 
Відсутність повноцінної CRM-системи. Жоден з проаналізованих сайтів не 
має інтегрованого модуля управління взаємовідносинами з клієнтами. Це 
унеможливлює ведення детальної історії відвідувань, аналіз вподобань клієнтів 
та персоналізацію обслуговування. 
Обмежений функціонал особистого кабінету. Сайти не надають клієнтам 
можливості переглядати історію своїх візитів, відстежувати накопичені бонуси 
чи керувати своїми даними. Відсутність такого функціоналу знижує залученість 
клієнтів та ускладнює формування довгострокової лояльності. 
Відсутність мобільного додатку. У епоху мобільних технологій жоден з 
розглянутих салонів не пропонує власний мобільний додаток, що могло б значно 
покращити зручність взаємодії з клієнтами та підвищити їхню лояльність. 
 
1.4. Формування вимог веб-сайту салону краси. 
На основі аналізу бізнес-процесів сформовано наступні функціональні 
вимоги до веб-сайту: 
Для клієнтів: 
 Інформаційний блок: 
- перегляд переліку послуг з описом, тривалістю та вартістю; 
- галерея робіт (портфоліо) з можливістю фільтрації за типом послуг; 
- інформація про майстрів (фото, спеціалізація, досвід, сертифікати); 
11 
 
- контактна інформація та схема проїзду (інтеграція з картами); 
- інформація про акції, знижки та програми лояльності; 
- блог з порадами щодо догляду за зовнішністю. 
 Онлайн-запис: 
- вибір послуги зі списку; 
- вибір майстра або автоматичний підбір вільного спеціаліста; 
- перегляд доступних дат та часу в календарі; 
- підтвердження запису з отриманням повідомлення (email, SMS); 
- можливість скасування або перенесення запису; 
- нагадування про запис за день та за годину до візиту. 
 Особистий кабінет клієнта: 
- історія відвідувань та наданих послуг; 
- накопичені бонуси та знижки; 
- збережені дані для швидкого повторного запису; 
- можливість залишити відгук після відвідування. 
 
Для адміністрації салону. 
 Адміністративна панель: 
- управління розкладом майстрів та графіком роботи; 
- моніторинг записів у реальному часі; 
- управління базою клієнтів; 
- управління контентом сайту (послуги, ціни, акції, портфоліо); 
 CRM-функції: 
- автоматичні email/SMS-розсилки; 
- управління програмами лояльності; 
- аналітика клієнтської бази. 
Сформовані вимоги становлять основу для подальшого аналізу технологій 
та вибору оптимального технологічного стеку для реалізації проєкту. 
 
12 
 
 
Висновки до розділу 1 
Дослідження бізнес-процесів салону краси виявило, що ключові процеси 
управління записами, надання послуг, CRM, маркетинг, фінансовий облік та 
управління персоналом потребують автоматизації для підвищення ефективності 
та зменшення ризиків фінансових втрат. 
Огляд існуючих сайтів салонів (maija.ua, p-de-p.com, aventin.com.ua) 
показав, що сучасні вебресурси виконують роль онлайн-візитки, містять 
інформацію про послуги, майстрів та контакти, забезпечують онлайн-запис і 
адаптовані для мобільних пристроїв. Проте більшість сайтів не має 
інтегрованого CRM та мобільного додатку. 
Порівняльний аналіз демонструє, що жодна з існуючих платформ не 
забезпечує повну кастомізацію під унікальні потреби салону та контроль над 
усіма даними клієнтів, що підкреслює необхідність розробки індивідуального 
веб-рішення. 
На основі проведеного аналізу сформовані функціональні та 
нефункціональні вимоги до веб-сайту салону краси, які включають інформаційні 
блоки, онлайн-запис, особистий кабінет клієнта, адміністративну панель та 
CRM-функції, а також забезпечення продуктивності та безпеки даних. 
Розробка індивідуального сайту дозволить максимально адаптувати 
систему під потреби конкретного салону, автоматизувати ключові бізнес-
процеси та підвищити якість обслуговування клієнтів, що є стратегічною 
перевагою в умовах сучасного ринку. 
 
  
13 
 
РОЗДІЛ 2 
ДОСЛІДЖЕННЯ МЕТОДІВ УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ 
ВЕБ-САЙТУ 
 
 
2.1. Огляд сучасних методологій управління проєктами 
Управління проєктами як дисципліна зазнала значної еволюції протягом 
останніх десятиліть, сформувавши різноманітні підходи та методології, кожна з 
яких відповідає специфічним потребам організацій та проєктів. Вибір 
методології безпосередньо впливає на ефективність реалізації проєкту, його 
здатність адаптуватися до змін та досягнення бізнес-цілей у визначені терміни та 
в межах встановленого бюджету. 
Традиційні методології управління проєктами 
Традиційний підхід до управління проєктами сформувався у другій 
половині ХХ століття на основі практик будівництва та виробництва, де 
необхідна була чітка послідовність етапів та детальне попереднє планування. 
Центральним елементом цього підходу є стандарт PMBOK (Project Management 
Body of Knowledge), розроблений Project Management Institute. Даний стандарт 
представляє собою систематизовану сукупність знань та практик, що охоплюють 
весь життєвий цикл проєкту від ініціації до завершення. PMBOK структурує 
управління проєктом, забезпечуючи комплексний підхід до планування, 
виконання та контролю. 
Застосування PMBOK передбачає створення детальної проєктної 
документації, включаючи структуру декомпозиції робіт, календарний план, 
бюджет, реєстри ризиків та зацікавлених сторін. Основною перевагою цього 
підходу є можливість точного прогнозування термінів та витрат завдяки 
ретельному плануванню на початкових етапах. Проте така детальність вимагає 
значних часових витрат на підготовчу фазу та обмежує гнучкість реагування на 
зміни вимог, що особливо критично у динамічному середовищі розробки 
програмного забезпечення. 
14 
 
Каскадна модель розробки (Waterfall) є логічним продовженням філософії 
PMBOK, реалізуючи принцип послідовного виконання фаз проєкту. У класичній 
інтерпретації модель передбачає, що кожен етап – від збору та аналізу вимог 
через проєктування, реалізацію, тестування до впровадження та підтримки – має 
бути повністю завершений перед початком наступного. Така послідовність 
забезпечує чіткі контрольні точки та критерії прийняття результатів кожного 
етапу, що полегшує управління великими проєктами з добре визначеними 
вимогами. Водночас модель виявляється вразливою до змін вимог, оскільки 
повернення до попередніх етапів потребує значних додаткових витрат ресурсів 
та часу. 
Гнучкі методології управління проєктами 
На початку XXI століття у відповідь на обмеження традиційних підходів у 
сфері розробки програмного забезпечення сформувалася філософія Agile, яка 
кардинально переосмислила принципи управління проєктами. Agile Manifesto, 
сформульований у 2001 році, визначив нову систему цінностей, де 
пріоритетними стали взаємодія людей, працюючий продукт, співпраця з 
замовником та готовність до змін. Ця філософія не є конкретною методологією, 
а швидше представляє собою сукупність принципів, на основі яких розроблено 
різноманітні практичні фреймворки. 
Фундаментальні принципи Agile орієнтовані на забезпечення 
максимальної цінності для замовника через ранню та регулярну доставку 
працюючого програмного забезпечення. Методологія заохочує прийняття змін у 
вимогах на будь-якому етапі проєкту, розглядаючи це як конкурентну перевагу. 
Щоденна співпраця між бізнес-стороною та розробниками, довіра до 
мотивованих команд та безперервна увага до технічної досконалості складають 
основу цього підходу. Ретроспективний аналіз процесів дозволяє команді 
постійно вдосконалювати свою ефективність. 
Серед численних Agile-фреймворків найбільшого поширення набув Scrum, 
розроблений Кеном Швабером та Джефом Сазерлендом. Scrum організовує 
роботу через короткі ітерації фіксованої тривалості – спринти, що зазвичай 
15 
 
тривають від одного до чотирьох тижнів. Кожен спринт розпочинається 
плануванням, де команда визначає обсяг роботи, завершується оглядом 
результатів та ретроспективою процесу. Щоденні короткі синхронізаційні 
зустрічі забезпечують координацію діяльності команди та швидке вирішення 
перешкод. 
Структура ролей у Scrum чітко розмежовує відповідальність між 
учасниками проєкту. Product Owner відповідає за максимізацію бізнес-цінності 
продукту, визначає пріоритети вимог та приймає рішення про готовність 
функціональності. Scrum Master виступає фасилітатором процесу, забезпечуючи 
дотримання принципів Scrum та усунення перешкод для команди. Команда 
розробників є самоорганізованою та крос-функціональною, що означає наявність 
усіх необхідних компетенцій для створення повноцінного інкременту продукту 
без залежності від зовнішніх ресурсів. 
Альтернативним підходом у рамках Agile є Kanban, який фокусується на 
візуалізації робочого процесу та оптимізації потоку задач. На відміну від Scrum 
з його фіксованими ітераціями, Kanban пропонує безперервний потік, де задачі 
проходять через визначені стадії від початку до завершення. Ключовим 
елементом методу є обмеження кількості незавершеної роботи (Work In Progress 
Limits), що запобігає перевантаженню команди та виявляє вузькі місця у процесі. 
Метрики потоку, такі як час виконання задачі та пропускна здатність, 
дозволяють об'єктивно оцінювати ефективність та прогнозувати терміни 
виконання. 
Гібридні підходи до управління проєктами 
Практика управління проєктами продемонструвала, що жоден з описаних 
підходів не є універсальним рішенням для всіх типів проєктів та організаційних 
контекстів. Це призвело до формування гібридних методологій, які синтезують 
переваги різних підходів, адаптуючи їх до специфічних потреб конкретних 
проєктів. Такі методології дозволяють організаціям зберігати необхідний рівень 
контролю та передбачуваності, одночасно забезпечуючи гнучкість реагування на 
зміни. 
16 
 
Однією з поширених гібридних моделей є Water-Scrum-Fall, яка поєднує 
елементи каскадного підходу на стратегічному рівні з гнучкістю Scrum на 
тактичному. Після завершення підготовчої фази розпочинається ітераційна 
розробка за методологією Scrum, що дозволяє гнучко адаптувати деталі 
реалізації та регулярно отримувати зворотний зв'язок від замовника. Завершальні 
етапи тестування, прийняття та впровадження знову виконуються за 
структурованим каскадним підходом, що забезпечує необхідну формалізацію та 
контроль якості перед передачею продукту в експлуатацію. 
Інший гібридний варіант – Scrumban – інтегрує структурні елементи Scrum 
з принципами управління потоком з Kanban. Команда може зберігати практику 
спринтів для планування та ретроспектив, одночасно використовуючи 
візуалізацію Kanban-дошки та обмеження незавершеної роботи для оптимізації 
поточної діяльності. Такий підхід особливо ефективний для команд, що 
перебувають у перехідному періоді між методологіями, або для проєктів з 
нестабільним потоком вхідних задач. 
 
2.2. Порівняльний аналіз методологій для проєктів веб-розробки 
Специфіка веб-розробки створює унікальні вимоги до методології 
управління проєктами. Динамічність веб-технологій, мінливість користувацьких 
очікувань та необхідність швидкого виходу на ринок вимагають балансу між 
структурованим плануванням та гнучкістю реагування. Для об'єктивної оцінки 
придатності різних методологій для веб-проєктів необхідно розглянути їх через 
призму ключових факторів успіху. 
Здатність адаптуватися до змін вимог є критичним фактором у веб-
розробці, оскільки розуміння потреб користувачів часто уточнюється в процесі 
створення продукту. Традиційні методології демонструють низьку гнучкість, 
оскільки зміна вимог на пізніх стадіях потребує перегляду значної частини 
проєктної документації та може призвести до суттєвих затримок. Навпаки, Scrum 
та інші Agile-підходи розглядають зміни як природню частину процесу розробки, 
забезпечуючи механізми їх інкорпорації через регулярний перегляд пріоритетів 
17 
 
та короткі ітерації. Гібридні моделі пропонують компромісне рішення, фіксуючи 
високорівневий обсяг проєкту, але залишаючи простір для адаптації деталей 
реалізації. 
Час до отримання першого працюючого результату є важливою 
характеристикою, особливо для стартапів та проєктів з обмеженим 
фінансуванням. Каскадний підхід передбачає тривалу фазу аналізу та 
проєктування перед початком розробки, що відкладає момент, коли замовник 
може побачити та протестувати реальний продукт. Scrum забезпечує найшвидшу 
доставку початкового функціоналу, оскільки вже після першого спринту 
(зазвичай 2-4 тижні) команда демонструє працюючий інкремент. Це дозволяє 
рано виявити непорозуміння у вимогах та отримати зворотний зв'язок від 
реальних користувачів. 
Контроль бюджету та термінів має різну природу у різних методологіях. 
PMBOK надає потужні інструменти для створення детальних оцінок вартості та 
календарних планів, що особливо цінно для проєктів з фіксованою ціною. Однак 
точність цих оцінок залежить від стабільності вимог, яка рідко досягається на 
практиці. Agile-підходи забезпечують передбачуваність через емпіричні дані про 
продуктивність команди (velocity), дозволяючи прогнозувати обсяг 
функціональності, яку можна реалізувати за визначений час та бюджет. Гібридні 
моделі поєднують початкове детальне бюджетування з можливістю 
перерозподілу ресурсів між функціями у процесі реалізації. 
Залучення замовника до процесу розробки є одним з найбільш дискусійних 
аспектів вибору методології. Традиційний підхід передбачає інтенсивну 
взаємодію на етапах збору вимог та прийняття результатів, але мінімальну участь 
під час безпосередньої розробки. Це може призвести до ситуації, коли фінальний 
продукт формально відповідає затвердженим вимогам, але не задовольняє 
реальні потреби через зміни у бізнес-середовищі або еволюцію розуміння 
проблеми. Scrum вимагає активної та регулярної участі Product Owner, що 
забезпечує постійну синхронізацію розробки з бізнес-цілями, але може бути 
викликом для замовників з обмеженою доступністю. 
18 
 
Аналіз цих факторів у контексті веб-розробки демонструє, що жодна з 
«чистих» методологій не забезпечує оптимального балансу всіх характеристик. 
Каскадний підхід виявляється занадто ригідним для динамічного середовища 
веб-технологій. «Чистий» Scrum може створити надмірну невизначеність для 
замовників, які потребують чітких гарантій щодо вартості та термінів. Гібридні 
підходи, що поєднують стратегічне планування за PMBOK з тактичною 
гнучкістю Scrum, представляються найбільш збалансованим рішенням для 
більшості веб-проєктів, особливо середнього розміру з чітко визначеними 
бізнес-цілями, але деталями реалізації, що потребують уточнення. 
 
2.3. Обґрунтування вибору методології для проєкту розробки 
Проєкт розробки веб-сайту для салону краси характеризується 
специфічним набором умов та обмежень, що визначають оптимальний підхід до 
управління. Аналіз цих характеристик у поєднанні з висновками порівняльного 
дослідження методологій дозволяє сформулювати обґрунтоване рішення щодо 
вибору управлінського підходу. 
Контекст та обмеження проєкту 
Проєкт реалізується для діючого бізнесу з чітко визначеними процесами 
надання послуг та сформованою клієнтською базою. Це означає, що базові 
бізнес-вимоги до функціональності системи онлайн-запису, управління 
розкладом та обліку клієнтів можуть бути специфіковані з високим ступенем 
точності на початковому етапі. Власник салону як замовник має чітке уявлення 
про проблеми поточних процесів та очікування від автоматизації. Водночас 
деталі користувацького інтерфейсу, конкретні сценарії взаємодії та пріоритети 
між функціями другорядної важливості потребують уточнення в процесі 
розробки на основі прототипів та зворотного зв'язку. 
Фінансові обмеження проєкту визначені бюджетом приблизно 185 тисяч 
доларів США, що включає резервний фонд. Такий бюджет не передбачає 
можливості значних коригувань у процесі виконання, що вимагає точного 
початкового планування розподілу ресурсів. Одночасно необхідна гнучкість у 
19 
 
розподілі цього бюджету між конкретними функціональними можливостями 
залежно від їх фактичної бізнес-цінності, яка може уточнюватися в процесі 
демонстрації проміжних результатів. Орієнтовний термін реалізації у шість 
місяців також є відносно жорстким обмеженням, пов'язаним з бізнес-планами 
салону та сезонними факторами попиту на послуги. 
Склад команди розробки з шести фахівців (менеджер проєкту, backend-
розробник, frontend-розробник, UI/UX дизайнер, тестувальник та системний 
адміністратор) створює специфічні умови для організації робочого процесу. 
Невеликий розмір команди полегшує комунікацію та координацію, дозволяючи 
ефективно використовувати гнучкі практики без надмірних накладних витрат на 
церемонії та синхронізацію. Водночас обмежена кількість людських ресурсів 
вимагає чіткого планування завантаження та недопущення паралельної роботи 
над надто великою кількістю задач. 
Синтез методологічного підходу 
Аналіз характеристик проєкту приводить до висновку про доцільність 
застосування гібридного підходу, що інтегрує методи структурованого 
планування з PMBOK та практики ітераційної розробки зі Scrum. Така інтеграція 
не є механічним поєднанням елементів, а представляє собою продуману 
адаптацію кожного методу до відповідної фази проєкту та специфічних 
управлінських завдань. 
Застосування методів PMBOK концентрується на стратегічному рівні 
управління проєктом. Структура декомпозиції робіт створює ієрархічне подання 
всього обсягу проєкту, розбиваючи його на керовані компоненти від найвищого 
рівня (основні фази) до деталізованих робочих пакетів. Ця структура служить 
фундаментом для всіх подальших оцінок ресурсів, часу та вартості. Метод 
критичного шляху застосовується для аналізу взаємозалежностей між 
основними блоками робіт та визначення послідовності операцій, затримка яких 
критично вплине на загальні терміни проєкту. Діаграма Ганта забезпечує 
візуалізацію календарного плану та інструмент для моніторингу відповідності 
фактичного прогресу запланованому графіку. 
20 
 
Управління ризиками за методологією PMBOK передбачає систематичну 
ідентифікацію потенційних загроз успіху проєкту через структуровані сесії з 
командою та зацікавленими сторонами. Кожен виявлений ризик оцінюється за 
двома параметрами – ймовірністю настання та потенційним впливом на цілі 
проєкту. На основі цієї оцінки розробляються стратегії реагування, що можуть 
включати превентивні заходи для зниження ймовірності, планування дій для 
мінімізації впливу або формування резервів для компенсації наслідків. 
Регулярний перегляд реєстру ризиків дозволяє відслідковувати зміни у 
ймовірності та впливі, а також виявляти нові ризики, що з'являються в процесі 
виконання проєкту. 
Планування якості інтегрує підхід PMBOK до визначення стандартів та 
метрик з практиками безперервної інтеграції та автоматизованого тестування, 
характерними для Agile. Для кожного атрибуту якості (функціональність, 
продуктивність, надійність, безпека, зручність використання) визначаються 
конкретні вимірювані критерії та цільові показники. Ці критерії інкорпоруються 
у Definition of Done для задач розробки, забезпечуючи автоматичну перевірку 
відповідності стандартам якості на кожній ітерації. 
Застосування Scrum для фази розробки адресує необхідність гнучкості та 
регулярного зворотного зв'язку. Організація роботи у десять двотижневих 
спринтів створює ритм розробки з чіткими моментами планування, виконання, 
огляду та адаптації. Тривалість спринту в два тижні є компромісом між 
необхідністю достатнього часу для реалізації значущої функціональності та 
бажанням короткого циклу зворотного зв'язку. Кожен спринт розпочинається 
сесією планування, де Product Owner презентує пріоритизовані елементи з 
Product Backlog, а команда оцінює обсяг роботи та формує Sprint Backlog. 
Щоденні синхронізації тривалістю 15 хвилин забезпечують координацію 
діяльності членів команди та швидке виявлення перешкод. 
Завершення кожного спринту відзначається двома важливими 
церемоніями. Sprint Review представляє зацікавленим сторонам реалізовану 
функціональність у формі працюючого програмного забезпечення, а не 
21 
 
проєктної документації чи презентацій. Це дозволяє замовнику та потенційним 
кінцевим користувачам безпосередньо взаємодіяти з продуктом, оцінювати його 
відповідність очікуванням та формулювати коригування пріоритетів для 
наступних ітерацій. Sprint Retrospective фокусується на аналізі процесу розробки, 
виявленні проблем у взаємодії команди, інструментарії або практиках, та 
формулюванні конкретних покращень для впровадження у наступному спринті. 
Переваги інтегрованого підходу 
Синтез методів PMBOK та Scrum створює управлінський підхід, що 
максимізує переваги обох методологій, одночасно мінімізуючи їх недоліки у 
контексті специфіки даного проєкту. Стратегічне планування за PMBOK 
забезпечує замовнику необхідну впевненість у контролі бюджету та термінів 
через детальну початкову оцінку та чіткий календарний план. Водночас тактична 
гнучкість Scrum дозволяє адаптувати деталі реалізації без необхідності 
формальних процедур зміни базового плану проєкту, якщо загальний обсяг робіт 
залишається в межах визначеного WBS. 
Ітераційний характер розробки за Scrum забезпечує раннє виявлення 
ризиків та проблем, коли їх усунення потребує мінімальних витрат. Якщо після 
другого-третього спринту виявляється, що обрана технологія не забезпечує 
необхідної продуктивності або певний підхід до користувацького інтерфейсу не 
відповідає очікуванням, це можна скоригувати без катастрофічних наслідків для 
проєкту. У каскадній моделі подібні проблеми зазвичай виявляються на етапі 
інтеграційного тестування, коли значна частина розробки вже виконана, що 
робить виправлення надзвичайно дорогим. 
Регулярні демонстрації працюючого продукту підтримують залученість 
замовника та формують довіру до команди розробки. Коли власник салону 
бачить конкретний прогрес кожні два тижні, а не тільки читає статусні звіти, це 
створює відчуття контролю та можливості впливу на результат. Така прозорість 
також полегшує спільне прийняття рішень про компроміси між 
функціональністю, якістю та термінами, якщо такі рішення стають необхідними 
в процесі реалізації. 
22 
 
Інтеграція практик контролю якості у щоденний робочий процес через 
Definition of Done та автоматизоване тестування забезпечує накопичення 
технічного боргу. Кожен інкремент функціональності відповідає встановленим 
стандартам якості, що виключає ситуацію, характерну для каскадної моделі, 
коли виявлення великої кількості дефектів на етапі тестування призводить до 
тривалих циклів виправлень та затримки релізу. 
Адаптації методології до організаційного контексту 
Ефективне застосування обраного методологічного підходу вимагає 
певних адаптацій до розміру команди та специфіки проєкту. Обсяг документації 
оптимізовано відносно повного набору документів PMBOK, зберігаючи тільки 
критично важливі артефакти: структуру декомпозиції робіт, інтегрований 
календарний план, детальний бюджет, реєстр ризиків та план управління якістю. 
User stories у Product Backlog виконують функцію детальної специфікації вимог, 
усуваючи необхідність у окремому обширному документі технічного завдання. 
Структура ролей адаптована до невеликого розміру команди через 
суміщення функцій. Менеджер проєкту виконує також обов'язки Scrum Master, 
що є природним поєднанням, оскільки обидві ролі фокусуються на процесі та 
усуненні перешкод для команди. Власник салону як замовник виступає у ролі 
Product Owner, що забезпечує пряму комунікацію бізнес-потреб без проміжних 
ланок. Така структура мінімізує накладні витрати на координацію, одночасно 
зберігаючи всі необхідні функції управління. 
Гнучкість у управлінні обсягом реалізована через фіксацію загального 
періметру функціональності на рівні WBS з можливістю перерозподілу деталей 
між спринтами. Якщо в процесі розробки виявляється, що певна функція має 
вищу бізнес-цінність, ніж початково передбачалося, Product Owner може 
підвищити її пріоритет, відповідно знизивши пріоритет інших елементів з 
еквівалентною трудомісткістю. Така гнучкість обмежена загальним бюджетом 
та календарним планом, що забезпечує баланс між адаптивністю та 
передбачуваністю. 
 
23 
 
Висновки до розділу 2 
У другому розділі проведено комплексне дослідження сучасних 
методологій управління проєктами та сформульовано обґрунтований вибір 
підходу для проєкту розробки веб-сайту салону краси. Аналіз продемонстрував, 
що кожна з розглянутих методологій має специфічні сфери оптимального 
застосування, а вибір підходу повинен базуватися на характеристиках 
конкретного проєкту та організаційного контексту. 
Традиційні методології, представлені стандартом PMBOK та каскадною 
моделлю, забезпечують структурованість планування та чіткість контролю через 
детальну початкову специфікацію обсягу робіт, термінів та бюджету. Однак їх 
обмежена гнучкість до змін вимог та пізнє отримання зворотного зв'язку 
створюють значні ризики у динамічному середовищі веб-розробки. Гнучкі 
методології Agile, зокрема Scrum та Kanban, пропонують ітераційний підхід з 
регулярною доставкою працюючого продукту та можливістю адаптації до змін, 
але можуть створювати невизначеність щодо фінальних термінів та вартості для 
замовників з фіксованим бюджетом. Гібридні підходи синтезують переваги обох 
напрямків, дозволяючи поєднати стратегічне планування з тактичною гнучкістю. 
Порівняльний аналіз методологій за критеріями гнучкості до змін, часу до 
першого результату, контролю бюджету, залучення замовника та складності 
впровадження виявив, що для веб-проєктів середнього розміру з частково 
визначеними вимогами оптимальним є гібридний підхід. Специфіка проєкту 
розробки сайту салону краси – наявність чітких бізнес-цілей при необхідності 
уточнення деталей реалізації, фіксований бюджет при потребі гнучкості у 
пріоритизації функцій, невелика команда розробки – підтверджує доцільність 
такого вибору. 
Обраний методологічний підхід інтегрує методи PMBOK для 
стратегічного планування та управління обмеженнями проєкту з практиками 
Scrum для організації ітераційного процесу розробки. Структура декомпозиції 
робіт, метод критичного шляху, діаграма Ганта, управління ризиками та 
планування якості за PMBOK забезпечують необхідну структурованість та 
24 
 
контроль на рівні всього проєкту. Організація розробки у десять двотижневих 
спринтів, регулярні демонстрації результатів, щоденні синхронізації команди та 
ретроспективний аналіз процесу за Scrum забезпечують гнучкість, швидкий 
зворотний зв'язок та безперервне вдосконалення. 
Переваги інтегрованого підходу включають баланс між передбачуваністю 
та адаптивністю, раннє виявлення проблем, підтримання залученості замовника 
через регулярні демонстрації, інтеграцію контролю якості у щоденний процес та 
природну мотивацію команди через відчуття прогресу. Адаптації методології до 
контексту проєкту включають оптимізацію обсягу документації, суміщення 
ролей відповідно до розміру команди та механізм гнучкої пріоритизації функцій 
у межах фіксованого загального обсягу. 
Розроблений методологічний підхід створює фундамент для детального 
планування та реалізації проєкту розробки веб-сайту салону краси, що буде 
представлено в наступному розділі через конкретні плани управління змістом, 
часом, вартістю, якістю та ризиками проєкту. 
  
25 
 
РОЗДІЛ 3 
УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ САЙТУ САЛОНУ КРАСИ 
 
 
У цьому розділі розглядається детальне планування та організація 
управління проєктом розробки веб-сайту для салону краси згідно з обраною 
гібридною методологією (PMBOK + Scrum). Описуються ключові процеси 
управління проєктом відповідно до десяти областей знань PMBOK: управління 
змістом, часом, вартістю, ресурсами, якістю, комунікаціями, ризиками, 
закупівлями, зацікавленими сторонами та інтеграцією проєкту. 
 
3.1. Склад учасників та їх ролі у проєкті 
Ефективне управління проєктом розпочинається з чіткої ідентифікації всіх 
зацікавлених сторін та розуміння їхніх інтересів і впливу на проєкт. Згідно зі 
стандартом PMBOK, зацікавлені сторони (стейкхолдери) — це особи, групи або 
організації, які можуть впливати на проєкт, зазнавати впливу від нього або 
вважати себе такими, що зазнають впливу від рішень, дій чи результатів 
проєкту.[14] 
Власник салону виступає одночасно замовником та спонсором проєкту, 
що визначає його ключову роль у прийнятті стратегічних рішень. Його головні 
інтереси полягають у збільшенні прибутку через залучення нових клієнтів, 
автоматизації рутинних процесів для зниження операційних витрат та 
формуванні сучасного іміджу закладу. Вплив власника на проєкт є 
максимальним: він приймає фінальні рішення щодо функціоналу, затверджує 
бюджет та терміни, погоджує дизайн та підписує акти приймання-передачі. 
Стратегія взаємодії з власником передбачає тісну співпрацю через щотижневі 
демонстрації результатів на Sprint Review та обов'язкове залучення до прийняття 
ключових рішень на етапах планування та приймання. 
Майстри салону є кінцевими користувачами системи, які працюватимуть 
з нею щодня для перегляду свого розкладу, отримання інформації про клієнтів 
26 
 
та фіксації наданих послуг. Їхні інтереси полягають у зрозумілому та зручному 
інтерфейсі, коректній роботі нагадувань та мінімізації часу на адміністративні 
задачі. Важливість цієї групи стейкхолдерів часто недооцінюється, проте саме 
від їхнього сприйняття системи залежить реальний успіх впровадження. Якщо 
майстрам буде незручно працювати з системою, вони саботуватимуть її 
використання, і проєкт не досягне своїх цілей. Стратегія взаємодії включає 
залучення представників майстрів на етап збору вимог для розуміння їхніх 
потреб, проведення воркшопів з UX/UI для валідації дизайн-рішень та участь у 
приймальному тестуванні перед запуском. 
Адміністратор салону є головним користувачем адміністративної панелі 
та виконує роль оператора системи. Він працює з базою клієнтів, управляє 
записами, формує звіти та координує роботу майстрів. Від якості зворотного 
зв'язку адміністратора залежить, чи буде система реально корисною в 
повсякденній роботі салону. Адміністратор залучається до інтерв'ю на етапі 
аналізу вимог для детального розуміння поточних процесів, а також бере активну 
участь у приймальному тестуванні та навчанні інших співробітників. 
Команда розробки є виконавцем проєкту та включає менеджера проєкту, 
backend-розробника, frontend-розробника, UX/UI-дизайнера та QA-інженера. 
Члени команди зацікавлені в чітких та стабільних вимогах, адекватних термінах 
виконання та своєчасній оплаті. 
Клієнти салону є кінцевими споживачами публічної частини сайту та 
системи онлайн-запису. Саме заради покращення їхнього досвіду створюється 
веб-сайт. Клієнти хочуть записатися швидко і без необхідності телефонувати, 
бачити актуальний вільний час, отримувати нагадування про візит та мати 
можливість переглянути історію своїх відвідувань.  
 
3.2. Формування структури декомпозиції робіт (WBS) 
Структура декомпозиції робіт (Work Breakdown Structure, WBS) є 
ієрархічною декомпозицією загального обсягу проєкту на керовані компоненти. 
Згідно зі стандартом PMBOK, WBS організовує та визначає повний зміст 
27 
 
проєкту, розбиваючи його на менші, більш керовані елементи. Кожен наступний 
рівень декомпозиції представляє все більш детальне визначення проєктної 
роботи. 
 
Рисунок 3.1  ієрархічна діаграма WBS 
 
WBS проєкту розробки сайту для салону краси: 
Ініціація проєкту 
- Розробка концепції проєкту 
- Формування команди 
- Затвердження бюджету та термінів 
Планування 
- Збір та аналіз вимог 
- Проєктування архітектури системи 
- UX/UI дизайн 
- Планування спринтів 
Розробка (Development) 
- Налаштування середовища розробки 
- Backend розробка 
- Frontend розробка 
- Інтеграції 
Впровадження (Deployment) 
- Підготовка production середовища 
- Міграція даних 
28 
 
- Розгортання додатку 
- Навчання користувачів 
Підтримка (Post-Launch Support) 
- Моніторинг роботи системи (перші 30 днів) 
- Виправлення критичних помилок 
- Надання технічної підтримки 
Кожен рівень WBS може бути розбитий на робочі пакети (Work Packages) 
з призначенням відповідальних осіб, оцінкою трудомісткості та термінів 
виконання. 
 
3.3. Управління часом проєкту. 
На основі WBS та експертних оцінок тривалості формується календарний 
план проєкту. Загальна тривалість становить приблизно сто двадцять робочих 
днів, що еквівалентно двадцяти чотирьом тижням або близько шести місяців 
календарного часу з урахуванням вихідних та свят. 
Основні етапи проєкту та їх тривалість: 
Таблиця 3.1 
Основні етапи проєкту 
Тривалість Попередні Ранній Ранній Пізній Пізній 
№ Етап (днів) етапи Старт  Фініш  Фініш  Старт  Критичний 
1 Ініціація проєкту 5 - 1 5 5 1 Так 
2 Планування 10 1 6 15 15 6 Так 
3 Дизайн (UX/UI) 15 2 16 30 30 16 Так 
Налаштування 
4 середовища 3 2 16 18 42 40 Ні 
5 Backend розробка 40 3, 4 31 70 70 31 Так 
6 Frontend розробка 45 3 31 75 75 31 Так 
7 Інтеграції 10 5, 6 76 85 85 76 Так 
8 Тестування 15 7 86 100 100 86 Так 
9 Виправлення багів 10 8 101 110 110 101 Так 
10 Впровадження 5 9 111 115 115 111 Так 
29 
 
11 Навчання користувачів 3 9 111 113 117 115 Ні 
12 Закриття проєкту 2 10, 11 116 117 117 116 Так 
Загальна тривалість проєкту: ~120 робочих днів (24 тижні / ~6 місяців) 
Деякі роботи можуть виконуватись паралельно (наприклад, backend та 
frontend розробка після завершення дизайну), що оптимізує загальний термін 
проєкту. 
 
3.4 Розробка розкладу проєкту 
На основі оцінок тривалості та залежностей будується календарний план 
проєкту з використанням діаграми Ганта. 
Діаграма Ганта проєкту розробки сайту салону краси: 
 
Рисунок 3.2  Діаграма Ганта 
 
Критичний шлях проєкту (Critical Path Method - CPM): 
Ініціація → Планування → Дизайн → Frontend та Backend розробка → 
Інтеграції → Тестування → Виправлення → Впровадження → Закриття 
Загальна тривалість критичного шляху: 115 робочих днів 
30 
 
Будь-яка затримка на критичному шляху призводить до затримки всього 
проєкту. 
 
3.5 Scrum-планування: спринти та їх структура 
Фаза розробки організована у вигляді спринтів фіксованої тривалості два 
тижні, що становить десять робочих днів. Загальна кількість спринтів у фазі 
розробки десять. Така структура забезпечує регулярний ритм поставок та 
можливість адаптації до змін вимог. 
Швидкість команди визначається емпірично після перших двох-трьох 
спринтів як середня кількість Story Points, виконаних за спринт. Очікувана 
швидкість становить сорок Story Points на спринт, що базується на досвіді 
аналогічних проєктів та розмірі команди. 
Перший спринт присвячується налаштуванню інфраструктури та 
закладенню фундаменту системи. До нього входять налаштування середовища 
розробки з конфігурацією репозиторію та CI/CD, створення базової структури 
проєкту для frontend та backend, реалізація моделі даних для користувачів та 
авторизації, а також базова інтеграція між frontend та backend. 
Другий спринт фокусується на системі аутентифікації та головній 
сторінці. Реалізується реєстрація та вхід користувачів, відновлення пароля, 
верстка та наповнення головної сторінки, а також сторінка з переліком послуг. 
Третій та четвертий спринти охоплюють ядро системи — функціонал 
онлайн-запису. Реалізується календар доступності майстрів, вибір послуги та 
майстра, підтвердження запису з email-нотифікацією, а також особистий кабінет 
клієнта з історією записів. 
П'ятий та шостий спринти присвячені адміністративній панелі. 
Створюється дашборд з ключовими метриками, управління розкладом майстрів, 
управління послугами та цінами, а також перегляд та управління записами. 
Сьомий та восьмий спринти охоплюють інтеграції та розширений 
функціонал. Реалізується інтеграція з платіжною системою для онлайн-оплати, 
31 
 
SMS-нагадування через Twilio, програма лояльності з бонусами, а також система 
відгуків. 
Дев'ятий спринт фокусується на аналітиці та звітності. Створюються 
звіти по фінансах, завантаженості майстрів та популярності послуг, а також 
експорт даних. 
Десятий спринт є фінальним та присвячений полірування продукту. 
Виконується оптимізація продуктивності, виправлення накопичених багів, 
підготовка до production-деплою та документування. 
 
3.6 Управління вартістю проєкту 
Оцінка вартості проєкту 
Загальні витрати на персонал становлять сто шістдесят три тисячі двісті 
доларів, що складає вісімдесят вісім відсотків від загального бюджету проєкту. 
Склад команди проєкту представлені у таблиці 3.2. Додаткові витрати 
проєкту представлені у таблиці 3.3. 
Таблиця 3.2 
Склад команди та погодинні ставки 
Ставка Робочі години Вартість Частка 
Роль Кількість ($/год) Завантаженість (година) (ФОП) ($) (%) 
Backend Developer 
(Senior) 1 40 100% 960 48 29.4% 
Менеджер проєкту 
(PM/SM) 1 25 50% 960 38,4 23.5% 
Frontend Developer 
(Middle) 1 25 100% 960 38,4 23.5% 
QA Engineer 1 20 75% 720 21,6 13.2% 
UX/UI Designer 1 15 50% 480 16,8 10.3% 
РАЗОМ 5 - - 3,6 163,2 100.0% 
 
 
 
 
32 
 
 
 
Таблиця 3.3 
Додаткові витрати проєкту: 
Базова 
Категорія Опис Вартість ($) Примітки 
Хостинг (6 міс. для Dev + Staging), 
Інфраструктура домен, SSL-сертифікат 600 Базове розгортання середовища. 
Інтеграція сторонніх 
Twilio (SMS-сповіщення), SendGrid комунікаційних та платіжних 
Сервіси та API (Email-розсилка), тестові платежі 400 сервісів. 
Figma Pro (дизайн), GitHub Team 
Інструменти (контроль версій), ліцензії JetBrains Витрати на професійне програмне 
розробки (IDE) 800 забезпечення. 
Cypress Dashboard, BrowserStack Забезпечення якості та покриття 
Тестування (кросбраузерне тестування) 300 тестів. 
Sentry (відстеження помилок), 
Моніторинг та LogRocket (моніторинг сесій Проактивний пошук та 
Логування користувачів) 200 виправлення проблем. 
Непередбачені Запас на непередбачувані 
витрати 10% від 230 технічні/операційні проблеми. 
ЗАГАЛЬНИЙ Всі витрати проєкту на 
БЮДЖЕТ (А + 10%) 2,53 інструменти та інфраструктуру. 
 
3.7. Управління якістю проєкту 
Планування якості 
Якість програмного забезпечення визначається ступенем відповідності 
продукту встановленим вимогам та очікуванням користувачів. Згідно зі 
стандартом ISO 25010, якість програмного продукту характеризується вісьмома 
атрибутами: функціональною придатністю, ефективністю продуктивності, 
сумісністю, зручністю використання, надійністю, безпекою, супроводжуваністю 
та переносимістю. 
Для проєкту сайту салону краси визначено конкретні критерії якості за 
кожним релевантним атрибутом. Функціональна придатність вимірюється 
33 
 
повнотою реалізації вимог зі специфікації, коректністю роботи бізнес-логіки та 
відсутністю критичних дефектів. Ефективність продуктивності характеризується 
часом завантаження сторінки не більше трьох секунд, часом відгуку API не 
більше двохсот мілісекунд та здатністю системи обслуговувати до ста 
одночасних користувачів. Зручність використання оцінюється через показник 
успішності виконання ключових сценаріїв не менше дев'яноста п'яти відсотків та 
середній час виконання запису не більше двох хвилин. Надійність визначається 
доступністю системи на рівні дев'яносто дев'ять і п'ять десятих відсотка та 
середнім часом відновлення після збою не більше однієї години. Безпека 
забезпечується шифруванням усіх з'єднань через HTTPS, захистом від типових 
веб-вразливостей та відповідністю вимогам захисту персональних даних. 
 
Таблиця 3.4 
Інструменти контролю якості 
Категорія Призначення Інструменти 
1. Якість та Стиль Коду 
  
Статичний аналіз коду (Static Виявлення помилок та потенційних проблем у коді 
Analysis) до його виконання. ESLint, TypeScript 
Форматування коду (Code Забезпечення єдиного, послідовного стилю коду в 
Formatting) усій команді. Prettier 
2. Тестування (QA) 
  
Тестування окремих компонентів, модулів та Jest, React Testing 
Unit-тестування функцій ізольовано. Library 
Імітація дій реального користувача для тестування 
End-to-End (E2E) тестування всього шляху в системі через UI. Cypress / Playwright 
Навантажувальне тестування (Load Перевірка продуктивності та стабільності системи 
Testing) під високим навантаженням. k6, Artillery 
3. Безпека (Security) 
  
Виявлення відомих вразливостей у залежностях npm audit, Snyk, 
Сканування вразливостей (бібліотеках) та коді. OWASP ZAP 
4. Автоматизація та Співпраця 
(DevOps / Collaboration) 
  
34 
 
Peer review змін у коді для виявлення логічних 
помилок, покращення архітектури та обміну GitHub Pull 
Code Review (Рецензування коду) знаннями. Requests 
CI/CD (Continuous Автоматизація збірки, тестування та деплойменту 
Integration/Deployment) коду на різні середовища (Dev, Staging, Production). GitHub Actions 
 
3.8. Управління ризиками проєкту 
Ідентифікація ризиків 
Управління ризиками є критичним елементом проєктного менеджменту, 
що дозволяє проактивно реагувати на потенційні проблеми до того, як вони 
стануть реальністю. Згідно зі стандартом PMBOK, ризик — це невизначена подія 
або умова, яка у разі виникнення матиме позитивний або негативний вплив на 
цілі проєкту.[10] 
 
Рисунок 3.3  Гістограма ризиків 
 
Ідентифіковано основні ризики проєкту, класифіковані за трьома 
категоріями: організаційні ризики, технічні ризики та ризики управління. 
35 
 
Організаційні ризики пов'язані з людським фактором та бізнес-
середовищем. 
Ризик зміни вимог замовника є одним з найбільш імовірних, оскільки 
власник салону може не мати чіткого бачення на початку проєкту і уточнювати 
свої потреби в процесі розробки.  
Ризик звільнення ключового розробника може критично вплинути на 
проєкт через втрату знань та необхідність пошуку заміни. Ризик недоступності 
замовника для консультацій може затримувати прийняття рішень та валідацію 
результатів. 
Таблиця 3.5 
Реєстр ризиків проєкту 
ID Ризик Категорія Ймовірність  Вплив Рейтинг  План реагування 
Уникнення / Зменшення. 
Заморозити вимоги після 
Планування (Етап 2). 
Впровадити суворий контроль 
Зміна вимог у змін, що вимагає повторної 
R01 процесі розробки Організаційний 0.7 (Висока) 8 (Високий) 5.6 оцінки термінів та вартості. 
Зменшення. Провести 
Затримка тестування (Етап 8) та 
впровадження заздалегідь підготувати план 
через технічні 0.5 відкату перед Впровадженням 
R02 проблеми Технічний (Середня) 8 (Високий) 4.0 (Етап 10).  
Зменшення. Забезпечити 
резервування ресурсів та обмін 
Хвороба знаннями (cross-training). 
ключового 0.4 Регулярно оновлювати 
R03 розробника Організаційний (Середня) 5 (Середній) 2.0 документацію та сховище коду. 
Зменшення. Провести раннє 
тестування API (Proof of 
Проблеми Concept) на етапі Дизайну (Етап 
інтеграції зі 0.5 3) або Налаштування 
R04 сторонніми API Технічний (Середня) 6 (Середній) 3.0 середовища (Етап 4). 
Перевитрата Проєктне 0.4 Зменшення. Встановити 
R05 бюджету управління (Середня) 9 (Високий) 3.6 щотижневий контроль бюджету. 
36 
 
Виділити окрему статтю на 
непередбачені витрати 
(Contingency Reserve). 
Зменшення. Включити 
навантажувальне тестування 
(Load Testing) у пайплайн 
Недостатня (використовуючи k6/Artillery). 
продуктивність Провести оптимізацію бази 
R06 системи Технічний 0.2 (Низька) 7 (Високий) 1.4 даних на ранніх етапах. 
Уникнення / Передача. 
Впровадити шифрування даних 
у спокої та транзиті. Регулярний 
Витік аудит безпеки (Snyk, OWASP 
персональних 10 ZAP). Розглянути страхування 
R07 даних клієнтів Безпека 0.1 (Низька) (Критичний) 1.0 від кіберризиків. 
Зменшення. Регулярні 
демонстрації та зустрічі із 
замовником (Sprint Reviews). 
Незадоволення Підтвердження приймання 
замовника 0.3 результатів після кожного 
R08 результатом Організаційний (Середня) 8 (Високий) 2.4 значного етапу (Етап 3, Етап 6). 
 
Ризики управління пов'язані з плануванням та контролем проєкту. Ризик 
перевищення бюджету може виникнути через недооцінку трудомісткості або 
непередбачені витрати. Ризик затримки термінів може бути спричинений 
технічними складностями або змінами у вимогах. Ризик невідповідності 
очікуванням замовника може виникнути через комунікаційні проблеми. 
 
3.9. Вибір технологій веб-розробки 
Архітектурні підходи до побудови веб-додатків 
Сучасні веб-додатки будуються на основі різних архітектурних підходів, 
кожен з яких має свої особливості: 
Монолітна архітектура 
- весь функціонал реалізується в межах єдиного додатку; 
- переваги: простота розробки та розгортання, зручність для малих проєктів; 
37 
 
- недоліки: складність масштабування, залежність компонентів, ризик 
каскадних збоїв. 
Клієнт-серверна архітектура з Server-Side Rendering (SSR) 
- рендеринг HTML відбувається на сервері; 
- переваги: краще SEO, швидше початкове завантаження; 
- недоліки: більше навантаження на сервер, менша інтерактивність. 
 
SPA (Single Page Application, CSR) — це веб-додаток, де сторінка 
завантажується один раз, а далі все оновлюється в браузері за допомогою 
JavaScript. Сервер в основному віддає дані (API), а інтерфейс будується на 
клієнті. 
 Переваги: швидкі переходи, плавний інтерфейс, менше навантаження на 
сервер. 
 Недоліки: довге перше завантаження, гірше SEO, високе навантаження на 
пристрій користувача. 
Мікросервісна архітектура. Додаток розбивається на множину 
незалежних сервісів, кожен відповідає за свою функцію. Кожен сервіс можна 
розробляти, оновлювати та масштабувати окремо. 
 Переваги: висока масштабованість, гнучкість, незалежність команд та 
технологій. 
 Недоліки: складна інфраструктура, важка відлагодження та моніторинг, 
більше мережевих взаємодій. 
Порівняння технологій frontend-розробки. Frontend-фреймворки 
використовуються для створення інтерактивних користувацьких інтерфейсів у 
браузері. Вони керують логікою відображення, станом додатку та взаємодією з 
користувачем. До основних відносяться React, Vue.js та Angular, зазначені нижче 
в таблиці 3.6 
Таблиця 3.6 
Порівняльний аналіз frontend-фреймворків 
38 
 
Критерій React Vue.js Angular 
Прогресивний Повноцінний 
Тип Бібліотека 
фреймворк фреймворк 
Рік створення 2013 2014 2016 
TypeScript Опціонально Опціонально За замовчуванням 
Архітектура Компонентна Компонентна MVC / компонентна 
Підтримка 
Через Next.js Через Nuxt.js Через Angular Universal 
SSR 
Поріг входу Середній Низкий Високий 
Популярність 
220K+ 204K+ 94K+ 
(GitHub stars) 
 
Рекомендація: Для проєкту сайту салону краси обрано React у поєднанні 
з Next.js, оскільки ця зв’язка забезпечує серверний рендеринг сторінок (SSR) та 
покращує SEO і швидкість першого завантаження. React має велику екосистему 
компонентів і широку підтримку спільноти, що зменшує ризики підтримки 
проєкту. 
Для стилізації інтерфейсу використовується Tailwind CSS, який дозволяє 
швидко створювати адаптивний дизайн та підтримувати єдиний стиль.Material 
UI, Ant Design, Styled-components та SCSS/SASS не обрані як основні, оскільки 
вони або нав’язують готову стилістику, або ускладнюють підтримку без суттєвої 
користі для проєкту такого масштабу. 
 
3.10 Технології backend-розробки 
Backend-фреймворки використовуються для реалізації серверної логіки, 
роботи з базами даних, обробки запитів клієнтів та інтеграції зі сторонніми 
сервісами. Вони відповідають за бізнес-логіку системи, безпеку, 
масштабованість та стабільність роботи веб-додатку.  
Найпоширенішими рішеннями є Node.js (Express/Nest.js), Django та Laravel 
які наведенні в таблиці 3.7 
Таблиця 3.7 
39 
 
Порівняльний аналіз backend-технологій 
Критерій Node.js (Express) Django (Python) Laravel (PHP) 
Продуктивність Висока Середня Середня 
Масштабованість Висока Середня Середня 
Залежить від 
Безпека Висока Висока 
розробника 
Асинхронність Так Частково Ні 
Підтримка REST 
Висока Висока Висока 
API 
Порог входу Середній Середній Низький 
 
Бази даних: 
Реляційні (SQL): 
PostgreSQL – найфункціональніша відкрита СУБД, підтримка JSON; 
MySQL/MariaDB – популярна, швидка для читання; 
SQLite – для малих проєктів. 
Нереляційні (NoSQL): 
MongoDB – документоорієнтована, гнучка схема; 
Redis – in-memory, для кешування та черг завдань. 
 
Рекомендація для проєкту: Для проєкту обрано Node.js з Nest.js та 
TypeScript як backend-фреймворк, що забезпечує високу продуктивність та єдину 
мову для frontend і backend.  
Як основну базу даних використовується PostgreSQL для надійного 
зберігання структурованих даних з підтримкою транзакцій, а Redis — для 
кешування. Django та Laravel не підходять через обмежену підтримку 
асинхронності та real-time функціоналу. 
 
3.11. Додаткові технології та сервіси 
Додаткові технології забезпечують розширення функціоналу веб-додатку, 
інтеграцію зі сторонніми сервісами та покращення користувацького досвіду. 
40 
 
Вони охоплюють аутентифікацію, платіжні системи, повідомлення та 
інфраструктуру розгортання. 
 
 
Аутентифікація 
Системи аутентифікації забезпечують безпечний доступ користувачів до 
системи та управління сесіями. 
 JWT (JSON Web Tokens) — stateless аутентифікація з токенами, що 
зберігаються на клієнті. 
 OAuth 2.0 / OpenID Connect — стандарт для соціальних логінів (Google, 
Facebook). 
 Passport.js — бібліотека для Node.js з підтримкою різних стратегій 
аутентифікації. 
Платіжні системи 
Платіжні системи дозволяють приймати онлайн-платежі від клієнтів за 
послуги салону. 
 Stripe — міжнародна платіжна система зі зручним API та широкою 
підтримкою валют. 
 LiqPay — популярна в Україні, підтримка карт Visa/Mastercard та онлайн-
банкінгу. 
Системи повідомлень 
Сервіси повідомлень використовуються для надсилання нагадувань, 
підтверджень та промо-акцій клієнтам. 
 Twilio / MessageBird — SMS-повідомлення з високою доставляємістю. 
 SendGrid / Mailgun — email-розсилки з підтримкою шаблонів та 
аналітики. 
 Firebase Cloud Messaging — push-повідомлення для мобільних додатків та 
браузерів. 
Хостинг та деплоймент 
41 
 
Платформи хостингу забезпечують розгортання, масштабування та 
підтримку веб-додатку в продакшені. 
 Vercel / Netlify — спеціалізовані платформи для frontend (Next.js, React, 
SPA) з автоматичним CI/CD. 
 Heroku / Railway / Render — PaaS-рішення для швидкого деплою backend 
(Node.js, Python). 
 DigitalOcean / AWS / Google Cloud — повноцінні VPS та хмарні сервіси з 
гнучкими налаштуваннями. 
 Docker + Kubernetes — контейнеризація додатків та оркестрація для 
складних інфраструктур. 
Рекомендація для проєкту 
Для проєкту обрано JWT через Passport.js для аутентифікації, LiqPay як 
основну платіжну систему (орієнтація на український ринок), SendGrid для 
email-розсилок та Twilio для SMS-нагадувань. 
Для хостингу використовується Vercel (frontend) та Railway (backend) 
завдяки простоті інтеграції з GitHub та автоматичному деплою. Docker 
використовується для локальної розробки та забезпечення однакового 
середовища на всіх етапах. 
 
Висновки до розділу 3 
У третьому розділі розроблено комплексний план управління проєктом 
розробки веб-сайту для салону краси, що охоплює всі ключові області знань 
проєктного менеджменту відповідно до стандартів PMBOK. 
У сфері управління змістом проєкту ідентифіковано п'ять груп 
зацікавлених сторін (власник салону, майстри, адміністратор, клієнти та команда 
розробки) та створено структуру декомпозиції робіт (WBS), що включає п'ять 
основних фаз: ініціацію, планування, розробку, впровадження та підтримку. Така 
декомпозиція забезпечує чітке розуміння обсягу робіт та дозволяє ефективно 
розподілити відповідальність між членами команди. 
42 
 
Управління часом проєкту реалізовано через застосування методології 
Scrum із десятьма двотижневими спринтами загальною тривалістю 120 робочих 
днів. Визначено критичний шлях проєкту тривалістю 115 днів, що включає 
послідовні етапи від ініціації до впровадження. Використання діаграми Ганта 
дозволяє візуалізувати взаємозв'язки між задачами та виявляти можливості для 
паралельного виконання робіт. 
Планування якості базується на визначенні конкретних метрик за 
атрибутами функціональності, продуктивності, надійності, зручності 
використання, безпеки та сумісності. Запропоновано комплекс інструментів 
контролю якості, що включає автоматизоване тестування, code review, статичний 
аналіз коду та моніторинг продуктивності. 
Управління ризиками включає ідентифікацію та аналіз організаційних, 
технічних та ризиків управління з визначенням їх впливу, імовірності та 
стратегій реагування. Створено реєстр ризиків із пріоритизацією за рівнем 
загрози та конкретними планами мітигації для кожного виявленого ризику. 
Технологічний стек проєкту обґрунтовано на основі порівняльного аналізу 
сучасних рішень. Обрано React з Next.js для frontend, Node.js з TypeScript для 
backend та PostgreSQL для бази даних, що забезпечує баланс між 
продуктивністю, масштабованістю та доступністю розробників на ринку праці. 
Розроблений план управління проєктом забезпечує структурований підхід 
до реалізації веб-сайту салону краси, мінімізує ризики невдачі проєкту та 
створює передумови для успішного досягнення поставлених цілей у визначені 
терміни та в межах затвердженого бюджету. 
 
  
43 
 
ВИСНОВКИ 
 
 
У кваліфікаційній роботі магістра вирішено актуальне науково-практичне 
завдання планування та реалізації проєкту розробки веб-сайту для салону краси 
шляхом застосування сучасних методологій управління проєктами та 
обґрунтованого вибору технологічного стеку. В процесі написання 
кваліфікаційної роботи магістра були виконані наступні завдання:  
Проаналізовано предметну область — досліджено специфіку 
функціонування салону краси як підприємства сфери послуг із комплексною 
системою взаємопов’язаних бізнес-процесів. 
Визначено ключові бізнес-процеси, що потребують автоматизації, 
зокрема: управління записами клієнтів, надання послуг, CRM-функції, 
маркетинг, фінансовий облік та управління персоналом. 
Досліджені існуючі рішення (maija.ua, p-de-p.com, aventin.com.ua) та 
проведений їх порівняльний аналіз, зокрема їхнього функціоналу, структури 
та дизайнерських рішень. Виявлено переваги та недоліки проаналізованих 
рішень. 
Сформовано вимоги до веб-сайту салону краси для двох категорій 
користувачів — клієнтів та адміністрації, з урахуванням вимог до 
продуктивності, безпеки, надійності та масштабованості. 
Досліджено сучасні методології управління проєктами, включно з 
традиційними (PMBOK, Waterfall), гнучкими (Scrum, Kanban) та гібридними 
підходами. 
Проведено порівняльний аналіз методологій управління веб-проєктами 
за критеріями гнучкості, швидкості реалізації, контролю бюджету та рівня 
залучення замовника. 
Обґрунтовано вибір оптимальної методології управління проєктом з 
розробки сайту для салону краси. 
44 
 
Розроблено структуру управління проєктом, що включає ієрархічну 
структуру робіт (WBS), календарний план тривалістю 120 робочих днів, бюджет 
проєкту, реєстр ризиків та систему показників якості. 
Проведено порівняльний аналіз сучасних технологій та обґрунтовано 
вибір оптимального технологічного стеку для реалізації проєкту: React з Next.js 
для frontend, Node.js з TypeScript для backend та PostgreSQL для зберігання даних. 
Виявлено ключові бізнес-процеси салону краси, що потребують 
автоматизації: управління записами клієнтів, CRM-функціонал, маркетинг та 
просування, фінансовий облік. Сформовано функціональні вимоги до веб-сайту 
для двох категорій користувачів (клієнти та адміністрація) та нефункціональні 
вимоги щодо продуктивності (час завантаження < 3 сек), надійності (доступність 
99,5%), безпеки (GDPR, SSL, захист від XSS/SQL-injection) та масштабованості 
системи. 
Досліджено існуючі рішення для салонів краси та проведено 
порівняльний аналіз технологій. 
Огляд сайтів салонів краси (maija.ua, p-de-p.com, aventin.com.ua) показав, 
що сучасні вебресурси виконують роль онлайн-візитки. Проте більшість сайтів 
не має інтегрованого CRM та мобільного додатку. 
Провівши аналіз та зробивши формування вимог, появилась можливість 
покращити послуки салонів краси. 
Обґрунтовано вибір оптимального технологічного стеку для реалізації 
проєкту. 
На основі порівняльного аналізу обрано технологічний стек: 
- Frontend: React 18 + Next.js 13 (SSR для SEO), TypeScript, Tailwind CSS; 
- Backend: Node.js 18 LTS + Nest.js, PostgreSQL 15, Redis, Prisma ORM; 
- Інтеграції: LiqPay (платежі), Twilio (SMS), SendGrid (email); 
- DevOps: Docker, GitHub Actions, Vercel/Railway. 
Таким чином обрана єдина мова програмування (JavaScript/TypeScript) для 
всього стеку, висока продуктивність, велика екосистема, підтримка real-time 
функціоналу через WebSocket. 
45 
 
Виконано планування всіх областей знань управління проєктом за 
PMBOK: 
- Управління змістом: ідентифіковано 8 груп зацікавлених сторін, 
розроблено стратегії взаємодії; 
- Управління часом: побудовано мережевий графік, визначено критичний 
шлях; 
- Управління вартістю: розраховано бюджет проєкту $184,680 (витрати на 
персонал 88.4%, додаткові витрати 11.6%); 
- Управління ресурсами: сформовано команду (PM, 2 розробники, 
дизайнер, QA), визначено ставки та завантаження; 
- Управління якістю: встановлено стандарти (покриття тестами >80%, 
Lighthouse Score >90); 
- Управління ризиками: ідентифіковано 10 ризиків, розроблено стратегії 
реагування для ризиків з рейтингом >4.0. 
Таким чином мета кваліфікаційної роботи магістра: побудова ефективного 
процесу управління проєктом розробки сайту для салону краси шляхом адаптації 
сучасних методологій управління проєктами та обґрунтованого вибору 
технологічного стеку на основі аналізу специфічних вимог предметної області, 
була досягнута. 
 
 
  
46 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
 
1. ДСТУ ISO 21500:2014. Настанови з управління проектами (ISO 21500:2012, 
IDT). Київ : ДП «УкрНДНЦ», 2014. 23 с. 
2. ДСТУ ISO/IEC 12207:2016. Інформаційні технології. Процеси життєвого 
циклу програмного забезпечення (ISO/IEC 12207:2008, IDT). Київ : ДП 
«УкрНДНЦ», 2017. 95 с. 
3. ДСТУ ISO/IEC 25010:2015. Інженерія систем і програмних засобів. Вимоги до 
якості систем і програмних засобів та їх оцінювання (SQuaRE). Моделі якості 
систем і програмних засобів (ISO/IEC 25010:2011, IDT). Київ : ДП «УкрНДНЦ», 
2016. 36 с. 
4. Бушуєв С. Д., Бушуєв Д. А., Ярошенко Р. Ф. Управління проектами: основи 
професійних знань та система оцінки компетенції проектних менеджерів. 3-тє 
вид. Київ : ІРІДІУМ, 2018. 208 с. 
5. The Standish Group. CHAOS Report 2020: Beyond Infinity. The Standish Group 
International, 2020. 24 p. 
6. Serrador P., Pinto J. K. Does Agile work? A quantitative analysis of agile project 
success. International Journal of Project Management. 2015. Vol. 33, No. 5. P. 1040–
1051. DOI: 10.1016/j.ijproman.2015.01.006. 
7. Conforto E. C., Salum F., Amaral D. C. Can Agile Project Management Be Adopted 
by Industries Other than Software Development? Project Management Journal. 2014. 
Vol. 45, No. 3. P. 21–34. DOI: 10.1002/pmj.21410. 
8. Dingsøyr T., Nerur S., Balijepally V., Moe N. B. A decade of agile methodologies: 
Towards explaining agile software development. Journal of Systems and Software. 
2012. Vol. 85, No. 6. P. 1213–1221. DOI: 10.1016/j.jss.2012.02.033. 
9. Fernandez D. J., Fernandez J. D. Agile Project Management — Agilism versus 
Traditional Approaches. Journal of Computer Information Systems. 2008. Vol. 49, No. 
2. P. 10–17. 
47 
 
10. ЗАСТОСУВАННЯ ПІДХОДІВ PMBoK URL: https://www.business-
inform.net/export_pdf/business-inform-2023-10_0-pages-366_374.pdf? 
11. Мельник О. В. Методичні підходи до оцінки ефективності ІТ-проєктів. 
Економіка та держава. 2021. № 3. С. 45–51. DOI: 10.32702/2306-6806.2021.3.45. 
12. React Documentation. URL: https://react.dev/learn (дата звернення: 15.11.2024). 
13. Next.js Documentation. URL: https://nextjs.org/docs (дата звернення: 
15.11.2024). 
14. Вісник Національного технічного університету URL: 
https://library.kpi.kharkov.ua/files/Vestniki/2018_45.pdf (дата звернення: 
16.11.2024). 
15. PostgreSQL Documentation. URL: https://www.postgresql.org/docs/current/ (дата 
звернення: 16.11.2024). 
16. TypeScript Documentation. URL: https://www.typescriptlang.org/docs/ (дата 
звернення: 17.11.2024). 
17. Prisma Documentation. URL: https://www.prisma.io/docs (дата звернення: 
17.11.2024). 
18. Tailwind CSS Documentation. URL: https://tailwindcss.com/docs (дата 
звернення: 18.11.2024). 
19. State of JavaScript 2023 Survey. URL: https://stateofjs.com/en-US (дата 
звернення: 20.11.2024). 
20. Stack Overflow Developer Survey 2024. URL: 
https://survey.stackoverflow.co/2024/ (дата звернення: 20.11.2024). 
21. Booksy for Business. URL: https://booksy.com/biz/ (дата звернення: 22.11.2024). 
22. Fresha for Business. URL: https://www.fresha.com/for-business (дата звернення: 
22.11.2024). 
23. Vagaro Business Solutions. URL: https://www.vagaro.com/pro/business (дата 
звернення: 23.11.2024). 
24. SimplyBook.me. URL: https://simplybook.me/ (дата звернення: 23.11.2024). 
25. GitHub Actions Documentation. URL: https://docs.github.com/en/actions (дата 
звернення: 25.11.2024). 
48 
 
26. Docker Documentation. URL: https://docs.docker.com/ (дата звернення: 
25.11.2024). 
27. Vercel Documentation. URL: https://vercel.com/docs (дата звернення: 
26.11.2024). 
28. LiqPay API Documentation. URL: https://www.liqpay.ua/documentation (дата 
звернення: 28.11.2024). 
29. Twilio API Documentation. URL: https://www.twilio.com/docs (дата звернення: 
28.11.2024). 
30. SendGrid API Documentation. URL: https://docs.sendgrid.com/ (дата звернення: 
29.11.2024). 
31. Google Lighthouse. URL: https://developer.chrome.com/docs/lighthouse (дата 
звернення: 30.11.2024). 
32. Web Content Accessibility Guidelines (WCAG) 2.1. URL: 
https://www.w3.org/TR/WCAG21/ (дата звернення: 01.12.2024). 
33. OWASP Top Ten. URL: https://owasp.org/www-project-top-ten/ (дата 
звернення: 02.12.2024). 
34. Jest Testing Framework. URL: https://jestjs.io/docs/getting-started (дата 
звернення: 03.12.2024). 
35. Cypress E2E Testing. URL: https://docs.cypress.io/ (дата звернення: 03.12.2024). 
36. Project Management Institute. A Guide to the Project Management Body of 
Knowledge (PMBOK Guide). 7th ed. Newtown Square, PA : PMI, 2021. 370 p. 
37. Highsmith J. Agile Project Management: Creating Innovative Products. 2nd ed. 
Boston : Addison-Wesley, 2010. 336 p. 
38. Nielsen J. Usability Engineering. Boston : Academic Press, 1994. 362 p. 
39. Krug S. Don’t Make Me Think: A Common Sense Approach to Web Usability. 
3rd ed. Berkeley : New Riders, 2014. 216 p. 
40. Preece J., Rogers Y., Sharp H. Interaction Design: Beyond Human-Computer 
Interaction. 4th ed. Wiley, 2015. 720 p. 
49
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
