TgQuestions
особенно если это продукт уже после релиза
внутренняя тулза vs для мира
++
но опять же очень зависит от продукта
Ну я допускаю что в теории есть zero-backlog проекты, но все-таки это какая-то утопия на мой взгляд. Пара сотен ишшю в бэклоге в любой момент времени это вроде абсолютная норма
ишью да, но не багов ))
Это помогает видеть, что вы будете делать завтра, а не фиксить рандомные баги круглый год
особенно когда тебя отдают клиенту без нормального менеджмента
В моей прошлой команде мы кроме количества багов использовал Early Bugs Detection Rate, когда общее количество багов в релизе, делилось на количество багов найденных после релиз кандидата 1. Было интересно видеть корреляцию метрики с субъективным "ну что за говно нам выкатили в этом релизе"
помогает новым чувакам или унижает
еще есть тема - человек ментор или зазнавшийся сениор?
и потом как себя в команде человек ведет, тим плеер или сыч?
маловероятно, что кто то еще ставит чушь как 10к линй кода или 100 засабмиченных багов как цели для команды/специалиста
я вообще не представляю, как можно в цифрах считать. вот один человек закрыл 10 багов, а другой только 1. при этом этот 1 баг не могли закрыть, допустим, год, а 10 были вроде “поправить опечатку”
сейлза оценить скажем проще чем инженера
самое печальное что они иногда не понимаю как оценивать KPI разных по сути позиций
OKR ) KPI это для сейлс/продакт больше
ок, я к счастью забыл что это за жесть
OKR это ж о планинровании, а метрики это "вася написал 10к линий кода, вася молодец"
10к линий кода - это KR внутри OKR )
тогда это очень криво составленный key result :) KR должен быть не только measurable, но и все остальные части SMART бы :)
measurable да, а еще по идеологии OKR недостижимый на 100%
Если такое есть то оно меняет цели человека, с того что б сделать продукт на то что б оптимизировать показатели
Не всегда. Ну т.е. конечно да, но IMBO\OKR это опять не не о метриках, а именно о целях. У вас же в продукте есть роадмап? Так квартальные цели это именно directions, куда продукт идет
Офкорс
+
Метрики это прикольно, но от них не должны зависеть результаты ревью. Точнее, результат ревью должен зависеть не только от метрик, они могут влиять тем или иным образом (но их в любом случае должно быть несколько), но не первостепенны
ну типа того, считать коммиты или к-во PR? закрытые баги или сколько приложился к большой фиче?
Ну, коммиты и ПР обычно неинтересны, а вот повешенные баги (для тестеров) и пофикшенные баги (для девелоперов) это вроде вполне обычная метрика, которую используют много где
в продуктовых компаниях, стоит добавить
видела такое и в аутсорс
когда Objective стоит снизить косты на разработку, то как раз и могутт ставить как цели - минимизировать reopened issues, или повысить качество кода
когда Objective стоит снизить косты на разработку, то как раз и могутт ставить как цели - минимизировать reopened issues, или повысить качество кода
к счастью мало в аутсорсе был, не очень приятный опыт в целом
Уменьшить ишшю это отвратительная цель))) Тестер будет лично девелоперам баги говорить, а не сабмитить же)))) А вот улучшить качество это хорошая цель, но к ней надо придумывать пути реализации в конкретном случае и инвестигировать проблемы
+
да , все так)
но я не про свой опыт
но я не про свой опыт
Та если есть такая цель я просто ствою джиру задеплою и норм