Выпуск #27. Беседа с Антоном Гафаровым

Опубликовано 19.08.2026

Краткая выжимка выпуска (TL;DR): В этом выпуске мы разбираем, как инженерные практики меняют работу технических писателей. Главные темы: внедрение методологии Docs-as-Code (Git, Markdown, CI/CD), концепция “Документация как услуга” (Docs-as-a-Service) и практическое применение ИИ-моделей (Qwen, DeepSeek) для вайб-кодинга и поддержки корпоративных док-порталов. Гость выпуска — Антон Гафаров, технический писатель в компании RWB (Wildberries & Russ) и автор канала Parawriter.

Главные инсайты выпуска (Q&A):

• Что такое Docs-as-Code в 2026 году? Это фреймворк, переносящий инструменты разработки кода (Git, легковесную разметку Markdown, статические генераторы сайтов) на процессы создания и управления документацией как продуктом.
• В чем суть Docs-as-a-Service? Технический писатель выступает в роли менеджера знаний и владельца док-портала (Product Owner), предоставляя инженерам и аналитикам услуги по глубокому ревью, верстке и публикации технического контента «под ключ».
• Как техписатели используют ИИ? Инструменты генеративного ИИ применяются для вайб-кодинга (доработки фронтенда док-порталов на HTML/JS без глубокого знания кода) и в качестве “третейского судьи” для рефакторинга сложного косноязычного текста.

---

Обожаю темы, которые находятся на пересечении инженерии и техписательства. В последнее время мы наблюдаем тенденцию, как программная инженерия со своим подходом к разработке “поглощает” смежные сферы ИТ.

На жизнь техписателей инженеры также оказали свое влияние и вылилось это в парадигму работы с документацией, известную как docs-as-code. Техписатели всё больше становятся похожими на инженеров. Кстати, как говорила наша Арина Балерина: “Все мы сначала вышли из инженеров, теперь в инженеров снова и превращаемся”.

После апрельского онлайн-митапа я получил огромное количество запросов на глубокий разбор docs-as-code. И сегодня у нас именно такой выпуск. Сегодня Антон поделится личной историей пути в профессию, подробно раскроет работу с документацией как кодом и расскажет про опыт использования искусственного интеллекта. Уверен, информация будет максимально полезной.

Полезные ссылки

Канал Антона Гафарова (Parawriter)

TechDocs митап от RWB (YouTube)

TechDocs митап от RWB (VK)

Слушайте подкаст на любимых платформах

Поделитесь подкастом с друзьями и коллегами

---

Расшифровка выпуска

Владимир Юсупов: Добро пожаловать в очередной выпуск подкаста технического коммуникатора Техкомпод! С вами Владимир Юсупов.

Обожаю темы, которые находятся на пересечении инженерии и техписательства. В последнее время все мы наблюдаем тенденцию, как инженерия, точнее программная программная, со своим подходом к разработке, функционированию и сопровождению программного обеспечения “поглощает” многие “смежные” сферы ИТ-индустрии.

На жизнь техписателей инженеры также оказали свое влияние и вылилось это влияние в парадигму работы с документацией, известную как docs-as-code. Техписатели все больше становятся похожими на инженеров. Кстати, как в одной из бесед говорила наша Арина Балерина: “Все мы сначала вышли из инженеров, теперь в инженеров снова и превращаемся”. В качестве некоего подтверждения этой мысли (для самого себя) могу отметить тот факт, что после нашего апрельского онлайн митапа я получил огромное количество запросов на проведение отдельных мероприятий на тему docs-as-code и выпусков подкаста с экспертами по данной теме.

И сегодня как раз именно такой выпуск. Гостем нашей скромной студии является Антон Гафаров, техписатель в компании RWB и автор телеграм-канала Parawriter.

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

Я получил огромное удовольствие от беседы с Антоном. Уверен, что вам тоже она понравится, а услышанная информация будет полезной.

Итак, запись беседы с Антоном Гафаровым.

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

Приятного прослушивания!

Антон, привет! Добро пожаловать в подкаст технического коммуникатора Техкомпод!

Антон Гафаров: Привет, привет!

Владимир Юсупов: Антон, прежде чем мы перейдем к сегодняшним основным темам, давай начнем с моей любимой рубрики. Кстати, надо дать ей название. Например, «Удивительная история гостя». Тебя очень хорошо знают в сообществе технических писателей. Но помимо техписателей среди слушателей подкаста, второй сегмент аудитории по численности, инженеры (в основном, дата-инженеры). Уверен, что им будет тоже крайне интересно узнать тебя поближе. Расскажи, пожалуйста, немного о себе и своем профессиональном пути. Как ты связал свою жизнь с документацией? При каких обстоятельствах ты, условно, стукнул кулаком по столу и сказал: «Всё! Я решил стать техническим писателем»?

Антон Гафаров: Я по своей профессиональной натуре тоже инженер, инженер-проектировщик. У меня специальность – пожарная безопасность. Я долгое время, в течение пяти лет, даже больше, работал инженером-проектировщиком пожарных инженерных систем. То есть занимался проектированием автоматических установок пожаротушения на разных технических объектах.

