7.2 instruction — Вайбкодинг-прототипирование¶

Этап RB-STEP-7 — SOLUTION VALIDATION (Stage 6) · Линза: Product · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-7-SOLUTION-VALIDATION/7.2 Прототипирование решения.md.

🎯 Цель в PAF-оптике¶

Создать проверяемые модели продукта для гипотез решения из 7.1 — но не вручную в Figma/Miro, а через вайбкодинг-агента / MVP-builder: Кортекс генерирует кликабельные и no-code прототипы из цифрового профиля продукта (Нексуса) по запросу Product Engineer. Rapid-итерации поднимают Context Ripeness Нексуса продукта.

Семь классических типов прототипов сохраняются как спектр дешевизны/точности, но теперь их генерирует Кортекс, а человек валидирует: - набросок на бумаге (5–30 мин); - wireframe статичный (1–4 ч); - кликабельный прототип (1–3 дня); - консьерж (1–3 дня + ручная работа); - Волшебник Оз (2–5 дней + ручная работа); - no-code прототип (3–7 дней); - Soft Launch (2–6 недель).

Ключевой инсайт методологии PAF сохраняется: ресурсы на создание «быстрых» прототипов коррелируют с точностью соответствия конечному интерфейсу, но не коррелируют с объёмом знаний, получаемых при валидации гипотез. Wireframe может дать те же инсайты, что и кликабельный прототип, — но в 10 раз быстрее. Вайбкодинг обнуляет стоимость «ручного» труда дизайнера/разработчика на ранних типах.

Цель 7.2 — поднять CP гипотез решения после smoke-теста и подготовить почву для Pitching of Trust (7.3). Прототип ловит ошибки на этапе «картона» (минуты), а не готового кода (недели). Тип прототипа выбирается под гипотезу: - бумага/wireframe — навигация/структура; - кликабельный — логика user flow; - лендинг — интерес к ЦП/тест спроса; - консьерж/Волшебник Оз — сложная логика/AI/алгоритм; - no-code — реалистичный тест; - Soft Launch — максимально реалистичный тест.

👤 Роль и ответственность¶

Product Engineer — определяет, какой тип прототипа минимален для ответа на гипотезу; задаёт критерий smoke-теста; veto на workslop-прототип.
Discovery / Launcher PM — вайбкодинг как ключевая компетенция [S2] III.6: продуктовые знания + генерация кода/прототипов через Кортекс; минимизация time-to-прототипа; full-stack человек-команда (весь цикл: исследование → проектирование → производство → запуск → развитие [S1] III.2).
AI UX Designer — проектирует состояния прототипа под ИИ-метафоры из 7.1; для AI-логики (консьерж/Волшебник Оз) определяет tone-of-voice «ИИ-ассистента».
Technical / AI Product Manager — если прототип содержит ИИ-логику: оценивает, что реально автоматизируется, а что имитируется вручную; COGS токенов прототипа; сшивает агентов-имитаторов.
Product Ops — поддерживает MVP-builder и связь прототипа с узлами Нексуса продукта; модель зрелости Кортекса [S1] Часть VII.
Зона человека [S2] III.4: выбор «какой минимальный прототип даст нужный ответ на гипотезу» — стратегическое решение, не агентное; синхронизация команды.

🤖 Что делает Кортекс-агент¶

Вайбкодинг-агент / MVP-builder — из узлов user-flow + ai-metaphor + solution-hypothesis генерирует:
бумажные скетчи (описание/ASCII, один лист = один экран) для проверки навигации и структуры;
wireframe-сеты (только прямоугольники/текст/иконки-заглушки, серый/чёрный, без брендинга) для проверки структуры;
кликабельные прототипы с переходами (On Click → Frame) для проверки логики user flow;
no-code прототипы (Tilda/лендинг, Glide/Bubble, ManyChat/чат-бот, Typeform/квизы) для проверки спроса/логики/мобильной логики;
сценарии для консьержа и Волшебника Оз:
- консьерж — когда клиенты онлайн и плохо разбираются в технике / непредсказуемая логистика / нужна капиталоёмкая автоматизация / высокая чувствительность к удовлетворению каждого клиента;
- Волшебник Оз — когда нужен сложный алгоритм/деликатная отрасль (финансы, здоровье, юриспруденция)/двусторонний рынок, и пользователь думает, что взаимодействует с AI.
Smoke-test-агент — автоматически проходит прототип имитацией незнакомого пользователя; ловит:
тупики (экраны без выхода);
отсутствие CTA, пустые «серые» экраны без контента;
непонятные переходы;
критические переходы: первый экран → что за продукт; ключевое действие → очевидна ли кнопка; момент оплаты → нет ли лишних шагов; финальный экран → понятен ли следующий шаг.
Сценарий-билдер — генерирует задания для юзабилити-теста (7.3) под конкретную гипотезу: формулируются как задачи, а не вопросы («Попробуй записаться к репетитору» вместо «Вам понятно, как записаться?»); минимум 2 задания.
CR-трекер — каждая rapid-итерация прототипа поднимает Context Ripeness узла prototype в Нексусе; обновляет timestamp и статус увядания.
Чужой продукт (API)-агент — если существующий внешний продукт частично реализует нужную функцию, использует его как прототип (быстро и дёшево, но трудно изолировать реакцию именно на свою гипотезу) — восьмой тип прототипа по PAF.

🧠 Что делает человек (метапознание)¶

