Як ви маєте справу з скарбником інформації? [зачинено]

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

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

Якими способами команди успішно вирішили цю проблему?

Видаліть власність коду з команди. Розподіліть навантаження. Робіть кодові огляди. Організуйте сеанси передачі знань, зачекайте кілька сеансів, а потім попросіть їх зробити презентацію про свою область.

Звичайно, обов'язково, якщо ви не менеджер, то у вас є підтримка вашого менеджера, але якщо всі в команді регулярно обмінюються інформацією, є лише стільки виправдань, з якими хтось може придумати себе за те, що не робити те саме .

Також його керівник повинен сісти з ним і пояснити, що це не загрожує його роботі. Бо саме тому він це робить.

Це добре, щоб людина не була шрифтом усіх знань. Це звільняє його від інших, більш цікавих речей.

Я вважаю, що Джеральд Вайнберг мав на увазі саме цей тип людини, коли він коментував у «Психології комп’ютерного програмування» (перефразоване тому, що в мене немає книги перед собою), якщо ви помітили програміста, який намагався зробити себе незамінним, вогнем його негайно. Через 25 років, коли він перевидав книгу, він прокоментував, що жодна порада не отримала такої подяки, як ця.

Тож це одне рішення.

Дайте їм те, що вони хочуть - призначте їм усі роботи з технічного обслуговування та завдання, про які має знати лише він / вона.

Ні, вони не можуть виконувати нову роботу, тому що ніхто інший не може виконувати інші важливі роботи з обслуговування.

Так, нові наймачі отримують веселу роботу та граються з блискучими новими іграшками, але ви повинні виконувати ці дуже складні завдання з високим пріоритетом та нудністю, оскільки вони не знають жодної речі, яку ви робите.

Якщо, звичайно, ви не хочете показати одному з них, як це зробити ...

Це нагадує цю статтю з Rands in Repose.

Я думаю, вам потрібно з’ясувати, чому цей хлопець зберігає інформацію. Захист роботи (як і стаття про The Fez) великий. Але так само є і незахищеність. Або просто те, що йому подобається така робота і хоче все це для себе, або відчуває якесь інтенсивне почуття власності щодо певної місцевості. Або занадто відданий і не бачив способу заробити час.

Деякі з цих питань можна вирішити неконфронтаційними хитрощами:

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

Варто також долучитися до декількох спроб інформаційного пошуку - це може зайняти два тангу, і, можливо, ви не хочете виключати думки про те, що навколо існує достатньо залякування, щоб запитуючі не задавали гарних запитань. загострення проблеми. Можливо, вам доведеться зайти і почати створювати резервні копії та задавати більш широкі запитання, щоб змусити хлопця рухатися. Крім того, якщо керівництво там задає питання, надає ваги і важливості діяльності з обміну інформацією - набагато складніше відмовитися і уникнути управління. Зазвичай, пройшовши кілька продуктивних сесій, ви можете вийти з середини і сказати, "у вас є, це вам не потрібно" і перейти до наступної проблеми.

Ще один ключ - НЕ дозволяйте хлопцеві домінувати над роботою в тих сферах, де йому потрібно ділитися знаннями. Поставте когось іншого, що відповідає за роботу, і дайте зрозуміти, що це справа охоронця інформації - ділитися знаннями. Якщо він тоді не може поділитися, вам може знадобитися жорстока розмова, де ви пояснюєте, що обмін інформацією - це вимога для команди, а не вибір. Що він вносить свій внесок у розклад розкладу команди, не допомагаючи комусь іншому вчитися.

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

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

Я рекомендую помічникові працювати в частині системи, і, як очікується, вона з часом стане експертом у цій галузі, очікується, що досвідчений розробник допоможе їм виконати свою роботу в цій невеликій області. Ми всі так чи інакше були там, "якщо ви хочете знати, як працює X, забудьте про (застарілу або неіснуючу) документацію і поговоріть з Джимом".

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

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

Візьміть на себе зобов’язання щодо кожного члена команди та оцініть їх щодо цього як частину щорічного огляду.

Переконайтесь, що команда визнана за досягнення, а не лише про людей, і переконайтесь, що всі люди знають, що успіх команди - їх пріоритет, карайте їх, якщо вони заважають команді досягти успіху.

Переконайтесь, що немає блоків для зв'язку, переконайтесь, що є процес та системи для написання документів та обміну інформацією; наприклад, вікі, сайти спільного доступу, заплановані результати для дизайнерських документів тощо.

Переконайтесь, що всі проекти мають принаймні двох програмістів, які можуть працювати над цим. Це допоможе вам завжди мати резервну копію, коли хтось залишає фірму.

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