Я был уверен тогда, что работать по специальности – это здорово и классно, что ты не зря потратил время на учебу в университете. И все вроде было хорошо, но постепенно так получилось, что я стал ощущать себя немножко не в своей тарелке. Были трудности с карьерным ростом на тот момент в компании, где я работал, были трудности с нагрузкой. Так получалось, что иногда мы могли сидеть месяц без проектов и я понял, что нужно попробовать что-то еще делать. Но совершенно не представлял что. Пытался смотреть, где еще могут понадобиться мои профессиональные навыки, но нигде они никому не были нужны в этот момент из тех мест, куда я мог дотянуться. А в чем заключается сейчас работа инженеров-проектировщиков? Неважно, какие системы они проектируют, работа заключается в том, что инженеры-проектировщики постоянно работают с документацией разного вида, большая часть это чертежи, 3D-модели и, конечно, текстовая документация тоже.

Мой хороший друг из университета, Женя, он тогда работал техническим писателем в IT, открыл мне глаза вообще на профессию технический писатель и на то, что, оказывается, навык работы с техническими текстами – это не что-то обычное, что умеют делать все, а это серьезный самостоятельный навык, который может пригодиться и в других сферах, не только в промышленном строительстве и чем-то подобном. И тогда я решил попробовать, попытаться перейти в IT и заниматься документацией уже в IT.

Путь, конечно, не был простой, но волей судьбы я попал в одну крупную известную компанию, Тут нечего скрывать, это Яндекс. В Яндексе и тогда, и сейчас существует целое направление технических писателей, которые работают внештатно. Это внештатные технические авторы, которые занимаются поддержкой самых разных документационных проектов внутри экосистемы Яндекса. В Яндексе очень много разных продуктов, внутренних, внешних, и все эти продукты хорошо задокументированы, во многом благодаря как раз этому подразделению. Это была такая работа не full-time, это такая part-time работа была, разумеется, удаленная, и мне это показало, что это отличный шанс стартовать вообще в IT, прикоснуться к этой сфере и разобраться, в чем же документация в IT отличается от документации за ее пределами. Вот там я поработал, в итоге поработал достаточно долго, но уже через 3-4 месяца после того, как я начал работать в Яндексе, я сумел найти себе свою первую full-time работу полноценным техническим писателем в небольшом IT-стартапе. И вот с той поры стал уже планомерно двигаться и развиваться профессионально, как технический писатель именно в IT-секторе.

Вот прошло с тех пор уже 5 лет и я продолжаю заниматься документацией. Даже скорее уже не документацией, а более широко стал заниматься знаниями в IT-командах. Сейчас я работаю в компании RWB, это Wildberries & Russ, техническим писателем и менеджером знаний, веду несколько внутренних документационных проектов.

Владимир Юсупов: Антон, так мы с тобой вообще практически коллеги, потому что я тоже инженер-проектировщик. Единственное, в машиностроении, а не в строительстве. Ну, очень близко. В продолжении вопроса про трудоустройство, кстати. Если не ошибаюсь, в одном из своих постов, может, даже не в одном, ты как-то отмечал, что идеальный срок работы на одном месте в IT – это 2-2,5 года. Почему именно столько?

Антон Гафаров: У нас в университете была преподаватель по маркетингу, которая нас учила, в числе прочего, что нужно каждые 5 лет пересматривать свой профессиональный статус. То есть если в течение пяти лет ничего не меняется, то есть ты не растешь на одном месте работы, например, горизонтально или вертикально, то это серьезный повод пересмотреть свой текущий статус и что-то изменить.

Я как раз на своем первом месте работы в роли инженера-проектировщика проработал пять с половиной лет и после этого сменил кардинально не только компанию, но и сферу деятельности. И тогда я понял, что 5 лет – это очень много. Наша жизнь не такая большая, чтобы позволять себе мыслить пятилетками. Мы все-таки уже вышли из того исторического периода, когда мыслили пятилетками. Поэтому я понял, что пятилетку нужно не в 4 года, а поменьше, как-то покомпактнее уложить. И сам для себя определил примерный срок, когда я пересматриваю свой текущий профессиональный статус, то есть насколько мне комфортно работать в компании, насколько я чувствую себя комфортно. Не будем также скрывать доход, который у меня есть в текущем (месте работы). Насколько я себя удобно чувствую комфортно в тех задачах, которые я выполняю и в том своем текущем статусе рядового сотрудника или там какого-нибудь младшего руководителя. И помимо всего этого, я еще и оцениваю то, насколько я, по моему мнению, полезен реально этой компании или этой команде, где я работаю. Тоже очень важно, чтобы было какое-то еще профессиональное удовлетворение того, что делаешь, понимаешь, ощущаешь, что действительно твоя работа имеет значение и несет пользу своим коллегам или пользователям продукта, на котором ты работаешь.

И этот срок 2-2,5 года – это, конечно, такой очень условный, но я думаю, что многие, наверное, согласятся, что первые, как минимум полгода, сейчас, может быть, уже побыстрее, первые 3-4 месяца ты все равно еще только вливаешься в новую компанию, в процессы. Особенно если какой-то сложный продукт или целый набор разных продуктов, целая экосистема, которой тебе предстоит заниматься, то, конечно, тут онбординг может проходить достаточно долго. Вот поэтому, период в год, наверное, все-таки маловато, чтобы действительно почувствовать, если ты собираешься поменять работу, чтобы уходить с чувством выполненного дела, с чувством, что ты можешь поставить здесь, если не точку, то хотя бы запятую, то есть дойти до какого-то логической паузы – я этот объем работы выполнил и действительно принес компании пользу. Это здорово.

