• Главная
• Контакты
• Нашёл ошибку
• Прислать материал
• Добавить в избранное

Если вы запомните хотя бы одно слово из данной главы (или вообще из всей книги), то эти словом должна быть приоритетность (triage) . Исходя из названия главы, вы можете подумать, что речь в основном пойдёт о таких знакомых методологиях, как структурный анализ, или формальных дисциплинах наподобие SEI Capability Maturity Model (CMM), или различных подходах к разработке ПО под общим названием RAD (Rapid Application Development). Все это важные и нужные вещи, но самое главное заключается в том, что в безнадёжном проекте вам не хватит времени на то, чтобы удовлетворить все потребности пользователя. Если вы будете строить все свои процессы и методы, исходя из этого непреложного факта, то у вас появятся шансы на успех; если же вы начнёте проект, будучи уверенными, что к кодированию нельзя приступать до тех пор, пока все диаграммы потоков данных, полученные в результате структурного анализа, не будут утверждены пользователем, то вы определённо потерпите неудачу.

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

Слово «triage» происходит от старого французского «trier», что означает «сортировать, классифицировать». AmericanHeritageDictionary (3-е издание) определяет его следующим образом:

triage – существительное

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

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

Большинство из нас знакомы с медицинской трактовкой этого термина, однако для безнадёжных проектов более подходящим является второе определение: распределение дефицитных ресурсов (самым дефицитным из которых обычно является время ) таким образом, чтобы извлечь из этого наибольшую выгоду. Или, как отметил Stephen Covey в [1], «главное – это быть уверенным в том, что главное – это главное». (В самом деле, можно будет достичь гораздо лучших результатов в проекте, если каждый участник команды вместо увесистого тома методологии разработки ПО получит экземпляр замечательной книги Covey!)

Большинство подходов, связанных с прототипированием и RAD, вполне сочетаются с данной концепцией, а некоторые даже явно на неё ссылаются. Однако, большинство подходов RAD делают акцент только на быстром получении некоторого – какого угодно! – результата (работающего приложения), который можно показать пользователю с целью (а) продемонстрировать, насколько ощутим достигнутый прогресс, и (б) получить замечания, касающиеся функциональности системы и (преимущественно) пользовательского интерфейса. Все это весьма полезно, однако если проектная команда будет расходовать свои ресурсы на проектирование начальных прототипов с внешне привлекательными, но несущественными возможностями, то как команда, так и пользователь будут зря терять время.

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

Разумеется, это честный девиз, но в безнадёжных проектах он почти всегда невыполним. Как я уже отмечал в главе 1, в большинстве безнадёжных проектов «официально утверждённые» требования превышают ресурсы проектной команды – в особенности, человеческие и временные ресурсы – на 50-100 процентов. В этой ситуации неопытная команда надеется, что, работая сверхурочно вдвое больше, она сможет как-нибудь покрыть этот дефицит; а циничная команда «самоубийственного» проекта предполагает, что их проект все равно затянется на 50-100 процентов по сравнению с первоначальным планом, как и любой другой проект. Но даже если циничная команда ошибается в этом, она все равно предполагает, что раньше или позже (обычно гораздо позже!) она в конце концов реализует все функции, которые требовались пользователю.

Один из ключевых моментов в безнадёжных проектах состоит в том, что некоторые требования не просто останутся невыполненными до официального срока завершения проекта, но и не будут выполнены никогда. Если предположить, что известное правило «80-20» справедливо, то проектная команда сможет добиться 80 процентов «эффекта» от разработанной системы, реализовав 20 процентов требований к ней – при условии правильного выбора этих 20 процентов. И, поскольку пользователю, как правило, не терпится получить работающую систему задолго до того срока, который проектная команда считает разумным, то он может взять эти готовые 20 процентов, приступить к их использованию и навсегда позабыть об оставшихся 80 процентах функций системы.

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

Если не следовать такой стратегии с самого начала проекта, то к концу он окажется в крайне неприятной кризисной ситуации. Чтобы понять, почему это происходит, рассмотрим типичный график проекта, изображённый на рис. 5.1:

Начало проекта – Середина проекта – Кризис – Окончание

Рис. 5.1 График проекта

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

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

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

Новый менеджер может быть как закалённым ветераном из самой организации, так и сторонним консультантом. Иногда случается так, что он в самом деле обнаруживает ряд грубых ошибок, сделанных его предшественником (например, отсутствие планирования вообще или отсутствие рабочих графиков) ; иногда новый менеджер приходит к выводу, что его предшественник в основном делал все правильно, но не смог избежать участи козла отпущения, когда высшее руководство наконец убедилось, что их первоначальные требования невыполнимы.

Однако, независимо от его оценки, почти не подлежит сомнению, что новый менеджер должен быть готов к следующему: все проектные требования в полном объёме не удастся реализовать в соответствии с первоначально установленным сроком – если бы это было не так, то предыдущего менеджера вряд ли бы уволили. Итак, что же следует предпринять новому менеджеру? Две наиболее очевидные возможности заключаются в следующем:

1) пересмотреть срок окончания проекта;

2) пересмотреть требования к системе.

(Консультант John Boddie предлагает ещё одну возможность: менеджер проекта может стать одним из тех, кто добьётся официального прекращения проекта, если его действительно невозможно спасти. Новому менеджеру сделать такое гораздо проще, чем его предшественнику, поскольку тот вложил в проект столько личных усилий и эмоций, что ему трудно представить себе, как вообще можно прекратить проект. Boddie даёт несколько хороших советов относительно политически приемлемых способов прекращения проекта в своей статье «Calling Doctor Kevorkian», опубликованной в журнале American Programmer, February 1997.)

Первая возможность в принципе вполне допустима, однако в безнадёжном проекте практически нереальна. В самом деле, ведь основной причиной, побудившей пользователей настаивать на таких нереальных планах, является неотложная потребность в системе, которая позволила бы им справиться со своими проблемами в бизнесе. Поскольку новый менеджер приходит в проект в тот момент, когда уже близок первоначально установленный срок завершения, высока вероятность того, что пользователи уже строят планы эксплуатации новой системы. Последнее, что им хотелось бы слышать – это то, что проект продлится ещё 6-12 месяцев.