Якщо "скарбник" справді не робить це цілеспрямовано, а насправді просто робить це через щось на зразок відсутності соціальних навичок, часових зобов'язань і т.д. навантаження чи допомога витягти знання. Дайте зрозуміти обом сторонам, що це мета нових осіб, і залучайте «скарбника» до процесу співбесіди. Керівництво має взяти руку в цьому і дати їм можливість ділитися своїми знаннями. Це мета управління, щоб усунути перешкоди та дати можливість працівникам отримати роботу.

На моєму досвіді, прихильники інформації можна класифікувати на два типи: тих, хто любить ділитися своїми знаннями та отримувати певне задоволення від відвертої допомоги іншим, як я, і тих, хто цього не робить. Очевидно.

Тепер обидві сторони мають свої причини, і той, хто любить ділитися своїми знаннями, рідко видаватиме все це з тієї ж причини, що і той, хто не ділиться своїми знаннями: вони намагаються зробити людей навколо їм краще, і на мій упереджений погляд, вони роблять це правильно. (звичайно, у вас також є ті, хто не ділиться знаннями просто для того, щоб зробити себе незамінними, і це з неправильних причин, і їх слід покінчити з тим, як зазвичай це не так здорово для початку)

Зрештою, їм довелося заглибитися в глибинні таємні та езотеричні моря, щоб навчитися тому, що вони знають, як правило, шляхом чистих експериментів, ліберального застосування критичного мислення, спалахів інтуїції та проникливості та містичних обрядів, пов’язаних із різними видами жертовних худоби, і вони вийшли кращими для цього. Мислення зазвичай полягає в тому, що якщо оточуючі люди занадто ліниві або не можуть керувати цим, тоді вони навіть не повинні робити цю роботу, і, звичайно, вони не варті своїх знань. Коли оточуючі пройдуть ті самі речі, що і їм довелося, тоді вони вийдуть кращим програмістом, тому що вони навчилися добре думати і вирішувати складні проблеми і все таке.

По суті, це змушує інших ставати кращими через чвари. Хоча багато буде перетоплено та вигнано, ті, хто пройде через рукавицю, неминуче виявляться набагато кращими, ніж у них, якби вони стали кращими завдяки співпраці.

Що ж стосується того, щоб змусити їх обмінюватися інформацією: ви не можете змусити їх робити це. Намагаючись змусити їх змусити їх бачити вас як жадібним, ледачим, або занадто дурним, щоб потрапити туди самостійно, і вони, звичайно, не збираються змилуватися над вами в жодному з цих випадків. Якщо хтось вище намагається змусити їх зробити це, він може стати дуже неприємним, перетворивши весь свій значний інтелект на те, щоб зірвати індивіда, або навіть кинути відверто, а не зраджувати їх принципи, зрештою, є багато місць, які могли б використовувати свої навички і знання.

Насправді існує лише один спосіб отримати один із них, який не любить ділитися своїми знаннями, щоб охоче ділитися своїми знаннями: стати гідними цього. Зазвичай знань, яких у них немає, достатньо (але важко зробити). Quid pro quo та все таке. В іншому випадку придбайте пару козлів і зануріться.

Хто начальник? Де це закінчується? Не потрібно ділитися інформацією. Не потрібно надавати документацію. Постійно не вдається зробити справи вчасно. Не дотримуйтесь стандартів кодування. Або хтось із відповідальних вважає це важливим, або вони цього не роблять. Мають бути наслідки. Вони в основному крадуть у компанії.

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

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

• що сталося
• чому це сталося
• як не допустити цього
• які інші системи вразливі до тієї ж помилки

Я також хотів би зробити цю особу відповідальною за ...

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

Багато залежить від типу залучених знань; чи це безпосередньо код, чи орієнтований на бізнес-процеси. Зазвичай останні є в інших місцях бізнесу ... і їх можна придбати.

По-друге, є аргумент щодо того, щоб жоден розробник не міг витрачати весь свій робочий ресурс на конкретні ділянки без обміну, так би мовити. Тож якщо у вас є керівник лінії, який відповідає за роботу над доліром, то варто домогтися того, щоб будь-які запити щодо зміни бізнесу надходили через нього / її, щоб конкретний розробник став першою лінією зв’язку для власника бізнес-процесів. ... Це перешкоджатиме зусиллям розробника стати гуру.

Чи було б в інтересах обох сторін, якби скарбнику інформації було запропоновано знайти компанію меншого розміру або навіть створити власну компанію? Можливо, людина процвітала б у такому меншому середовищі. (Цікаво, чи хтось коли-небудь спробував такий підхід і в реальному світі.)