🚘 Вася уволился и унёс с собой 80% знаний о системе
Главная проблема любой ИТ-команды - это bus factor, когда знания о системе живут только в голове одного незаменимого Васи. Мы теряем контекст решений, архитектурные компромиссы и историю, как только человек уходит. Спасти проект может только одно: культура фиксации знаний, встроенная в процесс, а не существующая отдельно от него в виде мертвой Wiki.
Фреймворк онбординга строится на трех этапах. День 1 - ориентация: база знаний выступает навигатором, заменяя устные пересказы и ответы на вопросы "К кому пойти". Неделя 1 - погружение: новичок разбирает архитектуру, где зафиксированы не просто решения, а путь к ним: проблема, варианты, последствия. Месяц 1 - автономность: человек начинает работать сам и, что критически важно, становится автором базы, закрывая пробелы, которые замылились для старожил.
Самое ценное - это четыре уровня связки знаний, которые превращают документацию из формальности в рабочий инструмент.
Первое: архитектура связывается с базой знаний, которые пишутся 20 минут, но читаются годами.
Второе: задачи привязываются к статьям, чтобы разработчик видел контекст еще до того, как начал писать код.
Третье: код связывается с базой знаний через ссылки в коммитах и PR, делая code review осмысленным, а не похожим на допрос.
Четвертое: люди привязываются к знаниям - мы фиксируем экспертов и авторов, чтобы при инциденте или уходе сотрудника мы знали, у кого спросить или где искать ответы в системе.
Главный барьер - это лень и вечная занятость. Решение - убрать трение. Используйте ИИ-ассистентов, чтобы превращать устные объяснения в черновики или FAQ за 30 секунд, и настраивайте low-code автоматизации, чтобы система сама напоминала обновить документацию при закрытии задачи. Писать документацию "потом" бессмысленно - "потом" не наступает. Встраивайте ее в момент принятия решения. Это рутина, но именно она страхует вас от того момента, когда Вася ушел, а вместе с ним испарился весь контекст бизнеса.
LinkedIn: Артём Герасимов, Agile Coach - SimpleOne
