Для кого эта статья

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

— Все вайбкодят, щас быстренько забацаю тоже!

Недавно ко мне пришёл фаундер с идеей продукта и говорит: “Давай быстро сбацаем мне продукт с помощью вайбкодинга”

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

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

— Зачем вообще разворачивать эту бюрократию?

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

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

— Окей, а как тогда развести бюрократию так, чтобы она работала

Расскажу на примере своего продукта.

О продукте: бот Ченджер — он помогает участникам челленджа не сойти с пути: трекает прогресс, знакомит участников друг с другом, делает саммари и подбадривает. Этот продукт — часть продуктовой экосистемы, его задача: масштабировать челленджи.

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

Метрики:

  • LTV (lifetime value — сколько денег принёс участник за весь жизненный цикл)
  • LT (lifetime — сколько в среднем циклов проходит участник за весь жизненный цикл)
  • Retention — сколько % от первоначальных пользователей (когорта) осталось в продукте в определённый момент. Когорта — это группа пользователей, объединённых по какому-то временному признаку: месяц, конкретная группа.

Продуктовая концепция

Продуктовая концепция — это артефакт проработанной идеи. Она должна ответить на вопросы:

  • цели
  • для кого
  • метрики
  • экономика
  • сколько это будет стоить: денег, человеко-часов

Архитектура

Представьте, что вам нужно построить дом. Для начала нужно понять, какие помещения и комнаты нужны, какие коммуникации. Как минимум, нужны жилые комнаты, санузел и кухня, нужна система отопления и электричество.

Примерно так же с продуктом — нужно понять из чего будет состоять продукт.

Модель сущностей

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

💡 У моего бота Ченджера такие сущности: расписание, когда он просит отчёты, отчёты, штрафы, участники, группа.

Интеграции

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

💡У бота Ченджера это: хранение прогресса участников в базе данных, ИИ-агент-саммаризатор, который проходит по чату и собирает саммари, база данных для хранения статусов и профилей участников.

Пользовательские сценарии

В разработке их называют user story — это атомарная пользовательская история или фича с конкретным результатом: оплатил, начисли штраф, отправил уведомление и т.д. Набор сценариев должен закрывать как пользовательские задачи, так и бизнес-задачи. Например, пользовательские задачи: онбординг, поддержка и основной сценарий продукта (core case). Но есть и бизнес-задачи, под которые нужно предусмотреть сценарии, например: триал и монетизация, программа лояльности, реактивация (напоминания и уведомления).

💡У бота Ченджер это: трекинг прогресса, знакомство участников, саммари челленджа, подбадривание

Для того, чтобы не утонуть во всех этих историях есть такой инструмент, как user story map.

Декомпозиция:

  1. Activities (Активности) — верхний, самый крупный уровень, синие карточки — крупные фазы пути пользователя с продуктом (в нашем случае — Онбординг, Trial, Основной опыт, Монетизация, Поддержка, Реактивация уснувших).
  2. Steps (Шаги) — опциональный ярус. Серые карточки под каждой Activity, более мелкая нарезка внутри неё (например, внутри Онбординга: регистрация → первый запуск → туториал). Используется, когда продукт крупный и одной активности недостаточно, чтобы наглядно разложить всю работу — нужна более глубокая декомпозиция. Для небольшого/личного продукта этот ярус можно пропускать и вешать стори сразу под Activities.
  3. User stories (Юзер-стори) — жёлтые стикеры, вешаются под конкретным шагом (или сразу под активностью, если Steps пропущены). Расположены по важности — важное выше.

Горизонтальные полосы Iteration 1 / Iteration 2 / … — обычно это спринты, релизы. Верхняя полоса (Iteration 1) — минимальная версия, задевающая все активности сразу («ходячий скелет»); последующие полосы — более поздние итерации, добавляющие глубину внутри тех же активностей.

Дизайн продукта

Дизайн продукта — это не просто картинки, это дизайн опыта (user experience). К нему относится:

  • визуал, стили, иконки
  • тексты
  • тон оф войс

💡У моего бота Ченджер визуальной части практически нет, но зато много текстов.

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

Опыт должен быть также предсказуемым, понятным, консистентным. Я использую 10 эвристик юзабилити Якоба Нильсена (Nielsen's 10 Usability Heuristics) — классический чек-лист, разработанный в 1994 году, который до сих пор используется для эвристической оценки интерфейсов.

Вот все десять:

  1. Видимость статуса системы — система должна всегда информировать пользователя о том, что происходит (загрузка, прогресс-бары, уведомления).
  2. Соответствие системы и реального мира — использовать понятные пользователю слова, метафоры и концепции, а не технический жаргон.
  3. Свобода и контроль пользователя — должны быть «аварийные выходы»: отмена действия, undo/redo.
  4. Согласованность и стандарты — одинаковые элементы должны выглядеть и работать одинаково во всём продукте.
  5. Предотвращение ошибок — лучше не допустить ошибку, чем потом показывать сообщение об ошибке.
  6. Узнавание, а не запоминание — минимизировать нагрузку на память пользователя, делать нужные опции видимыми.
  7. Гибкость и эффективность использования — сочетание возможностей для новичков и «ускорителей» для опытных пользователей (горячие клавиши и т.п.).
  8. Эстетичный и минималистичный дизайн — не перегружать интерфейс лишней информацией.
  9. Помощь в распознавании и исправлении ошибок — сообщения об ошибках должны быть понятны и предлагать решение.
  10. Помощь и документация — даже если система интуитивна, иногда нужна доступная справка.

— Супер! Теперь у меня есть доки, кому их нести?

Вайбкодинг — это процесс разработки с помощью агентов. Агент — это ИИ-эксперт в своей доменной области: дизайнер, бэкендер, фронт. Если бы вы делали продукт с реальной командой, то каждый из специалистов попросил бы у вас ТЗ. Вы бы дали ему эти доки и поставили конкретные задачи. Поэтому прежде чем разрабатывать полезно определиться, нужно ли делать разных специализирующихся агентов, или достаточно развести дизайн и разработку. В простых продуктах этого достаточно.

Сделайте описание как на вакансию и попросите ИИ создать вам такого агента: перечислите навыки, воркфлоу, с кем он взаимодействует — от кого принимает задачу, кому сдаёт, какой результат от него ждёте.

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

Доки есть, что дальше?

Ну вот сейчас можно начинать разработку. Просто пишите, что вы хотите разработать продукт и говорите, какие доки вам нужно сделать. Дальше или самостоятельно в чате с агентом готовите доки (он вам поможет), или можете использовать скилл product-dev-brief (см. блок «Инструменты»), который вас опросит и сам создаст все доки и сохранит в папку проекта.

Работу лучше выстраивать по спринтам — для этого мы делали user story map.

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

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