Я тестировщик-автоматизатор: шесть лет в QA, семь лет в преподавании, прикладная математика и информатика ЮУрГУ. За прошедшие полгода я написала фантастический роман на 632 тысячи знаков. Это 46 глав и первая книга из запланированной трилогии. И мой дебют.
Писать большую прозу я до этого не умела. Иногда баловалась короткими рассказами, и они получались нууу… так себе. Но всё поменялось, когда я перестала думать о книге как о «творчестве» и начала относиться к ней как к сложной системе, которую надо спроектировать, собрать, протестировать и выпустить в продакшен. И оказалось, что этот процесс вполне применим и к данному виду деятельности.
Прототип: что вместо пилотной главы?
Конечно же, книга была придумана не на пустом месте. Сначала я писала курс по тестированию на Stepik («Лучший в IT. Старт в тестировании»). В нём я заложила довольно простой сюжет: подросток Алан учится тестировать механизмы и ПО в виртуальной реальности (на космическом корабле), а наставник у него — летающий робот Окулус. Зачем вообще городить такой огород, да? «Простенький сюжет», — говорит она. Но обучение в VR мне было нужно затем, что там можно ошибаться без последствий, и ученикам курса будет проще привыкнуть к мысли, что ошибка — это нормально, часть обучения, не трагедия.
Этот курс и стал первым прототипом будущего продукта. На нём путём проб и ошибок я построила мир, героя и его наставника: как они разговаривают, что их отличает от других, на чём держится сюжет. Где-то на середине курса стало понятно, что история вышла далеко за рамки учебного материала: я знала про Алана гораздо больше, чем нужно для простых сюжетиков с поисками багов. Тогда я решила делать из прототипа большую систему. А точнее: включить туда сюжетную основу — целую книгу.
Требования пишем с конца
С чего начинают писать книгу? Обычно советуют начинать с героя и его окружения. У меня они уже были, но это не давало ответа на главный вопрос: а что мы вообще будем делать, о чём говорить? Поэтому первым делом я ни много ни мало придумала финал всей трилогии. Это были мои приёмочные критерии и ТЗ: всё, что происходит в трёх книгах, должно в итоге привести к этому состоянию. С некоторыми вариациями и доработками, конечно, но главное событие и развязка были зафиксированы чётко.
Ну ладно, допустим, мы определили пусть шаткое, но хоть какое-то ТЗ для всей трилогии. А нам бы как-то с первой части начать, да же? Так у нас уже есть рабочий приём — пользуемся!
Для первой книги я так же зафиксировала только две точки: откуда герой стартует (тайно пробирается на закрытый космодром, чтобы спасти сестру) и чем именно книга заканчивается (собственно, тем, как он найдёт сестру). Между ними — контрольные точки, которые герой обязан пройти, — уроки курса: в каждом Алан осваивает какой-то навык тестирования, и в книге этот навык должен пригодиться в деле. Может, не сразу, но пригодиться должен.
А как же творческий поиск? — спросите Вы. А вот тут он и начинается: как именно герой доберётся от одной контрольной точки до другой, я заранее не знала и не хотела продумывать. И это оказалось самым приятным: задача «написать роман» превратилась в серию маленьких задач «придумай путь для героя из этой точки вот в эту».
Главы — это модули программы
Ну тут понятно: каждая глава — это отдельный модуль или микросервис. На вход подаётся одно состояние героя и обстоятельства, о которых он уже знает, а на выходе — новое состояние (начало и конец зафиксированы, помните, да?). Внутри модуль может быть устроен как угодно. Это похоже, кстати, ещё и на конструирование математической функции или нейросети — кому что ближе.
Тогда задача превращается в простую, даже рутинную: придумать путь и рассказать о нём словами. Как написать программный код, решающий задачу.
И тут уже само собой напрашивается сравнение: модуль тоже не должен быть слишком громоздким и должен решать примерно одну задачу за раз. Так и у меня, например, одна из финальных глав оказалась слишком длинной: в ней были и спокойный день в укрытии, и ночной штурм. Я разделила её на две, и обе части от этого выиграли: у каждой появилось своё логичное завершение, а у второй — ещё и своё название.
Зависимости: чеховские ружья
Если глава — это модуль, то чеховское ружьё — это зависимость между модулями. А также, правда, зависимостями можно назвать и самих героев, и детали развития сюжета. Но с ружьями объяснение просто ярче: деталь объявляется в одной главе, а используется в другой. Если объявил и не использовал — это плохое ружьё, как и неиспользуемый код в продакшене. А если используешь то, что не было заранее объявлено, — то читатель чувствует, что решение взялось из ниоткуда. «Бог из машины» — это называется.
Но и тут принцип проектирования с конца отлично проявляется. Например, в шестой главе Алан ночью пробирается по учебному корпусу и сталкивается с роботом-уборщиком. Когда я писала эту сцену, то сначала придумала пылесос, а потом решила: было бы здорово, если бы он заранее знал про существование таких вот роботов и испытал какие-то эмоции от встречи. Тогда я вернулась в первую главу и дописала, как друзья Алана травят байки, что у охраны космодрома даже пылесосы с лазерным пулемётом. Теперь в шестой главе робот светит Алану в лицо, тот вспоминает байку и готовится к худшему, а робот раздражённо пищит и объезжает его кеды. Ровно как с функцией: можно сначала вызвать её в нужном месте в программе, а потом реализовать её в другом файле, например, utils.
Вот визуализация того, как уже работают связи в моих программных модулях. Это граф: главы расположены по кругу, каждое ружьё — своя цветная нить от главы, где его повесили, до главы, где оно выстрелило.
Получается, что книга — вовсе даже не линейная конструкция. Событие, нить, зацепка, деталь может затаиться на время, даже на двадцать и тридцать глав, а к кульминации «щёлкнуть».
Управление состояниями: таймлайн
Но на словах-то это всё красиво, а на практике… На практике такая модульность хорошо работает только в том случае, если ты помнишь каждое состояние системы. Но на самом деле это сотни деталей, и в какой-то момент ты начинаешь путаться в том, где и какой герой сейчас находится и что делает.
Тут я никакую Америку, конечно же, не открыла, а просто использовала гугл-таблицу. Столбцы — это дни, строки — это герои, в ячейке на пересечении показано, где герой сейчас и что делает. По сути, это снимок состояния системы в каждый момент времени. Например, два инженера космодрома работают во время действия сюжета в авральном режиме два через один. Вместо того, чтобы помнить их расписание, просто открываем таблицу, размечаем и смотрим: ага, сегодня рабочий день, можно прописать им действия, а в выходной не нужно.
Регрессионное тестирование
Ноо случается, конечно, тот момент, когда в книге уже много всего написано, а ты добавляешь новую деталь в нить. Тогда надо обязательно провести регресс — проверить, не поломалось ли что-то ещё из уже написанного. Например, в книге есть линия, где взрослый рассказывает нашему герою, что его родители ему не звонили, и даёт распечатку звонков как доказательство. Эта линия проходит через четыре главы: в начале книги герою велят выбросить сим-карту, в середине показывают распечатку звонков, потом он начинает сомневаться, а в конце выясняется, как всё было на самом деле. Если поменять хоть одну деталь в любой из этих глав, то нужно перепроверить остальные три.
Но есть и примеры «не багов, а фич»: некоторые вопросы в первой книге я оставила без ответа намеренно — как зацепки и крючки на будущие сюжеты второй и третьей книг. То есть это — те же ружья и нити, только между книгами, а не главами. Когда текст читали другие люди, такие места регулярно всплывали как «баги», но приходилось такие репорты отклонять и не фиксить.
Тестирование: бета-читатели и ревью
А когда книга готова и протестирована своими силами, то что с ней должно произойти перед выходом в релиз? Правильно: тестирование на реальных пользователях.
Но первые читатели — бета-ридеры — нашли совсем не то, что я ожидала. Стилистических проблем они почти не заметили, зато много спрашивали, почему персонаж поступил так, а не иначе. Я-то понимаю, почему так, но вот читателям объяснить в этих местах не получилось, пришлось править и переписывать сцены, но когда у тебя в голове и в схемах есть полное понимание сюжета, то это уже совсем не сложно.
Сложнее оказалось править языковые, стилистические проблемы. И тут уже мне своими силами было не справиться, нужно было ревью написанного кода. Когда были готовы примерно две трети романа, я начала отдавать главы языковой модели с задачей найти проблемы, но не исправлять ни в коем случае: мне нужно контролировать каждую деталь самостоятельно.
Модель хорошо умеет замечать недостатки конструкции: однотипные диалоги и клише. А вот если попросить её саму всё переписать, то выходит плохо: она убирает одни штампы и тут же вставляет свои, а заодно выкидывает детали сюжета, которые ей кажутся лишними. Поэтому схема была как с ревью кода: модель оставляет комментарии, но принимаю решение только лично я и исправляю вручную.
Было: Сердце Алана радостно подпрыгнуло в груди, но он лишь понимающе вздохнул, мастерски изобразив лёгкое разочарование.
Стало: Алан едва удержался от улыбки, но тут же понимающе вздохнул, изобразив лёгкое разочарование.
Подпрыгнувшее сердце ничего не говорит о герое: так радуется любой персонаж любой книги. А «едва удержался от улыбки» показывает сразу две вещи — он рад и он это скрывает. В этой сцене взрослый-наставник, от которого Алан скрывает свои планы, сообщает, что уедет на всю ночь.
Таких правок было очень много. Я переписывала книгу раз десять-пятнадцать, и это была самая тяжёлая часть работы. Придумать историю оказалось легко, а довести текст до состояния, за которое не стыдно, — очень сложно и долго.
Релизы
Книга выходит на Author.Today, и выкладывать её надо по главам примерно с равным интервалом в 2–3 дня и так, чтобы каждая порция была не менее 15000 знаков — правило обновления на платформе. А это — уже управление релизами: следить, чтобы выкладка заканчивалась клиффхэнгером, а сильные главы не терялись в общей пачке. Следить за равномерной выкладкой и размером порций. Получилось 23 релиза. Последний — 15 ноября 2026 года.
Вместо вывода
Я не утверждаю, что писать книги легко или что для этого достаточно только инженерного мышления. Без начитанности и без того, что ты хочешь сказать этому миру, никакая супервыверенная архитектура не поможет. Но если вы технарь и давно хотите создать что-то своё, то знайте, что ваш опыт не мешает этому, а, наоборот, помогает. Декомпозиция, интерфейсы, зависимости, состояние, регрессия, ревью — все эти приёмы применимы к построению любой сложной системы.
Интерактивный граф: jababaika-coder.github.io/sha256-viz/konstanta-graph.html
Книга «Архив „Константы“» — на Author.Today, курс «Лучший в IT. Старт в тестировании», с которого всё началось, — на Stepik.
P. S. Спасибо моему мужу Сергею за валидирование реальности и за то, что часами… и годами слушал мои идеи и зарисовки будущих сюжетов, предлагал «вкусные» технические решения, всячески меня поддерживал и порой просто «давал пенделя» двигаться дальше.
Комментарии 0