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

Это звучит, как вы делаете слишком много усилий на том, хорошо округлены лиц и не хватает усилия на том, хорошо округлены команда.

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

Вы заявили:

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

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

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

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

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

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

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

Стоит потерять какой производительности от вашего лучшие сотрудники, потому что они раздражают сердитый-Дэв? Вы'll должны решить.

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

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

2. стимулировать "От хорошего общения наша" либо с деньгами или другими благами. Дать понять, что вы на самом деле цените хорошие коммуникаторы и тогда ваши разработчики выиграл'т быть так раздражены, но награда должна быть реальной & значимым. на "обед с районным менеджером и" выиграл'т сократить его. Ни собой "звездный игрок/спасибо/молодец, что" награда's просто кусок бумаги. Его должно быть лишних денег, дополнительный отпуск, некоторые гибкого времени, серьезное признание с начальством, которые контролируют прибавку к зарплате и т. д.

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

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

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

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

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

Подсказка: прислушайтесь к ответу, как он'ы, разумный человек, а не людских ресурсов.

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

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

Что сказал, Это's наверное хорошо для разработчика с плохой навыков, необходимых для работы на них. Я хотел выяснить, что некодирующие что разработчик пользуется (или хотели бы делать), что предполагает больше навыков. Заставить их заниматься этой задачей, и в идеале они'МР улучшить навыки в качестве побочного эффекта.

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

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

Я'вэ видел разработчиков с 10, 15% other work (и была довольна собой, потому что это'ы прикольно, когда dose правильно), но 30% это слишком много. Я'd не думаю, что другие члены команды предпочитают не высказывать свои мысли, чем есть только один, кто не любит "и 30% прочие работы и".

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

• <суп>30+70, подведя к производительности 100% при переключении между программами и other work, никогда не произойдет в реальной жизни, это более вероятно, около 20+50 или 20+40. Переключение контекста является особенно болезненным для разработчиков программного обеспечения - если вы'повторно заинтересованы, проверить эту статью на хорошее объяснение почему: Дон'Т проснуться программист! Программисты, которые ценят их производительность, естественно, будет недоволен потери, как, что.ЛТ;/SUP и ГТ;

Что касается running tests часть работы, вы бы рассмотреть вопрос о принятии его в тестеры? Тот факт, что программисты can сделать это (я думаю, что любой опытный программист должен быть способен на это) не означает, что они should. Тестеры тоже можете это сделать, и они делают это лучше, и они выиграли'т нести потери производительности в "переключений контекста и".

Еще один момент, который заставляет меня задаться вопросом, как вы использовать ресурсы ОК-это ваше упоминание о Support / Investigation. Профессиональные тестеры, с которым я работала, как правило, "первый говорит:" в таких вещах.

• <суп>как бывший тестер себе, я их понимаю очень хорошо - производственные вопросы были для меня (как тестер) бесценный источник данных, чтобы узнать о тестировании покрытия ("имеют эту проблему правильно, охватываемых мои тесты?&и") и приоритетности дефектов ("и это'ы были покрыт тестами и сообщили до релиза, но я установить соответствующие приоритету / важности тогда?&и").</SUP и ГТ;

Это'ы довольно легко для хорошего тестера, чтобы выяснить, когда проходят исследования проблемы поддержки для разработчиков, и это происходит не очень часто. Причины перегрузки разработчики с этим просто убежать мой ум. Как я уже писал, они уверены, что can делать, что (I'd обычно ожидать, старший разработчик, чтобы знать, как делать что угодно ОК никак) но это не значит, что они should.

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

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

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

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

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

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

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

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

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

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

И наконец, самое главное, последующую беседу с физических лиц, или собрание команды, если это уместно. Если вы'вэ определены реальные организационные проблемы, которые в ваших силах, чтобы повлиять, рассказать своим сотрудникам о действиях, которые вы собираетесь предпринять для улучшения своего положения работы. Если вы все еще верите, что отдельные работники в неправильном, сесть с ним и объяснить, какие изменения вам нужно от него и почему. Разработчики, как правило, хорошо реагируют на логические/практические объяснения. "Это's не справедливо по отношению к своим сверстникам, чтобы дать вам все весело работать. Мы'd, как для всех вас, чтобы быть чистым, дэвы, но это's не реальная ситуация, поэтому мы должны разделить бремя дерьмовую работу.&и"

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

