Планирование AI‑спринта без бэклога, заваленного экспериментами

Почему AI‑задачи засоряют обычный бэклог

Обычный продуктовый бэклог предполагает, что команда уже знает, что собирается строить. В AI‑проектах это часто неверно.

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

Эта разница важна. Продуктовые элементы обычно имеют понятную черту «готово». Исследовательские — нет. Если никто не отмечает этот разрыв, бэклог превращается в длинный список задач с очень разным уровнем неопределённости.

Планирование быстро становится хаотичным. Лид просит дату по AI‑фиче, а команда ещё не знает, достаточно ли точна модель, дёшева ли она и стабильно ли работает. Инженеры всё равно дают оценку, потому что спринту нужен номер. Эта оценка редко выдерживает реальное тестирование.

Здесь команды обычно и попадают в проблемы: они обращаются с неизвестностями как с задачами по доставке и обещают результат до того, как появится подтверждение. К середине спринта половина усилий уходит на тесты подсказок, сравнения моделей, крайние случаи и базовую проверку пригодности результата.

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

Команды работают быстрее, когда делают неопределённость видимой заранее. Простое правило помогает: если задача всё ещё требует доказательств, она не должна конкурировать с работой по доставке как будто готова к выпуску.

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

Разделите работу на две дорожки

Смешанный бэклог делает AI‑задачи более предсказуемыми, чем они есть на самом деле. Фича, которая требует текста, UI и API‑изменений, не ведёт себя как эксперимент с тестами подсказок, оценочными метриками и неизвестными режимами отказа. Поставьте их в одну очередь — и команда начнёт воспринимать догадки как обязательства.

Используйте две дорожки.

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

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

У каждой дорожки должен быть свой владелец. Продуктовая работа обычно у product manager и технического лидера. Исследования нужны техническому владельцу, который умеет оценивать результаты, быстро отбрасывать слабые идеи и решать, стоит ли тратить на дальнейшие тесты время.

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

Держите задачу в одной дорожке до тех пор, пока команда не примет это решение. Не разрешайте исследовательской карточке тихо превращаться в обещание доставки. И не оставляйте заблокированную фичу в продуктовой дорожке, если никто не доказал подход.

Эта привычка держит бэклог чистым и спринт честным.

Что относится к продуктовой работе

Продуктовая работа начинается только после того, как команда выбрала метод и задача — строить, тестировать и выпускать. Если люди всё ещё спорят о модели, паттерне подсказок или рабочем процессе — это ещё не продукт.

Эта дорожка должна ощущаться «скучно» в хорошем смысле. Команда знает, что собирается выпустить, для кого и что значит «готово». Риск уже не «сработает ли идея вообще?», а «сможем ли мы качественно доставить и поддерживать её после релиза?».

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

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

Такая структура связывает бэклог с тем, что увидят пользователи. Она также не даёт экспериментальным задачам прятаться внутри delivery‑тикетов, где они бесшумно съедают весь спринт.

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

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

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

Что относится к исследовательской работе

Research‑работа попадает в спринт, когда команде нужно доказательство, прежде чем что‑то строить для пользователей. Если никто не может ответить «будет ли это работать достаточно хорошо?» — такая задача сюда.

Большинство research‑задач начинаются с неопределённости, а не со scope. Возможно, команда хочет понять, сможет ли модель пометить тикеты поддержки с приемлемой точностью, суммировать длинные звонки без потери важных фактов или вытащить чистые данные из грязных счетов. Это — исследовательские вопросы, потому что нужны доказательства.

Держите вопрос узким. Один эксперимент должен ответить на одну вещь.

«Может ли эта модель за две минуты с лёгкой правкой составлять заметки релиза из наших git‑коммитов?» — сильная research‑задача. «Можно ли вообще использовать AI в инженерии?» — слишком широко и приглашает бесконечные тесты без ясного финиша.

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

Эти лимиты делают команду честной. Если эксперимент требует трёх наборов данных, шести веток подсказок и недели тонкой настройки — это, скорее всего, несколько экспериментов, а не один.

Результат research‑работы — не выпущенная фича, а записанное решение. Команда должна зафиксировать, что тестировалось, какую выборку использовали, что произошло и что дальше. Далее может быть «перевести в продуктовую работу», «ещё один тест с чище́й выборкой» или «стоп — не строим».

Это важнее, чем команды ожидают. Люди тестируют что‑то, обсуждают в встрече, а потом через две недели забывают точный исход. Короткая заметка это предотвращает.

Именно поэтому бережливые AI‑команды движутся быстрее: они рассматривают эксперименты как ограниченные задачи обучения, а не как недоделанные deliverables. Исследования должны уменьшать неопределённость. Как только ответ ясен — работа переходит в другое место.

Дайте каждой дорожке свои правила успеха

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

Продуктовая работа

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

