×Закрыть

Чье QA-кунг-фу круче, или Почему QA Lead — друг, товарищ и брат инженера

Заметка написана, исходя из сугубо личного опыта и взглядов на вещи со своей «колокольни» — наблюдений за соседними командами, ситуациями из жизни знакомых и так далее. В основном информация может быть интересна людям, которые бы хотели заниматься организационными процессами в сфере QA и самим QA.


© Urban Decal

Уверен, что многие в своей практике сталкивались с разными спорными моментами, которые касались действий, решений и другой активности QA-инженеров. В дальнейшем все спорные ситуации будут называться «спор» — то есть, любого рода неурядицы, навязывание своего мнения другим и еще 10 синонимов, придумайте сами. А QA будем называть словом «инженер».

Споры можно грубо поделить на внутренние и внешние. Первые происходят среди инженеров, которые работают над одним проектом или в одной команде и спорят между собой, с QA/Dev-лидом или ПМ-ом. Вторые возникают, когда инженер спорит с клиентом или заказчиком.

Почему это происходит? Ведь, по сути, цель у команды одна, и все должны бы идти к ней мирно. Ответы могут быть разные. У меня есть свой.

Внутренние споры

В утверждении, написанном выше, не учитываются личные цели каждого человека. Приведу примеры:

  1. Кто-то любит спорить, имея такую цель — его мнение должно быть принято как верное. Зачем? Все просто. Во-первых, в таком случае он прав, а значит, более опытен, круче, важнее и «дороже». Во-вторых, мышление многих работает по шаблону — сказывается опыт предыдущих мест работы и проектов. Такие люди обычно не слушают своего собеседника, в лучшем случае ждут, когда он закончит, чтобы дальше навязывать свою позицию. Они достаточно враждебно воспринимают альтернативные взгляды.
  2. Инженер рвется к власти. Зачем? Опять все просто. Обычно это касается молодых инженеров, молодых и в плане опыта (около 2-х лет), и в плане возраста (до 23 лет). Юношеский максимализм бьет ключом. Они считают, что очень много знают и умеют, что их прямой или косвенный начальник шарится на работе, или они сделают его работу лучше и эффективней. Их грызет всем известный зверь: «Почему же он тогда старший?» или «почему у него выше ЗП?».
  3. Инженер является процессо-ориентированным aka троллем. Это самый запущенный случай. Для таких людей целью является либо симуляция рабочего процесса, либо непонимание его сути, либо банально — процесс спора как таковой.

Проблема в том, что все эти «активности» только создают «качели» внутри команды или за ее пределами, отпугивают клиентов и, как следствие, тормозят процесс QA в целом.

Пункты 1 и 2 возникают в 95% по одной и той же причине — человек не реализуется на работе или занимается не тем, не там или не так. По пункту 3: изредка бывают случаи, когда человек просто некомпетентен и не подходит для работы инженером.

В любом случае, львиная доля «вины» и процесс минимизации таких ситуаций ложится именно на QA Lead.

Что делать? Я вижу решение в следующем:

  1. Надо работать над организацией команды и QA-процессов.
  2. Работать с людьми, уметь их слушать и понимать, как бы это банально не звучало.

Организация команды и процессов

Начнем с первой задачи. Каждый член команды должен четко понимать структуру последней и свою личную роль в этой структуре и в QA-процессе как таковом. А именно:

  • Должна быть четкая структура и, если хотите, иерархия, а также механизмы взаимодействия: лид у команды — один, отношения в команде строятся на уважении друг к другу.
  • Инженеры, которые занимаются тестированием, имеют четкие задачи (которые НЕ пересекаются в глобальном смысле) и сферу ответственности. Неясности, несоответствия и другие спорные моменты решаются только через лида. При этом периодически происходит перераспределение задач, чтобы иметь свежий взгляд на тот или иной функционал или фичу от разных инженеров.
  • Необходимо донести до команды роли и полномочия всех ее участников, а именно — программистов и их Team Lead-ов, Project Manager-ов, дизайнеров, тех-суппорта, клиента и остальных.
  • Если инженеры имеют связь с клиентом, то обязательно стоит упомянуть, что в диалоге с ним надо быть максимально тактичным, выдержанным и вежливым. Любые свои идеи, замечания, несогласия или возмущения необходимо подавать только с позиции предложений или рекомендаций. О более критических моментах информировать QA/Dev Lead или PM.
  • Никогда нельзя говорить заказчику, что все плохо. Все всегда должно быть хорошо (хотя заниматься намеренной дезинформацией не стоит). А вот после уже — «пожелания и статистика». :)
  • Нужно иметь документ с описанием всего существенного (процессы, роли, стуктура) и довести его до сведения всех участников (если команда собрана с нуля) или до новичка. Причем не только в виде письма или ссылки, а и устно, выделив для этого необходимое время. Следует помнить: «документ на 3 страницы лучше, чем на 10» © . Не изобретайте сферических коней в вакууме или других небезызвестных сущностей! Люди не должны тонуть в тоннах информации и бюрократии. Все должно быть просто, прозрачно и понятно. Иными словами — чем проще система, тем она надежней.
  • В зависимости от специфики проекта или величины команды роли и обязанности могут быть различными. Взаимодействие всех этих ролей между собой необходимо тщательно продумать, не ограничиваясь только взаимодействием последних с собой (лидом), описать в документе и донести до команды.
  • Никто из команды не должен «скучать», сидеть без дела или заниматься крайне неинтересной, неприятной или неполезной работой. Это не значит, что каждый должен делать только то, что хочет или что нравится. Это значит, что должен быть здоровый баланс и правильное планирование ресурсов.

