Чего не стоит делать при проверке технической поддержки продукта?

Категория: Технические советы

– Автор: Игорь (Администратор)

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

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

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

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

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

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

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

И звучат два следующих вопроса:

1. А вот вы объясняли про хостинг и говорили про типы, я вот не совсем понял, чем именно отличаются первые два типа?

2. А можно простыми словами что такое хостинг?

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

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

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

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

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

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

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

Кстати, читатель и сам может вспомнить немало ситуаций, когда к нему приставали с глупыми вопросами и какое это приносило "непередаваемое" удовольствие.

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

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

Рассмотрим простой пример с тем же повествованием перед аудиторией, только теперь зададим два других вопроса, а так же рассмотрим примеры реакции на них.

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

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

Если подходить формально, то с одной стороны, вам может казаться, что во втором случае налицо плохое качество и затягивание сроков. С другой стороны, стоит понимать, что время для вопросов обычно весьма небольшое, к примеру, минут 10-20 или 40 для большой аудитории. Также вы ничего не знаете о рассказчике, поэтому задержка в день-два легко может быть оправданной. Соответственно, с точки зрения оратора, в данной ситуации лучше потратить эти 20 минут, предоставляя другим людям возможность сразу уточнить непонятные для них нюансы в рамках предоставленного материала, чтобы их потраченное время не прошло зря, чем провести эти 20 минут, объясняя совершенно другой материал (к тому же ещё такой, который ещё больше запутывает тех, кто не до конца понял базовые вещи).

Так же рассмотрим одни из вероятных итогов подобных вопросов:

1. В этом случае, человек узнает полезную дополнительную информацию (порой весьма ценную). Убедится в том, что оратор не просто читает по бумажке. Продемонстрирует свою заинтересованность в материале.

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

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

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

Так же вам могут быть интересны обзоры:

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

2. Как техподдержка справляется с неадекватными клиентами?

3. Закулисье технической поддержки: на что обращают внимание?

4. Старые сайты и системы: почему это не так плохо?

5. Зачем делать пометки для решённых задач?

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!