Как наладить обмен знаниями в компании, чтобы не было так больно
У среднестатистической ИТ-компании есть требования, история таск-трекеров, исходники (возможно, даже с комментариями в коде), инструкции на типовые, важные и сложные случаи на проде, описание бизнес-процессов (от онбординга до «как пойти в отпуск»), контакты, ключи доступа, списки людей и проектов, описание зон ответственности — и куча других знаний, о которых мы наверняка забыли и которые могут храниться в самых удивительных местах.
Как сделать так, чтобы те, кому понадобилось узнать что-то из этого, понимали, где и как это найти, а все, кому нужно быть в курсе отдельных вещей и договоренностей, моментально и точно могли узнать об изменениях в них.
В финальном выпуске подкаста «Тимлид позвонит» ребята из Skyeng поговорили про управление знаниями с Игорем may-cat Цупко — человеком из программного комитета KnowledgeConf и «директором по неизвестному» во Фланте.
Полная запись доступна в виде ютуб-ролика, а ниже мы собрали несколько интересных советов и ссылки на полезные материалы, которые упоминались в аудио или расширяют информацию из него. Будет здорово, если вы тоже поделитесь хаками и граблями своей команды в комментариях.
Первый хак: вам больше не надо знать, в какой из систем искать
"Я взял наши источники знаний и сделал по ним общий поиск: такое единое окно с системой фильтрации, чтобы уменьшить область поиска. Да, при этом все еще нужно следить за его качеством, пополнять базы знаний, бороться с дупликацией и ошибочной информацией.
Но уже сейчас порядка 60% инженеров Фланта пользуются этим поиском минимум 1-2 раза в день — и обычно находят ответы на первой-второй позиции. А в виде proof of concept лежит индексировалка гугл-документов: все доксы, папки, ван драйвы и так далее — это все тоже запросто вгоняется во внутренний поиск".
Второй хак: как не упустить критично-важное в куче чатов
«Если вы работаете в распределенной команде, то наверняка заметная часть вашего дня проходит в Slack — и в случае чего вы привыкли делать как-то так: «@myteam, помогите/смотрите/вписать нужное...». Но есть проблема обилия информации — и отдельное упоминание можно пропустить среди других сообщений.
Нам в Skyeng помогает бот, через которого можно написать сообщение и тегнуть любое количество людей или групп. Используем в случаях, когда реально важно, чтобы люди прочитали или отреагировали: он будет бесконечно тыкать, пока не нажмешь кнопочку «Я прочитал» — пропустить или проигнорировать не получится".
Вопрос на засыпку: что делать с документацией?
«Очень много знаний исходит от технарей, но не все умеют их хорошо описывать. Ведь у тебя нет никакого компилятора или линтера, который сказал бы, правильно ты делаешь или нет — и часто на выходе мы имеем непонятный, плохо оформленный и неполный текст. Конечно, делать нормально надо не потому, что кто-то пришел и сказал «надо» — ты сам себе же хорошо делаешь: через месяц-другой прочитаешь и поймешь. Да и другой человек, открывая доку, не будет тут же закрывать ее навсегда, понимая, что она никакая.
Но остается вопрос: а сколько времени на это выделять и как качественно делать?
И если тут есть честный ответ: если не будут вовлечены люди из бизнеса, и если они эмпирически не почувствуют отдачу от хорошей документации, есть риск, что попытки дадут малую отдачу. Это больше история про изменение культуры.
А в остальном, вас спасут опыт и наставничество. Тут могут подойти аналоги парного программирования, трекинга прогресса и код-ревью — показ лучших практик, тыкание в ошибки и нудение в конце концов".
Бонус: «Да ладно, я им так расскажу, поймут»
Вопрос «а сколько времени на это тратить и на каком уровне делать» важен не только в рамках документации, а вообще для передачи любых знаний. Демо — тоже прекрасный пример обмена информацией. Но есть нюансы: например, как сделать так, чтобы они минимально отнимали время.
Отчасти эти проблемы помогает решить практика внутренних докладов. Раз в неделю берется 40-60 минут в не самое нагруженное время — и ребята делают доклад по видео для коллег из разных проектов. Команда фронтенда ключевого продукта — Vimbox — рассказала о своем UI kit, который можно темизировать под любой другой проект. Команда маркетинговой разработки — про библиотеку для трассировки и логирования запросов, которая тут же заинтересовала еще несколько проектов. Команда проекта «Математика» поделилась опытом перехода с REST API на GraphQL. Команда групповых уроков думает рассказать, как первой перешла на PHP 7.4. И так далее.
Все встречи-заводятся через корпоративный Google Meet, записываются и в течение суток оказывают в папке на общем гугл-диске, а ссылки на записи дублируются в тот же Slack. То есть, можно не приходить, если аврал, а посмотреть потом на 1.5 скорости — обычно сам доклад идет до 20 минут, а обсуждение — как получится. Но за рамки часа не выходим).