Dev rel что это
«Профессии будущего» давно появились — современному миру нужны специалисты, работающие на стыке нескольких направлений. В IT-индустрии это — DevRel, незаменимые люди в компаниях, где создают продукты для разработчиков. Эта профессия полна возможностей и интересных задач. Рассказываем, кто такие DevRel, почему они востребованы, и делимся опытом нашего коллеги из воронежского офиса Haulmont. Кстати, недавно мы рассказывали, чем занимается команда разработки Haulmont в Воронеже.
Кто такой DevRel
Developer Relations (сокращ. DevRel) дословно означает «Отношения с разработчиками». Однако это далеко не все задачи. Да, DevRel общается с разработчиками, а также участвует в создании и поддержке продукта, маркетинге, бизнес-аналитике и публичных коммуникациях. В мире IT так и не сложилось единого мнения, что важнее в работе DevRel: каждая компания по-своему расставляет приоритеты. Вот несколько задач, которые выполняет такой специалист в Haulmont.
Эксперт среди специалистов. DevRel общаются как с внешними разработчиками, так и с продуктовыми девелоперами компании. И у каждой стороны — свои интересы. Пользователи хотят знать, как устроен продукт, в чем его удобства и преимущества, а компании нужна качественная обратная связь. Developer Advocate должен выступать неким информационным фильтром между разными специалистами, а это требует глубоких технических знаний и аналитической работы.
Свой среди заказчиков. Аудитория DevRel — не только опытные разработчики. Зачастую нужно общаться и с потенциальными клиентами, которые не всегда имеют техническое образование и в целом далеки от мира IT. Так что умение говорить просто о сложном — еще один навык, которым обладает хороший DevRel.
Хороший инженер. Конечно, нельзя рассказывать о продукте компании, не участвуя в его разработке. Все-таки приоритетом этой профессии являются технологии и их использование, а не маркетинг. Так что Developer Advocate — это прежде всего разработчик, и часть рабочего времени он пишет код и погружается в создание продукта.
Публичный коммуникатор. DevRel-специалист участвует в крупных конференциях и митапах. Там он обменивается техническими знаниями с другими экспертами и продвигает бренд компании. Эта профессия дает возможность познакомиться с разработчиками со всего света, вырасти до технического эксперта и, конечно, улучшить навыки публичных выступлений.
Технический писатель. Участие в конференциях — лишь один способ заявить о продукте. Не менее важным инструментом является контент. Поэтому DevRel регулярно пишет статьи в блог и активно общается с разработчиками на форумах и в соцсетях. Поэтому грамотность и авторский стиль — его лучшие друзья.
Стать DevRel может даже опытный регуляр — конечно, для этого нужно упорно работать: погружаться в низкоуровневую разработку и оттачивать Hard и Soft skills. Мы уже говорили, что самообучение входит в должностные обязанности DevRel? Он отлично разбирается не только в продукте своей компании, но и во всем, что происходит в мире IT. Профессия DevRel очень разнообразна, но именно поэтому такой специалист заслуженно является авторитетом среди разработчиков.
What is developer relations?
DevRelCon founder and CEO of Hoopy, the content agency for the developer economy.
DevRel, or developer relations, is a process for nurturing mutually beneficial relationships between organisations and software developers.
In other words, it’s a collection of strategies and tactics that help companies to work better together with software engineers. Exactly what developer relations teams do and why they do it depends on what their organisation needs.
So, what is it that developer advocates and other DevRel professionals actually do? And why do companies invest in developer relations?
Let’s start with the why.
Why developer relations
From one company to the next, the strategic reasons for pursuing DevRel can vary significantly. Company X, for example, might do DevRel to drive adoption of their API, whereas the Y Corp team might be tasked with improving the company’s ability to hire software engineers.
Those differences in the why lead to different DevRel strategies, tactics, and definitions of success. In fact, understanding why your organisation needs developer relations acts as a key to everything else you need to know. It helps you know what to do, who to engage, and how to measure your efforts.
So, what are those strategic reasons for developer relations? Most developer relations programmes today are focused on encouraging adoption of a product, such as an API. However, there are at least five other common reasons for DevRel. Including adoption, most companies invest in DevRel because they want to affect:
- Adoption: the organisation wants more developers to use their product.
- Productbuilding: the organisation relies on a community of developers to build their (probably open source) technology.
- Product-market fit: understanding developer needs and desires is necessary to the product’s success.
- Developer enablement: providing the education, tools, and infrastructure that developers need to use a product once their employer has adopted it.
- Developer perception: the organisation considers current developer perceptions to be a potential barrier to the success of their product.
- Hiring: the organisation wants to improve its employer brand in order to be more attractive to the developers they need to hire.
In practice, organisations do DevRel to satisfy some mix of those strategic drivers. For example, it’s likely that a company that needs to drive adoption will also want to make sure its products have good market fit.
Despite the variety in why companies do DevRel, how they do it draws on a similar set of skills and tactics that we’ll call the four pillars of developer relations.
The four pillars of developer relations
Four pillars of developer relations cycle
If you’ve had only a passing acquaintance with DevRel then you might think of it as beer, branded swag, and blog posts.
However, just as marketing isn’t all about advertising, there’s more to developer relations than building awareness. While not everyone agrees on the naming, there are four complementary areas of DevRel:
- Developer marketing: understanding who the target developers for a product are then making sure they have the information and tools to make a decision.
- Developer enablement: providing everything that developers need to be successful with the product.
- Developer advocacy: acting as a champion for and conduit between developers and the organisation.
- Developer community: creating and maintaining an ongoing process in which developers can pursue a common goal in relation to your product or organisation.
Each of these works together to enhance the relationship between an organisation and the developers it values most.
Developer relations responsibilities
Let’s look at it from a slightly different perspective. In a typical organisation, what are the responsibilities of the developer relations team? The answer depends on a few things:
- Who instigated the relationship with developers?
- Is the company developer first (i.e. developers are the primary end user of their product) or is it developer plus (i.e. developers are a supplemental audience)?
- Are developers buyers (i.e. bottom-up adoption) or primarily implementers of someone else’s technology choice?
For some companies, developer relations is a collaboration across the entire company. For them, developers are usually both the users and buyers of the product, so everyone focuses on how to engage them. But consider a 300 year old bank that is forced by law to offer open banking APIs. For that bank — in fact, in most organisations — developers are just one audience and, importantly, an audience whose work, motivations, favoured channels, pain points, and culture can seem unusual to non-developers. In the case of such a bank, it makes sense to have a team dedicated to the relationship with developers.
Those considerations lead to three broad models for how companies tend to divide developer relations responsibilities:
- Vertically integrated DevRel: a single department or team takes care of every aspect of a developer’s engagement with the company, only collaborating with specialist departments (such as engineering or marketing) when there’s a beneficial overlap.
- Core DevRel: the developer relations department takes care of those functions that wouldn’t happen otherwise, such as developer community, but leaves other aspects to specialised teams (e.g. engineering, marketing, product).
- Company-wide DevRel: there isn’t a specific team or department for developer relations but, instead, DevRel happens throughout the company.
Regardless of where in the company DevRel people find themselves, what do they actually do?
Developer relations tactics
The what of developer relations depends entirely on the why. However, there is a common toolkit of tactics that DevRel practitioners tend to use. Here’s an entirely non-exhaustive list of some of those tactics:
- Developer marketing:
- Content creation, placement, and distribution
- Events: sponsorship, speaking, attending, organising
- Advertising and other paid campaigns
- Competitive and market research
- Developer education: documentation, tutorials, videos, guides
- Developer experience: API design, SDKs, reference apps, sample code
- Support and developer success
- Acting as the public face of the technology
- Interacting directly with developers on social media, in forums, at events
- Speaking at events
- Twitch streaming, video production, podcast production
- Acting as a feedback loop from developers to the company
- Creating promotional and educational materials
- Providing and moderating forums, chat, and other channels for direct developer communication
- Running champions programmes and other ways to incentivise/reward participants
- Setting the standards and tone of interaction
- Creating a process that enables people to meet their needs one working towards a common goal
As you can see, there’s overlap. Precisely what one person, team, or department does will differ from company to company. However, even though developer advocates, developer educators, and developer marketers produce content, for example, their strategic reasons for doing so are quite different.
For more detail on developer marketing, read our article What is developer marketing?
Кто такие DevRel, зачем они нужны и какие вопросы могут решить для бизнеса
Привет! Меня зовут Женя Голева, я занимаюсь developer relations с 2016 года, и постоянно вижу профессиональных чатах холивары о нашей работе. Люди спорят, кто такие деврелы, кто занимается не деврелом, а какие виды деврелов наоборот имеют право на существование и очень нужны в команде.
Ответы на многие похожие вопросы уже есть — в книге Мэри Тенгвал “The Business Value of Developer Relations”. Я заручилась поддержкой автора и издательства-правообладателя и перевела главу “Building a Developer Relations Team / What’s in a name?” для русскоязычного сообщества. У вас впереди 10 коротких и ёмких разделов про цели и задачи всей команды Developer Relations на старте и в процессе развития, про то, какие роли и специализации могут быть востребованы на разных этапах, что кандидатам необходимо знать и уметь на входе, а что — вовсе не обязательно и можно добрать в процессе работы.
Эта статья будет полезна в первую очередь тем, кто хочет разобраться в специфике направления developer relations: если вы СТО или СЕО, то вам скорее будут полезны первые несколько разделов и последний, если вы уже занимаетесь деврелом или очень хотите начать, здесь будут ответы на вопросы, как войти в профессию или куда в ней развиваться дальше.
Developer Relations Team
Developer Relations Manager
Technical Community Builder
Developer Experience Manager
Technical Engagement Manager
DevRel Project Manager
1. Команда по выстраиванию отношений с разработчиками (Developer Relations Team)
В названии прямо указано, что команда работает с конечными пользователями или покупателями (технологии). [На российском рынке более распространено взаимодействие с «покупателями компании» — потенциальными кандидатами, прим. переводчика.] Это отличие помогает формулировать цели команды и не брать на себя работу других отделов. Члены команды DevRel являются признанными в сообществе экспертами в заявленной области.
От целей компании зависят обязанности команды DevRel, а также в каком департаменте она будет находиться. (И мы поговорим об этом позже в этой главе)
Тем не менее, главная задача команды DevRel состоит в том, чтобы обеспечивать успех аудитории разработчиков (делать так, чтобы они могли лучше делать свою работу), а также транслировать потребности целевой аудитории остальной части компании. Почти каждый отдел так или иначе взаимодействует с сообществом, но именно команда DevRel фокусируется на благополучии сообщества.
Если вы начинаете небольшой командой, то начните с базовых вещей, необходимых для работы:
бесплатные доступы для разработчиков.
Когда эти задачи будут завершены и перестанут требовать много внимания, можно начать формировать площадку для сообщества, где вы сможете:
собирать примеры использования кода/продукта,
создавать группы суперпользователей или чемпионов,
спонсировать open-source проекты и проекты самого сообщества,
публиковать общую информацию о бренде,
выкладывать выступления и многое другое.
Но пока разработчик не находит на вашем сайте базовых вещей, которые должны быть в каждом надежном и приличном продукте, все эти навороты не будут работать. Если при первом посещении сайта разработчик не нашел нужного, зачем бы он вернулся или рекомендовал ваш сайт кому-то ещё?
2. Руководитель команды: Менеджер по выстраиванию отношений с разработчиками (Developer Relations Manager)
На эту роль подойдёт не каждый менеджер: найти идеального кандидата чуть легче, чем единорога. Критически важно, чтобы этот человек имел опыт работы именно в DevRel, так как помимо управления людьми в команде, необходимо ещё и обладать сильной экспертизой. Такие люди работают для всей команды и зонтиком, и проводником. С одной стороны, DevRel менеджер защищает команду от нерелевантной работы, возвращая её в отделы, откуда прилетели эти задачи. С другой стороны, менеджер организует каналы для обратной связи, которую команда получает от сообщества регулярно, и направляет фидбэк в нужные отделы и нужным людям.
За что же отвечает DevRel менеджер?
Он не только управляет людьми и занимается повседневными нуждами команды. Главное, что он делает — определяет стратегию, в рамках которой будет двигаться и развиваться DevRel команда и всё сообщество.
Хороший кандидат, возможно, не имеет технического образования, но легко поддерживает разговор на технические темы и владеет профессиональным сленгом.
DevRel менеджер задает правильные вопросы и имеет опыт работы с техническими продуктами. Возможно, он никогда не писал код, но знает основы достаточно, чтобы оценить, насколько легко и понятно написано ваше руководство по началу работы (с технологией).
DevRel менеджер может увидеть всю картину целиком, не зацикливаясь на примерах кода, исправлениях багов и холиварах в чатиках сообщества.
DevRel менеджер будет собирать встречи с другими отделами и синхронизироваться с маркетингом, продуктом, продажами, разработкой и поддержкой. Этот человек будет участвовать в обсуждении планов по развитию продуктов и присутствовать на всех звонках по запуску новых, предлагая обратную связь от сообщества и глубокое понимание, что люди ожидают от продукта и почему.
Для этого DevRel менеджер должен быть в постоянном контакте со своей командой, знать и сортировать потребности сообщества, упорядочивать обратную связь, которую получает команда. Затем нужно договориться с другими отделами не только о том, куда направлять пришедшие от сообщества запросы, но и кто будет ответственным за их выполнение.
3. Технический эксперт: представитель интересов разработчиков (Developer Advocate)
Название Developer Advocate отвечает на два главных вопроса сообщества:
Какая у тебя квалификация?
Эта должность помогает установить тот факт, что эти сотрудники, во-первых, разработчики, а во-вторых, их основная задача быть голосом сообщества в компании. Это делает их одновременно и представителями сообщества, и экспертами об этом сообществе.
Помните, я упоминала в главе 3 про представительство компании перед сообществом и, наоборот, представлении сообщества перед компанией? Большую часть этой работы делают технические эксперты (Developer Advocates). Именно они больше всего лично общаются с аудиторией разработчиков, когда выступают на конференциях, работают на стендах и в интернете через форумы, слак, разные сайты и соцсети. Часть из этих платформ будут корпоративными, но большую часть времени технические эксперты будут проводить в каналах, управляемых сообществом, а не компанией.
Когда команда станет больше, можно начать специализировать технических экспертов по технологическому стеку, по навыкам личного общения, и даже по регионам.
Вы обнаружите, что кто-то лучше выступает с докладом, а кто-то хорош именно в личном общении на стенде. Другие станут известны благодаря своим писательским навыкам, создавая контент, который точно бьет в целевую аудиторию разработчиков. Третьи смогут писать самую легкую для понимания документацию, разбивая продукт на понятные и детальные этапы, а может они будут обладать врожденной способностью находить уже сложившиеся сообщества в самых узких нишах вашей отрасли.
Будьте осторожны при найме: очень легко потребовать, чтобы технический эксперт и по несколько статей в месяц писал, и на всех конференциях выступал, и был в курсе свежайших и наилучших подходов в разработке, а также глубоко разбирался в кодовой базе продукта, создавая демки и SDK; важно понимать, что такое описание вакансии тянет на три должности сразу.
Тщательно выберите нужные навыки, максимально соответствующие текущей ситуации и ближайшим планам, а когда команда станет расширяться, нанимайте тех, кто закроет образовавшиеся дыры. Это может быть владение ещё одним языком или какие-то специфические навыки, расширяйте свою команду до тех пор, пока каждый не сфокусируется на своей специализации. Так каждый член команды займёт ровно ту позицию, которая лучше всего подходит его талантам. Это не только принесет максимум пользы, но и позволит человеку развиваться именно в той области, которая ему интересна.
Помните, что в предыдущей главе я говорила о такой метрике, как создание DevRel команды мирового класса? Именно таким образом формируется сильная команда, и это начинают замечать за пределами компании.
4. Массовик-затейник: строитель технического сообщества (Technical Community Builder)
Эта роль традиционно называется “менеджером сообщества”, но я сознательно использовала в названии слово “строитель”.
На то есть две причины:
Такое название позволяет избежать путаницы.
Из этого названия становится кристально ясно, для чего предназначена эта роль: строить техническое сообщество вокруг существующего продукта.
Несмотря на то, что в названии должности есть слово “технический”, эта роль схожа с менеджером по связям с разработчиками (DevRel Manager) в том, что человеку не обязательно иметь опыт разработки; с другой стороны, есть и важное отличие: эту роль должен выполнять тот, кто хочет и может разобраться с техническими основами.
Один из самых ценных навыков заключается в том, чтобы быть “массовиком-затейником”: знать нужных людей в сообществе, а также тех коллег внутри компании, к кому следует отправлять членов сообщества с вопросами и сложностями. Этот человек — главный владелец процессов, систем и любых других конструкций, созданных вокруг поддерживаемых сообществ. Это может быть публичный форум, Slack, закрытая группа ключевых пользователей или чатик самых активных участников сообщества (создателей контента, контрибьюторов в GitHub и т.д.), за каждой кулисой стоит создатель сообщества.
Именно они следят за тем, чтобы всё работало как задумано, стоят на страже кодекса поведения (Code of Conduct), ищут потенциальные связи между участниками сообщества и разными сотрудниками вашей компании и делают многое другое. Кстати, тут можно подумать о метриках позитивного первого контакта и мягкой передачи потенциальных клиентов сейлзам.
Строитель сообщества (Community Builder) вместе с техническим экспертом (Developer Avdocate) коллекционируют уникальные кейсы из разговоров в сообществе, собирают информацию о возникающих проблемах, потенциальном контенте или возможностях сделать с кем-то совместный проект.
5. Менеджер по (пользовательскому) опыту разработчиков (Developer Experience Manager)
Пользовательский опыт разработчика критически важен для успеха вашего продукта. Это один из трёх вопросов, которые мы задавали в главе 2, чтобы классифицировать ваши цели в DevRel. Я поставила эту роль сразу следом за тремя основными, потому что как только ваша команда начнет расти, а сообщество — масштабироваться, вам тут же понадобится ответственный за пользовательский опыт.
Пользовательский опыт разработчика — краеугольный камень всего продукта, но, по мере роста команды, люди начнут углубляться в свою специализацию, и вы не захотите их регулярно дергать на базовые вопросы. Этот менеджер владеет пользовательским опытом разработчика от начала и до конца. У них может не быть подчиненных (пока команда не станет достаточно большой, и не возникнет такая потребность), но они будут контролировать каждый кроссфункциональный проект, который затрагивает пользовательский опыт разработчика: от UX и дизайна сайта до документации и SDK.
Человек в этой роли не обязательно отвечает за непосредственную реализацию, но именно они будут отвечать за то, чтобы работа в этой области выполнялась плавно и своевременно. Менеджер по пользовательскому опыту разработчиков (Developer Experience Manager) следит за тем, чтобы документация была осмысленной и понятной клиентам (я поклонник этой матрицы документации от Даниэля Прочиды). Они приглядывают за инструкциями “Приступая к работе” (Getting Started) и общим пользовательским опытом, а также играют ключевую роль в метрике “время окупаемости”, упомянутой в главе 4.
Ищите тех, кто может одинаково хорошо и делегировать, и сделать работу самостоятельно, когда потребуется. Это ещё одна должность, где не обязательно, чтобы кандидат был разработчиком в прошлой жизни, но как минимум должен владеть навыками технического письма.
6. Технический амбассадор (Technical Ambassador)
Я намеренно называю этих людей абмассадорами, а не евангелистами. Слово “евангелист” вызывает религиозные ассоциации и может порождать негативные коннотации в разных странах. Иногда это может помешать даже зайти на порог некоторых компаний, что уж говорить о создании доверия. Гай Кавасаки в 80-х годах, продавая ранний компьютер Macintosh, популяризировал термин “евангелист”, концепцию евангелизационного маркетинга и технологического евангелизма.
Несмотря на то, что в то время этот термин имел смысл, сейчас он потерял свою популярность во многих кругах. К тому же, евангелистов теперь нередко считают частью группы продаж, что ещё больше затрудняет продвижение в сообществах разработчиков.
С другой стороны, термин Технический амбассадор (Technical Ambassador) отличает эту роль от Технического эксперта (Developer Advocate) и делает этого человека послом доброй воли от имени компании.
На первый взгляд, эта роль очень похожа на Технического эксперта (Developer Advocate). Но эта роль больше про продажи, чем про сообщество. Технические амбассадоры (Developer Ambassador) прекрасно выступают на больших сценах и продают не только продукт, но и саму важность этого продукта для всего технического сообщества в целом. Технические эксперты (Developer Advocate) легко входят в контакт с инженерным сообществом и продают продукт, который облегчает работу инженера. Тогда как Технические амбассадоры (Developer Ambassadors) показывают руководству компаний важность продукта в долгосрочной перспективе.
Эти люди не особо привязываются к сообществу. Конечно, они должны понимать важность сообщества, но им не нужно быть на передовой митапов и технических конференций. Они будут выступать на бизнес-конференциях и конференциях для руководителей технических компаний, формируя понимание, почему именно эта технология важна для индустрии именно сейчас.
Эта роль лучше всего подходит для новых направлений в технической индустрии (например, революционная услуга “email servers as a service” от SendGrind или культурная революция DevOps), когда нужно не только рассказать сообществу про бренд компании, но и объяснить, какую проблему решает продукт, и кому он вообще нужен.
7. Менеджер по вовлечению инженеров (Technical Engagement Manager)
Название должности запутанное, да и роль эта нужна далеко не каждому бизнесу. Тем не менее, огромной победой будет иметь в команде кого-то, кто обладает достаточными техническими знаниями, чтобы писать в соцсети и вовлекать техническую аудиторию в общение в онлайне наравне с создателями технического сообщества или менеджерами по связям с разработчиками.
Обратите внимание, что для этой роли подойдет не каждый сммщик. Эти люди будут полностью отвечать за таблицы с вашими твитами и фейсбучными постами; вы не хотите, чтобы в свободное время они же подрабатывали на запуске рекламных кампаний на заказ.
Этот человек — последняя пара глаз для любого контента на техническую аудиторию. Как вы заметили, я не сказала, что они ответственны за создание всего контента. Их ответственность скорее в том, чтобы контент соответствовал общей интонации компании, служил интересам технической аудитории и не выглядел слишком “продающим”.
Они могут отвечать только за постинг и верную интонацию для технарей, а могут и сами писать весь контент для каналов, заточенных под техническую аудиторию. Снова обращаю внимание, что функционал каждого специалиста зависит от специфики вашей компании и существующих ресурсов. Если у вас уже есть гениальный сммщик, способный вовлечь инженеров в разговоры, то ему может понадобиться только помощь технического эксперта (Developer Advocate), чтобы они подсказали авторитетных членов сообщества или ключевых контрибьюторов (подробнее об этом написано в главе 3).
8. Менеджер DevRel проектов (DevRel Project Manager)
Так как эта универсальная роль подходит примерно любым направлениям работы команды DevRel, я совершенно намеренно поместила эту роль в мир управления проектами. Википедия даёт очень четкое определение управления проектами:
“Дисциплина по инициированию, планированию, выполнению, контролю и закрытию работы команды для достижения конкретных целей и критериев успеха в указанное время.”
Это определение защищает человека от вала всей работы, которую нужно сделать. Исчезает соблазн нагрузить менеджера проектов выполнением задач вместо его прямой обязанности формулировать эти задачи и делегировать в исполнителей.
В зависимости от размера вашей команды, эта роль может проявляться по-разному.
Эти люди могут отвечать за логистику всех мероприятий, за вовремя поданные заявки докладов, за подготовку к мероприятиям, которые вы проспонсировали, а также за всегда полные амбары классного мерча.
Они также могут управлять всеми кроссфункциональными проектами в более крупной команде. Так как DevRel задачи часто затрагивают другие отделы (маркетинг, разработку, продукт, и т. д.), неоценимой помощью будет наличие специального человека, который знает статус всех подобных задач.
Они же могут быть входных окном в команду DevRel для других отделов и участвовать во встречах по статусу задач, не отвлекая на это других членов команды.
9. Штатный инженер (Full-Time Engineer)
Роль очевидна из названия — это штатный инженер или разработчик. Отличаются от коллег по цеху лишь тем, что полностью заняты работой в DevRel команде. Я обнаружила, что эта роль невероятно полезна как для небольших команд (скажем, из одного технического эксперта и одного менеджера сообществ), так и для больших (десять и более человек в команде).
В любом случае, штатный инженер в команде сможет подхватить единичные баги или мелкие тикеты, созданные по жалобам сообществе, которые недостаточно значимые, чтобы за них взялись продакты или разработчики продукта.
Эти же люди напишут специальное приложение для мероприятия или инструмент для автоматизации некоторых DevRel процессов, и вам не придется выпрашивать время разработчиков продукта. Многие крупные компании переходят на такой формат работы: Google и Twitter, Oculus и RiotGames имеют штатных инженеров в DevRel командах. Именно они дежурят во время конференций, чтобы починить свою демку, если она сломалась прямо на сцене.
Наличие штатного инженера позволит всей команде сильнее фокусироваться на своей специальности, а не переключаться одновременно между стратегией, контентом, инструментами и демонстрационными приложениями.
10. Кого нанять первым? (Who’s First?)
Роли, которые я выделила, скорее теоретические, такую полноценную структуру команды редко увидишь вне крупных компаний. Первый нанятый специалист будет отвечать за кусочки всех перечисленных ролей. Хоть и любой найм считается инвестицией, найм вашего первого деврела критически важен. Этот человек принесёт с собой не только экспертизу, но и связи. Если вам удастся найти того, кто получает удовольствие от общения с сообществом и высоко ценится компанией, то этот человек будет первой скрипкой и задаст верную тональность будущим отношениям с инженерами. Как вы уже поняли, чрезвычайно важно правильно выбрать и роль, на которую вы нанимаете, и человека под неё.
Dev rel что это
DevRel в условиях дефицита IT-специалистов — это не столько должность отдельного менеджера, сколько системный подход бизнеса в общении с аудиторией разработчиков.
Программисты — самый требовательный соискатель: чаще не он охотится за работой, а компании — за специалистом. При этом топ-менеджменту сложно понять потребности разработчиков, и увеличение зарплаты не помогает привлечь новых работников или удержать текущих.
Согласно внутреннему исследованию Geecko, проведённому на выборке из 20 тысяч российских IT-специалистов, для разработчиков в приоритете использование современных технологий в компании (55%), сильная техническая команда (51%) и приятный коллектив (50%), при этом высокое вознаграждение (27%) и ДМС (8%) имеют второстепенное значение.
Разработчик скорее выберет интересные задачи и сплоченную команду профессионалов, а не оффер с самой высокой зарплатой. DevRel нужен как раз для создания имиджа компании, в которой разработчику захочется работать — только так можно решить проблему дефицита кадров в IT.
Сама профессия пришла к нам с Запада. Автор книги The Business Value of Developer Relations Мэри Тенгвал считает первопроходцем деврела Apple, в которой ещё в 80-е годы появились евангелисты продуктов компании, например, Майк Бойч, член первой команды разработчиков Macintosh.
За 30 лет культура DevRel на Западе оформилась в сплоченное коммьюнити — в России же это молодая профессия, к примеру, первые DevRel-конференции появились только три года назад.
Чем занимаются DevRel-специалисты
В обязанности DevRel-специалиста или DevRel-отдела входит целый набор стратегических задач.
Во-первых, сама компания должна осознать, в чём её ценность для аудитории разработчиков, и функция DevRel — помочь ей в этом. Компания может не знать, что продукт, который она делает, это интересная задача для разработчиков; или наоборот — переоценивать свою инновационность. Опытный DevRel подскажет, как использовать сильные стороны технической части продукта и оправдать ожидания разработчиков от работы в компании.
Во-вторых, DevRel должен уметь донести ценностное предложение работодателя (EVP) до аудитории разработчиков — и привычные инструменты вроде обзвона по базам резюме в случае с IT-специалистами не помогут. DevRel обязан хорошо знать российское IT-сообщество и уметь охватить каждого, кто потенциально интересен компании как сотрудник.
В-третьих, в задачи DevRel-специалистов входит формирование бренда компании как крутого работодателя в IT. Для этих целей подходят:
- контент, интересный разработчикам: ведение блога компании на Habr или создание сообществ в соцсетях специально для разработчиков — например, у Facebook есть аккаунты Facebook for Developers;
- митапы компании и выступления на IT-конференциях: важно делиться IT-кейсами, которыми гордится компания, чтобы другим разработчикам захотелось работать над задачами бренда;
- соревнования для разработчиков с призовым фондом: например, на хакатоне компания может получить решение прикладной IT-задачи и заодно — собрать потенциальных кандидатов для дальнейшего рекрутинга;
- развлекательные форматы: весёлый квиз на IT-тематику поможет разработчикам хорошо провести время на конференции и попутно узнать о том, какой продукт и какой командой делает компания.
При этом KPI деврел-менеджеров — вопрос дискуссионный. Активности в рамках направления дают результат только при системном подходе и в долгосрочной перспективе: разработчик может посетить митап компании, а прийти работать в неё только через год. При этом сформированный бренд работодателя сыграет ключевую роль при выборе места работы.
Каким компаниям нужен DevRel
Часто бизнес приходит к необходимости DevRel-активностей сам — в момент, когда нехватка IT-специалистов становится препятствием развитию компании. При этом можно выделить три категории компаний, которым точно нужен DevRel:
- Компании с продуктом, покупателями которого выступают сами разработчики — например, инструменты для программирования. Продажи разработчикам требуют подкованности в технической части и умения говорить на одном языке с аудиторией;
- Бизнесы с IT-продуктом, переживающие взрывной рост. Потребность в разработчиках увеличивается кратно, и разместить 50 новых вакансий становится заведомо проигрышной стратегией — потребность в разработчиках требует более тонких инструментов HR-маркетинга с фокусом на IT;
- Крупные компании, которые для поддержания технической части продукта нанимают >100 специалистов в год. Чтобы генерировать спрос на вакансии и нанимать лучших, важно сделать бренд работодателя известным IT-сообществу. При этом созданной репутации важно соответствовать: в противном случае проблемой бизнеса станет отток IT-специалистов.
Как построить карьеру DevRel-специалиста
DevRel — новая профессия, и ни в западных, ни в отечественных вузах нет программ, обучающих деврелу. Обычно в DevRel переходят из HR-маркетинга или рекрутинга — часто внутри самой компании, если она делает ставку на развитие IT-продуктов. Реже деврелами становятся сами разработчики, которые горят продуктом и склонны развивать свои коммуникативные навыки.
В крупных западных компаниях внутри DevRel существует разделение: созданием сообщества и выстраиванием системных коммуникаций занимаются одни специалисты, продвижением технологического бренда компании — другие, созданием контента — третьи.
В России DevRel пока должен уметь всё и сразу. Но есть общие компетенции, отличающие хороших DevRel-специалистов:- системный подход, который должен объединять все активности компании в DevRel и целостно доносить HR-имидж бренда;
- подкованность в технической части: для технических евангелистов на уровне разработчиков продукта, для остальных как минимум знание о применяемых в компании языках программирования и технологических процессах;
- высокие коммуникативные навыки и эмоциональных интеллект: придётся выступать посредником между брендом и внешним сообществом IT, быть адвокатом нанятых разработчиков и защищать их ценности перед топ-менеджментом компании;
- менеджерские и организаторские способности;
- долгосрочное видение: действия DevRel-a имеют отложенный эффект и поэтому важно иметь стратегию и двигаться к целям с горизонтом больше года;
- увлеченность своим делом: разработчики горят своей работой, и невозможно успешно выстраивать взаимодействие с ними без огня в глазах, важно любить гик-сообщество и хотеть работать на его благо.
В DevRel придётся столкнуться с высокими требованиями и многозадачностью, но работа окупает себя. Сейчас это высокооплачиваемая профессия: для специалиста с опытом работы в DevRel или смежных направлениях от трёх лет заработная плата составит
200 тысяч рублей в месяц. У руководителей DevRel-отделов в крупных компаниях зарплата ещё выше.
Как и в случае с IT-специалистами, в DevRel большую роль играет самообразование и инициативность. Тем, кто хочет работать в DevRel, можно посоветовать: