Чиє QA -кунг - фу крутіше, або Чому QA Lead - друг, товариш і брат інженера
Замітка написана, виходячи з суто особистого досвіду і поглядів на речі зі своєї «дзвіниці» - спостережень за сусідніми командами, ситуаціями з життя знайомих і так далі. В основному інформація може бути цікава людям, які б хотіли займатися організаційними процесами в сфері QA і самим QA.
Упевнений, що багато в своїй практиці стикалися з різними спірними моментами, які стосувалися дій, рішень та іншої активності QA-інженерів. Надалі всі спірні ситуації будуть називатися «суперечка» - тобто, будь-якого роду негаразди, нав'язування своєї думки іншим і ще 10 синонімів, придумайте самі. А QA будемо називати словом «інженер».
Суперечки можна грубо поділити на внутрішні і зовнішні. Перші відбуваються серед інженерів, які працюють над одним проектом або в одній команді і сперечаються між собою, з QA/Dev-лідом або ПМ-ом. Другі виникають, коли інженер сперечається з клієнтом або замовником.
Чому це відбувається? Адже, по суті, мета у команди одна, і всі повинні б йти до неї мирно. Відповіді можуть бути різні. У мене є свій.
Внутрішні суперечки
У твердженні, написаному вище, не враховуються особисті цілі кожної людини. Наведу приклади:
- Хтось любить сперечатися , маючи таку мету - його думка має бути прийнято як вірне. Навіщо? Все просто. По-перше, в такому випадку він має рацію, а значить, більш досвідчений, крутіше, важливіше і «дорожче». По-друге, мислення багатьох працює за шаблоном - дається взнаки досвід попередніх місць роботи та проектів. Такі люди зазвичай не слухають свого співрозмовника, в кращому разі чекають, коли він закінчить, щоб далі нав'язувати свою позицію. Вони досить вороже сприймають альтернативні погляди.
- Інженер рветься до влади . Навіщо? Знову все просто. Зазвичай це стосується молодих інженерів, молодих і в плані досвіду (близько 2-х років), і в плані віку (до 23 років). Юнацький максималізм б'є ключем. Вони вважають, що дуже багато знають і вміють, що їх прямий або непрямий начальник шарітся на роботі, або вони зроблять його роботу краще і ефективніше. Їх гризе всім відомий звір: «Чому ж він тоді старший?» Або «чому у нього вище ЗП ?».
- Інженер є процес-орієнтованим aka тролем . Це самий запущений випадок. Для таких людей метою є або симуляція робочого процесу, або нерозуміння його суті, або банально - процес суперечки як такої.
Проблема в тому, що всі ці «активності» тільки створюють «гойдалки» всередині команди або за її межами, відлякують клієнтів і, як наслідок, гальмують процес QA в цілому.
Пункти 1 і 2 виникають в 95% за однією і тією ж причини - людина не реалізується на роботі або займається не тим, не там або не так. За пунктом 3: зрідка бувають випадки, коли людина просто некомпетентний і не підходить для роботи інженером.
У будь-якому випадку, левова частка «провини» і процес мінімізації таких ситуацій припадає саме на QA Lead.
Що робити? Я бачу вирішення в наступному:
- Треба працювати над організацією команди і QA-процесів.
- Працювати з людьми, вміти їх слухати і розуміти, як би це банально не звучало.
Організація команди і процесів
Почнемо з першого завдання. Кожен член команди повинен чітко розуміти структуру останньої і свою особисту роль в цій структурі і в QA-процесі як такому. А саме:
- Повинна бути чітка структура і, якщо хочете, ієрархія, а також механізми взаємодії: лід у команди - один, стосунки в команді будуються на повазі один до одного.
- Інженери, що займаються тестуванням, мають чіткі завдання (які НЕ перетинаються в глобальному сенсі) і сферу відповідальності. Неясності, невідповідності й інші спірні моменти вирішуються тільки через ліда. При цьому періодично відбувається перерозподіл завдань, щоб мати свіжий погляд на той чи інший функціонал або фічу від різних інженерів.
- Необхідно донести до команди ролі та повноваження всіх її учасників, а саме - програмістів і їх Team Lead-ов, Project Manager-в, дизайнерів, тих-супорта, клієнта та інших.
- Якщо інженери мають зв'язок з клієнтом, то обов'язково варто згадати, що в діалозі з ним треба бути максимально тактовним, витриманим і ввічливим. Будь-які свої ідеї, зауваження, незгоди чи обурення необхідно подавати тільки з позиції пропозицій чи рекомендацій. Про більш критичних моментах інформувати QA/Dev Lead або PM.
- Ніколи не можна говорити замовнику, що все погано. Все завжди має бути добре (хоча займатися навмисній дезінформацією не варто). А от після вже - «побажання і статистика». :)
- Потрібно мати документ з описом всього істотного (процеси, ролі, стуктура) і довести його до відома всіх учасників (якщо команда зібрана з нуля) або до новачка. Причому не тільки у вигляді листа або заслання, а й усно, виділивши для цього необхідний час. Слід пам'ятати: «документ на 3 сторінки краще, ніж на 10» ©. Чи не винаходьте сферичних коней у вакуумі або інших відомих сутностей! Люди не повинні тонути в тоннах інформації та бюрократії. Все має бути просто, прозоро і зрозуміло. Іншими словами - чим простіше система, тим вона надійніше.
- Залежно від специфіки проекту або величини команди ролі та обов'язки можуть бути різними. Взаємодія всіх цих ролей між собою необхідно ретельно продумати, не обмежуючись тільки взаємодією останніх з собою (лідом), описати в документі і донести до команди.
- Ніхто з команди не повинен «нудьгувати», сидіти без діла чи займатися вкрай нецікавою, неприємною або некорисною роботою. Це не означає, що кожен повинен робити тільки те, що хоче чи що подобається. Це означає, що повинен бути здоровий баланс і правильне планування ресурсів.
Робота з людьми
- Необхідно донести до кожного члена команди мета вашої роботи, мотивувати його і допомагати йому розвиватися (про це я хотів би написати окрему замітку) і, по можливості, допомогти «полюбити» свою роботу, тим самим направивши людини до досягнення цієї мети.
- Необхідно вміти слухати людину до кінця, навіть якщо в середині або спочатку вже зрозуміло, до чого людина веде, і вникати в те, що до тебе намагаються донести.
- Не варто переривати, перебивати або відповідати на питання до того, як його тобі поставили. Потрібно поставити себе на місце людини і прийняти рішення, дати пораду або запропонувати допомогу виходячи з того, що йому потрібно, але не перенеправлять людини (щоб спростити собі життя) або видавати контрпропозицію (читай - затвердження) зі старту.
- Ні в якому разі не варто робити що-небудь «за нього». В іншому випадку людина ніколи нічому не навчиться і буде постійно бігати до вас без реальної потреби.
- Ніколи не варто кричати на людину або говорити з ним як з «рабом», критикувати його дії і роботу в жорсткій формі. Це не приносить позитивних результатів. У кращому випадку людина ображається і йому стає некомфортно працювати, або замикається в собі, чи буде «тихо вас ненавидіти», розповідати який ви деспот, тиран і так далі. Все це навряд чи допоможе вашій роботі з цією людиною, не підніме вашого авторитету в команді і, тим більше, не буде позитивно впливати на результат спільної роботи. При цьому, звичайно ж, не потрібно дозволяти сідати собі на голову і халтурити.
- Якщо людина веде себе неналежним або неприйнятним чином з вами або іншими членами команди, не варто відповідати йому взаємністю, це тільки посилить ситуацію. Необхідно поговорити з людиною і з'ясувати суть проблеми, бажано наодинці. Часто рішення виявляється дуже простим. Можна провести виховну бесіду про взаємодію з командою або клієнтом, постаратися «переключити» людини або змінити його ставлення до проблеми ліберальними методами. І тільки в крайньому випадку, якщо не виходить вирішити проблему мирно, повідомити «нагору» або прийняти більш жорстке рішення аж до зміни проекту або звільнення, якщо такі повноваження є.
- Періодично необхідно проводити мітинги з командою. Дейлі або викл - наскільки це дозволяє робочий процес. Цікавтеся у тому числі моментами, які виходять за межі безпосередньої роботи. Але це не повинно бути нав'язливо або переходити в допит. Всі мітинги повинні проходити в спокійній дружній і комфортній обстановці, без гестапо! Але доводити до ситуації «Ми провели 33 мітингу і все одно завалили проект» не варто! :)
- Не навантажуйте людей паперовою роботою, якщо в ній немає реальної необхідності. Не вантажте їх своїми завданнями, до яких у вас не доходять руки, тільки щоб полегшити собі життя. Чого не варто робити - сверхстрогій трекінг часу, звіти по кілька разів на день або надмірно деталізований опис тест кейсів та іншої документації.
І на закінчення, пам'ятайте: ви - приклад для інженерів. І якщо ви будете собі дозволяти халатно ставитися до роботи, робити її неякісно, ??спізнюватися, півгодини палити, прогулювати мітинги, грубо розмовляти з учасниками команди або півдня дивитися Ютюб, ви повинні розуміти, що всі інші, цілком ймовірно, будуть вести себе так само! :)
У результаті, якщо все організовано і побудовано правильно, донесено до людей з урахуванням їхніх власних бажань і амбіцій, ви практично напевно позбудетеся від описаних вище пунктів 1, 2 і 3.
Пам'ятайте, чим більше ви поважаєте оточуючих, тим більше вони поважають вас і як фахівця, і як учасника команди, і як керівника, і, що не менш важливо, - як людину.
Опубліковано: 12/12/11 @ 07:09
Розділ Різне
Рекомендуємо:
Дайджест: Стенфорд в Києві, архітектура Instagram , Java проти Scala , відмова від електронної пошти
TDS ( Traffic Directing System ) - система управління трафіком , система розподілу трафіку.
Скандинавський аукціон Gagen . Безкоштовні pin коди , пакет на 5 ставок в подарунок.
Вебмастера обманюють оптимізаторів ! Будьте пильні.
Установка коду SAPE на сайт з кириличними урламі ( UTF -8)