Новые требования посреди проекта: как оформить изменение объёма работ в разработке, чтобы не спорить о цене и сроке

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

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

Что просит заказчик	Что это	Как оформляется
Поменять порядок блоков на главной, переписать подписи кнопок	Правка в рамках согласованного макета	Входит в раунд правок этапа
Форма заявки не отправляет письмо, хотя в ТЗ это записано	Ошибка исполнителя	Исправляется без раунда и без доплаты
Добавить роль «бухгалтер», которая видит только счета	Изменение объёма: новая роль, права, экраны	Запрос на изменение, оценка, допсоглашение
Подключить вторую платёжную систему или склад	Изменение объёма: новая интеграция	Допсоглашение или следующий этап
Переделать каталог из плитки в таблицу с фильтрами по 12 параметрам	Изменение объёма: новая логика поиска и данные	Оценка; часто удобнее отдельным этапом
Заменить фирменный цвет после согласования макета	Смена согласованной концепции	Отдельная оценка, даже если работы немного

Чем изменение объёма отличается от правки?

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

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

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

Почему нельзя просто доделать по ходу?

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

Закон здесь на стороне порядка, а не одной из сторон. Если в договоре подряда не сказано иное, цена считается твёрдой, и подрядчик не вправе требовать её увеличения, а заказчик — уменьшения (п. 4 и 6 ст. 709 ГК РФ). Соглашение об изменении договора совершается в той же форме, что и сам договор, если иное не вытекает из закона или договора (п. 1 ст. 452 ГК РФ). Договор подписан на бумаге или электронно — так же оформляют и допсоглашение.

Есть и обратная сторона. Если разработчик видит, что ваше указание о способе работы может привести к неблагоприятным для вас последствиям или что не зависящие от него обстоятельства делают невозможным завершение в срок, он обязан немедленно предупредить и до ваших указаний приостановить работу (п. 1 ст. 716 ГК РФ). Поэтому честный ответ «это изменит срок на неделю» — не торг: закон прямо требует от исполнителя предупреждать о таких рисках.

Как разработчик оценивает новую функцию?

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

Что входит в нормальную оценку изменения:

• Новые экраны и состояния. Не только основной экран, но и пустой список, ошибка, загрузка, вид на телефоне.
• Данные. Новые поля и таблицы в базе, перенос уже накопленных данных, если структура меняется.
• Права. Кто видит и кто меняет новые данные. Новая роль затрагивает каждый экран, где проверяются права.
• Интеграции. Обмен с CRM, 1С, платёжным сервисом: часто нужен доступ к чужой системе, а его получение занимает больше времени, чем код.
• Влияние на сделанное. Какие готовые экраны и проверки придётся поменять, что нужно протестировать заново.
• Документация и приёмка. Обновление ТЗ и сценариев проверки, по которым функцию будут принимать.

Если изменение крупное, честнее сначала сделать короткую оценку с вариантами: полная версия функции, упрощённая и «вручную на первое время». Так проще решить, что нужно до запуска, а что подождёт. Для приоритизации пригодится метод из статьи о методе MoSCoW.

Поле	Что написать	Пример
Номер и дата	Порядковый номер запроса, дата	ЗИ-03 от 12.11
Что нужно	Что должен уметь сервис, глазами пользователя	Бухгалтер входит в кабинет и видит все счета клиентов, но не видит заказы и чаты
Зачем	Какую проблему это решает и что будет, если не делать	Сейчас счета выгружают вручную по пятницам, на это уходит полдня
Что уже есть в ТЗ	Ссылка на пункт ТЗ, который меняется или дополняется	Раздел «Роли»: администратор и менеджер
Приоритет	Нужно до запуска или можно после	Можно после запуска, но до конца квартала
Кто решает	Кто со стороны заказчика утверждает цену и срок	Финансовый директор
Оценка (заполняет исполнитель)	Стоимость, срок, что меняется в сделанном	Новая роль, 3 экрана, правка прав доступа, +N рабочих дней
Решение	Делаем сейчас, переносим в этап 2, отказываемся	Этап 2, допсоглашение ДС-01

Что написать в запросе на изменение?

Достаточно восьми полей: что нужно, зачем, какой пункт ТЗ меняется, приоритет и кто утверждает решение. Последние два поля заполняют после оценки. Один запрос — одно изменение, иначе часть пунктов согласуют, часть нет, и документ станет нечитаемым.

Запросы удобно вести в одной таблице или на доске задач проекта, с номерами по порядку: ЗИ-01, ЗИ-02. Номер потом указывают в допсоглашении и в акте, и через полгода видно, откуда в сервисе взялась каждая функция. У нас каждый запрос заводится задачей в личном кабинете клиента, оценка и решение остаются в её истории.