Поэтому наиболее часто – и успешно – применяемый приём заключается в определении приоритетов для первоначальных требований. Отметим, что при этом новый менеджер разговаривает с позиции силы – это не его вина, что проект оказался в таком плачевном состоянии; при этом не высказывается вслух, но подразумевается, что руководство и пользователи в первую очередь были настолько глупы, что позволили загнать себя в такой тупик. Новый менеджер может даже поставить своё согласие на участие в проекте в зависимость от успешного окончания переговоров – например, заявив: «Если вы хотите, чтобы я вытащил вас из этой ямы, то должны принять как факт, что мы сможем реализовать в срок только небольшой процент первоначально заданных функций. Таково реальное положение вещей, согласны вы с ним или нет».

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

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

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

Заметьте, что мы в данном обсуждении ещё ни разу не коснулись таких тем, как структурный анализ, SEI-CMM или любые другие «книжные» методологии и процессы создания ПО. Все, что говорилось по поводу приоритетности, продиктовано исключительно здравым смыслом, что для безнадёжных проектов является критически важным. Чтобы эта концепция работала, все акционеры и заинтересованные лица должны принять согласованное решение, какие требования следует отнести к категории «необходимо выполнить», какие к «следует выполнить» и какие к «можно выполнить». Разумеется, если владелец проекта категорически настаивает на том, чтобы все требования были обязательно выполнены, все дальнейшее обсуждение будет пустой тратой времени. (На самом деле, я бы порекомендовал менеджеру проекта и его команде использовать такое обсуждение в самом начале проекта как лакмусовую бумажку. Если пользователи, владелец проекта, высшее руководство, акционеры и заинтересованные лица не желают принимать такой подход к расстановке приоритетов требований, то наиболее разумным ответным шагом будет выйти из проекта, пока не поздно. В качестве дополнительной лакмусовой бумажки следует предложить пользователям разделить все требования на три равные группы в соответствии с вышеуказанными категориями. Это может уберечь от того, чтобы 90 процентов требований были объявлены критическими.) Если различные акционеры и заинтересованные лица никак не могут достичь консенсуса по поводу отнесения требований к той или иной категории, то проектная команда, пытаясь удовлетворить всех, в результате окажется парализованной из-за отсутствия необходимых ресурсов.

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

Из таких мрачных прогнозов можно сделать одно исключение: оно касается организаций, для которых безнадёжные проекты являются образом жизни. Разумеется, пользователи и высшее руководство не дураки, и они обычно извлекают уроки из своего опыта, даже если для их усвоения потребуется три или четыре проваленных проекта. Как было отмечено выше, первого менеджера безнадёжного проекта обычно губит неспособность расставить приоритеты в начале проекта, в то время как выжившие постепенно до этого доходят. Я ещё вернусь к этим вопросам в главе 7.

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

Традиционные методологии создания ПО – включая различные «структурные» и «объектно-ориентированные» методологии, разработкой которых некоторые мои коллеги и я занимались более 20 последних лет – сосредоточены на моделировании требований, обычно с помощью таких графических средств, как диаграммы потоков данных или диаграммы «сущность-связь». Но я в данной главе говорю именно об управлении требованиями в той лихорадочной обстановке, которая присуща безнадёжному проекту.

Эти два понятия – моделирование и управление – не являются противоречивыми или несовместимыми. Можно потратить время и силы как на одно, так и на другое; если команда безнадёжного проекта считает, что для лучшего понимания требований к системе полезно построить объектно-ориентированную модель, у меня нет никаких возражений. Я только хотел бы предостеречь проектную команду, чтобы она делала то, что именно она сама считает важным и полезным, а не то, что считают «правильным» блюстители чистоты методологии (здесь частично затрагиваются вопросы «наилучшей» практики, которые будут обсуждаться ниже).

Мой опыт говорит о том, что в большинстве безнадёжных проектов не используются формальные методы моделирования, такие, как SA/SD или OOA/OOD. Отчасти это из-за того, что эти методологии кажутся проектной команде слишком громоздкими и бюрократическими; отчасти из-за того, что CASE-средства, поддерживающие эти методологии, кажутся слишком неудобными для использования; и, как правило, из-за того, что они не видят, каким образом можно преобразовать полученные в результате анализа модели в работающий код – единственное, что в конечном счёте нужно пользователю. (В «нормальном» проекте, наоборот, SA/OOA-модели сами по себе воспринимаются, как весьма полезные. Пользователи и специалисты, определяющие бизнес-политику организации, будут толпиться вокруг диаграмм потоков данных и тихо бормотать друг другу: «Так вот в чем заключается наш бизнес! Может быть, имеет смысл провести реинжиниринг бизнес-процессов и изменить все это перед тем, как создавать новую автоматизированную систему».)

В самом деле, в экстремальной ситуации проектная команда даже не будет документировать ни одно из пользовательских требований; в своё оправдание (которое наверняка слышал каждый менеджер проекта!) они говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, команда обычно полагается на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе.

С точки зрения «приоритетности», о которой шла речь в разд. 5.1, все это порождает одну главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования «необходимо выполнить», какие «следует выполнить» и какие «можно выполнить»? Интересно отметить, что методологии SA/SD и OOA/OOD также не дают ответа на этот вопрос. Можно, конечно, определять приоритеты, раскрашивая кружочки на диаграммах потоков данных, но они изначально предназначены вовсе не для этого. Методологии SA/SD и OOA/OOD предназначены в первую очередь для понимания и объяснения требований, а не для управления ими в динамике.

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

3) Акционеры и заинтересованные лица не могут полностью согласиться с предложенными приоритетами. Разумеется, если они совсем не согласны, проект будет просто парализован; однако, нередко можно встретиться с такой ситуацией, когда для 80 процентов требований устанавливаются приоритеты и начинается работа над проектом, в то время как политиканы продолжают спорить относительно оставшихся 20 процентов. В результате этих споров требования с высоким приоритетом иногда появляются в самый последний момент. Это ставит перед проектной командой трудную задачу, однако вряд ли возможно этого избежать.

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

