Как измерить все, что угодно

К 1999 г. я проверил свой метод количественного анализа на базе прикладной информационной экономики примерно на 20 крупных проектах инвестиций в ИТ. В каждом случае нужно было оценить от 40 до 80 величин, таких как первоначальные затраты на разработку, темп восприятия нововведений, рост производительности труда, рост доходов и т. д. При анализе каждого проекта я запускал макрос на основе Excel, который рассчитывал стоимость информации о каждой переменной. Это позволяло мне решить, какие величины необходимо определить в первую очередь.

Работая с этой программой, я стал замечать следующие закономерности.

• Стоимость информации о подавляющем большинстве переменных равна нулю, то есть существующий уровень неопределенности для них вполне приемлем и дальнейшие измерения были бы (это уже упоминалось в главе 3) экономически нецелесообразными.

• Особенно высока стоимость информации о тех переменных, которые клиенты обычно не оценивают. При обосновании предыдущих проектов эти важные величины ни разу не определялись.

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

Анализ всей проведенной мной работы по исследованию указанных проектов и расчету стоимости полученной информации позволил подтвердить выявленную закономерность. Я написал на эту тему статью под названием «The IT Measurement Inversion» («Инверсия ИТ-измерений»), которая была опубликована в «CIO Magazine» в 1999 г.[24]

Полученные впоследствии данные продолжали подтверждать мои первоначальные наблюдения. Однако я заметил, что данная тенденция характерна для проектов, касающихся не только ИТ, но и военной логистики, защиты окружающей среды, венчурного капитала и расширения производственных мощностей. Клиенты почти всегда удивляются тому, какая информация оказывается для них самой ценной. Снова и снова я убеждался: люди тратят массу времени, сил и денег на измерение того, что не имеет большой информационной стоимости, и игнорируют величины, действительно важные для принятия решений. В конце концов, я отказался от прежнего названия «Инверсия ИТ-измерений» и переименовал этот феномен в инверсию измерений. Ведь тенденция к оценке незначащих вещей и игнорированию важных факторов наблюдается в самых разных областях.

Более того, я часто вижу: начав измерять что-то совершенно иное (осознав его информационную ценность), клиенты рассматривают результат как настоящее открытие. Иными словами, если вы жаждете прозрения, обратите внимание на переменную, которую прежде игнорировали. Все эти мои наблюдения суммированы в рисунке 7.4.

ИНВЕРСИЯ ИЗМЕРЕНИЙ

При обосновании проекта экономическая стоимость результатов измерения переменной обычно обратно пропорциональна тому, какое значение придается ее оценке.

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

Яркой иллюстрацией инверсии измерений может служить пример моего клиента — крупной британской страховой компании, активно применявшей метод определения сложности и трудоемкости программного обеспечения, называемый балльной функциональной оценкой. Он был популярен в 1980–1990-е годы и использовался для расчета затрат труда на крупные программные разработки. Компания проделала большую работу и собрала первоначальные оценки, балльные функциональные оценки и данные о фактических затратах труда на реализацию более чем 300 проектов в области информационных технологий. Три-четыре штатных сотрудника занимались исключительно подсчетом баллов. Ранее компании еще не приходилось тратить столько сил на анализ отдельных аспектов планируемых проектов по созданию нового программного обеспечения.

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

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