Про ИТ-менеджмент

Постараемся сделать мир чуточку счастливее

Previous Entry Поделиться Next Entry
Фундаментальная проблема IT: как измерить количество выпускаемой продукции?
anton_nix
Вот хочу я например предпринять что-то по улучшению работы компании. Или, хотя бы, улучшить работу команды, разрабатывающей ПО.

Внимание вопрос: как я могу быть уверен, что моё улучшение действительно улучшило работу команды?

Что такое улучшение? Это значит, что:

  • мы увеличили продуктивность, т.е. кол-во изготавливаемого продукта в единицу времени (Throughput в терминах Lean или TOC).

  • мы увеличили скорость поставки (Lead Time), т.е. продукта выпускаем столько же, но время от заказа до поставки сократилось.

  • мы улучшили качество продукции (Quality). Качество в широком смысле: меньше стало дефектов, лучше исходный код (т.е. систему легче стало поддерживать), улучшилось быстродействие и другие нефункциональные характеристики.

  • мы стали тратить меньше ресурсов на изготовление продукции (OE, Operational Expenses). Например, переключили одного человека на другой проект.


Примечание: эти KPI взяты из Теории Ограничений, но вместо Inventory я взял Lead Time, т.к. по-моему это взаимозаменяемые вещи при остальных равных условиях, а Lead Time понятнее.

Так вот, фишка в том, что о действительном улучшении можно говорить только в том случае, когда одна из этих характеристик улучшилась, а другие не ухудшились. Т.е. если мы хотим быть уверенными, что улучшение действительно состоялось, то мерить надо все четыре!


И главная загвоздка в том, что в нашей сфере разработки ПО, нормально померить можно только Lead Time и Operational Expenses! А вот Quality и Throughput мерить очень сложно. Быстродействие и дефекты еще можно более-менее измерить, и то, с большой натяжкой. Но как измерить улучшение качества архитектуры или исходного кода? А ведь это в долгосрочной перспективе может сильно сказаться на Throughput и других KPI.

Но вот сложнее всего дело обстоит с Throughput. В чем его измерять? В кол-ве удовлетворенных запросов заказчика? Но ведь они могут быть очень разные по трудоемкости. В кол-ве стори поинтов? Тоже довольно абстрактная величина, и команда, при малейшем желании, может легко устроить инфляцию стори поинтов :) В кол-ве строк исходного кода? Про это вообще ходят легедны, насколько легко это "подделывается".

Единственный способ, на который я пока возлагаю какие-то надежды - это функциональные точки (Function Points) или юзкейс-поинты (Use Case Points). Но эти штуки зато считать очень трудоемко, их подсчет очень сложно автоматизировать, да и вообще это требует огромных изменений в подходе к разработке: детальные спецификации и их жуткая стандартизация. Да и раз это сложно автоматизировать, то здесь, опять же, вполне возможно подделать выходные результаты.

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

?

Log in

No account? Create an account