Как вы справляетесь с информационным хранилищем? [закрыто]

Мы, должно быть, все сталкивались с ними - разработчиками, которые были вокруг на протяжении веков и имеют фантастические знания в области, но они не могут поделиться этими знаниями со своей командой.

Команда отчаянно нуждается в том, чтобы делиться знаниями, но они не могут вырвать их из запаса.

Каким образом команды успешно решили эту проблему?

Удалить код собственности из команды. Распределите рабочую нагрузку. Делать код-отзывы. Организуйте сеансы передачи знаний, подождите несколько сеансов, а затем попросите их сделать презентацию в своей области.

Конечно, обязательно, если вы не менеджер, то у вас есть поддержка вашего менеджера, но если все в команде регулярно обмениваются информацией, есть только так много оправданий, которые кто-то может придумать, чтобы не делать то же самое ,

Кроме того, его менеджер должен сесть с ним и объяснить, что это не угрожает его работе. Потому что именно поэтому он делает это.

Это хорошо для человека, чтобы не быть шрифтом всех знаний. Это освобождает его от других, более интересных вещей.

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

Так что это одно из решений.

Дайте им то, что они хотят - назначьте им все работы по техническому обслуживанию и задачи, которые только у него / нее есть знания, чтобы сделать.

Нет, они не могут выполнять новую работу, потому что никто другой не может выполнять эти другие очень важные работы по обслуживанию.

Да, новые сотрудники получают удовольствие от работы и играют с новыми блестящими игрушками, но вы должны выполнять эти очень сложные, высокоприоритетные и скучные задания, потому что они не знают ничего из того, что вы делаете.

Если, конечно, вы не хотите показать одному из них, как это сделать ....

Это напоминает эту статью от Рэндс в Repose.

Я думаю, тебе нужно выяснить, почему этот парень копит информацию. Обеспеченность работой (как статья о Феске) является большой. Но так же небезопасно. Или просто то, что ему нравится такая работа, и он хочет все это для себя, или испытывает какое-то сильное чувство причастности к определенной области. Или чрезмерно предан и не видел, как тратить время.

Некоторые из этих проблем могут быть решены неконфронтационными уловками:

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

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

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

Я не уверен, что слово «отказ» часто является правильным словом, обычно они просто слишком заняты и не имеют свободного времени (или склонности, или социальных навыков), чтобы отвлечься от большого количества времени, чтобы объяснить очевидное (для них). ) к n00bs.

Позитивное решение состоит в том, чтобы предоставить им помощников - почти как распространение работы по команде (но я думаю, что не так много команды, если у вас есть старожилы, которые знают все о системе, и новые парни, которые этого не делают Учитывая эту настройку, неудивительно, что они не хотят передавать свои драгоценные навыки и заменяются более молодой, более дешевой версией!) (вы тоже не захотите - представьте, если ваш менеджер пришел к вам и попросил вас сообщить все, что вы знаете новой команде на аутсорсинг ... хм?)

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

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

Не забывайте, что если у вас есть какая-либо система super-complx (которую вы делаете, или новые парни должны быть в состоянии понять это самостоятельно), то передача знаний - это очень долгий процесс. Никто не может сесть и заставить кого-то полностью набрать скорость, на моем месте такая задача заняла бы минимум 6 месяцев, и даже тогда ... черт, я все еще изучаю материал о том, что делает наш продукт, и я был здесь почти десятилетие!

Сделайте общение обязательством для каждого члена команды и оцените его в рамках ежегодного обзора.

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

Убедитесь, что нет никаких коммуникационных блоков, убедитесь, что существуют процессы и системы для написания документов и обмена информацией; например, вики, сайты sharepoint, запланированные результаты для дизайнерских документов и т. д.

Убедитесь, что во всех проектах работают как минимум два программиста. Это сделано для того, чтобы у вас всегда была резервная копия, когда кто-то покидает фирму.

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

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

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

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

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

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

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

На самом деле есть только один способ получить один из них, который не любит делиться своими знаниями, чтобы охотно делиться своими знаниями: стать достойным этого. Обычно достаточно знаний, которых у них нет (но это трудно сделать). Quid Pro Quo и все такое. В противном случае, купите пару коз и погрузитесь в.

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

Люди, которые играют в «У меня есть секретная игра», являются абсолютным худшим. Эти люди, как правило, небезопасны и создают или процветают в кризисном режиме .

Я хотел бы, чтобы они документировали каждое изменение или изменение, которое они вносят в систему. Я также заставил бы их предоставить вскрытие для каждого исправления, которое они разработали, чтобы включить ...

• что произошло
• почему это произошло
• как предотвратить это
• какие другие системы уязвимы для той же ошибки

Я также сделал бы этого человека ответственным за ...

• разработка стандартов кодирования
• поддержание библиотеки кода

Многое зависит от типа вовлеченных знаний; будь то код или бизнес-процесс. Как правило, последний доступен в другом месте в бизнесе ... и может быть приобретен.

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

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