Как управлять разработчиком, у которого плохие навыки общения

Я управляю небольшой командой разработчиков над приложением, которое находится на середине своего жизненного цикла, в большой фирме. Это, к сожалению, означает, что обычно 30/70 делят задачи по программированию на «другие технические работы». Эта работа включает в себя:

• Работа с командами DBA / Unix / Network / Loadbalancer над различными задачами
• Размещение и управление заказами на оборудование или инфраструктуру в разных регионах
• Запуск тестов, которые еще не были перенесены в CI
• Анализ
• Поддержка / Расследование

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

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

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

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

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

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

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

Вы заявили:

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

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

Как менеджер, вы не должны следить за тем, чтобы все были «хорошо округлены». Это ваша работа, чтобы убедиться, что s *** сделано. И ты этого не делаешь. На самом деле, вы принимаете решения, которые мешают что-то сделать.

Какие бы проблемы у вас ни возникали, вам нужно преодолеть их - вы делаете свою команду менее продуктивной.

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

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

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

Стоит ли терять продуктивность от ЛУЧШЕГО ИСПОЛНИТЕЛЬНОГО ПЕРСОНАЛА, потому что они раздражены раздражительным разработчиком? Вам придется решить.

Если вы не хотите уволить парня, я предлагаю вам воспользоваться одним из следующих подходов:

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

2) Стимулируйте «хорошее общение» либо деньгами, либо другими льготами. Дайте понять, что вы действительно цените хороших коммуникаторов, и тогда ваши разработчики не будут так раздражены, но награда должна быть реальной и значимой. "Обед с окружным управляющим" не будет сокращен. Также не будет награды «звездный игрок / престижность / аттабой», это просто лист бумаги. Должны быть дополнительные деньги, дополнительный отпуск, некоторое свободное время, серьезное признание со стороны старших руководителей, которые контролируют повышение заработной платы и т. Д.

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

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

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

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

Может быть, он просто ненавидит свое положение за столом (он смотрит в туалет?), И это вызывает у него плохое настроение.

Подсказка: слушайте ответ, как будто он разумный человек, а не человеческий ресурс.

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

Люди разные. Как менеджер, вы должны относиться к людям по-разному (но справедливо!), Чтобы получить максимальную отдачу от вашей команды.

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

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

Разделение 30/70 может быть там, где начинаются все ваши проблемы. Я никогда не видел разработчиков, довольных таким расколом.

Я видел, как разработчики чувствовали себя комфортно с 10, 15% других работ (и сам был счастлив, потому что это весело, когда доза верна), но 30% - это слишком много. Я предпочел бы думать, что другие члены команды предпочитают не высказывать свое мнение, потому что есть только один, который не любит «30% другой работы».

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

• ^{30 + 70, суммируя до 100% производительности при переключении между программированием и другой работой , никогда не случится в реальной жизни; это скорее около 20 + 50 или даже 20 + 40. Переключение контекста особенно болезненно для разработчиков программного обеспечения - если вам интересно, обратитесь к этой статье за ​​хорошим объяснением того, почему это так: НЕ ПРОБУЖДАЙТЕ ПРОГРАММИСТА!
  Программисты, которые ценят свою производительность, естественно, будут недовольны такими потерями.}

Что касается выполнения тестов - часть работы, вы рассматривали возможность передачи тестерам? Тот факт, что программисты могут сделать это (я думаю, что любой опытный программист должен быть способен на это) не означает, что они должны . Тестеры тоже могут это делать, и они делают это лучше, и они не понесут потери производительности при «переключениях контекста».

Еще один момент, который заставляет меня задуматься о том, как вы используете ресурсы QA, - это упоминание о поддержке / расследовании . Профессиональные тестировщики, с которыми я работал, имеют тенденцию «первым говорить» в подобных вещах.

• ^{Как сам бывший тестировщик, я понимаю их довольно хорошо - проблемы с производством были для меня (как для тестировщика) бесценным источником данных для изучения охвата тестированием («эта проблема была должным образом покрыта моими тестами?») И для расстановка приоритетов дефектов («хорошо, это было проверено тестами и сообщалось перед выпуском, но установил ли я соответствующий приоритет / серьезность тогда?»).}

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

