Думаю, о том, чем занимается наша компания — JetBrains, — большинство читателей Хабра так или иначе знают. Для остальных скажем коротко: мы делаем продукты, которые облегчают ежедневную жизнь программистов и помогают им писать код быстро и качественно. Среди наших продуктов — известные многим IntelliJ IDEA, ReSharper, PhpStorm, TeamCity, YouTrack и другие.
Но речь сейчас не совсем об этом. Задумывались ли вы о том, как в такой компании, как наша, организован support? Если вам было бы интересно почитать об особенностях работы наших инженеров Технической Поддержки — добро пожаловать под кат.
Говоря общими словами, наша техподдержка очень сильно отличается от техподдержки, скажем, Яндекса, Майкрософта или, тем более, какого-нибудь оператора мобильной связи. Специфика продуктов нашей компании позволяют судить об основной группе наших пользователей — это программисты. В связи с этим уровень и качество обращений в наш саппорт находится на очень высоком уровне. Все (или почти все) клиенты не пугаются сложных технических вопросов, профессионального сленга или определенных задач, которые ставят перед ними наши инженеры для troubleshooting-а проблем.
Однако эта особенность накладывает определенные ограничения и требования на самих инженеров Технической Поддержки. Все инженеры, работающие у нас, имеют достаточный технический опыт, знакомы как минимум с профильными для себя (т. е. своей команды и продукта) языками программирования, свободно владеют письменным техническим английским языком и зачастую имеют опыт работы в качестве QA-инженеров.
Дальше мы предоставим слово нашим инженерам, чтобы они сами рассказали о себе, своей работе и особенностях саппорта в их командах.
Я работаю в JetBrains вот уже больше трех лет и почти все это время занимаюсь технической поддержкой пользователей ReSharper-а.
Как уже было сказано в предисловии, для работы в саппорте надо обладать неплохими техническими навыками и иметь хотя бы базовый background в программировании. Так и получилось — я закончил СПбГПУ по специальности «математик-программист» и до JetBrains 2,5 года работал инженером по тестированию ПО в двух других петербургских IT-конторах. Программировать я никогда особо не любил, а вот «ломать» мне всегда нравилось, да и получалось неплохо.
До того как я пришел работать в JetBrains (и в команду ReSharper в частности), саппортом здесь занимался один человек, параллельно выполнявший девелоперские задачи; остальные вопросы решались «в открытую» другими девелоперами/тестерами в твиттере, на форумах и тому подобных местах. Со временем стало понятно, что количество клиентов (и, соответственно, обращений напрямую в саппорт) растет, и для этого нужен отдельный человек. Так я и попал в команду.
Еще три года назад саппорт в ReSharper-е представлял собой исключительно работу с почтой (прямые обращения в саппорт) и обработку Uninstall Feedback-а (да-да, мы его читаем и отвечаем на него — многие клиенты очень удивляются, так как думают, что он уходит в /dev/null). Со временем становилось ясно, что такая система перестает отвечать потребностям как пользователей, так и нас самих. Надо было что-то менять, чтобы улучшить качество саппорта.
Тут следует отдельно сказать, что под качеством технической поддержки я прежде всего подразумеваю время, которое требуется для решения проблемы пользователя. Как вы понимаете, простая переписка бесконечными имейлами не всегда работает оптимально; тем более что база знаний проблем и частых вопросов у меня постоянно росла. Сначала эта проблема решалась небольшим набором «макросов», которые я встроил прямо в Outlook, потом я переделал общедоступный FAQ (который располагался на наших форумах), но и этого оказалось не достаточно.
В результате было проведено небольшое исследование различных систем Help Desk, и спустя некоторое время «обкатки» мы внедрили его для всех наших продуктов. Сейчас я занимаюсь, помимо саппорта, в том числе и администрированием наших двух Help Desk'ов и слежу за тем, чтобы все работало исправно и удобно — как для нас, так и для наших пользователей.
Отдельно стоит сказать о пользователях: нам с ними очень повезло, т. к. в 99,9% случаев это взрослые и технически грамотные люди. Разумеется, есть небольшой процент не очень адекватных/вежливых людей, но я полагаю, что у нас он заметно ниже, чем в других компаниях с более широкой аудиторией клиентов. Кроме того, большинство наших клиентов — жители Европы и США, и это чувствуется в общении. Вся переписка ведется на английском языке.
Разумеется, у всех наших пользователей есть свои предпочтения, когда речь заходит о написании кода с помощью наших продуктов (и ReSharper-а в частности). Сколько людей — столько и возможных конфигураций Visual Studio, установленных в ней плагинов, различных проектов и тому подобных вещей. Ясно, что протестировать все возможные комбинации рабочего окружения и различные типы проектов (и их комбинации) абсолютно невозможно, поэтому большое количество проблем всплывает по мере общения с людьми. Тут саппортеру приходится выступать в роли тестера: после сбора всей нужной информации о проблеме пользователя ее надо воспроизвести и определить, где же кроется проблема — в его environment-е или в ReSharper-е. Думаю, что в других компаниях подобные кейсы передаются сразу на «следующий уровень» или в отдел тестирования, у нас же саппорт-инженер берет часть этой работы на себя. Разумеется, если кейс трудоемкий (например, для его воспроизведения только полдня надо готовить виртуалку), он передается нашим тестерам, у которых окружение может быть частично развернуто.
Кроме того, саппорт в нашей команде выступает некой «первой линией обороны», который после релиза первым понимает, насколько качественной получилась новая версия и не «продолбали» ли мы что-то критичное. Таким образом, у саппортера аккумулируются определенные знания о наиболее распространенных проблемах продукта, которыми надо делиться с командой на ежедневных стенд-ап митингах. Эта информация очень важна, так как, скажем, если в релиз попала какая-то бага, мешающая комфортной работе части наших пользователей, то это сигнал к тому, что необходимо готовить, например, bugfix update.
Резюмируя, я могу заверить, что саппорт — интересная и нужная работа, от которой очень многое зависит с точки зрения жизни продукта. Бывает тяжело, да, особенно после новогодних или майских праздников: ты отдыхаешь, а тикеты копятся и копятся, так как в Европе не празднуют «День солидарности трудящихся». После праздников приходится работать с утроенной силой и скоростью, и частенько работать на выходных.
Стоило мне набрать «сколько людей любят свою работу» (на русском и английском), как поисковик выдал мне тысячи ссылок вида «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 я упомянула, что у меня есть вот такой твиттер и выглядит он так-то и так-то, и никого ли он не оскорбит, надо мной только мило посмеялись и сказали не переживать.
А еще тут не надо брать телефон, и мой непосредственный начальник не имеет никакого отношения к саппорту, поскольку, как я уже говорила, иерархия тут по продуктам. Хотя есть еще неофициальный самый главный, самый крутой из нас саппортер Серж, про которого уже слагают легенды. Скриншот легенды приложен.
То есть я сама себе первая, вторая, третья и пятнадцатая линия саппорта и выше меня — только разработчики. Этот факт вызывал во мне первое время непрекращающееся «вау», потому что можно написать разработчику и он напрямую тебе ответит и даже может быть довольно быстро. И точно без снисхождения.
Мне кажется, я не рассказала и десятой части того, как тут круто, но, кажется, пора закругляться. Ищите меня в твиттере. ;)
Я работаю в поддержке достаточно давно. Сначала у интернет-провайдера, потом в крупной питерской программистской компании. Работая в поддержке, понял, что мой интерес к разным технологиям слишком большой, чтобы ограничиваться поверхностными знаниями и с целью их расширить и систематизировать, решил получить второе высшее образование по специальности “математик-программист”.
Мне всегда нравилось общаться с людьми, изучать английский язык и, конечно, узнавать и изучать новые технологии. И этим для меня особенно привлекательна работа в JetBrains. Разрабатывая софт для программистов, нужно идти наравне с прогрессом, а, может, даже впереди. И, конечно, в нашей компании все это есть.
Как раз поэтому мне повезло работать в команде IntellIJ IDEA. IntelliJ — открытая платформа, на которой разрабатывается продукт IntelliJ IDEA, IDE для Java, которая также используется как платформа для более легковесных, узко специализированных продуктов для других языков программирования (Ruby, Python, PHP, JavaScript и др.). То есть профессиональная область довольно широкая. Конечно, если есть какая-либо специфическая проблема, всегда можно обратиться к коллеге-саппортеру из соответствующей команды.
Естественно, нужно отлично знать не только продукт и профильную область его применения, но и окружение, в котором он используется. Так как IDEA — кроссплатформенная IDE, нужно хорошо разбираться в основах устройства и тонкостях разных операционных систем.
Вспоминая свой студенческий опыт работы в техподдержке интернет-провайдера, приведу основные, на мой взгляд, отличия.
Первое, понятно, тут нет телефона =) Правда, инженерам порой приходится подключаться к удаленному рабочему столу клиента, если ситуация требует. Но все же это случается не часто и не совсем то же самое. В основном почта, баг-трекер, иногда форум. Также, думаю, здесь больше личного профессионального общения с коллегами. Через почту, понятно, все не обсудишь.
По поводу профессиональной области и навыков. Естественно нужно знать Java, JavaEE — хотя бы их основы. Бывают и случаи, когда объясняешь пользователю, почему его программа работает именно так, а не иначе, что имеет малое отношение к IDE самой по себе.
Все общение исключительно на английском.
Эскалация. Интернет-провайдер, где я работал — небольшая компания, и инженер технической поддержки решал там широкий спектр вопросов. Поэтому никаких процедур эскалации у нас не было. Если какая-то нетривиальная задача — она передавалась напрямую админу. Однако, в более крупных компаниях существует несколько уровней поддержки (обычно до трех). И первый уровень, который принимает обращения пользователей, как правило, нешаблонную проблему/вопрос сразу эскалирует. У нас же, как говорилось, часто приходится выступать в роли тестера и напрямую консультироваться с разработчиком.
Количество наших пользователей и обращений в саппорт постоянно растет, и мы стараемся сделать работу программистов в наших IDE как можно более приятной и продуктивной. Зачастую можно встретить мнение, что человек покупает продукт в большей степени из-за оказываемой поддержки. Имеются ввиду как прямые обращения в саппорт и вопросы на форумах, так и быстрота реакции разработчиков на какую-либо критическую проблему, созданную в YouTrack. Например, пользователь создал issue, а через день или даже несколько часов фикс уже готов и включен в следующий EAP-билд продукта. Конечно, такое бывает не всегда, но критичные проблемы обычно решаются оперативно.
По поводу влияния на продукт. Конечно, в JetBrains саппорт в большой степени влияет на продукт. Важной составляющей тут является анализ мнений пользователей, который учитывается при планировании будущих релизов. Помогая продукту стать лучше, мы облегчаем работу с ним для тысяч людей, его использующих. Нам правда ценно мнение каждого пользователя.
Какие ассоциации у вас возникают со словом «инженер»? Что-то безумно скучное? А еще, быть может, трехэтажные формулы, чертежи, толстенные очки и какой-нибудь кабинет НИИ. Я видела это не только в советских фильмах, скорее — каждый день, потому что росла в семье инженера-конструктора и инженера-экономиста. Маленькая я твердо решила стать дирижером-юристом-космонавтом.
Прошло 15 лет. Здравствуйте, я Аня и я — инженер.
Инженер технической поддержки пользователей — для точности, которая многое проясняет. Например то, что я имею дело с живыми людьми, с чувством юмора и без, с серьезными проблемами и на один зубок, “в один момент”, одной левой. И могу совершенно точно сказать, что мою работу не назвать скучной. Несмотря на всю техничность и сложность вопросов, мне кажется, что уже давно пора открыть рубрику “Программисты шутят”. И она у нас, кстати, есть на ежедневных стендапах, потому что невозможно пройти мимо:
Сталкивались ли Вы с какими-то проблемами в PyCharm?
— Разумеется! У PyCharm нет ручек, а я бы хотел обнимать его каждый день!
— Должен признать, что у нас с ним сейчас медовый месяц и я, как водится, не замечаю и половины недостатков. Дайте мне время!
— А он может писать за меня код, который принесет мне big bucks?
Все это я записываю с первого дня в свой блокнот. Вы не сможете почитать мой твиттер (которого нет), но блокнот ведь даже лучше, там на полях есть рисуночки! Обращайтесь;) Это, кстати, не первый мой блокнот. До этого я два года проработала саппортером в компании i-Free, специфика приложений там была совсем другая, впрочем, как и аудитория. Но приложения эти часто появлялись в топах AppStore, как, например, CoinKeeper, и потому фидбэка было много, а значит мне, как единственному саппортеру на все приложения i-Free Innovations, тоже было нескучно:)
Итак, PyCharm одушевляют, хвалят (“Guys, you ROCK!!! You’re AWESOME!”), о нем пишут туториалы, текстовые и видео, и присылают их потом с вопросом: “Ребята, вам нравится?”. Да что там говорить, одна японская девушка рисует молоком наш логотип на капучино! Это ли не популярность?:)
Вы вот только представьте, пришли вы на работу 25 декабря, а у вас уже в почте с десяток поздравлений и не в одну строчку! Что-то мне подсказывает, что моя улыбка в такие моменты не иначе как гордая. Гордая, что в конце каждого ответа могу написать:
Best regards, Anna
PyCharm team.
К слову о нашей PyCharm team. Я опущу описание того, как я ее люблю и какие все там классные, — мы все-таки тут для серьезных дел собрались. Но ребята — настоящие профессионалы, и, когда я обращаюсь к ним с какой-нибудь трудной проблемой юзера, они с легкостью отправляют ее в нокдаун! Серьезно, даже Ван Дамм на двух грузовиках не так крут.
Ребята чуть выше достаточно подробно описали техническую сторону саппорта, и я не буду лезть туда же. Уверена, что для того чтобы дойти до конца статьи, нужно обладать достаточным терпением, и мне как-то не хочется его испытывать. Поэтому просто немного фактов о нашей саппортерской команде:
Но самое главное и будьте в этом уверены, в конце своего письма мы всегда добавляем: “Please feel free to ask any questions”. А это значит лишь одно: какая бы беда у вас ни приключилась с дебаггингом, какие эксепшены вы бы ни ловили, — мы здесь, чтобы вам помочь. Смелее, пишите!
Но речь сейчас не совсем об этом. Задумывались ли вы о том, как в такой компании, как наша, организован support? Если вам было бы интересно почитать об особенностях работы наших инженеров Технической Поддержки — добро пожаловать под кат.
Небольшое предисловие
Говоря общими словами, наша техподдержка очень сильно отличается от техподдержки, скажем, Яндекса, Майкрософта или, тем более, какого-нибудь оператора мобильной связи. Специфика продуктов нашей компании позволяют судить об основной группе наших пользователей — это программисты. В связи с этим уровень и качество обращений в наш саппорт находится на очень высоком уровне. Все (или почти все) клиенты не пугаются сложных технических вопросов, профессионального сленга или определенных задач, которые ставят перед ними наши инженеры для troubleshooting-а проблем.
Однако эта особенность накладывает определенные ограничения и требования на самих инженеров Технической Поддержки. Все инженеры, работающие у нас, имеют достаточный технический опыт, знакомы как минимум с профильными для себя (т. е. своей команды и продукта) языками программирования, свободно владеют письменным техническим английским языком и зачастую имеют опыт работы в качестве QA-инженеров.
Дальше мы предоставим слово нашим инженерам, чтобы они сами рассказали о себе, своей работе и особенностях саппорта в их командах.
Александр Березуцкий, команда .NET/ReSharper
Я работаю в JetBrains вот уже больше трех лет и почти все это время занимаюсь технической поддержкой пользователей ReSharper-а.
Как уже было сказано в предисловии, для работы в саппорте надо обладать неплохими техническими навыками и иметь хотя бы базовый background в программировании. Так и получилось — я закончил СПбГПУ по специальности «математик-программист» и до JetBrains 2,5 года работал инженером по тестированию ПО в двух других петербургских IT-конторах. Программировать я никогда особо не любил, а вот «ломать» мне всегда нравилось, да и получалось неплохо.
До того как я пришел работать в JetBrains (и в команду ReSharper в частности), саппортом здесь занимался один человек, параллельно выполнявший девелоперские задачи; остальные вопросы решались «в открытую» другими девелоперами/тестерами в твиттере, на форумах и тому подобных местах. Со временем стало понятно, что количество клиентов (и, соответственно, обращений напрямую в саппорт) растет, и для этого нужен отдельный человек. Так я и попал в команду.
Еще три года назад саппорт в ReSharper-е представлял собой исключительно работу с почтой (прямые обращения в саппорт) и обработку Uninstall Feedback-а (да-да, мы его читаем и отвечаем на него — многие клиенты очень удивляются, так как думают, что он уходит в /dev/null). Со временем становилось ясно, что такая система перестает отвечать потребностям как пользователей, так и нас самих. Надо было что-то менять, чтобы улучшить качество саппорта.
Тут следует отдельно сказать, что под качеством технической поддержки я прежде всего подразумеваю время, которое требуется для решения проблемы пользователя. Как вы понимаете, простая переписка бесконечными имейлами не всегда работает оптимально; тем более что база знаний проблем и частых вопросов у меня постоянно росла. Сначала эта проблема решалась небольшим набором «макросов», которые я встроил прямо в Outlook, потом я переделал общедоступный FAQ (который располагался на наших форумах), но и этого оказалось не достаточно.
В результате было проведено небольшое исследование различных систем Help Desk, и спустя некоторое время «обкатки» мы внедрили его для всех наших продуктов. Сейчас я занимаюсь, помимо саппорта, в том числе и администрированием наших двух Help Desk'ов и слежу за тем, чтобы все работало исправно и удобно — как для нас, так и для наших пользователей.
Отдельно стоит сказать о пользователях: нам с ними очень повезло, т. к. в 99,9% случаев это взрослые и технически грамотные люди. Разумеется, есть небольшой процент не очень адекватных/вежливых людей, но я полагаю, что у нас он заметно ниже, чем в других компаниях с более широкой аудиторией клиентов. Кроме того, большинство наших клиентов — жители Европы и США, и это чувствуется в общении. Вся переписка ведется на английском языке.
Разумеется, у всех наших пользователей есть свои предпочтения, когда речь заходит о написании кода с помощью наших продуктов (и ReSharper-а в частности). Сколько людей — столько и возможных конфигураций Visual Studio, установленных в ней плагинов, различных проектов и тому подобных вещей. Ясно, что протестировать все возможные комбинации рабочего окружения и различные типы проектов (и их комбинации) абсолютно невозможно, поэтому большое количество проблем всплывает по мере общения с людьми. Тут саппортеру приходится выступать в роли тестера: после сбора всей нужной информации о проблеме пользователя ее надо воспроизвести и определить, где же кроется проблема — в его environment-е или в ReSharper-е. Думаю, что в других компаниях подобные кейсы передаются сразу на «следующий уровень» или в отдел тестирования, у нас же саппорт-инженер берет часть этой работы на себя. Разумеется, если кейс трудоемкий (например, для его воспроизведения только полдня надо готовить виртуалку), он передается нашим тестерам, у которых окружение может быть частично развернуто.
Кроме того, саппорт в нашей команде выступает некой «первой линией обороны», который после релиза первым понимает, насколько качественной получилась новая версия и не «продолбали» ли мы что-то критичное. Таким образом, у саппортера аккумулируются определенные знания о наиболее распространенных проблемах продукта, которыми надо делиться с командой на ежедневных стенд-ап митингах. Эта информация очень важна, так как, скажем, если в релиз попала какая-то бага, мешающая комфортной работе части наших пользователей, то это сигнал к тому, что необходимо готовить, например, 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 в роли саппортера я была лучшим саппортером по статистике в отделе и, тем не менее, имела удовольствие общаться с непосредственным своим начальником по поводу своего закрытого, но не анонимного аккаунта в твиттере (вот это поворот!). Я была удивлена, но сменила имя и никнейм, продолжая свою деятельность по
А еще тут не надо брать телефон, и мой непосредственный начальник не имеет никакого отношения к саппорту, поскольку, как я уже говорила, иерархия тут по продуктам. Хотя есть еще неофициальный самый главный, самый крутой из нас саппортер Серж, про которого уже слагают легенды. Скриншот легенды приложен.
То есть я сама себе первая, вторая, третья и пятнадцатая линия саппорта и выше меня — только разработчики. Этот факт вызывал во мне первое время непрекращающееся «вау», потому что можно написать разработчику и он напрямую тебе ответит и даже может быть довольно быстро. И точно без снисхождения.
Мне кажется, я не рассказала и десятой части того, как тут круто, но, кажется, пора закругляться. Ищите меня в твиттере. ;)
Андрей Дернов, команда IntelliJ IDEA
Я работаю в поддержке достаточно давно. Сначала у интернет-провайдера, потом в крупной питерской программистской компании. Работая в поддержке, понял, что мой интерес к разным технологиям слишком большой, чтобы ограничиваться поверхностными знаниями и с целью их расширить и систематизировать, решил получить второе высшее образование по специальности “математик-программист”. Мне всегда нравилось общаться с людьми, изучать английский язык и, конечно, узнавать и изучать новые технологии. И этим для меня особенно привлекательна работа в JetBrains. Разрабатывая софт для программистов, нужно идти наравне с прогрессом, а, может, даже впереди. И, конечно, в нашей компании все это есть.
Как раз поэтому мне повезло работать в команде IntellIJ IDEA. IntelliJ — открытая платформа, на которой разрабатывается продукт IntelliJ IDEA, IDE для Java, которая также используется как платформа для более легковесных, узко специализированных продуктов для других языков программирования (Ruby, Python, PHP, JavaScript и др.). То есть профессиональная область довольно широкая. Конечно, если есть какая-либо специфическая проблема, всегда можно обратиться к коллеге-саппортеру из соответствующей команды.
Естественно, нужно отлично знать не только продукт и профильную область его применения, но и окружение, в котором он используется. Так как IDEA — кроссплатформенная IDE, нужно хорошо разбираться в основах устройства и тонкостях разных операционных систем.
Вспоминая свой студенческий опыт работы в техподдержке интернет-провайдера, приведу основные, на мой взгляд, отличия.
Первое, понятно, тут нет телефона =) Правда, инженерам порой приходится подключаться к удаленному рабочему столу клиента, если ситуация требует. Но все же это случается не часто и не совсем то же самое. В основном почта, баг-трекер, иногда форум. Также, думаю, здесь больше личного профессионального общения с коллегами. Через почту, понятно, все не обсудишь.
По поводу профессиональной области и навыков. Естественно нужно знать Java, JavaEE — хотя бы их основы. Бывают и случаи, когда объясняешь пользователю, почему его программа работает именно так, а не иначе, что имеет малое отношение к IDE самой по себе.
Все общение исключительно на английском.
Эскалация. Интернет-провайдер, где я работал — небольшая компания, и инженер технической поддержки решал там широкий спектр вопросов. Поэтому никаких процедур эскалации у нас не было. Если какая-то нетривиальная задача — она передавалась напрямую админу. Однако, в более крупных компаниях существует несколько уровней поддержки (обычно до трех). И первый уровень, который принимает обращения пользователей, как правило, нешаблонную проблему/вопрос сразу эскалирует. У нас же, как говорилось, часто приходится выступать в роли тестера и напрямую консультироваться с разработчиком.
Количество наших пользователей и обращений в саппорт постоянно растет, и мы стараемся сделать работу программистов в наших IDE как можно более приятной и продуктивной. Зачастую можно встретить мнение, что человек покупает продукт в большей степени из-за оказываемой поддержки. Имеются ввиду как прямые обращения в саппорт и вопросы на форумах, так и быстрота реакции разработчиков на какую-либо критическую проблему, созданную в YouTrack. Например, пользователь создал issue, а через день или даже несколько часов фикс уже готов и включен в следующий EAP-билд продукта. Конечно, такое бывает не всегда, но критичные проблемы обычно решаются оперативно.
По поводу влияния на продукт. Конечно, в JetBrains саппорт в большой степени влияет на продукт. Важной составляющей тут является анализ мнений пользователей, который учитывается при планировании будущих релизов. Помогая продукту стать лучше, мы облегчаем работу с ним для тысяч людей, его использующих. Нам правда ценно мнение каждого пользователя.
Анна Морозова, команда PyCharm
Какие ассоциации у вас возникают со словом «инженер»? Что-то безумно скучное? А еще, быть может, трехэтажные формулы, чертежи, толстенные очки и какой-нибудь кабинет НИИ. Я видела это не только в советских фильмах, скорее — каждый день, потому что росла в семье инженера-конструктора и инженера-экономиста. Маленькая я твердо решила стать дирижером-юристом-космонавтом.
Прошло 15 лет. Здравствуйте, я Аня и я — инженер.
Инженер технической поддержки пользователей — для точности, которая многое проясняет. Например то, что я имею дело с живыми людьми, с чувством юмора и без, с серьезными проблемами и на один зубок, “в один момент”, одной левой. И могу совершенно точно сказать, что мою работу не назвать скучной. Несмотря на всю техничность и сложность вопросов, мне кажется, что уже давно пора открыть рубрику “Программисты шутят”. И она у нас, кстати, есть на ежедневных стендапах, потому что невозможно пройти мимо:
Сталкивались ли Вы с какими-то проблемами в PyCharm?
— Разумеется! У PyCharm нет ручек, а я бы хотел обнимать его каждый день!
— Должен признать, что у нас с ним сейчас медовый месяц и я, как водится, не замечаю и половины недостатков. Дайте мне время!
— А он может писать за меня код, который принесет мне big bucks?
Все это я записываю с первого дня в свой блокнот. Вы не сможете почитать мой твиттер (которого нет), но блокнот ведь даже лучше, там на полях есть рисуночки! Обращайтесь;) Это, кстати, не первый мой блокнот. До этого я два года проработала саппортером в компании i-Free, специфика приложений там была совсем другая, впрочем, как и аудитория. Но приложения эти часто появлялись в топах AppStore, как, например, CoinKeeper, и потому фидбэка было много, а значит мне, как единственному саппортеру на все приложения i-Free Innovations, тоже было нескучно:)
Итак, PyCharm одушевляют, хвалят (“Guys, you ROCK!!! 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”. А это значит лишь одно: какая бы беда у вас ни приключилась с дебаггингом, какие эксепшены вы бы ни ловили, — мы здесь, чтобы вам помочь. Смелее, пишите!