5) Изменяются обстоятельства вовне проектной команды. В зависимости от финансовых успехов компании увеличивается или уменьшается бюджет. Срок окончания проекта отодвигается или приближается (и даже очень сильно) в зависимости от того, насколько департамент маркетинга осведомлён относительно изменения конкурентной ситуации на рынке. Меняются решения правительства, меняются технологии (не всегда в лучшую сторону!), поставщики приходят и уходят, и т.д., и т.п. Каждое из этих внешних событий может оказать некоторое воздействие на решения, принятые в отношении приоритетов требований.

6) Нередко наступает «момент истины», когда пользователи, высшее руководство и участники проектной команды вынуждены признать, что система не будет готова в срок. Разумеется, если в начале проекта была проделана достаточно квалифицированная работа по определению приоритетов требований, такой кризис может и не наступить вообще. Но что если команда вынуждена признать, что она не может выполнить в срок даже все необходимые требования? Как было отмечено выше, менеджеру проекта обычно «снимают голову» и заменяют на другого; при этом, если новому менеджеру удаётся отодвинуть конечный срок, то приоритеты могут быть оставлены без изменения. Однако в этот момент все же, как правило, ранее принятые решения подвергаются серьёзному пересмотру. Конечный срок уже маячит впереди на расстоянии нескольких недель, и пользователи могут волей-неволей согласиться с тем, что некоторые требования, считавшиеся ранее абсолютно необходимыми, вообще перестают быть таковыми.

Этот перечень можно продолжать дальше, но думаю, что вывод ясен: управление приоритетом требований является критически важной частью «процесса» безнадёжных проектов. Конечно, если безнадёжный проект содержит всего дюжину требований, то управлять ими будет совсем несложно; можно нацарапать их на бумажной салфетке и просто пересматривать по мере необходимости. Однако, большинство проектов включает сотни требований, а многие – даже тысячи; проект самолёта Боинг-777 (который вполне можно считать мешком программ с крыльями) включал, по слухам, 300.000 требований. Но это ещё не все, ведь требования обычно не являются независимыми; некоторые требования зависят от других требований, а некоторые в свою очередь порождают другие требования.

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

К счастью, в настоящее время появилось новое поколение средств, обеспечивающих более комплексную и сложную поддержку управления требованиями. Вот некоторые из доступных на сегодняшний день средств: Requisite (Requisite, Inc.), DOORS (Zycad Corp.), RTM (Marconi Systems). Поскольку данная глава посвящена в основном процессам, а не средствам, я не буду вдаваться в детали этих трех продуктов; но поскольку средства влияют на процессы, важно знать хотя бы о их существовании (ветераны-разработчики ПО вспомнят старую поговорку: «Если единственным вашим инструментом является молоток, то все ваши проблемы выглядят как гвозди»).

Существует один аспект в комбинации процессов и средств, который следует особо отметить. Как было сказано выше, многие команды безнадёжных проектов отказываются от использования формальных методологий SA/SD или OOA/OOD, поскольку они выглядят слишком громоздкими и бюрократическими. Что интересно, акционеры и заинтересованные лица рассуждают точно так же. Если предоставить им выбор, то они предпочли бы, чтобы их не заставляли изучать, как читать диаграммы потоков данных; в самом деле, руководители и конечные пользователи высокого уровня иерархии жалуются, что они ничего не понимают во всех этих «технических» диаграммах. У них также не хватает терпения продираться сквозь сотни страниц с диаграммами и мелкими деталями описаний элементов данных или спецификаций процессов. Конечно, если времени и терпения достаточно, то проектная команда в состоянии преодолеть сопротивление и убедить конечных пользователей в том, что тщательно разработанные модели на самом деле приносят большую пользу – однако в безнадёжных проектах вечно не хватает ни времени, ни терпения.

Что пользователи в состоянии понимать – так это их собственный родной язык, например, английский для большинства североамериканских проектов. И что большинство из них предпочитают читать – это небольшой документ из 10-20 страниц, суммирующий все требования к системе. Требования в таком документе могут называться «характеристиками», а сам документ в целом – «Требования к системе» («Product Requirements Document» – PRD) или «спецификация высокого уровня» или ещё какой-нибудь подходящей фразой. Главное, что этот документ небольшой и на английском языке. Он не должен содержать рекламной «шелухи», а также непонятной терминологии или обозначений, заставляющих пользователей задумываться, что бы это значило. В идеальном случае каждый абзац или даже каждое отдельное предложение должны соответствовать конкретному требованию, чтобы и пользователи, и участники проектной команды могли использовать их в качестве отправной точки для своей дальнейшей работы.

Во всем этом есть один интересный момент – он заключается в том, что у нас уже одно знакомое всем средство для создания таких документов; оно называется «текстовый процессор». В самом деле, начальная версия такого документа обычно исходит от пользователей – например, в виде записки от вице-президента по маркетингу к исполнительному директору по поводу возникшей потребности в новом замечательном продукте со свойствами X, Y и Z, который мог бы соперничать с продуктом конкурента – даже когда департамент информационных технологий ещё ничего об этом не знает. На этой ранней стадии пользователи рассматривают текстовый процессор как своё средство, а записку службы маркетинга – как свой документ; в результате они проявляют гораздо большую готовность участвовать в последующих дискуссиях по поводу приоритетности требований, если при этом продолжают использоваться аналогичные средства и документы. Таким образом, мы наблюдаем тенденцию, ведущую к документо-центричному управлению требованиями, когда средства, используемые специалистами по ИТ (например, Requisite, DOORS или RTM), тесно интегрируются с текстовыми процессорами и документами, в которых пользователи хорошо разбираются (я должен честно признаться, что это в какой-то степени рекламный трюк, поскольку такая интеграция является одним из основных свойств Requisite, и я был одним из членов правления компании Requisite, когда писал эту книгу. Но поскольку я играю роль объективного автора, я искренне рекомендую вам познакомиться со всеми тремя перечисленными здесь продуктами.)

