Баланс между рабочей нагрузкой и помощью новых сотрудников [закрыто]

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

Я понимаю, что новый найм также должен поддерживать баланс. Иногда потребуется 3 дня, чтобы исследовать и исправить что-то, что мог сделать ветеран за 20 минут. Новые сотрудники должны приложить усилия для изучения продукта и кодовой базы.

Если вы просто сократите рабочую нагрузку ветеранов, как вы сможете найти баланс между оказанием помощи новым сотрудникам и продолжением работы с отставанием с разумной скоростью?

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

Самое важное, что нужно помнить, это. Не задавайте вопросов, когда вы «предполагаете», что не сможете найти ответ самостоятельно. Сделайте попытку, сначала поищите, изучите код, попробуйте изменить некоторые вещи и посмотрите, что произойдет - посмотрите, сможете ли вы сначала заставить что-то работать. Если вы действительно не можете, задайте свой вопрос. Однако, когда вы задаете свой вопрос, переходите к ним с примерами того, что вы уже пробовали. Никто из них не хочет чувствовать, что вы просите их сделать вашу работу за вас.

Скажи: «Эй, я пытаюсь сделать это, и я попробовал это, это, и это уже, у вас есть какие-нибудь идеи?» Это поможет им тратить меньше времени на вас, и они будут более склонны делать это.

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

Лучший совет, который я могу вам дать, это записаться на прием . У каждого есть время простоя в течение дня, но если вы просто заходите случайно, вы вряд ли добьетесь этого. Скажите что-то вроде: «У меня есть несколько вопросов по поводу X, могу ли я назначить время сегодня, чтобы обсудить это с вами?» Они могут решить дать вам время прямо сейчас или позже, или, возможно, направить вас к кому-то, кто сможет ответить на ваш вопрос лучше или быстрее. В любом случае, вы получите более пристальное внимание. Если они назначат вам встречу позже в тот же день, используйте прошедшее время, чтобы попытаться выяснить ответ самостоятельно или, по крайней мере, уточнить вопрос. Даже если я откладываю чей-то вопрос всего на 15 минут, чаще всего он решает его самостоятельно.

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

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

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

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

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

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

1. Каждый день один разработчик в моей компании является «утилитарным» разработчиком на основе ротации. Разработчик Util является первой линией связи, когда поддержка нуждается в эскалации чего-либо. Часто Util просто передает проблему кому-то другому. Но это один конкретный разработчик, и поддержка знает, чтобы пойти к этому человеку. Сначала я сделал несколько «поездок» (они не включили меня в расписание на некоторое время), чтобы посмотреть, как решаются некоторые проблемы. Это заставило меня разобраться с частями кода. Когда они начали планировать мои обычные рабочие дни, сначала был кто-то «по вызову», чтобы добавить дополнительную помощь.

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

3. Каждый день мы проводим очередную встречу в 11:45. Это 15-20 минут. Каждый разработчик / QA человек говорит. По сути, это способ сказать «это то, что я делаю, и это то, где я застрял», и если вы застряли, вы, как правило, указали в каком-то альтернативном направлении (если это известная проблема / проблема с кодом, кто-то очень знаком с) или время пары установлено. Иногда назначается дополнительная встреча.

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

Я повторю другим: назначьте время встречи, чтобы задать вопросы, где это возможно. Идентификатор, который все еще не полезен. , , ну, я не хочу быть здесь экстремальным. Но я не считаю это идеальным рабочим местом. Возможно ли, что люди все еще согреваются к вам / получают контроль над вашими способностями / и т.д.?

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

Часто это скорее вопрос фокуса, чем времени. Запланируйте 30-45-минутные встречи с руководителем или наставником вашей команды (до или после обеда - это всегда мое предпочтение - тогда мой поток уже нарушается) пару раз в неделю и сохраните ваши вопросы на потом.

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

Если есть очень конкретные детали, которые блокируют ваш прогресс, используйте электронную почту.