Я сейчас в IT работаю 5 лет, если не считать Яндекса, который все-таки был такой работой параллельной с full-time деятельностью, я поработал в трех разных компаниях. В компании, где я работаю сейчас, уже два года, а в предыдущих работал полтора года и год. И в целом, я думаю, что я в обоих случаях вовремя уходил. То есть я уходил с чувством того, что мне, во-первых, не стыдно это оставлять, то, что я сделал, и, во-вторых, я уходил с чувством того, что я не успел очень сильно заскучать, устать или не успел разочароваться в том, что я когда-то сюда пришел. И сейчас, когда я провожу анализ своей деятельности в текущей компании, я понимаю, что мне здесь сейчас комфортно, поэтому я тут продолжаю работать. То есть не обязательно два года работать и уходить. Если все комфортно, все здорово, то можно работать и 3, и 4, и 5, и 10 лет. В этом, конечно, нет ничего плохого.

Владимир Юсупов: Да, я с тобой здесь согласен.

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

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

Антон Гафаров: Это точно. Особенно сейчас, когда немного усложнился процесс поиска новой работы, networking, конечно, решает многое. И это здорово. Ко мне тоже периодически приходят мои бывшие коллеги и куда-то приглашают, вот это круто. Я чувствую, что значит, я хорошо там поработал.

Владимир Юсупов: Да, это точно. Но понятное дело, что хорошие отношения не являются залогом того, что специалиста с полной уверенностью возьмут на работу. Все-таки этот специалист должен обладать определенными навыками, уметь выполнять поставленные перед ним задачи и, более того, уметь выполнять их качественно. Опять же в своем телеграм-канале ты вспоминал плакат про “Качество” из офиса проектировщиков. Скажи, что для тебя значит качество в работе техписателя?

Антон Гафаров: Да, давай сначала я напомню текст этого плаката. Плакат был такой, там была такая фраза “Качество – это не цель, это точка отчета”. Этот плакат меня всегда очень пугал и вызывал у меня какие-то неприятные ощущения, потому что этот плакат, он такой немного уличающий. Он говорит тебе, что то, что ты тут что-то делаешь хорошо, это недостаточно. Но на самом деле сейчас я отчасти с этим плакатом согласен, но я считаю, что этот плакат не говорит о том, что у тебя должно быть все идеально. Это какой-то базовый минимум, и от него ты дальше уже идешь и какие-то сверхподвиги делаешь.

Нет, я думаю, что здесь, наверное, под качеством можно подразумевать именно твое отношение к работе, твое стремление сделать то, чем ты занимаешься, хорошо. Понятно, что качество – это такое достаточно абстрактное понятие, И сейчас сложно сказать, что такое качество. Где качественно, а где некачественно. У каждого это будет свое определение, своя шкала, своя градация. И обязательно найдутся какие-нибудь люди, для которых качество – это вообще недостижимый идеал. И, конечно, не хочется по их мерилам качества работать. Но я думаю, что здесь, наверное, в работе технического писателя, любого другого специалиста, понятие качества именно в этом представление оно не сильно отличается. Это просто выполнение своей работы хорошо, ответственное выполнение своей работы. Когда ты отвечаешь за все то, что ты делаешь. Когда ты готов сказать “Да, это сделал я и готов за это ответить”.

Владимир Юсупов: Да, я тебя понял, Антон. Если продолжить направление по качеству. Не так давно прошел митап по технической документации TechDocs Meetup RWB, где ты и твои коллеги делились своими знаниями и опытом. Прими мои поздравления! Мероприятие прошло на высшем уровне – не только качественный контент, но и хороший звук, свет, картинка в целом. Очень профессионально!

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

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

Для достижения этих целей в арсенале современного технического писателя достаточно широкий набор инструментов, который роднит техписателя с инженером. В целом, работа техписателя становится более, скажем, инженерной. Процитирую здесь всеми нами уважаемую Арину Балерину: “Все мы сначала вышли из инженеров, теперь в инженеров снова и превращаемся”. Не уверен, что дословно повторил, но смысл именно такой. Например, программная инженерия со своим подходом к разработке, функционированию и сопровождению программного обеспечения “поглощает” многие “смежные” сферы ИТ-индустрии. В моем профессиональном сегменте я вижу это на примерах парадигм data-as-code, bi-as-code. На жизнь техписателей инженеры также оказали свое влияние в виде docs-as-code. Вот о последнем давай немного поговорим.

Часто сталкиваюсь с тем, что когда говорят о docs-as-code, то каждый подразумевает что-то свое. Скажи, пожалуйста, что ты лично вкладываешь в понятие docs-as-code? Опиши, пожалуйста, в каком случае можно сказать, что техписатель работает в этой парадигме?

Антон Гафаров: Docs-as-code – это я бы сказал, не просто подход, это целый фреймворк, с помощью которого ты можешь заниматься работой с документацией. Его определение очень простое, поэтому и дает такое широкое поле для разных интерпретаций. Docs-as-code – это использование практики инструментов работы с кодом для работы с документацией. Очень простое определение, которое в себя вбирает очень многое. Настолько многое, что если куда-то в кучку техписателей вбросить вопрос, что такое docs-as-code и что не является docs-as-code, то там начнется, скорее всего, драка рано или поздно, потому что, каждый убежден в том, что его вариант docs-as-code – это docs-as-code настоящий, сертифицированный, а какой-то там нет. Но я думаю, тут нет правильного ответа и не может, потому что docs-as-code – это в первую очередь способ организовать свои рабочие процессы, связанные с документацией. Давай еще шире скажем, связанные с обработкой знаний.

Это просто способ организовать (процессы) с использованием определенных практик и инструментов. Существует ли какой-то минимальный набор практик и инструментов, если мы его возьмем и скажем, что у нас docs-as-code, а если мы какой-то из этого минимального набора используем, у нас не будет его, то у нас будет еще не docs-as-code. Такого минимального набора нет. Никто его не определил. Я думаю, что каждый определил сам для себя, и при этом все окажутся правы. В таком общеупотребимом понимании считается, что когда у тебя документация пишется в каком-то облегченном языке разметки, то есть она формализована максимально, сами исходные файлы, из которых будет документация собираться. Вот когда она тебе пишется в таком облегченном языке разметки, условный markdown, когда она у тебя хранится в Git-репозитории, и когда ты ее обновляешь с помощью этого Git-а. И когда ты эту документацию потом компилируешь, собираешь вместе и на выходе получаешь какой-то, условно, документационный продукт. Чаще всего под этим продуктом подразумевается статический HTML-сайт, который с помощью генераторов собирается из этих исходных файлов. И этот статический HTML-сайт ты выгружаешь на какой-нибудь сервер. Считается, что это минимальный необходимый набор для того, чтобы сказать, что у тебя docs-as-code.

Опять же, я говорю, что это такое общеупотребимое понимание. Это далеко не всегда бывает именно так. Не обязательно в конце получать HTML-сайт и куда-то его выгружать. Можно в конце получить PDF, можно в конце собрать Word-овские документы даже. Это несущественно. Не обязательно использовать Git, можно использовать какую-нибудь другую систему контроля версий, если кто-то еще пользуется другими системами контроля версий и так далее. То есть это такое просто общеупотребимое понимание docs-as-code, которое мне кажется не совсем исчерпывающим, потому что это представление охватывает только одну часть подхода – набор практик инструментов. Все, что я сейчас перечислил, это, по сути, инструменты. Да, облегченный язык разметки, Git или какая-то другая система контроля версии, условный генератор сайтов, с помощью которого мы собираем документацию, CI/CD, чтобы эту документацию сгенерировать и куда-то задеплоить. Это все инструменты. Про практики тут уже ни слова нет. А я все-таки считаю, что docs-as-code – это именно набор практик в первую очередь и инструментов во вторую очередь.

То есть практики – это содержание подхода docs-as-code, а инструменты – это форма подхода docs-as-code, и с помощью инструментов мы реализуем те или иные практики. А вот какие практики работы с кодом мы можем реализовать для работы с документацией? Например, практика версионирования кода. Что нам на самом деле дает система контроля версий? Она позволяет нам в случае документации содержать неограниченное количество версий документации, обеспечивает нам параллельную работу на документации, то есть командную работу, обеспечивает нам прозрачный процесс ревью документации. В конечном итоге у нас повышается качество документации за счет того, что у нас налажены какие-то прозрачные процессы вычитки и ревью этой документации. У нас повышается скорость разработки документации, потому что мы можем работать вдесятером над одним и тем же документационным проектом и так далее. Вот эта практика, которая реализуется с помощью системы контроля версий. И так с каждым инструментом. Каждый инструмент подхода закрывает собой какую-то практику, которую мы позаимствовали у наших коллег-разработчиков. Этот симбиоз практик и инструментов в итоге рождает тот самый подход docs-as-code, когда мы полноценно реализуем нашу документацию так же, как реализуются программные продукты.

Ну и самое, на мой взгляд, важное. Как результат работы, условно скажем, программистов, это какой-то конкретный программный продукт на выходе получается, то результат работы документатора в парадигме docs-as-code должен быть тоже какой-то продукт. Поэтому в моем представлении docs-as-code неразрывен с еще одной концепцией, с концепцией документации как продукт. Мы на выходе получаем не просто какую-то документацию, мы получаем полноценный документационный продукт. Что это может быть за продукт? Например, тот же самый HTML-сайт, который, не сам по себе HTML-сайт, не какие-то там сухие HTML-ки статические, а именно HTML-сайт, который у нас публикуется на каком-то конкретном сервере и по какой-то конкретной ссылке доступен нашим пользователям. Мы на выходе получаем какой-то док-продукт, который можем предоставить как конечную точку документации нашим пользователям. И вокруг этого документационного продукта строится весь подход. И тогда уже, когда мы ставим во главу угла именно этот документационный продукт, у нас все выстраивается уже более-менее логично, и мы уже понимаем, для чего мы используем те или иные инструменты, которые мы заимствуем у наших коллег-разработчиков – Git, какие-то CI/CD инструменты и что-нибудь еще.

Владимир Юсупов: Антон, а всегда ли техписатель должен применять подход docs-as-code? Когда команде лучше продолжить работать с документацией, например, в том же Confluence?

