Пока выглядит так, что улучшение отношений и взаимодействий в команде - самый значимый вклад в качество и скорость поставки продукта

Если вы нанимающий QA лид/менеджер, можете ли вы нанимать разработчиков себе в команду? Если "да" или "нет", то почему "да" или "нет"?

а что мешает?

Олег, под “нанимать” - брать на себя окончательное решение?

Нанимать себе в команду.

Умозрительный вопрос или надо реальный опыт?

Реальный опыт. Потом можно пофантазировать.

Не было прецедента у меня, когда была Лидом, а у начальства сейчас не спросишь :(

Ок!

Есть практика привлекать к оценке хардов Техлида разработки, а итоговое решение найма в команду за лидом команды

Ага, интересно. Саша, а с какой целью нанимали разработчика в QA команду?

В кроссфункциональной команде был опыт, и Тимлид мог быть и аналитик.
А ты видимо про команду QA, не так поняла )

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

Когда я был QA лидом мне бы в голову такая идея бы не пришла.

Думаю, ты недалек от истины. Но у меня возникает другой вопрос: как эту идею продать руководству? И как это должно выглядеть технически?

То есть вот ты решил как QA Лид нанять разраба, прям полноценного разраба, а не автотестера. Под какие задачи? Под написание юнит-тестов? Как разработчика в продукт, но с "правильным" мышлением, чтобы распространял религию?

Да, это может быть задача под написание юнит-тестов, но в широком смысле. Например, разработчики вообще не пишут тесты, потому что в коде нет "инфраструктуры" под это, нет рельс на которые можно всем остальным разработчикам. Такие рельсы нужны не только для юнит-тестов, но и для других видов, визуальная регрессия, мутационное тестирование, компонентные/фича тесты.

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

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

Интересная мысль, я ее подумаю с точки зрения разработчика. Пока вижу проблемы с рефакторингом: обычно для рефакторинга тебе лучше быть хорошо знакомым с системой и кодом, чтобы не сломать что-то незаметное. Человеку со стороны я бы такое не хотела доверять.

А вот про "инфраструктуру" прям интересная мысль.

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

Испытательного мало. Для нормального рефакторинга по крайней мере