Выпуск #24. Беседа с Екатериной Павловой

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

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

Стоит ли бояться делиться своими знаниями? Как правильно организовать процесс передачи и накопления знаний?

Разобраться в этих и многих других вопросах мне помогла (по-моему всегда!) веселая и задорная Катя Павлова, директор по продукту Gramax (приложения для подготовки документации).

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

Связаться с Катей или узнать про Gramax:

Профессиональная социальная сеть

Телеграм

Сайт

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

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

---

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

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

Часто беседую со многими людьми по одному из своих любимых направлений, техническому писательству. Все собеседники пришли к техписательству, что называется, «через тернии к звёздам». Кто-то пришёл из условной технической сферы (инженеры, разработчики), кто-то из академической среды и так далее. Мало кто ставил себе цель стать техническим писателем и связать свою жизнь с профессией на стыке литературы и технологий.

В сегодняшнем выпуске вы услышите запись беседы с Катей Павловой, директором по продукту Gramax (приложения для подготовки документации). Катя расскажет о своем пути к техписательсву, поделиться своим опытом в сферах управления знаниями и бизнес-процессов. Также помимо описания функциональности Gramax Катя, конечно же по секрету, расскажет еще пару закулисных историй, связанных с этим интересным продуктом.

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

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

Екатерина Павлова: Владимир, привет!

Владимир Юсупов: Катя, одно из моих любимых направлений моей профессиональной деятельности — это техническая коммуникация и, в частности, техписательство. Ребята, с которыми я беседовал ранее и в подкасте, и на работе, и на некоторых офлайн-мероприятиях, пришли в техписательство из различных сфер. Твой же случай, как я понимаю, он обратный. Ты начала свой профессиональный Путь с позиции именно технического писателя, а затем немного сменила профиль. Вообще, очень интересен твой Путь. Когда я готовился к нашей беседе, искал информацию о тебе, в одной из социальных сетей в твоем профиле прочитал следующее. Если позволишь, я прочитаю сейчас.

Екатерина Павлова: Да, давай.

Владимир Юсупов: Итак, цитата «Писала документацию, управляла знаниями, строила бизнес-процессы. Научилась точно определять боли компании и сотрудников, потому теперь их лечу. Ищу кейсы, где что-то не получается, вы мне информацию, я вам варианты решения». Предлагаю построить беседу, основываясь на первом предложении из описания твоего профиля. Давай пройдемся по всем частям описания в том порядке, в котором они идут в предложении. И начнем с написания документации, с технического письма.

Как ты знаешь, условно техписателей можно разделить на две группы – это технари, которые любят или умеют писать, и гуманитари, которые разбираются или любят разбираться в технологиях, каких-то технических вопросах. Расскажи, пожалуйста, в какой условной группе ты себя относишь (или относила ранее) и как ты пришла в техписательство?

Екатерина Павлова: Да, очень классный вопрос, потому что у меня всё сложилось так, что в техническое писательство я попала, когда вообще не имела никакого представления о том, как работает IT, и тем более никогда не сталкивалась ни с какими технологиями. То есть я сама по себе очень жёсткий, если так можно выразиться, гуманитарий. Вообще у меня образование журналиста и долгое время я работала фрилансером, занималась SMM. То есть я писала, но я писала посты в соцсети, копирайтерские материалы и со сложными техническими текстами никогда не сталкивалась. И попала в техническое писательство, можно сказать, случайно.

Я в то время жила в славном городе Ярославле, и в Ярославле есть градообразующее IT-предприятие (мы это иногда в шутку называем) компания Tensor. Я туда отправляла резюме на позицию копирайтера и при общении с HR мне сказали, что можно попробовать писать немножко более технические тексты. Вдруг тебе это будет интересно. Да, давайте попишем немножко более технические тексты, почему бы и нет. И я помню, у меня тогда было тестовое задание объяснить в формате инструкции, либо какого-то текста, что такое протокол HTTP. И это задание меня, SMM-щика, повергло сначала в шок, но на тот момент я уже понимала, что каждый текст адресован на какую-то аудиторию. Я сама сформулировала свое тестовое задание и написала про протокол так, будто бы я рассказывала это своей маме. Меня взяли, и два года я писала инструкции к системе для работы в ресторане. И это было довольно прикольно. Я тогда, наверное, определилась, что мне интересно IT, мне интересно писать, мне очень интересно разбираться, как все работает, мне интересно просто исследовать этот бескрайний, бесконечный мир технологий. И вот так я осталась.

Владимир Юсупов: А всё-таки какого плана документацию ты готовила? Документацию по ГОСТу описывала, программные интерфейсы?

Екатерина Павлова: Это была пользовательская документация, то есть это были инструкции к продукту, как его использовать.

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

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

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

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

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

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

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

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

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

Но тут есть еще и такой момент. Если поразмышлять с точки зрения бизнеса об управлении знаниями, о том, зачем нам это все нужно, Я, наверное, иногда боюсь употреблять термин «управление знаниями», потому что это такая довольно академическая профобласть. О чем это? Есть специалисты, именно менеджеры знаний, есть очень много книг, есть очень много материалов про управление знаниями. Это все очень большая теоретическая база. Я в этой области всегда размышляю как практик. И чтобы лучше понять, что такое управление знаниями, в первую очередь стоит задавать вопрос: «Для чего это нужно?», в том числе и бизнесу. Бизнес всегда заинтересован в том, чтобы получать максимум результата от своих сотрудников за минимальное время. То есть бизнесу нужно, чтобы новый сотрудник пришел, быстро прошел онбординг, все понял и сразу же начал выполнять реальные рабочие задачи, чтобы сотрудники не ходили по кабинетам со ошалелыми глазами и вопросами «Кто мне с этой задачей может помочь?», «Где мне найти информацию?», чтобы они не тратили на это время. Естественно, чтобы разные команды параллельно не работали, не мучались над одной какой-то задачей схожей, а делились своим опытом, распространяли свой опыт, и в дальнейшем команды могли использовать опыт в своей работе. Если как-то подытожить в прикладном характере, есть суперпростые меры для управления знаниями, например, записывать ответы на самые популярные вопросы, описывать процессы, как что-то устроено, картировать знания, кто может ответить на конкретный вопрос, кто у нас профессионал по Excel, кто может помочь с вычиткой из публикации текста. Кроме простых мер, у нас есть еще и более сложные процессные меры. Я когда готовилась к подкасту, почитала твой сайт, послушала другие выпуски, где ты рассказывал о том, что долгое время занимался разработкой хранилищ данных. И я хочу вот привести пример из моего опыта. Моя родительская компания тоже занимается аналитическими системами и хранилищами данных. И раньше у нас было так устроено, что есть разные команды интеграции. Каждая команда интеграции работает над конкретным проектом для конкретного клиента. И бывало такое, что у клиента появилась какая-то хотелка, что хочу решить вот такую вот задачу. Команда начинает эту задачу решать, что-то разрабатывать, делать какой-то инструмент, его как-то описывать. И где-то в середине или иногда даже в конце процесса команда узнает, что другая команда для другого проекта такое уже однажды делала. И что получается, две команды параллельно решали одну задачу похожим, но не идентичным способом, потратив в два раза больше времени, чем можно было бы потратить.

Владимир Юсупов: Классика.

Екатерина Павлова: Да. И если говорить о менеджменте знаний, как вообще с такой проблемой справиться? Самое простое, что приходит на ум, например, проводить вебинар или как-то рассказывать друг другу о своих кейсах. Но здесь проблема решится частично, потому что когда ты готовишь кейс или когда ты готовишь вебинар, ты к этому тоже довольно-таки долго готовишься, то есть также тратишь время. И не факт, что подготовка и проведение вебинара будут гораздо быстрее, чем реально сделать эту задачу самостоятельно. У нас это решилось процессным образом. Мы концептуально поменяли фокус в своих задачах и сфокусировались на типовых проектах. Что это значит?

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

