{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "Виталий Филатов: заметки с тегом процессы", "_rss_description": "Меня зовут Виталий Филатов. Я коммерческий писатель, помогаю бизнесу рассказывать о себе и продукте. Пишу и редактирую статьи, инструкции, текст сайтов и интерфейсов. Люблю работать в команде с дизайнерами и разработчиками.", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/vitalyfilatov.ru\/tags\/processy\/", "feed_url": "https:\/\/vitalyfilatov.ru\/tags\/processy\/json\/", "icon": "https:\/\/vitalyfilatov.ru\/user\/userpic@2x.jpg?1613163987", "author": { "name": "Виталий Филатов", "url": "https:\/\/vitalyfilatov.ru\/", "avatar": "https:\/\/vitalyfilatov.ru\/user\/userpic@2x.jpg?1613163987" }, "items": [ { "id": "103", "url": "https:\/\/vitalyfilatov.ru\/all\/vtb-help\/", "title": "Редакционные процессы Помощи ВТБ Бизнеса", "content_html": "

История о том, как рерайт статей превратился в реорганизацию процессов производства.<\/p>\n

Ситуация и задача<\/h2>\n

В 2020 году ВТБ открыл интернет-банк для малого и среднего бизнеса — ВТБ Бизнес. Он служил витриной для уже существовавших банковских продуктов, которые вели автономные команды — СУБО. Такая архитектура не предусматривала единой языковой службы, да и мода на большие редакции до банка ещё не добралась. В команде платформы уже был редактор, но он занимался в основном задачами маркетинга, а статьи для справочного раздела каждое команда-СУБО писала сама.<\/p>\n

Статьи публиковались в сервисе «Помощь»<\/a>, который вела специальная команда внутренних сервисов. Руководителя этой команды беспокоило неравномерное качество этих статей, и он решил нанять второго редактора, переписывать за бизнес-аналитиками и наводить красоту. Так в команде Помощи появился я.<\/p>\n

На момент моего появления работа была организована так:<\/p>\n

    \n
  1. Каждое СУБО отвечало за свои статьи и никого к себе не пускало. Аналитики и юристы не умели писать пользовательские инструкции, поэтому ограничивались односложными ответами на частые вопросы, а стиль и глубина изложения сильно отличались.<\/li>\n
  2. Исходники статей хранились в эксель-таблицах у каждого СУБО. Авторы сами делали иллюстрации из скриншотов на тестовом сервере и заливали в общее облако.<\/li>\n
  3. Когда нужно было что-то изменить или добавить, бизнес-аналитик СУБО правил свою таблицу, выделял изменения цветом и присылал новый файл по почте команде Помощи.<\/li>\n
  4. Там текст из файла вставляли в базу данных и выкатывали на прод с общим релизом.<\/li>\n<\/ol>\n

    Процесс получался хаотичным: версии статей не отслеживали, файлы таблиц дублировались, актуальные правки терялись, картинки разных СУБО перетирали друг друга из-за совпадающих имён. Оперативно выложить что-то было невозможно из-за релизной политики, поэтому иногда статьи успевали обновиться несколько раз до релиза и окончательно всех запутать.<\/p>\n

    Чтобы упорядочить процесс, команда Помощи написала специальную админку с визуальным редактором, где авторы смогли бы работать со статьями без посредников. Но качество от этого не росло, а править и согласовывать текст в админке было так же муторно, как и в эксель-таблицах. Так что я составил план, заручился поддержкой команды и переделал сам подход к производству.<\/p>\n

    Работа с материалами<\/h2>\n

    Первым делом я убедил команду, что писать статьи и следить за структурой разделов нужно нам самим, а СУБО оставить только сбор фактуры, обновление макетов и согласование. Уже опубликованные статьи мы решили постепенно переписать по мере изменений в продуктах.<\/p>\n

    СУБО не обрадовались потере контроля, но после нескольких согласованных статей они обычно убеждались, что редактор бережно передаёт смысл, начинали доверять и охотнее рассказывать о бизнес-логике и нюансах.<\/p>\n

    Мы перенесли все статьи в гугл-доки<\/b>, а ссылки на них и служебную информацию собрали в сводной гугл-таблице. Таблица решала две задачи: хранила статьи со статусами и служила функциональным прототипом для следующих версий админки Помощи.<\/p>\n

    \n\"\"\n
    Сводная таблица — сердце системы контента. Там мы хранили все статьи, включая снятые с публикации, отменённые и удалённые. Вся таблица в гигантском PNG<\/a>, 2 Мб<\/div>\n<\/div>\n

    В первой версии админки не было инструментов согласования, поэтому их заменяли гугл-доки. Мы гибко настраивали доступы, вели архив версий, принимали и согласовывали правки. Особый шик давала совместная работа: на сложных согласованиях я приглашал всех следить за моим курсором в документе и правил текст прямо во время звонка, без расшаривания экрана.<\/p>\n

    Гугл-доки помогали и в вёрстке. Я подогнал шаблон статьи максимально близко к дизайну прода и при редактировании сразу видел примерную форму абзацев и переносы строк.<\/p>\n

    \n\"\"\n
    Аналитики и юристы могли комментировать исходники в любое время, я оперативно разбирал правки и публиковал обновления с ближайшим релизом<\/div>\n<\/div>\n

    Далее мы убрали автогенерацию слагов<\/b> — уникальных частей в URL-адресах статей. Первоначально слаг создавался транслитерацией заголовка, но адреса получались длинными и нечитаемыми. Я предложил составлять слаги силами редактора, чтобы адреса получались понятнее, умещались в СМС и не разрывали сообщения чат-бота.<\/p>\n

    \n

    Срок действия дополнительных опций к пакетам услуг
    \n↓
    \ndb.vtb.ru\/faq\/answers\/srok-dejstviya-dopolnitelnyh-opcij-k-paketam-uslug<\/b>
    \n↓
    \ndb.vtb.ru\/faq\/answers\/srok-dop-optsii<\/b><\/p>\n<\/blockquote>\n

    Уникальностью слагов отслеживали по сводной таблице и проверке на дубли в админке.<\/p>\n

    Поскольку слаги менялись крайне редко, я включил их в имена файлов иллюстраций. Такие имена не повторялись, и по ним можно было фильтровать файлы в хранилище. Папки в облаке также назывались слагом статьи.<\/p>\n

    \n\"\"\n
    Имена файлов упрощали рутину. Например, пожав пачку картинок в тинифаере, я сразу знал, куда сохранять архив с результатом<\/div>\n<\/div>\n

    Перешли со скриншотов интерфейса на макеты в Фигме<\/b>. Пришлось искать подход к дизайнерам СУБО и убеждать их обновлять макеты к релизам, но оно того стоило. Иллюстрации стали чище и консистентнее, а их исходники были всегда доступны. Но главное — мы смогли показывать все нужные состояния интерфейса, а не только те, что получалось поймать на тестовом сервере.<\/p>\n

    Сначала я готовил иллюстрации сам, чтобы изучить нюансы и сформулировать правила. Позже собрал всё в гайд для дизайнеров, и они начали мне помогать.<\/p>\n

    Гайд по изображениям для статей Помощи<\/a> получился наглядным: все картинки в нём собраны по требованиям гайда, чтобы читатель сразу видел образец.<\/p>\n

    Создали наглядный прототип в Обсидиане<\/b>, где отслеживали структуру каталогов, связи между статьями, выпавшие иллюстрации и ссылки на файлы. Чтобы не делать это руками после каждого крупного обновления, я собрал требования, а аналитик Евгений написал скрипт на Питоне.<\/p>\n

    \n\"\"\n
    Граф опубликованных статей в Обсидиане. Красные точки — страницы категорий, оранжевые — статьи с перекрёстными ссылками, а зелёные — с файлами для скачивания<\/div>\n<\/div>\n

    Публикация статей<\/h2>\n

    Админка Помощи задумывалась не для редакторов, поэтому за основу команда взяла визуальный редактор на контейнерах — как в Ноушене. Но он не умел работать в режиме исходного кода — HTML или маркдауна.<\/p>\n

    Необходимость настраивать оформление вручную ломала мой отработанный процесс: на других проектах я целиком копировал гугл-док и прогонял текст через Драйзер<\/a> — самописный скрипт на регулярках. Скрипт вырезал инлайн-стили и служебные блоки, оставляя чистый HTML. Так я мог заряжать в админку по статье в минуту.<\/p>\n

    Менять редактор было поздно, но разработчики нашли остроумное решение: добавили переключатель, который скрывал все контейнеры и показывал поле для HTML-кода.<\/p>\n

    \n
    \n\"\"\n\"\"\n<\/div>\n
    Редактирование статьи в обычном и экспертном режимах. В ранних версиях админки статья называлась вопросом, так уж вышло<\/div>\n<\/div>\n

    Мы выбрали HTML, а не в маркдаун, чтобы как можно меньше переписывать админку. Я всё равно получал готовый код из гугл-дока и сразу типографил текст своими скриптами.<\/p>\n

    Ещё я поучаствовал в разработке админки: тестировал механики, писал текст интерфейса, подменял дизайнера, надоедал всем нормами типографики и спорил с бизнес-аналитиком из-за статусной модели<\/a> :3<\/p>\n

    Работа с СУБО<\/h2>\n

    Сначала в Помощи публиковались 10 команд, но позже их стало уже 35. Они постоянно что-то меняли, уследить за всем было невозможно. Поэтому мы договорились, что за актуальностью своих статей СУБО следят сами, а команда Помощи отвечает за подготовку и публикацию.<\/p>\n

    Процесс добавления новой статьи выглядел так:<\/p>\n

      \n
    1. В СУБО назначали ответственного за процесс и обновляли макеты.<\/li>\n
    2. Ответственный заполнял бриф на новую статью<\/a>, в котором указывал тему, полезное действие, примерный план, ссылки на макеты и документацию.<\/li>\n
    3. Я принимал заявку, изучал материалы и предметную область, задавал вопросы аналитикам и дизайнерам, просил показать продукт в работе.<\/li>\n
    4. Собрав всю фактуру, я писал черновик и готовил иллюстрации по макетам.<\/li>\n
    5. Ответственный вычитывал и комментировал черновик, я дописывал нужное, и всё повторялось, пока статья не была готова.<\/li>\n
    6. Согласованную статью я добавлял в админку, помечал готовой к публикации и закрывал задачу.<\/li>\n<\/ol>\n

      Чтобы изменить уже опубликованную статью, ответственный просто правил копию исходника и передавал мне. А чтобы не тонуть в бюрократии, мелкие правки мы вносили без задачи в Джире, просто по переписке в мессенджере.<\/p>\n

      Задачи шли потоком, мы постоянно что-то правили, обновляли, поддерживали порядок и готовили пачки новых статей к релизам. Отслеживать всё в Джире не получалось, поэтому я завёл редакционный дашборд в Трелло.<\/p>\n

      \n\"\"\n
      Объём задачи в карточке мог быть любым, от мелкой правки до десятка статей<\/div>\n<\/div>\n

      Карточка с задачами типичного релиза выглядела так:<\/p>\n

      \n\"\"\n
      Обновляем 77 статей: добавляем новые, объединяем старые, правим опечатки, заменяем иллюстрации со старым интерфейсом<\/div>\n<\/div>\n

      Итоги<\/h2>\n

      Настроив процессы, мы занялись обычной текучкой: писали новые статьи, обновляли старые, изучали обратную связь от пользователей и операторов горячей линии, следили за обращениями в поддержку и метриками сервиса.<\/p>\n

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

      Но статей становилось всё больше, а задач на UX-редактуру не прибавлялось, так что я решил заняться Умным домом в МТС. А чтобы проект было легче передать, собрал материалы, записал скринкасты с основными процессами и составил вакансию редактора Помощи<\/a>.<\/p>\n

      К сожалению, вскоре в компании изменилась политика информационной безопасности, внешние облачные сервисы запретили и отбить гугл-доки не удалось. Исходники статей переехали в корпоративную вики, и процессы вновь пришлось менять.<\/p>\n

      Благодарности<\/h2>\n

      Спасибо команде Помощи за понимание, поддержку и вовлечённость. Вы с готовностью вникали во все мои идеи, хоть иногда я не особо выбирал выражения. С вами я получил бесценный опыт — как быть частью команды и находить продуктивное решение.<\/p>\n

      «Хороших выходных. И ведите себя плохо!» ©<\/p>\n", "date_published": "2026-03-23T11:51:11+05:00", "date_modified": "2026-05-06T17:22:18+05:00", "image": "https:\/\/vitalyfilatov.ru\/pictures\/091-pivot-table@2x.png", "_date_published_rfc2822": "Mon, 23 Mar 2026 11:51:11 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "103", "_e2_data": { "is_favourite": false, "links_required": [ "system\/library\/jquery\/jquery.js", "system\/library\/fotorama\/fotorama.css", "system\/library\/fotorama\/fotorama.js" ], "og_images": [ "https:\/\/vitalyfilatov.ru\/pictures\/091-pivot-table@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-comments@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-tinypng@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-obsidian@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-editor-nodes@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-editor-html@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-trello-dashboard@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-trello-release@2x.png" ] } } ], "_e2_version": 3877, "_e2_ua_string": "E2 (v3877; Aegea)" }