KnowledgeConf 2019. Впечатления и отчет

Отчет по докладам с конференции KnowledgeConf 2019 (24.04.2019).

Сайт

Тезисы

Tg

Конспекты

Ключевые слова: матрица компетенций, скиллсет, роль, onboarding, адаптация новых сотрудников, e-learning, knowledge sharing, обмен знаниями, мотивация, обучение, reuse, не изобретаем велосипед, компетенции, performance review.
Кому может быть интересно: тимлидам, HR, project manager, техническому писателю, руководителю технической поддержки, руководителю QA.
Инструменты: Jive (старое видео в кроке), Confluence, Jira, Visual Studio Code, Xi (синтаксис + расширение для VSC), Moodle, Evernote, MarginNote, Smart Commit (технология).

Идеи и что было бы здорово применить

Основные направления:

• матрица компетенций - это важно:
  • от должностной инструкции к списку нужных скиллов и знаний;
  • смотрим, каких компетенций не хватает, какие нужно продублировать;
  • проще составлять запросы на найм новых сотрудников;
  • на основе компетенций можно составлять роли и теги для базы знаний
• onboarding - это круто:
  • адаптация новых сотрудников;
  • создаем чек-лист - что сделать, чтобы пройти испытательный срок, конкретные DoD (definitions of done);
  • работает и для нового сотрудника, и для ментора (определяем, у кого есть склонность к менторству);
  • выявляем проблемы, если сотрудник не справляется или сваливает;
  • знакомим с командой, с целями компании, с бизнес-процессами, кто и что делает;
  • формируем индивидуальный план обучения и план обучения команды (какие компетенции нам нужны)
• sharing knowledge - потрать время сейчас - сэкономь время потом:
  • переиспользуем технические решения внутренние или opensource - не изобретай велосипед!;
  • готовые решения повторяющихся проблем (для технической поддержки, DevOps, администраторов);
  • делимся идеями и инструментами, чтобы другие люди не изобретали велосипед и не тратили время;
  • продвижение новых нужных компетенций и внутреннее обучение;
• мотивация обмена знаниями - формирование культуры и требований:
  • культура обмена знаниями - рождается из необходимости снизу, поддерживается сверху (ресурсами);
  • удобство и красота инструмента - ЭТО ВАЖНО;
  • формат (красота, картинки, формирование, доступность) подачи - ЭТО ВАЖНО;
  • закладываем время на документирование оценку задач и проектов;
  • материальная и нематериальная мотивация (деньги и признание/похвала);
  • документирование - это привычка. Хорошая привычка.

DISCLAIMER: заметки ниже это конспект + идея + личные пояснения (что я поняла и вынесла для себя), могут не соответствовать полностью содержанию доклада

Доклад 1: Холистическое управление знаниями в IТ-компании

Тезисы

Оценка: 8/10

Компания: КРОК

Чем впечатлил: очень крутая корпоративная система, мотивация вовлеченности сотрудников, хорошая структура доклада Что не понравилось: вставки из Игры престолов не к месту (может потому что я не фанат), сомнительные идеи по геймификации

Экономика ресурсов vs Экономика знаний. Активы экономики знаний: человек, роль, компетенция, знание -> нематериальный актив. Нужно определить точки бизнес-процесса, где требуются нематериальные знания:

• вход в некий процесс, который требует знания (нематериальный актив). Пример: обращение в колл-центр или в техническую поддержку. Ответ на вопрос или решение задачи требует, в том числе, нематериального актива - знания конкретного лица (специалиста поддержки);
• выход из бизнес-процесса, по результатам которого создается нематериальный актив. Пример: возникла проблема, мы ее решили, нужно задокументировать решение (чтобы использовать дальше);
• случайные идеи. Идеи, возникающие в процессах обсуждения. Пример: исследования для выбора возможной архитектуры, результаты тестирования, идеи по результатам митингов.

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

• двойная работа (“не изобретай велосипед”). Если эту проблему уже решила другая команда, можно просто взять ее решение, и не тратить время и ресурсы компании;
• сложный поиск. Знания хранятся хрен знает где, в нескольких местах, часто ограничен доступ;
• масштабирование и гибкость системы. Количество пользователей и гибкость для разных проектов;
• коммуникация. Сотрудники не знают своих коллег и чем они занимаются, не знают, как их найти, как к ним обратиться, кто за что отвечает;
• утечка и потеря знаний. Ситуация, когда сотрудник, который владеет ключевым знанием уходит и знание НИГДЕ не сохранено, недопустима. Незадокументированное ключевое знание (особенность архитектуры, причина ее изменения, особенность обработки) может вылиться в десятки потраченных зря человеко-часов.

