Документ о концепции и границах

Документ о концепции и границах (vision and scope document) собирает бизнес-требования в единый документ, который подготавливает основу для последующей разработки продукта. В некоторых организациях с этой же целью создают устав проекта (Wiegers, 2007) или положение о бизнес-задачах. В организациях, создающих ПО на продажу часто создают документ основных рыночных требований (market requirements document, MRD). В нем более детально, чем в документе о концепции и границах, рассматриваются целевые сегменты рынка и вопросы коммерческого успеха продукта.

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

На рис. 5-3 показан шаблон документа о концепции и границах, а далее в главе элементы шаблона описываются более детально. Как и в случае с любым шаблоном, этот нужно изменить в соответствии со спецификой проекта. Если вы уже зафиксировали информацию в других документах, не нужно дублировать ее в документе о концепции и границах. Некоторые части документа о концепции и границах повторяются от проекта к проекту, в их числе бизнес-цели, бизнес-риски и профили заинтересованных лиц.

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

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

Рис. 5-3. Рекомендуемый шаблон документа о концепции и границах

Использование шаблонов

Шаблоны обеспечивают единообразие при организации информации от проекта к проекту. Они позволяют мне помнить то, что я могу забыть, если начну с чистого листа.

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

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

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

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

Один менеджер проектов так описал преимущества, полученные от внедрения документа требований:

«Их заполнение занимает много времени. Первые несколько раз, когда я их заполнял, я был удивлен объемом подробных сведений, которые нужны, чтобы от документа была польза, а после этого нужен большой объем работы, чтобы привести документ в порядок, избавиться от двусмысленностей, заполнить пробелы и т. п. Но оно того стоило. Первые два продукта, разработанные после внедрения шаблонов, были выпущены вовремя, и качество их было намного выше, чем раньше».