Как взаимодействовать с коллегами?
Last updated
Was this helpful?
Last updated
Was this helpful?
Как правильно задавать вопросы?
В чатах, коллегам, на форумах, где угодно:
в случае общественных чатов убедитесь, что ответа нет в описании канала или в закрепленном сообщении, а также что ваш вопрос уже не задавали раньше (99% что задавали). Проверьте поиском по истории сообщений;
прочитайте внимательно ;
убедитесь, что вы потратили уже достаточно времени в гугле и у вас ничего не вышло;
сформулируйте вопрос со всем контекстом, чтобы любой человек мог не напрягаясь его понять;
опишите все ваши действия и результаты, в т.ч. не увенчавшиеся успехом;
сформулируйте предельно ясно и четко с чем вы просите помочь;
Как общаться с разработчиками?
Нельзя:
Не отвлекайте программиста по мелочам. Сначала задайте свой вопрос в мессенджере, либо договоритесь о встрече, если уж очень жаждете личного общения. Я понял это, как только начал программировать сам. Когда вы творите, и кто-то отвлекает вас, требуется много времени и сил, чтобы снова погрузиться в состояние сосредоточения. Такие перерывы нарушают продуктивность.
Не бойтесь просить о помощи. Вы не можете знать все. Спрашивать - это нормально! Просто убедитесь, что вы поняли ответ, - не задавайте один и тот же вопрос дважды. Главный принцип командной работы при реализации проекта “Мы в одной лодке и всем будет хорошо, если у каждого будет весло.”. Он позволяет двигаться дальше в одном направлении.
Главное правило QA - никогда не верить словам разработчиков! «Все должно быть хорошо!» или «Я изменил одну строку в коде, это ничего не сломает» - фразы, после которых стоит насторожиться и перепроверить проект.
Не вините разработчика в ошибке. Не зацикливайтесь на негативе, попытайтесь решить проблему. Позже всей командой обсудим, как избежать того или иного случая в будущем. Никто не идеален. Ошибки неизбежны. Основная цель - иметь возможность быстро отреагировать на проблему и качественно выполнить свою работу.
Не назначайте конкретного разработчика на дефект. В этом есть аналогия с тем как разработчик закрывает тикет без одобрения QA. Подобное поведение может разозлить
Не занимайтесь микро менеджментом над разработчиком. «Ты посмотрел багу?», «Как насчет сейчас?», «Когда ты исправишь багу?». Это раздражает, не уменьшая сроки решения проблемы. Поставьте себя на место работника, выполняющего задачи в строгой последовательности. Подобные “пинки” нецелесообразны.
Не принимайте все близко к сердцу, с “толстой кожей” живется проще. Чрезмерная эмоциональность (негативная) - кратчайший путь к выгоранию. Не позволяйте своим чувствам преобладать над здравым смыслом. В любой момент времени на вашем пути могут попасться высокомерные люди, которых придется терпеть, выполняя при этом поставленные цели и задачи. Правило применимо относительно любого специалиста. “Толстая кожа” столь же необходима, как и тактичность.
Правильно:
Обмен знаниями с разработчиками. Сообщите им о своих подходах к тестированию, найдите «access_key» для каждого разработчика, с которым вам приходится работать. Расскажите о том, как вы собираетесь тестировать продукт. Это поможет избежать некоторых ошибок в коде. Однако такое взаимодействие не всегда возможно по нескольким причинам:
нехватка времени;
организация процессов внутри компании, не позволяющая этого сделать;
банальное нежелание разработчика сотрудничать с тестером.
Если вы все же сможете найти тот самый «access_key», который упоминался мною выше,- будет гораздо легче поддерживать здоровые отношения и хорошее качество продукта в долгосрочной перспективе.
Будьте честны. В противном случае это разрушит вашу репутацию.
Будьте готовы защищать дефекты, о которых сообщаете. Иногда приходится отстаивать критичность дефектов, которые необходимо исправить. Со временем это становится проще, когда вы способны озвучить четкую аргументацию с обоснованием того, почему дефект должен быть исправлен. Корректное формирование фактов и умение видеть на несколько шагов вперед помогает сэкономить деньги компании.
Сохраняйте хладнокровие под давлением. Я знаю, это тяжело. Когда все торопят тебя или твою команду сложно противостоять авторитетам. Однако говорить «нет» - часть нашей работы, даже если это устраивает далеко не всех.
Обсудите тестовые кейсы с разработчиком. По моему опыту, это очень сложно сделать. Данный процесс требует много времени и силы воли. Со своей стороны QA в таких “переговорах” должен быть харизматичен и крайне убедителен. Я занимался подобным некоторое время, но так и не смог научиться правильно внедрять данный подход в собственную работу. Однако от таких переговоров с разработчиком есть очевидная польза. Они расширяют спектр мнений и позволяют учитывать кейсы, которые изначально даже не рассматривались, как потенциально перспективные.
Описывайте дефекты понятно. Говорите на языке разработчика, если можете. В ином случае, старайтесь писать как можно проще. Хорошо описанный баг со всей его информативностью и полнотой погружения в проблему со стороны разработчика будет максимально быстро исправлен. Соответственно, команда QA оперативно приступит к повторному тестированию проблемного участка.
Поощряйте заинтересованность членов команды в глубоком изучении продукта. Максимальная осведомленность специалиста позволяет минимизировать число глупых дефектов. По моему опыту, такие несущественные ошибки забирают у команды слишком много времени и сил. Лучше предугадать возможные нецелесообразные действия и сосредоточиться на более важных вещах, чем тратить время на описание несущественных дефектов, которых, возможно, вовсе и нет.
Терпение, только терпение. Научитесь справляться с трудными и самовлюбленными людьми. Это общее правило, применимое к любой сфере, как и в случае с хладнокровием.
Как решать конфликты?
По действию на функционирование команды, конфликты делятся на деструктивные и конструктивные. Конструктивные (функциональные) конфликты - это продуманные дискуссии, которые возникают из-за того, что члены команды имеют разные точки зрения. Конструктивные конфликты начинаются с открытого общения и ведут к дальнейшей коммуникации и соглашению. Деструктивные (дисфункциональные) конфликты препятствуют эффективному взаимодействию и принятию решений (конкурентные отношения, чувство обиды, плохое настроение и т.д).
Отличие конфликта в удаленной команде в инструментах. Инструменты в удаленной работе отличаются от тех, которые мы используем обычно в офисе. У нас только удаленные средства связи. Личное и непосредственное взаимодействие сильно ограничено или полностью исключено. Тактика избегания конфликтов, в условиях удаленной работы, весьма соблазнительна. В офисе, когда неприятные разговоры касаются работы, мы можем использовать массу средств для смягчения остроты разговора: например, сходить вместе пообедать, попить кофе.
Что может спровоцировать конфликт? Средства удаленной связи могут спровоцировать конфликт. А именно потеря невербальных сигналов. Например, одно и то же сообщение может иметь множество интерпретаций. При удаленной коммуникации у нас гораздо меньше возможностей для понимания смысла сказанного.
Как разрешить конфликтную ситуацию и провести важную беседу?
Для начала запланируйте встречу с коллегой на определенное время.
Во время разговора сформулируйте свою позицию в такой последовательности:
Озвучьте свое наблюдение: что коллега сделал, что вам не понравилось.
Выразите словами свои чувства и свою реакцию.
Выразите словами значимую для вас потребность, которая была проигнорирована.
Предложите решение или сформулируйте ясный запрос.
После разговора следует зафиксировать ваши договоренности.
Источники:
Доп. материал: