Я колебался, стоит ли вместо этого размещать это на программистах, но я думаю, что эта проблема вообще применима.
У нас есть младший член команды (около двух лет в компании), который продолжает ставить перед собой большие и сложные задачи, которые больше подходили бы более старшему разработчику. Поскольку любой может выбрать любой элемент из бэклога, избежать этого сложно.
Это, конечно, хорошо, что он честолюбив, но когда он застревает, он впадает в отчаяние. Вместо того, чтобы сделать шаг назад и подумать, почему что-то не работает, он часто заходит слишком далеко по ложному пути. Затем он начинает бомбардировать других разработчиков вопросами, на которые мы часто не можем ответить, потому что он не дает контекста.
Учитывая, что я хочу, чтобы мы работали как одна команда максимально эффективно, я попробовал несколько разных решений:
Обновление: спасибо за все ответы. Надеюсь, они и дальше будут полезны для будущих посетителей. Что касается моей истории...
Я обсудил это с моим менеджером (который уже наблюдал за поведением) и предложил попробовать включиться раньше и постараться убедиться, что он разбивает слишком большие задачи на более мелкие части. Мой менеджер был больше склонен прямо сказать ему, чтобы он не брался за сложные задачи. Я не совсем доволен, но посмотрим.
Самоорганизующиеся команды в Agile-среде разработки (на самом деле, в любой среде) могут творить чудеса и давать отличные результаты, как материальные (продукт), так и нематериальные (культура, мораль и т. д.). Но в основе работы самоорганизующихся команд обычно лежат следующие основные принципы :
Судя по тому, что вы описываете, у вашей команды есть некоторые проблемы с тремя из этих вещей: кто-то некомпетентен в каком-то аспекте работы, попытки сотрудничать и решить эту проблему не идут хорошо, и из-за этого, вероятно, страдает доверие и уважение. также.
Как вы хорошо знаете, это не делает команду счастливой и продуктивной... а это именно то, что есть у менеджера команды (или руководителя команды, или как вы называете человека, которому члены команды официально подчиняются) вмешиваться и управлять человеком , у которого возникли трудности с каким-либо аспектом процесса из-за чего-то, чего ему или ей не хватает. В этом случае неумение адекватно оценивать поставленные задачи, неумение просить о помощи и продуктивно сотрудничать и т. д.
Это не то, что должна решать остальная часть команды, даже если вы самоорганизующаяся команда; есть еще функциональный менеджер, чья работа должна заключаться в решении этих вопросов.
Теперь, после всего сказанного, вас (всех?) следует похвалить за то, что вы выбрали кучу вещей, которые совершенно разумны и обычно работают в таких ситуациях . Убрать немного возможность "выбирать" и прямо говорить человеку, что делать? Отличная идея, а также та, что менеджердолжны нести ответственность, а не члены коллектива, если только это не обременительно для вас всех (но будет). Подтолкнуть кого-то к правильному пути, которого они не видят? Супер - это форма сотрудничества. А если они не доберутся? Тогда их все еще нет, и вы находитесь в том же положении, плюс еще больше позади. Парное программирование? Блестяще - работает на многих людей, это отличная форма прямого сотрудничества, и то, что он не решался сделать это или сделать это хорошо, показывает, что существует проблема людей, которую должен решить кто-то, а не вы (например, менеджер ).
Руководитель группы, который мне подчиняется, недавно столкнулся с точно такой же ситуацией, и мы вместе проработали каждый из вышеперечисленных шагов, 1:1 между этим менеджером и его не совсем на должном уровне сотрудником, который портил все остальное. команда, и в результате член команды был уволен - не из-за того, что все не старались, а из-за недостаточной пригодности и в некоторой степени компетентности.
Итак, решение, которое вы все должны принять, заключается в том, что вы не можете принять решение. Пожалуйста, вовлеките своего менеджера и сформулируйте проблемы так же четко, как здесь, с точки зрения того, что вы пробовали, где что-то пошло не так, и где вам и вашей команде нужна помощь.
Знаете, есть причина, по которой на протяжении сотен лет задачи назначались менеджерами. Вы только что столкнулись с тем, почему.
Если вы хотите продолжать делать это (я признаю, что это нынешняя причуда — я чувствую, что она была недостаточно продумана), то, возможно, вам нужно классифицировать задачи по тому, какой тип или уровень разработчика может их выполнять. Если кто-то хочет перейти на более старшую роль или на роль, выходящую за рамки его текущего опыта, то, возможно, ему разрешается брать на себя эти задачи, но только с определенным типом руководства (например, в паре) или только с одобрения. руководителя группы после того, как человек обосновывает, как он справится с этим. Это катастрофа — позволять разработчикам сходить с ума по задачам, для выполнения которых они в настоящее время не обучены или не имеют достаточных суждений или опыта, чтобы справиться с ними. Это плохо для компании, это плохо для клиентов и, в конечном счете, плохо для разработчиков, которые выходят за рамки.
Принимать вызовы — это хорошо. Задавать вопросы — это хорошо. Пытаться разобраться самому — это хорошо. Какое бы решение вы ни выбрали, убедитесь, что вы не нанесете вреда его положительным качествам как члена команды, иначе в долгосрочной перспективе вы пострадаете.
Так в чем здесь настоящая проблема? Вы перечислили кучу симптомов:
Но почему это происходит? Какая на самом деле плохая привычка лежит в основе такого поведения? Неужели он не понимает, когда откусывает больше, чем может прожевать? Может быть, у него слишком много гордости, чтобы просить помощи в решении проблемы с самого начала, с тех пор как он ее выбрал? Может быть, он хочет узнать что-то новое, но у него нет простого способа получить руководство, когда он не может оправдать это как часть решения проблемы?
Я бы предложил вмешаться раньше. Поскольку вы были его наставником, и он доверяет вам, вы могли бы вмешаться в процесс раньше, не угрожая, чтобы дать ему возможность легко рассказать о том, что он делает с вами. Что-то вроде: «Вау, проблема, над которой вы работаете, кажется действительно интересной задачей. Мне бы хотелось услышать, как вы об этом думаете — я всегда ищу новые способы решения этих более сложных проблем». Это безопасный способ увидеть, в чем заключается реальная проблема, и он помогает войти в нее на более ранней стадии.
Вырастить талант гораздо проще, чем исправить вредные привычки. Если вы лучше поймете его мотивацию и то, почему он сталкивается с проблемами, вы сможете найти лучший способ избежать этих ловушек, сохраняя при этом его мотивацию и используя эти хорошие привычки наилучшим образом. Если он хочет получить положительные отзывы о решении сложных вопросов, вы можете предложить ему хорошие задачи, которые не будут ему мешать, и обязательно похвалите его, когда он хорошо поработает. Если ему нужна поддержка на ранних этапах, чтобы проработать всю проблему до того, как он начнет, вы можете найти способ выделить время во время групповых собраний для мозгового штурма или иным образом создать возможность, чтобы он работал с кем-то над концептуальным вопросом. стадии (но не до уровня парного программирования).
Всегда легче сосредоточиться на плохих привычках, потому что это всегда надоедливые вещи, которые вызывают проблемы у других людей. Проблема в том, что сосредоточение внимания на плохих привычках без развития хороших рискует убить мотивацию и притупить его природный талант, заставив его сосредоточить свою энергию на том, в чем он не силен.
Вам не нужно быть менеджером, чтобы вести себя как менеджер, поддержка членов команды является хорошей практикой для всех на любой должности.
Вероятно, вам следует заранее поговорить о его негативном влиянии на рабочий процесс команды, когда он «откусывает больше, чем может прожевать». Если вы можете привести конкретные примеры того, где он уронил мяч и как это повлияло на команду. Цель должна заключаться не только в том, чтобы он перестал выходить за рамки своих возможностей, но и в том, чтобы разработать стратегию оттачивания навыков, необходимых ему, чтобы стать лучшим программистом. По крайней мере, вы протягиваете руку и ведете беседу.
Попробуйте порекомендовать ему какие-нибудь проекты, вы можете обыграть это так, как будто они важны и должны быть выполнены немедленно. Если это не сработает, отведите его на минутку в сторону и усадите. Объясните ему, что важно усвоить основы, и, поскольку он знает об этом в компании, ему следует сосредоточиться на других задачах. Не говорите ему браться за более простые задания, найдите альтернативный способ сказать это; например, возьмем задачу, которая использует только эти 3 файла, которые обычно используются (или что-то еще). Вы можете упомянуть, как он часто путается в некоторых задачах, и сказать, что лучше всего брать менее существенные и короткие задачи.
Вы можете сказать что-то вроде: «Я знаю, что вы амбициозны, и это здорово, но, учитывая, как вы застряли на этих задачах, вы должны сначала ознакомиться с более простыми, такими как эти».
Если у вас есть эта проблема, то у остальной части команды будет такая же проблема. Мне любопытно, почему это не передается руководителю команды, потому что, очевидно, это повлияет на ход проекта в результате дополнительных задержек, вызванных неэффективностью. Поскольку это командная среда, и людям действительно нужно работать вместе гармонично, это следует решать вместе, как команда, чтобы он также не принял это слишком близко к сердцу. В худшем случае человек не подходит для команды (технически или социально) и его, возможно, придется удалить (если ничего не работает). Но на самом деле это не ваша проблема, а проблема лидера/менеджера группы, поэтому убедитесь, что она поднята с соответствующими лицами.
Будем надеяться, что менеджер разберется с этим, так что будьте откровенны с этим человеком и расскажите ему о положении, в которое он всех поставил, когда менеджер попросит оставить отзыв. Дайте ему знать, что вы не собираетесь лгать, и вот что я собираюсь сказать.
Предложение помочь. Если вы считаете, что он взял на себя слишком большую задачу, установите рекомендации. Дайте ему понять, что он может потратить на это короткий промежуток времени, а затем показать какой-то прогресс или выйти из задачи. Разрешайте вопросы в определенное время. Ему не разрешено просто прерывать. Некоторое время он злоупотреблял этой привилегией.
Если он не хочет заниматься парной программой, не стоит ожидать, что она сработает поначалу. Он будет сопротивляться и быть трудным, как ребенок. Будет хуже, прежде чем станет лучше. Вы чувствуете, что это важно, придерживайтесь этого до тех пор, пока он не присоединится к вам или не столкнется с последствиями. И должны быть последствия.
Мне кажется, каждому было бы лучше, если бы он ничего не делал вместо всех этих контрпродуктивных усилий. Даже если он поручает себе задачу, поручите ее и кому-то еще. Я просто не понимаю, что ты теряешь. Босс поймет это намного раньше.
HLGEM
ЦинциннатиПрограммист
свиристель
Охотник на оленей
свиристель
джкмелони
свиристель
пользователь5305
Крис Шиффхауэр
Турбьёрн Равн Андерсен