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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Business-требования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Напишите чёткие и конкретные требования на основе собранной информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Связывание соответствующих требований.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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