Что означает передача знаний в программировании

Передача знания и Нейронный машинный перевод на практике

Нейронный машинный перевод (НМП, англ. Neural Machine Translation, NMT) развивается очень быстро. Сегодня, чтобы собрать свой переводчик, не нужно иметь два высших образования. Но чтобы обучить модель, нужен большой параллельный корпус (корпус, в котором предложению на исходном языке сопоставлен его перевод). На практике речь идет хотя бы об одном миллионе пар предложений. Есть даже отдельная большая область НМП, исследующая методы обучения языковых пар с малым количеством данных в электронном виде (англ. Low Resource NMT).

Мы собираем чувашско-русский корпус и параллельно смотрим, что можно сделать с имеющимся объемом данных. В этом примере использовали корпус из 90 000 пар предложений. Самый хороший результат на данный момент дал метод передачи знания (англ. Transfer Learning), о нем и пойдет речь в статье. Цель статьи — дать практический пример реализации, который легко можно было бы воспроизвести.

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

В качестве родительского корпуса пробовали брать 1 миллион пар предложений из англо-русского параллельного корпуса и 1 миллион из казахско-русского корпуса. В казахских данных 5 миллионов предложений. Из них взяли только те, у которых коэффициент соответствия (третья колонка) больше 2. Казахский вариант дал результаты чуть лучше. Интуитивно кажется, что это понятно, поскольку чувашский и казахский языки более похожи друг на дурга. Но на самом деле это не доказано, а также сильно зависит от качества корпуса. Более подробно про подбор родительского корпуса можно прочесть в этой статье. Про дочерний корпус из 90 000 пар предложений узнать и запросить пример данных можно тут.

Теперь к коду. Если нет своей быстрой видеокарты, можно тренировать модель на площадке Colab. Для обучения мы использовали библиотеку Sockeye. Предполагается, что уже установлен Python3.

pip install sockeye

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

pip install mxnet-cu100mkl

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

from nltk.tokenize import WordPunctTokenizer def tokenize(src_filename, new_filename): with open(src_filename, encoding="utf-8") as src_file: with open(new_filename, "w", encoding="utf-8") as new_file: for line in src_file: new_file.write("%s" % ' '.join(WordPunctTokenizer().tokenize(line))) new_file.write("\n")

В результате, подаем на вход пары предложений вида

Нумаях пулмасть вӗсене те укҫа тӳлеме пӑрахнӑ. Республикӑра пурӑнакансем хӑйсен хастарлӑхӗпе, ырӑ кӑмӑлӗпе, чунтан тухакан йӑл куллипе тӗлӗнмелле лару-тӑру йӗркелерӗҫ, ют ҫӗршыври пирӗн ӗҫтешсем палӑртнӑ тӑрӑх, ҫавнашкалли вӗсен патӗнче Раштав уявне паллӑ тунӑ вӑхӑтра кӑна пулать.

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

На выходе получаются такие токенизированные предложения:

Нумаях пулмасть вӗсене те укҫа тӳлеме пӑрахнӑ . Республикӑра пурӑнакансем хӑйсен хастарлӑхӗпе , ырӑ кӑмӑлӗпе , чунтан тухакан йӑл куллипе тӗлӗнмелле лару - тӑру йӗркелерӗҫ , ют ҫӗршыври пирӗн ӗҫтешсем палӑртнӑ тӑрӑх , ҫавнашкалли вӗсен патӗнче Раштав уявне паллӑ тунӑ вӑхӑтра кӑна пулать .

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

В нашем случае понадобятся объединенные словари родительского и дочернего корпусов, поэтому создадим общие файлы:

cp kk.parent.train.tok kkchv.all.train.tok cat chv.child.train.tok >> kk.parent.train.tok cp ru.parent.train.tok ru.all.train.tok cat ru.child.train.tok >> ru.all.train.tok

так как дообучение дочерней модели происходит на том же словаре.

Теперь небольшое, но важное отступление. В МП предложения разбивают на атомы в виде слов и далее оперируют предложениями как последовательностями слов. Но этого как правило недостаточно, потому что образуется огромный хвост из слов, которые встречаются в корпусе по одному разу. Построить для них вероятностную модель сложно. Особенно это актуально для языков с развитой морфологией (падеж, род, число). И русский, и чувашский именно такие языки. Но есть решение. Можно разбить предложение на более низкий уровень, на подслова. Мы использовали Byte pair encoding.

git clone https://github.com/rsennrich/subword-nmt.git

Получим примерно такие последовательности подслов

