В самом конце апреля прошла первая конференция по Управлению знаниями в IT #KnowledgeConf. Работая в программном комитете конференции, я слушал предварительные прогоны большинства докладов, но на конференции все равно с большим интересом был на выступлениях, слушал то, что получилось в результате и писал заметки. А еще активно участвовал в обсуждениях. Вообще общение на конференции было очень активным, в фойе стояли большие круглые столы, за которыми непрерывно собирались различные компании и шло много интересных обсуждений.

Участников было достаточно много, особенно если учесть, что конференция - первая, а еще - что управление знаниями в подавляющем большинстве компаний не выделено как профессиональная специализация. И это накладывает свои ограничения, ведь люди обычно могут посещать конференции ограниченно, и надо понимать, почему тебе стоит участвовать именно в конференции по управлению знаниями, а не по основному профессиональному профилю. Но программный комитет не собирается прекращать работу между конференциями, и, я надеюсь, по управлению знаниями будет формироваться профессиональное сообщество в IT, так что я надеюсь, что в следующем году конференция будет еще более интересная и многолюдная, даст еще больше возможностей общения. Вообще я хочу отметить, что в программном комитете собрались интересные профессионалы, и я им очень благодарен за сотрудничество в совместной работе, работать в такой команде очень вдохновляет.

А в целом именно общение и есть суть участия в конференциях, потому возможность обсудить друг с другом профессиональные проблемы, задать вопросы докладчикам, среди которых много ведущих специалистов, которые давно и профессионально занимаются управлением знаниями. Отмечу, что это по управлению знаниями в IT конференция первая, а так управление знаниями - солидное и достаточно давнее направление деятельности, которое возникло примерно в 1980-х, когда запад задумался о том, как сохранять первенство, когда Китай скопирует все патенты, и придумали, что первенство будет за счет управления знаниями. И в России тема тоже не новая, ее в свое время принес в нефтянку BP, и дальше она распространялась по корпорациям, а с 2010 года проходит специализированная конференция KM Russia (о половине из них есть мои отчеты).

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

И можно читать отзывы других участников Родион Нагорном начал писать серию статей на Хабе о конференции, вот первая из них. Мария Мариничева, чей доклад я не смог послушать из-за конкуренции с другими, но который был очень интересен оставила свои впечатления. И, уверен, можно найти много других отзывов.

Пост на FB Алексей Сидорин (Alexey Sidorin). Холистическое управление знаниями в IТ-компании. Начало - видео тизер из игры престолов: "Знание это сила - Нет, власть это сила". В мире есть две экономики: экономика ресурсов и экономика знаний. Каждая компания, руководство выбирает экономику компании. Но снизу тоже возможно, просто тогда надо говорить с руководством на языке ресурсов.

А дальше был достаточно плотный рассказ про устройство управления знаниями, из которого у меня отдельные фрагменты и афоризмы.

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

• Самая частая точка - поиск ответа на вопрос в call-центре
• Создание актива из знаний в ответ на потребность
• Случайные точки - инсайты, неожиданные озарения. И именно там возникают самые эффективные знания. Никто не знает, как там хорошо управлять, но можно создавать условия.

Эффекты разнообразны. Двойная работа: не только не делать работу второй раз, но главное - не повторять ошибки. Когда не знаем, в какую папку положить документ - не кладем никуда.

Много схем. Про инструменты: горизонтальные связи, тиражирование знаний, координация усилий - внутри темы. Про методологии. Три слоя: методологический, культурный, технический и стандартная конструкция as is, to be, action plan по каждой из них.

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

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

От топового сейла: "Когда меня посылают базу знаний я думаю, что меня посылают нах." Это - нормально, с этим надо работать. Сначала посылаешь материалы и ссылки, потом - просто ссылки, на третий раз он сам ищет...