Антон Гафаров: Да, серьезный вопрос, очень важный, потому что docs-as-code – это, по сути, один из вариантов того, как ты можешь организовать документацию у себя. Вариантов много разных бывает.

Мы, технические писатели увлекаемся этим, потому что главное преимущество docs-as-code перед остальными подходами разработки документации – то, что он интересный. Сам по себе инструментарий docs-as-code интересный, потому что ты можешь почувствовать себя настоящим полноценным айтишником. Ты будешь работать в Git-е, будешь в консольке вводить команды гитовские, будешь клонировать репозитории, пушить, пулить, решать конфликты и так далее. Это действительно интересно. Из-за того, что технический стэк docs-as-code занимательный, его интересно изучать, его интересно настраивать. Не секрет, целый есть еще такой большой пласт DocOps-а, то есть именно работы с инструментарием к документации, настройка всех этих процессов публикации, документации и так далее. Из-за того, что это очень интересно и заманчиво, иногда бывает так, что люди начинают реализовывать docs-as-code только по этой причине, что это интересно и заманчиво.

На мой взгляд, это немного неверный путь, потому что docs-as-code – это подход, который должен служить человеку, а не человек подходу. Поэтому docs-as-code не всегда подходит для ведения документации. Я убежден, что реализация docs-as-code в команде должна начаться не по инициативе одного человека, например, документатора, технического писателя. Она должна созреть в самой команде. То есть процессам команды по документации должно стать тесно в текущих условиях. Например, команда ведет документацию в какой-то вики-системе, в условном конфлюенсе. И вот команде становится неудобно. По какой-то причине команда перестает понимать, как обновляется документация. Или, например, команда хочет более прозрачные процессы проверки документации. Тогда, конечно, уже назревает необходимость эти процессы как-то улучшить. И когда возникает понимание того, что инструменты docs-as-code могут эти процессы реально сделать лучше и команде будет удобнее, тогда, конечно, его можно внедрять. А бывает наоборот.

Бывает, что команде не нужен никакой docs-as-code. Ведь это дорогой подход. Дорогой не в плане того, что много денег надо потратить на него. Он дорогой, потому что он часто во многом бывает избыточен. Когда, например, команда ведет какую-то свою внутреннюю документацию, например, в таком ключе, что нужно куда-то быстренько закинуть RFC-шку, чтобы она сохранилась в памяти, не потерялась. Вот такая документация, например, в парадигме документации как код не будет эффективной, потому что, чтобы быстренько закинуть какие-то обновления, какие-то свои мысли в docs-as-code тебе придется пройти большой путь. Придется создать ветку, придется внести изменения, придется создать merge-реквест, дождаться, пока кто-то его проверит, аппрувнет и так далее, а потом запустить там сборку. Тогда только получишь свои знания, запечатленные в твоей док-системе. На это уходит очень много времени. Помимо этого тебе нужно еще во всем этом уметь разбираться. Если, допустим, какой-нибудь аналитик хочет внести свои какие-то срочные штучки, ему придется вот этот весь путь проходить. Это, наверное, будет неэффективно. Документация будет теряться, потому что не будут соблюдаться потребности конкретных пользователей документации. Поэтому нужно всегда исходить из потребностей конкретной команды.

Как там в манифесте Agile было “люди важнее процессов”. Вот это полностью про документацию в том числе. Документация, в первую очередь, это процессы документирования. А процессы – это, в первую очередь, люди, которые этим занимаются.

Владимир Юсупов: Антон, ты отметил, что важнее всего люди. У тебя есть курс «Docs-as-code для самых маленьких». Ты обучаешь техписателей этой методологии. Люди приходят к тебе разные - кто-то, видимо, с более глубоким айтишным бэкграундом, кто-то менее. Какой главный барьер в мышлении, на твоем опыте, приходится преодолевать студентам твоего курса?

Антон Гафаров: Я думаю, что на самом деле вообще барьеров здесь никаких нет. Docs-as-code воспринимается иногда как что-то сложное и трудное настолько, что там HR отдельно вписывают docs-as-code в список родовых навыков в вакансиях. На самом деле docs-as-code, как мы выяснили, это набор инструментов. Если мы говорим о навыках, то это набор инструментов, то есть навыки владения определенным набором инструментов, достаточно небольшой набор этих инструментов.

На моем канале есть курс для самых маленьких, docs-as-code для самых маленьких, он автономный. Каждый может просто по хэштегу его найти на канале и пройти самостоятельно. Этот курс знакомит с инструментами – давайте мы научимся клонировать репозиторию Git, давайте мы научимся писать в Markdown. Это супер, конечно, навык. Чтобы разобраться в синтаксисе Markdown, нужно потратить минут 10, наверное. И то же самое, чтобы разобраться git push, git pull, git merge тоже нужно потратить полчаса, может быть. А теперь давайте попробуем с помощью какого-нибудь генератора сайтов собрать из Markdown файлов сайт. Это тоже нужно потратить минут, наверное, 30. Умножим на какой-нибудь коэффициент и в течение дня можно с этим всем разобраться. Но это просто инструментарий.

Это как научиться пользоваться газовой плитой и разной посудой на ней. Вот эта сковородка, на нее мы кладем что-нибудь жарим, вот это кастрюли. В кастрюле мы не жарим, в кастрюле мы варим. Вот мы познакомились с инструментарием, потратили на это 30 минут. А теперь давайте займемся более интересным. Давайте теперь займемся тем, а как с помощью сковородки, кастрюли и газовой плиты приготовить ужин. Почему картошка варится не так же, как макароны, например. Почему говядина жарится в три раза дольше, чем курица. Вот это уже процесс docs-as-code.

У меня есть еще второй курс, я называю это большой мастер-класс docs-as-code для ребят постарше. Он уже не автономный, там уже мы занимаемся все вместе на онлайн-встречах, проводим воркшопы, разбираемся не только с инструментами, но и практики. А зачем мы эти инструменты применяем? Давайте мы сейчас сварим картошку, сварим макароны и поймем, в чем между этим разница. И самое главное, зачем нам это варить? Вот это уже более важный вопрос.

Владимир Юсупов: Понятно. Антон, давай подрезюмируем информацию по блоку docs-as-code и немного пофантазируем. Если бы тебе предложили составить, скажем так, своеобразный кодекс из трех правил, золотых правил docs-as-code для технического писателя, какие бы это были правила?

Антон Гафаров: Первое правило – это то, что процессы docs-as-code важнее, чем инструменты docs-as-code. Второе правило – люди важнее, чем процессы и все остальное. И третье правило – никто, кроме вас самих, не может указывать вам, что считается docs-as-code, а что нет. Это очень важно.

Но самое главное, к чему приводят все вот эти три условных тезиса, то что docs-as-code – это просто методология, которая может помочь вашу документацию сделать лучше, а может сделать вашу документацию хуже. И нормально использовать, например, какие-то отдельные аспекты docs-as-code, или не использовать его вовсе, или использовать его максимально. Все зависит от того, насколько это коррелирует с пожеланиями ваших коллег в команде и вас самих.

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

Владимир Юсупов: Согласен. Уверен, что те слушатели, которые только знакомятся с парадигмой docs-as-code, теперь получили подробную информацию и понимание, что это такое. Но я хотел бы копнуть немного глубже и добавить задачку со звездочкой. Антон, расскажи, пожалуйста, о концепции Docs-as-a-Service («Документация как услуга»). И как это работает на практике?

Антон Гафаров: Документация как услуга – это такая концепция, когда ты предоставляешь свои услуги по документированию, упрощенно говоря. Она не работает в вакууме, она работает только в конкретных условиях, в конкретной команде или компании. Если есть возможность у наших слушателей, я предлагаю посмотреть мое выступление как раз митапе RWB. Там я рассказываю о том, как мы у нас в команде постепенно пришли к реализации этого подхода документации как услуга.

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

Я немного попробую привести пример, опять же, из своей текущей рабочей деятельности. У нас есть док-портал внутренней документации, который как раз существует в парадигме документации как код. И так получилось, что все мои коллеги, не технические писатели любят писать документацию и пишут ее сами. То есть несколько команд держат свою документацию на этом портале и сами ее пишут. И я, как человек, который профессионально разбирается в технических текстах, предоставляю им услуги по ревью их текстов. Они приносят свою документацию и я эту документацию вычитываю. Провожу ревью не в таком ключе, как обычно проводят его в техписательских командах, не возвращая им пачку замечаний, что «пожалуйста, поправьте, это у вас не так», а я сам правлю их текст. Иногда это бывает достаточно глубокая корректировка, вплоть до того, что исходный текст переписывается на 90%. Бывает просто такая базовая корректировка, плюс корректировка верстки, тот же самый Markdown, которая несколько сложнее у нас, чем классический Markdown, разные расширения. Я понимаю, что, например, вот это можно оформить чуть лучше и так далее. Это пример одной из таких услуг. Люди приходят с каким-то запросом на документацию. Допустим, у них есть черновик, им нужно превратить его в красивую документацию. Они приносят и на выходе получают готовую красивую документацию. Не список замечаний, не совет, как сделать лучше, а просто готовую документацию. Вот это и есть предоставление одной из услуг документирования.

Как в магазине. Ты приходишь, даже не в магазине, а в каком-нибудь там салоне, говоришь, мне нужна стрижка модельная. Садишься, через 40 минут у тебя красивая модельная стрижка. Здесь что-то наподобие этого. То есть такой магазин услуг, только услуг по документированию.

Это достаточно специфический подход, потому что он может реализоваться только при соблюдении определенных условий. У нас просто в команде сложилась такая ситуация, когда много кто пишет, поэтому я могу предоставить определенный список услуг, помимо ревью документации, еще и предоставления нашего док-портала, как место хостинга документации, технической поддержки документации в нашем док-портале. Я выступаю еще и в роли владельца продукта, владельца хостинга документации команд. Это такая особенная немного история. Я сейчас так сумбурно объяснил, но если вы посмотрите и послушайте мои выступления на митапе RWB, или если не найдете, еще можно послушать выступления на конференции WriteConf, которая в феврале проходила, по-моему, там они выложили видео, там тоже рассказывал про нашу документацию, в том числе про концепцию документации как услуга. Я думаю, там будет более понятно.

Владимир Юсупов: Я добавлю обязательно ссылки на эти мероприятия. Думаю, достаточно для слушателей на сегодня информации docs-as-звездочка. Антон, хочу обсудить с тобой еще одну неоднозначную тему – как ты относишься к внедрению искусственного интеллекта в рабочие процессы техписателей? Применяешь ли ты ИИ в своей работе? Если да, и это не является конфиденциальной информацией, то какими инструментами пользуешься?

