Как оценить доработки сайта на Битрикс и собрать приоритетный бэклог

01

Почему список пожеланий не становится бэклогом

На сайте на 1С-Битрикс задачи обычно накапливаются в разных местах: менеджер пишет о форме в мессенджере, маркетолог хранит идеи в таблице, отдел продаж сообщает о потерянных лидах, а подрядчик присылает перечень технических замечаний. В результате рядом лежат просьба поменять баннер, ошибка оплаты, обновление ядра и идея нового личного кабинета. У этих пунктов разный эффект, риск и объём работ, но их часто обсуждают как одинаковые «доработки».

Приоритетный бэклог — это единый список решений, а не перечень экранов и кнопок. У каждой записи есть владелец, проблема, затронутый путь пользователя, ожидаемый эффект, срочность, ограничения и статус. Тогда руководитель понимает, почему исправление передачи заказа в CRM должно выйти раньше нового фильтра каталога, а разработчик не начинает работу по фразе «сделайте удобнее».

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

Полезный результат первого разбора — реестр из 20–60 понятных карточек вместо сотен сообщений. Уже на этом этапе видно, какие доработки сайта на Битрикс можно объединить в один релиз, а какие требуют аудита кода, интеграции или бизнес-процесса.

03

Какие данные собрать по каждой доработке

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

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

Добавьте ссылку на подтверждение проблемы: запись вебвизора, номер обращения, отчёт CRM, URL с параметрами UTM, ошибку из журнала или обращение клиента. Не все обращения требуют полного исследования, но решение с влиянием на оплату, лиды, персональные данные или обмен с 1С нельзя ставить в работу без проверяемых фактов.

04

Разделите задачи на четыре очереди

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

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

Статус «не сейчас» полезнее, чем бесконечное перетаскивание задачи между спринтами. Зафиксируйте причину: нет эффекта, требуется исследование, отсутствует владелец процесса или работа зависит от другой задачи. Так бэклог остаётся инструментом решений, а не архивом обещаний.

05

Оценивайте влияние до оценки часов

Трудоёмкость отвечает на вопрос «сколько стоит сделать», но не отвечает «зачем делать первым». Для задач P1–P3 достаточно простой шкалы от 1 до 5 по четырём параметрам: влияние на выручку или расходы, охват пользователей, срочность и уверенность в эффекте. Отдельно оцените сложность и риск. Не пытайтесь получить математическую точность: цель модели — сделать основания выбора видимыми для маркетинга, продаж и разработки.

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

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

Высокий приоритет получают не самые заметные просьбы, а задачи с доказанным эффектом, понятным сценарием и приемлемым риском внедрения.

06

Проведите разбор бэклога за одну рабочую сессию

Не нужно ждать идеальной документации. Назначьте встречу на 60–90 минут с владельцем сайта, маркетологом, представителем продаж и техническим ответственным. Перед встречей выгрузите задачи из трекера, почты и чатов в один лист. Во время сессии не обсуждайте дизайн решения дольше нескольких минут: фиксируйте проблему, владельца и следующий шаг.

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

После сессии список должен быть доступен всем участникам, а правила изменения приоритета — прозрачны. Иначе уже на следующий день срочные сообщения в личных чатах снова разрушат согласованную очередь. Минимально достаточно еженедельного короткого просмотра P0–P2 и ежемесячного пересмотра гипотез.

1. 1

   Соберите источники. Перенесите обращения, ошибки, идеи, отчёты CRM и технические рекомендации в единый реестр.

2. 2

   Уберите повторы. Свяжите разные симптомы с одной причиной и оставьте одну основную карточку.

3. 3

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

4. 4

   Поставьте очередь. Отделите инциденты и обязательства от улучшений и неподтверждённых гипотез.

5. 5

   Запросите оценку. Передайте подрядчику карточки с критериями, а неизвестные зависимости вынесите в исследование.

07

Что проверить на сайте и в CRM после релиза

Приёмка доработки не заканчивается фразой «на тестовом сайте работает». Маркетологу важно пройти путь пользователя в реальном окружении: открыть нужную страницу на мобильном устройстве, перейти с UTM-метками, заполнить форму, получить письмо и найти результат в CRM. Для заказа дополнительно проверяются статусы, состав корзины, цена, доставка и оплата.

Техническому ответственному стоит проверить журнал ошибок, скорость ключевых страниц, права доступа и влияние на кэш. На Битрикс изменения компонента, шаблона или обработчика могут проявиться не на той странице, которую тестировали. Если доработка затрагивает стандартный функционал, сверяйтесь с документацией для разработчиков 1С-Битрикс, а не только с описанием в задаче.

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

08

Ошибки, из-за которых бэклог перестаёт работать

Первая ошибка — смешать поддержку и развитие. Плановые улучшения нельзя ставить в одну очередь с авариями без отдельного резерва времени. Иначе каждая проблема будет отменять обещанные маркетинговые изменения, а бизнес не сможет планировать кампании. Для регулярной поддержки заранее согласуйте канал обращений, время реакции и правила для P0.

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

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

09

Когда достаточно внутренней сортировки, а когда нужен подрядчик

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

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

Хороший бэклог не гарантирует, что все идеи будут реализованы. Он даёт управляемое решение: что исправлять сейчас, что планировать на квартал, что проверять данными и что не делать вовсе. Регулярно пересматривайте приоритеты по фактическим заявкам, заказам, ошибкам и изменениям в процессах — тогда сайт развивается вместе с бизнесом, а не по громкости сообщений.