Нужно ли инженеру поддержки кодить самому?

JetBrains

В этом интервью мы поговорим с Сергеем Барановым, инженером технической поддержки компании JetBrains.

Привет! Ты, может быть, слышал, что в компании Apple есть такой главный дизайнер Jony Ive. Его еще иногда называют “человек из белой комнаты”. Видеоролики с ним показывают на каждой конференции Apple (WWDC), и они сняты в пустой белой комнате. Поэтому про этого человека ходит такая легенда-шутка, что Jony Ive – это компьютерная программа, а не живой человек. В компании JetBrains про тебя ходит похожая легенда, что ты не живой человек, а продвинутый искусственный интеллект, компьютерная программа из будущего. Это наверное связано с тем, что ты работаешь из дома, коллеги в офисе тебя не видят, а отвечаешь ты 24/7 фактически. Поделишься секретом, а как же на самом деле?

Тут никакого секрета в общем нет. Действительно, работаю я из дома, удаленно, в офисе практически не бываю. И наверное, многие коллеги меня ни разу и не видели. Разве что очень редко, на каких-то корпоративных мероприятиях, вечеринках. Но есть и те, кто видел меня, когда я еще в офисе работал, но таких вряд ли много. Последние лет 12 я полностью удаленно работаю.

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

Один пользователь Hacker News также предположил, что меня держат запертым в комнате, его поддержали хэштегом #keepsergecaptive.

А с чем связан тот факт, что ты уже 12 лет работаешь только из дома?

Офисы компании всегда были расположены довольно далеко от того места, где я живу. Дорога занимала минимум час в одну сторону. Одно время я ездил на работу вместе с Сергеем Жуковым (директор по IT – прим.) – он жил тут недалеко и по дороге меня подбирал на машине. Так что первое время мы с ним ездили вместе, обсуждали разные проблемы в дороге, рабочие вопросы. Это было интересно. Потом стало жалко тратить большое количество времени на поездки в офис (появились новые продукты, объем работы вырос), и я стал постепенно переходить на удаленную работу. Сначала это был один день в неделю, потом два, потом три. Так постепенно перешел на полностью удаленную работу.

Но вообще работать в офисе мне нравилось. Офисы JetBrains всегда привлекают разными “плюшками”, атмосферой, обстановкой, едой. С коллегами было приятно поболтать о чем-то за чашечкой чая. Но нежелание тратить время на дорогу пересилило в итоге. К тому же я по натуре такой человек, которому лучше работается одному.

Тут надо еще отметить, что раньше техническая поддержка в JetBrains была устроена так, что я один занимался всеми продуктами, основанными на платформе IntelliJ. Так что контактировать с другими инженерами поддержки не нужно было, а общение с разработчиками было редким. К тому же, чтобы не отвлекать разработчиков, когда они работают, приоритетным каналом для общения был email, а не так, что пошел и спросил лично. Конечно, в самом первом офисе, где нас было около 10 человек, все сидели в одной большой комнате, и быстрее было подойти и спросить. Но, с моей точки зрения, это все равно не очень хорошо, потому что, если разработчика отвлекать вопросами, ему потом потребуется много времени, чтобы вернуться обратно к своей задаче. А потом офис стал больше, комнат стало много, идти спрашивать стало долго, так что переключились на электронные коммуникации.

Работая дома, я меньше отвлекаюсь, слушаю музыку через колонки, печатаю на шумной механической клавиатуре, не мешая коллегам. В любой момент можно сделать перерыв, заняться домашними делами, любимым хобби, или просто поспать. Моя продуктивность в таком режиме намного выше, чем была при работе в офисе, но такое далеко не всем подойдет по разным причинам.

А не бывает такого, хотя бы изредка, что ты чувствуешь, что тебе не хватает какого-то живого общения с коллегами? Или тебя полностью устраивает формат удаленной работы?

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

Когда ты все же приезжаешь в офис или встречаешься с коллегами на каком-то корпоративном мероприятии, не бывает ощущения “кто все эти люди”?

Есть такое ощущение, оно уже давно появилось. Компания последнее время довольно сильно выросла. И есть даже люди, которые работают в офисе, но не все друг друга знают. Сотрудники сидят по разным этажам, да и офис теперь не один. И люди общаются только внутри своих команд, а из соседних команд мало кого знают. Так что, думаю, это не только ко мне применимо.

