Проблема, на которую мы здесь нацелились, состоит в том, что большинство проектов разработки программного обеспечения по своей природе комплексные. Проект получает финансирование на основе какой-то ценности – либо имеющей явное количественное выражение, либо нет – которую должен принести полученный в результате продукт. Теперь стоит задать несколько вопросов: «В чем ценность этого продукта? Равномерно ли она распределена между всеми компонентами системы? Одинакова ли ценность этого модуля объемом в сто строк и того модуля (тоже из 100 строк), который восстанавливает конфигурацию после потери питания?»

Не стоит ручаться за то, что их ценность равна. Наш опыт (да и ваш, признайтесь) подсказывает, что ценность очень неравномерно распределена по системе. Основных денег система стоит из-за определенных ключевых функций, осуществляемых «в самом сердце» продукта или около него.

Иногда эта область, концентрирующая в себе основную ценность, составляет не более 10% кода. А остальное… ну, что это может быть? Иногда – необходимое инфраструктурное обеспечение, а в другой раз – явно «прибамбасы», маскирующиеся под необходимую инфраструктуру. Анализ чувствительности и состоит в том, чтобы прорубиться через это маленькое заблуждение.

Как только мы разбили систему на куски (скажем, функции в период спецификации или модули в период разработки), возможно и разумно распределить предполагаемые затраты по карте этого разбиения. Так, доля системы, стоящая порядка $235000, могла бы иметь график затрат такого вида:

<……>заказчиком, показала бы ложность предположения об однородности распределения выгод по системе в целом.

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

То, что выгода неоднородна внутри системы, дает полезный тактический инструмент IT-менеджеру. Системные проекты отличаются проявлением отрицательных последствий, обусловленных изменением масштаба: при удвоении размера системы следует ожидать, что усилия для ее создания возрастут больше, чем вдвое. Эта нелинейность усилий по отношению к размеру системы хорошо документирована Боэмом[31] и другими:

Если при увеличении размера продукта обнаруживается и соответствующее возрастание усилий по его разработке, то уменьшение размера продукта дает возможность соответствующей их экономии. Отказ от частей системы в которых отношение «выгоды/затраты» мало, возможно, представляет собой легчайший и наилучший способ ослабить ограничения по времени и бюджету. Странно, что разработчики программного обеспечения должны поверить, что «создавать меньше программного обеспечения» должно стать частью их молитвы, но преимущества этого очевидны.

Ладно, посмотрим фактам в лицо: заставить заказчиков предсказывать выгоды – все равно, что удалять зубы. Это большой объем работы, открывающий дверь дополнительному уровню ответственности, причем усилия тех, кто подставляет себя под удар и занимается количественной оценкой, явно не окупятся. Если среди полезных функций затесались «прибамбасы», то люди, которые должны сделать количественную оценку, вполне могут оказаться теми, кто потеряет свои любимые игрушки. Можно ожидать практически от любого заказчика яростных возражений и уверений самым серьезным тоном, что «все это необходимо для поддержки основной функциональности, честное слово». Это та же самая старая и надоевшая песня про равномерно распределенную стоимость, но не рассчитывайте их в этом убедить.

Может быть, вам и не придется. Польза от частичных данных «выгоды/затраты» состоит в том, что они позволяют упорядочить компоненты для включения в версии. Получить точные оценки было бы отлично, но если их приобрести нельзя, то не устроит ли вас вместо этого упорядочение?

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

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

Если предыдущий абзац показался вам убедительным, вы относитесь к меньшинству. Кажется, что вся IT-отрасль поддерживает практически противоположный взгляд: Рискуйте много, когда выгода ничтожна. Как еще мы сумеем снизить затраты настолько, чтобы оправдать этот нестоящий проект?

Это мышление – порождение одного из самых распространенных, но постыдных стилей работы в нашей отрасли…

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

Оправдание этих жертв всегда апеллирует к важности проекта: это так важно и необходимо, что требует предела возможного от персонала проекта. Но есть нечто загадочное в этом утверждении. Если этот проект так важен, почему компания не может потратить время и деньги необходимые для его нормального осуществления?

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

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