ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6760| Title: | Управління стартапом з розробки мобільного додатку для обліку та аналізу доходів і витрат користувача |
| Authors: | Данченко, Олена Борисівна Ткаченко, Єгор Валентинович |
| Keywords: | УПРАВЛІННЯ ПРОЄКТАМИ;МОБІЛЬНА РОЗРОБКА;МОБІЛЬНИЙ ДОДАТОК;ОБЛІК ВИТРАТ;ПРОГРАМНІ ЗАСОБИ. |
| Issue Date: | 15-Dec-2022 |
| Abstract: | В час стрімкого розвитку інформаційних технологій людина отримала доступ до великої кількості інформації та нових можливостей. Тепер кожен має доступ до сотень онлайн курсів, тисячі різноманітних книг і статей для покращення професіональних навичок, соціальні мережі і чати що прискорюють комунікацію між людьми по всьому світу. Тепер сильно зросла роль планування та управління в організації використання всіх цих ресурсів. Бізнес використовує системи управління персоналом та товарами, команди розробників користуються системами планування роботи. Використання таких рішень значно прискорює роботу так як допомагає організувати робочі процеси, та виконує велику кількість рутинної роботи автоматично. Мета дослідження полягає в розробці мобільного додатку для управління власними фінансами користувача з використанням проектного підходу до управління. Об’єкт дослідження: Процес розробки та впровадження мобільного додатку для обліку та аналізу доходів і витрат користувача. Предмет дослідження. Проект створення мобільного додатку для обліку та аналізу фінансів. Методи дослідження. Системний аналіз, сітьове планування, метод декомпозиції, методи управління ризиками, метод бюджетування «знизу-нагору», SWOT-аналіз, PEST-аналіз. Апробація результатів роботи. Основні положення і результати кваліфікаційної роботи магістра доповідалися і були обговорені на міжнародній науково-практичній конференції «АКІТ-2022» (Кропивницький, 2022). Публікації. Результати кваліфікаційної роботи магістра опубліковані у збірнику тез доповідей міжнародної науково-практичної конференції: О. Данченко, Є. Ткаченко, С. Олійник, Управління стартапом з розробки мобільного додатку для обліку та аналізу: збірник тез доповідей міжнародної науково-технічної конференції: 10-11 листопада 2022 р. Кропивницький/ Центральноукраїнський національний технічний університет. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6760 |
| Appears in Collections: | 122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Ткаченко Єгор_МСТП-2102_2022-2023.pdf Restricted Access | 3.37 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему: «Управління стартапом з розробки мобільного додатку для
обліку та аналізу доходів і витрат користувача»
Виконав: студент 2 курсу, групи МСТП-2102
спеціальності 122 «Комп’ютерні науки»
(шифр і назва спеціальності)
освітня програма «Управління стартапами
(назва освітньої програми)
і проєктами в галузі інформаційних технологій»
Ткаченко Єгор Валентинович
Керівник Данченко О.Б.
(прізвище та ініціали)
Рецензент Веренич О.В.
(прізвище та ініціали)
Черкаси 2022 року
Бланк завдання на кваліфікаційну роботу магістра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі інформаційних технологій
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_____________ Юрій ТРИУС
«____» ____________ 20__ р.
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Ткаченку Єгору Валентиновичу
(прізвище, ім‘я, по батькові)
1. Тема роботи
«Управління стартапом з розробки мобільного додатку для обліку та аналізу доходів і витрат
користувача»
Керівник роботи Данченко Олена Борисівна, д.т.н, професор
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «14» жовтня 2022 р. №275 /04 .
2. Строк подання студентом роботи «8» грудня 2022 року.
3. Вихідні дані до роботи:
результати та матеріали з проходження виробничої та переддипломної практики
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
1. Аналіз передумов створення проєкту та обґрунтування його реалізації;
2. Формування задуму проєкту та розробка його концепції;
3. Планування та управління проєктом;
4. Процес практичної реалізації проєкту;
Висновки.
3
5. Перелік додатків (з точним зазначенням назв додатків):
А. Схема декомпозицій (поділ тільки за продуктами)
Б . Схема декомпозицій (поділ тільки за процесами)
В. Схема декомпозиції робіт проекту
Г. Перелік робіт проекту
1 . Інструкція користувача
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта
7. Дата видачі завдання _14__._10__.2022 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ з/п Назва етапів кваліфікаційної роботи магістра Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу Виконано
до 14.10.2022
магістра.
2 Аналіз літературних джерел, об’єкту та предмету Виконано
до 29.10.2022
дослідження.
3 Написання теоретичного розділу кваліфікаційної Виконано
до 07.11.2022
роботи магістра.
4 Написання аналітичного розділу (аналіз об’єкту Виконано
до 15.11. 2022
й предмету дослідження).
5 Написання практичних розділів й висновків Виконано
до 29.11.2022
кваліфікаційної роботи магістра.
6 Передзахист кваліфікаційної роботи магістра на Виконано
до 08.12.2022
засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри КН та СА. до 8.12. 2022 Виконано
8 Захист кваліфікаційної роботи магістра. 15.12.2022 Виконано
Студент _____________________________ / Ткаченко Є.В. /
(підпис) ПІБ
Керівник роботи ____________________________ / Данченко О.Б. /
РЕФЕРАТ
Кваліфікаційна робота магістра містить: 79 с., 36 рис., 12 табл., 25
використаних джерел, 4 додатки.
Актуальність теми. В час стрімкого розвитку інформаційних технологій
людина отримала доступ до великої кількості інформації та нових можливостей.
Тепер кожен має доступ до сотень онлайн курсів, тисячі різноманітних книг і статей
для покращення професіональних навичок, соціальні мережі і чати що прискорюють
комунікацію між людьми по всьому світу. Тепер сильно зросла роль планування та
управління в організації використання всіх цих ресурсів.
Бізнес використовує системи управління персоналом та товарами, команди
розробників користуються системами планування роботи. Використання таких
рішень значно прискорює роботу так як допомагає організувати робочі процеси, та
виконує велику кількість рутинної роботи автоматично.
Інформаційні технології стосуються не лише бізнесу, вони передусім створенні
для людей, які також планують свій час та задачі за допомогою календарів в
телефонах, та заміток. Деякі люди, заради оптимізації свого часу та ефективності
роботи, використовують спеціальні додатки для планування власного часу, або
обмеження перегляду веб-ресурсів на протязі дня.
Так само як і час, фінанси потребують управління для раціонального
використання. Облік доходів та витрат дає розуміння про кількість наявних ресурсів,
що є основою для майбутнього планування витрат. Спеціальні інструменти дають
змогу користувачу без навичок та знань в фінансовій області отримати важливу
інформацію для планування використання ресурсів.
Мета та задачі дослідження. Мета дослідження полягає в розробці мобільного
додатку для управління власними фінансами користувача з використанням
проектного підходу до управління.
Для досягнення поставленої мети в досліджені необхідно вирішити такі задачі:
- дослідження ринку послуг та технологій, що пропонують користувачу для
управління власними фінансами в Україні та в світі;
5
- дослідження особливостей методології управління стартап проектами;
- аналіз оточення проекту та формування стратегії;
- обґрунтування доцільності проекту;
- проведення структурного планування;
- розробка компонентів управління проектом;
- аналіз можливостей подальшого удосконалення продукту з метою
збільшення користувачів.
Об’єкт дослідження: Процес розробки та впровадження мобільного додатку
для обліку та аналізу доходів і витрат користувача.
Предмет дослідження. Проект створення мобільного додатку для обліку та
аналізу фінансів.
Методи дослідження. Системний аналіз, сітьове планування, метод
декомпозиції, методи управління ризиками, метод бюджетування «знизу-нагору»,
SWOT-аналіз, PEST-аналіз.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра доповідалися і були обговорені на міжнародній
науково-практичній конференції «АКІТ-2022» (Кропивницький, 2022).
Публікації. Результати кваліфікаційної роботи магістра опубліковані у
збірнику тез доповідей міжнародної науково-практичної конференції: О. Данченко,
Є. Ткаченко, С. Олійник, Управління стартапом з розробки мобільного додатку для
обліку та аналізу: збірник тез доповідей міжнародної науково-технічної конференції:
10-11 листопада 2022 р. Кропивницький/ Центральноукраїнський національний
технічний університет.
Перелік ключових слів: УПРАВЛІННЯ ПРОЄКТАМИ, МОБІЛЬНА
РОЗРОБКА, МОБІЛЬНИЙ ДОДАТОК, ОБЛІК ВИТРАТ, ПРОГРАМНІ ЗАСОБИ
ABSTRACT
Master's qualifying work includes: 79 pp., 36 figures, 12 tables, 25 used sources, 4
appendices.
6
Actuality of theme. During the rapid development of information technologies,
people get access to a large amount of information and new opportunities. Now everyone
has access to hundreds of online courses, thousands of different books and articles to
improve professional skills, social networks and chats that accelerate communication
between people around the world. Now the role of planning and management in organizing
the use of all these resources has greatly increased.
Business uses personnel and product management systems, development teams use
work planning systems. The use of such solutions significantly speeds up work as it helps
organize work processes and performs a large amount of routine work automatically.
Information technology is not only about business, it is primarily created for people
who also plan their time and tasks with the help of calendars in phones and notes. Some
people, in order to optimize their time and work efficiency, use special applications to plan
their own time, or limit the viewing of web resources during the day.
Just like time, finances need management for rational use. Accounting of income and
expenses provides an understanding of the amount of available resources, which is the basis
for future planning of expenses. Special tools allow a user without financial skills and
knowledge to obtain important information for planning the use of resources.
Purpose and tasks of research. The purpose of the research is to develop a mobile
application for managing the user's own finances using a project-based approach to
management.
In order to achieve the set goal, it is necessary to solve the following tasks in the
research:
- market research of services and technologies offered to the user to manage their
own finances in Ukraine and in the world;
- research on the peculiarities of the startup project management methodology;
- analysis of the project environment and strategy formation;
- justification of the feasibility of the project;
- carrying out structural planning;
- development of project management components;
- analysis of the possibilities of further improvement of the product in order to
7
increase users.
Object of research: The process of developing and implementing a mobile
application for accounting and analyzing user income and expenses.
Subject of research: The project of creating a mobile application for accounting and
financial analysis..
Research methods. System analysis, network planning, decomposition method, risk
management methods, bottom-up budgeting method, SWOT analysis, PEST analysis.
Approval of the results of work. The results of the master's qualification work are
published in the collection of abstracts of the student scientific-practical conference of
“ACIT-2022” (Kropyvnytskyi, 2022).
Publications. The results of the master's qualification work were published in the
collection of abstracts of reports of the international scientific and practical conference of:
O. Danchenko, E. Tkachenko, S. Oliynyk. Management of a startup for the development of
a mobile application for accounting and analysis: Collection of abstracts of reports of the
international scientific and practical conference: November 10-11, 2022, Kropyvnytskyi/
Central Ukrainian National Technical University.
The key words: PROJECT MANAGEMENT, MOBILE DEVELOPMENT,
MOBILE APP, ACCOUNTING, SOFTWARE
ЗМІСТ
ВСТУП ............................................................................................................. 10
1. Загальна характеристика ринку IT-послуг та обґрунтування необхідності
реалізації проекту ...................................................................................................... 12
1.1 Аналіз ринку IT-послуг ............................................................................ 12
1.2 Аналіз ринку мобільних додатків ......................................................... 14
1.3 Постановка та обґрунтування проблеми.............................................. 15
1.4 Огляд існуючих інструментів ............................................................... 18
1.4.1 Monefy .................................................................................................. 18
1.4.2 Toshl Finance ........................................................................................ 19
1.4.3 Coin Keeper........................................................................................... 20
Висновки до розділу 1 .................................................................................... 21
2. Формування задуму та розробка концепції проекту ............................... 23
2.1 Аналіз оточення проекту ....................................................................... 23
2.2 Аналіз зацікавлених сторін ................................................................... 23
2.3 Розробка концепції проекту .................................................................. 29
2.4 Учасники проекту ................................................................................... 32
2.5 Життєвий цикл проекту ......................................................................... 33
2.5.1 Результати проекту за фазами життєвого циклу ............................. 35
Висновки до розділу 2 .................................................................................... 37
3. Планування та управління проектом ........................................................ 38
3.1 Планування змісту проекту ................................................................... 38
3.2 Організаційна структура проекту та матриця відповідальності ....... 41
3.3 Розробка календарного плану проекту ................................................ 44
3.4 Планування ресурсів проекту ............................................................... 48
9
3.5 Планування якості проекту ................................................................... 54
3.6 Управління ризиками проекту .............................................................. 57
3.7 Планування закупівель в проекті .......................................................... 64
3.8 Планування комунікацій в проекті ....................................................... 65
Висновки до розділу 3 .................................................................................... 65
4. Практична реалізація продукту проекту .................................................. 66
4.1 Розробка технічних вимог ..................................................................... 66
4.2 Архітектура проекту .............................................................................. 69
4.3 Реалізація проекту .................................................................................. 71
4.4 Аналіз отриманих результатів .............................................................. 82
Висновки до розділу 4 .................................................................................... 83
ВИСНОВКИ ..................................................................................................... 84
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ....................................................... 85
ДОДАТКИ ........................................................................................................ 87
10
ВСТУП
Актуальність теми. В час стрімкого розвитку інформаційних технологій
людина отримала доступ до великої кількості інформації та нових можливостей.
Тепер кожен має доступ до сотень онлайн курсів, тисячі різноманітних книг і статей
для покращення професіональних навичок, соціальні мережі і чати що прискорюють
комунікацію між людьми по всьому світу. Тепер сильно зросла роль планування та
управління в організації використання всіх цих ресурсів.
Бізнес використовує системи управління персоналом та товарами, команди
розробників користуються системами планування роботи. Використання таких
рішень значно прискорює роботу так як допомагає організувати робочі процеси, та
виконує велику кількість рутинної роботи автоматично.
Інформаційні технології стосуються не лише бізнесу, вони передусім створенні
для людей, які також планують свій час та задачі за допомогою календарів в
телефонах, та заміток. Деякі люди, заради оптимізації свого часу та ефективності
роботи, використовують спеціальні додатки для планування власного часу, або
обмеження перегляду веб-ресурсів на протязі дня.
Так само як і час, фінанси потребують управління для раціонального
використання. Облік доходів та витрат дає розуміння про кількість наявних ресурсів,
що є основою для майбутнього планування витрат. Спеціальні інструменти дають
змогу користувачу без навичок та знань в фінансовій області отримати важливу
інформацію для планування використання ресурсів.
Мета та задачі дослідження. Мета дослідження полягає в розробці мобільного
додатку для управління власними фінансами користувача з використанням
проектного підходу до управління.
Задачі, що вирішуються в роботі:
- дослідження ринку послуг та технологій, що пропонують користувачу для
управління власними фінансами в Україні та в світі;
- дослідження особливостей методології управління стартап проектами;
- аналіз оточення проекту та формування стратегії;
11
- обґрунтування доцільності проекту;
- проведення структурного планування;
- розробка компонентів управління проектом;
- аналіз можливостей подальшого удосконалення продукту з метою
збільшення користувачів.
Об’єктом дослідження є процеси розробки та впровадження мобільного
додатку для обліку доходів та витрат користувача.
Предмет дослідження – процеси управління проектом розробки та
впровадження мобільного додатку для обліку доходів та витрат користувача.
У процесі дослідження використовувалися наступні методи:
- теоретичний аналіз джерельної бази, опис та представлення даних;
- STEP аналіз;
- SWOT аналіз;
- логіко-структурний підхід;
- аналіз дерева цілей;
- метод декомпозиції;
- календарне планування;
- метод освоєного обсягу.
Люди користуються різноманітними мобільними додатками для спрощення
повсякденних задача, це стало невід’ємною частиною нашого життя. Враховуючи це
логічним є рішення про розробку мобільного додатку завдяки якому користувач має
можливість вести облік доходів та витрат у зручний спосіб.
Розробка та впровадження цього продукту не потребує серйозних витрат на
старті. Після створення продукту з мінімальним функціоналом, почнеться залучення
користувачів до безкоштовної версії та збір відгуків про роботу додатку, згодом
будуть додані платні підписки які будуть включати безкоштовний функціонал та
додаткову аналітичну інформацію по доходам та витратам за періоди, можливості
інтеграцій с іншими системами.
12
1 ЗАГАЛЬНА ХАРАКТЕРИСТИКА РИНКУ IT-ПОСЛУГ ТА
ОБҐРУНТУВАННЯ НЕОБХІДНОСТІ РЕАЛІЗАЦІЇ ПРОЕКТУ
1.1 Аналіз ринку IT-послуг
Ринок інформаційних продуктів і послуг представляє великий інтерес для
бізнесів різного розміру та рівня рентабельності. Це зумовлено динамічними темпами
розвитку та революційними змінами в інформаційних технологіях, що дало широкі
можливості по інформатизації будь-якого бізнесу [1].
На кінець 2021 року ринок IT-послуг в Україні перебував в стані активного
зростання, розмір експорту досяг $6,8 млрд, що на $1,8 млрд більше ніж в 2020 році.
Доля IT-послуг в загальному експорті всіх послуг склала 37%, та посіла друге місце
серед найбільших галузей з експорту послуг, поступаючи тільки транспортним
послугам [2].
Експорт комп'ютерних послуг(млн.)
8000
7000
6000
5000
4000
3000
2000
1000
0
2013 2014 2015 2016 2017 2018 2019 2020 2021
Рисунок 1.1 — Графік об’ємів експорту комп’ютерних послуг
Згідно даним НБУ, ріст продовжувався до самого початку війни і в лютому 2022
року досяг значення $839 млн, що на 43% більше за аналогічний період 2021 року [3].
13
За останні півроку будувати довгострокові плани стало неможливим, тож уявити,
яким буде ІТ-ринок через років 5 важко. В нових реаліях IT-індустрії вдалося
консолідуватися та адаптувати формат роботи, завдяки чому більшість компаній
зберегла клієнтів та об’єми контрактів. На березень 2022 року галузь зберегла 96%
об’єму експорту комп’ютерних послуг, $522 млн, відносно аналогічного періоду 2021
року - $546 млн. Проте деякі проекти зупинилися, а нових поменшало, компанії
уповільнили зростання. Відповідно скоротився попит на фахівців.
У 2022 році в світі відбувся економічний спад на який компанії відповіли
зменшенням витрат, щоб заздалегідь убезпечитися від наслідків. Про призупинення
найму чи скорочення команд повідомили й гіганти як Amazon, Snapchat, Tesla,
Google, Microsoft, Meta. Згідно з аналітикою Djinni, зарплатні очікування фахівців
зменшилися, а на одну позицію в середньому претендує 12 спеціалістів, що в 5 разів
більше, ніж в липні 2021-го. Ситуація ще гостріша для джунів — в цій ніші на одну
вакансію відгукується понад 30 спеціалістів. Як наслідок, більшість кандидатів
сьогодні тримаються за робоче місце, що сприяє зменшенню плинності кадрів у
компаніях [4], таку тенденцію можна побачити на гістограмі вакансій та кандидатів.
Рисунок 1.2 — Гістограмі вакансій та кандидатів на платформі Djini
Натомість можна робити короткострокові прогнози на декілька місяців вперед.
14
Зважаючи на досвід 2020 року, коли підвищений попит на початку року змінився
шоком та спадом через пандемію і потім знову зростом попиту, можна вважати, що
спадний тренд обов’язково зміниться висхідним.
1.2 Аналіз ринку мобільних додатків
Смартфон сьогодні – це засіб не тільки для зв’язку, люди залюбки
використовують його в повсякденному житі, для онлайн покупок, розваг,
спілкування, навчання та роботи. Інформаційні технології знайшли застосування
майже у кожній сфері діяльності людини і потреба в них буде тільки зростати.
За останні 10 років частка мобільно трафіку значно зросла, та вже перевищила
часту трафіку від настільних пристроїв, комп’ютерів, ноутбуків [5]. Така тенденція
гарно показана на рис. 1.3.
100
90
80
70
60
50
40
30
20
10
0
2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022
Мобільні Настільні
Рисунок 1.3 — Гістограма розподілу трафіку між мобільним та настільним
пристроями
Одна з причин такої тенденції - стрімкий розвиток інформаційних технологій
спричинив зростання кількості загальнодоступних мобільних застосунків
направлених на рішення різноманітних повсякденних задач користувачів, що дають
можливість ефективніше вирішувати задачі та економити важливі ресурси, час та
15
гроші. Додатки для навчання, карти для навігації, онлайн магазини для покупки
одягу, продуктів харчування, побутових товарів та т.п., все це результат тотального
використання інформаційних технологій в усіх сферах життя людей.
1.3 Постановка та обґрунтування проблеми
Існує багато додатків для планування завдань та роботи. Вони вміщують в собі
зручні функції та перевіренні практики, що використовуються для ефективного
планування та допомагають зекономити багато часу. Так само як і час, фінанси
потребують управління для раціонального використання.
Звичка ефективно управляти своїми фінансами і вміння правильно розподіляти
свої кошти є ключем до економічної стабільності. Фінансово грамотні люди завжди
чітко знають, скільки грошей вони мають та витрачають, і на що саме. У цьому їм
допомагає облік фінансів. Він дозволяє побачити загальну картину, проаналізувати
тенденції та розумно розподіляти витрати [6]. Безконтрольне використання власних
фінансів стає причиною перевищення витрат над доходами. Це змушує залізати в
борги, брати кредити, але контролюючи власний бюджет ви ніколи не потрапите в
подібну ситуацію.
Облік доходів та витрат дає розуміння про кількість наявних ресурсів, що є
основою для майбутнього планування витрат. У випадку якщо людина не має навичок
фінансової грамотності, спеціальні інструменти можуть дати змогу користувачу без
знань в фінансовій області отримати важливу інформацію, в тому числі представлену
у вигляді графіків, для планування використання ресурсів.
Переваги ведення бюджету:
- це дає змогу дізнатись, куди дійсно діваються гроші. Ви швидко знайдете ті
труби, через які вони витікають, побачите реальні об’єми потоків, знайдете
спосіб переправити їх у правильне русло;
- аналіз бюджету допоможе знайти можливості для заощаджень;
- ведення бюджету привчає до дисципліни;
- докладна картина руху персональних фінансів дає змогу краще розуміти
16
цінність грошей, як вони працюють, як їх вигідніше використовувати. Ви
зможете планувати майбутнє, вчасно латати «дірки» й уникати фінансової
скрути.
Для успішного управління фінансами потрібно провести аналіз вашого
поточного фінансового стану та вести облік. Принцип ведення обліку простий –
потрібно регулярно записувати свої доходи та витрати. Так можна реально
оцінювати:
- скільки грошей є на даний час;
- скільки грошей надходить;
- скільки грошей витрачається;
- підсумок місяця.
Гроші - це окремий інструмент, який є еквівалентом виконаної роботи. Особисті
фінанси включають всі доходи та заощадження, наприклад на депозитах у банку, різні
інвестиції – всі доступні для вас кошти. Щодня ми витрачаємо гроші на ведення
домашнього господарства, комунальні платежі, оплату послуг та покупки. До витрат
також входять борги за кредитами або просто позичені у друзів гроші.
Для витрат можна визначити різні пріоритети. Часто виділяють умовні групи:
- обов’язкові витрати – сюди належать витрати на їжу, одяг, особисте
здоров’я, комунальні послуги, товари першої необхідності;
- витрати на розваги;
- кошти для накопичення заощаджень або на погашення боргів.
Доходи та витрати мають різні джерела, бувають разовими або періодичними,
їх можна виокремити в категорії, вся ця інформація є важливою для майбутнього
аналізу. У процесі ведення обліку виникають різні проблеми:
- періодичність та спосіб ведення обліку щоденних витрат;
- планування фінансових заощаджень для майбутніх покупок, яке вимагає
розуміння поточного фінансового стану та статистичні дані, про попередні
доходи та витрати;
- кількість інформації, що з часом невпинно збільшується, що значно
ускладнює обробку;
17
- не рідкістю є ведення спільного бюджету. Проблемою стає доступ до
інформації різними людьми.
Через ці проблеми процес обліку та управління фінансами здається складним і
саме через це більшість людей нехтує контролем своїх витрат. Розглянемо проблеми
які виникають через відсутність контролю використання своїх фінансів на рис 1.4.
Рисунок 1.4 — Дерево проблем в управлінні власними фінансами
Розглянувши детальніше дерево проблем можемо дійти висновку, що
майбутній застосунок, окрім функцій обліку, повинен мати інструменти які
спростять планування майбутніх витрат та заощаджень.
Для кращого розуміння потреб, потрібно також зрозуміти яким буде
потенційний користувач нашого застосунку. Перш за все, застосунок створюється
для людей, тому тип проекту B2C. Розглянемо портрети можливих користувачівна
рисунку 1.5.
Рисунок 1.5 — Портрети потенційних користувачів
18
У додатка широке коло потенційних користувачів, адже управління своїми
витратами і доходами може бути цікавим не залежно від фінансового, сімейного чи
соціального стану.
1.4 Огляд існуючих інструментів
Сьогодні ринок пропонує достатньо багато програмних продуктів, які можуть
допомогти у обліку та контролі власних фінансів, але вони не завжди в повному обсязі
вирішують потреби користувача. Функціональність різних додатків для контролю
фінансів досить схожа. Всі вони реалізують базовий функціонал обліку витрат. Деякі
з них дозволяють вносити суми доходів для відображенням наявних ресурсів. Також
зустрічаються можливості сортування витрат за категоріями та створення нотаток до
витрат. Проте є й додаткові функції, які відрізняють ці застосунки серед інших. Для
кращого розуміння функціональних вимог до мобільного додатку для обліку доходів
та витрат розглянемо детальніше кожен застосунок.
1.4.1 Monefy
Додаток з гарною графікою та простий у використанні. На головному екрані
показана діаграма витрат та доходів користувача, де кожен сектор відповідає одній з
багатьох категорій визначених у системі [6], наприклад: шопінг, розваги, транспорт
та ін. Крім того можна додавати нові категорії та видаляти непотрібні.
Всі дані користувача зберігаються на локальному пристрої у цілях безпеки,
тому використання додатку з декількох пристроїв одним користувачем недоступно.
Проте існує інтеграція с хмарними сервісами, наприклад Dropbox, за допомогою яких
можна синхронізувати файли баз даних, і таким чином синхронізувати додатки на
різних пристроях.
В додатку можна визначити налаштування безпеки та захистити обліковий
запис на пристрої за допомогою пін-кода або створити безліч облікових записів на
одному пристрої.
19
Рисунок 1.5 — Додаток Monefy
1.4.2 Toshl Finance
Найбільш просте та цікаве рішення для контролю особистих витрат. Для
початку потрібно зареєструватися та обрати основну валюту. У додатку реалізовано
тільки базові функції ведення обліку фінансів, які включають облік витрат та доходів,
статистику по всім даним, та панель бюджету, де відображена інфографіка за
наявними ресурсами [7]. Список фінансових операцій в додатку розділений за
календарними днями, також для групування операцій використовують систему міток,
замість категорій. Треба відзначити зрозумілий на інтуїтивному рівні інтерфейс та
візуалізацію статистики по всім операціям. Також доступна платна підписка, яка
дозволяє створювати необмежену кількість даних та експортувати звіти в популярних
форматах.
20
Рисунок 1.6 — Додаток Toshl Finance
1.4.3 Coin Keeper
Додаток веде облік користувача основуючись на покупках та доходах. Можна
визначити ліміти витрат на тиждень, місяць або квартал, наближаючись до якого
додаток буде надсилати повідомлення з нагадуванням. Також можна додавати мітки
та категорії до операцій та отримати детальну статистику витрат та доходів у вигляді
таблиць або графіків [8]. Платна підписка дає дозволяє користуватися одним
обліковим записом з різних пристроїв, це чудово підходить сімейним парам які разом
управляють своїми фінансами.
21
Рисунок 1.7 — Додаток Coin Keeper
Висновки до розділу 1
В цьому розділі було проаналізовано доцільність створення мобільного
застосунку для обліку та аналізу доходів та витрат користувача. Було розглянуто та
обґрунтовано проблему обліку доходів та витрати, побудовано дерево проблеми
контролю фінансів і наведено портрети потенційних користувачів мобільного
додатку. Також були розглянуті існуючі рішення на ринку та порівняно їх
функціональні можливості. В таблиці 1.1 наведено порівняння функціональних
можливостей різних рішень.
22
Таблиця 1.1 — Таблиця порівняння функціоналу застосунків
Назва Monefy Toshl Finance Coin Keeper
Облік фінансів + + +
Доступ з різних
- + +
пристроїв
Візуальна
+ - +
статистика
Налаштування
- - +
лімітів
Інтеграція з
- - +
іншими сервісами
Можливість
налаштувати - - -
категорії
23
2 ФОРМУВАННЯ ЗАДУМУ ТА РОЗРОБКА КОНЦЕПЦІЇ ПРОЕКТУ
2.1 Аналіз оточення проекту
Для аналізу оточення проекту було використано STEP – аналіз. Це
маркетинговий інструмент призначений для визначення соціальних, економічних,
політичних та технологічних аспектів зовнішнього середовища, які можуть вплинути
на організацію. Результати аналізу наведено в таблиці 2.1.
Таблиця 2.1 – STEP-аналіз
Соціальні фактори Технологічні фактори
- рівень доходів та витрат - зрілість технологій
населення - інтеграція з існуючими
- репутація проекту та технологіями
партнерів - рівень компетентності
- думки і ставлення спеціалістів
споживачів - проблеми інтелектуальної
- тенденція способу життя власності
Економічні фактори Політичні фактори
- економічна ситуація та - поточне законодавство на
тенденції ринку
- рівень інфляції - фінансування, гранти та
- оподаткування ініціативи
- інвестиційний клімат в - державне регулювання
галузі конкуренції
- політична стабільність
2.2 Аналіз зацікавлених сторін
Всі організації, групи людей, установи, потенційні користувачі, партнери та
опоненти, які можуть бути причетними до проекту є зацікавленими сторонами.
24
В таблиці 2.2. наведено перелік зацікавлених сторін проекту.
Таблиця 2.2 – Таблиця зацікавлених сторін проекту
Замовник
Роль Замовник, інвестор
Зиск Отримання прибутку та технічного фундаменту для
реалізації нових або додаткових застосунків в
майбутньому
Механізм участі Фінансування, планування, контроль та управління,
прийняття рішень на всіх етапах реалізації проекту
Форма підтримки проекту Фінансування проекту, організація команди та
необхідних ресурсів, сприяння виконанню проекту
Користувачі
Роль Кінцеві споживачі продукту
Зиск Можливість користуватися інструментами управління
доходами та витратами за допомогою мобільного
додатку
Механізм участі Використання продукту, придбання підписки,
створення користувацького досвіду та відгуків про
продукт
Форма підтримки проекту Використання продукту, придбання підписки
Сервіси для інтеграції
Роль Партнери
Зиск Надання користувачам можливості синхронізації
даних з різних додатків
Механізм участі Надання доступу до функцій та даних сервісу
Форма підтримки проекту Додаткові джерела збільшення нових користувачів,
підтримка довіри та іміджу
Продовження таблиці 2.2.
25
Постачальники
Роль Партнери
Зиск Отримання прибутку за рахунок надання послуг та
постачання обладнання
Механізм участі Надання послуг для роботи проекту за умовами
договору
Форма підтримки проекту Постачання послуг та обладнання
Органи влади
Роль Держструктури
Зиск Поповнення державного бюджету
Механізм участі Сертифікування організації, стягнення податків,
контроль над дотриманням норм та законів
Форма підтримки проекту Контроль відносин на ринку, оподаткування.
Допоки зацікавлена сторона отримує свою вигоду від проекту вона буде
продовжувати співпрацю, тому визначимо стратегії взаємодії з кожною зацікавленою
стороною проекту.
Стратегія взаємодії із замовником:
Замовник має завжди отримувати актуальну інформацію про хід виконання
проекту. Також можуть виникати нові вимоги до проекту, на ці зміни потрібно
реагувати та корегувати план. Як інвестор – замовник повинен отримувати фінансову
звітність про витрати на проект.
Стратегія взаємодії з користувачами:
Задоволеність кінцевих користувачів напряму впливає на прибуток проекту,
тому важливо, щоб мобільний застосунок повністю відповідав їх потребам та
вимогам. Дизайн має бути зручним та зрозумілим, націленим на щоденне
використання. Потрібно налагодити канал зворотного зв’язку для оперативного
реагування на скарги та питання користувачів. Залучення нових користувачів має
проводитися в соціальних мережах, групах та каналах з великою аудиторією. Варто
26
проводити аналіз трафіку користувачів, для оптимізації витрат на рекламу в
майбутньому.
Стратегія взаємодії з сервісами для інтеграції:
Сервіси для інтеграції можуть мати певні правила які вони вимагають
виконувати задля безпеки даних користувачів. Довготривала співпраця точно
підвищить лояльність іншого бізнесу та вірогідно збільшить кількість нових
користувачів.
Стратегія взаємодії з постачальниками:
Умови співпраці з постачальниками є взаємовигідними, а саме: за надані
послуги та обладнання замовнику, постачальник отримує прибуток. З огляду на це,
відносини мають бути партнерськими та довготривалими, постачальник отримає
постійного клієнта, а замовник – якісні послуги, технічну підтримку та в
майбутньому може заключити більш вигідний контракт.
Стратегія взаємодії з органами влади:
Під час планування проекту варто звернути увагу на правову складову. Всі
процеси мають бути у рамках закону, особливо у сфері сплати податків та
інтелектуальної власності. Надалі треба проводити моніторинг ситуації та реагувати
на можливі зміни в законах.
Проект існує в середовищі, де постійно взаємодіє з замовником, користувачами,
постачальниками та піддається впливу багатьох зовнішніх та внутрішніх факторів.
Для аналізу цих факторів, зменшення шансів невдач та знаходження точок зростання
проведено SWOT-аналіз. Результати наведено у таблиці 2.3.
Таблиця 2.3 – Матриця SWOT- аналізу
Сильні сторони Слабкі сторони
- невелика команда - брак фінансових
ВНУТРІШНІ розробників ресурсів
ФАКТОРИ - використання новітніх - низький прибуток на
технологій початку
- залучення користувачів з - відсутність репутації у
27
інших інтегрованих сервісів споживачів
- підвищення репутації - виконання умов
шляхом співпраці з сервісів для інтеграції
партнерами
Можливості Загрози
- реалізація нових ідей на - нестабільна ситуація
технічній базі проекту на ринку
- заключення більш вигідних - зміна постачальників
ЗОВНІШНІ
контрактів з - висока конкуренція
ФАКТОРИ
постачальниками - поява нових
- інтеграція з новими технологій
партнерами - втрата репутації у
- розвиток економіки споживача
Визначивши внутрішні та зовнішні фактори можна сформувати шляхи
регулювання проектної ситуації для майбутнього розвитку проекту.
а) Як скористатися можливостями:
1) Розширювати функціонал застосунку враховуючи відгуки та
потреби користувачів;
2) Мотивувати спеціалістів команди проекту;
3) Розширювати та покращувати співпрацю з партнерами та
постачальниками.
б) Що може завадити скористатися можливостями:
1) Недостатня компетентність спеціалістів в команді проекту;
2) Затримки в роботі та неузгодженість дій в команді;
3) Проблеми з просуванням продукту.
в) Як подолати найбільшу небезпеку для компанії:
1) Використовувати правила та норми в процесі виконання проекту;
2) Використовувати додаткові інструменти для управління командою та
28
планування робіт;
3) Залучити кваліфікованих спеціалістів для консультацій з приводу
безпеки та маркетингу.
г) За рахунок чого можна зменшити загрози:
1) Співпраця тільки з попередньо перевіреними партнерами та
постачальниками;
2) Використовувати різні джерела поширення продукту та залучення
нових користувачів;
3) Взаємовигідні умови співпраці з партнерами.
На основі результатів проведеного SWOT-аналізу було виділено та проаналізовано
альтернативи реалізації проекту:
1. Створення застосунку під веб-браузер:
Переваги: Швидка реалізація застосунку, можливість створити мобільну та
комп’ютерну версію інтерфейсу.
Недоліки: Не зручно постійно використовувати застосунок через мобільний
браузер.
2. Створення застосунку під операційну систему Android:
Переваги: Безкоштовне розміщення застосунку в магазині застосунків,
швидка реалізації застосунку.
Недоліки: Застосунок буде недоступний з комп’ютеру та на операційній
системі IOS.
3. Створення застосунку під операційну систему IOS:
Переваги: Велика кількість користувачів IOS зможуть стати потенційними
користувачами застосунку.
Недоліки: Складність реалізації застосунку під операційну систему IOS,
застосунок буде недоступний з комп’ютеру та на операційній системі
Android.
4. Створення застосунку з використанням Progressive Web Application
технології:
Переваги: Швидкість реалізації, використання популярних веб-технологій,
29
доступність додатку на всіх операційних системах.
Недоліки: Однакові функції по різному реалізовані на різних операційних
системах, тому треба проводити перевірку якості роботи застосунку на всіх
платформах.
Серед альтернатив було обрано створення застосунку з використанням
Progressive Web Application технології.
2.3 Розробка концепції проекту
В час стрімкого розвитку інформаційних технологій людина отримала доступ
до великої кількості інформації та нових можливостей. Тепер кожен має доступ до
сотень онлайн курсів, тисячі різноманітних книг і статей для покращення
професіональних навичок, соціальні мережі і чати що прискорюють комунікацію між
людьми по всьому світу. Тепер сильно зросла роль планування та управління в
організації використання всіх цих ресурсів.
Так само як і час, фінанси потребують управління для раціонального
використання. Облік доходів та витрат дає розуміння про кількість наявних ресурсів,
що є основою для майбутнього планування витрат.
Мета проекту: Створення та впровадження мобільного застосунку для обліку
витрат та доходів з використанням технологій управління проектами, що буде
доступний користувачам на всіх операційних системах, буде зберігати інформацію з
усіх пристроїв та дані з інших сервісів та надавати можливість перегляду статистики.
Цілі проекту:
- посилення перспективності проекту шляхом постійної роботи з пошуку
нових партнерів;
- забезпечення економічної ефективності, отримання прибутку від платних
підписок;
- формування бренду.
Продукт проекту: Мобільний застосунок, що відповідає наступним
характеристикам:
30
- підтримка OS: від Android 5 та від iOS 10.3;
- підтримка браузерів: Chrome, Firefox, Safari, Internet Explorer;
- двоетапна автентифікація для кращого захисту облікового запису
користувача;
- доступ до даних з будь-якого пристрою;
- підключення рахунків з облікових записів користувача в доступних додатках
інтернет-банкінгу;
- безкоштовний доступ до базових інструментів для обліку доходів та витрат;
- підключення додаткових функцій шляхом покупки платної підписки.
Критерії успішності проекту:
- кількість зареєстрованих користувачів через рік після запуску – не менше
ніж 30 000;
- кількість постійних користувачів через рік після запуску – не менше ніж
1 000.
Обмеження проекту:
- додаток має однаково працювати на всіх операційних системах та у всіх
браузерах;
- термін – тривалість проекту 12 місяців;
- бюджет – не більш ніж 500 000 грн.
Допущення проекту:
- за трудовими ресурсами – на розробку проекту може вистачити команди з 6
людей. Робочий тиждень складає 5 робочих днів, робочий день 8 годин.
- зменшення / Збільшення вартості різних рівнів підписки в залежності від
стану економіки та попитом користувачів.
- затримка запуску проекту може складати не більше 2 місяців від
запланованого терміну.
На рисунку 2.1 схематично представлено дерево цілей.
31
Рисунок 2.1 – Дерево цілей проекту
Розберемо детальніше цілі проекту та складемо стратегічний план їх
досягнення:
- отримання прибутку:
Проект має отримувати прибуток за рахунок платних підписок. Залучення
нових користувачі є одним із способів збільшення прибутку. Реалізація
додаткових інструментів для аналізу доходів та витрат користувача,
можливість інтеграції з новими сервісами може вплинути на формування ціни.
- посилення перспективності проекту:
У умовах ринкової економіки потрібно постійно реагувати та адаптуватися до
нових змін, щоб проект залишався конкурентоспроможним. Також потрібно завжди
шукати шляхи до розвитку проекту, отримання додаткового прибутку, співпраці з
новими партнерами.
Спеціальна маркетингова компанія має бути націлена на роз’яснення користі
від обліку своїх доходів та витрат і їх аналізі.. Простий інтерфейс та можливість
інтеграції з іншими сервісами спростить процес ведення обліку та позитивно подіє на
формуванні звички щоденного обліку витрат.
Всі ці дії націлені на створення бренду серед застосунків для управління
власними фінансами та підвищення репутації.
- забезпечення економічної ефективності:
Вартість платної підписки не повинна бути занадто високою або низькою, так
32
можна або не набрати потрібну кількість користувачів для виходу на точку
беззбитковості або потрапити в ситуацію коли витрати на підтримку роботи
проекту зростатимуть швидше ніж прибутки від самого проекту.
На основі розглянутої концепції проекту було складено канву бізнес-моделі яку
зображено на рисунку 2.2.
Рисунок 2.2 – Канва бізнес-моделі
2.4 Учасники проекту
На основі результатів аналізу середовища проекту та всіх факторів, що на нього
впливають можемо виділити наступних учасників проекту:
- ініціатор проекту – Власник стартапу;
- замовник проекту – Власник стартапу;
- інвестори - Власник стартапу;
- конкуренти – Інші компанії та застосунки, що надають інструменти для
управління витратами та прибутками;
- органи влади – Податкова;
- постачальники – Постачальники обладнання та послуг;
- партнери – Інші сервіси пов’язані з фінансами;
- кінцеві користувачі – Користувачі мобільних пристроїв.
33
Схему учасників проекту зображено на рисунку 2.3.
Рисунок 2.3 – Схема учасників проекту
2.5 Життєвий цикл проекту
Життєвий цикл проекту по створенню та впровадженню мобільного застосунку
для обліку доходів та витрат користувача складається з наступних фаз:
- ініціалізація;
- планування;
- виконання;
- завершення.
Розглянемо детальніше кожну фазу, дамо їй характеристику, наведемо перелік
основних робіт, допущення та обмеження:
Ініціалізація
Початкова фаза будь-якого проекту яка включає формулювання проблеми,
аналіз рішень та визначення альтернатив рішення цієї проблеми. Дослідження
34
ринку, визначення доцільності реалізації проекту та сбір всієї необхідної
інформації.
Основні роботи:
- аналіз та розробка загальної концепції проекту. Визначення чітких цілей,
завдань, вимог, можливостей, обмежень та очікуваних результатів
проекту;
- створення основних документів: статут проекту, структура організації
команди;
- залучення спеціалістів в команду проекту та проведення співбесід;
- узгодження з замовником основної документації по проекту та плану дій
на початковий період.
Планування:
На основі попереднього аналізу середовища проекту формується команда,
визначаються правила роботи в команді. Всі майбутні роботи детально
плануються, складаються графіки та назначаються відповідальні на кожну задачу.
Основні роботи:
- редагування та затвердження основної документації по проекту;
- затвердження кандидатів до команди за результатами співбесід;
- розробка плану управління проектом: календарного плану та плану
виконання робіт (WBS);
- ініціалізація всіх інструментів управління командою та процесами у
команді та проекті;
- створення та затвердження технічного завдання, визначення технічних
характеристик обладнання необхідного для розробки проекту;
- заключення договорів з постачальниками обладнання та ін.
Виконання:
В цій фазі команда займається реалізацією проекту. Створюється прототип
або мінімальний життєздатний продукт. Такий підхід дає результат в мінімальні
строки, поки команда буде далі розробляти додатковий функціонал для проекту,
маркетинговий відділ вже може займатися залучення користувачів.
35
Основні роботи:
- управління та керування процесом реалізації проекту;
- розробка дизайну інтерфейсу для мобільного застосунку;
- верстка екранів застосунку згідно макетів дизайну;
- розробка серверної частини застосунку, інтеграція з сервісами
партнерів;
- реалізація логіки клієнтської частини застосунку, під’єднання
серверної частини;
- тестування та відлагодження програми;
- ініціалізація кампанії з просування продукту;
- розрішення конфліктних ситуацій.
Завершення:
Налаштування інструментів для моніторингу роботи застосунку та збору
статистики та аналітики використання. Налаштування процесів збору відгуків
та підтримки користувачів. Завершення всіх основних процесів розробки.
Основні роботи:
- розгортання фінальної версії застосунку на сервері, налаштування
збору логів роботи програми та резервного копіювання даних;
- підключення сервісів Google Analytics для аналізу поведінки
користувача;
- формальне завершення всіх проектних етапів.
2.5.1 Результати проекту за фазами життєвого циклу
Ініціалізація:
- розроблена загальна концепція і стратегія проекту;
- узгоджено основні документи про проект.
Планування:
- затверджена основна документація по проекту та технічне завдання;
- затверджено план управління проектом;
- налаштовано інструменти для контролю ведення розробки, перевірки
36
результатів виконання задач та взаємозв’язку між членами команди;
- сформовано команду під проект.
Виконання:
- виконано пакети робіт;
- розроблено та протестовано мінімальний життєздатний продукт;
- опубліковано безкоштовну версію продукту та розпочато рекламну кампанію
із залучення користувачів;
- розроблено та протестовано додатковий функціонал для платних підписок.
Завершення:
- налаштовано систему моніторингу роботи застосунку;
- опубліковано повну версію продукту;
- створено систему підтримки користувачів;
- наказ про завершення проекту.
2.5.2 Стратегія отримання результатів за фазами життєвого циклу
проекту
Ініціалізація:
- проведення детальних співбесід для залучення кваліфікованих спеціалістів до
команди;
- аналіз зовнішнього та внутрішнього середовища проекту, можливостей,
обмежень та загроз.
Планування:
- використання спеціальних інструментів для планування робіт на проекті;
- проведення роз’яснювальної роботи серед команди.
Виконання:
- управління та контроль процесу виконання робіт проекту;
- перевірка якості результатів виконаних робіт.
Завершення:
- аналіз результатів виконаної роботи.
37
Висновки до розділу 2
У розділі було проведено аналіз оточення проекту, описано зовнішні та
внутрішні фактори впливу на проект. Були визначені зацікавлені сторони, що
причетні до проекту, та визначені стратегії взаємодії з кожною зацікавленою
стороною для отримання якнайбільшої вигоди від співпраці. Розроблено концепцію
проекту, створено дерево цілей та канву бізнес-моделі проекту.
38
3 ПЛАНУВАННЯ ТА УПРАВЛІННЯ ПРОЕКТОМ
3.1 Планування змісту проекту
Планування змісту проекту складається з процесів, що направлені на виявлення
робіт необхідних для успішного виконання проекту.
Управління змістом проекту – це процеси, що направлені на визначення всіх,
необхідних для успішного виконання проекту, робіт [12]. До процесів управління
змістом належать:
- визначення змісту – процес створення детального опису продукту та проекту;
- побудова ієрархічної структури робіт (WBS) – процес декомпозиції результатів
проекту та робіт проекту, виконання яких простіше контролювати;
- планування змісту – процес моніторингу рівня виконання проекту та
управління змінами в плані;
- затвердження змісту – процес затвердження виконаних результатів проекту.
Дамо перелік основних робіт, необхідних для виконання проекту:
- створення та затвердження документації до проекту;
- формування стратегії розвитку проекту;
- написання технічного завдання;
- створення концептуальної схеми продукту;
- розробка дизайну інтерфейсу програми;
- розробка прототипу продукту;
- тестування продукту;
- запуст безкоштовної версії продукту;
- проведення рекламної кампанії по просуванню продукту та залученню
користувачів;
- розробка додаткового функціоналу;
- тестування нового функціоналу;
- підготовка спеціалістів для служби підтримки;
- запуст повної версії продукту.
39
Ієрархічна структура робіт (WBS) представляє собою схему в графічному
вигляді, на якій представлені роботи задля їх логічного розподілу. Відношення робіт
між собою та до проекту в цілому представлено рівнями ієрархії, де кожний
наступний рівень містить роботи від яких залежить результат роботи на рівень вище
[14]. Таким чином проводиться декомпозиція робіт і деталізація змісту проекту, що
дає змогу точніше оцінювати об’єм роботи та час необхідний на її виконання.
Ієрархічної структура робіт має відповідати таким правилам:
- кожен елемент має забезпечувати досягнення об’єктивного або
вимірюваного результату;
- кожен елемент має бути агрегатом усіх підпорядкованих елементів, що
знаходяться на рівень нижче;
- декомпозиція має бути логічною на всіх рівнях;
- елементи не повинні дублюватися;
- процес розробки структурної схеми має бути гнучким та адаптивним. Це
дасть змогу редагувати схему в майбутньому, так як не завжди можна
провести достатньо детальну декомпозицію роботи.
Процес створення структури декомпозиції робіт являє собою послідовний
перегляд елементів схеми та розбиття на логічні частини. На початковому етапі
достатньо визначити верхні рівні. Подальшу деталізацію краще проводити вже після
створення технічного завдання.
При розробці схеми декомпозиції можна використовувати поділ «за
продуктами» (рис. 3.1), або поділ «за процесами» (рис. 3.2).
40
Рисунок 3.1 – Схема декомпозиції (поділ «тільки за продуктами»)
Збільшену схему декомпозиції наведено у додатку А.
Рисунок 3.2 – Схема декомпозиції (поділ «тільки за процесами»)
Збільшену схему декомпозиції за процесами наведено у додатку Б.
На головному рівні ієрархічної структури робіт проекту визначено кінцевий
результат проект – створення та впровадження мобільного застосунку. На другому
рівні визначено основні пакети робіт, виконання яких необхідне для отримання
41
кінцевих результатів проекту. Детальну структуру робіт проекту наведено на рис. 3.3.
Рисунок 3.3 – Структура декомпозиції робіт проекту
Збільшену схему декомпозиції робіт проекту наведено в додатку В.
3.2 Організаційна структура проекту та матриця відповідальності
Команда була повністю зібрана з нових спеціалістів. Схема оргструктури
команди проекту наведено на рис. 3.4. За типом організаційна структура команди
проекту відноситься до збалансованої матриці.
Рисунок 3.4 – Організаційна структура проекту
42
Керівник проекту відповідає за визначення функцій, а функціональні керівники
– за їх реалізацію [15]. Керівник відповідальний за розробку загального плану
виконання проекту, під час розробки якого він радиться із спеціалістами різних
галузей в команді. Важливою задачею керівника є складання графіку роботи та
контроль його виконання. Відповідно графіку виконання та загальному плану,
функціональні керівники призначають спеціалістів та відповідають за виконання
своєї частини проекту. Для ефективної роботи така команда потребую тісного зв‘язку
та сумісного вирішення технічних та операційних проблем [16].
На основі розроблених організаційної структури виконавців проекту та
структури декомпозиції робіт проведено розподіл відповідальності між учасниками
проекту по основним проектним роботам. В результаті було сформовано матрицю
відповідальності, в якій визначені ролі виконавців для різних робіт та фаз виконання
проекту. Матрицю наведено у таблиці 3.1.
Таблиця 3.1 – Матриця відповідальності
Основні роботи за
проектом
1 2 3 4 5 6 7 8
(1.1)Розробка проектної В І І П І І І
документації та
узгодження проекту
(1.2.3) Формування В П П І
стратегії проекту
(1.3.1.1) Створення МК П І В П І І
технічного завдання
(1.3.1.2) Створення МК В І І І І
концептуальної схеми
продукту
Менеджер
проекту
Бізнес
аналітик
Дизайнер
Технічний
спеціаліст
Програміст
DevOps
спеціаліст
Маркетолог
43
(1.3.1.3.1) Розробка МК В І І
дизайну продукту
(1.3.1.3.2) Верстка МК І В І
сторінок порталу
(1.3.1.4) Розробка МК І В І
основного функціоналу
порталу
(1.3.2) Закупівля В І І І І
апаратно-програмного
комплексу порталу
(1.3.3) Закупівля МК
контенту
(1.3.4) Розробка кампанії МК П І І В
по просуванню продукту
проекту
(1.4) Тестування системи МК І В П І
(1.5) Запуск продукту у МК І В І П
комерційну
експлуатацію
(1.5.1) Навчання МК В І І І
спеціалістів служби
підтримки абонентів
(1.5.2) Інтеграція порталу МК І І В
на системи компанії
(1.6.1) Підписання В П П
документації про
передачу продукту
замовнику
(1.6.2) Початок кампанії МК І І П П В
44
по просуванню продукту
В – відповідальний
МК – моніторинг та контроль
І – інформаційна підтримка
П – підзвітний відповідальному
3.3 Розробка календарного плану проекту
Календарний план створюється задля визначення дат виконання робіт,
планування дати завершення проекту та контролю працівників та процесу виконання
проекту.
Основні цілі календарного планування:
- моніторинг ходу виконання проекту;
- своєчасного надходження фінансування;
- визначення ступеню завантаження та своєчасне забезпечення ресурсами;
- забезпечення виконання проекту у термін.
Робота над розробкою календарного плану проекту завжди має ітераційний
характер, оскільки під час роботи постійно доводиться повертатись до попередніх
етапів з метою уточнення та деталізації. Розроблений на цьому етапі календарний
план проекту є першим наближеним прогнозом його реалізації. В процесі виконання
проекту, прогноз уточнюється з урахуванням реального дотримання термінів
виконання робіт проекту. Переваги комп'ютерних систем управління проектами
найкраще виявляються саме у процесі створення календарного плану проекту та у
можливості швидкого прогнозування перебігу його реалізації.
Перш за все потрібно визначити повний перелік робіт та пакетів робіт.
Результати робіт мають відрізнятися на всіх рівнях, а рівень деталізації робіт в
пакетах робіт мають забезпечити зручне планування, координацію, та контроль.
Розроблену структуру декомпозиції робіт проекту можна використати за основу
при складані переліку робіт. Нижче наведено приклад заповнення переліку пакетів
робіт та робіт проекту (рис. 3.5).
45
Рисунок 3.5 – Вікно проекту з переліком робіт
Після складання переліку робіт проекту у полі часової діаграми є лінії діаграми,
які починаються і закінчуються одночасно, так як не визначено тривалості робіт.
Потрібно визначити дати початку і закінчення, або тривалість для кожної роботи на
нижньому рівні.
Для визначення дати початку роботи найпростіше скористатись календарем,
який відкривається в комірці стовпця Start навпроти назви роботи. Після визначення
тривалості робіт, перелік робіт має наступний вигляд (рис. 3.6):
46
Рисунок 3.6 – Вікно проекту з визначеною тривалістю робіт
Повний перелік робіт з визначеною тривалістю наведено у Додатку Г.
Фінальним кроком у планування робіт проекту є визначення зв'язків між
роботами. Після визначення послідовності виконання робіт система може обчислити
часовий графік проекту і представити його на діаграмі.
Для зв'язування робіт використовують два основних інструменти: вказування
попередника (роботу зв'язують роботою-попередником проставляючи у стовпці
Predecessor ідентифікатор роботи попередника, або встановлення зв'язку
47
безпосередньо на часовій діаграмі з використанням піктограми зв'язування [10].
Зв'язки між роботами можуть бути чотирьох типів:
- Start to Start (SS) - старт до старту;
- Finish to Finish (FF) - фініш до фінішу;
- Finish to Start (FS) - фініш до старту;
- Start to Finish (SF) - старт до фінішу.
За замовчуванням роботи проекту зв'язуються між собою послідовно, тобто
зв'язком фініш до старту.
Встановлюючи зв'язки між роботами обов'язково потрібно враховувати часові
обмеження на роботи, які можуть бути наступних типів:
- As Late As Possible (ALAP) - так пізно, як це можливо;
- As Soon As Possible (ASAP) - так швидко, як це можливо;
- Finish No Earlier Than (FNET) - фініш не раніше, ніж;
- Finish No Later Than (FNLT) - фініш не пізніше, ніж;
- Must Finish On (MFO) - фініш на визначену дату;
- Must Start On (MSO) - старт визначеної дати;
- Start No Earlier Than (SNET) - старт не раніше, ніж;
- Start No Later Than (SNLT) - старт не пізніше, ніж.
Також потрібно враховувати конкретну дату часового обмеження. Для кожного
типу обмеження, суть і призначення яких стає зрозумілим після уведення
послідовності виконання робіт, логічним є уведення лише пари часових параметрів.
Так, наприклад, для роботи з обмеженням типу MFO логічно визначати дату фінішу і
тривалість. Дата старту в цьому випадку обчислюється автоматично [18].
На початку визначення зв'язків між роботами нашого проекту ми встановили
для всіх робіт обмеження типу ASAP, які відкоригували для окремих робіт згодом
[10].
Після виконання зв’язків робіт календарний план нашого проекту мав
наступний вигляд (рис. 3.7):
48
Рисунок 3.7 – Вікно проекту з вказаними зв’язками між роботами
3.4 Планування ресурсів проекту
Визначення ресурсів проекту
Наступним кроком є планування ресурсів, що полягає у визначені всіх наявних
ресурсів для виконання робіт проекту та їх ефективному розподілі між роботами.
Ресурси в проекті – це робоча сила, техніка, матеріали та гроші, що необхідні
для виконання робіт. В нашому випадку ресурсами проекту є команда проекту.
Планування ресурсів починається з визначення складу ресурсів, тобто
складання переліку людей, що необхідні для виконання проектних робіт [11].
Це можна зробити двома способами:
- призначити ресурси кожній роботі і таким чином сформувати їх перелік;
- скласти перелік ресурсів, а потім призначати до робіт, використовуючи
складений перелік.
Так як ми вже визначили склад команди використаємо другий спосіб.
Програма Microsoft Project в листі ресурсів проекту пропонує наступну
структуру для опису ресурсів:
- Resource Name - назва ресурсу;
- Type - тип (працівник, матеріал);
49
- Material Label - позначення матеріалу;
- Initials - абревіатура працівника;
- Group - група;
- Max. Units - максимальне використання ресурсу;
- Std. Rate - звичайний тариф оплати (протягом робочого часу);
- Ovt. Rate - тариф оплати за роботу в неробочий час;
- Cost/Use - одноразові витрати;
- Accrue At - форма оплати (аванс, погодинно, по факту);
- Base Calendar - базовий календар ресурсу;
- Code - код ресурсу.
Всі члени команди повністю використовуються в роботі, тому потрібно
виставити рівень максимального використання кожного ресурсу рівним 100%. У
випадку, якщо ресурс використовується частково - необхідно вказати відсоток його
використання на проекті.
Результати заповнення таблиці ресурсів даними наведено на рис. 3.8:
Рисунок 3.8 – Заповнення таблиці ресурсів проекту
Призначення ресурсів до робіт проекту
Визначивши ресурси проекту можна почати їх призначення до робіт.
Назначити ресурс на роботу можна у вікні інформації про задачу або безпосередньо
у плані навпроти роботи. В обох випадках потрібно обрати ресурс з переліку та
вказати рівень його використання як зображено на рисунку 3.9.
50
Рисунок 3.9 – Перелік доступних ресурсів проекту для призначення
Після присвоєння ресурсів, їх назви відображаються на діаграмі поруч з лініями
робіт (рис. 3.10):
Рисунок 3.10 – Відображення призначених роботам ресурсів на часовій
діаграмі
51
Вирішення конфліктів ресурсів
Після призначення ресурсів до кожної роботи, Microsoft Project оцінює рівень
навантаження кожного ресурсу, який можна переглянути на графіку перевантаження
ресурсів. На рисунку 3.11 зображений лист ресурсів, після їх призначення, де
червоним виділені ресурси в використані яких виявлено конфлікти. Як видно
більшість ресурсів виявилася перевантаженою.
Рисунок 3.11 – Вигляд перевантажених ресурсів
Також можемо переглянути графік перевантаження для обраного ресурсу, на
якому зображена діаграма використання на часовій шкалі. На рисунку 3.12 наведено
графік перевантаження для ресурсу «Менеджер проекту».
Рисунок 3.12 Графік – перевантаження ресурсу «Менеджер проекту»
У проекті перевантаженими виявились ресурси «Менеджер проекту», «Бізнес
аналітик», «Програміст» та «Маркетолог». Суть перевантаження в тому, що для
виконання призначеної роботи, ресурс має витратити більше часу ніж виділено на
52
роботу. Причин цьому може бути декілька, наприклад:
- призначення ресурсу до завдань, виконання яких повністю або частково
здійснюється в один і той же час;
- збільшення об’єму робіт завдання, що призводить до перевищення
допустимого рівню перевантаження ресурсу;
- призначення ресурсу через зміни у плані може припасти на дні, коли ресурс
недоступний.
Для того, щоб позбавитися перевантаження ресурсів потрібно оптимізувати їх
використання. Оптимізація ресурсів означає:
- згладжування – покращення використання ресурсів в межах визначених
часових резервів;
- вирівнювання – призводить до зміни шляху виконання задач.
Існують інші способи вручну виправити перевантаження ресурсів:
- змінити виконавця роботи, або змінити об’єм роботи ресурсу;
- змінити дати початку робіт в розкладі, щоб використання ресурсів не
накладались;
- позначити роботу як понаднормову.
Перевантаження ресурсів призводить до понаднормової роботи виконавців, що
в свою чергу витрачає важливий час, запас якого має залишатися на випадок настання
ризикових ситуацій на проекті.
Для виконання вирівнювання ресурсів Microsoft Project має інструменти які
автоматично проводять перерозподіл використання ресурсів. Можна виправити
перевантаження як одного так і всіх ресурсів одразу.
Зазвичай, застосовують всі способи оптимізації, так як автоматичні засоби
використовують тільки метод згладжування.
Після зміни виконавців у деяких роботах та автоматичного вирівнювання всіх
ресурсів проекту отримали новий план, який зображено на рисунку 3.14, без
перевантаження ресурсів.
53
Рисунок 3.13 – Завантаженості ресурсів на плані до проведення «згладжування»
Рисунок 3.14 – Завантаженості ресурсів на плані після проведення
«згладжування»
Після калібрування всіх ресурсів вдалося повністю уникнути перевантаження
кожного ресурсу. Тривалість виконання проекту значно зросла, у порівняні з
попередньою оцінкою, проте не перевищує визначених обмежень виконання проекту.
54
3.5 Планування якості проекту
Для контролю рівня якості у проекті визначені такі правила формування якості:
- всі роботи в проекті виконуються після узгодженої настанови з якості;
- використання технологій управління проектами як складової частини системи
управління якістю;
- відповідальний за якість виконання роботи не має бути виконавцем роботи;
- обов’язкове використання сертифікованого обладнання та ліцензованого
програмного забезпечення;
- кожен виконавець відповідає за якість своєї роботи;
- контроль за якістю відбувається на усіх етапах виконання проекту.
Визначимо заходи, які допоможуть в досягти максимальної якості виконання
робіт на кожній фазі проекту:
- Фаза ініціалізації:
Всебічний аналіз ринку та середовища проекту. Об’єктивне визначення
потреб та очікувань потенційних користувачів. Повнота статуту проекту
та техніко-економічного обґрунтування.
- Фаза планування:
Повнота основних нормативних документів та інструкцій, структур
проекту, оцінки ризиків, тощо. Створення правил формування команди,
вимог до кандидатів та рекомендацій щодо побудови ефективних
комунікацій проекту.
- Фаза виконання:
Відповідність результатів робіт внутрішнім та загальновизнаним
стандартам якості. Забезпечення детального та всебічного тестування
продукту з метою виявлення і усунення максимальної кількості помилок
і недоліків на фазі виконання проекту.
- Фаза завершення:
Оцінка та аналіз результатів, термінів та якості виконання проекту.
Створення звітів про результати проекту. Повнота та якість архіву
проекту.
55
Визначимо методи досягнення якості на різних фазах життєвого циклу проекту:
- Фаза ініціалізації:
Залучення висококваліфікованих спеціалістів для проведення детального
аналізу вимог користувачів. Набір працівників в команду на конкурсній
основі.
- Фаза планування:
Залучення висококваліфікованих спеціалістів, урахування якнайбільшого
числа факторів, що можуть впливати на якість виконання робіт.
Підготовка документів з урахуванням досвіду аналогічних проектів.
Виявлення вимог до якості проекту і продукту та визначення шляхів
задоволення цих вимог.
- Фаза виконання:
Залучення висококваліфікованих спеціалістів, забезпечення дисципліни
праці, точне доведення до усіх членів команди їх завдань та обов’язків.
Постійний контроль виконання поставлених задач, сертифікація
обладнання, ліцензування програмного забезпечення, проведення
контрольного тестування продукту.
- Фаза завершення:
Підготовка документів з урахуванням досвіду аналогічних проектів.
Виявлення вимог до якості проекту та якості продукту, визначення
шляхів задоволення цих вимог.
Ключові показники якості наведені у таблиці 3.2.
Таблиця 3.2 – Ключові показники якості
Показники Цільове Допустиме Опис Відповідаль Контролю Етап
значення значення ні ючий
1. 2. 3. 4. 5. 6. 7.
Підтримка iOS від iOS від Версії операційних Технічний Менеджер Фаза
операційних 10,3 та 11,3 та систем на яких спеціаліст, проекту планування,
систем віще віще повинен працювати Програміст Фаза
Android Android застосунок виконання,
від 5,0 та від 6 та Тестування
віще Win віще
56
Phone від
8,0 та
вище
Час До 3х До 3х Час за який Технічний Менеджер Фаза
завантаженн секунд секунд застосунок повинен спеціаліст, проекту планування,
я додатку бути запущений на Програміст Фаза
смартфоні виконання,
Тестування
Час До 5ти До 15ти Час за який контент Технічний Менеджер Фаза
оновлення секунд секунд має бути спеціаліст, проекту планування,
контенту оновлений/відо- Програміст Фаза
бражений на екрані виконання,
телефону Тестування
Бюджет 1,0 млн 1,2 млн Бюджет який Менеджер Замовник На всіх
грн грн допущенній при проекту проекту фазах
створенні
застосунку
Час виконано Допустиме Виконання робіт в Менеджер Замовник На всіх
виконання в термін відхилення термін впливає на проекту проекту фазах
поставлених не пізніше бюджет проекту.
задач 2х тижнів
зазначено-
го терміну
Надійність 100% 100% Відповідність Менеджер На фазі
виконаних кінцевих проекту виконання,
робіт результатів тестування
поставленим цілям
Перевірка
кінцевого
результату згідно
до погоджених
специфікацій та
дизайну додатку
для кожної
операційної
системи на всіх
етапах робіт.
57
3.6 Управління ризиками проекту
Для уникнення та зменшення наслідків негативних подій, що можуть статися
під час виконання проекту, а також наближення позитивних подій, потрібно оцінити
ризики та імовірності цих подій на етапі планування проекту та визначити план дій.
Загальний процес управління ризиками наведено на рис. 3.15.
Рисунок 3.15 – Схема процесу управління ризиками
У проекті було використано наступні процеси управління ризиками:
- планування управління ризиками – визначення підходів та планування
дій по управлінню ризиками проекту;
- ідентифікація ризиків – повторюваний процес, що передбачає пошук
ризиків, що можуть вплинути на проект;
- визначення пріоритетів ризиків;
- кількісний аналіз ризиків проводиться для тих ризиків, які були
кваліфіковані у процесі якісного аналізу як ті, що потенційно або суттєво
мають вплив на конкурентоспроможні якості продукту. В процесі
кількісного аналізу ризиків оцінюється ефект від таки ризикових подій та
присвоюється цифровий рейтинг;
- планування реагування на ризики – розробка шляхів та визначення дій по
збільшенню можливостей та зниженню загроз для цілей проекту;
- контроль управління ризиками – аналізу та планування ризиків що
виникають повторно, відслідковування визначених ризиків, а також
контроль виконання дій по реагуванню на ризики та аналіз їх
ефективності.
58
Для класифікації ступеню впливу ризикової події на хід виконання проекту
приймемо наступну шкалу:
- «0» - ризик не має ні якого впливу;
- «1» - ризик має мінімальний вплив;
- «2» - ризик має невеликий вплив;
- «3» - ризик має помірний вплив;
- «4» - ризик має великий вплив;
- «5» - ризик має надмірно великий вплив.
Розподілимо ймовірність настання ризикової події по наступний іменованих
діапазонах (від 0 до 1, де 0 – подія неможлива, 1 – подія достовірна):
- 0-0.3 – низька;
- 0.3-0.5 – середня;
- 0.5-0.7 – велика;
- 0.7-0.99 – дуже велика.
При реалізації проекту було сформовано наступну ієрархічну структуру
ризиків:
1. Управління проектом:
1.1 Помилки у плануванні.
2. Ресурси:
2.1 Постачальники:
2.1.1 Невиконання умов контрактів постачальниками;
2.1.2 Низька якість послуг що постачається.
2.2 Фінанси:
2.2.1 Збільшення бюджету проекту;
2.2.2 Припинення фінансування проекту.
2.3 Персонал:
2.3.1 Звільнення ключових виконавців;
2.3.2 Низька кваліфікація персоналу;
2.3.3 Низька мотивація персоналу;
2.3.4 Слабкий канал мотивації.
59
3. Технічні:
3.1 Обладнання:
3.1.1 Збій у роботі обладнання;
3.1.2 Невідповідність характеристик обладнання до темпів зростання
запитів системи.
3.2 Програмне забезпечення:
3.2.1 Виявлення помилок при проведенні тестів;
3.2.2 Недостатній функціонал програмного забезпечення.
4. Економічні:
4.1 Інфляція:
4.1.1 Коливання курсу.
4.2 Законодавство:
4.2.1 Зміни у оподаткуванні.
5. Соціальні:
5.1 Рівень життя:
5.1.1 Зниження середнього прибутку населення;
5.1.2 Стиль життя;
5.1.3 Демографічна криза.
6. Комерційні:
6.1 Маркетинг:
6.1.1 Малоефективне просування продукту на ринку;
6.1.2 Хибні дані про стан ринку.
6.2 Продажі:
6.2.1 Відхилення від прогнозу продажів (падіння продажів).
Було сформовано головну таблицю ризиків проекту (табл. 3.3), яка містить
наступні дані:
Таблиця 3.3 – Таблиця ризиків проекту
№ п/п Вид Умова Ризикова подія Наслідки Ймовірність Вплив ОВР
виникнення
1.1 Управління Помилки у Людський Зрив календарного 20 4 0.8
60
проектом плануванні фактор плану, додаткові
витрати на
позапланові ресурси
2.1.1 Ресурси Невиконання Неточність в Затримки у плані 10 4 0.4
умов умовах виконання проекту
контрактів контракту, викликані пошуком
постачальник халатність з нових постачальників
ам и боку або переглядом умов
постачальника. контрактів.
2.1.2 Ресурси Низька якість Висока Зниження іміджу 20 3 0.6
послуг що затримка проекту, невиконання
постачається обробки плану продаж
запитів серверу
2.2.1 Ресурси Збільшення Ріст цін на Призупинення або 8 5 0.4
бюджету товари та закриття проекту
проекту послуги
2.2.2 Ресурси Зупинка Непорозуміння Призупинення 4 5 0.2
фінансування з інвесторами проекту на
проекту проекту невизначений термін
Ресурси Ухід з Високі Затримки в термінах 30 5 1.5
команди навантаження, виконання, додаткові
2.3.1
ключових неконкурентна витрати на пошук та
виконавців заробітна навчання нового
плата, низька співробітника
мотивація
2.3.2 Ресурси Недостатня Економія на Погана якість 10 4 0.4
кваліфікація спеціалістах виконаних робіт,
персоналу додаткові витрати на
тестування та
виправлення помилок
2.3.3 Ресурси Низька Низьке Погана якість та 10 3 0.3
мотивація фінансування, затримки у виконанні
співробітникі високе робіт
в навантаження.
2.3.4 Ресурси Слабкий Відсутність Затримки у виконані 10 4 0.4
канал визначених робіт через
комунікації процедур відсутність контролю
взаємодії ходу реалізації
проекту
3.1.1 Технічні Збій у роботі Зупинка Відсутність доступу 20 3 0.6
обладнання серверів на до застосунку у
61
постачальник яких користувачів, втрата
ів розміщене виручки, втрата часу
програмне на ремонт або
забезпечення постачання і
налаштування нового
обладнання
3.1.2 Технічні Невідповідніс Невірно Незаплановані 10 2 0.2
ть прогнозовані додаткові витрати на
характеристи темпи росту обладнання.
к обладнання навантажень
до темпів
зростання
запитів до
системи
3.2.1 Технічні Знаходження Низький рівень Додаткові витрати 80 1 0.8
помилок при тестування з часу на виправлення
проведенні боку помилок та повторне
тестів співробітника тестування
3.2.2 Технічні Недостатній Невірно Витрати на розробку 30 1 0.3
функціонал функціональні додаткового
програмного вимоги та функціоналу
забезпечення технічне
завдання
4.1 Економічні Інфляція Природне Зростання цін на 90 2 1.8
явище товари та послуги
поза бюджетом
4.1.1 Економічні Коливання Економічна Зростання цін на 80 2 1.6
курсу криза товари та послуги
поза бюджетом
4.2.1 Економічні Зміни законів Зміни в рамках Додаткові витрати на 15 1 0.15
про плану на незаплановані
оподаткуванн наступний рік податкові збори
я або зміна
політики уряду
5.1.1 Соціальні Зниження Економічна Зменшення кількості 70 2 1.4
показників криза користувачів платної
середнього підписки,
доходу невиконання планів
населення продажів
5.1.2 Соціальні Стиль життя Зміна Переорієнтація 20 3 0.6
тенденцій потенційних
62
розвитку користувачів на інші
технології
5.1.3 Соціальні Демографічн Економічна Зменшення кількості 10 2 0.2
а криза криза користувачів платної
підписки,
невиконання планів
продажів
6.1.1 Комерційні Мала Некоректно Невиконання планів 10 4 0.4
ефективність складена продажів
просування маркетингова
продукту на компанія,
ринку недостатнє
фінансування
реклами.
6.1.2 Комерційні Некоректні Погано Некоректна 5 4 0.2
дані про стан проведено маркетингова
ринку аналіз ринку компанії, втрата
потенційних
користувачів
6.2.1 Комерційні Невиконання Високі Зменшення прибутку 50 2 1
планів прогнози проекту
продаж продаж,
неякісне
маркетингове
дослідження
Для проведення загальної оцінки ймовірних впливів ризикових подій на
виконання проекту було визначено матрицю ймовірностей наслідків (табл. 3.4).
Таблиця 3.4 – Матриця ймовірностей та наслідків
Р / Вплив 1 2 3 4 5
0.9 4.1
0.7 3.2.1 5.1.1, 4.1.1
0.5 6.2.1
0.3 3.2.2 2.3.1
0.1 4.2.1 5.1.3, 3.1.2 5.1.2, 3.1.1, 2.3.3, 6.1.2, 6.1.1, 2.3.4, 2.2.2, 2.2.1
2.1.2 2.3.2, 2.1.1, 1.1
63
Для подальшого формування фінансового резерву на управління ризиками
було виявлено згідно табл. 3.4 найбільш впливові ризикові події 4.1, 4.1.1, 5.1.1,
6.2.1.
Визначення резервного фонду:
- 4.1 – за прогнозами інфляція у 2023 році знизиться до 20% на рік, відповідно
це призведе до збільшення витрат на проект до 100 000 грн;
- 4.1.1 – Коливання валют за статистикою відбуваються в межах 20%, тому слід
виділити резерв у розмірі 80 000 грн;
- 5.1.1 – Зниження попиту призведе до зниження прибутку на близько 10%;
- 6.2.1 – розробка маркетингових компаній для просування продукту проекту та
створення адаптивної системи ціноутворення.
Стратегії реагування та конкретні заходи з реагування
- 2.1.1 – пошук та укладання договору з новими постачальниками;
- 4.1, 4.1.1 – виділення фінансів на створення резервів згідно прогнозам;
- 5.1.1, 5.2.1, 6.2. – розробка маркетингових компаній для просування продукту
проекту та створення адаптивної системи ціноутворення;
- 2.3.1, 2.3.3 – моніторинг рівня мотивації співробітників, тренінги, перегляди
розміру оплати;
Моніторинг та контроль
- 2.1.1 – звіти про виконану роботу, індикатором є створений календарний план
виконання робіт;
- 4.1, 4.1.1 – відслідковування основних макроекономічних показників: рівень
інфляції та курс валют;
- 5.1.1, 5.2.1, 6.2.1 – моніторинг результатів ходу рекламної компанії та
аналітики;
- 2.3.1 – моніторинг ринку праці, відслідковування рівня заробітних плат.
Матриця відповідальності за ризики:
Для моніторингу індикаторів ризикових подій було визначено матрицю
відповідальності (табл. 3.5).
64
Таблиця 3.5 – Матриця відповідальності моніторингу ризиків
Ризик Відповідальний
2.1.1 Зрив поставок Менеджер проекту
2.3.1 Ухід ключових спеціалістів Менеджер проекту
4.1 Інфляція Бізнес аналітик
4.1.1 Коливання курсу Бізнес аналітик
5.1.1 Вихід на ринок нових рішень Маркетолог
5.2.1 Зниження доходів населення Маркетолог
6.2.1 Низька якість просування Маркетолог
продукту
3.7 Планування закупівель в проекті
Закупівлі в проекті проводилися за двома напрямками:
- набір команди;
- оренда серверів для роботи.
Набір команди:
Під час відбору спеціалістів до команди слід звернути увагу на рівень
кваліфікації, мотивації та очікування кожного кандидата. Важливо підібрати такого
кандидата, який зможе достатньо якісно виконувати поставлену роботу, якнайменше
впливати на вірогідністю настання ризикової події, зв’язаної з його зоною
відповідальності.
Оренда серверів для роботи:
Для роботи команди над розробкою програмного забезпечення потрібно
використовувати сервери, розгортати версію продукту для розробки та
налаштовувати там системи доставки оновлень.
Також потрібні сервери для тестової версії продукту, що має бути максимально
наближена, по оточенню, до сервера, що буде використовуватись в майбутній
експлуатації.
65
3.8 Планування комунікацій в проекті
Під час роботи над проектом, співробітники постійно мають тримати в курсі
всю команду про стан та результати виконання робіт. Планування комунікацій в
проекті полягає в розробці системи для своєчасного поширення, редагування та
зберігання інформації по проекту.
Використання спеціального програмного забезпечення для управління
задачами команди значно підвищує ефективність роботи всієї команди. Такі
інструменти основуються на певних методологіях розробки програмного
забезпечення, тому слід звернути на це увагу під час підпору програми для управління
задачами команди.
Програмне забезпечення Notion, не призначене саме для управління розробкою
або проектом, проте широкий функціонал повністю покриває потреби команди. В
застосунку є можливості налаштувати таблиці, листи дошки. Можна надавати доступ
до матеріалів всім співробітникам, що дасть змогу всім працювати з однією базою
інформації.
Окрім управління інформацією про стан виконання проекту, важливим є
питання каналів зв’язку з командою. Для підтримки зв’язку та інформування про хід
виконання проекту слід, періодичні, організувати відеоконференції з командою. Для
спілкування між членами команди по робочим питанням використовувати робочі
чати.
Висновки до розділу 3
Було проведено планування проекту згідно міжнародного стандарту
проектного менеджменту РМВоК. В рамках планування було розроблено
календарний план виконання робіт, розписано використання трудових ресурсів,
визначено критерії якості проекту, визначено ризики та план відповіді на ризикові
події. Також було визначено механізми комунікації команди.
66
4 ПРАКТИЧНА РЕАЛІЗАЦІЯ ПРОДУКТУ ПРОЕКТУ
4.1 Розробка технічних вимог
Розробка програмного забезпечення завжди починається із створення
технічного завдання для розробників. Це документ, що встановлює основне
призначення мобільного додатку, структуру проекту, використані методи, технології
та важливі особливості. Технічне завдання це показник якості застосунку, в якому
розписані всі вимоги до функціоналу, згідно яких, в майбутньому, проводиться
тестування продукту.
Функціонал для мобільного застосунку визначається на основі попередніх
результатів аналізу середовища проекту, дослідженнях проблеми обліку доходів і
витрат та існуючих рішень. В таблиці 4.1 наведемо перелік функціональних вимог,
що було визначено, до мобільного додатку для обліку доходів та витрат.
Таблиця 4.1 – Таблиця функціональних вимог
№ Функція Опис Функції Дані
1 Реєстрація Створення нового облікового запису Ім’я, прізвище,
користувачем пошта, пароль
2 Авторизація Вхід в обліковий запис користувача Пошта, пароль
3 Редагування Редагування інформації про користувача в Ім’я, прізвище,
профілю профілі пошта, пароль,
номер
телефону
4 Прив’язка Прив’язка облікового запису до мобільного Номер
двоетапної телефону для захисту даних двоетапною телефону
авторизації авторизацією користувача
5 Видалення Видалення облікового запису користувача,
облікового та всієї інформації, що відноситься до
запису нього
6 Додати витрати Створити запис про нову витрату Сума, категорія
67
витрати, дата
7 Додати дохід Створити запис про новий дохід Сума, категорія
доходу, дата
8 Редагувати Редагувати інформацію про певну витрату Сума, тип
транзакцію або дохід
9 Видалити Видалити певну витрату або дохід з історії
транзакцію користувача
10 Перегляд історії Відображення списку витрат та доходів за Період,
певний період з можливістю фільтрації категорія
транзакції
11 Перегляд Відображення сум витрат та доходів за Період,
статистики категоріями, відсотків від загальної суми категорії
витрат та доходів у вигляді графіків, транзакцій
діаграм і таблиць.
12 Створення Створення нової категорії для витрат або Назва, тип,
категорії доходів, з можливістю задати ліміт на ліміт
місяць
13 Редагування Редагування інформації про певну Назва, тип,
категорії категорію ліміт
14 Видалення Видалити певну категорію
категорії
15 Попередження Надсилання користувачу повідомлення про
про ліміт перевищення заданого ліміту на категорію
16 Прив’язка Прив’язка банківського рахунку до Інформація про
рахунку облікового запису користувача рахунок
17 Видалення Видалення інформації про банківський Інформація про
рахунку рахунок користувача рахунок
68
Кінець таблиці 4.1
18 Призначення Призначення загального ліміту на всі Ліміт
ліміту категорії витрати, коли загальна сума
витрат досягне ліміту, користувач має
отримати повідомлення про ліміт
19 Перегляд Перегляд аналітичної оцінки змін Період,
аналітики статистики витрат та доходів за категорії, тип
категоріями у вигляді графіків та таблиці.
Визначивши функціональні вимоги ми можемо виділити об’єкти і описати їх
структуру, для майбутнього проектування бази даних. Структура об’єктів наведена в
таблиці 4.2.
Таблиця 4.2 – Структура моделей об’єктів у проекті
Назва об’єкту Поле Тип поля
Ідентифікатор Унікальний текст
Ім’я Текст
Прізвище Текст
Пошта Текст
Обліковий запис
Загальний ліміт витрат Число
Тип підписки Тип підписки
Пароль Текст
Дата створення запису Дата
Ідентифікатор Унікальний текст
Користувач Користувач
Назва Текст
Категорія Опис Текст
Ліміт Число
Тип транзакцій Тип транзакції
Дата створення запису Дата
Тип Транзакції Ідентифікатор Унікальний текст
69
Назва Текст
Чи це дохід Логічне значення
Ідентифікатор Унікальний текст
Тип Тип транзакції
Категорія Категорія
Транзакція
Сума Число
Замітка Текст
Дата створення запису Дата
Ідентифікатор Унікальний текст
Назва Текст
Тип підписки
Ціна Число
Дозволи Список дозволів
Ідентифікатор Унікальний текст
Обліковий запис Обліковий запис
Оплата Сума Число
Статус Текст
Дата Дата
Повідомлення Ідентифікатор Унікальний текст
Текст Текст
Дата Дата
4.2 Архітектура проекту
Продукт проекту буде мати багаторівневу клієнт-серверну архітектуру, в якій
функції представлення, обробки та збереження даних розділені. Наведемо детальний
опис кожному рівню.
Клієнт – рівень представлення
В результаті SWOT-аналізу було вирішено використати технологію Progressive
Web Application (PWA) для створення клієнтської частини мобільного застосунку.
PWA дає можливість використовувати веб-технології у створені мобільного додатку,
70
для встановлення застосунку на телефон достатньо відкрити веб-версію і браузер сам
запропонує додати іконку на головний екран телефону.
Основною технологією для розробки логіки було обрано фреймворк React.js, а
саме його розширену версію Next.js, що включає в себе багато інструментів для
оптимізації проекту які значно пришвидшать розробку та добре вплинуть на якість
кінцевого продукту.
Сервер – рівень обробки даних
Основні вимоги до серверу: він має добре справлятися з навантаженнями,
швидко оброблювати запити, повинен легко масштабуватися. З огляду на
обмеженість часу розробки, чудовим вибором для написання серверу є Node.js. Це
платформа для написання високопродуктивних мережевих застосунків мовою
JavaScript. Node.js має асинхронну одно-поточку модель виконання запитів,
неблокуючий ввід\вивід та систему модулів. Платформа є відкритою і дуже
популярною, існує безліч різноманітних бібліотек, які поширюють за допомогою
пакетних менеджерів npm або yarn.
Для прискорення розробки потрібно використовувати фреймворк. Strapi CMS –
це headless CMS на основі Node.js яку можна як завгодно налаштовувати, редагувати
та масштабувати. Інструменти для управління контентом, які включені в Strapi, дуже
спрощують роботу з моделями в базі. Також з легкістю можна налаштувати ролі і
доступи для користувачів додатку.
Панель Адміністратора – рівень представлення
Для контролю роботи застосунку, його підтримки та аналізу роботи проекту
обов’язково має бути розроблена адміністративна панель. Розробка такої панелі являє
собою створення абсолютно окремого застосунку, що сильно впливає на терміни
реалізації всього проекту. Використавши адміністративну панель, що пропонує Strapi
CMS, ми значно прискоримо реалізацію застосунку та зменшимо витрати на розробку
і тестування.
База даних – рівень збереження
При виборі бази даних потрібно звертати увагу на об’єм даних який планується
там зберігати та обробляти, а також їх структуру. В застосунку планується інтеграція
71
з іншими сервісами, що означає постійну роботу з даними нової і різної структури.
Також, через використання Strapi CMS, в нас є деякі обмеження щодо використання
баз даних, а саме, ми можемо використовувати лише ті бази, інтеграція з якими
підтримується Strapi CMS:
- SQLite;
- PostgreSQL;
- MongoDB.
Було обрано Mongo DB – документо-орієнтовану систему керування базами
даних, яка не потребує опису моделей таблиць. Це швидка та масштабована система,
що оперує даними у вигляді ключ\значення.
Рисунок 4.1 – Графічне зображення обраної архітектури проекту
4.3 Реалізація проекту
Сервер є основою роботи всього мобільного додатку, тому реалізація
програмного рішення починається саме з нього. Сервер Strapi CMS створюється
72
шляхом розгортання шаблону сервера, який можна завантажити з офіційного
репозиторію фреймворку.
Після завантаження шаблону сервера і встановлення всіх необхідних пакетів,
сервер вже готовий до роботи. Після запуску одразу з’являється доступ до панелі
адміністратора сервера (рис. 4.2).
Рисунок 4.2 – Вікно панелі адміністратора сервера
Велика перевага Strapi CMS, це те, що частина процесів які потрібно
виконувати при розробці логіки серверу, може бути виконана за допомогою
спеціальних інструментів в панелі адміністратора. Наприклад налаштування моделей
таблиць в базі даних.
Для створення моделей таблиць на сервері було використано схему бази даних,
зображену на рисунку 4.2, створену на основі моделей об’єктів проекту та
функціональних вимогу.
73
Рисунок 4.3 – Схема бази даних
Детальна схема бази даних наведена у Додатку Д.
Спираючись на схему бази даних було створено моделі для таблиць на сервері.
На рисунку 4.4 наведено приклад опису моделі для таблиці категорій.
Рисунок 4.4 – Опис моделі для таблиці категорій
74
Після визначення всіх необхідних полей та зв’язків в моделях можна
приступати до реалізації логіки та створенню API для створення клієнтської частини
проекту. В таблиці 4.3 наведений перелік розроблених методів API.
Таблиця 4.3 – Опис методів для запитів на сервер
Запит Метод Опис Параметри
/auth/login POST Вхід в обліковий запис identifier, password
/auth/register POST Створення облікового first_name, surname,
запису email, password
/auth/forgot-password POST Відправити лист на email
пошту для відновлення
паролю
/auth/reset-password POST Відновлення паролю reset_token, password
/transactions GET Отримати список type, category, _start,
доходів та витрат _limit, _sort
/transactions POST Створити запис про type, category, _start,
витрату або дохід _limit, _sort
/transactions/: id PUT Редагувати запис про type, category, _start,
витрату або дохід _limit, _sort
/transactions/: id DELETE Видалити запис про
витрату або дохід
/categories GET Отримати список
категорій
/ categories POST Створити нову категорію name, description,
limit
/ categories/: id PUT Редагувати запис про name, description,
категорію limit
/ categories/: id DELETE Видалити запис про
категорію
75
Продовження таблиці 4.3
/messages GET Отримати список
повідомлень
/ statistics GET Отримати статистику date_start, date_end,
category, type
Паралельно з розробкою серверної логіки було реалізовано дизайн мобільного
застосунку. Перед дизайнером стояла задача розробити вигляд сторінок, початкова
версія продукту складається з таких сторінок:
- вхід в обліковий запис;
- реєстрація облікового запису;
- панель витрат користувача;
- панель доходів користувача;
- статистика фінансів;
- профіль;
Результати розробки дизайну наведено на рисунках 4.5 – 4.11.
76
Рисунок 4.5 – Сторінка входу
77
Рисунок 4.6 – Сторінка реєстрації
78
Рисунок 4.7 – Сторінка витрат поточних користувача
79
Рисунок 4.8 – Вікно створення витрати
80
Рисунок 4.9 – Сторінка поточних доходів користувача
81
Рисунок 4.10 – Сторінка статистики обліку фінансів користувача
82
Рисунок 4.11 – Сторінка профілю
4.4 Аналіз отриманих результатів
У процесі розробки, з самого початку, було використано Microsoft Project для
моніторингу прогресу виконання проекту та використання ресурсів. На рисунку 4.11
зображено відхилення від плану виконання проекту.
83
Рисунок 4.11 – Відхилення по проекту
Загалом відхилення у виконані задач знаходяться в допустимих межах, а деякі,
виконані швидше ніж планувалося.
На даному етапі були проведені всі роботи необхідні для початку роботи над
розробкою клієнтської частини мобільного додатку.
Висновки до розділу 4
У цьому розділі було розглянуто процес підготовки та визначення
функціональних вимог для мобільного додатку. Описано результати розробки бази
даних, серверної частини додатку та дизайну. Також було проведено аналіз
результатів виконання проекту.
84
ВИСНОВКИ
В час інформатизації в людей з’явилися можливості підвищувати власну
ефективність використовуючи мобільні застосунки які допомагають у вирішені
повсякденних задач. Створення мобільного додатку для обліку спростить ведення
постійних витрат та довгі обрахування статистики і аналізу даних. Особливу увагу
при плануванні було звернено на зручність у використані.
На початку дослідження було визначено ряд завдань, що були вирішені у
наступних розділах дипломної роботи:
У першому розділі роботи було проаналізовано ринок IT-послуг та доцільність
створення мобільного застосунку для обліку та аналізу доходів і витрат користувача.
Було розглянуто та обґрунтовано проблему обліку доходів та витрати, побудовано
дерево проблеми контролю фінансів.
Другий розділ присвячений аналізу оточення проекту і факторів впливу та
формуванню концепції проекту. У розділі визначені цілі та завдання проекту,
проаналізовані стратегії досягнення, побудоване дерево цілей. Результатом роботи в
розділі є стратегічний план, проаналізовані зацікавлені сторони та зроблено прогноз
очікуваних результатів проекту.
Третій розділ включає в себе структурне планування та розробку компонентів
управління проектами. Згідно мети, це самий важливий розділ роботи в якому було
створено організаційну структуру проекту, ієрархічну структуру робіт, що треба буде
виконати, та календарний план відповідно до якого будуть виконуватися роботи
проекту. Також була проведена оцінка ризиків та сплановано дії для їх уникнення.
У четвертому розділі роботи описано процес виконання проекту, а саме початку
розробки програмного забезпечення. Визначено функціональні вимоги до мобільного
додатку та проаналізовано отримані результати.
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. https://itukraine.org.ua/results-of-a-national-study-of-the-it-industry.html
2. https://itukraine.org.ua/report%E2%80%992021-on-the-state-of-the-it-services-
market-in-ukraine-from-beetroot.html
3. https://bank.gov.ua/ua/statistic/macro-indicators
4. https://speka.media/dereva-ne-rostut-do-nebes-abo-yak-zminivsya-ukrayinskii-
rinok-it-za-ostanni-pivroku-v47edv
5. https://web-promo.ua/ua/blog/issledovanie-kak-razvivaetsya-rynok-mobilnyh-
prilozhenij/
6. https://education.24tv.ua/mobilni-dodatki-dlya-obliku-finansiv-kontrolyu-
vitrat_n1614621
7. https://monefy.me/
8. https://toshl.com/ru/
9. https://about.coinkeeper.me/
10. https://eim.snau.edu.ua/wp-content/uploads/2022/02/Управління-
проектами.pdf
11. https://ua-
referat.com/Використання_MS_Project_для_визначення_критичного_шляху
_проекту
12. http://mx.ogasa.org.ua/bitstream/123456789/9317/1/Шаблон%20управління%2
0будівництвом—нова%20інформативно-комунікаційна%20концепція.pdf
13. Гонтарева І. В. Управління проектами: підручник. Х.: ХНЕУ, 2011. 443 с.
14. Кучеренко В. Р. Управління проектами в підприємницьких структурах:
навч.посіб. [Текст] / В. Р. Кучеренко, Е. А. Кузнєцов, О. С. Маркітан; Х.:
Бурун Книга, 2010. -272 с.
15. Петренко Н.О. Управління проектами [текст] навчальний посібник. / Н.О.
Петренко, Л.О. Кустріч, М.О. Гоменюк. – К.: «Центр учбової літератури»,
2015. – 244 с.
16. Управління проектами: Навчальний посібник / Під заг. ред. доц., к.т.н.
86
Шевченко Т.Є. – К.: ІВЦ «Політехніка», 2011. – 237 с.
17. Управління проектами: навч. посіб. / Ю.І. Буріменко, Л.В. Галан, І.Ю.
Лебедєва, А.Ю. Щуровська; за ред. Ю.І. Буріменко. – Одеса: ОНАЗ ім. О.С.
Попова, 2017. – 208 с.
18. Бушуєва Н.С. Управління проектами та програмами організаційного
розвитку: навч. посібн. / Н.С. Бушуєва, Ю.Ф. Ярошенко, Р.Ф. Ярошенко. -
К.: Саммит-Книга, 2010.– 200 с.
19. Козик В.В. Практикум з управління проектами: навчальний посібник / В.В.
Козик, І. Є. Тимчишин; Нац. ун-т «Львів. Політехніка». - Львів: Львівської
політехніки, 2012. - 177 с.
20. Основи індивідуальних компетенцій для Управління проектами, програм та
портфелів Том 1. Управління проектами / Бушуєв С.Д., Бушуєв Д.А.; Під
редакцією Бушуєва С.Д. – К.: «Саміт-Книга», 2017. – 178 С.
21. Филипенко О. М. Управління проектами: навч. посібник / О. М. Филипенко,
Т. С. Колєснік. – Харків : ХДУХТ, 2016. – 161 с.
22. Управління проектами: Підручник. / Ноздріна Л.В., Ящук В.І., Полотай О.І.-
К.: 2010. – 432с.
23. Науковий журнал “Управління проектами, системний аналіз і логістика”
http://upsal.ntu.edu.ua/index.html
24. Васильков В. Г. Організація виробництва / В. Г. Василько. – Київ: Київський
національний економічний університет, 2003. – 524 с.
25. Капінос Г. І. Операційний менеджмент / Г. І. Капінос, І. В. Бабій – Київ:
«Центр учбової літератури», 2013. – 352 с.
ДОДАТКИ
ДОДАТОК А
Рисунок A.1 – Схема декомпозиції (поділ «тільки за продуктами»)
88
ДОДАТОК Б
Рисунок Б.1 – Схема декомпозиції (поділ «тільки за процесами»)
89
ДОДАТОК В
Рисунок В.1 – Схема декомпозиції робіт проекту
ДОДАТОК Г
Название задачи Длительность
Створення і впровадження інформаційно-розважального
163 днів
додатку
Управління Проектом 65 днів
Управління людськими ресурсами 16 днів
Розробка організаційної структури проекту 2 днів
Формування вимог до кандидатів 2 днів
Підбір персоналу в проект 10 днів
Призначення відповідальних 2 днів
Управління змістом 10 днів
Визначення та затвердження змісту проекту 5 днів
Розробка ієрархічної структури робіт 5 днів
Управління строками 10 днів
Складання розкладу 2 днів
Ресурсне планування 3 днів
Розробка та затвердження календарного плану 3 днів
Управління ризиками 6,5 днів
Створення плану управліня ризиками 2 днів
Створення реєстру ризиків 2 днів
Оцінка ризиків 4 ч
Розробка плану реагування на ризики 8 ч
Розробка процедури моніторингу ризиків 4 ч
Управління якістю 11,5 днів
Визначення ключових параметрів якості 2 днів
Визначення процедур контролю 3 днів
Управління вартістю 6 днів
Контроль та моніторинг 3,5 днів
Управління комунікаціями 6,5 днів
Створення плану комунікацій 1 день
Створення розкладу робочих зустрічей 4 ч
Налаштування системи звітності 4 днів
Управління закупівлями 3 днів
Створеня плану закупівель 1 день
Підписання угод з постачальниками 1 день
Ініціалізація 51,5 днів
Формальний початок проекту 0 днів
Призначення менеджера проекту 1 день
Формування стратегії проекту 51,5 днів
Маркетингові дослідження 5 днів
Аналіз оточення проекту 2 днів
Аналіз альтернатив 1 день
Аналіз зацікавлених сторін 2 днів
SWOT-аналіз 2 днів
Розробка та затвердження Статуту проекту 10 днів
Розробка 91,5 днів
Розробка мобільного застосунку 85,5 днів
91
Створення ТЗ 13,5 днів
Розробка ТЗ 9 днів
Розробка бізнес-вимог до продукту (маркетингова
5 днів
частина)
Розробка технічних вимог 3 днів
Розробка вимог до систем моніторингу 1 день
Узгодження ТЗ 4,5 днів
Узгодження бізнес-вимог до продукту (маркетингова
1 день
частина)
Узгодження технічних вимог 1 день
Узгодження вимог до систем моніторингу 1 день
Створення концептуальної схеми продукту 1 день
Розробка дизайн-макету сторінок 46 днів
Розробка дизайну продукту 8 днів
Розробка мобільної версії дизайну застосунку 5 днів
Розробка комп'ютерної версії дизайну застосунку 3 днів
Погодження дизайну 3 днів
Затвердження дизайну 2 днів
Front-End (Верстка) 13 днів
Верстка мобільної версії застосунку 5 днів
Верстка комп'ютерної версії застосунку 3 днів
Розробка основного функціоналу продукту 69 днів
Розробка БД 7 днів
Логічне проектування 5 днів
Фізичне проектування 2 днів
Back-End Розробка функціональної машини продукту 44 днів
Розробка системи авторизації 2 днів
Розробка системи обліку доходів та витрат 7 днів
Розробка функцій отримання статистики 4 днів
Розробка системи аналізу витрат та доходів 10 днів
Розробка системи доступів до функціоналу 3 днів
Розробка механізму інтеграції з іншими сервісами 5 днів
Розробка системи платних підписок 5 днів
Front-End 18 днів
Розробка логіки інтерфейсів авторизації 2 днів
Розробка логіки інтерфейсів обліку доходів та витрат 5 днів
Розробка логіки інтерфейсів статистики 4 днів
Розробка логіки інтерфейсів аналітики 3 днів
Розробка логіки рівнів доступу користувача до
2 днів
застосунку
Розробка логіки інтерфейсів управління обліковим
2 днів
записом
Тестове наповнення БД 2 днів
Закупівля апаратно-програмного компалексу (АПК) 16 днів
Постачання АПК продукту 1 день
Розрахунки з постачальником 1 день
Розробка кампанії по просуванню продукту проекту 6 днів
92
Розробка логотипу 1 день
Розробка банерів 2 днів
Розробка текстів для розміщення в соціальних мережах 3 днів
Тестування системи 42,5 днів
Запуск порталу у тестову експлуатацію 2,5 днів
Розгортання тестової платформи 1,5 днів
Налаштування серверів 4 ч
Розгортання БД 4 ч
Інтеграція продукту в тестове середовище 4 ч
Налаштування системи адміністрування 4 ч
Налаштування системи моніторингу 4 ч
Технічне тестування 2 днів
Тест на граничне навантаження 1 день
Тест відказостійкості системи 1 день
Usability-тестування 17 днів
Формування фокус-груп користувачів 5 днів
Проведення користувацького тестування
12 днів
представниками фокус-груп
Проведення користувацького тестування групою
12 днів
тестувальників
Аналіз отриманих результатів тестування 6 днів
Збір протоколів тестування 2 днів
Формування переліку недоліків 4 днів
Коррегування виявлених недоліків та помилок 5 днів
Проведення контрольного тестування 6 днів
Тестування системи моніторингу 2 днів
Тестування системи адміністрування 2 днів
Запуск продукту у комерційну експлуатацію 2 днів
Навчання спеціалістів служби підтримки 2 днів
Наказ про запуск продукту у комерційну експлуатацію 0 днів
Закриття 10 днів
Передача продукту замовнику 2 днів
Закриття контрактів з постачальниками 1 день
Підписаня документації про передачу продукту 1 день
Початок кампанії по просуванню продукту 8 днів
Розміщення історій з рекламою в Instangam 3 днів
Розміщення рекламних постів в Telegram, Facebook,
5 днів
LinkedIn
Формування проектної документації та передача в архів 3 днів
Аналіз результатів проекту 1 день
Розпуск команди проекту 2 днів
Проект завершено 0 днів
Рисунок Г.1 – Перелік робіт проекту