Баланс між навантаженням та наданням допомоги найнятим [закритим]

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

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

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

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

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

Скажіть: "Гей, я намагаюся це зробити, і я спробував це, це, і це вже, чи є у вас ідеї?" Це допоможе їм витратити менше часу на вас, і вони будуть більш схильні до цього.

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

Найкраща порада, яку я можу дати вам, - записатися на зустріч . У кожного є час простою протягом дня, але якщо ви просто випадково потрапляєте, ви навряд чи вдаритесь. Скажіть щось на кшталт: "У мене є якісь питання щодо X, чи можу я сьогодні встановити якийсь час, щоб перебрати це з вами?" Вони можуть вирішити приділити вам час тоді чи пізніше, або, можливо, направлять вас на когось, хто може відповісти на ваше питання краще чи швидше. Так чи інакше, ви збираєтеся привернути більше уваги. Якщо вони призначать вам зустріч пізніше, скористайтеся часом втручання, щоб спробувати зрозуміти відповідь самостійно або принаймні для уточнення питання. Навіть якщо я відкладаю чиєсь запитання лише на 15 хвилин, частіше за все вони розуміють його самостійно.

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

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

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

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

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

Мені пощастило, що зараз я десь працюю, це не проблема. Тут я здобув здорову дозу наставництва, і це мені дуже приємно.

1. Кожен день один розробник у моїй компанії - це "утиль", розробник на ротаційній основі. Розробник Util - це перша лінія контактів, коли підтримці потрібно щось розширити. Часто Util просто передає проблему комусь іншому. Але це один конкретний розробник, і підтримка знає, щоб звернутися до цієї людини. Я спершу зробив декілька "проїздів" (вони трохи не ставили мене в графік), щоб побачити, як вирішуються деякі проблеми. Це підштовхнуло мене до частини коду. Коли вони почали планувати мої звичайні службові дні, спочатку був хтось «за викликом», щоб додати додаткову допомогу.

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

3. Щодня ми робимо стенд-зустріч о 11:45. Це 15-20 хвилин. Кожен розробник / QA-людина говорить. Це в основному спосіб сказати "це те, що я роблю, і ось там я застряг", і якщо ти застряг, ти, як правило, вказуєш в якомусь альтернативному напрямку (якщо це відома проблема / проблема з кодом, хтось дуже знайомий з) або встановлено час пари. Іноді планується додаткова зустріч.

4. Мені тут доводилося занурюватися в абсолютно чужий код (як і на будь-якій роботі). Хтось завжди був впевнений, що вони можуть бути доступними для відповіді на запитання, якщо не відразу.

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

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

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

Більшість розробників (або, принаймні, ті, хто найбільш корисний для зустрічі) з цим будуть добре.

Якщо є дуже конкретна деталь, яка блокує ваш прогрес, скористайтеся електронною поштою.