Ну@@ маях пулмасть вӗсене те укҫа тӳ@@ леме пӑрахнӑ . Республи@@ кӑра пурӑнакансем хӑйсен хастар@@ лӑхӗпе , ырӑ кӑмӑ@@ лӗпе , чунтан тухакан йӑ@@ л кул@@ липе тӗлӗнмелле лару - тӑ@@ ру йӗркеле@@ рӗҫ , ют ҫӗршыв@@ ри пирӗн ӗҫ@@ те@@ шсем палӑртнӑ тӑрӑх , ҫав@@ наш@@ ка@@ лли вӗсен патӗнче Ра@@ шта@@ в уя@@ вне паллӑ тунӑ вӑхӑтра кӑна пулать .

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

Видно, что из слов хорошо вычленяются аффиксы: Не@@ давно и добро@@ той.
Для этого нужно подготовить словари bpe

python subword-nmt/subword_nmt/learn_joint_bpe_and_vocab.py --input kkchv.all.train.tok ru.all.train.tok -s 10000 -o bpe.codes --write-vocabulary bpe.vocab.kkchv bpe.vocab.ru

И применить их к токенам, например:

python subword-nmt/subword_nmt/apply_bpe.py -c bpe.codes --vocabulary bpe.vocab.kkchv --vocabulary-threshold 50 < kkchv.all.train.tok >kkchv.all.train.bpe !python subword-nmt/subword_nmt/apply_bpe.py -c bpe.codes --vocabulary bpe.vocab.ru --vocabulary-threshold 50 < ru.all.train.tok >ru.all.train.bpe

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

Теперь перейдем непосредственно к обучению нейронной модели. Сначала нужно подготовить общие модельные словари:

python -m sockeye.prepare_data -s kk.all.train.bpe -t ru.all.train.bpe -o kkru_all_data

Далее обучим родительскую модель. Более подробно простой пример описан на странице Sockeye. Технически процесс состоит из двух шагов: подготовки данных с использованием созданных ранее модельных словарей

python -m sockeye.prepare_data -s kk.parent.train.bpe -t ru.parent.train.bpe -o kkru_parent_data --source-vocab kkru_all_data/vocab.src.0.json --target-vocab kkru_all_data/vocab.trg.0.json

и самого обучения

python -m sockeye.train -d kkru_parent_data -vs kk.parent.dev.bpe -vt ru.parent.dev.bpe --encoder transformer --decoder transformer --transformer-model-size 512 --transformer-feed-forward-num-hidden 256 --transformer-dropout-prepost 0.1 --num-embed 512 --max-seq-len 100 --decode-and-evaluate 500 -o kkru_parent_model --num-layers 6 --disable-device-locking --batch-size 1024 --optimized-metric bleu --max-num-checkpoint-not-improved 10 

Обучение на мощностях Colab занимает около суток. Когда тренировка модели завершена, переводить с ее помощью можно так

python -m sockeye.translate --input kk.parent.test.bpe -m kkru_parent_model --output ru.parent.test_kkru_parent.bpe

Для обучения дочерней модели выполним

python -m sockeye.prepare_data -s chv.child.train.bpe -t ru.child.train.bpe -o chvru_child_data --source-vocab kkru_all_data/vocab.src.0.json --target-vocab kkru_all_data/vocab.trg.0.json

Код запуска обучения выглядит так

python -m sockeye.train -d chvru_child_data -vs chv.child.dev.bpe -vt ru.child.dev.bpe --encoder transformer --decoder transformer --transformer-model-size 512 --transformer-feed-forward-num-hidden 256 --transformer-dropout-prepost 0.1 --num-embed 512 --max-seq-len 100 --decode-and-evaluate 500 -o ruchv_150K_skv_dev19_model --num-layers 6 --disable-device-locking --batch-size 1024 --optimized-metric bleu --max-num-checkpoint-not-improved 10 --config kkru_parent_model/args.yaml --params kkru_parent_model/params.best

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

Подводя итоги, сравним результаты. Обычная модель машинного перевода дала качество 24,96 BLEU, тогда как модель с передачей знания 32,38 BLEU. Разница видна и визуально на примерах переводов. Поэтому, пока продолжаем собирать корпус, будем пользоваться этой моделью.

• нейронный перевод
• нейронные сети
• transfer learning
• чувашский язык
• sockeye
• colab

• Алгоритмы
• Big Data
• Машинное обучение

Передача знаний для вузов

Открытия находят свое применение во всем мире путем передачи знаний. Существуют различные способы обеспечить, чтобы передача знаний являлась не просто побочным продуктом деятельности вузов и НИИ.

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

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

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

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

