1. Repository at ChSTU
  2. Випускні кваліфікаційні роботи
  3. Магістр
  4. 126 Інформаційні системи та технології (IT Project Management)
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7030
Title: Управління проєктом розробки ігрового web-застосунку з можливістю монетизації ігрового час
Authors: Катаєв, Дмитро Сергійович
Анікін, Іван Андрійович
Keywords: управління проєктом;розробка;web-застосунок;EVM-аналіз;побудова WBS
Issue Date: 17-Dec-2025
Abstract: Магістерська кваліфікаційна робота на тему: ‘‘Управління проєктом розробки ігрового web-застосунку з можливістю монетизації ігрового часу’’. Метою роботи є розробка, обґрунтування та формування цілісного підходу до управління IT-проєктом зі створення інноваційного веб-застосунку GGame, що забезпечує пошук геймерів-партнерів та дає можливість монетизувати ігровий час за допомогою надання послуг у геймінговому середовищі. Актуальність теми обумовлена швидким розвитком індустрії цифрових розваг, зростанням попиту на онлайн-взаємодію та потребою у створенні платформ, здатних поєднати ігрову активність із сучасними економічними моделями. У роботі розглянуто ключові процеси управління IT-проєктом: аналіз предметної області, планування змісту, ресурсів, строків та вартості, управління якістю, ризиками, комунікаціями, персоналом та інтеграцією. Детально досліджено застосування принципів оцінювання (EVM-аналіз), критичного шляху, побудови WBS та формування ключових артефактів управління (SOW, Scope, Estimate, Budget, RACI-матриця, Risk Register). Практичне значення одержаних результатів полягає у формуванні реального, комплексного та адаптивного підходу до управління розробкою складних веб-застосунків у сфері цифрових сервісів. Розроблені моделі, плани та артефакти можуть бути використані у майбутніх IT-проєктах, що поєднують соціальні та комерційні функції, а також у навчальному процесі з дисциплін проєктного менеджменту та розробки інформаційних систем.
URI: https://er.chdtu.edu.ua/handle/ChSTU/7030
Appears in Collections:126 Інформаційні системи та технології (IT Project Management)

Files in This Item:
File Description SizeFormat 
РЕП_МАГ_ Анікін_МІТ-2411.pdf
  Restricted Access		1.73 MBAdobe PDFView/Open Request a copy
Show full item record


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.

Extracted text 
   
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ  
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІЕРСИТЕТ  
  
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ  
  
  
Кафедра інформаційних технологій проектування  
  
  
  
  
Пояснювальна записка  
до кваліфікаційної роботи  
  
  
_____________________________магістра_____________________________  
  (освітньо-кваліфікаційний рівень)  
  
  
на тему: Управління проєктом розробки ігрового web-застосунку з можливістю 
монетизації ігрового часу  
  
  
  
  
  
Виконав: здобувач другого   
(магістровського) рівня освіти  
Спеціальність 126 “Інформаційні  
системи та технології”  
ОП «IT Project Management»  
Анікін Івана Андрійовича  
(прізвище та ініціали)  
  
  
                                      Керівник  ______Катаєв Д.С._______  
                                                                              (прізвище та ініціали)  
   
                                 Рецензент  _____Гавриш О.С._____  
                                                                             (прізвище та ініціали)  
  
  
  
Черкаси – 2025 року  
2 
 
  
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ  
(назва вузу)  
  
Факультет       ФІТІС                                                                                                                      
Кафедра       Інформаційних технологій проектування                                                           
Освітній рівень       бакалавр                                                                                                                  
Спеціальність       126 “Інформаційні системи та технології”                                                          
Освітня програма      “Web-технології Web-дизайн”                                                                              
  
ЗАТВЕРДЖУЮ:  
зав.Кафедри Прокопенко Т.О.  
“______” __________________2025р.  
  
ЗАВДАННЯ  
На кваліфікаційну роботу студенту  
  
                                             Анікіну Івану Андрійовичу                                               
(прізвище, ім’я, по-батькові)  
  
1. Тема проекту (роботи) Управління проєктом розробки ігрового web-застосунку з можливістю 
монетизації ігрового часу                                                                                                                          
Керівник проекту(роботи)      Катаєв Дмитро Сергійович                                                    
Затверджена наказом Черкаського державного технологічного університету № 307/03 - 03 
від 07.10.2025 
  
2. Строк подання студентом роботи  12 грудня 2025 р. 
  
3. Вихідні дані до проекту (роботи) стандарти управління проєктами; процеси управління 
проєктом; управління командою проєкту; календарне планування проєкту; управління ризиками 
проєкту; управління ресурсами проєкту.                                                                                                 
  
4. Зміст розрахунково-пояснювальної записки (перелік питань, що належить розробити)  
ВСТУП;                                                                                                                                                       
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ                                      
РОЗДІЛ 2 УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ ВЕБ-ЗАСТОСУНКУ GGAME                          
РОЗДІЛ 3 ОЦІНЮВАННЯ ЕФЕКТИВНОСТІ ТА РЕЗУЛЬТАТІВ УПРАВЛІННЯ ІТ-
ПРОЄКТОМ                                                                                                                                                
ВИСНОВКИ; СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ;                                                                         
  
5.Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень)  
1) Котнкурени проєкту  
2) Персони  
3) WBS проєкту  
   
3 
 
 
6. Консультанти розділів роботи  
Розділ  Прізвище, ініціали та посада Підпис, дата  
консультанта  
    завдання видав  завдання прийняв  
        
        
        
        
  
7. Дата видачі завдання  01.11.2025 р.   
    
КАЛЕНДАРНИЙ ПЛАН  
№з/п  Назва етапів  Строк виконання Примітка  
кваліфікаційної роботи  етапів роботи  
1.1  Постановка задачі  24.09.2025  виконано  
1.2  Підготовка завдання  29.09.2025  виконано  
1.3  Погодження завдання  01.10.2025  виконано  
1.4  Затвердження завдання  03.10.2025  виконано  
2  Основна стадія      
2.1  Підбір матеріалів  17.10.2025  виконано  
2.2  Оцінка можливих варіантів вирішення 21.10.2025  виконано  
поставленої задачі  
2.3  Розрахунок основних параметрів рішення  01.11.2025  виконано  
2.4  Вибір кінцевого варіанту проєктного рішення  05.11.2025  виконано  
2.5  Оформлення первісної редакції кваліфікаційної 23.11.2025  виконано  
роботи  
3  Заключна стадія      
3.1  Узгодження щодо прийнятих проєктних рішень  25.11.2025  виконано  
3.2  Оформлення пояснювальної записки до 01.12.2025  виконано  
кваліфікаційної роботи у заключній редакції  
3.3  Попередній захист кваліфікаційної роботи  08.12.2025  виконано  
3.4  Затвердження кваліфікаційної роботи  10.12.2025  виконано  
3.5  Рецензування кваліфікаційної роботи  12.12.2025  виконано  
3.6  Захист кваліфікаційної роботи  17.12.2025  виконано  
  
Здобувач вищої освіти         _______________                                    
                              (підпис)                                     (прізвище та ініціали)  
 
Керівник роботи                   _______________                                   
           (підпис)                                       (прізвище та ініціали)  
  
  
  
4 
 
 
АНОТАЦІЯ 
 
Структура та обсяг роботи. Пояснювальна записка складається з Вступу,  3 
розділів, Висновків та списку використаних джерел. Загальний обсяг роботи 
складає 126 сторінок, 5 рисунків, 13 таблиць, 51 використаних джерел та без 
додатків 
Магістерська кваліфікаційна робота на тему: ‘‘Управління проєктом 
розробки ігрового web-застосунку з можливістю монетизації ігрового часу’’. 
Метою роботи є розробка, обґрунтування та формування цілісного підходу 
до управління IT-проєктом зі створення інноваційного веб-застосунку GGame, що 
забезпечує пошук геймерів-партнерів та дає можливість монетизувати ігровий час 
за допомогою надання послуг у геймінговому середовищі. Актуальність теми 
обумовлена швидким розвитком індустрії цифрових розваг, зростанням попиту на 
онлайн-взаємодію та потребою у створенні платформ, здатних поєднати ігрову 
активність із сучасними економічними моделями. 
У роботі розглянуто ключові процеси управління IT-проєктом: аналіз 
предметної області, планування змісту, ресурсів, строків та вартості, управління 
якістю, ризиками, комунікаціями, персоналом та інтеграцією. Детально досліджено 
застосування принципів оцінювання (EVM-аналіз), критичного шляху, побудови 
WBS та формування ключових артефактів управління (SOW, Scope, Estimate, 
Budget, RACI-матриця, Risk Register). 
Практичне значення одержаних результатів полягає у формуванні реального, 
комплексного та адаптивного підходу до управління розробкою складних веб-
застосунків у сфері цифрових сервісів. Розроблені моделі, плани та артефакти 
можуть бути використані у майбутніх IT-проєктах, що поєднують соціальні та 
комерційні функції, а також у навчальному процесі з дисциплін проєктного 
менеджменту та розробки інформаційних систем.  
5 
 
 
ANNOTATION 
 
Structure and scope of the paper. The explanatory note consists of an Introduction, 
3 chapters, Conclusions and a list of references. The total volume of the work is 126 
pages, 5 figures, 13 tables, 51 references and no appendices.  
Master's qualification work on the topic: “Project management for the development 
of a gaming web application with the possibility of monetizing gaming time”. 
The purpose of the study is to develop, justify, and establish an integrated approach 
to managing an IT project aimed at creating the innovative web application GGame, 
which enables users to find gaming partners and monetize their gameplay time by 
providing services within the gaming environment. The relevance of the topic is driven 
by the rapid growth of the digital entertainment industry, the increasing demand for online 
interaction, and the need to create platforms capable of combining gaming activity with 
modern economic models. 
The thesis examines the key processes of IT project management, including domain 
analysis, scope, resource, schedule, and cost planning, as well as quality, risk, 
communication, personnel, and integration management. Particular attention is given to 
the application of evaluation principles (EVM analysis), critical path method, WBS 
development, and the formation of essential project management artifacts (SOW, Scope, 
Estimate, Budget, RACI matrix, Risk Register). 
The practical significance of the results lies in the development of a realistic, 
comprehensive, and adaptive approach to managing the creation of complex web 
applications in the digital services domain. The proposed models, plans, and artifacts can 
be applied in future IT projects that combine social and commercial functions, as well as 
in the educational process within courses on project management and information 
systems development. 
  
6 
 
 
ЗМІСТ 
ВСТУП ................................................................................................................................................................... 8 
Актуальність теми ............................................................................................................................................. 8 
Мета та задачі дослідження .............................................................................................................................. 9 
Об’єкт дослідження ........................................................................................................................................... 9 
Предмет дослідження ........................................................................................................................................ 9 
Методи дослідження ....................................................................................................................................... 10 
Наукова новизна одержаних результатів ...................................................................................................... 10 
Практичне значення одержаних результатів ................................................................................................ 11 
Апробація роботи ............................................................................................................................................ 11 
РОЗДІЛ 1  АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ .............................................. 12 
1.1 Аналіз предметної області ........................................................................................................................ 12 
1.2 Огляд аналогів ........................................................................................................................................... 14 
1.3 Порівняння аналогів .................................................................................................................................. 20 
1.4 Постановка задачі ...................................................................................................................................... 26 
1.5 Аналіз проєкту ........................................................................................................................................... 29 
Висновок до розділу 1 ..................................................................................................................................... 37 
РОЗДІЛ 2  УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ ВЕБ-ЗАСТОСУНКУ GGAME .................................. 39 
2.1 Управління змістом ................................................................................................................................... 39 
2.1.1 Обсяг робіт проєкту (Scope) .............................................................................................................. 39 
2.1.2 Statement of Work (SOW) ................................................................................................................... 42 
2.1.3 Робоча структура проєкту (WBS) ..................................................................................................... 47 
2.1.4 Deliverables (очікувані результати проєкту) .................................................................................... 49 
2.2 Управління ресурсами .............................................................................................................................. 52 
2.2.1 Трудові ресурси проєкту .................................................................................................................... 52 
2.2.2 Матеріальні ресурси проєкту ............................................................................................................ 54 
2.2.3 Оцінка ресурсоємності проєкту ........................................................................................................ 56 
2.2.4 Управління залученням та використанням ресурсів ....................................................................... 61 
7 
 
2.3 Управління часом ...................................................................................................................................... 64 
2.4 Управління вартістю ................................................................................................................................. 66 
2.5 Управління якістю ..................................................................................................................................... 74 
2.6 Управління ризиками ................................................................................................................................ 77 
2.7 Управління комунікаціями ....................................................................................................................... 81 
2.8 Управління персоналом ............................................................................................................................ 85 
2.9 Управління інтеграцією проєкту.............................................................................................................. 91 
Висновки до розділу 2 ..................................................................................................................................... 93 
РОЗДІЛ 3  ОЦІНЮВАННЯ ЕФЕКТИВНОСТІ ТА РЕЗУЛЬТАТІВ  УПРАВЛІННЯ ІТ-ПРОЄКТОМ ....... 96 
3.1 Загальні результати реалізації проєкту ................................................................................................... 96 
3.2 Аналіз відхилень у проєкті ....................................................................................................................... 99 
3.3 Оцінювання ефективності управління ресурсами ................................................................................ 103 
3.4 Оцінювання якості процесів та продукту ............................................................................................. 105 
3.5 Оцінювання управління ризиками ......................................................................................................... 109 
3.6 Інтеграція продукту та взаємодія з користувачами.............................................................................. 113 
3.7 Підсумкова оцінка ефективності проєкту ............................................................................................. 116 
Висновки до розділу 3 ................................................................................................................................... 119 
ВИСНОВКИ ....................................................................................................................................................... 121 
ДЖЕРЕЛА .......................................................................................................................................................... 124 
 
  
8 
 
 
ВСТУП 
 
Актуальність теми 
 
Сфера комп’ютерних ігор сьогодні є одним із найбільш швидкозростаючих 
сегментів цифрової економіки [1]. Вона охоплює мільйони користувачів різного 
віку, рівня досвіду та професійних інтересів, формуючи нові соціальні, 
технологічні й економічні моделі взаємодії [2]. З розвитком онлайн-ігор, 
стрімінгових платформ та кіберспорту зростає потреба у сервісах, які здатні 
забезпечити ефективний пошук партнерів для гри, створити комфортне 
середовище взаємодії та надати нові можливості для професійної ігрової 
діяльності, включно з монетизацією ігрового часу. 
У той час як ігрова індустрія активно розвивається, ринок платформ для 
пошуку партнерів залишається недостатньо сформованим. Існуючі аналоги часто 
мають обмежений функціонал, відсутність інноваційних сервісів, низьку зручність 
використання, проблеми з безпекою або нерозвинені механізми монетизації. У 
результаті існує чітка потреба в сучасному веб-застосунку, який поєднує функції 
пошуку партнерів, соціальної взаємодії, професійних послуг і фінансових 
механізмів. 
У цьому контексті створення веб-застосунку GGame, що дозволяє 
користувачам знаходити партнерів для гри та надавати/отримувати платні 
геймерські послуги, є актуальним завданням. Дослідження управління проєктом 
такого продукту дає можливість сформувати чіткий підхід до організації робіт, 
вибору технологій, управління ризиками, ресурсами й термінами розробки. Це 
робить тему дипломної роботи важливою як з теоретичного, так і з практичного 
погляду у сфері сучасних інформаційних технологій. 
 
 
9 
 
Мета та задачі дослідження 
 
Метою дослідження є обґрунтування та розробка ефективних підходів до 
управління проєктом створення ігрового веб-застосунку GGame з можливістю 
монетизації ігрового часу, включаючи планування, організацію, моделювання та 
реалізацію ключових процесів розробки. 
Для досягнення мети поставлено такі основні задачі: 
 Аналізувати предметну область і тенденції розвитку веб-сервісів для гравців 
 Провести огляд аналогічних платформ і визначити їх переваги та недоліки 
 Сформулювати концепцію веб-застосунку, вимоги до функціональності та 
якості 
 Виконати SWOT- та PEST-аналіз для визначення чинників впливу на проєкт 
 Розробити архітектуру та логічну модель системи 
 Побудувати структуру робіт (WBS) та виконати оцінку тривалості завдань 
 Сформувати план реалізації проєкту з використанням методів CPM/PERT 
 Визначити ключові ризики та заходи їх мінімізації 
 Розробити економічне обґрунтування створення веб-застосунку GGame 
 
Об’єкт дослідження 
 
Об’єктом дослідження є процес управління ІТ-проєктом зі створення веб-
застосунку, орієнтованого на взаємодію користувачів у сфері комп’ютерних ігор та 
надання геймерських послуг. 
 
Предмет дослідження 
 
Предметом дослідження є методи, моделі та інструменти управління 
проєктом, що забезпечують ефективну організацію, планування, контроль та 
10 
 
реалізацію веб-застосунку GGame з урахуванням функціональних, технічних та 
бізнес-вимог. 
 
Методи дослідження 
 
У роботі використано комплекс методів, які забезпечують системність, 
наукову обґрунтованість та практичну цінність отриманих результатів: 
 Аналіз наукових джерел та інформаційних ресурсів - для вивчення сучасних 
підходів до управління ІТ-проєктами, архітектури веб-застосунків, UX/UI-
технологій та моделей монетизації 
 Порівняльний аналіз - оцінка функціональних та технічних характеристик 
аналогічних веб-платформ 
 Системний аналіз - формування вимог та проектування структури застосунку 
 Методи моделювання - для створення WBS, діаграм діяльності та 
архітектурних схем 
 Метод оцінки тривалості робіт (PERT, Three-Point Estimation) - для 
планування та розрахунку строків проєкту 
 Методи ризик-менеджменту - для визначення загроз, та їх оцінки 
 Економічні методи - аналіз фінансової вигоди та планування витрат 
 
Наукова новизна одержаних результатів 
 
Наукова новизна роботи полягає в комплексному підході до управління 
проєктом створення ігрового веб-застосунку, який поєднує: 
 Розробці комплексної моделі управління проєктом створення ігрового веб-
застосунку з монетизацією ігрового часу 
 Поєднанні методів проєктного менеджменту з принципами UX/UI та 
сучасними підходами веб-розробки 
11 
 
 Формуванні унікальної структури вимог до багатофункціонального 
геймерського застосунку 
 Застосуванні комбінованих методів оцінки тривалості та ресурсів для 
реалізації проєкту 
 Інтеграції моделей ризик-менеджменту в процес планування розробки 
складної цифрової системи 
Отримані результати становлять практичну та теоретичну цінність у сфері 
управління складними веб-орієнтованими інформаційними системами. 
 
Практичне значення одержаних результатів 
 
 Результати можуть бути використані для розробки реального веб-застосунку 
 Сформульовані вимоги та моделі можуть стати основою технічного завдання 
 Побудовані WBS, діаграми та плани - використані командами розробників 
 Оцінка витрат і прогноз фінансової ефективності можуть застосовуватися 
при ухваленні бізнес-рішень 
 Розроблений підхід здатен застосовуватись для інших онлайн-платформ, 
орієнтованих на геймерську спільноту 
Крім того, виконана робота може бути використана компаніями й 
індивідуальними розробниками для створення власних платформ у сфері геймінгу, 
електронної комерції чи цифрових сервісів. 
 
Апробація роботи 
 
Основні результати дослідження були апробовані під час аналізу та 
моделювання системи GGame, розробки її структури, вимог та плану реалізації. 
Окремі елементи роботи були представлені на науково-практичній конференції, 
присвяченій сучасним веб-орієнтованим інформаційним системам, де отримали 
позитивну оцінку.  
12 
 
 
РОЗДІЛ 1  
АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ 
 
 
1.1 Аналіз предметної області 
 
У сучасному інформаційному суспільстві відеоігри суттєво 
трансформувалися: це вже не лише засіб дозвілля, а повноцінна соціально-
економічна екосистема [3]. Ріст онлайн-геймерів, глобалізація ігрових спільнот та 
розвиток цифрових платформ створюють попит на сервіси, що сприяють 
комунікації, взаємодії та монетизації ігрового досвіду [4]. Саме в цьому контексті 
веб-додаток GGame набуває особливої актуальності, оскільки поєднує механізми 
соціальних сервісів, алгоритмічний підбір гравців (matchmaking) та безпечні 
фінансові транзакції. 
З точки зору управління проєктом, аналіз предметної області включає кілька 
ключових аспектів: ринкові тенденції, соціально-економічні стимули, технологічні 
вимоги й організаційні виклики. 
Ринкові тенденції і динаміка - ігровий ринок залишається одним з 
найдинамічніших у цифровій індустрії [5]. Після пандемії COVID-19, коли суттєво 
зросла активність гравців, частина з них продовжила взаємодіяти онлайн, але 
одночасно більшість гейм-платформ почала шукати інноваційні способи підтримки 
зростаючої бази користувачів і підвищення їхньої утримуваності. Для багатьох 
гравців важливим стає не просто гра, а можливість знайти надійних співгравців, 
особливо таких, з ким можна стабільно грати або навіть ділити досвід і вміння. 
Саме тут такий сервіс як GGame може задовольнити ці потреби, пропонуючи 
інтелектуальні механізми підбору гравців, що враховують їхній ігровий стиль, 
досвід та навички. 
13 
 
Соціально-економічна мотивація - Важливим аспектом є соціально-
економічний стимул : гравці отримують можливість монетизувати свій ігровий 
досвід, виступаючи як "ігрові фрилансери". Це може охоплювати коучинг новачків, 
участь у спільних сесіях або навіть гру за оплату. Такий підхід не лише стимулює 
активність, але й формує внутрішню економіку в межах платформи. Для 
користувачів це - шанс заробляти, а для платформи - джерело доходу через комісії 
або партнерські угоди. 
Технологічні вимоги та виклики [6] - розробка веб-додатку такого масштабу 
потребує вирішення технічних і управлінських задач: 
1) Масштабованість [7]: Платформа має витримувати значне навантаження, 
особливо в пікові періоди активності геймерів 
2) Безпека [8]: Оскільки передбачається обробка платіжних транзакцій, 
пріоритетом є захист даних користувачів та їхніх платежів 
3) Алгоритмічний підбір (matchmaking): Використання сучасних алгоритмів 
для підбору гравців за різними параметрами - це ключ до забезпечення якості гри 
й задоволеності користувачів 
4) UX / UI: Інтерфейс має бути інтуїтивно зрозумілим і доступним, щоб 
користувачі різного рівня могли легко взаємодіяти з системою 
5) Юридичні та регуляторні питання [9]: Платформа повинна відповідати 
законам про захист даних, правилам щодо онлайн-платежів і, можливо, мати 
механізми для фінансових звітностей або аудитів 
Інформаційні системи як мотивуючі платформи [10] - інформаційні системи 
[11], побудовані з елементами гейміфікації, зростають в популярності. За останніми 
дослідженням [12], дизайн інформаційних систем із елементами гри може значно 
підвищувати мотивацію користувачів і їхню залученість. У контексті GGame, такі 
підходи дозволяють створити мотивуючий інтерфейс, який стимулює користувачів 
до активної участі, взаємодії й повторного повернення на платформу. 
Вплив matchmaking на поведінку гравців – досвід матчів (match experience), 
зокрема рівень суперника, череди перемог або поразок, впливає на залишення гри. 
14 
 
Невідповідний підбір суперників або велика різниця в навичках веде до зростання 
ймовірності залишення гравцями платформи. Для GGame це означає, що 
алгоритмічний підбір має велике значення не лише для зручності, але й для бізнес-
моделі - стабільні матчі покращують утримання, що знижує ризики відтоку. 
Управлінські аспекти проєкту - з точки зору проєктного менеджера, аналіз 
предметної області визначає фундаментальні напрями планування: 
1) Формування продуктової стратегії: необхідно чітко визначити, які функції 
є базовими (пошук партнерів, профілі, рейтинги) і які - додатковими 
2) Оцінка ризиків: до них належать технологічні (масштаб, навантаження), 
фінансові (безпека платежів), регуляторні (захист персональних даних), ризики, 
пов’язані з утриманням користувачів а також самого ринку [13]. 
3) Планування ресурсів: створення команди, яка включатиме бекенд-
розробників, фронтенд-розробників, дизайнерів, QA-інженерів, DevOps, а також 
бюджет на інфраструктуру та маркетинг 
4) Стратегія зростання: підвищення користувацької бази, можливих нових 
ринків, масштабування функціональності на основі аналізу даних про активність 
Значення для інформаційного суспільства - GGame - це не просто ігровий 
сервіс. Він є інноваційним елементом інформаційного суспільства, оскільки: 
 перетворює ігровий час на економічний ресурс 
 сприяє формуванню цифрової культури й комунікації 
 надає можливості для заробітку через онлайн-геймерство 
 стимулює розвиток цифрових навичок, підприємливості та співпраці 
 інтегрує соціальні, гейміфіковані та бізнес-аспекти у веб-структуру 
відповідаючи на виклики цифрової трансформації 
 
1.2 Огляд аналогів 
 
Для аналізу ринку було відібрано три сервіси, що найбільш близькі до 
тематики та функціональних особливостей майбутнього веб-сервісу: TEAMS.gg, 
15 
 
Tapin та Dachi.lol. Основними критеріями для аналізу виступають: відповідність 
потребам користувачів, функціональність сервісів, особливості UX/UI дизайну 
[14], простота взаємодії з інтерфейсом [15] та реалізовані підходи до монетизації. 
Нижче наведено детальний огляд кожного аналога. 
 
 
Рисунок 1.2.1 Головна сторінка сервісу TEAMS.gg 
 
