Здравствуйте. Есть ли какая-то информация по оценке производительности тестировщиков? Например,

один тестировщик делает 10 задач за спринт, а второй 5. Как оценить работу данных сотрудников? В часах, story point, что-то еще?
Кто как делает подобную оценку?

А какую проблему решаете?

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

количество задач - это немного не тот показатель. Кто-то сделает несколько больших, а кто-то много маленьких. Если хочется прям заморочиться и закопаться в этом всём, то вот несколько вариантов: 1. Используйте математический "вес" для каждой задачи. Большая задача - 5, мелкая 1. И градируется всё, что между ними. Тогда к концу спринта/месяца, каждый тестировщик будет иметь сколько-то баллов на счету и будет видно где просадка. 2. Сопоставляте заявленне время на тестирование и реально потраченное. 3. Считайте возвраты или отмены задач от тестеров программистом. Вот навскидку.

Звучит как сторипоинты.

Можно сторипоинты в спринт. Для оценки числа фибоначчи или майки (s, m, l, etc). Можно отдельно оценивать сложность разработки и тестирования. По моему скромному опыту 2-4 спринта команда притирается, потом +/- аккуратно оценивает задачи.

по описанию, как story point

именно

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

Ну да, при планировании ж производительность можно не учитывать.

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

Сторипоинты не могут быть завязаны на часах. Только на Вася-часах и Катя-часах. Потому что Вася делает в спринт 24 сторипоинта, а Катя - 60. При том, что оба работают 40 часов в неделю.

понимаю. именно так и хотелось бы, но по факту не получается приносить отчеты в SP, потому что никто, в реальности, не понимает что это, и как это мерять

Вот. Как я понял, ваша проблема - это отчетность для стейкхолдеров? SP все же нужны для планирования команды (например, вы знаете, что больше 100 SP в спринт команда не сделает, а Вася больше 21 SP не делает). Для стейкхолдеров пусть просто трекают время на задачи, мне кажется это нормально.

если стейкхолдеры не из 90х, и бизнес - не аутсорс шлюпка, часы их не устроят. Им результат нужен. Точнее результат пер персон

Результат пер персон - микроменеджмент имхо какой-то. Часы нужны, чтобы стоимость задач понимать. Например, если перекраска кнопки стоит 80 часов работы команды разработки, то это тревожный звоночек для stakeholder

Там достаточно приближенные цифры нужны. ЧТобы четко видеть картинку. Например у нас 5 ручников мидлов, 1 по всем статам на 40% слабее остальных при стат ошибке в 15%. Это что значит? Нашли пинателя болта

да, все так. метрики приносим. теперь надо понять производительность сотрудников, реальную, измеримую, которая не будет влиять на зарплату или типа того. Понимать, Петя имеет производительность Х, что нужно сделать чтобы стало Y. Или, Маша делает Х, поэтому она старший специалист, а Света - Y, поэтому она ведущий

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

Клево. Не подумала в этом ключе. Конечно, комфорт важная характеристика

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

а потом уже производительность точнее планировать в разрезе : какие есть таски на команду \ какие есть инженеры на эту команду

Конечно, сначала разбираться, потом принимать решение. Это было как демонстрация :)

без разбора как раз кейс с бигдатой известный получается

У вас грейды выдаются в зависимости от скорости решения однотипных задач?

Пока у нас не введены грейды (только разрабатываем), но одна из идей - оценить квалификацию сотрудника, через его производительность (со всеми прочими оценками)

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

Почему? В среднем так и есть. Конкретную задачу старщий может даже и бытсрее сделать, но когда смотрим 50 задач - у ведущего должно быть вцелом все шустрее. Если нет - вопросики

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

Очень странные вопросики, мы же не о джунах речь ведем

А задачи делятся только на джуновские и остальные?

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

да. Потому что "не джун" работает, а не задачки выбирает. А джуну дают задачи попроще и не такие отвественные, чтобы обучался и вникал

Ну это какая-то галерная специфика видимо, ну или уровень тестировщиков настолько низкий, что от них не ждут решения сложных задач

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

А зачем в небольших продуктовых командах вообще грейды?

их там и нет, об этом и речь

Значит я где-то нить обсуждения потерял)