С каким бы приложением ни была связана ваша работа и в каком бы качестве вы ни присутствовали в процессе, рано или поздно наступит тот момент, когда к вам впервые явится пользователь и, доверчиво моргая, спросит: а почему у меня пимпочка не пимпает? Чтобы пимпочка пимпала, – скажете вы, погибая от умиления (поставил! пользуется!), – нужно сперва покрутить крутёлочку. К десятому пользователю умиления поубавится. К пятидесятому вы, вероятно, заведете пару-тройку шаблонов для ответа на наиболее популярные вопросы. К сотому наймете с полдесятка студентов на должность инженеров технической поддержки и вздохнете с облегчением – ровно до того момента, пока один из них не образуется у вашего рабочего стола с вопросом: а у меня тут пользователь пришел, и у него пимпочка не пимпает – почему? Крутёлочка? Какая крутёлочка?
Вдохните. Выдохните. Перекурите. Спрячьте тела и наймите новых студентов, если предыдущие уже кончились. Наступила эра технической поддержки, и именно ее представители будут теперь главным источником неприятностей в течение рабочего дня разработчика – но оно стоит того. В конце концов, сосуществовать с десятком-другим опытных проблемоводов, которым за это платят, значительно проще, чем с сотнями разгневанных пользователей, которые платят вам – и совсем не за проблемы. Я же попытаюсь рассказать о том, как это сосуществование можно облегчить без необходимости прятать тела систематически.
Мои советы ниже основаны на опыте взаимодействия службы технической поддержки кроссплатформенных продуктов (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!», – и вы полностью друг друга понимаете.
Вдохните. Выдохните. Перекурите. Спрячьте тела и наймите новых студентов, если предыдущие уже кончились. Наступила эра технической поддержки, и именно ее представители будут теперь главным источником неприятностей в течение рабочего дня разработчика – но оно стоит того. В конце концов, сосуществовать с десятком-другим опытных проблемоводов, которым за это платят, значительно проще, чем с сотнями разгневанных пользователей, которые платят вам – и совсем не за проблемы. Я же попытаюсь рассказать о том, как это сосуществование можно облегчить без необходимости прятать тела систематически.
Мои советы ниже основаны на опыте взаимодействия службы технической поддержки кроссплатформенных продуктов (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!», – и вы полностью друг друга понимаете.