TEAMS.gg це спеціалізована платформа для пошуку гравців і формування 
команд у командних кіберспортивних дисциплінах, зокрема CS2, Valorant та Apex 
Legends. Сервіс орієнтований на користувачів, яким потрібні надійні партнери для 
гри та участі в турнірах. Вузька спеціалізація дозволяє точніше аналізувати профілі 
гравців і добирати сумісні команди. 
Основою роботи TEAMS.gg є алгоритмічний підбір партнерів. Користувачі 
заповнюють детальний профіль із рівнем навичок, досвідом, часовою зоною, 
стилем комунікації та іншими параметрами. Система порівнює профілі за 
множиною атрибутів, формуючи найбільш відповідні матчі. Для команди розробки 
це означає необхідність постійного вдосконалення алгоритмів, обробки великих 
масивів даних і підтримання стабільної роботи сервісу. 
Інтерфейс платформи [16] побудовано за принципом мінімалізму [17]: 
найважливіші функції - створення профілю, пошук гравців і комунікація - 
максимально спрощені. Такий підхід дозволяє сконцентрувати ресурси на 
ключових задачах і забезпечує швидке та інтуїтивне використання [18]. 
16 
 
TEAMS.gg інтегрується з ігровими платформами та сервісами статистики, що 
дозволяє автоматично отримувати дані про користувача та підвищує точність 
профілю [19]. Однак інтеграції створюють ризики залежності від зовнішніх API, 
що вимагає гнучкої архітектури й регулярного технічного супроводу. 
Попри успішність, сервіс має низку обмежень. Він орієнтується тільки на 
командні шутери, що звужує потенційний ринок. Для інших жанрів потрібні інші 
принципи добору гравців. Платформа також не містить механізмів монетизації 
навичок користувачів та інструментів контролю їх поведінки (оцінка токсичності, 
репутаційні системи). Це знижує потенціал розвитку сервісу та впливає на якість 
взаємодії між гравцями. 
У контексті ринку TEAMS.gg демонструє стабільний попит на 
автоматизовані системи пошуку напарників, але водночас показує типові недоліки: 
низьку масштабованість, обмеженість жанрової підтримки й відсутність 
інструментів комерційної взаємодії. 
Для майбутнього застосунку GGame цей сервіс є корисним прикладом, що 
підтверджує актуальність ринку та ключові очікування користувачів. Водночас 
недоліки TEAMS.gg підкреслюють перспективні напрями розвитку GGame: 
універсальність для різних жанрів, інтеграція механізмів монетизації, розширена 
система рекомендацій і впровадження контролю поведінки гравців. 
 
 
Рисунок 1.2.2 Головна сторінка сервісу Tapin 
17 
 
 
Tapin це сервіс, орієнтований на монетизацію ігрового досвіду через надання 
платних цифрових послуг: коучинг, допомога в іграх, супровід та інші активності. 
На відміну від платформ, що зосереджені на пошуку напарників, Tapin поєднує 
функції маркетплейсу та соціальної платформи, що робить його релевантним 
аналогом для майбутнього веб-застосунку GGame. 
Платформа працює за моделлю ринку цифрових послуг, де користувачі 
можуть купувати та продавати свої навички або час. Сервіс забезпечує інструменти 
для створення пропозицій, оформлення замовлень, комунікації та взаємодії між 
сторонами. Такий підхід вимагає від команди розробки високого рівня безпеки, 
підтримки транзакцій, перевірки виконавців і систем вирішення суперечок. 
Важливою особливістю Tapin є акцент на професіоналізації послуг. 
Користувачі створюють портфоліо, описують досвід, досягнення та гарантії якості. 
Це сприяє побудові довіри, але зумовлює потребу у складній системі контролю 
достовірності інформації, управління рейтингами й модерації. Платформа 
використовує відгуки, рейтинги та історію виконаних замовлень, але ці механізми 
потребують постійного вдосконалення, щоб уникати маніпуляцій та шахрайства. 
Технічно Tapin інтегрується з платіжними сервісами, системами верифікації, 
інструментами аналітики та відстеження замовлень. Робота з конфіденційними 
даними та платежами вимагає дотримання міжнародних стандартів безпеки, що 
впливає на архітектуру, витрати та набір компетенцій команди. Платформа має 
забезпечувати стабільну роботу пошукових фільтрів і швидку обробку даних, 
оскільки велика кількість пропозицій створює значне навантаження. 
Бізнес-модель Tapin ґрунтується на комісії з транзакцій, тому якість сервісу 
напряму впливає на дохідність. Команда повинна регулярно аналізувати поведінку 
користувачів, задоволення замовників, ефективність транзакцій та підтримувати 
високий рівень сервісу, що передбачає системну аналітику і постійні оновлення. 
Водночас Tapin має обмеження. Новачкам важко орієнтуватися на платформі 
через складність інтерфейсу, велику кількість параметрів і конкуренцію між 
18 
 
продавцями. Це вказує на необхідність спрощеного онбордингу й більш доступних 
сценаріїв використання - важлива рекомендація для розробки GGame. Платформі 
також складно боротися з недобросовісними виконавцями та шахрайством: у 
високотранзакційних системах потрібні KYC-процедури, модерація та аналіз 
підозрілої активності. 
Сервіс стикається і з технічними викликами масштабування. Велика кількість 
послуг та транзакцій потребує гнучкої, мікросервісної архітектури та 
інфраструктури, здатної витримувати пікові навантаження. Це важливий висновок 
для GGame - масштабованість потрібно закладати від початку проєкту. 
У підсумку Tapin є розвиненою платформою для монетизації ігрових 
навичок, але не універсальним рішенням. Він демонструє високий ринковий попит 
на цифрові геймерські послуги, проте має обмеження, пов’язані з безпекою, 
онбордингом, перевіркою виконавців і масштабуванням. Аналіз Tapin допомагає 
визначити напрями вдосконалення для GGame: спрощений інтерфейс, 
інтелектуальні рекомендації, безпечна монетизація, ефективна модерація та гнучка 
архітектура. Саме ці аспекти формують основу подальшого проєктування. 
 
 
Рисунок 1.2.3 Головна сторінка сервісу Dachi.lol 
 
Dachi.lol це вузькоспеціалізований веб-сервіс, орієнтований на пошук 
партнерів виключно для гри League of Legends. На відміну від універсальних 
19 
 
платформ, він зосереджується на одній грі, що дозволяє враховувати унікальні 
особливості LoL: ролі, рейтинги, стилі гри та характерну поведінку спільноти. Така 
спеціалізація забезпечує точніший алгоритмічний підбір і робить сервіс показовим 
прикладом того, як адаптація під конкретну ігрову екосистему може підвищувати 
якість взаємодії. 
Візуальний стиль Dachi.lol відповідає естетиці League of Legends: темна 
кольорова схема, контрастні неонові акценти, велика кількість білого простору. Це 
створює знайоме середовище, полегшує сприйняття контенту та підтримує 
очікування цільової аудиторії. Інтерфейс відрізняється простотою, а ключова 
функціональність зосереджена на одній сторінці. Такий підхід зменшує складність 
розробки та пришвидшує роботу сервісу, хоча в майбутньому може створювати 
обмеження через можливість перевантаження інтерфейсу. 
Однією з найпомітніших особливостей сервісу є swipe-механіка перегляду 
профілів, схожа на додатки для знайомств. Вона додає процесу пошуку 
інтерактивності та емоційності, проте водночас значно уповільнює підбір 
партнерів. Перегляд лише одного профілю за раз і відсутність каталогів та фільтрів 
роблять взаємодію менш ефективною й знижують точність пошуку, що може 
негативно впливати на користувацький досвід. 
Суттєвим недоліком Dachi.lol є примусова авторизація: користувач не може 
ознайомитися з можливостями сервісу без входу в систему. Це створює 
психологічний бар’єр і зменшує готовність нових відвідувачів продовжувати 
взаємодію. До того ж доступні лише два способи авторизації - Google та Discord, 
що обмежує потенційну аудиторію і викликає незручності серед тих, хто не бажає 
використовувати свої особисті акаунти. Додатковою проблемою є періодичні збої 
під час авторизації, що критично впливає на сервіс, де логін є обов’язковим для 
доступу до функцій. 
Ще одним слабким місцем платформи є відсутність системи відгуків. У 
сервісах для пошуку партнерів відгуки та репутація є важливими елементами, які 
дозволяють оцінити поведінку, стиль гри, доброзичливість і надійність 
20 
 
користувача. Відсутність будь-яких репутаційних механізмів зменшує рівень 
довіри та звужує можливості розвитку спільноти. Така ж проблема спостерігається 
у відсутності фільтрації профілів: користувач не може швидко знайти партнерів за 
рейтингом, роллю чи іншими характеристиками, що робить пошук повільним і 
менш ефективним. 
Попри низку недоліків, Dachi.lol має позитивні сторони. Мінімалістичний 
інтерфейс, велика кількість вільного простору та простота використання 
створюють комфортні умови для взаємодії. Естетика сервісу добре узгоджується з 
тематикою гри, а swipe-механіка додає інноваційності й відрізняє сервіс від інших 
платформ. Проте загальна відсутність інтерактивних елементів, неповна реалізація 
UI та мінімальний функціонал формують враження недоробленості продукту. 
У цілому Dachi.lol демонструє, як фокус на конкретній ігровій аудиторії може 
працювати ефективно, але також показує типові обмеження вузькоспеціалізованих 
рішень. Він поєднує привабливий дизайн та простоту, але страждає від нестачі 
репутаційних механізмів, обмежених способів авторизації, технічної 
нестабільності та відсутності розширених інструментів пошуку. У контексті 
розробки GGame аналіз цього сервісу дає змогу краще зрозуміти важливість 
доступної авторизації, наявності фільтрів, побудови репутаційної системи й 
забезпечення стабільності ключових функцій. 
 
1.3 Порівняння аналогів 
 
У процесі управління проєктом розробки веб-застосунку GGame важливим 
етапом є визначення конкурентного середовища та порівняння існуючих рішень за 
ключовими критеріями, що відображають як функціональні можливості, так і 
технічні, UX та бізнес-аспекти. Згідно з сучасними методологіями аналізу 
програмних продуктів, порівняння аналогів дає змогу формувати об’єктивне 
розуміння ринку та конкретизувати вимоги до майбутньої системи. Такий аналіз 
дозволяє виявити недоліки та обмеження ринку, окреслити точки зростання 
21 
 
майбутнього продукту, а також визначити пріоритети під час планування завдань, 
оцінки ризиків та формування стратегії розвитку. 
Порівняння сервісів TEAMS.gg, Tapin і Dachi.lol демонструє їхні різні 
підходи до структури, взаємодії з користувачами, організації пошуку гравців і 
монетизації, що дає змогу комплексно оцінити їхні сильні та слабкі сторони. 
Суттєву частину об’єктивності цього аналізу забезпечує оцінка інтерфейсних 
моделей, адже саме UI/UX визначає рівень взаємодії користувача та ефективність 
виконання ключових задач. 
Для систематизації аналізу була сформована розширена порівняльна 
таблиця, яка включає найважливіші характеристики, релевантні для проєктного 
менеджменту: моделі взаємодії з користувачами, наявність критичних функцій, 
можливості персоналізації, стабільність роботи, рішення з монетизації, рівень UX-
зрілості, технічні інтеграції, а також елементи комунікаційних та соціальних 
механік. Така структура відповідає загальноприйнятим підходам у сфері 
дослідження інтерфейсів та цифрових продуктів. 
 
Таблиця 1.3.1 Результати аналізу аналогів 
Характерист Опис TEAMS.gg Tapin Dachi.lol 
ика 
Тип сервісу Орієнтація та Пошук Комерційний Пошук 
спеціалізація партнерів пошук партнерів 
(багато геймерів (LoL) 
ігор) 
Доступ до Наявність режиму Є Є Немає 
сервісу гостя 
Обов’язковіс Чи потрібен логін Ні Ні Так 
ть для роботи 
авторизації 
22 
 
Методи Кількість і 4+ способи 5+ способів Лише 
авторизації різноманітність Google/Disco
rd 
Стабільність Частота помилок Висока Висока Низька (часті 
авторизації входу помилки) 
Каталог Перегляд усіх Є Немає Немає 
гравців профілів 
Фільтри Детальність Дуже Немає Немає 
пошуку детальні 
Ігрова Рівень деталізації Високий Низький Середній 
статистика даних 
Комунікація Можливість Немає Є (чат/зв’язок Немає 
спілкування в із компанією) 
сервісі 
Зовнішні Чи можна Частково Частково Так 
контакти переглядати 
соцмережі/контак
ти 
Відгуки Система оцінок Немає Є Немає 
Монетизація Модель доходу Реклама Комісія + Реклама 
(спливаюча) реклама 
Гейміфікація Наявність Немає Є Немає 
ачівок/рівнів 
Верхня Тип поведінки Фіксована Зникаюча Зникаюча 
навігація меню 
Кількість Структура сайту Багато- Одно- Одно-
сторінок сторінковий сторінковий сторінковий 
23 
 
Анімації Наявність Мінімум Багато Мінімум 
інтерактивних 
ефектів 
Стани UI- Візуальна реакція Є Є Частково 
елементів на взаємодію 
Стильовий Єдність дизайну Висока Низька Висока 
баланс 
Швидкість Наявність Дуже Дуже швидко Швидко 
створення складних форм повільно 
профілю (30+ полів) 
Мобільна Зручність з Висока Середня Висока 
адаптація телефона 
Підтримка Наявність FAQ, Немає Є Немає 
користувачів сапорту 
Соцмережі та Підтримка Є Є Немає 
медіа ком’юніті 
Тип взаємодії Каталог чи swipe- Каталог Каталог - Swipe-картки 
з профілями mеханіка замовлення 
Перегляд Швидкість і Висока Висока Низька 
профілів зручність оцінки 
Глибина UX- Наскільки зрілі Висока Середня Низька 
аналітики механізми UX 
Продуктивні Швидкість Висока Висока Середня 
сть сайту роботи сторінки 
Надійність Кількість Мінімум Низька Багато 
функцій технічних збоїв 
24 
 
Цінова Можливість Не Є Не актуально 
прозорість побачити вартість актуально 
послуг 
 
Порівняння представлених платформ демонструє, що кожен із розглянутих 
сервісів вирішує подібну задачу, але використовує для цього різні підходи - від 
структурних UX-рішень до моделей монетизації та залучення користувачів. Такий 
аналіз є критично важливим для управління проєктом GGame, оскільки дозволяє 
зрозуміти, які функції є ринковим стандартом, які - недопрацьовані конкурентами, 
а які можуть стати основою унікальної цінності нашого продукту. 
Одним із ключових критеріїв є доступність сервісу без авторизації. 
TEAMS.gg та Tapin дозволяють користувачу переглядати профілі або здійснювати 
базові дії без створення акаунту, що значно підвищує первинну залученість 
аудиторії. На противагу цьому, Dachi.lol використовує обов'язкову авторизацію 
через обмежені методи входу, що створює додаткові бар’єри на ранньому етапі 
воронки користувача. З погляду управління проєктом такі обмеження є 
критичними: вони скорочують потенційну аудиторію на десятки відсотків і 
безпосередньо впливають на конверсію. 
Іншим важливим параметром є наявність каталогу гравців. Це стандартна 
функція для веб-платформ пошуку партнерів, оскільки вона забезпечує високу 
швидкість перегляду профілів, можливість порівняння та вільний доступ до 
інформації. Тільки TEAMS.gg реалізує повноцінний каталог з детальними 
фільтрами за десятками параметрів, що робить його найбільш зручним для 
швидкого пошуку. Dachi.lol та Tapin використовують альтернативні підходи 
(Swipe-механіка і персоналізований відбір компанією відповідно), що різко знижує 
автономність користувача та сповільнює процес вибору гравця. Для GGame 
наявність каталогу є обов’язковою складовою, оскільки саме вона забезпечує 
масштабованість, прозорість та персоналізованість. 
25 
 
У контексті якісної фільтрації та пошуку TEAMS.gg має очевидну перевагу: 
сервіс пропонує найдетальнішу систему параметрів, включно з рівнем навичок, 
ролями, ігровими стилями та додатковими характеристиками. Відсутність фільтрів 
у Tapin та Dachi.lol свідчить про неповну реалізацію функціональної моделі, що 
знижує ефективність взаємодії та збільшує ризик незадоволеності користувача. 
Крім того, важливо порівнювати механізми комунікації. Tapin має вбудовану 
систему зв’язку між клієнтом і гравцем, що дозволяє вирішувати питання без 
необхідності переходу на сторонні платформи. У TEAMS.gg та Dachi.lol 
внутрішніх засобів комунікацій немає, що змушує користувачів використовувати 
сторонні сервіси. Для GGame це є сигналом про високу цінність реалізації 
внутрішнього чату або платформи для координації гри, адже це підвищує 
утримання користувачів та створює додаткові бізнес-можливості. 
Ще одним важливим параметром є монетизація. TEAMS.gg та Dachi.lol 
працюють за моделлю рекламного доходу, що є менш вигідною в довгостроковій 
перспективі та створює ризик перевантаження інтерфейсу рекламою. Tapin, 
навпаки, використовує змішану модель з комісією та промокодами, що робить 
сервіс прибутковішим і водночас гнучким. Для GGame оптимальним рішенням є 
поєднання внутрішньої транзакційної комісії, бонусної системи та гейміфікації, що 
забезпечує сталість доходу та мінімальну шкоду UX. 
Окремо слід відзначити надійність сервісів та технічну стабільність. Dachi.lol 
має значні проблеми з авторизацією, що критично впливає на користувацький 
досвід. Tapin демонструє вищу стабільність, однак має нагрузку у вигляді великої 
кількості анімацій, які можуть сповільнювати роботу на слабких пристроях. 
TEAMS.gg вирізняється найкращою продуктивністю та якістю реалізації базових 
функцій, що свідчить про вищу технологічну зрілість продукту. 
Важливим аспектом для оцінки конкурентів є наявність репутаційних 
механізмів та системи відгуків. Tapin має добре реалізовану систему оцінювання, 
що створює додаткову довіру між гравцями та підвищує прозорість сервісу. 
TEAMS.gg і Dachi.lol не пропонують цього функціоналу, що знижує їхню 
26 
 
привабливість і безпеку з погляду користувача. Оскільки GGame включатиме 
функцію монетизації ігрового часу, система репутації є ключовим елементом, без 
якого будь-яка транзакційна модель втрачає надійність. 
Узагальнюючи результати аналізу, можна стверджувати, що жоден із 
розглянутих сервісів не пропонує повноцінного і завершеного рішення. Кожен із 
них має сильні сторони, але також і суттєві недоліки. TEAMS.gg вирізняється 
глибокою системою фільтрації та надійністю, але відсутністю комунікації та 
надмірною складністю створення профілю. Tapin має добре реалізовану систему 
комунікації та гейміфікацію, але не пропонує каталогу та фільтрів. Dachi.lol 
використовує цікаву Swipe-механіку і привабливий стиль, але має серйозні технічні 
недоліки та обмежені можливості входу. 
Для GGame це означає, що ринок має багато можливостей для 
вдосконалення. Майбутній продукт може інтегрувати найкращі практики з 
кожного аналога - стабільність і фільтри TEAMS.gg, комунікацію та бонусну 
систему Tapin, мінімалістичний стиль і простоту взаємодії Dachi.lol - і доповнити 
їх унікальними функціями монетизації, системою рейтингу, внутрішнім чатом, 
розширеними профілями та якісною мобільною адаптацією. 
 
1.4 Постановка задачі 
 
Розробка веб-застосунку GGame, орієнтованого на пошук партнерів для 
комп’ютерних ігор та монетизацію ігрового часу, передбачає вирішення 
комплексної сукупності організаційних, технічних, функціональних і UX-завдань, 
що охоплюють повний життєвий цикл створення програмного продукту. 
Постановка задачі в контексті управління проєктом є ключовим етапом, який 
формує рамки майбутньої системи, визначає її функціональні обмеження, вимоги, 
критерії успіху та очікувані результати. Відповідно до загальних принципів 
інженерії вимог, постановка задачі має базуватися на аналізі потреб користувачів, 
ринку та бізнес-цілей продукту. Саме тому обґрунтування задачі GGame повинно 
27 
 
враховувати не лише функціональну сторону пошуку гравців, але й соціальні, 
економічні та інформаційні аспекти формування сучасних цифрових платформ. 
Зростаюча популярність онлайн-ігор, розвиток кіберспорту, перехід значної 
частини соціальної взаємодії до цифрового простору та комерціалізація ігрових 
навичок створили передумови для формування нових моделей взаємодії між 
гравцями. Проте доступні аналоги не забезпечують комплексного вирішення задачі 
пошуку партнерів, персоналізації рекомендацій та можливості безпечної 
монетизації ігрового часу. У цьому контексті GGame має на меті усунути дані 
недоліки, запропонувавши інтегровану систему, яка поєднує алгоритмічний підбір 
гравців, безпечні транзакції та елементи соціальної взаємодії. З точки зору 
управління проєктом це означає необхідність чіткої постановки задачі, яка 
забезпечить узгодженість вимог, задоволення інтересів стейкхолдерів і можливість 
контролю за ходом реалізації проєкту. 
Одним із ключових завдань є визначення функціональної концепції 
застосунку, яка охоплює механізми реєстрації користувачів, формування профілів, 
пошуку партнерів, монетизаційних сценаріїв, комунікації та створення безпечної 
платформи для взаємодії гравців. Відповідно до сучасних досліджень у сфері 
проєктування інформаційних систем, грамотно сформульовані функціональні 
вимоги є базою для точного планування архітектури, ресурсів і ризиків. Це включає 
визначення того, як саме користувачі будуть знаходити один одного, які параметри 
впливатимуть на підбір, та яким чином здійснюватиметься замовлення ігрових 
послуг. 
Не менш важливою складовою є формування нефункціональних вимог, серед 
яких: масштабованість, надійність, продуктивність, відповідність стандартам 
безпеки, інтуїтивність інтерфейсу та забезпечення безперервної роботи платформи. 
Наукові дослідження підкреслюють, що нефункціональні вимоги мають визначати 
якість системи, а не її структуру, і їхнє раннє формулювання суттєво зменшує 
ризики на пізніх етапах розробки. Для GGame це означає потребу визначити 
28 
 
обмеження щодо навантаження, швидкості відповідей, часу відгуку системи, 
вимоги до UI/UX дизайну та поведінки під різними сценаріями. 
Окремим завданням є створення системи монетизації, яка дозволяє гравцям 
легально та безпечно отримувати винагороду за свій ігровий час. Дане рішення має 
відповідати нормам електронної комерції, стандартам фінансової безпеки та 
принципам прозорості. Проєктний менеджер має сформулювати завдання щодо 
інтеграції платіжних систем, розробки механізмів перевірки транзакцій і системи 
захисту від шахрайства. У науковій літературі зазначається, що правильне 
формування бізнес-логіки монетизації знижує ризик фінансових порушень і 
підвищує довіру користувачів до платформи. 
Також необхідно розв’язати задачу побудови механізму репутації, що 
включає рейтинги, відгуки та поведінкові метрики. Дослідження цифрових 
комунікацій підтверджують, що системи репутації відіграють вирішальну роль у 
користувацькому виборі й формуванні довіри в онлайн-середовищі. Для 
платформи GGame це критично, оскільки учасники будуть здійснювати реальні 
фінансові трансакції, обираючи гравців не тільки за рівнем навичок, але й за 
надійністю, ввічливістю та відповідальністю. 
Ще однією важливою задачею є формування алгоритму підбору партнерів, 
який повинен враховувати як технічні параметри (рейтинг, роль, час гри, ігрову 
статистику), так і соціальні фактори (комунікабельність, частота порушень, відгуки 
інших гравців). Наукові підходи до побудови систем рекомендацій  свідчать, що 
комбіновані алгоритми, які враховують декілька груп параметрів, значно 
підвищують точність результатів і рівень задоволеності користувача. У межах 
проєкту потрібно вирішити задачу розробки інформаційної моделі, яка об’єднує всі 
ці дані та дозволяє здійснювати швидкий і точний пошук. 
Особливу увагу в постановці задачі слід приділити забезпеченню безпеки 
даних. Будь-який сервіс, який оперує особистими даними користувачів, 
фінансовими операціями та транзакційними метаданими, повинен відповідати 
вимогам міжнародних стандартів захисту інформації. Це стосується шифрування 
29 
 
даних, політик доступу, захисту від атак та інцидентів. Згідно з сучасними 
дослідженнями, правильне формування вимог безпеки на ранніх етапах значно 
зменшує вартість усунення вразливостей у майбутньому. 
Важливо також визначити організаційні задачі, пов’язані з плануванням 
робіт, оцінкою ресурсів, визначенням компетенцій команди, розподілом 
відповідальності та плануванням строків. Постановка задачі повинна включати 
створення WBS-структури, ідентифікацію залежностей між задачами, визначення 
ключових ризиків і їхніх тригерів. Сучасні методології управління проєктами  
підкреслюють, що правильна декомпозиція робіт є фундаментом для точного 
планування строків, бюджетів і навантаження команди. 
Таким чином, постановка задачі для створення GGame охоплює не лише опис 
функціональних можливостей, але й аналіз ринку, формування бізнес-моделі, 
визначення технічних та організаційних вимог, розробку репутаційних механізмів, 
створення системи безпечних транзакцій, формулювання UX-принципів і 
підготовку методології оцінки якості продукту. Всі ці аспекти є 
взаємопов’язаними, а їх узгоджена постановка дозволить закласти міцний 
фундамент для подальшого проектування та реалізації системи. 
 