Работа с людьми

  • Необходимо донести до каждого члена команды цель вашей работы, мотивировать его и помогать ему развиваться (об этом я хотел бы написать отдельную заметку) и, по возможности, помочь «полюбить» свою работу, тем самым направив человека к достижению этой цели.
  • Необходимо уметь слушать человека до конца, даже если в середине или вначале уже понятно, к чему человек ведет, и вникать в то, что до тебя пытаются донести.
  • Не стоит прерывать, перебивать или отвечать на вопрос до того, как его тебе задали. Нужно поставить себя на место человека и принять решение, дать совет или предложить помощь исходя из того, что ему нужно, но не перенеправлять человека (чтобы упростить себе жизнь) или выдавать контрпредложение (читай — утверждение) со старта.
  • Ни в коем случае не стоит делать что-либо «за него». В противном случае человек никогда ничему не научится и будет постоянно бегать к вам без реальной надобности.
  • Никогда не стоит кричать на человека или говорить с ним как с «рабом», критиковать его действия и работу в жесткой форме. Это не приносит позитивных результатов. В лучшем случае человек обижается и ему становится некомфортно работать, или замыкается в себе, или будет «тихо вас ненавидеть», рассказывать какой вы деспот, тиран и так далее. Все это вряд ли поможет вашей работе с этим человеком, не поднимет вашего авторитета в команде и, тем более, не будет позитивно влиять на результат общей работы. При этом, конечно же, не нужно позволять садиться себе на голову и халтурить.
  • Если человек ведет себя недолжным или неприемлемым образом с вами или другими членами команды, не стоит отвечать ему взаимностью, это только усугубит ситуацию. Необходимо поговорить с человеком и выяснить суть проблемы, желательно наедине. Часто решение оказывается очень простым. Можно провести воспитательную беседу о взаимодействии с командой или клиентом, постараться «переключить» человека или изменить его отношение к проблеме либеральными методами. И только в крайнем случае, если не получается решить проблему мирно, сообщить «наверх» или принять более жесткое решение вплоть до смены проекта или увольнения, если такие полномочия есть.
  • Переодически необходимо проводить митинги с командой. Дейли или Викли — насколько это позволяет рабочий процесс. Интересуйтесь в том числе моментами, которые выходят за пределы непосредственной работы. Но это не должно быть навязчиво или переходить в допрос. Все митинги должны проходить в спокойной дружеской и комфортной обстановке, без гестапо! Но доводить до ситуации «Мы провели 33 митинга и все равно завалили проект» не стоит! :)
  • Не нагружайте людей бумажной работой, если в ней нет реальной необходимости. Не грузите их своими задачами, до которых у вас не доходят руки, только чтобы облегчить себе жизнь. Чего не стоит делать — сверхстрогий трекинг времени, отчеты по несколько раз в день или избыточно детализированное описание тест кейсов и другой документации.

И в заключение, помните: вы — пример для инженеров. И если вы будете себе позволять халатно относиться к работе, делать ее некачественно, опаздывать, полчаса курить, прогуливать митинги, грубо разговаривать с участниками команды или полдня смотреть ютюб, вы должны понимать, что все остальные, вполне вероятно, будут вести себя так же! :)

В итоге, если все организовано и построено правильно, донесено до людей с учетом их собственных желаний и амбиций, вы практически наверняка избавитесь от описанных выше пунктов 1, 2 и 3.

Помните, чем больше вы уважаете окружающих, тем больше они уважают вас и как специалиста, и как участника команды, и как руководителя, и, что не менее важно, — как человека.

LinkedIn

