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

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

• Образ продукта (product vision) - высокоуровневое видение и пожелания относительно продукта и его ключевых характеристик. Он отвечает на вопрос «какой продукт мы хотим создать?». Образ продукта фокусируется на философии и ценностях, которые воплотит продукт.

• Концепция продукта (product concept) - более детальное описание продукта, его характеристик, сценариев использования и ценности для пользователей. Концепция продукта отвечает на вопрос «как продукт будет работать?». Она включает общие спецификации дизайна и функциональности.

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

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

Например:

• «Я буду приезжать с работы на машине» — это определяет необходимость интегрированного гаража или отдельной парковочной площадки.

• «Я люблю принимать душ после работы и по утрам!» —  указывает на важность функциональной ванной комнаты.

• Желание сидеть у камина по вечерам показывает значимость семейной гостиной с камином, удобными местами для отдыха и проведения времени и так далее.

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

Итак, образ жилища, отвечающий образу жизни будущих владельцев, создается путем:

1) Понимания действий, сценариев и приоритетов использования пространства целевой аудиторией. 

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

3) Синтеза полученных решений в общий дизайн-образ, удовлетворяющий потребностям будущих жильцов. 

4) Тестирования и доработки образа с учетом отзывов представителей целевой аудитории.

Аналогично, при создании смартфона важно понимать модели взаимодействия будущих пользователей с устройством:

• Как они будут держать телефон - одной рукой, двумя руками, используя обе руки при наборе сообщений и т.д. Это влияет на размер, вес и эргономику устройства.

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

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

Подобные модели поведения пользователей анализируются и преобразуются разработчиками в конкретные эргономические решения:

• Размер, форма и вес телефона, расположение кнопок/элементов управления и т.д. 

• Логика и иерархия меню, количество уровней, использование табов/вкладок и т.п. 

• Приоритизация приложений в ленте, группировка по категориям и т.д. 

• Интеграция наиболее важных функций в быстрые доступы/ярлыки. 

и другие решения. 

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

• Автомобиль: модель вождения (городской/междугородний трафик), состав пассажиров (семья/один водитель), грузовая нагрузка и т.д. определяют дизайн салона, расположение элементов управления, доступный объем багажника и пр. 

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

• Городская среда: модели передвижения в пространстве города (пешеход, автомобиль, общественный транспорт), цели (проживание, работа, отдых) и сценарии использования инфраструктуры определяют планировку пространства города, размещение объектов, тип улиц и т.п. 

• Программный продукт: модели взаимодействия пользователей с продуктом (частота/продолжительность использования, сложность выполняемых задач, когнитивные способности целевой аудитории и т.д.) лежат в основе дизайна интерфейса, логики работы с продуктом, уровня сложности и т.п. 

Создание учебной программы также опирается на понимание модели поведения будущих студентов и преобразование ее в конструктивные дидактические решения. 

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

• Выбор наиболее важных и интересных для студентов разделов в качестве основного содержания курса. 

• Использование практикоо-ориентированных методов обучения: проекты, кейсы, практические задачи и т.п. 

• Подбор соответствующих примеров, задач и проектов, мотивирующих студентов. 

• Определение оптимального баланса между теорией и практикой. 

• Выбор стиля подачи материала (лекции, интерактивные занятия, самостоятельная работа и т.д.), соответствующего стилям обучения студентов. И так далее.

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

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

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

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

К примеру:

• Ограниченный бюджет - это может ограничивать этажность, применение дорогостоящих материалов, площадь дома и отдельных помещений. 

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

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

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

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

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

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

Влияние разных требований будет различным, но, в конечном счете, именно требования будет определять образ желаемого результата. Стандарт ГОСТ Р ИСО 9000-2015 даже определяет проектирование и разработку (design and development) как совокупность процессов, преобразующих требования  к объекту в более детальные требования к этому объекту. 

Требования играют ключевую роль в управлении проектами, так как на их основе:

• Происходит планирование работ - определяются задачи и этапы, ведущие к достижению требований. 

• Осуществляется контроль выполнения - проверяется соответствие промежуточных и конечных результатов проекта первоначальным требованиям. 

• Принимается / не принимается результат проекта заказчиком - требования являются критерием оценки реализованных решений.

• Совершаются изменения в проекте - появление новых требований порождает корректировки планов, структуры, результатов проекта. И т.д.

Основными свойствами хороших требований являются:

• Полнота - включение всех необходимых свойств и параметров результата. 

• Непротиворечивость - отсутствие противоречий между отдельными требованиями. 

• Однозначность - формулировка требований допускает только одно толкование. 

• Измеримость - требования по возможности должны быть количественными или поддаваться количественной оценке.

• Согласованность - требования не должны противоречить друг другу и общим целям проекта.

• Адекватность - требования должны соответствовать роли и масштабу проекта.

• Управляемость - требования должны допускать управление и контроль их выполнения.

• Своевременная доступность - требования должны быть доступны на протяжении всего жизненного цикла проекта.

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

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

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

Для удобства работы с требованиями, они заносятся в общий реестр. Реестр требований представляет собой систематизированный список требований к проекту. Обычно он содержит следующую информацию:

• Идентификатор требования - уникальный код или номер требования. Позволяет однозначно идентифицировать каждое требование. 

• Сформулированное требование - текстовая формулировка требования на естественном языке. Описывает функциональные и нефункциональные свойства результата проекта. 

