> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/faq-dlya-novichkov/kak-vzaimodeistvovat-s-kollegami.md).

# Как взаимодействовать с коллегами?

**Как правильно задавать вопросы?**

В чатах, коллегам, на форумах, где угодно:

* в случае общественных чатов убедитесь, что ответа нет в описании канала или в закрепленном сообщении, а также что ваш вопрос уже не задавали раньше (99% что задавали). Проверьте поиском по истории сообщений;
* прочитайте внимательно [https://nometa.xyz/](https://nometa.xyz);
* убедитесь, что вы потратили уже достаточно времени в гугле и у вас ничего не вышло;
* сформулируйте вопрос со всем контекстом, чтобы любой человек мог не напрягаясь его понять;
* опишите все ваши действия и результаты, в т.ч. не увенчавшиеся успехом;
* сформулируйте предельно ясно и четко с чем вы просите помочь;

**Как общаться с разработчиками?**

Нельзя:

* Не отвлекайте программиста по мелочам. Сначала задайте свой вопрос в мессенджере, либо договоритесь о встрече, если уж очень жаждете личного общения. Я понял это, как только начал программировать сам. Когда вы творите, и кто-то отвлекает вас, требуется много времени и сил, чтобы снова погрузиться в состояние сосредоточения. Такие перерывы нарушают продуктивность.
* Не бойтесь просить о помощи. Вы не можете знать все. Спрашивать - это нормально! Просто убедитесь, что вы поняли ответ, - не задавайте один и тот же вопрос дважды. Главный принцип командной работы при реализации проекта “Мы в одной лодке и всем будет хорошо, если у каждого будет весло.”. Он позволяет двигаться дальше в одном направлении.
* Главное правило QA - никогда не верить словам разработчиков! «Все должно быть хорошо!» или «Я изменил одну строку в коде, это ничего не сломает» - фразы, после которых стоит насторожиться и перепроверить проект.
* Не вините разработчика в ошибке. Не зацикливайтесь на негативе, попытайтесь решить проблему. Позже всей командой обсудим, как избежать того или иного случая в будущем. Никто не идеален. Ошибки неизбежны. Основная цель - иметь возможность быстро отреагировать на проблему и качественно выполнить свою работу.
* Не назначайте конкретного разработчика на дефект. В этом есть аналогия с тем как разработчик закрывает тикет без одобрения QA. Подобное поведение может разозлить
* Не занимайтесь микро менеджментом над разработчиком. «Ты посмотрел багу?», «Как насчет сейчас?», «Когда ты исправишь багу?». Это раздражает, не уменьшая сроки решения проблемы. Поставьте себя на место работника, выполняющего задачи в строгой последовательности. Подобные “пинки” нецелесообразны.
* Не принимайте все близко к сердцу, с “толстой кожей” живется проще. Чрезмерная эмоциональность (негативная) - кратчайший путь к выгоранию. Не позволяйте своим чувствам преобладать над здравым смыслом. В любой момент времени на вашем пути могут попасться высокомерные люди, которых придется терпеть, выполняя при этом поставленные цели и задачи. Правило применимо относительно любого специалиста. “Толстая кожа” столь же необходима, как и тактичность.

Правильно:

* Обмен знаниями с разработчиками. Сообщите им о своих подходах к тестированию, найдите «access\_key» для каждого разработчика, с которым вам приходится работать. Расскажите о том, как вы собираетесь тестировать продукт. Это поможет избежать некоторых ошибок в коде. Однако такое взаимодействие не всегда возможно по нескольким причинам:
  * нехватка времени;
  * организация процессов внутри компании, не позволяющая этого сделать;
  * банальное нежелание разработчика сотрудничать с тестером.
* Если вы все же сможете найти тот самый «access\_key», который упоминался мною выше,- будет гораздо легче поддерживать здоровые отношения и хорошее качество продукта в долгосрочной перспективе.
* Будьте честны. В противном случае это разрушит вашу репутацию.
* Будьте готовы защищать дефекты, о которых сообщаете. Иногда приходится отстаивать критичность дефектов, которые необходимо исправить. Со временем это становится проще, когда вы способны озвучить четкую аргументацию с обоснованием того, почему дефект должен быть исправлен. Корректное формирование фактов и умение видеть на несколько шагов вперед помогает сэкономить деньги компании.
* Сохраняйте хладнокровие под давлением. Я знаю, это тяжело. Когда все торопят тебя или твою команду сложно противостоять авторитетам. Однако говорить «нет» - часть нашей работы, даже если это устраивает далеко не всех.
* Обсудите тестовые кейсы с разработчиком. По моему опыту, это очень сложно сделать. Данный процесс требует много времени и силы воли. Со своей стороны QA в таких “переговорах” должен быть харизматичен и крайне убедителен. Я занимался подобным некоторое время, но так и не смог научиться правильно внедрять данный подход в собственную работу. Однако от таких переговоров с разработчиком есть очевидная польза. Они расширяют спектр мнений и позволяют учитывать кейсы, которые изначально даже не рассматривались, как потенциально перспективные.
* Описывайте дефекты понятно. Говорите на языке разработчика, если можете. В ином случае, старайтесь писать как можно проще. Хорошо описанный баг со всей его информативностью и полнотой погружения в проблему со стороны разработчика будет максимально быстро исправлен. Соответственно, команда QA оперативно приступит к повторному тестированию проблемного участка.
* Поощряйте заинтересованность членов команды в глубоком изучении продукта. Максимальная осведомленность специалиста позволяет минимизировать число глупых дефектов. По моему опыту, такие несущественные ошибки забирают у команды слишком много времени и сил. Лучше предугадать возможные нецелесообразные действия и сосредоточиться на более важных вещах, чем тратить время на описание несущественных дефектов, которых, возможно, вовсе и нет.
* Терпение, только терпение. Научитесь справляться с трудными и самовлюбленными людьми. Это общее правило, применимое к любой сфере, как и в случае с хладнокровием.

**Как решать конфликты?**

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

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

Что может спровоцировать конфликт? Средства удаленной связи могут спровоцировать конфликт. А именно потеря невербальных сигналов. Например, одно и то же сообщение может иметь множество интерпретаций. При удаленной коммуникации у нас гораздо меньше возможностей для понимания смысла сказанного.

Как разрешить конфликтную ситуацию и провести важную беседу?

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

Источники:

* [Набор правил для общения между разработчиком и QA инженером](https://habr.com/ru/post/648601/)
* [Как решать конфликты в удаленной команде](https://t.me/qa_chillout/100)

Доп. материал:

* [Коллеги: и не друг, и не враг, а как?](https://habr.com/ru/company/regionsoft/blog/497396/)
* [И жили они долго и счастливо: как QA выстроить плодотворное взаимодействие с dev](https://habr.com/ru/company/ispring/blog/645229/)
* [О конфликтах QA vs Dev, QA vs Product: почему так получается и что с этим делать](https://habr.com/ru/company/skyeng/blog/577010/)
* [Почему разработчики иногда отказываются исправлять баги](https://dou.ua/forums/topic/35024/)
* [Управление конфликтами](https://t.me/general_it_talks/204)
* [Как "продать" баг разработчику](https://www.youtube.com/watch?v=wGyAW3l_SxA)
* [Пойми меня, если сможешь. Или как донести мысль заказчику (понятно и с первого раза)](https://habr.com/ru/company/surfstudio/blog/674418/)
* [Как QA выстроить эффективное взаимодействие с разработчиками. Один возможный путь](https://habr.com/ru/articles/471576/)
* [Soft skills: общение с коллегами и командой — Камилла Самохина, Тинькофф](https://youtu.be/BFhdLITJobc?si=IkceEUI_TXOQH0Dx)