Задача считается завершённой, когда достигает согласованного состояния и остаётся рабочей при обычном использовании. Если AI‑фича отвечает медленно, падает на типичных входных данных или создаёт нагрузку на поддержку — работа фактически не завершена.

Простая чек‑листа достаточно:

• фича выпущена или полностью готова к релизу
• проходит проверки приёмки
• остаётся стабильной в нормальном использовании
• команда может поддерживать её без дополнительного хаоса

Это держит продуктовую работу привязанной к реальным результатам.

Research work

Research‑задача выполняет другую роль. Она уменьшает неопределённость, чтобы команда могла принять лучшее решение.

Поэтому research нужно судить по доказательной базе и качеству решения. Тестировала ли команда тот вопрос, который была поставлен? Сравнивали ли варианты честно? Собрали ли достаточно примеров, чтобы заметить закономерности ошибок, проблемы с затратами или пробелы в качестве?

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

Story points плохо подходят для research: они поощряют движение, а не обучение. Лучший финиш прост: команда теперь может выбрать путь с уверенностью. Этот выбор может быть «строить», «изменить дизайн» или «пока отказаться».

Когда обе дорожки используют правильные правила успеха, бэклог успокаивается. Продуктовая работа идёт к релизу. Исследования рассеивают туман.

Как планировать спринт

Большинство команд застревает, когда фичи и AI‑эксперименты борются за одно и то же пространство. Планирование работает лучше в два прохода.

Начните с продуктовой работы. Зафиксируйте обязательства спринта перед пользователями или бизнесом: исправления, небольшие релизы, поддержку и всё, что связано с датой. Если задача должна выйти — ставьте её первой и относитесь как к обычной доставке.

Затем выделите жёсткий лимит для исследований. Держите его небольшим и фиксированным. Многие команды успешно используют 10–20% спринта. Это защищает доставку и оставляет место для обучения.

Простой поток планирования работает так:

1. Выберите продуктовые элементы, которые команда должна закончить в этом спринте.
2. Зарезервируйте небольшой блок времени для исследований и не позволяйте ему расти в середине спринта.
3. Выберите эксперименты, которые ответят на продуктовый вопрос, нужный в ближайшее время.
4. Запишите решение, которое должен поддержать каждый эксперимент.
5. Проводите обзоры выпущенной работы и результатов исследований отдельно.

Третий шаг важнее, чем кажется. Не проводите эксперименты только потому, что они интересны. Выбирайте работу, которая поможет принять ближайшее решение: добавлять ли AI‑суммы на экран, менять подсказку или тестировать retrieval перед строительством фичи.

Каждому эксперименту нужен прикреплённый вопрос: «Стоит ли выпускать AI‑черновики для саппорта?» — хороший пример. «Попробовать несколько моделей» — слишком расплывчато. К концу спринта команда должна знать, продолжать, менять направление или остановиться.

Задайте простое правило успеха до старта. Например: «Если черновики сокращают время написания агентом на 30% без роста количества правок, переводим в продуктовую работу на следующий спринт». Это держит исследования честными.

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

Простой пример для стартапа

Небольшая SaaS‑команда хочет добавить AI‑подсказки для агентов поддержки. На бумаге фича простая: показывать черновик ответа рядом с тикетом, позволять агенту редактировать и отправлять. На практике идея быстро превращается в задачи по интерфейсу, логам, проверкам безопасности, замерам скорости и вопросам стоимости.

Команда с первого дня держит продуктовую и research‑работу отдельно.

Продуктовая работа остаётся близкой к inbox‑у поддержки. Один разработчик добавляет панель подсказок на экран тикета. Другой добавляет аудит‑логи, чтобы менеджеры видели, что предложила модель, что изменил агент и что в итоге отправилось.

Команда также строит fallback‑путь. Если модель медленная, неуверенна или недоступна, агенты могут использовать сохранённые шаблоны и писать ответы вручную. Это в продуктовой дорожке, потому что пользователям нужен fallback независимо от того, какая модель победит.

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

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

Команда не выпускает фичу только потому, что экран готов. Выпуск происходит только после того, как research‑дорожка прошла барьер. Если черновики слишком дорогие или ненадёжные, работа по интерфейсу всё равно пригодится позже, но фича останется под внутренним флагом.

В этом и смысл разделения: продуктовая работа доставляет части, которые команда может поддерживать. Research‑работа зарабатывает право выходить в прод.

Ошибки, которые размывают дорожки

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

Продуктовый тикет должен описывать поведение, которым люди смогут пользоваться. Research‑тикет должен описывать неопределённость, которую команда хочет уменьшить. Когда одна карточка пытается сделать и то, и другое, стендапы превращаются в дебаты, у QA нет чётких чеков, и спринт срывается по причинам, которые никто не может назвать.

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