Да, соглашусь тут с тобой. А сколько лет ты, получается, занимаешься уже саппортом в JetBrains?

Получается, что 15 с копейками. С января 2002 года.

Ого! В мире сейчас наметился тренд, что люди часто меняют род деятельности, ищут новые направления, так как им скучно заниматься одним и тем же, хочется перемен. А ты вот 15 лет занимаешься поддержкой. У тебя не возникает желания что-то поменять? Или ты находишь что-то новое в своей текущей деятельности?

IntelliJ IDEA – очень сложный продукт и очень быстро развивается. Буквально каждую неделю появляются новые возможности, поддержка новых языков, технологий. И если ты пытаешься быть в курсе всех этих изменений, у тебя просто нет времени думать о чем-то еще. Это уже очень много, наверное, даже больше, чем человек может усвоить, понять и осознать. В общем не соскучишься.

Я слышала, что есть случаи, когда инженеры технической поддержки в JetBrains начинали сами заниматься разработкой наших продуктов, чтобы лучше их узнать. А как ты справляешься с тем, чтобы знать продукт хорошо?

Я сам пользуюсь продуктами компании JetBrains для разработки своих приложений. У меня есть несколько таких проектиков. Например, приложение под Android. Оно появилось в момент, когда у нас только начали разрабатывать поддержку Android. Это приложение для синхронизации времени – ClockSync. У него сейчас более миллиона загрузок в Google Play.

Интересно. А какие еще приложения ты делал?

Еще у меня есть такой интересный проект, написанный на Java в IntelliJ IDEA. У Philips есть технология Ambilight (технология фоновой подсветки для телевизоров, запатентованная компанией Philips – прим.). Смысл заключается в том, что телевизор стену подсвечивает теми цветами, которые сейчас на экране, чтобы расширить визуальное представление картинки. И у них (Philips – прим.) есть еще такие лампочки Philips Hue. Было приложение под мобильные платформы (Android, iOS), которое позволяло синхронизировать лампочки с ambilight на телевизоре. Этим было не очень удобно пользоваться, потому что надо было включать вручную телефон, ставить его на зарядку, запускать там синхронизацию. И, получается, что каждый раз, когда ты хочешь посмотреть телевизор с таким эффектом, нужно пройти весь долгий процесс настройки. Мне пришла в голову мысль это автоматизировать, и я написал приложение, которые синхронизирует лампочки с ambilight на телевизоре. И работает оно не на мобильной платформе, а на любом устройстве, где можно Java запустить (на роутере, на сервере, на домашнем компьютере, на Raspberry PI, и т.д.).
Самая большая сложность заключалась в том, что алгоритм, конвертирующий цвет, который возвращает телевизор, в цвет лампочки, закрытый. Мне удалось это обойти, взяв из Android версии приложения уже скомпилированные классы, реализующие данный проприетарный алгоритм.

Я также сделал удобное API. Например, можно автоматизировать работу и добиться того, чтобы при включении телевизора и проигрывании фильма автоматически запускалась синхронизация лампочек, а по окончании фильма подсветка возвращалась в изначальное состояние. Там же есть всякая автоматизация для “умного дома”, чтобы с компьютера или других устройств менять настройки лампочек быстро. Штука узкоспециализированная довольно, так что не очень популярная. Делал я в основном для себя, но потом выложил в открытый доступ и сделал в Google+ группу поддержки, где отвечаю на вопросы. Называется программа HAmbiSync.

А как ты находишь идеи для таких приложений? Берешь их из мира вокруг себя и потом подбираешь технологию и подходящий инструмент от JetBrains, или ты отталкиваешься от технологии, например хочешь на Java что-то написать, и ищешь задачу, уже исходя из этого?

Сначала, конечно, возникает проблема. А потом уже смотрю, какой из наших продуктов может помочь мне ее решить, и заодно изучаю продукт. У меня вот, например, есть скрипты на Ruby для моих домашних автоматизаций, что-то на Python писал.

