? Сбор требований: краткое руководство

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

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

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

Сбор требований — процесс определения и получения требований к проекту. Существует два основных их типа: бизнес-требования и технические требования.

Бизнес-требования определяют, ЧЕГО компания планирует достичь с помощью проекта, а технические требования объясняют, КАК проект должен быть выполнен. Они собираются на этапе создания проекта, но проджект-менеджеры должны отслеживать их на протяжении всего срока реализации, поскольку требования со временем могут меняться.

Сбор требований начинается в самом начале работы над проектом и он должен ответить на следующие вопросы:

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

Что такое технические требования

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

Почему сбор требований так важен

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

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

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

Итак, как собрать требования наиболее эффективным и управляемым способом? Как правило, процесс состоит из нескольких основных этапов.

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

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

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

Опрос стейкхолдеров

Далее необходимо опросить всех стейкхолдеров, которых вы определили. Задайте им вопросы:

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

Документирование

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

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

Создание списка требований

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

На этом этапе вы ответите на вопросы:

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

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

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

Какова конечная цель в понимании требований проекта? Какова цель по времени, цель по бюджету и цель по объему? Будет ли это более жесткая конкуренция на рынке с конкурентом? Будет ли это решение проблемы клиента? Или просто исправление ошибок?

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

Отслеживайте прогресс

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

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

Методы сбора требований

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

Пользовательские варианты использования продукта (use-cases)

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

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

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

Составление ментальных карт

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

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

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

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

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

***

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас