- PVSM.RU - https://www.pvsm.ru -
Казалось бы, в небольших командах разработки (20+ человек) не должны возникать проблемы с разобщённостью, работой над общим кодом и принятием технических решений. Но все мы знаем, что это не так (не говоря уже о командах вроде нашей, где 80+ человек). Три года назад для их решения мы начали проводить еженедельную внутреннюю конференцию разработчиков DevForum. Под катом вы узнаете про то, как он помогает нам, почему не всегда подходят другие форматы (вроде еженедельных встреч или Sprint Review) и инструкцию по его созданию.
Посвящается тем командам разработки, в которых нет менеджеров, в которых вы работаете над единым кодом, в которых разработчикам интересно знать, что творится вокруг, тем людям, кто хочет развиваться и помогать расти другим, тем командам, кому важно доверие внутри.
From Dodo Pizza Engineering with humanity
DevForum – это наше еженедельное внутреннее мероприятие для разработчиков Dodo IS. Оно проходит по четвергам уже три года. Разработчики собираются вместе и уделяют час времени общению друг с другом.
На этой встрече мы обсуждаем технические вопросы, актуальные для всей команды. Час времени, два доклада по полчаса, время на вопросы и ответы.
Чтобы продвигаться к достижению общей цели нам важно сохранять фокус на значимых вопросах компании. Для общего синхрона всего Dodo мы устраиваем еженедельные встречи по понедельникам. На них присутствуют все сотрудники, партнёры/франчайзи, записи встреч можно посмотреть в свободном доступе [1]. Для синхрона с бизнесом и партнерами мы устраиваем раз в две недели Sprint Review [2]. Для единого фокуса и регулярного синхрона IT-команды нужно большее погружение в техническое «мясо». Этим мы и занимаемся на DevForum.
Вот список проблем и их решений:
Плюс наша команда постоянно расширяется, новые люди приходят и получают готовый инструмент для регулярного апгрейда и шеринга знаний.
Пример. Допустим, у нас есть Олег. Он сидит в инфраструктуре и делает с ребятами проект «Автономность». Когда проект запустится в полную мощь, жизнь простых разработчиков станет проще. Они перестанут дёргать инфраструктуру и будут делать всё сами. Сам всё делаешь, ни от кого не зависишь, прекрасно.
Олег готов произвести изменения в компании. Но он знает, что недостаточно просто написать о проведенных изменениях в Slack. Надо рассказать публично, объяснить, ответить на вопросы, написать статью, провести ряд действий, иначе ничего не поменяется. Олег приходит на DevForum и использует его как инструмент изменений.
Пример. Олег хочет выступать на больших конференциях. Ему нужны почет, слава и тысячи просмотров на Youtube.
Он приходит к нам и честно рассказывает о своих амбициозных целях. Мы в свою очередь выделяем ему площадку для (практически) безболезненной тренировки. При необходимости мы помогаем, подсказываем, направляем.
Порог входа на DevForum (в отличие от митапа или конференции) минимальный. Олегу требуется подготовить тему, подготовить слайды на полчаса и прийти в нужный момент. Это отличная площадка для пробной репетиции. Тренировка на кошках, т.е. на нас. Мы и фидбек дадим, и по слайдам пройдемся, и шуточки на нас можно проверить.
После DevForuma доклад уже можно закидывать на локальный митап. И скорее всего его возьмут.
Откуда вообще взялся этот формат? Коротенечко. Три года назад у нас в компании была первая попытка ввести Sprint Review на регулярной основе.
Это выглядело так: в одной комнате собирались все, абсолютно все и по очереди рассказывали друг другу, кто что сделал за прошедшие недели. На тот момент нас было всего 20 человек, но только представьте себе, каково это слушать и смотреть представителю бизнеса на код, а разработчику смотреть на застройку пиццерий. Мы очень быстро поняли, что люди слушают только темы, которые интересны именно им, а на остальных темах страдальчески залипают в телефон.
Мы столкнулись с тем, что демонстрация глубоко технических тем людям, которые далеки от этого – такое. Они пришли посмотреть, как касса запускается, а мы им про опыт использования фреймворка Polly для реализации ретраев между сервисами. Мы быстро поняли, что такой формат приносит людям мало пользы, и Sprint Review в том виде загнулся. В какой-то момент его просто отменили, а встреча в календаре осталась.
Инициативная группа людей подумала: так это же круто показывать технические вещи тем, кто в теме. Встреча есть, люди есть, желание есть, темы есть. Так мы стали собираться раз в неделю и продолжаем делать это по сей день.
Мы знаем, что наш 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:
1. Infrastructure as code. (In progress...)
2. Генерация Typescript контрактов по c# моделям. (In progress...)
...
Автор: OlesyaBalashova
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/konferentsiya/325759
Ссылки в тексте:
[1] в свободном доступе: https://www.youtube.com/playlist?list=PLXOrZPAO2Ui2F6bMG0NROLCH3tA-7pwEj
[2] Sprint Review: https://www.youtube.com/playlist?list=PLXOrZPAO2Ui0KS49RwwxuKBdxoBms7rA7
[3] Источник: https://habr.com/ru/post/462033/?utm_campaign=462033&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.