В главе 11 «График работ» Роско продолжает излагать свою теорию планирования программных проектов, прибегая к некоторым методам научного прогнозирования.

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

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

Компромиссы.

Самая большая трудность для каждого менеджера заключается в том, чтобы объяснить членам своей команды, что они должны успеть сделать всю необходимую работу к тому совершенно немыслимому сроку, который для них поставлен. Те самые разработчики, которые демонстрировали полный оптимизм («никаких проблем!») на подготовительных стадиях проекта, вдруг становятся мрачными и даже недовольными, когда руководство говорит им: «Ну, вперед!». Беда, конечно, в том, что руководство всегда хочет слишком многого. Хочет, чтобы все было сделано еще вчера.

Но это совершенно необходимо. Руководство знает, что если не ставить жестких сроков, то проект затянется еще сильнее. Беда в том, что большинству менеджеров программных разработок свойственна такая позиция: «Да, сроки напряженные, но команда хорошая, и, если повезет, мы справимся. Если мы примерно уложимся в сроки, все будет OK». Напротив, разработчики думают по-другому. Они знают, что впереди их ждут многие неприятности: кто-то уйдет из команды, подрядчики, поставляющие важные компоненты, в одну прекрасную ночь сложат шатры и исчезнут в неизвестном направлении и т. д. Нарождающаяся система окажется слишком медленной в сравнении с прототипом. Проект просто захлебнется.

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

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

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

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

Пирамида проекта.

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

при одновременной минимизации ресурсов и времени налагает чрезмерные ограничения и неизбежно приводит к провалу проекта. Макс Уайдман (Max Wideman) обсуждает этот «железный треугольник» на своем веб-сайте

, посвященном управлению проектами.

Макс делает важное замечание, что в парадигму должно быть добавлено решающее четвертое измерение - качество. В своем письме ко мне он отметил:.

Примечательно, что качество в конечном счете важнее всего остального, будь то интенсивность, продуктивность или окончательный продукт. Однако масса людей, занятых управлением проектами, этого, похоже, не понимают. Кому сегодня интересно, что прошлогодний проект не был выполнен в срок и превысил бюджет? Все это осталось в прошлогодних бухгалтерских документах. Зато качество [продукта] осталось.

Трудно не согласиться с такой точкой зрения. Большинство разработчиков ПО вспомнят, как им, старавшимся во что бы то ни стало выполнить свои обязательства и сдать продукт вовремя, случалось выпускать ПО такого качества, что потом они испытывали сильные сожаления.

Макс, таким образом, превращает треугольник в звезду (рис. 9.1).

Деррик Дэвис (Derrick Davis) в переписке с Максом предложил для иллюстрации этих связей заменить звезду тетраэдром. В результате сохраняется первоначальный треугольник, но добавляется третье измерение, отражающее аспект качества. Замечательным свойством тетраэдра является его внутренняя симметрия: четыре атрибута соответствуют вершинам, и любые три из них могут быть положены в основание. Макс умно продеОХВАТ КАЧЕСТВО

Рис. 9.1. Макс Уайдман развивает железный треугольник «ресурсы, охват и время», добавляя в него четвертый элемент - «качество»

Рис. 9.2. Модель тетраэдра позволяет положить в основание любые три атрибута, а четвертый поместить в третье измерении.

монстрировал это, связав пары вершин ребрами со смысловыми описателями (рис. 9.2).

Пять, а не четыре.

Я согласен с Максом, что качество - это важный четвертый фактор, но все же считаю, что эта модель оставляет желать лучшего. Рассматривая проект перед началом работы над ним, руководство обычно интересуется его «видом», и этот интерес прекрасно соответствует четырем параметрам, показанным на рис. 9.1 и 9.2. Иными словами, мы можем определить, что мы собираемся сделать (охват), насколько тщательно (качество); мы можем предсказать, когда будет завершен проект (время), и оценить, сколько это будет стоить (ресурсы). Но заканчивается ли на этом описание проекта?.

Думаю,что нет. Руководству всегда интересен пятый параметр - степень риска. То есть, исходя из выявленных ранее четырех параметров и сопутствующего плана, руководство желает знать степень риска, связанного с проектом, - высокую, среднюю или низкую. Наш богатый опыт подсказывает, что различные проекты характеризуются разными степенями риска, и хорошие менеджеры стремятся иметь портфель проектов, сбалансированный в отношении уровней риска. У более рискованных проектов больше вероятность провалиться, но они могут принести и более значительную прибыль. Так же, как рассудительный человек разнообразит свой портфель ценных бумаг, умная компания диверсифицирует свой портфель, наполняя его проектами с разными сочетаниями риска/прибыли. Статистически такая компания должна быть финансово успешной.