Антон Гафаров: Искусственный интеллект – это реалии сегодняшнего дня. Конечно, глупо и наивно отрицать значимость этого инструмента и пытаться избежать его использования. Потому что это наше даже не будущее, это наше настоящее.

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

Я уже тут до этого говорил, что я занимаюсь поддержкой док-системы у нас, внутренней документации. Эта док-система представляет из себя док-портал, который как раз реализован в парадигме docs-as-code. У нас есть несколько репозиториев, где хранится документация в Markdown, потом она вся собирается в один большой красивый док-портал, один большой красивый сайт. Док-портал реализован с помощью фреймворка Material for MkDocs, достаточно известный генератор стратегических сайтов, который очень популярный и много где используется. Мы его используем тоже. Когда ты создаешь такую док-систему, которая еще и выглядит, как какой-то программный продукт, всегда хочется пользователям, и тебе самому, всегда хочется какие-то дополнительные фичи, чтобы там были. Когда на самом деле это просто статические HTML-странички, которые предназначены для того, чтобы красиво отображать текст. И всегда людям хочется иметь какие-то фичи, которые на самом деле, можно было бы реализовать, если бы у этого всего был полноценный бэк. Никакого бэка полноценного нет, это просто статический HTML. Вот, и как раз для реализации таких вот фичей я использовал и использую до сих пор AI-ассистентов, то есть занимаюсь вайб-кодингом, чтобы эти штучки сделать.

И это действительно эффективно, это здорово, я начал использовать для вайб-кодинга AI где-то около двух лет назад и поразился, насколько это реально ускоряет мою работу. Сначала я что-то пытался сделать с помощью советов на Stackoverflow и прочее. Что-то получалось, но это было долго, медленно, и получалось не с первого раза. И потом, когда я решил попробовать это же сделать с помощью искусственного интеллекта, то вышло гораздо быстрее. В первый раз потратил целый рабочий день на это, но я сделал то, что я до этого пытался сделать в течение недели. И это классно. Это действительно облегчило мою задачу. С тех пор я, конечно, являюсь не амбассадором, но таким вайб-кодером-любителем. И занимаюсь этим для поддержания, для развития своих продуктов документационных. В принципе, мне нравится результат, который получается.

Что касается текста, то я практически не пользуюсь искусственным интеллектом для работы с текстами. Вот единственный момент. Я думаю, что все люди, которые занимаются профессиональными текстами, встречались с такой проблемой. Бывает просто затык, когда у тебя сформулировалась мысль, и она сформулировалась, очевидно, неправильно. Это какой-то косноязычный кусок текста, который ты никак не можешь этот клубок раскрутить в красивую ровную нить повествования. И в таких случаях иногда я спрашиваю, просто буквально предложение, которое у меня зависло, спрашиваю: как бы ты это переформулировал? Он там что-то переформулирует, и я вдохновляюсь его изменениями и понимаю, что мне нужно сделать с этим текстом. То есть я даже не беру в итоге те варианты, которые предлагает он, но на основе этих вариантов я сам понимаю, а что же здесь я хотел на самом деле сказать, основная мысль вот этого куска текста была в чем? И это мне помогает его переформулировать, вот этот клубок распутать.

Владимир Юсупов: Взгляд со стороны как будто бы, да?

Антон Гафаров: Да, да, будто бы какой-то совет со стороны твоего коллеги. Если у меня был бы коллега технический писатель, я, может быть, мог бы спросить его, а тут спрашиваю искусственный интеллект.

Чем я пользуюсь? Когда начинал, я подумал, что я поддержу отечественного производителя, использовал один из наших отечественных чатов. Мне не понравилось. Точнее, понравилось, но я в какой-то момент попал в такой замкнутый круг. Знаешь, когда муравьи собьются и начинают бегать кругами вокруг муравейника и все потом погибают. Вот мы с этим чатом попали в такой замкнутый круг. Реализовывали одну фичу для док-портала и там постоянно вылезала ошибка и мы исправляли эту ошибку, то есть занимаясь дебаггингом. В какой-то момент я понял, что мы просто ходим по кругу. Он исправляет ошибку, создает другую ошибку, исправляет ее снова, и за несколько раз возвращается к первоначальному багу. Вот мы так ходили, ходили, и я понял, что это не так. Я пошел искать какого-то третейского ИИ-чного судью, и с помощью другой модели мы этот вопрос разрешили. С тех пор я перестал пользоваться этим чатом, которым пользовался, потому что я понял, что, к сожалению, для вайб-кодинга он не очень хорошо подходит.

Сейчас я пользуюсь Qwen и DeepSeek. Есть у нас внутри нашего контура развернутые свои модели. Если мне необходимо какую-то NDA-информацию скормить, я пользуюсь этими нашими внутриконтурными моделями. Если мне никакой NDA-информации скармливать не надо, что чаще всего и бывает, потому что разработка фичей – такая достаточно абстрактная вещь, она никак не связана с тем контентом, который мы храним. А сам Material for MkDocs – это open-source. Поэтому я пользуюсь стандартными моделями, которые доступны бесплатно, без подписки. И для моих задач этого достаточно пока что.

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

