забей, просто игнорируй эту строчку, когда читаешь вакансии, считай, что это комментарий, а не код

Я хочу знать наверняка. Если я был командиром в октябрятской звёздочке - это говорит о моих навыках командной работы? А если старостой в ВУЗе, секретчиком и командиром отделения? Как мне доказывать эти скиллы в резюме?

Может им нужны только координаторы проектов github? Или ещё какие варианты есть?

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

Или когда ишут виновного, а ты знаешь кто виноват — молчать в тряпочку или врать, что виноваты тестеры, менеджеры, да кто угодно, но не твоя команда :))

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

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

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

А ещё в работу в команде входит обучение людей и ввод в курс дела над проектом.

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

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

Ммм, у нас появился гуру-анализатор вакансий!

man коммуникабельность

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

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

это некомандное поведение

Откуда ты знаешь? А если знаешь, зачем спрашиваешь?

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

предлагаешь увольнять сотрудников

а это - командное поведение, вот кейс с HR-сайта:

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

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

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

Откуда уверенность что ты в пятерке

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

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

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

я так и думал. А то понапишут на сайтах:

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

и сиди, догадывайся, что они имели в виду под этими общими фразами...

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

Если ты сам не можешь справиться - то слабак и неосилятор, отвлекаешь людей

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

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

общаться с коллегами только посредством почты.

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

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

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

С такими взглядами работать в команде не стоит - лучше одному. Всем только лучше будет.

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

Такой подход, имхо, тоже имеет право на существование

тестеры, которых я видел, так не делали, потому что у них KPI - количество найденных и зафиксированных багов.

баги находят не только тестеры

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

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

Это значит, что если ты и твоя команда работаете над фичей, вы можете между собой договориться, кто чем занимается. И не будете кричать «а я это не сделал, я думал этим Вася будет заниматься, и вообще это не моя работа!»

в таком случае баги передают в коллцентр, оттуда тестерам на воспроизведение и фиксирование.

баг может найти твой коллега, который работает над другим модулем.

И вообще ты пишешь про очень крупную dev-контору, а когда 5 разрабов и один тестер, то какой колл-центр нафиг? А в команде работать все равно надо.

И это только про баги, а еще ведь есть обсуждение, планирование и т.д.

по твоей схеме функционирования опенсурса бы не было )

как раз опенсорс именно так и работает - всё через багтрекер.

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

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

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

Вообще умение работать в команде это большая и интересная тема.

И помнить, что инициатива наказуема :)))

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

Тут не угадаешь. А вдруг надо было применить логику и сделать правдоподобные предположения, зафиксировав их? Позвонишь HR с вопросами, а тебе скажут «несамостоятелен» => не подходит.

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

Критерии эффективности разные. И эти критерии - не угадаешь.

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

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

Объем делегирования разный.

Мы искали эффективных именно по критерию готовности работать в команде. Этот тест выявляет именно таких. Естественно он был не единственный.

То есть, если бы сотрудник продумал варианты решений, зафиксировал их и когда был готов к дальнейшему разговору с демонстрацией решения/вариантов - обратился к HR, вы бы такого не приняли?

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

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

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

Все может быть. Платили хорошо, желающих было достаточно.

Про бухло ты не думал ?

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

Все ясно, в команде ты работать не умеешь....

Ты хоть раз работал на проекте больше хелловорлда?

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

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

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

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

Это не отменяет необходимость писать документацию, но документация — это совсем не то.

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

В аджайле нет смысла эскалировать проблему «Х меня блокирует» на какого бы то ни было менеджера: он таски конкретным исполнителям не назначает. Проблема решается опять же взаимодейтсвием людей.

А по мне так почта нужна только в четырех ситуациях:

• Нужна история, которая будет важна и через месяц, и через два, и через три;
• Автоматически либо массово отправляемые вещи;
• Нужны ссылки, аттачменты и всё остальное, что нельзя передать при личном общении (но тут катит IM);
• По каким-либо причинам более «человечные» способы (IM или личное общение) неприменимы;

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