Как взять на себя задачу стажера, не чувствуя себя побежденным?

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

Итак, контекст таков, что я дал своему стажеру важное, но небольшое задание. Он должен был что-то запрограммировать в проекте, над которым я работаю. Либо он неправильно понял задание, либо я недостаточно хорошо объяснил его, но он сделал это неправильно. Его работа пока не завершена, но из того, что он написал, я могу сказать, что она не будет работать и что он неверно истолковал задачу (или она была недостаточно хорошо объяснена), и способ, которым он выполнял неправильную задачу, был нехорош. В его защиту скажу, что он учится на втором курсе колледжа, а я закончил его, так что у меня впереди несколько лет обучения и целый год опыта работы. Я хочу удалить его код, написать свой собственный и объяснить ему, как и почему я запрограммировал его таким образом, но я не хочу, чтобы он чувствовал себя глупым или чувствовал себя побежденным из-за неудачи. Причина, по которой я беспокоюсь, что он может чувствовать себя тупым, заключается в том, что я понятия не имею, как он хотел, чтобы это сработало, а также потому, что мне кажется, что это глупый способ сделать это, но я прекрасно осознаю тот факт, что я тоже писал глупости. во время моей стажировки, и я все еще пишу глупости по сравнению со многими другими людьми. Тем не менее, он потерпел неудачу. Мы все терпят неудачу в тот или иной момент.

Итак, как мне взять на себя его задачу и объяснить, как сделать это правильно, чтобы он не чувствовал себя побежденным из-за неудачи?

Пробовали ли вы разработку через тестирование? Если он может кодировать по набору тестов, то вероятность неправильной передачи задачи очень мала.
@StevenGubkin - кто пишет тест? Если он будет делать это сам, он просто напишет неправильные тесты.
@Davor Один из распространенных способов - разработчики пишут модульные тесты, а владелец продукта / босс / клиент - приемочные тесты. Код должен передать их, чтобы считаться «выполненным».
@Angew - Да, это звучит хорошо. Я имел в виду только юнит-тесты.
«Я хочу выбросить его код, написать свой и объяснить ему, как и почему я закодировал его таким образом»: наихудший из возможных способов научиться кодировать для него, а для вас — делегировать полномочия. Пожалуйста, избегайте.
При работе с менее квалифицированными людьми лучше сократить цикл обратной связи. Часто проверяйте их работу и убедитесь, что они на правильном пути. В конце концов, вы несете ответственность за их работу. Если они кодируют что-то не то, это только замедлит вас.
@FreeAsInBeer Я приму это во внимание. Мы проверим код до того, как они уйдут.
@coredump для этого уже слишком поздно. Он сказал мне, что понимает, что у нас нехватка времени, и я хотел научить его новому способу сделать это. Мы сели и прошли через мой способ сделать это, и через его способ. Я объяснил, почему он не был хорош (у него были жестко закодированные вещи, когда мы хотим, чтобы наш код был более надежным и гибким), я научил его методам хранения данных и объяснил, когда и где он был на правильном пути. и у меня была правильная идея, но нужно было что-то большее. Я не знаю, было ли это ЛУЧШИМ решением, но я не чувствую, что оно было неправильным.
@TomSterkenburg Я рад, что все прошло хорошо, похоже, у вас был хороший подход. Я беспокоился, что вы начнете покровительствовать стажеру и контролировать его на микроуровне (да, я склонен к пессимизму). Рад, что это сработало для вас.
@coredump Я понимаю ваши опасения, я бы тоже их принял. FreeAsInBeer предложил меньшие циклы обратной связи, поэтому сегодня я просмотрел его код для другой задачи, прежде чем он ушел. Это была определенно отличная идея, я смог указать на небольшие недостатки в его общем дизайне (не использовать геттеры, изменять глобальные переменные без необходимости) и убедиться, что он знает, почему мы хотели бы сделать это по-другому. Это немного похоже на микроменеджмент, но я думаю, что этот тип оправдан, потому что часть моей работы состоит в том, чтобы учить его, потому что он всего лишь студент второго курса колледжа. Я думаю, все прошло хорошо, спасибо всем за помощь!
Вы относитесь к людям так, будто несете за них ответственность. Молодец. Я бы купил тебе пива, если бы мог.

Ответы (7)

Лучше всего спросить его об этом: «Давайте посмотрим, что вы сделали для функции X. Каков был ваш общий план? Как вы собирали входные данные, обрабатывали их, производили вывод? Почему вы сделали ABC таким образом?». Как наблюдатель это не должно быть обвинительным. Это создает диалог, в котором вы можете увидеть, каков их план, и позволяет вам спросить их об их решении препятствий, с которыми они столкнутся.

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

