Как быть с разработчиком, у которого плохие навыки, но с которым я хорошо лажу? [закрыто]

Я технический руководитель с 4 месяцев, как фрилансер, для конечного клиента.

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

На задачу, которую хороший разработчик выполнил бы за 1 день, он тратит 4 дня, и его решение никогда не проходит код-ревью за один раз.

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

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

Я не знаю, как взяться за это интервью.

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

Вы сталкивались с такой ситуацией?

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .

Ответы (5)

Стоит быть честным в вещах. Сокрытие или игнорирование проблемы только усугубит ситуацию в долгосрочной перспективе.

Парень, вероятно, знает, что он недостаточно квалифицирован/мотивирован, и, скорее всего, чувствует себя плохо из-за этого.

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

Будьте честны в обратной связи с Business Dev.

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

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

Я уже провел некоторое время месяц назад, разговаривая с разработчиком (один на один), он сказал мне, что ему нравится работать в таком месте, где ожидается «превосходство» (на уровне программирования), несмотря на его полное отсутствие навыки, о которых он, кажется, знает. Я не был очень строгим во время этого интервью и сделал ставку на его потенциальное улучшение в последующие дни.
Вероятно, стоит иметь в виду, что бизнес-разработчик также будет знать о способностях этого разработчика. Скрывать или не упоминать об этом может показаться странным.
@Paddy ... и создать (неверное) впечатление, что OP может не справиться с задачей оценки производительности.
@Mik378 Инвестиции обычно требуют времени, чтобы окупиться, если вообще окупаются. Это деловое решение, как и любое другое - может быть, ему просто нужно больше времени или другой подход... или, может быть, он тратит ваши ресурсы впустую. Когда я имел дело с некачественными разработчиками, я никогда не ожидал значительного улучшения в течение нескольких месяцев, и быть на должном уровне менее чем через год или два — некоторые люди могут вас удивить (хороший опыт, безусловно, помогает), но не Не нанимать невежественного парня, ожидая, что он поправится через месяц или два, это окажет вам обоим огромную медвежью услугу. Навыки не так просто получить.

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

Таким образом, фактический и профессиональный подход - лучший подход.

Было бы полезно, если бы вы также добавили, как может выглядеть разговор с BDev, когда речь идет о разработчике.

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

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

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

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

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

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

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

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

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

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

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

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

Еще немного мыслей после первых комментариев:

  • Вы работаете в стране, где потеря работы является большой проблемой?
  • Есть ли у вашего программиста потенциал или нет?

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

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

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

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

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

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

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