# Распространение знаний

# Описание

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

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

Чаще всего эти знания оседают в головах конкретных людей, и незаменимыми сотрудников делают именно они, а не конкретные навыки. Именно поэтому в ветке "Управление компетенциями" придаётся такое значение понятию bus factor – с уходом человека исчезает не только член команды, но и вся накопленная им за время работы над проектом информация.

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

# Почему ветка важна?

Для тимлида:

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

Для команды:

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

# Что будет, если её не делать?

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

# На кого может быть делегирована?

На любого члена команды, в том числе и на не разработчиков

# Примеры поведения

# Примеры плохого поведения

На проекте полностью отсутствует документация
Не ведутся логи встреч, где принимаются решения по процессам или архитектуре
Люди в команде работают обособленно и не делятся своими мыслями с коллегами
Разработчики не выходят за пределы подсистемы, разработкой которой занимаются
Члены команды не делятся новостями и своим опытом использования новых технологий

# Примеры хорошего поведения

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

# Способы прокачки

# Практика

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

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

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

Ведение базы знаний в Confluence, Quip, Notion или другой системе
Организация командного Stack Overflow
Отдельный чат в мессенджере для Q&A
Регулярные внутренние технические митапы
Архитектурные и code ревью
Технический радар
Рассылки про изменения в технологиях и продукте
Краткие дайджесты в командном чате
Общие демо или стендапы

# Консультации

# Теория

# Статьи