Вернуться в раздел Новости
Из-за этого может складываться впечатление, что техподдержка бесполезна. Олег Жигалов, технический директор и руководитель Департамента информационных технологий «Р7-Офис», рассказал о пяти популярных мифах, связанных с техподдержкой, и о том, как она работает в IT-компании на самом деле.
В техподдержке работают люди, которые только принимают обращения
Иногда пользователи думают, что техподдержка — это только специалисты на другом конце телефона или электронной почты. Основная их задача — принимать обращения и помогать разобраться с продуктом пользователю. В реальности всё гораздо сложнее. Например, в нашей компании департамент информационных технологий состоит из нескольких подразделений: инженеров, тестировщиков, аналитиков и проектного офиса.
Инженеры занимаются разработкой высоконагруженных архитектур и обслуживанием клиентов повышенной сложности. Тестировщики — тестированием программ, которые мы получаем от разработчиков. Это как технологические альфа- и бета-сборки, так и продукты уровня RC (релиз-кандидаты). Они используют в том числе ручные технологии тестирования, проводят нагрузочные испытания. Применяют специализированные стенды, которые разрабатывают наши инженеры совместно с тестировщиками. На них проводят highload-испытания.
Аналитики классифицируют заявки: тикеты на исправление ошибок не должны перемешиваться с заявками на добавление нового функционала. Они устанавливают приоритет для каждой заявки. Важно понимать, на каких крупных клиентов может оказать эффект та или иная заявка, с какой частотой спрашивают об изменении той или иной функции и какое количество пользователей предлагаемые изменения затронут. В результате специалисты формируют список самых актуальных запросов, который после обсуждения становится следующим пулом доработок.
Техподдержка не влияет на разработку IT-продукта
Это один из самых популярных мифов. На самом деле техподдержка напрямую влияет на IT-продукт. Не будь техподдержки, разработчики не получали бы «с полей» обратную связь от клиентов, которые помогают выяснить, что надо улучшить в продукте.
Именно «в полях» встречаются экзотические сценарии использования программных продуктов, которые проектировщики на этапе разработки не могли себе даже представить. Без технической поддержки ресурс разработки неоправданно расходовался бы на воспроизведение ошибок в конкретной инфраструктуре. А у нас эта задача лежит на технической поддержке, и разработчикам передаётся уже структурированная диагностика.
Именно техподдержка даёт разработчикам основное направление для работы в плане развития нефункциональных характеристик продукта. В нашей компании эту задачу выполняют аналитики, которые должны понимать, на каких клиентов может оказать эффект конкретная заявка, какие ключевые клиенты и с какой частотой спрашивают об изменении той или иной функции. На выходе формируется перечень, который после обсуждения включается в план доработок.
Обработка заявок от клиентов — один из основных двигателей в принятии решения о плане работы по нашим продуктам. Например, недавно по запросу клиента в один наш продукт добавили механизм, который позволяет взаимодействовать с Exchange-сервером по нативному протоколу Exchange Web Services (EWS). Эта доработка была бы невозможна без участия техподдержки наряду с разработчиками инженера, который в свое время «собаку съел» на Exchange, и тестировщиков, которые разобрались, как протокол работает.
Именно техподдержка даёт разработчикам основное направление для работы в плане развития нефункциональных характеристик продукта. В нашей компании эту задачу выполняют аналитики, которые должны понимать, на каких клиентов может оказать эффект конкретная заявка, какие ключевые клиенты и с какой частотой спрашивают об изменении той или иной функции. На выходе формируется перечень, который после обсуждения включается в план доработок.
Обработка заявок от клиентов — один из основных двигателей в принятии решения о плане работы по нашим продуктам. Например, недавно по запросу клиента в один наш продукт добавили механизм, который позволяет взаимодействовать с Exchange-сервером по нативному протоколу Exchange Web Services (EWS). Эта доработка была бы невозможна без участия техподдержки наряду с разработчиками инженера, который в свое время «собаку съел» на Exchange, и тестировщиков, которые разобрались, как протокол работает.
Самое частое обращение пользователей — жалобы на IT-продукт
На практике это не так. Самое популярное обращение — запрос на консультацию. Спрашивают о том, что прописано в справке, которую пользователям лень читать. Например, куда скопировать лицензию, как написать скрипт и так далее. Следом по популярности — запросы по поводу инцидентов и запросы на доработку. Здесь речь идёт в том числе о дефектах и багах: нашли что-то, что работает не так, как заявлено, или не так, как предполагали пользователи, исходя из своего опыта работы с другими продуктами. Далее по популярности — пожелания к расширению функционала. И лишь на последнем месте — жалобы.
Как и везде, иногда сталкиваемся с не всегда обоснованными замечаниями по функционалу. Например, пользователь в текстовом редакторе копирует из браузера или из другого документа текст. Он зелёного цвета, и когда вставляешь скопированное в наш редактор, он остаётся зеленым, но появляется окошко, где доступен пункт «отменить форматирование». В Microsoft Office было ровно то же самое, но в обратном порядке: сначала пользователь выбирает, хочет ли вставить форматированный или неформатированный текст, а уже потом происходит сама вставка. Итог тот же самый. Количество действий одинаковое. Но пользователь привык делать вот так, поэтому мы получаем замечание.
IT-компании не следят за качеством работы техподдержки
И это тоже миф. Мониторинг качества работы необходим. И он ведётся: например, мы просим клиентов оценить работу специалистов техподдержки. Это примитивный механизм, но он даёт представление о качестве работы сотрудников. Ещё мы работаем над совершенствованием системы мониторинга удовлетворённости клиентов, внедряем дополнительные метрики, проводим опросы.
Важный момент — ответственность. Поскольку участок у нас сложный, халатное отношение к работе недопустимо. Поэтому практикуется принцип двух предупреждений. В том смысле, что третьего не будет. К счастью, мы к этому практические не прибегаем. Как правило, наши сотрудники знают, что они здесь делают, поэтому понимают ответственность и работают с энтузиазмом. Они хорошо мотивированы, но это не результат проведения какой-то определённой политики. Просто тестировщик знает: если он отловил баг, то это будет исправлено. А значит, продукт станет лучше. И в этом его прямой вклад.
Полную версию материала можно посмотреть по ссылке
