Тактика и стратегия общения с Hotline

Любое программное обеспечение содержит ошибки. Кривизна рук любого пользователя, и уж тем более администратора базы данных, всегда отлична от нуля. Поэтому перед каждым человеком, поручающим программе какую-либо деятельность, рано или поздно встает вопрос: "Куда обратиться за помощью, кто поможет мне укротить эту толпу взбесившихся нулей и единиц?" В нашем случае (а мы говорим об 1Cv7), производитель предоставляет техническую поддержку, то, что называется hotline - мы заплатили за софт и нам помогают им пользоваться. Вроде бы логично - кто может знать повадки программного продукта лучше создателя? У кого должно быть собрано самое большое количество вопросов и ответов? Нужно просто поднять телефонную трубку и проблему можно считать решенной. Но наш родимый менталитет (упоминания о котором хоть и мозолят глаза повсюду, но не становятся оттого менее уместными) не позволяет вот так просто поверить в чудо - была проблема и нет ее. Первый вопрос, который задает "наш" человек в таких случаях - "А в чем подвох?"

Если просмотреть архивы многочисленных веб-конференций, посвященных платформе 1Cv7, можно встать в тупик - настолько полярными бывают мнения обитателей этих конференций. От громких оваций "Техподдержка 1С - rulezzz!" до гнилых помидоров "1C-hotline suxxx!". Ну и гробовое молчание зала - "я обращался на hotline, это не помогло", такие отзывы встречаются несколько чаще прочих. Явно не та ситуация, когда глас народа выражает истину в последней инстанции. Такое впечатление, что разным людям доставалось разное качество помощи, или сами эти люди были разного качества.

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

Мое мнение - просить помощи у hotline стоит, но делать это следует так, чтобы максимизировать вероятность успешного исхода дела. Если Вы спросите "А разве от меня что-то зависит?", я отвечу - "Еще как зависит!". Сам я неоднократно обращался в службу поддержки фирмы 1С, и мне там серьезно помогали. Более того, одно время я сам был сотрудником такой службы у крупного питерского франчайзи. И поэтому я позволю себе дать несколько рекомендаций - в деле получения помощи, как и в любом другом, не так важна проблема, как подход к делу.

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

Для чего нужна классификация? Дело в том, что с пунктами (a) и (d) лучше обращаться к "мировому сообществу" - это можно сделать прямо здесь, а можно на одном из сайтов, перечисленных где-то справа. Но будьте готовы к тому, что если ответ на Ваш вопрос в явном виде находится в одной из красно-желтых книжек, Вам ответят лаконичным "RTFM!". А вот с пунктами (b) и особенно (c) лучше все же обратиться на hotline - конечно, можно послать убитую базу доброму человеку, но, во-первых, свободного времени у настолько добрых людей, как правило, немного, а во-вторых, ни один добрый человек не может похвастаться столь глубоким знанием анатомии программы, как создатель/родитель.

Рекомендация #1: не стоит поднимать телефонную трубку, лучше перепоручить эту функцию Вашему модему. Говоря по-русски, письмо лучше звонка. Почему так? А поставьте себя на место администрации любой, не обязательно даже компьютерной, фирмы-производителя - кого Вы посадите на "горячий телефон"? Было бы довольно глупо держать там крутых профессионалов, ну кому охота платить профессионалам немаленькие деньги за диалоги типа "А теперь мышка шевелится? Не шевелится? Нажмите Ctrl+Shift+Reset..." Да и не согласится профессионал на такую работу, ни за какие деньги. Поэтому на "горячих телефонах" обычно держат людей, которых просто больше некуда в данный момент пристроить. Конечно, для страховки полагается наличие в команде "телефонных барышень" хотя бы одного человека с квалификацией advanced user и выше, но.. Не знаю, как другие, но лично я, когда мне поручали такого рода деятельность, саботировал ее под любыми предлогами. Поэтому бывают ситуации, когда на обоих концах телефонного провода оказываются братья по разуму:

