Антон Архипов: «В погоне за техническим решением мы часто забываем о пользователе»
Developer Advocate из JetBrains рассказал о своей работе, выгорании, увлечении бас-гитарой и о том, как всё и всегда успевать.
Иллюстрация: Gil Ndjouwou / Oliver Walthard / Unsplash / Colowgee для Skillbox Media
Я работал программистом около десяти лет: в банках, телекоме и даже на фрилансе. Большую часть карьеры программировал на Java, а в 2014 году мне даже вручили «лычку» Java-чемпиона. Но это не значит, что я крутой джавист. Такую награду дают за заслуги перед сообществом. При этом в начале пути я метался по стекам и писал на всём, что подворачивалось.
Первые деньги на программировании я заработал в начале 2000-х. Мне надо было быстро написать программу, которая обрабатывает текст. Для этого идеально подходил Perl: операции, которые в языке C недоступны или трудно выполнимы, в Perl реализуются довольно легко. Поэтому я без колебаний выбрал его.
Затем я попробовал Visual Basic, но вскоре пересел на Java. А в итоге стал продакт‑менеджером в стартапе, который разрабатывал инструменты для программистов, — там я проработал семь лет.
Как я увлёкся пользовательским опытом
Мне нравится писать код и решать технические задачи. Когда твоя программа работает, это всегда мотивирует. Но иногда в процессе разработки замыливается взгляд. В погоне за техническим решением мы часто забываем о конечном пользователе.
Однажды я написал плагин для IntelliJ IDEA и отдал его другому программисту — чтобы отвыкнуть и взглянуть на свой проект со стороны. Месяц спустя я включил плагин, взглянул на код и получившийся интерфейс. Первое, что я подумал: «Как этим вообще можно пользоваться?!» Казалось, что чужие написали плагин для хищников — настолько всё было плохо :)
В тот момент я переключился с мышления разработчика на мышление конечного пользователя. Может быть, именно это повысило мою эмпатию к пользователям, разожгло интерес к юзабилити и даже изменило сознание!
В продуктовой разработке мне нравилось постоянно анализировать данные и генерировать идеи. Но, видимо, «интеллектуальное топливо» постепенно заканчивается, а усталость накапливается. Даже если на работе всё здорово, рано или поздно наступает момент, когда ты садишься за компьютер, смотришь в экран, а написать ничего не можешь.
Так случилось и у меня перед уходом из стартапа. Я понял, что больше не могу постоянно что-то придумывать, поэтому стал Developer Advocate и теперь рассказываю о том, что придумали другие. Вообще, все эти годы извне меня больше воспринимали как Developer Advocate, чем как продакт-менеджера. Поэтому JetBrains часто звала к себе на должность Developer Advocate. А когда наш стартап выкупила другая крупная компания, от «реактивных мозгов» сразу же пришло официальное предложение.
Тогда я понял, что мне нравится изучать технологии и проекты других разработчиков и рассказывать о них людям. А в стартапе я уже достиг всего, чего хотел. Позже я пытался вернуться в продакт-менеджмент, но звёзды не сошлись, да и я ещё не отошёл от последнего выгорания.
Задача Developer Advocate в JetBrains — помогать разработчикам
Пользователи продуктов JetBrains — программисты и технические специалисты. Эффективно продвигать продукт для обеих категорий можно с помощью образовательных материалов, а не рекламы, поэтому мы рассказываем о новых версиях и лучших практиках использования продукта.
Каждая IT-компания выбирает свой способ продвижения продукта среди целевой аудитории. На предыдущем месте я успел побыть в роли Developer Advocate, но по сути был евангелистом: моей главной задачей было продать продукт. В JetBrains у меня нет такой цели. Я работаю с языком программирования, который напрямую не монетизируется.
Продавая что-то, можно попасть в ситуацию, когда задача решается эффективнее без вашего продукта. В таких случаях люди часто усложняют свои проекты, даже не подозревая об этом, потому что считают, что задачи нужно решать именно их инструментом. На самом деле этой сложности можно избежать. В моей практике такое было: я пытался балансировать, но всегда склонялся в сторону пользователя.
Сейчас я нахожусь в более выгодном положении: на меня никто не давит, не заставляет что-то продавать. Моя задача — помогать пользователям. Весь подход JetBrains состоит именно в этом. Даже продвижение коммерческих продуктов всегда идёт через пользу. В такой ситуации приятно находиться и работать.
Ключевые качества и навыки Developer Advocate
Developer Advocate пригодится компаниям, которые создают продукты для программистов. Это не значит, что он должен быть в каждой такой компании. Но если потребность в Developer Advocate всё-таки возникла, то руководство должно понимать: задача этого специалиста — приносить пользу разработчикам. Это не рекламщик и не маркетолог.
Ко мне иногда обращаются компании, которые только вводят у себя должность Developer Advocate, и спрашивают, по каким KPI оценивать его работу. Но разумных KPI для этой должности не существует. Есть лишь определённые качества и умения, которые позволяют эффективно работать.
Технические навыки. Developer Advocate должен кое-что понимать в IT и общаться с программистами на одном языке. Если я говорю с Kotlin-разработчиками, то должен уметь программировать на Kotlin и пользоваться теми же инструментами, что и они.
Если в чате задают вопрос, на который я не знаю ответа, то пытаюсь воспроизвести проблему и решить её. Когда делаю обучающие материалы, всё тщательно проверяю, самостоятельно пишу и компилирую.
Знание языка, умение писать и выступать. Язык программирования — это глобальная технология. Если бы в школе мне сказали, что на работе я буду писать тексты, выступать и снимать видео, я бы рассмеялся. Но вот факт: в школе я писал сочинения на двойки-тройки, а теперь пишу тексты, которые читают тысячи людей. Ирония судьбы!
Сильные стороны, таланты. У многих Developer Advocate есть сферы или занятия в которых они особенно хороши. Например, известные участники конференций — это очень харизматичные и энергичные люди, которые смогли раскрутить личный бренд. Но они не пишут посты в блоги, потому что для них это рутина.
В нашей команде Kotlin-адвокатов мы все очень разные. У нас суперпроизводительный тимлид — Светлана Исакова (@sveta_isakova). Она не любит выступать на конференциях, но зато может написать огромный туториал, знает, как быстро обучить человека новой технологии, и вообще здорово и понятно объясняет.
Ещё у нас есть Себастиан (@sebi_io) — молодой парень, который стал Developer Advocate сразу после университета, что очень необычно для нашей профессии. Обычно сюда идут бывшие программисты с десятилетним стажем. Но Себастиан — очень харизматичный. Он может так рассказать про новую фичу, что всем сразу захочется её попробовать.
Эмпатия. Понимать чувства людей — ещё одна важная составляющая для работы с сообществом. Даже если я жуткий мизантроп, то всё равно должен быть эмпатичным. Моя работа — помогать, и я не имею права назвать человека дураком или обвинить его в том, что он неправильно пользуется технологией, если он обращается за помощью.
Нас приглашают на разные конференции, но сами мы редко организовываем мероприятия. У нас есть KotlinConf, которая уже два года не проходит из-за пандемии. Вместо этого мы проводили онлайн-ивенты — сообщество встретило их довольно тепло.
А ещё нас приглашают на офлайн-мероприятия. Мне поступает много персональных приглашений, но пока я всем отказываю. Просто сейчас невозможно строить планы: сегодня офлайн-мероприятия разрешают, на следующий день — запрещают.
Мне понравился онлайн-формат — он позволяет экономить время и деньги на перелётах. Я знаю мультизадачных людей, которые могут писать код и статьи в дороге, оставаться производительными в любых условиях. У меня же в дороге производительность падает на 95%. Поэтому я не занимаюсь рутиной в поездках, и чем их у меня больше, тем меньше важных дел я успеваю сделать.
Доклад на конференции посмотрят сто человек. Хорошо, если его выложат на YouTube, — тогда ещё кто-то увидит. А моё пятиминутное видео про новый релиз корутин посмотрят 15 тысяч человек. И оно ещё долго будет лежать «артефактом». Поэтому пятиминутные видео гораздо полезнее. Да и делаются они быстрее и проще: дома за своими столом, с микрофоном и лампой.
Работа с комьюнити — это жизнь с телефоном в руках
На отслеживание активности пользователей в разных каналах уходит не менее 50% моего времени. И я сам затрудняюсь определить: это 50% от предполагаемого времени работы или от времени, которое я провёл за компьютером :)
Моя работа предполагает много общения в онлайне, некоторые дискуссии могут тянуться неделями. Поэтому из всех форм переписки я предпочитаю email. Но решать все вопросы с помощью электронной почты тоже не стоит — иначе по каждой теме будет тянуться «паровозик» из 200 писем.
Я много общаюсь на ходу. Например, когда еду в машине, то разговариваю по громкой связи, а когда куда-то иду — отвечаю в мессенджерах. Наверное, со стороны я выгляжу, как подросток, который никогда не расстаётся со своим смартфоном.
Моя работа тесно переплетена с моей жизнью. У меня нет чёткого графика, например, «с девяти до шести». В последнее время я научился это контролировать и, кажется, по вечерам уже почти не работаю. Но на самом деле это иллюзия, потому что телефон всегда при мне, и я периодически отвечаю на рабочие сообщения или захожу в чаты.
Тем не менее я оставляю время для хобби — спортивных тренировок. В прошлом я много занимался спортом: окончил спортивную школу и состоял в юниорской сборной Эстонии по плаванию. Поэтому я не могу жить без физической активности и уделяю тренировкам примерно 10 часов в неделю.
А в прошлом году я решил научиться играть на бас-гитаре, и это меня неожиданно увлекло. Я даже стал заниматься с преподавателем — созваниваюсь с ним один или два раза в неделю, а в другие дни изучаю новые композиции и бренчу в своё удовольствие.
Есть крутые мобильные приложения, которые помогают освоить музыкальные инструменты. Они «слушают» звук, определяют ноту и сообщают, попали вы в неё или нет.
А ещё у меня двое сыновей, с которыми надо заниматься. По вечерам я вожу их на кружки и тренировки. Именно ради детей я перестал участвовать в вечерних митапах и мероприятиях.
Самый большой секрет, как всё успевать, — не пытаться всё успеть. Когда на прошлой работе я начал сильно уставать, то пересмотрел свои приоритеты. Я понял, что не должен работать 20 часов в сутки, а если я что-то не успею, то ничего страшного не произойдёт. Мне больше не стыдно бросить работу на полпути, если на неё не хватает ресурса.