Як взаємодіяти з колегами?
Як правильно ставити запитання?
У чатах, колегам, на форумах, де завгодно:
у разі громадських чатів переконайтеся, що відповіді немає в описі каналу або в закріпленому повідомленні, а також, що ваше запитання вже не ставили раніше (99% що задавали). Перевірте пошук з історії повідомлень;
прочитайте уважно https://nometa.xyz/ ;
переконайтеся, що ви витратили вже достатньо часу в гугле, і у вас нічого не вийшло;
сформулюйте питання з усім контекстом, щоб будь-яка людина могла не напружуючись її зрозуміти;
опишіть усі ваші дії та результати, в т.ч. не увінчалися успіхом;
сформулюйте гранично ясно та чітко з чим ви просите допомогти;
Як спілкуватися із розробниками?
Не можна:
Не відволікайте програміста за дрібницями. Спочатку поставте своє питання в месенджері, або домовтеся про зустріч, якщо дуже прагнете особистого спілкування. Я зрозумів це, щойно почав програмувати сам. Коли ви творите, і хтось відволікає вас, потрібно багато часу та сил, щоб знову поринути у стан зосередження. Такі перерви порушують продуктивність.
Не бійтеся просити допомоги. Ви не можете знати все. Запитувати – це нормально! Просто переконайтеся, що ви зрозуміли відповідь, - не ставте одне й те саме питання двічі. Головний принцип командної роботи при реалізації проекту "Ми в одному човні і всім буде добре, якщо у кожного буде весло". Він дозволяє рухатись далі в одному напрямку.
Головне правило QA – ніколи не вірити словам розробників! "Все має бути добре!" або «Я змінив один рядок у коді, це нічого не зламає» - фрази, після яких варто насторожитися і перевіряти ще раз проект.
Не звинувачуйте розробника в помилці. Не зациклюйтесь на негативі, спробуйте вирішити проблему. Пізніше всією командою обговоримо, як уникнути того чи іншого випадку у майбутньому. Ніхто не ідеальний. Помилки неминучі. Основна мета – мати можливість швидко відреагувати на проблему та якісно виконати свою роботу.
Не призначайте конкретного розробника дефект. У цьому є аналогія про те, як розробник закриває тикет без схвалення QA. Подібна поведінка може роздратувати
Не займайтеся мікроменеджментом над розробником. Ти подивився багу?, Як щодо зараз?, Коли ти виправиш багу?. Це дратує, не зменшуючи термін вирішення проблеми. Поставте себе місце працівника, виконує завдання у суворої послідовності. Подібні “стусани” недоцільні.
Не приймайте все близько до серця, з товстою шкірою живеться простіше. Надмірна емоційність (негативна) – найкоротший шлях до вигоряння. Не дозволяйте своїм почуттям переважати здоровий глузд. У будь-який момент часу на вашому шляху можуть потрапити зарозумілі люди, яких доведеться терпіти, виконуючи при цьому поставлені цілі та завдання. Правило стосується будь-якого фахівця. "Товста шкіра" так само необхідна, як і тактовність.
Правильно:
Обмін знаннями із розробниками. Повідомте про свої підходи до тестування, знайдіть «access_key» для кожного розробника, з яким вам доводиться працювати. Розкажіть, як ви збираєтеся тестувати продукт. Це допоможе уникнути деяких помилок у коді. Однак така взаємодія не завжди можлива з кількох причин:
брак часу;
організація процесів усередині компанії, що не дозволяє цього зробити;
банальне небажання розробника співпрацювати із тестером.
Якщо ви все ж таки зможете знайти той самий «access_key», який згадувався мною вище, - буде набагато легше підтримувати здорові стосунки та хорошу якість продукту в довгостроковій перспективі.
Будьте чесними. Інакше це зруйнує вашу репутацію.
Будьте готові захищати дефекти, про які повідомляєте. Іноді доводиться відстоювати критичність дефектів, які потрібно виправити. Згодом це стає простішим, коли ви здатні озвучити чітку аргументацію з обґрунтуванням того, чому дефект має бути виправлений. Коректне формування фактів та вміння бачити на кілька кроків уперед допомагає заощадити гроші компанії.
Зберігайте холоднокровність під тиском. Я знаю, це тяжко. Коли всі поспішають тебе чи твою команду, складно протистояти авторитетам. Однак говорити «ні» - частина нашої роботи, навіть якщо це влаштовує далеко не всі.
Обговоріть тестові кейси із розробником. На мій досвід, це дуже складно зробити. Цей процес вимагає багато часу та сили волі. Зі свого боку QA у таких “переговорах” має бути харизматичним і вкрай переконливим. Я займався подібним деякий час, але так і не зміг навчитися правильно впроваджувати цей підхід у свою роботу. Однак від таких переговорів із розробником є очевидна користь. Вони розширюють спектр думок і дозволяють враховувати кейси, які спочатку навіть не розглядалися як потенційно перспективні.
Описуйте дефекти зрозуміло. Говоріть мовою розробника, якщо можете. В іншому випадку, намагайтеся писати якомога простіше. Добре описаний баг з усією його інформативністю та повнотою занурення у проблему з боку розробника буде максимально швидко виправлено. Відповідно, команда QA оперативно розпочне повторне тестування проблемної ділянки.
Заохочуйте зацікавленість членів команди у глибокому вивченні продукту. Максимальна поінформованість фахівця дозволяє мінімізувати кількість нерозумних дефектів. На мій досвід, такі несуттєві помилки забирають у команди занадто багато часу та сил. Краще передбачити можливі недоцільні дії і зосередитися на важливіших речах, ніж витрачати час на опис несуттєвих дефектів, яких, можливо, зовсім немає.
Терпіння, лише терпіння. Навчіться справлятися з важкими та самозакоханими людьми. Це загальне правило, яке стосується будь-якої сфери, як і у випадку з холоднокровністю.
Як вирішувати конфлікти?
По дії на функціонування команди, конфлікти поділяються на деструктивні та конструктивні. Конструктивні (функціональні) конфлікти – це продумані дискусії, які виникають через те, що члени команди мають різні точки зору. Конструктивні конфлікти починаються з відкритого спілкування та ведуть до подальшої комунікації та угоди. Деструктивні (дисфункціональні) конфлікти перешкоджають ефективному взаємодії та прийняттю рішень (конкурентні відносини, почуття образи, поганий настрій тощо).
Відмінність конфлікту у віддаленій команді інструментів. Інструменти у віддаленій роботі відрізняються від тих, які ми зазвичай використовуємо в офісі. У нас лише віддалені засоби зв'язку. Особиста та безпосередня взаємодія сильно обмежена або повністю виключена. Тактика уникнення конфліктів, за умов віддаленої роботи, дуже спокуслива. В офісі, коли неприємні розмови стосуються роботи, ми можемо використовувати багато засобів для пом'якшення гостроти розмови: наприклад, сходити разом пообідати, попити каву.
Що може спровокувати конфлікт? Кошти віддаленого зв'язку можуть спровокувати конфлікт. А саме втрата невербальних сигналів. Наприклад, те саме повідомлення може мати безліч інтерпретацій. При віддаленій комунікації ми набагато менше можливостей розуміння сенсу сказаного.
Як вирішити конфліктну ситуацію та провести важливу бесіду?
Для початку заплануйте зустріч із колегою на певний час.
Під час розмови сформулюйте свою позицію у такій послідовності:
Озвучте свій нагляд: що колега зробив, що вам не сподобалося.
Виразіть словами свої почуття та свою реакцію.
Виразіть словами значну вам потреба, яка була проігнорована.
Запропонуйте рішення чи сформулюйте ясний запит.
Після розмови слід зафіксувати ваші домовленості.
Джерела:
Дод. матеріал:
Last updated