Заинтересованными в проекте лицами (stakeholders) называются отдельные лица, группы или организации, которые активно вовлечены в проект, на которых влияет результат проекта и которые сами могу влиять на этот результат (Project Management Institute, 2000; Smith, 2000). Профили заинтересованных лиц описывают различные категории клиентов и других ключевых лиц, заинтересованных в этом проекте. Вам не нужно описывать каждую группу заинтересованных лиц, например юристов, которые проверят соответствие надлежащим законам. Сферой вашего интереса должны стать различные группы клиентов, целевые рыночные сегменты и различные классы пользователей, входящих в эти сегменты. В профиль каждого заинтересованного в проекте лица включается следующая информация:
· основная ценность или преимущество, которое продукт принесет заинтересованным лицам и то, как продукт удовлетворит покупателей. Ценность для заинтересованных лиц представляют:
o улучшенная производительность;
o меньшее количество переделок;
o снижение себестоимости;
o ускорение бизнес-процессов;
o автоматизация задач, ранее выполнявшихся вручную;
o возможность выполнять совершенно новые задачи;
o соответствие соответствующим стандартам и правилам;
o лучшая, по сравнению с текущими продуктами, легкость и простота использования;
· их вероятное отношение к продукту;
· наиболее интересные функции их характеристики;
· все известные ограничения, которые должны быть соблюдены.
Приоритеты проекта
Чтобы принимать эффективные решения, заинтересованные лица должны договориться о приоритетах проекта. Один из подходов к этому заключается в рассмотрении пяти измеряемых параметров проекта: функции (или объем), качество, график, затраты и кадры (Wiegers. 1996а). В любом проекте каждый из этих параметров относится к одной из трех категорий:
ограничение — лимитирующий фактор, в рамках которого должен оперировать менеджер проекта;
ключевой фактор — важный фактор успеха, ограниченно гибкий при изменениях;
степень свободы — фактор, который менеджер проекта может до определенной степени изменять и балансировать относительно других параметров.
Задача менеджера проекта — настроить те факторы, которые представляют собой степени свободы для достижения ключевых факторов успеха проекта в рамках, налагаемых ограничениями. Не все факторы могут быть ключевыми, как и не все — ограничениями. Менеджеру проекта необходима определенная степень свободы для того, чтобы он мог реагировать должным образом на изменение требований к проекту или внешних обстоятельств. Представьте себе, что отдел маркетинга неожиданно требует создать продукт на месяц раньше сроке. Какова будет ваша реакция?
Вы отложите реализацию определенных требований до более поздней версии?
Сократите запланированный цикл тестирования системы?
Оплатите сверхурочную работу вашим специалистам или пригласите специалистов по контракту для ускорения разработки?
Привлечете ресурсы других проектов для разрешения ситуации? Именно от приоритетов проекта зависят ваши действия в подобных ситуациях.
Операционная среда
Опишите среду, в которой будет использоваться система, и определите важнейшие требования к доступности, надежности, производительности и целостности. Эта информация существенно влияет на определение архитектуры системы, что является первым — и часто самым важным— этапом проектирования. Архитектура системы, предназначенной для поддержки пользователей, которые находятся далеко друг от друга и которым необходим круглосуточный доступ, сильно отличается от той, что предназначена для доступа пользователей, находящихся рядом, только в рабочие часы. На нефункциональные требования, такие как отказоустойчивость и способность обслуживать систему во время ее работы, требуется значительное количество средств, отпущенных на проектирование и реализацию. Чтоб прояснить ситуацию, задайте заинтересованным лицам уточняющие вопросы.
Пользователи расположены далеко (географически) или близко друг от друга? В скольких часовых поясах работают ваши пользователи?
Когда пользователям, находящимся в различных географических местоположениях, требуется доступ к системе? Где данные генерируются и используются? Насколько далеко друг от друга расположены эти местоположения? Нужно ли объединять данные из разных местоположений?
Известно ли максимальное время отклика для получения доступа к данным, которые могут храниться удаленно?
Готовы ли пользователи смириться с прерыванием работы службы или непрерывный доступ к системе крайне важен для работы их компании?
Какие элементы управления безопасностью и требования к защите данных необходимы?
Контекстная диаграмма
Уточнение рамок определяет границу и связи системы, которую мы разрабатываем, со всем остальным миром. Контекстная диаграмма (context diagram) графически иллюстрирует эту границу. Она определяет оконечные элементы (terminators), расположенные вне системы, которые определенным образом взаимодействуют с ней, а также данные, элементы управления и материальные потоки, протекающие между оконечными элементами и системой. Контекстная диаграмма представляет собой высший уровень абстракции в диаграмме потока данных, разработанной по принципам структурного анализа (Robertson и Robertson, 1994), но эта модель полезна и в случае применения какой-либо другой методики разработки. Вы можете включить контекстную диаграмму в документ об образе и границах, или определить ее как приложение к спецификации требований, или как часть модели потоков данных системы.
На рис. 5-3 показана часть контекстной диаграммы для Chemical Tracking System. Вся система изображена кружком; на контекстной диаграмме намеренно не показывают внутренние объекты системы, процессы и данные. «Система» внутри кружка может иметь любую комбинацию ПО, оборудования или людских ресурсов. Оконечные элементы в прямоугольниках представляют классы пользователей («Химик» или «Покупатель»), отделы («Отдел охраны труда и техники безопасности»), другие системы («База данных по обучению») или аппаратные устройства («Считывающее устройство штрих-кода»). Стрелками показаны потоки данных («запрос химиката») или физические элементы («контейнер с химикатом») между системой и оконечными элементами.
Вы можете ожидать, что поставщики химикатов должны быть показаны на диаграмме в виде оконечных элементов. Ведь компания направляет заказы для выполнения поставщикам, а те отправляют контейнеры с химикатами и счета в Contoso Pharmaceuticals, отдел же закупок пересылает чеки продавцам. Однако эти процессы происходят вне Chemical Tracking System, как часть операций отделов закупок и приобретений. Глядя на контекстную диаграмму становится совершенно ясно, что система не участвует напрямую в размещении заказов у поставщиков, в получении продуктов или оплате счетов.
Рис. 5-3. Контекстная диаграмма для Chemical Tracking System
Назначение таких средств, как контекстная диаграмма, заключается в стимулировании ясного и точного взаимодействия между заинтересованными в проекте лицами. Эта ясность гораздо важнее слепого следования правилам создания «правильной» контекстной диаграммы. Однако я горячо рекомендую использование схему, показанную на рис. 5-3, в качестве стандарта, когда вы возьметесь рисовать контекстные диаграммы. Предположим, вы решите использовать треугольник вместо кружка для изображения системы и эллипсы вместо прямоугольников для изображения оконечных элементов. Вашим коллегам будет трудно читать диаграмму, нарисованную в соответствии с вашими личным предпочтениями, а не с общепринятым стандартом.