Про маркетинговые исследования в JetBrains из первых рук

Мария Антропова, руководитель отдела маркетинговых исследований JetBrains, рассказывает разработчику и девелопер-адвокату проекта Kotlin Евгению Петренко о своей работе, команде, интересных задачах и планах на будущее. 

Ваша команда существует достаточно давно. С чего вы начинали и какие исследования проводите?
Я пришла в команду ReSharper как аналитик в 2012 году. Постепенно ко мне присоединялись другие аналитики, и в какой-то момент мы сформировали команду и стали частью отдела маркетинга.

Мы проводили продуктовые опросы, анализировали рынки и продажи. Это были небольшие задачи, которые отвечали очень конкретным запросам наших коллег.
Сейчас мы занимаемся не только классическими маркетинговыми исследованиями (в основном это опросы и анализ открытых источников), но и ценовыми исследованиями, делаем описания персон пользователей продуктов, анализируем популярность различных технологий, строим статистические модели, проводим исследования User Experience. Отдельный пласт работы — это посредничество между коллегами и внутренними системами статистики. По запросу мы выгружаем и анализируем данные из разнообразных внутренних и внешних источников.

Maria Antropova

Большая часть наших задач связана с проведением опросов. Мы изучаем как экосистему разработки в целом, например, в нашем самом большом ежегодном исследовании Developer Ecosystem Survey, так и ее отдельные части, например, в партнерском опросе Python Developers Survey, проводимом совместно с Python Software Foundation. Кстати, как раз сейчас мы проводим Developer Ecosystem в третий раз и приглашаем всех поучаствовать.

С чего начиналось исследование Developer Ecosystem?

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

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

Сейчас мы проводим более десяти опросов в месяц (сюда также входят внутренние опросы, опросы на мероприятиях, опросы для партнеров), но основной поставщик данных — это все же Developer Ecosystem.

Насколько трудно работать над исследованием Developer Ecosystem? Много ли времени занимает такой проект?

Чтобы оценить масштаб работы: расчетное время подготовки проекта Developer Ecosystem Survey 2019 — около 9 месяцев от разработки опроса до выпуска инфографики. Почему так долго? Там огромное количество вопросов. Каждый год нам нужно аккуратно перепроверять всю логику опроса, уточнять, что все вопросы по-прежнему актуальны, добавлять новые, если нужно. Для этого мы общаемся с представителями всех продуктовых команд и маркетинга.

Много времени занимает сбор данных: мы должны четко распределить все каналы распространения опроса и собрать нужное количество ответов. После первого Developer Ecosystem Survey внутри компании звучали вопросы, насколько наши результаты репрезентативны. Ведь мы опрашиваем аудиторию JetBrains, а она может отличаться от сообщества разработчиков в целом. Впрочем, как и аудитория любой другой компании. Поэтому опрос Developer Ecosystem распространяется двумя способами: через каналы нашей компании и рекламу: Twitter, Facebook, Google AdWords и др. Мы отдаем себе отчет, что bias1 может присутствовать и там: люди с большей вероятностью будут участвовать в опросах компании, которую они знают. Однако проанализировав результаты, мы выяснили, что они не сильно различаются при сравнении данных из каналов компании и рекламных каналов, разве что в вопросах использования наших продуктов, и вполне сопоставимы с результатами сторонних исследований. В этом году мы будем тестировать новые методы обеспечения репрезентативности, но это пока секрет.

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

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

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

Абсолютно. Если ты не знаешь и не можешь доказать, выстрелит идея или нет, ты рискуешь и смотришь: полетело или не полетело. Хочу спросить о том, какие трудности бывают в вашей работе. Эта область отличается от разработки. Может быть, возникают какие-то сложности еще и при взаимодействии с коллегами?

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

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

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

Как вы организуете работу над большими исследованиями? Наверное, возникает потребность в менеджере, а точнее, человеке, который выполняет функции коммуникатора?

«Менеджер» — это громко сказано. Как таковых менеджеров, которые занимались бы только организацией работы над проектом, у нас нет. Есть основной аналитик проекта, который занимается и всеми административными задачами. В масштабах команды менеджерскими задачами занимаюсь я, но при этом у меня есть и свои исследовательские задачи. К тому же я всегда изучаю результаты исследований всех членов команды.

У нас в команде есть еще и технический лид, который обеспечивает всю инфраструктуру и отвечает за качество используемых данных. Есть два разработчика. Один специализируется на базах данных, помогает с SQL, ETL. Второй занимается full-stack разработкой и помогает нам делать визуализации отчетов и инфографик. Есть аналитики — те, кто проводит исследования с большим маркетинговым и качественным уклоном. Есть технические аналитики, которые на самом деле data scientist’ы, просто у нас они исторически зовутся техническими аналитиками. Сейчас мы, кстати, ищем такого специалиста и разместили вакансию на HeadHunter. Мы ждем классного человека в команду, который поможет нам строить статистические модели.

Кстати, меня радует динамика в сфере data science на рынке вакансий. Пять лет назад, когда мы искали себе первого технического аналитика, откликов было очень мало, а подходящих людей еще меньше. В основном подавались те, кто занимался анализом в SPSS — системе для статистических расчетов с графическим интерфейсом. Это не R, где ты пишешь код. Это система, предназначенная для социологических и психологических исследований. Там можно писать скрипты, но по большому счету они не такие гибкие и удобные.

Расскажи поподробнее про технологии, которые вы используете?

У нас основной язык — это R, на нем написаны все скрипты для обработки данных и автоматизации. Опросы почти полностью автоматизированы. После того как мы получаем данные, обрабатываем их с помощью скрипта на R (который мы пишем еще до запуска опроса), у нас автоматически генерируется отчет в Google Doc, в котором содержатся все таблицы. Остается только выводы дописать руками. Сборка делается с помощью TeamCity. Весь код храним на GitHub.

Правда, что небольшую ошибку обработки данных можно исправить за несколько минут?

Сейчас уже да. Можно переписать пару строк кода и получить новый Google Doc за считанные минуты.

Это очень круто!

На самом деле обработка данных и подготовка отчета сейчас стали одними из самых быстрых этапов всего процесса.

Не так давно мы решили полностью пересмотреть процесс работы над опросами. Теперь мы пишем код по обработке данных перед тем, как запускаем опрос. Это нужно для того, чтобы моментально обрабатывать полученные данные, тестировать опрос и сразу ловить баги логики. Логика — это разветвление опроса в зависимости от ответов респондента. Когда человек проходит опрос, он обычно не замечает, как перенаправляется на разные ветки.

Итак, мы пишем код, все тестируем, проводим ручное тестирование. Потом мы запускаем внутренний пилот — тестируем наш опрос на небольшом количестве сотрудников JetBrains. Для настоящего пилота мы используем первые 100 ответов реального опроса, чтобы проверить, все ли в порядке.

Дизайнеров мы тоже стараемся привлекать на самых ранних стадиях. Вообще в проведении опроса и в подготовке инфографики участвует много команд: email-маркетинг, интернет-маркетинг, веб-разработчики, дизайнеры, переводчики, менеджеры по маркетингу продуктовых команд и другие сотрудники.

Как вы используете SurveyGizmo? Можно ли там смотреть результаты опросов онлайн в реальном времени?

Если надо прикинуть на глазок, то SurveyGizmo предлагает онлайн-отчеты. Но там данные с шумом (боты, дубликаты, фальшивки), поэтому нужно их выгружать и готовить отчет. Создавая опросы в SurveyGizmo, мы кликаем в UI. Нельзя создать опрос целиком через API, логику все равно придется прописывать вручную. Естественно, у нас есть question library, откуда мы берем вопросы. За годы работы у нас уже отточились формулировки, каждый опрос вычитывается. Developer Ecosystem Survey мы переводим на 8 языков, чтобы не было bias по англоговорящим разработчикам. Через API SurveyGizmo мы, например, чистим данные в соответствии с GDPR2. Выгрузка результатов опросов тоже делается через API.

Чем еще занимается ваша команда?

Год назад мы начали проект по анализу локальных рынков — исследуем перспективы продвижения наших продуктов в конкретных странах. Выйти на новый локальный рынок сложно, его нужно изучить, понять, какая там обстановка, какие особенности, конкурентные ситуации, нужна ли локализация или достаточно англоязычного продукта и его поддержки. Список стран для анализа составлялся с помощью статистической модели, учитывающей множество разных параметров, и потом согласовывался с отделом продаж. Для каждой страны мы проводили PESTLE-анализ, исследовали IT-сектор и анализировали наши внутренние статистики.

Еще один интересный проект — персоны пользователей. Персона пользователя — это искусственно созданный образ, представляющий определенную группу людей, которые используют продукты, сервисы, каналы коммуникации или любые услуги компании определенным способом. Несмотря на то, что персоны — это обобщенные выдуманные персонажи, обычно они имеют лицо, имя и некоторые характерные детали биографии. Мы проводили интервью с пользователями PyCharm и на их основе создавали персон для команды разработчиков.

Скажи, пожалуйста, как попасть к вам в команду. Куда идти, кому писать?

Если кому-то близко то, о чем я рассказала, можно отправить резюме в наш HR-отдел. Мы готовы рассмотреть интересного кандидата, даже если нет открытой вакансии. Для позиции Data Scientist нужно иметь опыт программирования, обязательно писать на R или Python. Нам не подходят системы SPSS, MATLAB, Statistica — они вне нашего стека технологий. Необходим опыт создания статистических моделей. Нужен хороший уровень английского языка, как письменного, так и устного, что для некоторых вакансий является одним из решающих факторов. Например, сейчас мы ищем кандидата на позицию UX-researcher с высоким уровнем владения английским для взаимодействия с англоговорящими пользователями.

Какие планы есть у вашего отдела на ближайшее будущее?

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

Здорово. Спасибо большое!

Eugene Petrenko


1. Систематическое искажение статистического результата.2. Генеральный регламент о защите персональных данных (англ. General Data Protection Regulation) — постановление Европейского Союза, которое регулирует защиту персональных данных всех лиц в Европейском Союзе.