«[должно быть] равенство ответственности у разработчиков и заказчиков. Заказчики отвечают за то, чтобы убедиться в том, что ожидаемая выгода получена. [Но] постоянно в своих обзорах мы обнаруживаем, что компании не отслеживают по факту, была ли получена ожидаемая выгода».
«Показатели экономии также классифицируют по тому, являются ли они сокращением или избежанием расходов. Это различие важно. Сокращение – это вычеты из текущего уже принятого бюджета. Вы (менеджер, делающий заявку на финансирование) уже получили эти деньги: вы соглашаетесь отказаться от них, если получите деньги на новую систему. Избежание расходов выглядит так: «Если у меня не будет этой системы, мне придется дополнительно нанять <столько-то> <таких-то работников> в <будущем году>. Но если у меня будет эта система, я обойдусь без этих расходов». Это – любимый тип выгоды для тех, кто делает заявку на новую систему: одни обещания, никаких реальных жертв. Ловушка в том, что нет оснований верить, что вы бы получили средства для найма этих дополнительных работников. Вы меняете средства на будущие операционные расходы, которых вы могли бы и не получить вовсе, на основные фонды сегодня. Очень соблазнительно, но большинство из тех, кто распределяет бюджет, и рассматривает финансовые заявки, чуют это за версту. Корректной проверкой выгоды, связанной с избежанием затрат, является вопрос о неизбежности предполагаемых затрат. Другими словами, была бы непременно удовлетворена будущая бюджетная заявка. Это суровая проверка, но реальная выгода, связанная с избежанием затрат, может пройти ее и пройдет».
Картинка, возникшая из этих неформальных мнений, сама похожа на сэндвич, упомянутый в одной из цитат, но все же можно проследить пару занятных тенденций:
1. Организации, применяющие передовые практики, нацелены на проведение оценки выгоды, хотя могут менять ее форму от проекта к проекту.
2. Многие из них следуют схеме сокращения финансовых потоков, идущих сверху вниз, исходя из размера ожидаемой выгоды, что имела в виду Кристина, говоря, что «будущие схемы финансирования расходов могут быть сокращены из-за невыполнимых обещаний».
Наконец, даже эти организации в некоторых случаях удовлетворяются гарантиями стоимости типа «Поверьте мне, это сделать выгодно», но чаще всего это проходит, когда ответственность за затраты и за выгоду оказывается в руках одного заказчика.
Глава 20
Анализ чувствительности
Щепетильный предмет, которому посвящена данная глава, – увеличившаяся ответственность заказчика. Мы уже высказывались в пользу необходимости переложить ответственность за предсказание выгоды и измерение реально полученной выгоды на пользователей системы и заказчиков (причем с той же степенью точности, что и оценка затрат и фактические затраты). Теперь мы хотели бы привлечь внимание к некоторому использованию инкрементного метода в этом расчете выгоды. Щепетильность вопроса состоит в том, что вы не можете просто обязать своих клиентов к такой ответственности. Вы должны это выманивать лестью, уговаривать и просить об одолжении. Хотите ли вы действительно тратить, какой бы то ни было, политический капитал, который у вас может иметься, на эти кажущиеся невразумительными цели? В этой главе мы постараемся убедить вас, что вы этого хотите.
Проблема, на которую мы здесь нацелились, состоит в том, что большинство проектов разработки программного обеспечения по своей природе комплексные. Проект получает финансирование на основе какой-то ценности – либо имеющей явное количественное выражение, либо нет – которую должен принести полученный в результате продукт. Теперь стоит задать несколько вопросов: «В чем ценность этого продукта? Равномерно ли она распределена между всеми компонентами системы? Одинакова ли ценность этого модуля объемом в сто строк и того модуля (тоже из 100 строк), который восстанавливает конфигурацию после потери питания?»
Не стоит ручаться за то, что их ценность равна. Наш опыт (да и ваш, признайтесь) подсказывает, что ценность очень неравномерно распределена по системе. Основных денег система стоит из-за определенных ключевых функций, осуществляемых «в самом сердце» продукта или около него.
Иногда эта область, концентрирующая в себе основную ценность, составляет не более 10% кода. А остальное… ну, что это может быть? Иногда – необходимое инфраструктурное обеспечение, а в другой раз – явно «прибамбасы», маскирующиеся под необходимую инфраструктуру. Анализ чувствительности и состоит в том, чтобы прорубиться через это маленькое заблуждение.
Как только мы разбили систему на куски (скажем, функции в период спецификации или модули в период разработки), возможно и разумно распределить предполагаемые затраты по карте этого разбиения. Так, доля системы, стоящая порядка $235000, могла бы иметь график затрат такого вида:
<……>заказчиком, показала бы ложность предположения об однородности распределения выгод по системе в целом.
У одних компонентов отношение «выгоды/затраты» будет иметь высокий показатель, и это будут кандидаты на более раннюю готовность. Советуем вам составлять план версий, выбирая для более ранних версий компоненты, у которых показатели этого отношения выше. При поставке версии n все или большинство участников могут обнаружить, что среднее значение отношения «выгоды/затраты» еще не готовых частей незначительно. Это вполне может вызвать массовый энтузиазм по поводу соглашения о завершении проекта, признав его исключительно успешным, что позволит перейти к другим делам. И все это без необходимости занимать непопулярную позицию по поводу того, что любимая функция такого-то была чистой подачкой его самолюбию и ни черта не давала для общей выгоды.
То, что выгода неоднородна внутри системы, дает полезный тактический инструмент IT-менеджеру. Системные проекты отличаются проявлением отрицательных последствий, обусловленных изменением масштаба: при удвоении размера системы следует ожидать, что усилия для ее создания возрастут больше, чем вдвое. Эта нелинейность усилий по отношению к размеру системы хорошо документирована Боэмом[31] и другими:
Если при увеличении размера продукта обнаруживается и соответствующее возрастание усилий по его разработке, то уменьшение размера продукта дает возможность соответствующей их экономии. Отказ от частей системы в которых отношение «выгоды/затраты» мало, возможно, представляет собой легчайший и наилучший способ ослабить ограничения по времени и бюджету. Странно, что разработчики программного обеспечения должны поверить, что «создавать меньше программного обеспечения» должно стать частью их молитвы, но преимущества этого очевидны.
Ладно, посмотрим фактам в лицо: заставить заказчиков предсказывать выгоды – все равно, что удалять зубы. Это большой объем работы, открывающий дверь дополнительному уровню ответственности, причем усилия тех, кто подставляет себя под удар и занимается количественной оценкой, явно не окупятся. Если среди полезных функций затесались «прибамбасы», то люди, которые должны сделать количественную оценку, вполне могут оказаться теми, кто потеряет свои любимые игрушки. Можно ожидать практически от любого заказчика яростных возражений и уверений самым серьезным тоном, что «все это необходимо для поддержки основной функциональности, честное слово». Это та же самая старая и надоевшая песня про равномерно распределенную стоимость, но не рассчитывайте их в этом убедить.
31
Barry W. Boehm. Software Engineering Economics (Englewood Cliffs, N.J Prentice-Hall. 1981), p. 76. Reprinted by permission of Pearson Education Inc., Upper Saddle River. N.J.