Pull to refresh

Comments 7

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

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

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

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

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

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

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

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

Sign up to leave a comment.

Articles