Кого и как защищает дев-адвокат

Вот уже полгода я работаю в роли Developer Advocate в iOS-команде inDrive. Позиция достаточно редкая и не так хорошо описана, особенно на русскоязычных ресурсах. Я решил рассказать, что делает дев-адвокат, как помогает разработке и как начать делать тоже самое. 

Предыстория

Мою карьеру можно описать по известной формуле: «Пацан к успеху шёл, не фартануло». Потому что изначально я очень не хотел быть разработчиком, но 10 лет назад не смог убежать — затянуло. Начал учиться, делал свои проекты и попал в Avito. Там побывал в продуктовых, платформенных командах, в это же время организовывал Podlodka iOS Crew, Mobius, курсы по iOS-разработке.

В Avito я пришёл в начале 2017 года обычным iOS-разработчиком. При этом, с конца 2020 года начал неформально заниматься адвокатством в компании, потому что увидел в этом необходимость. Руководство поддержало идею, но не в виде отдельной позиции, а как дополнительную роль к разработке. 

Закрутилось это так. В начале 2020 года я столкнулся с сильным кризисом — разрабатывать мне надоело, всё больше чувствовал, что тянет в работу с людьми. Начал проходить менеджерские курсы, читать литературу. В это время моя коллега Катя Петрова перешла в JetBrains на позицию дев-адвоката. Я подумал: «Хм, это что такое вообще? Это как?» При этом мне уже надоело заниматься только публичной активностью, хотелось делать что-то для своих, тех, кто рядом. 

Я заинтересовался, начал внутри Avito развивать направление: поднимать сообщество, изучать текущие проблемы разработки, выносить обсуждения на встречи, готовить спикеров, но формально в должности инженера. Я даже думал уйти в IT-консалтинг — настолько не верил, что получится найти позицию дев-адвоката. 

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

Это длилось полгода, и в этот момент я увидел сторис у знакомого по конференциям. Он ходил по горам в Казахстане, и я написал: «Прикольно там у вас». Я уже жил на Бали, потом в Турции, но это было не моё, и я сказал: «Может, в Казахстан перееду». В ответ на это он предложил попробоваться на позицию Developer Advocate к нему в inDrive. То, что нужно! Дело за малым — я прошёл все собеседования и начал работу. Только оказался я не в Казахстане, а на Кипре.

Дев-адвокат в inDrive: кастдевы и карта текущей реальности

Фундаментально дев-адвокаты бывают двух типов. Первые — это как раз Катя Петрова в JetBrains. Обязанности ближе к маркетологу: у тебя есть внешнее сообщество и ты работаешь с ним. Например, собираешь обратную связь от пользователей, изучаешь их боли, проблемы, хотелки, а потом рассказываешь, как продукт их решает. В этом смысле дев-адвокат вырос из евангелиста. 

Второй тип — когда ты адвокатируешь именно внутреннее сообщество группы разработчиков. Это как раз я — представитель интересов iOS-разработчиков внутри компании среди бизнеса, продактов и так далее. Моя задача — построить сильную инженерную культуру и тем самым улучшить качество и скорость разработки. Как-то я описал свою роль бывшему коллеге, и он сказал: «А, ну ты председатель профсоюза». Мне аналогия показалась максимально близкой.

Так как позиция дев-адвоката редкая, то и ожидания от неё не очень чёткие. На собеседованиях в inDrive я пытался понять, что происходит в компании и что нужно делать. Говорил, что мне интересно выстраивать внутреннее сообщество, улучшить developer experience, культуру разработки. Получилось, что в большей степени я формировал свои ожидания сам и сам же их драйвил.

Моими основными целями на первом этапе были: 

1. Изучить состояние разработки и найти способы для её улучшения.

2. Написать манифест дев-адвоката.

3. Организовать сообщество разработчиков.

