Главное за минуту
- Не начинайте правку по сообщению в чате: сначала зафиксируйте бизнес-цель и сценарий пользователя.
- До согласования запрос должен иметь оценку часов, влияние на сроки, риски и ответственного.
- Разделяйте ошибку реализации, уточнение исходного ТЗ и новую функциональность: это разные бюджеты.
- Принимайте доработку по проверяемым условиям, включая CRM, UTM, письма и права доступа.
01
Почему техническое задание меняется в процессе
В проекте на 1С-Битрикс новые требования обычно появляются после просмотра дизайна, теста формы или уточнения процесса продаж. Например, маркетинг просит добавить поле «Источник кампании» в форму, а отдел продаж — передавать его в сделку CRM.
Проблема не в самой правке, а в неявном решении «сделайте быстро». Такое изменение может затронуть шаблон формы, валидацию, обработчик, интеграцию, UTM-параметры и отчёты. Без фиксации команда теряет границы работ, а заказчик — контроль бюджета.
02
Запрос на изменение
Отдельная карточка правки связывает бизнес-цель, оценку и критерии приёмки с конкретной версией ТЗ.
03
Сначала определите тип правки
Тип изменения определяет, кто оплачивает работу и как быстро её можно взять в план. Руководителю проекта не нужно спорить о формулировках: достаточно сравнить фактический результат с согласованным ТЗ и макетами.
В практике ICONICA полезно вести реестр изменений рядом с основной постановкой, а не заменять исходный документ новой версией без истории.
Входит в работы
- Реализация расходится с утверждённым ТЗ.
- Не работает описанный сценарий или интеграция.
- Есть дефект в ранее принятой доработке.
Требует оценки
- Добавился новый экран, поле или роль.
- Изменился сценарий сделки, оплаты или доставки.
- Появилась интеграция, отчёт либо новое ограничение.
04
Что должна содержать карточка изменения
Не принимайте оценку «примерно на пару часов» без описания результата. Минимальная карточка позволяет проверить, что разработчик оценил весь путь данных, а не только видимый элемент страницы.
| Поле | Что зафиксировать | Пример |
|---|---|---|
| Цель | Зачем бизнесу правка | Разделить лиды рекламных каналов |
| Сценарий | Действие и ожидаемый итог | Форма → лид CRM → поле «Кампания» |
| Влияние | Затронутые сущности | Форма, CRM, почта, аналитика |
| Приёмка | Проверяемые условия | UTM сохраняются в карточке лида |
05
Мини-кейс: поле в форме оказалось не одной доработкой
Типовой запрос звучит просто: «Добавьте выбор региона в форму». При проверке выясняется, что регион нужен для маршрутизации лида, подстановки номера телефона и отчёта по рекламе.
Корректная оценка включает интерфейс, правила обязательности, передачу значения в CRM, тестовые заявки и проверку отчёта. Если оценить только форму, часть процесса останется ручной.
Оценивайте не элемент интерфейса, а полный сценарий от действия посетителя до результата сотрудника.
Готовое сообщение
Готовая формулировка задачи подрядчику
Цель: передавать выбранный регион из формы «Получить расчёт» в лид CRM для распределения заявок.
Сценарий: посетитель выбирает регион; после отправки менеджер видит значение в карточке лида, а заявка уходит в нужную очередь.
Ограничения: поле обязательно для двух форм, не показывается на английской версии; существующие UTM и уведомления не должны измениться.
Критерии приёмки: проверить две формы, три региона, заявку без UTM и заявку с UTM; приложить ссылки на тестовые лиды и перечень изменённых файлов или настроек.
Нужно от подрядчика: оценка в часах, перечень затронутых модулей, срок и риски до начала работ.
06
Маршрут согласования, который удерживает бюджет
Закрепите один канал для решений: трекер задач, CRM-проект или таблицу с неизменяемыми ID. Переписка может пояснять детали, но не должна заменять согласование объёма работ.
- 1
Зарегистрируйте запрос. Опишите цель, сценарий, ссылку на экран и приоритет для бизнеса.
- 2
Проверьте исходные договорённости. Сопоставьте запрос с ТЗ, макетом, протоколом встречи и уже принятыми задачами.
- 3
Получите оценку влияния. Запросите часы, срок, зависимости, риски и список затрагиваемых интеграций.
- 4
Примите решение. Одобрите бюджет, перенесите в следующий релиз или откажитесь от изменения.
- 5
Примите результат. Пройдите сценарий на тестовом стенде и зафиксируйте итог в карточке изменения.
07
Как маркетологу проверить результат до закрытия задачи
Попросите доступ к тестовому контуру и не ограничивайтесь визуальной проверкой. Для формы важно отправить реальную тестовую заявку, открыть её в CRM и убедиться, что данные не потерялись на переходах.
Если правка касается штатных механизмов, сверяйте настройку с документацией 1С-Битрикс. Скриншоты реальных решений можно запросить в портфолио ICONICA, не заменяя ими тестирование на вашем контуре.
Сайт
Поле, текст, адаптивность и ошибки валидации соответствуют задаче.
CRM
Значение пришло в нужную сущность и доступно ответственному сотруднику.
UTM
Метки не исчезают и не перезаписываются новой логикой формы.
Логи
Есть тестовые примеры и понятный способ найти ошибку после релиза.
08
Когда изменение нужно вынести в отдельный этап
Выносите задачу в отдельный релиз, если она меняет архитектуру, требует нового API, затрагивает оплату, персональные данные или несколько отделов. Срочность не отменяет оценки: она лишь влияет на приоритет.
Для накопившихся доработок полезнее собрать бэклог, ранжировать его по эффекту и риску, а затем утвердить лимит часов на релиз. Так бюджет становится управляемым, а не реактивным.
Есть ID изменения; указана бизнес-цель; оценены часы и срок; проверены CRM, UTM и уведомления; согласован ответственный; приложены критерии приёмки; результат проверен на тестовых данных.
FAQ
Частые вопросы
Можно ли менять ТЗ после подписания?
Да. Зафиксируйте изменение отдельной карточкой с оценкой, сроком и решением заказчика.
Кто утверждает дополнительные часы?
Сотрудник, у которого есть право распоряжаться бюджетом проекта. Это лучше указать в регламенте заранее.
Что делать, если разработчик уже начал работу?
Остановите только затронутую часть, зафиксируйте текущий статус и получите оценку нового объёма до продолжения.
Как отличить дефект от новой функции?
Сравните результат с согласованными сценариями и критериями приёмки, а не с устным ожиданием после старта.
Нужен ли новый договор на каждую правку?
Обычно достаточно процедуры change request в рамках договора, если она описывает порядок оценки и согласования.
