nmk

Лекція №6 (2 години). Управління вартістю та бюджетом IT-проєкту (Cost Management)

План лекції

  1. Вартість IT-проєкту: чому софт такий дорогий? Прямі та непрямі витрати.
  2. Процес створення бюджету: від грубої оцінки (ROM) до базової лінії (Cost Baseline).
  3. Робота з резервами: Contingency Reserve (Резерв на відомі ризики) та Management Reserve (Резерв на невідомі ризики).
  4. Методичні підходи до оцінки вартості: Bottom-Up, Top-Down. Вплив типів контрактів (T&M vs Fixed Price) на бюджетування.
  5. Контроль витрат: введення в Метод освоєного обсягу (EVM - Earned Value Management).

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

Вступ

Ми часто чуємо в новинах: “Держава витратила 10 мільйонів на розробку нового порталу послуг”. У людей, далеких від IT, виникає логічне запитання: “За що такі гроші? Це ж просто сайт в Інтернеті!”. Управління вартістю (Cost Management) — це процес, який дозволяє керівнику проєкту математично обґрунтувати кожен витрачений цент, а також контролювати, щоб витрати команди не перевищили затверджений ліміт.

Головне правило проєктного менеджменту: Бюджет завжди обмежений. У цій короткій лекції ми розберемо, з чого складається ціна IT-проєкту, як її оцінити на різних етапах, що таке резерви на ризики, та як за допомогою кількох метрик (EVM) дізнатися, чи не летить проєкт у фінансову прірву.

1. Вартість IT-проєкту та структура витрат

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

Усі витрати на ІТ-проєкті діляться на дві великі категорії:

  1. Прямі витрати (Direct Costs):
    • Витрати, які можна безпосередньо віднести до створення конкретного продукту. Без цього проєкту компанія б їх не понесла.
    • Приклади: Зарплата команди розробників (програмісти, QA, PM), купівля хмарних серверів (AWS) конкретно для цього сайту, ліцензія на сторонній API (наприклад, Google Maps API), оплата роботи зовнішнього дизайнера на фрілансі.
  2. Непрямі (накладні) витрати (Indirect / Overhead Costs):
    • Витрати, які несе IT-компанія (Vendor) для свого функціонування, і які “розмазуються” (розподіляються) між усіма проєктами компанії.
    • Приклади: Оренда офісу, зарплата бухгалтера, печиво і кава на кухні, податки компанії, електроенергія.
    • Роль в проєкті: Коли IT-компанія продає 1 годину роботи програміста замовнику за $50 (Billable Rate), програміст зазвичай отримує на руки лише $25. Інші $25 йдуть на покриття непрямих витрат та забезпечення прибутку компанії.

2. Процес створення бюджету та види оцінок

Бюджет не з’являється за один день. Точність оцінки зростає в міру того, як з’ясовуються деталі проєкту (це явище називається “Конус Невизначеності” - Cone of Uncertainty).

Етапи оцінки бюджету:

  1. ROM-оцінка (Rough Order of Magnitude — “Груба оцінка”):
    • Робиться на етапі першої зустрічі з клієнтом (до детального ТЗ).
    • Точність: від -25% до +75% (а іноді й до +200%).
    • Приклад: “Ваш застосунок коштуватиме від $50,000 до $100,000”.
  2. Оцінка на стадії Планування (Budget Estimate):
    • Робиться після затвердження архітектури.
    • Точність: від -10% до +25%.
  3. Остаточна (Базова) оцінка (Definitive Estimate):
    • Робиться перед самим початком розробки, коли всі вимоги затверджені (особливо актуально для Fixed-Price контрактів).
    • Точність: від -5% до +10%. Ця оцінка стає Cost Baseline (Базовою лінією вартості), з якою надалі будуть порівнювати реальні витрати.

Два популярні методи детальної оцінки (З попередньої лекції ми знаємо їх для оцінки годин, але тут застосуємо гроші):

3. Робота з резервами (Project Reserves)

Жоден розумний менеджер не віддає клієнту “голу” суму розрахунків. У світі IT (де постійно щось “падає”) бюджет ЗАВЖДИ повинен містити “подушку безпеки”.

У проєктному менеджменті виділяють два види резервів:

  1. Contingency Reserve (Резерв на випадок непередбачених обставин / Відомі ризики):
    • Що це: Гроші, закладені на ризики, які ми ідентифікували під час планування. (Так звані “Відомі невідомі” - Known-Unknowns).
    • Приклад: Ми знаємо, що інтеграція з базою даних старого банку може піти не за планом. Ми оцінили цей ризик і заклали +2 дні роботи програміста ($800) на його вирішення.
    • Цей резерв входить до Cost Baseline (керівник проєкту розпоряджається ним вільно, без дозволу топ-менеджменту).
  2. Management Reserve (Управлінський резерв / Невідомі ризики):
    • Що це: Гроші на форс-мажори, які неможливо було передбачити (Unknown-Unknowns). Зазвичай це 5-10% від усього бюджету.
    • Приклад: Почалася епідемія COVID, і всі розробники злягли в лікарню. Проєкт простоює, доведеться терміново (за подвійним тарифом) наймати фрілансерів, щоб не зірвати дедлайн тендеру.
    • Цей резерв НЕ входить до Cost Baseline. Він лежить “у сейфі” директора компанії (Спонсора). Щоб скористатися ним, PM має писати офіційний запит на зміну бюджету.

