Эту книгу я читала дважды. Читала. Не прочитала. Первый раз я остановилась приме��но на середине и списала всё на свою лень. Спустя два года я решила прочитать ее полностью, но тоже остановилась на середине. Правда теперь я поняла почему.

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

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

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

Для кого книга

Книга, хоть и описывает разные типы компаний, но фокусируется всё равно на developer first. И вся вторая половина книги как раз про такие компании, где есть продукт для разработчиков.

Я работаю в Контуре. У меня не то что продуктов для разработчиков нет, у меня и для обычных смертных их нет. Контур — это B2B. И даже если ваша IT-компания пользуется нашими продуктами — вы всё равно про нас не знаете. (за исключением последних лет, когда у нас появился Толк)

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

Часть первая

Книга стартует с истории зарождения Developer Relations и это реально интересно. Например, History of modern Developer Relations и книга про евангелизм в Эппл. Кому-то может показаться, что нафиг история, давайте уже настоящую жесть. Но мне кажется, что суть Developer Relations настолько неуловима, что именно через историю появления этого процесса вы сможете наконец-то разобраться что к чему.

Авторы с самого начала подсвечивают, что у DevRel должна быть поддержка на уровне C-level. (еще есть хорошая статья от Отуса на тему положения DevRel-отдела в компании)

И проговаривают эту мысль еще раз уже в блоке про создание деврел-программы.

Они даже пишут про эту поддержку как «air cover».

Мои рассуждения

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

Но если вы посмотрите на правую страницу, то прочтете «your job is to educate your stakeholders…». И это важная мысль, которая возвращает деврел-отделу ответственность за своё благополучие: понимание стейкхолдерами DevRel-сферы — это ответственность деврел-специалиста.

Мои рассуждения

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

Руководители могут меняться и нет никаких гарантий, что новый техдир или кто там у вас придерживается тех же взглядов на Developer Relations, что и предыдущий. Пока Developer Relations не стало чем-то настолько же жизненно необходимым, как скажем отдел маркетинга или HR — ваша задача всегда подогревать контекст и интерес к этой сфере внутри компании. Мало быть агентом изменений. Важно еще и найти «спонсоров» этих изменений. Тех, у кого достаточно сил, связей и веры в ваше дело.

Новым для меня стало и понятие Developer-led economy.

His data highlights how it is impossible to ignore the Developer-led economy and how this market continues to grow. This clearly demonstrates the need for your company to have a developer strategy and, when the time is right, a developer offering backed by a strong Developer Relations program to ensure the opportunity can be seized.

Источник, на который ссылаются авторы.

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

Case Study: Mobile Apps - Those Who

In the early 2000s, the mobile industry moved toward an app store model, which signaled a shift away from accessing the Internet and associated services via mobile operator-controlled portals. This was not a pain-free transition, as the mobile operators fought to maintain control of the user experience and associated service revenues. Established players like Nokia/Symbian, RIM/BlackBerry, and Microsoft/Windows Mobile attempted to placate the all-powerful mobile operators. This compromise only succeeded in delivering a substandard user experience, which ultimately led to their demise.

It was the arrival of the iPhone in 2007 and Apple's entry into the telecoms arena when things changed. You had a handset manufacturer that understood the power and potential of software and had the confidence that the demand for their product would empower them to dictate how things would work from this point forward.

The mobile operators were largely removed as the "gatekeepers of the walled garden," and Apple embarked on establishing new relationships with app developers to build for iOS. This strategy has delivered back $155 billion in revenue to developers, while all the original power brokers in the mobile industry have seen their control crumble.

И тут же, возможно, самое важное в понимании Developer Relations — «philosophy of co-creation with software developers».

Часть вторая

Инженер — творец. Он любит творить сам и с корешами. Любит искать нестандартные и элегантные решения. И он выберет ваш продукт (приложение, курс, статья на Хабр), если тот поможет ему в процессе творения.

В книге вообще достаточно подробно описан портрет среднестатистического инженера. Его ценности, взгл��ды на жизнь и работу.

Мои размышления

В центре написано «I made that». Инженеру важно это ощущение собственного вклада в создание чего-либо. Но, как и многим из нас, им зачастую сложно присвоить себе заслуги. Поэтому да. Львиную долю работы деврел-специалистов занимает валидация опыта разработчика. Проговаривание, что он молодец и сделал реально важное и полезное дело. Это не «да я просто код написал», а «я внес вклад в развитие своей компании, а может и IT-сообщества».

Это то, что будет полезно почитать HR-специалистам, брендерам и маркетингу. И это то, на что будет опираться ваша деврел-программа.

После прочтения вот этой пятой главы у меня случился лютейший перевот в голове.

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

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

между компанией и ее сотрудниками
между сотрудниками
между компанией и внешним сообществом инженеров
между внутренним и внешним сообществом инженеров.

Мои размышления

Обучение сотрудников на внутренних курсах? — Developer Relations
Организация курсов в университете? — Developer Relations
Отправка на конференции в качестве участника или спикера? — Developer Relations
Ежеквартальные встречи с техдиром? — Developer Relations
Внутренняя соцсеть с новостями и сообществами? — Developer Relations

У нас в Контуре все эти вещи лежат в разных командах, уровнях и отделах. Курсы, стажировки и ФИИТ — в образовательных программах. Учебные курсы для инженеров внутри — в корп.университете. Работа с внешним сообществом опытных ребят — в деврел-отделе. Работа с внутренними комьюнити — во внутренних комьюнити ха! И это прикол, конечно. Мы все работаем на одну и ту же аудиторию, но не комплексно, а каждый со своей стороны. Это не плохо! При наличии других объединяющих вещей типа корп.культуры, всё так или иначе работает в сторону одной цели и двигает компанию к ней. Но представьте, насколько было бы эффективнее, работай все эти механизмы в одной слаженной системе.

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

И если вы достаточно упёрты (ну или у вас ипотека, как мы помним), то с помощью этой книги вы сможете построить деврел-программу, способную выстроить эту самую экосистему.

Далее книга начинает углубляться в бизнес-модели и теорию о «продукте» для инженеров.

Готовые схемы для работы.

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

Подробно раскрываются бизнес-модели в зависимости от вашей компании (B2B, B2C, B2D).

Даже немножко завидно тем, кто, например, имеет опыт работы деврел-специалистом в Jetbrains.

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

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

Часть третья

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

Обратите внимание на третий блок: вам нужен спонсор изменений

Авторы помогают разобраться в долгосрочных и краткосрочных целях.

Обратите внимание на последнее предложение

А также приводят примеры классических неработающих целей.

Некоторый итог

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

Эта книга — практическое руководство к действию. Она же ваш друг и валидатор действий. В ней я нашла подтверждения многим своим мыслям о том как должен быть устроен мой отдел и моя деятельность.

Рекомендую :)

Примеры фреймворков из практической части

Что внутри книги DevRel. How to Build and Grow a Successful Developer Program by Lewko&Parton