От проблемы к продукту

Зачем

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

Vision и Mission здесь — не рекламные слоганы, а проверка того, понимает ли команда, зачем продукт нужен. User Stories должны продолжать ту же логику, а не превращаться в список функций.

Стартовый набор

Шаблоны Product Card и Peer Review — ниже на этой странице. Нужен ноутбук: карточка заполняется в текстовом виде, в конце пары понадобится доступ к LLM. Карточки проблем с квеста 1 держите под рукой.

Работаем командами. Если тема проекта уже выбрана — берём её; если нет — берём проблемную область из карточек первого квеста.

Что нужно сделать

1. Заполнить раздел Problem и роли ~5 мин

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

2. Сформулировать Vision и Mission ~15 мин

   Vision — одно предложение о будущем, которое наступит для пользователя при успехе продукта. Mission — одно предложение по шаблону:

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

   В Vision нет технологий, экранов и списка функций; Mission может назвать тип продукта и ключевой принцип, но не превращается в перечень возможностей. Проверочный вопрос: если убрать продукт, какая проблема останется у пользователя? Если ответ не формулируется без слов «нет приложения», «нет сайта», «нет функции» — вернитесь к Problem.

3. Написать пять User Stories и выложить их в карту сценария ~18 мин

   Сначала 2–3 роли, потом истории по шаблону «Как [роль], я хочу [действие или возможность], чтобы [получить ценность]». Ограничения:

   1. представлены минимум две разные роли;
   2. хотя бы одна история описывает основной успешный сценарий;
   3. хотя бы одна — важную ситуацию, которую легко забыть: ошибку, отсутствие данных, изменение решения, ограничение доступа;
   4. история не сводится к кнопке, экрану или другому элементу интерфейса;
   5. нефункциональные требования не маскируются под User Story;
   6. каждая история поддерживает Mission, а её ценность не повторяет действие другими словами.

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

4. Обменяться карточками и написать ревью соседней команде ~15 мин

   Ревьюеры не переписывают работу за авторов, а ставят диагноз по шести вопросам шаблона Peer Review. В ревью должно быть минимум одно конкретное замечание и один «красный флаг». Например: Mission обещает сократить время поиска аудитории, но три из пяти историй посвящены профилю, аватару и рейтингу — основной сценарий продукта потерян.

5. Доработать карточку и сравнить себя с LLM ~15 мин

   Сначала решите, какие замечания принимаете, а какие аргументированно отклоняете, и внесите правки; в разделе «Что мы изменили после ревью» фиксируется влияние обратной связи, а не факт её получения. Потом отдайте LLM разделы Problem, Target users, Vision и Mission и попросите пять новых User Stories:

   Ниже описаны Problem, Target users, Vision и Mission нашего продукта. Предложи пять User Stories для разных ролей. Для каждой укажи пользовательскую ценность и возможное нарушение INVEST. Не меняй исходную проблему и не добавляй новые потребности без явной пометки гипотезы.

   Каждое предложение пометьте: полезное / банальное / не соответствующее Mission / выдумывающее новую потребность. В карточку можно забрать не больше одной предложенной истории и только с объяснением выбора. Утверждения LLM об аналогах, конкурентах и их функциях фактами не считаются без отдельной проверки.

6. Проверить полноту карточки и сдать её ~5 мин

Шаблон продуктовой карточки

Команда — авторы карточки.

Problem — кто сталкивается с проблемой, в какой ситуации и что именно не получается.

Target users — основная роль, вторичные роли.

Vision — одно предложение о желаемом будущем пользователя.

Mission — одно предложение о том, что продукт делает, для кого и ради какой ценности.

User Stories — US-1 … US-5.

Peer review — главное замечание другой команды; какая User Story хуже всего соответствует INVEST и почему.

Что мы изменили после ревью — что приняли, что отклонили и почему; что изменили в карточке.

Сравнение с предложениями LLM — полезное предложение; банальное или лишнее; не соответствующее Mission или выдумывающее новую потребность; что забрали в карточку и почему.

Шаблон ревью

Команды — авторы карточки, команда-ревьюер.

1. Problem — понятно / частично понятно / непонятно. Понятны ли пользователь, ситуация и затруднение? Что в формулировке похоже на готовое решение?

2. Vision — соответствует / требует уточнения / не соответствует. Какое изменение должно произойти для пользователя? Что мешает его увидеть?

3. Mission — соответствует / требует уточнения / не соответствует. Понятны ли продукт, пользователь и ценность? Что выглядит как перечень функций или не связано с Problem?

4. Связность — продолжает ли цепочка Problem → Vision → Mission одну и ту же идею? Где разрыв или противоречие?

5. User Stories — сколько из пяти историй поддерживают Mission; какие выглядят случайными или описывают только интерфейс; покрыты ли основной сценарий, забываемая ситуация и минимум две роли; самая слабая история, нарушенные свойства INVEST (I / N / V / E / S / T) и почему.

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

Что сдаём

• Продуктовая карточка команды — в топик «Практики», одно сообщение от команды.
• Заполненный шаблон ревью — тем, чью карточку смотрели, и туда же в топик.

Зачтено, если

Обязательный критерий. В карточке есть связная цепочка Problem → Vision → Mission. Problem описывает конкретного пользователя, ситуацию и затруднение, а не отсутствие готового решения; Vision описывает желаемое изменение для пользователя; Mission объясняет роль продукта в этом изменении и не противоречит Problem и Vision. Без этого — 0 баллов, как бы ни были хороши отдельные истории.

Балл	Когда ставится
1	Обязательный критерий выполнен; минимум 4 из 5 User Stories содержат конкретную роль, возможность и ценность, поддерживают Mission и в целом соответствуют INVEST; в карточке приведено содержательное замечание ревьюеров и отражено, что команда изменила после ревью или почему аргументированно отклонила замечание.
0.5	Обязательный критерий выполнен, требованиям соответствуют 2–3 истории, но полного уровня нет: например, не описано влияние ревью.
0	Не выполнен обязательный критерий, или требованиям соответствуют меньше двух историй, или работа не дотягивает до условий на 0.5.

При оценке ниже 1 команда получает фидбек.

Типовые грабли

• Vision вида «стать ведущей цифровой платформой» — это слоган, а не изменение в жизни пользователя.
• Mission, превратившаяся в список функций («приложение с картой, фильтрами, push-уведомлениями и рейтингом»), не объясняет ценность.
• «Как пользователь, я хочу нажать кнопку „Показать на карте“, чтобы увидеть карту» — интерфейс вместо сценария, а ценность повторяет действие.
• «Как администратор, я хочу, чтобы система отвечала не дольше 200 мс» — нефункциональное требование под видом истории.
• Пять историй про профиль, аватар и настройки при Mission про экономию времени — основной сценарий потерян.
• INVEST — не проверка каждого слова, а способ найти слишком крупные, неясные, зависимые или бесценностные истории.
• Vision, Mission и User Stories остаются гипотезами: они объясняют замысел, но не доказывают, что потребность существует. Предложения LLM — материал для критики, а не источник истины.