Skip to content

Latest commit

 

History

History
74 lines (56 loc) · 15.3 KB

kak-vzaimodeistvovat-s-kollegami.md

File metadata and controls

74 lines (56 loc) · 15.3 KB
Raw

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

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

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

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

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

Нельзя:

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

Правильно:

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

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

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

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

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

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

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

Источники:

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