Как я запускаю Expedition Game: от идеи до прототипов за 30 часов

Сначала описал CJM

Первым делом я руками собрал CJM. Использовал подход из Product Architecture Framework Сергея Тихомирова.

Описал:

• персоны;

• их начальное и целевое состояние;

• мотивацию;

• ситуации-триггеры;

• пути перехода из начального состояния в целевое;

• шаги внутри каждого пути;

• проблемы на каждом из шагов.

В итоге получилась большая карта.

Те блоки, которые на ней выделены зелёным, — это предполагаемые ценности продукта. Продублирую их текстом.

1. Справочник маршрутов

Актуальные маршруты со сложностью, этапами прохождения и необходимым снаряжением.

2. Карточка своего похода

Можно сохранить и поделиться своим походом: фотографии, текстовое описание, геоточка, дата и время.

3. Мероприятия и сообщество

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

4. Челленджи с друзьями

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

5. Профиль участника

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

Часть профиля видят все участники мероприятия.

У организатора дополнительно есть информация, которая нужна именно для организации: откуда человек едет, есть ли машина, какое есть снаряжение и чем он готов поделиться.

6. Чаты

Отдельный чат под конкретное мероприятие.

Плюс чаты по видам активности в определённой локации и общие чаты людей из одного города.

7. Онлайн-разметка маршрута

Возможность прямо внутри продукта размечать маршрут.

Всю эту часть я делал руками. Ушло примерно 2 часа.

Касдев на этом этапе не проводил. Я сам являюсь целевой аудиторией продукта и постоянно вращаюсь среди людей из этого сегмента.

Понимаю, что это не заменяет исследование. Но для первого приближения мне этого было достаточно.

Проверяем, что уже есть на рынке

После этого каждую предполагаемую ценность я взял отдельно и попросил GPT найти аналоги в России и в мире.

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

Промт выглядел примерно так:

Отдельным запросом попросил проверить российский рынок и посмотреть, не идут ли в эту сторону крупные компании вроде Яндекса или 2ГИС.

Было два больших исследования.

Каждое заняло примерно 12 минут.

После этого я уже руками пошёл смотреть каждый найденный проект и субъективно оценивать его по Strategy Canvas.

И вот тут стало немного грустно :)

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

Но несколько свободных зон всё-таки осталось.

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

Поэтому решил идти дальше.

Дальше — бизнес-функциональные требования

Следующим этапом начал описывать функциональные требования к продукту.

Эту часть уже делал вместе с GPT.

Передал ему свои наработки и подключил режимы планирования и брейншторма из библиотеки Compound Engineering:

https://github.com/everyinc/compound-engineering-plugin

Промт был примерно такой:

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

Первичная обработка заняла у GPT примерно 20 минут. Но на этом я не остановился.

Следующим сообщением написал:

И дальше начался небольшой допрос.

GPT задал мне 74 вопроса. На каждый уходило в среднем по 2–3 минуты. В итоге только на этот этап ушло примерно 3,5 часа.

Документ получился здоровенный.

А вычитывать огромные текстовые документы — отдельное удовольствие.

Поэтому вместо того, чтобы пытаться держать всё это в голове, я попросил GPT собрать User Flow в Figma.

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

На сбор User Flow ушло ещё примерно 40 минут.

Из функциональных требований — в PRD

После этого я ещё раз прошёлся по схеме.

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

Эту часть тоже делал вместе с GPT.

Запрос выглядел примерно так:

И он задал. Ещё 66 вопросов. На этот блок ушло около 7 часов.

В итоге снова получился достаточно большой документ.

Но к этому моменту я уже привык к одной особенности работы с GPT: текста он может производить очень много.

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

В этот раз следующим шагом я попросил его перейти к прототипу приложения.

Сначала UI Kit

Перед тем как собирать сами экраны, решил сначала сделать UI Kit.

Промт был простой:

На создание UI Kit ушло примерно 70 минут. После этого начали собирать непосредственно прототипы под веб и приложение. И вот здесь был самый большой кусок работы.

На прототипы ушло примерно 15 часов. Почему так много? Было создано более 50 сценариев.

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

Какие скилы я использую

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

CE Plan — использую для планирования работы.

CE Brainstorm — когда нужно обсуждение. Чтобы GPT не сразу бежал выполнять задачу, а задавал вопросы, искал противоречия и помогал посмотреть на задачу с разных сторон.

CE Work — для непосредственного выполнения основной работы.

Это вроде небольшая вещь, но качество результата по сравнению с обычным запросом в духе «сделай мне PRD» отличается очень сильно.

ИИ начинает работать не просто как генератор текста, а внутри заданного процесса.

И ещё один скил, который появился после провала

У меня вместе со скилом Work запускается ещё один скил — «Разработка с контролем результата».

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

Однажды дал Codex задачу на разработку. Он работал примерно 12 часов без остановки, сожрал недельный лимит на GPT-6 Astra, а к нужному результату мы так и не пришли.

В какой-то момент я просто сидел и не понимал: а что вообще пошло не так?

Вместо того чтобы ещё раз запускать работу, предложил Codex провести ретро. Разобрали весь процесс.

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

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

Например, один из критериев внутри него сейчас звучит так:

И вот эта штука очень сильно повлияла на управляемость процесса.

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

Чаще проблема в другом:

как не дать ему бесконечно делать работу ради работы.

Что дальше

Следующий этап — пройти все прототипы в Figma уже руками.

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

Что я вообще хотел показать этой статьёй

• Весь продуктовый цикл от идеи до прототипов занял примерно 30 часов и одного человека. Раньше похожий цикл у меня занимал примерно 352 часа и 3–4 человека. Не утверждаю, что теперь любой продукт можно собрать за 30 часов. Скорее для меня это показатель того, насколько сильно поменялся сам способ работы.

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

• ИИ генерирует огромное количество текста. Поэтому на каждом ключевом этапе я стараюсь переводить результат в схемы. Функциональные требования → User Flow. PRD → прототип.

Так мне намного проще контролировать результат и ловить противоречия.

• Чем больше задач начинает делать ИИ, тем сильнее меняется роль продакта. Сейчас главная работа для меня смещается в две точки: дать правильный контекст на старте и контролировать переходы между этапами. То есть не написать самому 50 страниц требований, а сделать так, чтобы вся система последовательно пришла к нужному результату.

В следующей статье покажу, как построил уже сам процесс разработки Expedition Game и что в итоге получилось.

А в предыдущей статье рассказывал, как у меня сейчас устроено удержание контекста по проектам: https://gotoprod.ru/articles/ai-processes/

Если хотите что-то обсудить или есть вопросы — пишите в личку: https://t.me/forest_hard