Во время разработки появляются новые материалы, уточняются процессы и меняются решения. Задача управления изменениями — сделать последствия понятными до выполнения работы. Для этого запрос нужно связать с текущим согласованным результатом, зависимостями и способом приёмки.
Не всякое замечание является дополнительным объёмом. Сначала выясните, речь об исправлении несоответствия, уточнении уже согласованного поведения или новой возможности. Оценка и порядок согласования зависят от этой разницы и договорённостей проекта. Ниже — рабочая процедура обсуждения, а не толкование конкретного договора.
Начните с запроса и основания
Опишите, что должно измениться и зачем. Назовите человека, которому нужна возможность, и наблюдаемый результат. Фраза «добавить личный кабинет» слишком широка: просмотр заказов, редактирование профиля и доступ к документам — разные сценарии с разными данными и правилами.
Приложите ссылку на текущую версию требований или макета. Если результат отклоняется от согласованного, укажите конкретное расхождение. Если условие прежде не было определено, запишите неизвестное и вопрос для решения. Не называйте новый запрос исправлением только потому, что он кажется небольшим, и не объявляйте любой вопрос платной доработкой без разбора основания.
Для проверки формулировок используйте критерии приёмки. Они помогают сравнить ожидаемое поведение с тем, что действительно входило в результат.
Заполните карточку изменения
Сохраните запрос в одном месте и присвойте ID. Переписка может быть источником, но итоговая карточка должна содержать актуальное решение без необходимости собирать его из разных сообщений.
| Поле | Что указать |
|---|---|
| Запрос и причина | Какой результат нужен и какую задачу он решает |
| Основание | Новое требование, уточнение или расхождение с указанной версией |
| Затронутый объём | Страницы, состояния, языки, CMS, данные, интеграции и документация |
| Зависимости | Материалы, доступы, решения и внешние системы, необходимые для выполнения |
| Варианты и оценка | Состав каждого варианта, допущения, влияние на работы, даты и расходы |
| Приоритет и решение | Почему сейчас, что заменяется или откладывается, кто согласовал |
| Версия и приёмка | В какой выпуск входит запрос и как будет проверен результат |
| Состояние и следующий шаг | Уточняется, оценивается, ожидает решения, согласован, выполняется, проверяется или закрыт |
Не подставляйте цену или срок в неизвестное поле ради заполненной таблицы. Если данных мало, сначала согласуйте действие для оценки: разобрать сценарии, получить документацию интеграции или проверить техническое ограничение.
Посмотрите на влияние целиком
Проверьте не только видимую правку. Новый фильтр может затронуть данные каталога, редакторские поля, пустые состояния и мобильный интерфейс. Дополнительный язык — подготовку материалов, переключение страниц и поддержание актуальности переводов. Состав определяется конкретным запросом; не каждая правка вызывает все перечисленные последствия.
Отметьте, какие результаты уже согласованы или реализованы и что потребуется пересмотреть. Вернитесь к ограничениям проекта: фиксированная дата, доступность редактора, готовность материалов и возможности внешних систем могут влиять на порядок работ.
Разделите время выполнения и календарное ожидание. Даже небольшая работа может зависеть от ответа внешнего поставщика. В календарном плане сайта должны быть видны эти зависимости, а не только новая дата окончания.
Учебный пример: новый фильтр каталога
Вымышленная ситуация: в согласованном каталоге есть категории, а во время дизайна заказчик просит фильтрацию по техническим характеристикам. До оценки нужно выяснить, какие характеристики существуют, где хранятся значения, насколько они заполнены и как сочетать условия.
Карточка CR-01 может содержать два обсуждаемых варианта. Первый — фильтр по одному подтверждённому полю с согласованными состояниями и ручным наполнением. Второй — несколько характеристик с обменом данными из внешней системы. Это разные составы, а не заранее известные цены.
Для обоих определяют результат пустой выдачи, сброс выбора, мобильное поведение и работу редактора. Если интеграция ещё не описана, её влияние остаётся неизвестным; помочь уточнению может карта интеграций.
Решение может быть любым обоснованным: включить вариант в текущий выпуск, заменить им другую задачу, перенести на следующий этап или отказаться. В примере нет фактической сметы, клиента или результата CoreWeb.
Согласуйте приоритет и новую границу
Перед решением покажите последствия вариантов для состава, последовательности и приёмки. Слово «срочно» должно иметь причину: событие бизнеса, обязательная зависимость или значимый пользовательский барьер. Приоритет не отменяет необходимость понять объём.
Если дата остаётся фиксированной, явно перечислите, какие работы сохраняются и что исключается или переносится. Если изменяются расходы, укажите, что входит в новую оценку и на каких допущениях она основана. Не считайте согласованным вариант только потому, что участник прислал идею в чат.
Назначьте принимающую решение роль и зафиксируйте выбранный вариант. Новые условия должны быть доступны всем исполнителям, которых они затрагивают. При изменении содержания или интерфейса обновите связанные материалы, а не только название задачи.
Свяжите выполнение с версией и проверкой
Укажите выпуск, в который входит изменение. Обновите требования, макеты, план материалов и проверочные сценарии в необходимом объёме. Сохраняйте связь с предыдущим решением: участникам должно быть понятно, почему результат теперь отличается от исходного.
После выполнения проверьте согласованный сценарий и соседние функции, которые могли измениться. Например, новый фильтр не должен незаметно изменить поведение существующих категорий. Фраза «реализовано» и факт успешной приёмки — разные состояния задачи.
Для проверки используйте практикум приёмки. Если выявлено расхождение, запишите его и повторную проверку. Если запрос снова расширяется, заведите связанное изменение, сохранив границы предыдущего.
Что обсудить на встрече
Пройдите открытые карточки: какие данные появились, что мешает оценке, чьё решение требуется и какие версии изменились. Для каждого пункта должен быть следующий шаг. Процент «почти готово» не помогает, если ключевой вариант ещё не выбран.
При обсуждении разработки сайта под ключ полезно заранее согласовать такой порядок: кто принимает решения, где хранится актуальный объём и как проверяется новый результат. Тогда изменения остаются управляемой частью проекта, а не набором незафиксированных обещаний.
Чтобы применить этот порядок к одному пожеланию, заполните карточку изменения в академии: исходное требование, последствия, открытые вопросы и решение до начала работ.
До согласования объёма соберите план состава сайта: разделите первый выпуск и следующие этапы, запишите зависимости и открытые вопросы.