Если у них нет удовлетворительного решения для данного периода времени, тогда это не должно быть суровым. «У нас сжатые сроки, поэтому я возьму это на себя. Это была хорошая попытка, я совершил аналогичную ошибку, когда был стажером. Пожалуйста (укажите другое задание)».

В конечном итоге выбрал этот ответ, потому что он больше соответствовал вопросу и моим временным рамкам. Он работает 2 дня в неделю и предпочел бы, чтобы последний день этой недели он провел, выполняя другую задачу. В коде часто разумнее начинать сначала, чем работать со сломанной системой, и я думаю, что это один из таких случаев. Лучше он начнет новую задачу заново после того, как я объясню, как и почему я отказался от его текущей задачи, чем мы будем тратить время, пытаясь преобразовать его текущий код в то, что я на самом деле имел в виду. Обязательно поработаем над общением.
@TomSterkenburg Обратите внимание, что делегирование работы также сопровождается освобождением контроля. Единственный момент заключается в том, что код должен на самом деле делать то, что он должен делать (недопонимание, которое, вероятно, является ошибкой с вашей стороны, но не волнуйтесь, правильное делегирование — довольно сложный навык, для его изучения требуется время). Добавление дополнительных ограничений также допустимо, но вы должны видеть грань между «важным ограничением» и «я бы так не поступил». В противном случае делегирование — просто пустая трата времени.
@TomSterkenburg Вы заявили, что стали разработчиком на полную ставку только с мая. Я думаю, что в вашей карьере слишком рано делать широкие обобщения, такие как «В коде часто разумнее начинать сначала, чем работать со сломанной системой...» Вы обнаружите, что часто вы не будете работать. в новых проектах, а работа со старыми системами и старым кодом, который на самом деле может быть сломан. Вы не сможете просто отказаться от старого кода и написать его с нуля.
@Moss Но в большинстве случаев было бы еще лучше отказаться от него ;-) То, что вам приходится большую часть времени работать с ужасной устаревшей системой, не означает, что это хорошо или разумно ... Иногда это необходимо
@Falco Большую часть времени было бы еще лучше отказаться от него? Верно. Попробуйте рассказать об этом компании с большой, сложной, устоявшейся системой, от которой зависит множество пользователей. Если это ваш любимый проект, над которым вы работали дома, прекрасно. Когда речь идет о реальных компаниях, бюджетах, финансах и репутации, сделать это непросто. Кроме того, решение сделать это может иметь катастрофические последствия .
Попробуйте парное программирование. Вы по-прежнему должны делать это правильно, а он учится, когда вы делаете это шаг за шагом.
@Moss В любом случае, мы не работаем с устаревшей системой, мы работаем с кодом, написанным 3 дня назад. Может быть, не «часто», возможно, лучше было бы сказать «иногда», но не будем зацикливаться на семантике. Я не думаю, что кто-то будет возражать, что иногда нужно начинать сначала. Это верно и для многих вещей в жизни. Может быть, не в этот раз, но в любом случае уже слишком поздно для этого

Одним словом... не надо. (Да, хорошо, это сокращение.)

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

Вы признали, что были проблемы со связью. Чтобы научиться делегированию, вам нужно научиться более эффективно общаться. Цикл общения включает в себя рассказ, слушание, обратную связь и исправление/пересказ; в этой последней части цикл начинается заново и продолжается столько, сколько необходимо. Похоже, что до сих пор вы пытались использовать только первые две части. Однако вам нужны вторые две части для обеспечения точной связи.

Я предлагаю вернуться к стажеру и сообщить ему, что вы двое неправильно общались. Просмотрите, каким должен быть проект, и убедитесь, что стажер хорошо его понимает; не позволяйте ему просто сказать: «Да, я понимаю». Попросите его повторить (своими словами), что он должен делать, и внести необходимые исправления. Затем попросите его составить план и просмотреть его, прежде чем он начнет программировать. Кроме того, сохраняйте непредубежденность; его подход не обязательно неправильный, просто потому, что это не то, что вы бы сделали; конечно, возможно, его подход не сработает, но ваша задача - подвести его к рабочему решению, а не делать это самому.

