nmk

Лекція №1 (4 години). Поняття, життєвий цикл IT-проєкту та процеси управління

План лекції

Визначення проєкту та специфіка IT-проєктів. Причини успіху та провалу.
Життєвий цикл проєкту vs Життєвий цикл розробки ПЗ (SDLC).
Роль керівника проєкту (Project Manager), відмінності від інших ролей та ключові компетенції.
Організаційні структури компаній та їх вплив на проєкти (продуктові та аутсорсингові компанії).
Основні принципи управління проєктами (еволюція PMBOK).
Групи процесів управління проєктом (від ініціації до завершення).
Проєктний трикутник (Project Management Triangle) та мистецтво компромісів.

Перелік умовних скорочень

PM (Project Manager) — керівник проєкту;
PdM (Product Manager) — менеджер з продукту;
PMBOK (Project Management Body of Knowledge) — звід знань з управління проєктами;
PMI (Project Management Institute) — Інститут управління проєктами;
IT (Information Technology) — інформаційні технології;
SDLC (Software Development Life Cycle) — життєвий цикл розробки програмного забезпечення;
MVP (Minimum Viable Product) — мінімально життєздатний продукт;
ROI (Return on Investment) — окупність інвестицій.

Вступ

Ця лекція присвячена фундаментальним основам управління IT-проєктами. Робота в IT — це не лише написання коду. Згідно з дослідженнями Standish Group (CHAOS Report), понад 60% IT-проєктів зазнають невдачі (перевищують бюджет, зривають дедлайни або взагалі скасовуються). Причина найчастіше полягає не в технологіях, а в поганому управлінні, нечітких вимогах та неефективній комунікації. Ми розглянемо, що робить проєкт унікальним, як він розвивається, хто такий Project Manager і якими інструментами він оперує, щоб довести проєкт до успішного релізу.

1. Визначення проєкту та специфіка IT-проєктів

Що таке проєкт?

Проєкт — це тимчасове підприємство, спрямоване на створення унікального продукту, послуги або результату.

Ключові характеристики проєкту:

Тимчасовість (Timeliness): Проєкт має чіткий початок і кінець. Він закінчується тоді, коли досягнуті його цілі, або коли стає зрозуміло, що цілі не можуть бути досягнуті (проєкт скасовується). Тимчасовість не означає “швидкість” — проєкт може тривати роками.
Унікальність (Uniqueness): Результат завжди відрізняється від попередніх. Навіть якщо IT-компанія створює десятий інтернет-магазин на базі одного й того ж CMS-рушія, цей проєкт буде унікальним через нового клієнта, інший дизайн, специфічні інтеграції (наприклад, з новою CRM-системою) або іншу команду розробників.
Поступова розробка (Progressive Elaboration): План проєкту деталізується крок за кроком. На старті ми можемо знати лише базу: “нам потрібен додаток для доставки їжі”. Згодом ми уточнюємо: “потрібна інтеграція з Google Maps та платіжною системою Stripe”.

Проєктна vs Операційна діяльність

Важливо відрізняти проєкт від операційної (поточної) діяльності. Операційна діяльність — це безперервний процес, що повторюється і підтримує бізнес (наприклад, щоденне резервне копіювання баз даних, робота служби підтримки 1-ї лінії).

Приклад: Створення та запуск нової хмарної інфраструктури — це проєкт. Її щоденне адміністрування та моніторинг після запуску — це операційна діяльність.

Специфіка IT-проєктів

Чому керувати IT-проєктами складніше, ніж будувати мости?

