Значительная часть управления проектом связана с исключением неопределенности и неясности. Для этого, в первую очередь, и нужно определить содержание проекта.
Однако определение содержания проекта может оказаться трудным процессом (например, часто заказчик понимает, что ему что-то нужно, но не уверен, что именно, или не может четко объяснить свои потребности; кроме того, различные участники могут иметь взаимоисключающие желания).
Для несложных, типовых проектов содержание можно определить быстро, и оно может оставаться неизменным на протяжении всего жизненного цикла проекта.
Для проектов с высоким уровнем уникальности процесс определения содержания может превратиться и для заказчика, и для менеджера проекта в процесс «открытий», в результате которого представление участников о проекте может сильно отклониться от первоначального представления. Последующая реализация проекта также может превратиться в процесс новых открытий, требующих внесения изменений в содержание проекта по мере его развития.
Определение содержания проекта должно быть достаточно детализированным, чтобы начать разрабатывать план проекта и переходить к его реализации.
По мере реализации проекта уровень детализации содержания может возрастать (эта поэтапная детализация содержания по мере развития проекта называется последовательной разработкой).
Изменение содержания проекта осуществляется через процесс управления изменениями.
Сбор и анализ требований заказчика и других ключевых заинтересованных сторон проекта должны осуществляться в ходе инициации и начальных этапов планирования проекта.
На основе требований определяется содержание проекта. Однако и по мере реализации проекта требования могут уточняться и даже изменяться, что приводит к необходимости внесения изменений в содержание проекта, а в отдельных случаях – к повторному выполнению процедур определения содержания проекта.
К сбору и анализу требований следует подойти аккуратно (т.е. необходимо планировать и контролировать этот процесс).
Специалист в области технических коммуникаций и информационных технологий Карл Вигерс следующим образом охарактеризовал процесс сбора требований:
«Сбор требований не похож на приятную прогулку по цветущему лугу, на котором вы собираете симпатичный букетик полевых цветов. Сбор требований больше похож на работу в шахте, где вы добываете руду, чтобы потом из нее выплавить немного металла... Но если вы не можете собрать правильные требования, то становится совершенно неважным то, насколько хорош ваш процесс разработки».
Если на этапе сбора и анализа требований заказчика и ключевых участников допущены ошибки, то все последующие шаги планирования и реализации проекта могут оказаться бессмысленными.
Потребность представляет собой общее описание ожиданий участников проекта.
А требование – это точное определение параметров результата, которые заказчик намерен получить.
При этом некоторые проекты могут содержать сотни страниц требований, а для других проектов требования состоят из нескольких строчек.
Для сложных технических проектов сбор требований не относится к обязанностям менеджера проекта, это роль бизнес-аналитика. В зависимости от типа проекта, бизнес-аналитики могут использовать специальные методы определения и описания требований, включая вопросники, средства моделирования и визуализации.
Важно понимать разницу между требованиями и решением.
Требование определяет потребности заказчика, а не то, как они будут реализованы.
Например, требование может быть следующим: «Я должен держать продукты в холоде», а решение может быть таким: «Мне нужен холодильник». Утверждение «Мне нужен холодильник» не является требованием.
Требования могут относиться к различным характеристикам результатов проекта.
Это могут быть функциональные требования, описывающие те возможности, которые должны быть получены в результате проекта, или требования к надежности и другим параметрам, характеризующим качество результатов.
Процесс сбора требований включает следующие этапы.
1) определение участников и заинтересованных сторон;
2) выявление требований;
3) обзор и структуризация требований (включая определение индивидуальных и общих требований);
4) анализ и ранжирование требований;
5) формирование документов и спецификаций требований;
6) согласование и утверждение требований:
- участники проекта подписываются под тем, что эти требования являются правильным отражением их потребностей;
- менеджер и/или куратор проекта подписываются под тем, что требования, которые должны быть выполнены в результате реализации проекта, согласованы.
Трудная часть сбора требований – определение того, что их собрано достаточно. Участники могут приходить с дополнительными требованиями на протяжении долгого периода времени. В какой-то момент сбор требований должен быть остановлен, чтобы можно было продолжать реализацию проекта.
Менеджер проекта должен решить, достаточно ли собрано требований. Для этого надо задать вопрос: «Если вы реализуете все эти требования, получите ли вы результаты, соответствующие поставленным целям?»
Проекты должны быть практичными и реализуемыми. Во время сбора требований часто собирают их больше, чем может быть выполнено за определенное время и выделенные деньги.
Некоторые требования в этом случае необходимо исключить. Это можно сделать с помощью ранжирования (чем в большей степени требование способствует достижению целей проекта, тем выше его приоритетность; требования, не имеющие отношения к достижению целей проекта, должны быть исключены).
Шаги по сокращению списка требований:
1) свяжите требования снова с первоначальными целями. Если требование не способствует достижению цели, оно должно быть исключено;
2) распределите требования по категориям:
- «должно быть включено» – если эти требования не будут включены, не будет достигнута цель;
- «желательно включить» – если эти требования не будут включены, цели не будут реализованы в полном объеме;
- «хорошо бы включить» – это полезные требования, но они не способствуют достижению первоначальных целей;
- «нужно отклонить» – это требования, которые не соответствуют первоначальным целям.
3) приведите список требований в соответствие с возможностями:
- удалите требования категории «нужно отклонить»;
- удалите столько требований категории «хорошо бы включить», сколько необходимо для того, чтобы проект принял разумный масштаб; сконцентрируйтесь на удалении самых сложных, дорогих и рискованных требований;
- если необходимо, удалите некоторые требования категории «желательно включить»;
- иногда для сокращения числа требований необходимо создать несколько версий плана в зависимости оттого, какие требования включаются.
4) если вы считаете, что необходимо удалить некоторые требования категории «должно быть включено», следует вернуться и просмотреть цели со спонсором проекта до того, как двигаться дальше.
5) создайте спецификацию требований, которая будет служить основой для контроля изменений;
6) решите, что вы хотите делать с требованиями, которые были отклонены; их необходимо сохранить для будущих обзоров как нереализованные потребности.
Существуют различные способы определения требований:
1) интервьюирование и ответы на структурированные вопросы;
2) «мозговые штурмы» и другие групповые сессии;
3) демонстрация примеров и прототипов («Если результат будет выглядеть подобным образом, удовлетворит ли это ваши потребности?»).
Необходимо убедиться в том, что требования являются конкретными (т.к. непонятные требования не могут быть реализованы).
Правильно сформулированные требования должны быть:
1) соответствующими целям проекта;
2) понятными и четкими;
3) значимыми;
4) хорошо структурированными;
5) позволяющими отследить их источник;
6) тестируемыми (проверяемыми на то, что они выполняются).
Требования документируются и служат основой для документа, определяющего содержание проекта.
Для небольших проектов это может быть достаточно короткий документ, описывающий результаты и содержание проекта в общем виде.
Для технически сложных проектов это может быть комплект документов, включая техническое задание, описание и спецификацию конфигурации продукта проекта, и т.п.
Например,
Техническое задание на разработку программного обеспечения должно содержать следующие разделы:
1) Введение;
2) Основания для разработки;
3) Назначение разработки;
4) Требования к программе или программному изделию;
5) Требования к программной документации;
6) Технико-экономические показатели;
7) Стадии и этапы разработки;
8) Порядок контроля и приемки;
9) Приложения (их допускается включать при необходимости).
Раздел « 4) Требования к программе или программному изделию» должен содержать следующие подразделы:
4.1) Требования к функциональным характеристикам;
4.2) Требования к надежности;
4.3) Условия эксплуатации;
4.4) Требования к составу и параметрам технических средств;
4.5) Требования к информационной и программной совместимости;
4.6) Требования к маркировке и упаковке;
4.7) Требования к транспортированию и хранению;
4.8) Специальные требования.
На определенном этапе происходит переход от требований к проектированию (разработке проектной документации).
Требование – это понимание потребности, а проектирование – это описание того решения, которое позволит удовлетворить данную потребность.
Процесс и терминология проектирования зависят от типа проекта (например, проектирование на строительном проекте будет отличаться от проектирования на проекте разработки IT-системы).
На самом простом уровне переход от требований к проектированию происходит следующим образом.
1) преобразование требований участников в технические определения.
Требования обычно формулируются на обычном, неспециальном языке. Для того чтобы требования превратились в программное обеспечение, специалисты (например, разработчики IT-систем), должны иметь требования, написанные на техническом языке.
2) разработка решения (на основании технических определений).
Для этого создают собственные оригинальные решения и готовят обзор существующих решений – соответствуют ли они требованиям, и можно ли их быстро изменить таким образом, чтобы они соответствовали требованиям. Это, серьезно влияет на план проекта.
3) обзор хода проектирования с заказчиком (чтобы убедиться в том, что процесс соответствует его потребностям).
Это не обязательный шаг, поскольку в некоторых ситуациях участники могут не иметь достаточно компетенций для того, чтобы сделать подобный обзор.
4) согласование процедуры тестирования решения для обеспечения соответствия требованиям после его разработки.
Проектировщики решений участвуют в реализации требований (они могут помочь участникам выявить новые требования и исключить невозможные или нецелесообразные требования). Заинтересованные стороны, в свою очередь, могут привлекаться к проектированию (в случае наличия необходимых компетенций), что гарантирует реализацию их потребностей.
По результатам проектирования уточняется содержание проекта.
При определении содержания проекта может быть полезным также явно указывать не только работы и результаты проекта, но и те результаты, которые не являются продуктом проекта, а также работы, которые должны быть выполнены вне проекта.
Это позволяет более четко определить ответственность менеджера проекта и избежать неверных предположений заказчика относительно содержания проекта.