Антон Гафаров: Да, тут, наверное, сложно дать какой-то совет, который сработает. Потому что история всегда очень индивидуальная. Тут многое зависит от и текущей ситуации на рынке, и зависит от тех условий, в которых изначально находится человек.

Но я думаю так, во-первых, сейчас, на мое субъективное впечатление, недостаточно быть просто техническим писателем. Точнее, конечно, достаточно, но мне больше нравится идея быть скорее таким менеджером знаний, то есть человеком, который не просто пишет документацию, а который управляет документацией в узком смысле и знаниями в широком смысле. Документация – это ведь просто какой-то ограниченный кусочек знаний, который ты фиксируешь в какой-то там файл. Но сейчас зачастую бывает так, что этого оказывается недостаточно для команды. И поэтому приходится заниматься больше не написанием просто каких-то конкретных документов, а управлением знаниями в самом широком смысле. Фиксацией знаний и упаковкой этих знаний, правильным выстраиванием процессов по работе с этими знаниями. Есть целый такой большой комплекс. Вот поэтому я, наверное, могу посоветовать, во-первых, мыслить широко. Изначально, наверное, мыслить именно не категориями – документация, разработка документации, а категориями – знания, работа со знаниями, работа с информацией, консолидация информации, собирание информации, актуализация информации. Здесь такой, наверное, больший масштаб.

Самое-то сложное, ведь это, вообще попасть в этот загадочный мир IT. Потому что уже потом внутри все гораздо легче. Я думаю, что очень важно искать у себя релевантный опыт. Он есть почти у каждого. Например, я никогда до определенного времени не сталкивался непосредственно с программными продуктами в своей работе, чертил в Автокаде и писал рабочую документацию, проектную документацию в Word. Но оказалось, из этого можно найти какой-то релевантный опыт, который можно показать своим будущим работодателям, выйти и сказать, смотрите, я умею делать это, а это то же самое, что и у вас, просто другая предметная область. Надо всегда находить вот этот релевантный опыт у себя. В своем профессиональном бэкграунде, и он, скорее всего, найдется. И второй очень важный момент. Если релевантного опыта нет, надо его придумывать, создавать самостоятельно.

Когда я искал свою работу первую в IT, я написал несколько фейковых, ну, не фейковых, это было настоящее, несколько текстов технических инструкций к разным программам, которые были никому не нужны. Я просто взял их и сам написал. И потом показывал это как свою портфолио. Это тоже работает. И я думаю, что в первую очередь, конечно, для тех, кто хочет работать с документацией, с текстами, нужно убедиться, что вы действительно обладаете этими навыками работы с текстом, потому что это самое главное. Все остальное, все технические эти приколы, знание технологии, какая-то вот эта IT-эрудированность, как еще любят писать, docs-as-code и все прочее, это на самом деле все вторично, как бы не думали сами HR.

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

Владимир Юсупов: Ну ладно, продолжим тогда дальше. Дим, есть такой техписатель, широко известный в узких кругах, Том Джонсон. Думаю, ты о нем слышал. Он специализировался все на документации интерфейсов и так далее. Сейчас он работает техписателем в Google, по-моему. Это не столь важно. Так вот, Том является активным пользователем и одним из популяризаторов искусственного интеллекта в работе техписателей. В этом вы с Томом похожи, в какой-то степени. И обычно в начале каждого года у него выходит такой небольшой прогноз на текущий год развития индустрии (его субъективный взгляд на развитие индустрии). Одна из частей этого прогноза, наверное, как минимум из нескольких последних лет, посвящена искусственному интеллекту. Если позволишь, я приведу небольшую выдержку из его прогноза на текущий год.

Антон Гафаров: Да, конечно.

Владимир Юсупов: Антон, благодарю тебя за сегодняшнюю встречу! Мне было очень интересно и приятно с тобой беседовать.

Также хочу публично тебя поблагодарить за помощь и поддержку в проведении митапа по вывеской Техкомпод (TechCommPod Online Meetup). Я обращался во многие профильные ресурсы (телеграм-каналы и т.д.), просили дать время подумать, в итоге не возвращались и т.д. Но только ты и Михаил (автор канала “Мишка в курсе”) согласились без каких-либо условий оказать информационную поддержку. Я был крайне удивлен такой открытости и отзывчивости. Поэтому искренне благодарю тебя и Михаила!

Желаю тебе успехов!

Антон Гафаров: Спасибо большое. Спасибо и за сегодняшнюю встречу, и спасибо за тот митап, который ты проводил весной. Действительно, это очень важно. И у нас вообще очень хорошее техписательское комьюнити русскоязычное. И у нас есть лишь одна небольшая проблема – нам недостаточно мероприятий профессиональных. Поэтому спасибо, что ты вносишь свою лепту в развитие нашего такого внутригильдийного, внутрицехового общения. Спасибо большое.

Владимир Юсупов: Спасибо, Антон. До встречи.

Антон Гафаров: Да, до встречи.

Владимир Юсупов: Благодарю, что прослушали этот выпуск.

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

Сегодня с вами были Антон Гафаров и Владимир Юсупов. Подкаст технического коммуникатора Техкомпод.

До встречи!

Понравился выпуск? Поделитесь с друзьями и коллегами!

Похожие выпуски