Високий рівень невизначеності та змінність вимог: На старті проєкту замовник рідко знає, чого він хоче на 100%. Вимоги змінюються просто під час розробки, оскільки бізнес адаптується до ринку.
Нематеріальна природа продукту: Програмне забезпечення не можна “побачити” до моменту запуску інтерфейсу. Замовнику важко оцінити, що означає стан “система готова на 70%”, оскільки бекенд-логіка для нього невидима.
Швидке старіння технологій: Те, що було актуально рік тому (наприклад, певна версія фреймворку), може стати застарілим ще до моменту релізу великого ентерпрайз-проєкту.
Критична залежність від людського фактору: Продуктивність IT-команди залежить не від кількості людей, а від їхніх навичок, мотивації та інтелектуальної синергії. Додавання нових програмістів у проєкт, що запізнюється, зазвичай ще більше уповільнює його (Закон Брукса).
Складність інтеграцій: Сучасні IT-системи рідко існують ізольовано. Вони вимагають складних інтеграцій з десятками зовнішніх API (соцмережі, банки, державні реєстри), які можуть оновлюватися або падати.

2. Життєвий цикл проєкту vs SDLC

Життєвий цикл проєкту (Project Life Cycle) — це набір фаз, через які проходить проєкт від свого початку і до завершення.

Типові фази життєвого циклу універсального проєкту:

Початкова фаза (Starting the project / Feasibility): Формулювання бізнес-ідеї. Проводиться ТЕО (техніко-економічне обґрунтування). Оцінюється ROI. Приймається рішення “Make-or-Buy” (писати своє ПЗ чи купити готове рішення).
Організація та підготовка (Organizing and preparing): Збір детальних вимог, формування команди, виділення бюджетів, планування архітектури (Architecture Blueprint).
Виконання робіт (Carrying out the work): Найбільш ресурсомістка фаза. Безпосередньо створення продукту, тестування, виправлення багів.
Завершення проєкту (Ending the project): Передача продукту клієнту, підписання актів, розпуск команди, аналіз досвіду (Lessons Learned) та фіксація знань у корпоративній базі.

Project Life Cycle vs SDLC (Software Development Life Cycle)

Важливо не плутати життєвий цикл управління проєктом із життєвим циклом розробки програмного забезпечення (SDLC).

Життєвий цикл проєкту фокусується на управлінні (гроші, терміни, команда, документи).
SDLC фокусується на інженерії (як саме створюється код).

Фази SDLC включають:

Збір та аналіз вимог (Requirements Analysis).
Дизайн та проєктування системної архітектури (Design).
Написання коду (Implementation / Coding).
Тестування (Testing / QA).
Розгортання (Deployment).
Підтримка та обслуговування (Maintenance).

Для одного IT-проєкту (життєвий цикл проєкту) розробка самого софту (SDLC) може займати лише етап “Виконання робіт”.

3. Роль керівника проєкту (PM) та ключові компетенції

Project Manager (PM) — це диригент оркестру. Він не грає на скрипці (не пише код) і не грає на трубі (не тестує), але гарантує, що вся команда грає злагоджено, у правильному темпі та дає очікуваний результат.

Відмінність PM від інших ролей в IT:

Project Manager vs Product Manager (PdM): Product Manager фокусується на тому, ЩО ми робимо і ЧОМУ це потрібно ринку (стратегія, монетизація, користувачі). Project Manager фокусується на тому, ЯК і КОЛИ ми це зробимо (дедлайни, бюджети, розподіл задач).
Project Manager vs Scrum Master: Scrum Master — це фасилітатор, який відповідає виключно за дотримання командою процесу Scrum та усунення перешкод. Він не керує бюджетами чи контрактами, на відміну від PM.
Project Manager vs Tech Lead: Tech Lead відповідає за якість коду та архітектурні рішення. PM може взагалі не мати технічної освіти, якщо він працює в сильній команді з крутим Tech Lead.

Ключові компетенції PM (згідно з трикутником талантів PMI):

Раніше вважалося, що PM повинен просто вміти малювати графіки. Сучасний підхід інституту PMI виділяє три ключові сфери (Talent Triangle):