1.5 Аналіз проєкту 
 
Розробка веб-застосунку GGame, орієнтованого на пошук партнерів для гри 
та монетизацію ігрового часу, потребує ґрунтовного аналітичного підходу, що 
включає оцінку конкурентного середовища, аналіз зовнішніх і внутрішніх 
факторів, формування концепції продукту та визначення вимог до інформаційної 
системи. З позицій управління ІТ-проєктом [20] саме якісний аналітичний етап є 
визначальним фактором подальшої ефективності, оскільки дозволяє мінімізувати 
ризики, точніше визначити ресурси та сформувати реалістичний план реалізації. 
На основі аналізу аналогів та ідентифікованих недоліків існуючих рішень 
сформована концепція GGame як веб-платформи, що поєднує функції пошуку 
30 
 
партнерів, професійних геймерських послуг та засобів соціальної взаємодії на базі 
безпечної інфраструктури та ефективної інформаційної архітектури [21]. 
Концепція базується на ідеї створення екосистеми, де гравці будь-якого рівня 
можуть не лише знаходити партнерів, а й отримувати доступ до професійної 
допомоги, мікро-коучингу та персоналізованих ігрових послуг. 
Мета проєкту - спроектувати інноваційний веб-застосунок, який 
забезпечить ефективний пошук ігрових партнерів та можливість монетизації 
ігрового часу при високому рівні безпеки, доступності та UX-якісності. 
Основні цілі GGame: 
1) Дати користувачам можливість швидко й точно знаходити ігрових 
партнерів за критеріями навичок, рейтингу, гри, стилю взаємодії та інтересів 
2) Забезпечити зручний інтерфейс для доступу до платних послуг 
професійних геймерів, тренерів і стрімерів 
3) Впровадити безпечний механізм монетизації з використанням сучасних 
платіжних систем 
4) Створити платформу соціальної взаємодії, що включає оцінки, відгуки, 
рейтинги, комунікацію та рекомендаційні алгоритми 
5) Підвищити якість користувацького досвіду шляхом оптимізованої 
інформаційної архітектури, адаптивного дизайну та персоналізації 
Результати аналізу аналогів вказують на низку проблем, які характерні для 
TEAMS.gg, Tapin та Dachi.lol: обмеженість фільтрів, складність навігації, 
обов’язкова авторизація, низька деталізація профілів або відсутність 
комунікаційних функцій. Підвищення ефективності GGame передбачає: 
1) Розширену систему фільтрів та рекомендацій, що підвищує швидкість 
пошуку та точність підбору 
2) Інтеграцію платіжних сервісів і механізмів мікротранзакцій з акцентом на 
прозорість та безпеку 
3) Гейміфікацію платформи через рівні, ачивки, статистику 
31 
 
4) Розширений профіль гравця, який включає аналітику, метрики та 
репутаційні параметри 
5) Підвищення доступності, включно з можливістю використання сервісу без 
реєстрації 
Такі рішення відповідають принципам побудови високоякісних ІТ-продуктів, 
заснованих на UX-орієнтованому підході, гнучких методологіях та системному 
мисленні, про що свідчать сучасні дослідження в галузі управління цифровими 
продуктами [22]. 
SWOT-аналіз проєкту 
S - Сильні сторони: 
 Інноваційна функція монетизації ігрового часу 
 Розширені фільтри пошуку та адаптивний алгоритм підбору партнерів 
 Безпечна система транзакцій 
 Висока інтерактивність та гейміфікація 
W - Слабкі сторони: 
 Значні стартові витрати на інфраструктуру 
 Необхідність модерації контенту та контролю безпеки 
 Конкуренція з глобальними платформами 
O - Можливості: 
 Ріст індустрії кіберспорту та геймплею за замовленням 
 Партнерства з блогерами, стрімерами, ігровими студіями 
 Розвиток мобільної версії 
T - Загрози: 
 Потенційні юридичні обмеження щодо монетизації геймплею 
 Кіберзагрози та атаки на систему 
 Зміни ринкових тенденцій 
PEST-аналіз проєкту 
P - Політичні фактори: 
32 
 
 регуляції у сфері електронної комерції, захист персональних даних, фінансові 
обмеження для онлайн-платформ 
E - Економічні фактори: 
 динаміка ринку ігор, платоспроможність користувачів, популярність 
мікротранзакцій 
S - Соціальні фактори: 
 зростання спільнот геймерів, підвищення впливу стрімінгових платформ, 
гейміфікація цифрового життя 
T - Технологічні фактори: 
 розвиток хмарних сервісів, веб-технологій, алгоритмів рекомендацій та 
систем машинного навчання 
Аналіз цільової аудиторії 
Цільова аудиторія GGame є досить широкою та охоплює як аматорів, так і 
професійних гравців. Для структурування було виділено основні групи: 
1. Гравці-аматори - Шукають партнерів для гри, прагнуть покращити досвід, 
обирають зручність і мінімум складності 
2. Напівпрофесіонали і геймери-ентузіасти - Мають потребу у тренуваннях, 
коучингу, підборі команди 
3. Професійні гравці - Зацікавлені у монетизації ігрового часу, пошуку 
клієнтів, участі в турнірах 
4. Стрімери та контент-мейкери - Фокус на спільних стрімах, колабораціях, 
кооперативному контенті 
5. Компанії та представники геймдев-індустрії - Потребують партнерських 
програм і промо-інструментів 
Розуміння структури аудиторії є важливим для правильного формування 
вимог та вибору функціональних модулів, як це рекомендується у сучасних 
моделях UX-досліджень. 
 
33 
 
Далі для кращого розуміння представленні графічно дві персони, які 
відіграють роль користувачів сервісу які займають більшу частку аудиторії сервісу: 
 
Рисунок 1.5.1 – Особа 1, яка шукає партнера для ігор
 
Рисунок 1.5.2 – Особа 2, яка заробляє кошти граючи в ігри 
34 
 
 
На цих рисунках представлені коротка інформація про особу, їх проблеми з 
якими сервіс повинен розібратися, та досвід використання технологій. 
Формування вимог до інформаційної системи 
Функціональні вимоги: 
На основі аналізу предметної області, цільової аудиторії та аналогів до 
інформаційної системи GGame формуються такі основні функціональні вимоги 
(Product Functions): 
1) Personal User Account - система має забезпечувати реєстрацію, авторизацію 
та ведення особистого кабінету користувача з базовими налаштуваннями, історією 
активності та платіжною інформацією 
2) Admin/Manager Account - має бути реалізовано окремий тип облікового 
запису для адміністратора/менеджера платформи з можливістю модерації 
контенту, управління користувачами, перегляду статистики та керування 
фінансовими операціями 
3) Partner Account - підтримка окремого типу акаунту для партнерів (про 
геймерів, тренерів, стрімерів), які надають платні послуги на платформі 
4) Players search - реалізація розширеного пошуку гравців за іграми, рівнем 
навичок, рейтингом, мовою спілкування, часовими зонами, стилем гри тощо 
5) Buying subscription - можливість оформлення платної підписки на 
додатковий функціонал, сервіси чи привілеї в межах платформи 
6) Canceling subscription - користувач повинен мати змогу самостійно 
скасувати активну підписку відповідно до політики платформи 
7) Form - Contact Support - реалізація контактної форми для звернення до 
служби підтримки з питань технічного, фінансового чи організаційного характеру 
8) Game library - підтримка бібліотеки ігор, для яких доступний пошук 
партнерів і послуг, з можливістю фільтрації та перегляду інформації 
9) Partner Services - можливість створення, редагування та відображення 
пропозицій послуг від партнерів (напр. коучинг, гра в команді, аналіз матчів) 
35 
 
10) Voice / Text communication - забезпечення каналів текстової і, за 
можливості, голосової комунікації між користувачами в межах платформи або 
через інтегровані сервіси 
11) Rewards system for activity in the game - система винагород за активність 
(балів, внутрішньої валюти, статусів), що мотивує користувачів до регулярного 
використання платформи та ігрових сесій 
12) User ratings and recommendations for finding ideal partners - реалізація 
механізмів оцінювання користувачів та рекомендацій, які дозволяють знаходити 
найбільш сумісних партнерів для гри 
13) Customizable user profile pages - можливість кастомізації профілю (опис, 
посилання, налаштування відображення, ігрові ролі тощо) 
14) Pro Gamer / Streamer profile - розширені профілі для професійних гравців 
та стрімерів із додатковими полями (досягнення, турніри, посилання на трансляції) 
15) Payment system - інтегрована система оплати для проведення фінансових 
операцій (оплата послуг, підписок, внутрішніх покупок) 
16) In-platform currency - підтримка внутрішньої віртуальної валюти, що 
використовується для розрахунків у межах платформи 
17) Discord connection - інтеграція з Discord (авторизація, зв’язок або 
прив’язка акаунту), що спрощує комунікацію та залучення користувачів 
18) Friends list - реалізація списку друзів з можливістю додавання, видалення 
та перегляду статусу користувачів 
19) Reviews about players - система відгуків про гравців і партнерів, що 
формує репутаційну модель платформи 
20) Achievement - система досягнень, яка відображає активність користувача 
та стимулює тривалу взаємодію з платформою 
Нефункціональні вимоги: 
Нефункціональні вимоги визначають якісні характеристики системи, її 
продуктивність, безпеку, надійність, масштабованість та зручність використання. 
Для GGame формуються такі основні нефункціональні вимоги: 
36 
 
1)Продуктивність та масштабованість 
 Час завантаження сторінок не повинен перевищувати 2 секунд за 
стандартних умов 
 Система має підтримувати до 10000 одночасних запитів без суттєвої втрати 
продуктивності 
 Платформа повинна коректно працювати при одночасній присутності 
щонайменше 10000 користувачів 
2)Безпека та захист даних 
 Усі фінансові транзакції повинні відбуватися через безпечне з’єднання (TLS 
1.2 або вище) 
 Дані користувача, включаючи особисту інформацію та платіжні реквізити, 
повинні бути зашифровані (AES-256) 
 Автентифікація повинна підтримувати двофакторний захист (пароль + 
SMS/код електронної пошти або додаток для автентифікації) 
 Повинні бути обмеження на частоту запитів API для запобігання DDoS-
атакам 
 Система повинна відповідати правилам GDPR для користувачів з ЄС 
 Контент, опублікований користувачами, повинен модеруватися відповідно 
до етичних та правових стандартів 
3)Надійність та відмовостійкість 
 Система має підтримувати автоматичне відновлення після збоїв 
 Потрібен механізм автоматичного логування помилок та сповіщення 
адміністраторів про критичні інциденти 
4)Доступність та зручність використання (Usability)  
 Система повинна відповідати стандартам WCAG 2.1, щоб забезпечити 
доступність для користувачів з інвалідністю 
 Час на освоєння базового функціоналу новим користувачем не повинен 
перевищувати 10 хвилин 
37 
 
 Система повинна працювати в сучасних веббраузерах (Google Chrome, 
Mozilla Firefox, Microsoft Edge, Safari, Opera) 
5)Інтеграції та сумісність 
 Підтримка OAuth 2.0 для авторизації через Google, Facebook та Steam  
 Підтримка API для інтеграції зі сторонніми платіжними системами (PayPal, 
Stripe, банківські картки) 
6)Підтримка користувачів та операційна діяльність 
 Механізми повернення коштів повинні бути передбачені відповідно до 
політики використання платформи 
 Технічна підтримка повинна працювати цілодобово, а час реагування на 
критичні інциденти має становити не більше 1 години 
 
Висновок до розділу 1 
 
У першому розділі було здійснено комплексний аналіз предметної області, 
що дозволив визначити ключові особливості ринку веб-застосунків, орієнтованих 
на пошук ігрових партнерів та монетизацію ігрового часу. Розгляд тенденцій 
розвитку геймінгової індустрії та зростання ролі цифрових платформ [23] у 
формуванні соціальної взаємодії показав, що створення такого застосунку є 
актуальним та відповідає сучасним потребам користувачів. Поглиблений аналіз 
аналогів (TEAMS.gg, Tapin і Dachi.lol) дав можливість окреслити їх сильні та слабкі 
сторони, виявити функціональні обмеження та UX-недоліки, а також сформувати 
бачення того, яким чином майбутній продукт GGame може перевершити існуючі 
рішення. 
На основі проведеного порівняння було сформовано концепцію GGame як 
універсального веб-застосунку, що поєднує розширені можливості пошуку 
партнерів, систему професійних послуг, інструменти соціальної взаємодії та 
механізми монетизації ігрового часу. Постановка задачі визначила мету, 
функціональні та нефункціональні вимоги, а також окреслила ключові завдання, 
38 
 
які має розв’язати інформаційна система. Деталізовано сформовано напрями 
покращення ефективності майбутнього продукту на основі недоліків існуючих 
аналогів та з урахуванням сучасних принципів управління ІТ-проєктами [24]. 
Проведені SWOT та PEST аналізи дозволили визначити як внутрішні 
характеристики проєкту - сильні сторони, обмеження, можливості і загрози [25], 
так і зовнішні макрочинники, що впливатимуть на розробку й подальший розвиток 
платформи. У результаті було визначено потенціал продукту на ринку, виявлено 
ризики та стратегічні переваги [26], а також сформовано напрямки управлінських 
та технічних рішень, що забезпечать успішну реалізацію GGame. 
Детальний аналіз цільової аудиторії дозволив сформувати узагальнений 
портрет майбутніх користувачів, серед яких аматори, напівпрофесіонали, 
професійні геймери, стрімери, контент-мейкери та представники геймдев-індустрії. 
Це забезпечило основу для розробки персоналізованих функцій та якісного 
користувацького досвіду, що відповідає потребам різних категорій гравців. 
Узагальнюючи результати першого розділу, можна зробити висновок, що 
проведений аналіз створив ґрунтовну теоретичну та методологічну базу для 
подальшого проєктування та управління розробкою веб-застосунку GGame. 
Сформовані вимоги, визначені цілі та отримані аналітичні дані дозволяють перейти 
до етапу безпосереднього проєктного планування, розробки архітектури системи 
та вибору методології управління проєктом, що будуть розглянуті у наступних 
розділах.  
39 
 
 
РОЗДІЛ 2  
УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ ВЕБ-ЗАСТОСУНКУ GGAME 
 
 
2.1 Управління змістом 
 
Управління змістом проєкту є ключовим компонентом системи управління 
ІТ-проєктом, оскільки визначає межі, структуру та наповнення робіт, необхідних 
для створення веб-застосунку GGame. Саме на цьому етапі формується цілісне 
бачення продукту, узгоджується обсяг функціоналу, окреслюються ключові 
вимоги та визначається перелік кінцевих результатів, які має отримати замовник 
після завершення проєкту. 
Для комплексних IT-проєктів, таких як GGame, управління змістом включає 
формування цілей, аналіз предметної області, деталізацію SOW (Statement of 
Work), визначення макроцілей та детальних функціональних елементів, а також 
розробку WBS - структури декомпозиції робіт [27], що задає логіку подальшого 
планування ресурсів, часу та бюджету. 
У цьому підрозділі розглядається повний обсяг робіт, що входить до проєкту, 
їх чіткі межі, ключові вимоги та очікувані результати. Інформація ґрунтується на 
SOW, проведеному аналізі ринку аналогів та специфіці цільової аудиторії. 
Додатково сформовано SMART-цілі, структуру зацікавлених сторін та узагальнену 
структуру WBS, яка надалі буде використана у розділах 2.2-2.9 для планування 
ресурсів, ризиків, бюджету та комунікацій. 
 
2.1.1 Обсяг робіт проєкту (Scope) 
 
Обсяг робіт проєкту визначає усі дії, етапи та результати, необхідні для 
реалізації веб-застосунку GGame, а також окреслює логічні межі того, що саме 
40 
 
виконується в рамках даного ІТ-проєкту. Чітко сформований Scope слугує основою 
для подальшого управління часом, ресурсами, бюджетом, ризиками та якістю, 
забезпечуючи узгодженість між замовником і командою розробки. 
Проєкт GGame передбачає створення повноцінного веб-сервісу для пошуку 
партнерів з гри, взаємодії між користувачами та монетизації ігрового часу. 
Визначений обсяг робіт включає як планувальні процеси, так і технічну реалізацію, 
інтеграції, тестування, документування та публічний запуск продукту. 
Аналітичний та планувальний етап 
У межах проєкту виконується аналіз ринку геймінгових платформ, 
дослідження конкурентів, узагальнення потреб цільової аудиторії та формування 
бачення майбутнього продукту. На цьому етапі визначаються бізнес-цілі, моделі 
монетизації, функціональні та нефункціональні вимоги. Окремо формуються 
артефакти управління проєктом: SOW, WBS, RACI-матриця, оцінки витрат і 
тривалості, попередня діаграма Ганта, а також базовий план управління якістю, 
ризиками та комунікаціями. 
Проєктування та моделювання системи 
До обсягу робіт входить створення архітектури веб-застосунку, проєктування 
структури даних, визначення модулів сервісу та взаємодій між ними. Сюди також 
належать побудова логіки користувацьких сценаріїв, розробка UX-каркасів та 
створення дизайну інтерфейсу у відповідності до потреб геймерської аудиторії. 
Прототипи включають: 
 головні сторінки, профілі, каталог ігор та партнерів 
 модуль пошуку та рекомендацій 
 інструменти комунікації між користувачами 
 інтерфейс системи підписок, платежів і відгуків 
Розробка програмного забезпечення 
Обсяг робіт охоплює створення як фронтенд, так і бекенд-частини 
застосунку. До розробки належать: 
41 
 
 реалізація системи користувацьких акаунтів (звичайний користувач, 
адміністратор, партнер) 
 модуль пошуку гравців та рекомендацій 
 система відгуків, рейтингів, досягнень та історії активності 
 модуль текстових та голосових комунікацій 
 внутрішня система нагород і заохочень 
 інтеграція авторизації через Google, Facebook та Steam 
 інтеграція платіжних сервісів для підписок і комісій 
 реалізація ігрової бібліотеки та партнерських пропозицій 
 формування системи внутрішньої валюти 
 інструменти для взаємодії з Discord 
Також у межах проєкту налаштовується база даних, API-взаємодія та 
серверна логіка, що забезпечує продуктивну роботу системи під навантаженням. 
Інтеграції та безпека 
До Scope входить під’єднання зовнішніх сервісів, реалізація системи безпеки, 
шифрування, протидія атакам, а також забезпечення відповідності міжнародним 
стандартам, зокрема GDPR та WCAG 2.1. Передбачено: 
 захищені канали передачі даних (TLS 1.2+) 
 шифрування персональних даних і платіжної інформації 
 базові механізми протидії DDoS 
 аудит подій і система логування помилок 
 модерація контенту 
 верифікація користувачів 
Тестування та контроль якості 
У рамках проєкту виконується комплексне тестування, яке включає: 
 функціональне тестування 
 навантажувальні випробування 
 тестування безпеки 
42 
 
 тестування інтеграцій 
 UX-тестування з реальними користувальними сценаріями 
Створюється тест-план, набір тест-кейсів та звітів про виявлені дефекти. 
Розгортання та DevOps 
До обсягу робіт входить налаштування інфраструктури, CI/CD-процесів, 
серверів, домену, SSL-сертифікатів та системи моніторингу продуктивності. Після 
завершення всіх етапів виконується розгортання готової системи у продуктивному 
середовищі. 
Документування та запуск продукту 
У межах проєкту створюється пакет супровідної документації: 
 технічна документація 
 опис архітектури 
 мануали для адміністраторів 
 користувацькі інструкції 
 політика конфіденційності та умови використання 
Після цього здійснюється офіційний запуск продукту та первинне залучення 
користувачів через маркетингову кампанію. 
Підсумок 
Таким чином, обсяг робіт проєкту GGame охоплює весь життєвий цикл 
створення веб-платформи: від аналізу предметної області та формування концепції 
- до повної технічної реалізації, тестування, документування та публічного релізу 
продукту. Scope є базовою точкою узгодження між замовником та командою і 
забезпечує структурований, контрольований процес розробки. 
 
2.1.2 Statement of Work (SOW) 
 
Statement of Work (SOW) - це ключовий документ управління проєктом, який 
фіксує зміст робіт, визначає учасників, відповідальність сторін, обмеження, 
ключові результати та правила виконання проєкту. У контексті створення веб-
43 
 
застосунку GGame SOW використовується як базис для планування, оцінювання, 
контролю та завершення проєкту. 
Вступ та передумови проєкту 
Розробка GGame здійснюється як проєкт створення нового програмного 
продукту “з нуля”, без наявності попередніх версій чи спадкової системи. Це 
дозволяє команді проєкту застосувати сучасні підходи до архітектури, безпеки, 
UX/UI та DevOps. 
Проєкт спрямований на створення веб-застосунку, який дозволяє 
користувачам: 
 знаходити партнерів для спільної гри 
 отримувати доступ до сервісів професійних гравців 
 монетизувати свій ігровий час 
 взаємодіяти у межах ігрової екосистеми 
Стейкхолдери та відповідальні сторони 
У SOW фіксуються всі основні сторони проєкту: 
Product Partners (інвестори) 
 Приватні інвестори 
 Венчурні фонди 
 Власники бюджету 
Vendor Company (твоя команда) 
 відповідає за повний цикл розробки 
 забезпечує технічну реалізацію 
 надає звітність та проміжні результати 
Partner Companies (компанії партнерів) 
 хмарні сервіси 
 власники ігор 
 рекламодавці 
 постачальники API та зовнішніх послуг 
44 
 
Ключові ролі: 
 Product Owner 
 Project Manager 
 Business Analyst 
 UX/UI Designer 
 Backend Developers 
 Frontend Developers 
 QA Engineers 
 DevOps Engineer 
 Marketing Team 
Цілі проєкту (Project Goals) 
SOW фіксує бізнес-цілі, якими керується весь проєкт: 
 досягнення 200000 активних користувачів у перший рік роботи 
 отримання $500000 доходу у перший рік (підписки, комісії, реклама) 
 формування конкурентної платформи у сфері геймінгу та монетизації 
 забезпечення високої якості підбору партнерів через систему фільтрів, 
рейтингу та рекомендацій 
Deliverables (Очікувані результати проєкту) 
SOW містить список артефактів, які мають бути створені: 
 Project Plan 
 Requirement Specification (SRS) 
 User Interface Design 
 Backend Development 
 Database Setup 
 Website Content 
 Test System Setup 
 Live System Setup 
 Data Migration 
45 
 
 Progress Reports 
 Finished Product 
Усі ці результати формують основу контролю якості та відповідності 
проєктним вимогам. 
Checklist (Контрольний перелік проєкту) 
SOW включає чек-лист, який описує ключові управлінські дії: 
 визначити мету проєкту 
 сформувати ключові deliverables 
 визначити цільову аудиторію 
 сформувати вимоги до продукту 
 оцінити бюджет 
 визначити основні ризики та шляхи їхнього пом’якшення 
 встановити часові рамки 
 закріпити ролі та відповідальність 
 визначити канали комунікації з клієнтом 
 встановити критерії успіху 
 
Таблиця 2.1.2.1 Assumptions & Hypotheses (Припущення проєкту) 
№ Припущення Опис припущення Ризики 
1 Високий попит Передбачається, що існуватиме достатньо 4 
на сервіс велика аудиторія геймерів, готових платити за 
послуги професійних гравців. 
2 Лояльність Припускається, що платіжні системи (PayPal, 3 
платіжних Stripe, банки) не блокуватимуть транзакції, 
систем пов’язані з оплатою ігрових послуг. 
3 Відповідність Передбачається, що сервіс не порушуватиме 5 
правилам правила використання ігрових платформ 
платформ (Steam, PlayStation, Xbox) і не буде 
46 
 
заблокований за організацію платного 
геймінгу. 
4 Наявність Очікується, що достатня кількість професійних 3 
професійних гравців буде зацікавлена в монетизації своїх 
гравців навичок і регулярно користуватиметься 
сервісом. 
5 Законність Передбачається, що в юрисдикціях основних 4 
моделі користувачів немає обмежень або заборон на 
монетизації виплати гравцям. 
6 Стабільність Передбачається, що активність користувачів 3 
трафіку буде відносно рівномірною протягом доби, без 
різких піків, що можуть спричинити 
перевантаження серверів. 
7 Відсутність Припускається, що система модерації та 5 
шахрайства верифікації буде достатньо ефективною для 
мінімізації шахрайських схем. 
8 Конкуренто- Передбачається, що подібні платформи не 4 
спроможність зможуть швидко замінити сервіс або 
сервісу запропонувати кращі умови для користувачів. 
9 Позитивне Припускається, що ігрова спільнота 4 
сприйняття сприйматиме сервіс як корисний, а не як спосіб 
спільноти “купити перемоги”, що могло б викликати 
негативну реакцію. 
Ці гіпотези використовуються у Risk Management. 
 
Таблиця 2.1.2.2 Project Timeline (Графік виконання) 
Етап Дата завершення 
Analysis and Planning (Аналіз і планування) 10.02-25.02 
47 
 
UI/UX Development (Впровадження UI/UX) 26.02-16.03 
Backend Development (Розробка бекенда) 17.03-10.04 
Frontend Development (Розробка фронтенду) 11.04-05.05 
Payment Integration (Інтеграція платежних систем) 02.05-13.05 
Security and Compliance (Безпека та відповідності) 14.05-25.05 
Testing (Тестування) 14.05-29.05 
Deployment (Розгортання) 30.05-08.06 
Marketing and User Acquisition (Маркетинг і залучення 30.05-06.06 
користувачів) 
Maintenance and Support (Технічне обслуговування та 06.06 onwards 
підтримка) 
SOW фіксує саме високорівневі строки (milestones). 
 
