У вас мобилки или веб, кстати? Если мобилки - как делали обновления?

Ну, первый тезис: превращать бюджетирование в проблему членов команды (ака “не занимайся вот такими задачами, они не из нашего бюджета оплачиваются”) - признак [censored] менеджера.
Второй тезис: оценивать перформанс по команды по “профильным задачам”,  а не по импакту в продукт - признак того, что менеджер или не умеет, или сознательно ленится этот импакт оценивать, что делает его [censored] менеджером.
Третий тезис: если у человека хватает мотивации и скиллов решать сторонние задачи, то говорить ему “давай ты не будешь туда лезть, это не твоя зона ответственности”  - прямой путь к получению заявления на стол, и признак [censored] менеджера.
Четвертый тезис: позиция “мне так будет менее удобно проводить перформанс ревью, и бюджет сложнее рейзить”, без учета импакта в продукт, интересов юнита и команды - это попытка огородить свою жопу в ущерб всему остальному и признак [censored] менеджера.

Ну это так, если в двух словах.

Это, кстати, не значит, что такие менеджеры не нужны, или внедряемые ими практики и подходы не работают.
Просто в идеальном мире они живут в командах с настолько же больной корпоративной (и инженерной) культурой, репортят таким же посонам и руководят людьми, которых такое устраивает.
И все счастливы.

Сегодня он лезет в не свою зону ответственности, завтра не лезет. Спросить с него когда не лезет - нельзя. Получается что у семи нянек дитя без глазу.

Группа для тестирования это конечно особенности продукта, время мерять тоже легко, регресс занимал 40 часов и часто заканчивался баг фиксом и перезапуском, цель - сократить время доставки фичи на прод, плюс фича на проде используется, с этим ещё работаем

см. пункт 4.

А нас коробочный продукт, обновляем условно через деб-пакеты и стандартные средства линуха

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

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

Обновления принудительные или как-то договариваетесь с лояльной аудиторией о бета-тесте?

Договариваемся

Прикольно. Это сколько клиентов? десятки или тысячи?

Когда человек не хочет заниматься какой-то категорией задач - её надо стараться с него снять.
Независимо от того, профильная она или нет, если что.

Обновление возможно только после подтверждения

Кто б спорил

Когда в мобилках так делали, то просто раскатывали на n-процентов и смотрели метрики

Т.е. идея масштабируется на любые числа практически

Словить блокер на N процентов - если что, норм? Как-то договаривались с бизнесом?

У нас всего клиентов щас немного, но из особенностей продукта есть вероятность что он начнёт убивать людей