Я'м сварливого администратора Linux, который делает много сценариев, и было замечено, что у меня плохие навыки общения. Я сильно похожу на своего парня. В том, что'ы только уголок я вылететь в аттестации. С другой стороны, я'м непрерывно руководя своей командой в области инноваций и решения проблем, а также созданные под новую платформу, что мы'вновь выкатывает и спас свою команду много времени и много денег, поскольку ему позволили быть самим собой. Мой бывший босс спросил его семья/жена и наша компания'старшее руководство покинуть свою позицию .... одновременно. Он неустанно работал, чтобы сбалансировать достаточно обязанностей и взяли на себя нагрузку. При любом контакте с кем-либо вне Департамента, если произошло недоразумение общения, который вернулся к нему, он был быстро, ах, запредельно исправить. Он был беден на "Управление вверх," Так нашей команде был последним, чтобы получить ресурсы, пока это срочно, и то переплатил поставщикам с гладким продажи смолы для непроверенного оборудования, не посоветовавшись с командой, которая будет использовать эти инструменты. В стремлении создать на "сбалансированный" и сборной, он мелочным контролем наших списков задач и попыталась сбалансировать задачи так, чтобы члены команды могли улучшить свои навыки в тех областях, где они были'т большой, что повлекло за собой много разбитых код или плохо продуманных реализаций. В то время как люди, кроме автора были специально возложены задачи по поддержке, что сломанный код таким образом, чтобы они могли с "узнать" и -- плохо спроектирована реализации, код, и тесты, созданные много бедных доброжелательности между членами команды и вообще увеличение вхождения в "Кто виноват", который представляет собой быстрый маршрут до токсичного состояния. Мой нынешний босс-спокойный, собранный человек, который пришел в из роли младшего админа и работал его путь вверх. Он делает правильные решения и сильно зависит от членов команды, чтобы определить свои собственные приоритеты. Он является отличным коммуникатором и реагирует спокойно и в согласии со своим начальником любые проблемы коммуникация, идеи или потребности моей команды. Он "работает вверх" и без устали. Он'ы медленно принимать серьезные архитектурные изменения, и советуется тщательно со всей командой, прежде чем делать изменения в нашей окружающей среды и удобный с опорой на кухни из членов нашей команды. Под руководством нового тренера, наши простоев сократилось почти до нуля (что также сократилась доля времени, которое мы тратим на поддержку задачи от около 40% до около 10%), наша команда'ы удовлетворение и ушли через крышу, и мы'вновь на дорожку перешли от 'сорвать банк на новом оборудовании через каждые три-пять лет' для непрерывного плана закупок, которая должна сэкономить компании примерно миллион в год в течение пяти лет. Этот план был низовой программы, которые никогда не'вэ произошло при прошлом руководителе, а активно подтолкнули к высшему руководству новым менеджером и зависит от найти большое взаимодействие в команде's устанавливает навык. Мы've говорили неофициально ДИТ, что мы'вновь сейчас единственная команда в компании, которая действительно "есть свое дерьмо вместе" и что он's не собирается вмешиваться с нашей рабочей среде как можно меньше и перемешать столько ресурсов на проблемные зоны, которые мы выявляем, насколько это возможно. Этот вывод остается справедливым, и это'ов за рулем наших поддерживать "стоимость" и еще ниже, хотя она нарушается в некоторых других командах' нагрузки ... но это'ы движут те команды' поддерживать "стоимость" и нижней, а также. Смотрите, место для разработчиков, чтобы улучшить свои навыки в школе или на их собственное время. Место для них, чтобы производить вещи на ваша компания's время. Лучший способ создания вещей, производя то, что они лучше знают. При работе в местах, где один разработчик не комфортно, они должны тянуть на второй разработчик, который специализируется и работать в команде, или специализированных разработчик должен писать код и выпускать документацию и схемы. Поддержка маршрута задачи людям, которые писали код. Да, это увеличивает то, что мы называем вашу "автобусная фактор, что" -- вероятность вашего отдела наезд на "лежачего полицейского", если специалист должен сбить автобус. (Или увольняют, или сменить работу, или ...) правда в том, что ваша потеря производительности от страха на несколько порядков выше, чем фактические потери, когда А "событие автобус" и произойдет. Что обычно происходит во время на "автобусные событий" заключается в том, что наследником специалист's работы переделывает его по своему образу, так что он сможет максимально эффективно поддержать его, как правило, решить кучу проблем и снижение времени, затрачиваемого на поддержку еще дальше, и жизнь продолжается. Назначают людям, которые могут сделать их лучше. Заставить их поддерживать и документировать свою работу. Стимулировать их творческий потенциал и дать им возможность сосредоточиться, не отвлекаясь и не микроменеджмент. Все остальное управление-школа БС, который, к сожалению, звучит как ваша компания в плавание. Это вовсе'Т означает, что ваша команда должна плавать в нем тоже. От компании'с точки зрения, хороший менеджер продвигает ценности компании во время выполнения задач в соответствии с этими значениями. С ней работник'с точки зрения, хороший руководитель дает команду делать то, что's вправо, чтобы сделать максимально быстро и аккуратно, насколько это возможно, и выступает в качестве фекального барьер против высшего руководства толкает ценности, которые они узнали в выходные МВА классов в глотку на подчиненных. Вы'вновь быть человеком, и что не может быть лучшим для вашей команды. Те, с "хорошим" и коммуникативные навыки, которые просто слишком вежливы, чтобы сказать это.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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