Есть еще один очень старый проект, который уже давно не поддерживается. Я начал его делать еще до того, как пришел работать в JetBrains. Он написан на C++, и тогда у нас еще не было IDE для C++, поэтому он писался в Visual Studio. Это плагин AMIP, который интегрируется с популярными аудиоплеерами и позволяет из них получить название песни, которая играет. Эту информацию (и другие теги) можно было передать в другие приложения, записать в файл или передать в популярный тогда IRC. Или даже сделать динамический баннер, картинку, которая при обращении будет показывать, какая музыка у тебя сейчас играет. И такую картинку можно потом вставить в подпись на форуме, либо в ICQ или Skype передать. И вот в какой-то момент понадобилось сделать интерфейс с настройками, которых там было очень много. Тогда как раз у нас появился GUI дизайнер для Java в IntelliJ IDEA, и я его очень активно применял в этом приложении, сделав навороченные настройки. А заодно изучил, как это все работает.

Я вот смотрю, что у тебя на многих ресурсах никнейм CrazyCoder. Ты себя в большей степени ощущаешь кодером/разработчиком или инженером поддержки?

Я давно уже не занимаюсь программированием профессионально. Для меня программирование – это хобби. А техническая поддержка – это моя профессиональная деятельность. Но я, конечно, ощущаю себя программистом, потому что с этого я начинал. И сейчас продолжаю как хобби этим заниматься, и мне это интересно и помогает в работе в тех. поддержке. Мне кажется, что нельзя качественно поддерживать продукт для разработчиков, не являясь самому разработчиком хоть в какой-то степени.

Если говорить о твоей работе инженером поддержки, то вот ты вспоминал период, когда ты один поддерживал все продукты на базе IntelliJ-платформы. Это ж, наверняка, множество запросов. Как ты их приоритизируешь, как выбираешь, на какие ответить быстрее, а какие отложить на потом?

У меня все просто. Есть очередь входных вопросов, и я по порядку отвечаю. Если вижу в заголовке восклицательные знаки и надписи, что все сломалось и ничего не работает, ничего не запускается, то да, на такие вопросы стараюсь отвечать в первую очередь. В остальном все в порядке очереди поступления. Старюсь просто очень быстро отвечать, поэтому backlog-а нет. Максимальный backlog в начале дня может быть 15-20 вопросов.

А как тебе удается так быстро отвечать? Бывают же пользователи, которые присылают какие-то огромные куски кода, жалуются на множество проблем. Это все требует времени, чтобы разобраться.

Да, если какие-то сложные вопросы, которые требуют долгого времени, чтобы разобраться, я обычно откладываю. Отвечаю сначала на то, на что могу быстро ответить, чтобы люди не ждали, а потом уже занимаюсь теми проблемами, которые требуют времени.

На самом деле, очень большой процент вопросов – это известные проблемы. И важно просто понять, что это за проблема, и найти уже готовый баг-репорт в трекере или решение какое-то готовое.

Стараюсь отвечать максимально кратко и по делу, без лишних вступлений и прочих дежурных фраз. Использую несколько утилит, которые очень сильно ускоряют работу (основные — шаблоны через AutoHotkey, история буфера обмена с быстрым поиском через Ditto Clipboard и ShareX — для создания и загрузки скриншотов, коротких роликов). Также помогают правильно настроенные оповещения. Начинаешь отвечать сразу в момент появления нового тикета, пользователи бывают в шоке, получив ответ буквально в течение нескольких секунд.

У тебя есть какая-то база известных проблем и решений? Или она у тебя в голове?

База — это интернет и YouTrack. Там все можно найти. Обычно я сначала смотрю в YouTrack. Если ничего не нашлось, то ищу в интернете по каким-то ключевым словам. Очень часто находится ответ на StackOverflow. Иногда бывает, что находишь ответ, начинаешь его смотреть, и оказывается, что ты же сам его и написал. Проблем много всяких, случается, что забываешь, что ты уже этой проблемой когда-то занимался. Мозг уже не способен запомнить весь объем проблем, который через тебя прошел. Также можно поискать в базе всех тикетов техподдержки, может быть кто-то из коллег уже сталкивался с чем-то похожим. Самые частые проблемы опубликованы в публичной Knowledge Base. Есть еще база шаблонов в AutoHotkey, которые раскрываются из мнемонических сокращений (по аналогии с Live Templates в IntelliJ IDEA), в основном это ссылки на какие-то ресурсы или стандартные фразы, используемые при составлении ответа.

Пользователи бывают разные. Кто-то просто вопрос задает, кто-то потом напишет отдельное спасибо, а бывают очень эмоциональные и не слишком позитивные письма. Есть какой-то рецепт, как отбросить эмоции и ответить человеку вежливо и по существу?

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

