Казалось бы, в небольших командах разработки (20+ человек) не должны возникать проблемы с разобщённостью, работой над общим кодом и принятием технических решений. Но все мы знаем, что это не так (не говоря уже о командах вроде нашей, где 80+ человек). Три года назад для их решения мы начали проводить еженедельную внутреннюю конференцию разработчиков DevForum. Под катом вы узнаете про то, как он помогает нам, почему не всегда подходят другие форматы (вроде еженедельных встреч или Sprint Review) и инструкцию по его созданию.
DevForum – это наше еженедельное внутреннее мероприятие для разработчиков Dodo IS. Оно проходит по четвергам уже три года. Разработчики собираются вместе и уделяют час времени общению друг с другом.
На этой встрече мы обсуждаем технические вопросы, актуальные для всей команды. Час времени, два доклада по полчаса, время на вопросы и ответы.
Чтобы продвигаться к достижению общей цели нам важно сохранять фокус на значимых вопросах компании. Для общего синхрона всего Dodo мы устраиваем еженедельные встречи по понедельникам. На них присутствуют все сотрудники, партнёры/франчайзи, записи встреч можно посмотреть в свободном доступе. Для синхрона с бизнесом и партнерами мы устраиваем раз в две недели Sprint Review. Для единого фокуса и регулярного синхрона IT-команды нужно большее погружение в техническое «мясо». Этим мы и занимаемся на DevForum.
Вот список проблем и их решений:
Откуда вообще взялся этот формат? Коротенечко. Три года назад у нас в компании была первая попытка ввести Sprint Review на регулярной основе.
Это выглядело так: в одной комнате собирались все, абсолютно все и по очереди рассказывали друг другу, кто что сделал за прошедшие недели. На тот момент нас было всего 20 человек, но только представьте себе, каково это слушать и смотреть представителю бизнеса на код, а разработчику смотреть на застройку пиццерий. Мы очень быстро поняли, что люди слушают только темы, которые интересны именно им, а на остальных темах страдальчески залипают в телефон.
Мы столкнулись с тем, что демонстрация глубоко технических тем людям, которые далеки от этого – такое. Они пришли посмотреть, как касса запускается, а мы им про опыт использования фреймворка Polly для реализации ретраев между сервисами. Мы быстро поняли, что такой формат приносит людям мало пользы, и Sprint Review в том виде загнулся. В какой-то момент его просто отменили, а встреча в календаре осталась.
Инициативная группа людей подумала: так это же круто показывать технические вещи тем, кто в теме. Встреча есть, люди есть, желание есть, темы есть. Так мы стали собираться раз в неделю и продолжаем делать это по сей день.
Мы знаем, что наш DevForum не является суперуникальным форматом, многие наши коллеги пробовали что-то похожее. Но, к сожалению, часто такие регулярные встречи не приживаются, быстро изживают себя и увядают. Наш DevForum живет три года – это долгий срок для того, чтобы провести анализ, собрать экспертизу и поделиться с вами опытом создания и поддержания такого формата.
Вам понадобится 6 основных вещей:
1. Понимание задач и форматов DevForum.
2. Мощные и заряженные организаторы.
3. Согласие со стороны руководства вашего IT-департамента.
4. Наличие пространства и оборудования для встреч.
5. Наличие аудитории слушателей.
6. Наличие спикеров и тем для обсуждения.
Может показаться, что всё просто (или наоборот ничего не понятно), поэтому я перечислю еще несколько особенностей организации, которые надо учитывать и иметь ввиду.
Организаторам нужно вести работу с выступающими. Боязнь выступлений мы решаем через помощь в подготовке к выступлению. Лень или неорганизованность купируем просьбой заранее сформулировать тему, пусть даже в черновом виде, и точно обозначенной датой выступления.
Иногда тем нет. Бывают периоды, когда тем нашлось много, бывает, когда мало. В этом случае категорически нельзя отменять мероприятие. Надо стараться находить темы или выступать самим. Организаторы – это тоже разработчики, поэтому нам тоже всегда есть что рассказать. Можно прибегать к хитростям, устраивая более свободные обсуждения.
Качество видео и звука. Сугубо технический момент, но людям важно, чтобы звук был хорошим (проверяем заранее связь и интернет), а демонстрация кода на экране была читаемой. Даже самая интересная тема, поданая с техническими огрехами, может оттолкнуть зрителей.
Накапливаем материал. Встречи должны быть записаны. У нас есть архив видео, с прикрепленными туда презентациями и дополнительными материалами. Есть плейлисты в ютубе. Все записи мы складываем в нашу систему документации, где есть полнотекстовый поиск и можно найти интересующую тему после и ознакомиться.
Посвящается тем командам разработки, в которых нет менеджеров, в которых вы работаете над единым кодом, в которых разработчикам интересно знать, что творится вокруг, тем людям, кто хочет развиваться и помогать расти другим, тем командам, кому важно доверие внутри.
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.
Подробнее
Для понимания, надо ли вообще запускать у себя DevForum, можно свериться с теми задачами, которые, этот формат решает у нас в Dodo. Это задачи коммуникации, обучения и самореализации программистов. DevForum – гибкий механизм и может в тот или иной момент времени больше работать на достижение разных целей.
Есть два выверенных формата выступления, которые выработались у нас за три года. Можно брать на вооружение:
Доклад: один разработчик готовится и выступает, а другие задают вопросы.
Пример. Однажды в качестве доклада была тема «Структурное логирование», где рассказали про serilog, его использование в наших проектах, про то, как он помогает лучше работать с логами в Kibana. Также там была затронута тема структурного логирования через NLog и использования общих интерфейсов ILogging для .NET CORE проектов.
После презентации была сессия вопросов, и все участники поняли, как просто добавить эту либу в новый проект. Это заняло у нас 30 минут. Еще полчаса мы обсуждали в тот день уровни логирования типа Debug, Info, Warn, Error etc., а конкретно то, какими уровнями описывать какие ситуации в системе. На сессии вопросов была затронута проблема шума errors в логах, особенно связанных с ретраями. С того DevForum все новые проекты микросервисов используют именно Serilog, а также он появился в нашем шаблоне сервиса.
Принятие решения: есть проблема, которая так или иначе касается всех. Люди приходят с возможными вариантами решения, чтобы остановиться на чём-то одном.
Пример. Мы собирали DevForum для обсуждения Definition of done и хотели стабилизировать качество поставляемого на продакшн кода. Но как это сделать, когда у тебя над общим кодом работает сразу несколько команд? Решением было сделать общий для всех Definition of done пользовательских историй. В предложенном DOD был спорный пункт. Мы собрались и обсудили нужен он нам или нет. Было принято общее решение. Для его воплощения мы добавили пункт в чек-лист в нашем таск-трекере (Kaiten) и сделали его обязательным пунктом при закрытии задач. Некоторые команды потом ещё дополнительно усилили DoD, добавив туда свои собственные важные именно им пункты.
Есть два выверенных формата выступления, которые выработались у нас за три года. Можно брать на вооружение:
Доклад: один разработчик готовится и выступает, а другие задают вопросы.
Пример. Однажды в качестве доклада была тема «Структурное логирование», где рассказали про serilog, его использование в наших проектах, про то, как он помогает лучше работать с логами в Kibana. Также там была затронута тема структурного логирования через NLog и использования общих интерфейсов ILogging для .NET CORE проектов.
После презентации была сессия вопросов, и все участники поняли, как просто добавить эту либу в новый проект. Это заняло у нас 30 минут. Еще полчаса мы обсуждали в тот день уровни логирования типа Debug, Info, Warn, Error etc., а конкретно то, какими уровнями описывать какие ситуации в системе. На сессии вопросов была затронута проблема шума errors в логах, особенно связанных с ретраями. С того DevForum все новые проекты микросервисов используют именно Serilog, а также он появился в нашем шаблоне сервиса.
Принятие решения: есть проблема, которая так или иначе касается всех. Люди приходят с возможными вариантами решения, чтобы остановиться на чём-то одном.
Пример. Мы собирали DevForum для обсуждения Definition of done и хотели стабилизировать качество поставляемого на продакшн кода. Но как это сделать, когда у тебя над общим кодом работает сразу несколько команд? Решением было сделать общий для всех Definition of done пользовательских историй. В предложенном DOD был спорный пункт. Мы собрались и обсудили нужен он нам или нет. Было принято общее решение. Для его воплощения мы добавили пункт в чек-лист в нашем таск-трекере (Kaiten) и сделали его обязательным пунктом при закрытии задач. Некоторые команды потом ещё дополнительно усилили DoD, добавив туда свои собственные важные именно им пункты.
2. Мощные и заряженные организаторы.
Подробнее
Что ещё нужно обязательно учитывать, так это наличие постоянно занимающихся мероприятием людей – организаторов. Важно, чтобы они были из разработчиков или людей, понимающих в технической части. Им придётся помогать участникам в формулировании тем, выискивать новых спикеров и даже иногда поддерживать дискуссию, задавая хорошие вопросы.
В нашем случае у нас есть 3 организатора от разработчиков, а также активно помогающая команда IT-бренда.
В нашем случае у нас есть 3 организатора от разработчиков, а также активно помогающая команда IT-бренда.
3. Согласие со стороны руководства вашего IT-департамента.
Подробнее
Помимо целей и организаторов важной составляющей успешности мероприятия является отсутствие противодействия сверху. Этот процесс – чисто низовая инициатива, можно сказать, что это делают энтузиасты. Помощь со стороны руководства может сказаться положительно, а противодействие будет губительным. Всё-таки люди собираются в рабочее время, используют помещения и оборудование офиса. Это, как минимум, должно не возбраняться.
4. Наличие пространства и оборудования для встреч.
Подробнее
Пространством может быть как переговорная комната в офисе, так и виртуальное место встречи, общий созвон в Skype или Google meet.
Мы собираемся всегда в одной забронированной «навечно на это время» переговорке в офисе, но при этом транслируем все в общем Google meet, который также одинаковый и не меняется между встречами.
Переговорка у нас большая, вмещающая 20-30 человек. Есть проектор и система вывода звука для удалённого созвона. Все знают, что по четвергам с 16:00 до 17:00 в этой переговорке проходит DevForum.
В связи с тем, что у нас частично распределённая разработка, мы обязательно выводим удалёнщиков на общий созвон. Также это позволяет спикерам показывать свой экран со своего компьютера, подключаясь к общей встрече. Спикеры могут находиться в общей переговорке или в любом другом удобном для них месте. Мы все будем их слышать, а также видеть их экран.
Обозначенное постоянное пространство делает эту встречу более надёжной и предсказуемой для участников.
Мы собираемся всегда в одной забронированной «навечно на это время» переговорке в офисе, но при этом транслируем все в общем Google meet, который также одинаковый и не меняется между встречами.
Переговорка у нас большая, вмещающая 20-30 человек. Есть проектор и система вывода звука для удалённого созвона. Все знают, что по четвергам с 16:00 до 17:00 в этой переговорке проходит DevForum.
В связи с тем, что у нас частично распределённая разработка, мы обязательно выводим удалёнщиков на общий созвон. Также это позволяет спикерам показывать свой экран со своего компьютера, подключаясь к общей встрече. Спикеры могут находиться в общей переговорке или в любом другом удобном для них месте. Мы все будем их слышать, а также видеть их экран.
Обозначенное постоянное пространство делает эту встречу более надёжной и предсказуемой для участников.
5. Наличие аудитории слушателей.
Подробнее
Для сбора участников у нас есть постоянный канал в слаке #devforum, где точно сидят все разработчики. Мы даже включили этот канал в список обязательных каналов в чек-листе нового разработчика. Плюс менторы новичков обеспечивают, чтобы они попадали в канал #devforum.
Там происходят анонсы встреч, обсуждение после, выбор тем и дискуссия по темам.
Чтобы люди участвовали в жизни форума, мы устраиваем опросы, просим давать обратную связь спикерам, а также публикуем запись встречи на следующий день утром.
Также важно, что мероприятие является добровольным и необязательным к посещению. Да, оно проводится в рабочее время, но если кто-то хочет поработать или у него есть более важные дела в это время, он может пропустить.
Пример публикации после мероприятия:
Пример дискуссии после встречи:
Там происходят анонсы встреч, обсуждение после, выбор тем и дискуссия по темам.
Чтобы люди участвовали в жизни форума, мы устраиваем опросы, просим давать обратную связь спикерам, а также публикуем запись встречи на следующий день утром.
Также важно, что мероприятие является добровольным и необязательным к посещению. Да, оно проводится в рабочее время, но если кто-то хочет поработать или у него есть более важные дела в это время, он может пропустить.
Пример публикации после мероприятия:
Пример дискуссии после встречи:
6. Наличие спикеров и тем для обсуждения.
Подробнее
Это самая главная и самая сложная часть организации. Здесь мы сталкиваемся с проблемами, как поиска докладчиков, так и наличия тем.
Вот лишь краткий список мероприятий, которые делают организаторы для того, чтобы вовлекать людей:
Вот лишь краткий список мероприятий, которые делают организаторы для того, чтобы вовлекать людей:
- Ищем темы заранее, составляем план выступления более чем на неделю. По началу мы искали темы в начале недели, а уже в четверг надо было выступать.
- Заходим в каналы команд и спрашиваем явно: есть ли темы для DevForum?
- Проводим личные беседы в программистами, сподвигая их на выступления. Обосновываем ценность для спикера участвовать: более глубокое понимание темы, опыт выступлений, общественная польза, материал для будущей статьи, конференции.
- Вбрасываем в канал темы для обсуждения, которые людям было бы интересно послушать. Знающие тему разработчики могут откликнуться и выступить в качестве докладчика.
- Реагируем на общественно-важные события, самостоятельно устраивая обсуждения по проблемным темам разработки.
- Смотрим прошедшие конференции с нашими участниками. После посещения конференций всегда есть что рассказать.
- По итогам важных для нас конференций, которые посещало много людей от нас, устраиваем обсуждение в формате «3 лучших доклада с последнего Highload++».
- Приглашаем внешних спикеров.
Ещё кое-что важное
Может показаться, что всё просто (или наоборот ничего не понятно), поэтому я перечислю еще несколько особенностей организации, которые надо учитывать и иметь ввиду.
Организаторам нужно вести работу с выступающими. Боязнь выступлений мы решаем через помощь в подготовке к выступлению. Лень или неорганизованность купируем просьбой заранее сформулировать тему, пусть даже в черновом виде, и точно обозначенной датой выступления.
Иногда тем нет. Бывают периоды, когда тем нашлось много, бывает, когда мало. В этом случае категорически нельзя отменять мероприятие. Надо стараться находить темы или выступать самим. Организаторы – это тоже разработчики, поэтому нам тоже всегда есть что рассказать. Можно прибегать к хитростям, устраивая более свободные обсуждения.
Качество видео и звука. Сугубо технический момент, но людям важно, чтобы звук был хорошим (проверяем заранее связь и интернет), а демонстрация кода на экране была читаемой. Даже самая интересная тема, поданая с техническими огрехами, может оттолкнуть зрителей.
Накапливаем материал. Встречи должны быть записаны. У нас есть архив видео, с прикрепленными туда презентациями и дополнительными материалами. Есть плейлисты в ютубе. Все записи мы складываем в нашу систему документации, где есть полнотекстовый поиск и можно найти интересующую тему после и ознакомиться.
За три года мы накопили много годного контента. Поэтому тут будет серия статей, написанных по мотивам выступлений на DevForum:
1. Infrastructure as code. (In progress...)
2. Генерация Typescript контрактов по c# моделям. (In progress...)
...
Комментарии (17)
codemafia
02.08.2019 07:30-2Предлагаю переименовать статью в "Практики эффективного менеджмента. Пытаем разработчиков."
OlesyaBalashova Автор
02.08.2019 11:16Я понимаю вашу мысль, но если добавить фактов, то должно получится «Разработчики пытают разработчиков», потому что так называемые менеджеры никак не участвуют в этом мероприятии. Организуют встречу разработчики для своих же разработчиков.
Xander_Vi
02.08.2019 09:25+1Помимо описанных в статье сложностей, есть еще одна, чисто биологическая — условное разделение на сов и жаворонков. Кому-то проще концентрировать внимание с утра, кому-то — во второй половине дня. В итоге, чем большее количество людей одновременно участвует в серьезном техническом обсуждении, тем выше шанс, что для кого-то выбранное время — будет временем его не максимальной продуктивности.
Ну а это, в свою очередь, приводит к фотографиям с «моргающими» людьми)OlesyaBalashova Автор
02.08.2019 11:19Да, соглашусь с вами. Если выходит так, что тема доклада интересна, но при этом конкретный разработчик именно в этот день слишком устал или плохо себя чувствует или конкретно сегодня он «сова», всегда есть видеозаписи (всегда можно обратиться к ним в более благоприятный для себя биологический период).
Matisumi
02.08.2019 10:41-3Добавим в процесс обычные некому не нужные совещания, но обернем их в яркую маркетинговую упаковку с налетом сектантства, ага.
Schvepsss
02.08.2019 11:20+2Кажется вы упускаете из виду очень простую вещь – это не обязательная встреча / совещание. И для того, чтобы люди приходили туда нужно обеспечивать качественный контент, спикеров и темы. Если бы они были не нужны, люди бы просто не ходили и формат умер.
Также, через эту конференцию мы в первую очередь решаем проблемы команд: синхронизацию, шеринг знаний, помогаем желающим делать первые шаги к публичным выступлениям. Постоянно собираем с людей ОС. Поэтому да, можно сказать, что это маркетинг в классическом смысле, когда ты выявляешь потребности аудитории и помогаешь их решать.
И ещё интересно узнать, где вы здесь увидели сектантство? Вот это прямо неожиданный поворот. Я безусловно понимаю, что скорее всего это ваша общая интерпретация компании, но хотелось бы понять как это относится к статье и DevForum.puyol_dev2
02.08.2019 18:06Как показывает практика, самые интересные идет рождаются в курилках )
DmitryNovoselov
05.08.2019 13:34+1Что не мешает потом рассказать о них другим на DevForum'е
OlesyaBalashova Автор
05.08.2019 13:43В курилке можно как раз провести быстрый тест на актуальность темы.
Tom910
04.08.2019 23:15Спасибо за статью, тоже провожу каждые две недели общую техническую встречу между командами и есть куда развиваться и да, самое трудное это поиск тем и что не так часто хотят рассказать о чем либо.
OlesyaBalashova Автор
05.08.2019 13:39Класс! Расскажите, что общего, а что различного в вашем и нашем формате? Хотим обмениваться опытом =)
У нас еще бывают ситуации, когда разработчик долго варится в своей теме, глаз замыливается и ему начинает казаться, что об этом знают все и нет смысла рассказывать.
puyol_dev2
На фото на вашей DevForum народ спит ) Похоже на обычные никому не нужные совещания
OlesyaBalashova Автор
Во время технических докладов люди обычно не сидят с улыбками на лицах.
Мы сами долго совещались, чем в этот момент занят Юра: просто моргнул или достиг дзена и просветлел.
puyol_dev2
Человек сидит откинув голову назад с закрытыми глазами — он просто моргнул ) И таких «моргнувших» там 2, и ещё несколько сидят с видом «зачем меня сюда притащили»
OlesyaBalashova Автор
Хочу еще раз сделать акцент на том, что DevForum – это не то месту, куда тебя тащат.
Все разработчики заранее видят анонс с темами, которые будут на следующей встрече и дальше каждый для себя решает, пойдет или нет, актуальна ли и интересна эта тема ему сейчас.
Мне жаль, что вы не оценили самоиронию фотографии.
На всякий случай, показываю, что творилось в другой части переговорки.
puyol_dev2
Отношусь ко всему этому скептически, зная какие командно-административные системы существуют в российских компаниях. В частности, до сих пор распространена практика добровольного принуждения (