​​Какие знания бывают в ИТ проектах?

Одна из самых известных классификаций знаний делит его на:
- Явное - Explicit (формализованное знание, которое хранится в известном всем месте)
- Неявное - Tacit (неформализованный, интуитивный персональный опыт). Неявное знание не всегда можно даже артикулировать, сформулировать, иногда оно носит интуитивный характер, а иногда и вовсе - субъективный.

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

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

Фрагменты знаний, которые подлежат передаче называют артефактами или предметами, knowledge item. Это теоретическое понимание или навык по поводу какого-то процесса или явления.

Существует также понятие knowledge asset - он включает в себя несколько предметов, это может быть документ, ряд документов, case-study, исследование, лекция, материалы воркшопа и т.д. Обычно это то, что мы и называем внутренней или внешней документацией к системе.

О процессах перехода между этими видами поговорим в следующих постах.

Линус Торвальдс, который уходил в творческий отпуск, чтобы подумать о своих порой резких высказываниях относительно разработчиков сообщества и их ошибок - вернулся к разработке ядра Linux! И не один, а с идеей введения мягкого кодекса поведения в сообществе опен-сорс разработчиков. Ну вот, а в прошлый его отпуск мы получили Git. О возвращении Торвальдса рассказал Грег Кроа-Хартман в анонсе релиза ядра 4.19.

Теперь кодекс разработчиков Linux учитывает принципы другого, более широко распространенного свода правил поведения в опенсорсных сообществах Contributor Covenant.
Вообще, тема очень интересная, являются ли правила и конвенции поведения, общения и формулировки мыслей частью знаний об айти-проекте? Мне кажется, вполне может, ведь коррректная и конструктивная коммуникация вокруг задач, принятая в сообществе, влияет на продуктивность. Особенно это важно для опен-сорс сообществ, куда добровольно присоединяются новые и новые люди.

Оригинальное сообщение в анонсе релиза ядра: https://lwn.net/Articles/769110/

​​Делюсь лекцией Евгении Голевой о Knowledge Sharing в компании Lamoda.

Евгения рассказала несколько кейсов из реальной практики Ламоды, когда им приходилось обучать внутренних сотрудников, смежные команды или заказчиков их логистических систем.
Она занимается как содержанием, так и форматом обучения.
Каждый кейс рассмотрен с точки зрения – проблема (зачем обучение тому, что его будет проводить, что это сэкономит для него), результат (что изменится по его окончании – вопросы только по адресу, экономия времени поддержки, правильное использование решения и т.д.), задача, выбор ЦА (кто пользуется и принимает решения) и их проблемы и уровень, его определяют по классическому квадрату компетентности.

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

Эгоизма пост: делюсь моим выступлением на митапе WriteTheDocs в Москве, рассказываю про технику матрицы компетенций для управления знаниями (теперь с правильной ссылкой) https://www.youtube.com/watch?v=iQMFVTOo7Ug

​​Окно Джохари: переосмысление

Возьмем такую старинную технику, как окно Джохари. Его придумали в 1955 году психологи Джозеф Лафт и Харри Ингам в середине 20 века для самопознания, а не для оценки структуры знаний человека. Эту матрицу часть приводят без названия или называют моделью осознанной компетентности. На осях матрицы находятся знание и осознанность.

В результате получается четыре области: неосознанное незнание (не знаю, чего не знаю), осознанное незнание (знаю, что не знаю), осознанное знание (то, что обычно называют знанием) и неосознанное знание (усвоенный опыт, применяемый на автомате).

Попробуем переосмыслить это «старье» на опыт обучения сотрудников в IT компаниях.

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

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

Самую большую ценность представляет правый верхний квадрат, знания, которыми обладают опытные и ценные сотрудники, а в идеале – которые содержатся в базе знаний. Эта категория может обучать других, это Subject Matter Experts.

Какие есть способы перехода из одной области в другую?
Из неосознанного незнания в осознанное незнание можно перейти или из большого интереса к предмету (захватило, захотелось разобраться) или, если перед тобой встала какая-то проблема, чтобы ее решить, нужно освоить новый навык.

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

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

А какие у вас в компании есть категории знаний и навыков в каждой категории?

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

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

​​Сколько компании теряют на неэффективном управлении знаниями

Мне на глаза попал отчет компании Panopto — Workplace Knowledge and Productivity Report 2018.

Это результаты опроса более чем 1001 американских работодателей, которые рассказали о том, какие проблемы испытывают с передачей знаний и их утерей.

Отчет очень масштабный, поэтому поделюсь короткими выводами, которые привлекли мое внимание:
- 42 процента опрошенных признались, что обладают уникальными, нигде не зафиксированными знаниями
- Сложнее всего заменить знания, полученные в результате профессионального опыта
- 81 процент опрошенных расстроен тем, что в компании есть уникальные знания, которыми с ними не делятся
- 35 процентов признались, что иногда им сложно получить информацию, нужную для работы, 18 процентов сказали, что это очень сложно
- Если сопоставить данные предыдущего вопроса с оборотом компании, то у компаний, где сотрудникам сложнее получить знания, он ниже
- Среднее время онбординга и обучения в компаниях – менее 2,5 месяцев, все хотят, чтобы сотрудники как можно скорее начали работать, в 29 процентах компаний это время и вовсе составляет менее месяца
- Среднее время реальной адаптации – 6,5 месяцев
- Среднее время, которое новичок проводит в поиске ответов на вопросы в неделю – 12,7 часа, это 50 часов в первый месяц работы
- 28 часов в неделю у новичка занимает неэффективная работа, 5 часов в неделю занимает ожидание получения знаний, эксперты делятся ими не сразу
- 70 процентов опрошенных согласились, что уход сотрудников сопряжен с утерей уникальных знаний, которые невозможно заменить или восстановить

Авторы отчета даже подсчитали потенциальную экономию от более эффективного обмена знаниями:

Для компании с 17,7 тысячами сотрудников и средней заработной платой в 47 долларов в час она составит 42,5 миллиона в год, для компаний с 1000 сотрудников – 2,4 миллиона в год. Более эффективный онбординг новичков позволит компании с 17.7 тысячами сотрудников экономить еще 4,5 миллиона долларов ежегодно.

Подсчеты основаны на периодах простоя и неэффективной работы сотрудников.

Если вы давно думаете, как начать обучать разработчиков внутрь и наружу, послушайте последний выпуск подкаста Frontend Weekend, Иван Ботанов, старший фронтенд-разработчик в Tinkoff.ru рассказывает, как и зачем начать записывать курсы, как он планирует уроки для разработчиков и есть ли смысл в приглашенных офлайн преподавателях внутри компании

Слушать на SoundCloud https://soundcloud.com/frontend-weekend/fw-76

#рекомендации KM Talks - канал в Youtube, в котором автор, Владимир Лещенко, беседует с признанными экспертами в управлении знаниями, обычно это практики из технологических и производственных компаний (Oracle, Росатом, КРОК), аналитики, тренеры и даже юристы в области интеллектуальной собственности, ведь знания компаний зачастую попадают и под юридическую и патентную защиту

Ссылка на канал: https://www.youtube.com/user/Leshenko82/featured

#события Завтра на конференции для разработчиков высоконагруженных систем highload++ я проведу митап Управление знаниями по принципам DevOps.

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

http://www.highload.ru/moscow/2018/meetups

Делюсь конспектом и слайдами с митапа Управление знаниями по принципам DevOps, очень продуктивная дискуссия получилась

https://gist.github.com/lananovikova10/1e19e169d7365b958b7a4d15491a6b00

​​Что делать, если в команде проекта 5-10 человек, а тяжеловесные вики не подходят или слишком дороги? Notion is the answer!

Для небольших команд, которым не нужна поддержка макросов, сложной разметки, сложного разграничения прав, хорошо подойдет Notion, это сервис (веб-сайт и приложение) для организации контента и совместной работы. У Notion есть бизнес-режим, можно создавать проектные workspaces, вести роадмап, agile-борды, календари, списки задач, хранить полезную информацию, причем он поддерживает все нужные виды контента: текст, таблицы, изображения, мокапы интерфейсов, заметки, списки и другое.

У пользователя есть полная свобода в перетаскивании блоков на страницах и перетаскивании самих страниц в иерархии. Блок — ключевой элемент архитектуры Notion, он может принимать любую форму. Также доступны готовые шаблоны страниц, например, Vision, Coding Guidelines, Employee Onboarding, Team Home, Blog Post, Design Spec, Editorial Calendar, даже CRM.

Ограничения и минусы

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

Нет интеграции с таск-трекерами, например, JIRA.

Плюсы

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

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

Бесплатный план предлагает 1000 блоков для пользования. Это довольно много, но если переводить абслютно все проектные знания и процесс, может и не хватить. Командные планы предлагают платить по 8 долларов за человека в месяц. Индивидуальный тариф вдвое дешевле и стоит 4 доллара в месяц.

Evernote обходится дороже, к тому же, он скореезаметочник, а Notion — приложение для совместной работы с поддержкой большего числа типов контента. Другие альтернативы — Google Docs, Trello, Realtimeboard, Notion как бы пытается совместить их все с определенным успехом.

Мы используем Notion даже для домашнего планирования, получется этакая домашняя база знаний с нужными номерами телефонов, планами на месяц, списками задач, семья — это ведь тоже небольшая проектная команда. К посту прилагается фото нашей домашней инсталляции Notion.

​​Долг компетенций

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

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

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

Уход специалиста сразу превращает такой код в "legacy", "not invented here", "to rewrite", "так исторически сложилось" и прочие штампы. Усложняется поддержка и, как правило, ухудшается точность декомпозиции задач при работе с таким кодом, поскольку не влезая в детали сложно оценить реальный объем изменений.

К посту прикреплена иллюстрация типичного долга компенетций, где есть пересекающееся знание, а есть уникальное, с bus фактором – 1. Долг компетенций растет тем быстрее, чем чаще вы вносите изменения в код базу и чем меньше у вас общего кода и библиотек, которыми пользуется большинство в команде.

Что снижает долг компетенций

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

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

