Сбор бизнес требований это

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

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

В чем суть услуги?

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

Мастер-класс по сбору и анализу требований

Как идет работа?

Внутрикорпоративное исследование

Интервью с ключевыми сотрудниками компании для выявления основных свойств продукта:

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

Пользовательское исследование

Состоит из 3 этапов:

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

Описание групп пользователей

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

Техника интервьюрирования в бизнес-анализе

Представление заказчику результатов работы

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

Запросить пример полного отчета

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

Точное соответствие целям и потребностям клиентов

Снижение затрат на дизайн

Минимизация последующих доработок продукта

успешных кейсов

лет опыта проектирования интерактивных продуктов

успеха во всех проектах

Особенности нашей методики

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

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

Артём Кузнецов

Директор компании Ю-эксперт

Информация из первых рук

Мы получаем информацию непосредственно от ваших клиентов.

Глубокое понимание клиента

Интервью позволяют находить ответы на вопросы “Для чего?”, “Как?”, “Что важно?” и другие, чего нельзя сделать при анализе статистики.

Ценные инсайты

Технология сбора требований в процессе проектирования сайта

2012-04-13 в 9:05, admin , рубрики: waterfall model, Веб-разработка, водопад, пользовательские сценарии, работа с заказчиком, техзадание, техническое задание, управление проектами, Учебный процесс в IT, метки: waterfall model, водопад, пользовательские сценарии, работа с заказчиком, техзадание, техническое задание

Вступление

Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall). Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.

Классификация требований

В нашей компании принята следующая терминология в отношении требований:

1. Бизнес-требования
   Требования самого высокого уровня, которые определяют цель создания сайта и задачи, которые необходимо выполнить для достижения цели. Бизнес-требования определяются следующей метафорой: «Сайт как инструмент бизнеса, как его часть. Сайт – как лицо компании, как инструмент продаж и развития бизнеса».
2. Требования участников проекта
   Требования, которые определяют, как представители компании-заказчика будут взаимодействовать с сайтом, что им нужно от сайта. Метафора: «Сайт как неотъемлемая часть бизнес-процессов в компании. Сайт как помощник сотрудникам».
3. Требования внешних пользователей
   Требования, которые определяют, как внешние пользователи будут взаимодействовать с сайтом, и что им может потребоваться как посетителям ресурса и потенциальным клиентам компании. Метафора: «Сайт как инструмент продаж товаров и услуг компании через Интернет».

Бизнес-процесс по созданию клиентского сайта

Базовый бизнес-процесс по созданию клиентского сайта в нашей компании выглядит следующим образом:

1. После получения заявки на разработку сайта, менеджер связывается с клиентом, уточняет его ценовые ожидания и, если они соответствуют нашим, договаривается о встрече.
2. Перед встречей менеджер подготавливается к сбору бизнес-требований: читает информацию о компании заказчика, анализирует действующий сайт (если он существует), анализирует сайты конкурентов; создает примерное представление о том, какой сайт можно предложить клиенту.
3. Далее следует очная встреча с клиентом, на которой менеджер занимается сбором бизнес-требований и требований участников проекта. На данном этапе главная задача менеджера состоит в том, чтобы максимально подробно расспросить клиента о бизнес-процессах внутри компании, понять их суть, чтобы затем предложить такой функционал на сайте, который бы позволил увеличить эффективность работы сотрудников компании клиента.
4. После очной встречи с клиентом менеджер осуществляет оценку собранных требований на полноту и непротиворечивость.
5. Оценка сделана, и менеджер трансформирует требования в описание примерного функционала сайта как совокупности ряда модулей: «Каталог товаров», «Корзина», «Форум» и т. д.
6. Функционал будущего сайта согласовывается с клиентом как по содержанию, так и по стоимости. Возможны варианты, когда клиент выбирает для реализации лишь часть функционала.
7. Если предварительное соглашение о функционале будущего сайта достигнуто, то менеджер приступает к описанию целевых групп посетителей и описанию сценариев использования сайта посетителями. Данное описание также согласовывается с клиентом.
8. На основании согласованных сценариев использования сайта и функциональных модулей менеджер формирует техническое задание, в которое разработчик добавляет техническую информацию (требования к хостингу , например).
9. Техническое задание подписывается двумя сторонами, прикладывается к договору, договор оплачивается, и начинается работа.

Схематично бизнес-процесс выглядит следующим образом:

Теперь более подробно рассмотрим, как осуществляет сбор требований на всех этапах работы.

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

