DevRel: почему им стоит заняться уже сегодня

Шел 2020 год. Пандемия коронавируса. Социально-экономические и политические потрясения. И… реинкарнация удаленки.

Мы как-то в одночасье всем миром осознали, что можем работать в удаленном формате вполне эффективно. И не только работать, но еще и проводить различного рода мероприятия. Пресейлы, конференции, доклады – все это можно организовывать в онлайн-режиме!

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

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

DevRel как никогда сейчас актуален. И я постараюсь объяснить, почему.

Меня зовут Пластинин Артем. Я тимлид в компании IT Capital, руковожу разработкой по банковскому направлению.

Наша компания занимается автоматизацией всего, что под крылом Центрального банка Российской Федерации, – это банки, страховые компании, пенсионные фонды и т.д.

В компании мы очень любим рефлексировать над тем, что у нас получается, а что – нет, какие у нас «бутылочные горлышки» образуются.

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

В докладе расскажу, как так получилось и что из этого вышло:

• Сначала синхронизируемся в понятийном поле – я дам определение, что такое DevRel.

• Далее очерчу границы внешнего и внутреннего DevRel.

• Спустимся до вопросов целеполагания.

• Я дам некое декомпозированное определение, что мы получаем от того, что у нас внутри компании есть DevRel.

• И расскажу историю нашей компании: как у нас запустился DevRel, и почему мы до сих пор этим занимаемся.

Понятия

DevRel – как Public Relations, но только для девелоперов, и расшифровывается Developer Relations. Т.е. это PR для девелоперов.

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

И DevRel – это фактически Public Relations, только для этих инженеров.

Есть более простое определение. DevRel – это техпиар. Это самое простое из определений. Или, как в Яндексе его называют, технопиар.

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

DevRel – это техпиар от инженеров для инженеров или от разработчиков для разработчиков.

«Пиарить» можно все

О чем можно рассказывать истории, что можно пиарить?

Можно привести много различных примеров. Например, есть внутренний PR:

• Разработчик может рассказать о том, с какой-то проблемой он столкнулся и какое классное решение нашел.

• Разработчик, аналитик или консультант изучил какой-то новый инструмент и захотел поделиться со своей компанией, какой этот инструмент крутой.

• Можно рассказывать про успехи компании. Например, руководитель какого-то направления может поделиться успехом, что на каком-то проекте решили вопрос с производительностью.

Возможен также внешний PR – мы можем где-то вовне рассказывать:

• Как у нас устроен процесс.

• Какой стек технологий мы используем.

• Какими проектами мы занимаемся – я, например, рассказал, что мы занимаемся исключительно банковскими проектами.

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

«Пиариться» можно по-разному

Каким образом можно рассказывать эти истории, пиариться?

Для внутреннего DevRel:

• можно проводить внутренние митапы;

• на ежедневных дейли делиться успехами;

• на 1-to-1 / Performance review, когда проходит сбор какой-то обратной связи.

Внешний DevRel:

• выступления на конференциях;

• статьи на Инфостарте, Хабре и т.д.;

• и еще в 1С-отрасли сейчас набирает обороты менторская деятельность.

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

Перейдем к целеполаганию – для чего все это нужно. Я сейчас достаточно крупными мазками объясню, а потом мы это декомпозируем.

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

• С точки зрения внешнего DevRel – для заметности в отрасли или реализации каких-то своих корыстных целей.

• Если брать в совокупности, то это так или иначе все равно приводит к некоторому профессиональному развитию.

Приведу конкретные примеры. На картинке – Глеб Стальной на конференции Archdays рассказывает о том, каким образом они занимаются автоматизацией проектов на ERP. Рассказывает про стек технологий, про проектные методологии, которые они используют внутри команды.

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

Или вот сам вендор 1С на конференции HighLoad рассказывает о встроенных технологиях in-memory DB для аналитической обработки данных в 1С.

Все это истории от разработчиков, от инженеров для других разработчиков.

Или вот еще один пример – не самый очевидный, но, тем не менее.

Сам факт того, что в репозитории компании «Первый БИТ. Москва. Проектный офис Марксистская» находятся такие репозитории, как jenkins-lib или onec-docker, мне, как разработчику, как инженеру, гораздо больше расскажет, нежели любой HR.

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

А вот наш внутренний чат «Техкружок» – я уверен, что такие чатики есть внутри каждой компании.