Ещё одно последнее соображение: очень важно, чтобы все акционеры и заинтересованные лица участвовали в процессе выработки начальных требований, их документирования и определения приоритетов. Разумеется, это касается любых проектов, однако нехватка времени и политические баталии, присущие безнадёжным проектам, нередко соблазняют менеджера проекта рассуждать следующим образом: «Ладно, мы будем двигаться дальше и обойдёмся без этого идиота Мелвина из департамента маркетинга; все, на что он способен – это не соглашаться никогда и ни с чем». При этом может возникнуть следующая проблема: Мелвин, получив серьёзную «политическую» пощёчину и чувствуя, что его игнорируют (и что менеджер проекта считает его идиотом!), скорее всего найдёт способ саботировать проект.

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

Существует ли у менеджера проекта такая формальная группа управления – т.е., группа, состоящая из акционеров и заинтересованных лиц, которая оценивает полученные в проекте результаты и принимает определённые решения относительно приоритетности требований – или нет, в данном случае не имеет значения; это зависит от того стиля управления и организации проектов, который сложился в каждой организации. Но что действительно имеет значение для успешного завершения безнадёжного проекта – это тщательное документирование каждой модификации, вносимой в исходные требования, и извещение о ней всех акционеров и заинтересованных лиц. Если вице-президент по финансам хочет потихоньку вставить в проект ещё одно приоритетное требование, это замечательно; однако при этом менеджер проекта должен позаботиться, чтобы об этом узнали вице-президент по маркетингу и исполнительный директор.

Некоторые менеджеры, прочтя предыдущий раздел данной главы, могут высказать недовольство: «Вот здорово! Это выглядит гораздо более формальным, чем все, что мы когда-либо делали!» Когда мне приходилось сталкиваться с такой реакцией в некоторых консалтинговых проектах, это просто ставило меня в тупик. С одной стороны, я уверен, что документирование, определение приоритетов и управление требованиями просто необходимы (независимо от того, какие средства и методы для этого используются) ; с другой стороны, я опасаюсь следующего: когда проектной команде, и без того заваленной работой выше головы, навязывается совершенно новый и незнакомый процесс, то этот процесс – например, управление требованиями – может оказаться последней каплей, переполнившей чашу терпения.

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

Какое безумие! Это действительно последняя капля, которая переполнит чашу терпения; в конце концов типичный безнадёжный проект пытается выполнить то, что раньше никогда не делалось, и (несмотря на мои предостережения в главе 4) команда нередко состоит из людей, которые никогда раньше не работали вместе. Так мало того, они ещё вынуждены осваивать использование незнакомой методологии или процесса, не будучи уверенными в том, что это им необходимо в первую очередь, и, напротив, будучи убеждёнными, что это только затормозит их работу. Чему же тогда удивляются блюстители методологии, когда они в подобных обстоятельствах сталкиваются с сопротивлением? Консультант Doug Scott недавно привёл мне пример такой ситуации:

В одном проекте, насколько мне известно, потребовался диаграммер для ERD, и они приобрели Excelerator. Обнаружив, что он поддерживает методологию SSADM, они внедрили её без какого-либо обучения персонала, после чего обнаружили, что темп работы на проектом значительно снизился (фактически, работа просто остановилась), в то время как каждый был занят чтением руководств, освоением средств и решением проблемы, что делать дальше (или переделывать то, что было сделано в «неправильном» порядке). Почти идеальный сценарий для тех, кто наблюдает за безнадёжными проектами.

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

Это означает, что менеджер безнадёжного проекта должен безоговорочно настаивать на процессах, которые он считает принципиально важными – например: «Каждый, кто посмеет внести изменения в исходный код, минуя процесс управления изменениями, будет немедленно уволен!» Или проектная команда должна сама сознательно пойти на внедрение процесса, понимая, что это позволит сократить затраты. Такое может скорее произойти в том случае, если участники команды ранее уже работали вместе и приобрели общий опыт использования различных процессов создания ПО; и наоборот, это маловероятно, если только один из участников команды встанет и скажет: «Я глубоко уверен, что структурный анализ является критически важным для успеха нашего проекта», в то время как другие и понятия не имеют, о чем это он говорит. Ещё одно утверждение, следующее из этого правила: попытка внедрить в безнадёжном проекте новый, незнакомый процесс может закончиться катастрофически, даже если команда верит, что он может помочь в работе. Проблемы с освоением, неизбежная путаница и споры по поводу деталей процесса обычно сводят на нет все выгоды.

Это означает, что такие формальные подходы, как SEI-CMM, ISO-9000 или внедрение новых методологий анализа/проектирования должны иметь место где-нибудь за пределами безнадёжного проекта. Внедрение таких процессов имеет смысл как часть долговременной корпоративной стратегии, и должно начинаться с выполнения пилотного проекта (который не должен быть безнадёжным проектом), сопровождаясь организацией необходимого обучения.

Если все это уже сделано, и если все другие разработки ПО в организации уже выполняются на третьем уровне SEI-CMM, то интересно выяснить, следует ли также использовать такие процессы в безнадёжном проекте. Как однажды заметил Watts Humprey на конференции в докладе по поводу SEI-CMM: «Если процесс нельзя использовать в критических условиях, его вообще не следует использовать».

Я не уверен, что многие согласятся с этим утверждением, особенно если безнадёжный проект рассматривать как единственное в жизни исключение из правил. Если это в самом деле так, то, возможно, имеет смысл отказаться от формальных процессов и предоставить проектной команде возможность использовать любые методы, которые она сочтёт приемлемыми. Однако не забывайте при этом моё утверждение, высказанное в главе 1: безнадёжные проекты становятся нормой, а не исключением. Если это так, то официально принятые в организации процессы следует, при необходимости, усовершенствовать, чтобы сделать их пригодными для использования в безнадёжном проекте. Тогда и только тогда утверждение Humprey будет иметь смысл.

Между прочим, если вы в самом деле столкнулись с потребностью усовершенствовать сложившуюся практику работы команды безнадёжного проекта, я рекомендую обратиться к методологии PSP (Personal Software Process), автором которой является Watts Humprey. Её основные положения изложены в моей книге «Rise and Resurrection of the American Programmer. Можно также прочесть книгу [2], хотя я честно предупреждаю: в ней 789 страниц.

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

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

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

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