И множество подробностей. Баллы капают от каждого действия - компания замечает все твои маленькие дела. Группа создается быстро, по шаблону, доступность, включая внешние группы. Сообщество должно создаваться несколько секунд. Через сообщества создается вся система наших знаний. И на этом построена система управления знаниями. Вокруг каждой системы - сообщество, и все вынесено на общую плашку контентов. Запомни место на парковке: блютуф-датчик на каждом этаже, запоминает, где ты вышел, и это можно спросить у бота. Боты для бронирования переговорок, заказать пропуск и многое другое, и это - дешевая технология, которая очень много задач вносит в одну систему. Это нельзя оценить, но это очень много процессов поменяло и облегчило жизнь.

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

Поиск нельзя купить из коробки, поиск - это процесс, его надо постоянно поддерживать, подключать новые источники, индексы и так далее. Но! Поиск может дать много знаний. В том числе - анализ, что ищут и не могут найти и так далее. Они пробовали еще расширить - машинное обучение, графы и онтологии, поисковый ассистент - но эксперименты не взлетели.

Как это работает. Самая простая обратная связь - в любой момент можно поставить отзыв. Узнали, что у многих проессов нет ответственного, например у процесса согласования договора. CROGartner. Квадранты: заплатки, ждем перемен, хороший инструмент, ключевые системы. Важность против качества. onboarding: повесили кнопку "нажми ее, когда готов работать" - замерили, выяснив много интересного и точек улучшения.

После проекта - раздай 3 конфетки людям в команде. Через это выявляют, кто реально вытягивает активности.

На главной странице показывается портрет - и надо указать имя или департамент.

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

Итоги. Если бы писал систему знаний, то были бы следующий блоки

• профиль
• лендинг-платформа - быстрые странички создавать внутри
• совместная работа над документами, она там же
• многофункциональные сообщества
• нематериальная мотивация
• система аналитики
• поиск

Они используют Jive, сервер web-приложений вокруг громадное количество, Вокруг - CRM, Jira, Confluence (он не умер!), elastic, боты и многое другое.

Диаграмма у координатах объем-сложность. Там большой сегмент shadow-IT - большое количество поделок между ручной работой и корпоративными системами. Это - огромный источник инноваций, не хотите внешний doodle - сделайте внутренний и так далее.

И заключение про культуру управления знаниями, парадоксальное.УЗ:

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

Пост на FB Александра Куликова (Aleksandra Kulikova). Инкубатор разработчиков в Skyeng. Зачем мы наняли целый отдел джуниоров? Ответ парадоксален. Вовсе не для того, чтобы было кому делать легкие задачи - их успешно делал аутсорс. А проблема была в том, чтобы внутри компании растить тимлидов, прокачивать софтскилы разработчиков, которые этого хотят. Им для этого нужен материал, и они наняли отдел джунов. А джуны нужны не как рабочая сила, а как будущие сотрудники. Получается сложная многовекторная конструкция, из отдела джунов, которые выполняют реальные боевые задачи, только простые, технических менторов, которые прокачиваются в тимлидов, тьютора из T&D, которые этих менторов тренирует, объясняет, как давать обратную связь, HR занятого наймом и оценкой роста джунов и готовности к переходу в основные команды, и проджекта, которые организует процессы... И метрики по каждому векторов - рост тимлидов из менторов, выход джунов в основные команду, и эффективность решения задач не ниже, чем у аутсорсеров.

Меня в докладе вдохновляет способность собрать такую сложную конструкцию и гибко перестраивать, адаптировать по опыту функционирования.

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

Траектория джуна. Принцип - обучение на боевых задачах. 70% времени - именно выполнение задач. И важно подобрать задачи, которые подходят и развивающие - это проджект и ментор делают. Обучающий материал джунам тоже выдается кусочками, под задачи, а не большими партиями.

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

В целом. Понятные ожидания на входе; регулярные структурные фидбеки; мотивация - переход в основную команду

Комментарии в посте.

