Тим-дизайн, часть вторая В прошлом посте немного поговорили про то, как QA функция может вписываться в общую структуру команд и какими вообще эти команды бывают. Сегодня немного поговорим про то, как вообще понять какая команда нужна вам, из каких факторов эта картинка складывается и что со всем этим делать. 1. Традиционная точка старта здесь - выясняем запросы бизнеса и команды. Иными словами разбираемся с тем, что от вас хотят: какие цели стоят перед QA функцией, какие зоны ответственности надо захватить и какие проблемы предстоит решать. Это одновременно позволяет понять и масштабы работы, и основные домены в которых эта работа будет вестись. Если ваша задача на обозримое будущее - поддерживать ультра-быстрые поставки фичей, гарантируя работу ключевых бизнес-сценариев, то это один пул задач и работы. Если вам нужно максимально нарастить тестовое покрытие и выдавать 99% покрытие функциональных требований тестами, то это совсем другой пул работы и другие ресурсы. 2. Изучаем контекст, имеющиеся ограничения и факторы влияющие на работу. Наличие регуляторных ограничений, уровень рисков связанных с качеством, текущее состояние продуктового качества и кодовой базы, уровень инженерной культуры, релизные циклы, продуктовые и технические планы. Здесь мы, по сути, дополняем результаты предыдущего шага более подробным контекстом. Если команда и так неплохо справляется с обеспечением необходимого уровня качества, но хотят видеть отдельного юнита в качестве драйвера этого процесса - тогда возможно вам нужен минимум дополнительных ресурсов. Если команда утопает в багах, сборки постоянно красные, а для стаблизации релиз кандидата нужно три месяца по кругу переписывать один и тот же код - вероятно, вас ждёт много работы и это потребует ощутимо больше ресурсов. Если цена ошибки в продакшене минимальная и главное быстро поправить - это один флоу, если критический баг в продакшене может привести к катастрофическим последствиям - это другой флоу. И всё в этом духе. 3. Маппим получившийся список целей и активностей на необходимые экспертизы. Если мы видим запрос от команды на автоматизацию (или это единственный вариант обеспечить нужную частотность и объем прогоняемых тестов) - то нам нужна экспертиза в автоматизации. Нужна ли нам нагрузка, внутренние пентесты, экспертиза в UX или внимание к мельчайшим деталям для создания "вылизанного" юая. На выходе у нас получается что-то похожее на матрицу компетенций - области экспертизы, которые нам нужны и их маппинг на команды/домены/блоки работы. 4. Дополняем получившуюся матрицу деталями. Здесь мы грубо оцениваем объемы работы и её срочность, уровень нужной нам глубины экспертизы в зависимости от ожиданий, степень автономности в зависимости от уровня неопределенности по задачам и необходимости самостоятельно формулировать, выбирать и принимать решения. Здесь же мы накладываем получившиеся блоки работ на рабочие процессы в командах и смотрим, где могут быть боттлнеки, скачки нагрузки и/или где нам гарантированно нужно делать поправку на бас-фактор. И ещё раз возвращаемся к п.2 с имеющимися у нас ограничениями, в т.ч. по бюджету, возможности увеличивать хэдкаунт, срочности закрытия тех или иных пробелов в экспертизе. В результате у нас получается что-то похожее на приблизительный состав команды и профили кандидатов. 5. Расставляем приоритеты, дополняем это планами развития исходя из того горизонта планирования, который у нас есть, а так же дополняем эту картину общекомандными требованиями - здесь появляется культурный- и командный-фит и прочие штуки, которые компания ожидает условно от всех. То, что получится в результате уже можно нести согласовывать, продавать и запускать в работу, в случае успеха. Это, конечно, весьма упрощенное описание процесса. Полный текст вышел примерно на 5 тысяч слов длиннее. Ну, а что делать, что б его почитать - вы знаете. P.S. Если вы вдруг уже заполняли формочку про курс, а я до сих пор с вами не связался - значит сабмит куда-то затерялся,