При сборе бизнес-требований определяется окружение сайта (см. рисунок) и анализируется, как данное окружение может использовать сайт и соответственно, какой функционал и информация должны быть представлены на сайте.
Например, бизнес заказчика крупный и постоянно привлекаются инвесторы для финансирования проектов. Соответственно, должен быть раздел на сайте с информацией о проектах компании, о формате возможного участия инвесторов и т.п.
Случай из жизни. В ходе сбора бизнес-требований для сайта клиники красоты мы задумались, а что может быть нужно органам власти от сайта. Ответ не заставил себя долго ждать – необходимым оказалось размещение на сайте лицензий на оказываемые услуги.
Заметим, что требования сотрудников компании к сайту – это требования участников проекта, они будут рассмотрены в отдельной главе.

При проектировании с учетом бизнес-требований:

• Заказчик начинает фокусироваться на важных вопросах, касающихся целей и задач сайта, а не на том, «что на сайте будет в левом меню». Повышается мотивация и желание сделать хороший продукт.
• Большинство важных требований, которые не лежат на поверхности, выявляются в ходе последовательного прохода по внешнему окружению будущего сайта. Например: «…да, партнерам было бы хорошо предоставить личный кабинет…», «…далее сайт будет продвигаться и seo-специалистам необходимо следующее…», «…компания крупная и нужен хороший раздел с вакансиями…» и т.д.

Требования участников проекта

1. Сайт может помогать менеджеру при непосредственном общении с клиентом – например, менеджер с экрана компьютера демонстрирует клиенту продукцию или услуги компании.
2. Менеджер «конструирует» что-то на сайте, например, выбирает для клиента тур в Турцию или рассчитывает стоимость полиса ОСАГО. Частный пример – «конструктор кухонь» на сайте компании Ikea.
3. Менеджер часто выезжает на встречу с клиентом на местах и с планшетного компьютера демонстрирует продукцию, представленную на сайте – (для себя мы сразу делаем пометку, что будет важна мобильная версия сайта и интерфейс работы с устройствами с сенсорным экраном).
4. Сайт служит для сопровождения клиентов в процессе продажи товара и после. Это такие действия как: всевозможные консультации, отслеживание статуса заявки на покупку товара, обмен файлами, техническая поддержка.
5. Во многих случаях менеджеру приходится давать подробные консультации клиентам, и в этом случае на помощь может прийти сайт, где в специальном разделе можно будет разместить справочную информацию. Частный случай: раздел FAQ, где можно посмотреть ответы на основные вопросы и задать свой.

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

Варианты потенциальных требований со стороны участников могут быть такими:

1. Требования директора по персоналу:
   a. «Управление вакансиями на сайте сделать по аналогии с сайтом SuperJob».
   b. «Создать внутрикорпоративный портал и базу знаний».
   c. «Создать личные странички сотрудников».
   d. «Создать возможность проведения вебинаров для сотрудников через сайт».
2. Требования директора по рекламе, маркетолога:
   a. «Создать удобное управление баннерной системой – как для показа своих баннеров, так и чужих».
   b. «Сделать возможность выгрузки данных о товарах и услугах».
   c. «Создать функционал проведения опросов через сайт».
   d. «Создать возможность комментирования и обсуждения товара на сайте».
   e. «Организовать кросспостинг материала в социальные сети».
   f. «Создать рейтинги товаров».
3. Требования администратора сайта:
   a. «Создать возможность одновременной работы нескольких человек в административном разделе».
   b. «Создать функционал автоматического архивирования сайта».
   c. «Создать возможность разграничения прав доступа для редакторов сайта».
4. Пиар-менеджер:
   a. «Необходимо использовать фирменный стиль в дизайне, подчеркивать бренд».
   b. «Создать функционал «рассылки», «форум», разместить виджеты социальных сетей».
   c. «Создать определённые промо-страницы, промо-блоки, аудио-видео, flash».
5. Бизнес-аналитик:
   «Осуществить специальную настройку процесса формирования и отправки заказа, чтобы появилась возможность оценивать конверсию посетителей в покупателей».
6. Юрист:
   «Создать раздел для публикации документов, требующих публичного оглашения».
7. Представитель службы логистики:
   «Создать раздел с подробными картами складов».

Определение целевых групп посетителей и сценарии использования

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

1. Покупатели
   a. Первичные.
   b. Вторичные.
   c. Не определившиеся.
   d. Постоянные.
2. Соискатели работы.
3. СМИ.
4. Партнеры.
5. Инвесторы.

