0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p><strong>Обмен знаниями внутри инженерной команды - очень важный процесс для бизнеса. От методов, на основе которых он встроен, зависит успешность адаптации новых программистов при работе над сложным проектом, скорость обучения джунов и внедрения новых технологий. Бывший Engineering Manager из Facebook рассказывает, какие практики приняты в компании.</strong></p>
1
<p><strong>Обмен знаниями внутри инженерной команды - очень важный процесс для бизнеса. От методов, на основе которых он встроен, зависит успешность адаптации новых программистов при работе над сложным проектом, скорость обучения джунов и внедрения новых технологий. Бывший Engineering Manager из Facebook рассказывает, какие практики приняты в компании.</strong></p>
2
<p><em>Это адаптированный перевод<a>интервью с Балажем Балажем</a>, бывшим Engineering Manager в Facebook, которое он дал подкасту Level Up Engineering. Повествование ведется от лица автора оригинала.</em></p>
2
<p><em>Это адаптированный перевод<a>интервью с Балажем Балажем</a>, бывшим Engineering Manager в Facebook, которое он дал подкасту Level Up Engineering. Повествование ведется от лица автора оригинала.</em></p>
3
<h2>Содержание</h2>
3
<h2>Содержание</h2>
4
<ul><li><a>Как выбрать практики обмена знаниями для команд разработки</a></li>
4
<ul><li><a>Как выбрать практики обмена знаниями для команд разработки</a></li>
5
<li><a>С чего начать</a></li>
5
<li><a>С чего начать</a></li>
6
<li><a>(Мои) правила ведения документации</a></li>
6
<li><a>(Мои) правила ведения документации</a></li>
7
<li><a>Как устроено документирование в Facebook</a></li>
7
<li><a>Как устроено документирование в Facebook</a></li>
8
<li><a>Как выстроить систему обмена знаниями для развития джунов</a></li>
8
<li><a>Как выстроить систему обмена знаниями для развития джунов</a></li>
9
<li><a>Как адаптировать новичков в команде</a></li>
9
<li><a>Как адаптировать новичков в команде</a></li>
10
<li><a>Как найти время на обмена знаниями?</a></li>
10
<li><a>Как найти время на обмена знаниями?</a></li>
11
<li><a>Инструменты для обмена знаниями</a></li>
11
<li><a>Инструменты для обмена знаниями</a></li>
12
<li><a>Как мотивировать инженеров, которые не хотят участвовать в обмене знаниями?</a></li>
12
<li><a>Как мотивировать инженеров, которые не хотят участвовать в обмене знаниями?</a></li>
13
<li><a>В чем залог успеха кейса Facebook?</a></li>
13
<li><a>В чем залог успеха кейса Facebook?</a></li>
14
</ul><h2>Как выбрать практики обмена знаниями для команд разработки</h2>
14
</ul><h2>Как выбрать практики обмена знаниями для команд разработки</h2>
15
<p>Успех того или иного подхода к обмену знаниями сильно зависит от масштаба, на котором он применяется: в небольшой команде инженеров из шести-восьми человек, в целом отделе или в компании. Каждый из этих случаев требует собственного подхода. В этой статье сосредоточимся на обмене знаниями в небольшой команде.</p>
15
<p>Успех того или иного подхода к обмену знаниями сильно зависит от масштаба, на котором он применяется: в небольшой команде инженеров из шести-восьми человек, в целом отделе или в компании. Каждый из этих случаев требует собственного подхода. В этой статье сосредоточимся на обмене знаниями в небольшой команде.</p>
16
<p><em>Есть два основных принципа, которыми я руководствуюсь при выборе подхода:</em></p>
16
<p><em>Есть два основных принципа, которыми я руководствуюсь при выборе подхода:</em></p>
17
<p><strong>Взаимодействие.</strong>Я предпочитаю активный обмен пассивному - он строится на взаимодействии между людьми, и, в отличие от чтения документации, помогает укрепить связи внутри команды. Взаимодействие в процессе обучения помогает разработчикам лучше узнать друг друга и формирует атмосферу взаимного уважения внутри команды.</p>
17
<p><strong>Взаимодействие.</strong>Я предпочитаю активный обмен пассивному - он строится на взаимодействии между людьми, и, в отличие от чтения документации, помогает укрепить связи внутри команды. Взаимодействие в процессе обучения помогает разработчикам лучше узнать друг друга и формирует атмосферу взаимного уважения внутри команды.</p>
18
<p><strong>Прагматические соображения.</strong>Любой метод обмена знаниями имеет свою цену: нужно трезво оценивать ресурсы, которые вкладываются в обмен знаниями, и сопоставить их с получаемой пользой. Универсального метода не существует - для каждой команды соотношение усилий к результату будет разным.</p>
18
<p><strong>Прагматические соображения.</strong>Любой метод обмена знаниями имеет свою цену: нужно трезво оценивать ресурсы, которые вкладываются в обмен знаниями, и сопоставить их с получаемой пользой. Универсального метода не существует - для каждой команды соотношение усилий к результату будет разным.</p>
19
<h2>С чего начать</h2>
19
<h2>С чего начать</h2>
20
<p><strong>Создание культуры</strong></p>
20
<p><strong>Создание культуры</strong></p>
21
<p>Один из важнейших аспектов - создание среды, в которой поощряется практика задавания вопросов. Здесь важна психологическая безопасность в команде: каждый участник должен понимать, что глупых и неуместных вопросов не существует, а не знать что-то - это нормально.</p>
21
<p>Один из важнейших аспектов - создание среды, в которой поощряется практика задавания вопросов. Здесь важна психологическая безопасность в команде: каждый участник должен понимать, что глупых и неуместных вопросов не существует, а не знать что-то - это нормально.</p>
22
<p>Культура взаимного уважения делает систему обмена знаниями дешевле: люди в команде сами узнают нужную им информацию, а затраты на коммуникацию снижаются до минимума. Правильная инженерная культура облегчает внедрение активных методов обмена знаниями.</p>
22
<p>Культура взаимного уважения делает систему обмена знаниями дешевле: люди в команде сами узнают нужную им информацию, а затраты на коммуникацию снижаются до минимума. Правильная инженерная культура облегчает внедрение активных методов обмена знаниями.</p>
23
<p><strong>Ведение документации</strong></p>
23
<p><strong>Ведение документации</strong></p>
24
<p>Документацию игнорировать невозможно - это самый очевидный способ обмена техническими знаниями. Но, на мой взгляд, он сильно переоценен: документация требует много времени, а время - деньги.</p>
24
<p>Документацию игнорировать невозможно - это самый очевидный способ обмена техническими знаниями. Но, на мой взгляд, он сильно переоценен: документация требует много времени, а время - деньги.</p>
25
<p>Большинство компаний не задумываются о ее стоимости и чувствуют себя обязанными все документировать. При этом поддержание документации в актуальном состоянии требует усилий и времени программистов, которые получают довольно большие зарплаты. К тому же это пассивный метод обмена знаниями, который не поощряет человеческое взаимодействие.</p>
25
<p>Большинство компаний не задумываются о ее стоимости и чувствуют себя обязанными все документировать. При этом поддержание документации в актуальном состоянии требует усилий и времени программистов, которые получают довольно большие зарплаты. К тому же это пассивный метод обмена знаниями, который не поощряет человеческое взаимодействие.</p>
26
<p>В некоторых случаях высокая стоимость документации оправдана - о них поговорим ниже. Во всех остальных от нее можно отказаться и ничего при этом не потерять.</p>
26
<p>В некоторых случаях высокая стоимость документации оправдана - о них поговорим ниже. Во всех остальных от нее можно отказаться и ничего при этом не потерять.</p>
27
<h2>(Мои) правила ведения документации</h2>
27
<h2>(Мои) правила ведения документации</h2>
28
<p>Прежде чем приступить к документированию, оцените контекст. От него зависит, насколько подробно вам нужно описывать проект. Для этого задайте себе несколько вопросов:</p>
28
<p>Прежде чем приступить к документированию, оцените контекст. От него зависит, насколько подробно вам нужно описывать проект. Для этого задайте себе несколько вопросов:</p>
29
<ul><li>Над какой системой вы работаете?</li>
29
<ul><li>Над какой системой вы работаете?</li>
30
<li>Кто ваши клиенты?</li>
30
<li>Кто ваши клиенты?</li>
31
<li>Сколько людей будут работать с вашим кодом?</li>
31
<li>Сколько людей будут работать с вашим кодом?</li>
32
<li>Что именно должно быть задокументировано?</li>
32
<li>Что именно должно быть задокументировано?</li>
33
</ul><p>В документировании нуждается каждый проект. Вот что важно описать вне зависимости от контекста:</p>
33
</ul><p>В документировании нуждается каждый проект. Вот что важно описать вне зависимости от контекста:</p>
34
<ol><li>Принципы архитектуры</li>
34
<ol><li>Принципы архитектуры</li>
35
<li>Все исследования, связанные с проектом</li>
35
<li>Все исследования, связанные с проектом</li>
36
<li>Решения, которые вы принимаете</li>
36
<li>Решения, которые вы принимаете</li>
37
<li>Логику, лежащую в основе ваших решений</li>
37
<li>Логику, лежащую в основе ваших решений</li>
38
</ol><p>В документации должна содержаться информация, которую невозможно получить, изучив код. Не обязательно превращать документацию в официальный документ - некоторые процессы достаточно описать на платформе для внутренней коммуникации (в Facebook это Facebook Workplace).</p>
38
</ol><p>В документации должна содержаться информация, которую невозможно получить, изучив код. Не обязательно превращать документацию в официальный документ - некоторые процессы достаточно описать на платформе для внутренней коммуникации (в Facebook это Facebook Workplace).</p>
39
<p>Документация по API нужна почти в 100% случаев. Но создавать руководства, учебные пособия, примеры и вики-страницы о своем коде для внутреннего пользования необязательно.</p>
39
<p>Документация по API нужна почти в 100% случаев. Но создавать руководства, учебные пособия, примеры и вики-страницы о своем коде для внутреннего пользования необязательно.</p>
40
<h2>Как устроено документирование в Facebook</h2>
40
<h2>Как устроено документирование в Facebook</h2>
41
<p><strong>Когда документация не нужна</strong></p>
41
<p><strong>Когда документация не нужна</strong></p>
42
<p>В Facebook я сначала попал в команду, которая 3,5 года занималась разработкой внутренней системы с очень ограниченным числом пользователей. Я был первым новичком за долгое время и краткость документации сильно затрудняла процесс адаптации.</p>
42
<p>В Facebook я сначала попал в команду, которая 3,5 года занималась разработкой внутренней системы с очень ограниченным числом пользователей. Я был первым новичком за долгое время и краткость документации сильно затрудняла процесс адаптации.</p>
43
<p>Оглядываясь назад, я понимаю, что решение документировать только необходимый минимум информации было правильным - оно сэкономило разработчикам время для работы над проектом.</p>
43
<p>Оглядываясь назад, я понимаю, что решение документировать только необходимый минимум информации было правильным - оно сэкономило разработчикам время для работы над проектом.</p>
44
<p><strong>Когда документация нужна</strong></p>
44
<p><strong>Когда документация нужна</strong></p>
45
<p>Для команды, которая разрабатывает внутренние библиотеки, ситуация обратная. У ее системы тысячи пользователей внутри компании - мы тратили 50-60% времени на поддержку системы, ответы на вопросы и попытки решить проблемы пользователей. Очень подробная документация существенно облегчила работу.</p>
45
<p>Для команды, которая разрабатывает внутренние библиотеки, ситуация обратная. У ее системы тысячи пользователей внутри компании - мы тратили 50-60% времени на поддержку системы, ответы на вопросы и попытки решить проблемы пользователей. Очень подробная документация существенно облегчила работу.</p>
46
<h2>Как выстроить систему обмена знаниями для развития джунов</h2>
46
<h2>Как выстроить систему обмена знаниями для развития джунов</h2>
47
<p><strong>Реальные проекты</strong></p>
47
<p><strong>Реальные проекты</strong></p>
48
<p>В Facebook младшие инженеры очень амбициозны: последнее, что им нужно - это чей-то совет. Они предпочитают сами учиться на своих ошибках. Лучшее, что вы можете сделать - дать им возможность писать код.</p>
48
<p>В Facebook младшие инженеры очень амбициозны: последнее, что им нужно - это чей-то совет. Они предпочитают сами учиться на своих ошибках. Лучшее, что вы можете сделать - дать им возможность писать код.</p>
49
<p>Джунов нужно поддерживать - тогда код, который они пишут, можно было использовать на реальных проектах. При этом облегчать им задачу не обязательно - достаточно дать менее рискованные проекты, в которых не нужно проводить масштабные исследования.</p>
49
<p>Джунов нужно поддерживать - тогда код, который они пишут, можно было использовать на реальных проектах. При этом облегчать им задачу не обязательно - достаточно дать менее рискованные проекты, в которых не нужно проводить масштабные исследования.</p>
50
<p><strong>Ревью кода</strong></p>
50
<p><strong>Ревью кода</strong></p>
51
<p>Ревью кода - еще один крайне важный инструмент развития. Проводить оценку нужно лично, давая младшим инженерам возможность объяснить, почему они выбрали тот или иной подход к написанию кода и проектированию. Это поможет понять логику и вместе выбрать наиболее эффективное решение.</p>
51
<p>Ревью кода - еще один крайне важный инструмент развития. Проводить оценку нужно лично, давая младшим инженерам возможность объяснить, почему они выбрали тот или иной подход к написанию кода и проектированию. Это поможет понять логику и вместе выбрать наиболее эффективное решение.</p>
52
<p>Совместное ревью помогает выработать здоровое отношение к правкам. Отправлять код на проверку в первый раз - большой стресс, поскольку результат точно будут критиковать. Личное присутствие ревьюера поможет снизить стресс и правильно донести суть правок.</p>
52
<p>Совместное ревью помогает выработать здоровое отношение к правкам. Отправлять код на проверку в первый раз - большой стресс, поскольку результат точно будут критиковать. Личное присутствие ревьюера поможет снизить стресс и правильно донести суть правок.</p>
53
<p><strong>Design Review</strong></p>
53
<p><strong>Design Review</strong></p>
54
<p>Это отличный способ помочь младшим инженерам развиваться, особенно если не проводить такое ревью слишком формально. Не нужно просить джуна написать проектный документ - достаточно попросить его за 10 минут нарисовать на доске дизайн решения и объяснить, почему он выбрал именно такой подход. Это возможность помочь без непрошенных советов.</p>
54
<p>Это отличный способ помочь младшим инженерам развиваться, особенно если не проводить такое ревью слишком формально. Не нужно просить джуна написать проектный документ - достаточно попросить его за 10 минут нарисовать на доске дизайн решения и объяснить, почему он выбрал именно такой подход. Это возможность помочь без непрошенных советов.</p>
55
<p><strong>Парное программирование</strong></p>
55
<p><strong>Парное программирование</strong></p>
56
<p>Еще один способ ускорить развитие - решать возникшие проблемы вместе с более опытным инженером. Когда вы видите экран коллеги и наблюдаете, как он использует разные инструменты и как они работают, обучение происходит намного быстрее.</p>
56
<p>Еще один способ ускорить развитие - решать возникшие проблемы вместе с более опытным инженером. Когда вы видите экран коллеги и наблюдаете, как он использует разные инструменты и как они работают, обучение происходит намного быстрее.</p>
57
<p>Стоит отметить, что мне ни разу не удалось внедрить практику парного программирования - все попытки встречали активное сопротивление со стороны команды.</p>
57
<p>Стоит отметить, что мне ни разу не удалось внедрить практику парного программирования - все попытки встречали активное сопротивление со стороны команды.</p>
58
<p><strong>Наставничество</strong></p>
58
<p><strong>Наставничество</strong></p>
59
<p>Наставничество - хороший способ помочь неопытным инженерам расти. Поиск хорошего наставника и развитие доверительных отношений облегчает процесс обучения: дужну проще обратиться за советом и попросить помощи.</p>
59
<p>Наставничество - хороший способ помочь неопытным инженерам расти. Поиск хорошего наставника и развитие доверительных отношений облегчает процесс обучения: дужну проще обратиться за советом и попросить помощи.</p>
60
<h2>Как адаптировать новичков в команде</h2>
60
<h2>Как адаптировать новичков в команде</h2>
61
<p>Онбординг - сложная задача. Я предпочитаю организовать процесс адаптации так, чтобы новый инженер как можно больше взаимодействовал с командой.</p>
61
<p>Онбординг - сложная задача. Я предпочитаю организовать процесс адаптации так, чтобы новый инженер как можно больше взаимодействовал с командой.</p>
62
<p><strong>Разработка документации</strong></p>
62
<p><strong>Разработка документации</strong></p>
63
<p>Попросите новичка написать или обновить документацию для проекта, над которым вы работаете. Это кажется нелогичным, поскольку он пока не знаком с контекстом. Однако эта задача ускорит его адаптацию, и даст команде уверенность, что он разобрался в проекте - проверить это можно, прочитав документацию.</p>
63
<p>Попросите новичка написать или обновить документацию для проекта, над которым вы работаете. Это кажется нелогичным, поскольку он пока не знаком с контекстом. Однако эта задача ускорит его адаптацию, и даст команде уверенность, что он разобрался в проекте - проверить это можно, прочитав документацию.</p>
64
<p>Часто новички не решаются задавать вопросы - считают их не слишком важными, чтобы беспокоить коллег. Описанная выше задача - идеальный повод для общения: каждый участник понимает, что делает свою работу и помогает развитию проекта, а не тратит время впустую.</p>
64
<p>Часто новички не решаются задавать вопросы - считают их не слишком важными, чтобы беспокоить коллег. Описанная выше задача - идеальный повод для общения: каждый участник понимает, что делает свою работу и помогает развитию проекта, а не тратит время впустую.</p>
65
<p><strong>Ревью архитектуры</strong></p>
65
<p><strong>Ревью архитектуры</strong></p>
66
<p>Это короткие встречи с несколькими участниками команды, на которых обсуждается дизайн и архитектура проекта, а инженеры объясняют свои решения и делятся мнениями об их эффективности. Такой формат помогает новичку понять, что его мнение имеет значение.</p>
66
<p>Это короткие встречи с несколькими участниками команды, на которых обсуждается дизайн и архитектура проекта, а инженеры объясняют свои решения и делятся мнениями об их эффективности. Такой формат помогает новичку понять, что его мнение имеет значение.</p>
67
<p><strong>Кейс Facebook</strong></p>
67
<p><strong>Кейс Facebook</strong></p>
68
<p>Стандартная практика в Facebook - дать понять новому инженеру, что он может подвергать сомнению все решения. Идея в том, что свежий взгляд на проект помогает сделать его лучше.</p>
68
<p>Стандартная практика в Facebook - дать понять новому инженеру, что он может подвергать сомнению все решения. Идея в том, что свежий взгляд на проект помогает сделать его лучше.</p>
69
<h2>Как найти время на обмена знаниями?</h2>
69
<h2>Как найти время на обмена знаниями?</h2>
70
<p><strong>Сделайте его частью рутины</strong></p>
70
<p><strong>Сделайте его частью рутины</strong></p>
71
<p>Мой опыт показывает, что попытки выделить отдельное время для обмена знаниями ни к чему не приводят. Когда приближается дедлайн, и команде нужно выбирать, заняться документацией или завершить задачу, в 100% случаев приоритет отдается задаче.</p>
71
<p>Мой опыт показывает, что попытки выделить отдельное время для обмена знаниями ни к чему не приводят. Когда приближается дедлайн, и команде нужно выбирать, заняться документацией или завершить задачу, в 100% случаев приоритет отдается задаче.</p>
72
<p>Поэтому обмен знаниями должен стать рутинным процессом, частью культуры. Не дополнительной задачей, а тем, что инженеры делают ежедневно. Остается решить, сколько времени выделить на обмен и какие методы использовать.</p>
72
<p>Поэтому обмен знаниями должен стать рутинным процессом, частью культуры. Не дополнительной задачей, а тем, что инженеры делают ежедневно. Остается решить, сколько времени выделить на обмен и какие методы использовать.</p>
73
<p><strong>Шеринг-сессии</strong></p>
73
<p><strong>Шеринг-сессии</strong></p>
74
<p>В Facebook регулярно проводятся шеринг-сессии: раз в неделю все члены команды делились тем, какие задачи решали на прошлой неделе, как им удалось справиться с проблемами и какие обновления появились в проекте.</p>
74
<p>В Facebook регулярно проводятся шеринг-сессии: раз в неделю все члены команды делились тем, какие задачи решали на прошлой неделе, как им удалось справиться с проблемами и какие обновления появились в проекте.</p>
75
<p><strong>Документация</strong></p>
75
<p><strong>Документация</strong></p>
76
<p>Можно установить правило - команда не принимает новые коммиты, пока не задокументированы все изменения в API. Такой подход сделает написание документации частью процесса разработки - каждый программист будет закладывать время на нее при выполнении задач.</p>
76
<p>Можно установить правило - команда не принимает новые коммиты, пока не задокументированы все изменения в API. Такой подход сделает написание документации частью процесса разработки - каждый программист будет закладывать время на нее при выполнении задач.</p>
77
<h2>Инструменты для обмена знаниями</h2>
77
<h2>Инструменты для обмена знаниями</h2>
78
<p><strong>Корпоративные чаты</strong></p>
78
<p><strong>Корпоративные чаты</strong></p>
79
<p>Внутренний чат (например, в Slack) - базовый инструмент для обмена знаниями. Это площадка для дискуссий между членами команды и средство поддержания командного духа.</p>
79
<p>Внутренний чат (например, в Slack) - базовый инструмент для обмена знаниями. Это площадка для дискуссий между членами команды и средство поддержания командного духа.</p>
80
<p><strong>Вики-страницы</strong></p>
80
<p><strong>Вики-страницы</strong></p>
81
<p>Внутренние вики-страницы помогут новичкам понять, по какому принципу устроена официальная документация и где нужно искать нужную информацию.</p>
81
<p>Внутренние вики-страницы помогут новичкам понять, по какому принципу устроена официальная документация и где нужно искать нужную информацию.</p>
82
<p><strong>Социальные инструменты</strong></p>
82
<p><strong>Социальные инструменты</strong></p>
83
<p>В Facebook мы пользовались платформой Workspace - это, по сути, тот же Facebook, но для внутреннего использования. В нем есть лента с новостями компании, отделов и сотрудников, сообщества и другие функции социальной сети.</p>
83
<p>В Facebook мы пользовались платформой Workspace - это, по сути, тот же Facebook, но для внутреннего использования. В нем есть лента с новостями компании, отделов и сотрудников, сообщества и другие функции социальной сети.</p>
84
<p>Workspace - хороший инструмент коммуникации: он помогает понять, чем занимаются другие команды. У каждой из них есть своя группа, в которой документируются принимаемые в процессе работы над проектом решения. Написание поста стоит недорого: разработчик или тимлид описывает свой дизайн решения и рассказывает об альтернативных вариантах. Все посты можно найти в поиске - это помогает новичкам проследить историю проекта.</p>
84
<p>Workspace - хороший инструмент коммуникации: он помогает понять, чем занимаются другие команды. У каждой из них есть своя группа, в которой документируются принимаемые в процессе работы над проектом решения. Написание поста стоит недорого: разработчик или тимлид описывает свой дизайн решения и рассказывает об альтернативных вариантах. Все посты можно найти в поиске - это помогает новичкам проследить историю проекта.</p>
85
<p>Кроме того, обсуждения помогают поддерживать асинхронность: если разработчики находятся в разных странах или часовых поясах, они смогут прочитать обсуждение и поучаствовать в нем в удобное для себя время.</p>
85
<p>Кроме того, обсуждения помогают поддерживать асинхронность: если разработчики находятся в разных странах или часовых поясах, они смогут прочитать обсуждение и поучаствовать в нем в удобное для себя время.</p>
86
<p>Workspace для технических команд также выступает аналогом Stack Overflow - в каждой команде есть собственные группы вопросов и ответов, в которых обсуждаются проблемы и их решения.</p>
86
<p>Workspace для технических команд также выступает аналогом Stack Overflow - в каждой команде есть собственные группы вопросов и ответов, в которых обсуждаются проблемы и их решения.</p>
87
<h2>Как мотивировать инженеров, которые не хотят участвовать в обмене знаниями?</h2>
87
<h2>Как мотивировать инженеров, которые не хотят участвовать в обмене знаниями?</h2>
88
<p>Выше я говорил, что превращение обмена знаниями в рутинный процесс - это игра в долгую. Давить на членов команды, чтобы они активнее делились знаниями в таких условиях - плохая идея.</p>
88
<p>Выше я говорил, что превращение обмена знаниями в рутинный процесс - это игра в долгую. Давить на членов команды, чтобы они активнее делились знаниями в таких условиях - плохая идея.</p>
89
<p><strong>Вознаграждение</strong></p>
89
<p><strong>Вознаграждение</strong></p>
90
<p>Очевидный способ поощрить обмен знаниями - вознаградить разработчиков. Деньги - не единственная мотивация: в Workspace каждая публикация получает лайки других разработчиков. Это способ публично поощрить инженера, который прилагает много усилий для обмена знаниями.</p>
90
<p>Очевидный способ поощрить обмен знаниями - вознаградить разработчиков. Деньги - не единственная мотивация: в Workspace каждая публикация получает лайки других разработчиков. Это способ публично поощрить инженера, который прилагает много усилий для обмена знаниями.</p>
91
<p><strong>Фан</strong></p>
91
<p><strong>Фан</strong></p>
92
<p>Передачу знаний можно сделать увлекательным процессом. Подготовка длинного официального документа - это рутинная задача, но презентацию делать куда интереснее. Кто сказал, что документацию нельзя оформлять в виде презентации?</p>
92
<p>Передачу знаний можно сделать увлекательным процессом. Подготовка длинного официального документа - это рутинная задача, но презентацию делать куда интереснее. Кто сказал, что документацию нельзя оформлять в виде презентации?</p>
93
<p><strong>Кейс Facebook</strong></p>
93
<p><strong>Кейс Facebook</strong></p>
94
<p>У Facebook есть офисы по всему миру и сотрудники компании могут бесплатно совершать деловые поездки между офисами. Это один из инструментов поощрения.</p>
94
<p>У Facebook есть офисы по всему миру и сотрудники компании могут бесплатно совершать деловые поездки между офисами. Это один из инструментов поощрения.</p>
95
<p>Например, однажды я работал в лондонской команде, которая искала эффективный способ проанализировать данные. Над тем же проектом работала команда из Нью-Йорка. Один из инженеров предложил устроить в Нью-Йоркском офисе "неделю анализа данных", где обе команды смогут поработать над решением задачи в одном пространстве.</p>
95
<p>Например, однажды я работал в лондонской команде, которая искала эффективный способ проанализировать данные. Над тем же проектом работала команда из Нью-Йорка. Один из инженеров предложил устроить в Нью-Йоркском офисе "неделю анализа данных", где обе команды смогут поработать над решением задачи в одном пространстве.</p>
96
<p>Я почти уверен, что тому инженеру нравилась идея бесплатно съездить в Нью-Йорк. Это сделало бы работу над проектом увлекательнее. В результате эта "неделя данных" стала самой продуктивной за долгое время.</p>
96
<p>Я почти уверен, что тому инженеру нравилась идея бесплатно съездить в Нью-Йорк. Это сделало бы работу над проектом увлекательнее. В результате эта "неделя данных" стала самой продуктивной за долгое время.</p>
97
<p><strong>Сделайте обмен знаниями привлекательным</strong></p>
97
<p><strong>Сделайте обмен знаниями привлекательным</strong></p>
98
<p>Постарайтесь связать обмен знаниями с целями, которые стоят перед командой. Например, целью может быть развитие разговорного английского. Ее легко можно связать с публичными выступлениями, на которых разработчики могут рассказывать об опыте работы над проектом.</p>
98
<p>Постарайтесь связать обмен знаниями с целями, которые стоят перед командой. Например, целью может быть развитие разговорного английского. Ее легко можно связать с публичными выступлениями, на которых разработчики могут рассказывать об опыте работы над проектом.</p>
99
<p><strong>Положительный опыт</strong></p>
99
<p><strong>Положительный опыт</strong></p>
100
<p>Говорить об обмене знаниями с командой недостаточно: нужно на примере показать, почему важно принимать участие в этом процессе. То есть показать, что получат они и другие члены команды.</p>
100
<p>Говорить об обмене знаниями с командой недостаточно: нужно на примере показать, почему важно принимать участие в этом процессе. То есть показать, что получат они и другие члены команды.</p>
101
<h2>В чем залог успеха кейса Facebook?</h2>
101
<h2>В чем залог успеха кейса Facebook?</h2>
102
<p>Успех в организации обмена знаниями сильно зависит от уровня инженерной культуры в компании.</p>
102
<p>Успех в организации обмена знаниями сильно зависит от уровня инженерной культуры в компании.</p>
103
<p><strong>Прозрачность процессов</strong></p>
103
<p><strong>Прозрачность процессов</strong></p>
104
<p>Каждый сотрудник Facebook знает, как устроены процессы в его команде и как она управляется. Другими словами, сотрудники всегда знают, что происходит внутри компании - это положительно сказывается на их мотивации.</p>
104
<p>Каждый сотрудник Facebook знает, как устроены процессы в его команде и как она управляется. Другими словами, сотрудники всегда знают, что происходит внутри компании - это положительно сказывается на их мотивации.</p>
105
<p><strong>Фокус на взаимодействие</strong></p>
105
<p><strong>Фокус на взаимодействие</strong></p>
106
<p>Инженерная культура Facebook основана на взаимодействии между сотрудниками. По мере роста компании становятся все более бюрократизированными. Facebook же удалось сохранить высокий уровень коммуникации - это благотворно влияет на обмен знаниями.</p>
106
<p>Инженерная культура Facebook основана на взаимодействии между сотрудниками. По мере роста компании становятся все более бюрократизированными. Facebook же удалось сохранить высокий уровень коммуникации - это благотворно влияет на обмен знаниями.</p>