Книга как код. История написания бизнес-романа «Цифровое мышление в Бизнесе»

Книга как код. История написания бизнес-романа «Цифровое мышление в бизнесе».

Средний срок написания книги — от года до двух. Год считается хорошим результатом. Я написал бизнес-роман за три месяца, плюс месяц на литературную правку и полтора на печать. В три раза быстрее нормы. В жанре, в котором никогда не работал как автор. И это не история про волшебную кнопку «сгенерировать книгу». Это история про метод.

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

Зачем вообще писать книгу

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

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

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

Первая попытка: агенты-персонажи

Всё началось с простой идеи: а что, если воспринимать книгу как код?

Я наткнулся на научную статью MoPS: Modular Story Premise Synthesis — исследователи предложили разбивать замысел истории на модули: окружение, персонажей, события — и из комбинации этих модулей автоматически синтезировать сюжетные посылки. Идея была в том, что если поместить героев в среду и задать ситуацию — получится рассказ.

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

Я совместил обе идеи и попытался написать программу. Два героя — антагонист и протагонист — помещаются в проблемную ситуацию. У каждого свой взгляд на мир, своя память. Они общаются, а третий «агент-наблюдатель» записывает происходящее от третьего лица.

Идея была красивой. Результат — нет. Отладка приложения для генерации сюжетных линий съедала 90% времени. На творчество оставалось меньше десяти процентов. Текст получался «иишный» — без глубины, без жизни. Я остановился.

Причина провала была в том, что я пытался автоматизировать процесс, не восстановив метод. Я не ответил на вопрос «как мыслит писатель» — и сразу перешёл к коду. Машина исправно генерировала текст, но в нём не было того, что делает книгу книгой: авторского решения о смысле.

ПОПЫТКА №1: автоматизация без метода

┌────────────┐     ┌─────────────────┐     ┌────────────┐
│            │     │                 │     │            │
│   Идея     │────►│   Код (агенты)  │────►│   Текст    │
│            │     │                 │     │  «иишный»  │
└────────────┘     └─────────────────┘     └────────────┘
                          │
                    90% времени на
                    отладку кода
                          │
                    10% на творчество
                          │
                     РЕЗУЛЬТАТ: ✗

Но эта неудача оставила после себя кое-что ценное — артефакты. И главное — понимание: сначала восстанови метод, потом автоматизируй.

Книга как код: объектный подход

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

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

Мне не хватало гибкости этих платформ: все они работали на английском, данные хранились на чужих серверах. Я перенёс процесс в Cursor и воссоздал ту же логику, наложив методики зарубежных сервисов на собственные структурированные артефакты.

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

ОБЪЕКТНАЯ МОДЕЛЬ КНИГИ

┌─────────────────────────────────────────────────────────────┐
│                        СИНОПСИС                             │
│              (замысел на 2 страницах)                       │
└──────────────────────┬──────────────────────────────────────┘
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
  ┌───────────┐  ┌───────────┐  ┌───────────┐
  │  БЛОК 1   │  │  БЛОК 2   │  │  БЛОК 3   │
  │  начало   │  │кульминация│  │ развязка  │
  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘
        │              │              │
   ┌────┼────┐    ┌────┼────┐    ┌────┼────┐
   ▼    ▼    ▼    ▼    ▼    ▼    ▼    ▼    ▼
  гл.  гл.  гл. гл.  гл.  гл. гл.  гл.  гл.
   1    2    3    4    5    6    7    8    9

  Каждая глава = 3 раздела
  Каждый раздел = событие + люди + задача + тезис

╔═══════════════════════════════════════════════════╗
║  ОБЪЕКТЫ, привязанные к каждой главе:             ║
║                                                   ║
║  ┌──────────┐  ┌──────────┐  ┌──────────┐         ║
║  │ ПЕРСОНАЖ │  │ СОБЫТИЕ  │  │  ТЕЗИС   │         ║
║  │          │  │          │  │          │         ║
║  │ характер │  │ проблема │  │  мысль,  │         ║
║  │ взгляды  │  │ конфликт │  │ которую  │         ║
║  │ арка     │  │ решение  │  │  нужно   │         ║
║  │ изменений│  │          │  │ раскрыть │         ║
║  └──────────┘  └──────────┘  └──────────┘         ║
╚═══════════════════════════════════════════════════╝

• Тезисы — ключевые мысли, которые автор хочет донести до читателя.

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

• Арки изменений — как трансформируется герой от главы к главе, что происходит в его голове, как меняется его мироощущение при столкновении с антагонистом.

• События — проблемные ситуации, привязанные к конкретным тезисам.

Вся задумка книги компактно умещалась на двух страницах синопсиса. Нужно было эти мысли раскрыть.