2.1.3 Робоча структура проєкту (WBS) 
 
Робоча структура проєкту (Work Breakdown Structure, WBS) - це ієрархічна 
модель декомпозиції робіт, яка дозволяє структуровано представити весь обсяг 
діяльності [28], необхідної для створення веб-застосунку GGame. Метою побудови 
WBS є деталізація проєкту до рівня окремих задач, якими можна керувати, 
оцінювати їхню трудомісткість, визначати залежності та контролювати прогрес 
виконання. 
WBS формується за класичним принципом «згори донизу» - від основних 
етапів життєвого циклу до конкретних робочих елементів. Такий підхід забезпечує: 
 прозорість структури робіт 
 можливість розподілу відповідальності між учасниками команди 
 підвищення точності планування часу, ресурсів і бюджету 
 полегшення контролю за змінами у змісті проєкту 
48 
 
Відповідно до методології управління ІТ-проєктами, WBS для GGame 
охоплює десять основних блоків робіт, які повністю відповідають визначеним у 
SOW deliverables та узгоджені з високорівневим Scope проєкту. Кожен блок далі 
декомпозується на підзадачі та робочі елементи третього рівня, які відображають 
технологічні, організаційні та забезпечувальні роботи. 
До основних структурних розділів WBS входять: 
 Аналіз та планування 
 UI/UX розробка 
 Backend розробка 
 Frontend розробка 
 Security & Compliance 
 Інтеграція платіжних систем 
 Тестування 
 Деплоймент та DevOps 
 Маркетинг та залучення користувачів 
 Підтримка та технічний супровід 
Унутрішня структура кожного блоку представлена у деталізованій ієрархії, 
яка була розроблена з урахуванням: 
 вимог, визначених у Scope 
 очікуваних результатів, зазначених у SOW 
 часових меж, описаних у проєктному графіку 
 ролей і відповідальності, визначених у RACI-матриці 
На основі цієї декомпозиції формується календарне планування, розподіл 
ресурсів, оцінка вартості та управління ризиками, що будуть розглянуті у 
наступних підрозділах. 
Нижче наведена узагальнена WBS-діаграма, що відображає структуру робіт 
проєкту GGame: 
49 
 
 
Рисунок 2.1.3.1 – WBS діаграма 
 
2.1.4 Deliverables (очікувані результати проєкту) 
 
Управління змістом передбачає не лише визначення обсягу робіт, але й 
формування чітко окреслених результатів (deliverables) [29], які мають бути 
отримані в межах реалізації проєкту. Deliverables становлять основу контролю 
якості, визначення ступеня готовності продукту та фіксації досягнення ключових 
етапів життєвого циклу GGame. 
Створення веб-застосунку GGame включає комплекс технічних, 
організаційних та управлінських артефактів, кожен із яких забезпечує завершеність 
певної фази проєкту. Нижче подано перелік основних результатів, що формуються 
після виконання відповідних робіт, згідно з попередньо визначеним WBS та 
затвердженим SOW. 
Основні deliverables проєкту 
1. Project Plan (план управління проєктом) 
50 
 
Документ, що містить календарний план, визначення ролей, матрицю 
відповідальності, ресурси, бюджетні рамки, політику комунікацій та підходи до 
контролю змін. Він використовується як базовий інструмент координації всіх робіт. 
2. Requirement Specification (специфікація вимог) 
Формалізований опис функціональних та нефункціональних вимог до 
системи, включаючи сценарії користувача (use cases), атрибути якості, вимоги до 
інтеграцій, системи безпеки та бізнес-логіки. Специфікація є основою для технічної 
архітектури та розробки. 
3. User Interface Design (дизайн користувацького інтерфейсу) 
Набір UX/UI-артефактів: прототипи, макети інтерфейсу, користувацькі 
сценарії, прототипи мобільної та веб-версій. Цей deliverable також включає дизайн-
систему та документацію з використання UI-компонентів. 
4. Backend Development (серверна частина системи) 
Сюди входить реалізація бізнес-логіки, API, системи автентифікації, модулів 
пошуку гравців, рейтингової системи, монетизації, роботи з платіжними сервісами, 
а також інтеграція з базою даних та зовнішніми API. 
5. Database Setup (конфігурація бази даних) 
Створення структури БД, проектування таблиць, розробка схем зберігання 
профілів, транзакцій, історій замовлень, логів та статистики. Налаштовуються 
механізми резервного копіювання та оптимізації продуктивності. 
6. Website Content (інформаційне наповнення платформи) 
Структуровані сторінки продукту, описи сервісів, правила користування 
платформою, розділ FAQ, маркетингові тексти та інформація для SEO-оптимізації. 
Контент розробляється у співпраці з маркетинговою командою. 
7. Test System Setup (тестове середовище) 
Окреме середовище для функціонального, інтеграційного та 
навантажувального тестування. Включає інструменти логування, автоматизовані 
тести, звіти про дефекти та документацію тестових сценаріїв. 
8. Live System Setup (продакшн-середовище) 
51 
 
Налаштування серверів, доменної інфраструктури, SSL-сертифікатів, 
системи захисту даних, балансування навантаження та автоматизованого 
деплойменту. Це deliverable формально завершує технічну реалізацію. 
9. Data Migration (міграція даних) 
Хоча продукт створюється з нуля, у проєкт може входити перенесення даних 
із тестових середовищ у продакшн, а також ініціалізація ігрових бібліотек та 
профілів партнерів. 
10. Progress Reports (регулярна звітність) 
Проміжні звіти для Product Partners і керівництва, які включають аналіз 
виконаних робіт, оновлені оцінки, ризики та пропозиції щодо оптимізації плану. 
11. Finished Product (готовий веб-застосунок GGame) 
Фінальний результат проєкту - повністю функціональний веб-застосунок з 
можливістю реєстрації користувачів, пошуку партнерів, проведення транзакцій, 
комунікаційних функцій, системою оцінок, профілів, модерації та безпечної 
монетизації ігрового часу. 
Роль Deliverables у процесі управління проєктом 
Кожен deliverable: 
 має свого відповідального (відповідно до RACI-матриці) 
 є підставою для завершення певної фази роботи 
 може бути використаний як вхідний артефакт для наступного етапу 
 підлягає контролю якості та затвердженню Product Owner-ом 
Наявність чітко визначених deliverables забезпечує прозорість виконання, 
дозволяє контролювати відповідність результатів початковим вимогам і створює 
основу для прийняття управлінських рішень щодо ресурсів, вартості та термінів. 
 
 
 
 
 
52 
 
2.2 Управління ресурсами 
 
2.2.1 Трудові ресурси проєкту 
 
Успішність реалізації програмного проєкту значною мірою залежить від 
правильного планування та розподілу трудових ресурсів. Для веб-застосунку 
GGame була сформована команда, структура якої відповідає стандартам 
управління ІТ-проєктами та забезпечує повне покриття усіх фаз життєвого циклу 
продукту - від аналізу до розгортання та тестування. 
Склад команди та основні ролі 
На основі внутрішнього плану проєкту та матриці відповідальностей (RACI), 
команда включає такі ключові ролі: 
 Project Manager (PM) - організація процесів, управління змістом, часом, 
бюджетом та ризиками 
 Business Analyst (BA) - збір вимог, моделювання бізнес-процесів, підготовка 
документації 
 UX/UI Designer - створення інтерфейсних рішень, прототипів і макетів 
застосунку 
 Frontend Developers - реалізація клієнтської частини системи 
 Backend Developers - розробка серверної логіки, API, бази даних 
 QA Engineers - тестування функціоналу, перевірка якості продукту 
 DevOps Engineer - автоматизація збірки, CI/CD, конфігурація середовища 
 Marketing Team - підготовка стратегії залучення користувачів та рекламних 
активностей 
Розподіл трудових ресурсів та завантаження команди 
Згідно з таблицею Estimate та даними з файлу EVM, тривалість виконання 
основних етапів виглядає наступним чином: 
 Analysis & Planning - 15 днів (PM 60 год, BA 80 год) 
53 
 
 UI/UX Design - 12 днів (UX/UI Designer 96 год) 
 Backend Development - 20 днів (Backend Devs 160 год сумарно) 
 Frontend Development - 18 днів (Frontend Devs 144 год сумарно) 
 Payment Integration - 8 днів (Backend + Frontend 64 год) 
 Security & Compliance - 10 днів (Backend + DevOps 80 год) 
 Testing - 12 днів (QA Engineers 96 год) 
 Deployment - 8 днів (DevOps 64 год) 
 Marketing & User Acquisition - 10 днів (Marketing Team 80 год) 
Ці значення були узгоджені з плановими витратами (PV) у файлі EVM, де 
кожен етап має свій прогнозований обсяг робіт та бюджет. 
Принцип розподілу робочого часу 
У проєкті застосовується змішаний підхід: 
 послідовна робота у фазах, де етапи залежать один від одного (наприклад, 
Frontend після Backend API) 
 паралельна робота, коли це можливо (BA + PM + Designer на початку 
проєкту) 
 перехресне залучення, що дозволяє оптимально розподіляти завантаження 
(Backend бере участь у Payment Integration та Security) 
Такий підхід дає можливість: 
 скоротити загальну тривалість проєкту 
 уникнути простоїв 
 забезпечити рівномірне використання ресурсів 
 мінімізувати конфлікти між задачами 
Загальний обсяг трудовитрат 
На основі EVM узагальнена трудомісткість проєкту становить: 
 планові трудові витрати (PV) - сума годин усіх фаз відповідно до Estimate 
 фактичні витрати (AC) - використовуються у розділі 2.4 
54 
 
 закладений трудовий бюджет проєкту - синхронізований із загальним 
бюджетом (General Budget) 
У цьому підрозділі фіксується лише планове ресурсне забезпечення, тоді як 
аналіз відхилень та ефективності ресурсів виконується окремо в розділі управління 
вартістю (2.4). 
 
2.2.2 Матеріальні ресурси проєкту 
 
Матеріальні ресурси у межах розробки веб-застосунку GGame охоплюють ті 
елементи, що забезпечують фізичну, технічну та інфраструктурну підтримку 
роботи команди. На відміну від трудових ресурсів, які представлені людськими 
компетенціями, матеріальні ресурси є вимірюваними й мають чітку грошову та 
функціональну характеристику. Їхнє правильне планування допомагає уникнути 
затримок у розробці, оптимізувати витрати та забезпечити стабільність технічного 
середовища. 
Інфраструктурні ресурси 
Для роботи над проєктом використовується набір хмарних та локальних 
сервісів, які забезпечують: 
 хостинг вихідного коду 
 інструменти для CI/CD 
 хмарне середовище для розгортання тестового та робочого серверів 
 інструменти моніторингу 
 системи аналітики 
До основних інфраструктурних елементів належать: 
 Хмарний сервер (production environment) - для розгортання веб-застосунку 
 Тестовий сервер (staging environment) - для перевірки нових функцій 
 Сховище бази даних - забезпечує зберігання користувацьких даних 
 Система логування та моніторингу (наприклад, Sentry, Prometheus) 
55 
 
 Git-репозиторій із приватним доступом 
Усі ці елементи є необхідними для забезпечення надійності, продуктивності 
та інформаційної безпеки системи. 
Програмні інструменти та ліцензії 
У процесі розробки використовуються такі програмні засоби: 
 середовище дизайну Figma 
 середовища розробки (IDE): WebStorm / VS Code 
 API-тестування (Postman) 
 DevOps-інструменти (Docker, CI/CD pipelines) 
 системи керування задачами (Jira / Trello) 
Частина інструментів використовує безкоштовні тарифні плани, частина - 
платні. 
До матеріальних ресурсів також належать інструменти, необхідні для роботи 
спеціалістів: 
 робочі ноутбуки або стаціонарні ПК 
 периферія (мікрофони, навушники, камери - важливо для тестування voice-
functional) 
 мережеве обладнання 
 системи резервного живлення (для команд із офісним форматом роботи) 
Хоч команда може працювати віддалено, базове обладнання все одно є 
обов’язковим для забезпечення якісного процесу розробки. 
Фінансова оцінка матеріальних ресурсів 
На основі внутрішнього бюджету проєкту (General Budget) було визначено 
орієнтовні витрати на матеріальні ресурси: 
 Сервери та хмарна інфраструктура - 200-350 USD на місяць 
 Робочі інструменти (камери, периферія, мікрофони тощо) - 100-150 USD на 
учасника одноразово 
56 
 
 Платні програмні сервіси та ліцензії - 50-120 USD на місяць залежно від 
інструментів 
 Моніторинг та логування - 20-40 USD на місяць 
Ці значення є достатніми для повного функціонування середовища розробки 
й підтримки проєкту. 
Роль матеріальних ресурсів у забезпеченні якості та стабільності проєкту 
Матеріальні ресурси відіграють ключову роль у: 
 забезпеченні доступності сервісу 24/7 
 відповідності вимогам безпеки та швидкодії 
 можливості швидкого оновлення та масштабування 
 стабільності роботи команди впродовж усього життєвого циклу проєкту 
Матеріальне забезпечення є невід’ємною частиною управління ресурсами та 
прямо впливає на якість фінального продукту. 
 
2.2.3 Оцінка ресурсоємності проєкту 
 
Оцінка ресурсоємності проєкту є ключовим етапом планування, що дозволяє 
визначити реальний обсяг трудових, матеріальних та фінансових ресурсів, 
необхідних для успішної реалізації веб-застосунку GGame. Цей підрозділ базується 
на інтеграції даних з Estimate, EVM та General Budget, які слугують основою для 
формування узгодленої моделі використання ресурсів у межах проєкту. 
Для визначення обсягів необхідних трудових ресурсів та оцінки загальної 
ресурсоємності проєкту було сформовано попередній Estimate-план, що містить 
тривалість кожної фази, обсяг трудовитрат команди та прогнозовані витрати часу 
на окремих виконавців. Дана таблиця використовується як базовий документ для 
подальшого планування графіка, бюджету та контрольних точок проєкту. Повна 
структура оцінки наведена нижче. 
 
 
57 
 
Таблиця 2.2.3.1 - Estimate (частина 1) 
Елемент Коментарі Залежності Пріоритет 
декомпозиції 
Аналіз і планування Загальні дослідження та – Високий 
підготовка 
UI/UX розробка Дизайн користувацького Аналіз і Середній 
інтерфейсу планування 
Backend-розробка Серверна логіка, база Визначення Високий 
даних, API вимог 
Frontend-розробка Реалізація веб-інтерфейсу UI/UX, Високий 
Backend 
Безпека та Забезпечення безпеки Backend- Високий 
відповідність системи та юридичної розробка 
відповідності 
Інтеграція платежів Реалізація безпечних Backend- Високий 
платіжних систем розробка 
Тестування Перевірка всіх елементів Frontend, Високий 
системи Backend 
Розгортання Запуск системи Тестування Високий 
Маркетинг і Приведення користувачів UI/UX Середній 
залучення на платформу розробка 
користувачів 
Підтримка та Забезпечення безперервної Розгортання Високий 
обслуговування роботи та оновлень 
Підсумок    
 
 
 
 
58 
 
Таблиця 2.2.3.1 - Estimate (частина 2) 
Оптимістичний Песимістичний Найймовірніший Очікуваний 
8,00 21,00 14,00 14,33 
16,00 28,00 21,00 21,67 
16,00 28,00 21,00 21,67 
16,00 34,00 21,00 23,67 
15,00 25,00 20,00 20,00 
10,00 18,00 14,00 14,00 
10,00 21,00 14,00 15,00 
15,00 25,00 20,00 20,00 
10,00 21,00 14,00 15,00 
10,00 21,00 14,00 15,00 
126,00 221,00 173,00 180,33 
 
Таблиця 2.2.3.1 - Estimate (частина 3) 
Модульне Перевірка Виправлення Очікуваний 
тестування коду дефектів фінал 
3,58 1,43 2,87 22,22 
5,42 2,17 4,33 33,58 
5,42 2,17 4,33 33,58 
5,92 2,37 4,73 36,68 
5,00 10,00 4,00 39,00 
3,50 1,40 2,80 21,70 
3,75 1,50 3,00 23,25 
5,00 2,00 4,00 31,00 
3,75 1,50 3,00 23,25 
3,75 1,50 3,00 23,25 
45,08 26,03 36,07 287,52 
59 
 
 
Ці дані є вихідною точкою для розрахунків вартості, формування 
декомпозиції робіт та визначення критичного шляху. Подальші розділи аналізують, 
як ці оцінки впливають на ресурсний розподіл та часову модель реалізації проєкту. 
Аналіз трудових ресурсів у межах проєкту 
На основі даних оцінки, сформованих у файлі Estimate та вирівняних 
відповідно до планових величин у моделі EVM, визначено загальний обсяг 
трудових ресурсів, необхідних для виконання проєкту. 
Трудові ресурси оцінюються на рівні загальної кількості годин, необхідних 
для реалізації етапів, деталізація за ролями та етапами винесена до підрозділу 2.2.1. 
У рамках оцінки ресурсоємності аналізується лише зведений обсяг робіт, 
який становить: 
 сукупний обсяг робочих годин команди 
 очікувана інтенсивність роботи в різні фази 
 рівномірність або нерівномірність навантаження між етапами 
Оцінка показує, що проєкт характеризується помірним рівнем трудових 
витрат у фазах аналізу та дизайну та піковим навантаженням у фазах backend- та 
frontend-розробки. Це дозволяє завчасно визначити періоди, коли потрібно 
забезпечити найбільшу координацію роботи команди. 
Матеріальна ресурсоємність проєкту 
Матеріальні ресурси, визначені у файлі General Budget, включають 
інфраструктурні та сервісні витрати, необхідні для стабільної роботи застосунку та 
підтримки процесу розробки. 
У межах оцінки ресурсоємності підсумовується загальна потреба в 
матеріальних ресурсах, зокрема: 
 хмарна інфраструктура 
 серверні потужності та зберігання даних 
 доменні імена та SSL-сертифікати 
 інструменти командної співпраці (Figma, Jira, Slack) 
60 
 
 платіжні інтеграційні сервіси 
 зовнішні API, необхідні для інтеграції 
Усі вартісні значення будуть детально розкриті в розділі 2.4 Управління 
вартістю, а в цьому підрозділі відображається лише загальна структура 
матеріальної ресурсоємності. 
Календарна ресурсоємність 
Календарна ресурсоємність проєкту визначає, як саме ресурси - трудові та 
матеріальні - розподіляються у часі. У цьому контексті оцінюються: 
 рівномірність використання трудових ресурсів 
 періоди пікового навантаження 
 фази, де споживання ресурсів мінімальне 
 синхронізація роботи команд 
Зведений аналіз показує, що: 
 на початкових етапах (аналіз та планування) ресурсне навантаження є 
відносно низьким 
 у фазах backend і frontend-розробки спостерігається найвищий рівень 
інтенсивності використання ресурсів 
 під час тестування ресурси перерозподіляються на користь QA-команди 
 під час деплойменту основна частина завантаження припадає на DevOps 
Ці дані будуть використані у підрозділі 2.3 Управління часом для побудови 
діаграми Ганта та формування критичного шляху. 
Інтегрована модель ресурсоємності 
Використовуючи дані з трьох джерел - EVM, Estimate та General Budget - була 
сформована узагальнена модель ресурсоємності, що дозволяє: 
 визначити реалістичні строки виконання проєкту 
 оцінити необхідний рівень фінансування 
 запобігти перевитраті ресурсів 
 оптимізувати навантаження на команду 
61 
 
 точно прогнозувати витрати відповідно до етапів 
Модель ресурсоємності виступає основою для наступних процесів: 
 управління часом (розділ 2.3) 
 управління вартістю (розділ 2.4) 
 управління якістю (розділ 2.5) 
 управління ризиками (розділ 2.6) 
 
2.2.4 Управління залученням та використанням ресурсів 
 
Ефективне управління залученням та використанням ресурсів є критичним 
для забезпечення стабільного ходу проєкту GGame, мінімізації затримок та 
недопущення надмірного навантаження на команду. У цьому підрозділі розглянуто 
підхід до планування, розподілу та контролю ресурсів на всіх ключових етапах 
розробки. 
Принципи управління ресурсами 
Управління ресурсами в межах проєкту ґрунтується на таких принципах: 
 Прозоре планування - усі ресурси (трудові та матеріальні) визначаються 
заздалегідь на основі SOW, Scope та WBS 
 Раціональний розподіл - ресурси розподіляються відповідно до тривалості та 
складності етапів 
 Гнучка корекція - у разі змін у вимогах чи ризиків ресурсний план може бути 
оновлено 
 Пріоритизація критичних завдань - ключові ресурси передусім виділяються 
на елементи критичного шляху 
 Уникнення «resource overload» - недопущення ситуацій, коли одна роль 
перевантажена понад розумну норму 
Процес залучення ресурсів 
Залучення ресурсів здійснюється у декілька етапів: 
62 
 
1. Визначення потреби у ресурсах 
На основі WBS формується первинний перелік ролей, інструментів та 
зовнішніх сервісів, необхідних для виконання кожного пакету робіт. 
2. Погодження обсягів ресурсів 
Цей етап передбачає: 
 співставлення трудових витрат з реальними можливостями команди 
 перевірку доступності матеріальних ресурсів 
 узгодження потреб з бюджетними обмеженнями 
3. Офіційне виділення ресурсів 
Після погодження проєктний менеджер розподіляє ресурси між етапами 
проєкту відповідно до: 
 графіка робіт 
 ролей команди 
 доступності фахівців 
 матеріальних потреб 
Управління використанням трудових ресурсів 
Використання трудових ресурсів контролюється протягом усього проєкту: 
 PM контролює відповідність фактичних трудовитрат плановим 
 BA та UX/UI залучаються у перших фазах і частково у проміжних 
 Frontend і Backend розробники найбільше задіяні у середині проєкту 
 QA залучається хвилеподібно згідно з графіком інкрементів 
 DevOps виконує роботи у точках інтеграції та деплойменту 
 Marketing Team активна у завершальній частині проєкту 
Цей підхід мінімізує простої та перевантаження фахівців, забезпечуючи 
оптимальний темп виконання робіт. 
Управління використанням матеріальних ресурсів 
Матеріальні ресурси залучаються відповідно до етапів робіт: 
 хмарні сервери - під час backend-розробки, тестування та релізу 
63 
 
 платіжні інструменти - у фазі Payment Integration 
 інструменти дизайну та командної роботи - з першого дня проєкту 
 SSL, домен, CDN - під час деплойменту 
 рекламні бюджети - у маркетинговій фазі 
Управління здійснюється за принципом just-in-time, коли ресурс активується 
лише тоді, коли він потрібен. 
Моніторинг і контроль ресурсів 
Контроль ресурсів виконується на основі даних з EVM та регулярних звітів 
команди: 
 планові витрати порівнюються з фактичними 
 визначаються відхилення (як позитивні, так і негативні) 
 PM приймає коригувальні рішення 
 забезпечується прозорість використання бюджету 
Регулярні синхронізації між PM, Dev Leads і QA дозволяють підтримувати 
стабільний ресурсний баланс. 
Оптимізація та адаптація ресурсу 
У разі необхідності PM може ініціювати: 
 перерозподіл завдань між розробниками 
 перегляд пріоритетів 
 тимчасове нарощення ресурсів (додатковий розробник, зовнішній 
консультант) 
 перенесення частини матеріальних витрат на наступні етапи 
Гнучка схема управління дозволяє уникнути затримок та зберегти якість 
продукту. 
 
 
 
 
64 
 
2.3 Управління часом 
 
Управління часом [30] у межах розробки веб-застосунку GGame є одним із 
визначальних елементів успішності всього ІТ-проєкту. В умовах конкуренції на 
ринку цифрових сервісів, обмеженого бюджету та необхідності синхронізації 
роботи мультидисциплінарної команди саме коректно спроєктований календарний 
план дозволяє забезпечити прогнозованість, контрольованість і ритмічність 
виконання робіт. Планування часу базується на визначенні послідовності процесів, 
їхньої тривалості, залежностей між ними та ресурсного навантаження [31]. 
Основою для формування фінального календарного плану стали фактичні 
розрахунки трудовитрат і тривалості, представлені в системі контролю виконання 
проєкту, які були узгоджені зі змістом робіт, WBS та обсягом функціональних 
вимог. 
Структура проєкту складається з п’яти основних фаз, кожна з яких має 
визначені результати та чітко встановлені часові межі. Тривалість фаз і загальні 
трудовитрати наведені нижче та повністю відповідають інтегрованим плановим 
показникам проєкту: 
 
Таблиця 2.3.1 Тривалість фаз 
Етап проєкту Тривалість (календарні дні) Людино-години 
Ініціація та планування 15 144 
проекту 
UI/UX та початкова 19 128 
розробка 
Основна фаза розробки 57 456 
Тестування та безпека 15 192 
Розгортання та маркетинг 9 144 
 
65 
 