Роман Клин А экономический эффект то считали? много месяцев оплачивать труд целого отдела с заведомо пониженной эффективностью, чтобы вырастить несколько middle-ов и нескольких тимлидов?

Vladimir Fedorov Ага. Интересно было бы увидеть цифры: сколько стоит такой "университет" vs стоимость хэдхантинга спеца на рынке (включая косты на поиск, собеседования, адаптацию и риск слиться)

Evgenii Parfenov Vladimir Fedorov И не убегут ли они потом туда, где платить смогут больше, так как на этот университет не потратились. Вечный вопрос...

Максим Цепков Экономический эффект, конечно, считали - как это принято в современных компаниях. На этот отдел перенаправлено решение простых задач, которые раньше шли фрилансерам, и одной из метрик - стоимость решения задач не ниже, чем у фрилансеров.

А второе назначение - подготовка новых сотрудников для команд. До этого они ставили на найм senior, и по их оценкам рынок персонала практически исчерпан, или сильно ограничивает возможности роста для компании. Включать джунов или мидлов с рынка в продуктовые команды они не готовы, потому что это потребует существенной перестройки сложившейся командной работы. И они таким образом преодолевают ограничение рынка персонала, получая при этом готовых специалистов.

Ирина Гертовская Меня несколько смутило, что в периоды снижения резюме на рынке снижается и планка критериев отбора. Чтобы внутренние сотрудники не простаивали. Это может привести к снижению эффективности обучения и потере цели. Все же тим-лидов хотим выращивать. Вот смотрели ли на результат обучения по группам в таком разрезе? Я бы посмотрела. И если результат не хуже, то может и не стоит тратится на более жёсткий отбор? Для меня это не риторические вопросы. Мы тоже берём практически выпускников вузов и выращиваем из них.

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

Пост на FB Денис Волков (Denis Volkov). Обучение и подготовка специалистов в сфере управления знаниями: чему и как учить будущих и настоящих knowledge workers? Знания - результат разрешений когнитивного диссонанса. И еще: если мы меняемся яблоками, то у каждого остается по одному. А если обмениваетесь идеями - то будет две идеи.

Вообще забежал в конце доклада, потому что вопрос выбора треков на этой конференции не прост. Так что подробного конспекта не будет. В конце был маленький совет, тоже изложенный через историю. В Древнем Риме жизнь была на форуме у фонтана. Сейчас в компаниях новый фонтан - это кулер. У него будут меняться сплетнями, а если повесить доску, да еще с провоцирующим контентом - то будут обмениваться знаниями.

Пост на FB Tatiana Gavrilova. Как из менеджера сделать аналитика: опыт подготовки инженеров по знаниям. Множество афоризмов и метких замечаний и широкое содержание доклада.

Знания надо добыть, их не существует. Если у вас есть инструкция - там нет знаний, они растворены в бессмысленных словах. А инструкции вообще пишут для шпионов.

Пониматель старается понять ваш мессадж, а обычный человек - натягивает на свой каркас "это я знаю".

Самое сложное - извлечение из живого эксперта. Из техник - легче. А так - интервью, аналитика, расшифровка. Поле знаний, визуализация, а дальше - к программистам.

Самое страшное, когда программисты выступают как аналитики. Потому что программист сделает не как хочет клиент, а так как надо.

Классификация диаграмм визуализация знаний. Не сотни, но 7 штук полезно. Онтологии предметной области. Иерархические, языки описания онтологий. Но не все хорошо онтологизируется, есть жесткие и мягкие предметные области. Для онтологий есть специальные языки и традиция, и можно публиковать, share онтологий.

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

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

Коммуникативные и аналитические способности редко уживаются. Но нужны оба, или надо работать парой.

А самая важная характеристика - отсутствие обороны, аналитик не ждет удара, открыт - и в ответ открывается эксперт. Редкое качество.