Как же геометрически отразить этот новый (и, я надеюсь, последний) параметр?.

Появляется пирамида.

Я предлагаю модель, в которой первые четыре переменные соответствуют четырем ребрам в основании пирамиды. Мы припишем ребрам «расширенные свойства», чтобы длина этих сторон имела смысл. Обратите внимание на отличие от модели Дэвиса, в которой атрибуты соответствуют вершинам.

Допустим для простоты, что длины всех рёбер основания одинаковы, так что оно представляет собой квадрат. Похоже на звезду Макса, но атрибуты переместились от вершин к ребрам. Конечно, можно менять длину каждого ребра независимо, так что фактически основание является произвольным четырехугольником. Но в принципе ничего не изменится, если я пока предположу, что в основании лежит квадрат.

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

• Охват. Чем больше надо сделать, тем шире охват, поэтому длина этой стороны растет с расширением охвата.

• Качество. Более высокие стандарты качества требуют вложения большего труда, поэтому длина этой стороны растет вместе с ростом метрик качества - иными словами, когда мы «поднимаем планку» качества.

• Скорость. Это мера, отражающая время: длина этой стороны растет с увеличением скорости. И наоборот, чем медленнее вы двигаетесь (чем больше времени вам дано), тем короче становится эта сторона. Написать и отладить за месяц пять функций труднее, чем две. Эту сторону надо рассматривать как работу, выполняемую в единицу времени.

• Экономия (frugality). (Макс предложил это слово взамен предложенного мной сначала parsimony - скупость.) Если мы потребляем меньше ресурсов, то ведем себя более экономно. Чем сильнее экономия, тем длиннее эта сторона. Если мы расходуем больше ресурсов, сторона укорачивается.

Обратите внимание, что при таком определении охвата, качества, скорости и экономии проект оказывается тем проще, чем короче стороны четырехугольника. То есть проект проще, если делать меньше, снизить требования к качеству, работать медленнее (потратить больше времени) и позволить себе не экономить (располагать большими ресурсами). Таким образом, все четыре переменные «направлены в одну сторону».

Заметьте также, что с ростом площади основания растет прибыльность. Действительно, ценность продукта увеличится, если он станет крупнее и лучше и будет готов быстрее при большей экономии потраченных на его создание средств. Максимизация ценности при минимизации издержек оптимизирует прибыльность. Совершенно логично, что, пытаясь увеличить свою прибыль, мы также делаем проект более сложным и рискованным.

Переменная высота.

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

Теперь остается только связать все вместе (рис. 9.3).

Объем пирамиды представляет собой константу.

Теперь мы можем утверждать, что объем пирамиды представляет собой постоянную величину для данной команды. То есть законы природы определяют, что в пирамиду проекта помещается лишь такое количество «вещества», какое соответствует способностям команды. Это и понятно, поскольку объем пирамиды пропорционален произведению:.

{сложность} х {вероятность успеха}.

Когда увеличивается одно измерение, другое должно уменьшиться. Другими словами, здесь действует «закон сохранения»: произведение площади основания (она согласно определению четырех параметров представляет сложность проекта) на высоту (она представляет вероятность успеха) пропорционально «сохраняемому» объему.

Рис. 9.3. Пирамида проекта. У проекта с высокой степенью риска будет низкая вероятность успеха и маленькая высота. У проекта с низкой степенью риска будет высокая вероятность успеха и большая высота.

Чем определяется объем пирамиды? Двумя факторами. Во-первых, как я уже отметил, возможностями команды, работающей над проектом. Вовторых, количеством незнакомых проблем, с которыми сталкиваются ее члены. Способной команде соответствует больший объем:.

больше умения = больше «материала» = больше объем.

Чем больше новых задач и неизвестных, тем меньше объем: больше неизвестных = выше риск = меньше объем.

Итак, что же надо сделать (при данном постоянном объеме, соответствующем команде проекта и начальному множеству переменных), чтобы увеличить высоту, т. е. вероятность успеха? По правилам элементарной стереометрии, надо уменьшить основание. Для этого достаточно сократить длину одной или более сторон основания, и тогда проект станет проще.

Запомните: объем пропорционален произведению площади основания на высоту независимо от формы этого основания.

