Виталий Филатов: заметки с тегом ВТБ

Упрощаем набор статусов статьи

Виталий Филатов — Wed, 06 May 2026 17:06:57 +0500

Ещё один частный случай с высокими абстракциями. На этот раз на примере статусов статьи в админке Помощи ВТБ Бизнеса из прошлой статьи.

TLDR. Сперва модель статусов отражала серверную логику, отчего жизненный цикл статьи выглядел сложно. Мы вынесли один из статусов в параметр, и стало попроще, но не всем понравилось.

Контекст и задача

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

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

Статусная модель статьи в админке. Если не сохранять изменения, статья возвращается в предыдущее состояние. Статью нельзя стразу опубликовать скрытой, но почему — уже не помню

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

Немного теории

Статусная модель описывает жизненный цикл сущностей, с которыми работает пользователь: заказы, посылки, статьи. Модель объясняет, в каких состояниях объекты могут находиться и по каким правилам переходят из одного в другое.

Редакторам статусная модель интересна тем, что в ней пересекаются миры разработчиков и пользователей.

Для разработчика статусная модель — это модель жизненного цикла объекта данных, она показывает логику работы программы. За прямоугольниками на схеме разработчик видит программный код, схемы баз данных и текст запросов к ним.

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

Хорошую статусную модель пользователь понимает интуитивно

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

Решение

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

Если видимость сделать параметром, отдельные статусы для включения и выключения не понадобятся

По этой же логике можно было бы вынести в параметры и удаление, но его решили оставить отдельным статусом для удобства. Кнопка «Удалить» перемещала статью в статус «Удаляем» и заменялась на «Отменить удаление».

В интерфейсе я предложил вынести статьи к релизу в отдельную вкладку и показывать там не статусы, а описание изменений.

Фрагмент условного интерфейса админки со списком публикуемых статей

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

Редакционные процессы Помощи ВТБ Бизнеса

Виталий Филатов — Mon, 23 Mar 2026 11:51:11 +0500

История о том, как рерайт статей превратился в реорганизацию процессов производства.

Ситуация и задача

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

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

На момент моего появления работа была организована так:

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

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

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

Работа с материалами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публикация статей

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

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

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

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

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

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

Работа с СУБО

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

Процесс добавления новой статьи выглядел так:

В СУБО назначали ответственного за процесс и обновляли макеты.
Ответственный заполнял бриф на новую статью, в котором указывал тему, полезное действие, примерный план, ссылки на макеты и документацию.
Я принимал заявку, изучал материалы и предметную область, задавал вопросы аналитикам и дизайнерам, просил показать продукт в работе.
Собрав всю фактуру, я писал черновик и готовил иллюстрации по макетам.
Ответственный вычитывал и комментировал черновик, я дописывал нужное, и всё повторялось, пока статья не была готова.
Согласованную статью я добавлял в админку, помечал готовой к публикации и закрывал задачу.

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

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

Объём задачи в карточке мог быть любым, от мелкой правки до десятка статей

Карточка с задачами типичного релиза выглядела так:

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

Итоги

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

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

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

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

Благодарности

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

«Хороших выходных. И ведите себя плохо!» ©

Вакансия редактора Помощи в ВТБ Бизнес (АРХИВ)

Виталий Филатов — Fri, 24 Mar 2023 20:25:47 +0500

Вакансия закрыта, но я оставлю её текст на память :3

Ищу себе замену. Покажите друзьям, если они пишут и хотели бы поработать в банке.

ВТБ Бизнес — подразделение банка ВТБ для малого и среднего бизнеса. У банка есть справочный раздел со статьями для пользователей, вот его и нужно будет вести.

Помощь ВТБ Бизнес

Кто нужен

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

Требуются инфостиль, docx, гугл-доки, база Фигмы и HTML.

Хорошо, если вы любите писать инструкции, не боитесь бюрократии и умеете разговаривать с юристами и дизайнерами.

Пригодится знание основ JQL и регулярных выражений.

Что нужно делать

Редактировать статьи на основе черновиков продуктовых команд, делать из их макетов иллюстрации к статьям и готовить всё к публикации. Иногда нужно писать новые статьи, иногда дополнять старые или находить удалять неактуальные.

Ещё нужно сопровождать редакционные процессы, вести внутреннюю несложную документацию, обновлять регламенты и инструкции для участников.

Периодически нужно смотреть отзывы пользователей и статистику посещений, обновлять структуру разделов и всячески развивать сервис внутри и снаружи.

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

Как выстроен процесс

Банковских продуктов под три десятка и прямого доступа у редактора к ним нет. Каждым продуктом занимается своя команда. Эти команды автономны, у них свои приоритеты и задачи, писать статьи в Помощь им некогда, но черновики, макеты и экспертизу они чаще всего дают.

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

Процесс описан в инструкциях, команда Помощи дружелюбная, ответственные за статьи со стороны продуктовых команд тоже контактные и заинтересованные в процессе.

Полноценной редполитики и ToV у сервиса нет, придётся ориентироваться на готовые статьи и заметки прежнего редактора. Зато есть гайд по иллюстрациям для дизайнеров.

По деньгам и условиям

Платят нормально, но сумма обговаривается индивидуально.

В остальном — как в любой большой компании: рабочий ноутбук, ДМС и фултайм по московскому времени.

Как откликнуться

Напишите руководителю команды Помощи Александру в телеграм: тут была ссылка

СМС с рекламой сервиса

Виталий Филатов — Sun, 13 Feb 2022 01:28:16 +0500

Немного редакторского процесса на примере СМС колл-центра. Вникаем в задачу, упрощаем сценарий и пишем текст под особенности формата.

TLDR. 860 слов о том, как написать 200 символов.

