Как работать с неквалифицированным сверстником, который не уходит? [дубликат]

Я работаю в группе А крупной компании старшим разработчиком программного обеспечения/тимлидом. Группа А содержит почти все функции разработки программного обеспечения внутри компании.

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

Теперь беда двоякая:

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

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

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

Примечание о дубликатах: я читал Как поступить с некомпетентным коллегой? , но я думаю, что это другой вопрос, так как в этом случае нет реального способа убедить людей, наделенных полномочиями удалить Архимеда из проекта (руководство группы B), что он недостаточно хорош, а также мое местное руководство прямо сказало не сделать это. Точно так же я на самом деле не думаю, что это тот же вопрос, что и вопрос о том, как не допустить, чтобы некомпетентность коллеги повлияла на мою производительность - моя личная производительность здесь на самом деле не сильно пострадала, поскольку мне не нужно напрямую исправлять Ошибки Архимеда - но продуктивность команды есть.

Знает ли Архимед и заботится ли он о том, что он не в себе? Если он захочет учиться, это изменит мой подход. Поскольку он единственный разработчик в своей группе, он, вероятно, странный человек и может быть рад тесному сотрудничеству со всеми вами.
@ColleenV Честно говоря, я не знаю, что думает Архимед; к настоящему времени он, должно быть, осознает, что не в себе, но я не знаю, хочет он это исправить или нет.
Мне нечего добавить к уже написанным ответам, но я думаю, что открытие линий связи и попытка включить его помогут частично решить проблему. Связь между разработчиками может превзойти искусственные ограничения отчетных структур ;) Если вы приветствуете, он, скорее всего, признает, что перестарался, и не станет защищаться. Конечно, это зависит от его личности, но попытка не повредит. Может быть, разработчик только обедает, чтобы заняться тимбилдингом?

Ответы (3)

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

ОП не указывает, согласен ли Архимед с точкой зрения ОП. Я предполагаю, что Архимед, по крайней мере, знает о пробеле в навыках.

Какие существуют стратегии работы с Архимедом, чтобы попытаться сделать проект успешным?

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

Как и раньше, поручите Архимеду более простые задачи . Сделайте предварительный дизайн, чтобы определить и разделить простые задачи. Точно так же убедитесь, что он работает над своими сильными сторонами (например, внешний интерфейс, база данных, язык X).

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

Тем временем используйте другие навыки Архимеда (если они есть). Например, есть ли у него опыт работы в сфере бизнеса? Если да, дайте ему несколько задач в стиле бизнес-аналитика. Может ли он заниматься отслеживанием проекта/работой scrum master? Может ли он помочь с написанием автоматизированных тестов или тестированием производительности? Может ли он поддерживать существующие системы? Может ли он писать документацию? Может ли он убедиться, что титульные листы TPS верны? Это может освободить других членов команды для работы над более важными вещами.

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

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

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

Мне нравится этот конструктивный ответ. Цель состоит в том, чтобы повысить производительность, а не избавляться от людей
Это путь. Я согласен с отслеживанием прогресса и задач каждого. Таким образом, когда что-то идет не так, вы можете поднять все эти проблемы и сказать, что они были обнаружены на ранней стадии, но руководство не хотело с этим иметь дело.
+1 - один незначительный комментарий: группа А должна была участвовать в процессе найма - нам сказали, что мы будем участвовать, но внезапно следующее, что мы узнали, это то, что Архимед был нанят.

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

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

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

нет реального способа убедить людей, наделенных властью, убрать Архимеда из проекта

Так что «уберите» его из проекта.

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

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

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

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

Как работать с неквалифицированным сверстником, который не уходит? [дубликат]
СпросиСетьПолитика конфиденциальности1y, 0v