25 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Я скажу короче: QA действительно должны быть инженерами. И эта работа должна быть оплачена вдвое выше работы кодеров, с соответсвующими требованиями и по опыту и квалификации и результативности.

Не везде конечно, но массово, просто переименовали тестеров в QA. Чем поставили могильный крест на всех преимуществах этой специальности. И рискуют лишиться сертификации ISO9001 за низкое качество продукта.

Самый спорный тезис: «Лид у команды — один». Как только лид так подумал, может быть уверен — теперь у команды либо два лида, либо ноль. Лично я сей процесс набюлдал миллион раз: лидерство больше напоминает эстафетную палочку, чем преференцию — она работает пока её передают, и чем быстрее и чаще передают — тем лучше работает. Как только кто-то оставил у себя — процесс встал. И тогда либо есть вторая, запасная, и лид в недоумении смотрит, о чём команда спорит «просто так», и тут же удостоверяется что его палочка уже не так хороша (вторая роль). Либо вся команда уходит смотреть ютуб, посчитав половой орган эстафетной палочкой.

лидерство больше напоминает эстафетную палочку,...

Угу, но в конкретный момент времени, — лид всегда один! :)

Либо два. Либо ноль. И ноль гораздо чаще даже чем один.
Не будем забывать, что в какие-то моменты времени есть роль «козёл отпущения». И именно тогда сию эстафетную палочку пытаются передать. Вставить. Известно куда. И это самый верный способ остаться без лида.

есть роль «козёл отпущения».И именно тогда сию эстафетную палочку пытаются передать. Вставить. Известно куда. И это самый верный способ остаться без лида.

У нас нет такой роли и нет описанного вами процесса.

Поиск «виновного» — совковские пережитки в отсталых системах управления.

И это хорошо!

Про «своковые пережитки» я бы не стал говорить, эта проблема есть во многих местах. Равно как и её возникновение обеспечено вполне естественными причинами. Процесс может зародиться всегда. Но я соглашусь, что на постоветском пространстве проблема имеет очень глубокие корни.

Единственный вариант иммунитета — профессиональный менеджмент. И с этим у нас в стране ой как туго. Если он есть у Вас в компании, и тем более если Вы сами в нём работаете — да, делает Вам честь. И тем более не станете возражать тому факту, что такие нормы не устанавливаются сами по себе. А исключительно благодаря грамотному управлению.

Я понимаю, что формально и фактически лид один. Но структурно лидов всегда два и более. В этом суть лидерства — умение не просто командовать, но также вести за собой, а зачастую и заставлять толкать перед собой. Если лидер не может это лидерство делегировать, то он его утрачивает сам. Очень быстро. Отсюда и факт — либо 2 и более, либо 0.

Система с одним лидером нестабильна — она не умеет строить трёхсторонние связи. У строителей есть правило — несущая структура должна состоять из треугольников. По той причине, что треугольник невозможно согнуть.

Достаточно сумбурные рекомендации. Исходные 1-2-3 — категорически не согласна. А основная честь рекомендаций правильная. 1) Спор — показатель того что есть движение и действие.

2) Нет людей, которые конфликтуют просто так. (Если есть — то это оочень редкие исключения и их нужно направлять к психологу) 3) Мнение участников команды нужно выслушивать, понимать и исходя из общей цели совместно вырабатывать решения и изменения. 4) Жесткая схема руководства, типа «Все вопросы решаются через лида и каждый говорит только о своей части работы» лишает команду возможности быть командой. Менеджер должен быть тем человеком, который может в нужный момент напомнить участникам дискуссии, что у нас единая цель и направить разговор в русло «что делать чтобы достичь цели»... А вообще — «The Deadline» Том ДеМарко стоит почитать.

Я лишь говорил о своем видении, это не значит только так правильно и применимо везде.

А под «все вопросы» имелись ввиду «спорные ситуации» в которых не находится решение обычным диалогом между инженерами и он становится, так скажем, «не обычным».

Не спор, а дискуссия является показателем движения. Не всегда в споре рождается истина. И есть люди, которые любят спорить просто так, вероятно, вам с ними повезло не встречаться, чего и далее желаю. Так как что-то доказывать этому человеку очень сложно. После разговора он уйдет со своим мнением и еще у него появится идея, что собеседник непроходимый дурак

Вот, вы правильно поняли о чем я говорил :) Спасибо!

Необходимо донести до <b>команды</b> роли и полномочия всех ее участников, а именно — программистов и их <b>Team Lead-ов</b>, Project Manager-ов, дизайнеров, тех-суппорта, клиента и остальных.

