Вальсируя с медведями
Добавить в закладки К обложке
- Вступительное замечание авторов - Страница 1
- ПрологЭтика веры - Страница 2
- Часть IПочему? - Страница 4
- Глава 1Стремление к рискам - Страница 5
- Глава 2Управление рисками – это управление проектами для взрослых - Страница 8
- Глава 3Пересмотр истории международного аэропорта в Денвере - Страница 12
- Глава 4Доводы в пользу управления рисками - Страница 15
- Часть IIПочему бы и нет? - Страница 18
- Глава 5Доводы против управления рисками - Страница 19
- Глава 6Бремя ответственности за неопределенность - Страница 21
- Глава 7Удача - Страница 23
- Часть IIIКак? - Страница 25
- Глава 8Количественное определение неопределенности - Страница 26
- Глава 9Механика управления рисками - Страница 29
- Глава 10Правила управления рисками - Страница 34
- Глава 11Возвращение к основам - Страница 37
- Глава 12Инструменты и процедуры - Страница 41
- Глава 13Основные риски проекта по разработке программного обеспечения - Страница 44
- Глава 14Уточненный процесс обнаружения рисков - Страница 49
- Глава 15Динамика управления рисками - Страница 53
- Глава 16Инкрементный метод для ослабления рисков - Страница 55
- Глава 17Стратегия максимального ослабления рисков - Страница 59
- Часть IVСколько? - Страница 61
- Глава 18Количественная оценка ценности - Страница 62
- Глава 19Ценность – это тоже неопределенность - Страница 65
- Глава 20Анализ чувствительности - Страница 67
- Глава 21Выгоды возмещают риски - Страница 69
- Глава 22Уточнение правил управления рисками - Страница 70
- Часть VТак есть или нет? - Страница 72
- Глава 23Тест на управление риском - Страница 73
- Приложение АВильям Кингдон КлиффордЭтика веры, Часть 1 - Страница 75
- Приложение БШаблон для описания риска - Страница 79
- Ссылки - Страница 80
Глава 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).
Вопрос ответственностиКогда руководители разработки несут ответственность за проект, они обязаны представить в явном виде заданный бюджет времени и затрат, снабженный указанием на присущие проекту неопределенности (например, в форме диаграммы риска). Затем они должны руководить проектом так, чтобы подтвердить свои предсказания. Здесь появляются два компонента: предсказанная и реализованная производительность.