Новая идея появилась после утверждения ТЗ: как изменить сайт без конфликта по срокам

Почему просьба «добавить еще один блок» иногда меняет весь проект

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

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

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

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

Смотрите на путь посетителя, а не на один макет

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

Такой разбор не требует технического аудита на каждом созвоне. Достаточно ответить на три вопроса: какое действие посетителя должно измениться, какие части сайта из-за этого затрагиваются и какой результат бизнес сможет проверить после запуска. Если ответа нет, предложение пока остается идеей, а не готовой задачей для производства.

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

«В согласовании я всегда возвращаю разговор к человеку на сайте. Если мы не можем назвать, что он увидит иначе, что сделает дальше и как бизнес это примет, запрос рано отдавать в разработку. Сначала нужно договориться о результате, а уже потом выбирать способ реализации».

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

Зафиксируйте карточку изменения до начала работы

Новый документ на десятки страниц не нужен. Обычно хватает одной понятной карточки, которая живет рядом с ТЗ и заменяет устные версии решения. Ее задача - дать одинаковый контекст клиенту, аккаунт-менеджеру, дизайнеру, разработчику и тому, кто будет принимать результат.

В карточке стоит записать:

1. Что именно меняется: страница, функция, сценарий, контент или приоритет.
2. Зачем это нужно бизнесу и какое действие посетителя должно стать возможным или понятнее.
3. Какие части текущего ТЗ затрагиваются.
4. Что требуется от команды клиента: факт, цена, материал, решение или согласование.
5. Какой вариант выбран для текущего этапа и что происходит со сроком.
6. По какому признаку новая часть будет принята.

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

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

Выберите один из трех маршрутов вместо обещания сделать все сразу

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

Второй вариант - расширить этап. Он работает, если прежняя задача остается обязательной, а у команды есть согласованный ресурс выполнить новую. Здесь важно назвать не только добавленную работу, но и новые входные данные, контрольную дату и отдельный критерий приемки. Слово «параллельно» не отменяет того, что кому-то понадобится подготовить контент, проверить функцию и подтвердить результат.

Третий вариант - перенести идею в backlog следующего этапа. Это не способ убрать неудобный запрос. Хорошая идея сохраняется с причиной, первыми вводными и условием, при котором к ней вернутся. Такой вариант особенно полезен, когда текущий этап уже близок к приемке: новая задача не ломает качество запуска, а получает нормальную подготовку вместо спешки.

Новая идея не должна исчезать из-за того, что она появилась не вовремя. Но и текущий этап не обязан поглощать ее без выбора приоритета, объема и срока.

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

Не прячьте влияние на срок за словом «согласуем потом»

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

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

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

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

Проверьте изменение на приемке, а не только в переписке

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

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

Перед передачей результата проверьте именно новый путь посетителя: от точки входа до действия, которое стало возможным после изменения.

Если подготовка сайта только начинается, полезно сначала пройти kickoff разработки сайта: там закрепляются роли, вводные и первая версия результата. Для самого создания и развития сайта команда Медиакода использует отдельный контур разработки сайтов. В середине проекта эти две опоры помогают вернуть разговор от случайного комментария к понятной задаче.