CC BY
4
УДК 004.052.3:005.8 https://doi.Org/10.35546/kntu2078-4481.2023.3.15
о. г. трофименко
кандидат техшчних наук, доцент, доцент кафедри шформацшних технологш Нацюнальний ушверситет «Одеська юридична академiя» ORCID: 0000-0001-7626-0886
н. i. лог1нова
кандидат педагогiчних наук, доцент, зав^вачка кафедри iнформацiйних технологiй Нацюнальний ушверситет «Одеська юридична академiя» ORCID: 0000-0002-9475-6188
п. о. тесленко
кандидат техшчних наук, доцент, завщувач кафедри штучного штелекту та анатзу даних Нацюнальний ушверситет «Одеська полггехшка» ORCID: 0000-0001-6564-6185
о. с. савельева
доктор техшчних наук, професор, професор кафедри штегрованих технологш управлшня Нацiональний ушверситет «Одеська полггехшка» ORCID: 0000-0002-0453-4777
в. м. поляков
Senior Front End Lead, Krusche & Company ORCID: 0009-0008-0135-0973
КЛАСИФ1КАЦ1Я РИЗИК1В У ПРОЕКТАХ 13 РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Сучасна розробка програмного забезпечення стикаеться з численними ризиками. Щоб залишатися конку-рентними, 1Т-компанИ' мають швидко реагувати та мiнiмiзувати можливi ризики провалу. Проекты з розробки програмного забезпечення мають свою специфi^, пов'язану зi швидкими темпами розробки i з численними змi-нами тд час не!. Природа цих змт е дуже рьзноплановою. Задля пом'якшення ризиюв потрiбне визначення мож-ливих ризиюв, ïx оцтка та план управлiння ризиками. Класифжащя ризиюв, тобто групування пов'язаних титв ризиюв, сприяе бшьш ефективному загальномууправлтню ними. Вона допомагае виявити загальш джереларизи-ку, об'еднати ресурси ризику, точнше застосувати стратеги пом'якшення ризику та управляти взаемозв'язком конкретних ризиюв. Якщо ризики не класифжоват, може вiдбуватися ненавмисне збiгання або суперечливкть роботи з пом'якшення ризиюв, що спричинить проблеми, тобто додатковi негативы ризики. Анализ лтератури виявив вiдсутнiсть единого пiдxоду до класифжациризиюв управлтня проектами з розробки програмного забезпечення. У бiльшостi наявних класифкацт ризиюв не враховуеться специфта проектiв iз розробки програмного забезпечення, нехтуються ризики юбербезпеки. Автори статтi проаналiзували наявнi тдходи до iдентифiкацiï та класифiкацiï ризиюв управлтня проектами i запропонували багатофакторну класифжацт ризиюв у про-грамних проектах, в яюй враховано специфк сфери розробки програмного забезпечення. Застосування тако'1' класифiкацiï сприятиме ясностi та прозоростi у розумтш можливих на^дюв, яюснш оцiнцi ризиюв, ство-ренню ефективно '1' стратеги реагування на ризики та ефективному пом'якшенню ïx. Саме тому керiвники про-грамних проектiв мають знати категори ризиюв та 1'хроль в управлiннi ризиками. Корисно розвивати культуру ^mm^i до ризиюв, яка дозволить компанИ' адаптуватися та швидко реагувати у разi настання цих ризиюв. Систематичне застосування методологи управлiння ризиками та ïï поширення на всю органгза^ю може забез-печити суттеву конкурентну перевагу в умовах дедалi бшьшо'1' невизначеностi.
Ключовi слова: управлiння ризиками, о^нка ризиюв, план управлтня ризиками, розробка програмного забезпечення, ризики програмного проекту.
O. G. TROFYMENKO
Candidate of Technical Science, Associate Professor, Associate Professor at the Department of Information Technologies National University "Odesa Law Academy" ORCID: 0000-0001-7626-0886
N. I. LOGINOVA
Candidate of Pedagogical Sciences, Associate Professor,
Head of the Department of Information Technologies National University "Odesa Law Academy" ORCID: 0000-0002-9475-6188
P. O. TESLENKO
Candidate of Technical Science, Associate Professor, Head of the Department of Artificial Intelligence and Data Analysis Odesa Polytechnic National University ORCID: 0000-0001-6564-6185
O. S. SAVIELIEVA
Doctor of Technical Sciences, Professor, Professor at the Department of Integrated Management Technologies Odesa Polytechnic National University ORCID: 0000-0002-0453-4777
V. M. POLIAKOV
Senior Front End Lead, Krusche & Company ORCID: 0009-0008-0135-0973
CLASSIFICATION OF SOFTWARE PROJECT RISKS
Modern software development faces numerous risks. IT companies must respond quickly and minimize the risk of failure to remain competitive. Software development projects have their own specifics associated with the rapid pace of development and numerous changes during it. The nature of these changes is very diverse. Risk mitigation requires identifying potential risks, assessing them, and developing a risk management plan. Risk classification, that is, the grouping of related types of risks, facilitates more effective overall risk management. It helps identify common sources of risk, combine risk resources, more accurately apply risk mitigation strategies, and manage the interrelationship of specific risks. If risks are not classified, there may be an unintentional overlap or conflict of risk mitigation work, causing problems, i.e. additional negative risks. The analysis of the literature revealed the lack of a unified approach to the classification of software development project management risks. Most existing risk classifications do not consider the specifics of software development projects, cybersecurity risks are neglected. The authors of the article analyzed the available approaches to the identification and classification of project management risks and proposed a multifactor classification of risks in software projects, which considers the specifics of the software development area. The use of such a classification will contribute to clarity and transparency in the understanding of possible consequences, a qualitative assessment of risks, creation of an effective strategy for responding to risks and their effective mitigation. Therefore, project managers need to be aware of risk categories and their role in risk management. It is useful to develop a risk-resilient culture that allows the company to adapt and respond quickly when these risks occur. The systematic application of risk management methodology and its distribution throughout the organization can provide a significant competitive advantage in conditions of increasing uncertainty.
Key words: risk management, risk assessment, risk management plan, software development, software project risks.
Постановка проблеми
На сьогодш програмне забезпечення стало невщдшьною частиною нашого життя через повсюдне викорис-тання цифрових продукпв та послуг. Сучасш програмш технологи стрiмко розвиваються й сприяють появi та без-прецедентному поширенню рiзномaнiтних цифрових продукпв. Ця тенденцiя спостертаеться в бшьшосп сфер життeдiяльностi людей. При цьому проекти, орiентовaнi на використання програмного забезпечення, школи не стають завершеними, осшльки вебсайти та мобшьш застосунки продовжують розвиватися й оновлюватись вщ-повщно до появи новггшх технологш i вимог ктенпв. Ринок програмного забезпечення стрiмко розвиваеться, а сучасна розробка програмного забезпечення стикаеться з численними ризиками через гшерконкурентне серед-овище, яке зосереджуеться на досвщ ктентпв i скороченш часу виходу на ринок. Щоб залишатися конкурент-ними, 1Т-компани мають швидко реагувати на вимоги ктентш, впроваджувати новиш технологи i при цьому враховувати та мiнiмiзувaти можливi ризики провалу.
Проекта з розробки програмного забезпечення (ПЗ) мають свою специфшу, пов'язану 3Í швидкими темпами розробки i з численними змшами пвд час не!. Природа цих змш е дуже рiзноплановою: вщ втiлення новiтнiх вдей у реальшсть задля просування сво!х компанiй та сустльства в цiлому i до збо!в у кiбербезпецi, геополiтичних криз, екстремальних погодних умов та пандемш. Осшльки зараз змши ввдбуваються дуже стршко, управлiння ризиками у проектах iз розробки ПЗ е вкрай важливим. Задля пом'якшення ризик1в потрiбне визначення можли-вих ризикiв, !х оцiнка та план управлiння ризиками. Вчасне реагування, виявлення та врахування тих чи iнших ризик1в дозволить заощадити значнi кошти та задобри репутацiйним втратам для бiзнесу. Але для цього потрь бен постшний всебiчний монiторинг для виявлення, оцшки та пом'якшення ризик1в протягом усього життевого циклу програмного проекту.
Анaлiз останшх досл1джень i публiкацiй
Проблеми та аспекти щентифжацп ризик1в пвд час управл1ння проектами в рiзний час були розглянутi в чис-ленних наукових публiкацiях вiтчизняними i закордонними вченими. Автори статтi [1] дшшли висновку, що вико-ристання категорiй ризик1в для !х щентифшаци та документування створюе всебiчне розумшня того, як в управ-лшш проектом реагувати на ризик для зменшення його впливу. У дослщженш [2] пропонуеться оцiнювати ризики управлшня проектом за п'ятьма критерiями: 1) ризикована подiя, що може статися i вплинути на проект; 2) часовi рамки ризику; 3) ймовiрнiсть настання; 4) очiкуваний вплив; 5) фактори, якi можуть попередити або спровокувати ризиковану подш. Дослвдження [3] класиф^е ризики у розробцi ПЗ за п'ятьма видами: бюджетш, операцшш, технiчнi, програмнi та розкладу. Автори статп [4] стверджують, що групування ризик1в зi схожими характеристиками е фундаментальним для дiяльностi будь-яко! шженерно1 системи, i класифiкувати ризики у середовищi програмно! iнженерil слад за такими категорiями: стратегiчнi, фшансов^ програмнi, операцiйнi, технологiчнi, тех-шчш, зовнiшнi, екологiчнi, органiзацiйнi, проектнi, регуляторш, будiвельнi та пройду. У робот [5] запропоновано використовувати двi загальш категорп ризикiв, у кожнiй з яких згруповано дек1лька типiв ризишв: 1) ризики на основi джерела (внутрiшнi, зовнiшнi, технiчнi, нетехнiчнi, галузев^ загальнi) та 2) ризики на основi впливу на проект (граф^, вартостi, якостi, сфери застосування, ресурав). У статтi [6] ризики класифшэвано за такими основними категорiями: вимог, персоналу, технолопчш, полiтичнi. Дослвдження [7] пропонуе класифiкувати ризики в IT-проектах за чотирма типами: 1) обсягу; 2) планування; 3) ресурснi; 4) технолопчш. Автори статп [8] пропонують класиф^вати ризики за шiстьма факторами: ушкальшсть, складнiсть, припущення та обмеження, люди, стейкголдери, змiни. Дослвдження [9] пропонуе ризики циклу розробки ПЗ класифшувати через зв'язок з одним iз трьох компоненпв (данi, людина, система) i при цьому враховувати ступiнь впливу i вiдповiдальностi результапв оцiнки ризик1в для рiзних методологш розробки ПЗ. Автори роботи [10], намагаючись звузити класи-фiкацiю ризишв, подшивши !х на два типи: явш та неявнi проблеми ризику.
Проведений аналiз наявних дослiджень свiдчить про вiдсутнiсть единого пiдходу до класифжацп ризикiв управлiння проектами, формування реестру ризикiв та створення iерархiчноl структури ризикiв. Через частi змши, з одного боку, та широке розма!ття сфер застосування i засобiв розробки програмного забезпечення, з шшого, наразi використовуються рiзнi пiдходи до класифжацп ризикiв у сферi розробки програмних про-ектiв. Численнi публшацп з цього приводу свiдчать про важливють вирiшення завдання управлiння ризиками при розробщ ПЗ, а повсюдне впровадження iнформацiйних технологiй потребуе шдвищено! уваги до цього напрямку, i ввдповщно, бiльш глибокого висвiтлення питань ризик-менеджменту IT-iндустрil. Проте наразi спостертаеться вiдсутнiсть комплексного i системного шдходу до проблеми критерiзацil й вдентифжаци ризик1в при розробцi ПЗ.
Мета роботи
Порiвняльний аналiз пiдходiв щодо iдентифiкацil ризик1в управлiння проектами та формування класифтаци ризик1в в програмних проектах з урахуванням специфiки сфери розробки ПЗ.
Викладення основного мaтерiaлу дослiдження
Пров1дна професiйна асоцiацiя з управлшня проектами (Project Management Institute, PMI), яка е найбiльшою професшною органiзацiею у сферi управлiння проектами, визначила управлшня ризиками та управлшня яшстю двома основними напрямками Зводу знань про управл1ння проектами (Project Management Body of Knowledge, PMBOK) [11, 12]. З шшого боку, для допомоги оргашзащям в штеграцп ефективно1 структури прийняття рiшень в управлшш ризиками 2018 року розроблено м1жнародний стандарт ISO 31000 [13], на яшй органiзацil можуть орiентуватись у сво1й практицi управлiння ризиками задля надшного забезпечення принципiв ефективного менеджменту та корпоративного управлшня.
Вщповвдно до термшологп управл1ння проектами, рекомендовано1 PMI, ризик - це невизначена подiя або умова, яка, якщо вона трапиться, матиме позитивний або негативний вплив на одну або бшьше цшей проекту, а управлшня ризиками - це процес мiнiмiзацil будь-яких потенцiйних проблем, як1 можуть негативно вплинути на графж проекту [14]. Ризиком може бути будь-яка несподiвана подiя, яка може вплинути на людей, процеси, технологil та ресурси, залучеш до проекту. На ввдм^ вiд проблем, як1 обов'язково виникнуть, ризики - це поди, яш можуть в1дбутися, i неможливо сказати, коли саме. Через цю невизначенють ризики проекту вимагають певно1
подготовки для ефективного управлшня ними. Отже, управлшня ризиками в управлшш проектами - це певна тд-готовка до перешкод 1 проблем, яш можуть завадити устху проекту, та !х виршення.
Д1яльшсть з управлшня ризиками охоплюе так1 основш етапи: виявлення ризишв, !х ощнювання, виб1р метод1в та засоб1в управлшня, запоб1гання, контролювання, фшансування, ощнювання результата. Ризики можуть бути позитивними (можливосп) або негативними (загрози). Оптим1зоване реагування на ризики полягае в постшному ощнюванш ризишв, щоб максим1зувати позитивний вплив та мш1м1зувати негативний вплив на проект та його результата. Отже, по-перше, треба визначити ризики, по-друге, провести комплексну ощнку ризик1в, а, по-трете, варто пвдготувати ввдповщний план управлшня ризиками, який можна буде активувати у раз1 настання проблеми.
Для виявлення потенцшних ризик1в варто скласти список ус1х можливих ризик1в. Щд час процесу планування проекту кер1внику проекту (проектному менеджеру, ПМ) варто попросити допомоги у команди 1 провести моз-ковий штурм 1з досввдченими учасниками проекту та шшими защкавленими сторонами. Поширеним для цього е використання метода Кроуфорда - простого, проте ефективного способу збору 1 пор1вняння пропозицш та щей. При цьому важливо тут не нехтувати ствпрацею команд 1з р1зних вщдшв.
Початкове виявлення ризик1в у проекл варто провести якомога рашше, а надал1 постшно оновлювати про-тягом усього життевого циклу проекту, оскшьки ризики впливають на його важлив1 етапи. Звичайно з часом 1 з досвщом у компани накопичуеться власний каталог можливих ризик1в, з якими вона стикалася у завершених проектах.
При визначенш ризишв корисним для визначення сфер, схильних до ризишв, е класифжащя ризишв по категор1ях 1 р1зновидах. Категори ризишв - це конкретш елементи в рамках проекту або його робочого серед-овища, яш можуть шти не так шд час планування, реал1зацп або подальших еташв д1яльност1 [15]. Категори ризику охоплюють р1зш сфери: витрати, програмне та апаратне забезпечення, наявний персонал, граф1к тощо. Вони враховують складов1, необхвдш для створення усшшного проекту, 1 можлив1 наслщки у раз1, якщо одна або кшька складових вщхиляться вщ нам1ченого курсу поведшки. З1браш по категор1ях ризики забезпечують послщовний спос1б вщстеження того, що може статися з великими обсягами даних, а також розумшня та бачення того, де 1 коли потр1бно пом'якшити вщповщний ризик. Вщстеження ризик1в на р1вш категори дещо спрощуе управлшня ризиками. За допомогою категорш простше групувати ризики для вщстеження та визначення !х прюритепв.
Дослщження та анал1з ознак сучасних ризик1в у проектах 1з розробки ПЗ дозволили згрупувати гх у чотири категори (рис. 1).
Рис. 1. Категори ризишв у проектах i3 розробки ПЗ
Програмно-техшчш ризики пов'язаш з функцюнальшстю та продуктивнiстю програмного продукту чи то його складово1, а також з техшчною складовою забезпечення його розробки. При визначенш перелшу таких ризи-kîb варто вщповюти на питання [5]: 1) чи достатньо е апаратного забезпечення для вах членiв команди; 2) чи е фахiвцi для усунення рiзного роду програмних, апаратних чи то якихось технiчних збо1в, як1 можуть виникнути; 3) чи е доступ до зовшшшх постачальникiв, як1 можуть допомогти; 4) чи створено зручш у користуваннi довщ-ковi керiвництва для впровадження проекту тощо. Приклади таких ризик1в: проблеми з оновленням ПЗ, змшен-ням параметрiв безпеки мереж1, безпекою даних (можливi витоки, пошкодження), змiною вартостi лiцензiï на ПЗ, апаратна поломка, неузгодженiсть формапв даних, змiна вимог до аудиту, шдключення та доступ до мереж!, несумюшсть платформ тощо. Здебiльшого причини програмно-техшчних ризик1в пов'язанi з частими змшами вимог, недостатнiстю квалiфiкованих пращвнишв чи то програмно-апаратного забезпечення, високою складнютю в реалiзацiï, неправильною штегращею модулiв, вразливостями к1бербезпеки тощо. Рiзновидами програмно-тех-нiчних ризик1в е:
• програмт ризики - одш з найважливших ризишв у проектах i3 розробки ПЗ. Вони охоплюють доволi широкий спектр можливих ризишв, осшльки стосуються як розроблюваного програмного продукту, так i узго-джено1 роботи рiзноманiтного ПЗ, використовуваного п!д час всього життевого циклу розробки ПЗ: починаючи ввд програмних засобiв для документування вимог i сшлкування з членами команди та iншими стейкголдерами й зашнчуючи рiзними iнструментами тестування та розгортання. Це рiзнi програмнi фреймворки, бiблiотеки, бази даних, системи контролю версш, хмарнi сховища, текстовi, табличнi та графiчнi редактори, месенджери та ще доволi широкий перелiк специфiчного ПЗ, набiр якого залежить вiд характеру розроблюваного програмного продукту. До того ж сюди варто додати шструменти для оптимiзацiï процесiв 1Т-компанй' i безперебшно1 роботи над проектами у командах, серед яких найбiльш поширеними нинi е: Jira, Trello, Airtable, Worksection, Asana тощо. Цi шструменти дозволяють ошгашзувати спiлкування з ктентами, а також керувати даними, пов'язаними з ктентами, наприклад, збирати вщгуки клiентiв для кращого реагування на 1хш потреби. Що стосуеться розроблюваного ПЗ, то поширеним е ризик погано продуманого, iнтуïтивно незрозумшого або непривабливого UX/UI дизайну продукту. Для усунення цього ризику варто провести глибокий аналiз потреб цiльовоï аудиторiï готового продукту, що дозволить врахувати певнi особливостi при розробщ iнтерфейсу та зручностi використання продукту. 1ншим поширеним ризиком, пов'язаним iз розробкою ПЗ, е проблеми з кодуванням через низьку яшсть коду i поганий стиль програмування. На практицi програмний продукт часто розробляеться одними програмю-тами, а вдосконалюеться i шдтримуеться iншими. Крiм того, технiчне обслуговування е найтривалшим етапом життя програмного продукту. Яшсть орипнального коду сильно впливае на варпсть обслуговування. Програми з низькою яшстю коду можуть спричинити серйозш проблеми в програмних системах;
• mexHi4Hi ризики стосуються будь-яких аспекпв роботи та збоïв у робот численного апаратного забезпечення, залученого як для розробки програмного забезпечення, так i для нормального функцюнування структур-них пiдроздiлiв 1Т-компани. Осшльки спектр та шльшсть використовуваного апаратного забезпечення е доволi масштабним, i здебшьшого таке устаткування е псно взаемопов'язаним iз технологiчним циклом розробки ПЗ, то нехтувати цiею групою ризишв для 1Т-проекпв неприпустимо. До того ж варто зважати на те, що тд час трива-лого життевого циклу розробки ПЗ вщбуваеться постiйна мiграцiя та оновлення ввдповщно1' апаратно1' складово1'. На ринок виходять новi технологiчнi продукти i ршення, з'являються новi гаджети, на яких буде використову-ватись створюване ПЗ, що потребуе перегляду i врахування уах параметрiв пiд час розробки оновлень ПЗ та ввдповщного додаткового тестування [16]. Все зазначене е причиною того, чому 1Т-компанп вважаються органь зацiйними середовищами високого ризику [4];
• ризики cyMicHocmi роботи численних 1Т-компоненпв е специфiчною проблемою, з якою стикаються команди розробки ГГ-проекпв, через складнi залежносп мiж 1Т-складовими: обладнанням, програмним забезпеченням, мережами, даними. На практищ програмш проекти неминуче стикаються з помилками та проблемами 1'х взаемодй, не кажучи вже про численнi оновлення, верси та випуски програмного забезпечення [17]. Як приклад, необхвдшсть узгоджено1' взаемодй' рiзних комп'ютерiв, принтерiв, планшепв, смартфонiв iз рiзними версiями операцшних систем, драйверiв та утилтг у рамках великоï органiзацiï, де працюють тисячi рiзних подiбного роду пристро1в;
• мережевi ризики зумовлеш повсюдним використанням iнтернет-технологiй. Нинi б№шють програмно керованих пристро1в налаштовуються i керуються ктентами через iнтернет-мережу. Це потребуе постшного доступу до мереж1 через Wi-Fi, 4G або 5G. Змшення параметрiв безпеки мереж1 зазвичай впливае на всiх к1нцевих користувачiв або на всi кiнцевi сервери, при чому цей вплив значний, адже все, що тд'еднано до мереж!, з одного боку, зручно оновлювати, зм!нюючи прошивки, а, з шшого боку, небезпечно з точки зору вразливостц
• ризики юбербезпеки розглядають можлив! небезпеки через неналежний захист даних в!д зовшшшх атак. Сучасний цифровий свгт побудований на даних - 1х з6ор!, збертанш, аналiзi, розум!нн! та безпечному обмш. Б!льш!сть програмних систем нин! потребують та використовують р!зного роду конфвденцшш данi клiентiв. Що стосуеться спещального ПЗ для банкiвськоï галуз!, медичних, осв!тн!х та профес!йних сфер, то там персональш дан! е невщдшьною частиною роботи програмних систем [18]. Витоки даних таких систем сильно б'ють по репу-тацiï та чинять велику шкоду орган!зац!ям [19]. Так, за даними IBM Security, середня загальна варпсть витоку даних 2022 року становила 4,35 млн долар!в США [20]. Велика складшсть забезпечення надiйноï к1бербезпеки програмних систем зумовлена р!зними чинниками, насамперед безл!ччю загроз в!д зловмисник1в, як-от: фшин-гов! шахрайства та шахрайства з видаванням себе за !ншу особу, програми-вимагач!, порушення безпеки в хмар!, зловмисне ПЗ для моб!льних пристро1в тощо [21]. Ддевим для змщнення к1бербезпеки е розроблення дорожньоï карти к1берзахисту для визначення област! потенцшних уразливостей, пошуку нових можливостей протистояння к1берзагрозам, оц!нки безпеки продукту. Також важливим е формування та пвдтримка культурного р!вня об!зна-ност! сшвробггаишв i кл!ент!в про к1бербезпеку та дп щодо запоб!гання к!берзагрозам. Нин! в 1Т-компашях все б!льше уваги прид!ляеться !нвестиц!ям у проекти з юбербезпеки. Управлшня ризиками шбербезпеки мае врахову-вати багато р!зних речей та вимагае певних зусиль, щоб максимально пом'якшити ризики.
Зовшшш ризики стосуються всього, що може вплинути на проект, хоча i е поза прямим контролем компанп. Вони переважно стосуються проблем, як! можуть виникнути у субшдряднишв або постачальнишв, наприклад,
у р^ 1х можливоï змiни i того, як це вплине на проект. Також вони стосуються можливих законодавчих змш щодо фiскальноï полiтики, мiждержавних договорiв, вiйн, свiтових коливань цiн на енергоносп, пандемiй тощо. Адже не юнуе жодного програмного проекту, який був би на 100% iзольований вiд впливу зовнiшнiх змiн. Бшьшють зовнiшнiх ризикiв е непередбачуваними: раптовi змiни ринку, поява конкурентного програмного продукту, впро-вадження нових законодавчих акпв, змiни поведiнки та прюритепв споживачiв, клiматичнi, екологiчнi чи сощ-альнi катаклiзми. Так, росiйсько-украïнська вшна е прикладом зовнiшнього ризику, яка суттево вплинула на бiльшiсть 1Т-проекпв (персонал, ланцюги постачання, клiенти, перебо1' з енергоносiями, непередбаченi витрати). Можна видiлити декiлька рiзновидiв зовнiшнiх ризишв:
• ризики 1з зовнштми групами зацкавлених сторт (постачальниками, ментами) переважно стосуються впливу можливих мiжорганiзацiйних проблем у постачальнишв, затримки консультантiв або шдряднишв, пору-шення ланцюга постачання. Зовшшш зацiкавленi сторони - це особлива група людей, як1 формують вимоги, очiкування та цiлi проекту. ïхнi вимоги можуть вiдрiзнятися, збтатися та iнодi суперечити одна однш, що при-зводить до ризишв тд час виконання та здачi проекту. Для цього важлива постшна взаемодiя зi стейкголдерами для своечасного виявлення можливого конфлiкту iнтересiв, прийняття рiшень i вирiшення проблем;
• стратеггчт ризики - е зовшшшми оперативними ризиками, яш можуть вплинути на стратегiчний напрям i виживання компани. Фактори цього типу зовшшшх ризишв охоплюють ризики через хибш бiзнес-рiшення i як наслiдок злиття та поглинання структурних пiдроздiлiв i навиъ компанiй. За даними дослвдження [22] ввдсоток невдач вiд злиття i поглинань становить вiд 70% до 90% угод через неможливють реалiзацiï очiкуваноï ввд них вигоди. Прикрим прикладом невдалого злиття з мшьярдними збитками е угода м1ж eBay i Skype. Враховуючи шльшсть грошей, iнвестованих у такi тдприемства, сам факт бiльшостi невдач свщчить про наявне погане управлшня ризиками. До того ж, ^м спричинених фiнансових втрат, невдалi стратепчш бiзнес-рiшення спричиняють подальшi репутацiйнi ризики. Проте, тут можна навести i дешлька вдалих прикладiв iнтеграцiï злиття 1Т-компанш, наприклад: Apple i Shazam або IBM i Red Hat. Щодо репутацшних ризик1в, то вони можуть стосуватися: проблем управлшня защкавленими сторонами, медшних скандалiв та негативного висвгглення в ЗМ1, втрати довiри мен-тiв та довiри iнвесторiв через негативний досвiд тощо;
• зовтшт фтансовi ризики можуть вплинути на бiзнес з позицп його загально1' фiнансовоï життездатностi. Ц зовнiшнi ризики пов'язанi з ринком, на якому працюе органiзацiя (ринковi ризики), а також здатнiстю викорис-товувати позики (кредитнi ризики) [4]. Прикладами зовшшшх фшансових ризик1в можуть бути: неоч^ваш дй' конкурентiв, витрати внаслшок вiдсутностi активiв i невшомих зобов'язань, невизначена податкова позицiя, тиск ринку, непередбачеш змiни фiнансування тощо. Переважно фiнансовi ризики е добре зрозумшими для управлiння ризик-менеджерам, завдяки численним фiнансовим iнструментам i методам управлшня ними;
• юридичнi ризики стосуються рiзних можливих нормативно-правових, полгтичних, геополiтичних криз, макроекономiчних змiн, яш опосередковано можуть впливати на проект. Наприклад: змши фiскальноï полiтики, загрози судових позовiв та процесiв, змши полггачних факторiв, ризики iнтелектуальноï власносп, розiрвання угоди через антимонопольне законодавство тощо;
• екологiчнi ризики для 1Т-проекпв не так1 частi, як для шших проектiв, проте зважати на них варто. Так, пандемiя COVID-19 е прикладом такого зовшшнього ризику (глобальна криза охорони здоров'я), який суттево вплинув на бшьшють 1Т-проекпв (персонал, ланцюги постачання, витрати тощо). Хоча лвдери компанiй знали про такого роду ризики, проте шхто не уявляв, яш величезш втрати зазнае свiт через коронаврус. Це вказуе на потребу нового мислення для виявлення, управлiння та пом'якшення ризишв протягом усього життевого циклу проекту. До цього виду ризишв також вщносять екстремальнi погодш умови, клiматичнi катаклiзми та катастрофи з еколопчних причин: масштабнi пожежц проблеми сукупного впливу на навколишне середовище, проблеми з як1стю води та повиря, i як наслвдок очiкуваний негативний вплив на людей.
Оргашзацшш ризики стосуються органiзацiйноï зршосп керiвникiв проекту та зацiкавлених сторш, навичок, професiоналiзму та навчання персоналу, аспекпв загальних ресурсiв компанiï, яш можуть вплинути на реалiзацiю проекту. Ул проекти виконуються людьми, включаючи членiв проектноï групи та керiвництво, клiентiв i замовни-к1в, постачальнишв i субпщряднишв, як1 е певною мiрою непередбачуванi та вносять невизначешсть у проекти, над якими вони працюють. Органiзацiйнi ризики пов'язанi з порушеннями внутрiшнiх процедур i систем в орга-нiзацiï, будь-то компашя, департамент, пiдроздiл, команда чи група друзiв у стартапi. До цих ризишв вщносять:
• ризики з персоналом стосуються: недостатносп персоналу, необхщного для вчасного завершення проекту; помилок через недосввдчешсть фахiвцiв, призначених на виконання ключових завдань; втрати одразу декiлькох членiв команди на виршальному етапi проекту, наприклад, у разi 1х хвороби чи то шших життевих колiзiй; змiни персоналу протягом проекту тощо;
• ризики недотримання графта та своечасноï здачi програмного продукту. Наприклад, коли недостатньо часу для планування або коли защкавлеш сторони вимагають пiзнiх змш з тих чи то шших причин. До цiеï групи також вщносять можливi проблеми через внутршню бюрократичну тяганину i, як наслвдок, затримки в отри-маннi погоджених рiшень;
• бюджеmнi ризики можуть стосуватися проблем розподшу та достатносп фшансування i ресурав, проблем з постачанням, своечасноï оплати витрат у повсякденнш б!знес-д!яльносп або того, що впливов! стейкхолдери вимагатимуть додаткових витрат для власних комерцшних цшей;
• ризики планування стосуються мшливосп процеав всередиш оргашзаци, ïï прюритепв, змши вимог та залежностей у проект!, потреби впровадження новишх технологш i переходу на них пвд час роботи над проектом, що може спричинити збоï через несумюшсть штерфейав систем, конфлшт версш, необ!знашсть роботи з ними тощо. До цiеï групи можна вшнести ризики непередбаченого перенавантаження кер!вника проекту, збоï управлшня, появи нового бшьш прюритетного проекту тощо.
Проектш ризики стосуються того, як працюе команда над проектом i яю внутршш аспекти команди можуть вплинути на усшх проекту. Тут передуам варто враховувати можлив! м!жособиспсш проблеми члешв команди, а також те, як вони можуть вплинути на результата. Щ ризики стосуються проблем сформованоï у колектив! культури та морал! команди проекту, наявносп чи то вшсутносп узгодженоï роботи та читсих канал!в зв'язку м1ж членами команди. Р!зновидами проектних ризик1в е:
• ризики цыей проекту загалом пов'язаш з! складшстю або неможливютю досягнення вимог замовника через погане або неповне визначення мети, обсяпв, потреб та результалв проекту, помилки у формуванш граф!ку та плануванш кошторису, складносп одночасноï роботи над багатьма програмними проектами, незаплановану роботу, вшсутшсть контролю над прюритетами персоналу. Вшомо, що понад третину проекпв зазнають невдач! через вшсутшсть чгтких цшей [23]. Сюди можна додати проблеми через вшсутшсть пщтримки вищого кер!вни-цтва, його тиск з метою виконання проекту за прискореним графжом, вшсутшсть координацiï/комунiкацiï з про-ектною командою. Наявнють чiткоï проектноï документаци допомагае ПМ розробити ефективну стратепю для встановлення основних еташв i параметр!в якосп та кiлькiсноï оцшки прогресу проекту;
• ризики операцiйнi стосуються управлшських критерпв, дiловоï д!яльносп кер!вниюв проекту, питань б!з-нес-процеав, бiзнес-iнтеграцiï, оргашзацшних змш, планування та контролю виконання. Важливим тут е визначення прюритепв завдань i подготовка команди до нашмов!ршших перешкод задля швидкого подолання проблем та устшного завершення проекту. Ризики цiеï групи можуть бути спричинеш недостатшм квал!ф!кацшним р!в-нем ПМ, проблемами планування, нечптастю вимог i поганою комушкащею всередиш колективу, а, як наслщок, розповзання обсяпв проекту, перевищення бюджету, порушення графшу проекту. За даними статистики [24], 32% проекпв зазнають невдач! через погане управлшня проектами. Тому до ПМ висуваються висок! вимоги. Вш мае поеднувати в соб! риси та навички стратега i тактика, бути глибоко залученим у проект, ефективно спшкува-тися з командою, створювати мщну оргашзацшну структуру й впроваджувати детальш процеси документування. Немаловажним е наявшсть у ПМ лшерських та аналггачних зд!бностей. Залежно вш обсягу та складносп проекту, значна частина управлшня ризиками кер!вником проекту полягае в тому, щоб прид!лити увагу деталям, вод-ночас пам'ятаючи про загальну картину. Корисно мати детальний план пом'якшення таких ризишв, щоб проект не зашнчився провалом. Спещальне програмне забезпечення для планування проекту може допомогти уникнути багатьох ризишв, яш можуть виникнути у проект!;
• ризики культури спiлкування стосуються формування прозорого робочого середовища, вшкритих канал!в комушкацп та можливостей для члешв команди висловлювати свое бачення без страху бути пока-раним. Команди проекпв складаються з багатьох людей, як! мають р!зш навички, темпераменти, штереси, знання, досвш. Важливо створити i шдтримувати сприятливе для сшвпращ середовище однодумщв. Для формування такого середовища важливим е оргашзацшна i професшна культура, на основ! яких формуеться власна командна культура, яка дае змогу людям працювати разом i забезпечуе синергетичний ефект вш взаемодй. Одним !з наслшшв поганого управлшня проектами, вшсутносп комфортного робочого середовища може бути плиншсть кадр!в: ключов! розробники проекпв залишають команду, не передаючи шкому важ-ливу шформащю про проект, що тягне за собою затримки в розробщ, недотримання термжв i бюджету. Тому важливим е шдив!дуальне та командне навчання для обмшу знаннями й досвшом, що, врештьрешт, забезпечуе гарш результати проекту. Запровадження шструменпв сшвпращ мае життево важливе значення для шд-тримки стейголдер!в, створення централ!зованого центру керування змшами, встановлення чiткоï комушкацп. Надшшсть ПМ не в останню чергу означае активне виявлення конфлшпв м!ж особиспсними штересами та штересами органiзацiï чи кл!енпв. Приблизно 29% проекпв зазнають невдач! [25] через погану комуш-кацш численних стейкголдер!в. Кер!вников! проекту для виршення можливих розб!жностей м!ж стейкгол-дерами мирним шляхом варто послуговуватись стратепями керування оч!куваннями та звггаосп [26] перед вшповвдною групою стейкголдер!в:
o клiенти: головним тут е знання про потреби кл!ента, його культуру та можлив! больов! точки б!знесу. Таю дан! варто з!брати i задокументувати ще до початку виконання проекту. Це допоможе уникати або швидко вирь шувати можлив! конфл!кти;
o члени команди проекту: ключ до керування оч!куваннями команди - постшне сшлкування з ними. ПМ варто запланувати неформальш зустр!ч! в!ч-на-в!ч !з кожним учасником, щоб розумгта настроï та можлив! проблеми
в груш. Для зменшення комyнiкaцiйниx ризишв варто вибрати зручну для вж платформу для ^л^ваняя i ^вп-paцi, cпpоcтити комyнiкaцiйнi потоки проекту, що дозволить комавд бути ефективною;
o кеpiвнuкu: тут варто ^очагку подати кеpiвництвy комплекcний план з оcновними етапами роботи, а нaдaлi поcтiйно шформувати ïx про можливi ризики проекту на оcновi ïxнix iнфоpмaцiйниx потреб;
o менеджеpu pecypcie: ключовим тут е встановлення xоpошиx cтоcyнкiв. Якщо у ПМ xоpошi cтоcyнки з менеджером pеcypciв, то запити на обладнання чи робочу cилy не будуть блокyвaтиcя.
Слад зазначити, що перелш ризик1в розробки ПЗ та методiв ïx зменшення не е вичерпним i може доповнюва-тжя залежно ввд cклaдноcтi проекту, гaлyзi та зовнiшнix обcтaвин. Проте вишкий piвень компетентноcтi ПМ та продумана cтpaтегiя yпpaвлiння ризиками значно знижуе вплив ризик1в на проект.
Специфжа ризик1в у пpоектax iз розробки ПЗ зумовлена тим, що кожен проект е ушкальним, позаяк мае принайми деяк1 елементи, яш paнiше не pеaлiзyвaлиcя, i, природно, з цими елементами пов'язана невизначешсть. Загальною проблемою для вcix програмнт пpоектiв е неpозyмiння та/або невpaxyвaння нефyнкцiонaльниx вимог, тaкиx як продуктивнють, мacштaбовaнicть, вiдмовоcтiйкicть, монiтоpинг i пеpевipкa якоcтi. Цi вимоги нacтiльки ж критичш, як i фyнкцiонaльнi та бiзнеc-вимоги, щоб гарантувати, що доcвiд концевого коpиcтyвaчa вiдповiдaтиме його оч^ванням. Сюди варто додати, що cyчacнi пpогpaмнi проекти переважно е cклaдними, оcкiльки мають iнтегpyвaтиcя з багатьма зовнiшнiми cиcтемaми, наприклад, плaтiжними ^^темами, меcенджеpaми, xмapними cеpвicaми тощо. ^мандам, як1 розробляють комеpцiйнi пpогpaмнi продукта, необxiдно збaлaнcовyвaти швид-кicть розробки, безпеку (включно з конфiденцiйнicтю дант) i взаемодш з коpиcтyвaчем. Hеможливicть устш-ного виконання одного чи декiлькоx з циx тpьоx завдань, cкоpiш за вcе, призведе до провалу проекту [27]. До того ж вимоги до прогр^н^ проекпв можуть змiнювaтиcь. Kожен програмний проект е агентом змш, який pyxaетьcя ввд вiдомого тепеpiшнього до невшомого майбутнього з yciею невизнaченicтю, пов'язаною з таким pyxом. Знати чи передбачити в^, що змiнитьcя за такт умов, неможливо. Анал1з та виявлення ризишв програмного проекту передбачае створення низки припущень щодо майбутнього. Припущення можуть виявитиcя xибними, i ймовipно, що деяк1 з нт зaлишaтьcя пpиxовaними, тобто певним джерелом невизначеноап. yci цi acпекти створюють для пpогpaмниx пpоектiв додaтковi фактори ризику, до якт треба aдaптyвaтиcя.
Висновки
Kлacифiкaцiя ризик1в, тобто групування пов'язaниx типiв pизикiв, cпpияе бшьш ефективному загальному yпpaвлiнню ними. Вона допомагае виявити зaгaльнi джерела ризику, об'еднати pеcypcи ризику, точнiше зacтоcy-вати cтpaтегiï зменшення (пом'якшення) ризику та управляти взаемозв'язком конкpетниx ризишв. Якщо ризики не клаотфжоваш, може в^уват^я ненaвмиcний збiг або cyпеpечливicть роботи з пом'якшення pизикiв, що cпpичинить проблеми, тобто додaтковi негативш ризики. Групування ризик1в за категор1ями та piзновидaми допомагае створити ефективнiшi cтpaтегiï реагування на ризики, дозволяючи комaндi проекту зоcеpедитиcя на типax iз найвищим ризиком, або напрацювати загальну pеaкцiю для будь-акт ризик1в певного типу. Перевагами такого пiдxодy е пвдвищення ефективноcтi використання чacy команди проекту та точшша робота з управл1ння ризиками в цшому. Саме тому ПМ повинш знати категорй' ризик1в та ïx роль в управлшш ризиками.
Ocкiльки вci проекти пiддaютьcя ризику, устшними е тi проекти, в якм цим ризиком управляють правильно. Систематичне зacтоcyвaння методологiï yпpaвлiння ризиками та ïï поширення на вcю оргашзацш може забезпе-чити cyттевy конкурентну перевагу в yмовax дедaлi бiльшоï' невизнaченоcтi. Спецiaлicти-пpaктики з yпpaвлiння проектами шукають новi ефективнi та гнучш iнcтpyменти yпpaвлiння ризиками для тдтримки cвоеï повcякден-ноï роботи, але нapaзi не icнyе yнiвеpcaльного iнcтpyментa, який би задовольнив yci ïxrn потреби. Hинi ризики е лише частиною повcякденноï роботи щодо управлшня ними, ïx оновлення та пом'якшення. Постшно виника-ють ризики, про яш paнiше нaвiть не чули. Змiнюютьcя ментaлiтет i культура, з'являютьcя новi погляди на ризики з позицп aдaптaцiï' та пошуку в нт новиx можливоcтей, щоб забезпечити конкypентоcпpоможнicть i зберегти зaцiкaвленicть кл1енпв у cтвоpювaниx пpогpaмниx пpодyктax. ^ржно розвивати культуру cтiйкоcтi до ризишв, яка дозволить компани aдaптyвaтиcя та швидко реагувати у paзi настання циx ризик1в. Bci члени колективу (мене-джери, кеpiвники, розробники, тестувальники та iн.) повиннi pозyмiти ризики, пов'язаш зi cвоï'ми завданнями, i те, який вплив це може мати не лише на ниx, а й на ви команди проекту оргашзацш чи на компанш. Виxодячи з пpитaмaнниx cильниx i cлaбкиx cтоpiн компaнiй, варто узгодити cтpaтегiï' управл1ння ризиками, якi дозволять кеpiвникaм пpоектiв робити пpогpaмнi проекти угашними. Kонцепцiï та навички мають бути вплетеш в повcяк-денне прийняття бiзнеc-piшень i cтaти caмокоpиговaними та caмодоcтaтнiми для поcтiйного вдоcконaлення про-гpaмниx пpодyктiв i поcлyг. Саме тому нaдaлi yпpaвлiння ризиками ставатиме вcе бiльш i бшьш важливим, як i iнcтpyменти для визначення ризик1в, yпpaвлiння ними, а ошбливо для визначення дiй щодо реагування на нт.
Список використано'1 лiтератури
1. Crispin G. The Essence of Risk Identification in Project Risk Management: An Overview. International Journal of Science and Research (IJSR), 2020, no. 9, pp. 1553-1557. https://doi.org/10.21275/SR20215023033.
2. Project Risk Assessment (Ultimate Guide to Project Risk, P. 1). URL: https://www.wrike.com/blog/ultimate-guide-to-project-risk-part-1-risk-assessment
3. Different types of risks in Software Project Development. URL: https://geeksforgeeks.org/different-types-of-risks-in-software-project-development
4. Zvonko K., Kafol C. Types of Risk in a System Engineering Environment and Software Tools for Risk Analysis. Procedía Engineering, 2014, no. 69, pp. 177-183. https://doi.org/10.1016/j.proeng.2014.02.218.
5. Bell M. Risk Types in Project Management, 2022. URL: https://projectmanagementacademy.net/resources/blog/ risk-types-in-project-management
6. Грицюк Ю. I., Далявський В. С. Формалiзацiя процесу управлшня ризиками розроблення програмного забезпечення. Науковий вСник НЛТУ Украгни. 2018. № 28(11). C. 135-154. https://doi.org/10.15421/40281124.
7. Wikarsa L. Risk Management for IT Projects. URL: https://researchgate.net/publication/328653592_Risk_ Management_for_IT_Projects
8. Stojcetovic B., Misic M., Zivce S., Lazarevic D., Zubac D. Managing of risks and quality in projects. 8th International quality conference, 2014, pp. 201-207.
9. Коваленко О. В. Методи яшсного аналiзу та шльшсно1 оцшки ризишв розробки програмного забезпечення. 36ipHUK наукових праць «Системи управлшня, навiгацiï та зв'язку. 2018. № 3. C. 116-125. https://doi.org/10.26906/ SUNZ.2018.3.116.
10. Alkhuraiji Sh. L. Incorporating Knowledge Networks to Address Risk associated with Decision-Making in IT Projects. International Conference on Decision Support System Technology (ICDSST'2016), Plymouth, UK, 2016, pp. 1-7.
11. PMBOK® Guide. URL: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok.
12. Product Management and Project Management: Alignment and Differences. URL: https://www.pmi.org/learning/ thought-leadership/product-and-project-management.
13. ISO 31000 Risk management. URL: https://www.iso.org/iso-31000-risk-management.html.
14. PMI Lexicon of Project Management Terms. URL: https://www.pmi.org/pmbok-guide-standards/lexicon.
15. Bishop K. 4 Types of Risk Categories in Project Risk Management. URL: https://fool.com/the-ascent/small-business/project-management/articles/risk-categories
16. Трофименко О. Г., Пастернак Ю. Ю., Манаков С. Ю., Лобода Ю.Г. Автоматизащя тестування веб-сайпв електронно1 комерци. Сучасна спещальна техмка. 2021. № 2(65). C. 46-59. https://doi.org/10.36486/ mst2411-3816.2021.2(65).5
17. Ситник В. А., Тесленко П. О., Бедрш Д. I, Шерстюк О. I. Управлшня прототипуванням та ризиками IT-проекпв з вщкритим кодом. Управлшня проектами тарозвиток виробництва. 2018. № 3(67). C. 116-128.
18. Трофименко О. Г., Лопнова Н. I., Манаков С. Ю., Дубовой Я. В. Юбеззагрози в освггньому секторг Юбер-безпека: освта, наука, техмка. 2022. № 4(16). C. 76-84. https://doi.org/10.28925/2663-4023.2022.16.7684.
19. Трофименко О. Г., Лопнова Н. I., Манаков С. Ю., Янковський О. Г. Юберризики в освггньому секторг Сучасна спещальна техтка. 2022. № 2(69). C. 111-117. https://doi.org/10.36486/mst2411-3816.2022.2(69).10.
20. Gordon Y., Jasny M. From Ransomware to Mobile Malware: Emerging Cybersecurity Risks. Project Management Institute (PMI). URL: https://pmi.org/learning/training-development/projectified-podcast/podcasts/from-ransomware-to-mobile-malware-emerging-cybersecurity-risks
21. Трофименко О. Г., Дика А. I., Лобода Ю. Г. Аналiз уразливостей та проблем безпеки вебзастосуншв. Сис-темт технолог^'. 2023. № 3(146). C. 25-37. https://doi.org/10.34185/1562-9945-3-146-2023-03.
22. Guide on Mergers and Acquisitions Risks: Lessons Learned from Failed Transactions. URL: https://datarooms. org/vdr-blog/risks-in-merger-and-acquisition
23. 95 Essential Project Management Statistics: 2023 Market Share & Data Analysis. URL: https://financesonline. com/35-essential-project-management-statistics-analysis-of-trends-data-and-market-share/
24. Kononenko V. 7 main types of software development risks, 2022. URL: https://computools.com/software-development-risks
25. Success in Disruptive Times. Expanding the Value Delivery Landscape to Address the High Cost of Low Performance. URL: https://pmi.org//media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf
26. What Is Project Stakeholder Management? FAQ. Project Management Guide. URL: https://www.wrike.com/ project-management-guide/faq/what-is-project-stakeholder-management
27. 16 Obstacles To A Successful Software Project (And How To Avoid Them). URL: https://www.forbes. com/sites/forbestechcouncil/2022/06/21/16-obstacles-to-a-successful-software-project-and-how-to-avoid-them/?sh=76aa87581915
References
1. Crispin G. (2020) The Essence of Risk Identification in Project Risk Management: An Overview. International Journal of Science and Research (IJSR), no. 9, pp. 1553-1557. https://doi.org/10.21275/SR20215023033.
2. Project Risk Assessment (Ultimate Guide to Project Risk, P. 1). Access mode: https://wrike.com/blog/ultimate-guide-to-project-risk-part-1-risk-assessment
3. Different types of risks in Software Project Development. Access mode: https://geeksforgeeks.org/different-types-of-risks-in-software-project-development
4. Zvonko K., Kafol C. (2014) Types of Risk in a System Engineering Environment and Software Tools for Risk Analysis. Procedía Engineering, no. 69, pp. 177-183. https://doi.org/10.1016Zj.proeng.2014.02.218.
5. Bell M. Risk Types in Project Management, 2022. Access mode: https://projectmanagementacademy.net/resources/ blog/risk-types-in-project-management
6. Hrytsiuk Yu. I., Dalyavskyy V. S. (2018) Formalization of the Risk Management Process of Software Development. Scientific Bulletin of UNFU, no. 28(11), pp. 135-154. https://doi.org/10.15421/40281124. [in Ukrainian].
7. Wikarsa L. Risk Management for IT Projects. Access mode: https://researchgate.net/publication/328653592_ Risk_Management_for_IT_Projects
8. Stojcetovic B., Misic M., Zivce S., Lazarevic D., Zubac D. (2014) Managing of risks and quality in projects. 8th International quality conference, pp. 201-207.
9. Kovalenko O. (2018) Quality analysis and quantitative assessment of risks methods of software development. Control, Navigation and Communication Systems. Academic Journal, no. 3, pp. 116-125. https://doi.org/10.26906/ SUNZ.2018.3.116. [in Ukrainian].
10. Alkhuraiji Sh. L. (2016) Incorporating Knowledge Networks to Address Risk associated with Decision-Making in IT Projects. International Conference on Decision Support System Technology (ICDSST'2016), Plymouth, UK, pp. 1-7.
11. PMBOK® Guide. URL: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok.
12. Product Management and Project Management: Alignment and Differences. Access mode: https://www.pmi.org/ learning/thought-leadership/product-and-project-management.
13. ISO 31000 Risk management. Access mode: https://www.iso.org/iso-31000-risk-management.html.
14. PMI Lexicon of Project Management Terms. Access mode: https://www.pmi.org/pmbok-guide-standards/lexicon.
15. Bishop K. 4 Types of Risk Categories in Project Risk Management. Access mode: https://fool.com/the-ascent/ small-business/project-management/articles/risk-categories
16. Trofymenko, O., Pasternak, Yu., Manakov, S., Loboda, Yu. (2021). Automation of testing e-commerce websites. Modern Special Technics, no. 2(65), pp. 46-59. https://doi.org/10.36486/mst2411-3816.2021.2(65).5 [in Ukrainian].
17. Sytnyk V A., Teslenko P. O., Bedrii D. I., Sherstyuk O. I. (2018) Management of prototyping and risks of open source IT projects. Project management and production development, no. 3(67), pp. 116-128. [in Ukrainian].
18. Trofymenko, O., Loginova, N., Manakov, S., Dubovoi, Y. (2022). Cyberthreats in higher education. Cybersecurity: Education, Science, Technique, no. 4(16), pp.76-84. https://doi.org/10.28925/2663-4023.2022.16.7684. [in Ukrainian].
19. Trofymenko, O., Loginova, N., Manakov, S., Iankovskii, O. (2022). Cyber risks in the education sector. Modern Special Technics, no. 2(69), pp. 111-117. https://doi.org/10.36486/mst2411-3816.2022.2(69).10. [in Ukrainian].
20. Gordon Y., Jasny M. From Ransomware to Mobile Malware: Emerging Cybersecurity Risks. Project Management Institute (PMI). Access mode: https://pmi.org/learning/training-development/projectified-podcast/podcasts/from-ransomware-to-mobile-malware-emerging-cybersecurity-risks
21. Trofymenko O., Dyka A., Loboda Yu. (2023) Analysis of vulnerabilities and security problems of web applications. System technologies, no. 3(146), pp. 25-37. https://doi.org/10.34185/1562-9945-3-146-2023-03. [in Ukrainian].
22. Guide on Mergers and Acquisitions Risks: Lessons Learned from Failed Transactions. Access mode: https:// datarooms.org/vdr-blog/risks-in-merger-and-acquisition
23. 95 Essential Project Management Statistics: 2023 Market Share & Data Analysis. Access mode: https:// financesonline.com/35-essential-project-management-statistics-analysis-of-trends-data-and-market-share/
24. Kononenko V 7 main types of software development risks, 2022. Access mode: https://computools.com/software-development-risks
25. Success in Disruptive Times. Expanding the Value Delivery Landscape to Address the High Cost of Low Performance. Access mode: https://pmi.org//media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf
26. What Is Project Stakeholder Management? FAQ. Project Management Guide. Access mode: https://www.wnke. com/project-management-guide/faq/what-is-project-stakeholder-management
27. 16 Obstacles To A Successful Software Project (And How To Avoid Them). Access mode: https://www. forbes.com/sites/forbestechcouncil/2022/06/21/16-obstacles-to-a-successful-software-project-and-how-to-avoid-them/?sh=76aa87581915.
