Казалось бы, в небольших командах разработки (20+ человек) не должны возникать проблемы с разобщённостью, работой над общим кодом и принятием технических решений. Но все мы знаем, что это не так (не говоря уже о командах вроде нашей, где 80+ человек). Три года назад для их решения мы начали проводить еженедельную внутреннюю конференцию разработчиков DevForum. Под катом вы узнаете про то, как он помогает нам, почему не всегда подходят другие форматы (вроде еженедельных встреч или Sprint Review) и инструкцию по его созданию.
Посвящается тем командам разработки, в которых нет менеджеров, в которых вы работаете над единым кодом, в которых разработчикам интересно знать, что творится вокруг, тем людям, кто хочет развиваться и помогать расти другим, тем командам, кому важно доверие внутри.
From Dodo Pizza Engineering with humanity
Что такое DevForum и какие проблемы он решает?
DevForum – это наше еженедельное внутреннее мероприятие для разработчиков Dodo IS. Оно проходит по четвергам уже три года. Разработчики собираются вместе и уделяют час времени общению друг с другом.
На этой встрече мы обсуждаем технические вопросы, актуальные для всей команды. Час времени, два доклада по полчаса, время на вопросы и ответы.
Какие проблемы решает внутренняя конференция
Чтобы продвигаться к достижению общей цели нам важно сохранять фокус на значимых вопросах компании. Для общего синхрона всего Dodo мы устраиваем еженедельные встречи по понедельникам. На них присутствуют все сотрудники, партнёры/франчайзи, записи встреч можно посмотреть в свободном доступе. Для синхрона с бизнесом и партнерами мы устраиваем раз в две недели Sprint Review. Для единого фокуса и регулярного синхрона IT-команды нужно большее погружение в техническое «мясо». Этим мы и занимаемся на DevForum.
Вот список проблем и их решений:
- Шеринг знаний. Сейчас у нас в команде работает 80+ разработчиков. У каждого из них свой бекграунд, своя специфика работы, свой уровень погружения. Наши команды разделены по продуктам. И может сложиться так, что двум независимым командам понадобится пройти через одни и те же дебри. Когда у них есть возможность поделиться друг с другом своими наработками, мыслями, успехами или наоборот фейлами, становится лучше. Появляется небольшая вероятность не наступить на чьи-то грабли.
Плюс наша команда постоянно расширяется, новые люди приходят и получают готовый инструмент для регулярного апгрейда и шеринга знаний.
- Обучение. Тут можно научиться, если не умеешь сам и научить, если умеешь. Обучение – это пойнт, который очень тесно переплетён с шерингом знаний. Хотим мы этого или нет, мы должны постоянно повышать свой технический уровень.
- Технический синхрон команд (не путать с ежедневным синхроном команды). Легко быть в курсе всего, когда вас всего три человека. Сейчас нас сильно больше. Иногда мы сталкиваемся с такой проблемой: команды работали параллельно над одним продуктом, но не знали, что делает каждая в отдельности. В итоге возникали конфликты, переписывание чужого кода и т.д. Когда одни делают, а другие выкидывают, процесс разработки может пробуксовывать. На DevForum мы, в том числе, фокусируемся на техническом синхроне команд и боремся с разобщенностью.
- Инструмент изменений. Сюда можно прийти и изменить ход истории. Тут нужно рассказывать на примере.
Пример. Допустим, у нас есть Олег. Он сидит в инфраструктуре и делает с ребятами проект «Автономность». Когда проект запустится в полную мощь, жизнь простых разработчиков станет проще. Они перестанут дёргать инфраструктуру и будут делать всё сами. Сам всё делаешь, ни от кого не зависишь, прекрасно.
Олег готов произвести изменения в компании. Но он знает, что недостаточно просто написать о проведенных изменениях в Slack. Надо рассказать публично, объяснить, ответить на вопросы, написать статью, провести ряд действий, иначе ничего не поменяется. Олег приходит на DevForum и использует его как инструмент изменений.
- Тренировка перед выступлением. Тут можно потренироваться перед большим выступлением. Снова возьмем Олега для примера.
Пример. Олег хочет выступать на больших конференциях. Ему нужны почет, слава и тысячи просмотров на Youtube.
Он приходит к нам и честно рассказывает о своих амбициозных целях. Мы в свою очередь выделяем ему площадку для (практически) безболезненной тренировки. При необходимости мы помогаем, подсказываем, направляем.
Порог входа на DevForum (в отличие от митапа или конференции) минимальный. Олегу требуется подготовить тему, подготовить слайды на полчаса и прийти в нужный момент. Это отличная площадка для пробной репетиции. Тренировка на кошках, т.е. на нас. Мы и фидбек дадим, и по слайдам пройдемся, и шуточки на нас можно проверить.
После DevForuma доклад уже можно закидывать на локальный митап. И скорее всего его возьмут.
Немного ретро: как появился DevForum
Откуда вообще взялся этот формат? Коротенечко. Три года назад у нас в компании была первая попытка ввести Sprint Review на регулярной основе.
Это выглядело так: в одной комнате собирались все, абсолютно все и по очереди рассказывали друг другу, кто что сделал за прошедшие недели. На тот момент нас было всего 20 человек, но только представьте себе, каково это слушать и смотреть представителю бизнеса на код, а разработчику смотреть на застройку пиццерий. Мы очень быстро поняли, что люди слушают только темы, которые интересны именно им, а на остальных темах страдальчески залипают в телефон.
Мы столкнулись с тем, что демонстрация глубоко технических тем людям, которые далеки от этого – такое. Они пришли посмотреть, как касса запускается, а мы им про опыт использования фреймворка Polly для реализации ретраев между сервисами. Мы быстро поняли, что такой формат приносит людям мало пользы, и Sprint Review в том виде загнулся. В какой-то момент его просто отменили, а встреча в календаре осталась.
Инициативная группа людей подумала: так это же круто показывать технические вещи тем, кто в теме. Встреча есть, люди есть, желание есть, темы есть. Так мы стали собираться раз в неделю и продолжаем делать это по сей день.
- Мы стали записывать наши выступления. Сам формат идёт три года, записи у нас есть за два года. Все они хранятся в одном месте, при желании можно пересмотреть.
- Мы ушли от формата демонстрации, потому что пришли к выводу, что подготовка и само демо отнимают больше времени, чем формат презентации.
- Мы перешли к формату презентации, к которому легко подготовиться, уделив этому буквально 40 минут времени (хотя тут, конечно, зависит от сложности темы и выступающего).
- Сначала на DevForum выступал каждый разработчик. В какой-то момент времени мы сделали допущение о выступлении не каждого человека в отдельности, а представителя от команды.
- Потом мы пошли дальше и перестали приставать с предложением выступить тем командам, у которых сейчас «ничего не происходит».
- Изначально мы умещали в час четыре темы, но пришли к выводу, что какими бы интересными не были доклады, к концу часа в голове остается только каша. Поэтому теперь мы берём на DevForum одну-две темы, 25 минут доклада и 5 минут на вопросы.
- Недавно мы приняли решение немного расширить круг тем и иногда приглашать внешних спикеров.
Мы знаем, что наш DevForum не является суперуникальным форматом, многие наши коллеги пробовали что-то похожее. Но, к сожалению, часто такие регулярные встречи не приживаются, быстро изживают себя и увядают. Наш DevForum живет три года – это долгий срок для того, чтобы провести анализ, собрать экспертизу и поделиться с вами опытом создания и поддержания такого формата.
Как организовать DevForum в своей компании
Вам понадобится 6 основных вещей:
1. Понимание задач и форматов DevForum.
Есть два выверенных формата выступления, которые выработались у нас за три года. Можно брать на вооружение:
Доклад: один разработчик готовится и выступает, а другие задают вопросы.
Пример. Однажды в качестве доклада была тема «Структурное логирование», где рассказали про serilog, его использование в наших проектах, про то, как он помогает лучше работать с логами в Kibana. Также там была затронута тема структурного логирования через NLog и использования общих интерфейсов ILogging для .NET CORE проектов.
После презентации была сессия вопросов, и все участники поняли, как просто добавить эту либу в новый проект. Это заняло у нас 30 минут. Еще полчаса мы обсуждали в тот день уровни логирования типа Debug, Info, Warn, Error etc., а конкретно то, какими уровнями описывать какие ситуации в системе. На сессии вопросов была затронута проблема шума errors в логах, особенно связанных с ретраями.
Принятие решения: есть проблема, которая так или иначе касается всех. Люди приходят с возможными вариантами решения, чтобы остановиться на чём-то одном.
Пример. Мы собирали DevForum для обсуждения Definition of done и хотели стабилизировать качество поставляемого на продакшн кода. Но как это сделать, когда у тебя над общим кодом работает сразу несколько команд? Решением было сделать общий для всех Definition of done пользовательских историй. В предложенном DOD был спорный пункт. Мы собрались и обсудили нужен он нам или нет. Было принято общее решение. Для его воплощения мы добавили пункт в чек-лист в нашем таск-трекере (Kaiten) и сделали его обязательным пунктом при закрытии задач.
2. Мощные и заряженные организаторы.
В нашем случае у нас есть 3 организатора от разработчиков, а также активно помогающая команда IT-бренда.
3. Согласие со стороны руководства вашего IT-департамента.
4. Наличие пространства и оборудования для встреч.
Мы собираемся всегда в одной забронированной «навечно на это время» переговорке в офисе, но при этом транслируем все в общем Google meet, который также одинаковый и не меняется между встречами.
Переговорка у нас большая, вмещающая 20-30 человек. Есть проектор и система вывода звука для удалённого созвона. Все знают, что по четвергам с 16:00 до 17:00 в этой переговорке проходит DevForum.
В связи с тем, что у нас частично распределённая разработка, мы обязательно выводим удалёнщиков на общий созвон. Также это позволяет спикерам показывать свой экран со своего компьютера, подключаясь к общей встрече. Спикеры могут находиться в общей переговорке или в любом другом удобном для них месте. Мы все будем их слышать, а также видеть их экран.
Обозначенное постоянное пространство делает эту встречу более надёжной и предсказуемой для участников.
5. Наличие аудитории слушателей.
Там происходят анонсы встреч, обсуждение после, выбор тем и дискуссия по темам.
Чтобы люди участвовали в жизни форума, мы устраиваем опросы, просим давать обратную связь спикерам, а также публикуем запись встречи на следующий день утром.
Также важно, что мероприятие является добровольным и необязательным к посещению. Да, оно проводится в рабочее время, но если кто-то хочет поработать или у него есть более важные дела в это время, он может пропустить.
Пример публикации после мероприятия:
Пример дискуссии после встречи:
6. Наличие спикеров и тем для обсуждения.
Вот лишь краткий список мероприятий, которые делают организаторы для того, чтобы вовлекать людей:
- Ищем темы заранее, составляем план выступления более чем на неделю. По началу мы искали темы в начале недели, а уже в четверг надо было выступать.
- Заходим в каналы команд и спрашиваем явно: есть ли темы для DevForum?
- Проводим личные беседы в программистами, сподвигая их на выступления. Обосновываем ценность для спикера участвовать: более глубокое понимание темы, опыт выступлений, общественная польза, материал для будущей статьи, конференции.
- Вбрасываем в канал темы для обсуждения, которые людям было бы интересно послушать. Знающие тему разработчики могут откликнуться и выступить в качестве докладчика.
- Реагируем на общественно-важные события, самостоятельно устраивая обсуждения по проблемным темам разработки.
- Смотрим прошедшие конференции с нашими участниками. После посещения конференций всегда есть что рассказать.
- По итогам важных для нас конференций, которые посещало много людей от нас, устраиваем обсуждение в формате «3 лучших доклада с последнего Highload++».
- Приглашаем внешних спикеров.
Ещё кое-что важное
Может показаться, что всё просто (или наоборот ничего не понятно), поэтому я перечислю еще несколько особенностей организации, которые надо учитывать и иметь ввиду.
Организаторам нужно вести работу с выступающими. Боязнь выступлений мы решаем через помощь в подготовке к выступлению. Лень или неорганизованность купируем просьбой заранее сформулировать тему, пусть даже в черновом виде, и точно обозначенной датой выступления.
Иногда тем нет. Бывают периоды, когда тем нашлось много, бывает, когда мало. В этом случае категорически нельзя отменять мероприятие. Надо стараться находить темы или выступать самим. Организаторы – это тоже разработчики, поэтому нам тоже всегда есть что рассказать. Можно прибегать к хитростям, устраивая более свободные обсуждения.
Качество видео и звука. Сугубо технический момент, но людям важно, чтобы звук был хорошим (проверяем заранее связь и интернет), а демонстрация кода на экране была читаемой. Даже самая интересная тема, поданая с техническими огрехами, может оттолкнуть зрителей.
Накапливаем материал. Встречи должны быть записаны. У нас есть архив видео, с прикрепленными туда презентациями и дополнительными материалами. Есть плейлисты в ютубе. Все записи мы складываем в нашу систему документации, где есть полнотекстовый поиск и можно найти интересующую тему после и ознакомиться.
За три года мы накопили много годного контента. Поэтому тут будет серия статей, написанных по мотивам выступлений на DevForum:
1. Infrastructure as code. (In progress...)
2. Генерация Typescript контрактов по c# моделям. (In progress...)
...
Автор: OlesyaBalashova
