Путь камикадзе - [51]

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

К счастью, в настоящее время появилось новое поколение средств, обеспечивающих более комплексную и сложную поддержку управления требованиями. Вот некоторые из доступных на сегодняшний день средств: 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, когда писал эту книгу. Но поскольку я играю роль объективного автора, я искренне рекомендую вам познакомиться со всеми тремя перечисленными здесь продуктами.)

Ещё одно последнее соображение: очень важно, чтобы