Еще одна хорошая практика – фиксировать принятые архитектурные и технические решения с небольшим обоснованием, даже если они приняты на митинге или во время разговора на кухне.

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

Еще по теме
http://www.leanway.no/a-deeper-look-at-competence-debt/
http://www.julianbrowne.com/article/competence-debt

​​OneBar — стартап, который предлагает создавать базу знаний вашей команды с помощью парсинга разговоров в Slack

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

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

Что предлагает OneBar — решение подключается к Slack API, парсит разговоры разработчиков, ищет в них вопросы и ответы на них и создает подобие внутреннего StackOverflow. Затем, при наличии информации бот также сможет рекомендовать экспертов в том или ином вопросе, встревать в разговор и предлагать ссылки на схожие ответы со словами "возможно, вы ищете это".

Если у ответа нет вопроса, бот его сохранит, чтобы кто-то мог на него ответить.

Бот использует Natural Language Processing, он умеет выделять в тексте сущности и группировать их по темам.

Сервис написан на Python и JavaScript, поисковый индекс на Elastic, используется API Slack и Google. Есть планы посмотреть в сторону Телеграм, но на практике — Slack самый популярный айтишный мессенджер, поэтому было принято решение сосредоточиться на нем.

Монетизировать сервис разработчики планируют не по количеству пользователей, а по вкладу в базу знаний, то есть по числу созданных ботом ответов на вопросы (100, 1000 и более 1000).

Звучит завязка сервиса интересно, знаю, что многие компании делают подобные внутренние StackOverflow своими силами, поэтому вопрос, стоит ли игра свеч?

На Лайфхакер вышла статья про разные стили познания.

Почитать ее можно тут: https://lifehacker.ru/stili-obucheniya/

Она основана на цикле Колба, который описал стадии познания - получение опыта, осмысление, размышление и применение на практике, и основанные на них стили усвоения новых знаний и умений.

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

Видео от Linkedin о пользе качественного онбординга сотрудников, оно конечно в стиле "розовые пони и радуга", там слишком много обнимашек на квадратный метр, но суть отражена хорошо, как в неплохой социальной рекламе.

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

Смотреть: https://vimeo.com/156754695

​​Как считать/выявлять bus factor на проекте

Все говорят про фактор автобуса, фактор грузовичка или фактор кирпича, — это число разработчиков, инженеров на проекте, которые могут попасть под автобус/грузовик/кирпич, в результате чего проект остановится.

Проще – это мера сосредоточения информации о системе, проекте. Самый критический фактор автобуса — это единица.

Термин, конечно, не новый, он появился в сфере управления бизнесом еще в 1998 году.

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

Как посчитать фактор автобуса? Представим, у вас есть 30 человек на проекте, который занимается веб-разработкой, в нем есть API, фронтенд и дизайн, без деталей. 5 человек разрабатывают API, 10 – фронтенд и еще 5 занимаются дизайном, ваш фактор автобуса – 5.

Потенциальные сигналы о наличии фактора автобуса:

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

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

- CI/CD на проекте настраивал один человек, все просят его добавить, изменить pipeline, но никто не вдается в детали.

- У вас есть давно закомментированные куски кода без понимания, почему это так и в каких ситуациях из нельзя ни в коем случае раскомментировать.

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

Можно ли выявить его автоматически?

Да, но это будет только диагностика, более глубоко придется копать тимлиду вручную. Например, вот такой тул есть для Git/HG репозиториев, он позволяет найти файлы, где основным контрибьютором по строкам кода является один человек.

В дополнение
Также советую посмотреть выступление Артема Быковца Bus Factor и риски его игнорирования.

​​Кому в организации подчиняется специалист по управлению знаниями

Далеко не во всех организациях есть выделенный специалист или отдел по управлению знаниями, эту роль исполняют тимлиды, техписатели, менеджеры проектов, HR, но если он есть, то кому подчиняется?

APQC провела исследование среди 317 компаний и сделала инфографику по итогам. В 30 процентах компаний специалист или отдел по управлению знаниями подчинается напрямую высшему руководству, в 16 процентах - входит в подразделение по обучению и развитию, в 15 - отделу по управлению персоналом.

Когда специалист или отдел по УЗ подчинается напрямую руководству компании, он работает эффективнее, получает большую поддержку и понимание и проще получает необходимый бюджет. Кроме того, само управление знаниями получает больший вес и становится частью статегических приоритетов. Это, можно сказать, common sense.

Делюсь с вами ставшим очень полезным для меня материалом об адаптации новых сотрудников в компании "Флант"

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

Его написал Игорь Цупко, чей канал @lovely_it_hell я неистово рекомендую всем, кто занимется налаживанием процессов и управлением хотя бы одним разработчиком.

Ссылка: https://habr.com/company/flant/blog/419051/

Продолжаем неделю онбординга на канале, теперь на очереди материал от Avito о том, как новички проводят первые недели в компании

В статье написано про основные внутренние инструменты,welcome-тренинги, процесс Performance Review, тьюторинг и так далее.

Ccылка: https://habr.com/company/avito/blog/427837/