История от начала до конца выдумана, все совпадения с реальностью случайны.
В одной компании столкнулись с проблемой большого количества ошибок, пропускаемых в operation. На 10 ошибок, обнаруженных в процессе разработки, приходилось 10 ошибок, обнаруженных в процессе эксплуатации. Для борьбы с этой проблемой было принято решение об организации специального подразделения для проведения приемочного тестирования. Одним из KPI в рамках проекта создания такого подразделения, было требование снизить количество ошибок, всплывающих в процессе эксплуатации до 10% от суммарного количества ошибок. Т.е. 18 ошибок будет обнаруживаться в тестировании, и всего 2 будут приходить из эксплуатации.
После организации отдела и нескольких релизов неожиданно выяснилось, что эффективность тестирования не дотягивает до заданного KPI в 90%. В тестировании обнаруживалось 14 ошибок, но из эксплуатации приходило 8. Да, процент увеличился с 50% до 63%, но до заветных 90% оставалось еще очень далеко. А когда и очередной релиз ситуацию не улучшил, была проведена разъяснительная беседа с командой тестирования, о необходимости лучше относиться к своим обязанностям, ведь если цель не будет достигнута, может быть принято решение о расформировании свежесозданного подразделения. И отдел взялся за работу. Были найдены ошибки с присоединением файлов по 4 ГБ (система не предназначалась для хранения файлов, просто в одной из бизнес-операций необходимо было приложить скриншот), была обнаружена ошибка смещения на 4 пикселя текста подписи относительно элемента для ввода данных и т.д. Релиз всех впечатлил всего 9 ошибок из релиза против найденных в тестировании 42. А это уже 82%. Целевой KPI был все ближе.
Дальше уже можно и не рассказывать...
Когда девочка из отдела тестирования стала встречаться с мальчиком из отдела разработки, он не смог отказать любимой. Появилась куча мелких багов, за обнаружение которых девочку очень хвалили и ставили всем в пример.
После корпоратива, когда отдел тестирования нашел общий язык с ServiceDesk-ом, часть багов из релиза перестала фиксироваться в баг-трекере.
Так что, к дате отчета по проекту KPI был достигнут и даже немножко перевыполнен. А пользователи, ну что пользователи, в этом году всех интересовало успешное завершение проекта по внедрению приемочного тестирования.
В одной компании столкнулись с проблемой большого количества ошибок, пропускаемых в operation. На 10 ошибок, обнаруженных в процессе разработки, приходилось 10 ошибок, обнаруженных в процессе эксплуатации. Для борьбы с этой проблемой было принято решение об организации специального подразделения для проведения приемочного тестирования. Одним из KPI в рамках проекта создания такого подразделения, было требование снизить количество ошибок, всплывающих в процессе эксплуатации до 10% от суммарного количества ошибок. Т.е. 18 ошибок будет обнаруживаться в тестировании, и всего 2 будут приходить из эксплуатации.
После организации отдела и нескольких релизов неожиданно выяснилось, что эффективность тестирования не дотягивает до заданного KPI в 90%. В тестировании обнаруживалось 14 ошибок, но из эксплуатации приходило 8. Да, процент увеличился с 50% до 63%, но до заветных 90% оставалось еще очень далеко. А когда и очередной релиз ситуацию не улучшил, была проведена разъяснительная беседа с командой тестирования, о необходимости лучше относиться к своим обязанностям, ведь если цель не будет достигнута, может быть принято решение о расформировании свежесозданного подразделения. И отдел взялся за работу. Были найдены ошибки с присоединением файлов по 4 ГБ (система не предназначалась для хранения файлов, просто в одной из бизнес-операций необходимо было приложить скриншот), была обнаружена ошибка смещения на 4 пикселя текста подписи относительно элемента для ввода данных и т.д. Релиз всех впечатлил всего 9 ошибок из релиза против найденных в тестировании 42. А это уже 82%. Целевой KPI был все ближе.
Дальше уже можно и не рассказывать...
Когда девочка из отдела тестирования стала встречаться с мальчиком из отдела разработки, он не смог отказать любимой. Появилась куча мелких багов, за обнаружение которых девочку очень хвалили и ставили всем в пример.
После корпоратива, когда отдел тестирования нашел общий язык с ServiceDesk-ом, часть багов из релиза перестала фиксироваться в баг-трекере.
Так что, к дате отчета по проекту KPI был достигнут и даже немножко перевыполнен. А пользователи, ну что пользователи, в этом году всех интересовало успешное завершение проекта по внедрению приемочного тестирования.
можно к себе утащить ?:)
ОтветитьУдалитьКонечно
УдалитьШикарно. Я тоже украду!
ОтветитьУдалитьИ правильно. Может хоть на один такой KPI где то станет меньше.
УдалитьГосподи, когда пойем, что люди свободны в поиске способов обойти любую систему...
ОтветитьУдалитьАга, как только появляется показатель, он может и дает некий положительный эффект, а вот потом... Потом люди придумывают как его обмануть, причем даже в ущерб делу...
УдалитьНа самом деле общеизвестный факт, что плохих KPI не бывает. Бывает использование KPI не по назначению. И этот кейс в очередной раз это подтвердил.
ОтветитьУдалитьХм, что то я пока мало встречал KPI, которые обеспечивали бы поддержку долгосрочных целей. В основной своей массе начинается "использование KPI не по назначению".
УдалитьСугубо, имхо. Дело в кривизне KPI. Надо было KPI = (количество _критических_ ошибок в эксплуатации) / KSLOC в год.
ОтветитьУдалитьУгу, а потом появляются в коде вот такие места.
УдалитьГлавный KPI - это customer satisfaction на единицу затраченных килоденег :)
ОтветитьУдалитьУгу, вот только осталось выяснить как померить эту самую сатисфакшен. Электроды не приладишь, да и customer это только одно из заинтересованных лиц. Особенно это заметно в госконтрактах.
Удалить