Что означает передача знаний в программировании

«Как пасти котов» – это книга о лидерстве и руководстве, о том, как первое совмещать со вторым. Это, если хотите, словарь трудных случаев управления IT-проектами. Программист подобен кошке, которая гуляет сама по себе. Так уж исторически сложилось. Именно поэтому так непросто быть руководителем команды разработчиков. Даже если вы еще месяц назад были блестящим и дисциплинированным программистом и вдруг оказались в роли менеджера, вряд ли вы знаете, с чего надо начать, какой выбрать стиль руководства, как нанимать и увольнять сотрудников, проводить совещания, добиваться своевременного выполнения задач. В таком случае без этой книги вам не обойтись. А может быть, вы – опытный менеджер, желающий пересмотреть свои принципы лидерства? Тогда, опять же, эта книга для вас. Вне зависимости от возраста, пола и социального статуса, она поможет вам укрепить свои позиции в роли лидера программистов. Материал изложен довольно компактно и легко укладывается в голове. Стоя в книжном магазине и раздумывая, что же купить, задайте себе один простой вопрос: «Нужно ли мне совершенствовать свои лидерские навыки?» Полагаю, вы ответите: «Да», – а значит, моя книга окажется для вас небесполезной.

Книги автора: Как пасти котов. Наставление для программистов, руководящих другими программистами
Книги автора: Как пасти котов. Наставление для программистов, руководящих другими программистами

Книга: Как пасти котов. Наставление для программистов, руководящих другими программистами

Передача знаний

Скрыть рекламу в статье

Слово «благовещение» я первый раз услышал в церкви еще ребенком. В религиозном контексте оно употребляется в совершенно четком смысле и обозначает распространение хорошей новости. Много позже я услышал этот термин в светской интерпретации от Microsoft – словосочетание «благовестник продукта»[81] показалось мне чрезвычайно точной характеристикой для восторженного молоденького преподавателя, к которому я ходил на курсы программирования. Способность передавать знания есть второй необходимый признак лидера. Иногда говорят: «тот, кто умеет, делает; тот, кто не умеет, преподает». Это изречение я считаю неверным и предлагаю встречную мысль: у того, кто не может адекватно изложить свои мысли, их слишком мало. Полагаю, что именно эта проблема обусловливает плохую передачу информации в бизнесе: недостаточное понимание проблемы порождает комплекс, в результате чего субъект, который, по смыслу, должен эту проблему доходчиво изложить, начинает надеяться на то, что окружающие смогут интуитивно разобраться в ней и уяснить свои задачи. Наитие выходит на первый план, если документацию с бизнес-требованиями по ночам не читать, а использовать по естественному назначению – в качестве подушки; впрочем, и наитие никогда не сможет заменить четкое изложение мысли.

Цель передачи знаний – обеспечить понимание персоналом предъявленных к продукту требований на том же уровне, на котором их понимает лидер. Итак, каким образом вам самому удалось понять проблему в комплексе? Восстановите последовательность действий, направленных на изучение требований, и перенесите ее на процесс обучения сотрудников. Тот, кто способен четко доносить свои знания до окружающих, сможет преуспеть в педагогике. Да, действительно, даже самый лучший учитель не может обойтись без заинтересованных учеников, но как лидер программистов вы располагаете в этом отношении существенным преимуществом – ваши «студенты» работают под вашим же началом, и никуда им от вас не деться. Может быть, они не всегда вас слушают, но ведь вы – шеф и поэтому располагаете методами принуждения к обучению. Поощрение, несомненно, выигрывает в сравнении с принуждением, но бывают ситуации, когда выбирать не приходится. Вернемся к основной мысли: если передача знаний равнозначна педагогической деятельности, то как лучше составить «план урока»? Элементы, приведенные в табл. 8.1, являются минимально необходимыми для адекватной передачи знаний.

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

Как устроен обмен знаниями в инженерных командах Facebook. Большой гайд по шерингу экспертизы в компании

Обмен знаниями внутри инженерной команды — очень важный процесс для бизнеса. От методов, на основе которых он встроен, зависит успешность адаптации новых программистов при работе над сложным проектом, скорость обучения джунов и внедрения новых технологий. Бывший Engineering Manager из Facebook рассказывает, какие практики приняты в компании.

Это адаптированный перевод интервью с Балажем Балажем , бывшим Engineering Manager в Facebook, которое он дал подкасту Level Up Engineering. Повествование ведется от лица автора оригинала.

