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

Максим, бизнес-аналитик

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

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

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

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

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

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

Ну и здесь менеджер должен вступить в конфликт и определить приоритеты. Мы должны сделать на сайте меньше вкладок, но сделать их красивыми. Либо наоборот, сделать большой объем страниц, которые будут хорошо работать, но плохо выглядеть.

Прелесть в том, что решение принимает начальник. И в случае недовольства заказчиков и отказа платить вся ответственность ляжет на руководителя проекта. Ведь именно он принимал решение.

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

Этим мне и нравится моя сфера. Все очень четко. И вот, если такого рода конфликты существуют, а начальник закрывает на это глаза, не хочет брать на себя ответственность – заказчик не доволен, а руководитель обвиняет сотрудников.

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

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

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

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

Евгений, Software developer

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

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

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

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

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

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

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

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

Так вот, мой PM собрал очень большую команду, около 30 человек. Они разбивались на 3 маленькие подкоманды, в каждой из которых были свои тех. лид, разработчики, лид. тестировщик, тестировщики и по одному бизнес-аналитику. Плюс, на все 3 команды были еще один Project Manager и один тех. лид. 

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

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

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

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

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

Ангелина, UX/UI Designer

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

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

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

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

Соответственно ПМ не прав, что поступил непрофессионально, не задокументировав задачу. Но виноватым остался разработчик, которому не заплатили за потраченное время. Данный конфликт не был разрешен, и разработчик уволился.

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

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

Сергей, QA Engineer

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

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

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

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

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

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

Как минимум, в конфликте задействовано 2 человека, как максимум – человек и вся команда. Человек может быть необщительным, может не идти на контакт, но это же не конфликт. Главное, он работу свою делает, остальное никого не смущает.

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

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

Максим, Project Manager

Начнем с того, что конфликт – это проявление агрессивного, дисфункционального поведения. И если такое поведение присутствует, значит в команде есть конфликт.

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

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

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

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

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

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

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

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

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

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

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