Первым делом я поговорил со всеми iOS-разработчиками. Увидел, что люди жалуются на разные факторы: это болит, то болит. В итоге подготовил большой опросник по разным критериям разработки. Получилось почти 50 вопросов, на основе которых рассчитывается что-то типа eNPS — показателя удовлетворённости разработчиков функции, только в разрезе техники, а не всей компании. Опрос выглядит как Google-форма, в которой куча вопросов. Люди отвечают, насколько они согласны с утверждением по пятибалльной шкале. Дальше с выборкой людей, которые поставили низкие оценки, проводятся глубинные интервью. Я спрашиваю, в чём причина такой оценки и как можно её исправить. Докапываюсь до сути, а ответы фиксирую в таблице рядом с оценками респондента.

Представим, что мы выяснили у всех iOS-инженеров их боли. На выходе получается очень много информации. Что делать? Как собрать всё воедино? Я начал рисовать в Miro причинно-следственные связи. Получилось большое полотно, почти как у следователя. Оно хорошо помогает понять картинку, представить её бизнесу для объяснения. Показать, что если мы здесь, например, пофиксим боль, улучшение повлияет на всю систему. Эту технику я взял из знаменитой книги Элияху Голдратта «Цель», которую читал ещё до работы в Avito.

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

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

Из этого исследования появились и другие инициативы. Фоново изучаю, как устроена документация, как её переработать, чтобы всем разработчикам было удобно ей пользоваться. Также помогаю хэду кластера во внедрении продуктового подхода в платформенные команды. Важно, чтобы платформенные продукты развивались как продукты, а не просто как набор инициатив. Это улучшает developer experience, вносит ясность для команд и бизнеса. 

Team Maturity Model

Второй крупный проект — Team Maturity Model (TMM). Его я делаю совместно с командой Process and Practices. Проект также отвечает за инженерную культуру в компании. Если кратко, это модель оценки зрелости команд. Она состоит из четырёх уровней — с нулевого до третьего. На нулевом в команде не соблюдаются практики вообще, на третьем команда живёт в мире розовых пони, когда всё идеально. Целевой уровень — второй, где мы говорим, что у команды есть определенные практики. Это даёт право сказать, что команда зрелая. 

Например, есть модель следования пирамиде тестирования. В команде тесты могут быть написаны как попало, а могут быть по пирамиде, так, чтобы обеспечивать максимальное качество минимальными трудозатратами — это и оцениваем. Или, например, можно потрекать по TTM, сколько времени команда уделяет техдолгу. Есть всякие процессные вещи: следование Scrum, Kanban и так далее. Подробнее про опыт внедрения ТММ в Avito можно почитать у Миши Сухова в статьях на Medium и на Хабре. 

В inDrive своя специфика. Поэтому модель и процесс работы с ней мы досконально прорабатываем внутри компании. Нельзя взять прошлый опыт и наложить на новые реалии. Это так не работает. Поэтому я созваниваюсь с коучами, QA, бэкендерами, выкристализовываю формулировки вопросов, уровней, чтобы это ложилось на наши реалии.

Манифест дев-адвоката

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

Сначала начал описывать концепцию, какие у адвоката зоны ответственности и продукты. Пример зон ответственности — внутреннее и внешнее сообщество, улучшение developer experience, внедрение новых подходов в разработку, рост и развитие инженеров. Все эти вещи обычно становятся слабыми местами в кроссфункциональных командах.

В моей роли адвокат делает примерно тоже самое, что Head of iOS во многих других компаниях, но больше ориентирован на удовлетворение потребностей разработчиков. Плюс не загружен такими вещами как people-менеджмент, бюджетирование или тушение пожаров. Например, адвокат не бежит тушить пожар сам. Он смотрит на него системно и говорит: «Окей, что нужно, чтобы потушить пожар и как сделать, чтобы его больше не было?»

Если говорить про рост инженеров, давайте представим себе классического техлида. Обычно он хорошо знаком с одной платформой, на которой сам активно разрабатывал. Но если он бэкэндер, и к нему придёт айосник и скажет: «Прокачай меня», вряд ли это хорошо сработает. Я могу выстроить платформу, чтобы iOS-разработчики могли прокачивать друг друга и снять боль с техлида. Это же касается и онбординга по iOS. Я выстраиваю эффективную систему погружения человека в платформу, которую техлиду можно использовать, не выдумывая свою.

