Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/7039| Title: | Створення комп’ютерної гри на основі проєктного підходу |
| Authors: | Прокопенко , Тетяна Олександрівна Пархоменко, Павло Андрійович |
| Keywords: | комп’ютерна гра;проєктний підхід;Управління проєктом;розробка;економічна ефективність |
| Issue Date: | 17-Dec-2025 |
| Abstract: | Практично завжди під час розробки сучасних програмних продуктів, зокрема комп’ютерних ігор, виникає комплекс типових проблем: постійне розширення функціоналу та збільшення навантаження на систему, затримки у виробництві контенту, неузгодженість між технічними та творчими підрозділами, зміни вимог замовника або гравців, а також ризик перетворення розробки гри на безкінечний процес. Використання методів проєктного менеджменту та чіткої системи контролю процесів дозволяє уникати більшості таких ситуацій. Застосування інструментів планування, оцінювання, координації та аналізу, що традиційно використовуються в управлінні ІТ-проєктами, дає можливість своєчасно реагувати на зміни і не допустити зриву строків чи перевитрат бюджету, які особливо критичні в GameDev-галузі, що є однією з найбільш динамічних та непередбачуваних. У практиці все ще існує значна кількість непорозумінь щодо моделей, методів і технологій управління проєктами. Часто розробка гри сприймається лише як творчий процес, що потребує лише фінансування. Однак, як показує досвід індустрії, навіть за наявності достатнього бюджету відсутність професійного управління призводить до затримок, зростання технічного боргу, невиправданих витрат, а іноді – до повного провалу перспективних ідей. Управління – це комплекс планування, організації, мотивації та контролю, що забезпечує досягнення поставлених результатів. У сучасному розумінні створення комп’ютерної гри є повноцінним проєктом, що поєднує технічні, творчі, маркетингові та аналітичні складові. Саме тому темою даної роботи є «Створення комп’ютерної гри на основі проєктного підходу». На сьогодні методологія проєктного менеджменту зарекомендувала себе як один із найефективніших способів упорядкування та успішної реалізації складних ІТ-проєктів. Чітко визначені результати, обмеження за часом, бюджетом і якістю, а також прогнозування ризиків і розробка планів реагування дозволяють забезпечити системний та контрольований хід розробки гри. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/7039 |
| Appears in Collections: | 126 Інформаційні системи та технології (IT Project Management) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| РЕП_МАГ_Пархоменко_МІТ-2411.pdf Restricted Access | 946.43 kB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ ПРОЄКТУВАННЯ
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи магістра
на тему: Створення комп’ютерної гри на основі проєктного підходу.
Виконав здобувач другого
(магістерського) рівня вищої освіти
__2___курсу, групи МІТ2411
Спеціальності 126 Інформаційні системи та
технології
ОП «IT Project Management»
Пархоменко Павло Андрійович
Керівник: завідувач кафедри ІТП, д.т.н.,
проф. Прокопенко Тетяна Олександрівна
Рецензент: посада, науковий ступінь, вчене
звання, ПІП
Черкаси 2025 року
2
ЗМІСТ
ВСТУП .................................................................................................................. 3
РОЗДІЛ I Теоретичні засади створення комп’ютерної гри на основі проєктного
підходу .................................................................................................................. 7
1.1. Особливості розробки комп’ютерної гри як проєкту ........................................ 7
1.2 SWOТ та PEST аналізи проєкту створення комп’ютерної гри ........................... 10
1.3. Концепція проєкту .................................................................................................. 18
РОЗДІЛ ІІ Галузі знань створення комп’ютерної гри на основі проєктного підходу 27
2.1 Управління комунікаціями у проєкті ..................................................................... 27
2.2 Визначення та контроль змісту проєкту ................................................................ 39
2.3 Управління ресурсами у проєкті ............................................................................ 43
2.4 Управління часом у проєкті .................................................................................... 48
2.5 Управління вартістю у проєкті ............................................................................... 50
2.6 Управління закупівлями у проєкті ......................................................................... 56
2.7 Управління якістю у проєкті ................................................................................... 59
2.8 Управління ризиками у проєкті .............................................................................. 62
2.9 Контроль прогресу та мотивація команди ............................................................. 64
2.10 Управління інформаційною безпекою ................................................................. 67
Розділ ІІІ Оцінка економічної ефективності проєкту .............................................. 72
3.1 Планування фінансових ресурсів інвестиційної фази ІТ проєкту .................. 72
3.2 Оптимізація плану фінансування інвестиційної фази проєкту ....................... 74
3.3 Розробка зведеного кошторису витрат інвестиційної фази проєкту .............. 77
3.4 Прогнозування показників операційної діяльності ......................................... 79
3.5 Планування амортизаційних витрат операційної діяльності .......................... 82
3.6 Планування кредитних процесів операційної діяльності ................................ 83
3.7 Прогноз доходів операційної діяльності ........................................................... 84
3.8 Прогноз витрат операційної діяльності ............................................................. 85
3.9 Прогноз грошових потоків операційної діяльності .............................................. 86
3
3.10 Прогноз грошових потоків проєкту ..................................................................... 88
ВИСНОВКИ ......................................................................................................... 91
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................ 93
ДОДАТКИ ....................................................................................................................... 98
4
ВСТУП
Практично завжди під час розробки сучасних програмних продуктів, зокрема
комп’ютерних ігор, виникає комплекс типових проблем: постійне розширення
функціоналу та збільшення навантаження на систему, затримки у виробництві
контенту, неузгодженість між технічними та творчими підрозділами, зміни вимог
замовника або гравців, а також ризик перетворення розробки гри на безкінечний
процес. Використання методів проєктного менеджменту та чіткої системи контролю
процесів дозволяє уникати більшості таких ситуацій. Застосування інструментів
планування, оцінювання, координації та аналізу, що традиційно використовуються в
управлінні ІТ-проєктами, дає можливість своєчасно реагувати на зміни і не допустити
зриву строків чи перевитрат бюджету, які особливо критичні в GameDev-галузі, що є
однією з найбільш динамічних та непередбачуваних.
У практиці все ще існує значна кількість непорозумінь щодо моделей, методів
і технологій управління проєктами. Часто розробка гри сприймається лише як
творчий процес, що потребує лише фінансування. Однак, як показує досвід індустрії,
навіть за наявності достатнього бюджету відсутність професійного управління
призводить до затримок, зростання технічного боргу, невиправданих витрат, а іноді –
до повного провалу перспективних ідей. Управління – це комплекс планування,
організації, мотивації та контролю, що забезпечує досягнення поставлених
результатів. У сучасному розумінні створення комп’ютерної гри є повноцінним
проєктом, що поєднує технічні, творчі, маркетингові та аналітичні складові. Саме
тому темою даної роботи є «Створення комп’ютерної гри на основі проєктного
підходу».
На сьогодні методологія проєктного менеджменту зарекомендувала себе як
один із найефективніших способів упорядкування та успішної реалізації складних ІТ-
проєктів. Чітко визначені результати, обмеження за часом, бюджетом і якістю, а
також прогнозування ризиків і розробка планів реагування дозволяють забезпечити
системний та контрольований хід розробки гри.
Актуальність теми. Використання проєктного підходу під час створення
комп’ютерної гри є актуальним науковим і практичним завданням, оскільки дає змогу
5
оптимізувати роботу команди, мінімізувати ризики, раціонально використовувати
ресурси та дотримуватися встановлених строків виробництва.
Мета дослідження. Метою даної роботи є розкрити методологію проєктного
менеджменту в процесі створення комп’ютерної гри, застосувавши теоретичні знання
та практичні навички, набуті за час навчання.
Для досягнення поставленої мети необхідно вирішити такі завдання:
- визначити цілі та результати GameDev-проєкту;
- підготувати концепцію і техніко-економічне обґрунтування гри;
- сформувати структуру проєкту (фази, етапи, WBS);
- визначити ресурсні та фінансові потреби;
- здійснити вибір підрядників, інструментів і технологій розробки;
- підготувати контракти та організувати внутрішні процеси;
- розробити кошторис і бюджет проєкту;
- визначити строки виконання етапів і скласти календарний план;
- організувати контроль якості, змін і ризиків у проєкті.
Об’єкт дослідження – проєкт створення комп’ютерної гри.
Предмет дослідження – методи та засоби проєктного менеджменту, застосовані в
GameDev-процесі.
Галузь дослідження – інформаційні технології та індустрія розробки ігор.
Методи дослідження. У роботі застосовано інструменти проєктного
менеджменту відповідно до PMBOK, Agile-методологій (Scrum, Kanban) та
інструментів планування GameDev-процесів.
Наукова новизна. У роботі вперше запропоновано застосування сценарно-
цільового методу для формування та оптимізації етапів виробництва гри, а також
адаптовано класичні підходи PMBOK до специфіки ігрової індустрії.
Практичне значення. Отримані результати можуть бути використані при
плануванні, організації та управлінні процесом створення комп’ютерних ігор,
оскільки дозволяють підвищити ефективність, передбачуваність та якість розробки
завдяки застосуванню проєктного підходу.
6
Апробація результатів роботи і публікації. Результати дипломної роботи
представлені тезами Створення комп’ютерної гри на основі проєктного підходу/
Матеріали ІV Міжнародної науково-практичної Internet-конференції «ІННОВАЦІЇ
ТА ПЕРСПЕКТИВНІ ШЛЯХИ РОЗВИТКУ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ
(ІПШРІТ-2025)», 25 листопада 2025. [Електронний ресурс] – Черкаси: ЧДТУ, 2025.
7
РОЗДІЛ I Теоретичні засади створення комп’ютерної гри на основі проєктного
підходу
1.1. Особливості розробки комп’ютерної гри як проєкту
У сучасній цифровій економіці сфера розробки комп’ютерних ігор є
однією з найбільш динамічних, інноваційних та висококонкурентних галузей, у
якій постійно виникають нові технології, інструменти та підходи до створення
інтерактивних продуктів. Створення гри, здатної забезпечити інтерес
користувачів та відповідати запитам ринку, є не лише технічним, але й
організаційним викликом, який вимагає комплексного підходу до планування,
координації та контролю. Комп’ютерна гра виступає інтегрованою програмною
системою, що поєднує сюжетно-наративні елементи, художнє оформлення,
інженерні рішення, механіки взаємодії та оптимізовану програмну реалізацію
[1]. Така багатокомпонентність зумовлює необхідність трактування процесу
розробки гри саме як повноцінного проєкту, який має власний життєвий цикл,
чіткі обмеження, визначених стейкголдерів та механізми управління.
Застосування проєктного підходу дозволяє структурувати весь процес
створення гри як послідовність логічно пов’язаних стадій, що включають
ініціацію, планування, виконання, моніторинг, контроль та завершення [2]. На
етапі ініціації відбувається ідентифікація основної ідеї гри, визначення
стратегічної візії, окреслення ключових механік та формування очікувань щодо
майбутнього продукту. Саме на цьому етапі встановлюються базові обмеження
щодо бюджету, строків та доступних технологічних інструментів. Значною
відмінністю цього виду проєктів від традиційних інженерних рішень є те, що
початкова концепція рідко буває стабільною: упродовж розробки часто виникає
потреба в коригуванні дизайнерських і програмних рішень, що робить
початковий план менш детермінованим. Як наслідок, управління таким проєктом
передбачає не стільки слідування жорстко фіксованому плану, скільки
підтримання гнучкої структури, здатної адаптуватися до змін [3].
8
Важливою особливістю проєктів із розробки комп’ютерних ігор є творчий
компонент, який суттєво ускладнює прогнозування результатів. На відміну від
суто технічних проєктів, у яких вимоги можуть бути формалізованими та
однозначно перевірюваними, у сфері геймдизайну значний обсяг рішень має
суб’єктивний характер. Це стосується розробки сценаріїв, побудови ігрових
світів, визначення художнього стилю, темпоральних параметрів геймплею та
налаштування системи балансу. Оскільки ці елементи піддаються оцінці лише
після створення прототипів і проведення тестування, природним чином виникає
потреба в ітеративному підході, який дозволяє поєднувати творчий експеримент
із системним контролем якості. У більшості успішних практик саме циклічне
тестування, збирання фідбеку та покрокове вдосконалення стають центральними
методами управління проєктом [4].
У контексті методологій управління проєктами для ігрової індустрії
характерною є перевага гнучких підходів (Agile), які забезпечують можливість
частого перегляду вимог, швидкого коригування планів та інтеграції результатів
проміжного тестування у наступні фази. Методологія Scrum, наприклад,
дозволяє структурувати роботу команди на короткі ітерації - спринти, під час
яких створюються окремі функціональні елементи гри, що відкриває доступ до
регулярної оцінки прогресу [5]. У свою чергу, Kanban сприяє оптимізації процесу
через постійний потік завдань та візуалізацію їхнього статусу, що є надзвичайно
корисним у проєктах з великою кількістю дрібних, але залежних між собою
задач. Водночас багато студій користуються гібридними методами, які
поєднують структурованість традиційних моделей та гнучкість Agile-підходів,
формуючи внутрішні процедури, адаптовані до специфіки продукту [6].
Складність проєкту створення гри обумовлюється не лише
технологічними аспектами, але й мультидисциплінарністю команди. Типова
команда включає спеціалістів різних напрямів: програмістів, арт-фахівців (2D-
художників, 3D-моделерів, аніматорів), геймдизайнерів, сценаристів, саунд-
дизайнерів, спеціалістів із розробки інтерфейсу (UI/UX), тестувальників,
аналітиків та менеджерів проєктів. Така структура забезпечує комплексний
9
підхід до створення гри, проте водночас потребує ефективної координації та
налагодження безперервної взаємодії між фахівцями. Кожен підрозділ має різні
робочі цикли, інструменти та стандарти, тому важливим є встановлення чітких
протоколів комунікації, регулярних засідань, обміну документацією та
синхронізації результатів. Значну роль відіграють проєктні артефакти, такі як
Game Design Document (GDD), Vision Document, Technical Design Document
(TDD), які забезпечують єдине розуміння цілей і вимог продукту для всіх членів
команди[7].
Технічні обмеження, пов’язані з роботою вибраного ігрового рушія та
цільових платформ, також є визначальними чинниками у проєктному
менеджменті. Продуктивність, доступний набір інструментів, особливості
систем обробки графіки та фізики, робота зі штучним інтелектом, обмеження
мобільних чи консольних платформ - усе це впливає на прийняття технічних
рішень. Розробники повинні враховувати апаратні можливості користувачів,
оптимізацію графічних ресурсів, мінімальні системні вимоги, а також
необхідність масштабування гри під різні розширення та конфігурації пристроїв.
Неправильне врахування технічних умов на ранніх етапах може призвести до
значних часових витрат у майбутньому, що робить технічне планування
невід’ємною складовою загальної проєктної стратегії.
Не менш важливим аспектом є необхідність послідовного контролю якості.
У процесі розробки комп’ютерної гри тестування виконує не лише функцію
виявлення технічних помилок, але й оцінку зручності, реалістичності, балансу
ігрових механік та загальної мотиваційної структури ігроладу. Тому роль QA-
фахівців у таких проєктах є багатогранною: вони забезпечують відповідність гри
технічним стандартам, перевіряють коректність реалізації ігрових сценаріїв та
надають зворотний зв’язок щодо ігрового досвіду. Впровадження системи
безперервного тестування (Continuous Testing) у середовищі безперервної
інтеграції та доставки (CI/CD) дозволяє забезпечити стабільність продукту на
всіх етапах розробки.
10
Таким чином, проєкт створення комп’ютерної гри характеризується
високим рівнем складності, інтегрованістю творчих та технічних елементів,
множинністю етапів і необхідністю дотримання балансу між креативністю,
інженерністю та організаційною структурованістю. Застосування проєктного
підходу дозволяє ефективно управляти цими процесами, забезпечуючи логічне
планування, раціональний розподіл ресурсів, системний контроль якості та
досягнення запланованих результатів у межах узгоджених строків і бюджету.
Успіх такого проєкту визначається не лише технічною досконалістю
програмного продукту, але й здатністю команди створити цілісний, захопливий
та якісно опрацьований ігровий світ, який відповідатиме потребам сучасного
користувача та тенденціям ринку.
1.2 SWOТ та PEST аналізи проєкту створення комп’ютерної гри
У межах реалізації проєкту зі створення комп’ютерної гри особливої ваги
набуває детальний стратегічний аналіз внутрішніх і зовнішніх факторів, які
формують умови функціонування проєкту та визначають його подальші
перспективи розвитку. У сучасному глобалізованому й висококонкурентному
середовищі розробники стикаються не лише з потребою формування якісного
продукту, але й із необхідністю ефективного позиціонування своєї гри серед
величезної кількості альтернативних пропозицій. Саме тому SWOT-аналіз
виступає базовим та універсальним інструментом, який дає змогу виявити
стратегічні передумови успіху, мінімізувати потенційні ризики та визначити
напрями подальшого планування [9].
SWOT-аналіз дозволяє систематизувати параметри проєкту у контексті
чотирьох ключових груп: сильні сторони (Strengths), слабкі сторони
(Weaknesses), можливості (Opportunities) та загрози (Threats). Він поєднує
внутрішню оцінку ресурсів і компетенцій проєктної команди з аналізом
зовнішнього ринкового середовища, що включає динаміку попиту, технологічні
тренди, поведінку конкурентів, економічні та соціальні чинники. Результати
проведеного аналізу формують основу стратегічного бачення та дозволяють
адаптувати концепцію гри відповідно до вимог ринку [10].
11
Сильні сторони визначають потенціал проєкту та виступають ключовими
внутрішніми ресурсами, здатними забезпечити конкурентні переваги. У
контексті розробки комп’ютерної гри до сильних сторін може належати
унікальність концепту, що дозволяє проєкту виділятися на тлі ринку, насиченого
численними ігровими продуктами. Особливої цінності набуває наявність чітко
сформованого бачення кінцевого результату, яке забезпечує узгодженість роботи
різних підрозділів та сприяє ефективному управлінню проєктом.
Крім того, якщо команда володіє відповідними технічними
компетенціями-наприклад, глибокими знаннями у сфері програмування,
оптимізації, генерації процедурного контенту чи розробки віртуальних світів-це
значно підвищує ймовірність успішної реалізації продукту високої якості.
Сильними сторонами також можуть бути наявність фахівців із досвідом
реалізації попередніх ігрових проєктів, використання сучасного ігрового рушія,
що підтримує широкий набір функціональних можливостей, а також доступ до
ліцензійних інструментів для створення графічного та аудіоконтенту. У свою
чергу, гармонійна внутрішня комунікація та налагоджені процеси прийняття
рішень створюють підґрунтя для стабільного розвитку проєкту.
Слабкі сторони демонструють обмеження або внутрішні проблеми
проєкту, які можуть негативно вплинути на його реалізацію або фінансові
результати. Для проєктів у сфері розробки ігор типовими слабкими сторонами є
недостатність фінансових ресурсів, що може призвести до обмеження
функціональності продукту, тривалих термінів розробки або необхідності
скорочення штатної чисельності команди. Важливо також враховувати можливі
кадрові ризики, пов’язані з низьким рівнем досвіду окремих розробників або
відсутністю експертів у важливих сферах, таких як оптимізація коду, побудова
системної архітектури гри, управління мережевою взаємодією чи розробка
якісних анімацій.
До слабких сторін можуть належати також недосконалість внутрішніх
комунікаційних процесів, відсутність стандартизованої проєктної документації
або недостатній рівень організаційної культури. Певні ризики несе і технічна
12
залежність від вибраного ігрового рушія: нарощування складності проєкту може
виявити обмеження продуктивності, що потребуватиме значних зусиль для
оптимізації. Іншими словами, слабкі сторони часто відображають ті аспекти, які
потребують додаткових інвестицій, покращення або структурних змін, аби
мінімізувати негативний вплив на успіх продукту.
Можливості представляють сукупність сприятливих зовнішніх факторів,
які можуть бути використані для посилення позицій проєкту на ринку. Однією з
ключових можливостей є зростання ринку відеоігор, який демонструє позитивні
тенденції завдяки збільшенню аудиторії, поширенню доступу до інтернету та
зростанню інтересу до інтерактивних розважальних форматів. У межах цього
тренду особливу увагу варто звертати на розвиток нішевих сегментів ринку, які
можуть забезпечити проєкту стійку конкурентну перевагу, наприклад, ігри з
освітнім потенціалом, VR-проєкти, тактильні та експериментальні формати або
продукти з унікальними соціальними механіками.
До можливостей також можна віднести доступність сучасних платформ
для дистрибуції, таких як Steam, Epic Games Store чи мобільні маркетплейси, які
значно спрощують вихід продукту на широкий ринок. Підтримка інді-
розробників через грантові програми, конкурси та пітчинги дає змогу залучити
додаткове фінансування та покращити маркетингову присутність гри. Крім того,
поява нових технологій - наприклад, машинного навчання для генерації
контенту, оновлених графічних API чи інструментів для процедурної анімації -
відкриває можливість покращення ігрових рішень без суттєвого збільшення
витрат.
Загрози відображають сукупність негативних зовнішніх чинників, які
можуть створити ризики для успіху проєкту. У сфері розробки комп’ютерних
ігор однією з найсуттєвіших загроз є високий рівень конкуренції: на ринку
щоденно з’являються десятки нових проєктів, і лише невелика частина з них
отримує достатню увагу з боку користувачів. Це означає, що навіть якісний
продукт може залишитися непоміченим без належної маркетингової підтримки.
13
Суттєвими загрозами також є швидкі технологічні зміни, які можуть
зробити обрані інструменти застарілими ще на етапі розробки, а також зміни
алгоритмів і правил дистрибуційних платформ, що впливають на просування
гри. Додатковими ризиками є економічні кризи, зміни у поведінці споживачів,
коливання у вартості послуг хмарних технологій, а також можливі юридичні
проблеми, пов’язані з ліцензуванням програмного забезпечення, авторських прав
чи використання сторонніх матеріалів.
Ефективне стратегічне планування будь-якого інноваційного проєкту,
зокрема такого складного й багатофакторного як створення комп’ютерної гри,
потребує глибокої оцінки чинників макрооточення. На відміну від внутрішнього
аналізу або аналізу галузевого середовища, PEST-аналіз фокусується виключно
на зовнішніх факторах, які не підлягають контролю з боку команди розробників,
але здатні суттєво вплинути на загальну реалізованість, економічну ефективність
і подальшу життєздатність проєкту. Макросередовище є багатокомпонентним,
оскільки охоплює політичні, економічні, соціокультурні та технологічні аспекти,
кожен із яких створює як можливості, так і загрози для проєкту. В умовах
швидкозмінної ігрової індустрії, де конкуренція постійно зростає, а технологічні
інновації радикально змінюють стандарти якості, PEST-аналіз дозволяє коректно
обґрунтувати стратегічні рішення та адаптувати проєкт до актуальних умов
ринку [11].
Політичні та правові фактори значною мірою формують нормативну
основу, у межах якої функціонує ігрова індустрія. Одним із ключових аспектів є
законодавство у сфері інтелектуальної власності та авторського права. Оскільки
комп’ютерна гра включає великий обсяг унікальних активів - графіку, моделі,
анімації, музику, сценарні матеріали та програмний код - необхідність їх захисту
є надзвичайно важливою. Недотримання ліцензійних умов або порушення
авторських прав може спричинити юридичні наслідки, фінансові втрати та
репутаційні ризики для розробника. Державні норми, що регламентують
використання стороннього ПЗ, відкритих бібліотек, музичних творів або
14
інструментів розробки, визначають ступінь свободи та легітимності
створюваного продукту.
Другим важливим аспектом виступає регулювання електронної комерції та
онлайн-дистрибуції, адже продаж комп’ютерних ігор у більшості випадків
здійснюється через цифрові платформи. Законодавчі вимоги щодо
оподаткування цифрових послуг, правил міжнародної торгівлі, обмежень щодо
географічної доступності контенту або вимог до захисту персональних даних
користувачів безпосередньо впливають на модель роботи з платформами, такими
як Steam, Epic Games Store чи мобільні магазини. Не менш важливими є
політична стабільність та державна підтримка ІТ-сектора, яка може
реалізовуватися через податкові пільги, інвестиційні фонди або грантові
програми для стартапів, що створює сприятливі умови для розвитку ігрової
індустрії.
Економічні фактори визначають матеріальні можливості реалізації
проєкту й формують його фінансову модель. Одним із ключових параметрів є
купівельна спроможність цільової аудиторії. Якщо гра орієнтується на
преміальний сегмент (premium), важливо оцінити рівень доходів користувачів та
їхню готовність платити за цифровий контент. Для free-to-play моделей основний
акцент зміщується на поведінкову економіку споживачів, ефективність
монетизації через внутрішньоігрові покупки, рекламу або підпискові механізми.
Економічне середовище впливає також на собівартість розробки. Рівень
інфляції, зміни у вартості обладнання та програмних інструментів, витрати на
хмарні сервіси, а також курсові коливання національної валюти можуть істотно
змінити бюджет проєкту. Це особливо актуально для команд, що працюють на
міжнародних ринках або використовують ліцензійні інструменти із прив'язкою
до іноземних валют. Важливу роль відіграє й доступність фінансування:
венчурні інвестиції, гранти, кредити, платформи краудфандингу, що можуть
стати додатковими джерелами розвитку проєкту, але потребують чіткого
стратегічного планування та прозорої системи ризик-менеджменту.
15
Соціокультурні фактори визначають контекст, у якому сприймається
ігровий продукт, та впливають на формування його концепції, контенту та
ціннісної моделі. Одним із провідних чинників є зміна стилю життя та зростаюча
популярність цифрових розваг серед широких верств населення. Підвищення
інтересу до ігор як до форми дозвілля, навчання, соціальної комунікації та навіть
професійної діяльності (кіберспорт) збільшує потенційну аудиторію проєкту,
роблячи ринок більш сприятливим для нових продуктів.
Соціальні норми та культурні традиції також визначають обмеження щодо
контенту. Тематика гри, рівень насильства, присутність релігійних, політичних
або етичних елементів можуть по-різному сприйматися в різних країнах. Це
впливає на присвоєння вікових рейтингів (наприклад, PEGI, ESRB), а отже - і на
маркетингову стратегію, цільову аудиторію та допустимі канали дистрибуції.
Зростає роль інклюзивності, репрезентації різних соціальних груп, коректного
зображення гендерних та етнічних аспектів - усе це стає частиною сучасних
трендів і визначає сприйняття гри користувачами.
Крім того, важливим соціальним фактором є зміна комунікаційної
культури. Активне використання соціальних мереж, стримінгових платформ,
блогів та інтерактивних спільнот створює нові можливості для просування
продукту, формування ком’юніті та отримання зворотного зв’язку ще на ранніх
стадіях розробки. Водночас соціальні очікування користувачів стають дедалі
вищими, що вимагає від розробника уважного ставлення до якості, оновлень і
підтримки продукту.
Технологічні фактори є одним із найвпливовіших компонентів
макросередовища у сфері розробки комп’ютерних ігор. Стрімке зростання
обчислювальних потужностей, поява нових графічних процесорів, розвиток
VR/AR-технологій, штучного інтелекту, засобів машинного навчання та
процедурної генерації створюють нові можливості для інновацій. Використання
сучасних API, наприклад Vulkan або DirectX12, забезпечує вищу продуктивність
і гнучкість у розробці графіки, тоді як наявність ефективних SDK та інструментів
автоматизації зменшує тривалість виробничих циклів.
16
Важливу роль відіграє інфраструктура цифрового середовища. Оскільки
більшість ігор поширюється онлайн, швидкість та якість інтернету є критичними
для багатокористувацьких проєктів, оновлень та взаємодії гравців. Надійність
хмарних серверів, технології розподілених баз даних та сервіси автоскейлінгу є
важливими для забезпечення стабільності мережевих режимів. Доступність
платформ тестування, системи безперервної інтеграції, аналітичні інструменти
(game analytics) та машинне навчання у прогнозуванні поведінки користувача
відкривають можливості підвищення ефективності розробки та покращення
користувацького досвіду.
Управління будь-яким інноваційним проєктом, зокрема в галузі розробки
комп’ютерних ігор, невід’ємно пов’язане з необхідністю дотримання визначених
обмежень, що формують загальну архітектуру проєктної діяльності. Концепція
«проєктного трикутника», відома також як «потрійне обмеження», є
фундаментальною моделлю, яка дозволяє системно оцінити взаємозв’язки між
ключовими параметрами проєкту - Змістом (Scope), Часом (Time) та Бюджетом
(Cost). У поєднанні ці складові безпосередньо формують якість кінцевого
продукту (Quality), що робить їх управління критичним для успішної реалізації
проєкту створення комп’ютерної гри [12].
У контексті розробки гри поняття Змісту (Scope) охоплює сукупність усіх
функціональних і нефункціональних вимог, які визначають масштаб і складність
продукту. До нього входять ключові ігрові механіки, штучний інтелект
противників, система прогресії гравця, дизайн рівнів, наративні елементи,
графічні активи, звуковий супровід та інші компоненти. Чим ширший зміст
проєкту, тим більшої кількості ресурсів він потребує, що зумовлює вплив на два
інші елементи трикутника. У проєкті розробки гри на основі проєктного підходу
Scope повинен формуватися на ранніх етапах - під час ініціації та планування - і
закріплюватися у відповідних документах, зокрема у Технічному завданні, WBS-
структурі (Work Breakdown Structure) та плані управління вимогами.
Невизначений або надмірно амбітний зміст є одним із найпоширеніших факторів
17
ризику, що може призвести до «розповзання» вимог (scope creep), значного
подорожчання або зриву термінів.
Не менш важливим елементом є Час (Time), який відображає загальну
тривалість життєвого циклу проєкту та часові рамки для виконання кожної
ключової фази - від передвиробництва до фінального релізу й пострелізної
підтримки. В індустрії комп’ютерних ігор часові обмеження часто мають
критичне значення через прив’язку до ринкових циклів, конкурентних вікон і
маркетингових кампаній. Наприклад, випуск гри у високий сезон, такий як
передноворічні свята, може суттєво збільшити комерційний успіх, тоді як
затримка релізу може призвести до втрати інформаційного шуму та зниження
інтересу з боку потенційних гравців. Крім того, час визначає і можливість
проведення тестування, оптимізації та виправлення помилок, що безпосередньо
впливає на якість гри. У проєктному управлінні час контролюється за допомогою
таких інструментів, як діаграма Ґанта, мережевий графік, критичний шлях (CPM)
та аналіз з урахуванням невизначеності (PERT). Ефективне управління часом
дозволяє уникнути надмірного перевантаження команди, порушення дедлайнів і
компромісів, пов’язаних зі зниженням якості.
Третьою складовою проєктного трикутника є Бюджет (Cost), який включає
прямі та непрямі витрати на реалізацію всіх етапів розробки гри. До прямих
витрат традиційно належать заробітна плата команди розробників, дизайнерів,
художників, тестувальників і менеджерів, оплата ліцензій на програмне
забезпечення, обладнання та хмарні сервіси. Непрямі витрати включають
маркетингові кампанії, видатки на дистрибуцію, юридичний супровід, а також
витрати на аутсорсинг окремих компонентів (наприклад, 3D-моделювання чи
озвучення персонажів). Особливістю ігрової індустрії є значна
непередбачуваність фінансових потреб, оскільки складність реалізації певних
механік або необхідність у додатковій оптимізації може створювати додаткові
фінансові навантаження. Управління бюджетом здійснюється через кошторис
проєкту, план управління затратами, систему контролю виконання бюджету та
18
аналіз відхилень (Earned Value Management), що дозволяє забезпечити фінансову
дисципліну та прогнозованість.
Ключовий принцип проєктного трикутника полягає у взаємозалежності
всіх його елементів: будь-яка зміна одного з параметрів неминуче спричиняє
зміни у двох інших. Наприклад, якщо команда ухвалює рішення розширити зміст
гри шляхом додавання нової механіки або додаткових рівнів, це потребуватиме
збільшення бюджету або продовження строків розробки. Якщо ж ресурси
залишаються незмінними, то команда змушена піти на компроміс щодо якості,
що може негативно позначитися на користувацькому досвіді та ринкових
перспективах гри. У зворотній ситуації, коли бюджету скорочується, проєктний
менеджер повинен або зменшити зміст, або пришвидшити виконання робіт, що
також вплине на кінцеву якість. Саме тому грамотне балансування між трьома
обмеженнями є основою успішного управління проєктом, а ухвалення рішень
повинно ґрунтуватися на системному аналізі їх наслідків [13].
1.3. Концепція проєкту
Проєкт створення комп’ютерної гри у сучасних умовах цифрової індустрії
визначається як комплексна, цілеспрямована та структурована діяльність, що
має чітко окреслені часові межі, обмеження ресурсного характеру та орієнтована
на досягнення конкретного унікального результату - створення інтерактивного
програмного продукту з визначеними функціональними, художніми та
технічними характеристиками [14]. На відміну від операційної діяльності, яка є
повторюваною та стабільною, проєкт розробки гри є одноразовим і неповторним,
оскільки кожна гра створюється на основі унікальної концепції, має власний
набір механік, стилістичних рішень, сценарних ліній та технічної архітектури.
Відправною точкою такого проєкту є потреба ринку у нових формах цифрових
розваг, зростаючий попит на інтерактивний контент і прагнення компаній або
індивідуальних розробників створити конкурентоспроможний продукт, здатний
забезпечити прибутковість та відповідний рівень комерційного успіху [15].
Зміст проєкту охоплює взаємопов’язаний комплекс процесів, які
включають передпроєктні дослідження, формування ігрової концепції та
19
дизайнерського бачення, технічне планування, поетапну розробку програмного
коду, створення візуальних і звукових активів, тестування якості, оптимізацію
продуктивності та підготовку до релізу на обраних платформах дистрибуції.
Особливість розробки комп’ютерної гри полягає у високій міждисциплінарності:
технічна складова тісно пов’язана з творчою, а сам процес виробництва
передбачає постійну координацію між програмістами, художниками,
геймдизайнерами, сценаристами, аналітиками та менеджерами. Проєктний
підхід у такій діяльності забезпечує необхідну структурованість робіт,
системний розподіл відповідальності, контроль над якістю, управління ризиками
та ефективне використання ресурсів, що особливо важливо з огляду на високу
динаміку ринку та значну конкуренцію [16].
З огляду на загальноприйняті критерії класифікації проєктів, проєкт
створення комп’ютерної гри може бути віднесений до кількох груп.
За класом проєкт є монопроєктом, оскільки він спрямований на розробку
одного конкретного продукту. Попри те, що всередині проєкту може існувати
велика кількість підпроєктів (створення музики, розробка мережевої
інфраструктури, моделювання персонажів тощо), всі вони об’єднані однією
кінцевою метою й інтегруються в межах спільної системи управління.
За типом його можна класифікувати як інноваційний, оскільки кінцевий
продукт має унікальні особливості, відсутні на ринку в момент старту розробки,
та економічний, оскільки проєкт спрямований на досягнення фінансового
результату, включно з поверненням інвестицій та отриманням прибутку через
комерційну реалізацію гри. Інноваційність проявляється у нових ігрових
механіках, нестандартному сюжетному підході, технологічних рішеннях або
творчому стилі, що здатні забезпечити конкурентну перевагу [17].
За видом проєкт належить до інвестиційних, адже вимагає значних
початкових фінансових вливань, спрямованих на формування команди,
придбання необхідного програмного забезпечення, забезпечення технічної
інфраструктури, а також на маркетингові активності. Усі ці вкладення робляться
20
з розрахунком на майбутні доходи від продажу гри, мікротранзакцій, підписок
або інших монетизаційних механізмів.
За тривалістю проєкт зазвичай характеризується як середньостроковий або
довгостроковий. Більшість сучасних ігор середнього рівня складності
потребують від одного до трьох років активної розробки, залежно від масштабу,
жанру, розміру команди та складності реалізованих механік. Значний вплив
мають також непередбачені фактори: технічні труднощі, зміни у вимогах,
необхідність додаткового тестування або оптимізації [18].
За масштабом проєкт можна віднести до середніх, що зумовлюється
обсягом бюджету, кількістю людських ресурсів та структурою організаційних
процесів. На відміну від великих AAA-проєктів, які охоплюють сотні
співробітників і бюджети у десятки мільйонів доларів, середні проєкти
передбачають команду від 5 до 40 осіб та значно менші фінансові ресурси. Проте
їх складність залишається достатньо високою, що потребує чіткого управління
та ретельної координації.
За ступенем складності проєкт розробки гри належить до складних,
оскільки включає велику кількість взаємозалежних завдань різної природи -
технічних, креативних, організаційних та управлінських. Складність зумовлена
необхідністю синхронізації між різними підсистемами гри (графічний
рендеринг, фізика, логіка, штучний інтелект, мережеві модулі), забезпеченням
стабільної продуктивності, проведенням систематичного тестування та
підтримки відповідного рівня якості. До цього додаються ризики, пов’язані з
можливими змінами технологічних стандартів, вимог дистрибуційних платформ
та вподобань користувачів [19].
Формування чітко структурованої системи цілей є фундаментальним
елементом успішного управління проєктом створення комп’ютерної гри.
Проєкти у сфері Game Development характеризуються високою невизначеністю,
багатокомпонентністю та необхідністю узгодження творчих, технічних та
економічних рішень. Через це формування коректної системи цілей набуває
стратегічного значення, адже саме вона визначає напрямок роботи команди,
21
структурує процес планування, впливає на розподіл ресурсів та забезпечує базу
для подальшого контролю успішності проєкту [20].
Генеральна мета проєкту формулюється як досягнення успішного випуску
високоякісної комп’ютерної гри на ринок із забезпеченням як комерційної, так і
репутаційної результативності [21]. У цьому контексті успішність
інтерпретується не лише у фінансових категоріях, але й у категоріях сприйняття
та задоволеності кінцевих користувачів, а також у здатності продукту
підтримувати свій життєвий цикл протягом визначеного періоду. Таким чином,
генеральна мета передбачає досягнення двох інтегральних критеріїв: цільового
рівня продажів та високих оцінок від користувачів і професійних критиків.
Поєднання цих аспектів відображає особливість ігрових проєктів, де
комерційний успіх напряму залежить від якості, інноваційності та загальної
емоційної цінності продукту.
Для забезпечення логічної узгодженості цілей використовується метод
декомпозиції, що реалізується у формі дерева цілей. Застосування цього методу
дає змогу перетворити стратегічне бачення на конкретний набір операційних
завдань, що є доступними для планування, вимірювання та контролю. Кожен
елемент дерева цілей має пряму прив’язку до стратегічної мети, а його
досягнення у сукупності забезпечує реалізацію загального задуму проєкту [22].
Дерево цілей у контексті розробки комп’ютерної гри охоплює декілька
ключових рівнів: верхній рівень представлений генеральною метою, другий
рівень включає ключові стратегічні цілі, третій рівень - тактичні цілі, що
визначають напрямки діяльності, а четвертий рівень містить конкретні
вимірювані завдання, реалізація яких забезпечує досягнення тактичних цілей.
Така ієрархічна структура дозволяє ефективно узгоджувати роботу різних
підрозділів: програмістів, дизайнерів, художників, маркетологів та менеджерів,
забезпечуючи системність і прозорість проєктних процесів [23].
У таблиці 1.1 наведено базову структуру цілей, що формує основу
відповідного дерева цілей.
22
Таблиця 1.1
Опис цілей проєкту створення віртуального підприємства
Код Ціль
Ц1 Максимізація прибутку від продажів (Генеральна мета)
Ц2 Досягнення цільового обсягу продажів протягом першого року
(Ключовий показник).
Ц3 Забезпечення високої якості та стабільності продукту (Якість).
Ц4 Мінімізація витрат на розробку в межах бюджету (Ефективність).
Ц5 Створення унікального та привабливого геймплею (Творчий
аспект).
Ц6 Оптимізація ігрового процесу для цільових платформ (Технічний
аспект).
Ц7 Розробка ефективної маркетингової та PR-стратегії (Просування).
Ц8 Забезпечення високої оцінки користувачів (85%+ позитивних
відгуків) (Успіх).
Як видно з представленої системи, усі цілі перебувають у логічному
взаємозв’язку. Наприклад, досягнення цілей Ц3 і Ц5 напряму визначає якість
продукту, що впливає на виконання Ц8, а відтак і на загальний комерційний
результат (Ц1 та Ц2). Ціль Ц4 є критичною з погляду управління проєктним
трикутником, оскільки перевищення бюджету зменшує фінансову
результативність та ускладнює досягнення генеральної мети. Цілі Ц6 та Ц7
забезпечують відповідність сучасним ринковим вимогам - технічну стабільність
і видимість продукту серед конкурентів.
Оточення проєкту створення комп’ютерної гри являє собою багаторівневу
систему взаємодії внутрішніх і зовнішніх чинників, які безпосередньо або
опосередковано впливають на динаміку розробки, прийняття управлінських
рішень та кінцевий успіх продукту на ринку. На етапі ініціалізації та планування
проєкту важливим завданням є не лише визначення ключових зацікавлених
сторін, а й глибоке дослідження їхніх інтересів, очікувань і потенційного впливу
на результат. У контексті індустрії комп’ютерних ігор це набуває особливої
актуальності, оскільки ринок характеризується високою конкуренцією,
динамічними змінами технологій, залежністю від трендів цифрових розваг і
23
швидкою адаптацією нових інноваційних практик. Тому системний аналіз
оточення дозволяє не лише зменшити ризики, а й забезпечити передумови для
побудови ефективної стратегії управління проєктом [24].
Внутрішнє оточення охоплює ресурси, компетентності та технічні
можливості команди, організаційну структуру студії або продакшн-компанії, а
також специфіку обраного технологічного стека, включно з ігровим рушієм,
інструментами моделювання, засобами контролю версій та системами
управління задачами. До внутрішніх чинників також належать корпоративна
культура, ступінь комунікаційної взаємодії між учасниками, наявність
формальних процедур управління ризиками і змінами, а також досвід
розробників у релевантних технологічних напрямках. З огляду на особливості
індустрії, саме внутрішня синергія між технічною та творчою складовими є
критичною для досягнення високої якості ігрового продукту. Недостатній рівень
компетенції або неефективна організація роботи можуть призвести до зриву
термінів, збільшення бюджету та компромісів щодо змісту продукту, що прямо
пов’язано з концепцією проєктного трикутника [25].
Зовнішнє середовище проєкту є значно більш варіативним та охоплює
широкий спектр чинників: конкурентний ринок, економічну ситуацію, вимоги
платформ дистрибуції, регуляторні норми, тренди у геймдев-спільноті,
зворотний зв’язок користувачів, а також технологічні інновації, які формують
очікування гравців. Додатково важливими елементами зовнішнього оточення є
галузева екосистема партнерств - співпраця з видавцями, маркетинговими
агентствами, платформами монетизації, аналітичними сервісами, а також
взаємодія зі спільнотою через соціальні мережі, форуми та відкриті бета-
тестування. Усі ці чинники визначають ринкові бар’єри, формують економічні
обмеження та впливають на прийняття стратегічних рішень під час життєвого
циклу проєкту [26].
У межах проєктного менеджменту критично важливо ідентифікувати
стейкхолдерів - усі групи, особи або організації, які мають інтерес у реалізації та
результатах проєкту. Стейкхолдери відрізняються за рівнем впливу,
24
очікуваннями, інтересами, а також мірою ризику у разі невдачі. Їхнє правильне
картування (stakeholder mapping) дозволяє визначити стратегії взаємодії,
планування комунікацій та формування прозорої системи управління
взаємовідносинами впродовж усього проєктного циклу.
Однією з найважливіших сторін є інвестор або видавець, який забезпечує
фінансову підтримку та очікує отримання комерційного результату. Як правило,
видавець може впливати на ключові проєктні рішення, включно з термінами
релізу, пріоритетністю функціоналу та маркетинговою стратегією. Він також
забезпечує доступ до глобальних ринків, займається PR-підтримкою,
локалізацією, вибором каналів дистрибуції та визначенням цінової політики. Для
інвестиційних проєктів видавець є не тільки стороннім фінансовим партнером, а
фактично стратегічним учасником, який може суттєво вплинути на архітектуру
продукту чи масштаб його розробки.
Другим центральним стейкхолдером виступає замовник, тобто юридична
особа або продакшн-компанія, яка володіє правами на проєкт і несе
відповідальність за його реалізацію. Часто замовник може бути одночасно і
студією-розробником, однак у великих проєктах ці ролі розділяються. Замовник
формує концепцію продукту, визначає бізнес-цілі, а також приймає остаточні
рішення щодо стратегічного напряму розробки, балансу між інноваційністю та
економічною доцільністю.
На операційному рівні провідну роль відіграє керівник проєкту
(продюсер), який забезпечує інтеграцію всіх процесів, контролює виконання
плану, координує роботу команд і виступає посередником між творчою
частиною, технічною командою та управлінськими структурами. Він відповідає
за бюджетування, управління ризиками, комунікаційну політику, а також
ухвалення рішень у ситуаціях конфлікту інтересів чи обмеженості ресурсів. У
складних ігрових проєктах роль продюсера є системоутворювальною, оскільки
він забезпечує узгодженість між стратегічною метою та щоденною операційною
діяльністю.
25
Ключовою виробничою силою є команда проєкту, до якої входять гейм-
дизайнери, програмісти, художники, аніматори, спеціалісти зі звуку, наративні
дизайнери, технічні директори, тестувальники та інші фахівці. Гейм-дизайнер
формує логіку гри, механіки, правила взаємодії та елементи системи мотивації
гравця. Програмісти відповідають за створення ігрового функціоналу,
оптимізацію продуктивності, реалізацію фізики, штучного інтелекту та
інтеграцію всіх компонентів. Художники й аніматори забезпечують візуальну
складову, створюючи моделі, текстури, інтерфейс і кінематичні сцени.
Тестувальники проводять виявлення дефектів, забезпечують стабільність
продукту та підтверджують досягнення цілей якості. Ефективність роботи
команди визначає здатність проєкту залишатися в рамках планових термінів і
бюджету, а також безпосередньо впливає на остаточний рівень якості продукту.
Важливою групою стейкхолдерів є користувачі (гравці), оскільки саме
вони формують реальний попит і оцінюють фінальний продукт. На етапі
планування враховуються особливості цільової аудиторії: її вікові параметри,
ігрові вподобання, очікування щодо складності, стилістики та геймплейної
глибини. Під час розробки важливу роль відіграє користувацький зворотний
зв’язок, зокрема результати бета-тестування, огляди, відгуки в соціальних
мережах. Саме реакція користувачів визначає рівень конкурентоспроможності
гри та потенційний комерційний успіх.
До окремої групи стейкхолдерів належать платформи дистрибуції -
цифрові магазини, що виконують функцію посередників між розробником і
кінцевими споживачами. Вони визначають технічні вимоги, правила публікації,
політику комісій, а також впливають на видимість продукту через алгоритми
рекомендацій чи рекламні програми. Враховуючи домінування платформ на
ринку (таких як Steam, PlayStation Store чи App Store), їхній вплив на проєкт є
суттєвим і вимагає ретельного планування етапів релізу.
Зовнішнє конкурентне середовище також належить до стейкхолдерів, хоча
й опосередковано. Аналіз конкурентів дозволяє визначити оптимальну позицію
гри на ринку, оцінити переваги та недоліки аналогічних продуктів, а також
26
виявити ризики, пов’язані з перенасиченістю певних жанрів. Вивчення
конкурентного оточення сприяє прийняттю стратегічних рішень щодо змісту
гри, її унікальності, бізнес-моделі та маркетингової стратегії.
Висновки до розділу 1
У цілому проєкт створення комп’ютерної гри на основі проєктного підходу
постає як багатогранна діяльність, у якій креативні, технічні та організаційні
компоненти мають бути узгоджені в єдиній системі управління. Розгляд галузі
крізь призму життєвого циклу проєкту, «проєктного трикутника» обмежень,
SWOT- та PEST-аналізів, а також через визначення цілей, оточення та
стейкхолдерів показує, що успіх гри не зводиться лише до якості коду чи
візуальної складової. Вирішальними чинниками стають системне планування
змісту, часу й бюджету, адаптивне застосування гнучких методологій (Agile,
Scrum, Kanban), стратегічне врахування ринкових і макроекономічних умов, а
також побудова ефективної комунікації всередині мультидисциплінарної
команди та з ключовими зацікавленими сторонами. Саме інтеграція інструментів
проєктного менеджменту з особливостями геймдеву дає змогу перетворити ідею
гри на керований, прозорий та прогнозований процес, орієнтований одночасно
на комерційний результат, технологічну надійність і високу цінність ігрового
досвіду для кінцевого користувача.
27
РОЗДІЛ ІІ Галузі знань створення комп’ютерної гри на основі проєктного
підходу
2.1 Управління комунікаціями у проєкті
Комунікація — це основа проєктного менеджменту. Від того, наскільки
якісно вона налагоджена, залежить успіх проєкту, своєчасність рішень та
узгодженість роботи команди. У проєктах зі створення комп’ютерних ігор
значення комунікацій зростає багаторазово через міждисциплінарний характер
діяльності, що поєднує інженерні, художні, креативні та аналітичні складові.
Управління комунікаціями охоплює сукупність процесів планування,
організації, реалізації, контролю та коригування інформаційних потоків між
усіма учасниками проєкту, а також зовнішніми зацікавленими сторонами.
Основною метою цього управлінського напряму є забезпечення того, щоб
необхідна інформація була доставлена потрібним адресатам у потрібний час, у
зрозумілій формі та з відповідним рівнем деталізації [27].
Специфіка GameDev-проєктів полягає у постійній взаємодії фахівців з
кардинально різними професійними мовами, підходами до роботи та стилями
мислення. Програмісти орієнтуються на формальні технічні вимоги та
алгоритмічну логіку, художники - на візуальну мову, композицію та стиль,
геймдизайнери - на взаємодію механік, баланс та досвід користувача,
тестувальники - на пошук відхилень від очікуваної поведінки системи. У такому
середовищі комунікація виконує не лише інформаційну, але й інтеграційну
функцію, забезпечуючи єдність бачення продукту, узгодженість вимог та
зниження рівня конфліктності між підрозділами. Будь-яка помилка в передачі
вимог або затримка в обміні інформацією може призвести до значних втрат часу,
фінансових ресурсів і якості кінцевого продукту.
Процес управління комунікаціями у проєкті створення комп’ютерної гри
доцільно розглядати як безперервний цикл, що охоплює планування
комунікацій, управління обміном інформації та контроль ефективності
комунікаційних процесів. На етапі планування визначаються всі ключові
інформаційні потреби стейкхолдерів, канали передачі даних, частота звітності,
28
відповідальні особи та формати документування. У випадку GameDev-проєкту
до таких документів належать концепт-документ (Game Vision), дизайн-
документація (GDD), технічне завдання (TDD), арт-гайди, пайплайни
виробництва активів, звітність щодо стану білдів та результати тестування. План
комунікацій покликаний мінімізувати інформаційні розриви та забезпечити
прозорість усіх процесів [28].
Особливу роль в управлінні комунікаціями відіграє керівник проєкту або
продюсер, який виступає центральним вузлом інформаційної системи проєкту.
Саме він координує інформаційні потоки між замовником, інвесторами,
командою розробників та зовнішніми партнерами, забезпечує своєчасне
донесення рішень до виконавців та акумулює звітність про хід виконання робіт.
Неефективна комунікаційна політика керівника проєкту може призвести до
дезінтеграції команди, втрати контролю над термінами, зростання кількості
переробок і накопичення прихованих ризиків. Водночас прозора, структурована
і регулярна комунікація формує довіру між учасниками проєкту та підвищує
мотивацію персоналу [29].
У сучасних умовах управління комунікаціями тісно пов’язане з
використанням цифрових інструментів. До найпоширеніших засобів належать
системи управління завданнями та проєктами (Jira, Trello, Asana), корпоративні
месенджери (Slack, Discord, Microsoft Teams), системи контролю версій (Git), а
також спільні середовища зберігання даних (Google Drive, OneDrive, GitHub).
Дані інструменти не лише забезпечують миттєвий обмін інформацією, а й
формують єдине інформаційне середовище проєкту, в якому фіксуються всі
зміни, прийняті рішення, зауваження та результати виконаних робіт. Це
особливо важливо для забезпечення простежуваності управлінських рішень і
можливості ретроспективного аналізу [30].
Суттєву роль у процесі комунікацій відіграють регулярні наради та
синхронізаційні зустрічі. У рамках гнучких методологій управління проєктами,
таких як Scrum або Kanban, використовуються щоденні стендапи, спринт-рев’ю,
ретроспективи та планувальні сесії. Вони дозволяють забезпечити оперативний
29
обмін інформацією про стан завдань, виявляти вузькі місця на ранніх етапах та
своєчасно вносити корективи у план робіт. Для GameDev-проєктів такі зустрічі
також виконують функцію узгодження креативних рішень, що є критично
важливим при зміні геймплейних механік або стилістики візуального контенту
[31].
Окремим аспектом управління комунікаціями є документообіг і
стандартизація інформації. В умовах високої складності проєкту надзвичайно
важливо забезпечити єдині вимоги до оформлення технічної та дизайнерської
документації, протоколів зустрічей, звітів про помилки та змін у функціоналі.
Відсутність єдиних стандартів призводить до фрагментації інформації, втрати
контексту та труднощів у масштабуванні команди. Навпаки, чітко визначені
правила комунікації підвищують керованість проєкту та сприяють зниженню
транзакційних витрат на координацію.
Управління зовнішніми комунікаціями також має стратегічне значення для
проєкту створення гри. Сюди належать взаємодія з інвесторами, видавцями,
платформами дистрибуції, маркетинговими партнерами та спільнотою гравців.
Регулярна звітність перед інвесторами забезпечує фінансову прозорість і
підвищує рівень довіри, тоді як комунікація з платформами дистрибуції дозволяє
своєчасно адаптувати продукт до технічних вимог і умов розміщення. Взаємодія
з майбутніми користувачами через соціальні мережі, форуми та відкриті
тестування сприяє формуванню лояльної спільноти навколо продукту та дає
можливість отримувати ранній зворотний зв’язок [32].
Важливим елементом управління комунікаціями є також управління
конфліктами та інформаційними ризиками. У процесі розробки гри неминуче
виникають суперечності між творчими й технічними підходами, між бажаним
функціоналом і реальними ресурсними обмеженнями. Своєчасне виявлення
таких конфліктів та їх конструктивне вирішення можливе лише за умови
відкритої та довірчої комунікації. Інформаційні ризики, зокрема витік
конфіденційних даних, втрата проєктної інформації чи спотворення вимог,
30
потребують впровадження політики інформаційної безпеки, контролю доступу
до даних та резервного копіювання [33].
Планування комунікацій у проєкті створення комп’ютерної гри є
стратегічно важливим управлінським процесом, який безпосередньо впливає на
узгодженість дій усіх учасників, прозорість управлінських рішень і загальну
ефективність реалізації проєкту. У межах проєктного менеджменту планування
комунікацій розглядається як систематизований процес визначення того, яка
інформація, у якому обсязі, у якій формі, з якою періодичністю та через які
канали має передаватися між зацікавленими сторонами. Для GameDev-проєктів
цей процес набуває особливої складності через поєднання технічної, творчої,
бізнесової та маркетингової інформації, кожна з яких має власні вимоги до
точності, швидкості та форми подання.
Базовим етапом планування комунікацій є ідентифікація всіх ключових
зацікавлених сторін (stakeholders) та визначення їхніх інформаційних потреб.
Зацікавлені сторони у проєкті створення комп’ютерної гри утворюють
багаторівневу систему, у межах якої кожна група має власні цілі, очікування та
критерії успіху. Саме тому універсального підходу до інформування не існує:
ефективна комунікація повинна бути диференційованою та адаптованою до
специфіки кожної зацікавленої сторони.
Однією з ключових сторін є видавець, який зацікавлений у комерційній
ефективності проєкту та дотриманні договірних зобов’язань. Його інформаційні
потреби зосереджуються навколо стратегічних показників: дотримання
календарного плану, виконання бюджетних обмежень, рівень готовності
продукту, відповідність ринковим очікуванням та результати проміжного
тестування. Для видавця критично важливо отримувати регулярні звіти про
прогрес розробки, фінансову звітність, аналітику ризиків, а також
демонстраційні збірки гри (builds) для оцінювання поточного стану продукту.
Комунікація з видавцем, як правило, має формалізований характер, здійснюється
через офіційні звіти, презентації та контрольні наради.
31
Центральною фігурою в інформаційній системі проєкту виступає
продюсер або проєктний менеджер, який акумулює інформаційні потоки від усіх
підрозділів та транслює управлінські рішення у відповідні структурні одиниці.
Його інформаційні потреби мають найбільш комплексний характер і включають
оперативні дані про статус виконання завдань, наявність блокуючих факторів
(blockers), стан ризиків, рівень завантаженості команди, якість виконаних робіт
та відповідність запланованим показникам. Для забезпечення ефективного
управління продюсер має отримувати своєчасну, достовірну та деталізовану
інформацію як з технічної, так і з творчої частини проєкту. Від якості цієї
інформації безпосередньо залежить здатність керівника ухвалювати
обґрунтовані рішення щодо зміни пріоритетів, перерозподілу ресурсів і
коригування плану.
Безпосередніми виконавцями проєкту є члени команди розробки,
інформаційні потреби яких зосереджені на чітких вимогах до результатів роботи.
Для програмістів визначальною є наявність структурованих технічних
специфікацій, архітектурних схем, описів API та вимог до продуктивності. Для
художників і аніматорів критично важливими є арт-гайди, референси, технічні
обмеження рушія та вимоги до форматів графічних активів. Гейм-дизайнери
потребують доступу до єдиного, актуального Game Design Document (GDD),
який визначає правила гри, механіки, баланс, інтерфейс та користувацький
досвід. Команда повинна регулярно отримувати зворотний зв’язок щодо якості
своєї роботи, інформацію про зміни у вимогах та результати тестування.
Відсутність чітких і своєчасних комунікацій на цьому рівні призводить до
множинних переробок, втрати часу та зниження мотивації персоналу.
Окрему групу зацікавлених сторін становлять тестувальники (QA),
інформаційні потреби яких мають свою специфіку. Для ефективного виконання
своїх функцій вони повинні своєчасно отримувати нові збірки гри, списки змін
(change logs), інформацію про пріоритети функціоналу та критерії приймання. У
зворотному напрямі тестувальники передають детальні баг-репорти, результати
регресійного тестування, аналітику стабільності та рекомендації щодо
32
покращення геймплею й користувацького інтерфейсу. Ефективність комунікацій
між QA та іншими підрозділами прямо впливає на рівень якості та надійності
продукту.
Важливою зовнішньою зацікавленою стороною є ігрова спільнота, яка
виступає не лише кінцевим споживачем результату, але й активним учасником
інформаційного обміну. Для неї важливою є маркетингова інформація: анонси,
трейлери, демонстрації геймплею, публікації дорожніх карт розвитку, патчноути
та результати оновлень. Комунікація з ігровою спільнотою формує імідж
проєкту, рівень довіри до студії та очікування гравців. У сучасних умовах саме
через соціальні мережі, стримінгові платформи та тематичні форуми
відбувається активне формування громадської думки щодо продукту ще задовго
до його офіційного релізу.
Інформаційні потреби зацікавлених сторін суттєво змінюються залежно
від фази життєвого циклу проєкту, що зумовлює необхідність адаптивного
підходу до планування комунікацій. На етапі препродакшну (Pre-production)
основний акцент зроблено на інтенсивному обміні ідеями, формуванні спільного
бачення проєкту, узгодженні концепції, створенні технічного завдання та
розробці первинних прототипів. Комунікації на цьому етапі мають високий
рівень невизначеності, часто є усними, неформальними та спрямованими на
генерацію креативних рішень. Водночас саме на цьому етапі закладаються
фундаментальні вимоги до майбутнього продукту, тому надзвичайно важливим
є ретельне документування ключових рішень.
На етапі продакшну (Production) характер комунікацій змінюється у бік
формалізації та структурованості. Основу інформаційного обміну становлять
регулярні статусні звіти, оновлення щодо виконання завдань, баг-репорти, зміни
у GDD, технічні специфікації та аналітика освоєного обсягу робіт. Обмін
інформацією відбувається у чітко встановленому ритмі, відповідно до спринтів
або виробничих циклів. Основним завданням комунікацій на цьому етапі є
забезпечення синхронізації великої кількості паралельних процесів та
мінімізація ризиків відхилення від плану.
33
Етап постпродакшну та експлуатації (Post-production / LiveOps)
характеризується переорієнтацією інформаційних потоків на підтримку
продукту після релізу. У центрі комунікацій знаходяться оновлення,
виправлення помилок, аналіз поведінки гравців, планування та просування
додаткового контенту (DLC), подій та сезонних активностей. Значна увага
приділяється зворотному зв’язку від спільноти, аналітиці користувацьких даних
та управлінню репутацією продукту. Комунікації у цей період носять як
внутрішній характер (між командами підтримки), так і зовнішній - з гравцями,
платформами та медіа.
Комунікаційна програма проєкту створення комп’ютерної гри являє собою
цілісну систему взаємопов’язаних заходів, процедур та інструментів,
спрямованих на забезпечення ефективного обміну інформацією між усіма
учасниками проєкту та зовнішніми зацікавленими сторонами. В умовах високої
складності GameDev-проєктів, багатовекторності взаємодій та постійної
динаміки змін саме чітко структурована комунікаційна програма виступає
базовим фактором узгодженості дій, стабільності управлінських процесів та
своєчасного досягнення запланованих результатів. Відсутність системного
підходу до формування комунікаційної програми призводить до фрагментації
інформаційних потоків, дублювання завдань, зростання кількості помилок і, як
наслідок, до підвищення проєктних ризиків [34].
Планування комунікаційного процесу базується на низці
фундаментальних елементів, кожен з яких виконує окрему, але взаємозалежну
функцію в загальній системі управління інформаційними потоками.
Першочерговим елементом є визначення цілей комунікації, що передбачає чітке
формулювання того, яких управлінських, організаційних і соціально-
психологічних результатів необхідно досягти завдяки налагодженому
інформаційному обміну. До основних цілей належать забезпечення
однозначного розуміння завдань усіма учасниками, своєчасне інформування про
зміни у вимогах, підвищення рівня залученості персоналу до проєкту, підтримка
високого морального духу команди, формування довіри між підрозділами, а
34
також раннє виявлення потенційних ризиків і проблемних зон. У GameDev-
проєктах комунікація виконує не лише інструментальну, а й мотиваційну
функцію, оскільки креативний характер діяльності вимагає постійного обміну
ідеями та підтримки сприятливого психологічного клімату.
Наступним елементом є формування плану комунікацій, який виступає
формалізованим документом, що визначає правила та процедури
інформаційного обміну в межах проєкту. Такий план окреслює, хто, кому, у який
термін, у якому форматі та через які канали зобов’язаний передавати відповідну
інформацію. У рамках створення комп’ютерної гри план комунікацій включає
регламентацію щоденних, тижневих та етапних звітів, порядок проведення
нарад, процедури погодження змін у Game Design Document, правила роботи з
баг-трекінговими системами, а також норми комунікацій із зовнішніми
стейкхолдерами. Формалізація цих процесів сприяє підвищенню керованості
проєкту та зниженню суб’єктивного впливу людського фактору на критично
важливі інформаційні потоки.
Важливим складником комунікаційної програми є ідентифікація цільових
груп, що передбачає чітке визначення аудиторій, для яких призначена конкретна
інформація (Таблиця 2.1).
Таблиця 2.1
Цільові групи та їх інформаційні потреби
Цільова група Основні Приклади релевантної
інформаційні інформації
потреби
Управлінський контур Стратегічна, Бюджет, дедлайни,
(замовник, продюсер, фінансова та відхилення, результати
проєктний менеджер) контрольна виконання, якість
інформація продукту, статус
підрядників
35
Продовження таблиці 2.1
Технічний контур Технічна Архітектура, технічні
(програмісти, техліди) документація, вимоги, рішення, баг-трекінг,
специфікації зміни у вимогах, API-опис
Творчий контур Концептуальна та GDD, візуальні концепти,
(дизайнери, художники, креативна інформація ігрові механіки, елементи
геймдизайнери) стилю, level design
Маркетинговий контур Дані про Цільова аудиторія, бренд-
(маркетинг, PR) позиціонування та гайд, дорожня карта
просування релізу, промо-матеріали
Зовнішній контур Публічна та Анонси, трейлери, прес-
(гравці, ЗМІ, партнери) комунікаційна релізи, оновлення,
інформація ключові повідомлення
У межах одного GameDev-проєкту одночасно функціонують кілька
інформаційних контурів: управлінський, технічний, творчий, маркетинговий та
зовнішній. Кожен із цих контурів має власну цільову аудиторію, що
відрізняється рівнем компетенцій, глибиною залучення до процесів та
інтересами. Наприклад, технічна документація є критично важливою для
програмістів, однак не становить безпосередньої цінності для маркетингового
відділу, для якого ключовими є дані про позиціонування продукту, цільову
аудиторію та дорожню карту релізу. Чітке сегментування інформаційних потоків
дозволяє уникнути перевантаження учасників надмірною інформацією та
зменшити рівень інформаційного шуму.
Не менш вагомим елементом є вибір каналів комунікації, що визначає
технологічну та організаційну основу інформаційного обміну. У сучасних
умовах розробки ігор основну роль відіграють цифрові платформи: системи
управління завданнями (Jira, Trello, ClickUp), внутрішні комунікаційні сервіси
(Slack, Discord, Microsoft Teams), сховища документації (Confluence,
корпоративні Wiki), а також інструменти для демонстрації збірок і проведення
36
плейтестів. Вибір каналів повинен відповідати характеру інформації, швидкості
її оновлення, рівню формалізації та кількості учасників, залучених до обміну.
Наприклад, оперативні питання доцільно вирішувати через внутрішні чати, тоді
як стратегічні рішення мають бути зафіксовані в офіційній документації.
Цілі комунікаційної програми в GameDev-проєктах мають комплексний
характер і охоплюють як організаційно-управлінські, так і соціально-
психологічні аспекти. Однією з базових цілей є створення прозорих
інформаційних каналів, що передбачає відкритий доступ до актуальних версій
GDD, технічних вимог, виробничих графіків та планів спринтів. Прозорість
інформації сприяє формуванню довіри між учасниками проєкту, зменшенню
кількості помилок та підвищенню відповідальності за виконання поставлених
завдань.
Іншою важливою ціллю є координація завдань між підрозділами, яка
забезпечує узгодженість дій різних спеціалістів та запобігає асинхронності
виробничих процесів. У GameDev-проєктах тісна залежність між
програмуванням, створенням графічних активів та дизайном геймплею вимагає
постійної синхронізації. Наприклад, художники не повинні створювати графічні
ресурси для механік, реалізація яких ще не затверджена або перебуває на ранній
стадії програмування. Таким чином, комунікаційна програма виконує роль
інтегратора виробничих процесів.
Важливою стратегічною ціллю є також раціоналізація інформаційних
потоків, що передбачає мінімізацію інформаційного перевантаження та втрат
знань. Для цього ключові управлінські та технічні рішення мають
документуватися у централізованих сховищах знань, таких як корпоративні Wiki
або Confluence. Це забезпечує спадковість інформації, зменшує залежність
проєкту від окремих фахівців і спрощує процес адаптації нових учасників
команди.
Планування комунікацій у проєкті створення комп’ютерної гри, як
правило, відображається у вигляді узагальненого плану та деталізованих таблиць
каналів комунікацій (Таблиця 2.2), що забезпечують як стратегічне, так і
37
операційне управління інформаційними потоками. Загальний план комунікацій
структурований за основними фазами життєвого циклу GameDev-проєкту, кожна
з яких характеризується власними завданнями, інтенсивністю інформаційного
обміну та домінуючими каналами взаємодії.
Таблиця 2.2
Комунікацій у GameDev-проєкті
Етап проєкту Суть комунікацій Основні канали Мета
Setup Узгодження Наради, Формування
(Настроювання) концепції, брейншторми, спільного
формування GDD, презентації, бачення та
планів і технічних обговорення єдиного
рішень; висока бюджету та інформаційного
інтенсивність графіка. поля.
стратегічних
обговорень.
Core Production Регулярний Спринт- Забезпечення
(Основна ітеративний обмін планування, стабільного
розробка) інформацією в стендапи, рев’ю, виробничого
рамках ретроспективи, процесу та
Agile/Scrum, баг-трекінг. контролю
документування та виконання.
контроль завдань.
Launch (Запуск) Пік комунікаційної Внутрішні: Успішний вихід
активності; акцент координація гри на ринок та
на реліз, маркетинг релізу, активізація
і роботу з тестування. інтересу
аудиторією. трейлери, прес- аудиторії.
релізи, ЗМІ,
інфлюенсери.
38
На етапі настроювання (Setup) комунікація орієнтована насамперед на
узгодження концептуальних і стратегічних основ проєкту. У цей період
відбувається активний обмін інформацією щодо бачення гри, формування GDD,
розробки бюджету, календарного плану, технічних рішень та вибору ігрового
рушія. Комунікації мають високий рівень інтенсивності, переважають
стратегічні наради, брейншторми, презентації концепцій та прототипів.
Основною метою цього етапу є формування єдиного інформаційного поля та
спільного розуміння цілей проєкту.
Фаза основної розробки (Core Production) характеризується переходом до
систематизованого, ітеративного обміну інформацією відповідно до методологій
Agile або Scrum. Комунікації фокусуються на плануванні спринтів, щоденних
стендап-мітингах, оглядах результатів (Sprint Review) та ретроспективах. Саме
на цьому етапі формується основний обсяг технічної та творчої документації,
ведеться баг-трекінг, фіксуються зміни у вимогах і здійснюється контроль
виконання завдань. Комунікації стають більш формалізованими та
орієнтованими на забезпечення стабільного виробничого процесу.
На етапі запуску (Launch) комунікації зміщуються у бік маркетингу, PR та
взаємодії зі спільнотою. Внутрішні канали зосереджуються на координації
релізних процесів, фінальному тестуванні та підготовці оновлень, тоді як
зовнішні канали використовуються для розповсюдження трейлерів, прес-релізів,
анонсів, взаємодії зі ЗМІ та інфлюенсерами. Комунікаційна активність на цьому
етапі досягає пікового рівня, оскільки саме від її ефективності значною мірою
залежить успішність виходу продукту на ринок.
Деталізація каналів комунікацій передбачає розподіл інструментів за
внутрішніми та зовнішніми напрямами взаємодії. Внутрішні канали, орієнтовані
на команду розробки, включають щоденні стендап-мітинги для оперативного
узгодження, регулярні демонстрації ігрових збірок (Playtests, Show & Tell) для
отримання прямого зворотного зв’язку від команди, а також використання
систем управління завданнями (Jira) для контролю статусу робіт і баг-репортів.
39
Такі канали забезпечують безперервність інформаційного обміну та високу
швидкість реагування на зміни.
Зовнішні канали комунікації спрямовані на взаємодію з видавцем,
інвесторами та ігровою спільнотою. Для видавця використовуються регулярні
аналітичні звіти-дайджести, фінансова звітність, демонстрації білдів і
презентації прогресу. Для спільноти основними каналами виступають соціальні
мережі, Discord, Reddit, стримінгові платформи, а також офіційні вебресурси
проєкту. Прес-релізи, трейлери та маркетингові кампанії формують зовнішній
інформаційний образ продукту та забезпечують його ринкове позиціонування.
Узагальнюючи, можна стверджувати, що комунікаційна програма проєкту
створення комп’ютерної гри є складною, багаторівневою та адаптивною
системою, яка інтегрує стратегічне планування, операційне управління та
маркетингові комунікації. Її ефективність визначається не лише кількістю
використаних каналів, а насамперед рівнем узгодженості інформаційних
потоків, чіткістю регламентів та здатністю оперативно реагувати на зміни у
внутрішньому й зовнішньому середовищі проєкту.
2.2 Визначення та контроль змісту проєкту
Управління змістом у геймдеві насамперед означає необхідність
систематизувати величезний обсяг ідей, механік, систем та вимог, які
накопичуються ще на початкових етапах проєкту. У геймдеві завжди багато
ентузіазму, багато творчості, але саме тому управління змістом (Scope
Management) стає ключовим процесом, що дозволяє запобігти хаотичному
розширенню проєкту та забезпечити, щоб кінцевий продукт містив лише ті
компоненти, які дійсно необхідні для досягнення очікуваного результату. У
цьому контексті управління змістом виступає водночас аналітичною,
організаційною та комунікаційною функцією, оскільки воно структурує бачення
всієї команди, фіксує межі проєкту і визначає ступінь необхідності кожної фічі,
кожного елементу дизайну і кожного технічного рішення [33].
У процес розробки гри залучені різні спеціалісти - геймдизайнери,
програмісти, художники, тестувальники, продюсери. Кожен із них має певне
40
бачення майбутнього продукту, і саме тому етап ініціалізації змісту (scope
initiation) є фундаментальним. Він передбачає затвердження початкової
концепції гри та формування технічного завдання (ТЗ), у якому визначаються
базові параметри майбутнього продукту: жанрові характеристики, цільова
платформа, ключові механіки, вимоги до продуктивності, орієнтація на певну
аудиторію. У цьому етапі важливо забезпечити спільне розуміння між
зацікавленими сторонами (stakeholders), адже саме концепція та ТЗ виступають
еталоном, з яким порівнюватимуться всі наступні рішення щодо включення або
виключення функціональності [34].
Наступним етапом постає планування змісту, що традиційно у геймдеві
виражається через створення Game Design Document (GDD) - одного з
найцентральніших артефактів у всьому проєктному циклі. GDD є не лише
описом гри, а й інструментом комунікації, що фіксує всі ігрові системи, логіку їх
взаємодії, структуру рівнів, баланс, економіку гри, поведінку штучного
інтелекту, стилістичні особливості, правила візуального представлення,
механіки керування, опис інтерфейсів та супутні технічні обмеження. Саме
завдяки GDD команда отримує можливість працювати скоординовано, а
продюсер - контролювати відповідність реалізованих фіч початковому задуму.
При цьому важливо, що GDD не є статичним документом: він оновлюється в
міру розробки, але будь-які зміни мають проходити через процедуру контролю
змісту (scope control), щоб уникнути неконтрольованого зростання кількості
задач [35].
Зміст проєкту деталізується через процес визначення та декомпозиції
робіт. На цьому етапі формується WBS (Work Breakdown Structure) - ієрархічна
структура робіт, яка розкладає складні елементи гри на дрібніші та зрозуміліші
компоненти. Зазвичай WBS у розробці ігор будується за функціональною
логікою. Наприклад, окремо виділяються такі великі блоки як Core Gameplay
(основні механіки), Physics/Interaction (система взаємодії з об’єктами), AI
Systems (поведінка персонажів), UI/UX (інтерфейс та користувацький досвід),
Art Assets (моделі, анімації, текстури), Audio (музичне оформлення, звукові
41
ефекти), Networking (для онлайн-ігор), а також окремо технічні модулі на кшталт
збереження прогресу або оптимізації. Усередині кожного такого компонента
відбувається подальша декомпозиція - аж до рівня окремих задач, наприклад:
«Реалізувати анімацію атаки мечем», «Налаштувати систему колізій для
персонажа», «Створити прототип інвентаря», «Розробити UI-панель для
характеристик гравця» тощо. Важливо, що WBS, яка буде представлена у
Таблиці 2.3, дозволяє структурувати зміст не тільки за логікою процесів, але й
відповідно до етапів життєвого циклу.
Таблиця 2.3
Функціональна WBS структура проєкту
Проєкт створення комп’ютерної
гри
Передпроєктна аналітика
Аналіз ринку ігрової індустрії
Аналіз цільової аудиторії
Формування концепції гри
Оцінка технічної реалізовності
Попередня оцінка бюджету та
ресурсів
Робота з проєктною
документацією
Розробка та узгодження GDD
Розробка TDD
Планування робіт та складання
WBS
Розподіл ресурсів і
відповідальностей
Дизайн гри
Концепт-арт персонажів та світу
UX/UI дизайн інтерфейсу
Створення 2D/3D моделей
Анімації та візуальні ефекти
Розробка гри
Імплементація логіки персонажів і AI
Інтеграція графіки та анімацій
Побудова рівнів та внутрішнього
контенту
Оптимізація продуктивності
Тестування та стабілізація
Функціональне тестування
Playtesting
42
Продовження таблиці 2.3
Bug fixing
Підготовка релізної збірки
Маркетинг і запуск
Підготовка трейлерів і промо-
матеріалів
SMM та робота зі спільнотою
PR та співпраця зі
ЗМІ/інфлюенсерами
Підготовка до релізу та публікація
гри
Після побудови WBS команда переходить до календарного планування.
Тут у геймдеві зазвичай застосовується ітеративно-інкрементальний підхід,
орієнтований на гнучкі методології (Scrum, Kanban). Sprint Planning дозволяє
вибрати зі сформованого WBS ті задачі, які будуть виконані в найближчій
ітерації, сформувати Sprint Backlog та оцінити завантаження команди. Для
візуалізації використовується або Діаграма Ганта (більш характерна для
продюсерського та менеджерського контролю), або Kanban-дошка, яка дозволяє
в реальному часі відстежувати статус кожної задачі (To Do, In Progress, Code
Review, Testing, Done). У процесі розробки важливо враховувати залежності між
задачами: наприклад, неможливо тестувати логіку ШІ, якщо основний механізм
пересування ще не реалізований; або неможливо приступати до створення
фінальних 3D-моделей, якщо стиль та пропорції персонажів ще не затверджені.
Важливою частиною управління змістом є процедура верифікації –
перевірка того, наскільки готові фічі відповідають визначеним вимогам. Це
включає формальне приймання робіт, тестування функціональності, перевірку
відповідності GDD та технічним умовам. Прийомка може здійснюватися як на
рівні продюсера, так і на рівні ліда відповідної команди (геймдизайну,
програмування чи художнього відділу). Якщо фіча не відповідає вимогам або не
реалізує цінність для фінального продукту, вона повертається на
доопрацювання, а в деяких випадках – взагалі видаляється з переліку функцій
релізу.
43
Окремої уваги заслуговує контроль змін змісту, оскільки саме він
забезпечує стабільність проєкту. Запити на нові фічі (Feature Requests) можуть
надходити з різних джерел: від геймдизайн-команди, з результатів playtest-сесій,
від інвестора або продюсера, а інколи – від команди QA, яка помічає можливості
покращення. Проте кожен такий запит повинен пройти аналіз впливу на бюджет,
строки, ризики та якість гри. Зазвичай це відбувається через Change Control Board
(CCB) або внутрішню процедуру узгодження між продюсером, геймдизайнером
та технічним директором. Метою цього процесу є мінімізація Scope Creep –
неконтрольованого розростання гри, яке може призвести до збільшення витрат,
зриву термінів і втрати фокусування на основній ідеї [36].
2.3 Управління ресурсами у проєкті
Коли переходиш до питання управління ресурсами у проєкті створення
комп’ютерної гри, поступово усвідомлюєш, що саме ця складова проєктного
менеджменту визначає реалістичність усіх інших планів – від графіку релізу до
очікуваної якості продукту. Геймдев-проєкти зазвичай мають високу
інтенсивність використання ресурсів, значну кількість взаємозалежних задач і
команду спеціалістів, чия експертиза є критичною для успіху. Тому управління
ресурсами постає не просто технічною процедурою розподілу коштів чи
обладнання, а комплексним процесом планування, залучення, розвитку та
контролю всього, що робить можливим створення гри – людського потенціалу,
фінансових можливостей, технічної бази, програмних інструментів і зовнішніх
сервісів.
У GameDev управління ресурсами традиційно починається з визначення
потреб проєкту відповідно до його масштабу, жанрового напрямку та
технологічної складності. Наприклад, гра у жанрі 3D Action з розгалуженою
анімацією та складною фізикою вимагатиме потужних графічних станцій,
ліцензій на професійне програмне забезпечення, значно більшої кількості
художників, аніматорів та технічних спеціалістів у порівнянні з 2D-проєктом.
Уже на етапі ініціалізації формується базова оцінка потреб у ресурсах, яка потім
уточнюється при розробці WBS та календарного плану. Важливо, що у геймдеві
44
ресурсне планування прив’язане не тільки до фінансів та обладнання, але й до
конкретних компетенцій команди, тому стратегічно важливим стає питання
формування кадрового складу.
Людські ресурси є центральним елементом у структурі GameDev-проєкту,
оскільки саме від професійності, швидкості і здатності до творчого вирішення
завдань залежить темп розробки. Команда зазвичай включає геймдизайнера,
який визначає концепцію та ігрові механіки; програмістів різних спеціалізацій
(Backend, Frontend, Gameplay, AI); художників та 3D-моделерів; звукорежисера;
QA-тестувальників; а в більших проєктах – також продюсера, проектного
менеджера, аналітика, аніматора та спеціаліста з UI/UX. У Таблиці 2.4 наведено
оновлений перелік трудових ресурсів із зазначенням ставок за робочу та
понаднормову годину, що дозволяє оцінити загальну вартість утримання
команди та спрогнозувати додаткові витрати при розширенні графіку або
додаванні нових фахівців.
Таблиця 2.4
Трудові ресурси проєкту
№ Назва ресурсу Ставка за 1 Понаднормова
робочу годину, ставка, грн
грн
1 Менеджер 100 120
2 Бекенд- 75 90
розробник
3 Фронтенд- 80 96
розробник
4 Тестувальник 50 60
5 Дизайнер 65 78
6 SEO- 40 48
копірайтер
7 Маркетолог 50 60
45
Висока спеціалізація ролей є характерною для індустрії, тому правильний
підбір виконавців безпосередньо впливає на якість реалізації ключових механік
гри.
Матеріально-технічні ресурси охоплюють усе обладнання та програмні
продукти, які використовуються під час розробки. Це можуть бути робочі станції
з високопродуктивними GPU, професійні монітори з високою частотою
оновлення, VR-шоломи (для VR-проєктів), графічні планшети для художників,
сервери для тестування мультиплеєрної частини, а також різні інструменти
розробки. Зокрема, широке застосування мають ліцензії на ігрові рушії (Unity,
Unreal Engine), програмне забезпечення для 3D-моделювання, пакети для
анімацій, інструменти для роботи зі звуком, а також засоби контролю версій.
Окремо важливо розуміти, що у GameDev велике значення має не тільки
наявність ресурсів, а й ефективність їх використання. Саме тому планування
трудових ресурсів прив’язується до структури робіт WBS. Таблиця 2.5
відображає трудозатрати у годинах для кожної ролі та для кожної задачі, що
дозволяє точно визначати навантаження на фахівців.
Таблиця 2.5
Використання трудових ресурсів
Назва ресурсу / роботи Трудозатрати, годин
Менеджер 776
Аналіз середовища (по Україні) 80
Аналіз ринку 160
ТЕО 80
Комерційний аналіз 40
Оренда та облаштування офісу 40
Закупівля обладнання та техніки 40
Написання ТЗ 80
Планування робіт 40
Затвердження ТЗ 16
46
Продовження таблиці 2.5
Розподіл ресурсів 40
Підготовка до запуску гри 160
Бекенд-розробник 1 480
Написання ТЗ 80
Імплементація бізнес-логіки 560
Реалізація логіки додатку 720
Bug fixing 120
Фронтенд-розробник 800
Написання ТЗ 80
Розробка UI/UX прототипів (landing) 120
Розробка UI/UX контентних екранів 480
Bug fixing 120
Тестувальник 160
Тестування 160
2D/UX-дизайнер 336
Написання ТЗ 80
Розробка PSD-шаблонів UI (landing) 96
Розробка PSD-шаблонів UI (content) 160
SEO-копірайтер 80
SEO-оптимізація 80
Маркетолог 480
Написання ТЗ 80
Брендінг 40
Неймінг 40
SMM 80
Таргетинг 40
Контекстна реклама 40
Підготовка до запуску 160
47
Наприклад, програмування системи інвентарю може вимагати 60 годин від
Backend-програміста та 20 годин від UI/UX-дизайнера, тоді як створення
моделей персонажів потребуватиме 120 годин роботи 3D-художника і ще 50
годин від аніматора. Така деталізація забезпечує можливість перерозподілу
навантаження, своєчасного залучення додаткових спеціалістів або корекції
графіку проєкту.
Управління фінансовими ресурсами нерозривно пов’язане з плануванням
матеріальних та трудових витрат. Бюджет гри формується з урахуванням усіх
витрат на зарплати, ліцензії, обладнання, оплату зовнішніх сервісів (наприклад,
хмарні сервери), маркетинг, локалізацію, тестування. У геймдеві часто виникає
потреба у закупівлі додаткових програмних інструментів, а іноді й компонентів
зовнішніх пакетів, таких як анімаційні бібліотеки або авторські звукові ефекти.
Менеджер проєкту повинен контролювати ці витрати впродовж усього
життєвого циклу, запобігаючи перевищенню бюджету та забезпечуючи
ефективне використання наявних коштів.
Управління технічними ресурсами - окрема сфера, що потребує
системності. Особливу увагу приділяють контролю за ліцензіями, оновленнями
програмного забезпечення, резервним копіюванням даних, роботою серверів і
стабільністю інструментів, що використовуються командою. Нерідко
трапляється ситуація, коли внаслідок оновлення рушія або програмного
забезпечення певні компоненти починають працювати некоректно, що може
призвести до затримки розробки. Тому частиною управління ресурсами є також
технічна підтримка, своєчасне тестування оновлень і створення внутрішньої
інфраструктури, яка дозволяє команді працювати безперервно й злагоджено.
Значне місце займає і контроль використання ресурсів. Він включає регулярний
моніторинг виконання планових трудозатрат, перевірку відповідності фактичних
витрат запланованим у бюджеті, ревізію технічних засобів і оцінку ефективності
команди. Важливо враховувати, що у GameDev продуктивність спеціалістів
може змінюватися залежно від складності задачі, періоду розробки, доступності
інструментів і навіть креативного навантаження. Тому в процесі контролю
48
менеджер повинен не просто фіксувати відхилення, а й аналізувати їх причини,
коригувати графік або перерозподіляти ресурси між командами.
2.4 Управління часом у проєкті
Якщо говорити про тайм-менеджмент у розробці ігор, то саме від того, як
організовується час, залежить все: від темпу створення окремих фіч до здатності
проєкту вийти на реліз без авралів, зберігаючи при цьому базові ідеї. У GameDev
час набуває не просто календарного виміру - це динамічний, змінний і часто
нестабільний ресурс, який потребує точного планування, постійного контролю
та грамотної систематизації. Розробка гри включає в себе десятки, а інколи й
сотні процесів, кожен із яких має власні залежності, часову тривалість і
складність. Через це управління часом стає комплексною дисципліною, що
охоплює декомпозицію фіч, встановлення логічних послідовностей робіт, оцінку
тривалості завдань, створення спринтів, побудову календарних діаграм та
моніторинг фактичного прогресу.
Початком управління часом є визначення переліку завдань, що формують
зміст гри. Ігрові фічі - це не лише великі системи на кшталт інвентарю, бойової
механіки або діалогової системи. Це також дрібні, але критично важливі
компоненти: анімації атаки, логіка відкривання дверей, скрипти взаємодії з NPC,
поведінкові патерни ШІ, UI-панелі, VFX-ефекти, оптимізаційні патчі. На
початковому етапі ці фічі ідентифікуються та перетворюються на список робіт.
Далі проводиться декомпозиція - розбиття кожного завдання на дрібніші
частини, з якими команда може працювати ефективно. Наприклад, фіча «Бойова
система» може містити підзадачі: створення комбо-анімацій, розробка системи
виявлення попадань, налаштування колізійних зон, інтеграція звукових ефектів,
написання скриптів логіки бою, відлагодження AI-супротивників. Така
деталізація дозволяє не лише бачити реальну складність роботи, а й
прогнозувати часові витрати [37].
Важливо, що після формування переліку задач необхідно встановити
залежності між ними. Більшість процесів у геймдеві не є автономними:
тестування можливе лише після завершення кодування, анімація - після
49
моделювання персонажа, інтеграція інтерфейсу - після створення UX-макетів.
Встановлення залежностей дозволяє побудувати логічну послідовність та
визначити, які завдання можуть виконуватися паралельно, а які є
взаємозалежними. Це суттєво впливає на структуру календарного плану та
забезпечує реалістичність спринтів.
Оцінювання тривалості робіт є одним із найскладніших етапів, оскільки у
GameDev передбачити точний час виконання задач буває вкрай непросто.
Причин цьому кілька: креативний характер завдань, можливість технічних
ускладнень, непередбачуваність поведінки інструментів (наприклад, оновлення
рушія може зламати частину логіки), а також необхідність постійного внесення
змін на основі тестування. Проте менеджери використовують як експертні
оцінки, так і емпіричні методи, спираючись на досвід попередніх ітерацій,
середні показники продуктивності фахівців, складність фічі та кількість
можливих ризиків. Важливим інструментом на цьому етапі є Спринт-
планування, під час якого обираються задачі на найближчу ітерацію, оцінюється
їхня тривалість і доступність ресурсів [38].
Для оптимізації пріоритетів у межах спринтів застосовується Матриця
Ейзенхауера. Вона дозволяє класифікувати завдання залежно від їх терміновості
та важливості, що є особливо корисним у геймдеві, де більшість задач можуть
виглядати важливими, але не всі впливають на фінальний продукт однаковою
мірою. Наприклад, критичні баги належать до категорії “термінові або важливі”
та мають бути виконані негайно, оскільки вони блокують роботу інших членів
команди або унеможливлюють продовження розробки. Натомість додаткові
графічні ефекти, декоративні елементи або косметичні UI-покращення належать
до “нетермінових або неважливих”, тому можуть бути відкладені до пізніших
ітерацій без шкоди для проєкту. Матриця допомагає ПМ або продюсеру уникати
ситуацій, коли команда витрачає час на завдання низького пріоритету,
втрачаючи контроль над ключовими фічами.
Після встановлення залежностей і пріоритетів переходять до побудови
календарного плану та визначення тривалості проєкту. Одним із найбільш
50
ефективних методів є Метод критичного шляху (Critical Path Method - CPM). Він
дозволяє виявити ті задачі, затримка яких автоматично затримує весь проєкт.
Наприклад, у грі з власним ігровим рушієм розробка його базових систем
(фізика, рендеринг, система анімацій) потрапляє до критичного шляху; у
проектах на готових рушіях - такими задачами можуть бути інтеграція
персонажів, реалізація головних механік або створення ключових рівнів.
Важливо, що задачі, які не входять до критичного шляху, мають певний запас
часу, що дозволяє гнучко розподіляти ресурси, не ризикуючи зривом проєкту
[39].
Візуалізація всього цього процесу традиційно здійснюється за допомогою
Розширеної Діаграми Ганта, яка демонструє не лише часові рамки задач, а й
залежності, паралельні гілки, критичний шлях і точки контролю (milestones). Для
SCRUM-команд часто використовується також Burndown Chart - графік
згоряння, що відображає фактичну швидкість виконання задач у спринті
порівняно з плановою. Він дозволяє виявляти затримки, прогнозувати
завершення ітерації й оптимізовувати обсяг роботи. Старші продюсери та ПМ
часто використовують обидва інструменти: Гант для глобального менеджменту
проєкту та Burndown - для щоденного внутрішнього контролю [40].
Завершальною частиною управління часом є контроль прогресу. Він
охоплює щоденні стендапи, аналіз виконаних завдань (velocity), ревізію
спринтів, контроль критичного шляху, а також формування звітів щодо
відхилення від плану. ПМ або продюсер має постійно зіставляти заплановані
оцінки з фактичними показниками, коригувати графік, перерозподіляти задачі
або змінювати пріоритети. У геймдеві це особливо важливо, оскільки невеликі
затримки на ранніх етапах (наприклад, у створенні прототипу бою) здатні
призвести до значних відставань пізніше, коли розробка вступає в етап інтеграції
компонентів [41].
2.5 Управління вартістю у проєкті
Керування вартістю в розробці ігор - це фундамент реалістичності. Навіть
сильна ідея та найкращий рушій не допоможуть: якщо бюджет не продуманий,
51
проєкт просто не доживе до фінального релізу. Вартість у GameDev - це не
абстрактний показник, а жива, змінна величина, що охоплює десятки статей
витрат, залежностей, резервів і ризиків. Саме тому управління вартістю
розглядається як комплексний набір процесів, який включає планування,
складання кошторисів, розробку бюджету та контроль виконання фінансової
частини проєкту. Це дозволяє забезпечити завершення гри в рамках
затвердженого фінансування, зберегти стабільність проєкту та уникнути
сценарію, коли гроші закінчуються раніше, ніж завершено ключові фічі.
Першим кроком у процесі управління вартістю є детальне планування
витрат. На цьому етапі формується набір локальних кошторисів, які охоплюють
всі ключові напрямки фінансування. В GameDev зазвичай виділяють такі основні
категорії: оплата праці, ліцензії та обладнання, маркетинг, операційні витрати та
резерви на ризики. Формування цих кошторисів потребує залучення керівників
команд (лідів), продюсера, головного бухгалтера або фінансового менеджера,
оскільки кожен із них має власне розуміння структури витрат у своїй сфері
відповідальності. При цьому менеджер проєкту аналізує як фактичні потреби,
так і потенційні ризики, що можуть вплинути на бюджет - це дозволяє створити
гнучку, але достатньо жорстку фінансову модель [42].
Однією з основних статей витрат є оплата праці, що є цілком очікуваним
для GameDev, адже саме фахівці формують «серце» гри. Таблиця 2.6 містить
«Локальний кошторис оплати праці», у якому зазначено не лише ставки за
годину кожного спеціаліста (наприклад, Геймдизайнера, 3D-моделера,
Аніматора, Level-дизайнера, Backend-програміста), а й загальну кількість годин,
необхідних на виконання задач відповідно до WBS та спринт-планів [43].
Таблиця 2.6
Локальний кошторис оплати праці
№ Трудозатрати (роль у Орієнтовна вартість,
проєкті) грн
1 Проєктний менеджер (PM) 148 000
52
Продовження таблиці 2.6
2 Геймдизайнер / Lead Designer 96 000
3 Програміст Gameplay (Unity/Unreal) 132 000
4 Бекенд-розробник (API, сервіси, інтеграції) 118 000
5 Фронтенд / UI Developer (інтерфейси гри) 72 000
6 3D/2D художник-моделер 54 000
7 Тестувальник (QA) 14 000
8 Маркетолог (SMM + комʼюніті 31 000
менеджмент)
9 Копірайтер / сценарист (лори, діалоги, 9 000
описи)
10 Резерв фонду оплати (overtime, премії, 70 000
ризики)
Усього: 744 000
грн
Цей підхід дозволяє отримати реалістичну оцінку трудозатрат. Важливим
елементом є резерв на овертайми - геймдев-проєкти часто стикаються з
періодами пікового навантаження, особливо ближче до релізу, тому
передбачений фінансовий резерв дозволяє уникнути перевищення бюджету у
моменти інтенсивної розробки [44].
Не менш важливу роль відіграють матеріально-технічні ресурси. Таблиці
2.7 , 2.8 та 2.9 деталізують вартість ліцензій, приміщення, обладнання та
маркетингових активностей.
Таблиця 2.7
Локальний кошторис оплати приміщення
№ Стаття витрат Вартість (грн за 11 місяців)
53
Продовження таблиці 2.7
1 Комунальні платежі (електроенергія, 22 000
опалення, інтернет)
2 Оренда офісного приміщення 110 000
3 Резерв (непередбачені витрати, ремонт, 12 000
збільшення тарифів)
Усього: 144 000
грн
Таблиця 2.8
Локальний кошторис оплати обладнання та меблів
№ Обладнання / меблі Кількість Орієнтовна
вартість (грн)
1 Робочі комп’ютери / 5 145 000
ноутбуки для GameDev (5
шт.)
2 Периферія та 5 12 500
комунікаційне обладнання комплектів
(мікрофони, навушники,
клавіатури, миші,
маршрутизатор)
3 Офісні столи 3 12 600
4 Ергономічні офісні 6 15 000
крісла
5 Резерв 18 000
(обслуговування, заміна,
UPS, дрібні покупки)
Усього: 203 100 грн
54
Таблиця 2.9
Локальний кошторис маркетингових витрат
№ Вид маркетингової Орієнтовна вартість
діяльності (грн)
1 SMM 6 000
2 Таргетована реклама 10 000
3 Контекстна реклама 7 500
4 Маркетинг перед запуском 22 000
5 Резерв 4 000
Усього: 49 500 грн
Серед витрат на ліцензії можуть бути: підписка на Unreal Engine (для
комерційних релізів), преміум-версії Unity, ліцензії на програмне забезпечення
для 3D-моделювання (3ds Max, Maya), інструменти для анімації, аудіоредактори
(FMOD, Wwise), а також пакети візуальних ефектів чи сторонніх скриптів зі
спеціалізованих маркетплейсів (Unity Asset Store, Unreal Marketplace). Закупівля
обладнання охоплює придбання робочих станцій з високопродуктивними GPU,
професійних моніторів, графічних планшетів, серверів для
багатокористувацьких ігор та резервних систем зберігання. Витрати на
маркетинг, як правило, включають створення трейлерів, участь у виставках
(Gamescom, DevGAMM), рекламу у соціальних мережах, PR-кампанії,
локалізацію та роботу з інфлюенсерами. Саме ці витрати часто недооцінюються
на ранніх етапах, але у сучасному GameDev маркетинг впливає на успіх гри після
релізу [45].
Для кращої орієнтації в динаміці витрат використовується Діаграма
трудозатрат. Вона демонструє розподіл робочого часу команди протягом усього
періоду розробки та показує, на яких етапах виникає найбільше навантаження.
Наприклад, художники можуть мати пік роботи у фазі створення активів,
програмісти - на етапі інтеграції систем, а QA-команда - наприкінці проєкту,
55
коли відбувається активне тестування. Ця діаграма допомагає прогнозувати
фінансові витрати, оскільки трудозатрати прямо корелюють зі збільшенням
вартості оплати праці [46].
Після складання локальних кошторисів формується зведений кошторис,
представлений у Таблиці 2.10 .
Таблиця 2.10
Зведений кошторис
№ Найменування Вартість (грн.)
1 Трудозатрати 744 000
2 Матеріальні затрати 144 000
3 Обладнання та меблі 203 100
4 Маркетинг 49 500
Всього 1 140 600
Він об’єднує всі витрати за статтями та дозволяє визначити загальну вартість
проєкту. Наприклад, типовий середній GameDev-проєкт може мати бюджет у
межах $500 000, хоча це значення значно різниться залежно від масштабу,
платформи та складності гри. Зведений кошторис використовується продюсером
та інвестором для прийняття рішень щодо фінансування, а також для планування
грошових потоків (cashflow), щоб забезпечити своєчасну виплату заробітних
плат, купівлю обладнання та покриття операційних витрат [47].
Контроль вартості забезпечує відповідність фактичних витрат
затвердженому бюджету. Для цього застосовується моніторинг витрат за
освоєним обсягом (Earned Value Management - EVM). Ця методологія дає змогу
порівнювати заплановану вартість із фактично освоєною та прогнозувати
майбутні перевищення витрат. Наприклад, якщо фактичний обсяг виконаної
56
роботи менший, ніж обсяг витрачених коштів, проєкт перебуває у зоні ризику, і
менеджер має негайно втрутитися - переглянути пріоритети, оптимізувати
завдання або перерозподілити ресурси. У GameDev EVM дозволяє завчасно
виявляти відставання, які можуть призвести до збільшення бюджету, особливо
на складних етапах, таких як інтеграція компонентів або фінальне тестування гри
[48].
Управління вартістю - це не просто математичний розрахунок або
формальність. Це складна, постійна робота, що вимагає уважності, стратегічного
мислення й уміння передбачати фінансові ризики. У GameDev кожна фіча, кожен
художній актив, кожен рядок коду має ціну, а правильне управління цією
вартістю визначає успішність проєкту. Якщо бюджет контрольований, витрати
прогнозовані, а ризики враховані - команда має стабільність, а гра має шанс
досягти комерційного успіху. Якщо ж вартість виходить з-під контролю, проєкт
опиняється у ситуації, де неможливо завершити розробку без додаткового
фінансування, що не завжди доступне. Саме тому управління вартістю є одним
із найкритичніших елементів GameDev-проєктів і обов’язковою складовою
їхнього професійного планування.
2.6 Управління закупівлями у проєкті
Закупівлі в GameDev - це парадокс: вони визначально важливі, але часто
лишаються поза увагою керівництва, поки проєкту необхідно їх планувати.
Створення гри зазвичай асоціюється із творчою роботою команди -
програмуванням, геймдизайном, арт-виробництвом - але значна частина
необхідних компонентів для повноцінної реалізації продукту знаходиться за
межами студії. Саме тому управління закупівлями стає критичним інструментом,
що забезпечує проєкт усім необхідним - від ліцензій на програмне забезпечення
до аутсорсингових послуг, маркетингових матеріалів та інтелектуальної
власності, без яких гра не може вийти у світ.
Управління закупівлями включає не тільки придбання товарів і послуг, а й
планування, оцінювання постачальників, вибір оптимальних форм контрактів,
контроль виконання договірних умов та інтеграцію зовнішніх результатів у
57
внутрішній виробничий процес. У GameDev це особливо актуально, оскільки
проєкти зазвичай покладаються на широку екосистему інструментів, сервісів і
партнерств. Позастудійні ресурси можуть бути як матеріальними (обладнання,
ліцензії, сервери), так і нематеріальними (художні ассети, музика, звук,
озвучування, консультаційні послуги, QA-аутсорс, локалізація).
Планування закупівель у GameDev починається з аналізу потреб проєкту
відповідно до WBS, технічного завдання та спринтових планів. Команда
менеджерів визначає, які ресурси доцільно створювати всередині студії, а які
дешевше або швидше закупити зовні. Зазвичай зовнішнім джерелам віддають
перевагу тоді, коли внутрішня команда не має відповідної компетенції або коли
створення своїми силами потребує непропорційно великих витрат часу.
Наприклад, специфічна 3D-анімація, озвучування персонажів професійними
акторами, музичні композиції, складні VFX або технічні консультації з
оптимізації рушія - все це типові приклади послуг, які доцільно залучати ззовні
[49].
Форми закупівель охоплюють три основні категорії, кожна з яких має свої
переваги й недоліки. Прямі закупівлі - це придбання конкретного продукту або
ліцензії без посередників. Наприклад, придбання підписки на Unreal Engine,
пакету Adobe Creative Cloud, Maya або 3ds Max, а також спеціалізованих
інструментів для звуку. Посередницькі закупівлі включають аутсорсинг
художніх активів, озвучування, музики чи частини програмування через
спеціалізовані студії або агентства. Такий формат часто обирається, коли студія
не має у штаті вузькоспеціалізованих фахівців. Біржові закупівлі - характерні для
сучасного GameDev, де значну кількість ассетів можна придбати на
маркетплейсах (Unity Asset Store, Unreal Marketplace), включно з 3D-моделями,
анімаціями, матеріалами, звуками та навіть фрагментами коду. Біржові закупівлі
дозволяють значно прискорити розробку та зменшити витрати, але потребують
ретельного аналізу ліцензійних умов.
Суттєву роль у закупівлях відіграє вибір типу контрактів. У GameDev
зазвичай використовуються два основні формати: контракти з твердою
58
(фіксованою) ціною та контракти з відшкодуванням витрат. Контракти з
фіксованою ціною добре підходять для чітко визначених послуг: створення 3D-
моделей, написання музичної композиції, виробництво трейлера, озвучування
персонажів чи створення ілюстрацій. У таких контрактах обсяг робіт, терміни,
якість та фінальна ціна визначені наперед, що дозволяє менеджеру передбачити
витрати й уникнути непередбачених фінансових ризиків. Контракти з
відшкодуванням витрат доцільні у випадках, коли обсяг роботи важко оцінити
на старті або коли залучається експерт-консультант, який працює погодинно.
Наприклад, оптимізація продуктивності на специфічному обладнанні або
глибокий технічний аудит рушія.
Залучення зовнішніх підрядників - окрема частина управління
закупівлями. У GameDev часто виникає потреба у послугах сторонніх студій
анімації, звукозапису, спеціалістів з UX, акторів озвучення, технічних
художників або компаній, що займаються локалізацією. Такі закупівлі зазвичай
оформлюються через контракти з фіксованою ціною або через погодинну оплату.
Саме аутсорсинг часто стає оптимальним рішенням, коли потрібно виконати
складне або об’ємне завдання у стислі строки, не наймаючи при цьому
додаткових співробітників у штат.
Окрему увагу варто приділити закупівлям, пов’язаним із маркетингом. У
сучасному ігровому середовищі маркетингові витрати можуть становити
третину або навіть половину бюджету, особливо якщо йдеться про комерційний
реліз на міжнародному ринку. Це включає рекламні кампанії, роботу з
інфлюенсерами, створення кінематографічних трейлерів, участь у виставках та
конференціях, взаємодію з пресою, розміщення на тематичних платформах.
Частина цих послуг закуповується напряму, а частина проходить через рекламні
платформи або PR-агентства, де ціни можуть змінюватися залежно від
охоплення аудиторії та сезонності.
Деякі студії також здійснюють оренду офісних приміщень чи обладнання.
Наприклад, оренда motion capture-студії для запису рухів акторів, оренда
серверів для мультиплеєрного тестування або навіть оренда офісу, якщо
59
власного простору недостатньо. Такі закупівлі часто здійснюються через
посередників і потребують підписання довгострокових договорів.
Після планування закупівель виникає необхідність контролювати їх
виконання. Менеджер проєкту має слідкувати за графіком поставок,
відповідністю закуплених активів технічним вимогам, якістю аутсорсингових
робіт та своєчасністю платежів. У GameDev навіть одна затримка - наприклад, з
отриманням 3D-моделей або музики - може вплинути на весь графік розробки,
оскільки багато інших завдань прив’язані до цих матеріалів. Тому контроль
закупівель є таким самим важливим, як контроль витрат або контроль часу [50].
2.7 Управління якістю у проєкті
Коли замислюєшся над якістю гри як над окремою складовою управління
GameDev-проєктом, швидко усвідомлюєш, що поняття «якість» тут виходить
далеко за межі простої відсутності багів або технічної стабільності. У розробці
комп’ютерних ігор якість набуває значення комплексної характеристики, яка
охоплює всю сукупність властивостей продукту - від емоцій, які отримує
гравець, до продуктивності рушія, чіткості UI, плавності анімацій, відповідності
геймплейних механік очікуванням аудиторії та навіть етичності внутрішніх
монетизаційних рішень. Через це управління якістю у GameDev стає складним,
багатовекторним і водночас критично важливим процесом, що супроводжує
проєкт на кожному етапі його життєвого циклу [51].
Управління якістю починається ще на етапі формування концепції гри.
Саме тут з’являється перше розуміння того, що саме має бути донесено до
гравця: який досвід він повинен отримати, якого типу взаємодію очікується
створити, наскільки глибокими мають бути механіки, яким буде баланс між
викликом і задоволенням. На цьому рівні якість є не технічною, а
концептуальною категорією - у певному сенсі це «бачення» гри як завершеного
продукту. Далі, з кожною ітерацією, це бачення уточнюється, матеріалізується і
переходить у більш формальні критерії: технічні вимоги, вимоги до
продуктивності, стандарти візуального оформлення, правила роботи з
інтерактивністю тощо [52].
60
Однією з філософських основ управління якістю у GameDev є адаптована
концепція TQM (Total Quality Management), яка передбачає, що якість - це
відповідність гри очікуванням користувачів, а не внутрішнім уявленням
розробників. Часто в індустрії повторюють: «Якість - це те, що скаже гравець»,
підкреслюючи, що найточнішим індикатором успішності є саме гравець, який
торкається продукту [53]. Це формує потребу у постійному фідбек-аналізі, у
проведенні бета-тестувань, у вивченні реакції аудиторії на ранні збірки гри, що
у сучасному геймдеві стає нормою [54].
Задля комплексного розуміння факторів, які впливають на якість продукту,
ефективним інструментом є Діаграма Ісікави [55]. Вона дозволяє візуалізувати
основні категорії потенційних проблем, які можуть вплинути на фінальний
результат. У контексті GameDev такими гілками можуть бути:
- Геймплей - логіка механік, глибина систем, баланс, рівневий дизайн;
- Технічна стабільність - кількість багів, надійність рушія, оптимізація
пам’яті, стійкість мережевих з’єднань (для онлайн-ігор);
- Арт-стиль - відповідність візуальної естетики загальній концепції, якість
моделей, анімацій, освітлення;
- Оптимізація - FPS, час завантаження сцен, продуктивність на різних
платформах.
Таке представлення дає можливість команді швидко побачити «вузькі місця» та
коректно визначати пріоритети для покращення.
Критерії якості в GameDev - це конкретні, вимірювані показники, які
встановлюються для контролю реалізації стандартів. До них належать:
- відсутність критичних дефектів (crash bugs), оскільки помилки, що
призводять до аварійного завершення гри, є неприпустимими у релізній
версії;
- відповідність продуктивності (FPS) галузевим стандартам: наприклад, 60
FPS для консольних ігор або мінімум 30 FPS для мобільних платформ;
- задоволеність основними елементами геймплею (оцінюється через
плейтести та опитування користувачів);
61
- відповідність нормам кодування (Coding Standards), які забезпечують
читабельність, підтримуваність і масштабованість кодової бази;
- відсутність блокуючих багів у ключових системах (бойова система,
інвентар, система збереження прогресу);
- відповідність UI/UX уніфікованим правилам інтерфейсного дизайну.
Управління якістю спирається на міжнародні стандарти, зокрема ISO 9000–
2011, адаптовані до специфіки GameDev [56]. Одним із фундаментальних
принципів є орієнтація на гравця, що передбачає безперервний збір зворотного
зв’язку. Це включає внутрішні плейтести, закриті бета-тести з обраною
аудиторією, відкриті бета-тести на платформах Steam та itch.io, а також аналіз
рецензій та коментарів. Іншим важливим принципом є лідерство керівника -
продюсер або технічний директор має створити культуру відкритості й
прозорості, щоб учасники команди могли повідомляти про проблеми якості без
страху покарання. Це сприяє оперативному виявленню багів, дисбалансів і
технічних недоліків .
Окреме місце у системі управління якістю займає принцип постійного
поліпшення за циклом PDCA (Plan–Do–Check–Act). У GameDev цей цикл
відображає зміст ітеративної розробки: команда планує нові фічі (Plan), реалізує
їх (Do), тестує та оцінює відповідність вимогам (Check), а потім вносить
покращення (Act). Кожен цикл ітерацій вирівнює якість продукту, забезпечує
адаптивність та стабільний прогрес. Саме завдяки PDCA команда уникає
накопичення технічного боргу, підтримує баланс між інноваціями та
стабільністю, а також покращує внутрішні процеси [57].
Бенчмаркінг - порівняння гри з конкурентами є ще одним інструментом
підвищення якості. Команда вивчає рішення інших студій, аналізує рівень
анімацій, якість балансу, стабільність мережевого коду, дизайн інтерфейсу тощо.
Це дозволяє визначити слабкі місця власного продукту та зрозуміти очікування
гравців у конкретному жанрі [58].
Окремо варто підкреслити значення підвищення кваліфікації команди, яке
також входить у систему управління якістю. Світ GameDev швидко змінюється:
62
з’являються нові графічні рушії, інструменти анімації, бібліотеки для симуляцій,
методи оптимізації. Розробники мають постійно навчатися, брати участь у
воркшопах, конференціях, курсах, адже їхня компетентність прямо впливає на
якість кінцевого продукту [59].
Суворе дотримання норм кодування - ще один ключовий компонент
управління якістю. Нечіткий, неструктурований код створює технічний борг,
який ускладнює подальший розвиток проєкту, призводить до появи нових багів
та збільшує витрати часу на обслуговування. Використання єдиних стандартів
(наприклад, Unity C# Coding Guidelines або Unreal Engine C++ Coding Standards)
забезпечує стабільність, передбачуваність та легкість роботи з кодовою базою
для всієї команди.
2.8 Управління ризиками у проєкті
Зважаючи на ризикованість процесу створення відеогри, очевидно:
контроль ризиків має бути не формальністю, а основою проєктного
менеджменту. Без нього проєкту не вижити в такому швидкоплинному й
технологічно насиченому середовищі. Жоден проєкт, навіть той, що має ідеальну
команду, зрозумілий GDD та потужне фінансування, не може уникнути ризиків.
Вони завжди супроводжують геймдев - від дрібних технічних збоїв до критичних
затримок релізу, від неочікуваних змін ринку до невдалого маркетингу, від
перевищення бюджету до зниження інтересу гравців. Саме тому управління
ризиками є однією дисциплін, яка забезпечує стабільність та життєздатність
усього проєкту [60].
Управління ризиками в GameDev охоплює послідовність процесів:
ідентифікацію ризиків, оцінку їхнього впливу та ймовірності, розробку планів
реагування, моніторинг і контроль. Починається все з визначення можливих
сценаріїв, які можуть загрожувати якості гри, строкам розробки, бюджету або
репутації студії. Серед них: проблеми з інтеграцією фіч, затримка релізу,
перевищення бюджету на маркетинг, ризик Game Overdue (ситуація, коли
розробка затягується настільки, що гра морально застаріває на момент виходу),
низькі оцінки критиків, невірне масштабування серверів, втрата ключового
63
спеціаліста, порушення NDA, неефективні плейтести, непередбачувана
поведінка рушія після оновлень, здорожчання вартості технічних ресурсів. Цей
список ніколи не є повним, але він відображає центральні проблеми, з якими
стикаються GameDev-команди [61].
Оцінювання ймовірності реалізації кожного ризику може здійснюватися
двома підходами: експертним та статистичним. Експертний метод базується на
досвіді продюсерів, технічних директорів, лідерів команд, які спираються на
власний професійний шлях, попередні проєкти та індустріальний контекст.
Статистичний метод, у свою чергу, використовує історичні дані галузі: середню
кількість затримок релізів, частоту технічних проблем, типові коефіцієнти
відмови серверів, середні значення FPS-просідань під час бета-тестів. У
GameDev ці підходи часто комбінують, оскільки індустрія одночасно творча та
технологічна, а значить, потребує як глибокого досвіду, так і аналітичного
підходу.
Серйозним ризиком у GameDev є Game Overdue, коли тривала розробка
робить гру застарілою ще до виходу. Це відбувається, коли індустрія швидко
рухається вперед - змінюється графічна мода, з’являються нові ігрові тренди, і
проєкт, який розроблявся 5 років, просто перестає відповідати очікуванням
аудиторії. Основними факторами є: відсутність чіткої дорожньої карти, постійні
зміни бачення, переоцінка технічних можливостей студії. Контрзаходи:
заморожування концепту після пре-продакшену, ліміт на кількість фіч у релізній
версії, жорсткий контроль змісту і часу [62].
Не менш актуальними є ризики, пов’язані з маркетингом: перевищення
бюджету, неефективні рекламні кампанії, некоректний вибір цільової аудиторії,
негативні відгуки інфлюенсерів, неправильне позиціонування гри. Маркетингові
ризики особливо небезпечні, бо навіть якісна гра може провалитися в релізний
день через відсутність правильного охоплення. Фактори також можуть включати
недосвідчену PR-команду, відсутність A/B-тестування трейлерів, неоптимізовані
сторінки у Steam. Методи пом’якшення включають: залучення досвідчених
64
маркетингових консультантів, бенчмаркінг конкурентів, резервування бюджету
на додаткову рекламу, ранні рекламні альфа/бета-версії.
У мережевих іграх суттєвим ризиком стає невірне масштабування
серверів. У разі помилок можливі лаги, черги на входження, падіння серверів,
негативні відгуки на старті. Фактори: відсутність тестів навантаження,
неправильна оцінка пікової активності, економія на серверних ресурсах. Методи
пом’якшення: стрес-тести, контракти з надійними хмарними провайдерами,
резерви серверів, динамічне масштабування [63].
Для багатьох ризиків у GameDev характерним є ланцюговий зв’язок, який
показує логіку переходу від фактора (F), через ризик (R), до методів
пом’якшення (M). Така структура дозволяє виявити причини, наслідки та
можливі рішення у вигляді чіткої, візуально зрозумілої взаємодії.
Ефективне управління ризиками передбачає не тільки формальне
документування, але й створення культури відкритості в команді. Розробники
мають вільно говорити про проблеми, які помічають у своєму середовищі:
нестабільність рушія, підозріло повільну інтеграцію AI, погано працюючу
систему інвентаря, невідповідність анімацій або значне відставання окремих
членів команди. Проблема, озвучена на ранньому етапі, рідко стає критичною.
Проблема, яку приховали - майже завжди вибухає в найгірший момент [64].
2.9 Контроль прогресу та мотивація команди
Протягом довгого циклу розробки гри складно підтримувати стабільний
ритм команди. Тому контроль та мотивація є не просто допоміжними функціями,
а рушійною силою будь-якого GameDev-проєкту. Контроль дозволяє
впорядковувати хаотичність творчого процесу, розуміти, де команда
знаходиться зараз і чи рухається вона до релізу з тією швидкістю, яка була
запланована, а мотивація - це той внутрішній двигун, який утримує людей в
енергійному стані, не дозволяючи їм вигоріти, втратити зацікавленість або
опустити руки на завершальних етапах, коли накопичується втому та тиск
дедлайнів.
65
Система контролю в GameDev є багаторівневою та поєднує класичні
методи проєктного менеджменту з елементами гнучких підходів. На високому
рівні встановлюються віхи (Milestones) - контрольні точки, які відображають
стратегічні етапи розробки: Затвердження GDD, Прототип, Pre-Alpha, Alpha-
версія, Beta-версія, Release Candidate, Gold Master та Реліз. Наприклад,
неможливо перейти до бета-тестування, якщо не затверджено базовий набір
механік, а команді QA не передано стабільну збірку. Ці контрольні точки
виконують важливу функцію: вони дають команді зрозумілу загальну картину
прогресу, а продюсеру або проєктному менеджеру - об’єктивні індикатори стану
проєкту [65].
Водночас на щоденному та щотижневому рівнях застосовуються
інструменти Agile-методології: стендапи, ретроспективи, рев’ю, контрольні
синхронізації між командами (кодинг, арт, геймдизайн, звук). Особливу роль
відіграють Burndown Charts, які демонструють швидкість виконання задач у
спринті. Якщо лінія виконання занадто відстає від плану, це сигналізує про
потенційну затримку. Якщо ж виконання відбувається раніше визначеного
темпу, це може означати ефективну роботу або недооцінені задачі. Щоденні
стендапи дозволяють оперативно вирішувати конфлікти між командними
потоками, наприклад: художники затримуються з моделями, ігровий програміст
не може тестувати нові анімації; геймдизайнер змінив логіку бою, і команда AI
повинна адаптувати поведінку ворогів. Такий контроль не має на меті тиснути
на виконавців - він покликаний знімати блокування та забезпечувати стабільний
темп розробки [66].
Контроль фінансових відхилень також є необхідною складовою. У
GameDev часто трапляються ситуації, коли витрати на аутсорсинг, ліцензії,
маркетинг або закупівлю технічних ресурсів перевищують початково
заплановані показники. Продюсер або фінансовий менеджер застосовують
методи аналізу освоєного обсягу (Earned Value Management), що дозволяє
зіставляти реальні витрати з плановими, оцінювати індекс виконання робіт та
прогнозувати ризики перевищення бюджету. Наприклад, якщо витрати на
66
маркетинг зростають через додаткове замовлення трейлерів або залучення
більшої кількості інфлюенсерів, це потребує негайного коригування бюджету
або перерозподілу коштів між статтями.
Окремим напрямом контролю є контроль якості, тісно пов’язаний із
процесом QA. Перед включенням будь-якої фічі до основної збірки проводиться
ретельне тестування, що включає smoke-тести, функціональні, регресійні та
навантажувальні перевірки. Якщо геймплейний елемент або технічний модуль
не відповідає стандартам якості, він повертається на доопрацювання. Контроль
якості на пізніх етапах є критично важливим, адже кожна нова зміна в коді може
порушити вже стабільні механіки. У GameDev часто кажуть: «Чим ближче до
релізу, тим дорожче коштує кожен баг». Саме тому контроль якості повинен бути
системним, а не епізодичним [67].
Паралельно з контролем над проєктом велике значення має мотивація
команди. Навіть найкраще організований процес не має сенсу, якщо люди
емоційно виснажені, не бачать свого внеску або працюють у стані перманентного
стресу. У середовищі GameDev вигорання (burnout) - це поширене явище,
особливо у періоди “кранчів” (хронічних понаднормових робіт), коли команда
намагається встигнути до релізного дедлайну. Сучасні студії намагаються
відмовитися від токсичних практик минулого і впроваджують політику «no-
crunch», або принаймні істотно мінімізують такі періоди. Мотиваційні заходи
часто починаються з елементарного - нейтралізації демотивуючих факторів:
непрозорих рішень керівництва, хаотичних змін пріоритетів, відчуття
несправедливості або недооцінення внеску окремих учасників [68].
Позитивні методи стимулювання включають словесне визнання, що часто
недооцінюється, хоча має великий ефект; прозорість інформаційної політики, за
якої керівництво ділиться ключовими показниками (планами продажів,
відгуками від видавця, результатами плейтестів); гнучкий графік роботи, що
дозволяє спеціалістам працювати продуктивно у свої власні пікові години;
можливість професійного розвитку, наприклад, участь у конференціях, курсах з
67
нових рушіїв або технологій; матеріальні бонуси, включаючи оплату додаткових
релевантних інструментів або навіть видачу безкоштовних ігор студії.
У багатьох GameDev-компаніях застосовується система рівнів (Level
System), яка механічно, але справедливо відображає професійне зростання
співробітників. Така система може включати рівні від Junior до Lead або навіть
Principal. Підвищення рівня супроводжується зростанням зарплати,
розширенням повноважень, можливістю менторства молодших фахівців та
офіційним визнанням внеску в успіх проєкту. Наприклад, статус Senior Gameplay
Programmer не лише підкреслює майстерність у написанні коду, а й закріплює
високу відповідальність за стабільність ключових систем гри.
Не менш важливою частиною мотивації є створення культури підтримки,
коли команда відчуває, що її зусилля помічають, цінують і що кожен учасник є
важливою частиною загальної місії. Це може проявлятися у неформальних
подіях (як-от “Demo Fridays”, де кожен показує свій прогрес), у подяках під час
спринтових ретроспектив, у внутрішніх нагородах за кращу фічу або за
найскладніший виправлений баг.
2.10 Управління інформаційною безпекою
Інтелектуальна власність - це цінний актив команди розробників. Цей факт
стає очевидним, щойно починаєш сприймати створення гри як повноцінний
бізнес-проєкт, а не виключно як творчий процес. Ідея, сценарій, візуальний
стиль, унікальні механіки, власні напрацювання в коді, внутрішні інструменти -
усе це формує конкурентну перевагу студії, а будь-який витік або компрометація
цих напрацювань може фактично звести нанівець роки роботи. Саме тому у
структурі управління GameDev-проєктом окреме місце займає захист
інтелектуальної власності та побудова цілісної системи управління
комп’ютерними інцидентами, яка не лише реагує на проблеми, а й запобігає їм.
Для захисту ІВ гри в проєкті впроваджується власна система управління
комп’ютерними інцидентами (СУІІБ), яка розглядається як невід’ємний елемент
загальної системи менеджменту безпеки. На відміну від формального підходу,
коли безпека сприймається як набір окремих технічних рішень (антивіруси,
68
фаєрволи тощо), СУІІБ у даному випадку виконує роль процесного «каркасу».
Вона задає правила, регламенти, відповідальність і канали комунікації для
роботи з інцидентами інформаційної безпеки, пов’язаними як із внутрішніми, так
і з зовнішніми загрозами. Особливістю GameDev є те, що саме вихідний код,
скрипти геймплею, конфігурації серверів, художні активи та дизайн-документи
(GDD, технічні специфікації, документація до інструментів) є ціллю для
зловмисників, конкурентів або піратів. Тому система управління інцидентами
налаштована в першу чергу на виявлення спроб несанкціонованого доступу,
витоку вихідного коду та копіювання активів [69].
СУІІБ автоматизує процеси моніторингу та реагування на широкий спектр
загроз: кібератаки на внутрішню інфраструктуру, спроби злому репозиторіїв
кодової бази, несанкціоноване копіювання файлів з робочих станцій, підозрілу
активність користувачів, а також аномальну поведінку мережевого трафіку.
Процес функціонування СУІІБ, як правило, описується у вигляді
стандартизованої послідовності етапів. По-перше, отримання інформації про
інцидент: дані можуть надходити з різних джерел - систем журналювання подій
(логів серверів і репозиторіїв), систем виявлення вторгнень, моніторингу
робочого часу, сповіщень від працівників, а також через інтегровані системи
контролю доступу. На цьому етапі важливо, щоб система вміла відрізняти
нормальну робочу активність (наприклад, масовий коміт ресурсів перед спринт-
рев’ю) від потенційно небезпечної поведінки (раптове масове завантаження
приватних репозиторіїв на зовнішню IP-адресу).
Другий етап - аналіз інциденту, під час якого автоматизовані інструменти
та спеціалісти з інформаційної безпеки оцінюють характер події, її критичність,
можливі наслідки та масштаб. У GameDev це може означати перевірку, чи не
було скопійовано цілі модулі рушія, унікальні шейдери, дизайнерські сцени з
рівнями або конфігурації балансних таблиць, що визначають економіку гри. На
цьому етапі часто застосовуються механізми кореляції подій (SIEM-системи), які
дозволяють побачити загальну картину: наприклад, підозрілий вхід з нетипового
69
географічного місця, після якого відбулося масове завантаження архівів з
репозиторію і паралельно - відключення користувача від внутрішнього чату.
Третім етапом є локалізація порушення, яка має на меті оперативно
обмежити зону впливу інциденту. Сюди належать: тимчасове блокування
облікового запису, обмеження доступу до критичних репозиторіїв, ізоляція
ураженого вузла в мережі, блокування підозрілих IP-адрес, примусове оновлення
паролів або ключів доступу. У контексті GameDev-проєкту це може бути
блокування доступу до гілок репозиторію, що містять фінальну збірку гри, та
переміщення поточних активів у «зону карантину» для того, щоб переконатися
у відсутності модифікацій чи вбудованих бекдорів.
Четвертий етап - автоматизоване застосування контрзаходів. Сучасні
СУІІБ передбачають не лише сповіщення, а й здатність автоматично реагувати
на інцидент за наперед визначеними сценаріями. Наприклад, при виявленні
спроби масового експортy репозиторію з незнайомого пристрою система може:
заблокувати сесію, відключити VPN-тунель, занести інцидент до журналу,
сповістити відповідального адміністратора та керівника проєкту. Таким чином,
людський фактор у первинній реакції мінімізується, а час між виявленням та
локалізацією загрози скорочується до секунд або хвилин, що критично важливо
при спробах крадіжки вихідного коду.
Однак робота СУІІБ не обмежується лише автоматизацією. Вона
доповнюється цілим комплексом організаційно-технічних заходів, спрямованих
на зниження ймовірності інцидентів. Одним із ключових рішень є шифрування
вихідного коду та ключових художніх активів. Це означає, що навіть у разі
фізичного доступу до носія (наприклад, жорсткого диска чи серверу з резервною
копією) стороння особа не зможе прочитати або використати ці дані без
відповідних ключів. Шифрування може застосовуватися для окремих директорій
або для всіх робочих станцій, на яких ведеться розробка.
Другим важливим елементом є юридичний захист ІВ через договори про
нерозголошення (NDA). Усі працівники студії, включаючи штатних фахівців,
фрилансерів, аутсорсерів та технічних партнерів, зобов’язані підписувати NDA,
70
які чітко фіксують заборону на розголошення будь-якої конфіденційної
інформації, пов’язаної з грою, технологіями або внутрішніми процесами. У
договорі встановлюються суттєві штрафні санкції - наприклад, 100 000 доларів
США за порушення - що створює достатньо високий бар’єр для зловмисних дій.
NDA також може передбачати обов’язок відшкодувати всі побічні збитки,
пов’язані з витоком (втрата вигоди, шкода репутації, витрати на юридичний
захист), що ще більше підсилює мотивацію дотримуватися правил
конфіденційності [70].
Технічний рівень захисту доповнюється системами контролю доступу, які
реалізуються як на рівні мережевої інфраструктури, так і на рівні репозиторіїв
коду (Git, Perforce). Принцип мінімальних привілеїв (least privilege) означає, що
кожен працівник має доступ лише до тих модулів і гілок, які необхідні йому для
виконання поточних задач. Наприклад, 3D-художник не має доступу до
серверних конфігурацій або до фінального збірочного pipeline, а backend-
програміст не може безпосередньо читати всі арт-активи, що не пов’язані з його
частиною роботи. Така сегментація не лише зменшує ризик навмисного витоку,
а й мінімізує наслідки у разі компрометації одного облікового запису.
Додатковим елементом комплексу безпеки є системи моніторингу
робочого часу та активності (наприклад, умовний ScreenMaster), які фіксують
ключові дії на робочих станціях: копіювання великих обсягів даних,
встановлення стороннього ПЗ, підключення незареєстрованих зовнішніх
пристроїв, нетипову поведінку користувачів. Вони дозволяють виявляти
підозрілі патерни (наприклад, нічний експорт великої кількості файлів з арт-
папок або спроби архівації вихідних кодів) ще до того, як ці дії призведуть до
реального витоку. Важливо, що використання таких систем має бути
врівноважене політикою прозорості: співробітники повинні знати, що
моніторинг здійснюється, розуміти його цілі (захист проєкту, а не «тотальний
контроль») і мати гарантований рівень приватності в межах законодавства.
Ще одним суттєвим запобіжником є блокування зовнішніх носіїв
інформації на робочих ПК - USB-накопичувачів, зовнішніх дисків, карт пам’яті.
71
Це робиться через політики безпеки операційної системи та корпоративні засоби
управління. У разі необхідності передати дані поза локальною мережею
використовуються захищені канали (VPN, SFTP) та централізовано
контрольовані файлові сховища. Такий підхід практично унеможливлює просте
копіювання цінних активів «на флешку», що є одним із найпоширеніших методів
внутрішніх витоків.
Не слід забувати й про фізичну безпеку, яка часто залишається в тіні суто
цифрових рішень, але у реальності є їхнім фундаментом. Доступ до офісу або до
окремих приміщень (серверні, кімнати для зберігання резервних копій, робочі
місця з високим рівнем доступу) здійснюється за допомогою ключ-карт або
електронних пропусків. Системи контролю доступу фіксують час входу і виходу,
а також можуть обмежувати присутність у певні години. У поєднанні з
відеоспостереженням це дозволяє аналізувати підозрілі події - наприклад, нічний
доступ до кімнати, де зберігаються робочі станції арт-команди або сервер з
репозиторіями.
Висновоки до розділу 2
Управління комунікаціями в GameDev-проєкті фактично виконує роль
«нервової системи» всієї розробки: через нього проходять рішення, зміни у
вимогах, результати тестування, творчі ідеї та управлінська інформація. Від того,
наскільки чітко визначені інформаційні потреби стейкхолдерів, налагоджені
канали обміну (від GDD і технічних специфікацій до стендапів і звітів) та
стандартизований документообіг, залежить узгодженість дій різнопрофільних
команд і здатність проєкту адаптуватися до змін. Продумана комунікаційна
програма, що поєднує внутрішні й зовнішні контури, сучасні цифрові
інструменти та регламентовану ритміку обміну даними, знижує ризики,
мінімізує кількість переробок і підтримує прозорість управління. У таких умовах
комунікація перестає бути лише обміном повідомленнями й перетворюється на
ключовий механізм підтримки стабільного прогресу та збереження цілісного
бачення гри всіма учасниками проєкту.
72
Розділ ІІІ Оцінка економічної ефективності проєкту
3.1 Планування фінансових ресурсів інвестиційної фази ІТ проєкту
Планування фінансових ресурсів інвестиційної фази ґрунтується на
календарно-мережевій моделі робіт та прогнозі витрат, необхідних для реалізації
проєкту створення комп’ютерної гри. На основі тривалості етапів, трудових
витрат та статей кошторису формується первісний календарний графік
фінансування, який дозволяє оцінити помісячну потребу у фінансових ресурсах.
Відповідно до проведених розрахунків, найбільше навантаження припадає на
перший місяць робіт через одноразове придбання обладнання та меблів, тоді як
у подальші місяці витрати залишаються відносно рівномірними. Загальна сума
інвестицій інвестиційної фази становить 1 140,6 тис. грн, що відповідає повному
обсягу кошторису проєкту.
Для комплексної оцінки фінансових потреб застосовуються три
взаємопов’язані діаграми (рис. 3.1): графік поточних витрат (а), графік
накопичених капіталовкладень (б), а також графік щомісячної виплати процентів
за кредит (в) при ставці 1%. Дані графіків відображають динаміку фінансового
навантаження: наростання загальної потреби у фінансуванні до 1 140,6 тис. грн
та поступове збільшення суми відсоткових платежів від 2,919 % у другому місяці
до 10,27 % наприкінці інвестиційного періоду.
К К , тис. грн. (3.1)
t t
73
350
300
250
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10
А) графік поточних потреб у капіталовкладеннях (К= 1 140 600 грн.)
1200
1000
800
600
400
200
0
1 2 3 4 5 6 7 8 9 10
Б) графік накопичених сум капіталовкладень - потреб у кредитних ресурсах
74
12
10
8
6
4
2
0
1 2 3 4 5 6 7 8 9 10
В) графік виплати процентів за кредит (Пк = 1%, ПТ = 58.49 тис. грн.)
Рисунок 3.1 - Календарний план фінансування інвестиційної фази проєкту
У сукупності ці діаграми формують календарний план фінансування
інвестиційної фази ІТ-проєкту, забезпечуючи основу для прийняття
управлінських рішень щодо залучення та використання ресурсів у процесі
розроблення комп’ютерної гри.
3.2 Оптимізація плану фінансування інвестиційної фази проєкту
У процесі розроблення комп’ютерної гри, що здійснюється на основі
проєктного підходу, важливим завданням є оптимізація фінансових потоків
інвестиційної фази. Загальний принцип такої оптимізації полягає в перенесенні
більшої частини капіталовкладень на пізніші етапи, що дає змогу мінімізувати
обсяг коштів, які тимчасово перебувають у «замороженому» стані. Для цього
довготривалі роботи плануються таким чином, щоб їх основні фінансові виплати
відбувалися після завершення ключових етапів або суттєвої частини задачі —
зокрема оплата праці виконавців може здійснюватися не поетапно, а після
закриття всієї задачі, що є раціональним з точки зору часу обігу коштів.
Застосування такого підходу дозволило сформувати оптимізований варіант
календарного графіка поточних потреб у капіталовкладеннях, який оперує тією
75
ж загальною сумою ресурсів, що й первісний, проте розподіляє їх більш
збалансовано та економічно виправдано.
Порівняння первісного та оптимізованого планів показує, що завдяки
зміщенню витрат на пізніші періоди та зменшенню обсягу коштів, що
перебувають у кредиті, загальна сума виплат процентів за кредит знижується
(ВП). Оптимізовані графіки потреб у фінансуванні, накопичених кредитних
ресурсів та процентних платежів (рис. 3.2) формують основу для подальшого
укладання кредитного договору з банком-кредитором та забезпечують більш
ефективне фінансове управління в межах проєкту створення комп’ютерної гри.
135
130
125
120
115
110
105
100
95
1 2 3 4 5 6 7 8 9 10
А) оптимізований графік поточних потреб у капіталовкладеннях (К= 1 140 600
грн.)
76
1200
1000
800
600
400
200
0
1 2 3 4 5 6 7 8 9 10
Б) оптимізований графік накопичених сум капіталовкладень - потреб у
кредитних ресурсах
12
10
8
6
4
2
0
1 2 3 4 5 6 7 8 9 10
В) оптимізований графік виплати процентів за кредит (Пк = 1%, ПТ = 50.50 тис.
грн.)
Рисунок 3.2 - Оптимізований календарний план фінансування
інвестиційної фази проєкту
77
3.3 Розробка зведеного кошторису витрат інвестиційної фази проєкту
Розробка комп’ютерної гри як ІТ-проєкту вимагає точного фінансового
планування, тому зведений кошторис інвестиційної фази формується на основі
прогнозу витрат окремих робіт та визначеної суми процентних платежів за
кредитом за оптимізованим варіантом плану фінансування (ПТ = 50,5 тис. грн).
Такий кошторис виконує роль офіційного фінансового документа, який
затверджується керівником проєкту і узгоджує всі статті витрат, пов’язані з
GameDev-процесами: передвиробничими дослідженнями, розробкою ТЗ,
програмуванням, створенням контенту, тестуванням та маркетинговими
активностями.
“Затверджую”
Керівник проєкту
Дата 01.07.24 Підпис _________
Зведений кошторис
планових витрат інвестиційної фази проєкту
№ Процеси та роботи GameDev- Шифр Витрати, тис.
проєкту грн
1 Аналіз ринку відеоігор та цільової 12,0
аудиторії
2 Аналіз конкурентних продуктів 16,0
3 Техніко-економічне 8,0
обґрунтування (ТЕО)
4 Комерційний аналіз та стратегія 6,0
монетизації
5 Оренда офісних приміщень та 90,0
комунальні витрати
6 Закупівля обладнання, техніки та 203,1
меблів
7 Розробка технічного завдання (ТЗ) 52,0
78
8 Планування та побудова WBS 8,0
9 Затвердження ТЗ та документації 4,0
10 Розподіл трудових ресурсів 8,0
11 Створення UI/UX-прототипів 14,4
(landing)
12 Брендінг гри 8,0
13 Неймінг та розробка ключових 6,0
елементів стилю
14 Створення UI/UX-прототипів 24,0
15 Розробка фронтенд-інтерфейсів 38,4
16 Імплементація бізнес-логіки гри 42,0
(бекенд)
17 Реалізація серверної логіки та API 54,0
18 Розробка контентних модулів гри 48,0
19 SEO-оптимізація та підготовка 4,8
контенту
20 Тестування (QA) 16,0
21 Bug Fixing (бекенд + фронтенд) 28,8
22 SMM та активності в соцмережах 12,0
23 Таргетована реклама 8,0
24 Контекстна реклама 6,0
25 Підготовка до запуску гри та реліз 36,0
26 Резерв преміювання та overtime- 70,0
фонд
27 Контроль виконання та супровід 57,2
PM
28 Проценти за кредит (ПТ) 50,5
Разом витрат, 1 191,1
тис. грн
79
Розрахунок виконав бухгалтер-економіст проєкту ___________________
Рисунок 3.3 - Форма оформлення кошторису
Зведений кошторис включає усі процеси, що формують інвестиційний
бюджет, а окремим пунктом враховує виплати процентів за кредит. Він
забезпечує фінансову прозорість, дозволяє здійснювати контроль за
використанням ресурсів та сприяє ефективній координації етапів розроблення
комп’ютерної гри протягом всієї інвестиційної фази.
3.4 Прогнозування показників операційної діяльності
У межах проєкту створення комп’ютерної гри необхідно спрогнозувати
ключові вартісні показники операційної діяльності, адже після завершення
інвестиційної фази продукт переходить у комерційну експлуатацію.
Прогнозування дозволяє визначити динаміку майбутніх доходів від реалізації
ігрових пакетів доступу, зміну витрат на підтримку гри, оновлення контенту та
оплату праці команди підтримки. Основою прогнозних розрахунків є показники
базового року та коефіцієнти їх щорічної зміни (зростання або зниження), що
охоплюють ціну доступу до гри, зміну матеріальних витрат, витрат на оплату
праці та постійних витрат.
Прогноз показників преставлено в Таблиці 3.2, а прогноз динаміки
показників в Таблиці 3.3
80
Таблиця 3.2
Прогноз показників операційної діяльності
Показники Starter Deluxe
Pack Pack
1. Середньорічний обсяг реалізації, тис. од. 50 25
2. Початкова ціна доступу до гри (Ц₀), грн 50 100
3. Прямі матеріальні витрати (серверні ресурси, CDN, 3 3
інфраструктура), грн/од.
4. Прямі витрати на оплату праці LiveOps/Support, 8 23
грн/од.
5. Постійні операційні витрати на рік (сервери, 78,18
підтримка, маркетинг), тис. грн
Таблиця 3.3
Прогноз динаміки показників операційної діяльності
Назва Позначення Значення
1. Коефіцієнт зростання ціни продукту k₍ц₎ 1,05
2. Коефіцієнт зміни матеріальних витрат k₍м₎ 0,98
(інфраструктура)
3. Коефіцієнт зростання витрат на оплату праці k₍оп₎ 1,10
4. Коефіцієнт зростання постійних витрат k₍пв₎ 1,02
Прогноз дає змогу оцінити економічний потенціал проєкту на 10-річний
період експлуатації. На підставі вихідних даних сформовано таблиці прогнозної
динаміки вартості одиниці продукту та ресурсних витрат для двох пакетів —
“Starter Pack” і “ Deluxe Pack ”. Отримані значення є базою для визначення річних
операційних доходів, витрат і подальших фінансово-економічних показників
ефективності GameDev-проєкту.
81
Таблиця 3.4
Прогноз динаміки вартісних показників операційної діяльності
Показник 1 2 3 4 5 6 7 8 9 10
и
1. Ціна 50.0 52.5 55.1 57.8 60.7 63.8 67.0 70.3 73.8 77.5
одиниці
продукту
(грн)
2. 3.00 2.94 2.88 2.82 2.77 2.71 2.66 2.60 2.55 2.50
Матеріаль
ні витрати
(грн)
3. Витрати 8.0 8.8 9.68 10.6 11.7 12.8 14.1 15.5 17.1 18.8
на оплату
праці (грн)
4. Постійні 78.1 79.7 81.3 82.9 84.6 86.3 88.0 89.8 91.6 93.4
витрати 8 4 3 6 2 1 4 0 0 3
(тис. грн)
Таблиця 3.5
Прогноз динаміки вартісних показників операційної діяльності
Показни 1 2 3 4 5 6 7 8 9 10
ки
1. Ціна 100. 105. 110. 115. 121. 127. 134. 140. 147. 155.
одиниці 0 0 25 76 55 63 01 71 70 13
продукту
(грн)
2. 3.00 2.94 2.88 2.82 2.77 2.71 2.66 2.60 2.55 2.50
Матеріал
ьні
витрати
(грн)
3. 23.0 25.3 27.8 30.6 33.6 37.0 40.7 44.8 49.3 54.2
Витрати 3 1 7 4 5 2 0 3
на оплату
праці
(грн)
82
Отримані значення вартісних показників будуть використані при
розрахунку операційних доходів і витрат за роками проєкту.
3.5 Планування амортизаційних витрат операційної діяльності
У процесі створення комп’ютерної гри частина інвестиційної фази проєкту
спрямована на придбання основних активів — робочих станцій розробників,
серверного обладнання, периферії та офісного оснащення. Для оцінки їх впливу
на операційні витрати необхідно спрогнозувати амортизаційні відрахування на
весь період функціонування гри. Відповідно до стандартів бухгалтерського
обліку, GameDev-компанія має право самостійно визначати строки корисного
використання та метод амортизації; у проєкті обрано рівномірний метод, який
забезпечує стабільність витрат за роками.
Таблиця 3.6
Розрахунок амортизаційних витрат за роками операційної діяльності
Групи Перві Річна 1 2 3 4 5 6 7 8 9 10
основн сна норма
их варті амортиз
засобів сть, ації, %
тис.
грн
Сервер 203,1 20% 40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
не 62 62 62 62 62 62 62 62 62 62
обладна
ння та
перифе
рія
Робочі 144,0 20% 28, 28, 28, 28, 28, 28, 28, 28, 28, 28,
станції, 80 80 80 80 80 80 80 80 80 80
ноутбу
ки,
техніка
розробн
иків
Офісні 59,0 20% 11, 11, 11, 11, 11, 11, 11, 11, 11, 11,
меблі 80 80 80 80 80 80 80 80 80 80
Разом 406,1 – 81, 81, 81, 81, 81, 81, 81, 81, 81, 81,
амортиз 22 22 22 22 22 22 22 22 22 22
ації,
тис. грн
83
Амортизаційні відрахування розраховано на 10 років експлуатації гри,
беручи до уваги початкову вартість активів, сформованих у попередніх етапах.
Оскільки обладнання та техніка були придбані ще в інвестиційній фазі,
амортизація починає застосовуватися одразу з першого року операційної
діяльності. Отримані значення наведені в таблиці 3.6 і будуть використані при
формуванні прогнозу операційних витрат та фінансових результатів GameDev-
проєкту.
3.6 Планування кредитних процесів операційної діяльності
Планування кредитних процесів у GameDev-проєкті передбачає
визначення порядку та строків повернення коштів, залучених на фінансування
інвестиційної фази створення гри. Оскільки основна частина витрат на розробку
припадає на період до виходу продукту на ринок, повернення суми кредиту може
розпочатися лише після отримання перших операційних доходів.
Розраховані значення подано в таблиці 3.7 та використовуються при
формуванні річних грошових потоків фінансової діяльності та при визначенні
операційних витрат проєкту.
Таблиця 3.7
Схема використання та повернення кредиту за роками діяльності
Показники 1 рік 2 рік 3 рік 4 рік
1 варіант – 376,4 376,4 387,8
1. Повернення тіла кредиту, тис. грн
2. Використана сума кредиту (накопичено), 1 1 764,2 387,8
тис. грн 140,6 140,6
3. Оплата процентів, тис. грн (12%) 136,9 136,9 91,7 46,5
2 варіант
1. Повернення тіла кредиту, тис. грн – 570,3 570,3 -
2. Використана сума кредиту (накопичено), 1 1
тис. грн 570,3 -
140,6 140,6
3. Оплата процентів, тис. грн (12%) 136,9 136,9 68,4 -
4. Повернення кредиту (ПК), тис. грн 136,9 707,2 638,7 -
84
Після завершення першого року проєкт переходить до погашення основної
суми кредиту. Розглядаються два сценарії: рівномірне повернення протягом двох
років або протягом трьох років. Перший варіант забезпечує швидке закриття
боргових зобов’язань, але створює підвищене навантаження на прибуток.
Другий варіант знижує річні виплати, хоча подовжує строк повернення.
3.7 Прогноз доходів операційної діяльності
Прогнозування доходів операційної діяльності є важливим складником
фінансового планування GameDev-проєкту, оскільки дозволяє оцінити
економічну ефективність експлуатаційної фази гри. Обсяги реалізації пакетів
доступу до гри та їхня ціна були спрогнозовані у попередніх таблицях, що дає
можливість визначити річні доходи за весь 10-річний період. Для кожного року
операційної діяльності доходи формуються як добуток прогнозованої кількості
продажів Starter Pack та Deluxe Pack на відповідні ціни цих пакетів. Дані
представлені в Таблиці 3.8
Таблиця 3.8
Прогноз доходів операційної діяльності
Показн 1 2 3 4 5 6 7 8 9 10
ики
1. ОР 50, 55,0 60,5 66,6 73,2 80,5 88,6 97,4 107,2 117,9
Starter 0
Pack
2. ОР 25, 26,3 27,6 28,9 30,4 31,9 33,5 35,2 36,9 38,8
Deluxe 0
Pack
3. Ціна 50, 52,5 55,1 57,8 60,7 63,8 67,0 70,3 73,8 77,5
Starter 0
Pack
4. Ціна 100 105, 110, 115, 121, 127, 134,0 140,7 147,7 155,1
Deluxe ,0 0 3 8 6 6
Pack
5. 500 5643 6373 7202 8142 9210 10424 11804 13374 15161
Річний 0 ,8 ,8 ,2 ,7 ,9 ,8 ,9 ,8 ,4
дохід
85
Отримані розрахунки свідчать про сталі тенденції зростання обсягів
реалізації ігрових пакетів, що зумовлено розширенням бази користувачів,
ефективністю маркетингової стратегії та поступовим підвищенням вартості
доступу до гри. Таким чином, річний операційний дохід має стабільну позитивну
динаміку протягом усіх років, що підтверджує перспективність і комерційну
життєздатність GameDev-проєкту.
3.8 Прогноз витрат операційної діяльності
Планування операційних витрат дозволяє оцінити фінансове
навантаження, яке супроводжує експлуатаційну фазу створеної комп’ютерної
гри. Для цього визначаються річні витрати змінного характеру, що залежать від
обсягів реалізації ігрових пакетів, витрати постійного характеру, амортизаційні
відрахування та платежі з повернення кредиту відповідно до обраної моделі
погашення. На основі прогнозів операційних показників, амортизації та
кредитних графіків сформовано два варіанти розрахунків витрат: із поступовим
поверненням кредиту протягом трьох років або із більш інтенсивним
поверненням протягом двох років.
Отримані значення подані в таблицях 3.9 та 3.10 і демонструють, що
основний вплив на загальне навантаження в перші роки мають амортизація
основних активів та кредитні зобов’язання.
Таблиця 3.9
Прогноз витрат операційної діяльності, тис. грн. (1 – варіант)
Показник 1 2 3 4 5 6 7 8 9 10
и / Рік
ВЗ, тис. грн 2,3 2,4 2,6 2,9 3,1 3,4 3,7 4,0 4,3 4,7
ПВ, тис. 78,1 79,7 81,3 82,9 84,6 86,3 88,0 89,8 91,6 93,4
грн 8 4 3 6 2 1 4 0 0 3
Амортизаці 81,2 81,2 81,2 81,2 81,2 81,2 81,2 81,2 81,2 81,2
я (A) 2 2 2 2 2 2 2 2 2 2
Поверненн 0 376, 376, 387, 0 0 0 0 0 0
я кредиту 4 4 8
(ПК)
Разом ОВ, 161, 539, 541, 554, 168, 170, 172, 175, 177, 179,
тис. грн 0 8 6 9 9 9 0 0 1 4
86
Таблиця 3.10
Прогноз витрат операційної діяльності, тис. грн. (2 – варіант)
Показник 1 2 3 4 5 6 7 8 9 10
и / Рік
ВЗ, тис. грн 2,3 2,4 2,6 2,9 3,1 3,4 3,7 4,0 4,3 4,7
ПВ, тис. 78,1 79,7 81,3 82,9 84,6 86,3 88,0 89,8 91,6 93,4
грн 8 4 3 6 2 1 4 0 0 3
Амортизаці 81,2 81,2 81,2 81,2 81,2 81,2 81,2 81,2 81,2 81,2
я (A) 2 2 2 2 2 2 2 2 2 2
Поверненн 0 570, 570, 0 0 0 0 0 0 0
я кредиту 3 3
(ПК)
Разом ОВ, 161, 733, 735, 167, 168, 170, 172, 175, 177, 179,
тис. грн 0 7 4 1 9 9 0 0 1 4
Після завершення періоду повернення кредиту витрати значно
стабілізуються, що забезпечує прогнозованість інвестиційної моделі та дозволяє
ефективно оцінити економічну життєздатність GameDev-проєкту на тривалій
часовій дистанції.
3.9 Прогноз грошових потоків операційної діяльності
Прогнозування грошових потоків операційної діяльності дає змогу
визначити динаміку формування прибутку від реалізації комп’ютерної гри після
завершення інвестиційної фази. На підставі співставлення річних доходів від
продажу пакетів доступу до гри та операційних витрат, які включають змінні,
постійні, амортизаційні складові та виплати за кредитом, формується прогноз
балансового й чистого прибутку проєкту. Розрахунки проведені для всіх десяти
років експлуатації гри та охоплюють два варіанти повернення кредиту —
рівномірне погашення протягом трьох років або прискорене погашення протягом
двох років.
87
Таблиця 3.11
Прогноз грошових потоків операційної діяльності (1-варіант)
Показни 1 2 3 4 5 6 7 8 9 10
ки, тис.
грн
Дохід 5000 5643 6373 7202 8142 9210 1042 1180 1337 1516
(Д) ,8 ,8 ,2 ,7 ,9 4,8 4,9 4,8 1,4
ОВ 161, 539, 541, 554, 168, 170, 172,0 175,0 177,1 179,4
0 8 6 9 9 9
Балансо 4839 5104 5832 6647 7973 9040 1025 1162 132,0 1498
вий ,0 ,0 ,2 ,3 ,8 ,0 2,8 9,9 0 2,0
прибуто
к (ПБ)
Продовження таблиці 3.11
Амортизац 81,2 81,2 81,2 81,2 81,2 81,2 81,22 81,22 81,2 81,22
ія (A) 2 2 2 2 2 2 2
Оподатков 4757 5022 5751 656 789 895 1017 1154 131, 1490
аний ,8 ,8 ,0 6,1 2,6 8,8 1,6 8,7 80 0,8
прибуток
(ОП)
Податок 475, 502, 575, 656, 789, 895, 1017, 1154, 13,2 1490,
(П) 8 3 1 6 3 9 2 9 0 1
Чистий 4363 4601 5257 599 718 814 9235, 1047 118, 1349
прибуток ,2 ,7 ,1 0,7 3,3 5,0 6 5,0 00 2,0
(ЧП)
Таблиця 3.12
Прогноз грошових потоків операційної діяльності (2-варіант)
Показни 1 2 3 4 5 6 7 8 9 10
ки, тис.
грн
Дохід 5000 5643 6373 7202 8142 9210 1042 1180 1337 1516
(Д) ,8 ,8 ,2 ,7 ,9 4,8 4,9 4,8 1,4
ОВ 161, 733, 735, 167, 168, 170, 172,0 175,0 177,1 179,4
0 7 4 1 9 9
Балансов 4839 4910 5638 7035 7973 9040 1025 1162 132,0 1498
ий ,0 ,1 ,4 ,1 ,8 ,0 2,8 9,9 0 2,0
прибуток
(ПБ)
88
Амортиз 81,2 81,2 81,2 81,2 81,2 81,2 81,22 81,22 81,22 81,22
ація (A) 2 2 2 2 2 2
Продовження таблиці 3.12
Оподатков 4757 4828 5557 695 789 895 1017 1154 131, 1490
аний ,8 ,9 ,2 3,9 2,6 8,8 1,6 8,7 80 0,8
прибуток
(ОП)
Податок 475, 482, 555, 695, 789, 895, 1017, 1154, 13,2 1490,
(П) 8 9 7 4 3 9 2 9 0 1
Чистий 4363 4427 5082 633 718 814 9235, 1047 118, 1349
прибуток ,2 ,2 ,7 9,7 3,3 5,0 6 5,0 00 2,0
(ЧП)
Отримані дані свідчать, що обидва варіанти забезпечують позитивні
грошові потоки упродовж усієї операційної фази. Проте у разі застосування
прискореної схеми погашення кредиту загальна рентабельність проєкту зростає,
оскільки зменшується тривалість боргового навантаження. Такий підхід є більш
ефективним у GameDev-проєктах, де швидке зниження фінансових ризиків
сприяє подальшому розвитку продукту — масштабуванню, створенню оновлень
та розширень гри.
3.10 Прогноз грошових потоків проєкту
Метою прогнозних розрахунків грошових потоків у GameDev-проєкті є
інтегральна оцінка фінансових результатів за всіма видами діяльності —
інвестиційною, операційною та фінансовою. Таке зіставлення дозволяє
визначити динаміку сальдо реальних грошей і переконатися в економічній
ефективності створення комп’ютерної гри. У межах моделі проєкту розрахунки
виконано на 10 років, із використанням прогнозованих доходів, операційних
витрат, амортизаційних відрахувань, кредитного графіка та параметрів
дисконтування.
Зведені результати для всіх грошових потоків подано в додатку А. На їх
основі побудовано графічну схему руху реальних коштів, що демонструє
стабільне зростання прибутковості з другого року операційної фази. Аналіз
номінальних і дисконтованих грошових потоків підтверджує, що GameDev-
89
проєкт є фінансово життєздатним і доцільним для реалізації, а його повернення
інвестицій забезпечується протягом перших років експлуатації гри.
3.11 Оцінка показників ефективності проєкту
На основі прогнозу грошових потоків інвестиційної, операційної та
фінансової діяльності (Додаток А) оцінимо інтегральну ефективність GameDev-
проєкту. Абсолютний ефект визначається як різниця між сумою дисконтованих
грошових притоків та відтоків за всі періоди реалізації. Для нашого проєкту сума
дисконтованих притоків становить
ЧДП П *КД В *КД = 39843,10−1055,00=38788,10 тис. грн.
t t t t
Оскільки інвестиційна фаза профінансована кредитним капіталом, для власника
гри початкові інвестиційні відтоки дорівнюють нулю, тому з його точки зору:
ЧДП П *КД 0=39843,10 тис. грн
t t
Це свідчить про високу комерційну привабливість проєкту.
Відносна ефективність використання залученого капіталу характеризується
індексом дохідності: ІД = ∑∑тт==11 П ∗∗ = 319085453,0,100 = 37,77
Середньорічні дисконтовані грошові притоки за 10 років операційної фази
становлять: П̅ = ∑т=1 ПТоп∗ = 3981403,31 = 3984,31 тис. грн.,
де Т оп - тривалість операційного періоду генерування грошових притоків,
років.
Очікуваний строк окТупн=ос∑тіт =в1кВлад∗еного
ок П̅ =кап
310італ
98554,,
у0:
310 = 0,26 роки
тобто орієнтовно проєкт окупається менш ніж за 3–4 місяці експлуатації гри.
Внутрішня норма дохідності (ВНД) визначається з рівняння:
П *КД
t В *t КД 0
t t
90
Якщо підставити вираз КД 1 , отримуємо наступне вирішення
t t
Н д 1
100
цього рівняння:
П t Вt
0
t t
Н д
1 Н д
1
100 100
Вирішення цього рівняння відносно X Н д , дає значення, яке являє
собою показник ВНД. Цей показник повинен бути більшим ніж норми доходу на
капітал, яка покладена в осно8в1у3 р5о5з,р9аху−нк1ів1 4п0ок,6аз=ни0ків ефективності проєкту.
(1 + 1Х00)10
Чисельним методом підстановки отримано, що Х≈394 річних, тобто Х>H, де H =
12% - норма дохідності, прийнята для дисконтування. Отже, внутрішня норма
дохідності значно перевищує вимоги інвестора, а GameDev-проєкт зі створення
комп’ютерної гри можна вважати фінансово ефективним.
Висновок до розділу 3.
У третьому розділі було здійснено комплексний фінансово-економічний
аналіз GameDev-проєкту. Виконано планування інвестиційної фази створення
комп’ютерної гри, проведено оптимізацію графіка капіталовкладень та
сформовано зведений кошторис витрат. Побудовано прогноз показників
операційної діяльності, включаючи доходи, витрати, амортизаційні нарахування
та кредитні процеси. Розраховано грошові потоки за всіма фазами, визначено
ключові показники ефективності, серед яких чистий дисконтований прибуток,
індекс дохідності, строк окупності та внутрішня норма рентабельності. Отримані
результати підтвердили високу економічну доцільність та інвестиційну
привабливість проєкту створення комп’ютерної гри.
91
ВИСНОВКИ
Таким чином, у процесі дослідження методології проєктного менеджменту
в галузі GameDev було здійснено комплексне опрацювання проєкту зі створення
комп’ютерної гри на основі проєктного підходу. У магістерській роботі
продемонстровано, як інструменти сучасного управління проєктами можуть
бути застосовані до складного креативно-технологічного продукту, яким є
комп’ютерна гра, та як їх використання дозволяє мінімізувати ризики,
оптимізувати ресурси і забезпечити досягнення встановлених цілей у визначені
строки.
У ході виконання роботи були здійснені такі дослідження:
проведено аналіз сучасних гнучких методологій проєктного менеджменту
(Agile, Scrum, Kanban) та їх придатності для GameDev-проєктів;
досліджено сутність планування в управлінні ігровими проєктами, зокрема
розгляд методів структуризації робіт, ресурсного, календарного та фінансового
планування;
сформовано концепцію та структуру GameDev-проєкту відповідно до
вимог проєктного підходу, включно з WBS, ресурсними матрицями та планом
комунікацій;
виконано аналіз методів управління якістю, ризиками та змінами у
контексті розробки комп’ютерної гри.
У роботі вирішено такі практичні завдання:
досліджено роль та інструменти управління проєктами в умовах сучасного
ігрового виробництва;
проаналізовано методики та практики планування GameDev-проєктів;
визначено специфічні характеристики та обмеження, притаманні ігровим
продуктам;
обґрунтовано підходи до формування цілей та ключових результатів
проєкту (OKR), структуровано етапи розробки та супутні процеси;
здійснено деталізоване планування робіт, ресурсів, строків і витрат;
92
розроблено календарний план інвестиційної фази та економічну модель
прогнозування подальшої операційної діяльності;
проведено фінансово-економічне обґрунтування ефективності розробки
гри.
У роботі розглянуто як теоретичні засади проєктного менеджменту, так і
їх практичну реалізацію в GameDev-сфері. Створено покроковий приклад
упровадження проєктного підходу до розробки комп’ютерної гри, включно з
аналізом витрат, розрахунком операційних показників, плануванням
амортизаційних і кредитних процесів, прогнозом грошових потоків та оцінкою
ефективності.
Другий розділ було присвячено організації та плануванню розробки гри як
цілісного IT-проєкту, а третій — її економічному обґрунтуванню та визначенню
фінансової доцільності.
Результати проведених розрахунків підтверджують економічну
ефективність проєкту створення гри. Чист
38788,10 тис. грн, індекс дохідності — 37,и7й7 дисконтований прибуток становить
, а строк окупності — 0,26 роки, що
свідчить про високу інвестиційну привабливість та доцільність впровадження
проєкту.
Розроблений проєкт має значне практичне значення для ІТ-компаній, які
спеціалізуються на створенні комп’ютерних ігор, оскільки демонструє
можливість застосування структурованого проєктного підходу для підвищення
ефективності GameDev-процесів і оптимізації використання ресурсів.
93
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Schell J. The Art of Game Design: A Book of Lenses. – Boca Raton: CRC Press,
2019.
2. Project Management Institute. A Guide to the Project Management Body of
Knowledge (PMBOK® Guide). – 7th ed. – Newtown Square, PA: PMI, 2021.
3. Бушуєв С.Д., Бушуєва Н.С. Управління проектами: Підручник. – К.:
КНУБА, 2010.
4. Keith C. Agile Game Development with Scrum. – 2nd ed. – Upper Saddle River,
NJ: Addison-Wesley, 2010.
5. Rubin K.S. Essential Scrum: A Practical Guide to the Most Popular Agile Process.
– Boston: Addison-Wesley, 2013.
6. Anderson D.J. Kanban: Successful Evolutionary Change for Your Technology
Business. – Sequim, WA: Blue Hole Press, 2010.
7. Chandler H.M. The Game Production Handbook. – 4th ed. – Boca Raton: CRC
Press, 2014.
8. Ammann P., Offutt J. Introduction to Software Testing. – 2nd ed. – Cambridge:
Cambridge University Press, 2016.
9. Johnson G., Scholes K., Whittington R. Exploring Strategy. – 11th ed. – Harlow:
Pearson, 2017.
10. Wheelen T.L., Hunger J.D. Strategic Management and Business Policy:
Globalization, Innovation, and Sustainability. – 14th ed. – Harlow: Pearson, 2015.
11. Kotler P., Keller K.L. Marketing Management. – 16th ed. – Harlow: Pearson,
2016.
12. Larson E.W., Gray C.F. Project Management: The Managerial Process. – 8th ed.
– New York: McGraw-Hill, 2021.
13. Lock D. Project Management. – 10th ed. – Farnham: Gower, 2013.
14. Schwalbe K. Information Technology Project Management. – 8th ed. – Boston:
Cengage Learning, 2016. – 656 p.
15. Adams E. Fundamentals of Game Design. – 3rd ed. – Berkeley, CA: New Riders,
2014. – 576 p.
94
16. Novak J. Game Development Essentials: An Introduction. – 3rd ed. – Clifton
Park, NY: Delmar Cengage Learning, 2012. – 512 p.
17. Chandler H.M., Chandler S.O. The Game Production Handbook. – 4th ed. –
Burlington, MA: Jones & Bartlett Learning, 2014. – 392 p.
18. Meredith J.R., Mantel S.J. Project Management: A Managerial Approach. – 9th
ed. – Hoboken, NJ: John Wiley & Sons, 2014. – 600 p.
19. Verzuh E. The Fast Forward MBA in Project Management. – 5th ed. – Hoboken,
NJ: John Wiley & Sons, 2015. – 544 p.
20. Archibald R.D. Managing High-Technology Programs and Projects. – 3rd ed. –
Hoboken, NJ: John Wiley & Sons, 2003. – 432 p.
21. Pinto J.K. Project Management: Achieving Competitive Advantage. – 4th ed. –
Harlow: Pearson Education, 2016. – 528 p.
22. Burke R. Project Management: Planning and Control Techniques. – 5th ed. –
Chichester: John Wiley & Sons, 2013. – 545 p.
23. Kotler P., Keller K.L. Marketing Management. – 15th ed. – Harlow: Pearson
Education, 2016. – 832 p.
24. Johnson G., Scholes K., Whittington R. Exploring Corporate Strategy. – 9th ed. –
Harlow: Pearson Education, 2011. – 700 p.
25. Тарасюк Г.М. Управління проєктами: навч. посіб. – К.: КНЕУ, 2017. – 384 с.
26. Приймак В.М. Управління проєктами: навч. посіб. – Львів: «Магнолія
2006», 2013. – 320 с.
27. Verma V.K. The Human Aspects of Project Management. Volume One:
Organizational and Human Behavior. – 2nd ed. – Newtown Square, PA: Project
Management Institute, 1996. – 232 p.
28. Pritchard C.L. Communication Tools for Project Managers. – 2nd ed. – Newtown
Square, PA: Project Management Institute, 2014. – 224 p.
29. Bourne L. Stakeholder Relationship Management: A Maturity Model for
Organisational Implementation. – 2nd ed. – Farnham: Gower Publishing, 2015. –
288 p.
95
30. Тесля Ю.М., Кононенко І.В. Інформаційні технології управління проєктами:
навч. посіб. – К.: НТУУ «КПІ», 2013. – 312 с.
31. Cohn M. Agile Estimating and Planning. – Upper Saddle River, NJ: Prentice Hall,
2005. – 368 p.
32. Layton M.C. Agile Project Management for Dummies. – Hoboken, NJ: John
Wiley & Sons, 2012. – 360 p.
33. Project Management Institute. A Guide to the Project Management Body of
Knowledge (PMBOK Guide). – 7th ed. – Newtown Square, PA: PMI, 2021.
34. Pressman R.S., Maxim B.R. Software Engineering: A Practitioner’s Approach. –
8th ed. – New York: McGraw-Hill Education, 2014.
35. Sommerville I. Software Engineering. – 10th ed. – Harlow: Pearson, 2016.
36. Schell J. The Art of Game Design: A Book of Lenses. – 3rd ed. – Boca Raton:
CRC Press, 2019.
37. Fullerton T. Game Design Workshop: A Playcentric Approach to Creating
Innovative Games. – 4th ed. – Boca Raton: CRC Press, 2018.
38. Project Management Institute. Practice Standard for Work Breakdown Structures.
– 2nd ed. – Newtown Square, PA: PMI, 2006.
39. Highsmith J. Agile Project Management: Creating Innovative Products. – 2nd ed.
– Boston: Addison-Wesley, 2010.
40. Project Management Institute; Agile Alliance. Agile Practice Guide. – Newtown
Square, PA: PMI, 2017.
41. Kerzner H. Project Management: A Systems Approach to Planning, Scheduling,
and Controlling. – 12th ed. – Hoboken, NJ: Wiley, 2017.
42. Larson E.W., Gray C.F. Project Management: The Managerial Process. – 7th ed.
– New York: McGraw-Hill Education, 2017.
43. Heagney J. Fundamentals of Project Management. – 5th ed. – New York:
AMACOM, 2016.
44. Park C.S. Contemporary Engineering Economics. – 6th ed. – Boston: Pearson,
2016.
96
45. Project Management Institute. The Practice Standard for Earned Value
Management. – 2nd ed. – Newtown Square, PA: PMI, 2011.
46. McConnell S. Rapid Development: Taming Wild Software Schedules. –
Redmond, WA: Microsoft Press, 1996.
47. Monczka R.M., Handfield R.B., Giunipero L.C., Patterson J.L. Purchasing and
Supply Chain Management. – 6th ed. – Boston: Cengage Learning, 2016.
48. Lysons K., Farrington B. Procurement and Supply Chain Management. – 9th ed.
– Harlow: Pearson, 2016.
49. Turner J.R. Contracting for Project Management. – Aldershot: Gower Publishing,
2003.
50. Микитюк П.П. Управління проектами: навчальний посібник. – Тернопіль:
ТНЕУ, 2014.
51. Juran J.M., Godfrey A.B. Juran’s Quality Handbook: The Complete Guide to
Performance Excellence. — 6th ed. — McGraw-Hill, 2010.
52. Garvin D.A. Managing Quality: The Strategic and Competitive Edge. — New
York: Free Press, 2012.
53. Oakland J.S. Total Quality Management and Operational Excellence: Text with
Cases. — 4th ed. — Routledge, 2014.
54. Evans J.R., Lindsay W.M. Managing for Quality and Performance Excellence. —
11th ed. — Cengage Learning, 2020.
55. Ishikawa K. Guide to Quality Control. — 2nd ed. — Productivity Press, 1986
(класичне джерело, дозволене методичними вимогами).
56. ISO. ISO 9000:2015 Quality Management Systems — Fundamentals and
Vocabulary. — Geneva: International Organization for Standardization, 2015.
57. Deming W.E. The New Economics for Industry, Government, Education. — 3rd
ed. — MIT Press, 2018.
58. Camp R.C. Benchmarking: The Search for Industry Best Practices that Lead to
Superior Performance. — ASQC Quality Press, 2011.
59. Schön D.A. The Reflective Practitioner: How Professionals Think in Action. —
Basic Books, 2016.
97
60. Kerzner H. Project Management: A Systems Approach to Planning, Scheduling,
and Controlling. — 13th ed. — Wiley, 2022.
61. Hillson D. Practical Project Risk Management: The ATOM Methodology. — 3rd
ed. — Berrett-Koehler Publishers, 2022.
62. Hopkin P. Fundamentals of Risk Management. — 6th ed. — Kogan Page, 2023.
63. Bannerman P. Risk Management in Software Development Projects. — Springer,
2019.
64. Highsmith J. Adaptive Leadership and Agile Project Management. — Addison-
Wesley, 2020.
65. Schwaber K., Sutherland J. The Scrum Guide. — Updated 2020.
66. McConnell S. Software Project Survival Guide. — Microsoft Press, 2019
(перевидання).
67. Pressman R.S., Maxim B. Software Engineering: A Practitioner’s Approach. —
9th ed. — McGraw-Hill, 2019.
68. Stallings W. Information Security: Principles and Practice. — 3rd ed. — Pearson,
2018.
69. Tipton H.F., Krause M. Information Security Management Handbook. — 7th ed.
— Auerbach Publications, 2019.
70. Peltier T.R. Information Security Policies, Procedures, and Standards. — 2nd ed.
— Auerbach Publications, 2016.