Притча о KPI и отделе приемочного тестирования

KPI в истории

KPI — Ключевые показатели эффективности (Key Performance Indicators) — показатели деятельности подразделения (предприятия), которые помогают организации в достижении стратегических и тактических (операционных) целей. ©Wikipedia

Если коротко, то это тот инструмент, который очень любят внедрять получившие на это карт бланш HR’ы.
Вообще, сами по себе показатели эффективности вызывают множество вопросов и бурю возмущений в IT среде. И не только среди простых смертных инженеров, далеко не все руководители групп и подразделений в восторге от этих трех букв.
И бизнес любит эти показатели до определенного момента. Пока ими не начнут злоупотреблять.

Можно много говорить о том, что важно не просто померить, а знать что и зачем мы мерим. Можно долго говорить… Можно даже быть уверенным в том, что мы проводим измерения того, что надо и так, как надо. Но почему-то уверенность остается в основном только в теории. На практике — беда-беда. Все вкривь и вкось.
Можно не говорить тем, кого измеряем, о том, что они под наблюдением. Можно. Но… Молчание будет не самым мудрым управленческим шагом — тайное всегда становится явным.  🙂

А теперь коротко и емко о том, почему KPI это не самое удачное решение в интеллектуальной среде.

Это на столько мощно, просто и изящно, что я не мог не скопировать. 🙂

«История от начала до конца выдумана, все совпадения с реальностью случайны.

В одной компании столкнулись с проблемой большого количества ошибок, пропускаемых в operation. На 10 ошибок, обнаруженных в процессе разработки, приходилось 10 ошибок, обнаруженных в процессе эксплуатации. Для борьбы с этой проблемой было принято решение об организации специального подразделения для проведения приемочного тестирования. Одним из KPI в рамках проекта создания такого подразделения, было требование снизить количество ошибок, всплывающих в процессе эксплуатации до 10% от суммарного количества ошибок. Т.е. 18 ошибок будет обнаруживаться в тестировании, и всего 2 будут приходить из эксплуатации.

После организации отдела и нескольких релизов неожиданно выяснилось, что эффективность тестирования не дотягивает до заданного KPI в 90%. В тестировании обнаруживалось 14 ошибок, но из эксплуатации приходило 8. Да, процент увеличился с 50% до 63%, но до заветных 90% оставалось еще очень далеко. А когда и очередной релиз ситуацию не улучшил, была проведена разъяснительная беседа с командой тестирования, о необходимости лучше относиться к своим обязанностям, ведь если цель не будет достигнута, может быть принято решение о расформировании свежесозданного подразделения. И отдел взялся за работу. Были найдены ошибки с присоединением файлов по 4 ГБ (система не предназначалась для хранения файлов, просто в одной из бизнес-операций необходимо было приложить скриншот), была обнаружена ошибка смещения на 4 пикселя текста подписи относительно элемента для ввода данных и т.д. Релиз всех впечатлил всего 9 ошибок из релиза против найденных в тестировании 42. А это уже 82%. Целевой KPI был все ближе.
Дальше уже можно и не рассказывать…
Когда девочка из отдела тестирования стала встречаться с мальчиком из отдела разработки, он не смог отказать любимой. Появилась куча мелких багов, за обнаружение которых девочку очень хвалили и ставили всем в пример.
После корпоратива, когда отдел тестирования нашел общий язык с ServiceDesk-ом, часть багов из релиза перестала фиксироваться в баг-трекере.
Так что, к дате отчета по проекту KPI был достигнут и даже немножко перевыполнен. А пользователи, ну что пользователи, в этом году всех интересовало успешное завершение проекта по внедрению приемочного тестирования.» © Алексей Лосев

PS. Это не единственное обоснование неуклюжести применения подхода на основе KPI.