Магазин запущен, работает, приносит деньги — и тут же начинает обрастать «хотелками». Продажи просят новый блок на карточке, поддержка — починить фильтр, директор увидел у конкурента фишку, а разработчик напоминает, что обмен с 1С пора ускорять. Всё это валится в почту, чаты и устные разговоры, и через месяц никто уже не помнит, что обещали и что важнее. Знакомо?
Проблема не в том, что идей много, — это как раз хорошо. Проблема в отсутствии процесса: без него команда делает то, что громче просят, а не то, что приносит результат. В этой статье разберём, как выстроить сбор доработок магазина на 1С-Битрикс и приоритизировать их по понятным критериям, чтобы ресурс уходил на ценное, а не на «горящее». Многие доработки касаются обмена и учёта, поэтому процесс тесно связан с автоматизацией продаж и склада на 1С.
Коротко
- Заведите единый бэклог — одну точку входа для всех идей, багов и запросов.
- Разделяйте критичные баги, доработки и техдолг: у них разный приоритет и правила.
- Приоритизируйте по числовым критериям (ICE или RICE), а не по громкости просящего.
- Держите бэклог прозрачным, резервируйте часть спринта под техдолг и регулярно чистите хвост.
Почему хаос доработок дорого стоит
Отсутствие процесса приоритизации кажется мелочью, пока не посчитаешь его цену. Команда без бэклога работает по принципу «кто громче попросил» — а громче всех обычно не то, что важнее для бизнеса. В итоге ресурс разработки тратится на заметные, но малополезные правки, а действительно ценные задачи (те, что двигают выручку или снимают риск) годами лежат «на потом».
Ещё дороже обходится потеря доверия. Когда заказчик не понимает, почему его задача не сделана, а команда не может объяснить, что было важнее, начинаются конфликты. Каждая новая «хотелка» превращается в спор. Процесс приоритизации — это не бюрократия, а способ перевести эти споры из эмоций в рациональное русло: есть список, есть критерии, есть ограниченный ресурс, и задачи честно конкурируют за него.
Единая точка входа для идей и багов
Первый и главный шаг — одна точка входа. Пока задачи живут в разрозненных каналах, управлять ими невозможно: половина теряется, дубли плодятся, приоритет назначить не из чего. Нужен единый бэклог — список, куда стекается всё, независимо от источника и формы.
Единый бэклог даёт три вещи сразу:
- Полноту. Ничего не теряется — всё, что кто-то захотел, зафиксировано.
- Сопоставимость. Задачи лежат рядом и их можно сравнивать между собой.
- Дисциплину. «Хочу фичу» превращается в описанную задачу, а не мимолётную реплику в чате.
Инструмент вторичен — подойдёт любой трекер задач. Важно правило: если задачи нет в бэклоге, её не существует. Устные просьбы и сообщения «между делом» либо заносятся в список, либо не берутся в работу. Это дисциплинирует всех и защищает команду от постоянных внеплановых дёрганий.
Откуда берутся доработки
Чтобы бэклог был полным, полезно понимать основные источники доработок — тогда вы сознательно собираете вход, а не ждёте, пока прилетит само:
| Источник | Что приносит | Особенность |
|---|---|---|
| Клиенты и продажи | Запросы функций, жалобы на удобство | Ближе всего к деньгам, но субъективно |
| Поддержка | Повторяющиеся боли и баги | Хорошо видит частоту проблем |
| Аналитика | Точки отказа, узкие места воронки | Объективно, но требует интерпретации |
| Разработка | Техдолг, риски, оценка сложности | Видит то, что скрыто от бизнеса |
| Руководство | Стратегия, идеи от конкурентов | Важно, но легко подменяет данные |
Ни один источник не полон сам по себе. Клиенты не видят техдолга, разработка не всегда чувствует деньги, руководство может увлечься модной фишкой без спроса. Здоровый бэклог питается всеми потоками сразу, а приоритет расставляется уже с учётом всех точек зрения.
Баг, доработка или техдолг
Не все задачи в бэклоге равны, и путать их типы вредно. Разделяйте как минимум три категории, потому что у них разные правила приоритета:
- Баг. То, что должно работать, работает неправильно: не проходит оплата, обмен с 1С не выгружает заказы, умный фильтр даёт неверную выдачу. Критичные баги, ломающие продажи, идут вне очереди.
- Доработка. Новая возможность или улучшение работающего: новый блок на карточке, ускорение оформления, дополнительный способ оплаты. Доработки конкурируют между собой по ценности.
- Техдолг. Внутреннее качество: рефакторинг кастомных компонентов, ускорение обмена, обновление модулей. Не виден пользователю, но влияет на скорость всех будущих задач.
Смешение категорий приводит к перекосам: либо команда вечно тушит мелкие баги и не развивает магазин, либо гонится за фичами, а накопленный техдолг однажды обрушивает обмен или скорость. Явное разделение помогает держать баланс.
Как описать задачу, чтобы её оценили
Задача «сделать нормальный поиск» не приоритизируется — непонятно, что делать и зачем. Чтобы бэклог был рабочим, каждая запись должна нести минимум информации для оценки:
- Проблема, а не решение. «Закупщики не находят товар по коду 1С» вместо «прикрутить новый поиск» — так виден смысл и возможны разные решения.
- Кого касается. Кто страдает и как часто: все клиенты, только опт, редкий сценарий.
- Ожидаемый эффект. Что изменится — рост конверсии, экономия времени, снятие риска.
- Контекст. Ссылки на данные, скриншоты, обращения — чтобы не восстанавливать по памяти.
Хорошее описание экономит часы обсуждений и позволяет честно оценить и эффект, и трудозатраты. Плохо описанные задачи либо оседают внизу навсегда, либо берутся в работу с неверным пониманием и переделываются. Небольшая дисциплина на входе окупается многократно.
Критерии приоритета
Приоритет — это не «нравится / не нравится», а сопоставление ценности и затрат. Чтобы сравнивать разные по сути задачи, нужны общие критерии. Базовый набор такой:
- Влияние (Impact). Насколько задача двигает цель — выручку, конверсию, снижение затрат или риска.
- Охват (Reach). Сколько пользователей или сценариев затронет — вся аудитория или узкая группа.
- Уверенность (Confidence). Насколько вы уверены в эффекте: есть данные или это гипотеза.
- Трудозатраты (Effort). Сколько ресурса нужно на реализацию с учётом сложности в 1С-Битрикс.
Идея проста: высоко в списке оказываются задачи с большим влиянием и охватом, высокой уверенностью и низкими трудозатратами. «Дорого и сомнительно» опускается вниз, «дёшево и полезно» всплывает наверх. Эти же критерии лежат в основе популярных фреймворков приоритизации.
ICE и RICE на практике
Чтобы критерии превратились в порядок задач, их сводят в числовой балл. Два самых практичных фреймворка:
- ICE. Impact × Confidence × Ease. Каждый параметр оценивается, например, от 1 до 10, баллы перемножаются. Быстро и годится для оперативной приоритизации небольшого бэклога.
- RICE. (Reach × Impact × Confidence) / Effort. Добавляет охват и явно делит на трудозатраты. Точнее, когда важно, сколько людей затронет задача, и когда трудозатраты сильно разнятся.
Не относитесь к баллам как к точной науке — это инструмент разговора, а не истина. Их ценность в том, что команда вслух проговаривает оценки и делает предположения явными: почему эта задача «влияние 8, уверенность 3», а не наоборот. Часто именно спор об оценке вскрывает, что фичу все хотели «на глаз», а данных за ней нет. Метод вторичен — важно применять один и тот же ко всем задачам, чтобы список был сопоставим.
Место технического долга
Техдолг — вечный проигравший в приоритизации: он невидим клиенту, поэтому в честной конкуренции по «влиянию на выручку» почти всегда уступает заметным фичам. Но игнорировать его нельзя: накопленный долг замедляет каждую следующую доработку и повышает риск сбоев, особенно в обмене с 1С и кастомных компонентах.
Практичное решение — не заставлять техдолг конкурировать напрямую, а резервировать под него долю ресурса. Например, 15–20% каждого спринта отдавать под инфраструктуру, рефакторинг и ускорение. Тогда долг гарантированно двигается, а не откладывается вечно. Что именно относить к техдолгу и как его безопасно выкатывать, во многом определяется зрелостью процессов разработки — мы разбирали это в статьях про CI/CD и деплой Битрикс и D7 ORM в 1С-Битрикс.
От бэклога к спринтам и релизам
Приоритизированный бэклог — это ещё не работа. Задачи нужно превращать в поток релизов. Рабочий ритм обычно такой:
- Планирование. Раз в 1–2 недели берёте верх бэклога и набираете спринт под доступный ресурс.
- Фиксация объёма. Внутри спринта состав не меняется без веской причины — иначе ничего не доводится до конца.
- Реализация и проверка. Задачи делаются, тестируются, при необходимости через A/B-тест.
- Релиз. Готовое выкатывается предсказуемо, а не «когда-нибудь потом».
- Обратная связь. Результат возвращается в бэклог: что сработало, что породило новые задачи.
Отдельная тема — безопасный выкат на боевой магазин. Правки в обмен, оформление заказа или каталог нельзя выкатывать «наживую» без отката. Настроенный процесс развёртывания с возможностью быстро вернуться на предыдущую версию — обязательная часть зрелого развития; технически это относится к области инфраструктуры BitrixVM.
Прозрачность и роли в команде
Процесс работает только когда роли ясны и бэклог виден всем. Ключевое распределение:
- Владелец продукта. Один человек со стороны бизнеса, принимающий финальный приоритет и отвечающий за результат.
- Команда разработки. Даёт оценку трудозатрат, подсвечивает техдолг и риски, реализует.
- Поставщики задач. Продажи, поддержка, аналитика — приносят вход и обосновывают ценность.
Прозрачность бэклога снимает большую часть конфликтов. Когда все видят общий список, критерии и текущий приоритет, спор «почему моя задача не сделана» отпадает сам: видно, что ресурс ограничен и что стоит выше и почему. Это дисциплинирует просящих — приходится обосновывать ценность, а не давить срочностью — и защищает команду от произвольных вмешательств.
Чистка бэклога и ретро
Бэклог, который только растёт, со временем превращается в кладбище задач и сам становится источником стресса. Здоровый процесс включает регулярную уборку:
- Чистка хвоста. Раз в квартал пересматривайте низ списка: часть задач устарела, часть потеряла смысл, часть можно объединить или удалить.
- Ретроспектива. Периодически разбирайте не сами задачи, а процесс: что тормозит, где теряется вход, точны ли оценки.
- Проверка гипотез. Сверяйте, сбылся ли ожидаемый эффект сделанных доработок — это калибрует будущие оценки.
Лучше держать короткий живой бэклог из десятков актуальных задач, чем архив из тысячи «когда-нибудь». Признать, что часть задач не будет сделана никогда, — это не поражение, а честность, которая делает список рабочим инструментом, а не свалкой.
Частые ошибки
- Нет единой точки входа. Задачи живут в чатах и почте, половина теряется.
- Приоритет по громкости. Делается то, что настойчивее просят, а не то, что ценнее.
- Смешение багов и фич. Критичные баги тонут в общей очереди или наоборот пожирают весь ресурс.
- Техдолг вечно внизу. Не зарезервирована доля спринта, долг растёт до сбоя.
- Задачи-заголовки. «Улучшить поиск» без проблемы, охвата и эффекта — нечего оценивать.
- Оценки под желаемое. Баллы подгоняются, чтобы «протащить» любимую фичу.
- Непрозрачность. Бэклог скрыт, отсюда бесконечные конфликты о приоритетах.
- Бэклог не чистят. Список растёт бесконечно и парализует сам себя.
Чек-лист процесса
- Единый бэклог заведён. Одна точка входа, правило «нет в списке — не существует».
- Источники подключены. Клиенты, поддержка, аналитика, разработка и руководство питают вход.
- Типы разделены. Баги, доработки и техдолг помечены, критичные баги идут вне очереди.
- Задачи описаны. Проблема, охват, эффект и контекст — минимум для оценки.
- Критерии едины. Один фреймворк (ICE или RICE) применяется ко всем задачам.
- Техдолг зарезервирован. Фиксированная доля спринта уходит на качество и инфраструктуру.
- Ритм релизов налажен. Планирование, фиксация объёма, проверка, безопасный выкат.
- Прозрачность и роли. Бэклог виден команде, финальный приоритет за одним владельцем.
- Регулярная чистка. Хвост разбирается, гипотезы сверяются, процесс ретроспективно улучшается.
Вывод
Доработки магазина — не проблема, а признак того, что он живёт и развивается. Проблема возникает, когда нет процесса: тогда команда тратит ресурс на громкое вместо ценного, а между бизнесом и разработкой копятся конфликты. Лечится это системно: единая точка входа, честное разделение багов, доработок и техдолга, приоритизация по общим критериям и прозрачный бэклог.
Не гонитесь за идеальным методом — ICE или RICE одинаково хорошо работают, если применять их последовательно и честно. Гораздо важнее сама дисциплина: собирать вход, обсуждать оси приоритета вслух, резервировать долю под техдолг и регулярно чистить список. Тогда развитие магазина на 1С-Битрикс станет предсказуемым потоком ценности, а не бесконечным тушением пожаров.
