С каким бы приложением ни была связана ваша работа и в каком бы качестве вы ни присутствовали в процессе, рано или поздно наступит тот момент, когда к вам впервые явится пользователь и, доверчиво моргая, спросит: а почему у меня пимпочка не пимпает? Чтобы пимпочка пимпала, – скажете вы, погибая от умиления (поставил! пользуется!), – нужно сперва покрутить крутёлочку. К десятому пользователю умиления поубавится. К пятидесятому вы, вероятно, заведете пару-тройку шаблонов для ответа на наиболее популярные вопросы. К сотому наймете с полдесятка студентов на должность инженеров технической поддержки и вздохнете с облегчением – ровно до того момента, пока один из них не образуется у вашего рабочего стола с вопросом: а у меня тут пользователь пришел, и у него пимпочка не пимпает – почему? Крутёлочка? Какая крутёлочка?Вдохните. Выдохните. Перекурите. Спрячьте тела и наймите новых студентов, если предыдущие уже кончились. Наступила эра технической поддержки, и именно ее представители будут теперь главным источником неприятностей в течение рабочего дня разработчика – но оно стоит того. В конце концов, сосуществовать с десятком-другим опытных проблемоводов, которым за это платят, значительно проще, чем с сотнями разгневанных пользователей, которые платят вам – и совсем не за проблемы. Я же попытаюсь рассказать о том, как это сосуществование можно облегчить без необходимости прятать тела систематически.
Мои советы ниже основаны на опыте взаимодействия службы технической поддержки кроссплатформенных продуктов (Parallels Desktop для Mac, Parallels Access, Parallels Mac Management) и разработчиков компании. Поддержка этих решений разделена на два уровня: операторы первой линии отвечают на первичные, типовые и, по сути, простые вопросы пользователей по всему миру. Специалисты этой линии находятся в Индии и Китае и для решения вопросов пользователей используют базу знаний, к которой, кстати, может прибегнуть любой пользователь самостоятельно. Первая линия обрабатывает 96% всех обращений. Сотрудники второй линии располагаются в Москве и занимаются оставшейся частью заявок, привлекая для решения проблем разработчиков продукта. Процесс обработки обращений клиентов продуктов Odin, ориентированных на хостеров и телекоммуникационные компании, построен немного по-другому.
Этот пост описывает проблемы взаимодействия между разработчиками и службой поддержки и предлагает несколько советов по его улучшению.
Проблема: как можно не знать, что?
Итак, первый и главный момент, на котором, по моему опыту, спотыкается 99% взаимодействий между разработкой и технической поддержкой: „ну как можно не знать, что?“. Вам забили баг про пимпочку. Вы точно помните, что самолично рассказывали про пимпочку на тренинге для той же клятой техподдержки: „А теперь, дорогие коллеги, позвольте представить вам нашу новейшую пимпочку, сделанную согласно последним веяниям индустрии! Наша пимпочка позволяет пимпать со скоростью в N раз большей, чем пимпочки конкурентов, по протоколу PRTCL. Безопасность передачи данных обеспечивается криптошифрованием 80-го уровня и лично сисадмином Ивановым (давал честное слово)“.
28 слайдов, включая портрет сисадмина Иванова с честным словом. Старались? Старались: двух тестеров загоняли до смерти, измеряя сравнительную скорость пимпанья с точностью до пятого знака после запятой. И вот теперь смотрите в баг „не пимпает“, и рука тянется позвонить начальнику этих идиотов и потребовать немедленной замены их какими-нибудь другими идиотами, которые будут знать, что для работы протокола PRTCL необходимо, чтобы в системе был установлен его драйвер. Потому что – ну как можно не знать, что?!
Совет: всем инструкций!
Так вот: можно. Знай инженер поддержки обо всех тонкостях протокола PRTCL, он, возможно, сидел бы на вашем месте и получал бы вашу зарплату. А пока это все же не так, первое, что нужно технической поддержке от разработки – чтобы любая лекция о прелестях и тонкостях продукта завершалась инструкцией навроде „Итак, коллеги, если у вас не пимпает: 1) крутёлочка, 2) проверьте, пожалуйста, есть ли в списке таком-то пункт „PRTCL driver”.”
Именно таким образом мы снизили процент невалидных багов от техподдержки с исходных 18% до 7% всего за месяц – инструкции! Никто не любит их писать, никто не любит их читать, но это работает: каждый компонент продукта оборудован краткой инструкцией по тому, что нужно проверить или добыть в той или иной ситуации. Разработчики ядра любят дампы и бут-флаги, каждый раз новые; если жалоба касается работы устройств, немедленно посмотрите в драйвера и соберите такие-то показатели, а также имейте в виду способ подключения и тип устройства. И поди упомни все это наизусть, если ты инженер техподдержки без спасительных инструкций, время за полночь, а в трубке бушует разгневанный пользователь.
Проблема: благие намерения и куда они ведут
Практически любая область деятельности в нашем обществе предполагает, что притвориться немного профессиональнее, чем ты есть, исключительно полезно – на собеседованиях, на совещаниях, в повседневном общении. Это довольно базовый шаблон поведения – посмотреть вон хоть рекомендации по написанию резюме. Но на каких-то должностях эта понятная человеческая склонность, увы, не приносит ничего, кроме неприятностей, и инженер техподдержки – как раз такой случай: слегка недопонявший инженер одним движением руки может натворить на пользовательском компьютере таких дел, что полным составом разработчиков потом не разгребешь.
Совет: лучше переуточнить, чем недоуточнить
Бесконечно важно напоминать и разработчикам, и поддержке, что инженер последней – это не почти разработчик, только немножко похуже. Это профессионал (в идеале, конечно), чья работа состоит отнюдь не только из технической части и требует не только технических умений и навыков. Это может быть язык, например: для Parallels, работающей на международном рынке, крайне важен английский. В России не так просто найти людей, сочетающих базовую техническую грамотность с умением объяснить по телефону на чистом английском, как пимпает пимпочка. Нервничающему клиенту. С таким же, возможно, неродным английским. Это может быть умение упрощать и объяснять. Умение понимать упрощенное и описываемое человеком, который никоим образом не обязан являться знатоком хотя бы общекомпьютерной терминологии. Строить какие-то предположения и давать советы на материале, от качества которого любой разработчик долго плакал бы. И, конечно, успокаивать, рассказывать, извиняться и обещать светлое будущее даже в тех случаях, когда вы только что самолично выставили клиентскому багу статус Wontfix.
Проблема: а потом галоши пропадают!
Из всего вышеперечисленного возникает мораль: общаться с технической поддержкой разработчику будет скучно. Вы можете рассказывать про оригинальность и изящество протокола PRTCL, и слушать вас будут, возможно, с благодарностью, но в конце все равно потребуют нудных инструкций с перечнем галочек. Желательно, таких галочек, выставление которых вполне безопасно для клиента. Вас будут изводить и тиранить вопросами и уточнениями, требуя при том, чтобы вы признавали право изводящих всего этого не знать. И тут-то вы, разработчик, возопите: а где же, где часть про мои права и их обязанности?! Без паники, мы к ней как раз переходим.
Совет: документируй ЭТО!
Главная обязанность инженера поддержки по отношению к компании и себе самому – документировать. Задокументировано должно быть все, что не было задокументировано ранее. Все баги должны быть забиты. Все инструкции должны быть записаны, сверены с вами еще разок на всякий случай и опубликованы. Все ваши ответы на все вопросы должны быть упорядочены и сохранены. И вот тут-то вы имеете полнейшее право сказать: эй, дорогие коллеги, почему это инженер Маша задает мне точно тот же вопрос, который задавал третьего дня инженер Петя? Почему мне забили баг на пимпочку, не проверив наличие в системе драйвера, о чем я определенно упоминал в инструкции? И тут-то пусть горько плачут инженеры Маша и Петя, их очередь.
Итог: и это тоже пройдет
Чья бы ни была очередь горько плакать, помните: со временем будет лучше. Инженеры техподдержки накопят достаточно документации, чтобы не изводить вас вопросами. Лучшие из них и вовсе грянутся оземь и превратятся в тренеров, чтобы служить дополнительным фильтром между вами и новичками. Вы, в свою очередь, овладеете непростым умением переводить с программистского на общечеловеческий и ощипывать вольно парящую мысль до состояния инструкции из пяти пунктов. И в один прекрасный момент на корпоративе вы поймаете себя на том, что рассказываете инженеру Пете о тонкостях протокола PRTCL, а он в ответ жалуется вам: «Я ему про Friday evening, а он мне про hard drive partition!», – и вы полностью друг друга понимаете.
Комментарии (14)
sebres
09.06.2015 10:53-1Инструкции конечно хорошо. Главное, чтобы оно в меру было. Поэтому совет «лучше переуточнить, чем недоуточнить» я бы техподдержке так вот наобум не давал. Или снабдил бы дополнением — если с головой.
Пример из жизни — подвисла DSL-линия. Вусмерть. Звонишь в техподдержку, и после длинной мелодии (я уже заряжен), девочка начинает по пунктам меня пытать:
— Модем включен? А провода подсоединены? А правильно ли кабель подключен?
— (Перебиваю) девушка у меня ничего не изменилось с вечера (все работало), это DSL-линия висит, соедините пожалуйста с технарем — ему нужно тупо сбросить линию.
— (полный игнор — у меня инструкция) А вы пробовали выключить и включить рутер через 10 минут? А какие лампочки горят? А у вас не стандартный рутер, подключите стандартный… Уже пробовали? А тогда…
— (Терпение лопнуло окончательно) Слышишь Тусси, прикрой свой хорошенький ротик и соедини пожалуйста с технарем, нет лучше просто скажи ему чтобы линию ресетнул…
Я понимаю конечно, что есть наверняка люди звонящие в техподдержку действительно с выключенным модемом. Но никогда не поверю, что таких неадекватов — масса. Если я дважды сказал, что ничего не изменилось с проводами, что другой рутер тоже пробовал, что линия однозначно висит — какого спрашивается дальше вытаскивать из меня последние нервы вопросами, которые однозначно отпадают с самого начала.
Инструкции блин у них… Перепишите тогда нафиг свои инструкции (чтобы у них хотя бы goto появилось).
latimeria Автор
09.06.2015 11:56+3Хм, боюсь, 83% обращений, закрывающихся с первой же итерации – т.е. одной статьей с инструкцией – слегка опровергают это неверие. А цифры по не профессиональным программным продуктам обычно именно таковы. Ну и да, как бы ни раздражало взаимодействие с первой линией, я неоднократно видела в тикетах ситуацию, когда пользователь очень технически подкован, но какую-нибудь условную уборщицу, выдернувшую провод, не учел.
sebres
09.06.2015 12:23-1когда пользователь очень технически подкован, но какую-нибудь условную уборщицу, выдернувшую провод, не учел
Ага, ему видите ли доставляет удовольствие сначала послушать музыку, потом полчаса пробиваться через «упертую» девочку.
Даже условно не очень «подкованный» пользователь три раза проверит все, перед тем как звонить в такую поддержку. Я например не собираюсь выслушивать 20-ть глупых вопросов, отметающихся первым же моим ответом, только потому, что у девочки это инструкцией не предусмотрено.
Заметьте я не отрицаю, что глупые клиенты техподдержки встречаются (возможно даже чаще чем хотелось бы). Я лишь хотел донести, что если вы думаете, что время ваших программистов (техников и т.д.) дороже времени любого клиента, то вы очень сильно ошибаетесь.latimeria Автор
09.06.2015 12:31+1Я боюсь, у Вас довольно идеалистические представления о пользователях десктопных продуктов :)
Вы, вероятно, IT-профессионал. А мы в немалой степени закладываемся на условную домохозяйку, которая просто хочет свою любимую программу для превращения картинок в схемы для вышивания крестиком. На вот этом замечательном серебристом ноутбуке, который ей ловко всучили в магазине. И… 83%, словом.
Более того, как тоже какой-никакой IT-профессионал в жизни не стала бы вопить на условную девочку из посторонней техподдержки за то, что она отрабатывает свои сценарии. Именно потому, что см. выше: я понимаю, для кого и зачем она это делает.sebres
09.06.2015 12:58Я вообще-то про сферическую поддержку в вакууме…
Хотя, вы подумали, что это может быть и дорогущий адвокат, за своим «замечательным серебристым ноутбуком»… У которого час стоит столько, сколько вся техподдержка стоит.
Мы немного про разные вещи с вами разговариваем — я вам про то, что неоптимально созданной инструкцией вида — «лучше переуточнить, чем недоуточнить» можно как минимум вывести клиента из себя. Вы же мне про то, что 83% — бестолковое стадо, с которым по другому нельзя. Намек надеюсь понятен? И да, к сожалению, вашей точки зрения придерживаются очень многие call-центры.
Еще раз — не нужно уточнять вопросы, которые исключаются первым же ответом. В конце концов, можно к ним снова вернутся, если решение все же не было найдено (имеем случай 83%).
Хотя я думаю, даже эти 83% будут очень благодарны, если решение будет найдено на 5-м вместо 45-го вопроса, потому что 40 из них просто перепрыгнули.
Именно потому, что см. выше: я понимаю, для кого и зачем она это делает
Что я могу сказать, это делает вам честь. С другой стороны, возможно вы просто совсем не цените свое время.latimeria Автор
09.06.2015 13:15+2А не бывает сферической в вакууме, то-то и оно. Более того, я бы сказала, что попытка заложиться на «сферическую в вакууме» немедленно принесет всем участникам ничего хорошего. Именно поэтому у нас достаточно сильно разведены алгоритмы взаимодействия с пользователями профессиональных продуктов и десктопных – аудитория очень разная.
Плохие инструкции — это плохо, разумеется, с этим вряд ли кто-то будет спорить. Но если инструкции составлены по результатам анализа предварительно накопленных данных, то условный адвокат в итоге получит свой ответ, возможно, за час – но получит и за час, а не за два. Просто потому, что если в компании есть человек/люди, занимающиеся анализом саппортного волюма и последующей оптимизацией этих инструкций, они довольно неплохи-то обычно, инструкции. Даже если лично Вам кажется, что они составлены с недостаточным благоговением к лично Вашей компетентности – которая другой стороне диалога неизвестна-то, увы. И потому эта другая сторона не может быть уверена, что и в каком объеме исключается первым ответом, а если к этим вопросам придется возвращаться постфактум, Вы же следующим раундом упрекнете саппорт в том, что о том и этом не подумали с самого начала.
То есть, попросту говоря, если перепрыгнуть через сорок вопросов и найти ответ на пятом вместо сорок пятого, то вариантов тут будет три: либо инструкция заведомо плоха и порождена плохими процессами и недостаточным анализом данных – и это плохо, разумеется, либо почему-то резко изменились обстоятельства – и при хороших процессах это достаточно быстро всплывет, и инструкция будет обновлена, либо это чистое везение, и опираться на него массово мы не будем, не-а. Потому что если осмысленность этого алгоритма не подтверждается на больших объемах данных, то такой «творческий подход» встанет нам в итоге в разы дороже одного адвоката. Или даже дюжины.
Satyricon
09.06.2015 20:39Зачем вы такой нервный. Я спокойно звоню в ТП, спокойно отвечаю девочке — да, выдернул, выключил, включил, не работает, ребутнул, не работает. После этого девочка говорит — тогда я вас соединю с инженером. 5 минут без ругани и распальцовки, так горааааздо быстрее.
latimeria Автор
09.06.2015 20:54+1А главное, финальное качество помощи-то выше, потому что инженер более-менее уверен в том, что выдернули, выключили и ребутнули-то. Тоже небесполезно же.
sebres
09.06.2015 22:18И вот пока вы спокойно, без распальцовки, отвечаете, кто-то слушает музыку.
Время — понятие конечно субъективное… И я тоже могу его тратить хоть целую уйму, это если я так сам решил, а не если за меня это порешали…Satyricon
10.06.2015 04:19-2Ну я представляю что с вами творится в поликлинике или сбербанке. Вообще то вы пришли со своей проблемой. Ну будьте добры, подождите.
sebres
10.06.2015 14:43Это называется подмена понятий. И как бы я вам и автору статьи немного за другое рассказывал — «Инструкция — не панацея» и что случается, если исполнители начнут ее придерживаться буквально.
А так то да, подвисшая DSL линия — моя проблема…
datacompboy
Но я не понял. Так почему пимпочка не пимпает? Драйвер есть, крутелка покрутела. А не пимпает! И не надо мне тут про дампы! Мне надо пимпать а не дампать!
latimeria Автор
А у вас, небось, крутелочка от предыдущей версии :)