У меня есть 2 вещи, чтобы сказать по этому

1. Вы наняли кодера или разработчика программного обеспечения?
   Когда вы рассматриваете разработчика программного обеспечения, все, что вы упомянули, является неотъемлемой частью разработки программного обеспечения. Вы просто не можете игнорировать это, если только вы не приняли на работу только для конкретной задачи. ИМО 50% всей разработки программного обеспечения - это кодирование, остальное - это дизайн, анализ, тестирование, документация и т. Д.

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

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

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

Но я все еще думаю, что вашим главным приоритетом, вероятно, должно быть соблюдение ваших сроков (что вы все равно сможете сделать, равномерно распределяя работу).

РЕДАКТИРОВАТЬ: Если у вас небольшая команда, вероятно, имеет смысл, чтобы все участники могли носить несколько шляп. Если у вас достаточно большая команда, возможно, имеет смысл иметь группы, специализирующиеся в разных областях. Из вашего поста видно, что у вас недостаточно большой команды, чтобы иметь группы специалистов.

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: Кроме ваших личных чувств, вы не определили проблему. В какой-то момент отсутствие связи мешает программисту. Другие проявят негодование, и их работа может пострадать. Пока что вы, похоже, единственный, у кого проблема. Разве есть что-то еще, чем вы не делитесь?

РЕДАКТИРОВАТЬ 2 В конце концов, все будут просить особую услугу. Этот человек делает меньше общения и больше кодирования (что он должен всеми счетами). Кто-то хочет прийти немного позже. Другой должен будет пропустить встречу, чтобы уложиться в срок. Графический человек получает больший монитор. Когда вы слишком много внимания уделяете ведению счета, вы забываете, что важно.

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

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

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

При новом менеджере время простоя сократилось почти до нуля (что также сократило процент времени, которое мы тратим на задачи поддержки, с примерно 40% до примерно 10%), удовлетворение нашей команды достигло предела, и мы на пути к тому, чтобы перейти от «ломать банк на новом оборудовании каждые три-пять лет» к плану непрерывных приобретений, который должен сэкономить компании около крутого миллиона в год в течение пяти лет. Этот план представлял собой низовую программу, которая никогда бы не произошла при прежнем менеджере, но новый менеджер активно продвигал ее к высшему руководству и зависел от нахождения МНОГО синергизма в наборах навыков команды. Мы неофициально сказали ИТ-директору, что теперь мы единственная команда в компании, которая действительно «сплетничает» и что он Мы будем как можно меньше вмешиваться в нашу рабочую среду и перенаправлять как можно больше ресурсов на проблемные области, которые мы определим, насколько это возможно. Это подтвердилось, и это снижает стоимость нашей поддержки еще ниже, хотя и нарушает рабочую нагрузку некоторых других команд, но также снижает стоимость поддержки этих групп.

Посмотрите, разработчики могут улучшить свои навыки в школе или в свободное время. Место для их производства - время вашей компании. Лучший способ производить вещи - создавать то, что они знают лучше всего. При работе в областях, где одному разработчику неудобно, им следует привлекать второго разработчика, который специализируется и работает в команде, или же специализированный разработчик должен написать код и создать документацию и диаграммы. Направляйте задачи поддержки людям, написавшим код. Да, это увеличивает то, что мы называем вашим «фактором шины» - вероятность того, что ваш отдел столкнется с проблемой, если специалист столкнется с автобусом. (Или уволены, или поменялись местами, или ...) Правда в том, что ваша потеря производительности из-за этого страха на несколько порядков выше, чем фактическая потеря при "автобусном событии" случается. Что обычно происходит во время «автобусного события», так это то, что наследник работы специалиста переделывает его по своему собственному образу, чтобы он мог наиболее эффективно поддерживать его, обычно решая кучу проблем и сокращая время, затрачиваемое на поддержку, и жизнь идет дальше. на.

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

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

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

Это всего лишь краткие идеи, надеюсь, кто-то украдет эти пункты и сложит их в один из других ответов. ;-)

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

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

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

Теперь, как отмечается во многих постах, работа не справедлива и не должна быть. Менеджеры оценивают, сколько ценной работы сделано.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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