Всем привет! Вашему вниманию — очередной выпуск шоу «Без Слайдов». На этот раз гостем стал Олег Шелаев, Developer Advocate компании ZeroTurnaround, которые делают разные продукты для Java-разработчиков. За время, которое прошло с момента интервью, произошло два важных события:
- Олег получил звание Java Champion
- Компанию ZeroTurnaround купила компания Rogue Wave Software
Поэтому сейчас — самое время для того, чтобы выпустить это интервью. Оно получилось длинным, поэтому, как и в предыдущем случае, я разбил его на две части. Первая часть — перед вами. О чём мы поговорили в ней с Олегом:
- кто такие ZeroTurnaround;
- как стать Developer Advocate;
- о правильном маркетинге;
- о продажниках и инвесторах;
- об инструментах маркетинга и продаж;
- о задачах и проблемах маркетинга.
Получилось много про маркетинг и технологии в маркетинге. А так же о том, что такое «правильный айтишный маркетинг».
Расшифровка как всегда — под катом. Приятного вам просмотра или чтения.
Кто такие ZeroTurnaround
— Дорогие друзья, добрый день! Это «Без слайдов», я — Алексей Федоров. А в гостях у меня сегодня — Олег Шелаев, Developer Advocate компании ZeroTurnaround, которые делают разные продукты для Java-разработчиков. Прежде всего, это JRebel и XRebel. Я ничего не перепутал по части того, что вы делаете?
— Здравствуйте! Да, ZeroTurnaround — это продуктовая компания, мы делаем продукты для Java-разработчиков, которые улучшают их жизнь, производительность и делают их более качественными специалистами. Наш основной продукт — JRebel, у которого также есть специальная версия для Android-приложений.
— Что они делают?
— Они оба подключаются к JVM-процессу (в случае Android — к его процессу), и умеют подтягивать изменения в классах на машине разработчика внутрь этого процесса. То есть разработчик может менять код и без всяких пауз видеть эти изменения.
— То есть без перезапуска.
— Да, без перезапуска JVM-процесса, без перезапуска сервера, новый код будет сразу работать, что ускоряет процесс разработки. Лет где-то 8-9 назад появился JRebel для Java, и пару лет назад мы выпустили JRebel для Android. Вторая линейка продуктов, которая у нас есть, — это XRebel и XRebel Hub. XRebel — это такой инструмент для выяснения производительности кода твоего приложения, наподобие профайлера, но он делает не совсем те вещи, которые обычно выполняет официальный профайлер. Он показывает разработчику, куда уходит время обработки запросов на сервер, и показывает, где могут быть потенциальные проблемы с перформансом.
Делает он это достаточно интуитивно, прямо там же, на машине разработки. Это продукт для разработчиков, и его можно использовать, чтобы, когда ты пишешь код, быть уверенным, что ты написал его не просто функционально корректно, но и что он будет обладать более-менее нормальной производительностью.
— Чем он отличается от YourKit или JProfiler и так далее? То, что есть у OpenJDK и прочих инструментов?
— Функциональное различие одно: XRebel — это профайлер для веб-приложений, он заточен на показывание легкоусвояемой информации для программиста. То есть он встраивает твой виджет прямо внутрь твоего веб-приложения и показывает тебе статистику с сервера в одном месте, в которое ты не можешь не посмотреть.
К тому же, типичные профайлеры будут собирать много информации и показывать её тебе в таблицах, которые ты должен потом каким-то образом обработать. Нужно быть либо специалистом, либо просто знать, куда смотреть, чтобы понять, что вот это у нас узкое место, здесь мы будем терять время на обработку запросов. XRebel показывает для каждого запроса развёрнутое дерево, где код застревал во время обработки реквеста, плюс он туда вставляет небольшие кусочки информации про события, которые, как мы знаем, могут вызвать регрессию в производительности.
Например, общение с базой данных. Он показывает, какие запросы ты делал, когда и сколько, если ты используешь, например, Hibernate или что-то другое, показывает, откуда пришли эти вопросы, почему они делаются, общий вид и, как разработчик, ты сразу видишь: да, вот здесь у нас время пошло сюда, здесь мы запустили background-треды и ждали, здесь мы сделали запрос в Google и ждали полчаса, пока придёт ответ из интернета. И чтобы улучшить производительность, ты должен начинать с самого большого узкого места. Нет смысла оптимизировать места, на которые не уходит много времени, просто потому что прирост производительности будет небольшой.
— Или вообще не будет.
— Или вообще не будет. XRebel тебе очень чётко показывает, куда нужно смотреть. Потом, если тебе нужно производить какие-то низкоуровневые оптимизации и профилировать код, чтобы понять, почему именно здесь было так много и как это улучшить, ты уже можешь подключать профайлер и использовать его, чтобы всё оптимизировать. А XRebel показывает, куда утекло время. Как программист, ты можешь его использовать, чтобы посмотреть, что у тебя на самом деле происходит в приложении: не кликать мышкой через десятки интерфейсов в коде, а запустить отдельный квест и посмотреть, что же именно происходило, когда он обрабатывался.
Ты написал код (для веб-формы/виджета), посмотрел: он функционально работает. На твоей машине он всегда будет работать быстро, потому что у тебя нет данных, у тебя локальная база, у тебя мощная машина и там один юзер. И XRebel тебе может показать, что, да, ты избежал, как минимум, самых грубых ошибок, которые могут привести к потере производительности, и ты можешь его спокойно коммитить и дальше запускать какие-то стресс-тесты.
— То есть это такой инструмент, который позволяет нам выявлять какие-то грубые ошибки из серии «я написал алгоритм за O(n2), а тут я сделал десять запросов базе вместо одного»?
— Да. Помнишь, на кейноуте Алексей Шипилёв рассказывал про «кривую имени Шипилёва»?
— Да. То есть мы в зелёной зоне?
— Мы в зелёной зоне. Мы написали какой-то код, который функционально работает, мы готовы его коммитить, но, в принципе, с ним можно произвести какие-то манипуляции, чтобы он работал быстрее. XRebel помогает тебе избежать самых больших ошибок и регрессий.
— А если это уже жёлтая или красная зона, я беру более сложные инструменты.
— Конечно. Ты берёшь YourKit или подключаешь OpenJDK-шные штуки, honest-profiler или что угодно. Если тебе нужно избегать safepoint bias, то нужны уже другие инструменты.
— Мы поговорили про продукты. Ты — Developer Advocate. Чем ты занимаешься? Что такое Developer Advocate в понимании ZeroTurnaround и в твоём понимании?
— Developer Advocate — это такая должность в компании. Моя основная работа — это работа с сообществом Java-разработчиков. У меня есть две основные задачи — это повышать видимость компании и на своём примере создавать бренд компании, показывая, что в ZeroTurnaround работают умные люди.
— То есть ты умный?
— По профессии я должен выглядеть, как будто я умный. Я не обязательно должен быть самым умным, но я должен быть технически грамотным и уметь общаться с людьми. Вторая большая часть работы — быть каналом сообщения между нашими разработчиками, которые живут в своём, достаточно замкнутом мире Java-агентов, низкоуровневого кода и прочего, и нашими клиентами, которые тоже являются разработчиками.
То есть мы — компания, которая производит продукты для разработчиков. Это не совсем типичный рынок. Какие-то вещи, которые применимы к продаже и рекламе, скажем, хлеба или фастфуда, просто не будут работать на программистах. Если у нас что-то не работает, если есть какие-то проблемы, я всегда должен быть на виду, чтобы вы могли в любой момент к нам обратиться через простой и понятный канал связи с человеческим лицом, и у вас не оставалось сомнений, как, куда и что написать, если вы хотите что-то узнать про наши продукты.
Если вам что-то мешает, вы пишете мне. Я воспринимаю эту обратную связь и передаю её дальше программистам или продукт-менеджерам, и каким-то образом вашу проблему поправят. И если у наших разработчиков есть вопросы, например, какую фичу делать следующей, какие фреймворки делать вперед, следует ли нам сконцентрироваться на Spring, JavaEE, они могут обратиться ко мне, а у меня есть выход в комьюнити и, следовательно, уже какая-то информация.
— А они пользуются этим каналом?
— Да. Мы собираем информацию. Наша команда состоит из трёх человек: я, Антон Архипов и глава нашей Developer Relations Team — Саймон Мейпл. Периодически мы ездим к клиентам. Пусть у Amazon, скажем, 2 тысячи Java-программистов — это уже комьюнити, это достаточно много народу, чтобы у них были свои местечковые проблемы, свои предпочтения.
— Местечковые проблемы у Amazon чреваты проблемами на весь мир.
— У них может отклеиться облако, потому что Java тормозит, у них там свои специфические проблемы. Мы приходим к ним, рассказываем что-то, что мы знаем, расспрашиваем о проблемах, которые у них возникают, что им интересно, как они видят будущее Java-разработки и конкретно их команды. Соответственно, внутри компаний есть маленькие сообщества. И есть большое Java-сообщество, в котором мы пытаемся играть какую-то роль и двигать его вперед, делать его лучше.
Как стать Developer Advocate
— Смотри: ты, Антон и Саймон — все три технических человека, все трое в прошлом — разработчики, причем вы — разработчики в ZT, а Саймон, я так понимаю, уже был известным публичным человеком, когда пришёл в ZT, и разработкой в вашей компании не занимался. Как тебя вообще занесло из разработчиков в, по сути, маркетинг (часть функций, о которых ты рассказал — она маркетинговая), и как для тебя и для компании проходила эта трансформация?
— Разработчиком в ZeroTurnaround я был года три, до этого я писал одно онлайн-казино, а до него был в компании, работающей на публичный сектор. Она создает инфосистемы, в основном внутри Эстонии, но сейчас уже выходит на мировой рынок. Это достаточно большая компания, раньше она называлась Webmedia, сейчас называется Nortal. Там я был просто программистом, пришёл из университета, пытаясь параллельно учиться, и занимался разработкой.
Как я попал в маркетинг — это история достаточно интересная, но немного странная. В 2011 году мы были достаточно маленькой компанией.
— Сколько вас было?
— Я думаю, 20 человек.
— А сейчас?
— Сейчас нас почти 200, но это все — разработчики, sales, маркетинг, админы, services and operations, которые поддерживают наши внутренние системы. У нас где-то 80 Java-разработчиков, может быть 90. Но все команды растут. Сейчас мы доросли до 200 человек. Мы и сейчас пытаемся себя культурно позиционировать как стартап, по крайней мере, внутри компании, чтобы мы были достаточно гибкими, с нормальным процессом разработки. И мы делаем правильные вещи, а не забрасываем проблемы деньгами. Когда нас было 20, каждый человек делал то, что мог для компании. Если нужно было написать пост или съездить на конференцию, «постоять в будке» и пообщаться с потенциальными клиентами…
— «Постоять в будке» — это на сленге Developer Advocate значит «Участвовать со стендом на выставке».
— Да, на стенде. Постоять в будке. Можно посидеть, но это нежелательно, так сложнее общаться с людьми, которые приходят. В 2011 году у нас был небольшой офис в Праге, где были наши маркетологи. В Эстонии, в Тарту и в Таллине были офисы разработки.
— А можно я перебью: а почему в Праге? У вас в Праге, у JetBrains в Праге — что вы все в этой Праге нашли?
— Я не знаю. Но так исторически сложилось, что у нас были маркетологи из Праги: Оливер Уайт, который сейчас в Lightbend, ещё кто-то. У нас была небольшая команда. Оливер очень классный, умеет хорошо объяснять вещи. Ушёл от нас пару лет назад в Lightbend. Они тогда уже были в Праге, и так как мы были маленькой командой, их не имело смысла куда-то перенаправлять, им там нравилось, они работали, там же в офисе был дизайнер.
Кстати, типичный стереотип о том, что разработчики — интроверты, что не все они любят и умеют общаться с людьми, рассказывать что-то снова и снова так, как этого требует маркетинг. В маркетинге самое главное — что? Повторять информацию снова и снова. Потому что тогда люди слышат эту историю, а потом в какой-то момент вспоминают её как свою мысль. И если ты много раз одно и то же говоришь, они тебе начинают верить. Если тебе кого-то надо в чём-то убедить — говори одно и то же много раз на протяжении нескольких лет. Например, что JUG.ru Group организуют лучшие конференции на постсоветском пространстве.
— Да, и что без JRebel — вообще никуда.
— Именно. Если у тебя есть какие-то данные, чтобы это подтвердить, то это ещё лучше. Как-то мы поехали в корпоративный отпуск. Нас было мало, мы съездили на остров Крит, и каким-то образом я попал в группу маркетологов — случайно, вай-фай был в лобби, и я там пытался что-то скачать. Это было в далёком 2011 году. У нас была какая-то цель на полугодие по доходам или по объёмам сделок, мы её выполнили, и компания повезла нас на остров. Так я познакомился с нашими маркетологами, мы целую неделю общались, они увидели, что я не закрытый человек, и позвали съездить с ними на конференцию JavaOne помочь поработать на стенде.
Я съездил. Несмотря на то, что было сложно, мне очень понравилось, и маркетологам тоже. Так как нас было мало, у них особо не было выбора, кто поедет на следующую конференцию, а мы достаточно много участвовали в конференциях как спонсоры — у нас были стенды, нам нужно было каких-то людей туда ставить, и я как-то туда затесался. Потом мы начали развивать наш корпоративный блог, RebelLabs. Мы хотели, чтобы там был технический контент с интересными постами для разработчиков. Маркетологу без технической базы и опыта программирования достаточно тяжело написать такой пост. Поэтому нужно было, чтобы инженеры предоставляли своё время и помогали. Так как у них был выход на меня, они ко мне и подошли, я начал писать, какое-то время этим занимался, может, один день в неделю.
Потом мы решили, что можно вывести это в более концептуально целостную картинку и поняли, что нельзя просто идти к разработчику и говорить, что тебе к пятнице нужен пост на тему корутин в Kotlin, потому что у разработчика свои дедлайны, свои задачи, и даже если ему интересно это делать тогда, когда к этому душа лежит, делать это по расписанию сложно. И тогда я перешёл в команду маркетинга. А после в новую команду Developer Advocate. Соответственно, моя работа очень сильно изменилась, я перестал так много программировать, стал больше ездить по конференциям как участник или же с докладами, вращаться в сообществе и каким-то образом «устраивать» себя как канал. Так я стал более-менее известным, меня сейчас зовут на конференции и на интервью.
Какую роль в бизнесе играет узнаваемость компании
— Какова роль RebelLabs в маркетинге компании? Это блог, несколько десятков тысяч просмотров в месяц и так далее?
— Это блог, мы его ведём примерно пять лет, стараемся туда писать регулярно какой-то вменяемый технический контент, и он служит площадкой для поднятия видимости компании. Люди читают посты, описывающие, как сделать что-то и почему это стоит сделать именно так. Мы делаем опросы сообщества о том, какие инструменты используют разработчики, как они их используют, зачем и так далее.
— Как PornHub практически. Ты видел знаменитый опрос PornHub о том, сколько минут в какой стране смотрят порно, какие слова ищут и так далее? Вы делаете то же самое, но для Java-разработчиков.
— Они, наверное, тоже делают аналитику по каким-то данным, которые они собирают, и потом выкладывают это в публичный доступ. Мы устраиваем опросы на тему того, какие фреймворки идут сейчас на подъём; интересуются ли люди Kotlin; Docker — это хайп или всё-таки его приняли.
— «Docker — это хайп или просто говно?»
— Его каждая энтерпрайз-компания уже ввела у себя и использует вовсю. Или, допустим, является ли k8s следующим шагом после Docker или это такая надстройка, которая нужна operations?
— Где вы берёте людей для этих опросов? Это подписчики блога, у вас есть их имейлы, вы используете Twitter, Facebook — как это происходит?
— Мы используем всё. У нас есть база подписчиков RebelLabs, у нас есть email-база клиентов наших продуктов, у нас есть аккаунты в социальных сетях. Twitter среди разработчиков мне кажется наиболее признанной сетью. Наши маркетологи говорят, что Facebook тоже даёт очень хорошие результаты, но сам я им не сильно пользуюсь, поэтому мне сложно судить. Мы стараемся во всех доступных нам медиаканалах разрекламировать, что мы устраиваем опрос, просим уделить нам 10 минут и ответить на вопросы, а потом, чем больше мы ответов соберём, тем более внятной получится статистика. Всю эту информацию мы пытаемся выложить в публичный доступ, она становится частью бренда. Например, какой-нибудь разработчик из любой страны ищет, как применить лямбду в коллекциях в Java 8. Где-то на первом-втором запросе в Google будет наш блог.
— Видимо, сразу после Stack Overflow.
— Ну, тут зависит от того, какой именно был запрос. Например, «веб-фреймворки» — тут Google очень хорошо относится к нашему контенту. И вот, человек открывает пост, читает его, находит что-то полезное и видит, что сверху написано «ZeroTurnaround», и у него складывается впечатление, что в ZT работают умные люди, и он уже доверяет нам немножко больше. Чтобы что-то кому-то продать (а мы — продуктовая компания, и мы зарабатываем деньги тем, что продаём наши продукты для разработчиков), нужно иметь какой-то запас доверия, чтобы они знали, что мы — компания, продукты которой им, скорее всего, помогут, и если они знают, что там работают умные люди, то и продукты, должно быть, тоже умные.
— То есть часть тактики — показывать, что вы умны, и тем самым повышать доверие к вам и вашим продуктам.
— Ну и обычная видимость, visibility. В следующий раз, когда они увидят название ZeroTurnaround, они будут знать, что мы — те люди, которые им когда-то помогли каким-то образом.
— Если с повышением уровня доверия мне понятно, как это приносит деньги, то каким образом приносит деньги Visibility (можно перевести как «известность» или «заметность» — прим. авт.), мне до сих пор не очень ясно, хотя я занимаюсь вопросами, связанными с маркетингом, уже лет пять.
— Мне это, честно говоря, тоже не очень понятно. Но конкретно у меня всё очень просто. Моя миссия — это заметность и хорошее отношение к нам в Java-сообществе. Если люди вообще не будут знать про нас (если я не очень хорошо работаю), они будут думать, что в ZeroTurnaround работают какие-то странные личности, и с ними лучше не иметь никакого дела. И вот именно с заметностью нам помогает RebelLabs.
Те же отчеты занимают достаточно большое количество времени (подготовка, сбор информации, создание красивого PDF), эти же данные мы используем как вводные для продукт-менеджеров. Когда им нужно узнать что-то, они приходят к нам и говорят: «О, кстати, для XRebel нужно понять, как люди решают проблему с перформансом». И мы задаём вопрос: «Как вы относитесь к перформансу и почему?» И нам отвечают: «У меня в моём проекте от перформанса зависит количество полученных денег. А как мы его делаем? Да никак, потому что не умеем».
И тут уже можно рассказать, как стоит делать перформанс: начните с этой зелёной части кривой Шипилёва, а у нас есть продукт, который мог бы вам помочь. Это пример продукт-контента: в RebelLabs мы можем писать про наши продукты и образовывать. Значительная часть нашей работы — именно образовывать людей, объяснять им, что у них есть проблема. Например, если Java не может перезапустить классы и моментально подтянуть их в работающий процесс, есть решения, которые могут починить это. Если человек привык работать так, как он работает уже десять лет, ему очень сложно признать, что, на самом деле, от этого можно избавиться. Нам нужно его научить.
— Про блог RebelLabs: можешь назвать процент контента, который совсем не связан с вашими продуктами и просто демонстрирует, что вы умные, классные, даёт интересную статистику и процент контента, который с продуктами связан?
— Я думаю, 80% контента не связано продуктами. Это посты, которые заинтересовали меня, мы все подумали и решили, что они также будут интересны какой-то крупной группе разработчиков — например, джуниорам. Или уже более глубокие посты, которые никак не связаны с нашими продуктами.
— Фактически, это продукт-плейсмент, где, скажем, каждый пятый пост затрагивает ваши продукты.
— Грубо говоря, это так, но не совсем. Просто иногда у нас есть что-то интересное, что можно рассказать про наши продукты. Сюда не входят пресс-релизы о том, что у нас, например, вышла новая версия JRebel, — это проходящие посты, их нужно писать. Там должен быть, скажем, changelog или пост о том, почему мы сделали ту или иную вещь. Например, когда мы писали JRebel, нам нужно было организовать большую матрицу тестов: наш продукт должен работать на всех JVM с десятком application-серверов на пять версий плюс двадцать фреймворков на каждой, потому что из-за всех этих комбинаций всё может сломаться. Мы пишем эти тесты. И в блоге мы хотим написать о том, как классно мы это сделали, что мы выучили такие-то уроки и используем TestContainers, чтобы организовать это всё.
— Ты очень занятно говоришь, видно, как у тебя в голове постоянно идёт перевод с английского на русский. Ты как-то сказал вместо «делать вещи» — «делать штучки». И вот сейчас тоже. Ты много говоришь по-английски и мало по-русски?
— Да, по-русски я очень редко общаюсь. Русский — мой родной, но я его использую в более-менее неформальной обстановке, с друзьями или дома. Собаку я бы тренировал узнавать команды на русском, но в профессиональной обстановке я русский очень редко использую, поэтому мне иногда тяжело подобрать слова. А английский — это рабочий язык компании, и моё ежедневное общение происходит даже не на эстонском, а на английском, хотя мы в эстонском офисе.
— Это ни разу не упрёк с моей стороны, это просто дико интересно наблюдать.
О правильном маркетинге
— Итак, мы поговорили о компании, продуктах, о твоей роли и о блоге. А теперь хочется немного поговорить про предметную область. Объясню, почему. Очень часто мы с айтишными людьми говорим про виртуальные машины, про продукты и так далее, но очень мало говорим про маркетинг. Это важная вещь. Мы уже много знаем про процессы в компании, Scrum, Agile. Про то, как хорошо писать код с лямбдами и без лямбд, какой модный язык Go и прочее. А про маркетинг весьма мало. Вещи, которые меня безумно интересуют — это метрики, инструменты и, может быть, ценообразование.
Меня в детстве научили, что маркетинг должен быть построен на данных. Я знаю, что вы собираете или пытаетесь собирать какие-то данные. Какие данные получается собрать, а какие — нет? С точки зрения метрик данных, что бы ты ещё хотел собирать, но не понимаешь, как?
— Это хороший вопрос. Начну с общего — что мы собираем и что мы хотели бы собирать. Мы собираем данные про каналы использования. На каких-то стадиях использования продукта есть опция, чтобы продукт делал запросы на наши сервера и рассказал, что он сейчас делает. Это начинается с веб-сайта. Расскажу на примере JRebel: сначала человек приходит на RebelLabs, потому что что-то погуглил, потом он смотрит — ага, продукты, переходит на страничку JRebel, читает её, скачивает.
— То есть там есть реферрал в браузере, который сказал, что мы пришли с JRebel, там идут какие-то метки.
— Там отдельный набор метрик для сайта, трафика и прочего. Потом, когда начинает работать сам продукт, он тоже может послать какие-то данные: сейчас меня скачали, сейчас я установился как плагин в IDE, сейчас меня привязали к какому-то проекту, который сидит в Workspace, и сейчас произошла первая перезагрузка классов, первый reload.
— Можно вопрос: некоторые люди работают с живыми продакшнами, с какими-то системами, которые могут быть связаны с безопасностью, с деньгами, с чем-то подобным. А вы некоторые пользовательские данные отправляете на свои сервера. Как вы это решаете? Человек какую-то галочку ставит, или вы тщательно выбираете те данные, которые вы отправляете? Я понимаю, что это тонкий вопрос, но если в общих чертах?
— Мы не отправляем «домой» никаких конфиденциальных данных. Метрики, о которых я сейчас сказал, — это просто пинг о том, что «сейчас я в такой-то стадии процесса. Меня запустили, меня установили». Он не говорит, куда его запустили или ещё что-то такое. Просто есть уникальный идентификатор, чтобы мы могли проследить, что для этого клиента для инсталляции были сделаны такие-то шаги. JRebel, как, практически, и все продукты сейчас, отсылает некоторые данные домой. По-моему, они сейчас опциональны, то есть если у тебя совсем конфиденциальная информация, то ты можешь просто при инсталляции сказать: «Пожалуйста, не отправляй ничего «домой».
— Да, сейчас модно так делать.
— Если у тебя большая компания, которая занимается разработкой финансового программного обеспечения, у тебя есть процессы, которые там стоят. Ты с бухты-барахты на свою машину не поставишь вообще ничего. В некоторых компаниях у тебя просто нет доступа в интернет с твоей машины. Когда тебе что-то нужно посмотреть на Stack Overflow, ты «переключаешь рычаг», на твой монитор выводится картинка с другой машины, и ты можешь погуглить.
— Ну или личный ноутбук сбоку открываешь.
— Метрики, которые мы собираем, достаточно безобидны. Наши продукты отсылают домой метрики про то, какие технологии используются, это делается выборочно. Просто статистика. Например, мы берём какой-то срез, и видим, что у нас заинициализировался плагин Spring, и мы знаем, что, наверное, пользователь использует Spring или какую-то версию Java и так далее. Это помогает не следить за нашими клиентами, а понять, чем именно они пользуются, чтобы в дальнейшем улучшить разработку. Эти метрики не так-то просто придумать и сделать, хотя, казалось бы, что этот процесс достаточно очевиден: нужен customer journey через твою систему, чтобы видеть, что, скажем, плагин инсталлируется, а проект не конфигурируется.
Что нужно сделать? Нужно каким-то образом облегчить конфигурацию или изменить вид меню или сделать какие-то подсказки и сказать пользователю, что вот тут он что-то не сделал. Или они конфигурируют, но при этом перезагрузка классов не происходит. Может, они что-то неправильно сконфигурировали или ещё что-то. То есть мы знаем, куда копать и где улучшать. В итоге от сбора этих данных всем становится лучше.
Sales и инвесторы
— Как эти данные используют разработчики — понятно. Вы видите, что там, очевидно, кнопку не нажали, и ничего не работает. Как это использует маркетинг?
— Начнём с истории. Когда мы начинали, JRebel продавался просто, как архив с сайта. Клиент мог прийти и сказать: «Вот моя кредитка, я хочу один JRebel», скачивал zip-файл, в котором сидел jar-файл, и устанавливал его. Мы наивно думали, что JRebel – такой хороший продукт (а он действительно хороший, все радовались, говорили, что вообще не представляют жизни без JRebel, он такой классный), что он будет продавать сам себя. Нам не нужны сейлзы, нам не нужна команда и какие-то процессы. В один прекрасный момент это мнение поменялось, и мы начали набирать sales-команду.
— Можно задать странный вопрос: связано ли это мнение с приходом инвесторов? Обычно инвесторы, вкладывая деньги, хотят, чтобы эти деньги в компанию вернулись. Я так понимаю, у вас были раунды. Сейчас у вас большой отдел продаж. Чувствуется ли в этом рука инвестора?
— Скорее, это собственное понимание того, как надо развивать продукт. У нас есть совет директоров, инвесторы, у них свои собственные интересы, и в какой-то момент стало ясно, что чтобы компания росла, чтобы было интересно её развивать, чтобы мы могли нанимать больше людей и делать наш продукт лучше, невозможно просто использовать inbound-маркетинг, который подразумевает, что нас сами находят и хотят, а нужно создавать отдел продаж. Наши инвесторы (это открытая информация) — Bain Capital (они же и у Hazelcast), мы с ними работаем уже достаточно давно. Компания изначально приносила прибыль, и мы какое-то время жили на эти деньги, но когда было принято решение, что нам нужно развивать компанию гораздо более быстрыми темпами, был раунд.
Инструменты маркетинга и продаж
— В тот момент уже был отдел продаж?
— Он тогда начинался, был в задумках. Bain Capital дали нам экспертизу, помогли. Наш sales-офис находится в Бостоне, там же, где и они. Они нас познакомили с полезными людьми. Они очень большая компания, 20 лет на рынке. У них всё серьёзно, есть большое портфолио, и вообще они молодцы, сильно нам помогли.
Потом мы начали делать отдел продаж. Изначально он был в большой степени основан на идее, что наши продукты настолько хорошие, что люди сами их захотят. С помощью холодного обзвона мы собирали списки Java-программистов по всему миру и складывали их в LinkedHashMap. Сейчас у нас Salesforce для продаж, как и у каждой второй большой компании, и Marketo для нужд маркетинга. В Salesforсe — информация о клиентах, кому и когда мы звонили, кто купил, когда были сделки, когда звонить в следующий раз, когда кончится лицензия, когда написать письмо и так далее. В Marketo информация про потенциальных клиентов, про лидов из практик Lead Generation.
— Я думал, у вас это в CRM. Обычно там можно делать воронку, начиная с лида.
— Практически для всех маркетинговых нужд у нас Marketo. Все имейлы, которые мы пишем, открыты — можно ткнуть на любую ссылку, эта информация пойдёт через серверы Marketo, там отметит, что такой-то человек ткнул на такую-то ссылку, и в этой статистике нам всё покажут. Соответственно, когда мы собираем контактные данные, когда они скачивают репорты или просто оставляют свою информацию, когда скачивают trial JRebel или XRebel, они заполняют форму, что я — Олег Шелаев из такой-то компании скачал и хочу попробовать этот продукт, эта информация приходит в Marketo и выпускается в оборот. Если я через две недели не попробовал или же попробовал, но ничего не сказал, мне придёт имейл.
— Вопрос: кто понимает этот триггер? Это делает Marketo? Что человек скачал и не купил. Или это Salesforce делает?
— Я думаю, это Marketo.
— Я правильно понимаю: вот я купил лицензию на ваш продукт на 365 дней, у меня осталось где-то две недели, и Marketo скажет вам, что надо послать мне письмо, потому что у меня заканчивается лицензия, и я её ещё не продлил. Так?
— Да, так эта система работала. Сейчас у нас немного сместился фокус на большой энтерпрайз, мы стали меньше звонить и пытаться найти контакты разработчиков, стали больше концентрироваться на существующих аккаунтах, помогать им использовать весь потенциал наших продуктов. Если в компании купили 200 лицензий, а используют лишь 100 из них, то в следующем году они уже эти 200 лицензий не купят. Скорее всего, они изначально купили столько, потому что у них есть разработчики, которым это было бы интересно, но у них не получилось использовать наш продукт, или же их что-то отвлекло.
У нас есть небольшая команда Customer Success, они специально работают с сейлзами и с клиентами и пытаются им помочь всё это сделать. Соответственно, если это большой аккаунт, то, когда заканчивается лицензия, наши сейлзы связываются с менеджерами компании, ведь в больших компаниях разработчик не машет своей банковской карточкой и не говорит: «Два XRebel этому господину!» Скорее всего, там есть аккаунт-менеджер или тимлид, какой-то отдел, который сертифицирует, какими инструментами можно пользоваться. Там есть кто-то, кто занимается бюджетом, с ним мы и будем связываться.
— Во времена моей работы в Oracle там было специальное место в интранете, где я мог качать определенный софт. Там были разные версии разных тулов, обычно не самые последние, в среднем годичной давности. Становилось понятно, что у нас есть лицензия вот на это и на это, а на то — нет.
— В большой компании будет так: если тебе что-то нужно, например, жить не можешь без XRebel, с ним будешь лучше программировать и выполнять задачи, ты приходишь к тимлиду или к твоему непосредственному начальнику и говоришь, чего ты хочешь. Он соглашается, но сразу не станет тебе его покупать, тут есть какой-то свой процесс, человек с бюджетом, надо сначала этот продукт попробовать, выкатить это всей команде — немножко странно давать тул одному человеку, который сильно об этом попросил, потому что, если это хороший инструмент, было бы классно обрадовать всю команду. Если это не очень хороший инструмент, может, не очень и надо. И мы сейчас сконцентрированы на этих enterprise sales, на большие аккаунты.
Во всём виноват маркетинг
— В какой-то момент о ZeroTurnaround ходили шутки, что у вас очень агрессивный отдел продаж: звонят, пишут — не отвязаться от вас.
— И звонят, и пишут. Признаюсь, мне немного жаль, что в какое-то время люди были не очень довольны. Продукты хорошие, но агрессивная политика отдела продаж выводит людей из себя. Было очень печально это слышать. Во всём же винят маркетинг. Когда кто-то виноват, виноват маркетинг, несмотря на то, что это была прямая работа сейлзов. Мы, как канал общения между компанией и нашими клиентами, пытались снова до этих людей дозвониться, написать, понять, что произошло, как это произошло, извиниться. Кому-то мы отправляли корзинки с цветами и вином. Например, мы звонили человеку в течение недели несколько раз, и когда он сказал: «Пожалуйста, я знаю вашего CEO, я два раза в год вижу Евгения Кабанова, мы хорошие друзья. Если мне нужен будет JRebel, я знаю, где его взять», мы ему всё равно продолжали звонить — галочка в Salesforce не поставилась о том, что не надо больше звонить.
И поэтому мы таким образом пытались извиниться. Просто потому что по-человечески это правильно. В какой-то момент всё это стало сходить на нет. Или люди стали терпеливее, или у них внимание с Twitter стало рассеиваться настолько, что звонок им уже не мешает. Вообще мы знали, что такая проблема существует. Это — часть стратегии. Когда твои продажи построены на том, что ты индивидуально контактируешь с сотнями Java-разработчиков, у тебя обязательно будут 2%, которые скажут, что вы уже надоели, хватит им звонить, будут публично писать об этом в Twitter или на Reddit. С другой стороны, 98% будут работать, потому что для них это нормально, это их сильно не тревожит. Те 2% случаев, о которых мы слышали, — это очень печально, но это, скорее, исключение из правила.
— У меня есть любимая дихотомия в этом бизнесе, она такая: есть некоторые разработчики, которые пользуются вашим продуктом. Сначала они читают блог RebelLabs, потом скачивают trial, пользуются две недели, а потом они не идут покупать ваш продукт со своей карточки, а вы бы их потом оттрекали, увидели транзакции, оплату лицензии и так далее; они идут к тёте Маше из бухгалтерии и говорят, что вот это вот надо купить. Тётя Маша покупает это всё по безналу, и у вас выстраивается маркетинговая цепочка. С точки зрения CJM (Customer Journey Map) довольно трудно связать покупку тёти Маши с конкретным моментом, когда человек пошёл на сайт, что-то скачал, попробовал. Как у вас это делается?
— Это действительно проблема, не для компании, а больше для Developer Advocacy. Для компании всё хорошо — у неё покупают продукты, она счастлива. Проблема в измерении, насколько я продуктивен. У отдела продаж очень просто — у них есть цифры: за квартал им надо продать столько-то. Ты получил эту цифру в конце — ты молодец, не получил — не очень молодец.
— Но тогда там довольно тяжело понять, как эти KPI ставить. Иначе мы ввязываемся в игру, где наши продажники выполнили прошлый план, мы им заплатили слишком много премий, давайте мы им сделаем план на 20% больше в следующем году. Начинается сложная игра.
— Это игра немного другого порядка, когда у тебя проблема в том, что ты выполнил план, но тебя немного жаба душит деньги платить. Это, с одной стороны, хорошая проблема: план-то ты выполнил.
— Смотри, если я выполнил план, сказать тебе, что будет в следующем году? Мой план повысят. Надо было продать столько, а теперь — ещё больше.
— Да, но ты понимаешь, что у тебя сложный процесс продажи. Это не эмоциональная покупка, как жвачку на кассе взять, и ты знаешь, что ты продал два контейнера жвачек, в следующем году ты сделаешь полку больше, и тебе надо будет продать три контейнера жвачек. У тебя есть прогноз, sales-команды, которые работают с аккаунтами, с увеличением аккаунтов, нахождением новых команд, работают с индивидуальными разработчиками и пытаются найти новый бизнес, у них у всех строятся прогнозы.
— Новый бизнес — это новый корпоративный клиент?
— Да, или же новые разработчики, или найти одного разработчика, который ещё не использовал наш продукт, дать ему попробовать, чтобы он начал пользоваться. Даже если он сейчас не купит, позже это может вырасти в целую команду. И у тебя всегда есть какие-то прогнозы: в этом месяце у нас будет пять сделок, есть метрики о том, сколько это всё денег принесёт, какие-то вероятности и прочее. У отдела продаж машина метрик очень хорошо отточена.
— Лучше, чем у вас?
— В маркетинге немного непонятно, потому что у нас маркетинг играет скорее вспомогательную роль для сейлзов. Маркетинг про что? Про любовь и истории.
О задачах и проблемах маркетинга
— Storytelling.
— Да, это storytelling, так, чтобы клиент прошёл этот путь от незнакомого человека до фаната твоих продуктов. В этом вся суть глобальной задачи маркетинга. Плюс для сейлзов туда идут месседжинг, брендинг, как сказать, что сказать, кто наши конкуренты, как мы позиционируем себя по отношению к ним, что говорить, где мы лучше и прочее. Это задачи маркетинга. Сами эти вещи говорят сейлзы. Люди встречаются на конференции и спрашивают: «А кто вы?» «А мы пишем JRebel». «А чем он лучше HotSwap?» И тут сейлзы знают, что отвечать: маркетинг им рассказал, что в HotSwap можно менять только тело метода, а это ничтожное количество изменений, и когда он не работает для всех остальных изменений — это ещё хуже, чем когда он работает. А JRebel может всё, и, таким образом, выигрывает у HotSwap или каких-то других конкурентов. Этим занимается маркетинг. Метрики в маркетинге более расплывчатые, потому что KPI сложно ставить, они не очень явно влияют на деньги и на bottom line.
— Тут я бы ещё поговорил, конечно. Мы с тобой, кажется, уже обсуждали
Нортона и Каплана и работу с Balanced Scorecard. Мне кажется, это скорее от непонимания всего процесса. Маркетингу в этом плане лучше, он больше про бизнес и бизнес-функции. Проблема с измерениями. Но их, в принципе, можно настроить.
— Можно, и это делается, но это не так явно и не так просто, как с чёткими числами. Например, ты программист, у тебя есть набор тестов, и ты знаешь, что, когда покрытие кода 90% и когда у нас всё зелёное, мы в порядке и мы молодцы.
— И ты можешь спокойно идти домой, и шансы, что тебе позвонят ночью на выходных, очень малы.
— Они равны 10%, которые не покрыты тестом. А с маркетингом немножко сложнее. Если у тебя есть месседжинг или ты пытаешься понять, что лучше работает, какими словами тебе описывать продукт, какие документы показывать потенциальным клиентам, когда они хотят твой продукт купить, но у них сомнения, а будет ли это работать с WebSphere, тут уже больше метод проб и ошибок. Когда ты строишь диаграммы и модели и пытаешься сконцентрировать свои усилия на чём-то, ты можешь это сделать тем или иным способом, например, есть фреймворк и стратегия, цели, тактика. Но работает ли это?
— Мы сейчас возвращаемся к тому, что в основе маркетинга должны быть гипотезы, операционализация, проверка и фидбэк — весь этот цикл. Это очень мало кто понимает. Есть у вас такого типа метрика: сколько раз с вашего сайта скачали дистрибутивов JRebel?
— Да, такая метрика — достаточно простая, иногда бывает обманчива, но мы считаем, что, например, (с потолка сейчас цифры возьму) 50% скачанных JRebel инсталлируются, 80% установленных JRebel конфигурируются. У нас получается типичная воронка. Естественно, когда кто-то просто берет trial, они сразу не покупают, но обращаются в отдел продаж, мы с ними общаемся, показываем демо всей их компании, команде, и там дальше снова начинается воронка.
— А если я поставил JRebel, попользовался, у моего дистрибутива есть уникальный id, можно потом как-то проследить, что я его купил? Именно тот, который я качал — оттуда ключик пришёл на сервер. Связать покупку и инсталляцию.
— Скорее, нет. Конечно, это можно сделать, когда у тебя какие-то большие платформы или что-то, что идёт всей команде. А когда у тебя индивидуальный разработчик, он ставит что-то, пробует, и практически никогда он сам это не покупает, это всегда идёт обходным путём. Мы можем это каким-то образом связать, но это тоже будет, скорее, ретроспективно. Мы не сможем следить через весь путь, как человек попробовал, пошёл к менеджеру — это на стадии, когда он ещё не стал нашим клиентом. Но задним числом, когда сделка закрыта и ключ куплен, мы уже это сказать можем. Я точно не знаю, делаем ли мы это.
— Все, с кем я общался, говорят, что ты никак не отследишь связь, но это можно выяснить только после сделки.
— Да, так можно. Но, если подумать о том, как работают метрики, можно понять, что это не всегда помогает. Мы бы хотели, чтобы метрики и какие-то данные, которые они собирают, подсказывали нам, что делать дальше, чего нам делать больше, куда нам концентрировать свои усилия.
Автор: Алексей Федоров