Вплоть до этого момента времени они выражают своё недовольство: «Как вам понравится, если мы будем использовать ваш „достаточно хороший“ подход применительно к ПО ядерного реактора или системы управления воздушным движением?» Разумеется, я отвечу, что мне это совсем не нравится; и, если кто-нибудь вздумает затеять безнадёжный проект для создания такого рода высоконадёжных приложений, тогда я просто перестану летать на самолётах и буду держаться как можно дальше от предприятий с ядерными реакторами. С другой стороны, нам обычно и не приходится сталкиваться с безнадёжными проектами такого рода; скорее, это может быть кадровая система на ядерном предприятии или система резервирования авиабилетов. Это, конечно, не означает, что кадровые системы и системы резервирования авиабилетов должны работать со сбоями, однако все же непосредственные последствия этих сбоев будут не столь серьёзны.

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

Почему же нам не удаётся создать «достаточно хорошее» ПО? Это обычно объясняется совокупностью следующих причин:

7) Мы стремимся определять качество только в терминах дефектов, не задумываясь о других его аспектах – которые, с точки зрения пользователя, включают, например, готовность к определённой дате.

8) Мы предполагаем, что малое количество дефектов равносильно лучшему качеству, и полагаем, что пользователь всегда предпочитает такое качество – хотя существуют обстоятельства, когда пользователь готов пойти на компромисс и примириться с некоторыми ошибками в обмен на более скорое завершение работы или возможность продукта работать на различных программных/технических платформах и др.

9) Мы стремимся определить требования к качеству (дефектам) один раз, в самом начале проекта, и зафиксировать их, хотя обстоятельства могут измениться в течение проекта не один раз.

10) Мы так долго твердили, что процессы являются критически важными, что при этом зачастую забываем об их «нейтральности» – дурак, вооружённый процессами и средствами, все равно останется дураком. Невозможно обеспечить качество, если просто слепо следовать всем деталям методологии структурного анализа или рекомендаций SEI-CMM.

11) Мы рассматриваем обеспечение качества как процесс, укладывающийся в жёсткую схему, заданную в начале проекта раз и навсегда (или, что ещё хуже, для всех проектов во всей компании).

12) Мы недооцениваем нелинейный характер зависимостей между такими ключевыми параметрами проекта, как численность персонала, плановые сроки, бюджет и количество дефектов – все эти аспекты в безнадёжных проектах являются ключевыми.

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

14) Мы игнорируем такие факторы, как моральное состояние команды, адекватные условия для работы и др.

Каким же образом мы сможем создать «достаточно хорошее» ПО? Как отмечает James Bach [3], для этого требуется несколько вещей:

15) Утилитарная стратегия – искусство количественного анализа и максимизации чистого выигрыша в неопределённых ситуациях – обобщает идеи системного анализа, управления рисками, экономики, теории принятия решений, теории игр, теории управления и нечёткой логики.

16) Эволюционная стратегия – рассматриваемая не только по отношению к жизненному циклу проекта, но также к людям, процессам и ресурсам.

17) Героические команды – не Могучие Гениальные Программисты, а обычные умелые специалисты, способные к эффективному сотрудничеству.

18) Динамическая инфраструктура – противоположность бюрократии и засилью политики. Высшее руководство уделяет необходимое внимание проектам, уделяет внимание положению на рынке, предупреждает и разрешает конфликты между проектами, и становится на сторону проекта в случае конфликта между ним и бюрократами.

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

Не один раз уже в этой книге я предупреждал об опасностях, связанных с вмешательством блюстителей методологии и попытками насильно внедрить в практику проектной команды лишённые гибкости методологии или процессы создания ПО. То же самое касается внешних консультантов, гуру, знахарей, целителей, заклинателей змей и книг. Дажеэтой книги: если то, что я рекомендую, не находит должного понимания, и проектная команда не испытывает по этому поводу особого энтузиазма, то такую рекомендацию лучше проигнорировать!

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

К сожалению, у команд безнадёжных проектов практика такого рода зачастую отсутствует, поскольку их проект, как правило, рассматривается как первый проект такого рода в организации. Если он даже не первый, то все равно рассматривается как исключение – поэтому никто не побеспокоился заранее составить перечень хорошо и плохо зарекомендовавших себя методов. Что ещё хуже, большой процент безнадёжных проектов заканчивается провалом (иначе они не назывались бы «смертельными маршами»!). Таким образом, люди, которые могли бы помочь полезными советами в последующих безнадёжных проектах, уже ушли, были уволены, покончили жизнь самоубийством, заработали нервное расстройство или превратились в закоренелых циников.

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

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

Что же касается организаций, которым недоступен положительный опыт других команд, то я бы порекомендовал несколько источников. Данная тема затронута в одной из глав моей книги Rise and Resurrection of the American Programmer ; другие материалы, касающиеся наилучшей практики, можно найти на сайте консультанта Кристины Комафорд http://www.christine.com. Возможно, наиболее амбициозным проектом, находящимся в настоящее время в процессе разработки, является проект министерства обороны США, информацию о котором можно найти на сайте http://spmn.com.

Ниже перечислены «наилучшие практики», рекомендуемые в этом проекте (не забывайте данный мною ранее совет о том, что не следует воспринимать эту информацию буквально как «заповедь», которой необходимо следовать; наоборот, она может служить полезной отправной точкой для ваших собственных идей относительно наилучшей практики):

20) Формальное управление рисками – я буду обсуждать его позже в данной главе.

21) Согласованные интерфейсы – аппаратные интерфейсы, программные интерфейсы и интерфейсы между вашей системой и другими внешними системами.

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

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

24) Бинарная оценка качества по результатам этапов – другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно, фиксируя достигнутые результаты с помощью «бинарных» признаков. Одним из способов выполнения этого является стратегия «ежедневного завершения проекта», которая обсуждается в следующем разделе.

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

26) Фиксация дефектов в соответствии с заданными показателями качества – одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.

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

28) Ответственность и подотчётность руководства перед сотрудниками – увы, но в большинстве безнадёжных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадёжные проекты относятся к типу «самоубийственных» или «камикадзе».

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

