Как быть с членом команды, который постоянно берется за задачи, которые не может решить?

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

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

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

Учитывая, что я хочу, чтобы мы работали как одна команда максимально эффективно, я попробовал несколько разных решений:

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

Обновление: спасибо за все ответы. Надеюсь, они и дальше будут полезны для будущих посетителей. Что касается моей истории...

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

Именно поэтому большинство компаний не позволяют людям выбирать, чем они хотят заниматься. Это работает только в том случае, если все действительно хороши и действительно ответственны. Интех реальный мир, что не правда.
Вы его менеджер?
Нет, я не. У нас одинаковые должности, но я проработал в компании примерно на пять лет дольше, чем он. Я был его наставником, когда он только начинал, и он слушает меня. Он почти никогда не бывает трудным или недружелюбным.
Разбить проблемы на более мелкие части? Заставить его писать проектную документацию, которая будет проверена коллективно? Отправить его обратно в школу (шучу)?
На самом деле очень хороший совет — разбить проблему на более мелкие части. Часто именно разработчик выбирает задачу, которая также отвечает за ее разбиение на подзадачи, поэтому мне не будет странным предложить ему разбить ее дальше, если он застрянет. Риск заключается в том, что мы получим что-то наполовину законченное, но это может быть более управляемой ситуацией.
Итак, для ясности, вы работаете в Agile-среде с действительно самоорганизующейся командой и без назначенного Scrum-мастера? И, чтобы еще раз внести ясность, здесь нет особого управленческого надзора? (например, никто не является непосредственным руководителем этого человека?) Я спрашиваю, потому что я был в такой ситуации и у меня есть ответ, но я хочу убедиться, что передо мной вся правильная информация....
Роль скрам-мастера распределяется между членами команды. У нас есть непосредственный менеджер, но он еще не вступил в должность. Мне все равно было бы интересно услышать ваше мнение!
Как вы ожидаете, что он научится решать проблемы. Если вы не позволите ему попытаться решить проблемы?
Его действия вызывают вопрос, почему он продолжает это делать? Похоже, он принимает вызовы с целью повысить свои навыки, чтобы получить новую работу с более высоким званием. Все ваши усилия, вероятно, являются бесплатной подготовкой его следующего шага.
Подумайте о том, чтобы снова получить наставничество, просто сядьте с ним и обсудите проблему, над которой он работает.

Ответы (7)

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

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

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

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

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

Теперь, после всего сказанного, вас (всех?) следует похвалить за то, что вы выбрали кучу вещей, которые совершенно разумны и обычно работают в таких ситуациях . Убрать немного возможность "выбирать" и прямо говорить человеку, что делать? Отличная идея, а также та, что менеджердолжны нести ответственность, а не члены коллектива, если только это не обременительно для вас всех (но будет). Подтолкнуть кого-то к правильному пути, которого они не видят? Супер - это форма сотрудничества. А если они не доберутся? Тогда их все еще нет, и вы находитесь в том же положении, плюс еще больше позади. Парное программирование? Блестяще - работает на многих людей, это отличная форма прямого сотрудничества, и то, что он не решался сделать это или сделать это хорошо, показывает, что существует проблема людей, которую должен решить кто-то, а не вы (например, менеджер ).

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

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

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

Знаете, есть причина, по которой на протяжении сотен лет задачи назначались менеджерами. Вы только что столкнулись с тем, почему.

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

Это не был бы мой первый вариант, но вы правы. Нужен барьер, который не позволит слишком неопытным членам команды просто вникать во что угодно, даже если это с самыми лучшими намерениями.
да, некоторые задачи требуют от вас определенного уровня знаний
Я собирался прокомментировать и спросить: «Кто менеджер?» потому что именно поэтому у вас есть (предположительно?) менеджеры.
Между прочим, «сотни лет» — это преувеличение, поскольку нынешняя концепция управления является продуктом промышленной революции и массового производства, и, возможно, ей меньше 100 лет.
Что ж, мастера, приказывающие своим ученикам, довольно стары. И почти вся управленческая наука в конечном итоге исходит из армейского прошлого, от греческих гоплитов и римских легионеров до Чингисхана ... Думаю, мы должны быть благодарны тому, что практика децимации не так уж модна.
Обучение навыкам (как кузнец, как заниматься сельским хозяйством, как булыжник) сильно отличается от офисной работы. В конце концов, вы узнаете, как сделать обувь у сапожника в первом случае, а во втором вы делаете то, что говорит босс, независимо от того, делает ли он обувь или пончик (даже если вы должны делать обувь), потому что это твоя работа. Нынешняя концепция «менеджмента» рождается на фабрике, где конечный продукт неясен, но есть цель добраться из пункта А в пункт Б.
@DeerHunter: Ну, увольнения — это современный инструмент уничтожения :)
@jmac Я не согласен с вашим утверждением, что они сильно отличаются от офисной работы ... только потому, что конечные результаты немного менее ощутимы, усилия направлены на достижение общей цели. Я предполагаю, что новый ученик кузнеца может задаться вопросом, зачем ему рубить деревья, а его мастер может не удосужиться объяснить, но древесина нужна для древесного угля, который нужен для огня, который нужен для плавки / кузнечного дела ... это управление в его основы.

Поощряйте его хорошие привычки

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

Определите его плохие привычки

Так в чем здесь настоящая проблема? Вы перечислили кучу симптомов:

  • Он не может решить проблему
  • Он задает вопросы без контекста
  • Он отнимает время у других разработчиков

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

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

Найдите способ обойти его плохие привычки

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

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

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

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

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

Я думаю, он осознает проблемы, которые создает, но это противоречит его стремлению проявить себя. Я сказал ему перед тем, как приступить к задаче, что он должен «почитать о технологии X», но это не помогло. Я чувствую, что для того, чтобы это сработало, мне нужно придумать что-то более конкретное, чтобы сказать ему. Хотя совет не плохой!

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

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

Это хорошая идея, но я беспокоюсь, что не могу постоянно следить за всем, что он делает. Часто мы не осознаем, что это проблема, пока не становится слишком поздно. Хотя мне очень нравятся ваши примеры фразировки!
Управление тем, кто какую работу выполняет, на самом деле является работой менеджера. Вы обсуждали с ним свои опасения?
Еще нет. Завтра у меня будет личная встреча с моим менеджером. Вот почему я задал вопрос, чтобы получить представление о том, как справиться с тем, что я считаю проблемой.

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

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

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

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

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