Гильдии разработчиков становятся обычным явлением в IT-компаниях. Это своего рода неформальные клубы по интересам, которые помогают улучшать процессы, обмениваться опытом и развивать участников. Потенциал таких сообществ весьма высок, — они могут запустить изменения на уровне всей компании. Но что делать, если активность в гильдии снизилась и стало непонятно, зачем она вообще нужна?
Меня зовут Саша Киверин, я лид Python-гильдии в Циан. Сейчас в нашем сообществе более 60 разработчиков. За последние 2 года мы совместными усилиями сделали целый ряд крутых проектов. Перевели монолит с версии Python 2.7 на 3.12, создали библиотеку для внешних вызовов и внедрили автоматический чеклист здоровья микросервиса. Дотащить все это до прода нам помогли 5 простых советов, которыми я и поделюсь в этой статье. Надеюсь, они помогут оживить и вашу гильдию.
Начну с основ — для чего это вообще всё нужно. Если вы уже знаете — смело переходите к первому совету.
Зачем компании нужна гильдия?
Первый вопрос, который стоит задать себе, и который наверняка зададут стейкхолдеры: зачем компании поддерживать сторонние активности разработчиков, если можно направить их усилия на продукт и получить результат сразу? Вот несколько причин, почему это важно:
Developer Experience (DevEx)
Чтобы понять, что нужно разработчикам и каковы их проблемы, нужно смотреть на ситуацию в целом. Без обмена опытом можно получить ложное впечатление о текущем состоянии дел или, что ещё хуже, потратить ресурсы на проекты, которые никому не нужны. Гильдия помогает сформировать культуру обратной связи, что даёт много полезных инсайтов для улучшения DevEx.
Platform as a Product
Любому продукту нужна обратная связь для развития. В случае с командой платформы клиентом выступает вся гильдия. Обратная связь должна быть своевременной — лучше всего получать её сразу после релиза и в большом объёме. Создавая новые каналы связи с разработчиками, мы ускоряем переход на новые версии библиотек и получаем более быструю обратную связь.
Developer Retention
Разработчики могут устать от рутинных бизнес-задач. Мы не можем перевести всех в команду платформы, но можем предложить им интересные проекты в рамках гильдии. Это позволяет сменить вид деятельности без необходимости менять команду, что снижает текучку.
Growth
Разработчикам нужно расти, а наша задача — помочь им в этом. Гильдия предоставляет возможности для роста за счёт внутренних проектов, которые могут быть более масштабными и сложными, чем задачи в основной команде. Обмен опытом также ускоряет поиск наставников, что помогает развиваться быстрее и качественнее.
Employer-brand
Гильдия напрямую влияет на ускорение найма. Она предоставляет площадку для обмена опытом внутри, что помогает разработчикам легче переходить к внешним выступлениям. Даже если вклад во внешние активности незначителен, гильдия всё равно укрепляет ваш Employer-бренд — рассказ на собеседовании о том, как устроена ваша разработка, становится ярче и убедительнее, особенно когда за ним стоят реальные внутренние проекты и инструменты.
Зачем гильдии нужна компания?
Может ли гильдия существовать отдельно от компании? С планами на устойчивое развитие — нет. Без прозрачного планирования и общения с лидами крупные проекты просто не будут двигаться вперёд — некому будет их реализовывать, так как разработчика просто не отпустят из проектов его команды. А если проекты не связаны с целями компании, то со временем стейкхолдеры перестанут видеть в них смысл.
Вывод простой: для успешной работы гильдии нужно тесно сотрудничать с компанией. Работайте открыто, связывайте свои проекты с целями компании и показывайте результаты. Взамен получайте нужные ресурсы и поддержку.
Теперь перейдем к самой сути изменений: наладьте каналы связи с сообществом, собирайте от них полезные идеи, следите за важными показателями компании и рынка. Делегируйте задачи и популяризируйте планирование среди разработчиков и их лидов.
Совет №1. Запустите регулярные встречи
Регулярные встречи — это важная составляющая успешной работы гильдии. Без них теряется фокус, а разработчики постепенно утрачивают мотивацию. Встречи помогают синхронизировать работу, обменяться важной информацией и выявить проблемы, которые нужно решить.
Собрания по запросу редко приносят пользу, потому что разработчики могут недооценивать важность своих тем и переносят обсуждения в чаты. Таблица тем в большинстве случаев остается пустой.
Частота проведения встреч и их длительность зависят от вашей компании, но важно помнить: длинные встречи отнимают много времени и могут отпугнуть участников. Мы, например, пришли к формату еженедельного синка на 25 минут.
Выбирая время для встречи, постарайтесь учесть расписание всех команд. Желательно, чтобы от каждой был хотя бы один представитель, который затем сможет донести до коллег важные новости, инструменты и практики.
Понимая, что не все разработчики смогут присутствовать, записывайте встречи и сохраняйте их вместе с заметками в канале гильдии. Используйте транскрибацию и ChatGPT для создания кратких тезисов, чтобы уйти от рутины. В нашем случае еженедельные синки посещают 30-50% разработчиков, поэтому заметки в канале — отличный способ охватить остальных.
Бонусный совет: разделяйте каналы гильдии на информационные и дискуссионные. У нас это #python-dev для вопросов и обсуждений, и #python-info для заметок со встреч, важных анонсов и оповещений о релизах внутренних библиотек. Это помогает удерживать внимание разработчиков на ключевых запусках и повышает их вовлеченность.
Совет №2. Сделайте шаблон встречи
Что обсуждать, если мы ушли от встреч по запросу? Создайте типовой шаблон всречи и следуйте ему каждый раз. Обсуждайте статус внутренних проектов, последние запуски, проблемы на продакшене и собирайте обратную связь от разработчиков. Шаблон поможет вам не сбиться с курса, даже если до встречи нет интересных тем для обсуждения. Важно следить за реакцией участников и задавать открытые вопросы, чтобы извлечь как можно больше полезных идей.
Из нашего опыта: на встречах мы обсуждаем текущие внутренние проекты, рекламируем полезные активности, говорим о последних запусках и делимся планами на будущее.
Не забывайте и про достижения людей — не стоит прятать их за общими фразами вроде «на этой неделе появились такие-то фичи». Если кто-то внедрил новый инструмент, подчеркните это на встрече и дайте человеку возможность поделиться опытом. Если кто-то прошёл обучение и стал самостоятельным ведущим собеседований — тоже это отметьте.
Также всегда приглашайте и представляйте новых разработчиков. Это поможет им быстрее адаптироваться и сделает онбординг комфортнее. Из нашего опыта, новые сотрудники охотнее включаются в жизнь гильдии, если с самого начала знакомятся с её культурой.
Совет №3. Собирайте бэклог проектов и дайджест задач
Регулярные встречи и обсуждения — это хорошо, но без конкретных задач и проектов, которыми можно занять участников, активность гильдии начнет падать. Чтобы поддерживать интерес и вовлеченность разработчиков, важно иметь под рукой постоянно обновляемый список задач, которые можно предложить участникам.
Откуда брать проекты? Вот несколько идей:
Чужой опыт. Изучайте, что делают другие компании или соседние стеки у вас в компании, и адаптируйте это под свои нужды.
Тренды. Следите за тенденциями. Это не значит, что нужно посещать все конференции на свете. Иногда достаточно раз в полгода изучить техрадар, например, от Thoughtworks.
Автоматизация. Если есть рутинная ручная работа, постарайтесь её автоматизировать. Например, мы внедрили автоматический реопен задач на CI при недостаточном покрытии, что раньше приходилось делать руками.
Проблемы, о которых говорят сами разработчики. Прежде чем браться за их решение, оцените актуальность и важность этих проблем, а также их соответствие целям гильдии. Даже если к вам приходят сразу с идеей решения, старайтесь сначала точно определить проблему, откуда возникла потребность что-то изменить.
Не откладывайте проекты, если некоторые участники не поддерживают идею. Работайте с их возражениями, постарайтесь понять их причины. Если после уточнений остаются только субъективные аргументы, продолжайте работу над проектом. Например, когда мы внедряли автоматическое форматирование кода, было много споров из-за стиля. Но со временем все привыкли, и теперь 100% наших активных сервисов используют ruff.
Еще один важный момент — барьер для входа в работу над проектами. Крупные задачи часто связаны с неопределённостью, что может отпугнуть разработчиков без успешного опыта решения таких задач. Чтобы помочь им решиться, следуйте простым правилам:
Всегда описывайте проект подробно и чётко формулируйте конечный результат. Так задача станет более понятной и осязаемой.
Найти время на задачу в один день проще, чем на недельный проект. Поэтому мы создали дайджест задач, включив туда небольшие таски до двух дней. Список доступен всем, и любой разработчик может выбрать себе задачу по душе. Дополнительно в дайджест можно закидывать доработки, которые оказались out of scope ваших основных проектов гильдии.
Старайтесь привлечь как можно больше разработчиков к работе над внутренними инструментами. Мы используем метку good-for-introduction для задач, которые не несут больших рисков и помогают освоиться в новой кодовой базе. Это могут быть мелкие правки или улучшение документации.
Совет №4. Ищите таланты
Проект — это хорошо, но для его реализации нужен герой, который возьмёт на себя главную роль. Начните поиск исполнителя с того, кто предложил идею. У него, скорее всего, будет самая высокая мотивация завершить проект. Чтобы ему было легче справиться с задачей, привлеките других участников гильдии и создайте рабочую группу. Однако не отпускайте их в свободное плавание сразу — помогите на старте, ограничьте скоуп проекта и чётко сформулируйте definition of done.
Другой источник потенциальных исполнителей — активные участники гильдии. Со временем у вас появятся разработчики, которые чаще других участвуют в обсуждениях, посещают встречи и делятся своими идеями. Не забывайте также о тех, кто уже успешно реализовал проекты — на них можно положиться. Обратитесь к кому-то из них, и вы не прогадаете.
Рекламируйте свободные проекты на общих встречах и в заметках — продвигайте их через техническую сложность и пользу для сообщества. Это особенно важно в конце квартала, когда команды планируют работу и у разработчиков могут появиться слоты, которые можно занять проектами гильдии.
Бонусный совет: лидеру гильдии не обязательно брать на себя самый большой объем задач. Гораздо эффективнее в долгосрочной перспективе сосредоточиться на росте числа активных участников и делегировании. Считайте своей задачей сделать как можно больше работы не своими руками. Производительность одного лида не сравнится с работой нескольких десятков участников гильдии, даже если среди них активно участвуют только 20%. Однако брать на себя отдельные задачи всё равно полезно, чтобы сохранять общий контекст и связь с разработчиками.
Совет №5. Работайте с прозрачностью
Часто бывает, что проект стартует, но не доходит до финиша или движется очень медленно. Чтобы поддерживать мотивацию и темп, нужно избегать двух основных проблем: отсутствия результатов и обратной связи после проделанной работы.
У отсутствия результатов может быть несколько причин:
Непрозрачное планирование. Если проект плохо спланирован в команде, его приходится делать параллельно с основными задачами или даже вне рабочего времени, что вредит как проекту, так и разработчику. Перед стартом проекта убедитесь, что на него выделено время. Попросите разработчика обсудить это с лидом или сделайте это сами. Даже если проект запланирован на конец квартала, это лучше, чем работать совсем без плана.
Блокеры. Иногда проект тормозится из-за того, что требуется техническая или организационная помощь. Лучший способ минимизировать такие проблемы — выявлять их на ранних стадиях. Если на регулярной встрече гильдии давно не было новостей по проекту, это знак, что нужно обсудить ситуацию с разработчиком.
Слишком большой объём работы. Старайтесь сокращать скоуп до старта проекта и проводите повторную декомпозицию после, если это необходимо. Чем раньше проект будет завершён, тем быстрее у разработчика появится первая «история успеха», которая станет мотивацией для дальнейшей работы.
Когда проект наконец добрался до пользователей, это успех. Но со временем разработчик может утратить мотивацию брать на себя новые задачи. Почему так происходит?
Нет ощущения значимости проекта. Предложите разработчику рассказать о своём опыте и сложностях, с которыми он столкнулся. Такие истории обычно вызывают интерес в гильдии и усиливают чувство полезности у самого разработчика. Мы, например, периодически проводим внутренние митапы вместо обычных синков, где делимся такими кейсами.Кстати, такие митапы затем удобно конвертируются в выступления на конференциях и статьи.
Отсутствие влияния на карьерный рост. Возможность повышения грейда — сильный стимул для разработчиков. Чтобы лучше оценить вклад на performance review, разделите оценку работы в команде и участие в гильдии. Мы у себя сделали именно так и приравняли участие в гильдии по значимости к продуктовой разработке.
Дополнительная мотивация. Новый грейд — это хорошо, но почему бы не добавить что-то ещё? Мы, например, раз в квартал выбираем самых активных участников гильдии, чей вклад особенно запомнился, и награждаем их внутренней валютой, которую можно потратить на мерч. Это может показаться мелочью, но такой подход заметно поднимает настроение и мотивацию.
Подводим итоги
Итак, что у нас получилось:
Регулярные встречи: организуйте регулярные встречи, записывайте их и делайте заметки для тех, кто не смог присутствовать. Это поможет поддерживать осведомленность разработчиков о жизни их стека.
Шаблон встреч: сформируйте свой шаблон встречи. Включите в него обсуждение активных проектов, новости Python и компании, и обязательно отмечайте достижения участников. Не забывайте, что цель встречи — собрать как можно больше инсайтов, а не просто обсудить интересные темы.
Бэклог и дайджест задач: создайте и регулярно пополняйте бэклог проектов и дайджест небольших задач. Ищите идеи в трендах, опыте других компаний и проблемах, с которыми сталкиваются разработчики. Бэклог и дайджест всегда должны быть полны.
Поиск исполнителей: предложите авторам идей самим довести проект до конца. Если это невозможно, привлекайте активных участников гильдии и помогите им сформировать рабочую группу и правильно поставить задачу.
Прозрачность и мотивация: работайте прозрачно, планируя проекты наравне с продуктовыми задачами. Поддерживайте идею, что работа в сообществе должна оцениваться компанией наравне с основной деятельностью. И не забывайте про дополнительную мотивацию — награждайте самых активных участников.
Конечно, этот список можно продолжать, но дальше это будут уже детали. Если бы мне нужно было описать весь опыт с гильдией одной фразой, я бы сказал: цените людей, их опыт и их проблемы. Удачи на пути к идеальному DevEx!