1. Для покупателей:
   a. Для первичных: покупка товара, ознакомление с ценами, сравнение товара, получений консультаций.
   b. Для вторичных: повторный заказ товара, получение скидки.
   c. Для не определившихся: поиск товара, участие в акциях, связь с компанией.
   d. Для постоянных: покупка одних и тех же товаров, использование скидок, техподдержка.
2. Соискатели работы: поиск вакансий, отправка резюме.
3. СМИ: импорт новостей, импорт графической информации.
4. Партнеры: авторизация на сайте, загрузка прайс-листа, чат с персональным менеджером.
5. Инвесторы: информация об акциях компании, графики котировок.

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

Техническое задание

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

Техническое задание состоит из следующих блоков:

1. Подробные сценарии использования со стороны заказчика (как представители заказчика взаимодействует с сайтом, например, как менеджер обслуживает через сайт заявки, как менеджер по персоналу публикует вакансии и прочее).
2. Описание структуры элементов и набор полей в административной части сайта.
3. Структура сайта и навигация по нему (разделы сайта, порядок расположения элементов на типовых страницах).
4. Сценарии использования основного функционала (как пользователь может отправить заявку, что получит в ответ, как пользователь использует поиск по сайту и прочее).
5. Описание функционала основных модулей
6. Компоновка элементов, дизайн (описываются все требования к дизайну)
7. Описание работы отдельных сервисов (например, использование калькулятора ОСАГО)

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

1. Представитель клиента озвучил следующее требование: «Хочу удобную систему публикации и представления вакансий на сайте, чтобы было удобно создавать новые вакансии, доставать из архива и активировать старые».
2. После беседы с клиентом помимо прочего менеджер выделил функционал «Вакансии», который учел при оценке общей стоимости создания сайта.
3. Далее менеджер определил целевые группы: «Соискатели работы» — со стороны посетителей сайта и «HR-менеджер» со стороны участников проекта.
4. В итоговом техническом задании изначальное требование приобрело следующий вид:
   a. В административном разделе сайта имеется возможность создавать новые вакансии на основе шаблонов, содержащих следующий набор полей: должность/требования/обязанности/зарплата/…
   b. Администратор сайта имеет возможность изменить базовый шаблон или создать новый. Соответственно при публикации вакансии имеется возможность выбрать соответствующий шаблон из имеющихся и создать на его основе вакансию.
   c. Раздел «Вакансии» расположен в основном разделе «О компании».
   d. Список вакансий на странице «Вакансии» имеет табличный вид. Используются поля: «Должность», «Зарплата».
   e. При переходе на конкретную вакансию пользователь видит следующее (см. эскиз дизайна).
   f. На странице конкретной вакансии пользователь может отправить резюме, которое придет на определенный электронный адрес, а также сохранится в базе данных.
   g. Форма отправки резюме имеет следующий вид…

Заключение

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

Источник: www.pvsm.ru

Что такое процесс сбора требований? (с примерами)

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

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

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

Подумайте о том, чтобы начать процесс сбора требований в начале проекта, чтобы обеспечить эффективное планирование и управление. Вот некоторые аспекты, которые следует учитывать при начале сбора требований:

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

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

Кто использует процесс сбора требований?

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

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

• Интервью и анкеты
• Наблюдения за пользователями и истории
• Прототипирование и ролевая игра
• Сценарии и варианты использования

Преимущества сбора требований

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

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

Советы по эффективному сбору требований

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

Заранее ставьте цели

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

Документируйте обсуждения и подчеркивайте прозрачность

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

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

Говорите с реальными пользователями

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

Практикуйте активное слушание

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

Сосредоточьтесь на характеристиках продукта

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

Оставайтесь адаптируемыми

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

Примеры сбора требований

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

Пример 1

North-West Management встречается со своими заинтересованными сторонами, в которую входит команда из пяти поставщиков, двух пользователей и четырех ИТ-специалистов. Боб, руководитель проекта, проводит собеседования с поставщиками и предоставляет ИТ-персоналу анкеты для заполнения. Затем он проводит наблюдение за пользователями продукта и спрашивает их отзывы об их опыте. На основе этих взаимодействий Боб и другие члены его проектной группы составляют список требований, которые они собирают из интервью, анкет и отзывов. После составления этого списка он организует встречу со своими заинтересованными сторонами, чтобы сохранить прозрачность в отношении пунктов, которые его команда включила в объем проекта.

Пример 2

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

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

Источник: buom.ru