Процессы в «безнадежных» проектах

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

Почти во всех «безнадежных» проектах приходится устанав­ливать приоритеты, разделяя все требования к системе на различные категории (см. подразд. 1.5). При этом все акционеры и заин­тересованные лица должны принять согласованное решение от­носительно того, какие требования следует отнести к категориям «необходимо», «желательно», «хотелось бы» и «хотелось бы, но не в этот раз». Разумеется, если владелец проекта категорически настаивает на том, чтобы все требования были обязательно вы­полнены, дальнейшее обсуждение будет пустой тратой времени. Если акционеры и заинтересованные лица не могут достичь консенсуса по поводу отнесения требований к той или иной ка­тегории, то проектная команда, пытаясь удовлетворить всех, в ре­зультате окажется парализованной из-за отсутствия необходимых ресурсов.

К сожалению, в большинстве организаций нет дисциплины, опыта и политической силы, чтобы определить приоритет требо­ваний в самом начале проекта. Политические баталии вокруг «безнадежного» проекта могут сделать почти невозможным дос­тижение консенсуса по приемлемым для всех приоритетам. Толь­ко когда станет понятно, что проект «безнадежен», противобор­ствующие стороны придут к соглашению, которое им надо было бы достичь в самом начале проекта;

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

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

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

Формальные подходы (типа SEI-CMM, ISO-9000 или внедре­ние новых технологий анализа и проектирования) должны иметь место где-нибудь за пределами «безнадежного» проекта. Внедре­ние таких процессов имеет смысл как часть долговременной кор­поративной стратегии. Оно должно начинаться с выполнения пилотного проекта (но не «безнадежного»), сопровождаясь орга­низацией необходимого обучения. Если все это уже сделано, и другие разработки ПО в организации уже выполняются на треть­ем уровне SEI-CMM, то официально принятые в организации процессы следует усовершенствовать, чтобы сделать их пригод­ными для использования в «безнадежном» проекте.

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

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

Эти требования не являются необходимыми, практичными или желательными в большинстве «безнадежных» проектов. Дос­тичь такого совершенства невозможно даже в нормальных проектах, хотя в них нет таких жестких ограничений на время, бюджет и людские ресурсы. Что же касается «безнадежных» проектов, то пользователям в действительности нужна система, которая дос­таточно дешева, достаточно производительна, обладает необхо­димыми возможностями, достаточно устойчива и будет готова достаточно скоро — вот в чем заключается их определение «дос­таточно хорошего» ПО.

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

7.7.