Чат поддержки

Практикум
Привет! Это поддержка Практикума 👋 Если что-то не получается — постараемся помочь. Пишите в чат или выберите другой способ связи

пт, 2 декабряв 17:21

Мы уже начали заниматься вашим вопросом, ответим в ближайшее время

Практикум

Здравствуйте!

Поддержка не сможет помочь с вопросами, связанными с теорией или задачам из курса «Системный аналитик» — в этой ситуации рекомендуем вам обратиться к вашему преподавателю в чате в Slack.

Если же у вас возникнут иные вопросы — обязательно пишите, будем рады помочь :)

17:24

Выбрать способ связи

Поменять когорту

Перейти в профиль

Выйти из профиля

Добавить аккаунт

Поддержка, обслуживание и оценка результатов

спринт Поддержка, обслуживание и оценка результатов

Рабочая документация

2/2

О чём этот спринт

Документирование по ГОСТ

План миграции

4/4

План миграции

План подготовки кадров

Обучение пользователей

Информация для пользователей

Постпроектная деятельность

1/1

Поддержка и обслуживание системы

Воркшоп и домашнее задание

2/2

Заключение

1/1

Пригласить друзей

Поддержка и обслуживание системы

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

Даня

А у нас будет чат-бот для «Капсулы»? Это же так удобно, я постоянно ими пользуюсь.

Айгуль

Поддержка у системы точно будет. Возможно, и чат-бот!

Даня

Хм, какие ещё варианты поддержки есть?

Айгуль

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

Окей!

Постпроектная деятельность

Тестирование завершено, ПО успешно развёрнуто в рабочей среде. Наступает одна из самых интересных стадий — постпроектная деятельность. Основная её цель — помочь в использовании ПО в тех бизнес-процессах, для которых оно создавалось.

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

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

Поддержка — помощь в использование системы.

Обслуживание — доработка и обновление системы.

Оценка проекта — анализ: что прошло хорошо, а что требует улучшения.

Поддержка системы

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

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

Как загрузить фотографию товара?

Возникает ошибка при попытке совершить заказ вне территории доставки — что делать?

Не работает выгрузка отчётов о продажах для автоматизированной обработки бизнес-аналитики платформой — как их скачать?

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

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

Онлайн-поддержка может включать в себя:

Экраны документации и справки, встроенные в систему.

Часто задаваемые вопросы (Frequently Asked Questions, FAQ).

Чат-боты и системы голосового ответа (VRS).

Рассмотрим подробнее виды поддержки.

Служба поддержки

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

Первый уровень поддержки

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

В поддержку интернет-магазина могут поступать такие обращения первого уровня:

Где мой заказ?

Есть ли возможность отменить уже предоплаченный заказ?

Как можно оставить отзыв о работе службы доставки?

Чаще всего специалисты первого уровня работают по заранее подготовленным простым сценариям.

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

Второй уровень поддержки

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

Служба поддержки второго уровня не работает по шаблону (по готовым сценариям), она глубже разбирается в ПО и анализирует поступающие запросы на системном уровне.

В интернет-магазине в поддержку второго уровня могут поступать такие обращения:

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

У меня дважды списались деньги с банковской карты при оформлении заказа.

Третий уровень поддержки

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

Варианты обращений на третьем уровне поддержки интернет-магазина могут быть следующими:

Система выдаёт ошибку оформления заказа при подключении агрегатора через публичный API.

У клиента не отображается история заказов до 2022 года, когда проводили миграцию данных на новую платформу.

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

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

Как системный аналитик работает со службой поддержки

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

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

Проверяют, действительно ли это ошибка, или нормальное поведение системы.

Оценивают потенциальное влияние ошибки: разовый инцидент или затронет других пользователей.

Анализируют причину ошибки, зачастую вместе с разработчиком.

Создают требование на изменение.

Когда ошибка исправляется, уведомляют команду поддержки.

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

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

Первый уровень поддержки

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

Интеграция со складом через Storage_Update.API приводит к ошибке X0568.

Третий уровень поддержки

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

Я оплатил заказ, произошло списание средств с банковской карты, но статус заказа не изменился.

Второй уровень поддержки

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

Начать заново

Чат-боты

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

Вот какие у чат-ботов есть преимущества:

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

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

Наполнение базы знаний службы поддержки

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

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

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

Ценность базы знаний высока, если специалисты корректно её ведут и постоянно актуализируют. Если документирование поступающих обращений и шагов, предпринимаемых для их решения, ведётся не регулярно и не актуализируется, то ценность базы знаний падает.

Как системный аналитик помогает с базой знаний

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

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

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

Возможные ошибки при авторизации на сайте через сторонние сервисы.

После сдачи проекта системный аналитик может:

Дополнить базу знаний описанием новых функциональностей.

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

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

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

