Бэклог из двадцати задач — это порядок. Сто пятьдесят — это уже хаос, который никто не читает. Product owner клянётся, что «скоро разгребёт», а команда берёт задачи методом тыка. Знакомо?
Я сталкивался с этим на трёх проектах подряд. И каждый раз честный ручной груминг занимал полдня, после которого оставалось ощущение, что половину дублей мы всё равно пропустили.
Почему ручной груминг ломается на объёме
Человек неплохо сравнивает пять задач. На двадцати — уже путается в деталях. На ста — тупо пролистывает, опираясь на заголовки. Мозг не предназначен для монотонного перелопачивания сотен строк с одинаковой структурой. К пятнадцатой минуте внимание рассеивается, на сороковой — хочется закрыть Jira и пойти пить кофе.
LLM в этом смысле тупая, но неутомимая. Она не устаёт, не теряет концентрацию и действительно видит паттерны там, где аналитик начинает замыливаться. Самое интересное — она ловит дубли, которые человек пропускает просто потому, что две задачи создавались с разрывом в месяц и с разными формулировками.
Я не говорю, что LLM заменит продакта. Я говорю, что она возьмёт на себя самую муторную часть: прочитать все сто пятьдесят задач и сказать, что тут вообще происходит. А человек пусть принимает решения.
Что LLM реально умеет в бэклоге
Четыре вещи работают прямо сейчас, без танцев с бубном.
Кластеризация по темам. Сгруппировать 150 задач в 8–10 смысловых кластеров LLM может за минуту. «Вот эти 23 задачи — всё про авторизацию. Вот эти 15 — про отчёты. А вот эти 7 — выглядят как одно и то же, проверь». Сразу видно, куда уходит внимание команды и какие модули продукта перегружены хотелками.
Поиск дублей и пересечений. Задачи «Добавить экспорт в PDF» и «Сделать выгрузку отчёта в файл» с вероятностью 90% — одно и то же. LLM находит такие пары надёжнее, чем поиск по ключевым словам в Jira, потому что смотрит на смысл, а не на совпадение слов. Отдельный кайф — когда модель находит три задачи из разных эпиков, которые на поверку оказываются одной функцией, просто сформулированной разными людьми в разное время.
Приоритизация по ценности. Если дать LLM контекст — описание продукта, цели квартала, обратную связь пользователей — она неплохо ранжирует задачи по влиянию на метрики. Не идеально, но как отправная точка для обсуждения — работает. Дальше человек корректирует: добавляет политический вес, интуицию, знание технического долга.
Выявление зависимостей. «Прежде чем делать ленту рекомендаций, нужен модуль сбора поведения пользователей». Такие цепочки LLM вытаскивает из описаний задач даже тогда, когда связь явно никто не прописал. И это, честно говоря, самая сильная сторона — потому что вручную распутывать зависимости в бэклоге из 150 задач никто не будет.
В сумме это не заменяет продакта. Но превращает четырёхчасовой груминг в часовую сессию, где команда обсуждает уже структурированный материал, а не копается в помойке.
Как это выглядит на практике
Рабочий пайплайн, который я использую на своих проектах:
1. Выгрузка. Экспортирую бэклог из Jira — заголовок, описание, приоритет, лейблы, дата создания. Всё в CSV или прямо текстом в промпт. Linear, YouTrack, Trello — аналогично, принцип один.
2. Первый прогон: кластеризация и дубли. Промпт:
Проанализируй список задач из бэклога продукта. Сгруппируй их по функциональным темам. Для каждой темы укажи количество задач и краткую суть. Отдельно выведи задачи, которые выглядят как дубли или имеют значительные пересечения. Дубли сгруппируй и предложи, какую формулировку оставить.
Результат этого прогона — компактная карта бэклога вместо простыни из 150 строк. Уже на этом этапе обычно всплывает 5–10 дублей, которые годами висели в разных углах.
3. Второй прогон: приоритизация. К результатам кластеризации добавляю контекст:
Учитывая цели квартала (рост конверсии в корзину на 15%, снижение оттока на 5%), проранжируй кластеры задач по влиянию на эти метрики. Внутри каждого кластера отсортируй задачи по ожидаемой ценности. Для каждой задачи из топа укажи, почему она получила такой приоритет.
4. Третий прогон: зависимости. Финальный промпт:
Для топ-30 задач из ранжированного списка найди технические и логические зависимости. Какие задачи должны быть сделаны раньше других? Где есть блокирующие связи? Построй цепочки: что тянет за собой что.
5. Ручная валидация. Результат LLM — это черновик, а не истина. Я просматриваю его, корректирую очевидные глупости, добавляю контекст, который модель не знает: политические решения, обещания конкретным клиентам, интуицию команды. Иногда модель предлагает удалить задачу, которая кажется бессмысленной, а на деле это личная договорённость CEO с ключевым заказчиком.
Весь прогон занимает 15–20 минут. Из них 10 я трачу на формулировку промптов, остальное — на валидацию результата.
Три прохода LLM по бэклогу: кластеризация и поиск дублей → приоритизация по бизнес-ценности → поиск зависимостей. На выходе — структурированный бэклог, готовый к обсуждению с командой. Ручной на всём пути остаётся только финальная валидация — всё остальное модель берёт на себя.
Где LLM ошибается
Тут есть нюанс. LLM не знает контекста, который живёт в головах команды. Она не в курсе, что три месяца назад СТО пообещал инвестору фичу X, а клиент Y угрожает уйти без фичи Z. Политические решения, личные договорённости, интуиция тимлида — всё это вне её поля зрения. И это не баг, а ограничение метода.
LLM склонна переоценивать «простые» задачи и недооценивать те, где много неизвестных. Если задача звучит как «обновить библиотеку аутентификации», модель поставит ей низкий приоритет — хотя на деле там может быть неделя работы и критические последствия для безопасности. Лаконичность формулировки модель принимает за простоту исполнения.
Модель не чувствует технический долг. Задача «переписать модуль расчёта цен» выглядит как неприоритетный рефакторинг, пока человек не объяснит, что текущая реализация даёт ошибку в 3% случаев на больших корзинах. LLM нужно явно подсветить такие моменты в промпте.
По моему опыту: примерно 70% рекомендаций LLM по приоритизации — разумные. Остальные 30% требуют ручной корректировки. Но 70% — это экономия пары часов, которые лучше потратить на разговор с командой.
Когда это не работает
На маленьких бэклогах (меньше 30 задач) LLM не даёт выигрыша. Человек справляется быстрее. Контекст слишком мал, чтобы модель нашла паттерны, невидимые с первого взгляда.
Если описания задач — garbage. «Пофиксить баг», «Доделать фичу», «Срочно!!!» — LLM не телепат. Без вменяемых описаний модель будет гадать, а гадание в продакт-менеджменте — верный способ закопать продукт. Сначала нужно навести порядок в культуре ведения бэклога. Про то, как формулировать задачи так, чтобы их можно было потом приоритизировать, я писал в посте про User Story и Use Case.
На высокоспециализированных доменах LLM может не хватать предметной экспертизы. Если продукт — софт для расчёта нагрузок на крыло самолёта, общая модель вряд ли правильно приоритизирует задачи без серьёзного отраслевого контекста в промпте.
Связка с оценкой трудозатрат
Приоритизация без оценки — это половина дела. Можно расставить задачи по ценности, но если самая ценная фича требует полгода разработки, а три следующих можно сделать за спринт — картина резко меняется.
Я обычно прогоняю приоритизированный бэклог через второй LLM-пайплайн — оценку в стори-поинтах. Детально подход разобран в статье про AI для оценки сложности и трудозатрат. Связка «приоритизация + оценка» даёт полноценную основу для планирования спринта, а не просто аккуратно рассортированный список хотелок.
Резюме в двух словах
LLM не делает из плохого продакта хорошего. Но хорошему продакту она экономит 3–4 часа в неделю на рутине: чтении, сортировке, поиске дублей и зависимостей. Это время лучше потратить на разговоры с пользователями и командой — то, что LLM пока не умеет и вряд ли научится в ближайшее время.
Попробуйте на следующем груминге скормить модели свой бэклог и посмотреть, что она скажет. Если результат окажется бредом — вы узнаете, насколько хаотично ведутся задачи. Если окажется полезным — у вас появился инструмент, который не просит зарплату и не уходит в отпуск.