Новые требования посреди проекта: как не сорвать бюджет и сроки

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

Откуда берутся новые требования

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

Первые четыре причины полезны: изменения делают систему лучше. Пятая чаще всего нет.

Журнал изменений

Заведите простую таблицу — она защищает и вас, и подрядчика.

Подрядчик оценивает каждый запрос в течение 1–2 дней. Решение принимает один человек со стороны заказчика, у которого есть право менять бюджет.

Как принимать решение по запросу

Задайте три вопроса:

1. Без этого можно запуститься? Если да — переносим после запуска. Большинство запросов попадает сюда.
2. Это дешевле сделать сейчас, чем потом? Иногда да: поле в базе данных проще добавить до запуска, чем мигрировать живые данные. Тогда делаем сейчас.
3. Это меняет то, что уже сделано? Переделка готового всегда дороже нового. Если запрос ломает принятый этап, оценка должна включать переделку.

Почему «это же мелочь» бывает дорогим

Заказчик просит «просто добавить роль менеджера, который видит только своих клиентов». Кажется, что это одна галочка. На деле это проверка прав в каждом списке, отчёте, поиске, выгрузке и API, плюс тесты, что менеджер не видит чужого ни в одном месте. Это 2–5 дней работы, а не час.

Другой пример: «пусть заявка уходит ещё и в Telegram». Отправить уведомление — час. Но заявка содержит имя и телефон клиента, а Telegram — зарубежный сервис. Правильная реализация — отправлять номер заявки и ссылку в админку, а персональные данные хранить в базе в России. Это уже другой объём.

Просите подрядчика объяснить, из чего состоит оценка. Если он не может, оценка ненадёжна. Если может — вы видите, где можно упростить.

Фиксированная цена и изменения

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

Как разговаривать о стоимости изменений

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

Что прописать в договоре

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

Гражданский кодекс тоже разделяет эти случаи. Если цена в договоре твёрдая, подрядчик не вправе требовать её увеличения, а заказчик — уменьшения. Если смета приблизительная и появилась необходимость в дополнительных работах, из-за которых её придётся существенно превысить, подрядчик обязан своевременно предупредить заказчика (ст. 709 ГК РФ). Журнал изменений — простой способ выполнить это требование и не спорить потом о том, кто что знал.

Список «после запуска» — это не мусорная корзина

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