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