{ "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:\/\/www.vitalyfilatov.ru\/tags\/vtb\/", "feed_url": "https:\/\/www.vitalyfilatov.ru\/tags\/vtb\/json\/", "icon": "https:\/\/www.vitalyfilatov.ru\/user\/userpic@2x.jpg?1613163987", "author": { "name": "Виталий Филатов", "url": "https:\/\/www.vitalyfilatov.ru\/", "avatar": "https:\/\/www.vitalyfilatov.ru\/user\/userpic@2x.jpg?1613163987" }, "items": [ { "id": "104", "url": "https:\/\/www.vitalyfilatov.ru\/all\/status-model\/", "title": "Упрощаем набор статусов статьи", "content_html": "

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

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

Контекст и задача<\/h2>\n

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

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

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

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

Немного теории<\/h2>\n

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

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

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

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

\n

Хорошую статусную модель пользователь понимает интуитивно<\/p>\n<\/blockquote>\n

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

Решение<\/h2>\n

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

\n\"\"\n
Если видимость сделать параметром, отдельные статусы для включения и выключения не понадобятся<\/div>\n<\/div>\n

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

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

\n\"\"\n
Фрагмент условного интерфейса админки со списком публикуемых статей<\/div>\n<\/div>\n

Аналитику такое решение показалось непривычным и избыточным, мнения разделились. К счастью, пока мы спорили, публикацию статей удалось отвязать от релизного цикла, и набор статусов упростился сам собой.<\/p>\n", "date_published": "2026-05-06T17:06:57+05:00", "date_modified": "2026-05-08T17:56:02+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/092-complex-model@2x.png", "_date_published_rfc2822": "Wed, 06 May 2026 17:06:57 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "104", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/092-complex-model@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/092-simple-model@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/092-articles-lists@2x.png" ] } }, { "id": "103", "url": "https:\/\/www.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:\/\/www.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:\/\/www.vitalyfilatov.ru\/pictures\/091-pivot-table@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-comments@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-tinypng@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-obsidian@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-editor-nodes@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-editor-html@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-trello-dashboard@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-trello-release@2x.png" ] } }, { "id": "91", "url": "https:\/\/www.vitalyfilatov.ru\/all\/vtb-faq-vacancy\/", "title": "Вакансия редактора Помощи в ВТБ Бизнес (АРХИВ)", "content_html": "

      Вакансия закрыта, но я оставлю её текст на память :3<\/i><\/p>\n

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

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

      Помощь ВТБ Бизнес<\/a><\/p>\n

      Кто нужен<\/h2>\n

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

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

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

      Пригодится знание основ JQL и регулярных выражений.<\/p>\n

      Что нужно делать<\/h2>\n

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

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

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

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

      Как выстроен процесс<\/h2>\n

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

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

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

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

      По деньгам и условиям<\/h2>\n

      Платят нормально, но сумма обговаривается индивидуально.<\/p>\n

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

      Как откликнуться<\/h2>\n

      Напишите руководителю команды Помощи Александру в телеграм: тут была ссылка<\/i><\/p>\n", "date_published": "2023-03-24T20:25:47+05:00", "date_modified": "2023-12-26T21:18:25+05:00", "_date_published_rfc2822": "Fri, 24 Mar 2023 20:25:47 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "91", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "79", "url": "https:\/\/www.vitalyfilatov.ru\/all\/call-center-sms\/", "title": "СМС с рекламой сервиса", "content_html": "

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

      TLDR. 860 слов о том, как написать 200 символов.<\/p>\n

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

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

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

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

      \n

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

      \n

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

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

      Очевидно, что текст можно сделать короче, а сценарий точнее.<\/p>\n

      Задача<\/h2>\n

      Колл-центр редактуру не заказывал, так что поставим задачу сами.<\/p>\n

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

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

        Сценарий<\/h2>\n

        Проблемы первоначального сценария:<\/p>\n