698
0
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Как мы решили конфликт между разработчиком и QA-менеджером и какие выводы сделали

Время чтения 2 минуты
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
698
0
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Привет, я Лилия Гермус, HR-директор международного B2B-маркетплейса BirdsBuild. Поделюсь своим мнением о конфликтах на работе в IT-сфере.

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

Как мы решили конфликт между разработчиком и QA-менеджером и какие выводы сделали

Суть конфликта

Один из наших фронтенд-разработчиков залил релиз с критическими багами. Project manager (PM) команды со своей стороны это пропустил, несмотря на то, что специалист QA был против и говорил о возможных рисках при выкатке такого релиза. Это произошло под Новый год, когда сотрудники старались качественно завершить дела и уложиться во все возможные сроки. То есть накал в IT-команде чувствовался и до этой ситуации: сказывалась усталость каждого участника. И по закону жанра разразился конфликт. 

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

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

Живой диалог запустил эмпатию

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

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

Не менее важно было по возможности избежать обвинений. Вместо этого мы сосредоточились на фактах, а я, как HR, попросила выразить свои чувства и потребности каждого присутствующего. Ребята приложили усилия, чтобы говорить о своих потребностях и чувствах, используя «Я-сообщения». Например, среди них были такие высказывания: «Я понимаю, что задерживаю работу другого специалиста», «Я нахожусь в большем контексте релиза, чем PM», «Я понимаю, что мог вспылить, но так получилось потому, что я проанализировал риски» и тому подобное. Всё это помогло избежать негатива и поскорее выйти на конструктивный диалог.

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

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

Подводя итоги встречи, мы выразили благодарность всем сторонам за открытость и участие в диалоге.

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

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

Анализируем причины

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

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

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

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

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники