Роман как сложная система: применяем стиль разработки ПО к написанию художественного произведения

Я тестировщик‑автоматизатор: шесть лет в QA, семь лет в преподавании, прикладная математика и информатика ЮУрГУ. За прошедшие полгода я написала фантастический роман на 632 тысячи знаков. Это 46 глав и первая книга из запланированной трилогии. И мой дебют.

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

Прототип: что вместо пилотной главы?

Конечно же, книга была придумана не на пустом месте. Сначала я писала курс по тестированию на Stepik («Лучший в IT. Старт в тестировании»). В нём я заложила довольно простой сюжет: подросток Алан учится тестировать механизмы и ПО в виртуальной реальности (на космическом корабле), а наставник у него — летающий робот Окулус. Зачем вообще городить такой огород, да? «Простенький сюжет», — говорит она. Но обучение в VR мне было нужно затем, что там можно ошибаться без последствий, и ученикам курса будет проще привыкнуть к мысли, что ошибка — это нормально, часть обучения, не трагедия.

Этот курс и стал первым прототипом будущего продукта. На нём путём проб и ошибок я построила мир, героя и его наставника: как они разговаривают, что их отличает от других, на чём держится сюжет. Где‑то на середине курса стало понятно, что история вышла далеко за рамки учебного материала: я знала про Алана гораздо больше, чем нужно для простых сюжетиков с поисками багов. Тогда я решила делать из прототипа большую систему. А точнее: включить туда сюжетную основу — целую книгу.

Требования пишем с конца

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

Ну ладно, допустим, мы определили пусть шаткое, но хоть какое‑то ТЗ для всей трилогии. А нам бы как‑то с первой части начать, да же? Так у нас уже есть рабочий приём — пользуемся!

Для первой книги я так же зафиксировала только две точки: откуда герой стартует (тайно пробирается на закрытый космодром, чтобы спасти сестру) и чем именно книга заканчивается (собственно, тем, как он найдёт сестру). Между ними — контрольные точки, которые герой обязан пройти, — уроки курса: в каждом Алан осваивает какой‑то навык тестирования, и в книге этот навык должен пригодиться в деле. Может, не сразу, но пригодиться должен.

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

Главы — это модули программы

Ну тут понятно: каждая глава — это отдельный модуль или микросервис. На вход подаётся одно состояние героя и обстоятельства, о которых он уже знает, а на выходе — новое состояние (начало и конец зафиксированы, помните, да?). Внутри модуль может быть устроен как угодно. Это похоже, кстати, ещё и на конструирование математической функции или нейросети — кому что ближе.

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

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

Зависимости: чеховские ружья

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

Но и тут принцип проектирования с конца отлично проявляется. Например, в шестой главе Алан ночью пробирается по учебному корпусу и сталкивается с роботом‑уборщиком. Когда я писала эту сцену, то сначала придумала пылесос, а потом решила: было бы здорово, если бы он заранее знал про существование таких вот роботов и испытал какие‑то эмоции от встречи. Тогда я вернулась в первую главу и дописала, как друзья Алана травят байки, что у охраны космодрома даже пылесосы с лазерным пулемётом. Теперь в шестой главе робот светит Алану в лицо, тот вспоминает байку и готовится к худшему, а робот раздражённо пищит и объезжает его кеды. Ровно как с функцией: можно сначала вызвать её в нужном месте в программе, а потом реализовать её в другом файле, например, utils.

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

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

Управление состояниями: таймлайн

Но на словах‑то это всё красиво, а на практике… На практике такая модульность хорошо работает только в том случае, если ты помнишь каждое состояние системы. Но на самом деле это сотни деталей, и в какой‑то момент ты начинаешь путаться в том, где и какой герой сейчас находится и что делает.

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

Регрессионное тестирование

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

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

Тестирование: бета‑читатели и ревью

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

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

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

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

Было: Сердце Алана радостно подпрыгнуло в груди, но он лишь понимающе вздохнул, мастерски изобразив лёгкое разочарование.

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

Подпрыгнувшее сердце ничего не говорит о герое: так радуется любой персонаж любой книги. А «едва удержался от улыбки» показывает сразу две вещи — он рад и он это скрывает. В этой сцене взрослый‑наставник, от которого Алан скрывает свои планы, сообщает, что уедет на всю ночь.

Таких правок было очень много. Я переписывала книгу раз десять‑пятнадцать, и это была самая тяжёлая часть работы. Придумать историю оказалось легко, а довести текст до состояния, за которое не стыдно, — очень сложно и долго.

Релизы

Книга выходит на Author.Today, и выкладывать её надо по главам примерно с равным интервалом в 2–3 дня и так, чтобы каждая порция была не менее 15 000 знаков — правило обновления на платформе. А это — уже управление релизами: следить, чтобы выкладка заканчивалась клиффхэнгером, а сильные главы не терялись в общей пачке. Следить за равномерной выкладкой и размером порций. Получилось 23 релиза. Последний — 15 ноября 2026 года.

Вместо вывода

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

Интерактивный граф: jababaika‑coder.github.io/sha256-viz/konstanta‑graph.html

Книга «Архив „Константы“» — на Author.Today, курс «Лучший в IT. Старт в тестировании», с которого всё началось, — на Stepik.

P. S. Спасибо моему мужу Сергею Мидоночеву за валидирование реальности и за то, что часами… и годами слушал мои идеи и зарисовки будущих сюжетов, предлагал «вкусные» технические решения, всячески меня поддерживал и порой просто «давал пенделя» двигаться дальше.