Определение готовности ИИ‑фич для ревью спринта

Почему ИИ‑истории покидают ревью слишком рано

Работа над ИИ часто выглядит законченной раньше, чем безопасно выпускать её в прод. Демка работает, промпт возвращает аккуратный ответ, и счастливый путь кажется гладким. Потом реальный пользователь задаёт грязный вопрос, модель отказывает не в тот момент, или ответ требуется получать три раза и обходятся дороже, чем предполагали.

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

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

Именно здесь обычно разваливается понятие "готово" для ИИ‑фич. История выходит из ревью без трёх важных проверок: поведения при отказах, потолка расходов и запасного UX. Если этого нет — фича не готова. Она готова к демонстрации, но не к релизу.

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

Что должно значить "готово" для ИИ‑фичи

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

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

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

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

Рабочая демка скрывает эту пропасть чаще, чем команде хочется признать. Демки используют чистые примеры, короткие сессии и человека рядом, который может объяснить странный вывод. Пользователи этого не делают. Они формулируют размытые запросы, кликают быстро, повторяют попытки и предполагают, что продукт знает, что делает.

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

Пропишите правила в истории до ревью

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

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

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

Записывайте краевые случаи в историю с той же тщательностью, что и нормальное использование. Включите пустой ввод, конфликтующие инструкции, отсутствующие данные, повторные повторы, запросы, связанные с политиками, и выводы с низкой уверенностью. Затем добавьте условия остановки. Модель должна прекращать попытки после заданного числа ретраев, использования токенов, вызовов инструментов или секунд ожидания ответа. "Пробовать до тех пор, пока не сработает" — не правило.

Важна и ответственность. Каждое правило должно иметь именованного владельца после релиза. Продукт может отвечать за сообщение, показанное пользователю. Инженерия может владеть лимитами, логированием и поведением фолбэка. Саппорт — за путь передачи человеку. Финансы или продакт‑лид — за оповещения о расходах. Если за правило никто не отвечает, оно обычно исчезает при приходе реального трафика.

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

Сформулируйте поведение отказа преднамеренно

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

Хорошая история называет три состояния: ответить, отказаться или попросить уточнение. Это продуктовые решения. Они не должны жить только внутри промпта, который понимает один инженер.

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

Сам отказ важен. "Я не могу этого сделать" оставляет пользователя в тупике. "Я не могу изменить подписку в чате, но могу показать следующий шаг" даёт путь дальше.

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

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

Если в истории нет прописанных случаев отказа — обычно она ещё не готова.

Установите потолок расходов до релиза

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

Установите лимит на уровне, который реально вызывает пользователь. Это может быть за запрос, за чат‑сессию или за действие вроде «суммаризовать отчёт» или «написать ответ». Выберите единицу, о которой команда может рассуждать, и пропишите потолок простыми словами. «Держать это ниже $0.03 за ответ» гораздо лучше, чем «уменьшить использование токенов.»

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

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

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

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

Спланируйте фолбэк UX до того, как он понадобится пользователям

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

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

Держите сообщение коротким и прямым: "Я не могу выполнить этот запрос. Пожалуйста, выберите один из вариантов ниже." Обычно этого достаточно. Избегайте длинных извинений и расплывчатой воды. Скажите пользователю, что случилось, что он может сделать дальше и займёт ли ответ человека минуты или день.

Большинство фолбэк‑UX должно покрывать три момента: модель отказала по соображениям безопасности или политики, ответ слишком неопределённый для показа, или сервис недоступен либо слишком медленный.

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

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

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

Как ревьюить ИИ‑историю

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

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

Простая схема ревью работает хорошо. Сначала проверьте нормальный путь с реальным запросом и подтвердите, что ответ полезен, ясен и в правильном формате. Затем проверьте поведение при отказе с промптами, которые должны провалиться. Система должна сказать «нет» спокойно, прямо и направить пользователя к безопасному следующему шагу. Потом проверьте лимиты расходов — запустите сценарий, который покажет использование токенов, выбор модели и то, что происходит, когда запрос пересекает потолок. Наконец, форсируйте ошибку, таймаут или результат с низкой уверенностью и убедитесь, что у пользователя всё ещё есть путь вперёд.

Не полагайтесь на чистые тестовые входы. Просмотрите логи, прогоните воспроизведения или staged‑запуски с грязными запросами, отсутствующим контекстом, опечатками, повторными вопросами и расплывчатыми формулировками. Именно там ИИ‑фичи обычно ломаются, а не в отполированном демо.

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

Одобряйте историю только когда весь поток работает «от начала до конца». Сильного ответа недостаточно, если отказ небрежен, фолбэк сбивает с толку или затраты взлетают при увеличении длины запроса.

Пример для команды поддержки

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

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

Непонятные сообщения получают другой ответ. Если тикет говорит «Снова сломалось» или «Почему меня списали?», ассистент не догадывается. Он задаёт один короткий уточняющий вопрос, чтобы агент получил недостающую деталь, прежде чем кто‑то отправит неверный ответ.

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

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

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

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

Ошибки, которые команды повторяют

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

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

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

Фолбэк UX тоже откладывают на конец, и именно оттуда приходят многие тяжёлые запуски. Когда модель отказывает, таймаутится или даёт слабый ответ, пользователям нужен ясный следующий шаг. Слишком многие команды оставляют общий экран с извинением и считают этого достаточно. Это не достаточно. Пользователям нужен retry‑кнопка, простой путь или передача человеку.

Ещё одна повторяющаяся ошибка — одобрять промпты вместо результатов. Промпт может выглядеть хитро в командной встрече и всё равно оставить пользователей в тупике. На ревью задайте простой вопрос: завершил ли пользователь задачу, остался ли уровень затрат в пределах и восстановился ли пользователь, когда модель сказала «нет»? Если ответ неуверенный — история не готова.

Короткий чеклист для одобрения

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

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

• Модель отказывает ясно, когда должна. Пользователь должен видеть простую формулировку, а не расплывчатую ошибку или странный полуответ.
• Задача всё ещё может продвигаться после отказа. Если ИИ говорит "нет", экран должен предложить ручной шаг, упрощённый вариант или способ связаться с человеком.
• В истории указан лимит расходов. Это может быть лимит за запрос, за сессию или за действие, но должен быть конкретный номер.
• Путь фолбэка работает на том же экране. Пользователю не должно быть нужно начинать сначала, открывать другой инструмент или догадываться, что делать дальше.
• Команда тестировала реальные вводы. Используйте грязный текст, неполные данные, краевые случаи и несколько промптов из реальных логов поддержки или интервью с пользователями.

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

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

Что делать дальше с вашей командой

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

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

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

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

Если ваша команда хочет внешнего взгляда, Oleg Sotnikov at oleg.is работает как Fractional CTO и советник для стартапов. Он помогает стартапам и небольшим компаниям превратить расплывчатые стандарты доставки ИИ в практичные правила для продукта, инфраструктуры и инженерных команд.