Скільки юніорів повинен старший наставник? [зачинено]

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

Десь від 0 до 5 або 7 (або близько того).

Аргументи для низької сторони:

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

Аргументи на більшу суму:

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

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

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

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

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

Стільки, скільки вони можуть, в той же час в змозі зробити свою роботу вчасно.

Відповідь, отже, залежить від того, наскільки ефективні старші як розробники, так і вчителі.

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

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

Від роботи залежить стільки, скільки людей, на мою думку.

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

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

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

В ідеалі молодший працює з наставником над проектом. Таким чином старший може призначити додаткові завдання та працювати з ними над виконанням проекту. Чим більше юніорів старшим доводиться керувати, тим менше роботи старший зможе виконати самостійно. Я б не хотів, щоб у будь-який час працювало більше 1 або 2 молодших. Хоча старший може продовжувати наставляти інших програмістів через 2 або 3 місяці, пристойному програмісту потрібно більше часу від старшого, ніж раніше. Таким чином, старший міг би мати 20 і більше людей, яким він є наставником, але насправді лише 2 або 3, які дійсно потребують значної частини часу.