Конференция завершена. Ждем вас на KnowledgeConf в следующий раз!

Доклады

KnowledgeConf: Джуны и онбординг (6)

Создаем культуру доверия для обмена знаниями и ошибками

Ольга Елисеева

Инфосистемы Джет

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

В докладе поговорим о том, как создать культуру обмена знаниями и опытом:
1. Проектный опыт, внутреннее обучение как форматы обмена знаниями для создания поддерживающей среды.
2. Как мы запустили мероприятие Fails Nights, где любой сотрудник может рассказывать о своих ошибках, чтобы другие не повторяли их в будущем. Ведь успех команды и компании невозможен без ошибок, и правильное отношение к ошибкам — это двигатель прогресса.
3. Как мы поддерживаем культуру обмена знаниями и вовлекаем все больше людей.
4. Что это дает сотрудникам, и что получает сама компания.

Доклад принят в программу конференции

Онбординг для социофобушков

Времена изменились. Если раньше компании могли позволить себе годами "искать лучших", то сейчас за разработчиков идут нешуточные бои. И преимущество получают те компании, в которых комфортно работать не только "коммуникабельным и быстро обучающимся" экстравертам, но и классическим воробушкам-социофобушкам, которых у нас в IT более чем. Собственно, я сама такая и побывала по обе стороны баррикад.

В докладе расскажу про все те подходы и приемы, которые делают процесс вливания в работу новых сотрудников комфортным и для них, и для компании. Мы пройдемся по "трем китам" онбординга, я расскажу, зачем и как делать коммуникации "прозрачными" и сведу это все к главному: великой и ужасной Базе Знаний. У нас же Knowledge Conf.

Доклад принят в программу конференции

Быстрый старт разработчиков в Яндекс.Еде

Илья Шишков

Яндекс.Еда

Всем знакомо состояние, в котором вы выходите на работу на новом месте. На собеседовании вам рассказывали, как вы вместе будете строить космические корабли и бороздить на них просторы Вселенной. Но вот первый день, и вы не понимаете, как вам сделать простейшие вещи. А ещё вы не знаете, на что способны все эти люди, которые сидят вокруг вас. Они говорят непонятные слова, и вам неясно, к кому за чем обращаться.

В Яндекс.Еде мы избавили от этих страданий новых разработчиков, которые приходят к нам. У нас есть две стадии онбординга новых разработчиков: предбуткемп и следующий за ним буткемп. На первом этапе новый сотрудник знакомится со всеми инструментами и процессами разработки. А во втором пробует по две недели поработать в каждой из команд Еды, чтобы понять, какие задачи и команда ему больше всего подходят.

В своём докладе я поделюсь, как эти две системы устроены у нас и каких результатов мы достигли благодаря им.

Доклад принят в программу конференции

Онбординг новичков: как компании влюбить в себя сотрудника

- «Добро пожаловать в команду!» — кому и зачем нужен онбординг.
- Немного про Пребординг, зачем он нужен и чем отличается от Онбординга.
- Онбординг сотрудников в IT-компании и не только: онбординг как бизнес-процесс, роли и артефакты.

Доклад принят в программу конференции

Как быстро масштабировать команду и не умереть

На рынке не так много QA-специалистов, да и вообще айтишников, поэтому, когда мы столкнулись с нехваткой коллег, — решились на эксперимент, где взяли в команду 28 junior-спецов и вырастили 22 из них до middle за полгода.

В своем выступлении я поделюсь нашими практиками по развитию и вовлечению. Чтобы те, кто уже работает с вами или только присоединился, никогда не “оставались за бортом” и росли.

В своем выступлении поделюсь:
* вызовами, с которыми столкнулась команда;
* практиками, которыми мы пользовались для решения этих проблем;
* результатами и планами на будущее.

Доклад принят в программу конференции

Квест на входе: как новички в HFLabs онбордят сами себя

Когда появляется новый человек в команде, то:
* команде хочется, чтобы новичок как можно скорее узнал все, что нужно для работы, и начал приносить пользу;
* новичку хочется быстрее познакомиться с людьми, вникнуть во все тонкости рабочего процесса, чтобы сократить период адаптации.

Пока не нашли способа прямой загрузки в мозг всех необходимых знаний в первый рабочий день.