В моих целях на первый квартал была задача — построить внутреннее iOS-сообщество. Я сделал постоянные встречи, описал процессы, настроил пайплайн, нашёл нескольких человек, которые мне в этом помогают. И сейчас мы просто ротируемся, проводя встречи раз в неделю.

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

Идеальный флоу — когда человек будет что-то менять, он сколлаборируется с другими своими коллегами, они друг друга лучше узнают, потому что работают в разных командах. Это помогает людям не чувствовать себя одиноко. В кроссфункциональных и распределённых командах, особенно при удалёнке, ситуация, когда ты один iOS разработчик и не с кем обсудить профессиональную тему — большая проблема. Для бизнеса это тоже становится проблемой, потому что люди устают, хуже развивают платформу и в конце-концов уходят.

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

Внешнее сообщество

Моя концепция строится на том, что сначала ты строишь внутрянку, и только потом можешь показывать и открывать её. Часто компании делают так: «А давайте выступим с чем-нибудь, проведём свой митап и захайрим новых сотрудников». А потом человек приходит в компанию и разочаровывается. Поработает какое-то время, но это не win-win. Это не наш подход. 

Мы вкладываемся во внутреннее сообщество и ждём, что рано или поздно оно принесёт пользу. Недавно статья моего коллеги Азиза по Live Activity была номинирована на премию «ТехноТекст» от Хабра. Идея для материала родилась, когда он смотрел WWDC и написал в чате: «О, прикольная фича». Я ответил: «Азиз, запилишь?». И он запилил с привлечением помощи других коллег.

Возникла идея внутри, она получила признание, и мы рассказали про это. Работа с внешним сообществом так и строится — я нахожу инициативы из общения разработчиков между собой и мы что-то делаем. А потом не забываем про них рассказывать и передаём команде Developer Relations.

Если говорить про общение с разработчиками из других компаний, то сейчас я погружён в это меньше, чем когда занимался конференциями. Но когда необходимо, у меня есть социальный граф, и я достаю из него человека для разговора. Мы сейчас прорабатываем архитектуру и навигацию и я дёрнул инженера из Apple: «А как у вас с архитектурой? Какую сами используете?» Дёрнул одного человека по фреймворку навигации, одному из наших ребят дал контакты третьего. 

Фоново занимаюсь организацией CocoaHeads на Кипре. Тоже поднимаю социальный граф, но в меньших масштабах, потому что это локальная активность на небольшом острове. Спрашиваю ребят: «Как у вас двигается разработка? Что вы делаете?» Важно понять, как живёт iOS-индустрия, что интересного есть для переиспользования, туда ли мы движемся. Зачем выдумывать космолёты, если экспертиза уже есть у коллег по цеху? Да и своей в кулуарах можно поделиться.

Как стать дев-адвокатом

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

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

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

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

Мне в своё время очень помогли книги по построению сообществ. Выделю две — Building Brand Communities и Get Together. Также есть полезный канал в Telegram по построению комьюнити. Помогли и бывшие коллеги, которые набросали кучу информации. У меня есть большая Google-табличка с мыслями о том, как работать с сообществом. Если углубиться в продуктовые подходы, тут мне помог курс GoPractice, а также школа менеджмента от «Стратоплана».

Пошагово старт карьеры дев-адвоката можно представить так:

1. Собрать сообщество, послушать боли. 

2. Попробовать запустить одну активность или сделать проект. 

3. Сообщество начнёт кристализироваться, и в какой-то момент сможет жить без тебя. 

Это один путь. Но, как было описано выше, есть другой — выйти в дев-адвокаты со стороны маркетинга и публичного бренда. Для этого можно начать выступать, делать конференции и подкасты. Тут Катя Петрова расскажет лучше. 

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

P.S. Ещё я пишу свои мысли в Telegram-канале и ко мне можно прийти за консультацией по адвокатству.