Как, исключительно для себя, понимать, что человек проседает? Чтобы прийти

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

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

а мерять что?

Скрепный подход - прийти и наругать, депремировать до кучи. Эффективность все понимают. Но самое смешное - иногда в случае с нашими людьми это работает, особенно с вкатывальщиками, которых так и мотивировали в их предыдущей профессии Западный подход - поговорить один на один, что получается, что не получается, чем помочь. По итогу общения сделать экшен айтимы помощи, и выполнить Если изменений нет - тест на пинателя болта. Аккуратно высвобождаете чела от всех задач кроме одной или двух на спринт, фокусируете его и смотрите. Если все сделано и в срок, значит человек перегружен мелкими тасками/отвлекают на мелочи, и не очень умеет работать в таких условиях, надо соотв наладить его роль. Если снова нихрена не готово - приказ, стол коробка, выходное пособие

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

По цифири -- никак. Человек может тестировать фичи в которых где-то два бага, где-то сорок два. Программист при мерже пропустил одну строку -- приложение стало в определённом месте грузится дольше часа, блокер. Человеку зашла новая задача типа которой человек раньше не делал (тестирование прикрутки MDM, например). Человеку надо почитать мануалы и познакомиться с решениями вообще. А потом для коллег ещё и написать инструкцию как с этим работать. Один человек может смотреть поверхностно, другой от опыта добавлять ещё проверок. В результате найденных проблем какая-то задача команды может быть вообще занять два спринта, а не один. Сравнивать можно если отправлять разных людей работать над совершенно одним и тем же, и смотреть сколько багов нашли, каких, сколько времени это заняло. И то не факт что так получится -- кто-то может больше внимания обращать на один функционал, кто-то на другой.

задача - как-то это систематизировать, субъективно, с возможностью внесения изменений в свои оценки, но систематизировать. но, да, это очень субъективно

По-моему это нереалистично. Разные люди работают в разных командах. В одной из команд более небрежный программист и более дотошный тестировщик. С кодом программиста больше проблем, тестировщик находит больше проблем, фиксы затягивают. В другой программисты делают чисто или почти чисто, задачи проходят тестирование легко. В третьей тестировщик покрутил-подумал два дня, а на третий выдал контрпример согласно которому фича как её задумали вообще не может быть реализована. В четвёртой куча мелких багов типа "кнопка съехала" или "текст не влез в ячейку" В пятой такие фичи в которых вообще не разобраться без платного за доллары тренинга от поставщика стороннего компонента. Что бы вы не меряли, тренинг один, платный, компания отправила на тренинг одного тестировщика. Как это вообще униформно систематизировать? Сторипойнты между командами тоже разные -- у кого-то велосити может быть 41, у кого-то 55, так сложилось что они по-разному оценивают.

Как это систематизировать? Через единую шкалу оценок, очевидно. Потому что все примеры, о которых идёт речь могут выражаться не только в жирноте сторипоинтов, но и в их количестве. Исторически много реопенов в команде - закладываем это в оценку, накидываем поинтов сверху. Ну и дальше по списку.

на чем вы предлагаете построить данную шкалу оценок?

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

Ну, собственно, на том, на чем строится вся оценка работ в сторипоинтах - сколько абстрактных единиц работы человек/команда дотаскивает до продакшена за спринт.

Сторипойнты придуманы для оценки сложности задач, определения велосити и потом планирования выполнения задач в рамках одной команды. Поработав некоторое время даже не со скрам-мастерами, а с тренерами, которые учат скрам-мастеров, я ни разу не слышал даже о сравнении сторипойнтов между разными командами или каком-то "сглаживании".

Угу, потому что разные люди для разных задач. Задача скрам-мастера и тем более тренера - наладить стабильный процесс скрама, который позволит выйти на стабильный пул сторипоинтов и предсказуемую скорость. А аналитику делать и КПИ считать хоть как то вменяемо - это отдельные люди и отдельные навыки

Давай я задам наводящий вопрос. А чем принципиально отличается формирование велосити команды (формирующееся из совокупности велосити участников) от формирования велосити N команд?