Валидация ИИ-генерации: человек проходит smoke-тест сам перед показом пользователям — проверяет, что переходы живые, CTA видны, нет тупиков, нет пустых экранов, видео/анимации воспроизводятся.
Выбор типа прототипа: Launcher PM решает, какой тип адекватен гипотезе и ресурсам. Правило: начинать с самого простого типа, который даёт ответ на ключевой вопрос гипотезы; не усложнять без необходимости. Кортекс предлагает, человек утверждает.
Veto на workslop-прототип: если прототип выглядит реалистично, но не проверяет гипотезу (красивый лендинг без реального момента решения; кликабельный прототип без критических переходов) — отбраковка.
Метапознание-фильтр вайбкодинга [S2] III.4: Launcher PM обязан понимать, что сгенерировано, и быть способным это объяснить. Harvard × BCG: «убедительные, но неверные» результаты при отключённой верификации.
Этика Волшебника Оз: обязательно раскрыть пользователям правду после теста — это вопрос этики и доверия.

📦 Артефакт = узлы Нексуса продукта¶

prototype — узел прототипа:
тип (бумага/wireframe/кликабельный/консьерж/Волшебник Оз/no-code/Soft Launch);
гипотеза-источник, инструмент, ссылка;
критерий успеха (метрика+порог);
статус, smoke-результат, CP.
smoke-test-result — вложенный результат: пройден / найденные тупики / недостающие CTA / непонятные переходы.
test-scenario — узел заданий для юзабилити-теста (минимум 2 задания под гипотезу) + гайд модератора.
Обновляются узлы user-flow (связь с конкретным прототипом) и solution-hypothesis (CP после smoke).
prototype-checklist — чеклист готовности прототипа к тесту:
UX: навигация «назад» на каждом экране, понятный CTA, нет тупиков, нет пустых экранов;
сценарии: минимум 2 задания как задачи, гайд модератора;
технические: ссылка открывается с телефона, переходы работают, видео воспроизводится;
участники: отобрано 5–8 из целевого сегмента, запланировано 30–60 мин на сессию, есть запись экрана.
Каждый узел: источник, CP, timestamp, статус увядания. Context Ripeness после 7.2 → ~40% стадии.

🚦 Confidence Point-гейт¶

Gate 7.2 → 7.3 (CP после smoke):
для каждой приоритетной гипотезы есть прототип, покрывающий весь user flow от входа до ценности;
smoke-test пройден (тупики устранены, CTA видны, нет пустых экранов);
test-scenarios готовы (минимум 2 задания);
отобрано 5–8 пользователей целевого сегмента (не сотрудники/родственники, имеют реальный опыт с проблемой).
Кортекс пересчитывает CP по результатам smoke: прототип, прошедший smoke, поднимает CP связанной гипотезы; CP падает при найденных критических тупиках.

🔭 Связь с Тремя Линзами (3PL)¶

Product Lens [S1] VI.1: прототип — свойство продукта, поднимающее CP в Product Sprint; rapid-итерации = насыщение банча (Bunch Saturation).

Принцип Stagility [S1] Принцип 3 (stability + agility): стабильность долгосрочной цели (Видение) + гибкость пути (тип прототипа выбирается под гипотезу в моменте, а не фиксируется заранее).

Связь с Business Lens: no-code/лендинг-прототип (тест спроса, готовность платить) даёт ранний сигнал mNSM-потенциала (кандидат mNSM → NPV в 7.6).

Связь со Strategy Lens: тип прототипа определяет, насколько дёшево мы закрываем Гэп; лимиты Банча — Bunch Size (скорость восприятия рынка) и Bunch Window (период ожидания бизнес-результата) [S1] VI.6.

🛡️ Анти-workslop чекпоинт¶

Workslop в коде/прототипах — топ-зона вайбкодинга (~15,4% [S2] III.7): сгенерированный лендинг выглядит убедительно, но не проверяет гипотезу; кликабельный прототип «красивый», но без критических переходов; no-code без реальной логики.
Метапознание-фильтр: Launcher PM проходит прототип сам + объясняет команде, что он проверяет и почему; способен отредактировать сгенерированное.
Трассировка до Нексуса: каждый prototype связан с узлом solution-hypothesis; прототип без гипотезы-источника → в Банч не попадает, CP = 0.
premature PMF-риск: «пользователям понравился прототип» ≠ рост CP — CP растёт только от поведения (нажали/завершили), а не от слов. Politeness bias («вам понятно?» — всегда «да») нейтрализуется методом Think Aloud и наблюдением за поведением.
Иллюзия живого Нексуса: узлы прототипа обновляются только через агентов, не ручным редактированием; CR имеет фазы созревание/увядание [S1] III.1.
Длительность консьержа/Волшебника Оз: достаточно долго, чтобы набрать репрезентативную выборку (обычно 2–4 недели, 30–50 пользователей); если последние 5 пользователей не принесли новых инсайтов — можно останавливаться.
Bottleneck discovery снят ИИ [S2] III.5 (Голдратт): вайбкодинг снимает bottleneck с разработки/прототипирования → фокус смещается на качество гипотез и валидацию. Парадокс Джевонса: удешевление когнитивного труда через ИИ увеличивает его потребление → больше экспериментов.

🧩 Маппинг к Skill Map / профстандарту 06.012¶

Skill Map [S3] IV:
сектор 2 Value & Solution Design (проектирование решений);
зарождающийся сектор 3 Development & Delivery (вайбкодинг как ранняя доставка).
Профстандарт 06.012 [S4] V: обобщённая функция B «Управление ИТ-продуктом», уровень 5 — B/03.5 «дизайн/выпуск обновлений» (ранняя стадия). PAF: Launcher PM как full-stack продукт+код [S2]. Связка стандарт ↔ PAF интерпретативна [S3]+[S4].

🔗 Связи¶

Назад: 7.1 instruction · Дальше: 7.3 instruction — Pitching of Trust и Stage-Gate по CP Связанные: reformation · index · naming_conventions