Школа Скрам-мастеров

Услуги

Контакты

Блог

Главная

Блог

ИИ для проверки пользовательских историй

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

ИИ для проверки пользовательских историй: как не отдать алгоритму продуктовое решение

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

Но стала ли задача действительно качественнее, или она просто приобрела правильную форму?

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

Навигация по статье:

Где ИИ помогает, а где начинает придумывать
Три уровня качества пользовательской истории
Как попросить ИИ сначала провести диагностику
Разбор пользовательской истории на примере
Почему качественные истории не исправят плохой бэклог
Как встроить ИИ в уточнение бэклога

Правильная формулировка ещё не означает правильного решения

Возьмём пользовательскую историю:

"Я как пользователь, хочу быстро оформить заказ, чтобы не тратить время"

Формально всё на месте:
• определён пользователь;
• обозначено действие;
• названа предполагаемая ценность;

Но команда пока не понимает, что именно необходимо реализовать.

Кто этот пользователь: новый покупатель, постоянный клиент или корпоративный заказчик?
Что означает «быстро»: меньше минуты, не более трёх шагов, без регистрации?
На каком этапе сейчас возникает затруднение?
Покидают ли пользователи оформление заказа именно из-за его продолжительности, или команда только предполагает, что процесс слишком длинный?
Какой показатель должен измениться после реализации?

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

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

Что ИИ может проверить, а чего он не знает

Полезно разделить работу с пользовательской историей на три уровня.

Уровень 1. Качество формулировки
На этом уровне проверяем:

понятен ли текст;
нет ли двусмысленных слов;
определён ли пользователь;
обозначена ли его потребность;
можно ли проверить результат;
не объединено ли в одной истории несколько задач;
соответствует ли формулировка критериям INVEST.

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

Уровень 2. Полнота контекста
Дальше появляются вопросы другого порядка:

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

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

Например:

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

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

Уровень 3. Обоснованность продуктового решения
На третьем уровне мы уже не редактируем текст. Мы принимаем решение:

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

🚨ИИ может предложить аргументы и варианты. Но он не видит продуктовую систему целиком и не несёт ответственности за последствия выбора.

Он не знает:

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

🚨Поэтому ИИ может участвовать в анализе, но ценность, приоритет и продуктовое решение остаются ответственностью человека.

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

На тренинге "Управление бэклогом продукта и построение карты пользовательских историй" мы рассматриваем эту систему целиком: от целей продукта и структуры реального бэклога до задач, готовых к разработке.

Лучше просить ИИ диагностировать, а не сразу переписывать

Распространённый запрос к ИИ выглядит примерно так:

"Улучши эту пользовательскую историю и добавь критерии приёмки"

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

Профессиональнее сначала поручить ИИ диагностику.

Проанализируй пользовательскую историю. На первом этапе не переписывай её

Найди неоднозначные формулировки
Покажи, какой информации не хватает
Проверь историю по критериям INVEST
Отдели факты от предположений
Покажи возможные зависимости и ограничения
Сформулируй вопросы для владельца продукта и команды
Только после анализа предложи варианты улучшенной формулировки и критериев приёмки

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

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

Разберём пользовательскую историю на примере

Вернёмся к исходной истории:

"Я как пользователь, хочу быстро оформить заказ, чтобы не тратить время"

После диагностики ИИ может показать:

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

Это полезный результат. Но задача всё ещё не готова к разработке.

Дальше команда обращается к реальным данным и выясняет:

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

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

Теперь можно обсуждать критерии приёмки:

авторизованный пользователь видит сохранённый адрес;
может выбрать другой адрес;
может изменить сохранённые данные;
перед оформлением система предлагает проверить выбранный адрес;
при отсутствии сохранённых данных отображается стандартная форма.

Но даже точная история и согласованные критерии не отвечают на главный продуктовый вопрос:

Даст ли это изменение достаточный эффект по сравнению с другими задачами в бэклоге?

🚨Качество формулировки делает задачу понятнее, но оно не делает её автоматически приоритетной.

Критерии приёмки не должны создавать требования задним числом

ИИ особенно убедительно формулирует критерии приёмки. Поэтому возникает соблазн передать ему короткую историю и получить готовую спецификацию.