Группы вопросов, с которыми сталкивается каждый новичок:
1. Организационные. Где взять блокнот, ручку, кто мне выдаст компьютер?
2. Человеческие. Кто есть кто в команде, у кого что можно спрашивать?
3. Погружение в проект/продукт. Какими задачами я буду заниматься в ближайшее время? А какие процессы взаимодействия есть?
4. Развитие. Куда развиваться дальше? Кто со мной обсудит вопросы развития?

Мы в HFLabs укомплектовали ответы на эти вопросы в игровой квест. В первые пару недель новичок проходит квест, изучает теорию, выполняет практические задания и знакомится с командой.

У квеста версия уже 2.0, первая версия пожила пару лет, мы собрали метрики и обратную связь, нашли точки отказа. Улучшили квест. Получили версию 2.0, которая используется 1,5 года. Но мы идем и к ее улучшению.

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

Доклад принят в программу конференции

KnowledgeConf: Эксперты, bus factor (9)

Создание Body of Knowledge как процесс: от анализа потерь до укрощения экспертов

В выступлении подводится итог 2х-летней работы нашей команды по публикации серии Навигаторов (Body of Knowledge) для госслужащих — с описанием набитых шишек и наших находок. Задача каждого навигатора — ввести сотрудника госорганизации в ту или иную конкретную тему, дать ему как минимальную теорию, так и практические шаги, лайфхаки и рекомендации от лучших экспертов в заданной теме.

Как понять, что нам нужен именно этот эксперт? Как уговорить его на интервью? Что делать, если интервью недостаточно? А если эксперт с умным видом рассказывает какую-то фигню? Как не утонуть в море разных материалов и отобрать самое главное? Как организовать непрерывный процесс сбора знаний и выпуска навигаторов? Какие шаги процесса лишние и почему мы готовим каждый BOK так долго?

Нам приходилось отвечать на эти и множество других вопросов. За это время мы прошли путь от хаотичного сбора сведений с SME до выстроенного процесса отбора и подготовки экспертов, сбора информации, ее упаковки и публикации. Не только расскажем лайфхаки коммуникации с экспертами, но и покажем наши инструменты работы: гайды для экспертов и тех, кто с ними работает, чек-листы и т.д., опишем метрики успеха.

В докладе предполагается сделать акцент на двух основных моментах — оптимизации процесса сбора и публикации информации (как научиться это делать с минимумом потерь, ресурсов, максимально быстро и эффективно) и на различных работающих подходах по работе с экспертами.

Доклад принят в программу конференции

15 приемов, чтобы задать вопрос профессионалу

#Деловая встреча
#Коммуникация
#Soft Skills

Самые новые знания содержатся не в книгах, а в головах у профессионалов. Умение задавать качественные вопросы и извлекать знания из экспертов — навык, которым обладают единицы. После доклада вы узнаете, как формулировать вопросы так, чтобы:
1) извлекать редкую информацию из эксперта;
2) развить тему, если дан поверхностный ответ;
3) вернуть эксперта к обсуждаемой проблеме, если он уходит в сторону от темы.

В XXI веке умение задавать качественные вопросы конвертируется в успехи в бизнесе, в науке и во многих других сферах.

Доклад принят в программу конференции

Dendron: Zettelkasten на стероидах

В докладе я расскажу про Dendron — это подход и инструмент для ведения базы знаний: https://www.dendron.so. Я сам до этого пользовался Foam и сменил его на Dendron, в докладе расскажу почему.

Расскажу, в чем его особенности и отличия от похожих инструментов: Roam, Obsidian, Foam и прочих.

Расскажу про сам подход — он очень схож с Zettlekasten, но расширяет его еще и иерархией заметок (что на самом деле изначально было заложено в Zettlekasten и самим Луманом в виде системы нумерации заметок) и схемой этой иерархии. Поэтому я кратко расскажу и про сам Zettlekasten для тех, кто про него не слышал.

Расскажу про инструмент и покажу его в действии — это надстройка над VS Code, плагин, такой же как и Foam, со всеми его преимуществами, плюс предлагающая удобный способ ведения и изменения иерархии заметок, переиспользования текста заметок в других заметках и еще несколько удобных мелочей.

Доклад принят в программу конференции

Извлечение ошибок профессиональной деятельности на интервью с экспертом

Николай Сенин

Независимый исследователь