29) Не следует ожидать более чем 10-процентного сокращения сроков по сравнению со среднестатистической нормой для аналогичных проектов – разумеется, если вы действительно в это верите, то не следует даже и начинать безнадёжный проект!

30) Не пытайтесь использовать новую технологию как средство для сокращения сроков – у вас будет и без того достаточно проблем кроме отлавливания ошибок в бета-версиях новых средств и технологий, добытых у знакомого поставщика. Более детально этот вопрос будет обсуждаться в главе 6.

31) Не навязывайте заказчику решения, специфичные только для него – полезный совет для любого проекта.

32) Не следует заниматься поиском панацей – об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.

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

34) Не следует ожидать точной оценки состояния проекта от чисто формальных оценок, выполненных множеством чересчур активных и некомпетентных критиков – проектная команда не должна об этом беспокоиться, поскольку она уже знает, что такие сеансы оценки представляют собой политические ритуалы. Этот совет предназначен скорее для руководителей высокого уровня, которые наблюдают за безнадёжным проектом с безопасного расстояния, пытаясь при этом определить, в каком состоянии он находится.

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

В течение прошлого года на своих семинарах в разных концах света я задал нескольким сотням менеджеров проектов два вопроса: «Если ваш коллега предпринимает свой первый безнадёжный проект, какой единственный совет для достижения успеха вы могли бы ему дать? И что единственное вы бы посоветовали ему не делать?» Я был весьма заинтригован, обнаружив, что никто даже не упомянул средства или технологии в качестве «одной самой важной вещи»; не были также упомянуты и формальные методологии и методы, такие, как структурный анализ или объектно-ориентированное проектирование. Некоторые рекомендовали стратегии управления человеческими ресурсами (например, «наймите хороших исполнителей» и «добейтесь, чтобы команда была действительно нацелена на успех»), однако почти все рекомендации были направлены на проведение переговоров, контроль за выполненным объёмом работ (которому хорошо способствует обсуждавшееся ранее определение приоритетов требований) и управление рисками (о котором речь пойдёт ниже).

Ещё один последний подход, заимствованный из упоминавшегося проекта министерства обороны, может оказаться полезным для безнадёжных проектов, хотя он в большей степени предназначен для менеджеров за пределами проекта, чем для менеджера самого проекта и участников его команды. Он называется «тест на алкоголь»: какие вопросы следует задать команде безнадёжного проекта, чтобы быстро определить, не утратили ли они чувство реальности до такой степени, что проект пора прекращать? Вопросы такого рода часто задаются консультантами, которых высшее руководство уполномочило проанализировать состояние проекта. Я сам был в таком положении, и я обычно могу заключить, что проект находится в плачевном положении, когда вижу остекленевший взгляд менеджера проекта, который напоминает взгляд лани, застигнутой светом фар приближающегося автомобиля.

Иногда безобидный вопрос типа «знаете ли вы, кто является вашим заказчиком?» приводит всех в полное замешательство, и в гробовом молчании каждый озадаченно смотрит на своего соседа, а потом все внимательно вглядываются в пол. Если вас интересуют некоторые другие вопросы «теста на алкоголь», ниже приведён их список:

36) Используете ли вы (и поддерживаете в актуальном состоянии) сетевой график работ?

37) Располагаете ли вы утверждённым планом и бюджетом?

38) Знаете ли вы, за разработку какого ПО несёте ответственность?

39) Можете ли вы перечислить первые десять проектных рисков?

40) Известен ли вам процент сжатия вашего плана по сравнению с нормальным?

41) Каков оценочный объём вашего ПО? Каким образом он вычисляется?

42) Известна ли вам та часть внешних интерфейсов, которая находится вне вашего контроля?

43) Достаточными ли знаниями о предметной области располагают ваши специалисты?

Как было отмечено выше, «тест на алкоголь» проводится в том случае, когда кто-либо в организации – как правило, не менеджер проекта, а кто-либо, стоящий на существенно более высоком уровне иерархии – почувствует, что проект идёт не так, как надо. Для того, чтобы выжить в политических схватках, менеджеру проекта и всей команде периодически следует задавать друг другу подобные вопросы. Менеджеру проекта вообще все время следует быть бдительным по отношению к другим признакам, говорящим о тревожном состоянии проекта, даже если в соответствии с официальным графиком PERT все выглядит как положено. Такими признаками могут быть:

44) Уход ключевых участников команды – это может произойти по ряду причин, однако важно вовремя почувствовать, не утратили ли участники проекта веру в свою способность завершить проект. Если начнут уходить ключевые разработчики, другие могут последовать за ними.

45) «Фактор обратной корреляции Дильберта» – чем больше карикатур Дильберта появляется на дверях в офисе и на досках объявлений, тем хуже идут дела в проекте.

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

47) Проекту даются новые имена, например, «Проект Титаник» – другая разновидность юмора висельников, которая, однако, является более серьёзным признаком того, что проектная команда утратила веру в успех, чувство причастности к проекту и вообще какой-либо интерес к работе.

48) Зловещее молчание конечных пользователей и высшего руководства, которые обычно каждый день интересовались ходом проекта – к тому моменту, когда вы это осознаете, может оказаться слишком поздно, чтобы наверстать упущенное, однако у вас может быть по крайней мере несколько дней, чтобы обновить своё резюме.

49) Бестолковая суета – бурная деятельность при отсутствии видимых результатов. Выходом из такой ситуации может быть использование идеи «мини-этапов» и стратегии «ежедневной сборки проекта».

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

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

Разумеется, реалии таковы, что приступить к ежедневной сборке проекта с самого первого дня невозможно. Правда, уже на второй день проекта можно написать подпрограмму типа «Hello, World», и трудно сегодня удивить кого-то совершенно новыми технологиями (в частности, многие из проектов, использующих Java, во время написания этой книги уже находились в процессе разработки). Однако, существуют определённые требования, которым должна удовлетворять версия прототипа системы при первой «официальной» демонстрации: помимо того, что она включает необходимую совокупность компонентов, процедур или модулей и, по крайней мере, несколько сотен, а может быть и тысяч строк кода, она должна выполнять реальный ввод данных, производить реальную обработку или вычисления и формировать реальный выход. Именно с этого момента следует начинать ежедневную сборку проекта и формировать каждый день новую (желательно улучшенную) версию системы.

