Отношения с разработчиками (DevRel)
DevRel (relations with developers — отношения с разработчиками) описывает процесс активного взаимодействия с инженерами и учёта их потребностей при создании вашего продукта в попытке развить и поддерживать прочные отношения с сообществом разработчиков.
Разработчики всегда были и остаются важной частью разработки продукта. Не только потому, что инженеры создают продукты, которыми мы пользуемся, но и потому, что привлечение инженерного сообщества в качестве сторонников вашего продукта может обеспечить вам успех или погубить его.
В некоторых секторах руководители продуктов заискивают перед инженерным сообществом, потому что знают, насколько полезно для некоторых продуктов иметь поддержку инженерного сообщества.
Но инженеры также могут быть непостоянными и непредсказуемыми, поэтому установление с ними долгосрочных отношений — непростая задача.
В этом посте мы рассмотрим, почему DevRel важен, что он означает для вашей продуктовой стратегии и как вы можете развить свои отношения с разработчиками.
Почему мне стоит беспокоиться об отношениях с разработчиками?
Web3, криптовалюты и рост сообществ
В течение последних нескольких лет взаимодействие с сообществом инженеров было центральным фактором успеха продуктов, включая крупные проекты в Web3. Обычно продукты Web3 ищут не только инвесторов, но и инженеров для поддержки своих блокчейнов.
Обанкротившийся токен $LUNA, который недавно потерял практически всю свою рыночную капитализацию в $40 миллиардов, теперь пытается заново изобрести себя с помощью нового токена. И отчасти это возможно благодаря инженерному сообществу, которое он культивировал до своего падения в хаос.
С тысячами разработчиков, уже купивших экосистему Terra / Luna, сработала концепция «затонувших затрат», и инженеры, которые создавали что-то на основе исходного блокчейна — многие из которых также являются инвесторами — всё ещё хотят, чтобы проект преуспел.
Основатель $LUNA До Квон ясно дал это понять в своей серии твитов после краха токена:
Но я знаю, о чём вы думаете… это же криптовалюта. Можем ли мы поговорить о настоящих продуктах, пока так называемый Web3 не разберётся, что, чёрт возьми, это такое на самом деле?
Хорошо, конечно.
За пределами Web3 продукты и компании, которые развивают прочные отношения с инженерным сообществом, могут настроить себя на успех по ряду причин. И налаживание этих отношений может оказать существенное влияние на вашу продуктовую стратегию и принимаемые вами решения.
Как DevRel и продуктовая стратегия переплетаются
Для некоторых компаний основным стратегическим фокусом является нетехнический потребитель. Это не значит, что инженеры полностью игнорируются, просто основное внимание уделяется созданию ценности для нетехнических потребителей.
Пример — WordPress
WordPress поддерживает около 40% всего Интернета. Это потрясающе. Но не менее поразительно то, что если поговорить с инженером, многие из них ненавидят его. Всякий раз, когда у меня были разговоры о создании блога для поддержки продукта, 99% инженеров говорили: «Только не WordPress, пожалуйста».
У WordPress плохая репутация в сообществе разработчиков, но это не помешало их усилиям по росту, поскольку они уделяют огромное внимание конечным пользователям: в данном случае нетехническим специалистам по маркетингу и блогерам, которые хотят быстрое решение для создания контента.
Это не значит, что WordPress ничего не делает для сообщества разработчиков. Множество разработчиков создают для него плагины, и экосистема огромна, но это абсолютно не тот продукт, который выбирают большинство команд по разработке продуктов.
Для WordPress DevRel вторичен по отношению к основным пользователям: маркетологам, блогерам и авторам контента, которые не хотят изучать HTML, CSS и JS для публикации своего контента. Но как насчёт компаний, где DevRel важен для продуктовой стратегии?
Установление прочных отношений с сообществом разработчиков важно в трёх основных случаях:
- Рост — рост продукта связан с внедрением инженерных решений. Если инженеры любят ваш продукт и пропагандируют его, скорее всего, ваш продукт будет расти. Если ваш продукт содержит множество API, SDK или других инструментов, которые после внедрения сделают его более вероятным для роста, инвестирование в DevRel может иметь решающее значение для вашей продуктовой стратегии.
- Полезность — сам продукт ориентирован на инженеров и используется ими. Подумайте о Github, Gitlab или о headless CMS-решениях вроде Strapi или Storyblok. В этих случаях инженеры — ваши пользователи, а значит, важно наладить с ними прочные отношения.
- Новые технологии — ваш продукт — это совершенно новая технология, и вам нужно, чтобы инженеры полюбили её и приняли, чтобы она стала популярной и успешной. MongoDB, GraphQL, React и т. д. — всё это требует от инженеров принятия технологии, чтобы она стала повсеместной и успешной.
Это не единственные случаи, когда DevRel имеет значение, но они дают вам представление о некоторых примерах, когда DevRel важен.
Давайте рассмотрим несколько реальных примеров, чтобы понять, как каждый из этих случаев проявляется в реальном мире.
Банк Monzo (рост)
Для тех, кто не знаком с Monzo, это крупный лондонский банк-претендент, который привлёк сотни миллионов инвестиций и несколько лет назад пережил взрывной рост. Сейчас это прочно утвердившийся игрок в сфере финансовых технологий, и банк был признан лучшим банком Великобритании по рекомендациям.
В статье, описывающей рост банка Monzo, соучредитель компании и бывший генеральный директор Том Бломфилд объясняет, что сработало для роста компании, а что — нет. Вот что не сработало:
Мы потратили больше времени на вторую идею — хакатоны и отношения с разработчиками. Многие из нас (включая меня) были разработчиками программного обеспечения, и нас очень воодушевила идея банковского счёта с API. Мы провели 3–4 хакатона на раннем этапе (ещё до того, как у нас появились живые предоплаченные карты), и люди придумали несколько интересных идей, но мы быстро поняли, что это не будет большим стимулом для роста. Мы получили только 300 дополнительных пользователей, но это, безусловно, помогло нанять несколько первых инженеров.
По опыту Monzo, сосредоточение внимания на DevRel не привело к значительному увеличению реальных показателей привлечения пользователей, но позволило открыть возможности для найма талантливых инженеров.
Это то, что следует учитывать при разработке стратегии вашего продукта. Даже если вы не видите очевидного пути, по которому развитие DevRel будет стимулировать рост, подумайте о других преимуществах — в данном случае о найме талантливых специалистов.
FourSquare (рост)
Когда новый генеральный директор присоединился к компании FourSquare, продукт был struggling, B2C-ориентированным предприятием, где пользователи проверяли различные места в мобильном приложении.
Новый генеральный директор быстро понял, что помимо традиционного пути B2C существует ещё одна крупная возможность: стратегия продукта, ориентированная на API и учитывающая потребности разработчиков для включения информации о местах в их приложениях.
Это привело к выпуску ряда новых продуктов, ориентированных на разработчиков, включая Places API. FourSquare использовала DevRel, чтобы вывести свой рост на новый уровень.
AWS, Azure, Google Cloud (полезность)
AWS и облачные вычисления — это яркие примеры продуктов, полезность которых полностью ориентирована на инженерное сообщество.
Неудивительно, что эти сектора являются одними из самых агрессивных в своей тактике по привлечению разработчиков.
AWS ежегодно проводит Global Summit, где лидеры AWS рассказывают о последних способах использования платформы облачных вычислений, а также демонстрируют разработки от разработчиков, пытаясь убедить посетителей принять технологию в своих продуктах.
Azure и Google проводят аналогичные мероприятия с аналогичными намерениями.
Это некоторые из способов, с помощью которых компании используют своё влияние, чтобы попытаться привлечь разработчиков и убедить их принять свои продукты. Но как ещё вы можете улучшить DevRel для своего продукта?
Давайте посмотрим.
Практические способы улучшения отношений с разработчиками
Любая продуктовая компания может принять решение улучшить свои отношения с разработчиками, и, как мы уже выяснили, для некоторых продуктов это будет иметь фундаментальное значение для их продуктовой стратегии. Для других это может быть не так критично.
Если вы решаете, стоит ли удвоить усилия по сосредоточению на DevRel, задайте себе несколько вопросов:
- Рост — поможет ли установление более тесных связей с сообществом разработчиков значительно увеличить рост моего продукта?
- Зависимости от дорожной карты — есть ли в моей дорожной карте предстоящие стратегические пункты, реализация которых зависит от установления более тесных связей с сообществом разработчиков?
- Доходы — открывает ли развитие более тесных связей с сообществом разработчиков возможности для новой монетизации / получения доходов?
- Что произойдёт, если мы этого не сделаем? Подумайте о стоимости того, что вы не будете активно взаимодействовать с инженерным сообществом и не будете стремиться к более тесным связям с ним. Пострадает ли ваш продукт от этого каким-либо образом?
Создание внутренних команд, посвящённых DevRel
Некоторые компании будут относиться к DevRel настолько серьёзно, что создадут внутренние команды, посвящённые DevRel.
В этом примере FourSquare нанимает на должность «адвоката разработчиков» (Developer Advocate), в обязанности которого входит:
- Формирование присутствия в онлайн-сообществах на ключевых платформах.
- Организация мероприятий для разработчиков.
- Представление интересов сообщества разработчиков внутри компании для влияния на решения о дорожной карте продукта.
Решение о налаживании отношений с инженерным сообществом редко бывает достаточным; вместо этого вам потребуется выделить на это ресурсы, и один из способов сделать это — нанять людей, специально ориентированных на это.
Использование нишевых каналов и сообществ
Разработчики вряд ли будут использовать VK для поиска новейших инструментов и технологий. Если вы серьёзно настроены удвоить свои усилия в DevRel, вам, вероятно, понадобится кто-то, кто понимает, где инженеры проводят время в Интернете, чтобы вы могли влиять на мнения и поведение.
Каналы и сообщества, такие как Reddit, Twitch и Discord, вероятно, станут хорошей ставкой для влияния и формирования мнения, наряду с любыми влиятельными лицами, но эти каналы постоянно развиваются, поэтому вам нужно будет держать руку на пульсе, чтобы понимать, где и когда взаимодействовать с влиятельными разработчиками.
Конечно, менеджер по продукту — не лучший человек для этого. Скорее всего, вам понадобится оставить это тем, кто знает, где найти инженеров.
Взаимодействие с сообществом
Найти, где тусуются инженеры, — это одно, но активно взаимодействовать с ними осмысленным образом — совсем другое. У некоторых гигантов, таких как Microsoft, Apple, AWS и Google, есть ресурсы для проведения масштабных мероприятий, но у большинства небольших компаний их нет.
В этом случае небольшие компании всё равно могут взаимодействовать с сообществом через онлайн-мероприятия, выделенные каналы Discord, форумы и другие платформы.
Если у вас есть бета-версия вашего продукта, доступная для тестирования, или если ваша дорожная карта была опубликована, пригласите инженеров, чтобы собрать отзывы и наладить более тесные отношения. Всегда помните, что инженеры — это супертехнологичные люди, поэтому, если ваш продукт не предназначен для использования разработчиками, их отзывы, скорее всего, будут гораздо более ориентированы на технологии, чем отзывы нетехнических пользователей.
Поддерживайте продукты и документацию в актуальном состоянии
Взаимодействие и привлечение внимания не стоят ваших усилий, если вы не найдёте время, чтобы сделать сообщество разработчиков счастливыми в основных, но важных аспектах. Что мы имеем в виду под основными, но важными аспектами?
Ну, скажем, ваша документация по API устарела, или ваши коды ответов бессмысленны. Эти мелочи будут раздражать разработчиков настолько, что независимо от того, сколько модных вебинаров вы для них проведёте, они быстро поймут, что на самом деле вам не так уж важны их потребности.
Практические способы продемонстрировать разработчикам, что вы серьёзно относитесь к DevRel
- Документация удобна в использовании, проста для понимания и актуальна — Stripe считается золотым стандартом для документации разработчиков, и компания даже открыла исходный код своих инструментов документации, чтобы вы тоже могли создавать свои версии красиво оформленной, лёгкой для чтения документации.
- Примеры кода и библиотеки легко доступны для изучения, чтобы инженеры могли быстро увидеть, как технология работает на практике.
- Поддержка клиентов ориентирована не только на нетехнических клиентов, но и в равной степени доступна для технических пользователей вашего продукта, особенно если ваш продукт имеет техническую полезность или ориентирован на технических пользователей.
Подводя итог
Выделение времени и ресурсов на развитие отношений с разработчиками — это не новость. Но появление DevRel в качестве потенциального рычага для получения стратегического преимущества перед конкурентами — это новость.
Как менеджер по продукту, вам не нужно быть человеком, возглавляющим усилия вашей компании в области DevRel, но если ваша продуктовая стратегия предполагает, что установление более тесных отношений с сообществом разработчиков означает, что у вас больше шансов на успех, или что без этого вы потерпите неудачу, то, возможно, пришло время подумать об улучшении ваших усилий в области DevRel.
С другой стороны, если ваш продукт не ориентирован на инженеров и вряд ли выиграет от тактики, призванной привлечь инженеров на борт, то, возможно, лучше сосредоточиться на нетехнических конечных пользователях вашего продукта. Сосредоточение внимания на нетехнических конечных пользователях не означает, что вы обречены на провал, это просто означает, что вы ясно дали понять, какие пользователи являются приоритетными — просто спросите WordPress.