Выдвижение разумной оценки общих потерь времени на замену может быть трудной задачей, но любая хорошо продуманная цифра, выбранная вами, намного лучше, чем 0, до сих пор принимавшийся по умолчанию в гипотезах по управлению проектами.
Главный риск № 4: Нарушение спецификаций
Четвертый главный риск – нарушение спецификаций – несколько иного рода, чем остальные. Он скорее дискретный, чем непрерывный, бинарный по своему воздействию (другими словами, он либо реализуется, либо не реализуется, но не оказывает какого-то неполного воздействия в той или иной степени), если же он реализуется, то это почти всегда фатально. Он не замедляет ваш проект, а губит его.
Нарушение спецификаций относится к краху процесса переговоров по установлению требований, которые идут в начале любого проекта. Вы могли бы подумать, что это сравнительно легко отследить, а потому очень легко этому противодействовать: если стороны не могут согласиться по поводу того, какой продукт нужно создать, то можно закрыть проект на ранней стадии, собрать свои вещички и отправиться восвояси без особых потерь.
К несчастью, так редко бывает. Люди обязаны прийти к соглашению. Они обязаны сотрудничать. Когда существует глубокий конфликт, не позволяющий им это сделать, то часто результат маскируют. Проект продолжают с неправильными, двусмысленными целями, которые не радуют никого, но с которыми обе стороны готовы мириться, по крайней мере, до поры.
Пусть, например, конфликт возник по поводу того, кто из участников проекта должен управлять определенной ключевой порцией данных. Спецификации искусственно избегают определения того, где будут находиться данные, какие разрешения требуются для их изменения, какие сотрудники отслеживают эти данные, частью какого архива они должны стать, когда и как их могут замещать и т.д. Люди ворчат по поводу спецификаций, поскольку они не очень-то ясны. Но сохраняется то преимущество, что там не содержится ничего явно неприемлемого для какой-то из сторон. Проект переходит (или кажется переходящим) на стадию внутреннего конструирования и внедрения.
Замаскированная проблема уходит на время, но не навсегда. Хотя возможно описать (специфицировать) продукт двусмысленно, но невозможно создать продукт неоднозначным. В итоге приходится столкнуться с отложенными проблемами, и конфликт разгорается вновь. В худшем случае это происходит на очень поздней стадии проекта, когда потрачены почти все (или совсем все) отведенные на проект ресурсы (деньги и время). Проект очень уязвим в этой стадии, и отказ любой из сторон поддерживать его может привести к быстрому прекращению. Проект успешно уничтожен, без необходимости кому-то признаваться в том, что реальной проблемой было недостаточное согласование.
