Когда мы говорим про обмен знаниями, мы подразумеваем два аспекта: документацию (knowledge base) и образование (onboarding, knowledge sharing, тренинги и прочее).

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

Вот, например, самый странный способ, подготовить новичка - вручить ему доступ к кодовой базе и документации, пусть читает.

Такой способ солидно экономит время команды, но подходит он только для опытных спецов - иными словами, такой onboarding подходит для medior/senior/principal уровня, когда человек знает, как и что делать, и ему надо узнать как все сделано в условной конторе/команде.

С junior уровнем, понятно дело, все иначе. И пусть и есть садисты, которые выпускнику дают кодовую базу на изучение, в большинстве (я надеюсь) случаев, к человеку привязывается ментор, который готовит новичка, используя тот же shadowing/reverse shadowing.

Однако рассмотрим ситуацию с другого угла, когда нужен обмен знаниями не внутри команды, а между командами.

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

Классический пример из опыта - разработчики решили использовать DynamoDB для batch обработки событий. Чего разработчики не знали, так это того, что DynamoDB как решение для batch обработки стоит слишком дорого, но всплыло это уже не в качестве вопроса (“Эй, Томас, мы тут думаем использовать динаму, потому что она очень шустрая. Нам нужно обрабатывать 10 000 событий в минуту, как нам лучше сделать? Подойдет ли она?”), а в качестве проблемы (“Эй, Томас, мы тут сделали Динаму, но она почему-то выплевывает нам 400 Throttling, как нам заставить это работать?”).

Не углубляясь в детали - DynamoDB имеет определенные лимиты на API вызовы, и 10 000 операций в минуту (допустим запись), это около 170 вызовов в секунду, что приблизительно 0.765 USD в час или 558.5 USD в месяц.

Чтобы вы понимали - это очень дорого.

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