Или чат INFOSTART FRIENDS – здесь тоже элемент DevRel, когда Сергей Голованов задает вопрос: «Разве программисты не ходят в свитерах с оленями?». И Андрей Овсянкин – как ответ на этот вопрос.

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

Это все DevRel – все это истории от инженеров для инженеров.

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

Сообщество «Деврел-бюро» ведет реестр компаний, декларирующих, что у них есть внутренний DevRel. Там приведены контакты каждой из этих компаний, можно пообщаться, что-то спросить, запросить какой-нибудь референс и т.д.

Я этим воспользовался и спросил у действующих DevRel-ов (даже должность такая есть во многих компаниях): «Почему вы решили внедрять DevRel?»

Оказалось, что многие вообще не думали о том, что будут внедрять какой-то DevRel.

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

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

С этим утверждением я согласен – это самый важный, наверное, инсайт.

Расскажу, каким образом у нас в компании зародился DevRel через решение проблем.

Решаем проблемы через рефлексию

Мы в компании выявляем проблемы через рефлексию – индивидуальную и групповую.

Индивидуальная – это:

• оценки 360;

• performance review;

• One-to-one.

Групповая – это:

• ретроспективы внутри команд разработки;

• ретроспективы с заказчиком, с бизнесом;

• так называемые ретроспективы по направлениям;

• опросы по различным мероприятиям.

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

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

Мы поручаем человеку изучить этот вопрос, и он делает доклад на эту тему. Причем доклад сразу же тиражируем на всю компанию.

Он нам рассказывает, что есть такой фреймворк Vanessa Automation, чем он отличается от Vanessa ADD. Это наш первый кейс.

Другой кейс. Приходит к нам в команду разработчик и спрашивает, почему мы не используем такой классный инструмент как Infostart Toolkit. Мы попросили его рассказать о нем.

Он делает доклад на эту тему, мы все принимаем, покупаем этот инструмент, и все выкладываем в YouTube.

Дальше на это все обращает внимание Александр Кунташов, репостит. К нам приходит еще некоторая аудитория.

Потом к нам приходит Евгений Люлюк и говорит: «Ребята, если вам нужны какие-то консультации, я готов их вам незамедлительно предоставить». Т.е. Женя стал для нас Key Account менеджером.

Следующий кейс – прототипирование экранных форм.

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

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

В результате появился инструмент – обработка «Помощник консультанта». Мы его опубликовали на GitHub и Инфостарте, т.е. отдали этот инструмент в сообщество на доработку и разработку.

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

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

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

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

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

Но на этом пути можно столкнуться с возражениями со стороны команды.

• Первое: «Я сделаю черновой вариант, но с докладом, боюсь, не получится. Я интроверт».

• Второе: «Отрасль 1С и люди, которые в ней работают, слишком токсичны. Они все раскритикуют, вообще пропадет желание что-то делать».

• Или человек говорит: «Мне кажется, это вообще никому интересно не будет».

Чтобы нивелировать эти возражения, было решено выкладывать все наши внутренние митапы на канал «команда ИТК».

У нас появился такой технологический бренд, бренд команды.

Благодаря этому были разрушены все ограничения, все стереотипы. Любой ролик всегда набирает просмотры, получает обратную связь. И понятно, что и отрасли, и сообществу в целом это направление достаточно интересно.

Как привлечь внимание сообщества

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

Почему мы всем этим продолжаем заниматься? Мы любим рефлексировать. И чтобы это делать, мы собираем обратную связь. Ее можно поделить на внутреннюю и внешнюю.

На внутреннем фидбэке:

• Когда проводится 1-to-1, разработчику задается вопрос: «Что ты увидел хорошего за последнее время?» И все разработчики, все консультанты, аналитики в восторге, что у нас появились техкружки, конскружки и обмен опытом.

• На performance review аналогичная ситуация. Люди гордятся тем, что они делают доклады. Они побороли какие-то свои страхи, им радостно, что сообщество их доклады принимает.

• И, конечно, успехи компании: когда кто-то из руководителей рассказывает о том, что мы достигли успеха на проекте благодаря тому, что переиспользовали какую-то практику в результате внутреннего технологического пиара.

• Анкетирование кандидатов. Когда человек устраивается к нам на работу, мы его спрашиваем, что в нашей компании его привлекло. Часто человек отвечает: «У вас есть такое направление, как DevRel. Мне это интересно, я хотел бы в этом тоже поучаствовать».

Внешний фидбэк:

• Time-to-Market. Когда мы вместе с заказчиком (с бизнесом) подводим итоги на ретроспективах о том, что переиспользование практик напрямую влияет, в том числе, на Time-to-Market;

• Некий респект от сообщества;

• Комментарии на YouTube;

• Рейтинги – мы как компания в первый раз попали в рейтинг самых привлекательных работодателей.

DevRel влияет на все

DevRel прекрасен тем, что влияет на все. И эти побочные эффекты – это и есть основная причина, почему DevRel стоит заниматься.

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

• Удовлетворен заказчик – быстрой доставкой бизнес-ценностей за счет переиспользования практик и наличия внутреннего технологического пиара.

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

• Компания, как работодатель, становится привлекательнее. Это еще и сокращает затраты на наем. Сейчас многие кандидаты сами пишут мне в личку, с желанием устроиться к нам в компанию. И все это за счет того, что человек увидел какой-то ролик, и ему понравилось, как мы решаем ту или иную проблему.

• Еще одна важная функция – это синхронизация с отраслью. Рассказывая о чем-то в своих докладах, в техкружках, мы говорим о том, что мы начали использовать какую-то классную практику. И нас отрасль может подкорректировать и сказать: «Ребята, вы не туда идете, вам лучше туда пойти». Или наоборот, ребята могут посмотреть и сказать, что раз в IT Capital начинают использовать автоматические тесты, то и нам, наверное, нужно использовать автоматические тесты.

Это основные причины, почему вам стоит заниматься DevRel сегодня.

Вопросы

Изначально это была инициатива HR-отдела? Или все-таки девелоперов?

В основном все делают девелоперы. А остальные просто им помогают.

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

Мы открыты к такому взаимодействию. Я мечтаю, чтобы в отрасли 1С DevRel стал еще более открытым форматом, чтобы друг к другу ходили на референсы, узнавали, как кто какие вопросы решает.

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

Но если в 1С отрасли это все наладится, я буду самым счастливым человеком на планете.

По итогам доклада у меня сложилось впечатление, что огромную роль в успехе DevRel играет именно разработчик, который в этом заинтересован, т.е. непосредственно вы. Как маленьким компаниям начать этим заниматься, если главные разработчики и архитекторы этого хотят, но сильно загружены своей постоянной деятельностью? Может быть, это можно как-то совместить или есть какие-то лайфхаки? Потому что я уверен, что такая ситуация у всех: хочется, но очень много работы.

Нужен некоторый уровень осознанности. Здесь сыграла роль не только моя заинтересованность.

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

Когда мы решали эти проблемы, у нас и появился DevRel – нас не нужно было к этому подталкивать. Я приводил пример с автоматическими тестами. Нам надо было решить реальную проблему. Она у нас есть, у нас баги на продакшене. Для нас это неприемлемая история. Мы нашли решение – нужно запускать автоматические тесты.

Мы не директивно дали задачу какому-то разработчику: «Запусти, пожалуйста, это». Мы сказали: «Сделай технологический пиар – расскажи всей команде, чтобы они осознали, что это действительно нужная практика для них».

Т.е. надо выявлять проблемы и решать их. И тогда у вас, возможно, появится DevRel. А вообще надо просто пробовать.

Кстати, на сайте DevRel-бюро зафиксированы некоторые постулаты. Они говорят о том, что:

• Важна регулярность.

• Интерес будет всегда, даже если вам кажется, что это вообще неинтересная тема.

• Хороший DevRel должен быть полезным для команды – реально решать какую-то проблему в компании. Причем решить задачу важнее, чем сделать это красиво.

• И еще один постулат: схожий материал не отменяет возможности рассказать его еще раз – это ответ на возражение о том, что в интернете уже много чего есть на ту или иную тему.

В DevRel есть какое-то ограничение, некий закрытый клуб, который дает элитарность? Например, если ты становишься мидлом, ты уже можешь в этом участвовать, а если ты джуниор, то ты еще материал не видишь и т.д. Или нет такого ограничения, и нет смысла его делать?

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

У нас есть прикольный кейс: когда мы запускали SonarQube, там выдавалось огромное количество различных базовых уведомлений. С этим нужно было каким-то образом бороться. Тогда мы поручили нашему джуну рассказать всей компании, что должен знать джун из «Библиотеки стандартных подсистем».

Человек сделал доклад из 12 пунктов. И оказалось, что архитекторы половину из того, что знает джун, не знают.

Поэтому никакой элитарности тут нет.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.