Discovery за четыре недели

У большинства основателей, которые пишут в студию, есть идея продукта — технически состоятельная, но архитектурно неопределённая. Они знают, что продукт должен делать. Они не знают, как его строить, как должен выглядеть AI-слой и где проходит граница между тем, что можно проверить дёшево, и тем, что нельзя.

Discovery отвечает на эти вопросы. Он не производит код. Он производит проверенный технический план.

Ниже — как это устроено: что происходит в каждую из четырёх недель, что получается на выходе и почему структура именно такая.

Почему Discovery, а не прототип

Желание сразу собрать прототип понятно. Работающая вещь убедительнее плана: её проще показать инвестору, проще дать пользователям, приятнее держать в руках.

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

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

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

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

Неделя первая: карта домена

Первая неделя — про предметную область, а не про технологии.

Студия проводит две сессии с основателем и профильными экспертами. Цель — карта домена: формальная модель сущностей, процессов и связей, с которыми будет работать продукт. Не модель данных, а модель предметной области. Какие объекты существуют в этом мире? Через какие состояния они проходят? Кто на них воздействует и зачем?

Сессия намеренно низкотехнологичная: бумага, доска или простой инструмент для схем. Это не сбор требований, а структурированное исследование того, что эксперт знает, — и того, что он считает само собой разумеющимся.

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

К концу первой недели карта домена — общий артефакт: основатель её прочитал, поправил там, где модель студии разошлась с его пониманием, и утвердил. Дальше она источник истины для всего Discovery.

Результат недели: утверждённая карта домена.

Неделя вторая: проектирование AI-слоя

Вторая неделя прикладывает карту домена к вопросу об AI-архитектуре.

Учитывая домен — сущности, процессы, пользователей, данные, — как выглядит AI-слой? Это не вопрос о том, какого поставщика AI выбрать. Это вопрос о том, что AI делает в операционной модели продукта.

Рамка — собственная диагностика студии из пяти вопросов и четыре уровня зрелости, в которые она сортирует; они изложены в Agent-Native, а не «AI-powered». Для каждого значимого процесса из карты домена сессия второй недели спрашивает: какой уровень агентности этому процессу нужен?

Уровень 1 (завершение): AI генерирует результат, человек его проверяет и утверждает до того, как тот вступит в силу
Уровень 2 (оркестрация): AI координирует несколько шагов внутри процесса, человек утверждает на заданных развилках
Уровень 3 (автономность в домене): AI действует от имени пользователя в заданных границах без пошагового утверждения
Уровень 4 (мультиагентная координация): несколько специализированных агентов работают над общими целями, с аудит-логом и разрешением конфликтов

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

Именно эта сессия чаще всего вскрывает допущения, о которых основатель не знал, что они у него есть. «AI обрабатывает заявки» — это второй уровень (AI пишет ответ, человек утверждает) или третий (AI отправляет ответ без просмотра)? От ответа зависит и архитектура, и модель ответственности продукта.

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

Результат недели: проект AI-слоя.

Неделя третья: ограничения и риски

Третья неделя проверяет карту домена и проект AI-слоя на ограничениях — технических, регуляторных, операционных и организационных, — внутри которых проекту предстоит жить.

Технические ограничения: системы, с которыми продукт обязан интегрироваться; форматы данных, которые нельзя изменить; инфраструктурные требования, которые не обсуждаются. Регуляторные: требования к месту хранения данных, отраслевые обязательства, применимые положения AI Act. Операционные: что команда сможет поддерживать, что основатель сможет финансировать, какой срок у первого результата. Организационные: кто принимает решения, кто утверждает изменения объёма, кто доступен студии во время разработки.

Сессия построена так, чтобы вытащить конфликты между архитектурой и ограничениями. Если проект AI-слоя требует данных в реальном времени, а у стороннего API задержка в сутки — это конфликт. Если архитектура предполагает автономного агента третьего уровня в области, где регулятор требует человеческого надзора, — это конфликт.

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

Результат недели: карта ограничений и реестр рисков.

Неделя четвёртая: план

Четвёртая неделя производит то, ради чего всё затевалось: проверенный технический план.

План сводит карту домена, проект AI-слоя, карту ограничений и принятые решения по рискам в связную поэтапную программу работ. В нём:

Запись архитектурных решений. Каждое значимое решение, принятое за время Discovery, с рассмотренными альтернативами и обоснованием выбора. Это человекочитаемая версия файла design.md из OpenSpec — она написана для основателя и будущих технических собеседников, а не только для агентов, которые будут по ней работать.

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

Триплет OpenSpec для первого этапа. Готовые proposal.md, design.md и tasks.md. Если разработка продолжается со студией, этот триплет уходит оркестратору первой задачей. Если основатель забирает план в другое место, триплет работает как технический бриф для первого спринта.

Оценки уверенности. У каждого раздела плана своя: высокая (студия уже строила такое, шаблон понятен), средняя (подход верный, но контекст добавляет переменных), низкая (направление верное, но Discovery вскрыл вопросы, которые потребуют итераций). Разделы с низкой уверенностью — не провал Discovery. Это честное признание, что на часть вопросов отвечает только стройка.

Результат недели: проверенный технический план — архитектурные решения, этапы, триплет OpenSpec для первого этапа и оценки уверенности.

Чем план не является

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

План переживает первое столкновение с реализацией, потому что построен на проверенных допущениях — картировании домена, проекте AI-слоя, картировании ограничений. Он не переживает это столкновение неизменным, потому что неизменным его не переживает ни один план.

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

Что ловит карта домена: пример из реальной работы

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

Каталог VSThermo Moldova представляет линейку термовкладышей для оконных систем — для дистрибьютора. Девять товаров. Очевидная модель товарного каталога: девять страниц и список.

Что в домене есть на самом деле — альбом совместимости на пятьдесят одну оконную систему, связанный с товарами в обе стороны. Систем в пять с половиной раз больше, чем товаров. И направление поиска обратно вендорскому инстинкту: клиент приходит, зная систему, которая у него уже стоит, и ищет, какой профиль к ней подходит. Не «вот наши девять товаров», а «у вас такая система — значит, вам нужен вот этот профиль».

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

Экспертное знание так устроено по умолчанию. Дистрибьютор, который годами отвечает по телефону на вопрос «а к моему подойдёт?», никогда не должен был объяснять программе, что вопрос задаётся именно в эту сторону, — а значит, никогда не делал это явным. Сессия первой недели существует ровно для того, чтобы сделать это явным до того, как архитектура предположит обратное.

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

Подходит ли вам Discovery

Discovery — правильная точка входа для большинства запросов, которые приходят в студию. Если у вас есть продуктовая задача, которой нужен архитектурный AI-слой — не чат-бот сбоку, а обязательство строить AI как операционный слой продукта, — и вы хотите понять, как выглядит правильная стройка, прежде чем в неё вкладываться, Discovery сделан для вас.

Работа начинается после короткого созвона, на котором мы проверяем, что беремся за своё. Созвон бесплатный. Discovery — четыре недели с фиксированным объёмом. Цена фиксируется тогда же, когда фиксируется объём: конкретную цифру мы называем после созвона, а не до него.

На сайте это предложение называется диагностикой роста — та же работа, описанная со стороны заказчика.

FAQ

Сколько стоит Discovery?

Цена фиксируется тогда же, когда фиксируется объём. Конкретную цифру мы называем после короткого созвона, на котором проверяем, что беремся за своё, — а не до него: оценка, выданная до понимания формы задачи, это догадка с десятичной запятой. Там, где объём честно нельзя определить заранее, мы так и говорим и работаем по времени и материалам, вместо того чтобы изображать фиксированную цену.

Что я получаю в конце?

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

Гарантирует ли Discovery продолжение работы со студией?

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

Что нужно от меня, чтобы Discovery состоялся?

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

Почему четыре недели, а не две?

Первые две недели вскрывают допущения, о которых ни студия, ни основатель не знали, что это допущения. Вторые две проверяют их на ограничениях и превращают в план. Двухнедельный Discovery даёт план уверенный, но непроверенный. Четырёхнедельный — уверенный и проверенный. Разница видна в том, как план переживает первое столкновение с реализацией.

Что читать дальше

Agent-Native, а не «AI-powered» — диагностика зрелости, которую Discovery применяет на второй неделе
Метод OpenSpec в продакшене — методология, по которой идёт разработка после Discovery