Smart Questions:Как грамотно задавать вопросы и не быть героем шуток bash.org.ru?


Собирательный образ проблемного продвинутого пользователяНаверное, всем ИТшникам, да и не только им, нравится юмор в стиле bash.org.ru. Каждый из профессионалов обязательно имеет десяток своих баек про блондинок, пользователей бухгалтерии или секретарш. Очевидно, смотря на постоянный рост посещаемости сайта – должно быть просто искрометный юмор. Правда, чем дальше я работаю в Premier Support, тем менее смешным мне он кажется. Потому, что даже матерые администраторы при обращении к нам, частенько, выглядят этакими злобными недалекими блондинками. Давайте поговорим о еще одной, казалось бы, банальной проблеме – как задавать вопросы, что бы получать на них ответы.

В идеальном мире свободного ПО принято оказывать тех. поддержку за интерес, т.е. если человеку неинтересно отвечать на ваш вопрос, то и ответа вы не получите. Поэтому ребята давным-давно сделали документ “Как правильно задавать вопросы” (Оригинал на английском Smart Questions). Этот труд поистине фундаментальный и обязателен к прочтению каждому специалисту в области ИТ.

Будь у меня подчиненные, я бы потребовал от них знать этот текст вдоль и поперек! Нам он важен еще и потому, что этот блог или русский форум TechNET, как и любой другой форум – это часть коммюнити. Не только с плюсами в виде общения напрямик, так и по-факту с такими же правилами ведения дискуссии, ведь многие из людей, кто ОТВЕЧАЮТ на форумах, делают это, прежде всего, “за интерес”!

Откройте текст руководства «Как правильно задавать вопросы» прямо сейчас! Если вы уже читали его когда-либо, имеет смысл вновь освежить память и повторить простые правила грамотного общения.

Что важно помнить при обращении в любую службу поддержки?

Мы обсудили тему как задавать вопросы, чтобы получать ответы “за интерес”. Давайте посмотрим, как обстоят дела с платной поддержкой. Больше всего задержек при решении проблемы вызывает сложность понять следующие три вещи:

  1. Важность проблемы – т.е. насколько сильно вы страдаете, насколько срочно надо ее решать, какие средства хороши?
  2. Что вас конкретно интересует – т.е. за решение какой проблемы вы платите деньги?
  3. Критерий решения проблемы – когда МЫ(т.е. вы и тех. поддержка) будем считать, что вся проблема решена?

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

Если вы нервничаете и сильно нервничаете, то, наверное, (повторюсь, наверное) проблема важная. Кстати, ничего не мешает обозначить важность проблемы словами и цифрами. Например, два хороших варианта объяснить важность: “3 филиала компании не могут работать с основным для зарабатывания денег процессом”, “если почта не заработает через 2 часа - меня уволят”.

После понимания важности проблемы, как правило, всем, кто занят решением или страдает от проблемы, хотелось бы понять, в чем она собственно состоит. И если для вас проблема состоит в том, что на сервере Exchange не монтируется хранилище, то для сотрудника службы поддержки проблема может быть в том, что вы громко кричите в трубку телефона (шутка конечно, но очень правдивая, будьте вежливыми – это помогает).

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

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

Как правило, грамотно сформулированное описание проблемы позволяет легко получить критерии решения проблемы. Но основная задача здесь в том, чтобы их ОЗВУЧИТЬ! Т.е. и ВЫ, и тех. поддержка (отсуорсер, поставщик решения, друг Вася) были в курсе, что именно выполнение таких условий означает решение проблемы. Настоятельно-обязательно рекомендую зафиксировать эти условия в виде небольшого чек-листа и в письменном виде!

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

  • ВАЖНОСТЬ ПРОБЛЕМЫ, то вашу проблему могут решать слишком долго(по вашим меркам, естественно), или предлагать неподходящие способы: легкие и безопасные, или наоборот координальные и жесткие
  • СУТЬ ПРОБЛЕМЫ – вам вылечат симптом, но не излечат от недуга… Поэтому всегда сообщайте свой недуг, а не один из симптомов. Не знаете недуг – перечисляйте все симптомы и критерий разрешения!
  • Без КРИТЕРИЕВ РЕШЕНИЯ ПРОБЛЕМЫ вы просто рискуете, что, несмотря на понимание сути и важности проблемы, решение будет не полным для вас.

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

Мы все в той или иной степени продвинутые пользователи. Если я знаю ИТ-системы Microsoft, то мало того, что я не знаю бухгалтерию, так я еще и плаваю в мире Unix/Linux. Хе-хе…  Конечно я там не полный чайник, и ядро пересобрал, и даже iptables настраивал на весьма хитрые варианты source base routing, но в большинстве проблем Linux я буду плавать.

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

Есть способ проще – осознайте, что в данный момент вы "продвинутый пользователь"! Расскажите, ДЛЯ ЧЕГО вы делаете все эти действия, а затем опишите их. В 8 случаях из 10 вы скорее всего получите в ответ: “Ба! Да ты просто не туда копаешь! Надо в другом направлении посмотреть, слушай сюда…<описание как делать для вашей задачи правильно, быстро и просто>”

Будьте мудрее, сразу копайте в правильном направлении!

Успехов.

Comments (1)
  1. Anonymous says:

    Если быть очень кратким, то ITIL – это просто инструмент. Как мы знаем, сам по себе инструмент работу

Comments are closed.

Skip to main content