Статистическая интермедия.

Я сейчас попытаюсь определить правильный «масштаб» для высоты. Ребра, лежащие в основании, можно измерить в привычных единицах:.

• Охват: функциональные точки или основные функции.

• Качество: величина, обратная количеству дефектов.

• Скорость: функциональных точек или основных функций в месяц.

• Экономичность: величина, обратная потраченным долларам или человеко-месяцам.

А как быть с этой пресловутой вероятностью успеха - нашей высотой?.

Мы знаем, что «чем длиннее, тем лучше»: большая высота соответствует большей вероятности успеха. Однако есть некоторые неувязки с использованием вероятностей (выражаемых в процентах от величины) в качестве шкалы. Например, если имеется пирамида с высотой, соответствующей вероятности успеха 60%, то нельзя, сохраняя постоянным объем, улучшить этот процент, сократив площадь основания вдвое. Это дало бы для вероятности успеха абсурдную величину в 120%, ведь значение вероятности должно находиться в интервале между 0% и 100%.

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

Если вы позабыли, что такое функция распределения вероятности, напомню, что ось x представляет исходы, а ось у представляет относительное количество событий с таким исходом, которое при соответствующей нормализации (на общее число испытаний) становится вероятностью этого исхода. Если измерить площадь под кривой от левого ее края до данной точки, то она составит итоговую вероятность получения такого исхода. Проценты под осью x на рис. 9.4 показывают, какая площадь находится между концами охватывающих интервалов на оси х.

Обратите внимание, что распределение здесь «нормализовано» с центром в точке ц и «шириной» распределения, характеризуемой стандартным отклонением сигма (ст). Функция распределения уходит в плюс- и минус-бесконечность, но «хвосты» распределения за пределами плюс и минус (3хст) весьма незначительны: оба они составляют менее 0,3% всей площади под кривой. График показывает, что 68% проектов оказываются в той или иной мере успешными или неудачными, что всего 27,5% (95,5% минус 68%) окажутся очень успешными или очень неудачными и лишь 4,2% (99,7% минус 95,5%) окажутся экстремально успешными или неудачными. Чтобы получить отдельный процент в каждом случае, надо поделить эти величины надвое, поскольку существует симметрия относительно центра.

Рис. 9.4. Связь исходов проектов программных разработок со стандартным нормальным распределением.

Например, можно ожидать, что примерно 34%, т. е. примерно треть всех проектов окажутся в той или иной мере успешными.

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

Можно считать, что по оси x откладывается чистая денежная прибыль. Хотя я и не сомневаюсь, что у многих программных проектов прибыль нулевая или отрицательная, трудно представить себе, чтобы у какого-то проекта оказалась очень большая отрицательная прибыль.

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

Ачто если «сместить» нормальное распределение? В этом случае также есть масса оснований предполагать, что распределение перекошено и имеет очень длинный (если не бесконечный) положительный хвост и более короткий отрицательный. Например, чистая прибыль такого проекта, как MS-DOS, огромна. Трудно представить себе проект, который не зарубили бы задолго до того, как его чистая прибыль станет симметричным отрицательным числом! Предпочтительнее выбрать распределение с конечной границей отрицательных исходов.

Идея правильная,распределение - нет.

С этой целью мой дорогой друг и коллега Паскаль Леруа

предложил воспользоваться смещенным логнормальным распределением,

которое точнее отражает многие природные явления (рис. 9.5).

В отличие от стандартного нормального, логнормальное распределение асимметрично и у него нет левого хвоста, уходящего в бесконечность.

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

Это равносильно тому, чтобы сказать: мы готовы вложить в проект ц (или ст = 1), и любой меньший исход (полученное вознаграждение) будет означать убытки, а больший - прибыль.

Иными словами, мы «сместили» логнормальное распределение так, что ц (ст = 1) соответствует безубыточности, или нулевой чистой прибыли.

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

Смысл сигмы в этом распределении иной. При движении от средней точки, обозначенной здесь как 1 сигма, площадь нарастает несколько иначе. Каждый доверительный интервал соответствует расстоянию от ((1/2)

х сигма) слева до (2

х сигма ) справа. Это означает, что 68% площади лежит между 0,5 сигма и 2 сигма и 95,5% площади лежит между 0,25 сигма и 4 сигма. Вот таким образом проявляется мультипликативная природа логнормального распределения.

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

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

Приложение к реальным проектам.

