Change request: как договариваться об изменениях в фикс-прайсе

Модели оплаты в ИТ-проектах и место изменений

В заказной разработке чаще всего встречаются три модели. Фиксированная цена: объём и стоимость оговорены заранее, риск перерасхода несёт подрядчик. Time & Material: клиент платит за фактически потраченные часы, риск на его стороне. И гибрид: фикс за этап с понятным объёмом, а дальше почасовая работа.

Изменения есть в любой модели. Разница в том, как они влияют на деньги. В T&M изменение просто добавляет часы. В фиксированной цене каждое изменение — повод для переговоров, и без процесса они превращаются в конфликт.

Фиксированный бюджет, гибкий объём

Есть компромисс, который часто выручает в продуктовой разработке. Бюджет и срок фиксируются, а состав функций остаётся гибким: команда делает самое ценное в пределах суммы. По-английски это называют fixed price, variable scope. Такой договор честнее к продукту как к живой системе, но требует доверия и хорошего бэклога с приоритетами.

Как устроен процесс управления изменениями

В PMBOK это называется интегрированным контролем изменений. Звучит тяжело, но суть простая: ни одно изменение не попадает в работу, пока не оценено его влияние на объём, срок и бюджет и пока его не согласовал тот, кто платит.

Из чего состоит запрос на изменение

• Что меняется: описание и ссылка на исходное требование из ТЗ.
• Почему: кто инициатор и какая причина — рынок, новая идея, ошибка в ТЗ.
• Оценка: сколько часов добавится или уйдёт, в разбивке по задачам.
• Влияние на срок и стоимость.
• Решение: принято, отклонено или отложено, кем и когда.

Журнал изменений объёма работ

Отдельные запросы собираются в общий журнал. Это и есть та таблица, о которой пишу выше. Её главная ценность — история. Через полгода проекта никто не помнит, почему личный кабинет стал вдвое сложнее. Журнал помнит. С ним видно, что исходный объём вырос, скажем, на 30%, и откуда взялся каждый процент.

Кто согласует изменения

На крупных проектах собирают комитет по изменениям, по-английски Change Control Board. В небольшой команде достаточно двух людей: руководителя проекта со стороны подрядчика и владельца продукта со стороны клиента. Главное, чтобы право сказать «да» было у конкретного человека, а не у всех и ни у кого.

Как оценить изменение и не поссориться

Спор обычно идёт не о том, нужно ли изменение, а о том, сколько оно стоит. Клиенту кажется, что «поменять кнопку» — это полчаса. Подрядчик видит за кнопкой три экрана, API и тесты. Снять это противоречие помогает прозрачная оценка.

Я бы показывал не одну цифру, а разбивку по задачам. Для неопределённых задач подходит трёхточечная оценка из метода PERT: оптимистичная, наиболее вероятная и пессимистичная, итог считается по формуле (О + 4В + П) / 6. Клиент видит не «вам будет 80 часов», а откуда эти часы взялись и где риск.

Обмен объёма вместо доплаты

Не каждое изменение должно увеличивать бюджет. Часто разумнее поменять одну функцию на другую равной трудоёмкости. Здесь помогает приоритизация MoSCoW: must, should, could, won't. Новая хотелка из категории «must» может вытеснить что-то из «could», и договор с фиксированной ценой остаётся в своих рамках. Многие подрядчики закладывают в фикс-прайс резерв 10–20% на мелкие правки, чтобы не согласовывать каждую запятую.

Что говорит закон про фиксированную цену

Большинство договоров на разработку — это подряд по главе 37 ГК РФ или возмездное оказание услуг. Для подряда важна статья 709. По её пункту 4 цена в договоре бывает приблизительной или твёрдой, и по умолчанию считается твёрдой. При твёрдой цене подрядчик не вправе требовать её увеличения, а заказчик — уменьшения.

Поэтому изменение объёма нужно оформлять документом. По статье 452 ГК РФ изменение договора совершается в той же форме, что и сам договор. Если договор подписан на бумаге, значит, нужно дополнительное соглашение, а не сообщение в мессенджере. На практике многие договоры прямо описывают порядок изменений: через протокол или подписанный запрос.

Что делать, если допсоглашение не подписано

Бывает, что работа по изменению уже идёт, а документ застрял у юристов клиента. Тогда я бы фиксировал согласие хотя бы письмом с электронной почты ответственного лица: что именно меняется, сколько стоит и к какому сроку. Это не заменяет допсоглашение, но при споре показывает, что заказчик знал и согласился. Работать вообще без следа — худший вариант для обеих сторон.

Ошибки при работе с изменениями в фикс-прайсе

• Нет срока на ответ. Если клиент неделю думает над запросом, команда либо простаивает, либо делает на свой риск. Разумная норма — 2–3 рабочих дня.
• Делать «по-дружески» без записи. Через три месяца дружба заканчивается на акте.
• Копить изменения и выставлять их пачкой в конце проекта.
• Оценивать изменение одной цифрой, без разбивки по задачам.
• Молчать о влиянии на срок, обсуждая только деньги.
• Не фиксировать изменения, которые уменьшают объём. Они тоже нужны для честного баланса.