Как некомандный игрок отвечает на вопросы о командной игре [закрыто]

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

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

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

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

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

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

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

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

Например, он обычно:

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

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

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

Это несправедливо? Абсолютно нет — компания предлагает много $$$$$ сотрудникам и часть этой работы предполагает работу в командах. Если он не хочет этого делать, то он не имеет права расстраиваться из-за того, что компании ему отказали.

Начну с того, что он прав.

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

Это также ограничено темпом одного человека - если проблема достаточно мала, это абсолютно выполнимо.

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

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

Если он твердо намерен не совершенствоваться в этой области, я бы посоветовал ему:

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

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

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

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

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

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

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

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

Обратите внимание, что всегда неудобно говорить «твой друг», поэтому для краткости я буду говорить «ты».

Так что делать?

1. Как говорит enderland , вы можете создать свою собственную компанию и никогда больше не иметь дела ни с кем другим, кроме клиентов, бухгалтеров, дизайнеров и т. д. (все они могут заставить других разработчиков выглядеть невероятно легко работать).
2. Станьте настолько хороши, работая самостоятельно, что всегда найдутся компании, которые наймут вас и запихнут в какую-нибудь комнату, просто чтобы полакомиться вашим талантом. Проблема в том, что есть много навыков, которые вам, вероятно, потребуются, чтобы достичь того уровня, которого вы вряд ли сможете достичь, работая самостоятельно, например, использование контроля версий и архитектуры, чтобы менее квалифицированные разработчики могут использовать ваш код. Есть также проблема, что есть так много хороших разработчиков, что даже если вы доберетесь до этого уровня, у вас не будет возможностей, если вы не сможете заявить о себе — выступая на конференциях, или написав книгу, или что-то в этом роде. И то, и другое требует, чтобы вы хорошо справлялись с людьми.
3. Посмотрите на человеческие навыки как на любые другие навыки и работайте над ними. Обратите внимание, что изменить своего основного персонажа очень сложно , поэтому у вас, вероятно, всегда будут «проблемы». Но вам нужно с чего-то начинать — так же, как вы начали со своими навыками программирования. У вас будет возможность освоить технические навыки, полученные при работе в команде, и вы даже можете чему-то научиться у тех, с кем у вас есть возможность работать. Я думаю, вы должны быть честны, что это не ваша сильная сторона, но вы готовы работать над этим. Может быть, кто-то рискнет на вас. В то же время, возможно, работа над проектом с открытым исходным кодом даст вам возможность попрактиковаться, не прося кого-то воспользоваться этим шансом вместе с вами.

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

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

К счастью, и то, и другое можно решить с помощью самопомощи или, что еще лучше, с помощью тренера на рабочем месте.

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

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

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

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

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

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

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

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

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

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

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

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