Единственное, что я бы добавил к этому ответу: в будущем не делегируйте важные задачи стажерам. Стажеры должны работать только над вещами, которые не имеют большого значения, если они не удаются.
Кроме того, я думаю, что вам следует иметь дело с меньшим количеством стажеров (одного для старшего работника должно быть более чем достаточно), чтобы иметь возможность должным образом наставлять их и иметь возможность выполнять некоторую работу самостоятельно.
@NotMe Я бы не согласился с этим мнением, по крайней мере, из-за того, как мое место работы обращается со стажерами. Им платят, и они здесь, чтобы получить ценный опыт, и я пытаюсь убедиться, что они его получат. Я действительно не могу дать им задачу, которая не важна
@TomSterkenburg, похоже, культура вашей компании склонна возлагать на стажеров немного больше ответственности, чем обычно (сейчас я нахожусь в похожей среде). Такая среда, вероятно, принимает тот факт, что работа стажера может не сработать, и понимает риск, который это может иметь для проектов. Я думаю, что владелец проекта должен внести свой вклад в то, обучаете ли вы своего стажера, чтобы вернуть задачу в нужное русло или взять ее на себя. Я не публиковал в качестве ответа, потому что это не дает совета по вашему фактическому вопросу. :)
@blaughw правильно. Ну, в данном случае я руководитель проекта. Это небольшой проект, но в основном я руковожу всем, включая взаимодействие с клиентами и все такое. Я решил просмотреть его код и мой новый код и посмотреть, что он задумал.
@TomSterkenburg Если вы действительно хотите, чтобы они научились, вы можете попросить их переписать свой код - на этот раз в соответствии с вашими стандартами. Я никогда не учился у людей, которые писали для меня код, я учился у людей, которые говорили мне, в каком направлении двигаться (использовать список для перебора, использовать технику-x и т. д.). Кроме того, не говорите никаких подводных камней, таких как «проверьте здесь на ноль». Это самые ценные. Кроме того, вы сказали, что взаимодействуете с клиентами. Включите стажеров в эту часть, если это возможно. Я всегда наслаждался такими моментами.
@EdwinLambregts Хороший совет, но, к сожалению, не в моей компетенции, взаимодействуют они с клиентами или нет. Они только уполномочены делать так много. Только сотрудники, работающие полный рабочий день, взаимодействуют с клиентами напрямую, хотя они могут видеть зарегистрированные ошибки клиента.
Этот. Если стажер не понял задачу, а вы не предпримете вторую попытку лучше ее донести, то как вы не почувствуете себя побежденным? Стажеры делают что-то медленнее, чем опытные сотрудники, но вы все равно должны пройти все этапы задачи, если это вообще возможно, а «выбросить ее и начать заново» — это этап любой задачи, где первая попытка совершенно бесполезна.

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

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

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

Теперь может случиться так, что вам нужно сесть с этим человеком и составить парную программу, если у него действительно очень мало знаний. Но в этом конкретном случае вы заставляете их придумать решение и просто останавливаете стажера, когда он начинает двигаться в неправильном направлении. Вы продолжаете задавать такие вопросы, как «Почему вы выбрали этот метод? Рассматривали ли вы... библиотеку? Как вы думаете, какое влияние это окажет со временем?» и т. д.

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

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

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

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

Подумайте о парном программировании со стажером. Либо парная программа просматривает их неправильный код и пытается его исправить, либо проходит их код, объясняет его недостатки и обсуждает и парная программа использует новый, лучший код. Парное программирование — лучший инструмент обучения, передача знаний, проверка кода, контроль качества — все в одном!

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

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

Парное программирование — это здорово, но если вы этим занимаетесь, стажер должен быть человеком, который на самом деле работает с клавиатурой.
Полностью согласен @HLGEM

Я хочу переписать его код, написать свой и объяснить ему, как и почему я написал его именно так.

Да! Сделай это!

Эрр, может быть.

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

Широко цитируемым примером является обучение правительства США методам обнаружения фальшивых денег. Людей обучали этому навыку, когда они хорошо знали, что правильно, а не изучали, что неправильно. Если код, созданный вашим коллегой, достаточно уныл, лучшим вариантом может быть исключение того, что бесполезно, и демонстрация того, что хорошо, и обсуждение того, что хорошо, и удостовериться, что он может делать то, что хорошо.

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

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

Если вы пытаетесь кого-то обучить, обязательно задавайте вопросы (в самом начале процесса), чтобы проверить понимание и определить, какой подход работает с пользой, а какой нет. Сосредоточьтесь на том, чтобы дать им структуру, в которой они нуждаются, с четко определенными желаемыми результатами и, возможно, даже четко определенными подходами, а затем предоставьте им задачу достижения простой для достижения цели, которую вы изложили. Что касается предоставления примеров (сделанных вами и сделанных им) и предоставления инструкций, полезность конкретного подхода будет зависеть от человека.

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

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

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

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

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

Как взять на себя задачу стажера, не чувствуя себя побежденным?
СпросиСетьПолитика конфиденциальности1y, 0v