Support в JetBrains

Думаю, что о том, чем занимается наша компания – JetBrains – большинство читателей Хабра так или иначе знают. Для остальных скажем коротко: мы делаем продукты, которые облегчают ежедневную жизнь программистов и помогают им писать код быстро и качественно. Среди наших продуктов – известные многим IntelliJ IDEA, ReSharper, PhpStorm, TeamCity, YouTrack и другие.

Но речь сейчас не совсем об этом. Задумывались ли вы о том, как в такой компании, как наша, организован support? Если вам было бы интересно почитать об особенностях работы наших инженеров Технической Поддержки – добро пожаловать под кат.

Небольшое предисловие

Говоря общими словами, наша техподдержка очень сильно отличается от техподдержки, скажем, Яндекса, Майкрософта или, тем более, какого-нибудь оператора мобильной связи. Специфика продуктов нашей компании позволяют судить об основной группе наших пользователей – это программисты. В связи с этим уровень и качество обращений в наш саппорт находится на очень высоком уровне – все (ну или почти все) клиенты не пугаются сложных технических вопросов, профессионального сленга или определенных задач, которые ставят перед ними наши инженеры для troubleshooting-а проблем.

Однако эта особенность накладывает определенные ограничения и требования на самих инженеров Технической Поддержки. Все инженеры, работающие у нас, имеют достаточный технический опыт, знакомы с, как минимум, профильными для себя (т.е. своей команды и продукта) языками программирования, свободно владеют письменным техническим английским языком и зачастую имеют опыт работы в качестве QA инженеров.

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

Александр Березуцкий, команда .NET/ReSharper

Я работаю в JetBrains вот уже больше трех лет, и почти все это время занимаюсь технической поддержкой пользователей ReSharper-а.
Как уже было сказано в предисловии, для работы в саппорте надо обладать неплохими техническими навыками и иметь хотя бы базовый background в программировании. Так и получилось – я закончил СПбГПУ по специальности «Математик-Программист» и до JetBrains 2,5 года работал инженером по тестированию ПО в двух других петербургских IT-конторах. Программировать я никогда особо не любил, а вот «ломать» мне всегда нравилось, да и получалось неплохо.

До того, как я пришел работать в JetBrains (и в команду ReSharper в частности), саппортом здесь занимался один человек, параллельно выполнявший девелоперские задачи; остальные вопросы решались «в открытую» другими девелоперами/тестерами в твиттере, на форумах и т.п. местах. Со временем стало понятно, что количество клиентов (и, соответственно, обращений напрямую в саппорт) увеличивается, и для этого нужен отдельный человек. Так я и попал в команду.

Еще три года назад, саппорт в ReSharper-е представлял собой исключительно работу с почтой (прямые обращения в саппорт) и обработку Uninstall Feedback-а (да-да, мы его читаем и отвечаем на него – многие клиенты очень удивляются, так как думают, что он уходит в /dev/null). Со временем становилось ясно, что такая система перестает удовлетворять потребностям как пользователей, так и нас, и надо было что-то менять, чтобы улучшить «качество» саппорта.

Тут следует отдельно сказать, что под «качеством технической поддержки» я прежде всего подразумеваю время, которое требуется для решения проблемы пользователя – как вы понимаете, простая переписка бесконечными email-ами не всегда работает оптимально; тем более что база знаний проблем и частых вопросов у меня постоянно росла. Сначала эта проблема решалась небольшим набором «макросов», которые я встроил прямо в Outlook, потом я переделал общедоступный FAQ (который располагался на наших форумах), но и этого было не достаточно.

В результате было проведено небольшое исследование различных систем HelpDesk, и спустя некоторе время «обкатки», мы внедрили его для всех наших продуктов. Сейчас я занимаюсь, помимо саппорта, в том числе и администрированием наших двух HelpDesk'ов и слежу за тем, чтобы все работало исправно и удобно – как для нас, так и для наших пользователей.

Отдельно стоит сказать о пользователях – нам с ними очень повезло, т.к. в 99.9% случаев это взрослые и технически грамотные люди. Разумеется, есть небольшой процент не очень адекватных/вежливых людей, но я полагаю, что у нас он значительно ниже, чем в других компаниях с более широкой аудиторией клиентов. Кроме того, большинство наших клиентов – жители Европы и США, и это чувствуется в общении. Вся переписка ведется на английском языке.

Разумеется, у всех наших пользователей есть свои предпочтения, когда речь заходит о написании кода с помощью наших продуктов (и ReSharper-а в частности). Сколько людей – столько и возможных конфигураций Visual Studio, установленных в ней плагинов, различных проектов и тому подобных вещей – как вы понимаете, протестировать все возможные комбинации рабочего окружения и различные типы проектов (и их комбинации) абсолютно невозможно, поэтому достаточно большое количество проблем всплывает по мере общения с людьми. Тут саппортеру приходится выступать в роли тестера – после того, как вся нужная информация о проблеме была собрана, проблему пользователя надо воспроизвести и понять, где кроется проблема – в его environment-е или в ReSharper-е. Думаю, что в других компаниях подобные кейсы передаются сразу на «следующий уровень» или в отдел тестирования, у нас же саппорт-инженер берет часть этой работы на себя. Разумеется, если кейс трудоемкий (например, для его воспроизведения только пол дня надо готовить виртуалку), он передается нашим тестерам, у которых окружение может быть частично развернуто.

Кроме того, саппорт в нашей команде выступает некой «первой линией обороны», который после релиза первым понимает, насколько качественной получилась новая версия, и не «продолбали» ли мы что-то критичное. Таким образом, у саппортера аккумулируются определенные знания о наиболее распространенных проблемах продукта, которыми надо делиться с командой на ежедневных stand-up митингах. Эта информация очень важна, так как, скажем, если в релиз попала какая-то бага, мешающая комфортной работе части наших пользователей, то это сигнал к тому, что необходимо готовить, например, bugfix update.

Резюмируя, я могу заверить, что саппорт – интересная и нужная работа, от которой очень многое зависит с точки зрения жизни продукта. Бывает тяжело, да, особенно после новогодних или майских праздников – ты отдыхаешь, а тикеты копятся и копятся, так как в Европе не празднуют «День Солидарности Трудящихся». После праздников приходится работать с утроенной силой и скоростью, и частенько работать на выходных.

Любовь Мельникова, команда PhpStorm

Стоило мне набрать «сколько людей любят свою работу» (на русском и английском), как поисковик выдал мне тысячи ссылок вида «why do so many people hate their jobs». Примерно 80% людей в мире ненавидят или не очень любят свою работу. Я уверена, что многие сотрудники технической поддержки войдут в эти 80%. Многие, но только не я. Меня зовут Люба, я закончила МатМех СпбГУ и работаю в тех.поддержке PhpStorm.

Работа саппорта полна стереотипов, и я не могу сказать, что они всегда не верны (имею опыт работы в двух технических поддержках). Но это точно не так для компании JetBrains.

Здесь нет автономного саппорт-отдела. В основном в компаниях сотрудников тех.поддержки сгоняют в 1-2 кабинета, где «особая атмосфера поддержки» и куда никогда не заглядывают другие отделы. Разработчики на кухне старательно не замечают саппортеров, которые кучкуются по углам, и даже девочки, перекладывающие бумажки, воротят нос. У нас всё не так. У нас есть команды по продуктам, например, в моей команде PhpStorm’а 9 человек — 5 разработчиков (один из них тимлид), продукт маркетинг менеджер, тестировщик, технический писатель и я. Себя на последнее место я поставила исключительно из врожденной скромности, потому что за все время, что я тут работаю, мы все общаемся абсолютно на равных. Никакого пренебрежительного отношения, даже намека на него.

У меня — нескучная работа. Вот совсем. Никаких шаблонных ответов у нас не существует, конечно, есть стандартные фразы (ну, куда уж без них), но никаких заготовок, где надо вставить имя. Плюс, я отвечаю за форум и даже, по возможности, за stackoverflow. Где-то процентов 60 от всех кейсов – это отзывы (они же фидбэки), есть такие, где люди просто хотят сказать спасибо, есть такие, где репортят баги и просят фичи. Бывают очень серьезные проблемы, на которые стараюсь отвечать побыстрее, даже несмотря на то, что человек может даже и не ждал от меня ответа. Иногда бывает очень весело, например, совсем недавно писал к нам в редакцию товарищ, который в поле «License server» вводил адрес физического своего сервака, включая штат и почтовый код. Некоторые перлы или милые комментарии я выписываю себе в закрытый (!) твиттер без упоминания моего имени и компании на память.

Are there any features you'd like to have but did not find in PhpStorm?
— Write my code for me?
Are there any features you'd like to have but did not find in PhpStorm?
— A button to send my wife flowers and candy.

