Что такое командная работа в IT?
Публичный постЧасто слышу разговоры о том, как важно работать в команде, иметь навыки командной работы и т.д., но никогда не понимал, что это значит. Вот мы группой людей из разных стран работаем на типичной удалёнке — ставим и закрываем задачки в жире, советуемся и помогаем друг-другу и смежным отделам, делаем ревью PR на гитхабе, переписываемся в слаке по рабочим вопросам и иногда совсем чуть-чуть по личным, токсичного поведения ни разу ни от кого не видел, каких-либо интриг тоже — это уже команда или должно быть что-то большее? Что нас ей делает или, наоборот, чего нам не хватает? Догадываюсь, что могут существовать какие-то более сложные взаимоотношения, для которых действительно нужны какие-то особые навыки, но какие?
Какие есть паттерны или антипаттерны командной работы? Помню, наняли одного человека, дали для начала самую простую задачу, и он её делал неделю, потому что абсолютно во всём пытался разобраться сам. Сказали ему: ну ты это, если что-то непонятно, лучше спроси, чем время тянуть — и следующую самую простую задачу он снова делал неделю по той же причине. После нескольких итерации было решено, что у человека отсутствуют навыки командной работы. Это такой ярко выраженный случай, а у вас бывало что-нибудь поинтереснее?
По моему это - каноничный пример энтерпрайз-лицемерия и контр-командной работы, когда отсутствие хотя бы элементарного понимания того, как следует вести проект, вырождается в сваливание вины на исполнителя. Именно поэтому энтерпрайз называется кровавым и деградирует качество как разрабов, так и продуктов.
Мантра "если непонятно - спроси" в таких случаях - не решение. Чувак просто начнет ходить по людям и доставать их вопросами, и когда окончательно всех доконает, будет то же самое - "не командный игрок, всех достал", либо у чувака начнутся негласные проблемы рода "чет ты на синьора лицом не вышел, слишком много тупых вопросов задаешь".
Всегда есть причины, почему чувак работает над задачей неделю. Далеко не всегда это - некомпетентность чувака (такое бывает, но нечасто). Иногда это - проклятость самого кода (один взгляд на который вызывает мигрень и отчаяние). Иногда это - отсутсвие хоть какой то ретроспективы (ни тасок в тасктрекере, ни вменяемых комментов в коммитах, ни пулл реквестов, ничего - хрен пойми с чем работать). Если желание человека разобраться самому вдруг становится проблемой для команды, то root cause - точно не в человеке.
Впрочем эта тема уже выходит за рамки дискуссии об одной лишь командной работе.
В моём понимании, командная работа — это когда люди друг другу помогают. Задают друг другу вопросы, отвечают на них, могут друг другу передать задачу и в целом готовы поддержать. То есть, в буквальном смысле, когда каждый не за себя, а за команду и общие цели.
Из этого определения легко выводятся паттерны и антипаттерны.
Команда - больше, чем группа людей, работающих вместе.
В команде участники четко понимают и разделяют общие командные цели и свой вклад в команду, стремятся не только вносить индивидуальный вклад, но и помогать команде развиваться.
В общем, это про принадлежность к группе людей, имеющих общие интересы и ценности.
Соответственно, командная работа - та дополнительная ценность, которую ты создаешь не только как индивидуальный исполнитель.
Примеры командной работы:
Кстати, рекомендую подборку инструментов для управления и развития командой от Atlassian, например https://www.atlassian.com/team-playbook/health-monitor
Работать в команде - работать так, чтобы другим не было хуже.
Командная работа, как по мне, это работа всей команды над одной общей целью. Не один человек над частью цели, а вся команда сдаёт один элемент одновременно.
Как быть хорошим членом команды зависит от контекста. Есть разные способы существования команды, и в каждом способе ценится разное.
в этом описание нету ничего про команду и звучит оно так будто у вас коллектив "индивидуальных разработчиков". называть себя командой имеет смысл когда у вас появляется общая цель (и это не цель спринта, а более глобальный смысл), что-то вроде миссии существования вашего коллектива (писать код, даже самый крутой - это еще не миссия). причем эту цель должны одинаково понимать и принимать все члены вашей команды, как исполнители, так и менеджмент.
когда у всех членов команды есть одинаковое понимание проблемы которую они должны решить и одинаковое желание эту проблему решить, вот тогда они становятся командой и будут стремиться к тому чтобы минимальными усилиями нанести максимальную пользу. в скраме, к слову, ретро именно про это: "что мы должны изменить чтобы быть эффективнее?"
я не могу представить такую ситуацию, в команде со здоровой атмосферой. команда не стала бы перекладывать проблему на новичка "ну пиши если что", а пришла бы на помощь, убедилась что помогла во всем разобраться и подумала что нужно изменить в онбординге и документации, чтобы больше никто не залипал.
Тут наверное важный момент - способность здраво оценивать свои силы и понимать, когда нужно обратиться за помощью, когда ситуация позволяет потратить больше времени на задачу и попутно прокачать навыки работы с определённой частью системы/проекта. Ну и конечно помогает воспринимать конструктивную критику и отличать её от любых других неконструктивных выражений мнений другими людьми.
Из-за недостатка этой способности и появляется большинство проблем в командной работе.
Если человек считает, что он способнее и умнее, чем на самом деле, то он будет брать больше, чем может сделать, и обращаться за помощью позже, чем это будет нужно. Да и критику будет воспринимать с некоторым скепсисом, даже если она максимально конструктивна.
И тут же стоит упомянуть, что довольно многое зависит и от самой команды. Возможность критиковать без того, чтобы провоцировать конфликты должна поощряться. А просьба о помощи не должна никем восприниматься, как недостаток профессионализма у просящего.