Хорошие специалисты часто ненавидят писать документацию.

И, если честно, я их прекрасно понимаю.

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

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

Но очень мало кто любит заниматься корпоративной бюрократией ради самой бюрократии.

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

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

То есть самая ценная экспертиза компании часто существует в максимально неудобном для передачи формате — в человеческой голове.

А потом этот человек увольняется.

И внезапно выясняется, что половина процессов компании держалась на каком-то шаманизме, который никто никогда не описывал.

Мне вообще кажется, что хороший knowledge management начинается не с «заставим всех писать документацию», а с вопроса: «Как сделать передачу знаний настолько простой и полезной, чтобы люди сами полюбили этот процесс?»

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