Суть конфликта
Один из наших фронтенд-разработчиков залил релиз с критическими багами. Project manager (PM) команды со своей стороны это пропустил, несмотря на то, что специалист QA был против и говорил о возможных рисках при выкатке такого релиза. Это произошло под Новый год, когда сотрудники старались качественно завершить дела и уложиться во все возможные сроки. То есть накал в IT-команде чувствовался и до этой ситуации: сказывалась усталость каждого участника. И по закону жанра разразился конфликт.
Специалисту QA хотелось «возмездия» и полного разбора этого кейса буквально на атомы, сторона разработчиков была вынуждена объяснять, на чем были основаны решения, и аргументированно обосновать предпринятые действия. А от продакт-менеджера хотели услышать объяснения, почему он не знал, что «едет» в релизе и к каким последствиям это может привести.
Для того чтобы погасить конфликт, мы приняли решение вывести всех его участников на живой диалог друг с другом. Здесь важно отметить, что в таком вопросе всегда имеют значение скорость реакции модераторов конфликта и оперативное прекращение выяснения обстоятельств по переписке между конфликтующими сторонами.
Живой диалог запустил эмпатию
Для того чтобы модифицировать конфликтную ситуацию в конструктивный диалог, нам с командой потребовалось совершить несколько действий.
В первую очередь мы организовали созвон специалистов, так как они работают удаленно. Модератором этой встречи выступала сторона, которая изначально не принимала участия в конфликте. Нам было важно создать атмосферу доверия и взаимоуважения, чтобы каждый смог прямо высказать свои мысли и выслушать других.
Не менее важно было по возможности избежать обвинений. Вместо этого мы сосредоточились на фактах, а я, как HR, попросила выразить свои чувства и потребности каждого присутствующего. Ребята приложили усилия, чтобы говорить о своих потребностях и чувствах, используя «Я-сообщения». Например, среди них были такие высказывания: «Я понимаю, что задерживаю работу другого специалиста», «Я нахожусь в большем контексте релиза, чем PM», «Я понимаю, что мог вспылить, но так получилось потому, что я проанализировал риски» и тому подобное. Всё это помогло избежать негатива и поскорее выйти на конструктивный диалог.
Далее мы стали искать компромиссы, используя эмпатию. Участники попытались поставить себя на место коллег и представить, что они думают и чувствуют. И ребята, уже услышав все точки зрения, стали делиться мнением со стороны, почему такая ситуация могла произойти и как предотвратить подобное в будущем. И уже далее всем было гораздо легче предлагать решения, так как разработчик, QA и PM поняли точку зрения друг друга и выразили свои позиции достаточно открыто.
После разговора все единогласно сошлись на том, что разработчики будут прислушиваться к мнению QA, даже если поджимают дедлайны, а QA, в свою очередь, будут более четко и аргументированно доносить мысли и разграничивать риски. Конфликты часто требуют компромиссов со всех сторон для достижения общей цели.
Подводя итоги встречи, мы выразили благодарность всем сторонам за открытость и участие в диалоге.
Также после общения все специалисты единогласно пришли к решению, что выкатывать релиз такого качества точно нельзя. Взвесив всё и сопоставив риски, команда открыто сообщила всем участникам процесса о своем решении, аргументированно обосновав его.
Несмотря на срыв дедлайнов, релиз откатили и принялись за исправление критичных багов. Кстати, починить всё удалось в очень короткие сроки, и буквально на следующий день релиз снова выкатили. Таким образом, конфликт был полностью исчерпан.
Анализируем причины
Основная причина того, что между специалистами этих двух отделов могут возникать разногласия, — это непонимание ролей каждой из сторон. Разработчики могут думать, что специалисты по контролю качества занимаются работой «под капотом», проявляя ошибки в их коде. В то время как QA могут чувствовать, что коллеги не уделяют достаточного внимания качеству своего кода.
Разногласия также вполне могут возникать из-за разницы в приоритетах. Интерес разработчиков в том, чтобы доставить и запустить продукт как можно быстрее, а QA, в свою очередь, стремятся обеспечить его высокое качество.
В описанном мной кейсе главная мысль состоит в том, что и QA, и разработчики, и PM играют важную роль в создании качественного продукта и их сотрудничество может привести к лучшим результатам. Мы стараемся этого достичь через совершенствование коммуникации, установление общих целей и ценностей, а также отлаживание совместных процессов работы.
В любом конфликте важно помнить, что каждый человек индивидуален и имеет свою точку зрения. Именно поэтому необходимо проявлять гибкость, терпение и уважение к другому.
