У среднестатистической ИТ-компании есть требования, история таск-трекеров, исходники (возможно, даже с комментариями в коде), инструкции для типичных, важных и сложных случаев в производстве, описание бизнес-процессов (от онбординга до «как уйти в отпуск»).
»), контакты, ключи доступа, списки людей и проектов, описания зон ответственности — и куча других знаний, о которых мы наверняка забыли и которые можно хранить в самых удивительных местах.
Знания =/= документация.
Это невозможно объяснить, это нужно помнить Как сделать так, чтобы те, кому необходимо что-то из этого знать, понимали, где и как это найти, и каждый, кому необходимо быть в курсе отдельных вещей и соглашений, мог мгновенно и точно узнать об изменениях в них.
В заключительном выпуске подкаста «Тимлид позвонит» ребята из Skyeng поговорили с Игорем об управлении знаниями майская кошка Цупко — член программного комитета KnowledgeConf и «директор неизвестного» во Flant. Полная запись доступна по ссылке YouTube видео , а ниже мы собрали несколько интересных советов и ссылок на полезные материалы, которые были упомянуты в аудио или расширили информацию из него.
Было бы здорово, если бы вы также поделились в комментариях лайфхаками и хитростями вашей команды.
Первый хак: вам больше не нужно знать, в какой системе искать
«Я взял наши источники знаний и сделал по ним общий поиск: единое окно с системой фильтрации для уменьшения области поиска.Да, при этом еще нужно следить за ее качеством, пополнять базу знаний, бороться с дублированием и ошибочной информацией.
Один лист бумаги, чтобы найти это все
Но уже около 60% инженеров Flant пользуются этим поиском хотя бы 1-2 раза в день — и обычно находят ответы на первой или второй позиции.
А в виде доказательства концепции — индексация документов Google: всех доксов, папок, дисков фургонов и так далее — все это тоже легко забивается во внутренний поиск».
Второй хак: как не пропустить критически важные вещи в куче чатов
«Если вы работаете в распределенной команде, то, вероятно, значительная часть вашего дня проводится в Slack — и в этом случае вы привыкли делать что-то вроде этого: «@myteam, помоги/посмотри/введи необходимое…» .Но есть проблема с обилием информации – и отдельное упоминание среди других сообщений можно пропустить.
В Skyeng нам помогает бот, с помощью которого можно написать сообщение и отметить любое количество людей или групп.
Используем его в тех случаях, когда действительно важно, чтобы люди прочитали или отреагировали: он будет тыкать бесконечно, пока не нажмешь кнопку «Прочитал» — пропустить или проигнорировать не получится».
Вопрос на ответ: что делать с документацией?
«Многие знания исходят от технарей, но не все умеют их хорошо описать.Ведь у вас нет никакого компилятора или линтера, который бы подсказывал, правильно вы это делаете или нет — и зачастую на выходе мы имеем непонятный, плохо отформатированный и неполный текст. Конечно, нужно делать это нормально, а не потому, что кто-то пришел и сказал «надо» — ты это делаешь хорошо для себя: через месяц-два прочитаешь и поймешь.
И другой человек, открыв документ, не станет сразу закрывать его навсегда, понимая, что он бесполезен.
Часть подкаста, посвященная вопросу «Сколько людей нужно, чтобы написать хорошую документацию или сделать нормальную демку» Но остается вопрос: сколько времени на это выделить и как сделать это эффективно? И если здесь есть честный ответ: если в процесс не будут вовлечены деловые люди и если они эмпирически не испытают на себе влияние хорошей документации, существует риск того, что эти усилия принесут небольшую отдачу.
Это скорее история об изменении культуры.
В остальном вас спасет опыт и наставничество.
Здесь могут подойти аналоги парного программирования, отслеживания прогресса и code review — показ лучших практик, тыканье в ошибках и занудство в конце».
Бонус: «Ладно, я им так скажу, они поймут»
Вопрос «сколько времени на это потратить и на каком уровне это сделать» важен не только в рамках документации, но и вообще для передачи любых знаний.Демо также является отличным примером обмена информацией.
Но есть нюансы: например, как сделать так, чтобы они занимали минимальное время.
Канал обмена знаниями между разработчиками: внутренние отчеты, полезные книги, статьи и т. д. Структурированный отрывок также хранится в Notion.
Частично эти проблемы может решить практика внутренних отчетов.
Раз в неделю в менее загруженное время выделяется 40-60 минут — и ребята делают видеоотчет для коллег из разных проектов.
Фронтенд-команда ключевого продукта — Vimbox — сказал о вашем наборе пользовательского интерфейса, который может быть тематическим для любого другого проекта.
Команда развития маркетинга рассказала о библиотеке для отслеживания и протоколирования запросов, которая сразу привлекла интерес нескольких других проектов.
Команда проекта Mathematics поделилась опытом перехода с REST API на GraphQL. Команда групповых занятий думает рассказать, как они первыми перешли на PHP 7.4. И так далее.
Список ведется с мая 2018 года и насчитывает более 120 записей.
Все встречи запускаются через корпоративный Google Meet, записываются и в течение 24 часов появляются в папке на общем диске Google, а ссылки на записи дублируются в том же Slack. То есть не надо приходить, если ЧП, а смотреть потом на скорости 1,5 - обычно сам репортаж длится до 20 минут, а обсуждение - как получится.
Но мы не выходим за рамки часа) P.S. Что сработало и не сработало для вас? Полезные ссылки:
- Родион Нагорнов из «Лаборатории Касперского» о что такое управление знаниями и почему это не документация (спасибо каналу Игоря за ссылку “Уютный IT-ад” , там еще много подобного).
- Телеграм-канал Игоря Цупко из Фланта о как реализовать управление знаниями в моей компании
- Алексей Катаев из Skyeng о том, как контролировать и выравнивать фактор баса (пробелы в знаниях в технологиях и конкретных областях) в распределенной команде.
- Сергей Гончарук из Flant о донесении информации - как узнать, когда и кого спросить , если вы столкнулись с проблемой в распределенной команде.
-
Дата Профессиональной Деформации Учёных
19 Oct, 24 -
Друпалконф — 2 Июня
19 Oct, 24 -
Русский Linux-Подкаст
19 Oct, 24