Владимир Юсупов: Да, согласен с тобой. Ты упомянула про вебинары. Было время, когда мы решили некую базу знаний ввести через запись. У нас была презентация, мы ее озвучивали через Яндекс Спич (Yandex SpeechKit). Оказалось, что продукт меняется достаточно быстро, поэтому приходилось менять переозвучку. Поэтому от вебинаров и различных видеоинструкций отказались. Но если продукт меняется редко или это какой-то процесс, который тоже редко меняется, наверное, подойдет такой вариант. А для более такой оперативной какой-то деятельности такие варианты, наверное, не очень подходят.

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

Владимир Юсупов: Вспоминая, опять же, свой опыт, когда я только начинал работать с консультантом, базы знаний у нас не было. Был простой принцип советской армии «делай, как я», когда старший консультант тебя брал под крыло, и ты просто делал, как он. Вот это была база знаний, которую ты получал именно напрямую от старшего более опытного товарища. Да, ты права, что это не совсем эффективно, потому что человека задергать можно, но и человек, в принципе, может уйти, не доучив своего более младшего, менее опытного коллегу.

Хорошо. Если говорить про один из способов накопления знаний, введения базы, самое простое, что можно делать, это ответы на какие-то вопросы, да? Правильно я тебя понял?

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

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

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

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

Мы сами в Gramax (Gramax — приложение для подготовки документации) довольно часто ругаемся о том, какой у нас будет документация, как мы опишем ту или иную фичу, в какой раздел мы ее поместим и в каком порядке, буквально по важности, у нас будут расположены фичи в Release Notes. Потому что это вкусовщина, и при организации внутренней базы знаний, в том числе, нет каких-то объективных критериев, в каком формате структурировать информацию. Каждая компания выбирает свой подход, свой разрез, в котором она эту информацию будет группировать. По команде, по продукту, по процессу. И все это, по сути, оно правильно. Оно правильно, если это работает. И с документацией точно так же. Есть вообще такое понятие, которое я, например, сама очень активно продвигаю, что документация — это маркетинг в том числе. Это не когда мы запихиваем продающие формулировки в описании фичи, а когда мы адаптируем нашу доку под нашего пользователя и под поисковые системы. И вполне вероятно, что посмотрев на какой-нибудь продукт из тех, которые ты сейчас описал, про структуру, когда говорил, если, например, пообщаться с их ответственным за эту документацию, задать вопрос: «Почему у вас организовано именно так?» Он ответит: «Так хорошо индексируется», либо «Мы общались с пользователями, они говорят, что им так понятнее». Скорее всего, у этого есть определенные причины, просто на первый взгляд они не очень заметны. А поделись своим впечатлением. Вот, например, документацию Gramax ты читал?

Владимир Юсупов: Читал, да. Но если позволишь, чуть попозже про это поговорим.

Екатерина Павлова: Хорошо.

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

Один мой хороший приятель работал бизнес-аналитиком в Утконосе в тот период, когда они отказывались от физических магазинов и столов-заказов и переходили к модели доставки заказов на дом. Интересное такое время было на заре развития новой модели ведения бизнеса для интернет-торговли. Сначала бизнес-аналитики (и мой приятель в их числе) разрабатывали процессы, а потом лично проходили по всем шагам этих процессов. Обрабатывали вместе с операторами заказы, потом шли на склад для сборки заказов, затем с водителями грузовиков развозили заказы под рейсам. В результате такого тестирования вносили корректировки в процесс до реализации идеального решения.

Расскажи, пожалуйста, каким образом ты погружалась или погружаешься до сих пор в бизнес-процессы? Как отслеживаешь, что все работает так, как задумано?

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

