Управление требованиями 101: ваше пошаговое руководство

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

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

Что такое управление требованиями?

Управление требованиями — это способ обеспечить соответствие окончательных ожидаемых результатов проекта потребностям клиентов и внутренних заинтересованных лиц. В данном случае требование — это то, что заинтересованным сторонам нужно или чего они хотят от вашего продукта. Заинтересованные стороны могут быть внутренними (например, межфункциональные партнёры) или внешними (например, клиенты или заказчики). 

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

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

Что такое требование? 

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

• Необходимыми: это требование нужно вам для достижения целей вашего бизнеса или продукта. 

• Конкретным: требование должно быть подробным и иметь чёткую цель. 

• Понятным: требование должно быть сформулировано чётко и легко для понимания. 

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

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

• Проверяемое: у вас должна быть возможность проверить требование с помощью пользовательского тестирования, A/B-тестирования или другого метода. 

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

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

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

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

• Оно точное, потому что вы чётко указали, почему это требование важно — потому что английский, китайский, японский и французский языки соответствуют основным рынкам вашей компании. 

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

• Оно поддается проверке, поскольку у вас есть система для тестирования и подтверждения точности каждой переведенной версии. 

Почему управление требованиями так важно? 

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

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

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

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

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

Кто отвечает за управление требованиями? 

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

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

Какие бывают типы требований? 

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

Ниже приведён обзор различных типов требований. 

Бизнес-требования

Бизнес-требования — это общие бизнес-цели или показатели, которым служит ваш продукт. Это не обязательно то, что должен делать продукт, а скорее то, что должна делать ваша компания, чтобы удовлетворить как внутренних, так и внешних заинтересованных сторон. 

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

Проект вашей команды по продукту отвечает следующему бизнес-требованию: увеличить ассортимент продукции на 50 % в первом квартале. Чтобы зафиксировать подобные требования в едином, упорядоченном формате, попробуйте использовать шаблон документа с описанием бизнес-требований.

Требования пользователей

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

Команды, работающие по методологии Agile, обычно оформляют требования пользователей в виде пользовательских историй, которые представляют собой неформальные описания функций программного обеспечения, написанные с точки зрения конечного пользователя. Пользовательские истории имеют следующий формат: «Как [персонаж], я хочу [цель программного обеспечения], чтобы [результат]». 

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

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

Системные требования

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

Системные требования часто делятся на функциональные и нефункциональные. Функциональные требования определяют, что будет делать продукт, а нефункциональные — насколько хорошо продукт выполняет свои функции. Это означает, что нефункциональные требования обычно связаны с безопасностью, производительностью и надёжностью. 

Например, вот как инженерная команда может разбить вышеупомянутое пользовательское требование к системе управления контентом на системные требования: 

Функциональные требования

• В каждой карточке продукта хранится следующая информация: тип продукта, дата создания, автор, URL-адрес и статус публикации.

• Новые продукты нельзя создавать, если авторы не выберут тип продукта в выпадающем меню. 

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

• Можно выбрать сразу несколько фильтров. 

Нефункциональные требования

• Результаты поиска отображаются менее чем за пять секунд. 

• Результаты поиска точны на 100%. 

Семь шагов в процессе управления требованиями

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

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

Шаг 1. Разработка плана управления требованиями

Начните проект с создания плана управления требованиями (ПУТ). Этот план — ваша дорожная карта для работы с требованиями на протяжении всего жизненного цикла проекта. В своём ПУТ определите следующее:

• Кто будет участвовать в сборе требований?

• Как вы будете собирать и документировать требования?

• Каков ваш процесс отслеживания изменений требований?

• Как вы будете обеспечивать успех проекта, согласовывая его с целями?

Хороший ПУТ помогает вашей проектной команде оставаться организованной и согласованной на протяжении всего цикла разработки.

Шаг 2. Выявление и определение требований

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

Выявление требований

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

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

• Управляйте ожиданиями: объясните, что не все запрошенные требования обязательно будут реализованы. Уточните, что это этап сбора информации.

Определение требований

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

• Сформулируйте чёткие и конкретные требования на основе собранной информации.

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

• Убедитесь, что каждое требование описывает одну конкретную потребность или функцию.

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

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

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

Шаг 3. Анализ и проверка требований

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

Проверка требований включает в себя следующее:

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

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

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

Шаг 4. Определение исходного уровня требований

После проверки требований установите исходные параметры. Документация на этом этапе представляет собой снимок всех одобренных требований и обеспечивает:

• Отправную точку для вашего решения по управлению требованиями

• Справочный материал для принятия решений в будущем и оценки изменений

Единого способа документирования и отслеживания требований не существует. Возможно, ваша команда по разработке продукта исторически использовала спецификацию требований к программному обеспечению (SRS), документ с требованиями к продукту (PRD) или матрицу прослеживаемости требований (RTM). 

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

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

Шаг 5. Расстановка приоритетов и определение зависимостей

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

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

• Связывание взаимосвязанных требований

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

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

Шаг 6. Менеджмент изменений, контроль версий и анализ влияния

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

По мере продвижения проекта требования могут меняться. Управляйте этими изменениями следующим образом:

1. Наладьте процесс подачи и рассмотрения запросов на изменения

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

3. Обновление базового плана, если изменения одобрены

Используйте карту зависимостей для проведения анализа влияния. Это поможет вам понять все последствия изменений, прежде чем принимать решение об их внедрении.

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

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

Шаг 7. Верификация и валидация системы

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

• Верификация: протестируйте каждую функцию, чтобы убедиться, что она работает в соответствии с требованиями.

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

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

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

Инструменты для оптимизации управления требованиями

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

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

Вопросы и ответы: управление требованиями

Что подразумевается под управлением требованиями? Управление требованиями — это процесс определения, отслеживания и контроля требований к проекту на протяжении всего жизненного цикла разработки. Оно обеспечивает понимание и согласование потребностей проекта всеми заинтересованными сторонами.

Что такое план управления требованиями? План управления требованиями определяет, как требования будут собираться, отслеживаться и контролироваться в ходе проекта. Он служит руководством по работе с изменениями, документацией и обменом информацией.

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

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