Мужчинам надо писать или рисовать, говорить бессмысленно. Зато у них больше интерес к новым решениям. А женщины многостороннее охватывают проблему.

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

История. Тренинг, потом люди ушли внедрять, через 3 месяца вопрос: "Как внедряете?" - "Хорошо внедряем, но троих пришлось уволить - дураки оказались..."

Learning by doing, попробовать руками.

Много вопросов - как узнать склонность к аналитической работе, у себя или ребенка? Ответ очень интересен: у тестов нет прогностической силы, это диагноз. Смотрите, чем занимаетесь, как именно. Через поведение.

Пост на FB Никита Соболев. Как учить программистов в 21 веке. Интересная завязка доклада - от лица основателя компании. Когда ты начинаешь, ты работаешь с плохими, случайными проектами, с плохими и случайными заказчиками, со случайными людьми - не получается выбирать. И ты пишешь плохой код, который ненавидишь. И ты бы ушел из этой компании, если бы это не было твоя компания.

И тут ты оглядываешься вокруг, вдруг это у тебя все плохо, а у остальных хорошо? Это не так, вся индустрия в огне

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

Улетел баг в прод, упал сервис на 12М - тебя максимум уволят - и что, пойдешь в другую компанию. Ваш продукт - еще один этап их пути. Можно пройти быстрее или задержаться. Есть программисты по призванию, а есть - за деньги.

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

Но, к сожалению, на вопрос, вынесенный в заголовок доклада это не отвечает, если, конечно, не относить к программистам тех, кто максимум что может - сделать типовую 4-часовую задачу.

Пост на FB Екатерина Гудкова. Разработка базы знаний компании, которой действительно пользуются. Рассказ начался с первых разочарований: чем больше загружали в базу, тем меньше читали :) А дальше был рассказ, как решали эту проблему, создавали действительно востребованную базу знаний.

Модель ролевого управления сотрудниками - скелет. Роли - Типовые задачи - Компетенции - Материалы базы знаний. Система тэгов, связанная с ролями, ими размечают внутренние и внешние статьи, идет подписка на новости. Типовые задачи базы знаний по разным этапам lifecycle сотрудника от onboarding - опытный - уход из компании.

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

Пост на FB Григорий Петров (Grigory Petrov). Как я 15 лет делал себе персональную Wiki для программиста. Доклад про то, как Григорий ведет собственную базу знаний, и для этого развивает собственную вики-разметку xi для компактного и цветного представления знаний. Рассказ был про структурирование знаний и статей, в том числе в случаях невнятной структурировании через привязку ссылками, а не позиционирование в сложном оглавлении, и про свою разметку, которая превращает текст в некоторую размеченную и расцвеченную структурную информацию. Для расцветке сделал собственную цветную схему, так как стандартные имеют слишком мало цветов. Хранение всего этого - в Visual Studio, расцветка, переход по словам и поиск ее средствами, хранение в git. Картинки и таблицы - на google drive и google sheet, а не внутри.

Начинаем с одного файла, куда складываем параграфы. Далее их несколько десятков - пишем заголовки. Потом часть уезжает в статьи. И финальный шаг - статья состоит только из ссылок. Тэги - это оглавления и группирующие статьи. И достаточно делать группирующие статьи, не надо тэгировать. Поиск - работает поиск visual studio по именам и контенту, которые опознается как ключевые слова. Более 5000 файлов. Поиск - быстрый.

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

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

В ответах на вопросы. Записывает и по нейрофизиологии, и по изучению иностранных языков, но фокус разметки - на профессиональные записи программиста - языки, api и многое другое, что нужно именно разработчику. Компактный inline-код, специальный синтаксис записи параметров и т.п.

Пост на FB Прапион Медведева (Prapion Medvedeva). Моделируй в любом контексте. Если у вас фейл повторяется более двух раз, то моделирования недостаточно

