Как устроен обмен знаниями в инженерных командах Facebook. Большой гайд по шерингу экспертизы в компании
2026-02-26 22:31 Diff
https://ru.hexlet.io/blog/posts/kak-ustroen-obmen-znaniyami

Обмен знаниями внутри инженерной команды — очень важный процесс для бизнеса. От методов, на основе которых он встроен, зависит успешность адаптации новых программистов при работе над сложным проектом, скорость обучения джунов и внедрения новых технологий. Бывший 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 же удалось сохранить высокий уровень коммуникации — это благотворно влияет на обмен знаниями.