Для того чтобы структурировать полезные знания в некоторой предметной области, имеет смысл использовать форму чек-листов, или списков контрольных вопросов/типовых ошибок. Часто у специалистов по работе со знаниями есть доступ к экспертам, которые эти типовые ошибки не совершают. Однако при прямых вопросах этим экспертам вроде "А какие ошибки важно не допускать?" зачастую получается вытянуть лишь 2-5 единиц знания. В то время как обычно таких ошибок существует несколько десятков. Это происходит в силу семи основных ограничений, которые будут упомянуты на докладе.

Для повышения КПД интервью и преодоления выше указанных ограничений в докладе предлагается использовать подход, в котором знания извлекаются с использованием специальных выделенных классов. Количество извлеченных типовых ошибок в таком случае возрастает в 3-15 раз.

Также в докладе будет дан ряд общих рекомендаций для увеличения эффективности экспертного интервью.

Доклад принят в программу конференции

“Твоя моя не понимай”: когнитивные аспекты обмена знаниями в мире онлайн

Информационные перегрузки и онлайн-формат снижают эффективность традиционных форм деловых коммуникаций (брифов, презентаций, брейнсторминга), а также деловой переписки.

Частично это можно компенсировать использованием методов компрессии (сжатия) информации, например, через использование "правильных диаграмм". При этом ведущую роль играют особенности когнитивного стиля, часть из которых можно тренировать:
а) поленезависимость (способность выделять главное),
б) способность к обобщению (генерализации),
в) диапазон когнитивной эквивалентности (формирование классов и категорий).

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

Доклад принят в программу конференции

Учимся задавать вопросы осмысленно

#Коммуникация
#Soft Skills
#Управление проектами

Задумывались ли вы о том, что у некоторых лучше получается задавать вопросы? А что эту способность можно целенаправленно развивать в себе и, возможно, в окружающих? Представляете ли вы, как это сделать? Какую пользу может принести?

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

Признаюсь, что вы не найдете универсального инструмента или шаблона со списком вопросов “на все случаи жизни”. Но я собрала для вас набор методов, которые помогут тренировать навык "задавать вопросы".
"Чем лучше вопросы, тем выше шансы получить хорошие ответы" (Хэл Грегерсен).

Доклад принят в программу конференции

Заходят тимлид, менеджер и инженер в бар, а там матрица компетенций

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

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

Доклад принят в программу конференции

Зачем я разбирала архив блокнотов за 10 лет: экзистенциальная сторона менеджмента знаний

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

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

Доклад принят в программу конференции

Как сделать, чтобы базой знаний начали пользоваться, пожалуйста

Доклад будет полезен тем, кто только начинает работать над внутренней корпоративной базой знаний и еще не очень представляет, за что им браться и как подходить к ее продвижению.

В этом докладе я расскажу, как я продвигал свою базу знаний, будучи junior QA-инженером, не имея особого опыта, влияния и административного ресурса. Расскажу о том, как удалось преодолеть раздражение в адрес коллег ("ведь я такой молодец и принес вам свет базы знаний, а вы ею не пользуетесь") и провести свою вики от 3 статей до 13 000, не растеряв при этом взаимоуважения.

Доклад принят в программу конференции

KnowledgeConf: Гильдии и масштабирование знаний (11)

Рабочий процесс как процесс накопления знаний

Зачастую мы рассматриваем рабочий процесс как процесс передачи работы между специалистами разной функциональной направленности, и это вызывает определенные сложности. Эти сложности зачастую не видны, и их причина не очевидна. Но я вам их покажу и объясню, как так происходит, а также покажу, что в мире интеллектуального труда, труда, связанного с разработкой нематериальных продуктов, достаточно опрометчиво рассматривать рабочие процессы как передачу работы от специалиста к специалисту, а стоит рассматривать как процесс накопления знаний.

В докладе вас ждет объяснение:
* как смотреть на рабочий процесс как на процесс накопления знаний;
* как визуализировать такой рабочий процесс;
* хорошие и плохие практики, а также лайфхаки.

Доклад принят в программу конференции

Process Decision Record — простой инструмент постепенной рационализации процессов

#Методологии и процессы разработки ПО; Сроки и приоритеты
#Управление / другое
Виталий Шароватов

Независимый эксперт

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