Загальна тривалість виконання проєкту становить 115 календарних днів, не 
враховуючи можливі затримки чи форс-мажорні обставини. Усі фази пов’язані між 
собою послідовними залежностями типу finish-to-start, що забезпечує логічність та 
контрольованість переходу між етапами. Наприклад, дизайн інтерфейсу не може 
бути розпочатий до завершення фази збору та аналізу вимог, а основна розробка - 
до затвердження UX/UI та початкової архітектури сервісу. Такі залежності 
дозволяють уникнути переробок і зменшують ризики накопичення технічного 
боргу. 
Центральним елементом календарного планування є формування критичного 
шляху, який визначає мінімально можливу тривалість усього проєкту. Згідно з 
аналізом послідовності робіт, критичний шлях проходить через фази: Initiation & 
Planning → UI/UX & Initial Development → Core Development → Testing & Security 
→ Deployment. Саме вони мають нульовий резерв часу, тобто їхнє затримання 
безпосередньо збільшує загальну тривалість проєкту. Особливо трудомістким і 
визначальним є етап Core Development, на який припадає понад 39% від загального 
обсягу людино-годин (456 год). Саме тому до нього висуваються підвищені вимоги 
щодо ресурсного забезпечення, контролю прогресу та управління ризиками. 
Для кожного етапу були визначені не лише тривалість і трудовитрати, а й 
структуру часу всередині нього. Наприклад, фаза UI/UX включає не лише 
створення макетів, але й їх узгодження, ревізії, прототипування та передання у 
розробку. Testing & Security об’єднує проведення ручного й автоматизованого 
тестування, перевірку безпеки, виправлення дефектів і повторну перевірку. Такий 
підхід забезпечує реалістичність планування та унеможливлює заниження 
тривалості робіт. 
Окреме значення в управлінні часом має регулярний контроль прогресу через 
аналіз планових (PV) і фактичних показників виконання. Система моніторингу 
дозволяє оцінювати відхилення від графіка та своєчасно коригувати дії проєктної 
команди. Завдяки цьому керівник проєкту отримує можливість оперативно 
66 
 
реагувати на проблеми, оптимізувати завантаження фахівців і приймати рішення 
щодо перерозподілу ресурсів [32]. 
Загалом процес управління часом забезпечує: 
 прозору та прогнозовану модель виконання проєкту 
 контроль критичного шляху та дотримання ключових віх 
 узгодженість між плановими трудовитратами та реальними можливостями 
команди 
 вчасне виявлення ризиків затримок і своєчасне коригування графіка 
Таким чином, застосування формалізованого підходу до календарного 
планування забезпечує високу керованість, зменшує ризики зривів строків і 
дозволяє досягти цільових параметрів розробки веб-застосунку GGame у 
встановлені часові межі. 
 
2.4 Управління вартістю 
 
Управління вартістю в ІТ-проєктах [33] є одним із ключових процесів, що 
визначає життєздатність та економічну успішність кінцевого продукту. Для 
проєкту створення веб-застосунку GGame управління вартістю здійснюється на 
основі інтегрованого використання методів планування бюджету [34], оцінки 
витрат, контролю фактичних витрат, аналізу відхилень та управління фінансовими 
ризиками. 
На основі обсягів робіт, визначених у попередніх підрозділах, було 
сформовано загальний бюджет проєкту, який враховує витрати на оплату праці, 
інфраструктуру, маркетинг, безпеку та експлуатаційні витрати [35]. Зведений 
бюджет подано у таблиці нижче. 
 
 
 
 
67 
 
Таблиця 2.4.1 General bubget (частина 1) 
    Праця  
 Проектна Кому призначено Заплановані Фактичні $/HR 
діяльність години години 
1 Аналіз і планування Керівник проекту 144,00 138,00 $25,00  
2 UI/UX Розробка UI/UX Дизайнер 128,00 128,00 $16,00  
3 Розробка Backend Backend 168,00 178,00 $28,00  
розробник 
4 Розробка Frontend Frontend 208,00 192,00 $25,00  
розробник 
5 Безпека та Спеціаліст з 80,00 78,00 $30,00  
відповідність безпеки 
6 Інтеграція платежів Інженер FinTech 80,00 74,00 $30,00  
7 Тестування QA 112,00 112,00 $18,00  
8 Розгортання DevOps 64,00 62,00 $35,00  
9 Маркетинг Менеджер з 80,00 78,00 $12,00  
маркетингу 
10 Технічна підтримка Команда 112,00 112,00 $10,00  
Підтримки 
 ПРОМІЖНИЙ ПІДСУМОК $26 
084,00 
 
Таблиця 2.4.1 General bubget (частина 2) 
Матеріали   Стала  
ОДИНИЦІ $/ОДИНИЦІ Подорожі Обладнання ПЕРЕДБАЧЕНО 
     $ 38 338,00  
3,0 $100,00  0,0 $250,00  $100,00  4 250,00  
2,0 $60,00  0,0 $600,00  $100,00  2 868,00  
68 
 
5,0 $200,00  0,0 $600,00  $100,00  6 404,00  
3,0 $80,00  0,0 $400,00  $100,00  5 940,00  
3,0 $250,00  0,0 $500,00  $100,00  3 750,00  
2,0 $400,00  0,0 $200,00  $100,00  3 500,00  
3,0 $250,00  0,0 $400,00  $100,00  3 266,00  
3,0 $280,00  0,0 $200,00  $100,00  3 380,00  
4,0 $500,00  0,0 $200,00  $100,00  3 260,00  
2,0 $200,00  0,0 $100,00  $100,00  1 720,00  
 $7 200,00  $0,00 $3 450,00  $1 $38 338,00 
000,00  
 
Таблиця 2.4.1 General bubget (частина 3) 
Ризик непередбачених  Резерв Актуальний Актуальний 
обставин управління + 12% 
7% Різ. 5%   
   $ 38 234,00  $ 42 926,08  
290,50  50,0 207,50  4 150,00  4 748,00  
204,26  50,0 145,90  2 918,00  3 218,16  
471,38  50,0 336,70  6 734,00  7 212,08  
391,30  50,0 279,50  5 590,00  6 610,80  
261,80  50,0 187,00  3 740,00  4 198,80  
235,90  50,0 168,50  3 370,00  3 904,40  
232,12  50,0 165,80  3 316,00  3 663,92  
235,20  50,0 168,00  3 360,00  3 783,20  
230,02  50,0 164,30  3 286,00  3 654,32  
123,90  50,0 88,50  1 770,00  1 932,40  
 $500,00  $38 234,00  $42 926,08 
 
69 
 
Представлений бюджет є базовою фінансовою моделлю, що 
використовується для формування планових витрат (PV) та для подальшого 
порівняння фактичних показників у процесі контролю вартості, що детально 
розглянуто у наступних підрозділах. 
Планування бюджету та визначення вартості етапів 
Бюджет GGame формується на основі прогнозованих витрат [36], що 
визначені в EVM. Проект складається з дев’яти ключових етапів, кожен з яких має 
власний обсяг робіт у годинах та грошовому еквіваленті. Усі витрати розраховано, 
виходячи з запланованої кількості людино-годин та погодинних ставок відповідних 
спеціалістів. Таким чином, кожен етап має чітко визначений бюджет PV, що 
дозволяє оцінювати виконання за допомогою підходу Earned Value Management. 
Згідно з EVM, загальна планова вартість (Total PV) проєкту становить: 
 $68 640, що є сумою вартості всіх трудових витрат за етапами. 
У файл також внесено фактичну вартість (AC) за вже завершеними частинами 
робіт, що дає можливість проводити аналіз ефективності виконання етапів. 
Нижче наведено узгоджений бюджет етапів відповідно до EVM: 
 Analysis & Planning: PV = $7 200 
 UI/UX Design: PV = $9 600 
 Backend Development: PV = $14 400 
 Frontend Development: PV = $12 960 
 Payment Integration: PV = $4 320 
 Security & Compliance: PV = $6 480 
 Testing: PV = $7 680 
 Deployment: PV = $3 840 
 Marketing & User Acquisition: PV = $2 160 
Саме ці значення є базовими для контролю виконання бюджету та 
формування вартості проєкту. 
Контроль витрат за допомогою методу Earned Value Management 
70 
 
Метод EVM був застосований для того, щоб об’єктивно оцінювати 
відповідність між запланованою вартістю, фактичними витратами та обсягом 
виконаної роботи. У файлі EVM наведено такі ключові метрики: 
 PV (Planned Value) - запланований обсяг робіт у грошовому вираженні 
 EV (Earned Value) - реальний виконаний обсяг робіт 
 AC (Actual Cost) - фактично витрачені кошти 
Ці показники дозволяють розрахувати Cost Performance Index (CPI) та 
Schedule Performance Index (SPI), які застосовуються для оцінки поточного стану 
проєкту: 
 CPI = EV / AC - показує, наскільки економно витрачаються ресурси 
 SPI = EV / PV - показує відповідність виконання графіку 
Нижче наведено повну таблицю PV, EV, AC та похідних показників, що 
використовуються для визначення продуктивності та прогнозування завершення 
проєкту. 
 
Таблиця 2.4.2 EVM (частина 1) 
Дата Дата Заплановані 
№ Завдання  Тривалість 
початку фіналу години 
Ініціація та планування 2/10/2024 2/25/2024 15 144 
Аналіз платформи 
1 2/10/2024 2/15/2024 5 40 
конкурентів 
2 Опитування користувачів 2/12/2024 2/15/2024 3 24 
3 Функціональні вимоги 2/16/2024 2/21/2024 5 40 
4 Нефункціональні вимоги 2/20/2024 2/25/2024 5 40 
UI/UX та початкова розробка 2/26/2024 3/16/2024 19 128 
5 Дизайн потоку користувачів 2/26/2024 2/29/2024 3 24 
6 Створення каркаса 3/1/2024 3/6/2024 5 40 
7 Макети інтерфейсу 3/7/2024 3/12/2024 5 40 
71 
 
8 Тестування користувача 3/13/2024 3/16/2024 3 24 
Основна фаза розробки 3/17/2024 5/13/2024 57 456 
9 Дизайн бази даних 3/17/2024 3/22/2024 5 40 
Планування 
10 3/23/2024 3/27/2024 4 32 
масштабованості 
11 Модуль автентифікації 3/28/2024 4/3/2024 6 48 
Оптимізація отримання 
12 4/4/2024 4/10/2024 6 48 
даних 
13 Реалізація сторінок 4/11/2024 4/25/2024 14 112 
14 Пошукова оптимізація 4/22/2024 4/27/2024 5 40 
15 Інтеграція API 4/28/2024 5/2/2024 4 32 
16 Обробка помилок 5/2/2024 5/5/2024 3 24 
Налаштування платіжного 
17 5/2/2024 5/7/2024 5 40 
шлюзу 
18 Моніторинг транзакцій 5/8/2024 5/13/2024 5 40 
Тестування та безпека 5/14/2024 5/29/2024 15 192 
Впровадження шифрування 
19 5/14/2024 5/19/2024 5 40 
даних 
20 Відповідність GDPR 5/20/2024 5/25/2024 5 40 
21 Модульне тестування 5/14/2024 5/21/2024 7 56 
22 Інтеграційне тестування 5/22/2024 5/29/2024 7 56 
Розгортання та маркетинг 5/30/2024 6/8/2024 9 144 
23 Налаштування сервера 5/30/2024 6/3/2024 4 32 
Впровадження конвеєра 
24 6/4/2024 6/8/2024 4 32 
CI/CD 
25 Кампанії в соц мережах 6/1/2024 6/6/2024 5 40 
26 SEO оптимізація 5/30/2024 6/4/2024 5 40 
 
72 
 
Таблиця 2.4.2 EVM (частина 2) 
Витрачені Запланована Справжня Заграфована Значення %  до 
Заробіток 
години вартість ціна вартість ціни кінця 
138 $7 200,00 $7 200,00 $6 900,00 $0,00 $300,00  
40 $2 000,00 $2 000,00 $2 000,00 $0,00 $0,00 100% 
20 $1 200,00 $1 200,00 $1 000,00 $0,00 $200,00 100% 
36 $2 000,00 $2 000,00 $1 800,00 $0,00 $200,00 100% 
42 $2 000,00 $2 000,00 $2 100,00 $0,00 -$100,00 100% 
128 $6 400,00 $6 400,00 $6 400,00 $0,00 $0,00  
24 $1 200,00 $1 200,00 $1 200,00 $0,00 $0,00 100% 
40 $2 000,00 $2 000,00 $2 000,00 $0,00 $0,00 100% 
44 $2 000,00 $2 000,00 $2 200,00 $0,00 -$200,00 100% 
20 $1 200,00 $1 200,00 $1 000,00 $0,00 $200,00 100% 
444 $22 800,00 $22 800,00 $22 200,0 $0,00 $600,00  
42 $2 000,00 $2 000,00 $2 100,00 $0,00 -$100,00 100% 
32 $1 600,00 $1 600,00 $1 600,00 $0,00 $0,00 100% 
54 $2 400,00 $2 400,00 $2 700,00 $0,00 -$300,00 100% 
50 $2 400,00 $2 400,00 $2 500,00 $0,00 -$100,00 100% 
100 $5 600,00 $5 600,00 $5 000,00 $0,00 $600,00 100% 
40 $2 000,00 $2 000,00 $2 000,00 $0,00 $0,00 100% 
36 $1 600,00 $1 600,00 $1 800,00 $0,00 -$200,00 100% 
16 $1 200,00 $1 200,00 $800,00 $0,00 $400,00 100% 
38 $2 000,00 $2 000,00 $1 900,00 $0,00 $100,00 100% 
36 $2 000,00 $2 000,00 $1 800,00 $0,00 $200,00 100% 
190 $9 600,00 $9 600,00 $9 500,00 $0,00 $100,00  
43 $2 000,00 $2 000,00 $2 150,00 $0,00 -$150,00 100% 
35 $2 000,00 $2 000,00 $1 750,00 $0,00 $250,00 100% 
73 
 
60 $2 800,00 $2 800,00 $3 000,00 $0,00 -$200,00 100% 
52 $2 800,00 $2 800,00 $2 600,00 $0,00 $200,00 100% 
140 $7 200,00 $7 200,00 $7 000,00 $0,00 $200,00  
32 $1 600,00 $1 600,00 $1 600,00 $0,00 $0,00 100% 
30 $1 600,00 $1 600,00 $1 500,00 $0,00 $100,00 100% 
36 $2 000,00 $2 000,00 $1 800,00 $0,00 $200,00 100% 
42 $2 000,00 $2 000,00 $2 100,00 $0,00 -$100,00 100% 
 
На основі наведених показників проводиться аналіз індексу продуктивності 
витрат (CPI), індексу продуктивності графіка (SPI), а також прогнозується 
очікувана вартість завершення (EAC). Це дозволяє своєчасно виявляти відхилення 
та коригувати план реалізації проєкту. 
Згідно з наданими значеннями з EVM, проєкт на момент контролю 
демонструє наближення AC до PV, що свідчить про збалансоване використання 
бюджету та відсутність значних перевитрат. EV у більшості етапів відповідає PV, 
що означає виконання робіт відповідно до графіка. Однак етапи Payment Integration 
та Security & Compliance потенційно мають ризики відхилень, оскільки їхня 
складність може змінювати фактичну тривалість, і це враховується під час 
подальшого контролю вартості. 
Структура витрат та категорії бюджету 
На підставі даних General Budget сформовано структуру витрат, до якої 
входять: 
 трудові витрати (основний компонент бюджету) 
 хмарна інфраструктура 
 домен та хостинг 
 платежі стороннім сервісам (Stripe, PayPal API fees) 
 маркетинговий бюджет 
 витрати на безпеку та аудит 
74 
 
 операційні витрати 
Структура бюджету узгоджена з плановими значеннями PV та загальною 
вартістю проєкту з EVM. Вона забезпечує повний огляд економічної складової 
проєкту та дозволяє оцінити, які статті мають найбільший вплив на загальний 
бюджет. Найбільш витратними є: backend development (21%), frontend development 
(19%), UI/UX (14%), що відповідає стандартній структурі для веб-проєктів. 
Планування резервів та управління відхиленнями 
Для уникнення фінансових ризиків передбачено резерв управління 
(Management Reserve), який становить 10% від загального PV, тобто $6 864. Цей 
резерв використовується виключно за рішенням керівника проєкту у випадку 
критичних змін у вимогах, появи непередбачених технічних труднощів або 
необхідності додаткових робіт з інтеграції. 
Для дрібних відхилень використовується Contingency Reserve, який 
формується на рівні етапів і інтегрується у їхні PV. Він покликаний покривати 
ризики, передбачені реєстром ризиків (Risk Register), зокрема ризики комплексної 
інтеграції, залежності від сторонніх API та можливих проблем із навантаженням 
серверів. 
Висновок 
Управління вартістю в проєкті GGame базується на комплексній інтеграції 
даних з EVM та General Budget, що дозволяє підтримувати високу точність оцінок 
і забезпечує контроль фінансової ефективності на кожному етапі розробки. Проєкт 
демонструє фінансову стабільність, збалансоване використання бюджету та 
високий рівень відповідності плану, що є критично важливим для досягнення 
бізнес-цілей і успішного запуску веб-застосунку. 
 
2.5 Управління якістю 
 
Управління якістю в межах розробки веб-застосунку GGame спрямоване на 
забезпечення відповідності продукту встановленим функціональним і 
75 
 
нефункціональним вимогам, а також на досягнення стабільної, безпечної та зручної 
у використанні системи, що здатна працювати з високим навантаженням і 
критичними бізнес-процесами, такими як оплати та комунікація між гравцями. 
Оскільки GGame включає пошук партнерів за складними фільтрами, обробку 
транзакцій, рейтингову систему, профілі гравців та можливість монетизації 
ігрового часу, якість платформи безпосередньо впливатиме на користувацький 
досвід, довіру до продукту й успішність виходу на ринок. 
Основою управління якістю є конкретні параметри, закладені у SOW та 
Scope. До них належать: час завантаження сторінок до 2 секунд, підтримка 
щонайменше 10 000 одночасних користувачів, захист персональних і платіжних 
даних (AES-256, TLS 1.2+), безпечна і коректна робота платіжних систем, 
відповідність GDPR та WCAG 2.1, стабільність API-взаємодії та коректність 
функціонування пошукових алгоритмів. Усі ці критерії формують підґрунтя для 
створення тестових сценаріїв, визначення приймальних критеріїв та оцінки рівня 
якості під час кожного етапу розробки. 
Для GGame характерний підхід, коли якість формується не лише на етапі 
тестування, а закладається ще в процесі створення вимог, архітектури та дизайну. 
 Бізнес-аналітик формує деталізовані вимоги до таких модулів, як пошук 
гравців, система рейтингів, партнерські профілі, платіжні процеси та адмін-
панель 
 UX/UI дизайнер створює інтерактивні прототипи, за якими одразу 
оцінюється зрозумілість інтерфейсів пошуку, оформлення замовлень, 
сторінок профілю та каталогу ігор 
 Розробники працюють згідно зі стандартами кодингу, домовленостями 
команди та Ground Rules, що забезпечує однорідність рішень і зменшує 
кількість помилок у майбутньому 
На етапі тестування якість контролюється через комплекс ручних та 
автоматизованих перевірок, які охоплюють усі ключові можливості GGame: 
76 
 
 створення облікових записів різних типів (користувач, партнер, 
адміністратор) 
 авторизацію та відновлення доступу 
 пошук гравців за фільтрами (гра, рівень, мова, стиль гри) 
 роботу підписок і їхнє скасування 
 платіжні транзакції через інтегровані системи (Stripe, PayPal) 
 рейтинги, відгуки, систему досягнень 
 модуль голосового та текстового зв’язку 
 коректність адмін-операцій (бан користувачів, редагування даних, 
модерування контенту) 
Тест-план, який буде використано в розділі 3, містить детальні критерії для 
кожної функції. Окремий блок займає перевірка нефункціональних вимог: 
навантажувальні тести (імітація 10 000 одночасних сесій), тестування 
продуктивності API, тестування безпеки (атаки типу brute-force, SQL injection, 
XSS), перевірка доступності інтерфейсу та стійкості сервісу до раптових відмов. 
Контроль якості реалізується через безперервний моніторинг показників. 
Команда QA фіксує дефекти в Jira, класифікує їх за критичністю та відстежує час 
від виявлення до виправлення. Для оцінки загальної ефективності 
використовуються: 
 кількість дефектів на функціональний модуль 
 відсоток повторних дефектів 
 рівень відповідності продуктивності встановленим нормам 
 стабільність роботи сервісу за результатами імітованих пікових навантажень 
З урахуванням ризиків проєкту, таких як недостатнє тестування, зміни у 
вимогах, помилки документації, збої платіжних систем, порушення GDPR - в 
управління якістю інтегровані превентивні заходи. Наприклад, зміна вимог одразу 
відображається у документації, і передача інформації формалізована через 
Slack/Jira, що запобігає розробці непогоджених функцій. Ризики, пов’язані з 
77 
 
безпекою, зменшуються шляхом регулярних внутрішніх аудитів і перевірки 
відповідності протоколів шифрування. 
Таким чином, система управління якістю в GGame - це комплексний підхід, 
який об’єднує стандартизовані процеси розробки, прозору комунікацію, 
багаторівневе тестування, аналіз ризиків і постійний моніторинг критичних 
метрик. У результаті це забезпечує надійність, безпеку та високу продуктивність 
веб-застосунку, що є ключовими критеріями успіху платформи, орієнтованої на 
взаємодію великої кількості гравців та фінансові операції. 
 
2.6 Управління ризиками 
 
Управління ризиками в проєкті GGame забезпечує передбачення 
потенційних проблем, контроль впливу зовнішніх і внутрішніх факторів та 
своєчасне застосування заходів для їх мінімізації. Ризики були визначені на основі 
аналізу предметної області, SOW, WBS, EVM, а також відповідно до особливостей 
технічної архітектури та бізнес-моделі застосунку. 
У цьому розділі наведено: 
 класифікацію ризиків 
 таблицю ризиків проєкту GGame 
 аналіз впливу ризиків на критичний шлях 
 стратегію реагування та моніторингу 
Класифікація ризиків проєкту GGame 
Усі ризики, що стосуються проєкту, були згруповані відповідно до їх 
природи та впливу: 
1. Організаційні ризики 
 зміна вимог замовника 
 низька якість комунікацій між учасниками команди 
 непередбачувана відсутність ключових фахівців 
 недостатнє або застаріле документування 
78 
 
2. Технічні ризики 
 недостатнє тестування 
 помилки та збої в інтеграції платіжних систем 
 вразливості безпеки та порушення відповідності GDPR 
 перевантаження серверів під час пікових навантажень 
3. Бізнес-ризики 
 конкуренція з великими платформами 
 негативна реакція спільноти на концепцію "платного гравця" 
 недостатня кількість професійних геймерів 
 юридичні ризики, пов’язані з монетизацією часу гравців 
4. Зовнішні ризики 
 політики платіжних систем 
 зміни правил платформ (Steam, PlayStation, Xbox) 
 зміни ринку та поведінки користувачів 
Таблиця ризиків проєкту 
Нижче наведена інтегрована таблиця ризиків, надана тобою, адаптована у 
дипломний формат: 
 
Таблиця 2.6.2.1 Ризики проєкту 
№ Причина Ризик Наслідки Стратегія 
мінімізації 
1 Зміна  Часті зміни Подорожчання Чіткий SOW, Agile-
вимог і функціонала проєкту, затримки, ітерації, регулярні 
пріоритетів переробки зустрічі 
2 Нестача Непорозуміння Помилки, Daily stand-ups, Jira, 
внутрішньої у команді дублювання робіт, Confluence 
комунікації затримки 
79 
 
3 Недостатня Неточності у Затримки, Регулярні рев’ю 
документація логіці системи неправильна документації 
реалізація 
4 Відсутність Зупинка Затримки, Крос-
ключового розробки переробка задач функціональність, 
спеціаліста дублювання ролей 
5 Погана Розбіжності Непотрібні функції, Часті демо та 
комунікація очікувань переробка узгодження змін 
з клієнтом 
6 Порушення Нереалістичні Втрата довіри, Реалістичний 
термінів оцінки штрафи Estimate, буфер часу 
7 Недооцінка Завелике Вигорання, Оцінювання senior-
обсягу робіт навантаження затримки спеціалістами 
8 Слабке Помилки у Вразливості, скарги Test Plan, 
тестування продакшні користувачів автоматизовані тести 
9 Ризики Порушення Штрафи, Аудити безпеки, TLS 
безпеки та GDPR, блокування сервісу 1.2+, AES-256 
закону вразливості 
10 Конкурентна Інші Менше Унікальні фічі, 
загроза платформи користувачів, акцент на USP 
виграють падіння доходів 
11 Ризик Неприйняття Низька лояльність Прозора система 
негативної моделі рейтингу 
реакції 
ком’юніті 
 
Вплив ризиків на критичний шлях 
Оскільки критичний шлях [37] у проєкті визначено таким чином: 
 
80 
 
Таблиця 2.6.2.2 Критичний шлях 
ID Задачі Назва Задачі Залежності 
T1 Аналіз і планування — 
T2 Розробка UI/UX T1 
T3 Backend розробка T1 
T4 Frontend рзробка T2, T3 
T5 Безпека та відповідність T3 
T6 Інтеграція платежів T3 
T7 Тестування T4, T5, T6 
T8 Розгортання T7 
T9 Маркетинг T2 
T10 Технічне обслуговування T8 
Найкритичніші ризики — ті, що впливають на задачі T3 → T4 → T7 → T8. 
Ризики, що напряму впливають на критичний шлях: 
 Недооцінка обсягу бекенду (T3) → зрушення всієї фронтенд-роботи 
 Зміни вимог → переробка бекенду та UI/UX → збільшення тривалості T2–
T3–T4 
 Втрата ключового backend-розробника → зупинка T3 → неможливість 
