«Ваша заявка принята»: 5 мифов о техподдержке в IT

В техподдержке работают люди, которые только принимают обращения

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

Инженеры занимаются разработкой высоконагруженных архитектур и обслуживанием клиентов повышенной сложности. Тестировщики — тестированием программ, которые мы получаем от разработчиков. Это как технологические альфа- и бета-сборки, так и продукты уровня RC (релиз-кандидаты). Они используют в том числе ручные технологии тестирования, проводят нагрузочные испытания. Применяют специализированные стенды, которые разрабатывают наши инженеры совместно с тестировщиками. На них проводят highload-испытания.

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

Техподдержка не влияет на разработку IT-продукта

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

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

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

Обработка заявок от клиентов — один из основных двигателей в принятии решения о плане работы по нашим продуктам. Например, недавно по запросу клиента в один наш продукт добавили механизм, который позволяет взаимодействовать с Exchange-сервером по нативному протоколу Exchange Web Services (EWS). Эта доработка была бы невозможна без участия техподдержки наряду с разработчиками инженера, который в свое время «собаку съел» на Exchange, и тестировщиков, которые разобрались, как протокол работает.

По теме. Айтишники теперь гуманитарии? Как ИИ изменил агентский рынок

Самое частое обращение пользователей — жалобы на IT-продукт

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

Как и везде, иногда сталкиваемся с не всегда обоснованными замечаниями по функционалу. Например, пользователь в текстовом редакторе копирует из браузера или из другого документа текст. Он зелёного цвета, и когда вставляешь скопированное в наш редактор, он остаётся зеленым, но появляется окошко, где доступен пункт «отменить форматирование». В Microsoft Office было ровно то же самое, но в обратном порядке: сначала пользователь выбирает, хочет ли вставить форматированный или неформатированный текст, а уже потом происходит сама вставка. Итог тот же самый. Количество действий одинаковое. Но пользователь привык делать вот так, поэтому мы получаем замечание.

По теме. Работать с негативом клиентов так, чтобы потом он работал на вас

IT-компании не следят за качеством работы техподдержки 

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

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

По теме. Возможен ли бизнес на отношениях, если 95% продаж холодные

Если пользователи ставят плохие оценки, это значит, что техподдержка не работает

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

Фото на обложке: Freepik