Как сформировать бэклог продукта для корпоративной системы: пошаговый процесс и приоритизация

Бэклог продукта (продуктовый бэклог) корпоративной системы не пишут с чистого листа. Его собирают из остатков ТЗ, заявок подразделений, обязательных требований и техдолга. Порядок такой: цель продукта, инвентаризация, дедупликация, декомпозиция на эпики и истории, приоритизация, подготовка верха списка к разработке. Очерёдность задаёт один владелец продукта. В Scrum Guide (ноябрь 2020) про эту роль сказано: «one person, not a committee». Регуляторным задачам и техдолгу выделяют фиксированную долю ёмкости команды.

Типичная картина: у ERP пятнадцать подразделений-заказчиков, в Service Desk сотни заявок с пометкой «срочно», а поправка к закону приходит с датой, которую никто не перенесёт.

Что такое бэклог продукта и чем он отличается от бэклога спринта и проекта

Бэклог продукта (product backlog) — это упорядоченный и постоянно меняющийся список всего, что нужно сделать для развития продукта. В Scrum Guide (ноябрь 2020) он назван «an emergent, ordered list» и считается единственным источником работы для Scrum-команды.

Цель продукта (Product Goal) — это будущее состояние продукта, под которое планируют работу. В Scrum Guide 2020 цель названа «обязательством» бэклога. Судя по Scrum Guides Revisions, Product Goal появилась только в редакции 2020 года.

Путаница начинается с трекера. Бэклогом задач там называют любую очередь, включая операционку, а продуктовый бэклог касается только развития. Статус «Backlog» в карточке означает всего лишь «приняли, но не запланировали».

Бэклог продукта и бэклог спринта: в чём разница

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

Параметр	Бэклог продукта	Бэклог спринта	Бэклог проекта
Горизонт	Жизненный цикл продукта	Один спринт	Срок проекта
Кто владеет	Владелец продукта	Разработчики	Руководитель проекта
Что внутри	Эпики, истории, дефекты, техдолг, обязательное	Элементы, цель и план спринта	Работы по ТЗ
Когда меняется	Постоянно	В пределах цели спринта	Через управление изменениями
Чем заканчивается	Пока жив продукт, ничем	Инкрементом	Актом приёмки

Бэклог продукта или бэклог проекта: внедрение против развития

Внедрение ERP — проект с ТЗ и датой запуска. Развитие после запуска уже продукт, и даты окончания у него нет. Отложенные пункты ТЗ и замечания эксплуатации первыми попадают в продуктовый бэклог. Такой же хвост доработок оставляет и замена SAP и Oracle на российские платформы.

Как выглядит хороший бэклог: принцип DEEP

Хороший бэклог отвечает свойствам DEEP (Mountain Goat Software, 10.10.2024). Innolution приписывает акроним Роману Пихлеру и Майку Кону.

• Detailed appropriately. Подробно описан только верх: истории на 1–2 спринта, а эпики на год умещаются в строку.

• Estimated. У элементов есть хотя бы грубая оценка, иначе WSJF не посчитать.

• Emergent. Список меняется вместе с нормами и платформой.

• Prioritized. У каждого элемента своё место в очереди, без «равных» позиций.

Чем бэклог корпоративной системы отличается от бэклога B2C-продукта

Бэклог корпоративной системы наполняют не гипотезы роста метрик, а десяток внутренних заказчиков, закон с датами и legacy. A/B-тесты на ERP, CRM и СЭД почти не работают, аудитория маленькая и выбора системы у неё нет.

Фактор	Как проявляется	Что это значит для бэклога
Много внутренних заказчиков	Бухгалтерия, склад, продажи, HR: у каждого «срочно»	Прозрачные правила и квоты
Регуляторика с датой	152-ФЗ, ФСТЭК, импортозамещение	Тип «обязательное», приоритет задаёт дата нормы
Legacy и техдолг	Доработки поверх старой платформы	Техдолг как видимые элементы с долей ёмкости
Интеграции	Банк-клиент, ЭДО, MDM, BI	Зависимости от смежных систем
Календарь бизнеса	Закрытие месяца и года	Окна заморозки релизов, задачи под дату
Фиксированная аудитория	Пользователи в штате	Reach почти не различает задачи