Ways of Working (Раніше “Technical Project Management”): Вибір правильних методологій (Agile, Scrum, Waterfall), уміння складати розклад (діаграми Ганта), керувати ризиками, бюджетом та обсягом. Знання Jira або MS Project.
Power Skills / Лідерство (Leadership): Емоційний інтелект, емпатія. Вміння мотивувати вигорілу команду. Навички фасилітації мітингів, вирішення конфліктів між розробниками та тестувальниками, ведення жорстких переговорів із замовниками щодо дедлайнів.
Business Acumen / Стратегічне управління: Розуміння бізнес-домену проєкту (наприклад, специфіки FinTech або HealthCare). Здатність відповісти на питання: “Як затримка релізу на 2 тижні вплине на маркетингову кампанію клієнта?”.

Практичний приклад: Коли розробник каже, що задача займе 5 днів, PM з розвиненим критичним мисленням запитає: “Чи враховано тут час на code review, написання unit-тестів та можливі баг-фікси?”, тим самим рятуючи проєкт від зриву термінів.

4. Організаційні структури компаній та їх вплив на проєкти

Те, наскільки легко PM-у керувати проєктом, сильно залежить від організаційної структури компанії — кому належать бюджети і хто має владу звільняти чи наймати людей.

1. Функціональна структура (Functional)

Класична ієрархія. Компанія поділена на відділи: Відділ Бекенду, Відділ Дизайну, Відділ QA.

Позиція PM: Дуже слабка. PM виступає як координатор (експедитор).
Процес: Щоб бекенд-розробник зробив задачу, PM має йти до начальника Відділу Бекенду і просити його виділити людину.
Недоліки: Проєкти робляться дуже повільно через бюрократію. “Колодязне” (silo) мислення: кожен відділ дбає лише про свою роботу, а не про проєкт загалом.

2. Проєктизована структура (Projectized)

Компанія складається з ізольованих проєктних команд. Відділів немає. Після завершення проєкту команда розформовується. Часто зустрічається в чистих аутсорсингових компаніях.

Позиція PM: Максимальна влада (“Міні-CEO”). PM контролює бюджет і наймає/звільняє людей зі своєї команди.
Переваги: Максимальна згуртованість команди та фокус на цілі. Висока швидкість прийняття рішень.
Недоліки: Дублювання ресурсів (кожному проєкту потрібен свій дизайнер, навіть якщо він завантажений на 20%). Ризик втрати роботи для спеціалістів після завершення проєкту.

3. Матрична структура (Matrix)

Найбільш поширена структура в сучасному IT (особливо в продуктових компаніях). Співробітник підпорядковується відразу двом босам: своєму функціональному керівнику (наприклад, Head of QA) та PM-у на конкретному проєкті.

Слабка матриця: Влада у функціонального керівника, PM просто відстежує статус.
Збалансована матриця: Влада розділена. PM керує проєктом, а функціональний керівник відповідає за професійний розвиток працівника (наприклад, проведення performance review).
Сильна матриця: PM має вирішальне слово щодо того, чим і коли займається співробітник.

5. Основні принципи управління проєктами (PMBOK)

PMBOK (Project Management Body of Knowledge) — це звід знань, створений Інститутом управління проєктами (PMI). Це світовий стандарт, який збирає найкращі практики. Важливо розуміти: PMBOK — це не методологія і не жорстка інструкція. Це фреймворк, “книга рецептів”, з якої PM обирає потрібні інструменти.

Раніше (до 6-го видання) PMBOK був процесно-орієнтовним. Сьоме видання (PMBOK 7) кардинально змінило підхід на принципово-орієнтований, щоб краще відповідати Agile-середовищу управління IT-проєктами.

Ключові принципи управління проєктами (PMBOK 7):

