2. большая прозрачность
3. большее привлечение пользователя в проекте с середины до конца
4. возможность отмены заключительной части проекта в силу понимания, что она в основном состоит из малополезных частей продукта
Инкрементный метод хорош для всех проектов… и является обязательным, когда риски высоки.
Глава 17
Часть IV
Глава 18
Глава 19
3. большее привлечение пользователя в проекте с середины до конца
4. возможность отмены заключительной части проекта в силу понимания, что она в основном состоит из малополезных частей продукта
Инкрементный метод хорош для всех проектов… и является обязательным, когда риски высоки.
Глава 17
Стратегия максимального ослабления рисков
Позвольте предложить вам небольшой мысленный эксперимент. Вам понравится. Представьте, что вы работаете на территории своего клиента в Чикаго. Среда, вторая половина дня. Вы узнаете, что очень важное совещание назначено в Сан-Франциско на полдень пятницы. Обстоятельства требуют вашего присутствия там, а сложные характеры некоторых участников превращают опоздание в катастрофу. Вам просто необходимо быть там вовремя.
Вы ныряете в Интернет и обнаруживаете рейс American Airlines в 8:40 из аэропорта O'Hara, на который еще есть билеты, он прибывает в Сан-Франциско в 11:21. Прикинем: с собой только ручная кладь, в это время очереди на такси быть не должно и пробки на шоссе не такие уж страшные. Если повезет там и здесь со своевременным взлетом и посадкой, не будет никаких задержек при входе или выходе, никаких пробок и заторов на дорогах, то, возможно, вам повезет добраться до офиса в Сан-Франциско минут за пять-десять до начала совещания.
Но на этом задержим внимание: план, зависящий от того, что вам должна везде улыбаться удача, вряд ли можно назвать свободным от риска. Если вам не будет сопутствовать везение на каждом шагу, то вы опоздаете. Ничего хорошего. Итак, вы теперь переходите в режим ослабления риска. Как поменять план, чтобы защитить себя от очевидных рисков?
Тут не требуется быть семи пядей во лбу. Не требуется умения читать чужие мысли, чтобы угадать, что вашим первым импульсом будет найти возможность более раннего вылета. Рейс на рассвете (в б утра) не вызывает восторга, но зато оставляет в запасе пару часов. А что если прилететь накануне вечером и обосноваться в отеле рядом с офисом?
Ваш «проект» в данном случае состоит в попадании в Сан-Франциско. Самое важное для вас — выполнить его своевременно, наиболее естественное решение для вас — раньше приступить к проекту. Это каждому понятно, то есть, разумеется, кроме разработчиков IТ-проектов.
Чтобы убедиться в этом, следует рассмотреть обстоятельства принятия типичного решения о начале проекта. Это может выглядеть примерно так:
С другой стороны, дерзкое руководство стремится идти на возможное увеличение рисков, если это окупится. Всегда требуется мужество, чтобы начинать проекты достаточно рано. Это всегда требует от кого-то решения, которое еще не оправдано рынком. Это означает трату денег на что-то не вполне надежное.
Ирония состоит в том, что множество проектов оказываются под угрозой срыва сроков поставки из-за того, что руководители ушли от другого риска, куда более важного, связанного с ранним стартом.
ТДМ: В начале 1996 года одна из моих клиенток была менеджером крупного проекта по разработке встроенного программного обеспечения. Ее задача состояла в создании системного программного обеспечения новой линейки товаров, которую отдел маркетинга рвался срочно запустить на рынок. Главным заказчиком для нее был руководитель службы маркетинга Ганс, который выдвинул этот проект и получил на него финансирование. Ганс рассердился, когда команда моей клиентки назначила сроком сдачи четвертый квартал 1997 года. Он настаивал на сдаче 31 марта 1997 года. Он заклеймил ее расчеты на публичном совещании, объявив их недостаточно напористыми, и завершил свою речь словами (к несчастью для него): «Я берусь доказать, что каждый месяц после марта компания будет терять в виде упущенной прибыли 110000 долларов, если не будет готова отгружать эти товары».
Я уточнил у него по поводу этого заявления: «Ганс, а эта цифра относится к сроку завершения до 31 марта? Если бы мы завершили к концу февраля, например, получили бы мы дополнительно 110000 долларов прибыли, сверх запланированного вами дохода?»
«Да, — сказал он. — Наверняка».
«А если бы закончили к концу января? — настаивал я. — Дало бы это еще 110000 долларов прибыли?»
«Да», — ответил он.
«А если бы мы могли вручить вам готовый продукт сегодня (это было в феврале 1996 года, когда только было открыто финансирование проекта) вы бы получали дополнительно по 110000 долларов ежемесячно до конца года?»
«Да», — ответил он, теперь несколько потеряв былую самоуверенность.
«Ну тогда, Ганс, очевидно, что вы слишком поздно начали этот проект. Если бы вы дали старт 18 месяцев назад, мы бы могли уже отгружать этот продукт и получать все эти месяцы по 110000 долларов дополнительной прибыли…» Я предоставил ему самостоятельно понять, что подразумевалось.
Вы ныряете в Интернет и обнаруживаете рейс American Airlines в 8:40 из аэропорта O'Hara, на который еще есть билеты, он прибывает в Сан-Франциско в 11:21. Прикинем: с собой только ручная кладь, в это время очереди на такси быть не должно и пробки на шоссе не такие уж страшные. Если повезет там и здесь со своевременным взлетом и посадкой, не будет никаких задержек при входе или выходе, никаких пробок и заторов на дорогах, то, возможно, вам повезет добраться до офиса в Сан-Франциско минут за пять-десять до начала совещания.
Но на этом задержим внимание: план, зависящий от того, что вам должна везде улыбаться удача, вряд ли можно назвать свободным от риска. Если вам не будет сопутствовать везение на каждом шагу, то вы опоздаете. Ничего хорошего. Итак, вы теперь переходите в режим ослабления риска. Как поменять план, чтобы защитить себя от очевидных рисков?
Тут не требуется быть семи пядей во лбу. Не требуется умения читать чужие мысли, чтобы угадать, что вашим первым импульсом будет найти возможность более раннего вылета. Рейс на рассвете (в б утра) не вызывает восторга, но зато оставляет в запасе пару часов. А что если прилететь накануне вечером и обосноваться в отеле рядом с офисом?
Ваш «проект» в данном случае состоит в попадании в Сан-Франциско. Самое важное для вас — выполнить его своевременно, наиболее естественное решение для вас — раньше приступить к проекту. Это каждому понятно, то есть, разумеется, кроме разработчиков IТ-проектов.
Шутка о нас
Можно слегка пошутить на тему отличия нашего («айтишного») подхода к сдерживанию риска от всех прочих. Эта шутка звучала бы примерно так:IT-менеджер и нормальный человек оказываются в одинаковой ситуации: работают в Чикаго и после обеда в среду узнают, что надо быть в Сан-Франциско на совещании в полдень пятницы, причем строго необходимо попасть туда вовремя. Нормальный человек (назовем ее Дианой) вылетает вечером в четверг и устраивается в славном небольшом отеле, расположенном всего за квартал от нужного офиса. Она неспешно ужинает в хорошем ресторане и успевает прогуляться до магазина, чтобы запастись фотопленкой. На следующее утро она с удовольствием и не торопясь завтракает, а потом работает на своем портативном компьютере до 11 часов. Она выходит в 11:30 и, совершив променад до офиса, попадает туда за 10 минут до начала совещания.В проектах, где критичен срок сдачи, реальным ослаблением риска является раннее начало. Это, пожалуй, единственный эффективный способ сдерживания риска опоздания для большинства проектов. Да, мы знаем, что уже слишком поздно, чтобы начать наш проект рано, он начался, когда начался, и вы уже влипли. И вы читаете эту книгу не для того, чтобы узнать, как вы могли бы так не влипнуть. Вы хотите найти выход из этого положения. Все это правда. Но выбор раннего старта все равно для вас полезен, как будет показано ниже.
А теперь IT-менеджер Джек. Он покупает билет на 8:40 в пятницу. Поймав такси в городе в 7:05, попадает в пробку и гневно жалуется на это шоферу всю дорогу до аэропорта. Тупой водитель никак не уразумеет, как важно Джеку не опоздать на этот рейс. Pегистрируясь в аэропорту, он с нажимом объясняет клерку, что самолет должен взлететь и приземлиться точно по расписанию и никаких оправданий он не примет. Он говорит, что будет «весьма и весьма разочарован» в случае любого опоздания. Когда объявляют о задержке рейса, Джек вскакивает и громко ругается. Когда объявляется измененное время отправки рейса, он роется в своих управленческих инструментах и выкапывает оттуда ультиматум: «Если меня не доставят вовремя на совещание в Сан-Франциско, ПОЛЕТЯТ ГОЛОВЫ!»
Отважное и робкое руководство
Во-первых, следует разобраться с одним деловым поверьем, которое иначе будет мешаться у нас на дороге: представление о том, что начинать проект без малейшего запаса времени — признак по-настоящему отважного стиля руководства, а противоположное является признаком трусости.Чтобы убедиться в этом, следует рассмотреть обстоятельства принятия типичного решения о начале проекта. Это может выглядеть примерно так:
Сейчас в экономике некоторый спад, но в ближайшие пару кварталов дело должно выправиться. Начиная сейчас создавать новую версию нашего продукта, мы опередим своих конкурентов, когда рынок оживет, следовательно, нам нужно браться за осуществление этого проекта. Но что будет, если рынок не восстановится в ожидаемые нами сроки? Может, лучше подождать, пока это произойдет на самом деле. Если спрос возрастет в начале следующего года, тогда мы и начнем этот проект. А если спячка продержится до лета, мы сможем до той поры легко обойтись без затрат на этот проект.Это — робкое руководство в худшем своем проявлении.
С другой стороны, дерзкое руководство стремится идти на возможное увеличение рисков, если это окупится. Всегда требуется мужество, чтобы начинать проекты достаточно рано. Это всегда требует от кого-то решения, которое еще не оправдано рынком. Это означает трату денег на что-то не вполне надежное.
Ирония состоит в том, что множество проектов оказываются под угрозой срыва сроков поставки из-за того, что руководители ушли от другого риска, куда более важного, связанного с ранним стартом.
Почему важна возможность раннего старта, даже если вы не можете ее реализовать
Проекты, которые завершаются с опозданием — это почти всегда те проекты, которые слишком поздно начаты. А слишком поздно начатые проекты — признак нехватки видения и мужества у высшего руководства. Если вам грозят снести голову за недостаточно быстрое завершение работы, вы быстро понимаете, что проект был начат недостаточно рано. Это — заклинание, которое многим организациям следовало бы принять на вооружение.ТДМ: В начале 1996 года одна из моих клиенток была менеджером крупного проекта по разработке встроенного программного обеспечения. Ее задача состояла в создании системного программного обеспечения новой линейки товаров, которую отдел маркетинга рвался срочно запустить на рынок. Главным заказчиком для нее был руководитель службы маркетинга Ганс, который выдвинул этот проект и получил на него финансирование. Ганс рассердился, когда команда моей клиентки назначила сроком сдачи четвертый квартал 1997 года. Он настаивал на сдаче 31 марта 1997 года. Он заклеймил ее расчеты на публичном совещании, объявив их недостаточно напористыми, и завершил свою речь словами (к несчастью для него): «Я берусь доказать, что каждый месяц после марта компания будет терять в виде упущенной прибыли 110000 долларов, если не будет готова отгружать эти товары».
Я уточнил у него по поводу этого заявления: «Ганс, а эта цифра относится к сроку завершения до 31 марта? Если бы мы завершили к концу февраля, например, получили бы мы дополнительно 110000 долларов прибыли, сверх запланированного вами дохода?»
«Да, — сказал он. — Наверняка».
«А если бы закончили к концу января? — настаивал я. — Дало бы это еще 110000 долларов прибыли?»
«Да», — ответил он.
«А если бы мы могли вручить вам готовый продукт сегодня (это было в феврале 1996 года, когда только было открыто финансирование проекта) вы бы получали дополнительно по 110000 долларов ежемесячно до конца года?»
«Да», — ответил он, теперь несколько потеряв былую самоуверенность.
«Ну тогда, Ганс, очевидно, что вы слишком поздно начали этот проект. Если бы вы дали старт 18 месяцев назад, мы бы могли уже отгружать этот продукт и получать все эти месяцы по 110000 долларов дополнительной прибыли…» Я предоставил ему самостоятельно понять, что подразумевалось.
Часть IV
Сколько?
• Сколько риска можно себе позволить?
• Как ценность компенсирует риски?
• Как можно реалистично оценить ценность (выгоду) нового проекта?
• Как можно убедиться, что ожидаемая выгода реально получена?
• Как обращаться с выгодой, которая представляет собой неопределенную величину?
• Какой смысл в обосновании выгод и затрат, которое пытается сравнить неопределенные затраты с неопределенной выгодой?
• Как ценность компенсирует риски?
• Как можно реалистично оценить ценность (выгоду) нового проекта?
• Как можно убедиться, что ожидаемая выгода реально получена?
• Как обращаться с выгодой, которая представляет собой неопределенную величину?
• Какой смысл в обосновании выгод и затрат, которое пытается сравнить неопределенные затраты с неопределенной выгодой?
Глава 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).
Аналогично, участники проекта должны быть ответственны за предсказанные и реализованные выгоды. Точность или неточность этих количественных оценок выгоды должна быть примерно равна точности или неточности затрат.
Среди других причин, по которым компании не делают тщательных предсказаний выгоды и оценок реализации выгоды, встречаются следующие:
• Система слишком мала для нас, чтобы стоило беспокоиться о ней.
• Нет выбора, создавать или не создавать эту систему.
• Создать систему требует контролирующий орган.
• Выгода полностью определяется соответствием потребности рынка.
• Система является заменой ныне действующей системы.
• Заявка исходит с самого верха.
• Выгода слишком неопределенна и не поддается количественной оценке.
• Заказчик сказал: «Поверьте мне, это стоит сделать».
• Оценка выгоды все равно не будет правдоподобной.
По этому последнему пункту наш коллега Стив МакМенамин, в бытность вице-президентом Edison International, отметил следующее:
Мы еще не включили в свой список причин, по которым компании не делают точных предсказаний выгоды и оценок ее реализации, такую причину, которая часто встречается, но редко упоминается: выгода является крохотной или несуществующей. Как общее практическое правило можно принять, что при отсутствии количественной оценки выгоды, ее нет вовсе.
Решительная позиция по принятию рисков должна руководствоваться выгодой. Количество рисков, которое вы готовы принять должны являться функцией от того, какова может быть выгода от этого риска.
ТРЛ: В 1990-х годах многие из моих клиентов зациклились на улучшении неправильных процессов. Они все помешались на процессе построения проектов. Единственный по-настоящему значимый процесс — это тот, который определяет какие проекты стоит осуществлять. По иронии судьбы, в некоторых из известных мне компаний, особенно озабоченных процессами, не существует определенного процесса инициации проекта — это делается авторитарным решением.
• Участники проекта объявляют ожидаемую выгоду в то же самое время, когда разработчики объявляют ожидаемые стоимость и расписание работ, причем с одинаковой точностью.
• Участники проекта выражают неопределенность своих ожиданий по выгоде тем же способом, каким разработчики указывают неопределенность в своих расчетах стоимости и расписания (см. подробности в главе 21).
• Участники проекта оценивают сравнительную ценность компонентов системы, чтобы обеспечить основу для выбора версии и осуществлять разумный анализ чувствительности и инкрементный анализ выгод и затрат (см. подробности в главе 22).
• Руководство утверждает проект на основе тщательного сравнения выгод и затрат, а также сопутствующих им неопределенностей (см. подробности в главе 23).
• Руководство оценивает фактическое значение выгоды и проводит оценку для получения входных данных для процесса анализа после завершения проекта.
Этот подход примерно совпадает с тем, что Барри Боэм (Barry Boehm) называет разработкой программного обеспечения на основе ценности (Value-Based Software Engineering). Боэм так комментирует необходимость стоимостной основы:
Прибыль на инвестиции =(Ценность — Затраты) / Затраты
Для демонстрации своего почтения к стоимости денег во времени, мы выражали различные потоки затрат и сбережений в терминах чистой приведенной стоимости (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].
Глава 19
Ценность — это тоже неопределенность
Участники проекта часто отговариваются от оценок выгодности новой системы, потому что считают, что она слишком неопределенна для прогнозов. Самое честное, что они могут придумать в ответ на вопрос об ожидаемой выгоде: «Я не знаю». Им нужна та же автоматическая реакция, к которой мы призывали вас в главе II: при произнесении слов «я не знаю» переключаться в режим указания границ неопределенности и начинать строить диаграммы неопределенности.
Люди, вынужденные связать себя такими обязательствами, будут настаивать на приписывании этим ожиданиям некоторых явных допущений участника проекта, в том же духе, в каком делает допущения менеджер проекта относительно рисков, которыми он не управляет, и которые находятся в чужой зоне ответственности. Допущение участника проекта могло бы выглядеть как-то так: «Все ставки снимаются, если система окажется нестабильной». Для каждой диаграммы неопределенности, вроде приведенной выше, существует эквивалент в кумулятивной форме, подобный этому:
Легко говорить о будущих рыночных нишах, но существует до крайности мало примеров, которые можно выкопать из прошлого. VisiCalc явно получила свой продукт до того, как заполнилась какая бы то ни было рыночная ниша, но как объяснить Lotus Notes? А всякая рыночная ниша для электронных таблиц была забита до отказа задолго до появления Excel. Как же понять тогда, что Excel стал доминирующей системой электронных таблиц? Или Google, далеко-далеко промахнувшийся мимо своей рыночной ниши, по этой теории никак не мог стать доминирующим на рынке поисковиков, но ведь как-то стал им!
Если рыночная ниша имеет хоть какое-то значение, то, во всяком случае, оно не бинарное. Ответный ход состоит в том, чтобы обязать заказчика описать ожидаемую выгоду для всего диапазона возможных сроков поставки. Диапазон дат, указанный в диаграмме риска, представленной разработчиками, должен быть охвачен и набором диаграмм, представленным заказчиком и показывающим ожидаемую выгоду при любой из дат в этом диапазоне. Не так-то легко выиграть от получения этих диаграмм. Указание нулевой или отрицательной выгоды при поставке продукта позднее некоторой даты может обернуться против того, кто утвердит эту зловещую дату. Поскольку выгода находится в центре широкого противодействия риску в организации, быстрое и свободное рассмотрение различных предсказаний выгоды (их недооценка или переоценка) не будет рассматриваться как знак отличия.
Выгода? Ну, возможны варианты…
Для систем, предназначенных скорее для упрочения положения на рынке, чем для замещения затратных или трудоемких операций, реально существуют некоторые неизвестные параметры вероятной выгоды. Рынок может немедленно наброситься на новый продукт, а может прореагировать и крайне вяло. Конкуренты могут незаметно опередить вас с этим новым продуктом, либо выведя аналогичный товар на рынок раньше нас, либо объявив, что у них вот-вот появится товар с кучей новых соблазнительных характеристик. В любом из этих случаев реальная ценность вашей новой системы сократится по сравнению с наиболее оптимистичными ожиданиями. Сама формулировка таких сомнений привлекает внимание к тому факту, что существуют «наиболее оптимистичные ожидания». Первый этап предсказания ценности состоит в количественной оценке наиболее оптимистичных ожиданий и выражении ее в денежном эквиваленте дохода или процентах дополнительной доли рынка. Аналогично можно количественно оценить наименее оптимистичные ожидания. Какая-то точка между этими значениями и будет представлять наиболее правдоподобные ожидания. Эти три точки дают рудиментарную диаграмму неопределенности, очерчивающую риски, связанные с ожидаемой выгодой:Люди, вынужденные связать себя такими обязательствами, будут настаивать на приписывании этим ожиданиям некоторых явных допущений участника проекта, в том же духе, в каком делает допущения менеджер проекта относительно рисков, которыми он не управляет, и которые находятся в чужой зоне ответственности. Допущение участника проекта могло бы выглядеть как-то так: «Все ставки снимаются, если система окажется нестабильной». Для каждой диаграммы неопределенности, вроде приведенной выше, существует эквивалент в кумулятивной форме, подобный этому:
Рыночная ниша
Великая иллюзия относительно рыночной ниши является самой надежной и чаще всего используемой отговоркой, чтобы не делать продуманных оценок выгоды. Заказчик может конфиденциально говорить о выгодах, которые удастся извлечь только в том случае, если у разработчиков система будет готова до того, как заполнится рыночная ниша. Можно говорить о любом количестве выгоды, потому что этому сопутствует тактика уверения, что рыночная ниша заполнится до даты, успеть к которой абсолютно невозможно. Таким образом, проект оказывается изначально обреченным на неудачу, да и заказчик избегает всякой ответственности.Легко говорить о будущих рыночных нишах, но существует до крайности мало примеров, которые можно выкопать из прошлого. VisiCalc явно получила свой продукт до того, как заполнилась какая бы то ни было рыночная ниша, но как объяснить Lotus Notes? А всякая рыночная ниша для электронных таблиц была забита до отказа задолго до появления Excel. Как же понять тогда, что Excel стал доминирующей системой электронных таблиц? Или Google, далеко-далеко промахнувшийся мимо своей рыночной ниши, по этой теории никак не мог стать доминирующим на рынке поисковиков, но ведь как-то стал им!
Если рыночная ниша имеет хоть какое-то значение, то, во всяком случае, оно не бинарное. Ответный ход состоит в том, чтобы обязать заказчика описать ожидаемую выгоду для всего диапазона возможных сроков поставки. Диапазон дат, указанный в диаграмме риска, представленной разработчиками, должен быть охвачен и набором диаграмм, представленным заказчиком и показывающим ожидаемую выгоду при любой из дат в этом диапазоне. Не так-то легко выиграть от получения этих диаграмм. Указание нулевой или отрицательной выгоды при поставке продукта позднее некоторой даты может обернуться против того, кто утвердит эту зловещую дату. Поскольку выгода находится в центре широкого противодействия риску в организации, быстрое и свободное рассмотрение различных предсказаний выгоды (их недооценка или переоценка) не будет рассматриваться как знак отличия.