Как приложить это распределение к реальным проектам? Поскольку пик кривой приходится примерно на 0,6 сигма, мы видим, что наиболее вероятным исходом (по меркам высоты кривой) оказывается провал проекта! Фактически, если бы пик приходился точно на 0,5, вероятность успеха составила бы лишь около 16%:.

50% - 1/2(68%) = 50% - 34% = 16%.

Поскольку пик находится не в 0,5, а ближе к 0,6 сигма или 0,7 сигма, вероятность успеха несколько выше - примерно 20%.

Это очень любопытно, поскольку в отчете Standish Group CHAOS,

к которому я всегда относился несколько скептически, указана частота успеха, примерно равная 20%.

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

Что надо, чтобы сыграть в «орлянку»?.

Какой же менеджер захочет начинать проект с плохими шансами на успех? Хотелось бы иметь шансы хотя бы 50/50. Или, в терминах нашей модели пирамиды, что надо сделать с основанием, чтобы увеличить высоту?.

Измеряя высоту нашей пирамиды в «сигмах», я начну с плана, который дает наиболее вероятный исход: в пике распределения при 0,66 сигма. Чтобы достичь вероятности успеха 50%, нужно набрать под кривой половину всей площади, что происходит в точке 1 сигма. Итак, мне надо дойти от 0,66 сигма до 1,0 сигма, что означает прирост в 50%. Таким образом, я должен увеличить высоту пирамиды в 1,5 раза, для чего площадь основания надо уменьшить в 1,5 раза, т. е. умножить ее на две трети.

Это в свою очередь означает, что длину сторон основания надо умножить на квадратный корень из двух третей, или примерно на 0,82. Поэтому, чтобы от наивного плана с 20% вероятности на успех перейти к плану с 50%, надо одновременно.

• Уменьшить охват примерно на 18%;.

• Снизить требования к качеству примерно на 18%;.

• Продлить сроки примерно на 18% (иначе говоря, уменьшить скорость на 18%);.

• Затратить примерно на 18% больше ресурсов (другими словами, снизить экономичность на 18%), чем было запланировано в первоначальном сценарии;.

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

Назовем этот новый план - тот, который приводит нас к результату 50/50, - «планом В». Первоначальный же, наиболее вероятный и наивный план, назовем «планом А».

Рост уверенности.

Нет ли вариантов получше? Допустим, я хочу добраться до точки 2 сигма. Это будет означать вероятность успеха, близкую к 84%:.

50% + S(68%) = 50% + 34% = 84%.

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

Во что нам это обойдется?.

Можно вести расчеты двумя способами: опираясь на план A или на план B с шансами 50/50. Для единообразия возьмем план A. Арифметика примерно та же. От 0,66 сигма теперь надо перейти к 2 сигма, увеличив высоту втрое. Это означает, что требуется умножить площадь основания на треть, что в свою очередь означает умножение каждой стороны основания на квадратный корень из 0,333. Теперь для получения нужного результата в прежнем списке параметров, которые должны быть одновременно изменены, надо на место 18% поставить 42%.

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

Вероятность успеха по плану A составляет лишь около 20%. Мы видели, что если уменьшить сложность каждого из четырех основных параметров (охват, качество, скорость и экономичность) на 20%, то получится план B, в случае чего вероятность успеха составляет 50%. Чтобы достичь вероятности успеха в 85%, надо уменьшить сложность по этим базовым параметрам примерно на 40% по сравнению с планом A. Эти соотношения подытожены в табл. 9.1.

Таблица 9.1. Результаты применения пирамидальной модели и логнормального распределения

Очевидно, что мы скользим здесь по очень тонкому льду, но цифры в табл. 9.1 дают предсказания модели, основанной на пирамиде, если считать, что имеет место логнормальное распределение исходов проектов, а объем не меняется.

Важные предостережения.

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

• Начнем с того, что подразумевается под словом «успех». Если помните, то я сказал, что определяю успех как исход, превышающий.

1 сигма в логнормальном распределении, из чего следует, что примерно половина наших проектов окажется успешной.

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

Отчет Standish всегда вызывал у меня сомнения, поскольку, по моему мнению, он содержит преувеличения, а потому упрощает реальную проблему. Если взять все первоначальные планы проектов и оценить их в момент завершения по нашим четырем базовым параметрам, то Standish, возможно, окажется права. И логнормальное распределение согласуется с таким сценарием. Но неужели у нас действительно на каждый успех приходится четыре провала?.

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