Поле «Зачем» заказчики часто пропускают, а оно экономит больше всего денег. Зная проблему, разработчик иногда предлагает решение дешевле запрошенного: вместо новой роли с отдельными экранами — ежедневную выгрузку счетов на почту бухгалтеру.

Допсоглашение или новый этап: что выбрать?

Допсоглашение к текущему договору подходит, когда изменение нужно до запуска и встраивается в текущую работу. Отдельный этап или новый договор — когда функцию можно сделать после запуска. Мелкие доработки после запуска удобнее брать в поддержку.

• Допсоглашение к текущему договору. Функция нужна к запуску, без неё сервис не решает задачу. Меняются ТЗ, спецификация, цена и срок основного договора, принимают всё одним актом.
• Следующий этап. Функция важна, но запуск без неё возможен. Сначала сдают и принимают согласованный объём, оплачивают его, а новую функцию делают отдельно со своим ТЗ, сроком и актом. Риски не смешиваются: задержка по новой функции не держит приёмку основной.
• Поддержка и развитие. Небольшие доработки после запуска, которых будет много. У нас это абонентка от 7 900 ₽ в месяц или разовые задачи; объём и цену каждой задачи согласуют до начала.

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

Что должно быть в допсоглашении?

Ссылка на договор, точное описание добавляемых или убираемых работ (или новая редакция ТЗ), стоимость, порядок оплаты, срок и то, как изменение принимается. Если чего-то из этого нет, спор просто переедет из договора в допсоглашение.

1. Реквизиты договора и номер соглашения: «Дополнительное соглашение № ДС-01 к договору № … от …».
2. Предмет изменения. Новые пункты ТЗ или его новая редакция приложением. Если функция заменяет другую, прямо написать, что исключается.
3. Стоимость. Отдельной строкой в спецификации и новое итоговое значение по договору.
4. Оплата. Как платится добавленная часть. Удобно повторить схему основного договора: у нас это 50 % предоплаты и 50 % после акта.
5. Срок. Новая дата сдачи всего результата или отдельный срок для дополнительной работы, и с какого события он считается.
6. Приёмка. Принимается ли дополнительная работа вместе с основной или отдельным актом.
7. Что не меняется. Фраза «остальные условия договора действуют без изменений» снимает вопросы о гарантии, правах и ответственности.

Состав работ и стоимость в нашем типовом договоре записаны в приложениях — ТЗ и спецификации. Допсоглашение обычно меняет именно их, а текст договора оставляет прежним. Образцы договоров лежат в разделе документов.

Как изменение сдвигает срок и приёмку?

Срок сдвигается на время дополнительной работы и на время, пока вы готовите материалы и доступы для неё. Приёмка либо переносится целиком на новую дату, либо делится: сначала акт по исходному объёму, затем отдельный акт по изменению.

Несколько деталей, о которых стоит договориться заранее:

• С какого момента считается новый срок. По нашему договору срок считается с даты предоплаты и передачи исходных материалов. Для изменения логично так же: с подписания допсоглашения, оплаты и получения нужных доступов.
• Что происходит со старой датой. Если дату сдачи не изменили в документе, она остаётся прежней, и пеня за просрочку (у нас 0,1 % в день, не более 10 % стоимости) считается от неё. Это неудобно обеим сторонам, поэтому новую дату записывают сразу.
• Сколько длится приёмка. На проверку результата по договору — 5 рабочих дней. Если изменение затронуло уже проверенные экраны, их тоже придётся пересмотреть, и это стоит учесть в своём графике.
• Гарантия. Гарантия 30 календарных дней считается с даты акта. При отдельном акте по изменению у дополнительной части будет свой гарантийный срок.

Как проверить сделанное перед подписанием, разобрано в чек-листе приёмки сайта.

Как выглядит изменение на условном примере?

Возьмём личный кабинет для клиентов с двумя ролями — администратор и менеджер. На середине разработки финансовый директор просит роль бухгалтера, который видит только счета. По ТЗ такой роли нет, значит, это изменение объёма.

Дальше по шагам. Заказчик заполняет запрос ЗИ-03 и пишет, зачем это нужно: счета выгружают вручную. Разработчик за пару дней возвращает оценку с двумя вариантами. Первый — полноценная роль: вход, три экрана, проверка прав на всех существующих экранах, повторное тестирование. Второй — автоматическая выгрузка счетов на почту раз в день, без новой роли. Заказчик выбирает второй вариант до запуска, а роль бухгалтера переносит в следующий этап. Обе работы фиксируют в допсоглашении ДС-01 с новой датой сдачи, основной объём принимают по исходному ТЗ.

Конкретные суммы в таком примере зависят от проекта, поэтому мы их не называем: базовая стоимость веб-приложения в прайсе — от 160 000 ₽, а цену изменения считаем после оценки и записываем в допсоглашение.

