Великая иллюзия относительно рыночной ниши является самой надежной и чаще всего используемой отговоркой, чтобы не делать продуманных оценок выгоды. Заказчик может конфиденциально говорить о выгодах, которые удастся извлечь только в том случае, если у разработчиков система будет готова до того, как заполнится рыночная ниша. Можно говорить о любом количестве выгоды, потому что этому сопутствует тактика уверения, что рыночная ниша заполнится до даты, успеть к которой абсолютно невозможно. Таким образом, проект оказывается изначально обреченным на неудачу, да и заказчик избегает всякой ответственности.
Легко говорить о будущих рыночных нишах, но существует до крайности мало примеров, которые можно выкопать из прошлого. VisiCalc явно получила свой продукт до того, как заполнилась какая бы то ни было рыночная ниша, но как объяснить Lotus Notes? А всякая рыночная ниша для электронных таблиц была забита до отказа задолго до появления Excel. Как же понять тогда, что Excel стал доминирующей системой электронных таблиц? Или Google, далеко-далеко промахнувшийся мимо своей рыночной ниши, по этой теории никак не мог стать доминирующим на рынке поисковиков, но ведь как-то стал им!
Если рыночная ниша имеет хоть какое-то значение, то, во всяком случае, оно не бинарное. Ответный ход состоит в том, чтобы обязать заказчика описать ожидаемую выгоду для всего диапазона возможных сроков поставки. Диапазон дат, указанный в диаграмме риска, представленной разработчиками, должен быть охвачен и набором диаграмм, представленным заказчиком и показывающим ожидаемую выгоду при любой из дат в этом диапазоне. Не так-то легко выиграть от получения этих диаграмм. Указание нулевой или отрицательной выгоды при поставке продукта позднее некоторой даты может обернуться против того, кто утвердит эту зловещую дату. Поскольку выгода находится в центре широкого противодействия риску в организации, быстрое и свободное рассмотрение различных предсказаний выгоды (их недооценка или переоценка) не будет рассматриваться как знак отличия.
Новости из реального мира
Чтобы дополнить наш собственный опыт в оценке выгоды, мы опросили некоторых менеджеров, которым на практике приходилось пользоваться этим (а порой и терпеть неудачу). Как вы увидите, получилась восхитительная смесь успеха и неудач:
«Чем больше система, тем больше ответственность… размер выгоды тщательно проверяется, потому что будущие схемы финансирования расходов могут быть сокращены из-за невыполнимых обещаний…
Всегда есть ситуация, когда заявку делает «правильный» человек. В каждой организации есть несколько индивидуумов, которые легко получают то, что хотят, в силу их значимости для компании».
Кристина Дэвис, раньше работавшая в TI и Raytheon
«[работа без оценивания ценности] вынуждает принимать решения на основании лишь тестостерона[30]. Мой опыт подсказывает, что принятие решений, диктуемое тестостероном, не дает положительных результатов, если проследить их ценность в долгосрочной перспективе. На самом деле я считаю, что этот подход в лучшем случае портит карьеру…
Я также встречал весьма странное отношение к ответственности, выглядящее примерно так: «У проекта был полный успех (после того, правда, как мы переопределили понятие успеха)». Это обычно следует после одного из совещаний на поздних стадиях проекта, где «срезают функциональность». Это похоже на сэндвич: в начале проекта — ломоть хлеба, в конце — тот же ломоть хлеба, а в середине кусок какого-то мяса (вы надеетесь, что это мясо, но близко его рассматривать не стоит)».
Син Джексон, Howard Hughes Medical Insulate
«[должно быть] равенство ответственности у разработчиков и заказчиков. Заказчики отвечают за то, чтобы убедиться в том, что ожидаемая выгода получена. [Но] постоянно в своих обзорах мы обнаруживаем, что компании не отслеживают по факту, была ли получена ожидаемая выгода».
Роб Остин (Austin), профессор Гарвардской школы бизнеса
«Показатели экономии также классифицируют по тому, являются ли они сокращением или избежанием расходов. Это различие важно. Сокращение — это вычеты из текущего уже принятого бюджета. Вы (менеджер, делающий заявку на финансирование) уже получили эти деньги: вы соглашаетесь отказаться от них, если получите деньги на новую систему. Избежание расходов выглядит так: „Если у меня не будет этой системы, мне придется дополнительно нанять <столько-то> <таких-то работников> в <будущем году>. Но если у меня будет эта система, я обойдусь без этих расходов“. Это — любимый тип выгоды для тех, кто делает заявку на новую систему: одни обещания, никаких реальных жертв. Ловушка в том, что нет оснований верить, что вы бы получили средства для найма этих дополнительных работников. Вы меняете средства на будущие операционные расходы, которых вы могли бы и не получить вовсе, на основные фонды сегодня. Очень соблазнительно, но большинство из тех, кто распределяет бюджет, и рассматривает финансовые заявки, чуют это за версту. Корректной проверкой выгоды, связанной с избежанием затрат, является вопрос о неизбежности предполагаемых затрат. Другими словами, была бы непременно удовлетворена будущая бюджетная заявка. Это суровая проверка, но реальная выгода, связанная с избежанием затрат, может пройти ее и пройдет».
Стив МакМенамин, Atlantic Systems Guild
Картинка, возникшая из этих неформальных мнений, сама похожа на сэндвич, упомянутый в одной из цитат, но все же можно проследить пару занятных тенденций:
1. Организации, применяющие передовые практики, нацелены на проведение оценки выгоды, хотя могут менять ее форму от проекта к проекту.
2. Многие из них следуют схеме сокращения финансовых потоков, идущих сверху вниз, исходя из размера ожидаемой выгоды, что имела в виду Кристина, говоря, что «будущие схемы финансирования расходов могут быть сокращены из-за невыполнимых обещаний».
Наконец, даже эти организации в некоторых случаях удовлетворяются гарантиями стоимости типа «Поверьте мне, это сделать выгодно», но чаще всего это проходит, когда ответственность за затраты и за выгоду оказывается в руках одного заказчика.
Глава 20
Анализ чувствительности
Щепетильный предмет, которому посвящена данная глава, — увеличившаяся ответственность заказчика. Мы уже высказывались в пользу необходимости переложить ответственность за предсказание выгоды и измерение реально полученной выгоды на пользователей системы и заказчиков (причем с той же степенью точности, что и оценка затрат и фактические затраты). Теперь мы хотели бы привлечь внимание к некоторому использованию инкрементного метода в этом расчете выгоды. Щепетильность вопроса состоит в том, что вы не можете просто обязать своих клиентов к такой ответственности. Вы должны это выманивать лестью, уговаривать и просить об одолжении. Хотите ли вы действительно тратить, какой бы то ни было, политический капитал, который у вас может иметься, на эти кажущиеся невразумительными цели? В этой главе мы постараемся убедить вас, что вы этого хотите.
Если это — решение, то что является проблемой?
Проблема, на которую мы здесь нацелились, состоит в том, что большинство проектов разработки программного обеспечения по своей природе комплексные. Проект получает финансирование на основе какой-то ценности — либо имеющей явное количественное выражение, либо нет — которую должен принести полученный в результате продукт. Теперь стоит задать несколько вопросов: «В чем ценность этого продукта? Равномерно ли она распределена между всеми компонентами системы? Одинакова ли ценность этого модуля объемом в сто строк и того модуля (тоже из 100 строк), который восстанавливает конфигурацию после потери питания?»
Не стоит ручаться за то, что их ценность равна. Наш опыт (да и ваш, признайтесь) подсказывает, что ценность очень неравномерно распределена по системе. Основных денег система стоит из-за определенных ключевых функций, осуществляемых «в самом сердце» продукта или около него.
Иногда эта область, концентрирующая в себе основную ценность, составляет не более 10% кода. А остальное… ну, что это может быть? Иногда — необходимое инфраструктурное обеспечение, а в другой раз — явно «прибамбасы», маскирующиеся под необходимую инфраструктуру. Анализ чувствительности и состоит в том, чтобы прорубиться через это маленькое заблуждение.
Инкрементный анализ выгод и затрат
Как только мы разбили систему на куски (скажем, функции в период спецификации или модули в период разработки), возможно и разумно распределить предполагаемые затраты по карте этого разбиения. Так, доля системы, стоящая порядка $235000, могла бы иметь график затрат такого вида:
<……>заказчиком, показала бы ложность предположения об однородности распределения выгод по системе в целом.
