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

Коротко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такой подход не делает продукт быстрее сам по себе. Он делает раннюю ошибку дешёвой, а это в вайбкодинге для непрограммиста важнее скорости: остальные принципы этой работы я собрал в материале про 12 принципов вместо кода.

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