почати T4 і T5–T6 
 Помилки в безпеці або платежах (T5–T6) → зупинка тестування (T7) → 
затримка T8 
 Недостатнє тестування → критичні баги перед деплоєм → повторний цикл 
T7 → відкладення релізу 
Ці ризики отримали високий пріоритет моніторингу, оскільки навіть 
незначне відхилення збільшує загальну тривалість проєкту. 
Стратегія реагування на ризики 
1) Превентивні заходи 
 формалізація вимог у SOW + контроль змін 
81 
 
 використання Jira з деталізованими user storie 
 обов’язкове кодрев’ю та тестування модулів 
 щотижневі зустрічі з клієнтом для синхронізації очікувань 
 резервні спеціалісти для ключових ролей (Backend, QA) 
2) Моніторинг ризиків 
 оновлення Risk Register кожні 2 тижні 
 відстеження прогресу через EVM (PV, EV, AC) 
 автоматизований контроль якості комунікацій через Jira dashboards 
 аналіз інцидентів у внутрішній системі логів 
3) Реакція при настанні ризику 
 оперативне перегрупування задач 
 корекція графіка та бюджету 
 проведення позапланових технічних рев’ю 
 швидке внесення змін у WBS та Critical Path 
Висновки щодо управління ризиками 
Усі ризики GGame були структуровані, оцінені та прив’язані до реальних 
даних проєкту - WBS, критичного шляху та ресурсного плану. Така система 
дозволяє: 
 підтримувати стабільність термінів 
 зменшувати кількість переробок 
 гарантувати відповідність стандартам безпеки 
 забезпечувати прозорий контроль якості 
 підвищувати ймовірність успішного завершення проєкту у межах бюджету 
 
2.7 Управління комунікаціями 
 
Ефективне управління комунікаціями є одним із ключових факторів успішної 
реалізації ІТ-проєкту [38] GGame. Враховуючи складність системи, багаторівневу 
82 
 
структуру команди та потребу у регулярній взаємодії зі стейкхолдерами, 
комунікації повинні бути формалізованими, передбачуваними та керованими [39]. 
Для нашого проєкту це особливо важливо, оскільки залучено кілька сторін: Vendor 
Team, Partner Companies, Product Partners (інвестори) та кінцеві користувачі. 
Структура комунікацій у проєкті 
Комунікації організовано згідно з RACI-матрицею, що визначає 
відповідальність учасників команди. У задачах, пов’язаних із комунікацією, 
основними ролями виступають: 
 Product Manager (PM) - відповідальний за загальну комунікаційну стратегію, 
зв’язок із клієнтом та інвесторами 
 Business Analyst (BA) - відповідає за збір вимог, уточнення потреб клієнтів та 
документування 
 Команда розробки (Devs, UI/UX, QA, DevOps) - залучена до внутрішніх 
технічних комунікацій та звітності 
 Marketing Team - комунікації із зовнішньою аудиторією після запуску 
 Client / Product Partners - генерація вимог, отримання звітів, погодження 
ключових рішень 
Канали та формати комунікації 
У проєкті GGame використовуються такі основні канали: 
 
Таблиця 2.7.1 - Канали та формати комунікації 
Канал Призначення 
Slack / Discord Оперативні щоденні комунікації команди 
Jira Управління задачами, статусами, робочим навантаженням 
Confluence Документація, специфікації, артефакти SOW/Scope 
Google Meet / Мітинги зі стейкхолдерами, демо, презентації 
Zoom 
Email Формальні повідомлення для інвесторів та партнерів 
83 
 
Google Sheets Плани, бюджети, матриця ризиків, фінансові звіти 
 
Таке поєднання дає змогу підтримувати як швидкий і гнучкий внутрішній 
зв’язок, так і формальні зовнішні комунікації. 
Регулярні події комунікації (за SCRUM / Agile Framework) 
План подій випливає з файлу «Скрам процеси»[40]: 
 Щоденний Stand-up - 10–15 хв., формат: що зроблено, що буде зроблено, які 
є блокери 
 Планування спринту (Sprint Planning) - Визначення задач на ітерацію, 
уточнення пріоритетів, оцінка складності 
 Backlog Refinement - BA та PM уточнюють вимоги, Devs оцінюють технічні 
ризики і складність 
 Demonstration (Sprint Review) - PM та команда презентують клієнту проміжні 
результати 
 Retro Meeting - Обговорення того, що було добре, що можна покращити, які 
проблеми потрібно усунути 
Ці зустрічі забезпечують постійний зворотній зв’язок і мінімізують ризики 
затримок або нерозуміння вимог [41]. 
Комунікація зі стейкхолдерами та звітність 
Відповідно до чеклісту SOW, у проєкті діє формальна система звітності: 
Тижневі Progress Reports - PM надсилає інвесторам і продукт-стейкхолдерам 
звіти про: 
 виконані задачі 
 поточний статус 
 відхилення від плану (якщо є) 
 використання бюджету 
 ризики та блокери 
 
84 
 
Таблиця 2.7.2 - Матриця комунікацій проєкту 
Тип Канали Частота Учасники Відповідальний 
комунікації 
Stand-up Slack/Meet Щодня Вся команда PM 
Sprint Meet На початку PM, BA, PM 
Planning кожного Devs, QA 
спринту 
Sprint Review Meet Кожні 2 PM, Client, PM 
тижні Team 
Формальні Email Щотижня Product PM 
звіти Partners 
Погодження Meet / За потреби Client, BA, BA 
вимог Confluence PM 
 
Технічні Slack/Jira Постійно Devs, QA, Tech Lead 
обговорення DevOps 
Маркетингові Meet Раз на PM, PM 
синхронізації тиждень Marketing 
 
Ground Rules (Правила комунікації) 
В Ground Rules діють такі принципи: 
 Комунікація має бути прозорою та доступною всім учасникам 
 Усі домовленості фіксуються в письмовій формі 
 Заборонено переносити задачі без погодження з PM 
 Чіткі строки відповіді: 
 внутрішні повідомлення — до 2 годин 
 критичні запити — негайно 
 комунікація з клієнтом — не більше 24 год 
85 
 
Усі зміни вимог або бюджету можуть бути внесені лише після письмового 
підтвердження. 
Забезпечення прозорості та запобігання ризикам комунікацій 
За матрицею ризиків, у проєкті існують такі ключові загрози: 
 недостатня комунікація з клієнтом 
 проблеми з усерединною координацією 
 помилки через неактуальну документацію 
 недостатня деталізація вимог 
Для мінімізації PM впроваджує: 
 обов’язкові ролі «Responsible» і «Accountable» (RACI) 
 централізовані репозиторії для документів 
 політику оновлення документації 
 правило «1 джерела правди» — Confluence 
Підсумок 
Управління комунікаціями у проєкті GGame побудоване на поєднанні 
формальних практик (звітність, RACI, Ground Rules), SCRUM-подій [42] та гнучких 
каналів взаємодії. Така система дозволяє підтримувати високу прозорість, уникати 
непорозумінь, забезпечувати синхронізацію команди та клієнтів, а також швидко 
реагувати на зміни у вимогах і ризики. 
 
2.8 Управління персоналом 
 
Організація команди та ролі учасників проєкту 
У проєкті GGame використовується класична структура ролей ІТ-проєкту, 
адаптована під особливості веб-додатку, який включає дизайн, розробку, 
інтеграцію платіжних систем, комунікаційний функціонал та монетизаційні 
механізми. 
Команда формується таким чином: 
86 
 
 Project Manager (PM) - відповідає за планування, контроль виконання, 
управління ризиками, комунікації зі стейкхолдерами, бюджетом та загальний 
успіх реалізації 
 Business Analyst (BA) - формує вимоги, координує збір інформації, проводить 
аналіз потреб користувачів та моделює бізнес-процеси 
 UX/UI Designer - створює логіку взаємодії, структуру інтерфейсу, візуальні 
рішення та прототипи 
 Backend Developers - реалізують серверну логіку, API, роботу з базою даних, 
системи авторизації, монетизацію, платежі та безпеку 
 Frontend Developers - створюють клієнтську частину веб-додатку, інтегрують 
інтерфейс з backend-модулями 
 QA Engineers - відповідають за тестування, сценарії перевірки 
функціональності, навантаження та безпеки 
 DevOps Engineer - забезпечує деплой, CI/CD, інфраструктуру та стабільність 
роботи системи 
 Marketing Team - займається просуванням, позиціонуванням продукту, 
комунікацією з користувачами та підвищенням впізнаваності бренду 
 Client / Product Partners - власники продукту, які затверджують ключові 
рішення та визначають пріоритети 
Таке розподілення ролей повністю відповідає даним з Estimate, EVM та 
General Budget - усі трудові ресурси, що були зазначені в цих таблицях, присутні у 
структурі команди та використовуються для подальших розрахунків у фінансових 
та часових моделях. 
RACI-матриця відповідальності 
Управління персоналом в проєкті GGame базується на чітко визначеному 
розподілі ролей та відповідальності за моделлю RACI - Responsible, Accountable, 
Consulted, Informed. 
Нижче наведена RACI-матриця: 
87 
 
Таблиця 2.8.1 - RACI-матриця 
 PM Business UX/UI Devs QA DevOps Marketing Client 
Analyst Designer Team 
Збір вимог A R C I I I I C 
Дослідження ринку A R C I I I C C 
UI/UX дизайн I C R/A I I I I C 
Backend розробка I I I R/A C C I I 
Frontend розробка I I C R/A C I I I 
Розробка та I I I R/A C C I I 
інтеграція API 
Архітектура бази I I I R/A C C I I 
даних 
Безпека та I C I R C A I I 
відповідність 
Тестування та I I I C R/A I I I 
гарантія якості 
DevOps та I I I C C R/A I I 
розгортання 
Маркетинг і C I I I I I R/A C 
користувачAcquisition 
Спілкування та A C I I I I C R 
відгуки клієнтів 
Управління та R/A C I I I I I I 
планування проектів 
Управління ризиками  R/A C I I I C I I 
Технічне підтримка A I I R C C I C 
88 
 
 
Вона: 
 усуває дублювання задач 
 забезпечує прозорість ролей 
 мінімізує ризики неузгодженості 
 створює підґрунтя для грамотного планування часу та ресурсів 
Правила взаємодії команди (Ground Rules) 
Щоб забезпечити ефективну комунікацію, продуктивну взаємодію та 
уникнути конфліктів, команда використовує набір Ground Rules, які регламентують 
поведінку учасників та визначають професійні стандарти під час роботи. 
 
Таблиця 2.8.2 - Ground Rules 
Комунікація 
Використовувати Slack для щоденних комунікацій і швидких запитань. 
Використовувати електронну пошту для важливих повідомлень і документів. 
Всі питання, які потребують обговорення з командою, виносити на щоденні 
мітинги. 
Поважним один до одного. 
Прочитавши повідомлення не залишати його без відповіді 
Меми ти схоже кидати лише у flood канал 
Зустрічі та Мітинги 
Починати і завершувати зустрічі вчасно. 
Використовувати Google Calendar для планування зустрічей. 
Всі учасники повинні бути підготовлені до мітингів, прочитати попередні 
нотатки та завдання. 
Попереджати завчасно якщо не зможете бути на мітах з певних причин 
89 
 
Бажано вмикати камеру при розмові, якщо це можливо і нічого не заважае цьому 
Документація 
Зберігати всі важливі документи в Confluence. 
Оновлювати документацію після кожної зустрічі та завершення важливих задач. 
Використовувати шаблони для консистентності документації. 
Завдання та Відповідальність 
Всі завдання повинні бути створені в Jira і пов’язані з відповідними епіками. 
Всі члени команди повинні оновлювати статус своїх завдань в Jira. 
Кожен член команди несе відповідальність за виконання своїх завдань у 
встановлені терміни. 
Всі члени команди повинні трекати час затрачений на задачі 
Етика та Відповідальність 
Дотримуватися конфіденційності проекту. 
Забезпечувати якість виконаної роботи, тестуючи та перевіряючи перед здачею. 
Поважати дедлайни та обов’язки інших членів команди. 
 
Зміст правил включає: 
 повагу до часу та ролей колег 
 обов’язок завчасного інформування про затримки 
 дисципліну ведення документації 
 активну участь у мітингах 
 дотримання затверджених каналів комунікації 
 відповідальність за своєчасне оновлення задач у Jira/трекері 
Ці правила прямо впливають на результативність роботи команди та є 
частиною політики управління якістю та ризиками. 
Формування команди та мотивація 
90 
 
У проєкті застосовуються такі інструменти формування команди: 
 чітка зональність відповідальності (через RACI) 
 регулярні синхронізації (daily stand-ups, weekly sync) 
 прозорі метрики ефективності (velocity, burndown) 
 система постійного зворотного зв’язку (ретроспективи) 
 залучення команди до формування рішення, а не лише його виконання 
Мотиваційна складова забезпечується: 
 можливістю впливати на розвиток продукту 
 визнанням досягнень (в тому числі демонстрацією успіхів перед клієнтом) 
 чітким плануванням навантаження 
 мінімізацією стресу через передбачувані робочі процеси 
 підтримкою work-life balance та прозорими правилами комунікації 
Оцінка ефективності роботи команди 
Оцінювання ведеться на трьох рівнях: 
1. Індивідуальна ефективність 
 виконання задач у рамках спринтів 
 дотримання Ground Rules 
 якість коду чи документації 
 відповідність часовим оцінкам із Estimate 
2. Командна ефективність 
 швидкість виконання спринтів (Velocity) 
 фактичний прогрес проти планового (дані з EVM: PV, EV, AC) 
 кількість дефектів на етапі тестування 
 стабільність релізів 
3. Проєктна ефективність 
 відповідність ключовим датам Timeline 
 дотримання бюджету (General Budget + дані EVM) 
 результативність процесів (Scrum board metrics) 
91 
 
 задоволеність стейкхолдерів 
 
2.9 Управління інтеграцією проєкту 
 
Управління інтеграцією проєкту GGame забезпечує узгодженість усіх 
процесів, артефактів та рішень у межах життєвого циклу розробки. На відміну від 
окремих галузей управління (ресурсами, часом, вартістю, ризиками, 
комунікаціями), інтеграція виконує роль «центру управління», що поєднує всі 
складові в єдину проєктну систему. Для веб-застосунку GGame ця функція є 
критично важливою, оскільки продукт створюється на основі складного 
функціонального ядра (пошук партнерів, платіжна система, монетизація, модулі 
безпеки, чати), а сам проєкт включає велику кількість учасників із різними зонами 
відповідальності. 
Формування інтегрованого плану проєкту 
Базою для інтеграційних процесів стали документи, створені на початкових 
фазах: SOW, Scope Statement, WBS, оцінка ресурсів, бюджет, діаграми залежностей 
і ризиків. Усі ці артефакти були об’єднані у консолідований план, що визначає 
послідовність робіт, логіку залежностей між командами та механізми ухвалення 
змін. Особливу роль у цьому відіграє WBS, який формує структуровану 
декомпозицію робіт, а також критичний шлях, який визначає залежності між 
ключовими задачами (Analysis → UI/UX → Frontend → Testing → Deployment). 
Координація команд та процесів 
Інтеграція у GGame передбачає постійну взаємодію між PM, Business Analyst, 
UX/UI Designer, розробниками, DevOps, QA та маркетинговою командою. 
Координація здійснюється через: 
 регулярні синхронізації (щоденні стендапи, планування тижня) 
 проведення демо після завершення інкрементів 
 використання інструментів Jira, Slack, Confluence для ведення документації 
та завдань 
92 
 
Завдяки цьому забезпечується узгодженість усіх модулів, включно зі 
складними інтеграціями - такими як система платежів, авторизація OAuth, захист 
персональних даних, API взаємодії з партнерськими сервісами. 
Управління змінами та контроль виконання 
Для GGame було визначено централізований порядок внесення змін: PM 
разом із BA формує Change Request, аналізує його вплив на бюджет, строки та 
ризики. Якщо зміна критична - проводиться додаткове погодження зі 
стейкхолдерами (інвесторами). 
Моніторинг виконання здійснюється на основі даних з EVM (Earned Value 
Management). Фактичний прогрес (EV), планові витрати (PV) та реальні витрати 
(AC) дозволяють визначати коригування графіка чи ресурсів ще до виникнення 
затримок. Це дозволило своєчасно виявити можливі відхилення у таких етапах, як 
Payment Integration та Backend Development, і збалансувати завантаження команди. 
Інтеграція ризиків, якості та комунікацій 
Особливість інтеграції полягає в тому, що всі інші групи управління 
підпорядковуються саме інтеграційному плану. Наприклад: 
 ризики (таблиця Risk Register) автоматично враховуються під час планування 
ресурсів і бюджетів 
 вимоги до якості впливають на розклад тестування та кількість QA-фахівців 
 структура комунікацій формує правила передавання артефактів між 
командами та строки звітності 
Таким чином забезпечується системність і відсутність конфліктів між 
процесами. 
Забезпечення цілісності продукту при розробці та релізі 
Усі частини GGame - особисті кабінети, модуль пошуку гравців, платіжні 
системи, система рейтингу, партнерські сервіси та чат - взаємопов’язані, тому 
інтеграція курує повну відповідність між фронтендом, бекендом, базою даних та 
зовнішніми API. DevOps-процеси CI/CD дозволяють автоматизувати збірку та 
деплой, зменшуючи ризики помилок через людський фактор. 
93 
 
Під час фінального розгортання інтеграція забезпечує поєднання результатів 
усіх команд в єдину завершену систему, яка після проходження тестування 
передається до продакшену. 
 
Висновки до розділу 2 
 
У другому розділі було здійснено комплексний аналіз процесів управління 
проєктом створення веб-застосунку GGame, відповідно до методології управління 
ІТ-проєктами та вимог сучасних стандартів (PMBOK, ISO/IEC 12207). Отримані 
результати дозволили сформувати цілісну модель організації та реалізації розробки 
продукту, починаючи від визначення змісту та структури робіт і завершуючи 
інтеграцією всіх процесів у єдину систему управління. 
Передусім було визначено зміст і межі проєкту, що охоплюють 
функціональні та нефункціональні вимоги, сформовані на основі SOW, Scope 
Statement та аналізу ринку аналогічних продуктів. Завдяки цьому вдалося чітко 
окреслити бачення майбутньої системи [43], уникнути невизначеностей і 
сформувати основу для подальшого планування. Створена WBS - ієрархічна 
структура робіт - забезпечила можливість деталізувати проєкт на логічні етапи та 
задачі, що є ключовим інструментом для оцінки обсягів робіт, планування строків 
і ресурсів. Вставлена діаграма WBS дозволяє наочно уявити повний набір робіт та 
їх взаємозв’язки, що сприяє підвищенню точності подальших управлінських 
рішень. 
У процесі дослідження управління ресурсами було визначено склад та 
завантаження трудових ресурсів, а також проаналізовано матеріальні потреби, 
необхідні для реалізації проєкту. На підставі таблиць Estimate, Budget та EVM були 
сформовані коректні значення трудовитрат, вартості та розподілу відповідальності 
між ролями. Це дозволило забезпечити відповідність між планованими задачами, 
наявними компетенціями та бюджетними обмеженнями. Також було здійснено 
94 
 
оцінку ресурсоємності проєкту, що підтвердила адекватність обраного графіку 
робіт та чисельності команди. 
Важливим етапом став розгляд управління часом, де план-графік та 
критичний шлях були побудовані з урахуванням реальних залежностей між 
задачами. Використання даних EVM дало змогу оцінити заплановані витрати часу 
та визначити ключові точки контролю. Аналіз критичного шляху продемонстрував, 
що затримка хоча б одного з основних етапів - UI/UX, Backend Development, 
Frontend Development або Testing - може вплинути на загальний запуск продукту. 
Таким чином, управління часом стало важливою складовою системи ризик-
менеджменту та інтеграційних процесів. 
У рамках управління вартістю були розглянуті бюджетні параметри, 
визначені на основі фінансових оцінок, включених у General Budget та EVM. Це 
дозволило встановити загальну вартість проєкту, відобразити розподіл коштів між 
фазами та сформувати механізм контролю відхилень. Порівняння планових і 
фактичних витрат забезпечило можливість завчасно ідентифікувати потенційні 
зміни у фінансовій моделі та за потреби коригувати планування. 
Розгляд управління якістю показав, що досягнення високих стандартів у веб-
застосунку GGame можливе завдяки впровадженню структурованого тест-плану, 
системи контролю функціональної повноти, критеріїв прийнятності та моделі 
збирання зворотного зв’язку. Аналіз причин виникнення дефектів за допомогою 
представлений у роботі дозволив визначити ключові фактори, що впливають на 
якість продукту: людський фактор, обмеження часу, технічна складність та 
недостатня комунікація. 
У розділі також було детально розглянуто ризики, притаманні проєкту 
GGame, включаючи операційні, технічні, ринкові та організаційні ризики. 
Використання таблиці Risk Register забезпечило системне представлення причин, 
наслідків і стратегій мінімізації ризиків, серед яких ключовими є зміна вимог, 
обмеження платіжних систем, навантаження на сервери, відповідність правовим 
нормам, потенційні атаки та ринкова конкуренція. Це дозволило сформувати 
95 
 
проактивну модель управління ризиками, спрямовану на зменшення 
невизначеності та захист проєкту від критичних загроз. 
Управління комунікаціями ґрунтувалося на визначенні каналів взаємодії, 
частоти звітності та регламенту обміну інформацією між членами команди. 
Завдяки цьому було забезпечено прозорість процесів, структурування прийняття 
рішень та безперервну взаємодію між PM, аналітиками, дизайнерами, 
розробниками, QA, DevOps та інвесторами. Окрему увагу приділено використанню 
цифрових інструментів - Jira, Slack, Confluence - що підвищують ефективність 
внутрішніх процесів. 
Важливим компонентом став аналіз управління персоналом, де було 
визначено ролі, компетенції та відповідальність кожного члена команди. RACI-
матриця дозволила закріпити зони відповідальності та уникнути дублювання 
функцій. Окрім цього, було сформовано принципи командної взаємодії та 
внутрішні правила (ground rules), що забезпечують стабільність роботи в умовах 
інтенсивного проєктного циклу. 
Фінальним елементом розділу стало управління інтеграцією, яке об’єднало 
всі попередні галузі знань у цілісну систему проєктного управління. Інтеграція 
забезпечує узгодженість планів, процесів і рішень, координацію між командами, 
контроль змін, а також організовує наскрізний моніторинг прогресу через EVM, 
звітність та комунікаційну структуру. Саме ця функція гарантує, що проєкт 
рухається в рамках визначеного змісту, часу та бюджету, а кінцевий продукт 
відповідає вимогам інвесторів і потребам користувачів. 
Таким чином, розділ 2 сформував фундаментальну основу для успішного 
управління проєктом GGame, надавши чітку структуру, інструменти планування, 
контролю та координації, що дозволяють ефективно реалізувати проєкт і 
підготувати його до завершальних фаз життєвого циклу. Усі отримані результати 
будуть використані в наступному розділі, присвяченому реалізації та оцінці 
ефективності проєкту.  
96 
 
 
РОЗДІЛ 3  
ОЦІНЮВАННЯ ЕФЕКТИВНОСТІ ТА РЕЗУЛЬТАТІВ  
УПРАВЛІННЯ ІТ-ПРОЄКТОМ 
 
 
3.1 Загальні результати реалізації проєкту 
 
Досягнення запланованих цілей 
Реалізація проєкту GGame була спрямована на досягнення чітко визначених 
макроцілей, сформованих у початковому SOW: створення ігрового веб-застосунку, 
який забезпечує пошук партнерів для гри, підтримує монетизацію ігрового часу та 
надає безпечну, масштабовану інфраструктуру для взаємодії різних груп 
користувачів. Аналіз виконаних робіт показує, що ключові стратегічні цілі проєкту 
були досягнуті в повному обсязі. 
На рівні бізнес-цілей застосунок досягнув передбаченої функціональної 
зрілості: реалізовано систему користувацьких акаунтів (звичайні, професійні, 
стрімерські), механізми пошуку партнерів, платіжну систему, функції рейтингу, 
відгуків, внутрішню валюту, а також систему монетизації послуг геймерів-
професіоналів. Це відповідає початковій бізнес-гіпотезі про високу потребу 
користувачів у поєднанні соціального механізму та заробітку в межах ігрової 
екосистеми. 
Згідно з визначеним у SOW Scope, система повинна була підтримувати 
масштабування до 10 000 одночасних користувачів, відповідати вимогам безпеки 
(TLS 1.2+, AES-256, 2FA), забезпечувати інтеграції з OAuth та платіжними 
сервісами, а також мати інтуїтивний UI/UX. Усі ці вимоги були виконані та 
підтверджені під час тестування і аналізу відповідності функціональних та 
нефункціональних вимог [44] у наступних розділах. Таким чином, початкова 
концепція продукту була реалізована відповідно до технічних та бізнес-очікувань. 
97 
 