Методология. Определяем требования для системы знаний.

• AS IS. Оцениваем, что есть сейчас;
• TO BE. Формируем понимание, чего хотим получить и чего добиться;
• ACTION PLAN. Что нужно сделать.

Матрица знания. Формируем матрицы знаний, какие для нас знания самые важные (spoiler: Ключевые. Знание специфичные для проекта и которые нельзя добыть больше совсем нигде).

• архивные. Знания по прошлым проектам;
• общие. Знания, которые можно найти где-то еще. Экономят время, но не составляет большого труда их восстановить или найти в условном гугле. Не уникальны;
• важные. Знание, которое можно купить на рынке;
• ключевые - самые важные знания.

Управление компетенциями:

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

Мотивация:

• важно мотивировать сотрудника и хвалить, когда он проявляет инициативу по обмену знаниями;
• конкретно в КРОК есть система баллов. Публикации и участии в наполнении базы знаний добавляет сотруднику баллы, которые он может тратить во внутреннем магазине.
• конкурсы (иногда - шуточные). В КРОКе был проведен конкурс “Подколи коллегу” на 1ое апреля, который повысил посещаемость корпоративной системы и познакомил с ней сотрудников;
• в продвижении системы знаний и вовлечении сотрудников активно участвует HR отдел.

Почему сотрудники не хотят писать:

• некачественный инструмент;
• неудобно;
• непонятно зачем.

Проект не считается закрытыми, пока каждый участник не оставит отзыв по проекту. (ИДЕЯ: не считать проект/этап закрытым, пока ключевые знания не будут задокументированы).

Корпоративный поиск также может быть источником знания:

• что ищут чаще всего и НЕ НАХОДЯТ;
• количество просмотров статей и сколько тратится на их чтение.

Обратная связь:

• очень важно понимать, какими инструментами сотрудники пользуются и как они их оценивают. Наиболее нужный инструмент в компании нужно развивать и тратить на него ресурсы. Можно использовать как метрику, для оценки возможности трат ресурсов;

• важно спрашивать сотрудников об их идеях, как бы они решили конкретную задачу (предложи инструмент, предложи решение);
• важно исследовать, какие лайфхаки используют сотрудники. Табличка Excel? Какой-то маленький скрипт? Формула? Нужно находить возможности для их улучшения и экономии ВРЕМЕНИ

Интересно: постоянные штат поддержки корпоративной системы 4 чел. + рандомные сотрудники время от времени

Техническая реализация:

• Jive + плагины и доработки;
• Moodle (эксперименты)
• Telegram-бот (задаем вопрос боту а ля “кто такой Иван Иванов”, “порядок выхода в отпуск”) и Telegram выдает ответ или ссылку на статью в базе знаний;
• Jira, Confluence, Elasticsearch

Доклад 2: Применение практик Тиаго Форте для управления своими знаниями

Тезисы

Оценка: 6/10

Конспект

Компания: Express42

Что не понравилось: управлением знаниями это назвать нельзя, скорее управление информацией речь только про текст (книги, статьи)

Краткое описание практики: набор идей и практик для быстрой “загрузки” информации в контексте в мозг (например, из прочитанной ранее статьи или книги). Описание чуть подлиннее.

Идея: Создаем конспект “над” оригиналом:

• выделяем главное;
• выделяем ключевые слова и фразы;
• делаем мини summary главы или статьи;
• при повторном чтении ориентируемся на summary и ключевые фразы. Если этого недостаточно, всегда можно быстро окинуть взглядом оригинал. Оригинал всегда перед глазами.

Доклад 3: Performance Review и выявление тайного знания

Тезисы

Оценка: 9/10

Что понравилось: больная проблема, хорошая структура, конкретные идеи

Как стать лучше? Как оценивать рост сотрудников и мотивировать их обучение?

Прозрачные правила роста:

• нужна детализация;
• нужна “линейка” (уровень владения SQL с гуглом min > решаю проблемы галактической важности с космической скоростью SQL max);
• нужна оценка квалификации экспертом;
• нужна матрица компетенций - навык/уровень владения.

Ни одна практика не дает 100% результата. Aka - они плохи, но других у нас для вас нету.

