«Давайте сделаем внутреннюю википедию, все будут ее изучать и развиваться», – говорят менеджеры, а потом грустят, что никто в компании ничего не читает и не развивается. А все потому, что каждому вопросу – свой формат.
Чем больше опыт у компании, тем выше в ней порог входа для новичка, даже если он классный специалист. Да что там новички, при большом проектном опыте не все сотрудники успевают следить за обновлениями в уже существующей системе. К тому же, неизбежно происходит уход разных экспертов, и это не должно быть ударом для всей команды.
Без обмена знаниями команда в лучшем случае растет медленно, в худшем – топчется на месте или деградирует. И какой руководитель будет этому рад? Поэтому создание общего поля для обмена знаниями – в первую очередь, задача менеджмента и тех специалистов, которые стремятся к развитию.
Если у вас пока не сложилось понимание, как сохранять и обмениваться информацией внутри команды, то предлагаю несколько проверенных способов, как это сделать. Все способы делятся на две большие группы: энциклопедические странички и обмен опытом в прямом эфире.
Как создать базу знаний: 5 форматов
Особенность базы знаний в том, что в ней можно описать основные понятия и процессы, которые должны знать все сотрудники. Конечно, не надо перепечатывать сюда все по первым ссылкам Google. Но вот оргструктура и крупнейшие проекты вполне укладываются в wiki-формат статей, которые любой сотрудник может увидеть в любой момент.
Важная особенность базы знаний в том, что ее очень легко превратить в кладбище информации. Так бывает, если у базы отсутствует структура, есть сразу несколько авторов, которые не работают сообща, а актуальность информации не поддерживается.
5 форматов обмена информацией, которые подойдут для базы знаний:
- Wiki-статьи. Внутренняя энциклопедия с перекрестными ссылками прекрасно работает, когда дело касается описаний проектов, онбординга новичков, нововведений и обновления ПО.
- Мануалы. К ним требования аналогичные: не делаем очевидных инструкций «Как установить MS Office», а вот при подключении нового корпоративного ПО мануал придется очень кстати. Это не обязательно должно быть в виде текста – презентации, вебинары и даже чат-боты приветствуются.
- Техническая документация. Ее важно не просто написать один раз, а именно поддерживать в актуальном состоянии. Потому что документация, которая пишется на старте проекта часто не соответствует тому, что получается в конце. В итоге на тестировании команда находит лишние баги, которых на самом деле нет.
- Статьи. Это переработка проектного опыта, поиск закономерностей и поиска решения проблемных зон для себя и своих коллег.
- Подборки. Их можно собирать по любому поводу – вопросы, проекты, онбординг и т.п. Когда в вашей базе знаний накапливается достаточно информации, можно создавать подборки по любым вопросам или формировать дайджесты.
Как поддерживать культуру обмена опытом: 5 инструментов
Народная мудрость и пословицы «В споре рождается истина» и «Одна голова хорошо, а две – лучше» подсказывают нам, что знания рождаются в диалоге. Поэтому, если хотите создать атмосферу активного развития внутри компании, надо дать коллегам возможность общаться и обсуждать свой опыт и идеи.
Часто бывает, что команда закончила проект, спокойно вздохнула и начала другой. Осмыслять и оформлять проектный опыт, конечно же, никто не собирается. И зря, потому что при анализе можно выявить интересные закономерности, которые могут помочь улучшить показатели работы в будущем. Поэтому важно:
- Осмыслять полученный опыт, а не просто складывать статьи в базу знаний.
- Активно делиться знаниями с коллегами, просить и получать советы, выносить вопросы на обсуждение.
5 инструментов, которые помогут это сделать:
- Внутренние чаты взаимопомощи. Их может быть несколько по узким темам, но если вы в одном чате сделаете разделение по тегам – это тоже подойдет. В чате можно закреплять важные сообщения, собирать архив отправленных изображений и файлов. Пользователи могут порыться в архивах, а если не найдут ответов – всегда можно задать вопросы остальным. Рекомендую поставить модераторов в таких чатах, чтобы они следили за порядком и выуживали ценную информацию для пополнения базы знаний.
- Внутренние конференции и вебинары. Это очень мощный инструмент внутреннего накопления информации. Во-первых, публичное выступление побуждает более качественно подготовиться и осмыслить опыт. Во-вторых, аудитория может сразу задавать вопросы, предлагать свои варианты. То есть обе стороны обучаются в моменте. Ну а записи таких мероприятий – почти готовые материалы для пополнения базы знаний.
- Внутренние курсы и наставничество. Конкретный формат зависит от масштабов компании и задач обучения. Если у вас огромный поток новичков, которых нужно обучить прямым действиям, то хватит и простой системы мануалов. А вот если один человек или группа уткнулись в стеклянный потолок, то уместно провести полноценный курс, чтобы они могли задавать вопросы и выполнять тренировочные задания.
- Разбор ошибок. Покажите хоть одну команду, которая ни разу не облажалась. Иногда попытки скрыть провалы выглядят жалко, но ведь это же плодородная почва для обучения, особенно, если речь об IT, где далеко не все приемы обкатаны и ежедневно появляются новые решения. Случилась неудача – можно разобрать ситуацию не вдвоем, а всей командой, чтобы в следующий раз она не повторилась.
- Создание сообществ. Это один из видов горизонтальной карьеры. Некоторые удивляются, но не все хотят быть руководителями, многие предпочитают работать «на местах» всю жизнь, и создание профессиональных сообществ внутри компании, которые ищут способы решения задач определенной группы, – отличный путь развития для таких людей. Сообщество может выглядеть как форум или группа в мессенджере, а может перейти в формат еженедельных встреч.
Как получать знания извне и делиться ими
Что делать, если мы не хотим вариться в своем котле? Выходить наружу, разумеется! И для этого также есть ряд возможностей.
- Приглашение спикеров. На рынке полно экспертов, готовых делиться опытом. Это могут быть как представители других организаций, так и специалисты-консультанты. Это могут быть лекции и вебинары, обучающие мастер-классы, корпоративные игры и даже полноценные курсы.
- Участие в хакатонах. Если нет возможности организовать свою фабрику стартапов, то хакатоны всегда рады принять активных участников. За отведенное время (1-3 дня) участники создают MVP – это хорошая тренировка, поэтому многие делают хакатоны своим хобби. Почему бы не снарядить собственную команду на такой хакатон? В них могут быть нужны не только разработчики, но и маркетологи, аналитики, иногда даже дизайнеры.
- Конференции – в них можно принимать участие, а можно даже организовывать самим. Мы, например, провели несколько своих конференций по управлению знаниями и щедро делимся выступлениями спикеров из крупных компаний на нашем YouTube-канале.
- Вести блог компании. Вообще, у него может быть много функций, как раз одна из них – ваш интеллектуальный капитал на рынке.
Вместо заключения
Все эти форматы обмена знаниями – не просто дань моде или калька с западных практик. Даже чат взаимопомощи уже помогает растить внутреннюю экспертизу и выращивать руководителей под себя.
Если у вас в компании есть такие практики, поделитесь своим мнением в комментариях: как они влияют на работу компании?
Читайте также:
Есть примеры реальных систем управления корпоративными знаниями с хорошими классификаторами, системами поиска, правилами доступа и режимами хранения?
Борис, благодарю за развернутое мнение. Опытный специалист может дать ценный совет, вы правы. Но он не всегда доступен (в отпуске, ушел в другую компанию, что-то еще). А библиотека знаний — вот она, под рукой у каждого, кто ищет ответ.
Николай, спасибо за конструктив. Поясню: знания, которыми мы управляем благодаря knowledge management, — это микс опыта (оформленного), корпоративных ценностей, экспертных взглядов, проверенной информации о контексте. Это интеллектуальный актив компании. Далеко не любая информация превращается в актив и знания, и само собой это не произойдет. И конечно, для создания целостной картины одной статьи не хватит, это точно.
Возвращаясь к вопросу из начала статьи: команда не развивается без обмена знаниями, потому что именно оформленный, повторюсь, и осмысленный проектный опыт — источник роста команды.
Сергей, статья освещает тему в общих чертах, это так. Система управления знаниями не начинается с инструментов, как вы и заметили. Я перечислил прикладные инструменты, которые помогают делиться знаниями с коллегами и осмыслять опыт. Строить базу знаний с нуля — совсем другая история, как говорится, и другая тема.
Татьяна, спасибо за вопрос. Конечно, персональное обучение в форме наставничества, например, — очень важная вещь, особенно в процессе онбординга. Требует больше времени, чем групповая работа, но учитывает индивидуальные особенности новичка в идеале.
Николай, к счастью, в нашей компании не в ходу стратегия имитации бурной деятельности) Жаль, что управление знаниями показалось вам запутанным. Но это действительно сложный процесс, согласен с вами.
Павел, спасибо за интересную мысль, тут согласен. Вот почему так важно групповое осмысление опыта — без него у людей на разных позициях даже в одной небольшой команде разные исходные данные, а обучающие курсы для одного или нескольких человек только увеличивают этот разрыв. Есть решение: сотрудник, прошедший курс, делает презентацию на одной из планерок и делится тем, что узнал, с коллегами.
Сегодня главная проблема не в недостатке информации, а в ее избытке и низком качестве. Статья - прекрасный гайд, как парализовать работу.
В статье Владимир формулирует основной тезис
- обмен знаниями - это инструмент развития компании
и далее делится идеями, как организовать этот обмен.
Т.е. есть не заявленная но подразуменваемая цель - обеспечение некоторого уровня знаний, позволяющего развивать компанию
Есть инструмент - обмен знаниями
Есть назначение - собственно развитие компании.
Оставим за рамками обсуждения третий пункт и вопросы использования полученных знаний для развития компании (хотя без этого мы получаем знания ради знаний). При этом в статьпе, в разделе "5 инструментов" процесс обмена/получения знаний и процесс их использования перекликаются.
Но я думаю, все знают формулу "Нельзя управлять тем, что мы не измеряем".
Исходя из этого, есоли мы говорим о знаниях, как об инструменте развития компании, нам необходимо определить способы идентификации треьуемого уровня и состава знаний, а также способы контроля результата - удалось ли достичь нужного уровня.
Мне не хватило размышлений автора рна эту тему.
Еще один важный момент можно начать с цитаты из статьи:
Важно
- осмыслять полученный опыт, а не просто складывать статьи в базу знаний.
- активно делиться знаниями с коллегами, просить и получать советы, выносить вопросы на обсуждение.
Я целиком соглашусь, что для сформулированных целей просто складывать статьи в базу знаний - это не решение. Но действительно ли достаточно просто осмысления, советов и обсуждений?
Если мы ответим на предыдущий вопрос о том, какой измеримый результат нам нужно получить, то скорее всего у нас появятся необходимость в дополнительных инструментах для его достижения.
Лично я, как человек, который много лет занимается этими вопросами, вижу белые пятна в предложенной системе, если мы говорим именно о развитии компании. Однако, обсуждать эти пятна до того, как определен измеримый результат, не имеет смысла.
Если Владимир согласен с изложенными замечаниями, то я бы предложил ему начать именно с определения результата
Владимир, я просто хотел сделать акцент на то, что сама по себе библиотека знаний может быть не так понята и особенно не так применена к требованиям конкретной ситуации!
Например правила, инструкции и стандарты Тойоты, а также аналогичные стандарты качества, описывают правильные вещи.
Но в самой Тойоте хорошо понимали, что для того, чтобы стандарты работали нужно еще научить применять их на практике.
Например, в свои зарубежные подразделения, они отправляли не только технологии и стандарты, но и закрепляли на несколько лет наставника, прежде всего за ГД, чтобы наставник научил как пользоваться инструкциями в конкретный ситуациях!
Отправляли, пока хватало таких наставников. Когда не стало хватать, то они еще раз убедились, что скопировать знания нельзя!:)
Чтобы экономить время(и деньги тоже), при возникновении проблем быстро приходил на помощь спец с нужной компетенцией.
А при проектировании новых продуктов под управлением знаниями подразумевают обмен знаниями специалистов участвующих в разработке.
Также это подразумевает выявление недостающих Знаний, Умений и Навыков - для того чтобы исследовать и найти их на стороне.