Вот что важно: эта объектная модель — не изобретение, а реконструкция. Я восстановил то, что хороший писатель держит в голове интуитивно. Сделал невидимое — видимым. А когда метод стал видимым — дальше уже инженерная работа: разложить по структурам, связать объекты, подключить инструменты.

Процесс: от скелета к тексту

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

ПОПЫТКА №2: сначала метод, потом автоматизация

┌────────────┐     ┌─────────────────┐      ┌────────────┐
│            │     │  Восстановление │      │            │
│   Идея     │────►│     метода      │─────►│  Объектная │
│            │     │  (как мыслит    │      │   модель   │
└────────────┘     │   писатель?)    │      │   книги    │
                   └─────────────────┘      └──────┬─────┘
                                                   │
                    ┌─────────────────────────────┐│
                    │ Инженерный процесс:          ││
                    │                              ▼│
                    │  ┌────────┐  ┌────────┐  ┌────────┐
                    │  │наполне-│  │ правка │  │ финаль-│
                    │  │  ние   │◄►│  арок  │◄►│  ный   │
                    │  │смыслом │  │        │  │  текст │
                    │  └────────┘  └────────┘  └────────┘
                    │      ▲                       │
                    │      └── пинг-понг ──────────┘
                    │                              │
                    └─────────────────────РЕЗУЛЬТАТ: ✓

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

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

В какой-то момент JSON-описания мне стали не нужны. Машине без разницы — JSON или текст. Достаточно было текстового описания в Markdown. Я не заметил проседания в качестве, когда основные элементы перешли в абзацовый вид.

ИИ как ассистент писателя

ИИ в этом процессе не был автором. Он был ассистентом — по сути, я воспроизвёл в цифре работу зажиточного писателя XIX–XX века. Тот ходил из угла в угол и диктовал книгу своей любовнице или жене. Она поправляла, меняла, дорабатывала то, что не важно для сути, но важно для стиля. Причём «диктовал» — в прямом смысле: я активно использовал голосовой ввод.

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

Модели я использовал разные — для разных задач. В основном Sonnet и Gemini, потому что книга занимала 300–400 тысяч токенов. Но модель вторична. Самым важным был объектный подход к написанию и та методология, которая из него выросла.

Змейка артефактов: метод книги внутри самой книги

Забавно, но процесс написания оказался живой иллюстрацией к тому, о чём книга рассказывает. В «Цифровом мышлении» есть ключевая идея — змейка артефактов: видимый артефакт порождает скрытый, скрытый — следующий видимый, и так далее. Между видимыми артефактами нет прямых связей — только через скрытые.

ЗМЕЙКА АРТЕФАКТОВ: как писалась книга

СКРЫТЫЕ          ┌───────────┐        ┌────────────┐
(в голове)       │осмысление │        │творческое  │
                 │структури- ├───┐    │ решение:   ├──┐
                 │  рование  │   │    │как раскрыть│  │
                 └─────▲─────┘   │    └─────▲──────┘  │
                       │         │          │         │
───────────────────────│─────────│──────────│─────────│──────
                       │         │          │         │
                       │         ▼          │         ▼
ВИДИМЫЕ          ┌─────┴────┐ ┌──────────┐  │   ┌──────────┐
(артефакты)      │стенограм-│ │ синопсис ├──┘   │  текст   │
                 │мы, записи│ │  главы   │      │  главы   │
                 └──────────┘ └──────────┘      └──────────┘

   Между видимыми артефактами НЕТ прямой связи.
   Стенограмма ≠ книга. Между ними — скрытая работа мышления.

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

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

Четыре типа работы — и все четыре в одной книге

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

3 ТИПА КОГНИТИВНОЙ РАБОТЫ В ПРОЦЕССЕ НАПИСАНИЯ КНИГИ

┌──────────────────────┬──────────────────────┬──────────────────┐
│     ТИП РАБОТЫ       │   ГДЕ ПРОЯВИЛСЯ      │   ИНСТРУМЕНТ     │
├──────────────────────┼──────────────────────┼──────────────────┤
│                      │                      │                  │
│ 1. Работа по правилам│ Структура: 3 блока,  │ Каркас задаёт    │
│    если X → то Y     │ 3 главы, 3 раздела   │ рамки            │
│                      │                      │                  │
├──────────────────────┼──────────────────────┼──────────────────┤
│                      │                      │                  │
│ 3. Трансформация     │ Стенограммы, записи  │ ИИ: переформули- │
│    информации        │ выступлений → связный│ рование, смена   │
│                      │ художественный текст │ стиля            │
│                      │                      │                  │
├──────────────────────┼──────────────────────┼──────────────────┤
│                      │                      │                  │
│ 4. Проектирование    │ Создание самого      │ Человек.         │
│    деятельности      │ метода написания.    │ Восстановление   │
│                      │ Работа в             │ метода — это     │
│                      │ неопределённости     │ и есть тип 4     │
│                      │                      │                  │
└──────────────────────┴──────────────────────┴──────────────────┘

Типы 1, 3: можно автоматизировать ПОСЛЕ восстановления метода
Тип 4:     на момент написания — за человеком

Восстановление метода — это и есть работа четвёртого типа. Проектирование деятельности в неопределённости, когда ты не знаешь, как правильно, и выстраиваешь процесс по ходу. На момент написания книги (осень 2025) этот тип оставался целиком за человеком. Но как только метод восстановлен — типы 1 и 3 становятся инженерной задачей. Их можно ускорять, автоматизировать, масштабировать.

Важная оговорка: с начала 2026 года агентские системы начали менять эту картину. Агенты уже способны участвовать в проектировании — не заменяя человека, но работая рядом с ним: предлагая варианты, проверяя гипотезы, удерживая контекст. Граница четвёртого типа сдвигается. В книге я как раз захожу на эту территорию — и то, что казалось исключительно человеческим, постепенно становится совместным.

Голдратт: не только жанр, но и метод

Элияху Голдратт для меня — родоначальник жанра бизнес-романа. Его книги заставляют думать, и именно этот стиль я взял за основу. Но влияние Голдратта оказалось глубже, чем просто выбор жанра.

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

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

Что из этого следует

Весь путь от идеи до книги можно уложить в одну схему:

ОТ ИДЕИ ДО КНИГИ: две фазы

═══════════════════════════════════════════════════════════════
  ФАЗА 1: ВОССТАНОВЛЕНИЕ МЕТОДА           ◄── делает человек
═══════════════════════════════════════════════════════════════

  «Как на самом деле мыслит писатель?»

  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
  │          │    │          │    │          │    │          │
  │ Наблюдай │───►│ Выявляй  │───►│ Разложи  │───►│ Проверь  │
  │ за собой │    │ скрытые  │    │на объекты│    │ на       │
  │          │    │ решения  │    │          │    │ практике │
  └──────────┘    └──────────┘    └──────────┘    └──────────┘

  Результат: объектная модель (персонажи, арки, тезисы, события)

═══════════════════════════════════════════════════════════════
  ФАЗА 2: ИНЖЕНЕРНЫЙ ПРОЦЕСС              ◄── человек + ИИ
═══════════════════════════════════════════════════════════════

  «Метод восстановлен — теперь ускоряем»

  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
  │          │    │          │    │          │    │          │
  │ Структура│───►│Наполнение│◄──►│  Правка  │───►│ Рецензи- │
  │ и каркас │    │ смыслом  │    │  и арки  │    │ рование  │
  │          │    │          │    │          │    │          │
  └──────────┘    └──────────┘    └──────────┘    └──────────┘
    правила      трансформация   трансформация   агенты-
                                                 рецензенты

═══════════════════════════════════════════════════════════════

Ключевые принципы, которые я вынес:

1. Восстанови метод, прежде чем автоматизировать. Это главное. Если ты не понимаешь, что на самом деле делает человек, занимающийся умственным трудом, — автоматизация даст мусор. Как только метод восстановлен — дальше инженерный процесс.

2. Разложи на объекты. Персонажи, события, тезисы, арки — всё это отдельные сущности. Как классы в коде. Комбинируя их, ты получаешь сложную систему, которую при этом можешь контролировать.

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

4. Работай со структурой сверху. Сначала идея, потом блоки, потом главы, потом события. Держи синопсис как точку опоры и возвращайся к нему при каждом изменении.

5. Пиши параллельно. Полная структура позволяет работать над всей книгой одновременно, видеть связи и удерживать целостность. Это убирает асимметрию времени.

6. Найди своё узкое место. Если 90% времени уходит на инструмент, а не на содержание — ты автоматизируешь не то. Узким местом должна быть экспертиза, а не инфраструктура.

7. ИИ — ассистент, не автор. Машина решает проблему пустого листа, помогает переформулировать, проверяет текст из разных позиций. Но замысел, метод и глубина — это работа человека. Фаза 1 — всегда за тобой.

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

Книга «Цифровое мышление в бизнесе. Как строить процессы, чтобы ИИ стал стратегическим преимуществом» — ссылки где можно купить.

К книге прилагаются готовые скилы (навыки) для ИИ-агентов — анализ процессов, поиск узких мест, визуализация артефактов. Их можно подключить к своему рабочему окружению и сразу начать применять методологию на практике. Ссылка та же (см. выше)