Как получить требования к проекту от заинтересованных сторон

Введение

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

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

Designmodo

Истории пользователей

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

Мозговой штурм

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

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

PM Alliance

Обзор сессий

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

Что включать в еженедельный отчет о состоянии проекта

Диаграмма процесса

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

Продолжайте спрашивать, почему

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