Глава 18 Количественная оценка ценности

Глава 18

Количественная оценка ценности

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

Прибыль на инвестиции =(Ценность – Затраты) / Затраты

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

Порой обоснование принимало слегка иную форму:

ТДМ: Одной из первых моих обязанностей менеджера было управление проектом по установке программы централизованного биллинга для French National Merchandise Marte La Villette (Париж). Планировалась замена старой системы, находившейся в филиале в Les Halles. В La Villette вся биллинговая информация передавалась в цифровой форме. Ручная система для исполнения той же функции в Les Halles использовала сеть пневматических труб для отсылки квитанций и счетов, которые под давлением воздуха носились со свистом по всему этажу. Сеть пневматических труб была установлена в Les Halles во времена Всемирной выставки в 1897 году. В 1897 году еще почти не было резиновых изделий, чтобы обеспечить герметичность, поэтому трубы были целиком сделаны из свинца. Когда строили Les Halles, цена свинца составляла всего несколько сантимов за килограмм. Когда мы их демонтировали, цена свинца составляла более семи франков за килограмм. А там было очень много свинца. Денег, вырученных при сдаче свинца в утиль, хватило для оплаты всего проекта, включая аппаратное оборудование и программное обеспечение.

Что изменилось сегодня?

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

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

Затраты = $6235812,55

Выгоды = «Нам это необходимо»

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

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

Все это ведет к неизбежному принципу:

Затраты и выгоды следует определять с одинаковой точностью

Когда выгоду нельзя указать точнее, чем «Нам это необходимо», тогда и указание по затратам пусть будет «это окажется дороговато». Если затраты указаны в диаграмме риска, выгоды должны быть указаны в такой же форме (подробнее об этом см. главы 21-23).

Вопрос ответственности

Когда руководители разработки несут ответственность за проект, они обязаны представить в явном виде заданный бюджет времени и затрат, снабженный указанием на присущие проекту неопределенности (например, в форме диаграммы риска). Затем они должны руководить проектом так, чтобы подтвердить свои предсказания. Здесь появляются два компонента: предсказанная и реализованная производительность.

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

Оправдания: 45328 причин, по которым мы не можем точно указать выгоду

Оправдания для плохо прогнозируемых выгод стали удивительно искусными. Наиболее типичен такой вариант:

«Преимуществом данной системы является то, что мы сумеем с ее помощью выжить, <подходяшее к случаю междометие>!».

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

Среди других причин, по которым компании не делают тщательных предсказаний выгоды и оценок реализации выгоды, встречаются следующие:

• Система слишком мала для нас, чтобы стоило беспокоиться о ней.

• Нет выбора, создавать или не создавать эту систему.

• Создать систему требует контролирующий орган.

• Выгода полностью определяется соответствием потребности рынка.

• Система является заменой ныне действующей системы.

• Заявка исходит с самого верха.

• Выгода слишком неопределенна и не поддается количественной оценке.

• Заказчик сказал: «Поверьте мне, это стоит сделать».

• Оценка выгоды все равно не будет правдоподобной.

По этому последнему пункту наш коллега Стив МакМенамин, в бытность вице-президентом Edison International, отметил следующее:

Есть класс подразумеваемой экономии, называемый мною «общая производительность». Он имеет следующую форму: «Если применить новую систему сбора данных, каждый работник сэкономит хотя бы две минуты в день, что добавляет к среднегодовой экономии по организации в целом 42 квазиллиона долларов». Нельзя сказать, что в таких заявлениях нет ни крупицы потенциальной правды. Но они являются таким надежным прикрытием для дурацких проектов и предлагающих их консультантов, что заявления о выгоде «общей производительности» встречают уничтожающим и обычно вполне заслуженным презрением. Я обычно сомневаюсь в них по крайней мере на 100%.

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

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

Самые большие риски вашей компании

Какое все это имеет отношение к риску и управлению рисками? До сих пор мы рассматривали управление рисками на уровне руководителей проектов и руководителей IT-служб. Теперь поднимемся на одну ступень выше. В то время как на уровне IT самые большие риски являются технологическими (связанными с продуктом либо <……> связанными с проектом), самые большие риски <……> потраченным на малоценные проекты усилиям и <……> стоимости упущенных ценных проектов.

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

ТРЛ: В 1990-х годах многие из моих клиентов зациклились на улучшении неправильных процессов. Они все помешались на процессе построения проектов. Единственный по-настоящему значимый процесс – это тот, который определяет какие проекты стоит осуществлять. По иронии судьбы, в некоторых из известных мне компаний, особенно озабоченных процессами, не существует определенного процесса инициации проекта – это делается авторитарным решением.

Пять элементов расчета выгоды

Настойчивое утверждение того, что ответственность за выгоду от системы эквивалентна ответственности за расходы, ведет к следующей схеме расчета выгоды:

• Участники проекта объявляют ожидаемую выгоду в то же самое время, когда разработчики объявляют ожидаемые стоимость и расписание работ, причем с одинаковой точностью.

• Участники проекта выражают неопределенность своих ожиданий по выгоде тем же способом, каким разработчики указывают неопределенность в своих расчетах стоимости и расписания (см. подробности в главе 21).

• Участники проекта оценивают сравнительную ценность компонентов системы, чтобы обеспечить основу для выбора версии и осуществлять разумный анализ чувствительности и инкрементный анализ выгод и затрат (см. подробности в главе 22).

• Руководство утверждает проект на основе тщательного сравнения выгод и затрат, а также сопутствующих им неопределенностей (см. подробности в главе 23).

• Руководство оценивает фактическое значение выгоды и проводит оценку для получения входных данных для процесса анализа после завершения проекта.

Этот подход примерно совпадает с тем, что Барри Боэм (Barry Boehm) называет разработкой программного обеспечения на основе ценности (Value-Based Software Engineering). Боэм так комментирует необходимость стоимостной основы:

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

Далее, теория, с которой знакомится большинство современных студентов, охватывает примерно 15% того, с чем им предстоит столкнуться на практике. Большая часть ее основывается на модели разработки программного обеспечения как работе с поставленным заданием по написанию и отладке кода на основе постоянного (неизменного) набора требований. Это было хорошей моделью в 1970-х годах… но сейчас явно устарело. В 1970-х годах программное обеспечение составляло небольшую часть в большинстве систем, а стабильность требований означала, что вы часто могли «разделить задачи» и решать проблемы с соответствием программного кода требованиям совершенно отдельно от остальных частей проекта. Но все это теперь изменилось. Программное обеспечение критично привязано к добавочной ценности, создаваемой системой, его гибкость – ключ к адаптации и возможным изменениям, а разработка программного обеспечения теперь все меньше и меньше напоминает «сплошное программирование»[29].

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