Но критерии приёмки фиксируют договорённость о результате. Если договорённость ещё не достигнута, алгоритм фактически начинает создавать её вместо команды.

Он может самостоятельно добавить:

роли пользователей
ограничения
варианты ошибок
правила обработки данных
поведение интерфейса
исключения и пограничные сценарии

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

Следует из предоставленного контекста
То, что можно обоснованно превратить в критерий приёмки

Требует подтверждения
Возможные условия и сценарии, которые команда должна проверить

Остаётся открытым вопросом
Информация, без которой задача не готова к разработке

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

Проверка по INVEST не подтверждает ценность

Модель INVEST помогает оценить, является ли пользовательская история:

независимой;
обсуждаемой;
ценной;
оцениваемой;
достаточно небольшой;
проверяемой.

ИИ способен последовательно проверить каждый критерий. Но особенно осторожно нужно относиться к критерию ценности.

Алгоритм может определить, заявлена ли ценность в тексте.
Например: "Чтобы повысить удобство пользователя"

Формально польза обозначена. Но это ничего не говорит:

о масштабе проблемы;
о количестве затронутых пользователей;
о влиянии на поведение;
о связи с целями продукта;
об ожидаемом эффекте;
о стоимости решения.

🚨ИИ проверяет наличие аргумента. Команда должна проверить его обоснованность.

Даже качественные истории могут образовать плохой бэклог

Можно улучшить каждую пользовательскую историю отдельно и по-прежнему иметь неуправляемый продуктовый бэклог.

Задачи могут быть прекрасно сформулированы, но при этом:

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

ИИ не исправит эту проблему, потому что она находится не внутри отдельной карточки.

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

🚨Здесь заканчивается редактирование текста и начинается управление продуктом.

Пять вопросов, которые нужно задать после ответа ИИ

После автоматической проверки полезно пройтись по пяти вопросам.

1. Что является фактом, а что предположением?
Любая добавленная роль, потребность, зависимость или ограничение должны иметь источник.
2. Какую реальную проблему пользователя мы решаем?
Важно определить не функцию, которую команда хочет реализовать, а затруднение или изменение поведения, стоящее за задачей.
3. На каких данных основано решение?
Источниками могут быть интервью, продуктовая аналитика, обращения в поддержку, наблюдения, эксперименты или стратегические ограничения.
4. Почему задача должна попасть в работу сейчас?
Даже хорошо сформулированная история конкурирует за ресурсы с другими элементами бэклога.
5. Что изменится после реализации?
Команде необходимо заранее определить, как она поймёт, что решила проблему, а не просто выпустила новую функциональность.

🚨Эти вопросы возвращают обсуждение от убедительного текста к обоснованному продуктовому решению.

Как встроить ИИ в уточнение продуктового бэклога

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

Рабочий сценарий:
1. Владелец продукта готовит первоначальную формулировку истории
2. ИИ помогает найти неоднозначности, пробелы и скрытые предположения
3. Владелец продукта уточняет контекст и проверяет источники данных
4. Команда обсуждает проблему, зависимости, ограничения и варианты реализации
5. Критерии приёмки фиксируют достигнутые договорённости
6. После обсуждения ИИ повторно проверяет итоговую версию на согласованность и полноту

В таком процессе алгоритм помогает снизить объём механической работы и лучше подготовиться к разговору.

Но сам разговор остаётся необходимым.

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

ИИ усиливает мышление, но не заменяет управление бэклогом

Профессиональное использование ИИ начинается не с вопроса:
"Как поручить ему написать пользовательскую историю?"

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

ИИ способен:

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

🚨Но он не может подтвердить, что команда:

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

ИИ может улучшить описание решения, но не способен подтвердить, что команда решает правильную проблему

Когда проблема уже не только в формулировках

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

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

На тренинге "Управление бэклогом продукта и построение карты пользовательских историй" участники проходят полный цикл работы с продуктовым бэклогом:

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

Посмотреть программу тренинга

Автор статьи
Анастасия Бутова-Никишина
основатель и генеральный директор компании «Лаборатория ПроЛидеров», автор тренинга "Управление бэклогом продукта и построение карты пользовательских историй"