Что такое KPI - это просто метрика с планом. Главная особенность, что она должна быть достижима. И если она достигнута, то по ней можно принимать решение о эффективности сотрудника или предприятия.

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

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

А теперь давайте посмотрим на разработку продуктов. Все оценки, даже в часах очень условны. Да, их можно вписать в план и договор, но никто не застрахован от того, что во фреймворке у вас обнаружилось некорректное описание или баг в новом релизе. Или то, что никто из пользователей не сказал аналитику о редком корнер кейсе, который в итоге не обработали. Тут появляется очень большое влияние случайности (такие маленькие черные лебедята), потому что работу у нас творческая. Таким образом, любой KPI может быть не выполнен по независящим не то что от аналитика, а от всей команды разработки, обстоятельствам. Поэтому количество багов, конечно, можно использовать как KPI, но он будет хакаться, прятаться под ковер или вся разработка будет осуществляться на “годами проверенных решениях”, которые будут антонимом для инноваций и по настоящему крутых разработок.

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