Scrum.org (21.11.2025) пересказывает 18-й State of Agile (Digital.ai): лишь 15% бизнес-руководителей реально участвуют в Agile-практиках, а 53% респондентов не могут приоритизировать, потому что не доверяют данным. Когда правила не записаны, выигрывает тот, кто громче.

Регуляторные требования: когда приоритет задаёт закон, а не бизнес-ценность

Регуляторное требование входит в бэклог системы как обязательный элемент с жёстким сроком. В 2025–2026 годах таких источников четыре.

• 420-ФЗ от 30.11.2024, в силе с 30.05.2025 (ppt.ru, 02.12.2024). За повторную утечку ПДн полагается оборотный штраф 1–3% выручки, от 25 до 500 млн руб.

• Ч. 5 ст. 18 152-ФЗ (ред. 23-ФЗ), с 01.07.2025: базы с ПДн граждан РФ должны находиться в России. Минцифры (письмо от 12.05.2025 № П25-44929, не НПА) считает иностранную веб-аналитику с ПДн трансграничной передачей.

• Приказ ФСТЭК № 117 от 11.04.2025, в силе с 01.03.2026 (обзор ppt.ru, 18.06.2025). Он заменил приказ № 17 для ГИС, ИС госорганов, ГУП и госучреждений.

• Указ Президента РФ № 166 от 30.03.2022 (указ, не закон). С 01.01.2025 госорганам и заказчикам по 223-ФЗ запрещено иностранное ПО на значимых объектах КИИ (Контур.Толк, 20.12.2024). Остального бизнеса запрет не касается.

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

*Раздел носит информационный характер и не заменяет консультацию юриста.

Почему «простая доработка» в ERP оказывается дорогой: legacy, интеграции и техдолг

«Простая доработка» в ERP дорога из-за интеграций. Добавили новое поле, а за ним тянутся правки обмена с банком, MDM, отчётов и полный регресс.

