nmk

Лекція №10 (2 години). Управління контрактами (SLA, Outsourcing), закупівлі та завершення проєкту

План лекції

Види контрактів в IT: Fixed Price, Time & Material, Dedicated Team, Outstaffing.
Процес вибору підрядників. Outsourcing vs Insourcing в IT.
SLA (Service Level Agreement) — гарантія якості послуг.
Процеси завершення проєкту (Handover, підписання актів, розпуск команди).
Вивчені уроки (Lessons Learned) та проведення ретроспектив.
Написання пост-мортемів (Post-Mortem).
Оцінка успішності проєкту.

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

SLA (Service Level Agreement) — угода про рівень обслуговування;
T&M (Time and Material) — контракт “Час та матеріали”;
NDA (Non-Disclosure Agreement) — угода про нерозголошення конфіденційної інформації;
Handover — передача проєкту (продукту) замовнику чи команді підтримки;
Post-Mortem — документ-“розтин” (аналіз інциденту або завершеного проєкту).

Вступ

Проєкт не закінчується в момент, коли програміст написав останній рядок коду і натиснув Commit. Це лише завершення технічної фази. Один із найважливіших етапів IT-проєктування — це його юридичне та адміністративне оформлення: як ми наймаємо людей (контракти), як передаємо готовий продукт клієнту, та які висновки робимо після завершення.

Якщо проєкт починається без чіткого контракту або закінчується без ретроспективи, команда приречена постійно повторювати одні й ті самі помилки, втрачаючи гроші і клієнтів.

1. Види контрактів в IT

Вибір типу контракту визначає, хто нестиме основні ризики: замовник чи IT-компанія (виконавець).

1. Fixed Price (Фіксована ціна):

Суть: Клієнт платить строго узгоджену суму (наприклад, $100 000) за строго узгоджений продукт (SRS). Ні копійкою більше.
Ризик: Майже всі ризики бере на себе IT-компанія. Якщо розробка затягнеться, програмістам все одно доведеться платити зарплату з кишені компанії (збиток).
Де застосовується: У Waterfall-проєктах, державних тендерах або на дуже тривіальних проєктах, де все зрозуміло з першого дня. Несумісний з Agile-підходами.

2. Time & Material, T&M (Час і матеріали):

Суть: Клієнт платить за ФАКТИЧНО ВИТРАЧЕНИЙ ЧАС розробників (зазвичай погодинна ставка, наприклад, $50/година).
Ризик: Ризики (бюджетні) лежать на Клієнті. Якщо він постійно змінює настрій і додає нові фічі (“Спробуймо зробити кнопку червоною… ні, синьою”), він просто оплачує всі ці години роботи.
Де застосовується: Ідеально для Agile. Так працює понад 80% сучасних аутсорс-проєктів.

3. Dedicated Team (Виділена команда):

Суть: Клієнт орендує цілу “збиту”, спрацьовану команду (PM, 3 Back-end, 2 Front-end, 1 QA), яка місяцями працює тільки над його продуктом як єдиний організм.

4. Outstaffing (Оренда “голів”):

Суть: Клієнт орендує конкретних людей. Наприклад, американській компанії терміново потрібен ще один Senior Java розробник. Вони “беруть в оренду” українського програміста через агенцію. Розробник підпорядковується PM-у клієнта, а агенція лише забезпечує йому стілець, ноутбук та бухгалтерію.

2. Outsourcing vs Insourcing в IT. Закупівлі

Insourcing (In-house-розробка): Продукт створюється власними штатними працівниками компанії.

Плюси: Максимальний контроль, висока безпека даних (всі підписали NDA), корпоративна культура.
Мінуси: Дорого тримати людей у штаті (податки, лікарняні), важко швидко “звільнити” 50 програмістів, якщо проєкт раптово закрили.

Outsourcing (Аутсорсинг): Передача розробки (або її частини) сторонній компанії.

Плюси: Значна економія коштів (наймають команди у Східній Європі, Індії), можна швидко масштабувати команду.
Мінуси: Складна комунікація (різні часові пояси), ризики витоку інформації. Потребує жорстких контрактів (SLA).

Процес закупівель (РFI, RFQ, RFP): Коли компанії потрібно найняти підрядника (наприклад, купити систему безпеки), вона проходить 3 етапи:

RFI (Request for Information): “Розкажіть, хто ви і що взагалі вмієте?” (збираємо загальну інформацію по ринку).
RFQ (Request for Quotation): Запит ціни. “Ми хочемо ось це. Скільки це буде коштувати?”.
RFP (Request for Proposal): Найсерйозніший документ. Оголошується тендер. “Ось наша проблема, запропонуйте нам технічне рішення і дайте повний кошторис”.

3. SLA (Service Level Agreement)

Коли проєкт здано, часто IT-компанія залишається надавати підтримку. Тут працює SLA (Угода про рівень обслуговування).

Це юридичний документ, в якому математично описано критерії якості. Ніхто не пише “Ми будемо добре вас обслуговувати”. В SLA пишуть:

Uptime (доступність серверів): 99.9% на рік (це означає, що програма може “лежати” не більше 8.7 годин за весь рік).
Response Time (Час реакції на баг): Наприклад, на критичний баг (Level 1) служба підтримки зобов’язана відреагувати протягом 15 хвилин, а виправити його — за 2 години.
Штрафні санкції: Що буде, якщо ми не вкладемося в обіцяний час (наприклад, повернення 10% місячної абонплати).

4. Процеси завершення проєкту

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

Етап Handover (Передача):

