Како да се воспостави размена на знаење во една компанија за да не боли толку многу

У среднестатистической ИТ-компании есть требования, история таск-трекеров, исходники (возможно, даже с комментариями в коде), инструкции на типовые, важные и сложные случаи на проде, описание бизнес-процессов (от онбординга до “как пойти в отпуск”), контакты, ключи доступа, списки людей и проектов, описание зон ответственности — и куча других знаний, о которых мы наверняка забыли и которые могут храниться в самых удивительных местах.

Знания =/= документация. Это нельзя объяснить, это надо запомнить

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

В финальном выпуске подкаста “Тимлид позвонит” ребята из Skyeng поговорили про управление знаниями с Игорем may-cat Цупко — человеком из программного комитета KnowledgeConf и “директором по неизвестному” во Фланте.

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

Первый хак: вам больше не надо знать, в какой из систем искать

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

Один скрепыш, чтобы найти вот-это-всё

Но уже сейчас порядка 60% инженеров Фланта пользуются этим поиском минимум 1-2 раза в день — и обычно находят ответы на первой-второй позиции. А в виде proof of concept лежит индексировалка гугл-документов: все доксы, папки, ван драйвы и так далее — это все тоже запросто вгоняется во внутренний поиск”.

Второй хак: как не упустить критично-важное в куче чатов

“Если вы работаете в распределенной команде, то наверняка заметная часть вашего дня проходит в Slack — и в случае чего вы привыкли делать как-то так: “@myteam, помогите/смотрите/вписать нужное…”. Но есть проблема обилия информации — и отдельное упоминание можно пропустить среди других сообщений.

Нам в Skyeng помогает бот, через которого можно написать сообщение и тегнуть любое количество людей или групп. Используем в случаях, когда реально важно, чтобы люди прочитали или отреагировали: он будет бесконечно тыкать, пока не нажмешь кнопочку “Я прочитал” — пропустить или проигнорировать не получится”.

Вопрос на засыпку: что делать с документацией?

“Очень много знаний исходит от технарей, но не все умеют их хорошо описывать.
Ведь у тебя нет никакого компилятора или линтера, который сказал бы, правильно ты делаешь или нет — и часто на выходе мы имеем непонятный, плохо оформленный и неполный текст. Конечно, делать нормально надо не потому, что кто-то пришел и сказал “надо” — ты сам себе же хорошо делаешь: через месяц-другой прочитаешь и поймешь. Да и другой человек, открывая доку, не будет тут же закрывать ее навсегда, понимая, что она никакая.

Часть подкаста, посвященная вопросу “Сколько нужно человек, чтобы написать хорошую документацию или сделать нормальное демо”

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

А в остальном, вас спасут опыт и наставничество. Тут могут подойти аналоги парного программирования, трекинга прогресса и код-ревью — показ лучших практик, тыкание в ошибки и нудение в конце концов”.

Бонус: “Да ладно, я им так расскажу, поймут”

Вопрос “а сколько времени на это тратить и на каком уровне делать” важен не только в рамках документации, а вообще для передачи любых знаний. Демо — тоже прекрасный пример обмена информацией. Но есть нюансы: например, как сделать так, чтобы они минимально отнимали время.

Канал обмена знаниями среди разработки: внутренние доклады, полезные книги, статьи и т.д. Структурированная выжимка также хранится в Notion.

Отчасти эти проблемы помогает решить практика внутренних докладов. Раз в неделю берется 40-60 минут в не самое нагруженное время — и ребята делают доклад по видео для коллег из разных проектов. Команда фронтенда ключевого продукта — Vimbox — кажа о своем UI kit, который можно темизировать под любой другой проект. Команда маркетинговой разработки — про библиотеку для трассировки и логирования запросов, которая тут же заинтересовала еще несколько проектов. Команда проекта «Математика» поделилась опытом перехода с REST API на GraphQL. Команда групповых уроков думает рассказать, как первой перешла на PHP 7.4. И так далее.

Список ведется с мая 2018-го и насчитывает свыше 120 записей

Все встречи-заводятся через корпоративный Google Meet, записываются и в течение суток оказывают в папке на общем гугл-диске, а ссылки на записи дублируются в тот же Slack. То есть, можно не приходить, если аврал, а посмотреть потом на 1.5 скорости — обычно сам доклад идет до 20 минут, а обсуждение — как получится. Но за рамки часа не выходим)

PS А что сработало и не сработало у вас?

Корисни врски:

• Родион Нагорнов из “Лаборатории Касперского” про то, что такое управление знаниями и почему это не документация (спасибо за ссылку каналу Игоря “Уютный ИТ-адочек”, там еще много такого).

• Игорь Цупко из Фланта про то, как внедрять управление знаниями у себя в компании

• Алексей Катаев из Skyeng про то, как отслеживать и нивелировать бас-фактор (пробелы знаний по технологиям и специфическим областям) в распределенной команде.

• Сергей Гончарук из Фланта про донесение информации — как понять, когда и кого спросить, если столкнулся с проблемой в распределенной команде.

Извор: www.habr.com