Проблемы:

• зачем расти, когда и так не плохо кормят?
• слабая вовлеченность в результат (я тут с краешку посижу, свое попилю, а “будущие проблемы - проблемы будущих программистов”);
• нет фидбека (сотрудник не понимает, хорошо или плохо он работает и что улучшить).

Собеседования с сотрудниками (по оценке текущей работы):

• к собеседованию надо готовиться;
• тезисы должны быть конкретными. “Какой-то мутный он” (неправильно) - “Долго выполнял задачу 123, непонятно, почему выбрал такое решение, на вопрос почему - ответить не смог” (правильно).
• подкреплять тезисы конкретными фактами: трекер задач, история в мессенджере, отзывы коллег, следы в вики;
• формулировать четко;
• давать сотруднику высказать свое мнение о проблеме, уточнить факты и обстоятельства;
• при наличии проблемы, определить, готов ли он ее решать.

Посчитали, что как только отладили практику подготовки, то она стала занимать ок. 30 мин. Нужно примерно 6-12 собеседований, чтобы тимлид/руководитель научились это делать правильно. Важно понять, принял человек фидбек или нет.

Как классифицировать скиллы? Хз.

Выявили для себя важные софт-скиллы: увлеченность, умение концентрироваться, вникать в цель задачи, нет страха показаться глупым (yes!).

Интересно замечание: если к человеку по конкретным задачам вообще только позитивные отзывы, то возможно стоит ему дать задачу посложнее.

Доклад 4: Разработка базы знаний компании, которой действительно пользуются

Тезисы

Оценка: 9/10

Что понравилось: идея доступа по ролям, выявление важных проблем, больная тема :). Интересные слайды. Очень классная фишка с графами и облаками тегов. Например, могут выявлять аномальные теги, выявлять связи между тегами, статьями. Очень круто (можно слайды посмотреть)

Проблема, с которой столкнулись в компании: разработали некоторую базу, засунули туда информацию, сотрудники сначала пользовались - потом перестали (отслеживали по метрикам - что ищут, сколько по времени читают статью). Почему и как сделать, чтобы пользовались?

Чем больше материалов - тем меньше читают (хнык).

Разработали требования к системе знаний:

• масштабируемость (в компании много сотрудников, быстро растет);
• отличны поиск, система тегирования. Внедрили построение графов на основе облака тегов, чтобы выявлять связи между материалами (круто!);
• структура рекомендаций (“возможно вам будет интересно почитать еще вот это”);
• управление доступом. К роли также привязан определенны набор тегов (всего тегов около 10 000)

Построили матрицу компетенций, связали с выполняемыми задачами, назначали роль, которая регулирует доступ к материалам. Роль определяет навыки, требуемый скилл (обучение) и soft-skill. Для роли и для компетенции формируется индивидуальны план обучения и роста сотрудника.

Система знаний строилась исходя из жизненного цикла сотрудника (роли) в компании:

• onboarding - новы сотрудник;
• увольняющийся;
• опытный сотрудник.

Определили общие вопросы, которые новые (и опытные) сотрудники задают чаще всего (опросили сотрудников “что бы вы хотели, чтобы вас больше НЕ СПРАШИВАЛИ”, aka как сделать справку, кому отдавать заявление, где тут кофе сварить, кому ключи оставлять). Разработали бот для Telegram, которому эти вопросы можно задать и он предоставляет информацию или ссылку на базу знаний.

Для части материалов, которые новому сотруднику требуется обязательно изучить, есть встроенная система тестирования (убедиться, что он все прочитал).

Внедрение системы позволило:

• предоставлять сотрудникам информацию, которая им действительно нужна;
• с помощью матрицы компетенций отслеживать наиболее “утекающие” (каких сотрудников нужно искать, нанимать).

Доклад 5: Как я 15 лет делал себе персональную Wiki для программиста

Тезисы

Оценка: 5/10

Конспект

Не конспектировала, потому что обедала вкусняшками, пропустила первые 15 мин. Техническое описание, как чел для себя велосипед изобретал. Но возможно кому-то будет полезно.

Доклад 6: Трудно быть Колей: теория и практика knowledge sharing в Lamoda

Тезисы

Оценка: 8/10

Что понравилось: рассказ про бедолагу Колю хорошо иллюстрирует, где ИТ-отдел спотыкался об необходимость обмена знаниями и документирования. Местами смешно и поучительно.