Как не превратить проект в бесконечный?

Договоритесь о точке заморозки объёма, копите запросы в списке вместо того, чтобы отдавать их в работу по одному, и назначьте одного человека, который утверждает изменения. Остальное решает простое правило: всё новое после заморозки — в следующий этап.

• Заморозка объёма. После согласования прототипа или на готовой сборке новые функции в текущий этап не принимаются, кроме тех, без которых запуск невозможен.
• Лист ожидания. Новые идеи записываются в отдельный список и разбираются раз в неделю или в конце этапа, а не по мере появления.
• Один ответственный. Запрос от отдела продаж и запрос от бухгалтерии могут противоречить друг другу. Решать должен один человек со стороны заказчика.
• Цена отказа. В каждом запросе отвечайте на вопрос «что будет, если не делать». Если ответ «ничего страшного», это кандидат в следующий этап.
• Дорожная карта. Когда идей много, их удобнее сразу разложить по кварталам.

Когда отдельное соглашение не нужно?

Когда изменение укладывается в раунд правок, когда это ошибка исполнителя и когда вы заменяете одну ещё не начатую функцию равноценной другой. В последнем случае достаточно письменно зафиксировать обмен, чтобы при приёмке проверяли новую версию ТЗ.

Ещё два случая без допсоглашения. Мелкие правки после запуска покрывает бесплатная поддержка: 7 дней у лендинга, бота, интеграций и ИИ-ассистента, 14 дней у магазина, веб- и мобильного приложения, 1 месяц у корпоративного сайта. Если же вы работаете по абонентке, новые задачи оцениваются и согласуются внутри неё. Где проходит граница между гарантийной ошибкой и доработкой после сдачи, разобрано в статье о гарантии на сайт и программу.

Какие ошибки встречаются чаще всего?

Самые дорогие ошибки — устные договорённости без цены и срока, пачка изменений одним письмом, отсутствие новой даты сдачи и попытка спрятать новую функцию в раунд правок. Каждая из них переносит спор с середины проекта в момент подписания акта.

• «Сделайте, потом посчитаем». Цена после выполнения почти всегда кажется заказчику завышенной, а исполнителю — заниженной.
• Десять изменений в одном письме. Согласовать по отдельности невозможно, оценить честно — тоже.
• Изменение без поправки в ТЗ. При приёмке проверяют по старому ТЗ, и новую функцию формально никто не обязан принимать или сдавать.
• Срок остался прежним. Работы стало больше, дата сдачи та же — конфликт заложен заранее.
• Изменения от разных людей. Разработчик получает противоречащие запросы и вынужден выбирать сам.
• Новая функция под видом правки. Раунд правок заканчивается спором, а не результатом. Честнее сразу назвать изменение изменением.

Чек-лист перед подписанием допсоглашения

• У изменения есть номер запроса и ссылка на пункт ТЗ.
• Описано, что сервис должен делать, и записаны критерии приёмки.
• Оценка включает переделку уже сделанного и повторную проверку.
• Есть стоимость отдельной строкой и новая итоговая сумма.
• Записаны порядок оплаты добавленной части и новая дата сдачи.
• Понятно, принимается изменение вместе с основным объёмом или отдельным актом.
• Соглашение подписано в той же форме, что и договор.
• Решение утвердил тот, кто отвечает за бюджет со стороны заказчика.

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

Короткие ответы на частые вопросы

Можно ли согласовать дополнительную работу в переписке, без допсоглашения?

Если договор признаёт переписку по электронной почте юридически значимой и в письме есть объём, цена и срок, это уже согласование. Но подписанное допсоглашение надёжнее: его проще приложить к акту и оно не теряется в цепочке писем.

Обязан ли разработчик делать новую функцию по старой цене?

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

Сдвигается ли срок сдачи, если я добавил функцию?

Обычно да, и это нужно записать прямо в допсоглашении: новую дату сдачи или отдельный срок для дополнительной работы. Если срок не изменили на бумаге, остаётся старый, и спорить о просрочке потом будет сложнее обеим сторонам.

Что делать, если оценка новой функции слишком дорогая?

Попросите разложить оценку на части и посмотрите, без чего функция всё ещё решает задачу. Часто можно сделать упрощённую версию сейчас, а остальное перенести в следующий этап или в поддержку после запуска.

Можно ли поменять одну функцию на другую без доплаты?

Да, если обмен равноценный по трудоёмкости и ещё не начатая функция убирается из ТЗ. Такой обмен тоже стоит зафиксировать письменно, чтобы при приёмке проверяли новую функцию, а не старую.

Услуги и кейсы по теме: типовые договоры · заказная разработка · цены и сроки