4. Типи контрактів та їх вплив на бюджет

Те, ЯК відбувається оплата за проєкт, фундаментально змінює підхід до оцінки вартості. В IT існує два основних типи контрактів:

  1. Fixed-Price (Фіксована ціна):
    • Суть: Клієнт платить тверду суму (напр. $100,000) незалежно від того, 2 чи 10 місяців працювала компанія над функціоналом із затвердженого ТЗ.
    • Хто несе ризики перевитрат бюджету: Компанія-виконавець. Якщо програмісти схиблять і писатимуть код втричі довше, гроші на їхню зарплату компанія платитиме зі своєї кишені, отримуючи збитки.
    • Специфіка бюджетування: IT-компанії спеціально завищують оцінки (додають величезні Contingency Reserves), щоб застрахуватися.
  2. Time and Materials (T&M — “Час і матеріали”):
    • Суть: Клієнт платить “за фактично відпрацьований час”. (Програмісти відпрацювали 100 годин за ставкою $50 — клієнт заплатив $5,000 в кінці місяця).
    • Хто несе ризики перевитрат бюджету: Замовник. Якщо він часто змінюватиме вимоги, він просто продовжуватиме платити компанії роками.
    • Специфіка бюджетування: Точний бюджет (Baseline) не фіксується апріорі. Використовується в гнучких (Agile) методологіях.

5. Контроль витрат за допомогою методу EVM

Як зрозуміти, що ми перевитрачаємо бюджет (Burn Rate занадто високий) ще до того, як гроші закінчилися? Для цього Інститут PMI рекомендує математичний апарат — Earned Value Management (EVM - Метод освоєного обсягу).

EVM поєднує вимірювання обсягу, розкладу та витрат у єдину систему.

Три базових показники EVM (у грошах!):

  1. Planned Value (PV) — Запланована вартість. (Скільки грошей ми планували витратити за графіком на сьогоднішній день). Приклад: За планом, до 15 жовтня ми мали закінчити фазу Дизайну, яка оцінювалась у $10,000. PV = 10,000.
  2. Actual Cost (AC) — Фактичні витрати. (Скільки реальних грошей ми вже заплатили команді на сьогоднішній день). Приклад: Дизайнери працювали повільно і ми заплатили їм уже $12,000. АС = 12,000.
  3. Earned Value (EV) — Освоєний обсяг. (Скільки грошей з бюджету “коштує” та робота, яка фактично завершена). Приклад: З усього дизайну готова лише половина. Отже, ми заробили лише половину запланованої цінності (0.5 * $10k). EV = 5,000.

Аналіз стану (Індекси):

Ці дві прості формули (EV/AC та EV/PV) дозволяють PM-у щотижня формувати звіт для топ-менеджменту і сигналізувати про проблеми на ранніх стадіях.

Висновки

  1. Бюджет IT-проєктів формується здебільшого з прямих (зарплати, ліцензії) та непрямих (оренда, податки, адміністрування) витрат.
  2. Не можна вимагати від команди точної оцінки на самому старті (до з’ясування всіх вимог). Використовуйте порядок ROM (-25% до +75%).
  3. Точний розрахунок (Bottom-Up) робиться після декомпозиції вимог (WBS), множачи години всіх дрібних задач на ставку фахівців.
  4. Проєкт, складений без “Резервів на непередбачувані ситуації” (Contingency Reserves), майже приречений на провал (Overbudget).
  5. При Fixed-Price контрактах усі фінансові ризики несе розробник, тому оцінки зазвичай значно завищуються. При T&M ризики перевитрат фінансів бере на себе клієнт.
  6. EVM (Метод освоєного обсягу) дозволяє керівнику проєкту одночасно відстежувати ефективність як за грошима (CPI), так і за строками (SPI) завдяки порівнянню Плану, Фактичних витрат та Реально Зробленої роботи.

Джерела

  1. Інститут управління проєктами (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Розділ: Cost Management (детально про EVM).
  2. Fleming, Q. W., & Koppelman, J. M. Earned Value Project Management. (Довідник з EVM).

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

  1. До яких витрат — прямих чи непрямих (накладних) — належить оплата оренди офісу компанії-розробника і чому?
  2. Яка різниця між Contingency Reserve (Резервом на відомі ризики) та Management Reserve (Управлінським резервом)? Хто має право розпоряджатися останнім?
  3. Чому оцінка за допомогою методу Tоp-Down (Аналогія) є дуже небезпечною для контрактів з фіксованою ціною (Fixed-Price)?
  4. Поясніть концепцію “Конуса Невизначеності” під час оцінки бюджету.
  5. Ви розраховуєте метрики проєкту. Earned Value (EV) = $40,000, Planned Value (PV) = $50,000, Actual Cost (AC) = $60,000. В якому стані знаходиться проєкт: (а) іде за планом і в рамках бюджету, (б) відстає від графіка і перевищує бюджет? Підтвердіть розрахунками SPI та CPI.
  6. Які ризики для клієнта (замовника) містить тип контракту “Time & Materials”? Як компанія-клієнт може їх мінімізувати?