Опять же, из-за того, что это IT, из-за того, что мы как-то все склонны к тому, чтобы структурировать информацию и свою деятельность, они сами собой уже сложились. И, возможно, даже какой-то зачаток процесса он сам собой сложился, просто его очень сложно увидеть невооруженным взглядом. Правило вот как раз о том, что нужно сначала посмотреть, как работает команда сейчас. Процесс уже есть, его нужно просто зафиксировать и понять, все ли знают об этом процессе и какие сложности в этом процессе есть. И только после того, как появляется картинка «as-is», можно как-то представить картинку «to-be». Причем картинка «to-be» не должна быть сразу детализированной до всех мелочей. Любой процесс нужно детализировать постепенно. С течением времени он обрастает какими-то деталями, какими-то уточнениями. Команда или компания сталкивается с какими-то сложностями и придумывает, как в дальнейшем не столкнуться с этой сложностью.

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

Процесс — это всегда цикл. Либо вся команда по этому циклу двигается бесконечно, либо отдельные… разные сотрудники по нему двигаются. В конце цикла ты пришел и спросил: «Всё получилось?» Они такие: «Вот это круто, а вот здесь мы какой-то момент упустили». И ты задаешь команде вопрос: «Как вы думаете, а что стоило сделать, чтобы вот такой ситуации не случилось?» И команда сама скажет, как улучшить этот процесс. Команда сама подсветит нужные места, где требуются уточнения. Таким образом уже появится не пять шагов, например, а шесть.

Владимир Юсупов: Понятно. То есть на практике, получается (выстраивать процессы).

Екатерина Павлова: Да, с течением времени, не директивно, а в диалоге с командой. Самое главное, с постоянными ретроспективами.

Владимир Юсупов: Понятно. Если продолжить тему процессов, бывают, наверное, достаточно часто такие случаи, когда в компании внедряется что-то новое. Скажем, новый процесс. Например, ведение документации по какому-то определенному регламенту. Как правило, есть какой-то драйвер – тот, кто придумал, тот, кто внедрил этот новый процесс. Этот сотрудник занимается своим детищем, контролирует его, всё замечательно. Но приходит день, когда этот сотрудник, например, увольняется или переходит на другую позицию с какими-то иными задачами. В результате процесс, который он создал, остается, бесконтрольным. Со временем все забывают про него.

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

Екатерина Павлова: Процесс, вернее, результат этого процесса, всегда кому-то нужен. Давай рассматривать на примере накопления знаний. Был у нас тимлид который в команде построил всё так, что каждый раз, когда мы разрабатываем какую-то возможность в нашем продукте, мы эту возможность документируем. И этот тимлид ушел. Понятное дело, что команда долго без тимлида жить не будет – либо появится исполняющий обязанности, либо новый тимлид. Этому новому тимлиду процесс и требования к этому процессу перейдут по наследству. Он уже как-то сам его изменит, что-то в нем поменяет или просто продолжит по нему работать и контролировать этот процесс. Но кроме тимлида ценность этого процесса также должна понимать и команда. Если мы говорим, что мы все возможности документируем, я сомневаюсь, что команде нужно объяснять, зачем мы это делаем. Скорее всего, они сами прекрасно понимают, что если они сейчас ее не задокументируют, то это будет выстрел себе в ногу, когда придется ее как-то улучшать или дорабатывать, а никто не знает, как это работает.

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

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

Екатерина Павлова: Я сейчас развиваю продукт для подготовки документации и ведения внутренней базы знаний — Gramax. Так получилось, что я застала его буквально с первых его маленьких шажочков, когда только устроилась в эту компанию. Изначально это был продукт просто для внутреннего использования. В компании была потребность писать документацию и публиковать ее для клиентов. Наш технический директор посмотрел все возможные продукты на рынке статик-сайт-генераторов, ему что-то ничего не понравилось, он решил написать свое (тоже классика).

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

Владимир Юсупов: То есть Gramax создали практически для тебя?

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

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

Владимир Юсупов: Понятно. Не могу держаться. Во мне внутренний инженер все время спрашивает. Не могла бы ты описать верхнюю уровню архитектуру продукта (без технических деталей)?

