Цели обмена знаниями в IT компании

    «Знание есть сила», и я считаю, что компании должны поощрять культуру обмена знаниями между разработчиками. Удержание информации сотрудниками не является правильным путем по карьерной лестнице и не сделает никого ключевой персоной в долгосрочной перспективе. Ряд активностей, объединенных общим названием, напоминает win-win игру, в которой выигрывают обе стороны. За счет увеличения эффективности каждого отдельного разработчика, компании достигает более высоких целей наиболее эффективным образом. Основной трудностью, которая мешает продвижению этих активностей в компаниях, является отсутствие прямой связи между инвестициями в них и отдачи. Я не встречал четкой системы оценки прогресса этих мероприятий. Поэтому для себя расписал, как цели обмена знаниями связаны с реальными процессами в компании.

    Цели обмена знаниями


    Часто можно встретить следующий перечень целей:

    1. обучить разработчиков
    2. поднять эффективность разработчиков
    3. построить экспертные группы по направлениям
    4. снизить риски в разработке
    5. поощрить внедрение инновации

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

    1. распространить знание между разработчиками
    2. выровнять скилы и терминологию
    3. подтянуть к последним стандартам IT индустрии
    4. разработать внутренние стандарты разработки

    1. Распространить знание между разработчиками


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

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

    2. Выровнять скилы и терминологию


    Чуть менее очевидной задачей обмена знаниями, на мой взгляд, является выравнивание скилов разработчиков и их терминологии. Про скилы речь идет, главным образом, о подтягивании менее опытных к более опытным, чтобы они на равных могли принимать участие и в обсуждении и в разработке. Опять же, это полезно как самой компании, так и самим разработчикам — win-win game. Я делаю упор именно на подтягивании скилов, т.к. набор скилов определяется проектами. Образование же имеет слишком абстрактное определение. Прежде чем двигаться в этом направлении необходимо небольшое исследование своих команд, чтобы определить срез по скилам, необходимым в проектах и уровень разработчиков. В результате будет видно какие из них требует дополнительных действий.

    Другой аспектов задачи является унификация терминов, используемых разработчиками. Я встречал ситуации, когда стандартные термины в компании использовались для описания несвойственных вещей. Например, термин milestone использовался для того, для чего в остальном мире используется user story. Кроме этого, существует еще множество ошибочно используемых терминов, жаргонизмов и прочее, что, само по себе, совершенно не критично. Если коллектив не меняется, никто не приходит и не уходит, все нормально. Как только появляется некоторая текучка, коммуникации могут хромать. В компаниях с множеством проектов так же может существовать разница в обозначениях одного и того же. Например, location и property обозначают в двух разных проектах одно и то же: конкретный ресторан.

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

    3. Подтянуть к последним стандартам IT индустрии


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

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

    4. Разработать внутренние стандарты разработки


    Результатом активностей в этом направлении является согласованный с экспертными группами набор готовых решений, подходов и шаблонов. Этот набор может отличаться от принятых за стандарт в IT индустрии, но он является рабочим для самой компании. Речь тут идет не только о технических решениях, но и о дизайне, процессах в разработке, способах мониторинга и прочие все возможные практики, позволяющие компании и разработчикам достигать общих целей. Выглядеть это может, как база знаний на wiki, c примерам и на GitHub. Отличительной особенностью этого направления является явная работа в экспертных группах по техническим направлениям и выявление таких групп так же является частью этой задачи.

    Дополнительно



    В комментариях расскажите как обстоит дело с обменом знаниями в вашей компании? С какими сложностями в развитии это дисциплины вы сталкивались, как решали?
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 7

      +2
      В целом всё верно сказано, я тоже обеими руками ЗА обмен опытом и знаниями, но есть всегда некоторые трудности, классика жанра «ожидание и реальность».

      Ты думаешь, расскажу вот это и это и остальные заинтересуются, а после если кто-то слышит знакомые слова из разговора с тобой, из прочтенных лекций, вся работа (содержащая эти слова) ложится на тебя. Сама попадала в такую ситуацию. Это реально выглядело так: «Где-то я уже слышал эти слова, ах точно, вот этот человек знает, пусть этим и занимается». Все просто узнали, какими знаниями ты обладаешь, а потом будут стараться выжимать из этого полную выгоду. Поэтому очень важно, чтобы сам коллектив был готов принять и переворить эти знания, а потом развивать и применять.

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

      Все зависит от коллектива, должна быть обратная связь.
        0
        Правильно ли я понимаю, что вы говорите о двух проблемах:
        1. о том, что докладчик становится, своего рода, «крайним» и все начнут его напрягать вместо того, чтобы сделать самим
        2. и то, что после пары лекций никто специалистом не станет.

        Поясните, пожалуйста?
          +1
          1. Смотрите, сотрудник обладает специфическими знаниями в каком-то направлении. В проекте задач, связанных с этим не возникало. Этот сотрудник в один прекрасный день разговаривает с кем-то из команды и рассказывает что к чему, потом предлагает почитать лекции. Вроде всё прекрасно, слушатели довольны. Но это так в одно ухо вошло в другой вышло. Более того, потом кто-то может еще и на курсы пойти. Через несколько месяцев появляется необходимость решить задачу в этом направлении, и, как можно догадаться, задачка попадает в руки человека, который в теме. А потом в следующие месяцы появляется еще несколько задачек, которые снова идут этому человеку. То есть задачи идут даже мимо тех, кто ходил на специальные курсы. Это история из личного опыта, не более.

          2.Кто-то собрался почитать лекции, и думает «вот я такой молодец, через неделю у меня будет коианда мечты из неотесанных слушателей». Проходит неделя, и у таких людей просто пропадает желание вообще когда-либо что-то рассказывать. Ведь порог вхождения у некоторых тем очень разный(а это не было учтено), без знания одного нельзя давать друго. Все хотят, чтоб их труды были оправданы, но не всегда это реализуемо. Опять же, это история из моего коллеектива.
            +1
            Спасибо за интересные моменты и описание.

            Не претендую ни на что, но мне описанные проблемы, кажутся, стандартными для ситуации, когда процесса обмена знаниями нет. Рассказать о чем-то, еще не обменяться знаниями, как вы сами подметили во втором пункте. А первый пункт связан с недальновидностью и не так важно чьей: менеджера или самого разраба. При повышении нагрузки, очевидным решением распределение задач между разрабами с обучение их до должного уровня. Принять решение об этом может менеджер, или сам разраб.
            Если же ситуация иная: кто-то хочет чтобы ему дали эту задачу, а ему не дают, несмотря на пройденные курсы, то тут необходимо смотреть почему. Может быть никто не знает о новом специалисте, может нет доверия, может еще что. Об этом обобщенно сложно обсуждать.
        0
        У нас опен сурс финская стартап-компания, что уже собой подразумевает делиться всем и «transparency» во всем. Поначалу (первый год) было интересно и драйвово и в какой-то момент даже начал вливать кучу свои идей, которые были успешно применены и это было отмечено у меня в рекомендационном письме. Но потом, встречаешь моменты точь в точь как было сказано, когда поделился опытом или недавним ресерчем, на тебя сразу скидывают относящиеся к этому задачи. От этого начинаешь уставать и вроде как сам хотел заниматься другим… Хоть это и стартап, где у каждого роль фул-стак разработчика — сетевика, но по некоторым фреймворкам, тулзам или скилам предпочтение отдается конкретному человеку, а не вовлечение всей команды.
          +1
          Просто по бытовому рассуждая: почему нельзя сказать, что ты это делать не хочешь. И ты готов обучить кого-то другого, чтобы ему передать эту эстафету?
          +2

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

          Only users with full accounts can post comments. Log in, please.