Технический долг — это будущие затраты на исправление решений, принятых ради скорости. Метафору предложил Уорд Каннингем (OOPSLA '92): черновой код он сравнил с займом, а обход неудачного решения с процентами по нему.

McKinsey (25.04.2023) пишет, что основную часть техдолга предприятия обычно дают 10–15 активов. Компании с самым тяжёлым техдолгом на 40% чаще срывают модернизации.

Из чего состоит бэклог продукта: эпики, user story, дефекты, техдолг и обязательные требования

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

Иерархия элементов: эпик → фича → история → задача

Эпик — это крупный блок работы, который разбивают на истории и делают обычно несколько спринтов (Atlassian).

User story (пользовательская история) — это короткое описание функциональности глазами того, кому она нужна. Шаблон Майка Кона: «Как [роль], я хочу …, чтобы …».

Если верить Wikipedia, истории ввёл Кент Бек в XP в 1997 году, а шаблон с ролью и целью придумала команда Connextra в 2001-м. Фича занимает уровень между эпиком и историей. Задача означает технический шаг внутри истории.

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

Качество истории проверяют по INVEST Билла Уэйка (17.08.2003): Independent, Negotiable, Valuable, Estimable, Small, Testable.

Пять типов элементов, без которых бэклог корпоративной системы неполон

Тип	Пример из ERP, CRM, СЭД	Кто инициирует	Как приоритизировать
Развитие	Резерв товара под заказ	Подразделение	WSJF в рамках квоты
Дефект	Двойное проведение документа	Пользователи, QA	По влиянию на процесс
Техдолг	Отказ от файлового обмена с банком	ИТ, архитектор	Фиксированная доля ёмкости
Обязательное	Локализация ПДн, журнал доступа	ИБ, юристы	Вне скоринга, по дате нормы
Исследование (спайк)	Перенос отчётов на российскую BI	Владелец продукта	Перед крупным эпиком

Бэклог гипотез и бэклог идей лучше держать отдельно. Идея переезжает в основной список, когда у неё появились инициатор, понятная проблема и ожидаемый результат.

Что не нужно хранить в бэклоге

• Операционные заявки вроде сброса пароля или выдачи прав. Им место в Service Desk, а развести потоки помогает MyFellow Bot (продукт iFellow).

• Дубли одной и той же потребности.

• Идеи без владельца и задачи, ценность которых нельзя проверить.

Как сформировать бэклог продукта за 7 шагов: от накопленных заявок до готовых к разработке элементов

Формирование бэклога продукта для работающей системы начинается с инвентаризации ТЗ внедрения, заявок Service Desk и Excel-реестров. Дорожная карта появится позже. Вот как формируется и планируется бэклог:

Шаг	Что делаем	Кто	Результат
1	Фиксируем цель и периметр	Владелец продукта, ИТ-директор	Подписанная страница
2	Собираем вход	Бизнес-аналитик	Сырой реестр
3	Удаляем дубли, нормализуем	Аналитик, ключевые пользователи	Нормализованный реестр
4	Раскладываем на эпики и истории	PO, аналитик, архитектор	Карта историй
5	Размечаем тип, источник, зависимости	Аналитик	Реестр с обязательными полями
6	Приоритизируем	Владелец продукта, комитет	Упорядоченный бэклог
7	Готовим верх к разработке	Владелец продукта, разработчики	Элементы на 1–2 спринта

Шаг 1. Зафиксируйте цель продукта и границы системы

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

Шаг 2. Соберите весь накопленный вход

Второй шаг: собрать требования из семи источников. Брать стоит всё, даже то, что выглядит давно мёртвым:

1. ТЗ и «вторая очередь» внедрения.

2. Замечания опытной эксплуатации.

3. Заявки Service Desk типа «доработка».

4. Excel-реестры и служебные записки подразделений.

5. Регуляторика, ИБ, аудит.

6. Аудит техдолга от архитектора.

7. Интервью с ключевыми пользователями.

Шаг 3. Удалите дубли и приведите заявки к одному формату

Третий шаг: объединить похожие заявки. Склад и бухгалтерия нередко просят одно и то же, только разными словами. Аналитик переписывает каждую заявку по шаблону «проблема, кто страдает, как часто, ожидаемый результат». Не ложится в шаблон? Возвращают инициатору.

Шаг 4. Разложите элементы на эпики и истории: story mapping

Четвёртый шаг: разложить элементы на эпики и истории по сквозным процессам методом story mapping Джеффа Паттона. Сверху идёт «хребет» пользовательских активностей, под ним истории по убыванию важности, а релизы режут карту горизонтальными полосами.

Первым делают walking skeleton, минимальную сквозную систему (термин Алистера Коберна). Для ERP хребтом служит процесс «заявка → заказ → приёмка → оплата».

Шаг 5. Разметьте тип, источник и зависимости каждого элемента

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

Шаг 6. Приоритизируйте по согласованным правилам

Шестой шаг: упорядочить список в три прохода. Сначала обязательное с датой, потом всё остальное по выбранному методу, в конце проверка квот. Для очереди развития подходит WSJF, для релиза с датой удобнее MoSCoW.

Шаг 7. Подготовьте верх бэклога к разработке

Седьмой шаг: подготовить только верх списка на 1–2 спринта (Detailed appropriately из DEEP). У элементов появляются критерии приёмки, проверка по INVEST и оценка. По Scrum Guide 2020 оценивают те разработчики, которые будут делать работу. Критерии приёмки согласуйте с тестированием.

Definition of Ready (DoR) — это договорённость команды о том, каким условиям должен отвечать элемент бэклога, чтобы его взяли в спринт. В Scrum Guide 2020 и 2017 такого термина нет. Есть лишь фраза о готовности к выбору на Sprint Planning.

Scrum Alliance оценивает DoR двояко. Она помогает заранее видеть зависимости и точнее оценивать, но легко превращается в «ворота» к каскадной работе.

Приоритизация бэклога: какой метод подходит ERP, CRM и СЭД

Приоритизация бэклога корпоративной системы почти никогда не сводится к одному методу. Обязательное идёт вне скоринга, развитие считают по WSJF, релиз с датой режут по MoSCoW. Ниже пять способов приоритизировать бэклог и их пределы.

Метод	Формула / суть	Когда подходит	Ограничения в enterprise	Типичный сценарий
MoSCoW	Must / Should / Could / Won't	Фиксированные срок и объём	Всё «Must» без правила 60%	Релиз к закрытию года
WSJF	Cost of Delay / Job Size	Разная стоимость задержки	Калибровка шкал между подразделениями	Сквозная очередь ERP
RICE	Reach × Impact × Confidence / Effort	Порталы и CRM с внешними пользователями	Во внутренней системе Reach одинаков	Личный кабинет клиента
Кано	Обязательные / одномерные / привлекательные	Исследование удовлетворённости	Нужен опрос, порядка не даёт	Редизайн интерфейса
Value vs Effort	Матрица 2×2	Первичная сортировка	Грубая, без учёта сроков	Шаги 3–5 формирования бэклога

Немного истории. MoSCoW предложил Дай Клегг в 1994 году для RAD (Wikipedia). RICE описал Шон Макбрайд в блоге Intercom (05.01.2018): Impact оценивают как 3 / 2 / 1 / 0,5 / 0,25, Confidence как 100% / 80% / 50%. Модель Кано опубликована в 1984 году, а у Value vs Effort автора нет вовсе. WSJF пришёл из SAFe, которым, если верить пересказу Scrum.org (21.11.2025) 18-го State of Agile, пользуются 44% респондентов.

Как применять WSJF в корпоративной системе с учётом стоимости задержки и регуляторных сроков

WSJF в корпоративной системе считают по SAFe Framework: WSJF = Cost of Delay / Job Size. Стоимость задержки складывается из ценности для бизнеса, срочности (time criticality) и снижения риска.

Cost of Delay (стоимость задержки) — это потери компании за время, пока элемент бэклога не сделан. Концепцию развил Дон Рейнертсен в книге «The Principles of Product Development Flow» (2009).

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

Пример условный, оценки иллюстративные (шкала 1, 2, 3, 5, 8, 13):

Элемент	Ценность	Срочность	Риск	CoD	Размер	WSJF
Отчёт к закрытию месяца	5	8	3	16	2	8,0
Статус ЭДО в поступлении	8	5	3	16	5	3,2
Обмен с банком через API	3	3	8	14	8	1,75

Малая задача с датой обходит крупную и ценную. Так и должно быть. Но по той же логике крупная локализация ПДн уехала бы вниз, поэтому обязательное через скоринг не пропускают.

Когда использовать MoSCoW: фиксированный объём и бюджет

MoSCoW подходит, когда объём и срок зафиксированы договором или датой релиза. В DSDM Project Framework (Agile Business Consortium) Must описан как минимальный набор для жизнеспособного решения, а Could как резерв, который выкидывают первым. Ограничения там жёсткие: на Must не больше 60% трудозатрат, на Could около 20%.

Почему RICE хуже работает во внутренних системах и как комбинировать методы

RICE хуже работает во внутренней ERP, потому что охват ограничен штатом и у половины задач он одинаковый. Для портала и CRM с внешними клиентами метод вполне полезен. Связка, которая на практике даёт приоритизированный бэклог, выглядит так:

1. Обязательное с датой идёт вне скоринга, по сроку нормы.

2. Развитие и техдолг считают по WSJF в пределах квот.

3. Релиз нарезают по MoSCoW.

Кто управляет бэклогом: владелец продукта, продуктовый комитет и квоты подразделений

Бэклог продукта приоритизирует владелец продукта, и Scrum Guide 2020 отвечает на этот вопрос однозначно. Владелец формулирует цель, описывает и упорядочивает элементы, отвечает за прозрачность. Работу он может делегировать. Ответственность нет.

Владелец продукта (Product Owner) — это один человек, который отвечает за ценность продукта и порядок элементов в бэклоге. По Scrum Guide 2020, это «one person, not a committee».

Владельцем продукта ERP становится сотрудник бизнеса, ИТ или внешний специалист, который знает процессы. Найти такого человека сложнее, чем кажется. По PMI Pulse of the Profession (март 2025), высокие бизнес-компетенции есть лишь у 18% проектных специалистов. Внешнего PO вводят в работу так же, как любого члена команды.

Продуктовый комитет — это регулярная встреча владельца продукта с подразделениями-заказчиками и ИТ, где согласуют цели, квоты и спорные приоритеты. Решение о порядке всё равно остаётся за владельцем продукта.

Комитет даёт бизнесу формальное влияние на бэклог команды. Правила у него такие:

• ритм месячный или квартальный, в такт релизам;

• состав: PO, по одному представителю от подразделения, архитектор, ИТ-директор;

• на повестке квоты и спорные элементы, отдельные истории там не разбирают;

• нерешённый спор уходит спонсору.

Если ролей не хватает, часть функций можно отдать внешнему проектному офису.

Квота ёмкости — это закреплённая доля ёмкости команды за период для категории работ или подразделения. Она снимает вечный спор «почему опять задача склада».

Пример условный, доли — иллюстрация, а не норма:

Категория	Доля ёмкости	Кто распоряжается
Обязательные требования	20%	PO по срокам норм
Техдолг	15%	Архитектор, согласует PO
Развитие по подразделениям	55%	PO по WSJF
Резерв на срочные дефекты	10%	Команда

По опросу McKinsey (06.10.2020), на техдолг уходит 10–20% бюджета на новые продукты. Выборка там небольшая, 50 CIO финансовых и техкомпаний с выручкой от $1 млрд, так что обобщать нельзя. В материале McKinsey от 25.04.2023 сказано, что снижать техдолг ниже ~10% обычно невыгодно.

Кто за что отвечает (R делает, A отвечает, C консультирует, I информируется):

Активность	Владелец продукта	Подразделение	Бизнес-аналитик	Команда	ИТ-директор
Сбор заявок	A	R	R	I	I
Описание историй	A	C	R	C	I
Оценка	C	I	C	A/R	I
Приоритизация	A/R	C	C	C	I
Утверждение квот	R	C	I	I	A
Приёмка	A/R	C	R	C	I

Бэклог, ТЗ и договор: как работать при Fixed Price и Time & Material

При Fixed Price ТЗ фиксирует объём, а бэклог упорядочивает работу внутри него. При Time & Material бэклог сам управляет объёмом.

Параметр	Fixed Price	Time & Material	Гибрид (FP + T&M)
Роль ТЗ	Фиксирует объём	Задаёт цель и рамку	ТЗ на этап
Роль бэклога	Порядок внутри объёма	Управление объёмом	Бэклог на развитие
Как меняется объём	Change request, допсоглашение	Переприоритизация	По модели этапа
Риск заказчика	Наценка, споры о ТЗ	Контроль бюджета	Стык этапа и развития
Что помогает	MoSCoW, Must ≤ 60%	Квоты, лимит бюджета	Трассировка ТЗ → эпики

ТЗ внедрения превращают в продуктовый бэклог трассировкой: раздел ТЗ → эпик → истории со ссылкой на пункт ТЗ. Устаревшие пункты закрывают через управление изменениями. Молча удалять их не стоит, потом никто не вспомнит, куда они делись.

Что прописать в договоре, если объём ведётся через бэклог

Договор с объёмом через бэклог фиксирует пять условий:

• кто владелец бэклога у заказчика и какие у него полномочия;

• регламент изменений: кто добавляет элементы и как часто пересматривают порядок;

• ритм и состав продуктового комитета;

• • приёмку инкремента по Definition of Done, «formal description of the state of the Increment» (Scrum Guide 2020);

• отчётность по категориям ёмкости.

Если исполнитель меняется, бэклог становится главным артефактом передачи.

Груминг бэклога: как часто проводить рефайнмент и что удалять

Груминг бэклога по Scrum Guide 2020 идёт непрерывно и без таймбокса: элементы уточняют, разбивают и оценивают по мере необходимости. В самом Guide это называется рефайнментом.

Груминг (рефайнмент) бэклога — это регулярная работа владельца продукта, аналитиков и разработчиков по уточнению, разбиению, оценке и переупорядочиванию элементов.

В Scrum Guide 2013–2017 был ориентир: рефайнмент обычно занимал не больше 10% capacity команды разработки. В 2020 году цифру убрали.

Когда удалять элементы и сколько их должно быть в бэклоге

Нормы на размер бэклога в первоисточниках нет. Обходятся четырьмя правилами:

• элемент без движения дольше согласованного срока уходит в архив, инициатора уведомляют;

• обязательное перепроверяют при каждом изменении нормы;

• архивируют, а не стирают, потому что аудит спросит, почему задачу сняли;

• детально описывают не больше 1–2 спринтов.

Пример бэклога продукта для ERP-системы

Пример бэклога продукта для ERP ниже: фрагмент очереди развития с разными типами элементов и оценкой WSJF по SAFe.

Пример условный, оценки иллюстративные. Шкала 1–13; CoD = ценность + срочность + риск; WSJF = CoD / размер.

ID	Эпик	Элемент	Тип	Подразделение	Дедлайн	CoD	Размер	WSJF	MoSCoW релиза
E-01	Защита ПДн	ПДн сотрудников — в российской БД	Обязательное	HR, ИБ	В силе с 01.07.2025	3+13+8=24	8	вне скоринга	Must
E-02	Защита ПДн	Журнал доступа к карточкам	Обязательное	ИБ	План ИБ	2+8+13=23	5	вне скоринга	Must
E-03	Закрытие периода	Отчёт по непроведённым документам	Развитие	Бухгалтерия	Закрытие года	5+8+3=16	2	8,0	Must
E-04	Продажи	Двойное проведение реализации	Дефект	Продажи	—	5+5+5=15	2	7,5	Must
E-05	Отчётность	Спайк: отчёты на российской BI	Исследование	ИТ	—	2+2+5=9	1	9,0	Should
E-06	ЭДО	Статус ЭДО в карточке поступления	Развитие	Бухгалтерия	—	8+5+3=16	5	3,2	Should
E-07	Склад	Резерв товара под заказ	Развитие	Склад	—	8+3+2=13	5	2,6	Should
E-08	Техдолг	Обмен с банком через API	Техдолг	ИТ, казначейство	—	3+3+8=14	8	1,75	Should
E-09	Закупки	Согласование с телефона	Развитие	Закупки	—	5+2+1=8	3	2,7	Could
E-10	Техдолг	Обновление платформы	Техдолг	ИТ	Конец поддержки	2+5+8=15	13	1,15	Won't (этот релиз)

Как это читать. E-01 и E-02 попали в релиз по сроку нормы, скоринг тут ни при чём. Спайк E-05 стоит высоко из-за малого размера: дешёвое исследование окупается. E-10 отложен, но из квоты техдолга не выпадает. И не забудьте сверить долю Must с правилом DSDM «до 60%».

Где вести бэклог: Jira и российские альтернативы

Бэклог в Jira для российской компании остаётся решением с датой окончания. По данным Atlassian (октябрь 2022), продажи в России прекращены в марте 2022 года, с 31.10.2022 лицензии не продлеваются, а истёкший Data Center работает только на чтение. Поддержка Server закончилась 15.02.2024. Data Center не продают новым клиентам после 30.03.2026, а с 28.03.2029 он станет доступен только для чтения.

При выборе трекера стоит смотреть на пять вещей: on-premise; наличие в реестре российского ПО (для госкомпаний и КИИ); иерархию эпик → история → задача; связь с Service Desk; возможность завести поля под тип, дедлайн и WSJF.

Инструмент	Поставка	Реестр российского ПО
Яндекс Трекер	Яндекс 360; on-premise объявлен 30.10.2025 (Anti-Malware.ru)	Проверить
Kaiten	On-premise	Да, по Tproger; проверить
TeamStorm	On-premise	Да, по Tproger; проверить
YouGile	Коробочная версия	Проверить
SimpleOne SDLC	—	Да, по Tproger; проверить

Данные о Kaiten, TeamStorm, YouGile и SimpleOne взяты из обзора Tproger «Аналоги Jira 2026» (23.04.2026), их стоит сверить на reestr.digital.gov.ru. Excel годится, чтобы собрать заявки, но для постоянной работы не подходит. В нём нет ни истории изменений, ни связей.

8 ошибок, из-за которых бэклог корпоративной системы перестаёт работать

Бэклог корпоративной системы перестаёт работать, когда превращается в архив заявок, а порядок в нём определяет должность заказчика.

Ошибка	Признак	Как исправить
1. Бэклог = все заявки Service Desk	Пароли рядом с эпиками	Развести операционку и развитие
2. Приоритет у громкого	Порядок меняется после звонков	Записанные правила, квоты
3. Комитет вместо PO	Решения большинством	Один владелец продукта
4. Регуляторика и техдолг вне бэклога	«Делаем по ночам»	Свои типы, доля ёмкости
5. Детализирована вся глубина	Истории на год устаревают	Детально только 1–2 спринта
6. Нет правила удаления	Бэклог растёт годами	Срок жизни, архив
7. ТЗ и бэклог отдельно	Не видно, что из ТЗ сделано	Трассировка ТЗ → эпик
8. Приоритеты без данных	Дорабатывают неиспользуемое	Аналитика использования

Последняя ошибка встречается чаще, чем принято признавать. В Pendo «2019 Feature Adoption Report» (05.02.2019) сказано, что в среднем 80% функций используются редко или никогда (данные вендора: 615 подписок клиентов, 3 месяца). А вот популярной цифре Standish «45% функций не используются» доверять не стоит: Майк Кон разобрал её и показал, что она основана на четырёх приложениях. Чтобы данным вообще верили, нужен Data Governance и качество данных.

Частые вопросы

Что такое бэклог продукта простыми словами?

Бэклог продукта простыми словами — это упорядоченный список всего, что нужно для развития продукта: функций, исправлений, техдолга и обязательных доработок. По Scrum Guide (ноябрь 2020), это единственный источник работы команды. Список постоянно меняется, а наверху лежит то, что возьмут в работу следующим.

Чем бэклог продукта отличается от бэклога спринта и бэклога проекта?

Бэклог продукта охватывает весь жизненный цикл продукта, и управляет им владелец продукта. Бэклог спринта состоит из выбранной на спринт части этого списка плюс цели и плана спринта. Бэклог проекта описывает объём работ с датой окончания, например внедрение ERP. После запуска его остатки переходят в продуктовый бэклог.

Кто формирует и приоритизирует бэклог продукта?

Формирует и упорядочивает список работ по продукту владелец продукта. По Scrum Guide 2020, работу он может делегировать аналитикам, а ответственность нет, это «one person, not a committee». Подразделения и аналитики приносят и описывают элементы, разработчики их оценивают, продуктовый комитет согласует квоты.

С чего начать формирование бэклога, если система уже работает и накопились заявки?

Формирование бэклога работающей системы начинают с цели продукта и периметра. Затем собирают весь вход: остатки ТЗ, заявки Service Desk на доработку, реестры подразделений, обязательные требования и техдолг. После этого удаляют дубли, приводят заявки к единому шаблону и раскладывают на эпики и истории по сквозным процессам.

Как приоритизировать бэклог, если у системы десяток внутренних заказчиков?

Приоритизировать бэклог с десятком внутренних заказчиков помогают три правила. Обязательные задачи с датой нормы идут вне очереди. Ёмкость команды делят квотами между обязательным, техдолгом и развитием. Внутри квоты развития порядок задаёт единый метод, например WSJF, а споры решает продуктовый комитет.

Какой метод приоритизации выбрать для корпоративной системы: MoSCoW, RICE, WSJF или Кано?

Метод приоритизации для корпоративной системы выбирают под задачу. WSJF из SAFe подходит очереди развития с разной стоимостью задержки, MoSCoW нужен релизу с фиксированной датой (DSDM: на Must до 60% трудозатрат). RICE (Intercom, 2018) полезен системам с внешними пользователями, модель Кано пригодится для исследования удовлетворённости.