Как вести себя с трудным застройщиком

Управляйте им, скорее раньше, чем позже. Краткосрочная боль от его потери заставит остальную часть команды узнать то, что знал незаменимый человек, и вдохновит меньше незаменимых людей в будущем. См. https://blogs.msdn.microsoft.com/eric_brechner/2018/02/01/good-engineers/

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

Обзоры кода

он провел рефакторинг какой-то части приложения, не посоветовавшись с командой

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

Обсуждение архитектуры

Он также выдвигает множество идей (в том числе архитектурных) и пытается их протолкнуть.

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

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

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

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

Профессиональный отряд

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

Один из самых ценных уроков, который может усвоить любой разработчик, — «Я — это не мой код». Атака на код, написанный разработчиком, никогда не должна рассматриваться как атака на разработчика. Похоже, ваш «проблемный» разработчик еще не научился этому. Есть другие разработчики? У вас есть?

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

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

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

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

Это управление заинтересованными сторонами 101. Как он участвует? Каковы его задачи? Какая информация вам от него нужна? Какая информация ему нужна от вас? Какие риски проекта вызваны им и какие действия мне нужно для их снижения? И так далее. Вы не собираетесь вытаскивать его из песочницы, поэтому вам нужно придумать, как с ним играть. Здесь нет простых ответов, но первое, что я бы сделал, это пригласил его в качестве партнера. Вовлеките его в обсуждение и рассейте вероятное отчуждение, которое он чувствует и на которое реагирует. Это манипуляция, но вы можете добиться от нее благоприятных результатов, а не пытаться с ней бороться.

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

1) Ведите журнал RAID, в котором регистрируются все риски, связанные с проектом. Это будет служить контрольным следом. 2) Каждый раз, когда возникает риск или проблема из-за символа x, сообщите об этом старшему руководству, показав им журнал RAID и то, как это повлияло на статус RAG проекта.

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

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

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

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

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

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

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

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

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