Зачем «шарить» знания?

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

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

Текстовые способы

Создание wiki страничек

Можно создать базу знаний в корпоративной Wiki/Confluence. Недостаток этого способа связан с поддержкой актуальности информации. Как правило, наиболее полезная информация о проекте — это UML-схемы и самые базовые понятия.

Эффективность: 5/10.
Сложность внедрения: 3/10.

Список ресурсов, подборки

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

Эффективность: 6/10.
Сложность внедрения: 4/10.

Чаты по узкой тематике

Базой знаний по какому-либо процессу или проекту также может быть чат. Информация в нём хуже структурирована, но, как правило, всегда можно посмотреть список уже отправленных фотографий, ссылок и файлов, и отталкиваясь от них глубже разобраться в теме либо найти эксперта. Главное, не допускать разговоров вне тематики чата. Чтобы важная информация не терялась, рекомендую использовать закреплённые сообщения.

Эффективность: 3/10.
Сложность внедрения: 2/10.

Написание статей

Как правило, поиск материала и исследование при написании статьи дают сильный толчок к развитию кругозора автора, а полученный опыт может быть полезен и релевантен для коллег. Например, темой для статьи может стать какая-то «боль» в проекте или описание полученного опыта. Чтобы процесс написания не затягивался на бесконечный срок, лучше придумать какие-то дедлайны либо создать их искусственно. Если статьи публикуются на внешних площадках и укрепляют HR-бренд компании, то стоит рассмотреть варианты поощрения авторов для поддержания мотивации.

Эффективность: 6/10.
Сложность внедрения: 7/10.

Базы данных по инцидентам

Результаты разбора инцидентов можно систематизировать на Wiki и использовать для обучения новичков на уже полученном опыте, а для senior-сотрудников будет полезным проводить ревизию этих знаний для выявления основной информации и принятия системных мер

Эффективность: 7/10.
Сложность внедрения: 7/10.

Способы, основанные на живом общении

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

Площадки для прогона докладов

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

Эффективность: 3/10.
Сложность внедрения: 7/10. 

Создание сообществ и гильдий по разным технологиям

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

Эффективность: 7/10.
Сложность внедрения: 10/10.

Архитектурные комитеты

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

Эффективность: 9/10.
Сложность внедрения: 6/10.

Совместное исследование

Если какая-то проблема не решается одним человеком, то может помочь совместное исследование. Помимо объединения знаний и повышения шанса найти наилучшее решение этот процесс ценен интенсивным обменом опытом.

Эффективность: 8/10.
Сложность внедрения: 6/10.

Площадки для обсуждения прочитанных книг

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

Эффективность: 5/10.
Сложность внедрения: 6/10.

Написание статей в соавторстве с другим сотрудником

Найти соавтора может быть непросто, но результат от командной работы может превзойти ожидания. Стимулом для написания статьи может быть всё то же желание разобраться в какой-нибудь сложной теме.

Эффективность: 8/10.
Сложность внедрения: 8/10.

Написание прототипов, MVP, участие в feature team

Одним из способов быстро создать прототип нового процесса в крупных компаниях является объединение свободных разработчиков из нескольких команд в так называемую “feature team”. Как правило, MVP продукта создаётся в короткие сроки «в режиме стартапа», и это хорошая проверка на прочность ранее полученных разработчиком навыков. Обмен знаниями и опытом идёт в максимально интенсивном режиме, и навыки оперативно превращаются в рабочий код. По достижению результата feature-команду расформировывают (проект отдаётся на поддержку и развитие одной из существующих команд), но бонусом остаются приятные воспоминания и налаженные связи. Часто применять такой способ написания новых сервисов нельзя, потому что повышенная нагрузка ведёт к выгоранию сотрудников.

Эффективность: 10/10.
Сложность внедрения: 8/10.

Дежурства по сервису, релизы, разбор багов

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

Эффективность: 8/10.
Сложность внедрения: 7/10. 

Участие в разборе инцидентов

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

Эффективность: 7/10.
Сложность внедрения: 7/10.

Обучение внутри компании (внутренние курсы)

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

Эффективность: 8/10.
Сложность внедрения: 9/10.

Голосование по интересующим темам

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

Эффективность: 5/10.
Сложность внедрения: 3/10. 

Способы получения знаний вне компаний

Хакатоны

Способ чем-то похож на участие в “feature team”. Плюсом хакатона является его ограниченность во времени и сфокусированность на конкретной проблеме. Хакатоны могут быть хорошей встряской для заскучавших программистов, помогающей не выгореть в нашей нелёгкой профессии.

Эффективность: 9/10.
Сложность внедрения: 8/10.

Работа над open source

При работе над Open Source программист совершенствует свои навыки, создавая новое либо улучшая существующее ПО. Полученная на pull request'ах обратная связь от опытных программистов может дать стимул для получения новых знаний и чтения профессиональной литературы. Для разработки предпочтительно выбирать те проекты, которыми сам регулярно пользуешься, либо которые востребованы работодателем.

Эффективность: 10/10.
Сложность внедрения: 8/10.

Хождение по собеседованиям

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

Эффективность: 9/10.
Сложность внедрения: 8/10.
Опасность: 10/10.

Итоговая таблица

А как обмениваетесь знаниями вы?

Способов поделиться знаниями существует великое множество, но бывает сложно выбрать какие-то конкретные и системно внедрить в культуру компании. Буду рад, если вы поделитесь более простыми и эффективными методами в комментариях.