Почему это так важно? Как любит говорить Jim McCarthy, менеджер продукта Microsoft Visual C++ и автор книги DynamicsofSoftwareDevelopment [4]:

«Ежедневная сборка – это биение сердца проекта. Она даёт знать, что жизнь продолжается». Такая стратегия может быть приоритетом номер один для менеджера проекта. Если в течение недели каждый крутит свою прялку, и никто не соберётся с духом, чтобы сообщить менеджеру проекта, что разрабатываемое ими клиент-серверное приложение никак не хочет правильно взаимодействовать с новой замечательной объектно-ориентированной базой данных, то в результате проект может безнадёжно отстать от графика. До тех пор, пока менеджер судит о состоянии проекта по устным отчётам, запискам или диаграммам потоков данных, будет слишком легко перепутать движение с прогрессом и усилия с результатами. Однако, если менеджер проекта настаивает на ежедневной физической демонстрации результатов, будет гораздо труднее скрыть какие-либо трудности, которые в конечном счёте могут способствовать провалу проекта.

Некоторые менеджеры проекта будут кивать головами и подтверждать, что они всегда именно так и поступают, однако большинство согласится, что они довольствуются еженедельным, ежемесячным или полугодовым контролем реализации системы. В то время как вряд ли кто-нибудь вправе претендовать на «изобретение» данного подхода, многие знают, что он впервые стал популярным во время разработки операционной системы Windows NT (интересную дискуссию на эту тему можно обнаружить в описании данного проекта, приведённом в [5]). Любопытно также отметить, что при разработке Windows 95 также использовался принцип ежедневной сборки проекта; заключительная бета-версия перед выпуском конечного продукта была реализована в августе 1995 года и называлась «Проект 951».

Важно осознавать, что подобный подход становится неотъемлемой составляющей процесса разработки системы, которому следует проектная команда. Представьте себе, каково быть участником команды, которая должна демонстрировать работающую версию программного обеспечения 951 день подряд! (Правда, если быть честным, я не уверен, что команда Microsoft действительно свято соблюдала такой порядок каждый день. Возможно также, что формирование более чем одной версии укладывалось в 24-часовой промежуток, и возможно, команда могла день или два отдохнуть в этом марафоне.) Кроме того, чтобы быть эффективным, процесс ежедневного завершения проекта должен быть автоматизированным и должен выполняться ночью без чьего-либо участия, когда все программисты отправились домой спать (или влезли на свои рабочие столы и забрались в спальные мешки!). Такой подход подразумевает наличие автоматизированного управления конфигурацией ПО и механизмов контроля исходных кодов, а также разнообразных «скриптов» для выполнения компиляции и сборки приложений. Но что ещё более важно, он подразумевает наличие системы автоматизированного тестирования, которая может работать всю ночь, выполняя гору тестов для проверки работоспособности системы. Таким образом, чтобы реализовать на практике принцип ежедневной сборки проекта, необходимо иметь в своём распоряжении адекватный набор средств и технологий; мы ещё вернёмся к этому вопросу в главе 6.

Действие данного принципа может также дополнительно усилить ряд следующих мер:

50) Менеджеру проекта следует переместить свой офис непосредственно к месту разработки и тестирования системы, как только начнётся процесс ежедневной сборки проекта. Так поступил Dave Cutler в Microsoft. Рассказывают страшные истории, как он метал громы и молнии, когда появлялся в офисе и обнаруживал, что сборка очередной версии в полночь накрылась. Будет менеджер проявлять свой гнев или нет, важно, чтобы он был почти всегда на виду и непосредственно участвовал в ежедневном процессе, а не уподоблялся генералу, который получает ежедневные сводки с поля боя, находясь за много миль от него в тылу.

51) Поскольку вполне вероятно, что ночной процесс ежедневного формирования версии потребует минимального человеческого вмешательства, будет полезным установить следующий порядок: любой программист, допустивший ошибку в коде, которая привела к аварийному завершению ежедневной сборки, удостаивается высокой чести наблюдать за очередной сборкой, пока не появится следующая жертва. Разумеется, такой порядок имеет как плюсы, так и минусы, но по крайней мере благодаря ему команда гораздо «ближе» знакомится с принципом ежедневной сборки проекта.

52) Поручите одному из программистов, который обычно приходит в офис рано утром, проверять успешность завершения ежедневной сборки и вывешивать результаты на видное место. Если ни у кого нет желания или возможности появляться в офисе рано утром, наймите студента колледжа. Одна компания велела студенту поднимать над офисом флаг, чтобы таким образом предупреждать сотрудников, какой день ожидается: плохой или хороший. Зелёный флаг означал успешное завершение процесса ежедневной сборки, а красный – аварийное завершение.

Если управление требованиями – особенно определение приоритетов требований – является в безнадёжном проекте наиболее важным процессом, то вторым важнейшим процессом является управление рисками. Если бы понятие «риска» не было столь критическим, тогда мы не употребляли бы по отношению к проекту определение «безнадёжный». Интересно отметить, что один из вопросов «теста на алкоголь» связан с идентификацией проектных рисков, и если ответом на такой вопрос со стороны менеджера «нормального» проекта может быть удивлённый взгляд (даже если проект оказался в плачевном состоянии), то менеджер безнадёжного проекта скорее всего даст на такой вопрос чёткий и ясный ответ. Менеджер был бы просто глупцом, если бы он приступил к безнадёжному проекту, не имея какого-либо серьёзного представления об основных рисках и о том, как с ними бороться.

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

Если вся эта дискуссия относительно рисков разработки ПО кажется вам чересчур раздутой или вообще не относящейся к делу, можете смело переходить к следующей главе. Меня больше всего заботит менеджер проекта, который успешно завершил несколько «нормальных» проектов, справляясь с рисками на интуитивном уровне; такой подход в безнадёжном проекте обычно не работает. На самом деле, существуют эффективные формальные процессы управления рисками, позволяющие предпринимать безнадёжные проекты, которые в противном случае наверняка стали бы самоубийственными.