Навчання користувачів: розробники проводять воркшопи для команди клієнта.
Передача ключів: клієнту віддають доступ до репозиторіїв з кодом (GitHub), паролі від серверів баз даних (AWS), ліцензійні ключі.
Підписання Акта прийому-передачі виконаних робіт — юридичного документа, після підписання якого клієнт визнає: “Я все перевірив (через UAT-тестування), мене все влаштовує, плачу фінальний платіж”.

Після цього відбувається Release / Розпуск команди. Керівник проєкту (та HR-відділ) переводить звільнених розробників на нові (bench) або інші проєкти. Робити це треба швидко, інакше програмісти без поточного завдання (які сидять “на бенчі”) просто “спалюють” гроші компанії.

5. Вивчені уроки (Lessons Learned) та Ретроспективи

Після того, як пил проєкту осів, команда обов’язково має зустрітися для проведення Ретроспективи (Lessons Learned meeting). Це мітинг не для того, щоб покарати винних, а щоб обговорити три питання:

Що ми зробили добре? (Які технології спрацювали, які процеси треба перенести на наступні проєкти).
Що пішло не так? (Чому ми двічі зірвали дедлайн, чому сервер не витримав навантаження).
Що ми змінимо наступного разу? (Action Items - конкретні кроки).

Результатом цієї зустрічі є документ Lessons Learned Register, який додається до бази знань компанії (в Confluence). Завдяки йому молодий PM, який прийде в компанію через рік роблячи схожий проєкт, зможе прочитати: “О, вони використовували цей платіжний шлюз і мучилися з ним місяць. Я виберу інший інструмент”.

6. Написання пост-мортемів (Post-Mortem)

Класична Ретроспектива проводиться після всього проєкту (або після кожного спринту). Post-Mortem (від лат. “після смерті”) пишеться здебільшого після великого факапу чи масштабного інциденту (наприклад, на 3 години впав Production сервер через баг у коді).

Ключове правило Post-Mortem в IT (яке популяризувала компанія Google) — він має бути Blameless (Без звинувачень). Замість того, щоб писати “Джуніор Вася випадково видалив базу даних, ми його звільнили”, пишуть “Процес релізу дозволяв інженеру без достатніх прав виконати деструктивну команду на Production-середовищі”.

Коректний пост-мортем описує:

Що сталося? (Хронологія подій з точністю до хвилини).
Який вплив? (Втратили $15 000, тому що користувачі не могли зробити замовлення).
Як ми вирішили проблему під час інциденту? (Відкотили бекап).
Core (Root) Cause Analysis (Аналіз першопричини): Використовується метод “5 Чому?” (5 Whys), щоб розкопати справжню технічну чи процесну причину.
Які Action Items на майбутнє? (Заборонити прямий доступ до БД, налаштувати систему Alerting).

7. Оцінка успішності проєкту

Наприкінці PM має оцінити метрики успіху. Проєкт вважається успішним, якщо:

Задоволені потреби бізнесу (клієнт отримав те, що хотів, тобто потрібний Scope).
Дотримано час (Schedule) і бюджет (Cost Project Baseline).
Команда залишилася цілою (люди не звільнилися від вигорання через постійні овертайми і готові працювати з цим PM-ом на нових ініціативах).
Процес створення продукту приніс корисні “Вивчені уроки” в скарбничку IT-компанії.

Висновки

Існує кардинальна різниця між контрактами Fixed Price (ризикує компанія) та T&M (ризикує замовник, але він має повну Agile-гнучкість). Також використовують формати Dedicated Team та Outstaffing (надання розробників в оренду).
SLA (Service Level Agreement) математично фіксує якість технічної підтримки (Uptime, швидкість реакції) після здачі продукту.
Процес закупівель і вибору підрядників складається із запитів (RFI, RFQ, RFP), щоб обрати найвигідніший формат співпраці.
Завершення проєкту (Handover) вимагає юридичного оформлення: передачі доступів, навчання клієнта та підписання Актів прийому-передачі.
“Blameless” підхід у складанні Post-Mortem документів дозволяє команді сфокусуватись на ремонті зламаних процесів (через аналіз першопричини Root Cause), а не на пошуку і звільненні “винних” програмістів.
Вміння зібрати і зберегти Lessons Learned (“Вивчені уроки”) у корпоративній Wiki-системі формує досвід організації, який відділяє компанію-професіонала від новачків на ринку IT.

Джерела

Інститут управління проєктами (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). (Розділи Project Procurement Management та Project Integration/Closing Management).
Google SRE Book (Site Reliability Engineering). Розділ “Postmortem Culture: Learning from Failure”.
Р. Нільсон. Мистецтво управління IT-ресурсами.

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

Чому розробка проєкту за моделлю Scrum неможлива (або вкрай ризикована для IT-компанії) за контрактом Fixed-Price? Який тип контракту ідеально підходить для Scrum?
Поясніть своїми словами, чим організаційно відрізняється Outsourcing (клієнт віддає проєкт вам) від Outstaffing (клієнт “орендує” ваших розробників). Хто у другому випадку управляє проєктом?
Що таке SLA? Наведіть 2 приклади метрик для технічної підтримки, які зазвичай включають в угоду про рівень обслуговування.
Які кроки включає в себе етап “Handover” (передача) перед фінальним розпуском IT-команди з проєкту?
Наведіть приклад “Blameless Post-Mortem” підходу. Як ви опишете інцидент (наприклад, падіння бази даних), щоб не переходити на особистості, а зробити акцент на вирішенні проблеми з процесами компанії?