Человек прислал пример кода:

Catch (Exception e)
{
//who cares?
}

Моё любимое:

CTRL + F4 to close files, really? What kind of fingers do you guys have ;-)

Чувствую необходимость пояснить свой восклицательный знак после упоминания закрытости моего твиттера. На прошлой работе в компании V-m Software в роли саппортера я была лучшим саппортером по статистике в отделе и, тем не менее, имела удовольствие общаться с непосредственным своим начальником по поводу своего закрытого, но не анонимного аккаунта в твиттере (вот это поворот!). Я была удивлена, но сменила имя и никнейм, продолжая свою деятельность по осквернению V-m Software в социальных сетях (на самом деле нет). Когда же в JetBrains я упомянула, что у меня есть вот такой твиттер и выглядит он так-то и так-то, и никого ли он не оскорбит, надо мной только мило посмеялись и сказали не переживать.

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

То есть я сама себе первая, вторая, третья и пятнадцатая линия саппорта и выше меня — только разработчики. Этот факт вызывал во мне первое время непрекращающееся «вау», потому что можно написать разработчику и он напрямую тебе ответит и даже может быть довольно быстро. И точно без снисхождения.

Мне кажется, я не рассказала и десятой части того, как тут круто, но, кажется, пора закругляться, ищите меня в твиттере. ;)

Андрей Дернов, команда IntelliJ IDEA

Я работаю в поддержке достаточно давно. Сначала у интернет-провайдера, потом в крупной питерской программистской компании. Работая в поддержке, понял, что мой интерес к разным технологиям слишком большой, чтобы ограничиваться поверхностными знаниями и с целью их расширить и систематизировать, решил получить 2-е высшее образование по специальности “математик-программист”.
Мне всегда нравилось общаться с людьми, изучать английский язык и, конечно, узнавать и изучать новые технологии. И этим для меня особенно привлекательна работа в JetBrains. Разрабатывая софт для программистов — нужно наравне с прогрессом а может даже впереди. И, конечно, в нашей компании все это есть.

Как раз поэтому мне повезло работать в команде IntellIJ IDEA. IntelliJ — открытая платформа, на которой разрабатывается продукт IDEA — Java IDE, также используется как платформа для более легковесных, узко специализированных продуктов для других языков программирования (Ruby, Python, PHP, JavaScript и др). То есть профессиональная область довольно широкая. Конечно, если есть какая-либо специфичная проблема, всегда можно обратиться к коллеге-саппортеру из соответствующей команды.

Естественно, нужно отлично знать не только продукт и профильную область его применения, но и окружение, в котором он используется. Так как IDEA — кроссплатформенная IDE, нужно хорошо разбираться в основах устройства и тонкостях разных операционных систем.

Вспоминая свой студенческий опыт работы в техподдержке интернет провайдера, приведу основные, на мой взгляд, отличия.
Первое, понятно, тут нет телефона =) Правда, инженерам бывает приходится подключаться к удаленному рабочему столу клиента, если ситуация требует. Но все же это случается не часто и не совсем то же самое. В основном почта, issue tracker, иногда форум. Также, думаю, здесь больше личного профессионального общения с коллегами. Через почту, понятно, все не обсудишь.
По поводу профессиональной области и навыков. Естественно нужно знать Java, JavaEE — хотя бы основы. Бывают и случаи когда объясняешь пользователю почему его программа работает именно так а не иначе, что имеет малое отношение к IDE самой по себе.

Все общение исключительно на английском.

Эскалация. Интернет провайдер, где я работал — небольшая компания, и инженер технической поддержки решал там широкий спектр вопросов. Поэтому никаких процедур эскалации у нас не было. Если какая-то нетривиальная задача — она передавалась напрямую админу. Однако, в более крупных компаниях существует несколько уровней поддержки (обычно до трех). И 1й уровень, который принимает обращения пользователей, как правило, не шаблонную проблему/вопрос сразу эскалирует. У нас же, как говорилось, часто приходится выступать в роли тестера и напрямую консультироваться с разработчиком.

Количество наших пользователей и обращений в саппорт постоянно растет, и мы стараемся сделать работу программистов в наших IDE как можно более приятной и продуктивной. Зачастую можно встретить мнение, что человек покупает продукт в большей степени из-за оказываемой поддержки. Имеются ввиду как прямые обращения в саппорт и вопросы на форумах, так и быстрота реакции разработчиков на какую-либо критическую проблему, созданную в YouTrack. Например, пользователь создал issue, а через день или даже несколько часов фикс уже готов и включен в следующий EAP билд продукта. Конечно такое бывает не всегда, но критичные проблемы обычно решаются оперативно.

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

Анна Морозова, команда PyCharm

Какие ассоциации у вас возникают со словом «инженер»? Что-то безумно скучное? А еще, быть может, трехэтажные формулы, чертежи, толстенные очки и какой-нибудь кабинет НИИ. Я видела это не только в советских фильмах, скорее — каждый день, потому что росла в семье инженера-конструктора и инженера-экономиста. Маленькая я твердо решила стать дирижером-юристом-космонавтом.

Прошло 15 лет. Здравствуйте, я — Аня и я — инженер.

Инженер технической поддержки пользователей — для точности, которая многое проясняет. Например то, что я имею дело с живыми людьми, с чувством юмора и без, с серьезными проблемами и на один зубок, “в один момент”, одной левой. И могу совершенно точно сказать, что мою работу не назвать скучной. Несмотря на всю техничность и сложность вопросов, мне кажется, что уже давно пора открыть рубрику “Программисты шутят”. И она у нас, кстати, есть на ежедневных стендапах, потому что невозможно пройти мимо:

Сталкивались ли Вы с какими-то проблемами в PyCharm?
— Разумеется! У PyCharm нет ручек, а я бы хотел обнимать его каждый день!
— Должен признать, что у нас с ним сейчас медовый месяц и я, как водится, не замечаю и половины недостатков. Дайте мне время!
— А он может писать за меня код, который принесет мне big bucks?

Все это я записываю с первого дня в свой блокнот. Вы не сможете почитать мой твиттер (которого нет), но блокнот ведь даже лучше, там на полях есть рисуночки! Обращайтесь;) 

Это, кстати, не первый мой блокнот. До этого я два года проработала саппортером в компании i-Free, специфика приложений там была совсем другая, впрочем как и аудитория, но приложения эти часто появлялись в топах AppStore, как, например, CoinKeeper, и потому фидбэка было много, а значит мне, как единственному саппортеру на все приложения i-Free Innovations, тоже было нескучно:)

Итак, PyCharm одушевляют, хвалят (“Guys, you’re ROCKS!!! You’re AWESOME!”), о нем пишут туториалы, текстовые и видео, и присылают их потом с вопросом: “Ребята, вам нравится?”. Да что там говорить, одна японская девушка рисует молоком наш логотип на каппучино! Это ли не популярность?:)

Вы вот только представьте, пришли Вы на работу 25 декабря, а у Вас уже в почте с десяток поздравлений и не в одну строчку! Что-то мне подсказывает, что моя улыбка в такие моменты не иначе как гордая. Гордая, что в конце каждого ответа могу написать:
Best regards, Anna
PyCharm team.

К слову о нашей PyCharm team. Я опущу описание того, как я ее люблю и какие все там классные — мы все-таки тут для серьезных дел собрались. Но ребята — настоящие профессионалы и когда я обращаюсь к ним с какой-нибудь трудной проблемой юзера, они с легкостью отправляют ее в нокдаун! Серьезно, даже Ван Дам на двух грузовиках не так крут.

Ребята чуть выше достаточно подробно описали техническую сторону саппорта, и я не буду лезть туда же. Уверена, что для того чтобы дойти до конца статьи нужно обладать достаточным терпением и мне как-то не хочется его испытывать. Поэтому просто немного фактов о нашей саппортерской команде:

• Девочек и мальчиков в саппорте JetBrains примерно поровну. Это я к тому, что определить мужская это профессия или женская — не удастся. Главное — чтобы у тебя было широкое саппортерское плечо и определенный, не менее широкий, набор знаний.
• Мы все видим открытые тикеты друг друга. Закончились свои — берешь чужие, мы же саппортеры и друг друга поддерживать тоже надо:)
• У каждого из нас свой стиль ответа. Кто-то любит в одну строчку, а кто-то подробно и обстоятельно. Но результат всегда один: “Thanks for your help! The problem is solved” — ура!

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

Но самое главное и будьте в этом уверены, в конце своего письма мы всегда добавляем: “Please, feel free to ask any questions”. А это значит лишь одно: какая бы беда у вас не приключилась с дебаггингом, какие эксепшены вы бы не ловили — мы здесь, чтобы вам помочь. Смелее, пишите!

Автор: fergard

Источник ^[1]