Чье 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.
Помните, чем больше вы уважаете окружающих, тем больше они уважают вас и как специалиста, и как участника команды, и как руководителя, и, что не менее важно, — как человека.
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
25 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.