# Первая версия продукта собирается насквозь, а не по слоям

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

URL: https://posts.danashkin.ru/guides/pervaya-versiya-naskvoz-a-ne-po-sloyam
Обновлено: 2026-08-31

---

## Коротко

**Главное**

- Первую версию продукта собирают одним тонким проходом от входа до результата, а не слоями. Слои по отдельности могут быть готовы, а вместе не работать.
- Тонкий проход отвечает на единственный важный вопрос старта: сходится ли конструкция вообще. Дизайн, функции и красота проверяют другое.
- Замысел почти всегда больше первого шага. Отделяй снаряд от надстроек: снаряд - минимальное действие, без которого продукта нет.
- Типовая ошибка масштаба - попытка заменить собой всю свою работу целиком. Такой проект не доводят.
- Пока тонкий проход не работает на твоём компьютере, публиковать нечего: выкладывание сломанного среза не приближает к результату.

## Почему первую версию собирают насквозь?

**Главное**

Потому что стыки ломаются чаще, чем сами части. Форма отдельно работает, хранилище отдельно работает, экран отдельно работает, а вместе данные не доходят. Тонкий проход проверяет именно стыки, и делает это на первой неделе, а не на четвёртой.

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

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

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

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

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

## Метафора, которая объясняет это за минуту

**Главное**

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

Из всех объяснений, которые я слышал на своих занятиях, лучше всего заходит именно это.

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

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

**Почему метафора важнее термина**

У этого приёма есть техническое название, и оно ничего не объясняет непрограммисту. Слово запоминается, механика - нет. Торт же объясняет и механику, и зачем это делать сейчас, а не потом.

Заодно метафора снимает типичное сопротивление: «а можно я сначала сделаю красиво». Можно, но украшать имеет смысл торт, который уже получился.

## Что такое тонкий проход на твоём проекте?

**Главное**

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

Возьмём три типовых замысла и посмотрим, как выглядит в них тонкий проход.

| Замысел | Тонкий проход | Что откладывается |
|---|---|---|
| Конструктор документов на все случаи | один тип документа, три поля, один готовый файл на выходе | остальные типы, шаблоны, роли, история |
| Личные финансы под контроль | запись одного расхода и список за неделю | категории, отчёты, графики, планирование |
| Помощник по встречам | одна расшифровка на входе, одна страница выводов на выходе | база встреч, поиск, напоминания, интеграции |

Заметь закономерность: во всех трёх случаях остаётся именно вертикаль. Не «сделаем ввод данных для всех типов», а «проведём один тип до конца».

Проверка, которую я даю ученикам: опиши свой проход одним предложением по формуле «человек делает X, система отвечает Y». Не помещается в предложение - проход ещё толстый.

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

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

Как сформулировать это агенту, чтобы он не начал строить всё сразу, разбирал в [каноне промпта для агента](/guides/kanon-prompta-dlya-ai-agenta).

## Как отделить снаряд от надстроек?

**Главное**

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

Формулировка про снаряд и надстройки пришла ко мне от ученика, и она точнее любой методички.

Человек описывал систему учёта личных финансов: контроль расходов и доходов, аналитика, планирование, категории. А потом сам разложил: снаряд - это начать вообще записывать расходы. Всё остальное - надстройки.

Разложение делается за десять минут:

1. **Выпиши всё, что хочешь от продукта**

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

2. **Отметь то, без чего продукта нет вообще**

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

3. **Проверь отмеченное вопросом «а если убрать»**

   Убрал и смысл исчез - это снаряд. Убрал и стало менее удобно - надстройка.

4. **Остальное сложи в отдельный файл**

   Не выбрасывай. Список надстроек станет планом второй и третьей недели.

Тут же снимается частый вопрос: делить ли большой замысел на несколько проектов. Не делить. Это один проект и одна папка, просто ты идёшь по нему очередями. Разные папки под одну идею создают ровно ту проблему, ради которой затевались: контекст расползается.

## Что мешает урезать замысел до первого шага?

**Главное**

Чаще всего размер цели. Самая частая формулировка новичка - «хочу заменить себя целиком», и такой проект не доводится до конца, потому что у него нет края.

Замысел «клон меня, который делает всю мою работу» звучит красиво и почти всегда остаётся замыслом. Я вижу его на каждом потоке.

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

Второй симптом того же корня - соскок. Человек доходит до середины, упирается, и вместо того чтобы дожать, берёт новую идею. Свежая идея всегда выглядит проще текущей, потому что её сложностей ты ещё не видел.

**Правило одного проекта**

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

Отдельно про выбор самого замысла: как отобрать первую задачу и не начать с самой сложной, разбирал через [фильтр «бесит, боюсь, спрашивают»](/guides/kakuyu-zadachu-otdat-ii-pervoy).

## Три ловушки, из-за которых проход перестаёт быть тонким

**Главное**

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

**Ловушка первая: сначала красиво.** Просьба «сделай нормальный дизайн» на второй день добавляет к проходу слой, который ничего не проверяет. Оформление имеет смысл, когда механика уже работает.

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

**Ловушка третья: строить поверх пустоты.** Если предыдущая фаза не доделана, а ты уже пишешь код, конструкция стоит ни на чём. Я разбирал случай, где у человека была написана архитектура при полностью пустой папке с описанием идеи: две недели работы ушли на починку следствий, пока причину не увидели глазами. Прежде чем идти дальше, открой папку и убедись, что документы предыдущего шага существуют и не пустые.

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

Про то, что делать после первой рабочей версии - хостинг, данные, доступы, - написал отдельно в материале про то, [что делать, когда прототип готов](/guides/prototip-gotov-chto-dalshe-deploy-152fz).

## Частые вопросы

**Главное**

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

### Частые вопросы

**Сколько времени занимает первый проход?**

На простом замысле - от вечера до нескольких дней. Если он растянулся на две недели, проход выбран слишком толстым: отрежь ещё.

**Обязательно ли первая версия должна быть некрасивой?**

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

**Проект уже собран по слоям. Всё переделывать?**

Нет. Возьми один сценарий и доведи его до конца через готовые слои. Если он проходит - каркас жив, дальше наращивай.

**Когда публиковать первую версию?**

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

## Главный вывод

**Главное**

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

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

Такой подход не делает продукт быстрее сам по себе. Он делает раннюю ошибку дешёвой, а это в [вайбкодинге](/concepts/vibecoding) для непрограммиста важнее скорости: остальные принципы этой работы я собрал в материале про [12 принципов вместо кода](/guides/vibecoding-dlya-predprinimatelya-12-principov).

Опиши свой замысел одним предложением по формуле «человек делает X, система отвечает Y». Помещается?

### Источники

- [Vertical slice - обзорная статья о подходе «тонкий проход через все уровни», Википедия](https://en.wikipedia.org/wiki/Vertical_slice)
- [Минимально жизнеспособный продукт - обзорная статья о минимальной версии продукта, Википедия](https://ru.wikipedia.org/wiki/Минимально_жизнеспособный_продукт)
- [Minimum viable product - англоязычная статья о том же подходе, Википедия](https://en.wikipedia.org/wiki/Minimum_viable_product)
- [Claude Code - типовые рабочие сценарии в официальной документации](https://code.claude.com/docs/en/common-workflows)
- [Pro Git - книга о контроле версий: как фиксировать состояние проекта, русский перевод](https://git-scm.com/book/ru/v2)