Стюардшип (Stewardship): Будьте сумлінним і дбайливим управителем. Це означає чесність перед клієнтом (не приховувати баги перед релізом) та турботу про ресурси компанії і екологію роботи команди.
Команда (Team): Створюйте безпечне середовище для співпраці. Психологічна безпека, коли Junior не боїться сказати про помилку Senior’a.
Стейкхолдери (Stakeholders): Ефективно залучайте зацікавлених сторін. Комунікуйте з ними, виявляйте їхні приховані інтереси.
Цінність (Value): Проєкт повинен приносити бізнес-цінність, а не просто “вкладатися у терміни та бюджет”. Якщо ви вчасно розробили фічу, але нею ніхто не користується — це провал з точки зору цінності.
Системне мислення (Systems Thinking): Враховуйте, як зміна в одному модулі системи може “покласти” всю архітектуру.
Лідерство (Leadership): Проявляйте лідерську поведінку на всіх рівнях.
Адаптація (Tailoring): «One size does not fit all» — адаптуйте підхід. Для стартапу з 3 людей використовуйте легкий Kanban, для розробки софту атомної станції — жорсткий Waterfall з тотальною документацією.
Якість (Quality): Вбудовуйте якість у процеси, а не намагайтесь “втестувати” її наприкінці.
Складність (Complexity): Вчіться працювати у середовищі системної складності та людської непередбачуваності.
Ризики (Risk): Оптимізуйте реакцію на ризики (постійно ідентифікуйте загрози та можливості).
Адаптивність та життєстійкість (Adaptability and Resiliency): Вміння швидко оговтуватися від невдач (сервер впав, бюджет скоротили).
Зміни (Change): Сприяйте впровадженню змін, підтримуйте перехід компанії від поточного стану (as-is) до майбутнього (to-be).

6. Групи процесів управління проєктом

У класичному процесному підході (історично PMBOK 6) управління реалізовується через 49 процесів, які логічно розподілені на 5 груп процесів:

Ініціація (Initiating): Процеси, що формально розпочинають новий проєкт.
- IT-приклади: Затвердження Business Case. Розробка та підписання Статуту проєкту (Project Charter), де PM офіційно отримує повноваження. Складання початкового списку стейкхолдерів.
Планування (Planning): Визначення обсягу робіт та уточнення цілей. Найважливіша група.
- IT-приклади: Написання специфікації (SRS). Розбиття робіт на WBS. Оцінка задач у Story Points або годинах. Розробка діаграми Ганта або плану релізів (Release Plan). Створення плану комунікацій (“щовівторка надсилаємо звіт клієнту”).
Виконання (Executing): Залучення ресурсів для виконання робіт за планом.
- IT-приклади: Безпосереднє написання коду розробниками. Проведення дейлі-мітингів. Робота з підрядниками (наприклад, аутсорсинг дизайну). Управління конфліктами в команді. Забезпечення якості (QA - процеси).
Моніторинг і контроль (Monitoring and Controlling): Регулярне відстеження прогресу та виявлення відхилень.
- IT-приклади: Перевірка графіків Burndown Chart. Відстеження метрик швидкості (Velocity). Контроль витрат бюджету. Процес контролю змін (Change Request) — якщо клієнт хоче додати нову фічу, ми оцінюємо її вплив на строки і лише тоді затверджуємо або відхиляємо.
Завершення (Closing): Формальне завершення всіх проєктних робіт.
- IT-приклади: Впровадження в Production. Отримання офіційного підпису (Sign-off) від клієнта (UAT - User Acceptance Testing пройдено). Звільнення команди з проєкту. Проведення фінальної ретроспективи або Post-Mortem аналізу. Архівування репозиторіїв та документації.

Важливо: Ці групи не є послідовними етапами (як каскад). “Моніторинг” іде паралельно з “Виконанням”. А якщо клієнт під час “Виконання” кардинально змінює вимоги, ми повертаємося до “Планування”.

7. Проєктний трикутник (Project Management Triangle)

«Проєктний трикутник» (Залізна транзитивність або Iron Triangle) ілюструє взаємозалежність обмежень будь-якого проєкту. Уявити управління ІТ-проєктом без цього концепту неможливо.

Традиційний трикутник має три вершини:

Час (Time / Schedule): терміни виконання проєкту, дедлайни.
Вартість (Cost / Budget): бюджет, ресурси, зарплати команди.
Обсяг (Scope): перелік функцій (фіч), вимоги, які потрібно виконати.

У центрі трикутника (або як результат) знаходиться Якість (Quality).