Скажи, а есть какое-то письмо от пользователя, которое больше всего запомнилось?

Было письмо от 75-летней бабушки, которая поставила себе RubyMine и начала изучать Ruby on Rails. Причем сразу так с места в карьер – до этого она много лет не программировала, последнее, с чем она имела дело, это, кажется, еще перфокарты. И у нее был такой резкий скачок от перфокарт к навороченным клиент-серверным приложениям. У нее была куча всяких вопросов, и она даже где-то не понимала базовых принципов, как это все работает. Но интересное было общение, объяснил ей основы, рассказал, как настроить IDE и окружение.

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

Я учился в университете на 4-м курсе. И что-то мне пришло в голову, что нужно найти работу. До этого у меня не было постоянной работы, были только какие-то подработки. Ну и решил, что пора уже найти что-то постоянное, серьезное. Я пошел на сайт job.ru (тогда был очень популярный) и стал смотреть подряд все вакансии, которые мне хоть как-то подходили, и отправлять туда свое резюме. Стали приходить отклики, я стал ходить по собеседованиям и смотреть, что там предлагают. Я рассматривал вакансии не технической поддержки, а какое-то программирование в основном, веб-технологии (я тогда еще PHP изучал, Perl, HTML, CSS, и т.д.), смотрел вакансии на C и C++ для начинающих. А потом нашел такую вакансию, которая называлась Java User Support. И больше ничего не было написано, это было все описание. Подумал, что интересно – Java я вроде знаю, я ее начал изучать и язык мне нравился. А что такое User Support – наверное, кому-то нужно будет помогать. На тот момент у меня был плагин популярный и форум, на котором я отвечал пользователям. И я подумал, что помогать я умею. Так что я решил, что это может мне подойти, и пришел на собеседование. Оно сначала было в какой-то рекрутинговой компании (в то время пользовались услугами сторонней компании, которая осуществляла предварительный отбор, своего HR отдела не было). Прошел собеседование, и меня пригласили в офис JetBrains. Пообщались, а когда приехал домой, мне сразу перезвонили и предложили работу.

То есть тебя никак не смутило, что это именно поддержка? Тебе хотелось что-то, связанное с IT, а не конкретно разработка?

Да, мне тогда было не принципиально, разработка это или общение с пользователями. А тут еще мне рассказали, что из себя представляет продукт Java IDE, и мне было интересно им пользоваться, разбираться в нем, писать свои программы. То есть была и разработка как хобби, и работа в IT, в развивающейся молодой компании, где можно было набраться опыта и почерпнуть знаний в технологиях (VCS, Refactorings, Unit Tests) и методологиях (Scrum, Pair programming), для меня это все было в новинку.

А за эти 15 лет не приходила мысль, что ты хочешь вернуться именно на full-time разработку?

Для меня разработка – это хобби. Я не могу себя представить занимающимся разработкой full-time за деньги. Мне кажется, это довольно стрессовая ситуация, когда у тебя куча багов в трекере, и их количество каждый день растет.

А поддержка – не стрессовая деятельность?

Поддержка в этом плане отличается тем, что все запросы, которые пришли, можно закрыть. А в разработке (наверное, во многих компаниях так) очередь реквестов разработчика только растет. Мне кажется, это большое психологическое давление. По-крайней мере, для меня было бы так.

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

Но ты же пользователю тоже не всегда можешь помочь? Ведь порою твой разговор с пользователем заканчивается багом в трекере?

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

А у тебя не возникало желания взять и поправить самому?

Бывает. Я несколько раз так делал. Иногда я могу найти место в коде, где проблема, и пишу разработчику, что вот ошибка здесь, исправить можно вот в таком месте. Это, конечно, если проблема находится на моем уровне понимания продукта. Думаю, что даже программисты со стажем в каких-то подсистемах не все знают. Обязанности распределены, вряд ли есть разработчики, которые могут в любом месте быстро найти и исправить любую проблему. В идеале каждый должен заниматься тем, что у него лучше всего получается.

Спасибо за интервью! Новых тебе идей для приложений, спокойных пользователей в поддержке, и чтобы тебе было и дальше комфортно и интересно работать в JetBrains!

Анастасия Казакова, менеджер по маркетингу продукта CLion в JetBrains