что относится к требованиям к результату проекта
Что нужно сделать до старта проекта? Требования к результатам проекта
Этой статьей я начинаю цикл материалов, посвященных тому, что надо сделать руководителю проекта до старта проекта, чтобы снизить неопределенность. На мой взгляд, самое важное – определить продукты (результаты) проекта и проработать требования к каждому из них. Чем более четко сформулированы требования, тем легче спрогнозировать сроки, бюджет и объемы проекта. Давайте обсудим процесс сбора и анализа требований к продуктам (результатам) проекта.
Для компании, которая платит за проект, создается некая ценность – в виде материальных или нематериальных результатов проекта.
В ходе своих рассуждений я воспользуюсь определением термина «результат проекта», которое дает Свод знаний по управлению проектами PMBOK V:
Поставляемый результат (Deliverable) – любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта.
В статье речь пойдет о сборе требований и их анализе к поставляемым результатам проекта, но я позволю себе заменить термин «поставляемый результат» на термин «результат проекта», сохранив при этом определение термина.
Итак, до старта проекта руководителю и заказчику нужно договориться о том, каких результатов заказчик ожидает от проекта. Иногда это не так просто, как кажется на первый взгляд. Попробуйте определить цель для проекта проведения корпоративного праздника, а затем сформулируйте результаты, которые помогут реализовать эту цель. Как вы с этим справились? Думаю, было нелегко.
Давайте рассмотрим ситуацию на примере проекта «Внедрение CRM-системы в компании». Заказчик сформулировал следующие цели:
И отсюда результаты проекта:
Для того чтобы удовлетворить ожидания заказчика, руководителю проекта необходимо уточнить требования к каждому результату проекта.
Что такое требование?
Существуют десятки определений этого термина.
Например, в ISO 9000 написано следующее: Требование – это потребность или ожидание, которое установлено, обычно предполагается или является обязательным.
В IEEE Standard Glossary of Software Engineering Terminology (1990) приведена такая трактовка: Требование – это условия или возможности, необходимые пользователю для решения проблем или достижения целей.
За основу возьмем определение из ISO 9000, при этом будем считать, что ожидание считается установленным, если оно записано в документе, который согласовал заказчик.
Классификация требований
Для некоторых продуктов уже разработаны классификаторы требований, которые позволяют снизить вероятность того, что некоторые важные требования к продукту могут быть упущены.
Например, существуют классификаторы требований к программному обеспечению. Один из них представлен на рисунке 1:
©Карл И. Вигерс «Разработка требований к программному обеспечению»
С точки зрения сбора требований к программному продукту такая классификация позволяет аналитику помнить о том, что кроме требований к функциям программного продукта необходимо уточнить требования к внешним интерфейсам, ограничения системы. Кроме того, данная классификация помогает понять, с чего начать сбор требований и как их уточнять (стрелки на диаграмме показывают последовательность сбора требований, но при этом аналитик может возвращаться к предыдущим этапам). В книге К. Вигерса даны определения каждой категории требований и примеры по ним, поэтому я не буду приводить их в статье.
Итак, при сборе требований к программному продукту аналитику требований уже есть чем руководствоваться – есть классификаторы требований и описания классов требований.
Рассмотрим, какие могут быть требования к регламенту, описывающему правила работы с клиентами компании. Как мне кажется, они могут быть такими:
Конечно, при наличии классификатора требований к документам типа «Регламент» аналитику было бы проще учесть все классы требований, но такого классификатора я пока не встречал.
Какие требования можно предъявить к такому результату, как обученные сотрудники?
Требования к работающему сервису поддержки программного продукта можно сформулировать так:
Сформулировав требования к результатам проекта, руководитель проекта может начинать планировать состав работ и прогнозировать объемы работ, сроки и бюджет проекта.
Мы должны понимать, что любое пропущенное требование к результату проекта приведет к дополнительным объемам работ, а это повлияет на сроки и бюджет проекта. Поэтому для руководителя проекта очень важно попытаться собрать максимально полные требования перед стартом проекта.
Какие есть подходы к сбору требований к результатам проекта?
Самые распространенные подходы к сбору требований представлены на рисунке ниже:
Методы расположены на шкале сложности (отмечу, что расположение подходов на этой шкале – это мое субъективное мнение).
Наблюдение используется для получения информации о том, как определенная заинтересованная сторона проекта исполняет свои обязанности или задачи. На мой взгляд, метод хорош для уточнения требований к уже имеющемуся продукту, когда люди, пользующиеся продуктом, не могут или не хотят изложить свои требования.
Анкеты – письменные наборы вопросов, разработанные с целью быстрого сбора информации у большого числа респондентов. Анкеты лучше всего подходят для ситуаций, когда ограничено время на сбор информации, когда респонденты территориально распределены или когда бюджет на сбор информации по требованиям сильно ограничен.
Анализ документов используется для выявления требований путем анализа существующей документации и идентификации информации, которая имеет отношение к требованиям. Существует множество документов, которые можно проанализировать для выявления требований.
Фокус-группы позволяют выбрать несколько представителей от каждой из заинтересованных сторон проекта и провести совместное обсуждение, чтобы узнать их ожидания к обсуждаемому продукту или результату проекта.
Мозговой штурм – подход, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к результатам проекта. Часто его используют вместе с другими подходами, которые предполагают приоритезацию собранных требований (например, метод номинальных групп, построение ассоциативных карт, диаграммы сходства и т. д.).
Инновационные игры – с помощью бизнес-игры модератор вовлекает заинтересованные стороны проекта в сбор требований к продукту и в ранжирование этих требований. Этот подход я уже описывал ранее в своей заметке: http://project-management.zis.by/uluchshenie-proektov/kak-povysit-tochnost-prognozirovanija-srokov-proekta.html
Прототипирование – способ сбора требований путем предоставления модели ожидаемого продукта. Модель будущего продукта может быть физической, графической или компьютерной, но она должна по максимуму продемонстрировать пользователям, каким будет будущий продукт. Через демонстрацию прототипа можно быстро получить обратную связь о том, насколько продукт удовлетворяет ожиданиям, и уточнить требования. Прототипы поддерживают концепцию последовательного уточнения требований в серии итераций, проведения экспериментов пользователем, формирования отзывов и пересмотра прототипа.
Моделирование процессов – метод используется для сбора требований к выполнению процесса (или некоторой деятельности). Используются графические модели, которые позволяют согласовать структуру действий в процессе, ответственных за выполнение отдельных действий, преобразования объектов деятельности. Для моделирования процессов при сборе информации часто используются интервью, анкеты, фокус-группы.
QFD (quality function deployment) — подход, который помогает определить критически важные характеристики для разработки нового продукта, отталкиваясь от требований будущих пользователей. В подходе используются матрицы, например, которые показывают связи между требованиями и техническими характеристиками продукта. Отмечу, что этот подход используется не только для сбора, но и для анализа требований.
После того как требования к результатам проекта собраны, их нужно проанализировать на предмет полноты, наличия противоречивых требований, наличия проблем с реализацией требований. Для решения этих задач аналитик требований может использовать такие инструменты, как реверсивный анализ требований, анализ систем-аналогов, ТРИЗ, Root Conflict Analysis Plus (RCA+), Value-Conflict Mapping +.
Как видно из списка подходов, аналитик требований должен знать и уметь достаточно многое для решения вопросов, связанных со сбором и анализом требований.
И в заключение я хочу привести простую мысль: если, будучи руководителем проекта, вы должны подписаться под проект с определенными сроками и бюджетом, но при этом ваша команда не понимает требований к результатам проекта или убеждена, что имеющиеся на входе проекта требования слишком абстрактны, ваш проект содержит слишком большую неопределенность. Как резко сократить неопределенность в таком проекте? Один из вариантов – вынести сбор и анализ требований к результатам проекта в отдельный проект, и только по его итогам определять сроки и бюджет проекта реализации. Да, не для всех проектов этот вариант подойдет, но его не стоит отбрасывать без дополнительного анализа.
Итак, подведем итоги размышлений:
Лично я в небольших проектах совмещаю роли руководителя проекта и аналитика требований. Но если проект сложный и бюджет проекта позволяет, я стараюсь привлекать к нему профессиональных аналитиков, чтобы снизить риски, связанные с неполными требованиями к результатам проекта.
Удачи вам при сборе и анализе требований в проектах!
Что относится к требованиям к результату проекта
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОЕКТОМ
Project management. Requirements for project management
Дата введения 2012-09-01
Предисловие
1 РАЗРАБОТАН Автономной некоммерческой организацией «Центр стандартизации управления проектами» (АНО «Центр стандартизации управления проектами»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»
6 ПЕРЕИЗДАНИЕ. Октябрь 2019 г.
Введение
Настоящий стандарт устанавливает требования к управлению проектом от его старта до завершения, при этом предметом стандартизации являются обязательные выходы процессов управления проектом.
Стандарт не содержит требований, которые могут считаться обязательными лишь для определенного вида проектов, требований к методам реализации процессов управления проектами, а также требований к предпроектной и послепроектной деятельности.
1 Область применения
Настоящий стандарт устанавливает требования к управлению проектом для обеспечения эффективного достижения целей проекта.
Требования настоящего стандарта распространяются на управление любыми проектами и могут быть применены для проектов, реализуемых юридическими или физическими лицами. Проекты могут осуществляться на договорной основе или быть реализованы внутри организации.
Настоящий стандарт может использоваться с целью оценки соответствия управления проектом установленным в стандарте требованиям.
2 Нормативные ссылки
В настоящем стандарте использована нормативная ссылка на следующий стандарт:
ГОСТ Р ИСО 9000 Системы менеджмента качества. Основные положения и словарь
3 Термины и определения
В настоящем стандарте применены термины в соответствии с ГОСТ Р ИСО 9000, а также следующие термины с соответствующими определениями:
3.1 архив проекта: Структурированный комплект документации проекта, представленный в бумажном и/или электронном виде.
3.2 базовый план проекта: Принятый к исполнению план проекта, содержащий сведения об основных временных и стоимостных параметрах проекта.
3.3 бюджет проекта: Документ, содержащий общую сумму финансовых средств, распределенных по статьям и временным периодам.
3.4 допущение: Фактор, который считается верным для проекта без привлечения доказательств.
3.5 заинтересованные стороны в проекте: Лица или организации, чьи интересы могут быть затронуты в ходе реализации проекта.
3.6 изменение в проекте: Модификация утвержденного ранее содержания, сроков, ресурсов в проекте, а также установленных процедур.
3.7 контрольное событие проекта: Существенное событие проекта, отражающее получение измеримых результатов проекта.
3.8 корректирующее действие: Действие, предпринятое для устранения обнаруженного несоответствия плану проекта.
3.9 ограничение: Сдерживающий фактор, влияющий на ход исполнения проекта.
3.10 предупреждающее действие: Действие, предпринятое для снижения вероятности или последствий отрицательных рисков проекта.
3.11 продукт проекта: Измеримый результат, который должен быть получен в ходе реализации проекта.
3.12 проект: Комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.
3.13 процесс: Совокупность взаимосвязанных действий, направленных на достижение определенных результатов.
3.14 работа проекта: Действие, выполняемое для достижения цели проекта.
3.15 расписание проекта (календарный план): Плановые даты исполнения работ и контрольных событий проекта.
3.16 риск: Вероятное для проекта событие, наступление которого может как отрицательно, так и положительно отразиться на результатах проекта.
3.17 управление проектом: Планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов проекта, направленные на эффективное достижение целей проекта.
4 Организация управления проектом
Ролевая (организационная) структура управления проектами может в значительной степени различаться в зависимости от их специфики, но в каждом проекте должны быть определены следующие роли:
Схема, иллюстрирующая основные понятия проектного менеджмента и их взаимосвязь, приведена в приложении А.
5 Управление проектом
5.1 Области управления и последовательность процессов управления проектами
Управление проектом включает совокупность процессов инициации, планирования, организации исполнения, контроля и завершения проекта.
В рамках процессов управления проектом выполняются действия, относящиеся к следующим функциональным областям управления проектом:
— управление содержанием проекта;
— управление сроками проекта;
— управление затратами в проекте;
— управление рисками проекта;
— управление персоналом проекта;
— управление заинтересованными сторонами проекта;
— управление поставками проекта;
— управление качеством в проекте;
— управление обменом информацией в проекте;
— управление интеграцией проекта.
Последовательность процессов управления проектом определяется условиями конкретного проекта, при этом:
— проект должен начинаться с процесса инициации проекта;
— проект должен оканчиваться процессом завершения проекта;
— выполнение процессов организации исполнения и контроля проекта начинается не раньше процессов планирования.
5.2 Процесс инициации проекта
Цель процесса: формальное открытие проекта.
Выходы процесса определяются и документируются следующими параметрами проекта:
— причины инициации проекта;
— цели и продукты проекта;
— дата инициации проекта;
5.3 Процессы планирования проекта
5.3.1 Процесс планирования содержания проекта
Цель процесса: определение требований проекта и состава работ проекта.
а) требования к проекту со стороны заказчика, других заинтересованных сторон проекта, а также законодательства и нормативных актов определены, проанализированы на предмет возможности их выполнения, согласованы с заказчиком проекта и документированы;
б) определены, согласованы с заказчиком и документированы ключевые данные по продукту проекта, а именно:
1) назначение, свойства и характеристики продукта;
2) критерии и методы приемки продукта проекта и его составных частей;
3) допущения и исключения, касающиеся продукта проекта;
4) определены, согласованы с заказчиком и документированы работы проекта, а также допущения и исключения, касающиеся работ проекта.
Этапы оценки проекта: понятия, методы и полезные инструменты
Оценка помогает команде определить вектор развития проекта и вовремя его скорректировать. Однако для многих менеджеров оценка — сложный и пугающий процесс, из-за чего она часто упрощается или игнорируется вовсе.
Вместе с Андреем Кокшаровым, продюсером направления «Высшее образование» в Нетологии, разобрались, зачем проводить оценку проекта, из каких этапов она состоит и какие инструменты помогут в этом.
Статья будет полезна участникам проектных команд и начинающим предпринимателям.
Продюсер направления «Высшее образование» в Нетологии
Проект — это временное предприятие, которое направлено на создание уникального продукта или услуги. Проекты могут иметь различные формы и реализовываться в любой сфере и отрасли. Например, проектами можно считать:
Также к проектам относят стартапы — молодые компании без опыта операционной или проектной деятельности, работающие над идеей с высокой долей риска и неопределённости.
Любой проект начинается с идеи, а заканчивается, когда:
Оценка проекта как раз помогает избежать рисков не уложиться в бюджет или сроки проекта, потерять в качестве продукта или разработать фичи, которые никому не нужны.
Расскажу, зачем командам проводить оценку проекта и какие методы при этом используют.
Что такое оценка проекта и зачем её проводят
Оценка проекта — это способ выяснить, насколько вероятно выполнить задачу в нужные сроки, качественно и в пределах бюджета.
Оценка позволяет понять реальный статус проекта.
Она не призвана наказать отстающих, иначе участники будут приукрашать результаты или прятать неудобные данные и оценка станет необъективной и бесполезной.
Получить реальные данные для принятия решений возможно только, если оценка будет достоверной и актуальной. Чтобы в процессе оценки не возникало искажений, руководителю важно позволить участникам проектных команд высказывать опасения и предположения по ходу проекта.
Например, в некоторых компаниях используют анонимные ящики, которые устанавливают в общедоступных местах, чтобы любой участник команды мог положить туда записанные на листке бумаги сомнения и опасения. С определённой периодичностью менеджер проекта проверяет ящик и узнаёт о проблеме, о которой по какой-то причине подчинённые не говорят лично.
Оценку проекта можно разделить на оценку идеи проекта и оценку самого проекта. Данные блоки в свою очередь состоят из процессов, связанных с оценкой бюджета, сроков, качества и прочих компонентов в зависимости от уровня сложности проекта.
Оценка идеи проекта происходит на этапе, когда формируется бизнес-план и создаётся концепт продукта. Она позволяет руководителю обосновать решение о запуске проекта и его необходимости для бизнеса. В оценке идеи обычно участвуют аналитик, команда маркетинга, менеджер будущего проекта. По её результатам принимают решение об инициации проекта, подписывают устав проекта и набирают команду.
Оценка же самого проекта может происходить на всех этапах, начиная от планирования до этапа завершения. Её задача — скорректировать ход проекта. После проведения оценки проекта обычно вносят изменения в документацию, может измениться состав команды или перечень фичей продукта, либо вовсе решают закрыть проект. Если команда решила продолжать, то после этого оценивают потребности в дополнительных ресурсах.
Менеджер определяет, что важно рассмотреть в ходе оценки проекта. Он же решает, какие процессы нужно оценить и формирует список критериев для оценки каждого из них. В крупных компаниях — особенно тех, которые работают на зарубежном рынке, — инициирует оценку обычно отдельный специалист или команда специалистов отдела контроллинга, которые следят за ходом проекта. В перечень могут входить, например, такие процессы, как:
Состав оцениваемых процессов определяет менеджер на этапе инициации проекта. Чаще всего это называется процессом адаптации системы управления проектом к новому проекту — важно настроить его под среду и процессы внутри компании. Во время адаптации менеджер проекта тесно взаимодействует с командой проекта, с владельцем продукта и ключевыми стейкхолдерами. Адаптация помогает определить контролируемые точки в проекте, грамотно распределить ресурсы и разработать базовый план проекта.
Процесс адаптации — важный этап в работе над любым проектом, так как из-за уникальности разрабатываемого продукта каждый новый проект требует свой набор инструментов, компонентов и контрольных точек.
Менеджер проекта разрабатывает план управления выгодами проекта. И в процессе адаптации ему необходимо синхронизировать между собой основные бизнес-документы проекта — понять, нет ли расхождения между ними и бизнес-кейсом, который изначально представлялся руководству.
К основным бизнес-документам относят:
Прежде чем сформулировать бизнес-кейс, нужно провести оценку потребностей рынка. В неё будет входить первичная оценка бизнес-идеи, оценка бизнес-задач, потенциальных проблем и возможностей проекта.
Что нужно сделать до старта проекта. Часть 2
Наш эксперт Максим Якубович рассказывает, что необходимо сделать до начала проекта, чтобы его шансы на успех выросли. Сегодня речь о том, как получить четкие требования к ожидаемым результатам проекта.
– В Части 1 речь шла о влиянии допущений на планирование проекта. Анализ допущений помогает руководителю сформулировать риски проекта и снизить неопределенность.
Но еще большая неопределенность в проекте порождается нечеткими требованиями к его результатам. Изучим вопрос сбора и анализа требований к продуктам (результатам) проекта.
В проекте создается некоторая ценность для компании, которая платит за проект. Ценность эта может выражаться в виде материальных или нематериальных результатов.
До старта проекта руководителю и заказчику нужно договориться о том, какие результаты ожидает от проекта заказчик.
Сформулировать результаты проекта иногда не так просто как кажется. Попробуйте сформулировать цель для проекта проведения корпоративного праздника, а после этого для реализации целей сформулируйте результаты проекта. Не думаю, что у вас это получится легко сделать.
Давайте вернемся к кейсу, который был описан в Части 1 – проект внедрения CRM-системы. В этом проекте заказчик определил следующие результаты:
1. Регламент, описывающий работу сотрудников с клиентами.
2. Программный продукт, автоматизирующий правила работы с клиентами, описанные в Регламенте.
3. Обученные работе с программным продуктом сотрудники компании.
4. Работающий сервис поддержки пользователей программного продукта.
Чтобы удовлетворить ожидания заказчика от проекта, руководителю проекта необходимо уточнить требования к каждому результату проекта.
Что такое требование?
Существуют десятки определений термина «требование».
Например, в ISO 9000 этот термин определяют как: потребность или ожидание, которое установлено, обычно предполагается или является обязательным.
За основу возьмем это определение, и будем считать, что ожидание считается установленным, если оно записано в документе, который согласовал заказчик.
Классификация требований
Для некоторых продуктов уже разработаны классификаторы. Они позволяют снизить вероятность того, что некоторые важные требования к продукту могут быть упущены.
Например, существуют классификаторы требований к программному обеспечению. Один из них представлен на рисунке:
Источник: Карл И. Вигерс «Разработка требований к программному обеспечению»
С точки зрения сбора требований к программному продукту, такая классификация позволяет аналитику помнить что, кроме требований к функциям, которые должен выполнять программный продукт, нужно еще уточнить требования к внешним интерфейсам, ограничениям системы.
Эта классификация помогает также понять, с чего начать сбор требований и как их уточнять (стрелки на диаграмме показывают последовательность сбора требований, но при этом аналитик может возвращаться к предыдущим этапам). В книге Карла Вигерса «Разработка требований к программному обеспечению» даны определения каждой категории требований и примеры, поэтому я не буду приводить их в статье.
Итак, при сборе требований к программному продукту аналитику требований уже есть чем руководствоваться – есть классификаторы требований и описания классов требований.
Рассмотрим, какие могут быть требования к регламенту, описывающему правила работы с клиентами компании. Как мне кажется, они могут быть такими:
1. Регламент процесса должен содержать описание процесса в нотации … (здесь нужно уточнить название нотации).
2. Регламент должен содержать матрицу ответственности с перечислением функций каждого участника процесса (к матрице ответственности тоже можно предъявить требования).
3. Документ не должен превышать определенное количество слов (это является ограничением).
4. Документ должен быть написан определенным шрифтом (можно указать его название и кегль).
5. В документе обязательно должны быть следующие разделы (к каждому можно предъявить требования по содержанию).
6. Документ должен содержать раздел, описывающий внесенные изменения в документ.
Какие требования можно предъявить к такому результату, как обученные сотрудники?
1. Сотрудники должны пройти обучение работе с программным продуктом.
2. Для обучения сотрудников должна быть разработана программа обучения (могут быть требования к содержанию программы).
3. Обучение должно проходить на реальных примерах компании. Примеры для обучения должны быть утверждены заказчиком проекта.
4. По итогам обучения проходит тестирование знаний сотрудников. Средний балл по итогам тестирования на знание программного продукта составляет не менее ___ баллов (по 10-бальной шкале).
5. Требования к методике тестирования знаний сотрудников следующие…
Требования к работающему сервису поддержки программного продукта можно сгруппировать по следующим темам:
1. Стоимость сервиса поддержки в месяц.
2. Время предоставления сервиса (например, с 8.00 до 20.00 по GMT+2).
3. Время реагирования на обращение в службу (к примеру, 30 минут с момента регистрации обращения в службу поддержки).
4. Время на решение проблемы, описанной в обращении пользователя (здесь нужно вводить классификацию обращений и по каждому из них определять норматив на закрытие обращения или на перевод его в другой статус).
5. Время на восстановление сервиса в случае сбоя.
6. Возможность для пользователей отследить статус своего обращения.
7. Возможность получить отчет по обращениям за определенный период.
Сформулировав требования к результатам проекта, руководитель проекта может начинать планировать состав работ по проекту и прогнозировать объемы работ, сроки и бюджет проекта.
Мы должны понимать, что любое пропущенное требование к результату проекта приведет к дополнительным объемам работ, а это повлияет на сроки и бюджет проекта. Поэтому для руководителя проекта очень важно попытаться собрать максимально полные требования перед стартом.
Какие есть подходы к сбору требований к результатам проекта?
Самые распространенные – представлены на рисунке ниже:
Методы расположены на шкале сложности, чем сложнее метод (по моему субъективному мнению) – тем правее на шкале он находится.
Наблюдение используется для получения информации о том, как определенная заинтересованная сторона проекта исполняет свои обязанности или задачи. На мой взгляд, метод хорош для уточнения требований к уже имеющемуся продукту, когда люди, пользующиеся им, не могут или не хотят изложить свои требования.
Анкеты – письменные наборы вопросов, разработанные с целью быстрого сбора информации у большого числа респондентов. Анкеты лучше всего подходят для ситуаций, когда ограничено время на сбор информации, когда респонденты территориально распределены или когда бюджет на сбор информации по требованиям сильно ограничен.
Анализ документов. Существует множество документов, которые можно проанализировать для выявления требований.
Интервью. В ходе интервью заинтересованным сторонам задают подготовленные и непосредственно возникающие вопросы и записывают ответы. Тот, кто проводит интервью, получает возможность считывать дополнительную информацию по мимике и жестам собеседника и задавать уточняющие вопросы, что невозможно при проведении анкетирования.
Фокус-группы позволяют выбрать несколько представителей от каждой из заинтересованных сторон проекта и провести совместное обсуждение, чтобы узнать их ожидания по обсуждаемому продукту или результату проекта.
Мозговой штурм. Часто его используют с другими подходами, которые предполагают приоритезацию собранных требований (например, метод номинальных групп, построение ассоциативных карт, диаграммы сходства и т.д.).
Инновационные игры – с помощью бизнес-игры модератор вовлекает заинтересованные стороны проекта в сбор требований к продукту и в ранжирование этих требований.
Прототипирование – способ сбора требований путем предоставления модели ожидаемого продукта. Модель будущего продукта может быть физической, графической или компьютерной, но она должна по максимуму продемонстрировать пользователям каким будет будущий продукт. Демонстрируя прототип, можно получить быструю обратную связь о том, насколько продукт удовлетворяет ожиданиям, и уточнить требования.
Моделирование процессов – метод используется для сбора требований к выполнению процесса (или некоторой деятельности). Используются графические модели, которые позволяют согласовать структуру действий в процессе, ответственных за выполнение отдельных действий, преобразования объектов деятельности. Для моделирования процессов при сборе информации часто используются интервью, анкеты, фокус-группы.
QFD (quality function deployment) — подход, который помогает определить критически важные характеристики для разработки нового продукта, отталкиваясь от требований будущих пользователей. В подходе используются матрицы. Например, матрица, которая показывает связи между требованиями и техническими характеристиками продукта. Отмечу, что этот подход используется не только для сбора, но и для анализа требований.
После того, как требования к результатам проекта собраны, их нужно проанализировать:
Для решения этих задач аналитик требований может использовать такие инструменты как реверсивный анализ требований, анализ систем-аналогов, ТРИЗ, Root Conflict Analysis Plus (RCA+), Value-Conflict Mapping+.
Как видно из списка подходов по сбору и анализу требований, аналитик требований должен знать и уметь достаточно многое.
Напоследок я хочу привести простую мысль: если будучи руководителем проекта, вы должны подписаться под проект с определенными сроками и бюджетом, но при этом ваша команда не понимает требований к результатам проекта или убеждена, что имеющиеся на входе проекта требования слишком абстрактны – ваш проект содержит слишком большую неопределенность.
Как резко сократить неопределенность в таком проекте? Один из вариантов – вынести сбор и анализ требований к результатам проекта в отдельный проект и только по его итогам определять сроки и бюджет проекта реализации. Да, не для всех проектов этот вариант подойдет, но его не стоит отбрасывать.
Подведем итоги:
1. Успех проекта закладывается на старте путем уточнения целей проекта, результатов проекта, требований к результатам.
2. Сбор требований к результатам позволяет команде проекта понять, чего ожидают заинтересованные стороны. На основании собранных и проанализированных требований команда может разрабатывать технические решения по реализации требований, определять список работ по проекту, прогнозировать трудозатраты. Чем полнее требования к результатам проекта, тем точнее может сделать прогноз по трудоемкости проекта, срокам и бюджету руководитель проекта.
3. Собранные требования к результатам проекта нужно проанализировать на предмет их полноты, наличия противоречивых требований, наличия проблем с реализацией.
4. В проекте, в котором требуется сбор или уточнение собранных требований, нужно планировать использование аналитика, который должен владеть различными подходами к сбору и анализу требований.
Из личного опыта: в небольших проектах совмещаю роли руководителя и аналитика требований. Но если проект сложный и бюджет проекта позволяет, я стараюсь привлекать к нему профессиональных аналитиков, чтобы снизить риски, связанные с неполными требованиями к результатам проекта.
Удачи вам при сборе и анализе требований в проектах!
Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».
Опыт работы в сфере управления проектами – более 10 лет.
20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.
Опыт преподавания – 8 лет. Около 2000 студентов, прошедших обучение на его семинарах.
Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий блога по управлению проектами.