FAQ

Frequently Asked Questions (FAQ) — часто задаваемые вопросы. Они могут дополнять инструкции и руководства пользователя, описывать временные решения или обходные пути для известных ошибок, которые пока не устранены.

FAQ может быть представлен в виде пошаговых инструкций со снимками экрана или текстовых инструкций. Ответы на вопросы должны быть компактными и содержать только необходимую информацию.

Так, например, выглядит FAQ Яндекс Маркета для продавцов услуг:

А вот так выглядит FAQ для продавцов на Avito:

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

Как системный аналитик помогает с наполнением FAQ

Системный аналитик может привлекаться к созданию FAQ. Он должен провести анализ вопросов пользователей, определить сценарии использования, выполнить юзабилити-тесты и собрать варианты решения, предоставленные службой поддержки.

Определите, к чему относится то или иное утверждение: к базе знаний или FAQ.

База знаний

Ключевой инструмент службы поддержки

Ключевой инструмент службы поддержки

Системный аналитик заполняет как во время проекта, так и после его выпуска

Системный аналитик заполняет как во время проекта, так и после его выпуска

Дополняется по мере выпуска новых версий ПО

Дополняется по мере выпуска новых версий ПО

FAQ

Публичный инструмент, содержащий информацию по часто задаваемым вопросам

Публичный инструмент, содержащий информацию по часто задаваемым вопросам

Обновляется по мере выпуска новых версий ПО

Обновляется по мере выпуска новых версий ПО

Системный аналитик помогает с наполнением после выпуска проекта

Системный аналитик помогает с наполнением после выпуска проекта

Проверить
Правильных ответов: 6, неправильных ответов: 0.
Ответить повторно

Даня

Мы же будем что-то менять в системе, если получим негативные отзывы?

Айгуль

Конечно! И, кстати, дело не только в отзывах.

Подробнее об обслуживании системы

Обслуживание системы

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

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

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

Источники запросов на изменение

Можно выделить пять источников запросов на изменения.

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

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

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

Улучшения
Второй наиболее распространённый источник запросов на изменение — усовершенствования системы. Когда пользователи работают с системой, они часто замечают моменты, которые могут упростить использование системы (например, оптимизация экранного пространства), или предъявляют новые требования. Усовершенствованиям часто отдаётся второй приоритет после исправления ошибок.

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

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

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

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

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

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

Соотнесите формулировку запроса на изменение с его источником.

Многие пользователи не могут авторизоваться в приложении после установки его последнего обновления.

Инцидент

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

Склад планирует изменить формат хранимых данных товаров.

Другой проект

Формат хранимых данных товаров может повлиять на интеграцию со складом, следовательно, это влияние другого проекта.

Пользователи хотят видеть предполагаемую дату доставки товара в личном кабинете.

Улучшение

Это запрос пользователей на улучшение системы.

11-я версия PostgreSQL снимается с поддержки в ноябре 2023 года.

Изменение ПО или сетей, используемых системой

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

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

Организационное изменение

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

Начать заново

Процесс обслуживания

В общем виде процесс обслуживания выглядит следующим образом.

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

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

Запросу на изменение присваивается приоритет.

Затем системный аналитик выполняет анализ, который может включать опрос пользователей.

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

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

Выберите ситуации, которые могут привести к изменениям в системе.

Пользователь забыл пароль и не может войти в систему.

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

Правильный ответ

Компания планирует расширить работу с поставщиками и ввести новые категории продаваемых товаров.

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

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

Этот отзыв пользователей не может быть исправлен изменением в системе.

Нескольким пользователем не нравится, как выглядит корзина товаров.

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

Неправильный ответ

Вышла новая версия платформы для разработки веб-приложений.

Новая версия платформы для разработки не является основанием для изменения в системе.

Тоже правильный ответ

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

Это потенциальное улучшение, значит, может привести к изменениям в системе.

Подведём итоги

В этом уроке вы узнали, как осуществляется постпроектное сопровождение системы.

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

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

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

Обслуживание системы — это процесс доработки системы согласно новым или обновлённым бизнес-требованиям.

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

К следующей теме

Курсы

Вводный модуль

Понимание профессии системного аналитика

Разработка требований

Проект 1. Спецификация требований ко второму релизу Chatty

SQL для аналитиков

Моделирование данных

Проект 2. Моделирование данных и работа с базой данных интернет-магазина «Накарабине»

Моделирование процессов

Пользовательские интерфейсы

Agile-практики

Проект 3. Бэклог приложения для сети клиник «Вита»

Трудоустройство

Архитектура системы

Программные интерфейсы

Проект 4

Реализация системы

Поддержка, обслуживание и оценка результатов

Дипломный проект

Дополнительные материалы

x

Draggable item. Ensure your screen reader is not in browse mode and then press space bar to lift.