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

21

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

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

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

Spacebob
источник
1
Кажется, вопрос задан со старой точки зрения найма, но вы проработали там всего 2 месяца: вы просите предложения передать руководителям (странно) или вы работаете в компании, которая нанимает так много, что вы сейчас один из старых?
ZJR
2
Я новичок в компании, но у меня был опыт совместной работы 1,5 года, поэтому я несколько раз был новичком в разных компаниях. Я хотел показать, что я понимаю точку зрения как ветерана, так и
новичка,
1
Я вижу это недавно, когда все новые сотрудники были переведены на обслуживание для текущих клиентов, и большинство нынешних программистов, которые знали, что кодовая база была «прокачана» новому клиенту, который был готов заплатить большие суммы денег за консультации, чтобы расширить продукт.
Ян
2
Я чувствую, что это немного актуально. programmers.stackexchange.com/questions/100725/...
user606723

Ответы:

21

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

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

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

slandau
источник
8
Если вы собираетесь задавать вопросы, попробуйте записать несколько и задать их за один присест (т.е. один раз в день или неделю). Может быть неприятно, если ваши опытные коллеги отвлекаются от работы каждые полчаса.
Том ван Энккеворт
Мой вопрос действительно касается того, что вы делаете, если после коллеги трудно получить ответ от коллеги? Похоже, что на данный момент это проблема, которую мне нужно довести до менеджера
Spacebob
@ Spacebob - попробуй спросить другого коллегу? Если они все такие - держите себя в руках, и когда ваш начальник спрашивает вас, почему что-то не делается, скажем, я пытался - но это занимает у меня некоторое время, потому что никто не хочет помочь (очевидно, в лучшем случае путь, чем это хотя).
slandau
@ Spacebob, В какой-то момент вы должны прекратить тратить время на тупик и спросить коллегу. Мой совет - попробуйте спросить кого-то, кто также новичок. Они часто гораздо охотнее помогают и могут не знать ответа, но будут заинтересованы в том, чтобы помочь вам найти его. Иногда вам нужно не больше опыта, это другой взгляд.
user606723
8

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

Pedro
источник
У нас тоже есть эта система. Существует переходный период, когда вам нужно начать обращаться к другому партнеру за помощью. Я говорю о том, когда новичкам назначают работу, над которой тренер может не быть экспертом, а другой член команды будет командиром / галом.
Spacebob
Мне нравится, как это сформулировано "потреблять одного человека"
Ладья
Почему новые сотрудники в команде A назначаются наставнику из команды B?
Ramhound
4

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

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

Карл Билефельдт
источник
3

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

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

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

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

Майк Кроуфорд
источник
3
«Возможно, ваш менеджер продлит свои сроки, чтобы дать им больше времени, чтобы привести вас в движение». - Я боюсь, что это не произойдет в реальном проекте ... если менеджеры не собираются сдвигать сроки, несмотря на то, что существующие разработчики находятся под жестким графиком давления, какова вероятность того, что они сделают это ради новичку не уделяют достаточного внимания?
Петер Тёрёк
1

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

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

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

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

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

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

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

peacedog
источник
0

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

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

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

timh
источник