Цели обмена знаниями в IT компании
Цели Обмена Знаниями
Часто можно встретить следующий перечень целей:
- обучить разработчиков
- поднять эффективность разработчиков
- построить экспертные группы по направлениям
- снизить риски в разработке
- поощрить внедрение инновации
В то время, как этот список полностью описывает активности в дисциплине обмена знаниями, он очень абстрактный и не даёт представления об ожидаемых результатах. На мой взгляд, разные люди могут понять совершенно разные вещи, читая эти пункты. Кто-то будет думать о том, что надо учить все новое, кто-то подумает о фундаментальных знаниях. Пытаясь сделать эти пункты ближе обычным людям, у меня получились следующие цели:
- распространить знание между разработчиками
- выровнять скилы и терминологию
- подтянуть к последним стандартам IT индустрии
- разработать внутренние стандарты разработки
1. Распространить знание между разработчиками.
Самой очевидной задачей дисциплины обмена знаниями является распространение информации между разработчиками. В компаниях, где ведется параллельная работа над несколькими проектами, которые необходимо интегрировать между собой и поддерживать согласованность версий, данный момент играет наиболее важную роль. Осведомленность одной команды о принципах работы компонента другой команды, с которым они интегрируются, при ведет к созданию более адекватных решений и снизит количество итераций по отладке. Если не брать во внимание интеграцию между проектами, то данная активность снизит вероятность повторного создания одного и того же в разных проектах.
Активности в этой области помогают в достижении сразу двух целей из первого списка: снизить риски и увеличить эффективность разработчиков. Кто-то может заметить, что распространяя знания, разработчик теряет свою эксклюзивность для компании. Думаю, иногда это становится причиной того, что разработчики не желают быстро делиться обретенными знаниями о каком-то из направлений в разработке. Как кто-то сказал, так делают только говнюки. Я же считаю, что боязнь потерять свою эксклюзивность связана со страхом оказаться недостаточно компетентным в теме. В момент, когда человек попытается рассказать об этой теме, вопрос о его компетенции будет поставлен ребром. Я не берусь тут выдвигать психологические теории, но знаю по себе, что рассказывая другим, даже если не до конца понимаешь тему, помогает поставить мозги на место и дополнить знания до необходимого для уверенного уровня.
2. Выровнять скилы и терминологию
Чуть менее очевидной задачей обмена знаниями, на мой взгляд, является выравнивание скилов разработчиков и их терминологии. Про скилы речь идет, главным образом, о подтягивании менее опытных к более опытным, чтобы они на равных могли принимать участие и в обсуждении и в разработке. Опять же, это полезно как самой компании, так и самим разработчикам — win-win game. Я делаю упор именно на подтягивании скилов, т.к. набор скилов определяется проектами. Образование же имеет слишком абстрактное определение. Прежде чем двигаться в этом направлении необходимо небольшое исследование своих команд, чтобы определить срез по скилам, необходимым в проектах и уровень разработчиков. В результате будет видно какие из них требует дополнительных действий.
Другой аспектов задачи является унификация терминов, используемых разработчиками. Я встречал ситуации, когда стандартные термины в компании использовались для описания несвойственных вещей. Например, термин milestone использовался для того, для чего в остальном мире используется user story. Кроме этого, существует еще множество ошибочно используемых терминов, жаргонизмов и прочее, что, само по себе, совершенно не критично. Если коллектив не меняется, никто не приходит и не уходит, все нормально. Как только появляется некоторая текучка, коммуникации могут хромать. В компаниях с множеством проектов так же может существовать разница в обозначениях одного и того же. Например, location и property обозначают в двух разных проектах одно и то же: конкретный ресторан.
Еще одной полезным результатом активностей в этом направлении является создание экспертных групп. Я это представляю, как группы людей, которым нравится то, что они делают и они заражают своей «любовью к теме» других. Обычно это неформальные лидеры команд, которые и являются драйверами многих вещей в разработке внутри компании.
3. Подтянуть к последним стандартам IT индустрии
Данная задача связана с обучением разработчиков. Как и предыдущие две, это тоже выгодно обеим сторонам, хотя в данном случае беспокоиться больше приходиться компании. Инвестируя в данные активности и в разработчиков, компания может лишится последних. Вероятно, это является причиной, почему в некоторых компаниях инвестиции в это направление не ведутся. Но мне кажется, что причина этого в том, что идея понимается слишком поверхностно и без связи с остальными задачами. Уточню, что тут я имею ввиду именно технические скилы.
В моем представлении данная задача должна решаться экспертными группами. И только в критических случаях необходимо вливание знаний со стороны. Это важно потому, что обучение и совершенствование будет происходить благодаря улучшениям внутри компании и мотивации самих разработчиков. И компании необходимо направить инвестиции на поощрение таких «драйверов». Это гарантирует максимальную заинтересованность участников в том, чтобы остаться в компании. И, как следствие, будет движение в строну еще одной важной задачи: инновации.
4. Разработать внутренние стандарты разработки
Результатом активностей в этом направлении является согласованный с экспертными группами набор готовых решений, подходов и шаблонов. Этот набор может отличаться от принятых за стандарт в IT индустрии, но он является рабочим для самой компании. Речь тут идет не только о технических решениях, но и о дизайне, процессах в разработке, способах мониторинга и прочие все возможные практики, позволяющие компании и разработчикам достигать общих целей. Выглядеть это может, как база знаний на wiki, c примерам и на GitHub. Отличительной особенностью этого направления является явная работа в экспертных группах по техническим направлениям и выявление таких групп так же является частью этой задачи.
Дополнительно
- Creating a Knowledge Sharing Culture
- Top 5 knowledge management goals
В комментариях расскажите как обстоит дело с обменом знаниями в вашей компании? С какими сложностями в развитии это дисциплины вы сталкивались, как решали?
