Логичнее поступить как-то так: «Вы говорите, что хотите X, наш опыт подсказывает, что в процессе работы возникнут изменения в требованиях и вы в итоге захотите что-то слегка иное, поэтому мы будем планировать создание X с некоторой готовностью к ожидаемым изменениям».
Но какой именно готовностью? В середине 1990-х министерством обороны США было предложено количественное определение того, как должны вести себя хорошо управляемые проекты. Они количественно измерили размер разумно ожидаемых изменений примерно на уровне менее 1% в месяц. Итак, проект, по созданию продукта размером в 20000 функциональных точек[23] за два года, должен быть рассчитан на создание примерно 25000 функциональных точек программного обеспечения (20000 фт х (1.00 + 24 месяца х 1 % в месяц)). Реальный размер будет где-то посередине, поскольку часть изменений потребует отмены уже выполненных и оплаченных работ.
Опыт Минобороны США, может быть, трудно применить к вашему проекту. Поскольку типичные программные продукты для Минобороны велики, проекты часто выполняются с привлечением субподрядчиков (иногда нескольких уровней) и их продолжительность дольше, чем у большинства коммерческих проектов, более того, приближение, предложенное Минобороны США выражено, скорее, «терминах самого объема, чем в его влиянии на продолжительность по времени.
Из наших собственных наблюдений, где много одно- и двухгодичных проектов, осуществленных силами команд, состоящих из десятка, не более, исполнителей, сделан следующий вывод относительно ожидаемого воздействия изменяющихся требований на продолжительность во времени.
В вашей организации влияние этого риска может отличаться от того, которое мы показали. Конечно, вы захотите заменить наши данные собственными, если они у вас есть (см. в следующем разделе подсказки по такой замене). Если у вас нет данных, используйте для начала то, что мы предлагаем в симуляторе «RISKOLOGY». Это наверняка будет лучше, чем стандартный подход с ожиданием 0%-вых изменений.
Люди иногда уходят во время проекта. Возможность этого обычно не рассматривается в процессе оценки. Чтобы принять во внимание этот фактор, вам нужно предусмотреть некий буфер для сдерживания риска. Какой именно? Вот что мы получили из нашей базы данных проектов:
Здесь показано воздействие текучести кадров на одно- и двухгодичные проекты, исходя из среднеотраслевых данных о текучести.
У вас, скорее всего, должны быть приличные собственные данные по этому риску, поэтому стоит заменить ими наши. Инструкции по замене есть на нашем сайте «RISKOLOGY». Чтобы произвести замену вам нужно иметь следующие данные:
• средний процент текучести технического персонала в вашей компании
• ваша собственная наилучшая оценка общих потерь времени при найме для каждой замены
Мы определяем общие потери времени как число месяцев, которое потребуется типичному новичку на достижение того же уровня производительности, который был у замененного им работника. Обычно это время составляет от 2 месяцев на самых простых позициях в IT-отделах до 24 месяцев для компании, производящей очень сложные приложения. Очевидно, что длина этого периода зависит от того, насколько сложна область и насколько она необычна (насколько отличается от опыта и навыков, наличие которых можно ожидать от типичного новичка).
Выдвижение разумной оценки общих потерь времени на замену может быть трудной задачей, но любая хорошо продуманная цифра, выбранная вами, намного лучше, чем 0, до сих пор принимавшийся по умолчанию в гипотезах по управлению проектами.
Четвертый главный риск – нарушение спецификаций – несколько иного рода, чем остальные. Он скорее дискретный, чем непрерывный, бинарный по своему воздействию (другими словами, он либо реализуется, либо не реализуется, но не оказывает какого-то неполного воздействия в той или иной степени), если же он реализуется, то это почти всегда фатально. Он не замедляет ваш проект, а губит его.
Нарушение спецификаций относится к краху процесса переговоров по установлению требований, которые идут в начале любого проекта. Вы могли бы подумать, что это сравнительно легко отследить, а потому очень легко этому противодействовать: если стороны не могут согласиться по поводу того, какой продукт нужно создать, то можно закрыть проект на ранней стадии, собрать свои вещички и отправиться восвояси без особых потерь.
К несчастью, так редко бывает. Люди обязаны прийти к соглашению. Они обязаны сотрудничать. Когда существует глубокий конфликт, не позволяющий им это сделать, то часто результат маскируют. Проект продолжают с неправильными, двусмысленными целями, которые не радуют никого, но с которыми обе стороны готовы мириться, по крайней мере, до поры.
Пусть, например, конфликт возник по поводу того, кто из участников проекта должен управлять определенной ключевой порцией данных. Спецификации искусственно избегают определения того, где будут находиться данные, какие разрешения требуются для их изменения, какие сотрудники отслеживают эти данные, частью какого архива они должны стать, когда и как их могут замещать и т.д. Люди ворчат по поводу спецификаций, поскольку они не очень-то ясны. Но сохраняется то преимущество, что там не содержится ничего явно неприемлемого для какой-то из сторон. Проект переходит (или кажется переходящим) на стадию внутреннего конструирования и внедрения.
Замаскированная проблема уходит на время, но не навсегда. Хотя возможно описать (специфицировать) продукт двусмысленно, но невозможно создать продукт неоднозначным. В итоге приходится столкнуться с отложенными проблемами, и конфликт разгорается вновь. В худшем случае это происходит на очень поздней стадии проекта, когда потрачены почти все (или совсем все) отведенные на проект ресурсы (деньги и время). Проект очень уязвим в этой стадии, и отказ любой из сторон поддерживать его может привести к быстрому прекращению. Проект успешно уничтожен, без необходимости кому-то признаваться в том, что реальной проблемой было недостаточное согласование.
Нарушение спецификаций проявляется и по-другому. Например, в том, что гуру менеджмента Питер Кин (Peter Keen) называет контр-осуществлением, когда недовольные участники проекта перегружают проект все большим и большим количеством функций. Функции A-F используют для оправдания проекта. Но потом те, кто кажется энтузиастами-сторонниками проекта, добавляют функции G-Z. С таким объемом добавленных функций нет надежды на выгоду, превосходящую затраты. Такого рода «заваливание» обычно происходит в конце работы по анализу и приводит к невозможности договоренности по спецификациям.
Около седьмой части всех проектов в нашей базе данных были прекращены без поставки какого бы то ни было продукта. У других исследователей есть другие оценки доли прекращенных проектов, но большинство попадают в диапазон 10-15%. Мы взяли среднее значение от этого процентного диапазона прекращения проектов и рассматриваем его как фиксированный риск нарушения спецификаций. Для простоты мы предположили, что нарушение спецификаций – единственная причина прекращения проекта. (Возможно, вы сумеете найти где-то проект, прекращенный по причинам, не имеющим ничего общего с конфликтом сторон, но все же постарайтесь убедиться, что заявленная причина не является просто маскировкой глубинного отсутствия согласия между сторонами).
Проявление этого главного риска также уникально в своем роде. Мы предлагаем приписывать этот риск каждому новому проекту, пока не происходит четкого прекращения прений по поводу спецификаций. После чего риск можно убрать.
23
Авторы имеют в виду балльную функциональную оценку (function point analysis) – общепринятый метод оценки сложности и трудоемкости крупных программных разработок