Екатерина Павлова: Да, конечно, это совсем не секрет. Gramax построен по подходу docs-as-code, но с таким довольно низким порогом входа для нетехнических специалистов. Как это устроено?

У нас есть приложение для редактирования. В нем все авторы – технические писатели, аналитики и так далее – создают новые статьи, проводят ревью, правят документы друг друга. В приложение для редактирования встроен git-клиент, который довольно сильно упрощен для понимания как раз нетехнических спецов. Commit и push — это у нас кнопочка «Опубликовать». Симпатичное отображение веток, merge requests, которые мы называем «запросами на слияние». Все статьи, с которыми работает редактор, они для него выводятся в удобном, привычном визуальном редакторе, а под капотом хранятся в виде обычных markdown-файлов.

У нас приложение полностью self-hosted. Так как у нас нет никакого облака для того, чтобы обмениваться той информацией, над которой мы сейчас работаем, теми статьями, то в приложении нужно подключить свое хранилище. Это может быть любой git-сервис – GitLab, GitHub, Bitbucket, GitVerse. Мы в приложении подключаем свой git-сервис, условно давай обозначим GitLab, и в него мы уже публикуем каталоги. В рамках системы каталог равно репозиторий. Когда мы открываем приложение Gramax, видим каталоги, как пространство Confluence, и видим в нем статьи. Когда мы это все опубликуем в свое хранилище, видим репозиторий с markdown-файлами и с ресурсами – картинками, диаграммами и так далее.

Третья часть граммакса — это портал для чтения, который выглядит идентично, как и приложение для редактирования. Единственное, на нем нельзя изменять контент. Мы придерживаемся концепции True WYSIWYG – как я пишу приложение, так я это в конечном виде и просматриваю на портале документации. И на портал документации у нас уже заходят все, кому мы хотим показать свою документацию, чтобы они ее не меняли, а просто читали. Это могут быть клиенты, партнеры компании, другие сотрудники компании и так далее.

Владимир Юсупов: Как раз отвечу на твой вопрос ранее смотрел ли я документацию. Да, смотрел. Документация понятна, мне очень понравилось. Когда я начал знакомиться с информацией о Gramax, его возможностях, то в какой-то момент я осознал, что такого не может быть, потому что быть такого не может.

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

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

Екатерина Павлова: Это просто ужасно сложный вопрос. Как все такие талантливые люди на интервью, я элегантно уйду с этого вопроса и скажу, что, естественно, я горжусь Gramax целиком.

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

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

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

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

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

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

Владимир Юсупов: Один из пунктов, почему мне приглянулся Gramax, он бесплатный. Но, я так понимаю, есть еще все-таки версия платная. Расскажи, пожалуйста, есть какие принципиальные отличия open-source бесплатной версии от, корпоративной версии.

Екатерина Павлова: Вообще все возможности, которые мы разрабатываем, мы отдаем это в open-source. У нас здесь есть такая довольно глобальная цель предложить сообществу и всем людям, которые работают с контентом, удобный инструмент, повысить качество их работы. Но мы при этом прекрасно понимаем, что на больших масштабах, в рамках крупных компаний, open-source решения может оказаться недостаточно. Почему?

Потому что Gramax работает на подходе docs-as-code, и в нем есть такой момент, что очень сложно разграничивать доступы. Когда мы ведем документацию в репозиториях, мы ограничиваем доступ по репозиториям. Мы не можем ограничить, например, доступ на статью, мы не можем ограничить доступ на конкретную ветку, и самое главное, мы не можем этим управлять удобно в случае с нетехническими специалистами. Из-за того, что Gramax не имеет своего сервера, open-source версия не имеет своего сервера, не имеет никакого облака, как-то комплексно эту проблему довольно сложно решить. Как раз для крупных компаний мы предлагаем установку корпоративной версии, у которой этот сервер есть. И на сервере можно управлять глобальными политиками, как раз политиками доступа – кто, куда, какой доступ имеет (на редактирование, на чтение, на проверку и так далее).

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

Естественно, это единый вход, то есть single sign-on, чтобы нам не приходилось где-то хранить в Gramax каталог этих сотрудников и чтобы им не приходилось отдельно как-то заходить в нашу систему. Мы к этому серверу Gramax подключаем single sign-on компании и все ходят под одним паролем во все системы компании.

Владимир Юсупов: Можно сказать, что твой вариант, который ты нарисовала в Figma, в принципе, можно реализовать для тебя, да?

Екатерина Павлова: Да, именно так.

Владимир Юсупов: Катя, ты сказала про планы на будущее относительно ИИ-помощника. Ещё есть какие-то планы по развитию функциональности помимо помощника?

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

Какая проблема есть. Например, при работе в Word или какой-то другой системе, как правило, ты видишь какие-то предыдущие версии и видишь статью либо документ в состоянии сейчас. Чтобы сравнить, например, версию сейчас с версией 5 дней назад, я один раз пользовалась этим сравнением в Word. У меня умер компьютер. Я очень сильно тогда загрустила. Использование GitHub, который лежит в основе архитектуры Gramax, позволяет выводить подробный diff, то есть подробное сравнение изменений в разных разрезах между разными версиями одного документа и между разными версиями всего каталога. Мы хотим, чтобы любое согласование изменений было легким, быстрым и удобным, чтобы автор внес изменения в несколько статей, отправил на ревью, например, своему руководителю. Руководитель открыл этот запрос, увидел, что эти три статьи в каталоге поменялись, вот конкретно в них изменились эти абзацы, эти картинки, чтобы он не искал, что там писатель поменял, а сразу просмотрел это и подтвердил, либо оставил комментарий. Когда я захожу в каталог, я хочу увидеть, что, например, за неделю, пока я была в отпуске, там поменялось. Чтобы Gramax удобно и красиво подсвечивал все изменения и выводил их в понятном виде.

И если не говорить о конкретных фичах, а скорее, о моих микроцелях. Сейчас я, наверное, сказала о целях глобальных для Gramax, то есть это и автоматизация, это удобная работа с изменениями. Моя микроцель, она такая шутливая, но она очень реальная. Раньше, когда я задавала кому-то вообще вопрос: «Знаешь ли ты про Gramax?», то очень часто слышала ответ: «Нет, не знаю». Сейчас картинка поменялась. На конференциях, на митапах и просто в переписках я задаю также этот вопрос «Знаешь ли ты про Gramax?» и мне уже отвечают: «Да, знаю, но не пробовал что-то вот такое». И я очень хочу, чтобы, задавая этот вопрос, я слышала ответ: «Да, знаю. Да, использую». Мне кажется, это очень важно сейчас и для развития продукта, и для продвижения нашей концептуальной идеи про удобную работу с документацией. И очень жду, когда я, наконец, этой цели достигну.

Владимир Юсупов: Катя, в одном из своих недавних постов ты написала, что если возникнут какие-то вопросы по работе с Gramax, то с тобой можно созвониться и обсудить вопросы. Это действительно так?

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

Владимир Юсупов: Если позволишь, на странице этого выпуска укажем твои контакты.

Екатерина Павлова: Конечно.

Владимир Юсупов: Хорошо. Катя, если честно, у меня еще два листа с вопросами лежат, но мы с тобой по таймингу договорились ранее, так что не буду тебя задерживать. Благодарю тебя, что нашла свободное время в твоем плотном графике для сегодняшней беседы. Желаю тебе успехов в твоей интересной работе, а также твоему продукту, который ты сейчас растишь, развиваешь. Спасибо, Катя.

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

Владимир Юсупов: С удовольствием продолжу общение. Большое тебе спасибо.

Екатерина Павлова: И тебе. Пока-пока.

Владимир Юсупов: Пока-пока.

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

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

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

До встречи!