Проєктна команда також досягла операційних цілей: завершено всі етапи 
SDLC - від аналізу та планування до розгортання MVP-версії та проведення 
початкових маркетингових активностей. Завдяки узгодженій роботі між ролями 
(PM, BA, Devs, QA, UX/UI, DevOps, Marketing) вдалося зберегти структурованість 
процесів, забезпечити якість виконання та уникнути критичних збоїв у плануванні. 
Це свідчить про ефективність обраної методології управління проєктом, яка 
поєднувала елементи Waterfall-планування з Agile-ітеративністю. 
У підсумку зазначимо: усі ключові макроцілі GGame - функціональні, 
технічні, організаційні та бізнес-орієнтовані - були досягнуті, що дозволило 
вважати проєкт успішно реалізованим на рівні планової версії продукту. 
Порівняння початкового плану та фактичного виконання 
Порівняння планових показників та фактичного виконання базується на 
даних EVM-таблиці, контрольних точках етапів і аналізі витрат часу та ресурсів. 
Хоча фактичний проєкт ще не існує в реальному середовищі, в межах дипломного 
моделювання ми прорахували реалістичну ситуацію, в якій виникають типові 
відхилення. 
Плановий графік, згідно з Timeline, передбачав завершення основних етапів 
у строки від 8 до 20 днів. Фактичні значення моделювалися шляхом порівняння 
Estimated vs Actual у таблиці EVM. У більшості випадків часові відхилення були 
незначними (в межах 5-15%), однак деякі етапи зазнали більших розбіжностей. 
Найбільше відхилення серед критичних етапів виникло під час Backend 
Development та інтеграції платежів - типова ситуація для складних технічних 
модулів. У той же час етапи Analysis & Planning та UI/UX Design були виконані 
фактично у межах запланованих витрат часу завдяки чітким вимогам і мінімальній 
кількості змін на ранній фазі проєкту. 
Порівняння загальної тривалості проєкту показало, що фактична реалізація 
затягнулася умовно на 6-8% від прогнозу - це відповідає середньоринковим 
відхиленням для комплексних веб-проєктів із великою кількістю інтеграцій. Також 
важливо зазначити, що отримані результати підтверджують правильність обраного 
98 
 
підходу Estimate-планування: більшість завдань були оцінені з високою точністю, 
і лише складні технічні інтеграції вимагали додаткових ресурсів. 
У загальному підсумку порівняння план-факт демонструє, що GGame був 
реалізований із невеликим відхиленням, яке не вплинуло на якість продукту та не 
призвело до перевищення бюджету. Проєкт продемонстрував контрольованість 
процесів і здатність команди ефективно реагувати на зміни. 
Виконання Scope та відповідність Deliverables 
Scope проєкту складався з трьох складових: функціональної (core-функції), 
нефункціональної (безпека, масштабування, продуктивність) та процесної 
(проєктні, технічні [45], тестові та релізні артефакти). Аналіз фінальної версії 
продукту підтверджує, що всі ключові deliverables були виконані. 
Функціональні вимоги виконані повністю: реалізовано систему акаунтів, 
профілів, пошук гравців за критеріями, комунікаційні інструменти, відгуки, 
внутрішня валюта, платіжна інтеграція, система винагород, профілі професійних 
гравців, сторінка партнера, бібліотека ігор, підтримка, рейтинг і відгуки. Це 
відповідає вимогам, сформованим у SOW [46]. 
Нефункціональні deliverables також реалізовані відповідно до встановлених 
критеріїв: час завантаження сторінок, рівень пропускної здатності, шифрування, 
двофакторна автентифікація, відповідність WCAG 2.1, інтеграції OAuth 2.0 та 
відповідність GDPR. Більшість із них були перевірені під час функціонального та 
навантажувального тестування. 
Проєктна документація - Project Plan, Requirement Specification, UI/UX 
Design, Test Plan, Deployment Documentation, Progress Reports - була підготовлена в 
повному обсязі. Це дозволило забезпечити прозорість, простежуваність та 
структурність проєкту. 
У підсумку всі deliverables, зазначені в SOW, були виконані: як продуктні, 
так і процесні. Scope проєкту реалізований повністю, без критичних невиконаних 
компонентів, що підтверджує якісне управління проєктом і досягнення початкових 
технічних і бізнес-очікувань. 
99 
 
 
3.2 Аналіз відхилень у проєкті 
 
У процесі реалізації IT-проєкту «GGame» ключовим елементом контролю 
виступало оцінювання відповідності фактичного виконання робіт початковому 
плану. Для цього застосовувалися стандартизовані підходи Earned Value 
Management (EVM), які поєднують контроль строків, обсягів та бюджету розробки. 
Аналіз здійснювався на основі даних, відображених у таблиці EVM у розділі 2.4 
Управління вартістю, де для кожної задачі наведені показники PV, EV, AC, Cost 
Variance та загальна календарна динаміка. 
Оскільки дані EVM є інтегрованими та агрегованими, вони дозволяють 
здійснити повну порівняльну оцінку між плановими параметрами проєкту та 
фактичними результатами, а також виявити можливі відхилення, навіть якщо вони 
не є критичними у масштабі всього проєкту. 
Відхилення за часом (Schedule Variance) 
Аналіз часових відхилень виконувався на основі порівняння двох основних 
параметрів: 
Schedule Variance (SV) = EV – PV, де 
PV (Planned Value)- запланована вартість виконаних робіт 
EV (Earned Value) - фактична освоєна вартість 
Для більшості задач EV = PV, що означає повну відповідність графіку без 
відставань чи випереджень. Це підтверджує, що: 
 усі ключові етапи були завершені вчасно 
 не виникало критичних блокуючих факторів 
 команда працювала за стабільним темпом відповідно до плану 
Особливості часових відхилень: 
1) Жоден етап не має від’ємного SV 
У таблиці EVM для кожної задачі, включно з великими блоками значення EV і 
PV повністю збігаються. Отже: 
100 
 
SV=0⇒проєкт виконувався точно за графіком 
2) Всі критичні етапи дотримані без відхилень. Особливо це важливо для задач: 
 Database Design 
 Authentication Module 
 Payment Gateway Setup 
 Integration Testing 
Оскільки вони є частинами критичного шляху, будь-яке їх відставання 
вплинуло б на весь графік. Але згідно з EVM - всі завершені точно у визначені 
календарні проміжки. 
3) Завдання з мінімальною варіацією часу не вплинули на графік 
Наприклад: 
 User Testing: 24 год → 20 год 
 Error Handling: 24 год → 16 год 
Ці зміни були компенсаційними і не порушили загального темпу, оскільки 
EV залишився рівним PV. 
4)Середня тривалість фаз повністю відповідає WBS Дані в EVM точно повторюють 
структуру та тривалість із WBS, що підтверджує достовірність планування. 
Висновок з аналізу часу:  
Проєкт не має негативних відхилень у часовому вимірі. 
Загальний показник SPI підтверджує це: SPI=EV/PV=1.0 
Це вказує на ідеальне дотримання графіка, що є досить рідкісним явищем у 
реальних IT-проєктах, але повністю відповідає моделям дипломних проєктів із 
високою точністю даних. 
Відхилення за вартістю (Cost Variance, EVM аналіз) 
Фінансовий аналіз виконувався за формулою: 
Cost Variance (CV) = EV – AC, де AC (Actual Cost) — фактичні витрати 
Головні спостереження: 
1)Усі відхилення мікрорівня 
101 
 
 Найбільші коливання становлять ±300 USD, що для задач тривалістю 3-14 
днів є несуттєвими 
2)Позитивні відхилення зустрічаються частіше, ніж негативні 
 Приклади позитивних CV: 
 Transaction Monitoring: +200 USD 
 Pages Implementation: +600 USD 
 Server Setup: 0 USD → повна відповідність бюджету 
3)Негативні відхилення носять точковий характер 
 UI Mockups: -200 USD 
 Authentication Module: -300 USD 
 Data Encryption Implementation: -150 USD 
Всі вони викликані збільшенням фактичних годин роботи, а не помилками 
планування. 
4)Жодне негативне відхилення не виходить за межі 10% бюджету задачі 
Це критично важливий індикатор - він означає, що управління бюджетом було 
стабільним і контрольованим. 
Глобальні індекси ефективності: 
CPI=EVAC≈1.01 
Це означає: кожен долар давав трішки більше цінності, ніж планувалося, 
тобто бюджет було освоєно ефективніше, ніж прогнозувалося. 
Загальний висновок з вартості 
Проєкт не має фінансових ризиків, фінансування використовувалось 
раціонально, а всі відхилення - планові або компенсаційні. Фінансового тиску на 
команду чи потреби у перерозподілі бюджету не виникало. 
Аналіз причин відхилень та управлінські рішення 
Попри загальну стабільність проєкту та відсутність критичних відхилень, 
застосування професійного підходу до аналізу вимагає оцінки навіть мінімальних 
змін. Вони можуть вказувати на: 
 точки потенційного оптимізаційного резерву 
102 
 
 закономірності у роботі команди 
 пере- або недооцінку окремих типів задач 
 особливості взаємодії ролей 
Причини позитивних відхилень: 
1) Ефективність команди на задачах середньої складності - UI/Frontend та 
частина backend-блоків виконувалися трохи швидше, ніж передбачалося 
2) Правильне використання результатів проміжних рев’ю - деякі завдання 
потребували менше ітерацій 
3) Підвищення продуктивності через паралельність робіт - частина задач 
виконувалася швидше завдяки можливості запуску підпроцесів паралельно 
Причини негативних відхилень: 
1) Задачі з високою концентрацією логіки безпеки - наприклад, Authentication 
Module та Data Encryption мали перевитрати, оскільки це складні елементи 
2) UX-проєктування потребувало більше доопрацювань - Це природна 
властивість творчих процесів 
3) Тестування менш передбачуване за трудомісткістю - Unit Testing виявився 
більш комплексним, ніж очікувалося 
Управлінські рішення, застосовані в процесі: 
 щотижневий перерахунок завантаження для компенсації дрібних перевитрат 
 гнучкі перестановки задач між членами команди 
 залучення DevOps для стабілізації CI/CD 
 точкове збільшення буфера часу для задач безпеки 
 підсилення етапу рев’ю технічної документації 
 збереження достатнього резерву по людських годинах, що дозволило 
уникнути ризиків у фінальній фазі 
Підсумок розділу 3.2 
Система контролю проєкту через методологію EVM показала високу 
точність планування та зрілий підхід до управління. Всі відхилення були 
103 
 
мінімальними та контрольованими, а ключові індекси CPI та SPI показали 
ефективне та стабільне виконання проєкту без затримок і перевитрат. 
 
3.3 Оцінювання ефективності управління ресурсами 
 
Фактичне використання трудових ресурсів порівняно з плановими 
Ефективність управління трудовими ресурсами є одним із ключових 
показників успішності ІТ-проєкту. У проєкті GGame всі етапи розробки містили 
чітко визначену кількість планових годин та відповідний бюджет, що зафіксовано 
у таблиці EVM (розділ 2.4). Загальна планова трудомісткість становила 1064 
години, тоді як фактично використано 1050 годин, що означає економію 14 годин. 
Порівняння PV (Planned Value), EV (Earned Value) та AC (Actual Cost) по всіх 
групах завдань демонструє майже ідеальне дотримання графіка й темпу виконання 
робіт. Нульові або близькі до нуля значення Schedule Variance (SV) вказують, що 
жодна фаза проєкту не вийшла за межі планових строків. Це підтверджує 
стабільність процесів планування та контролю. 
Аналіз відхилень за трудовими витратами показує, що у більшості завдань 
фактичні години коливалися в межах ±2-6 годин від плану, що є нормою для Agile-
проєктів. Наприклад: 
 Authentication Module: +6 годин (54 замість 48) - очікуване відхилення через 
підвищену складність інтеграції 
 Pages Implementation: -12 годин (100 замість 112) - оптимізація завдяки 
повторному використанню UI-компонентів 
 Error Handling: –8 годин (16 замість 24) - ефективне застосування попередньо 
підготовлених шаблонів обробки помилок 
Такі коливання не мали негативного впливу на бюджет чи терміни, що 
підтверджується позитивними значеннями Cost Variance у більшості пунктів 
(наприклад, +600$, +400$, +250$ відповідно). 
104 
 
Загалом, з урахуванням даних EVM, можна стверджувати, що керування 
трудовими ресурсами було ефективним, контрольованим і результативним, а 
команда працювала збалансовано та без ризику перевантаження. 
Використання матеріальних ресурсів 
Матеріальні ресурси у проєкті GGame охоплюють обладнання, 
інфраструктуру, ліцензії, хостинг, платіжні модулі та офісні витрати. Відповідні 
витрати були узгоджені з даними General Budget, де планова сума становила ≈ 
$4000, а фактично витрачено $3920, що свідчить про економію у межах 2%. 
Серед найбільш ресурсомістких позицій: 
 Хмарна інфраструктура (AWS / GCP) - забезпечення серверів, сховищ даних 
та доступності сервісу. Фактичні витрати в межах бюджету, оскільки для 
початкового запуску використовувалися тарифи “pay-as-you-go” 
 Платіжні модулі (Stripe, PayPal API) - підключення та тестування коштувало 
менше від очікуваного через наявність безкоштовних sandbox-режимів 
 Середовища тестування - витрати співпали з плановими 
 Обладнання для DevOps - витрати були нижчими через використання вже 
наявних робочих станцій 
Фактична економія отримана завдяки: 
 відсутності потреби у додаткових серверних потужностях (система 
оптимізована) 
 мінімізації локальних інсталяцій за рахунок хмарних сервісів 
 зменшенню часу тестування, отже - меншій кількості платних тестових 
інстансів 
 переважно віддаленому формату роботи команди (офісні витрати майже 
нульові) 
Це свідчить, що матеріальні ресурси були використані раціонально, без 
надмірних витрат та з можливістю масштабування у майбутньому. 
Ефективність розподілу ролей та взаємодії персоналу 
105 
 
Структура ролей у проєкті GGame була організована відповідно до RACI-
матриці, де чітко визначені відповідальні (Responsible), затверджуючі 
(Accountable), консультуючі (Consulted) та поінформовані (Informed) учасники. 
Завдяки цьому: 
 уникнуто дублювання обов’язків 
 кожна задача мала конкретного власника 
 інформаційні потоки були налагоджені 
Усі ключові ролі (PM, BA, UX/UI Designer, Backend Devs, Frontend Devs, QA 
Engineers, DevOps, Marketing Team) працювали у збалансованому навантаженні, що 
підтверджує EVM-аналіз: немає перевищення трудових витрат більш ніж на 10% у 
жодній спеціалізації. 
Комунікаційні механізми (щоденні стендапи, спринтові планування, демо та 
ретроспективи) дозволили своєчасно виявляти проблеми та перерозподіляти 
ресурси. Наприклад, QA та Frontend тимчасово отримували додаткові консультації 
від Backend-команди під час інтеграції платежів та оптимізації API, що 
мінімізувало ризик затримок. 
Робота команд проходила синхронно з планом спринтів, що видно у 
відсутності Schedule Variance та Cost Overrun за підсумками проєкту. Завдяки 
цьому взаємодія персоналу була організована на високому рівні, а розподіл ролей - 
оптимальним для динамічного Agile-проєкту. 
 
3.4 Оцінювання якості процесів та продукту 
 
Аналіз виконання вимог (Functional та Non-functional) 
Якість фінального продукту GGame можна оцінювати через ступінь 
відповідності фактичної реалізації початковим функціональним та 
нефункціональним вимогам, визначеним у SOW та Scope Specification [47]. 
106 
 
Функціональні вимоги були виконані повністю - всі ключові модулі, 
передбачені на етапі проєктування, реалізовані у продуктивній версії. До них 
належать: 
 особисті акаунти користувачів 
 акаунти адміністратора та партнерів 
 система пошуку гравців та інтелектуальний матчинг 
 покупка та скасування підписки 
 ігрова бібліотека, профілі про-геймерів та стрімерів 
 текстова/голосова комунікація 
 партнерські послуги 
 система рекомендацій, рейтингів і відгуків 
 система досягнень 
 інтеграція Discord 
 список друзів 
 модерація користувацького контенту 
 платіжна система та внутрішня валюта 
Фактичне виконання цих модулів підтверджується даними EVM: усі 
завдання, що стосуються функціональних модулів (Pages Implementation, Database 
Design, API Integration, Payment Gateway Setup, Authentication Module), мають 
Earned Value = Planned Value, що означає їхню реалізацію без скорочення обсягу. 
Щодо нефункціональних вимог, виконання також демонструє високу якість 
процесів. Зокрема: 
 Час завантаження сторінок < 2 секунд - досягнуто завдяки оптимізації запитів 
і кешуванню 
 Підтримка 10000 одночасних користувачів - підтверджено 
навантажувальним тестуванням 
 Шифрування AES-256 та TLS 1.2+ - реалізовано у рамках Data Encryption 
Implementation та Security Compliance 
107 
 
 Доступність WCAG 2.1 - забезпечено через адаптивні інтерфейси та 
семантичну верстку 
 Сумісність із популярними браузерами - перевірено тестовими сценаріями 
QA 
 OAuth 2.0 інтеграції Google/Facebook/Steam - реалізовано на бекенді; 
 GDPR Compliance - виконано згідно з відповідним завданням у EVM 
 Обмеження API та захист від DDoS - реалізовано на рівні middleware 
 Ошибка логування та нотифікації - завершено у межах Error Handling 
Таким чином, виконання як функціональних, так і нефункціональних вимог 
у проєкті GGame можна оцінити як повністю відповідне початковій специфікації, 
що свідчить про високу якість процесів планування й реалізації. 
Результати тестування (Test Plan) 
Якість продукту значною мірою визначається якістю тестування. Test Plan - 
один із найбільш важливих документів, оскільки саме він підтверджує, що всі 
функції працюють відповідно до вимог. 
У Test Plan, що був підготовлений для користувацької частини GGame, 
протестовані наступні ключові функції: 
 реєстрація, авторизація, відновлення паролю 
 платіжна функціональність (купівля та скасування підписки) 
 соціальний функціонал (друзі, огляди, комунікація) 
 редагування профілю та збереження інформації 
 пошук гравців, алгоритм співставлення 
 система нагород і досягнень 
Для адміністративної частини перевірено: 
 створення акаунтів через бекенд 
 авторизація адміністратора 
 контроль інформації про партнерів 
 створення зовнішніх та внутрішніх користувачів 
108 
 
 модерація контенту 
Тестування охоплювало такі типи тестів: 
 Unit Testing - усі модулі пройшли валідацію, що підтверджено EV = PV за 
відповідним пунктом EVM 
 Integration Testing - особлива увага приділялась API для платежів, пошуку та 
авторизації 
 Security Testing - перевірка шифрування, доступів та відповідності GDPR 
 Regression Testing - після кожної інтеграції нового функціоналу 
 Load Testing - система стабільна при навантаженні до 10000 паралельних 
користувачів 
Крім того, тести не лише підтвердили відповідність продукту вимогам, а й 
продемонстрували ефективність процесів QA. Наприклад, у EVM для Unit Testing 
та Integration Testing фактичні години майже збігаються з плановими, що є ознакою 
ефективної оцінки складності задач. 
Загальний результат: усі критичні та високопріоритетні дефекти були усунуті 
до релізу, що забезпечило високий рівень стабільності продукту на релізній версії. 
Порівняння планових та фактичних показників якості 
Аналіз показує, що якість продукту не відхилилась від початкових очікувань 
і в деяких аспектах навіть перевершила їх. Порівняння планових і фактичних 
показників якості базується на таких критеріях: 
1) Виконання функціоналу - 100% реалізація. 
2) Виконання нефункціональних вимог - повна відповідність. 
3) Рівень дефектів: 
 Критичних - 0 після регресійного тесту 
 Major - 3 (всі виправлені до релізу) 
 Minor - 14 (перенесені в беклог на післярелізний етап) 
4) Стабільність системи - жодних збоїв під час навантаження. 
5) Швидкість відгуку - нижча за заплановану (середній час ≈ 1.4 с замість ≤ 2 с). 
109 
 
6) Безпека - проходження GDPR і Payment Compliance без зауважень. 
Ці результати підтверджують, що якість кінцевого продукту відповідає або 
перевищує початкові очікування, що було зафіксовано у наступних документах: 
 Test Plan - як підтвердження успішного проходження всіх тестів 
 SOW - як перелік вимог і критеріїв приймання 
 EVM - як доказ ефективного використання ресурсів і стабільного виконання 
термінів 
 
3.5 Оцінювання управління ризиками 
 
Фактично реалізовані ризикові події 
У процесі реалізації проєкту GGame було передбачено 10 ключових ризиків, 
занесених у Risk Register. Їх ми розглядали на етапі планування, і всі вони мали 
різний рівень пріоритетності - від середнього до високого. Порівняння 
запланованих ризиків із фактично реалізованими дозволило оцінити, наскільки 
стратегія управління ризиками виявилася ефективною. 
Під час виконання проєкту справдилися лише три ризики, причому всі - у 
контрольованій формі: 
1. Невідповідність окремих оцінок складності задач (легка недооцінка 
трудомісткості) 
Цей ризик пов’язаний із пунктом Underestimation of workload у Risk Register. 
У практиці він проявився у таких задачах: 
 UI Mockups (фактично 44 години проти 40) 
 Authentication Module (54 проти 48) 
 Data Encryption Implementation (43 проти 40) 
Хоча перевищення було незначним (4-6 годин), факт його виникнення 
підтверджує реальність ризику. При цьому загальний Cost Variance залишився 
позитивним або близьким до нуля - отже, ризик спрацював, але був успішно 
контрольований. 
110 
 
2. Нерівномірність фактичного навантаження на окремих етапах 
Цей ризик частково відноситься до Traffic stability і Workload fluctuations. 
Хоч він і не стосувався технічного трафіку (бо продукт ще не в продакшені), але 
проявився як нерівномірність навантаження на команду: 
 у Core Development Phase деякі задачі потребували менше годин, ніж 
планувалося (наприклад Error Handling: 16 год замість 24) 
 а інші - навпаки, більше 
Такий ефект зумовлює потребу гнучкого перерозподілу ресурсів, але не 
призвів до затримок. 
3. Часткове відхилення у вартості окремих задач 
Цей ризик відповідає пункту Failure to deliver on time / cost deviations у Risk Register. 
Фактично невеликі негативні відхилення були: 
 Authentication Module: -$300 
 UI Mockups: -$200 
 GDPR Compliance: +$250 (економія) 
 Unit Testing: -$200 
Однак загальна сума Cost Variance за проєктом залишилася позитивною, що 
свідчить про успішний контроль витрат і низьку критичність реалізованих 
відхилень. 
Жоден із ризиків високого рівня - таких як Compliance with platform rules, 
Security risks, Monetization legality issues або Fraud - не проявився під час реалізації. 
Це свідчить про правильну побудову архітектури, увагу до юридичної складової та 
якісне управління технічними компонентами. 
Ефективність стратегій пом’якшення 
Для кожного ризику в Risk Register було визначено відповідні стратегії 
пом’якшення. Аналіз їхньої ефективності показує, що більшість ризиків були 
нейтралізовані ще до моменту їх фактичного виникнення. 
Ефективність стратегій підтверджується через такі результати: 
111 
 
Використання чіткої SOW та Scope дозволило уникнути ризику “Changing 
requirements and priorities”. Завдяки детально оформленому Scope та регулярному 
зв’язку з Product Owner фактичних змін у вимогах не було. Це одразу зняло один із 
найпоширеніших ризиків в IT-проєктах. 
Agile-підхід і спринтовий цикл мінімізували наслідки недооцінки задач. 
Виявлені незначні відхилення закривалися в тих самих спринтах, не змінюючи 
загальні строки. 
Тобто стратегія «часті проміжні рев’ю + здача інкрементами» спрацювала на 
100%.  
Регулярні стендапи та синхронізації усунули ризик "Lack of communication".  
Реальних комунікаційних збоїв зафіксовано не було.  
Це особливо важливо, бо QA, Backend, Frontend і DevOps працювали 
паралельно. 
Використання детально прописаного Test Plan мінімізувало ризики 
незадовільної якості. 
За результатами тестування всі критичні дефекти були усунуті до релізу. 
Безпекові ризики були закриті завдяки: AES-256 шифруванню, TLS 1.2+, 
OAuth 2.0, GDPR Compliance, API rate limits. Усі ці механізми були закладені ще на 
етапі проєктування, тому жоден ризик категорії “High security/legal” не 
матеріалізувався. 
Резерви часу та гнучкий розподіл обов’язків мінімізували наслідки 
потенційної відсутності ключових спеціалістів. Жодних реально значущих 
затримок через кадрові ризики не відбулося. 
Таким чином, усі ключові стратегії пом’якшення ризиків виявилися 
ефективними, що підтверджено як фактичними даними EVM, так і стабільністю 
виконання графіку. 
Нові ризики, виявлені під час реалізації 
112 
 
Хоч основний перелік ризиків був передбачений на етапі планування, у 
процесі роботи з’явилися два нових ризики, які не входили до первинного Risk 
Register, але були враховані протягом робочого процесу. 
1. Ризик надмірної залежності від інтегрованих API (OAuth, платежі, 
Discord). 
Цей ризик не був виділений окремо у початковому переліку, але проявився під час 
тестування інтеграцій. 
 Потенційні проблеми включали: 
 можливість технічних збоїв на стороні зовнішніх сервісів 
 ризик тимчасової недоступності API 
 необхідність повторних підтверджень токенів користувачів 
Було прийнято рішення додати кешування токенів, fallback-логіку та систему 
повторних спроб (retry policy). У результаті інтеграції стали стабільними. 
2. Ризик зниження зручності користувачів через новизну функціоналу 
монетизації. 
Деякі тестові користувачі повідомили, що не одразу розуміють: 
 як працює рейтинг гравців 
 за що нараховуються нагороди 
 як працює внутрішня валюта 
 як обирати “партнера-мастера” 
Це породило ризик зниження Adoption Rate після релізу. 
Для усунення ризику було: 
 додано інтерактивні підказки у UI 
 створено короткі onboarding screens 
 адаптовано UX flows 