Вот такая иногда бывает помощь. Случай вполне реальный, из практики некоего франчайзи. Все бы ничего - 95окон сравнительно легко переносят сбой питания, но клиенту "горячего телефона" повезло - у него было открыто сразу две базы. Одна на 1С, работе с которой он учился, и одна на Access, в которой шла основная работа. Угадайте, какая из двух баз была переиндексирована, а какая убита насмерть? Поймите правильно, я вовсе не хочу сказать, что качество помощи на "горячем телефоне" всегда плохое и эта помощь приводит к трагическим последствиям. Но вероятность потратить время и заплатить по тарифам междугородней связи за советы из серии "Перезагрузить компьютер, а если не поможет, переустановить операционную систему" довольно велика. Да, ведь туда еще нужно дозвониться, а это не так и просто - множеству пользователей электронная почта недоступна и они забьют все телефонные линии, будь эти линии хоть трижды многоканальными. Итак, если Вам есть из чего выбирать - выбирайте e-mail.

Рекомендация #2: не пожалейте времени для написания и отладки письма. Во-первых, Вам нужно как можно более полно описать свою проблему и все сопутствующие обстоятельства, а во-вторых, Ваше письмо должно заинтересовать службу поддержки. Зачем это нужно? Опять-таки, поставьте себя на место тамошней администрации - каким образом Вы бы организовали обработку обвального количества входящей почты? Правильно, посадили бы нескольких наименее квалифицированных сотрудников на отсев зерен от плевелов и раздачу первых по принадлежности. Цепочка может быть сколь угодно длинной, а Вам нужно, чтобы письмо попало к наиболее компетентному человеку с минимальным числом форвардов. Поэтому, если положение не совсем критичное, постарайтесь найти время и немного исследовать свою проблему самостоятельно. Конкретных рекомендаций тут дать невозможно, просто постарайтесь пробудить в себе исследователя ;-) Изложите эти данные и свои соображения в письме, снабдите его скриншотами, логами, архивными копиями баз - всегда найдется что-то материальное. Довольно важный момент - стиль письма. Не пренебрегайте знаками препинания и правилами грамматики! Это важно - письмо без единой запятой воспринимается человеком старше 18 лет как несрочное, неважное и необязательное к ответу, и происходит это совершенно автоматически. Используйте больше умных слов - вместо "вылетает" лучше сказать "крах системы", а вместо "глючит" - "ведет себя неадекватно". Но если Вы не знаете точного значения того или иного слова - не употребляйте его, а еще лучше, загляните в словарь. Лучше проще, но лучше ;-) Еще один важный момент - подпись. Не стоит подписывать письмо генеральным директором и главным бухгалтером - это не счет-фактура. Да и что за фирма такая, где проблему сломанной БД решает директор? Самая лучшая формулировка - "ответственный за работу с пакетом", на регистрационной карточке прямо так и написано. И не забудьте указать в письме номер лицензии, а главное, реквизиты фирмы-продавца - отнюдь не каждый франчайзи утруждает себя отсылкой регистрационных карточек производителю.

Рекомендация #3: будьте корректны. Еще раз - будьте корректны. Ни в коем случае не позволяйте эмоциям заглушить голос разума. Даже если Вы твердо уверены, что разработчики ПО заслужили семиэтажную бранную конструкцию - перед отправкой уберите ее из письма. Это даже не этика общения, а голый прагматизм - Вам ведь нужно получить помощь в решении своих проблем, а не просто отвести душу. Даже мелкое ехидство типа "мы заплатили $$$ и надеялись на корректное выполнение программой декларированных функций" лучше отложить на потом - на случай, если решению Вашей проблемы не уделят должного внимания. Но и в этом случае аргументы действуют лучше ругани. Упирайте на то, что из-за проблем с СУБД Ваша организация несет материальные убытки - ведь это чистая правда.

Рекомендация #4: не стесняйтесь напоминать о себе. Если на первое письмо не последовало никакой реакции, или пришла явная отписка - пишите второе. Точнее, отправляйте первое еще раз. Потом третье, четвертое, пятое. Капля камень точит - рано или поздно Вашей проблемой займутся всерьез. На первый взгляд, смысла в этом мало - к тому времени, как раскачается служба поддержки, выйдет новый релиз с исправленным багом, проблема потеряет всякую актуальность, уже будут найдены способы обхода багов, поломанная БД будет выброшена и заполнена заново.. Но. Дело в том, что проблемы имеют пакостное свойство повторяться - напрягая разработчика решить проблему, пусть и потерявшую смысл лично для Вас, Вы тем самым помогаете другим пользователям, которые только собираются наступить на эти самые грабли. А у Вас, в свою очередь, будет больше шансов получить помощь, если по этому вопросу кто-то уже проел плешь разработчикам. "Помогайте ближним своим и воздастся Вам..", за точность цитаты не ручаюсь, но смысл именно тот.

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