Том ДеМарко - Вальсируя с медведями

Картинка, возникшая из этих неформальных мнений, сама похожа на сэндвич, упомянутый в одной из цитат, но все же можно проследить пару занятных тенденций:

1. Организации, применяющие передовые практики, нацелены на проведение оценки выгоды, хотя могут менять ее форму от проекта к проекту.

2. Многие из них следуют схеме сокращения финансовых потоков, идущих сверху вниз, исходя из размера ожидаемой выгоды, что имела в виду Кристина, говоря, что «будущие схемы финансирования расходов могут быть сокращены из-за невыполнимых обещаний».

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

Щепетильный предмет, которому посвящена данная глава, — увеличившаяся ответственность заказчика. Мы уже высказывались в пользу необходимости переложить ответственность за предсказание выгоды и измерение реально полученной выгоды на пользователей системы и заказчиков (причем с той же степенью точности, что и оценка затрат и фактические затраты). Теперь мы хотели бы привлечь внимание к некоторому использованию инкрементного метода в этом расчете выгоды. Щепетильность вопроса состоит в том, что вы не можете просто обязать своих клиентов к такой ответственности. Вы должны это выманивать лестью, уговаривать и просить об одолжении. Хотите ли вы действительно тратить, какой бы то ни было, политический капитал, который у вас может иметься, на эти кажущиеся невразумительными цели? В этой главе мы постараемся убедить вас, что вы этого хотите.

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

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

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

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

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

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

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