Как выбрать практики обмена знаниями для команд разработки

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

Есть два основных принципа, которыми я руководствуюсь при выборе подхода:

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

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

С чего начать

Создание культуры

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

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

Ведение документации

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

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

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

(Мои) правила ведения документации

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

• Над какой системой вы работаете?
• Кто ваши клиенты?
• Сколько людей будут работать с вашим кодом?
• Что именно должно быть задокументировано?

В документировании нуждается каждый проект. Вот что важно описать вне зависимости от контекста:

1. Принципы архитектуры
2. Все исследования, связанные с проектом
3. Решения, которые вы принимаете
4. Логику, лежащую в основе ваших решений

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

Документация по API нужна почти в 100% случаев. Но создавать руководства, учебные пособия, примеры и вики-страницы о своем коде для внутреннего пользования необязательно.

Как устроено документирование в Facebook

Когда документация не нужна

В Facebook я сначала попал в команду, которая 3,5 года занималась разработкой внутренней системы с очень ограниченным числом пользователей. Я был первым новичком за долгое время и краткость документации сильно затрудняла процесс адаптации.

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

Когда документация нужна

Для команды, которая разрабатывает внутренние библиотеки, ситуация обратная. У ее системы тысячи пользователей внутри компании — мы тратили 50-60% времени на поддержку системы, ответы на вопросы и попытки решить проблемы пользователей. Очень подробная документация существенно облегчила работу.

Как выстроить систему обмена знаниями для развития джунов

Реальные проекты

В Facebook младшие инженеры очень амбициозны: последнее, что им нужно — это чей-то совет. Они предпочитают сами учиться на своих ошибках. Лучшее, что вы можете сделать — дать им возможность писать код.

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

Ревью кода

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

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

Design Review

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

Парное программирование

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

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

Наставничество

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

Как адаптировать новичков в команде

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

Разработка документации

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

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

Ревью архитектуры

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

Кейс Facebook

Стандартная практика в Facebook — дать понять новому инженеру, что он может подвергать сомнению все решения. Идея в том, что свежий взгляд на проект помогает сделать его лучше.

Читайте также: Чек-лист хороших инженерных практик в компаниях

Как найти время на обмена знаниями?

Сделайте его частью рутины

Мой опыт показывает, что попытки выделить отдельное время для обмена знаниями ни к чему не приводят. Когда приближается дедлайн, и команде нужно выбирать, заняться документацией или завершить задачу, в 100% случаев приоритет отдается задаче.

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

Шеринг-сессии

В Facebook регулярно проводятся шеринг-сессии: раз в неделю все члены команды делились тем, какие задачи решали на прошлой неделе, как им удалось справиться с проблемами и какие обновления появились в проекте.

Документация

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

Инструменты для обмена знаниями

Корпоративные чаты

Внутренний чат (например, в Slack) — базовый инструмент для обмена знаниями. Это площадка для дискуссий между членами команды и средство поддержания командного духа.

Вики-страницы

Внутренние вики-страницы помогут новичкам понять, по какому принципу устроена официальная документация и где нужно искать нужную информацию.

Социальные инструменты

В Facebook мы пользовались платформой Workspace — это, по сути, тот же Facebook, но для внутреннего использования. В нем есть лента с новостями компании, отделов и сотрудников, сообщества и другие функции социальной сети.

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

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

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

Как мотивировать инженеров, которые не хотят участвовать в обмене знаниями?

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

Вознаграждение

Очевидный способ поощрить обмен знаниями — вознаградить разработчиков. Деньги — не единственная мотивация: в Workspace каждая публикация получает лайки других разработчиков. Это способ публично поощрить инженера, который прилагает много усилий для обмена знаниями.

Фан

Передачу знаний можно сделать увлекательным процессом. Подготовка длинного официального документа — это рутинная задача, но презентацию делать куда интереснее. Кто сказал, что документацию нельзя оформлять в виде презентации?

Кейс Facebook

У Facebook есть офисы по всему миру и сотрудники компании могут бесплатно совершать деловые поездки между офисами. Это один из инструментов поощрения.

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

Я почти уверен, что тому инженеру нравилась идея бесплатно съездить в Нью-Йорк. Это сделало бы работу над проектом увлекательнее. В результате эта «неделя данных» стала самой продуктивной за долгое время.

Сделайте обмен знаниями привлекательным

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

Положительный опыт

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

В чем залог успеха кейса Facebook?

Успех в организации обмена знаниями сильно зависит от уровня инженерной культуры в компании.

Прозрачность процессов

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

Фокус на взаимодействие

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

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