Скриншот результата в мокапе iPhone SE. Для фотографии мой телефон слишком потёрт :3

Ситуация

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

Чтобы клиенты чаще искали ответы сами, колл-центр решил отправлять им СМС с рекламой чат-бота и Помощи ВТБ Бизнес. Вот оригинал:

Переходите по ссылке https://db.vtb.ru/faq в раздел «Помощь». Здесь вы найдете много полезной информации по правилам работы Интернет банка ВТБ Бизнес. Еще у нас есть чат-бот, который подскажет ответы на самые актуальные вопросы.

Чат-бот живет в правом нижнем углу экрана https://db.vtb.ru под названием «Чат». Особенно хорошо чат-бот разбирается в вопросах входа в систему. Напишите ему Ваш вопрос, он расскажет план действий.

Оператор будет отправлять это сообщение после консультаций, если у клиентов нет жестких технических проблем. Но по нескольким вопросам клиенты будут получать по два СМС: сначала ссылку на конкретную статью, а потом рекламу.

Очевидно, что текст можно сделать короче, а сценарий точнее.

Задача

Колл-центр редактуру не заказывал, так что поставим задачу сами.

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

Начнём со сценария, чтобы выстроить предсказуемый контекст. Чем больше мы узнаем о ситуации клиента, тем точнее напишем. Обратное тоже верно: без знания ситуации вместо работы со смыслом получится перестановка слов.

Сценарий

Проблемы первоначального сценария:

не учитываются настроение и суть вопроса клиента;
реклама отправляется при любом вопросе;
иногда клиент получает два похожих СМС.

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

К счастью, операторы вправе решать, что и кому отправлять. Договариваемся, что рекламу шлём при условиях:

вопрос о работе в новом интернет-банке;
оператор посоветовал полезное;
у клиента нет негатива и технических проблем;
клиент ещё не получал рекламу.

Ограничимся одним СМС. Когда отправляем ссылку на конкретную статью, считаем, что клиент оценит пользу Помощи самостоятельно.

Текст

Теперь сценарий формирует предсказуемый контекст и мы знаем о ситуации клиента следующее:

клиент обратился за консультацией, ему все объяснили;
у клиента всё работает, он настроен позитивно;
клиенту наверняка пришлось долго ждать ответа оператора.

Не исключено, что хорошее впечатление от работы оператора клиент распространит на Помощь и чат-бота.

Начнём с позитивного:

Мы рады, что смогли вам помочь!

Сформулируем полезное действие: зачем обращаться к Помощи и чат-боту вместо живого оператора? Например, чтобы не ждать в очереди.

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

Сократим заход про звонки. Нужно быстрее переходить к сути: пока операторы заняты, попробуйте поискать ответ в Помощи.

К сожалению, операторы часто не могут быстро ответить. Если у вас возникнут новые вопросы, посмотрите раздел «Помощь» или спросите у чат-бота.

Уже лучше, но не лаконично. Сократим вступление и допишем остальное.

Надеемся, мы смогли вам помочь!

Наши операторы не всегда могут быстро ответить. Если у вас возникнут новые вопросы, посмотрите раздел «Помощь» или спросите у чат-бота. Мы собрали там много полезного.

Бот открывается по кнопке «Чат» в правом нижнем углу интернет-банка. А раздел «Помощь» располагается по адресу: https://db.vtb.ru/faq

Нормально, но что-то смущает. Вспоминаю, что СМС ограничено 140 байтами. Латинские символы занимают 1 байт, кириллица — 2, поэтому в одном СМС не больше 70 кириллических символов. Длинные сообщения приходят пачкой СМС, которые телефон показывает как одно.

В нашем тексте 333 символа, на 5 сообщений. Если сократим, сэкономим внимание пользователя и деньги банка.

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

Чтобы не ждать на линии, посмотрите «Помощь» (https://db.vtb.ru/faq) или спросите у чат-бота — кнопка «Чат» в правом нижнем углу интернет-банка

Получилось 143 символа, можно ещё сократить, но звучит отрывисто. Хочется естественнее: объяснить причину и выразить отношение, как в разговоре с живым человеком. Попробуем уложиться в три смски.

К сожалению, наши операторы не всегда могут быстро ответить. Чтобы не ждать на линии, посмотрите «Помощь» (https://db.vtb.ru/faq) или спросите у чат-бота — кнопка «Чат» в правом нижнем углу интернет-банка

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

Не всегда быстро отвечают — словно так и устроено

Не всегда могут быстро ответить — может и хотят, но возможности нет

Спорно, но на тот момент ничего лучше не придумал. Пишите в комментариях, что думаете. А пока пойдём дальше.

После сокращения выходит 204 символа. В интернете узнаю, что длинные СМС тарифицируются по 67 символов. Следовательно, нужно не больше 201.

Убираем скобки, всё равно адрес подсветится. Чат-бота назовём просто ботом, там рядом про кнопку «Чат». Останется место написать посмотрите в Помощи вместо смотрите Помощь. Результат на 200 символов:

К сожалению, наши операторы не всегда могут быстро ответить. Чтобы не ждать на линии, посмотрите в «Помощи» https://db.vtb.ru/faq или спросите у бота — кнопка «Чат» в правом нижнем углу интернет-банка

Вариант не без проблем, например, в предпросмотр почти не влезает польза про ожидание на линии. Но в колл-центре текстом оказались довольны и назвали самым красивым из всех 237 шаблонов.

Как ставить ссылки

Виталий Филатов — Sat, 15 Jan 2022 00:45:07 +0500

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

Cвёрстано в Фигме по дизайн-системе банка

ВТБ Бизнес открылся в 2020, а собственные редакторы появились в прошлом году. Пока нас двое. Я слежу за статьями в разделе Помощи и при случае помогаю ведущему редактору.