* Можете ли вы ответить, насколько эффективны ваши процессы?
* Можете ли ответить, эффективны ли они вообще?
* А что вы подразумеваете под эффективностью?
* Решает ли каждая процессная активность какую-то проблему?
* Актуально ли ещё это решение?
* Можете ли хотя бы ответить, для чего какая активность была внедрена?
* А понимают ли ценность каждой активности ваши коллеги или члены команды?
* Знакомо ли вам, когда спрашиваете СТО "а почему у нас тестирование так работает?", а вам отвечают "так сложилось"?
* Бывает ли, что кажется, что какая-то процессная активность появилась просто потому, что "консультант так сказал", а сути не понимает никто?
* А что, если какие-то процессные активности были добавлены, когда команда состояла из 4 сеньоров-фулстеков, а сейчас в ней уже 12 специалистов разного уровня и разных специальностей?

Кажется, что каждая процессная активность должна быть рационально обоснована в текущем контексте, и сотрудники должны понимать, для чего что происходит.

Можно выпасть из процесса производства ПО на месяцы, описать все процессы, а потом запустить тренинг для всех сотрудников. Но рационально ли это? Наверное, нет.

Но можно же есть слона по частям 🙂

PDR — Process decision record — подход, дающий возможность любой команде комфортно съесть слона, — "рационализация процессов" по частям.

Доклад принят в программу конференции

Документация — это про деньги

Семён Факторович

DocFactor (documentat.io)

Все мы живем в парадигме того, что управление знаниями — это инструмент управления рисками и, как следствие, экономии денег.

Если сузить этот тезис до документации к софту, то получится интересный вывод: документацию стоит рассматривать исключительно как способ экономии денег.

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

Мы проанализировали истории всех этих компаний и хотим поговорить вот о чем:
- Когда документация экономит деньги, а когда зарабатывает?
- Документация — хорошая инвестиция? Каков ее ROI? А скорость возврата?
- Когда документацию дешевле не писать?
- Кто основной выгодоприобретатель документации?

Доклад принят в программу конференции

"Клуб Франклина" — внутренний клуб компетенций

Иван Преснов

Купибилет.ру

Вы услышите историю проекта по шарингу знаний "Клуб Франклина", который мы запустили в 2019 году и уже через год он вырос с одной команды до половины офиса.

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

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

Доклад принят в программу конференции

Гильдии как способ взаимодействия в большой и растущей команде

Иван Миронов

Перекресток Vprok.ru

В один миг мы оказались в пучине роста и изменений. Команда выросла, нас стало больше.
Мы делали одно общее дело, но каждый по своему.
Появлялось больше мнений на тему того, как делать правильно.
Мы предвкушали, что у нас будет десять способов решать одно и то же.
Каждый будет создавать свои велосипеды, яро отстаивая их право на жизнь.
Будем подолгу спорить, как решать сложные и не очень сложные задачи. Утонем в водовороте споров и разных мнений.

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

Что мы нашли на этом пути?
* Договорились о новом стеке для нашего фронта и бэкенда и внедрили его.
* Привели в порядок техническую документацию.
* Даже автоматизировали работу по просмотру и оценке "мемасиков", чтобы жилось веселее.

Казалось, это курица, несущая золотые яйца, философский камень, превращающий все в золото, но были у него и недостатки.
О том, через что нам пришлось пройти и куда мы пришли, мой доклад.

Доклад принят в программу конференции

Позитивное управление контентом: как выстроить партнерские отношения с коллегами

#Коммуникация
#Бизнес-процессы
Алиса Комиссарова

Positive Technologies

Ирина Рыбникова

Positive Technologies

Работа с контентом наиболее эффективна, когда она выстроена централизованно.

На презентации вы узнаете о том, как в Positive Technologies организованы коммуникации и единый воркфлоу работы с документами. Мы расскажем как про техническую сторону (внедрение системы управления контентом, ее настройку, поддержку и автоматизацию), так и про бизнес-ценность этого подхода для развития организации. Вы узнаете, как специалисты подразделения технических писателей — архитекторы контента — налаживают взаимодействие между проектными командами, обеспечивая переиспользование контента в документах разного типа. Мы покажем, как строить партнерские отношения с маркетологами, юристами, специалистами по сертификации и обучению, как создавать корпоративное информационное пространство и находить новые решения для оптимизации работы.

