О профессии DevRel многие наверняка слышали, но не все представляют, кто это такие и чем они занимаются. По сути DevRel это тот же пиар специалист, только он занимается техническим пиаром, выстраивая отношения с ИТ‑индустрией.

Также в некоторых западных компаниях специалистов DevRel называют Developer Advocate, разработчик адвокат (многих вводит в ступор упоминание адвокатов применительно к ИТ).

По сути основная задача DevRel это продвижение продукта среди ИТ‑специалистов.

То есть задача DevRel специалиста рассказывать о компании, её продуктах и услугах на различных мероприятиях, форумах и митапах, создавать необходимый медиаконтент и размещать его на соответствующих площадках, писать посты, статьи, активно заниматься соцсетями.

Отдельно стоит отметить необходимость DevRel участвовать в Open‑Source проектах, взаимодействовать с образовательными учреждениями и помогать настраивать IT‑рекламу отделу маркетинга на языке, понятном ИТ специалистам.

В рамках этой статьи мы будем говорить не столько о специальности DevRel, сколько о разработке программного обеспечения на основе принципов Developer Relations.

Разработка на основе DevRel предполагает создание софта на основе активностей по взаимодействию интересов различных ИТ разработчиков. Так специалисты DevRel часто выявляют недостатки публичного интерфейса при создании контента. Они могут тесно сотрудничать с разработчиками, создавая более интуитивно понятные API и предоставляя конечным пользователям лучший опыт разработки.

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

Далее мы посмотрим то, как разработка по принципам DevRel может помочь при создании качественно софта.

Работа с документацией

Когда DevRel начинает работу над проектом, ему необходимо просмотреть всю существующую документацию, посмотреть имеющиеся примеры и выяснить, возможны ли какие‑то улучшения, которые помогут привлечь новых пользователей.

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

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

Здесь методика DevRel может помочь обогатить документацию дополнительными примерами использования данного компонента. Эти примеры помогут другим разработчикам, использующим данный компонент быстрее в нем разобраться и начать его активнее использовать.

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

В конечном итоге, активно участвуя в доработке документации, DevRel не просто обогатит ее новыми примерами и дополнениями, но и сможет подсказать разработчикам о необходимости добавления новый функций в API и другие компоненты.

То есть здесь DevRel уже в определенной степени будет выступать в роли архитектора, предлагая дополнительный функционал в приложение. Тем самым он будет уже не просто ИТ‑пиарщиком, но и реальным помощником для разработчиков.

Усовершенствование интерфейсов

DevRel также могут предоставлять разработчикам свои предложения о публичных интерфейсах для взаимодействия с приложением.

Приведем небольшой пример. API интерфейс приложения содержит функционал для добавления новых данных в базу, однако за одно обращение к API можно добавить только одну запись.

DevRel, обсуждая работу приложения с различными ИТ‑специалистами, пришел к выводу, что необходимо добавить возможность сохранять сразу несколько записей. В процессе обсуждения с разработчиками пришли к выводу, что оптимальным будет наличие возможности сохранения до десяти записей за один раз.

Таким образом DevRel может, получая обратную связь от ИТ‑специалистов заказчика улучшить реализацию нашего приложения.

Хороший DevRel должен помогать разработчикам привлекать новых пользователей и помогать делать удобнее работу существующих.

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

Еще одна, если так можно выразиться, задача DevRel специалистов это внесение позитива в проект и направление команду на общение в жизнерадостной манере. У каждого человека есть свой стиль общения, но немного дополнительной позитивной энергии никогда не помешает.

Например, позитивные комментарии, эмодзи под выполненными в срок задачами — все это мелочи, которые могут сделать работу в команде немного приятнее.

Немного дегтя

Прежде чем перейти к заключению рассмотрим те случаи, когда использование принципов DevRel может быть не слишком эффективно или даже бесполезно.

Итак, DevRel Driven Development — это отличный способ наладить прочные связи с разработчиками основных компонентов и конечными пользователями и стимулировать внедрение технологий. Это более активный тип DevRel, который требует от вас непосредственно участвовать в проекте, а не обеспечивать поддержку, находясь в стороне, так как это делают, например маркетологи.

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

Лучше всего использовать методику разработки DevRel Driven в сочетании с расстановкой приоритетов задач под руководством инженеров. У инженеров есть много задач, которые нужно разработать, и технический долг, над которым нужно работать, независимо от дополнений, предлагаемых DevRel.

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

Маркетинг для DevRel является скорее вспомогательным инструментом, который хотя и требуется в работе DevRel, но не является основным.

Заключение

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

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

В заключение рекомендую к посещению открытые уроки, которые проведут мои коллеги в Otus в марте:

• 13 марта: Мок-интервью на позицию DevRel. Узнать подробнее

• 20 марта: Как построить сильный HR-бренд в IT. Узнать подробнее

• 24 марта: Креативные стратсессии и способы провести встречи для DevRel и HR. Узнать подробнее