Как организовывать Knowledge Sharing внутрь и наружу

[rzerda]

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

ИТ про людей, а не про языки программирования.

[cheaffa]

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

[yakimchuk-ry]

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

Из статьи вижу, что разложены по полочкам степени осознания компетенции (удобно, не знал, спасибо). Были даны ответы на все вопросы по списку (в чём проблема и результат каждой из сторон), и сразу идет решение "Как мы решили эту проблему?" (в примере про Helpdesk), без описания ПОЧЕМУ вы так сделали.

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

Поэтому, не понятно:

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

   
   

2. Какие еще были варианты решения задачи? Почему это выбрано верным решением, есть аналитика по другим вариантам? Например, почему не используется база знаний (особенно учитывая 300 человек из примера), ведь так знания будут откладываться в единой системе, и доступны всем работникам, и в любом время, а не только на лекции. Поэтому, какие еще варианты решения вы рассматривали?

   
   

Статья оказалась полезной, спасибо.

[cheaffa]

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

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

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

2) Разумеется, есть ветвистая база знаний в Confluence, которая поддерживается и пополняется, об этом много рассказывает Саша Афёнов с докладе «Техническая ипотека: что и кому должен тимлид» youtu.be/D5euegEMjVc. Все лекции транслируются и записываются, если представляют ценность не только в моменте, но и будут актуальны спустя несколько месяцев.

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