Вальсируя с медведями - ДеМарко Том - Страница 23

В вашей организации влияние этого риска может отличаться от того, которое мы показали. Конечно, вы захотите заменить наши данные собственными, если они у вас есть (см. в следующем разделе подсказки по такой замене). Если у вас нет данных, используйте для начала то, что мы предлагаем в симуляторе «RISKOLOGY». Это наверняка будет лучше, чем стандартный подход с ожиданием 0%-вых изменений.

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

Здесь показано воздействие текучести кадров на одно- и двухгодичные проекты, исходя из среднеотраслевых данных о текучести.

У вас, скорее всего, должны быть приличные собственные данные по этому риску, поэтому стоит заменить ими наши. Инструкции по замене есть на нашем сайте «RISKOLOGY». Чтобы произвести замену вам нужно иметь следующие данные:

• средний процент текучести технического персонала в вашей компании

• ваша собственная наилучшая оценка общих потерь времени при найме для каждой замены

Мы определяем общие потери времени как число месяцев, которое потребуется типичному новичку на достижение того же уровня производительности, который был у замененного им работника. Обычно это время составляет от 2 месяцев на самых простых позициях в IT-отделах до 24 месяцев для компании, производящей очень сложные приложения. Очевидно, что длина этого периода зависит от того, насколько сложна область и насколько она необычна (насколько отличается от опыта и навыков, наличие которых можно ожидать от типичного новичка).

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

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

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

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

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

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

Нарушение спецификаций проявляется и по-другому. Например, в том, что гуру менеджмента Питер Кин (Peter Keen) называет контр-осуществлением, когда недовольные участники проекта перегружают проект все большим и большим количеством функций. Функции A-F используют для оправдания проекта. Но потом те, кто кажется энтузиастами-сторонниками проекта, добавляют функции G-Z. С таким объемом добавленных функций нет надежды на выгоду, превосходящую затраты. Такого рода «заваливание» обычно происходит в конце работы по анализу и приводит к невозможности договоренности по спецификациям.

Около седьмой части всех проектов в нашей базе данных были прекращены без поставки какого бы то ни было продукта. У других исследователей есть другие оценки доли прекращенных проектов, но большинство попадают в диапазон 10-15%. Мы взяли среднее значение от этого процентного диапазона прекращения проектов и рассматриваем его как фиксированный риск нарушения спецификаций. Для простоты мы предположили, что нарушение спецификаций – единственная причина прекращения проекта. (Возможно, вы сумеете найти где-то проект, прекращенный по причинам, не имеющим ничего общего с конфликтом сторон, но все же постарайтесь убедиться, что заявленная причина не является просто маскировкой глубинного отсутствия согласия между сторонами).

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

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

<…>

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

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

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