Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности. Если бы вам в самом начале проекта удалось убедить всех акционеров и заинтересованных лиц согласиться с приоритетностью требований, и если бы эти приоритеты никогда не менялись в течение проекта ... ну что ж, если вы в самом деле в это верите, то вы, наверное, также верите в фей и колдунов. В реальных же безнадежных проектах обычно возникают в различных вариантах следующие дилеммы:
· Акционеры и заинтересованные лица не могут полностью согласиться с предложенными приоритетами. Разумеется, если они совсем не согласны, проект будет просто парализован; однако, нередко можно встретиться с такой ситуацией, когда для 80 процентов требований устанавливаются приоритеты и начинается работа над проектом, в то время как политиканы продолжают спорить относительно оставшихся 20 процентов. В результате этих споров требования с высоким приоритетом иногда появляются в самый последний момент. Это ставит перед проектной командой трудную задачу, однако вряд ли возможно этого избежать.
· Во время проекта изменяется ситуация в команде. Например, в одно прекрасное утро менеджер проекта приходит в офис и обнаруживает, что два его лучших программиста, Матильда и Эзекиель, решили создать реггей-бэнд и только что уехали в Нэшвил в поисках контракта для записи диска. Никто не предполагал, что такое может случиться, однако это случилось. Первые три вопроса, которые вынужден выяснить менеджер, заключаются в следующем: «Над какими обязательными требованиями работали эти мерзавцы, каков статус этих требований и кому я могу их перепоручить?»
· Изменяются обстоятельства вовне проектной команды. В зависимости от финансовых успехов компании увеличивается или уменьшается бюджет. Срок окончания проекта отодвигается или приближается (и даже очень сильно) в зависимости от того, насколько департамент маркетинга осведомлен относительно изменения конкурентной ситуации на рынке. Меняются решения правительства, меняются технологии (не всегда в лучшую сторону!), поставщики приходят и уходят, и т.д., и т.п. Каждое из этих внешних событий может оказать некоторое воздействие на решения, принятые в отношении приоритетов требований.
· Нередко наступает «момент истины», когда пользователи, высшее руководство и участники проектной команды вынуждены признать, что система не будет готова в срок. Разумеется, если в начале проекта была проделана достаточно квалифицированная работа по определению приоритетов требований, такой кризис может и не наступить вообще. Но что если команда вынуждена признать, что она не может выполнить в срок даже все необходимые требования? Как было отмечено выше, менеджеру проекта обычно «снимают голову» и заменяют на другого; при этом, если новому менеджеру удается отодвинуть конечный срок, то приоритеты могут быть оставлены без изменения. Однако в этот момент все же, как правило, ранее принятые решения подвергаются серьезному пересмотру. Конечный срок уже маячит впереди на расстоянии нескольких недель, и пользователи могут волей-неволей согласиться с тем, что некоторые требования, считавшиеся ранее абсолютно необходимыми, вообще перестают быть таковыми.
Этот перечень можно продолжать дальше, но думаю, что вывод ясен: управление приоритетом требований является критически важной частью «процесса» безнадежных проектов. Конечно, если безнадежный проект содержит всего дюжину требований, то управлять ими будет совсем несложно; можно нацарапать их на бумажной салфетке и просто пересматривать по мере необходимости. Однако, большинство проектов включает сотни требований, а многие - даже тысячи; проект самолета Боинг-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, когда писал эту книгу. Но поскольку я играю роль объективного автора, я искренне рекомендую вам познакомиться со всеми тремя перечисленными здесь продуктами.)
Еще одно последнее соображение: очень важно, чтобы все акционеры и заинтересованные лица участвовали в процессе выработки начальных требований, их документирования и определения приоритетов. Разумеется, это касается любых проектов, однако нехватка времени и политические баталии, присущие безнадежным проектам, нередко соблазняют менеджера проекта рассуждать следующим образом: «Ладно, мы будем двигаться дальше и обойдемся без этого идиота Мелвина из департамента маркетинга; все, на что он способен – это не соглашаться никогда и ни с чем». При этом может возникнуть следующая проблема: Мелвин, получив серьезную «политическую» пощечину и чувствуя, что его игнорируют (и что менеджер проекта считает его идиотом!), скорее всего найдет способ саботировать проект.