Я утверждаю, что многие проекты попадают в класс «достаточно успешных» или в класс «частично успешных». Как это бывает в жизни, мы по ходу дела пересматриваем свои ожидания (обычно в меньшую сторону), чтобы объявить о своей победе, когда они сбудутся. Это необходимо как с политической, так и с психологической точки зрения. Таким образом мы избегаем того, что психологи называют внутренним конфликтом. Никто не любит поражения, и всегда можно что-то спасти. Поэтому мы стремимся незаметно подправить историю и смошенничать с результатами. Цифры Standish справедливы только в том случае, если оценка основывается на исходном проекте. Но на практике никто так не поступает. В таком контексте правильной оценкой будет признание успешными примерно половины проектов.

• Такие параметры, как охват, качество, скорость и экономичность, не являются взаимно независимыми. Например, если проект затягивается по срокам, то его стоимость увеличивается из-за возросшего расхода ресурсов, поэтому скорость и экономичность страдают одновременно. Можно попытаться поправить одно с помощью другого, например, потратить деньги и нанять еще людей, чтобы двигаться быстрее. Но как очень верно заметил Брукс почти 30 лет назад,

добавление в программный проект новых работников

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

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

раметром, который они могут варьировать, являются ресурсы. Поэтому они часто пытаются решать проблему, изыскивая дополнительные денежные средства. Обычно это ничего не дает, поскольку они не дают себе труда подумать, как распределить эти средства, и тратят их неэффективно. Это полностью совпадает с точкой зрения Брукса. Он говорит, что в конечном итоге больше проектов проваливается из-за недостатка времени, чем по всем остальным причинам вместе взятым. Он был прав тогда, и я считаю, что он прав до сих пор.

• Обычно не удается компенсировать один из этих четырех параметров за счет другого - во всяком случае в больших размерах. Имеется в виду, что большой дефицит в одном из них нельзя восполнить путем значительного приращения одного или нескольких других. Проектам свойственно подчиняться закону естественного равновесия: если вы попробуете выстроить основание, в котором одна из сторон будет значительно отличаться по размеру от остальных, вас ждет неудача. По этой причине я сделал предположение, что основанием у нас является квадрат и все стороны (параметры) примерно одинаковы. Я допускаю, что можно увеличивать или уменьшать стороны, чтобы получить искомую площадь, но имейте в виду, что при этом необходимо соблюдать меру. Нельзя произвольно менять один параметр, чтобы обойти препятствия, связанные с другими. Макс Уайдман любит уподоблять основание «листу резины». Можно тянуть его за угол, изменяя длины сторон, но если переусердствовать, он порвется. Конечно, с точки зрения геометрии одна сторона не может быть длиннее суммы длин трех других, иначе четырехугольник «не замкнется».

• В известной мере я проигнорировал самый важный фактор любого проекта разработки ПО: талант участвующих в нем людей. Я неоднократно убеждался, что значение имеет не просто количество людей, работающих в команде, но их мастерство, опыт, пригодность и характер. Темы управления динамикой команды и подбора специалистов для конкретных задач проекта выходят за рамки данной главы. Однако объем пирамиды в некоторой степени соответствует одаренности команды.

• Не следует определять качество продукта только по количеству имеющихся в нем дефектов. Качество лучше определить более общим образом, таким как «пригодность к применению». Если продукт не содержит ошибок, но не может удовлетворительно решить важную задачу, то в целом он бесполезен и не может быть признан «высококачественным».

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

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

• Вопрос о том, описываются ли проекты логнормальным распределением вероятности, является спорным. Я согласен с Паскалем в том, что это распределение предпочтительнее стандартного нормального. И вот почему.

Нормальное распределение получается при сложении большого числа мелких событий, влияющих на окончательный результат. В разговорной речи мы можем сказать: «Что-то окажется лучше, чем мы предполагали, что-то хуже, но в итоге все усреднится». Здесь неявно участвует понятие симметрии, т. е. представление о том, что исход может с равной вероятностью оказаться больше или меньше своего среднего значения. Эти два допущения - сложение и симметрия - делают нормальное распределение симметричным относительно центрального значения и уводят хвосты в бесконечность в обоих направлениях, т. е. вероятность того, что все события будут иметь только одно или другое направление, мала. Если результат образуется суммированием «симметричных» исходов, то нормальное распределение оказывается очень надежной концепцией; в действительности так называемая центральная предельная теорема фактически гарантирует его получение, даже если сами суммируемые величины в отдельности не подчиняются нормальному распределению. Нормальное распределение, или «колоколообразная кривая», вошло в наше коллективное сознание. Оно является главной темой всех читаемых курсов теории вероятности и статистики, оно интуитивно и обладает рядом легко вычислимых характеристик. Но в жизни не всегда результат получается путем сложения образующих его величин. Поэтому следует с осторожностью применять стандартное нормальное распределение, если не изучены лежащие в основе явления причины. Несмотря на поразительно широкую область его применения, будет ошибкой предполагать, что «стандартное нормальное» действует всюду.