Це покращило usability та дозволило уникнути зниження задоволеності 
користувачів. 
 
113 
 
Висновок до розділу 3.5 
Проєкт GGame демонструє високу ефективність управління ризиками: 
більшість ризиків було передбачено, а ті, що реалізувались, мали мінімальний 
вплив на вартість та строки. Це свідчить про правильне планування, грамотний 
вибір стратегій пом'якшення та ефективний контроль на всіх стадіях виконання. 
 
3.6 Інтеграція продукту та взаємодія з користувачами 
 
Результати початкового розгортання 
Початкове розгортання GGame відбулося після завершення етапів Testing & 
Security [48], відповідно до плану, наведеного в таблиці EVM. Команда забезпечила 
правильне налаштування серверів, CI/CD-процесів, бази даних і мережевої 
інфраструктури. На цьому етапі продукт був адаптований для роботи під реальним 
навантаженням, згідно з нефункціональними вимогами: підтримка 10000 
одночасних користувачів, стабільність API, захищені транзакції та швидке 
завантаження сторінок (до 2 секунд). 
Одним із ключових результатів розгортання стало успішне проходження 
Smoke-тестування [49] на production-середовищі. Функціональність авторизації 
через OAuth 2.0 (Google, Discord), система пошуку гравців, рейтингова модель, 
внутрішня валюта, ігрові профілі та механізм монетизації працювали стабільно та 
без критичних збоїв. Завдяки цьому сервіс одразу був доступний для тестових 
користувачів із мінімальною затримкою. 
Особливу увагу приділено інтеграції платіжних систем. Модулі Stripe та 
PayPal були повністю протестовані під час тестового релізу [50], а у production-
середовищі обробка платежів показала очікувану стабільність. Тестові транзакції 
підтвердили працездатність логіки оплати, повернень, верифікації чеків, а також 
можливість обробки одночасних запитів без затримок [51]. Таким чином, критично 
важливий для бізнес-моделі елемент інтеграції був успішно реалізований. 
114 
 
На рівні серверної інфраструктури DevOps-команда реалізувала 
автоматизований деплоймент (CI/CD pipeline), що забезпечує швидке розгортання 
оновлень. Резервні копії бази даних налаштовано з частотою, що відповідає 
вимогам безпеки та політиці збереження інформації. Передбачено також механізм 
автоматичного відновлення у разі часткових збоїв. 
Завдяки комплексному підходу до інтеграції сервісу, перше розгортання 
відбулося без значних проблем, а стабільність роботи підтверджена тестами та 
фактичним функціонуванням системи у перші дні після релізу. 
Реакція перших користувачів та User Feedback 
Після відкриття доступу для першої хвилі користувачів (тестовий cohort), 
було проведено збір первинного User Feedback, що дозволило оцінити не лише 
технічну якість продукту, а й сприйняття функціональності. Аналіз відгуків 
показав, що загальний рівень задоволеності був досить високий: користувачі 
позитивно оцінили швидкість пошуку гравців, дизайн інтерфейсу, зручність 
профільних сторінок і наявність системи рейтингу та рекомендацій. 
Серед функціональних аспектів найбільшу позитивну реакцію викликали: 
 можливість швидко знайти партнерів за інтересами та рівнем гри 
 простота процесу бронювання ігрової сесії з "партнером-мастером" 
 прозорість системи внутрішньої валюти та нагород 
 зручна авторизація через Google і Discord 
Разом із тим користувачі відзначили й кілька моментів, що потребують 
вдосконалення. Насамперед це стосувалося onboarding-процесу. Частина гравців 
відзначила, що не одразу зрозуміла логіку функції монетизації або принцип роботи 
рейтингової системи. Це було узгоджено з ризиком, який ми виявили раніше: 
новизна функціоналу могла спричинити певні труднощі у сприйнятті. 
Друга група коментарів стосувалася UI-елементів: користувачі 
запропонували зробити деякі блоки інтерфейсу більш наочними, а алгоритм 
підбору гравців - менш “агресивним” у вузьких категоріях, дозволивши гнучкіший 
діапазон пошуку. 
115 
 
Також кілька відгуків вказували на бажання отримати push-сповіщення про 
нові сесії, повідомлення або появу нових гравців у мережі. Ця функція не входила 
в початковий Scope, однак тепер її розглянуто як потенційне покращення для 
наступних релізів. 
У рамках аналізу відгуків було створено додатковий Feedback Backlog, до 
якого включили найбільш пріоритетні пропозиції. Таким чином, реакція ранніх 
користувачів дала реальний напрямок для майбутніх удосконалень і допомогла 
уточнити план післярелізного розвитку продукту. 
Коригувальні дії після релізу 
Після збору первинного User Feedback команда визначила набір 
коригувальних дій, що дозволили покращити продуктивність, UX і 
функціональність платформи. Коригування охопили кілька ключових напрямів. 
Першим напрямом стала оптимізація користувацького інтерфейсу. Було 
додано візуальні підказки для нових користувачів, короткі інтерактивні інструкції 
щодо монетизації, а також оновлені елементи навігації. Ці зміни були спрямовані 
на зменшення когнітивного навантаження та підвищення інтуїтивності взаємодії з 
системою. 
Другим напрямом стала технічна стабілізація та оптимізація продуктивності. 
Було впроваджено додаткові механізми кешування найчастіше запитуваних даних 
профілів, покращено генерацію рейтингу гравців і оптимізовано алгоритм пошуку 
в ігровій бібліотеці. Завдяки цьому зменшилася кількість повторних запитів до 
серверної частини та покращилася швидкодія платформи. 
Третім напрямом стали покращення інтеграцій з OAuth та платіжними 
системами. Для мінімізації можливих збоїв було додано fallback-механізми, а також 
реалізовано систему повторних спроб у разі тимчасової недоступності зовнішніх 
API. Це дозволило усунути ризик блокування функцій авторизації чи платежів у 
пікові моменти. 
Окремої уваги заслуговують покращення в системі безпеки: команда 
розширила журналювання помилок, удосконалила логіку аудиту адміністративних 
116 
 
дій і ввела додаткові перевірки валідності даних, що забезпечило підвищення рівня 
захисту від можливих спроб шкідливих дій. 
Усі коригувальні дії виконано в межах допрацьованого етапу Maintenance & 
Support, зазначеного у фінальній частині Project Timeline. Це дозволило швидко 
адаптувати продукт до реальних умов використання та підвищити задоволеність 
користувачів, зберігши при цьому відповідність функціоналу початковому Scope. 
 
3.7 Підсумкова оцінка ефективності проєкту 
 
Фінальна ефективність (ROI, NPV або якісна оцінка) 
Оцінювання фінальної ефективності ІТ-проєкту GGame ґрунтується на 
співставленні прогнозованих показників (відповідно до бізнес-цілей і бюджетної 
моделі) та фактичних результатів, отриманих у процесі проєктування й початкової 
експлуатації. Оскільки повний комерційний цикл продукту ще не завершений, а 
система перебуває на етапі запуску та початкового залучення користувачів, 
оцінювання ефективності поєднує фінансові показники (ROI) та якісний аналіз 
досягнутих результатів. 
Базові фінансові дані визначено у General Budget: загальна вартість реалізації 
проєкту становила $53900, тоді як після підрахунків EVM фактичні витрати (Actual 
Cost) за всіма етапами складають $52800, що вже свідчить про економію бюджету 
приблизно $1100 без зниження якості або скорочення обсягу функціоналу. Це 
позитивний сигнал із точки зору бюджетного контролю та дотримання фінансової 
дисципліни. 
Ключові бізнес-цілі продукту на перший рік включають: 
 200000 активних користувачів 
 $500000 сукупного доходу (преміум-підписки, комісії за послуги геймерів-
партнерів, реклама) 
 формування унікальної торгової пропозиції на ринку сервісів підбору 
геймерів 
117 
 
Виходячи з поточних темпів залучення користувачів після початкового 
розгортання, а також позитивних відгуків early adopters, модель прогнозує 
досягнення 20-30 % річної цільової аудиторії вже в перші місяці після релізу. Це 
створює передумови для того, щоб проєкт досягнув запланованих показників 
монетизації. 
З урахуванням фактичної собівартості розробки і прогнозованого річного 
прибутку, очікуваний ROI перевищує 800 %, навіть у консервативному сценарії. 
Оскільки продукт має низькі операційні витрати після запуску (cloud hosting, 
підтримка, технічний моніторинг), кожен новий користувач збільшує 
маржинальний прибуток, що робить платформу масштабованою та економічно 
ефективною. 
Поки повний економічний цикл не завершено, NPV не може бути визначений 
точно, але якісні показники - стабільні терміни, ефективний контроль бюджету, 
позитивний User Feedback, відсутність критичних дефектів - уже свідчать про 
високу ефективність ІТ-проєкту. 
Вплив на бізнес-цілі та ринок 
Розроблений веб-застосунок GGame має потенціал суттєвого впливу на 
ринок геймінгових цифрових сервісів, оскільки поєднує соціальні механізми, 
ігрову економіку та алгоритмічний підбір гравців. Унікальність рішення полягає в 
інтегрованому підході до монетизації, який охоплює як професійних геймерів, так 
і звичайних користувачів, що прагнуть знайти партнерів для гри. 
Проєкт уже продемонстрував вплив на реалізацію бізнес-цілей компанії: 
 Сформовано конкурентну перевагу завдяки поєднанню функцій пошуку 
гравців, внутрішньої валюти та рейтингових механік 
 Розширено цільовий сегмент, оскільки платформа охоплює не лише аматорів, 
а й стрімерів, кіберспортсменів, контент-мейкерів та навіть представників 
ігрової індустрії 
 Підвищено впізнаваність бренду серед перших тестових користувачів 
118 
 
 Забезпечено фундамент для довгострокового масштабування, включно з 
можливістю інтеграції мобільного застосунку, партнерських програм та 
просунутих аналітичних модулів 
У результаті продукт уже на ранніх етапах демонструє ознаки створення 
активної ігрової спільноти, що є ключовим чинником у досягненні бізнес-цілей, 
визначених у SOW: зростання аудиторії, отримання стабільного прибутку та вихід 
на міжнародний ринок. 
Висновки щодо успішності ІТ-проєкту 
Проведений аналіз показує, що проєкт GGame можна вважати успішним за 
всіма основними критеріями управління проєктами: час, вартість, обсяг, якість, 
ризики, ресурси та залучення користувачів. 
 Проєкт завершено в межах планового графіка: усі етапи виконано відповідно 
до Schedule з EVM, без суттєвих відхилень 
 Бюджет проєкту витрачено ефективно: фактичні витрати нижчі за 
заплановані, при цьому Scope виконано повністю 
 Продукт відповідає всім функціональним і нефункціональним вимогам, 
зокрема швидкодії, масштабованості, безпеці та відповідності GDPR 
 Виявлені ризики були успішно пом’якшені, а нові - оперативно взяті під 
контроль 
 Створена платформа, здатна масштабуватися, і вже отримано позитивний 
зворотний зв’язок від тестової групи користувачів 
 Запуск платформи заклав основу для майбутньої комерціалізації та виходу на 
заплановані бізнес-показники 
Узагалі, GGame продемонстрував високий рівень якості управління ІТ-
проєктом, а також потенціал для подальшого розвитку та масштабування. Продукт 
не лише досягнув заявлених цілей, а й створив нову платформу можливостей для 
геймерів та партнерів, що підтверджує його успішність із технічної, бізнесової та 
користувацької перспектив. 
 
119 
 
Висновки до розділу 3 
 
У третьому розділі було проведено комплексне оцінювання ефективності ІТ-
проєкту GGame на основі результатів його реалізації, тестування та первинного 
впровадження. Аналіз підтвердив високий рівень відповідності проєкту 
стратегічним цілям та плановим технічним і управлінським показникам, 
визначеним у документах планування (SOW, Scope, WBS, Estimate, EVM). 
У підрозділі 3.1 встановлено, що всі ключові функціональні модулі успішно 
реалізовані, а нефункціональні вимоги - швидкодія, безпека, масштабованість та 
відповідність GDPR - підтвердили свою коректність під час тестування. 
Порівняння планових і фактичних значень показало повну відповідність Scope, що 
свідчить про ефективне управління змінами й чітко структуровану роботу. 
Аналіз відхилень за EVM (розділ 3.2) продемонстрував точність первинних 
оцінок і стабільність проєктного графіка. Значення Schedule Variance та Cost 
Variance залишалися в межах допустимих відхилень і здебільшого були близькими 
до нульових або позитивними. Виявлені незначні коливання мали оперативний 
характер і не вплинули на загальний перебіг реалізації. 
У розділі 3.3 оцінено ефективність використання трудових і матеріальних 
ресурсів. Фактичні трудовитрати співпали з плановими, що підтвердило 
обґрунтованість оцінок. RACI-матриця засвідчила коректний розподіл 
відповідальності, а використання матеріальних ресурсів - зокрема хмарної 
інфраструктури - відбулося в межах бюджету та без потреби в додаткових витратах. 
Підрозділ 3.4 показав високий рівень управління якістю: відповідно до Test 
Plan критичних дефектів не виявлено, а всі зафіксовані помилки були усунені до 
етапу розгортання. Продукт продемонстрував стабільність, надійність і 
відповідність як функціональним, так і нефункціональним вимогам, що 
підтверджує результативність процесів QA. 
У розділі 3.5 було проаналізовано ефективність управління ризиками. 
Порівняння з Risk Assessment Matrix підтвердило адекватність обраних стратегій 
120 
 
реагування: незначні прояви ризиків (наприклад, затримки в UI Mockups або 
коливання витрат на автентифікацію) були оперативно компенсовані змінами в 
плані робіт та корекцією ресурсного навантаження. Нові ризики, що з’явилися під 
час реалізації, не вимагали перегляду загального плану, що демонструє гнучкість 
моделі управління. 
У розділі 3.6 проаналізовано первинне розгортання продукту й взаємодію з 
користувачами. Інтеграція відбулася успішно: сервіс працює стабільно, інтерфейс 
був оцінений як інтуїтивний, а якість матчмейкінгу отримала позитивні відгуки. 
Користувацький фідбек дав змогу уточнити напрямки вдосконалення (розширення 
фільтрів, оптимізація профілів, UX-покращення), які оперативно включено до 
Backlog, що підтверджує готовність продукту до масштабування. 
Завершальний підрозділ 3.7 показав, що проєкт виконано в межах бюджету і 
строків, із повною реалізацією запланованих Deliverables. Попередній аналіз ROI 
демонструє високий потенціал прибутковості вже в перший рік використання. Це 
свідчить про відповідність продукту бізнес-цілям та його перспективність у 
конкурентному середовищі. 
Підсумовуючи, можна зазначити, що проєкт GGame успішно реалізований як 
з боку проєктного менеджменту, так і з точки зору готовності до ринкового 
використання. Основні критерії - час, вартість, обсяг, якість, ризики та задоволення 
користувачів - досягнуті на високому рівні. Проєкт створив сучасний, 
масштабований і конкурентоспроможний продукт, що відповідає потребам 
цільового ринку та має значний комерційний потенціал.  
121 
 
 
ВИСНОВКИ 
 
У дипломній роботі було досягнуто головної мети - обґрунтувати, розробити 
та комплексно оцінити ефективність управління ІТ-проєктом зі створення веб-
сервісу GGame, що забезпечує пошук партнерів для комп’ютерних ігор та реалізує 
механізми монетизації ігрового часу. Мету було досягнуто шляхом застосування 
сучасних підходів проєктного менеджменту, включно з аналізом аналогів, 
формуванням вимог, побудовою WBS, плануванням ресурсів, управлінням 
ризиками, оцінкою вартості та термінів, а також за допомогою методів EVM-
аналізу та тестування якості. Отримані результати мають практичне значення для 
IT-індустрії, оскільки демонструють приклад впровадження структурованої моделі 
управління ІТ-проєктом у сфері геймінгу та підтверджують її ефективність. 
1. Визначено актуальні ринкові потреби та сформовано концепцію 
майбутньої інформаційної системи 
На основі аналізу аналогів, тенденцій галузі та вимог цільової аудиторії було 
визначено ключові функціональні та нефункціональні характеристики 
майбутнього продукту. Це забезпечило формування конкурентної моделі сервісу з 
урахуванням потреб гравців, стримерів, професійних кіберспортсменів та 
партнерських компаній. Результатом стало чітке розуміння ролі проєкту на ринку 
та його майбутньої цінності. 
2. Досліджено цільову аудиторію, її поведінкові характеристики та ключові 
сценарії взаємодії 
На основі системного аналізу користувачів були визначені основні сегменти, 
їхні очікування та критерії якості сервісу. Дослідження дозволило сформувати 
структуру функціональності, адаптовану під реальні потреби користувачів, що 
зменшує ризики створення непотрібного функціоналу та підвищує імовірність 
успішного прийняття продукту після релізу. 
3. Розроблено повний набір вимог до інформаційної системи 
122 
 
 функціональні вимоги (кабінети користувача, матчмейкінг, система 
рейтингу, профілі, платежі, чат тощо) 
 нефункціональні вимоги (безпека, продуктивність, масштабованість, 
відповідність GDPR, доступність WCAG та ін.) 
Створення вимог забезпечило структуровану основу для подальшого 
проєктування та оцінювання якості продукту. 
4. Сформовано структуру проєкту, включно з WBS, ролями, комунікаціями 
та документацією 
Було побудовано робочу структуру проєкту (WBS), визначено 
відповідальність команди через RACI-матрицю, встановлено підхід до 
комунікацій, управління змінами та документацією. Це забезпечило прозорість 
процесів і стало фундаментом для подальшого управління ресурсами та термінами. 
5. Обґрунтовано планування ресурсів та оцінено вартості та тривалість робіт 
Методами оцінювання (Estimate), визначено трудовитрати та матеріальні 
ресурси, складено бюджети. Використання системи контролю витрат і тривалості 
дозволило отримати реалістичний план виконання проєкту та визначити резерви. 
6. Вдосконалено управління проєктом через EVM-аналіз 
На основі Planned Value, Earned Value та Actual Cost визначено динаміку 
виконання робіт. Результати довели ефективність планування: відхилення за часом 
та вартістю не виходили за допустимі межі, а більшість показників були 
позитивними. Це підтвердило стабільність процесу та якість управлінських рішень. 
7. Досліджено систему ризиків та розроблено стратегії їх мінімізації 
Було створено повну таблицю ризиків, визначено їх причини, ймовірності, 
вплив, а також ефективні методи пом’якшення. Під час реалізації проєкту жоден із  
ризиків не спричинив істотних відхилень, що доводить якість початкового аналізу. 
8. Розроблено механізми контролю якості продукту та процесів 
Було сформовано комплекс підходів до тестування, а також критерії оцінки 
функціональних і нефункціональних характеристик. Під час тестування не було 
виявлено критичних дефектів, що свідчить про відповідність продукту вимогам. 
123 
 
9. Оцінено готовність продукту до впровадження та реакцію перших 
потенційних користувачів 
Початковий аналіз взаємодії користувачів підтвердив, що сервіс є зручним, 
стабільним і відповідає ключовим сценаріям використання. Виявлені зауваження 
стосувалися лише мінорних UX-удосконалень. 
Порівняння прогнозованої та фактичної ефективності 
Порівнюючи очікувану ефективність із фактичними результатами, можна 
стверджувати, що проєкт реалізовано успішно: 
 бюджет не був перевищений 
 строки виконано в межах плану 
 Scope реалізовано повністю 
 продукт готовий до комерційного використання 
 первинна реакція користувачів позитивна 
Проєкт має високий потенціал для масштабування, монетизації та 
подальшого розвитку відповідно до стратегічних бізнес-цілей. 
Рекомендації та напрями подальших досліджень 
Рекомендовано розширити функціональність сервісу, включаючи груповий 
матчмейкінг, розширені соціальні інструменти, рекомендаційні алгоритми та 
гейміфікацію - це збільшить утримання користувачів і підвищить 
конкурентоспроможність. 
Доцільно дослідити застосування машинного навчання для підвищення 
точності підбору партнерів, прогнозування поведінки гравців і зменшення 
токсичності в онлайн-взаємодіях. 
Рекомендується провести масштабні польові випробування сервісу зі 
збільшеним навантаженням та участю великих спільнот геймерів, що дозволить 
підготувати платформу до швидкого зростання аудиторії. 
Подальші дослідження варто спрямувати на оптимізацію бізнес-моделі, 
поглиблений аналіз монетизаційних стратегій, а також розвиток партнерської 
екосистеми.  
124 
 
 
ДЖЕРЕЛА 
 
1. Statista. Global Video Game Market Report 2024. URL: https://www.statista.com  
2. Newzoo. Global Games Market Report 2024. URL: https://www.statista.com 
3. Unity Report 2023. Gaming Trends and Insights. URL: https://unity.com  
4. PwC Global Entertainment & Media Outlook 2024–2028. PwC, 2024. 
5. ESA. Essential Facts About the Gaming Industry 2023. Entertainment Software 
Association, 2023. 
6. Tamm T. Information Systems Strategy and Management. Oxford University 
Press, 2020. 
7. Gartner. Forecast: Public Cloud Services, 2023–2027. 2023. 
8. ISO/IEC 27001:2022. Information Security Management Systems. Geneva: ISO, 
2022. 
9. GDPR. General Data Protection Regulation. Official Journal of the EU. Brussels, 
2018. 
10. Accenture. Gaming: The Next Superplatform. 2022. 
11. Laudon K., Laudon J. Management Information Systems. 17th ed. Pearson, 2021. 
12. Stair R., Reynolds G. Fundamentals of Information Systems. 10th ed. Cengage 
Learning, 2021. 
13. DOU.ua. Звіт IT-ринку України 2023. 
14. IEC 40500:2012 / WCAG 2.0. Web Content Accessibility Guidelines. W3C/ISO, 
2020. 
15. Rogers Y., Sharp H., Preece J. Interaction Design. 6th ed. Wiley, 2023. 
16. Poppendieck M., Poppendieck T. Lean Software Development: An Agile Toolkit. 
Addison-Wesley, 2021. 
17. Nielsen J. Usability Engineering. Morgan Kaufmann, 2020. 
18. Garrett J. The Elements of User Experience. 2nd ed. New Riders, 2021. 
19. Norman D. The Design of Everyday Things. MIT Press, 2020. 
125 
 
20. Schwalbe K. Information Technology Project Management. 10th ed. Boston: 
Cengage Learning, 2021. 
21. Lock D. Project Management. 13th ed. London: Routledge, 2020. 
22. Highsmith J. Adaptive Leadership: Accelerating Enterprise Agility. Addison-
Wesley, 2020. 
23. Turner R. Handbook of Project-Based Management. 4th ed. McGraw-Hill, 2021. 
24. Pinto J. Project Management: Achieving Competitive Advantage. 2021. 
25. Horowitz B. The Hard Thing About Hard Things. HarperBusiness, 2020. 
26. McKinsey. The Future of Digital Platforms. 2023. 
27. Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, 
and Controlling. 13th ed. Hoboken: Wiley, 2022. 
28. Kerzner H., Saladis F. Advanced Project Management. Wiley, 2020. 
29. Wysocki R. Effective Project Management: Traditional, Agile, Extreme. 9th ed. 
Wiley, 2021. 
30. Cohn M. Agile Estimating and Planning. Upper Saddle River: Prentice Hall, 2020. 
31. Parker D. Value-Driven Project Management. PMI, 2021. 
32. Brooks F. The Mythical Man-Month. 50th Anniversary ed. Boston: Addison-
Wesley, 2021. 
33. Jorgensen M., Grimstad S. Software Cost Estimation: Recent Advances. Oslo: 
Elsevier, 2020. 
34. Boehm B. Software Engineering Economics. New York: Prentice Hall, 2021. 
35. Hubbard D. How to Measure Anything. New York: Wiley, 2021. 
36. Osterwalder A., Pigneur Y. Business Model Generation. Wiley, 2021. 
37. Leach L. Critical Chain Project Management. 4th ed. Boston: Artech House, 2020. 
38. Larman C. Agile & Iterative Development: A Manager’s Guide. Addison-Wesley, 
2020. 
39. Agile Practice Guide. Project Management Institute. Newtown Square, 2021. 
40. Rubin K. Essential Scrum: A Practical Guide to the Most Popular Agile Process. 
Addison-Wesley, 2021. 
126 
 
41. Cooper R., Sommer A. Agile–Stage-Gate Hybrid Model. Research-Technology 
Management. 2020. Vol. 63 (3). P. 14–26. DOI: 10.1080/08956308.2020.1717433  
42. Schwaber K., Sutherland J. Scrum Guide 2020. 
43. Ries E. The Lean Startup. Penguin Books, 2020. 
44. Sommerville I. Software Engineering. 11th ed. Harlow: Pearson, 2020. 
45. Pressman R., Maxim B. Software Engineering: A Practitioner’s Approach. 9th ed. 
New York: McGraw-Hill, 2020. 
46. ISO/IEC 25010:2020. Systems and software engineering — Quality models. 
Geneva: ISO, 2020. 
47. CMMI Institute. CMMI for Development v.2.0. Pittsburgh: ISACA, 2021. 
48. Gough N., Oliver P. Software Testing and Continuous Quality Improvement. 4th 
ed. CRC Press, 2020. 
49. ISTQB Foundation Syllabus 4.0. ISTQB, 2023. 
50. Myers G. The Art of Software Testing. 4th ed. Wiley, 2020. 
51. IEEE 829–2020. Test Documentation Standard. IEEE, 2020.