Чего не хватило: так и не поняла, как они смогли добиться, чтобы все было так замечтательно (error intended)

Технология: Smart Commits

Как проходит onboarding:

• знакомство с командной;
• используют Jira/Conflunce - список сотрудников, профиль команды, выполненные проекты;
• induction встреча - общие вопросы по компании, ее история, цели, к чему стремимся;
• tech onboarding - сколько сервисов (проектов), какой стек, как работаем с задачами, какие инструменты;
• field trip - работа в поле, экскурсии на производство (важно, если например программисту нужно разработать алгоритм построения оптимального маршрута по складу);
• первый коммит, обязательны формат: “#1234 (номер задачи) fixed max_limit_whatever”.

Deployment:

• есть отдельный проект - Deploy. На каждый Deploy релиз создается задача со списком задач, которые в релиз вошли;
• есть DeployFM - канал в телеграм, в который из задач транслируется: что установлено, куда (площадка), кто ответственный (трансляция автоматическая);
• есть календарь + проект RFC (request for change). Согласовывается деплой, изменения настроек. Фиксируются все проводимые работы (на 13.04 запланированы работы, изменения: такие-то). Все разработчики должны следить за календарем и проектом, чтобы понять, затрагивает ли это изменения их сервис.

Инциденты:

• если происходит инцидент, необходимо занести его в базу (проект в jira > incident > date+time) и описать решение. Если инцидент не занесен в базу, то в будущем при его повторении, опять придется тратить время на выяснения причин.

Кто пишет в Confluence:

• аналитики. Описания бизнес-процессов, функциональные требования;
• QA (тестировщики): описание тест-кейсов, описание функциональности (разобрался как работает - опиши). В оценку задачи всегда включено время на документирование;
• разработчики (чтобы не забыть).

Как мотивировать?

• разработчики обязательно пишут Test Notes - что поменялось по задаче, что еще вероятно нужно протестировать, кроме основного функционала;
• учет времени - всегда закладывается в ресурсах время на документирование;
• шаблон задачи: why (зачем мы это делаем), what (что надо сделать) и dod (definition of done) список пунктов, что задача решена. По важному новому функционалу задача не считается решенной, пока изменения не задокументированы;
• экономия времени (забудешь сейчас, потратишь время потом);
• ставятся задачи на документирование;
• если есть культура обмена знаниями - то остальными тоже хочется ими поделиться.

Доклад 7: Не хочешь мокнуть – плыви: добровольно-принудительный обмен знаниями

Тезисы

Оценка: 7/10

Что понравилось: про мотивацию, два подхода, хорошее заключение

Что зашло не очень: немножко противоречиво

В компании 350 QA и что с этим делать.

Обмен знаниями - катализатор развития. Решает проблемы:

• дублирование работы;
• изобретение велосипедов.

Два подхода к мотивации: демократический и диктаторский.

Демократический:

• новостная рассылка. О компании (новые сотрудники за 2 недели), о новых проектах, о технологиях в компании, об изменениях в процессах;
• внутренние конференции в форме кейс-завтрака. Один доклад по конкретной теме, могут прийти заинтересованные сотрудники. Помогает готовить докладчиков, распространяет знания, помогает делиться опытом между командами;
• демо по отделу. Например, переход на новый фремворк - показываем как делать, как работать. Формулируем проблему (1-2), которую надо решить, ищем заинтересованных;
• демократический подход: правильная атмосфера, прозрачны процесс. Минусы: время.

Диктаторский:

• дежурство по продукту (только для QA). На неделю тестировщик отправляется на тестирование другого проекта. Помогает развивать навыки, стимулирует обмен опытом между командами, новый человек в команде с незамыленным взглядом;
• планы развития. Выбираем компетенции для сотрудника. Компетенции связаны с командой (какие нужны для проекта/команды), ставим задачи по тренировке компетенции;
• игры - тесты, групповые опросы. Группа садится в кружок, тимлид задает вопросы по системе - отвечаешь неправильно - встаешь и продолжаешь стоять пока не ответишь правильно, ответил правильно - садишься. Помогает быстро закрепить и проверить знания в игровой форме.
• плюсы: прокачка команды, контроль. Минусы: демотивация, паранойя.

Общее для всех: база знаний:

• один вход - все знания, документы и заметки хранятся в ОДНОМ месте;
• фильтр и теги для супер удобного поиска;
• метрики (оцениваем что читают, что ищут, что надо добавить);
• регламент как работать: добавь описание, чего добавил, навесь теги;
• ведение документации - что-то изменилось - обнови запись в вики.

Результаты:

• ускорено внедрение новых решений и технологий;
• увеличено использование open source (перестали изобретать разнообразные существующие двухколесные и трехколесные транспортные средства);
• уменьшили парк технологий;
• рост компетенций.

Неожиданные результаты:

• горизонтальные переходы между командами сотрудников;
• кроссфункциональные команды (QA + разработчик в одном лице).

Доклад 8: Адаптационный чек-лист как инструмент мягкого введения в должность

Тезисы

Оценка: 5/10

Что не понравилось: очень много воды, повторение по пять раз одного и того же, скорее подойдет HR, мало собственно про знания

О чем: придумали и формализовали процесс онбоардинга новичков. Ну такое себе

Почему нужен onboarding:

• спрос на ИТ-специалистов велик, предложение падает (а то, все ж валят);
• сложно нанимать;
• цена сотрудника высока;
• стоимость ошибки еще выше.

Как это делается обычно:

• никак;
• портянки непонятных текстов;
• confluence (ну это там где-то пойди почитай);
• welcome-встреча;
• доки под запрос (о, это сходи спроси у Коли, он знает где)

Как они это это придумали:

• декомпозировали портянки (к сожалению, подробнее не рассказал);
• составили чек-лист с временными блоками: что нужно сделать, чтобы пройти испытательный срок, что нужно сделать, чтобы адаптировать сотрудника (условно 1) узнать где туалет 2) узнать как тут работают с гитом 3) получить логины пароли);
• даем наставника (это может быть руководитель или коллега);
• review встречи:
  • 1 неделя: личная оценка наставника/руководителя (aka задает вопросы, вроде шарит). На ревью обсуждаем установку: что сделать, чтобы пройти испытательный срок;
  • 2 неделя: фибдек подразделения, фидбек по задачам;
  • 1 мес.: движение к цели, текущее состояние дел, задач, процесса адаптации, фидбек от сотрудника;
  • 2 мес.: при необходимости предупреждения, отзывы фидбеки от других тимлидов;
  • 3 мес.: итог, формулируем цели на дальнейшую работу, обучение.

Если сотрудник работает хорошо, не забывать ХВАЛИТЬ.

Ну и дальше вода вода еще больше воды. Чуть не уснула.

Доклад 9: Естественное развитие: как перейти от e-learning к управлению знаниями

Тезисы | Оценка: 6/10 | Конспект Что понравилось: ответы на вопросы, основная идея.

Что могло бы быть лучше: слайды так себе, не хватает структуры, хотелось бы немножко живых примеров курсов.

E-learning - это электронные курсы. Это могут курсы для клиентов (пользователей) по продукту, а также внутренние курсы для обучения сотрудников (aka сделаем курс по ЕГИСу с котиками и тестированием!).

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

Делиться знаниями - это привычка.

Инструменты e-learning:

• делаем многоразовые курсы. Не дублируем существующие ресурсы. Не необходимости, дублировать информацию с сайта компании, дайте просто ссылку на сайт компании или продукта;
• story telling. Шаблон: была проблема, вот решение, вот как можно применить, а вот результат;
• курируемый контент: делимся полезными инструментами, best practice и ссылками.

Зачем нужны курсы? Для формирования практических навыков в первую очередь, и формирования системы понятий.

Курс, которым можно пользоваться постоянно:

• сам курс (видео, желательно с субтитрами);
• документация (практические, лабораторные);
• микробаза знаний (глоссарий, определения, ссылки, практики и т.д.).

Люди не любят СЛОЖНЫЕ решения. Делиться знаниями должно быть ПРОСТО (кинул ссылку боту в телеграм, вики в одном месте, единый вход, минимум телодвижений и переключения контекста). Нужен комфортный инструмент.

И мое любимое, ответ на вопрос про тенденции развития e-learning.

Основные направления:

• обучение;
• информирование;
• поддержка принятия решений.

Тенденции: предоставление информации в нужный момент и интеграция с бизнес процессами. Интеграция обучения в интерфейс приложений (чем больше становится информации, тем с меньшей охотой люди читают)

Пример 1 от гугла: вы летите в Амстердам на встречу с заказчиком. За сутки до этого гугл предложит список ресторанов, где можно провести встречу и как заказать столик, книгу как вести переговоры и еще несколько рекомендаций.

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