Логнормальное распределение имеет место, когда многочисленные мелкие величины, порождающие конечный результат, перемножаются. Обратите внимание, что между сложением множества маленьких величин и их перемножением есть существенная разница. Для получения большого результата при перемножении необходимо, чтобы некоторые сомножители были «большими», но для того, чтобы результат был близок к нулю, достаточно только одному из сомножителей быть близким к нулю. Поэтому распределение несимметрично и смещено в сторону малых величин. А ведь правда, многие составные события в жизни лучше моделируются логнормальным распределением: чтобы получился большой положительный результат, очень многое должно состояться правильно; чтобы получился ма-.

ленький результат (так сказать, негативный исход), достаточно лишь одной очень неправильной вещи. Даже один «нуль» обнулит результат, какими бы ни были все остальные множители. В случае управления проектами опыт подсказывает мне, что природа распределяет исходы скорее логарифмически нормально, чем просто нормально.

• Наконец, закон сохранения, выражаемый как постоянство объема пирамиды, представляет собой лишь модель. Она обеспечивает удобную визуализацию явления, но это всего лишь предположение, простейшая геометрическая модель, какую я смог придумать. Чтобы установить, отражает ли она реальность, необходимо изучить эмпирические данные.

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

Все дело в риске.

Риск, по-видимому, является важнейшим параметром, который надо учитывать при финансировании и планировании проекта. Вот почему простая модель, которую я описал в этой главе, связывает четыре традиционных параметра проекта - охват, качество, скорость, экономичность и добавляет риск в качестве пятой переменной. Если вы собираетесь спускаться по реке на каноэ, желательно знать, к какому классу относятся пороги - к третьему или к пятому. В последнем случае риск значительно возрастает, и, может быть, стоит потратить больше денег на лодку. То же происходит с инвестициями в разработку ПО: стоит оценить риск, прежде чем решать, какие ресурсы надо выделить для проекта. Но помните, что ресурсы представляют собой лишь одно ребро в квадратном основании; их следует рассматривать согласованно с обхватом, временем и качеством. Именно комбинация этих параметров наряду с качеством команды в конечном счете определяет уровень риска.

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

Резюме.

Нетрудно представить себе, что я подвергнусь острой критике за свои математические модели. Причин тому несколько.

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

Почему мне нравятся математические модели? Мой ответ прост. Все мы примерно понимаем или инстинктивно чувствуем, как устроен реальный мир. А вот что мы не понимаем, так это размеры и тяжесть последствий своих действий. Если менеджер проекта, оказавшегося в трудном положении, руководствуется здоровыми инстинктами и, например, решает уменьшить охват, а не брать новых людей, то это движение в верном направлении. Но было бы еще лучше, если бы он знал, насколько надо уменьшить охват, чтобы исправить положение. Если таких данных нет, то менеджер скорее пойдет лишь на незначительное уменьшение охвата. Так он навлекает на себя гнев руководства, во-первых, за то, что проект выполнен лишь частично, и, во-вторых, за то, что он все равно опоздал, т. к. выкинул мало. Из двух зол выбраны оба.

Предлагаемые мной модели просты по замыслу. Обычно они требуют знания математики в пределах понятия площади и объема и закона сохранения (если что-то где-то прибудет, то в другом месте это что-то должно убыть). В данной главе я обратился к некоторым понятиям статистики, но постарался тут же их объяснить. Логнормальное распределение - вещь неочевидная, но это не умаляет его пригодности. Это правильно выбранное распределение.

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

Модель, построенная на компромиссах, учит нас, что повысить вероятность успеха не так-то просто. Необходимо существенно изменить параметры, чтобы добиться заметного результата. В свою очередь это означает, что наши усилия по выработке оценок и графиков работы должна быть более эффективной. Я рассмотрю эти темы более подробно в главах 10-11. Как можно догадаться, у Роско Леруа найдется что сказать по этим вопросам. Будет интересно сравнить некоторые его математические модели с моими.