Средний бэклог ИТ-проекта разрастается на 15-20% ежемесячно, превращаясь в «кладбище идей», где критические задачи тонут в шуме второстепенных хотелок. Без жесткой приоритизации команда тратит до 30% ресурсов на функционал, который в итоге не приносит прибыли или не используется заказчиком.
MoSCoW: жесткий фильтр для жестких дедлайнов
Метод MoSCoW (Must, Should, Could, Won't) идеален для фиксированных сроков (Fixed-Date), когда нужно отсечь лишнее, чтобы успеть к релизу. В практике внедрения 1С это работает так: Must — это законодательные требования и базовый учет, без которых система не запустится; Should — важные автоматизации, которые можно заменить ручным вводом на 1-2 месяца; Could — «вишенка на торте»; Won't — задачи, которые переносятся в следующий год бюджета.
Кейс: При запуске модуля склада для ритейлера с оборотом 500 млн руб./год, разделение Must/Should позволило сократить срок MVP с 4 до 2.5 месяцев, выделив 40% функционала в категорию Could/Won't. Это спасло проект от кассового разрыва при стоимости разработки 1.2 млн руб./мес.
Экспертный вывод: Используйте MoSCoW только на этапе фиксации MVP. Главная ошибка — раздувание категории Must до 80% бэклога, что делает приоритизацию бессмысленной и ведет к срыву сроков.
RICE: математический подход к Product Management
RICE (Reach, Impact, Confidence, Effort) переводит субъективные «мне кажется» в цифры. Формула (Reach × Impact × Confidence) / Effort позволяет объективно сравнить задачу по оптимизации SQL-запроса (высокий Reach, средний Impact) с разработкой редкого отчета для гендиректора (низкий Reach, высокий Impact). Effort измеряется в человеко-часах или стори-поинтах.
Пример: Задача А (автоматизация выгрузки чеков) имеет Reach 100 чел/мес, Impact 3, Confidence 80%, Effort 40 ч. Задача Б (новый интерфейс личного кабинета) — Reach 10 чел/мес, Impact 5, Confidence 50%, Effort 120 ч. Скор задачи А будет в 5 раз выше, несмотря на визуальную привлекательность задачи Б.
Экспертный вывод: RICE — лучший инструмент для борьбы с «эффектом самого громкого голоса» в компании. Однако помните, что Confidence (уверенность) — самая субъективная метрика; её стоит подтверждать данными из Google Analytics или опросами пользователей.
Матрица Эйзенхауэра: борьба с операционным хаосом
Этот инструмент работает не с бэклогом продукта, а с ежедневным планированием PM-а. Разделение на Срочное/Важное позволяет выявить системные ошибки. Если более 40% задач попадает в квадрат «Срочно и Важно», значит, в проекте отсутствуют 5 техник управления рисками в ИТ-проектах для предотвращения срыва сроков, и вы работаете в режиме тушения пожаров.
Мини-кейс: Перераспределение задач PM-а в команде из 5 разработчиков показало, что 15 часов в неделю уходило на «Срочное, но Неважное» (бесконечные созвоны без повестки). Делегирование этих задач тимлиду освободило 20% времени на стратегическое планирование и контроль KPI.
Экспертный вывод: Матрица Эйзенхауэра — это диагностический инструмент. Если ваш день состоит из квадрата «Срочно/Важно», проблема не в тайм-менеджменте, а в архитектуре процессов управления проектом.
WSJF: приоритизация по стоимости задержки
Weighted Shortest Job First (WSJF) — стандарт SAFe, который считает Cost of Delay (стоимость задержки). Если задержка внедрения функции расчета налогов на месяц стоит компании 200 000 руб. штрафов, а разработка занимает 2 недели, эта задача приоритетнее, чем функция, приносящая 50 000 руб. прибыли при разработке в месяц. Формула: Cost of Delay / Duration.
В крупных ERP-проектах (бюджет от 10 млн руб.) WSJF позволяет обосновать заказчику, почему «красивая кнопка» будет реализована позже, чем скучный перенос остатков. Это снижает количество конфликтов с бизнесом на 30-40% за счет прозрачной финансовой логики.
Экспертный вывод: WSJF незаменим в B2B и Enterprise-сегменте, где цена ошибки или простоя измеряется конкретными убытками в рублях или часах простоя производства.
Метод Кано: баланс между гигиеной и восторгом
Модель Кано разделяет функции на базовые (Must-be), линейные (Performance) и привлекающие (Attractive). Ошибка многих команд — инвестировать 80% ресурсов в «привлекающие» фичи, забывая о базовых. Если в системе 1С работает крутой ИИ-помощник, но при этом периодически «отлетает» проведение документа, пользователь оценит систему на 2 из 10.
Пример: Для интернет-магазина «корзина» — это базовый функционал. Её улучшение с 3 до 2 кликов — линейный рост. А внедрение дополненной реальности для примерки мебели — привлекающий фактор. Без работающей корзины AR-примерка не увеличит конверсию даже на 1%.
Экспертный вывод: Используйте модель Кано для формирования дорожной карты (Roadmap). Сначала закрываем 100% базовых потребностей, затем наращиваем линейные показатели и только в конце добавляем «фишки» для маркетинга.
Вывод
Для старта в небольших проектах (до 3 месяцев) выбирайте MoSCoW — он дает быструю фокусировку. В продуктовой разработке с постоянным потоком гипотез переходите на RICE, чтобы исключить субъективизм. Для крупных корпоративных систем с высокими финансовыми рисками единственно верный выбор — WSJF. Избегайте попыток совместить все 5 методов в одном бэклоге: это создаст избыточную бюрократию, которая замедлит разработку сильнее, чем отсутствие приоритизации. Начните с аудита текущего бэклога: если в нем более 50 задач без четкого приоритета, внедрите RICE уже на следующем спринте.