Ещё одна ошибка — позволить одному эксперименту разрастись на весь спринт. Кто‑то начинает с смены подсказок, потом добавляет retrieval, меняет датасет и просит инженеров интегрировать всё в приложение. К середине спринта один эксперимент съел backend, frontend и QA.

Простое правило помогает: если вопрос меняется, открывайте новую research‑карточку. Если пользовательский scope меняется, переносите работу в будущий продуктовый спринт.

Проваленные тесты тоже часто обрабатывают плохо. Команды воспринимают плохой результат как потраченное время и продолжают подгонять до тех пор, пока не получится что‑то симпатичное. Так слабые идеи живут дольше, чем должны.

Чёткий провал с записанным результатом вроде «точность держалась на 61% после трёх вариантов подсказок на 200 сообщениях поддержки» — всё ещё полезная работа. Она даёт команде доказательство. Команда может остановиться, сузить задачу или попробовать другой метод вместо того, чтобы притворяться, что идея почти готова.

Признаки проблем легко заметить:

• тикеты используют размытые слова вроде «улучшить», «изучить» или «сделать умнее» без метрики
• даты релиза зависят от эксперимента, который не достиг воспроизводимого барьера
• одна research‑задача постоянно тянет в себя больше людей и объёма
• команда подробно записывает успехи, но пропускает провальные прогоны в заметках спринта

Когда команды отделяют продукт и исследования, обзоры становятся яснее, а решения — лучше, потому что доказательства имеют своё место.

Проверки перед стартом спринта

Спринт часто идёт в сторону ещё до первого дня. Проблема обычно простая: никто не договорился, что должно выйти, что требует ответа и что остановится при слабом раннем сигнале.

Короткая проверка перед планированием экономит много уборки позже. Если команда не может разделить работу на эти корзины за пару минут — спринт уже слишком мутный.

Перед закрытием спринта проверьте базовые вещи:

• Покажите элементы, которые точно будут выпущены. Если команда не может их назвать, значит в доставке слишком много discovery.
• Сделайте так, чтобы каждая research‑задача отвечала на один ясный вопрос. «Тест подсказок» — расплывчато. «Можно ли сократить время ответа агентов на 30% с генератором черновиков?» — ясно.
• Установите лимит времени на каждый эксперимент и назначьте одного владельца. Два дня с одним человеком обычно лучше, чем «команда будет исследовать, когда будет время».
• Напишите правило остановки до старта. Если точность ниже минимума, цена за задачу слишком высока или пользователи отвергают вывод — закончить эксперимент.
• Скажите заинтересованным сторонам, какие элементы могут не выйти в этом спринте. Research может дать решение, тупик или маленький следующий шаг. Это тоже прогресс.

Одна стартап‑команда, с которой я работал, имела восемь пунктов в спринте и считала, что шесть из них — продуктовые. После 10‑минутного обзора только три оказались реально готовыми к выпуску. Остальные три были исследовательскими вопросами без владельца, лимита и правила провала. Как только команда перевела их в отдельную дорожку, спринт стало гораздо легче отслеживать.

Если у задачи нет чёткого вопроса, владельца или правила остановки — уберите её из спринта до тех пор, пока это не появится. Звучит строго, но это не даёт AI‑бэклогу превратиться в кучу недоделанных экспериментов.

Начните с простого разделения

Не нужно перестраивать весь процесс планирования. Начните с малого. Оставьте все элементы спринта на одной доске, затем разделите её на две дорожки: product work и research work.

Простой первый шаг достаточен. Поместите shipping‑задачи, исправления и клиентские задачи в продуктовую дорожку. Поместите тесты моделей, пробные подсказки и технические ставки с неизвестным исходом в research. Добавьте короткое правило «готово» для каждой дорожки и держите разделение как минимум два спринта, прежде чем что‑то менять.

Эти правила «готово» важнее самой доски. Продуктовая задача «готова», когда команда может выпустить её, протестировать и поддерживать. Research‑задача «готова», когда команда записывает вопрос, настройку, результат и решение. Если нет записанного решения — эксперимент не завершён.

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

Через два спринта проверьте, что ушло в дрейф. Ищите продуктовые тикеты, в которых прячутся исследовательские неопределённости, research‑тикеты без результата и доставку, заблокированную открытыми экспериментами. Затем ужесточите правила. Возможно, вы решите, что research‑предметы нуждаются в жёстком таймлимите или что каждый эксперимент должен иметь владельца и дату решения.

Если команда продолжает смешивать дорожки, внешняя помощь экономит время. Oleg Sotnikov, at oleg.is, консультирует стартапы и небольшие компании по архитектуре продукта, процессам доставки и практическому внедрению AI. Короткая консультация может помочь навести порядок в планировании, доставке или AI‑поддержке, прежде чем бэклог превратится в набор догадок.