Чи потрібно вимагати старших програмістів брати участь у наставництві та розробляти молодший розробник? [зачинено]

У магазині, який повинен бути в'язаним і підтримувати, чи слід входити в культуру, яку старші розробники поєднують з молодшими розробниками як наставники? Або це наставництво повинно бути чимось більш органічним і стихійним, тобто не потрібно, але дозволено розвиватися без штучного заохочення?

Я думаю, що це слід заохочувати, але не вимагати; пенсіонерів не слід привласнювати до юніорів чи чогось подібного, інакше ви опинитесь у Ділбертові. Відносини "наставник-наставник" вимагають певного рівня дружби, а також здорової дози ВЗАЄМНОГО поваги. Ви цього не здогадуєтесь, просто кажучи людям піти і "накладати".

чи має це бути частиною культури, яку старші розробники поєднують із молодшими розробниками як наставники?

Так.

органічні та спонтанні, тобто не потрібні, але дозволяють розвиватися без штучного заохочення

Це не станеться досить часто, щоб насправді допомогти комусь.

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

Будучи консультантом понад 30 років (100 клієнтів), я можу стверджувати, що нові люди завжди сторонні. Це не особливість "культури" чи "атмосфери". Це важлива особливість того, як люди працюють. Консультанти формують свою власну кліку, оскільки створений персонал не прагне їх включати ні до чого.

Єдиний спосіб налагодити наставництво - це вставити нових людей у ​​кліки.

Традиційне значення "наставника" дещо не піддає завданням. Ви також можете спробувати призначити друзів.

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

Чи слід вимагати старших розробників для наставника молодших розробників?

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

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

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

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

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

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

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

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

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

Я думаю, що ти повинен бути готовим бути наставником у деяких випадках та наставником в інших.

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

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

Примусове наставництво, ймовірно, створить систему каст, яку розробники можуть обурювати один одного. Краще ставитися до кожного розробника однаково на одному рівні.

Ця галузь дуже відрізняється. Сеньйори не завжди кращі.

Іноді старші потребують наставництва юніорів.

Я був у середовищах, які роблять справи в обох напрямках.

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

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

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

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

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

Слід очікувати, що старші розробники вийдуть за рамки витіснення коду. Однак напрямок, в якому вони йдуть, не повинен бути однаковим для кожного старшого розробника.

Деякі добре підходять до наставництва. Інші не є і повинні переслідувати якусь іншу мету вищого рівня, будь то планування та впровадження архітектурних удосконалень, або оцінка нових технологій, або планування та провідне вдосконалення процесів (наприклад, безперервна інтеграція, TDD тощо)

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

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

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

Структура лідерів команд, що веде до огляду коду, повинно зробити трюк ...

У вас буде старший член вашого персоналу, відповідальний за одного або декількох юніорів. Я не вірю, що це повинна бути спонтанна допомога, а скоріше формальний процес; в тому сенсі, що старший член буде відповідати за якість роботи, яку виробляють нові бажаючі. Цей підхід має 2 переваги (принаймні): інструктуй старших людей у ​​стилях управління та переконайся, що юніори виробляють якісний код.

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

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

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

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

1. Поточний статус - Де зараз справи? Який сучасний виклик може надати наставнику допомогу у вирішенні?
2. Майбутній стан - Що хочеться: Підказка, рішення, запитання, кому задати?
3. Ретроспектива - Що працювало, а що не працювало над внесенням змін?
4. Майбутні зміни - Що буде намагатися в майбутньому, що може працювати краще, ніж раніше?

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

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

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

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

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

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

Це вимагає збалансованого управління. Я не впевнений, що це звичайне явище.

Для того, щоб наставництво працювало, важливо, щоб керівництво усвідомлювало, що це важливо, і виділяти час на це, і активно заохочувати це!

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

Як правило, кораблі-наставники є хорошим кроком для переходу від старшого до керівника команди чи керівника. Ефективніше пов'язати менторство з просуванням в ПДП (Особистий план розвитку) або з тим, що коли-небудь заслуговує план вашої компанії. Прив’язання до підвищення заробітної плати та кар’єрного розвитку хоча б частково до їхньої здатності передавати знання та доглядати за новими розробниками є ключовим фактором для створення сильного ІТ-персоналу, який може змінити погоду в управлінні та плинності персоналу. Забезпечення ключових цілей та робота з персоналом, щоб допомогти їм вдосконалюватися, є частиною цього зростання в лідерстві. Для тих, хто вважає, що не справедливо прив'язувати оцінку старших до виступів юніорів, які є частиною зростання. У більшості випадків ви не говорите про зниження зарплати, а скоріше зменшення збільшення або уповільнене просування.

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

Це спрацювало чудово, але потім, напевно, вам потрібні приємні люди з почуттям гумору, щоб змусити це працювати.