• Тип требования - функциональное, нефункциональное, бизнес-требование и т.д. Позволяет классифицировать требования. 

• Приоритет требования - высокий, средний, низкий. Определяет важность выполнения каждого требования. Используется при планировании и приоритезации работ. 

• Статус выполнения - выполнено, в работе, не выполнено. Отображает текущее состояние выполнения требования. Позволяет контролировать прогресс работ по проекту. 

• Дополнительная информация - комментарии, обоснование, примечания и пр. Любая дополнительная информация, полезная для понимания и выполнения требования.

• Ссылки - связи с другими элементами реестра (требованиями, задачами, документами и т.д.). Позволяют устанавливать взаимосвязи между данными о проекте.

• И другие поля - в зависимости от методологии и инструментов управления проектом, используемых в организации. 

Реестр требований позволяет:

• Систематизировать и структурировать требования к проекту. 

• Поддерживать требования в актуальном состоянии на протяжении всего жизненного цикла проекта. 

• Приоритезировать требования и планировать выполнение работ по их реализации. 

• Контролировать статус выполнения каждого требования и прогресс по проекту в целом. 

• Прослеживать взаимосвязи между требованиями, задачами, документами и другими объектами проекта. 

• Обеспечивать прослеживаемость требований, позволяя возвращаться к исходным бизнес-требованиям. 

• Соответствовать стандартам и методологии управления требованиями, принятой в организации. 

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

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

Требования к проекту дома прямо связаны с заинтересованными лицами (стейкхолдерами) проекта. К примеру, среди основных стейкхолдеров в примере с домом можно выделить:

• Заказчик (владелец участка) - предъявляет требования, исходя из своих потребностей, предпочтений, ограничений бюджета и т.п. Требования заказчика определяют функциональное назначение и основные параметры дома.

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

• Инженеры (конструкторы, инженеры-сметчики, инженеры-снабженцы и т.д.) - предъявляют требования, связанные с техническими характеристиками проекта (несущими и ограждающими конструкциями, инженерными системами, материалами, коммуникациями и т.п.).

• Подрядчик - вносит требования, определяемые принятой технологией строительства, наличием материально-технических ресурсов и квалифицированных кадров. 

• Госорганы (архнадзор, пожнадзор, роспотребнадзор и т.д.) - предъявляют требования, основанные на строительных нормах и правилах, сводах правил.

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

Заинтересованные лица могут быть разными в зависимости от предметной сферы и конкретных условий реализации проекта. К примеру, для проекта по разработке практико-ориентированной учебной программы основными стейкхолдерами будут:

• Учебное заведение - предъявляет требования к достижению установленных образовательных стандартов, качеству подготовки выпускников, соответствию программы профилю обучения. 

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

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

• Работодатели - выдвигают требования к соответствию программы актуальным потребностям рынка труда, приобретению студентами профессиональных компетенций, востребованных при трудоустройстве.

• Государственные органы - предъявляют требования соблюдения образовательных стандартов и правил сертификации образовательных программ. 

• Профессиональные сообщества - формулируют требования, соответствующие профессиональным практикам и современному состоянию отрасли.

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

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

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

Информация, содержащаяся в реестре стейкхолдеров, обычно включает:

• Идентификатор стейкхолдера - уникальный код стейкхолдера. 

• Имя / название стейкхолдера. 

• Тип стейкхолдера - владелец работ; спонсор; исполнитель и т.д.

• Интересы и требования стейкхолдера относительно проекта. Позволяет идентифицировать потенциальные препятствия и конфликты.

• Влияние стейкхолдера - высокое; среднее; низкое. Оценивает степень влияния на планы, результаты, ресурсы проекта. Используется при определении стратегии взаимодействия.

• Приоритет стейкхолдера - высокий; средний; низкий. Учитывает важность удовлетворения интересов для успеха проекта. Влияет на выбор методов управления отношениями. 

• Потребности в информировании и отчетности для каждого стейкхолдера. Определяет масштаб коммуникации с различными стейкхолдерами.

• Контактная информация - ФИО контактных лиц; адреса, телефоны, электронные адреса и т.д. Используется для сообщений и прочих взаимодействий.

• История взаимодействий с каждым стейкхолдером. Позволяет анализировать эффективность применяемых методов и стратегий управления отношениями.

• Дополнительные сведения - должность контактного лица; отношение к проекту; предыдущий опыт сотрудничества и т.п.

Реестр стейкхолдеров помогает:

• Идентифицировать всех лиц и организаций, чьи интересы затрагивает проект. 

• Определять их интересы, требования, влияние и приоритет.

• Разрабатывать эффективную стратегию взаимодействия с каждым стейкхолдером. 

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

В зависимости от содержания проекта, документы, описывающие требования к продукту, отличаются по степени детализации и уровню абстракции:

• Реестр требований (Requirements Registry) - это самый подробный документ. Каждое требование описывается с высокой детализацией, включая идентификатор, документы реализации, результаты тестирования и т.д. Реестр требований поддерживает управление требованиями на протяжении всего жизненного цикла разработки.

• Матрица требований (Requirements Matrix) - это более детализированный документ. Он включает списки требований, приоритеты, статус выполнения и другую информацию. Матрица позволяет систематизировать и отслеживать требования на протяжении всего проекта. 

• Сводное требование (Statement of Requirements) - это самый высокоуровневый документ. Он содержит описание требований на высоком уровне абстракции, без детализации. Цель - представить общее видение и направление разработки. 

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

* * *

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