Ера ШІ і fixed price проєкти: де зв’язок і чи варто українському ІТ переглянути фокус на Time&Material форматі?
Історично склалось так, що сервісний ІТ-бізнес працює здебільшого у форматі Time & Material (далі — T&M) проєктів. Це зрозуміло і вигідно, адже окрім того, що замовник платить за час роботи кожного інженера, ще й бере на себе абсолютну більшість ризиків.
Водночас зараз ми спостерігаємо певну волатильність у напрямку Fixed Price (далі — FP) проєктів – і одна з причин цього полягає у стрімкому розвитку ШІ, зменшенні вартості написання коду і збільшенні цінності результату.
Мене звати В’ячеслав Проценко, я керую GovTech напрямком в ЕРАМ Україна. Разом з колегами ми маємо значний досвід FP проєктів для замовників за кордоном і в Україні, ділимось ним всередині компанії, нарощуємо базу знань і відповідні полісі. Поділюсь в цьому матеріалі нашими інсайтами і гайдом для успішного делівері в умовах таких проєктів з високим рівнем невизначеності.
Чому T&M починає «тиснути», а ШІ змінює правила гри
Базова різниця між моделями зрозуміла: у T&M ми делегуємо людей, які інвестують свій час у розробку, і замовник цей час оплачує за узгодженою ставкою. Майже всі ризики – на боці клієнта. У FP – на відміну від T&M – є конкретна задача, яку треба виконати за фіксовану суму. Ризики залишаються здебільшого на боці виконавця.
Раніше сервісні гіганти тримали частку FP на мінімальному рівні, бо це ризиковано. Але зараз все йде до «тектонічного зсуву». Чому? Через ШІ.
Для інженерних спеціалізацій стає все важче рахувати бізнес-модель погодинно. Якщо раніше написання коду займало 40 годин, а тепер з ШI-асистентом – 10, то як це порахувати замовнику в моделі T&M? Продавати менше годин? Це невигідно вендору. Піднімати ставки в 4 рази? У клієнта виникнуть питання.
Часом не зрозуміло, як шукати баланс, адже все залежить від самого коду, специфіки проєкту і ментальності інженерів.
Про ціну помилки: як один рядок у вимогах може стати роком додаткової роботи
Головний ризик FP – це невизначеність. На старті ми часто не розмовляємо із замовником однією мовою. Експерти, які глибоко розуміють конкретний домен, не завжди є в сервісних компаніях, а саме їхня експертиза може стати вирішальним фактором для успіху вашого проєкту. Якщо ви не розумієте специфіку глибоко, ви можете проґавити ризики ще на етапі пресейлу.
Власний приклад: багато років тому ми з колегами поїхали у відрядження до США. Клієнт зібрав дуже досвідчених, зрілих експертів з різних штатів. Ми мали їх послухати і розібратись у специфіці галузі. Проте через брак глибокого розуміння домену ми просто не поставили правильних запитань. Це призвело до викликів, які треба було потім подолати.
У іншого замовника у вимогах був один рядок: «Система повинна мати гнучку конфігураційну частину». Команда зробила припущення, що мова йде про звичайну адмін-панель на 50-100-200 параметрів – не більше.
Саме тому у FP-проєктах бізнес-аналітики мають не просто записувати вимоги, а виступати перекладачами з бізнесової мови на технічну. Якщо ви не знаєте домену глибоко, невизначеність росте експоненціально.
Це причина, через яку в ІТ інколи закладають надбавки під 200% від собівартості (згідно з Chaos Report від Standish Group), якщо проєкт складний. Це не жадібність, це ризик-менеджмент і обережність.
Fixed Price у GovTech: бюрократія як частина бюджету
Підписуйтеся на наші соцмережі
У державному секторі (і в Україні, і за кордоном) T&M майже не існує. Є тендер, є бюджет, є чіткий обсяг. Тут ризики ще вищі, бо до технічних додаються бюрократичні нюанси.
Нещодавно ми завершили проєкт для Держстату — це величезна комплексна трансформація: бекенд-система, внутрішні процеси, налаштування датасетів. Це робота на роки. Коли ви працюєте з державою, маєте закладати в бюджет не тільки код, а й звітність, перехресні перевірки та процедури передачі знань.
Якщо в комерції бюрократію намагаються мінімізувати, то в GovTech вона є частиною процесу делівері. Не треба плекати ілюзій, що ви «просто напишете код». Ви будете писати томи документації, і це має бути прораховано на старті. Це не погано і не добре – це особливість домену.
Гайд: як успішно працювати з FP проєктами
На основі нашого досвіду ми сформували внутрішню базу знань, яка допомагає менеджерам. Водночас ми переконані, що на FP проєктах мають працювати досвідчені менеджери та спеціалісти, які добре знаються на конкретних галузях.
1. Етап Discovery – це не опція, це фундамент
Якщо ви не зробите детальний аналіз на старті, ви програєте. Перша оцінка (high-level) може відрізнятись від оцінки після завершення цієї фази у рази. Це нормально. Головне – зафіксувати в контракті, що фінальна ціна базується на результатах discovery.
2. Кристалізація вимог до «атомів»
Вимоги мають бути розписані до функціональних, нефункціональних і технічних. Окремо – UI/UX та User Journey. Якщо ви бачите фразу «високонавантажена система» – за цим одним словом стоять місяці роботи. Розшифровуйте кожне таке словосполучення і не зупиняйтесь, навіть якщо хтось в команді каже, що “це просто, я так 100 разів робив”.
3. Бюджетна дисципліна
До моменту підписання ви нічого не винні. Після підписання контракту бюджет стає головною бізнес-цінністю. Ви маєте розуміти кожен крок аж до передачі системи замовнику, а інколи навіть до виведення з експлуатації.
Пам'ятайте також про те, що ціна дефектів збільшується, що ближче до фіналу проєкту. Якщо ви не бачите, як будете впроваджувати систему через рік, ви не готові підписувати контракт.
4. Синхронізація зі стейкхолдерами (безпека, інфраструктура тощо)
Часто розробка йде за планом, а потім ви дізнаєтесь, що відділ безпеки замовника розписаний на квартал вперед і не може дати вам доступ. Або для вашого замовника з певних причин недоступні певні опенсорсні бібліотеки, які ви використали.
Важливо: Якщо ви наприкінці проєкту дізнаєтесь, що ваша архітектура не проходить по внутрішнім комплаєнс-правилам клієнта, доведеться все «випилювати» за власний кошт. Знайомтесь якомога раніше із відповідними командами клієнта, які в майбутньому відповідатимуть за передачу і подальше використання вашого рішення.
5. Глибоке вивчення домену
Досвідчені експерти, збір інформації, таргетована робота з ШІ — все це може допомогти зі створенням солідної бази знань в конкретній області досить швидко.
Штучний інтелект може допомогти команді з навчанням і заглибленням в індустрію замовника - використовуйте його як бустер для розуміння мови клієнта і ефективного навчання команди.
6. Робота з командою
Як я вже зазначав, не варто призначати на FP проєкти менеджерів, які нещодавно долучились до вашої команди. Тут потрібні ті, хто вміє тримати удар, знають компанію і ключові контакти для різних випадків, обізнані щодо механізмів, які можна використовувати для подолання складнощів тощо.
7. Підготовка до передачі (Runbooks & Playbooks)
FP – це робота під ключ. Ви повинні передати систему так, щоб її міг підтримувати штатний ІТ-відділ клієнта. Це означає навчання персоналу, написання плей-буків і ран-буків (інструкцій, як реагувати на збої). Якщо ви не заклали час на це – втратите прибуток на фінальній стадії. План мінімум у цьому випадку — поставити запитання на початку співпраці, щоб визначити, чи знадобляться такі послуги.
Магія економіки: як FP може бути вигіднішим за T&M
Збоку FP виглядає як «страшний звір», але він дає простір для фінансових маневрів, яких немає в T&M.
- ШІ: Багато задач сьогодні потребують менше зусиль і часу — MVP, створення прототипів, документація тощо. Це один з факторів, який здатен зменшити ваші перестороги щодо ризиків таких проєктів. До того ж, весь профіт від використання ШІ залишається вам. Якщо інженери стали працювати швидше завдяки автоматизації, ваша маржинальність росте, а не падає (як це було б у T&M). Проте зауважу, що й інженери мають це усвідомлювати.;
- Оптимізація «піраміди»: У T&M всі хочуть мати Senior-ів. У FP замовнику байдуже, хто пише код, якщо результат відповідає вимогам. Ви можете гнучко змінювати Seniority-мікс, залучати мідлів там, де це доречно, і таким чином оптимізувати собівартість;
- Спільні ресурси: Вам не потрібно тримати окремого Security-експерта чи Performance-тестера на кожному проєкті на повну ставку. Якщо у вас портфоліо з 5-10 FP проєктів, ви можете використовувати цих експертів точково, під конкретні задачі;
Культурний код: від сієсти до специфічних графіків
Не забувайте про «людський фактор». Кожна країна має свій робочий етикет.
Наприклад, з мого досвіду з замовниками з Іспанії треба бути готовим до сієсти і специфічного графіку, в арабських країнах працює багато експатів, які надзвичайно вимогливі і очікують підтримки 24/7, в США дуже м’яка модель спілкування йде поруч з агресивною бізнес-моделлю всередині. Говорити про різні особливості можна дуже довго.
До того ж, якщо ви не врахували національні свята чи сезон відпусток замовника, ваш таймлайн буде зазнавати змін. А у FP кожен день затримки – це гроші з вашої кишені.
Приклад для фіналу
Аналогія, яку я завжди наводжу: запуск великого FP проєкту схожий на відомий кейс із запуском терміналу 5 в аеропорту Хітроу навесні 2008 року.
Ви можете все передбачити, але невелика послідовність факапів (не спрацювала парковка, персонал вчасно не потрапив на роботу, багажні стрічки почали перевантажуватись, рейси затримувались і скасовувались) – і весь аеропорт було паралізовано в операційному колапсі вже у другій половині дня після запуску нової системи на декілька тижнів.
Чи є FP ризикованим? Так. Але в еру ШІ це важливий крок до зростання прибутковості. Тут знадобиться експертність. Якщо ви знаєте свій домен, маєте сильну команду менеджерів і навчилися користуватися перевагами ШІ, FP стане для вас не пасткою, а прибутковою моделлю в портфоліо.
Але чи готові ви брати повну відповідальність за результат, а не за процес? Це головне питання, яке кожен менеджер має поставити собі вже сьогодні.