В прошлых частях серии “QA Lead и точка: Часть 3” и “QA Lead и точка: Часть 4” мы говорили о возможных ролях лида. Пришло время перейти к вопросу формированию нашей команды.
Для начала разберемся какие бывают команды. Два самых популярных подхода, которые применяются в большинстве компаний, это “функциональный” и “кросс-функциональный”. Подход с функциональными командами более классический. Такие команды состоят из сотрудников одного направления (QA, Frontend разработчики, Backend разработчики итд) и лида (руководителя команды). Современный и “модный” кросс-функциональный подход подразумевает наличие разных специализаций в рамках одной команды. А если быть точным, то должно быть наличие всех необходимых навыков внутри команды для успешного выполнения работ над проектом, так как кросс-функциональная команда независима и самодостаточна. Также в некоторых компаниях комбинируют оба подхода. В таком случае один и тот же сотрудник в рамках кросс-функциональной команды занимается продуктовыми задачами, а в контексте своей функциональной команды выполняет технические улучшения, влияющие на всю организацию и ускоряющие работу нескольких кросс-функциональной команд.
Чаще всего, когда мы употребляем сочетание team lead команды, мы имеем в виду лида кросс-функциональной продуктовой команды. Но, так как наша серия статей связана с позицией QA Lead, рассмотрим дизайн функциональной QA команды.
Звездная карта QA команды
При формировании портрета команды мы должны знать ответы на следующие вопросы:
Из кого состоит наша команда (специализация / должность)
Какие навыки нужны команде для выполнения поставленных задач
В какой степени каждый член команды владеет этими навыками
Слабые стороны команды (навыки, которыми владеет ограниченное число сотрудников или не владеет никто)
Именно на эти вопросы сходу дает ответ звездная карта. Важно не забывать ее поддерживать, чтобы держать руку на пульсе и иметь актуальную информацию.
Далее описан пошаговый процесс составления карты.
Из кого состоит наша команда
Указываем фамилии / имена коллег и их специализацию. Примеры:
Иванов Иван (Web QA Automation)
Петров Петр (IOS QA Analyst)
Дополнительно можно указать уровень экспертизы Junior / Middle / Senior. Однако я бы советовал избегать навешивания лычек и явного выделения. Если члены команды уже работали вместе, они знают, кто какими навыками обладает. Дополнительно уровень владения навыками можно посмотреть в звездной карте.
Список членов команды указываем в таблице по вертикали:
Какие навыки нужны команде для выполнения поставленных задач
При перечислении навыков указываем только необходимые и реально используемые в работе, чтобы не засорять фокус. Также не забываем про soft-skills, они не менее важны.
В какой степени каждый член команды владеет этими навыками
В этом пункте возможны вариации, которые стоит учесть в самом начале. Все зависит от того, хотите ли вы показывать карту своей команде или используете ее только для личного мониторинга. Соответственно, у вас есть 3 варианта:
Не показывать карту, оценить навыки сотрудников самостоятельно
Показывать карту, оценить навыки сотрудников самостоятельно
Показывать карту, сотрудники сами оценивают свои навыки
Лично я предпочитаю третий вариант, идя по принципу открытости и доверия. Даже если сотрудник где-то занижает или завышает свои навыки при самостоятельной оценке, это будет видно и скорректировано в процессе работы. Более того, самостоятельное выставление уровня владения навыка повышает ответственность сотрудника, ведь он понимает уровень своей ответственности, где команда на него рассчитывает по данной экспертизе.
На пересечении имен и навыков заполняем выпадающие списки с уровнем владения навыком. Тут есть важный нюанс. Для того, чтобы каждый член команды понимал, что такое beginner / intermediate / expert необходимо составить описание для каждого навыка. Для этого используется другая таблица – матрица компетенций. Об этом инструменте мы подробнее поговорим в следующих частях.
Слабые стороны команды (навыки, которыми владеет ограниченное число сотрудников или не владеет никто)
Самая главная и финальная часть – выводы, которые мы можем сделать из получившейся карты:
У команды отсутствует экспертиза мобильной автоматизации (нужно нанимать еще одного сотрудника или обучать текущих)
Web автоматизацией владеет только один человек. Если по каким-то причинам он покинет команду, рабочий процесс по этому направлению встанет
Конечно, для трех человек польза карты не так сильно видна, поскольку можно сделать аналогичные выводы самостоятельно. Но при развитии и росте команды от десяти и более человек под вашим контролем этот инструмент чрезвычайно эффективен. Рекомендую попробовать!
Заключение
В статье мы описали:
какие команды бывают
какие вопросы должны быть учтены при формировании команды
как составить звездную карту для регулярного мониторинга состояния команды
Если хотите углубиться еще больше в тему формирования команды, рекомендую обратить внимание на курс OTUS QA Lead, где подробно разбирается модель развития команды, проводится практический урок по созданию звездный карты с возможностью оттачивания навыка при выполнении соответствующего домашнего задания.