Доклад принят в программу конференции

С высоты птичьего полёта: что остаётся важным при управлении знаниями на масштабе нескольких компаний

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

* Личкам — бой!
Почему это особенно больно и как выйти на общие каналы связи без кнута и палки?
* Инструменты должны служить, а не руководить.
Как не быть узником удобной инфраструктуры, а решать практическую задачу по синхронизации всех со всеми?
* У нас тут своя атмосфера.
Почему суперважным на масштабе становится настрой и подход к общему делу?
* Дейли и ретро как инструменты управления знаниями.
Почему информация должна быть перед глазами и как совместно ею управлять?
* Как координатору не сойти с ума :)
... и другое.

Доклад принят в программу конференции

Как я принес воркшопы в команду Tarantool

Tarantool — не только база данных. Это полезная штука, но ее трудно объяснить в двух словах. И не только нашим клиентам, но даже собственным стажерам. Мы в VK помогаем строить решения на базе Tarantool, так что объяснять надо много и часто.

Два года назад я понял, что нам нужны воркшопы! Но как сделать воркшопы внутри большой компании, если ты не ее директор? В докладе я расскажу про путь от идеи до четырех одновременных потоков платных воркшопов.

Сейчас наши воркшопы помогают нам управлять знаниями о Tarantool, обучать стажеров, помогать нашим клиентам. Но чтобы к этому прийти, нам пришлось знатно помучиться, и мой доклад — история этого пути. Как собирал единомышленников, искал внутренних спонсоров, вытаскивал из разработчиков знания, набивал первые шишки и "продавал" решение бизнесу.

Доклад принят в программу конференции

Как создать систему управления знаниями на 1к человек: от продуктовых команд к кастомер-фейсинг и обратно

Чтобы управление знаниями перманентно приносило пользу, не вызывало боли у тех, кто им занимается, и негатива у тех, кто не понимает, зачем это все, нужно: а) вывести этот процесс из подполья и б) добавить активности по фиксации и переиспользованию знаний во все бизнес-процессы. Это звучит сложно и нереализуемо. Но на самом деле достаточно просто понять, что продукт мало просто создать — сам себя он не продаст и не поддержит. Это понимание должно возникнуть у менеджмента и дальше спуститься во все подразделения компании в виде конкретных action points с контролем их выполнения.

В своем докладе буду рассказывать, как эта интеграция управления знаниями в бизнес-процессы работает у нас в Exness. В компании в настоящий момент больше 1000 человек, из которых более 200 — штаб разработки. Компания распределена географически и мультинациональна. Для организации процесса передачи знаний в компании существует специальное подразделение (я в нем работаю), которое взаимодействует со всеми другими департаментами, отделами и штабами.

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

Как это реализовано, каких усилий и ресурсов это стоит, а главное, что это дает бизнесу, об этом я расскажу в своем докладе.

Почитать немного о том, чем команда Knowledge Management занимается в Exness, можно в моих статьях на Хабре:
https://habr.com/ru/company/exness/blog/505470/
https://habr.com/ru/company/exness/blog/515056/
https://habr.com/ru/company/exness/blog/574848/

Доклад принят в программу конференции

Ландшафт коммуникаций

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

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

Доклад принят в программу конференции

Строим внутренние и внешние сообщества

Алексей Долгушев

Деврел-бюро

Гильдии, трайбы, community of practices — названия разные, а суть похожая. Ребята внутри компании собираются в группы по интересам, устраивают встречи, генерят артефакты, делятся знаниями.

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

Статьи для базы знаний — отдельная боль. Пишут единицы, да и то нерегулярно.

То немногое, что получается завести, едет на ручной тяге. Стоит только главному идеологу отвлечься на другие дела, как активность сразу начинает буксовать.

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

Хорошие новости — все компании разные, но проблемы с созданием сообществ похожи и, самое главное, лучшие практики работают не только в формате "ошибка выжившего"; многие приёмы удаётся подсмотреть в другом месте, а воспроизвести у себя.

В докладе поделюсь наблюдениями за сообществами по мотивам 30+ кейсов: где какие практики срабатывали в тех компаниях, с которыми я имел возможность работать и кого наблюдал.

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

Спойлер: будем вдоль и поперёк эксплуатировать деврел-инструментарий.

Доклад принят в программу конференции