На тему об управлении рисками написана масса книг, их обзор не является предметом данной книги. Всю необходимую вам детальную информацию вы можете получить из первоисточников [4, 5, 6, 7], хотя важно остерегаться, чтобы «служба управления рисками» не погребла проект под формами, отчётами и другими бюрократическими штучками. Например, некоторые менеджеры безнадёжных проектов следуют очень простой практике идентификации и мониторинга десяти основных рисков проекта; их можно отпечатать на одной странице и еженедельно выполнять оперативный анализ их состояния.

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

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

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

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

С другой стороны, как отмечает Rob Charette [8], основные причины провалов проектов зачастую кроются в окружающей проект среде (среде самой организации и/или внешней среде), как показано на рис. 5.2. Эта среда почти всегда находится вне пределов досягаемости менеджера проекта, и что не менее важно, менеджер проекта может и не подозревать о наличии этих «внешних» рисков, пока они не обрушатся на проект.

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

Рис. 5.2 Область действия проектных рисков

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

Оценка риска выполняется обычно путём оценки сложности разрабатываемой системы или продукта, а также оценки клиентской среды и среды проектной команды. Сложность продукта можно оценить в терминах объёма (например, количества функциональных точек), ограничений производительности, технической сложности и т.д. Риск, связанный с клиентской средой, определяется в основном такими факторами, как количество пользователей, вовлечённых в проект, уровень квалификации пользователей, значение разработки для пользовательского бизнеса, вероятность того, что внедрение новой системы (если оно произойдёт) приведёт к реорганизации или даунсайзингу и т.д. Наконец, риск, связанный со средой проектной команды, зависит от её способностей, опыта, морального состояния и физического/эмоционального здоровья.

Как правило, достаточно полная модель риска может включать сто или более факторов риска; как отмечено ранее, некоторые проектные команды сознательно ограничиваются рассмотрением десяти наиболее существенных рисков. Некоторые из рисков можно оценить количественно – например, требования к производительности (скорости реакции системы) или объём системы, выраженный в количестве функциональных точек. Другие факторы – например, степень дружелюбности или враждебности пользователей – могут быть оценены только качественно. Такие факторы принято характеризовать значениями «высокий», «низкий» или «средний».

После того, как риски подверглись идентификации и оценке, менеджер и команда могут попытаться выбрать подходящую стратегию минимизации или исключения по возможности большего количества рисков. Эта деятельность носит, конечно, общий характер, однако не следует забывать, что сама природа безнадёжного проекта такова, что количество рисков превышает обычное, они более серьёзны, и от них нельзя просто так избавиться. С другой стороны, если риски являются экстраординарными, то и решения должны быть адекватными: в то время как проектная команда «нормального» проекта может никогда не набраться смелости, чтобы обратиться к исполнительному директору или первому вице-президенту с просьбой уменьшить риск путём существенного увеличения бюджета или снятия серьёзных бюрократических ограничений, будет вполне разумным обратиться с такой просьбой в безнадёжном проекте. Если вы этого не сделаете – а для этого может потребоваться пройти по иерархической лестнице и обойти несколько уровней тупых начальников – то вы так никогда и не узнаете, удалось бы вам решить ваши проблемы или нет.

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

Довольно легко оставить за бортом многие из тех идей, которые обсуждались в этой главе, и оказаться впоследствии в плену пустопорожней бюрократии. Однако, как отмечает Stephen Nesbit (я получил его сообщение как раз тогда, когда добрался до конца этой главы и не знал толком, как её закончить):

Отсутствие стандартов и методологии само по себе может превратить проект в безнадёжный. Например, в моем последнем проекте сжатый и нереальный план был использован в качестве предлога для того, чтобы отказаться от следующего:

1) Использования системы конфигурационного управления для контроля проектного исходного кода, сосредоточенного в трех различных компьютерных системах, расположенных в двух территориально удалённых местах. В результате значительное время было потеряно впустую в попытках:

а) осуществить сборку программного обеспечения;

б) определить, кому какая версия ПО принадлежит;

в) определить, почему ПО работает на одной системе и не работает на другой.

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

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

Итак, пожалуйста, не надо воспринимать эту главу как предлог для отказа от каких-либо процессов, методологий или методов вообще; в самом деле, это может погубить безнадёжный проект. Фокус заключается в том, чтобы отыскать те процессы, методологии или методы, которые действительно работают, и которым команда будет следовать естественным образом и бессознательно. Последнее особенно важно: команда испытывает такой стресс и давление, что должна делать многие вещи чисто инстинктивно. Если взвалить на команду бремя новых, незнакомых процессов, которые настолько сложны, что они вынуждены будут каждые пять минут останавливаться и заглядывать в руководство, чтобы определить, что делать дальше, то все пропадёт впустую. Поэтому надо поступать проще – и если команда может запомнить только одно слово, этим словом должно быть приоритетность.

Литература к главе:

1) Stephen R. Covey, Roger A. Merill, Rebecca R. Merill. First Things First. New York: Simon & Schuster, 1994.

2) Watts Humphrey. A Discipline of Software Engineering. Reading, MA: Addison-Wesley, 1995.

3) James Bach. The Challenge of ‘Good Enough’ Software. American Programmer, October 1995.

4) Jim McCarthy. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995.

5) G. Pascal Zachary. Show-Stopper! New York: Free Press, 1994.

6) Rob Thomsett. The Indiana Jones School of Risk Management. American Programmer, September 1992.

7) Capers Jones. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Prentice Hall, 1994.

8) Rob Charette. Building Bridges over Intellectual Rivers. American Programmer, September 1992.

Дополнительная литература:

1) 1. Alan M. Davis. Software Requirements: Objects, Functions, and States. Englewood Cliffs, NJ: Prentice Hall, 1993.

2) Mark C. Paulk, Charles V. Weber, Bill Curtis, Mary Beth Chrises, et al. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995.

3) Robert N. Charette. Application Strategies for Risk Analysis. New York: McGraw-Hill, 1990.

4) Robert N. Charette. Software Engineering Risk Analysis and Management. New York: McGraw-Hill, 1989.