Люди делают инструкцию только после неоднократных фейлов. Люди делают uml модели без цели, потому что так принято "деды так делали".

Дальше были кейсы из зала для обсуждения, достаточно интересные. Собеседование - в сжатое время надо смоделировать человека в компании - чтобы проверить, приживется ли. Декомпозиция: вот как декомпозировать процесс анимации (анимационная студия), надо ли декомпозировать вообще? Есть набор деятельности, который неплохо бы сделать, но никто не назначен и деятельность не делается. Все говорят "давайте", но никто не делает - какая модель тут поможет. Как моделировать стихийные вещи, чтобы решить, что можно отпустить на самотек, не для себя, а для команды?

Модель. Что это такое? Это упрощение и замещение объекта. Важно: модель предсказывает что-нибудь и строится для ответа на вопрос. Очень часто строят модели, не ставя вопроса и модели - бесполезны.

При построении модели люди выделяют объекты из фона. Разные стейкхолдеры выделяют разные объекты, и еще есть задача состояния модели.

"Работает не трогай" - хорошо или плохо? Если там нет магии, то все в порядке, а вот если мы не знаем, какая там магия, то там может сломаться.

Не моделировать, а делать "как попало" - иногда хорошая стратегия, особенно в маленьких командах. В контексте фразы было, что в некоторых случаях построение относительно точной модели - дорого, проще работать методом проб и ошибок или проб и находок - как получится.

Чек лист do and check. Универсальное построение модели.

1. Зачем. На какой вопрос будет отвечать модель.

1.1. Степень формальности: слова на естественном языке, схема, модель в Excel ... Выбор после зачем

1.2. Есть ли уже примеры или шаблоны моделирования, у нас или у кого-то, надо погуглить.

1.3. Вид представления результата: да/нет, число, ощущение у пользователя...

1.4. Поддержка актуальности (ресурсы), интерактивность модели, версионирование

1.5. Кто обновляет - вы или пользователи. Постоянное взаимодействие или срез на момент.

1.6. Чем наполняем модель, достаточно ли данных, знаний, мудрости?

2. Взять кусок реальности, упростить как можем и засунуть в формат, который нужен. Какие есть штуки?

2.1. Какие объекты. Надо дотыкаться до физических объектов, иначе коммуникация не получается. Объекты должны быть, даже если это сложно. И как объекты взаимодействуют между собой (пользователи запускают программы).

2.2. Объединение в классы. Правильно, чтобы было 5+-2 объекта на каждом уровне, иначе мозг не сможет работать. Классификацию надо делать по взаимодействию с объектами, а не по структуре внутри объектов.

Модель встречи. Объекты - не только люди, с которыми встреча, но и дела, о которых мы говорим. И еще про выделение: программист и дизайнер по-разному видят систему: программисты про функции, а дизайнеры про шрифт. Фича для каждого по-разному.

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

Компонента про стейкхолдеров присутствует в любой модели.

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

3. Время (актуальность, изменения) и внешние связи (связь с соседями и метамодель для всех моделей). Это - общий алгоритм. По конкретным задачам есть алгоритмы построения моделей. А обобщенного алгоритма, хорошего - нет. Она пытается захватить.

Модель кофейня. Есть основатель, который варит кофе. Решает научить сотрудника, сотрудник делает все не так, его увольняют. Основатель страдает. Дальше нанимает онтолога, он описывает объекты и процессы. И главное - процесс, что надо делать, чтобы покупатель был доволен. Иногда получается хорошо, иногда плохо, потому что далеко не всегда описывают что нужно.

Глобальный кейс. Сотрудник приходит, действует по инструкции - и все плохо. Просто дописать по месту - не помогает. Потому что предыдущий сотрудник не только делал по инструкции, но и представлял место того, что он делал в контексте компании. И надо нанять опытного консультанта, который как раз восстановит этот глобальный контекст, и допишет, исходя из этого, ключевые слова в инструкции.