Что такое change request и как оплачиваются доработки
Основы3 минРедакция Innovialabs
Коротко
Change request — это формальный запрос на изменение согласованного объёма работ: его описывают, оценивают по времени и деньгам, утверждают письменно и только потом выполняют и оплачивают отдельно.
Короткий ответ
Change request (CR, запрос на изменение) — это официальная просьба изменить то, о чём уже договорились: добавить функцию, поменять логику, переделать экран. Всё, что выходит за рамки утверждённого ТЗ или бэклога, оформляется как CR.
Каждый CR проходит один и тот же путь: описание → оценка → согласование → выполнение → оплата. Это защищает обе стороны: заказчик заранее знает цену и влияние на сроки, а подрядчик не работает бесплатно.
Изменение или ошибка: в чём разница
Главный спорный вопрос — кто платит. Ответ зависит от того, что было зафиксировано в требованиях.
| Ситуация | Что это | Кто платит |
|---|---|---|
| Функция работает не так, как описано в ТЗ | Баг | Подрядчик (в рамках гарантии) |
| Функция работает по ТЗ, но вы хотите иначе | Change request | Заказчик |
| Нужна новая функция, которой не было в ТЗ | Change request | Заказчик |
| Требование в ТЗ было неоднозначным | Обсуждается | Зависит от договора и переписки |
| Сломалось после изменений во внешнем сервисе | Обычно поддержка или CR | По договору поддержки |
Отсюда правило: чем точнее ТЗ и критерии приёмки, тем меньше споров.
Как проходит change request
1. Запрос
Заказчик описывает, что хочет изменить и зачем. Хороший запрос отвечает на вопросы:
- что сейчас работает и как;
- что должно стать иначе;
- почему это нужно бизнесу;
- насколько это срочно.
2. Оценка
Подрядчик анализирует влияние изменения:
- трудозатраты — сколько часов по ролям (разработка, дизайн, тестирование);
- сроки — сдвигается ли релиз или другие задачи;
- риски — что ещё может затронуть изменение;
- стоимость — по ставке или фиксированной ценой.
3. Согласование
Заказчик принимает, отклоняет или откладывает CR. Решение фиксируется письменно: подпись, дополнительное соглашение или подтверждение в системе управления задачами — в зависимости от договора.
4. Выполнение и приёмка
Изменение реализуют, тестируют и принимают по тем же правилам, что и основную работу.
5. Оплата
Обычно используют одну из моделей:
- Time & material — оплачиваются фактически потраченные часы.
- Фиксированная цена за CR — согласованная сумма за конкретное изменение.
- Пакет часов — заранее купленный объём часов на доработки, из которого списываются CR.
- Резерв в бюджете — часть бюджета проекта заранее выделяется под изменения.
Как вести чистую документацию
- Один CR — один документ или задача. Не смешивайте несколько изменений в одном запросе.
- Нумерация и статусы. Например, CR-012: «новый», «оценён», «утверждён», «выполнен», «отклонён».
- Журнал изменений. Таблица со всеми CR, их оценками, решениями и датами.
- Ссылки на исходные требования. Указывайте, какой пункт ТЗ меняется.
- Решения только письменно. Договорённости в звонке подтверждайте сообщением или в системе задач.
| Поле журнала | Пример содержания |
|---|---|
| Номер | CR-012 |
| Описание | Добавить фильтр по дате в отчёт заказов |
| Связанное требование | Раздел ТЗ «Отчёты» |
| Оценка | Часы по ролям и влияние на срок |
| Решение | Утверждён / отклонён, дата, кто утвердил |
| Статус | Выполнен, принят |
Частые ошибки
- Устные доработки «по дружбе». Потом трудно понять, почему вырос бюджет и сдвинулись сроки.
- Начинать работу до согласования оценки. Возникают споры об оплате.
- Считать любое изменение багом. Это портит отношения с подрядчиком и затягивает проект.
- Не учитывать влияние на сроки. Даже небольшой CR может сдвинуть релиз, если затрагивает связанные модули.