Золоте правило PM: Ви не можете змінити одну сторону трикутника, не вплинувши принаймні на одну з інших сторін, щоб зберегти якість на заданому рівні.

Практичні приклади з IT (як домовитись із клієнтом):

Сценарій 1: Замовник приходить в середині проєкту і просить додати ще інтеграцію з Apple Pay (збільшення Обсягу). Ваші дії як PM: Ви пояснюєте, що обсяг трикутника зріс. Отже, ми повинні або збільшити Час (відкласти реліз на 2 тижні), або збільшити Вартість (наняти на ці 2 тижні додаткового Senior iOS розробника).
Сценарій 2: Інвестор вимагає запуск продукту на місяць раніше (зменшення Часу), а бюджет фіксований. Ваші дії як PM: Час зменшився. Бюджет зафіксовано. Щоб не постраждала Якість, ми змушені зменшити Обсяг. Ми домовляємось запустити “урізану” версію (MVP), наприклад, без особистого кабінету користувача, а його додати вже у версії 2.0.

В ІТ існує класичний жарт (принцип швидкої розробки):
“Швидко, Дешево, Якісно — оберіть лише два”.

Швидко і дешево — це буде кривий та забагований код (неякісно).
Швидко і якісно — вам доведеться найняти найдорожчих спеціалістів на ринку (недешево).
Якісно і дешево — працювати будуть ентузіасти або стажери, але це займе роки (нешвидко).

У сучасних концепціях використовують “Проєктний шестикутник”, додаючи ще три обмеження: Ризики, Ресурси та Задоволеність клієнта.

Висновки

IT-проєкти характеризуються високим ступенем невизначеності, нематеріальністю продукту та частими змінами вимог, що вимагає гнучкого підходу.
Життєвий цикл проєкту формує управлінський каркас для його реалізації, в той час як SDLC описує суто інженерні етапи розробки програмного забезпечення.
Роль Project Manager полягає не в написанні коду, а в налагодженні процесів управління, фасилітації комунікацій, вирішенні проблем, плануванні та підтримці команди. Компетенції PM виходять далеко за межі складання графіків та включають потужне лідерство і стратегічне бачення.
Організаційна структура компанії (матрична чи проєктизована) безпосередньо впливає на повноваження менеджера проєкту та легкість доступу до ресурсів.
Стандарт PMBOK містить фундаментальні принципи адаптивності, цінності та управління змінами, а також описує 5 ключових груп процесів (Ініціація, Планування, Виконання, Моніторинг, Завершення) для ефективного управління.
Керівник проєкту завжди балансує між часом, витратами та обсягом у проєктному трикутнику, керуючи очікуваннями стейкхолдерів для досягнення необхідної якості фінального IT-продукту.

Джерела

Інститут управління проектами (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project Management.
Schwalbe, Kathy. Information Technology Project Management, 9th Edition.
Stellman, Andrew, and Jennifer Greene. Applied Software Project Management. O’Reilly Media.
CHAOS Report (The Standish Group) — дослідження успішності IT-проєктів.
Офіційний сайт Project Management Institute: https://www.pmi.org/

Запитання для самоперевірки

З яких причин створення нового веб-сайту для турфірми є проєктом, а його щомісячне наповнення статтями та SEO-оптимізація — операційною діяльністю?
Назвіть щонайменше 3 ключові характеристики IT-проєктів, які відрізняють їх від проєктів у будівництві чи важкій промисловості.
Поясніть різницю між Project Manager та Product Manager в IT-компанії.
У якій організаційній структурі (функціональній чи проєктизованій) управління комунікаціями займає більше часу, і чому?
Наведіть власний приклад із життя, як застосування правила “Проєктного трикутника” могло б врятувати студентський курсовий проєкт або організацію університетської вечірки від провалу.
В чому різниця між поняттями SDLC (Життєвий цикл розробки ПЗ) та Життєвий цикл проєкту?
Чому принцип “спрямованості на цінність” (Value) вважається одним із найважливіших у сучасних IT-проєктах?