В этой ситуации неопытная команда надеется, что, работая сверхурочно вдвое больше, она сможет как-нибудь покрыть этот дефицит; а циничная команда «самоубийственного» проекта предполагает, что их проект все равно затянется на 50-100 процентов по сравнению с первоначальным планом, как и любой другой проект. Но даже если циничная команда ошибается в этом, она все равно предполагает, что раньше или позже (обычно гораздо позже!) она в конце концов реализует все функции, которые требовались пользователю.
Один из ключевых моментов в безнадёжных проектах состоит в том, что некоторые требования не просто останутся невыполненными до официального срока завершения проекта, но и не будут выполнены никогда . Если предположить, что известное правило «80-20» справедливо, то проектная команда сможет добиться 80 процентов «эффекта» от разработанной системы, реализовав 20 процентов требований к ней — при условии правильного выбора этих 20 процентов. И, поскольку пользователю, как правило, не терпится получить работающую систему задолго до того срока, который проектная команда считает разумным, то он может взять эти готовые 20 процентов, приступить к их использованию и навсегда позабыть об оставшихся 80 процентах функций системы.
Это, конечно, чересчур упрощённый подход, но, тем не менее, почти во всех безнадёжных проектах, в которых я принимал участие, приходилось устанавливать приоритеты, разделяя все требования к системе на три категории: «необходимо выполнить», «следует выполнить» и «можно выполнить». Смысл этих категорий очевиден, и тот факт, что их всего три, предупреждает любые бесполезные дискуссии на тему о приоритетах, например, какой приоритет присвоить конкретному требованию — шестой или седьмой. При такой расстановке приоритетов в проекте очевидная стратегия будет заключаться в следующем: в первую очередь сосредоточиться на требованиях, которые необходимо выполнить; затем, если останется время, сосредоточиться на требованиях, которые следует выполнить; и наконец, если произойдёт чудо, заняться требованиями, которые можно выполнить.
Если не следовать такой стратегии с самого начала проекта , то к концу он окажется в крайне неприятной кризисной ситуации. Чтобы понять, почему это происходит, рассмотрим типичный график проекта, изображённый на рис. 5.1:


Начало проекта — Середина проекта — Кризис — Окончание
Рис. 5.1 График проекта

Когда проект начинается, никто и слушать не желает, что его сроки нереальны — в особенности все пользователи и высшее руководство. У менеджера проекта и участников команды может возникнуть неприятное ощущение, что им предстоит выполнять «самоубийственную» миссию, однако если они — оптимисты, то могут поверить, что проект будет иметь характер «невыполнимой миссии» и впоследствии какое-нибудь чудо придёт им на помощь. В этот момент самым важным является то, что конечный срок ещё достаточно далеко (через шесть месяцев или год), и никто не хочет всерьёз задумываться о невыполнимости поставленных задач.
В самом деле, политическое давление и неопытность проектной команды могут привести к тому, что даже в середине проекта он не будет подвергнут никакой переоценке. Как не смешно это звучит, но проблема может оказаться ещё более сложной, если проектная команда использует какую-либо разновидность RAD-подхода, поскольку они, вероятно, уже продемонстрировали пользователю один или более прототипов системы и тем самым поддержали у него иллюзию, что все будет сделано вовремя. Однако, к этому моменту проектная команда скорее всего начнёт понимать, что они пытаются прыгнуть выше головы, и если для менеджера этот безнадёжный проект — первый, он будет наивно верить, что высшее руководство и пользователи тоже в конце концов их поймут.
Увы, но обычно этого не происходит. В конце концов наступает кризис, когда пользователи и/или высшее руководство оказываются вынуждены посмотреть в лицо реальности: несмотря на их требования и искренние заверения менеджера проекта, система не будет готова в срок. Обычно это случается за месяц до окончания проекта, иногда за неделю, а иногда и через день после официального окончания! Последствия могут быть различными: это зависит от степени напряжённости политических баталий к этому моменту, а также от степени изнурённости и разочарованности менеджера проекта. Тем не менее, при этом, как правило, происходит следующее: высшее руководство приходит к выводу, что во всем виноват менеджер проекта, и в итоге несчастного увольняют (если только он сам уже не уволился!) и ставят нового с требованием «ликвидировать весь этот бардак и сдать систему вовремя».
Новый менеджер может быть как закалённым ветераном из самой организации, так и сторонним консультантом. Иногда случается так, что он в самом деле обнаруживает ряд грубых ошибок, сделанных его предшественником (например, отсутствие планирования вообще или отсутствие рабочих графиков) ; иногда новый менеджер приходит к выводу, что его предшественник в основном делал все правильно, но не смог избежать участи козла отпущения, когда высшее руководство наконец убедилось, что их первоначальные требования невыполнимы.
Однако, независимо от его оценки, почти не подлежит сомнению, что новый менеджер должен быть готов к следующему: все проектные требования в полном объёме не удастся реализовать в соответствии с первоначально установленным сроком — если бы это было не так, то предыдущего менеджера вряд ли бы уволили. Итак, что же следует предпринять новому менеджеру?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71