Замечены взаимоисключающие параграфы: вроде бы, весь стафф проекта — одна команда, с другой стороны, у программистов своя команда, у тестировщиков — своя, и т.п. Определитесь, для кого эта колонка — для component teams или feature teams (по-моему, для первых).

Да, немного не верно высказался:
Все QA-и — одна команда.
Другие «отделы» — другие команды.

Но все часть большой команды, точнее — проекта.

В данном случае слово «команды» вначале абзаца надо заменить на «проекта». :)

Тогда это достаточно тривиальные наблюдения. Через пару лет придете к осознанию того, что если программиста, тестировщика и аналитика собрать в одной кросс-функциональной команде, то половина конфликтов исчезнет. Как минимум, исчезнет разделение на «мы» и «они».

Суть описанного была в том что каждый QA понимал чем занимается «не QA» — какую инфу он может захотеть от QA и какую инфу он может предоставить для QA. А так же с чем может быть связана там или иная проблема или вопрос.

Я и говорю — в кросс-функциональной команде таких вопросов не возникает, т.к. команда постоянно обменивается информацией (как минимум, раз в день — на daily standup).

У нас такой принцип работы + «локации в разных городах» + еще и фрилансеры бывают.... стенд-апы как и «кросс-функциональная» команда не могут существовать как сущности в принципе, даже теоретически :)

ПИЧАЛЬКА...
И поэтому вы пытаетесь доказать, что диктаторский метод управления — самый лучший? Только потому, что у вас демократия в принципе не проходит?

Спасибо что через 2.5 года после поста еще комментируете и ни разу не занимаетесь некропостингом.
Но я вам отвечу, никогда не пропагандировал и не применял диктаторские методы в своем отделе, тем более не называл их лучшими.
Что вы подразумеваете под «демократией» в данном случае и почему у «нас» это не проходит?

100 правил руководителей проектов NASA

Правило 1. Руководитель проекта должен посетить каждого, кто делает что-нибудь в его проекте хотя бы один раз, должен знать всех менеджеров в своём проекте (как из государственных органов, так и у субподрядчиков), а также членов команды проекта. Людям нравится, когда руководитель проекта заинтересован в их работе и лучше всего посетить их лично и увидеть самому, что они делают.

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

Правило 3. Принципы управления не изменяются. Меняются только средства. Вы по прежнему должны найти нужных для выполнения работы людей и найти путь, следуя которому они смогут выполнить её.

И точно так же далее — www.pmblog.com.ua/2011/06/1010

Я понимаю что статья носит достаточно общий характер.

Это как «первый блин» aka вступление. В дальнейшем я хотел бы писать о более конкретный вещах, если это конечно будет интересно :)

Вот именно!

Предлагаю сразу брать быка за яйца, а играть перед ним вступительные прелюдии.

Общее видение — это сумбур. Было бы в сто раз круче все это расписать для себя, а в мир выходить с рассуждениями по каждому пункту в отдельности, бо тут по каждому пункту можно очень грамотно и долго дискутировать.

А то в целом получается «Люди, мы дышим воздухом; воздухом, люди!» :)

Принято!

Не судите строго :)

Я б все-таки перефразував наступне твердження:

Никогда нельзя говорить заказчику, что все плохо. Все всегда должно быть хорошо (хотя заниматься намеренной дезинформацией не стоит).

Думаю, тут мається на увазі, що повідомлення про те, що «все погано» (якщо так дійсно є), має йти від всієї команди чи тімліда як її представника перед замовником. Тобто має бути внутрікомандне розуміння, що зараз є «все погано», і замовник тоді отримує інформацію у вигляді — «тут все погано, ми (уся команда) над цим працюєм».

Почти :)
Я имел виду что нельзя говорить именно «все плохо», а стоит сказать какие есть проблемы, и что мы их решаем и когда примерно мы их поборем :)

Так как фраза «все плохо» может быть совсем не так принята клиентом, то есть «мы» и «они» часто вкладываем в смысл «все плохо», для «нас» это пара блокеров или какой-то неожиданный упс, а для «них» это может быть нечто большим вплоть до «оговоренным срокам конец» или даже «срокам конец»...

Я не понимаю каким боком тестеры к заказчику?
Вроде как с ним все вопросы ПМ решает?

Заказчик часто предпочитает общаться не только с ПМ-ом, а и со всей команды, в том числе с QA-инженерами.
Демо-билды не редко презентуют QA-инженеры.

ЗЫ:
А «тестеры» никаким боком, вы правы, ни только к заказчику, но и к разработке ПО в принципе, исключая тот случай, когда ПО для тестеров разрабатывается, конечно.

Подписаться на комментарии