Как вам определение управления знаниями от ЛУКОЙЛа?)  - это про коммуникации для инноваций и устранения рисков, а не про доки :)

Мне - нормально.)))

Структура невидима. Это способ обобщения и является новым знанием. Т.А.Гаврилова

Друзья, на профильных конференциях очень много говорится о том, что нужно создавать в компании соответствующую культуру, но очень мало говорится о том, что, собственно, в это понятие входит. У нас в ПК KnowledgeConf на эту тему тоже регулярно происходит обмен мнениями. На картинке то, что под культурой подразумевается в МАГАТЭ. Что-то мне подсказывает, что список не полный :) как вы считаете, что же должно быть в культуре компании, чтобы в ней хорошо работало управление знаниями?

На заре моей карьеры я работал в компании где все книжки прятались под стол, никто ничего “не знает”, “настоящий специалист разберется во всем сам”  и т.п.
Причина:  job security, поощрение руководством конкуренции между сотрудниками.
Нужна культура сотрудничества, взаимопомощи, чтобы не было боязни раскрывать знания.

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

Я, <фио>, прошу уволить меня в связи с некомпетентностью в связи с допущением следующего инцидента:
(подробное описание шагов и фатального результата)

Меритократия это называется - всё уважение тому, кто самый умеющий.
В любой бирюзовой прекрасной компании будущего правит именно она.

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

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

А как при такой политике узнать о случившихся ошибках во всех деталях?) чтобы больше никто не допускал

Это ведь ирония? :)

Истессна

Не везде 🤷‍♂️

Онбординга пост
В субботу днём буду на DevOpsDays, общаться про технологический онбординг.

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

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

Окей, в теории всё просто: чек-листы, наставничество, парное программирование, ревью, записанные видео и статьи - но что из этого действительно работает на практике и почему? А что - не работает?

Я, например, пробовал организовывать в командах учебные задачи для новичков в рамках "курса молодого бойца". Идея казалась прекрасной: снять нагрузку с тимлида, чтобы инженер в "учебных", "лайтовых" условиях мог освоить базовые вещи и затем идти в одну из команд и доучиваться "в бою".
Но на практике:
а) снятие нагрузки с тимлидов оказалось порочной затеей, так как они полностью отстранились и стали рассчитывать на чудо, не желая даже участвовать в детализации курса;
б) базовые, фундаментальные вещи и приёмы в разных командах оказались разными. И команды отстранялись от попыток их синхронизировать.
в) оказалось, что курса молодого бойца даже в одну неделю не хватает на ощутимый результат: объём информации и знаний слишком большой. А тащить человека дольше без погружения в реальную практику выглядело полным бредом.

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

Не хочется превращать пост в простыню. Лучше поделимся своей болью интерактивно на митапе в субботу или в канале @KnowledgeConfChannel.

Присоединюсь к Игорю и тоже буду пиарить DevOpsDays Moscow :) Буду рассказывать там про управление знаниями в ИТ, выгодах, задачах, практических инструментах и основных блокерах. А также о том, как управление знаниями вообще пересекается с DevOps (да, пересекается), какие у нас общие боли, и что нам в ИТ нужно понять, чтобы осознать всю важность системной работы со знаниями в командах и компаниях. https://www.facebook.com/devopsdaysmoscow/photos/a.1751435085178258/2463468803974879/ До встречи в субботу!

https://vc.ru/dev/96077-jetbrains-predstavila-servis-dlya-komandnoy-razrabotki-s-chatami-i-planirovshchikom

Интересная штука

о) это прям огонь) подтягивать всю инфу, связанную с задачей или потенциально полезную - это прям сильно) Думаю, будет иметь успех)

Они в целом ничего нового не изобрели. Уже есть Team Foundation Server и Atlassian Stack, которые решают похожий круг задач.

отечественные корни = отечественный рынок.