Сбор требований к проекту и определение его содержания
Значительная часть управления проектом связана с исключением неопределенности и неясности. Для этого, в первую очередь, и нужно определить содержание проекта.
Однако определение содержания проекта может оказаться трудным процессом (например, часто заказчик понимает, что ему что-то нужно, но не уверен, что именно, или не может четко объяснить свои потребности; кроме того, различные участники могут иметь взаимоисключающие желания).
Для несложных, типовых проектов содержание можно определить быстро, и оно может оставаться неизменным на протяжении всего жизненного цикла проекта.
Для проектов с высоким уровнем уникальности процесс определения содержания может превратиться и для заказчика, и для менеджера проекта в процесс «открытий», в результате которого представление участников о проекте может сильно отклониться от первоначального представления. Последующая реализация проекта также может превратиться в процесс новых открытий, требующих внесения изменений в содержание проекта по мере его развития.
Определение содержания проекта должно быть достаточно детализированным, чтобы начать разрабатывать план проекта и переходить к его реализации.
По мере реализации проекта уровень детализации содержания может возрастать (эта поэтапная детализация содержания по мере развития проекта называется последовательной разработкой).
Изменение содержания проекта осуществляется через процесс управления изменениями.
Сбор и анализ требований заказчика и других ключевых заинтересованных сторон проекта должны осуществляться в ходе инициации и начальных этапов планирования проекта.
На основе требований определяется содержание проекта. Однако и по мере реализации проекта требования могут уточняться и даже изменяться, что приводит к необходимости внесения изменений в содержание проекта, а в отдельных случаях – к повторному выполнению процедур определения содержания проекта.
К сбору и анализу требований следует подойти аккуратно (т.е. необходимо планировать и контролировать этот процесс).
Специалист в области технических коммуникаций и информационных технологий Карл Вигерс следующим образом охарактеризовал процесс сбора требований:
«Сбор требований не похож на приятную прогулку по цветущему лугу, на котором вы собираете симпатичный букетик полевых цветов. Сбор требований больше похож на работу в шахте, где вы добываете руду, чтобы потом из нее выплавить немного металла. Но если вы не можете собрать правильные требования, то становится совершенно неважным то, насколько хорош ваш процесс разработки».
Если на этапе сбора и анализа требований заказчика и ключевых участников допущены ошибки, то все последующие шаги планирования и реализации проекта могут оказаться бессмысленными.
Потребность представляет собой общее описание ожиданий участников проекта.
А требование – это точное определение параметров результата, которые заказчик намерен получить.
При этом некоторые проекты могут содержать сотни страниц требований, а для других проектов требования состоят из нескольких строчек.
Для сложных технических проектов сбор требований не относится к обязанностям менеджера проекта, это роль бизнес-аналитика. В зависимости от типа проекта, бизнес-аналитики могут использовать специальные методы определения и описания требований, включая вопросники, средства моделирования и визуализации.
Важно понимать разницу между требованиями и решением.
Требование определяет потребности заказчика, а не то, как они будут реализованы.
Например, требование может быть следующим: «Я должен держать продукты в холоде», а решение может быть таким: «Мне нужен холодильник». Утверждение «Мне нужен холодильник» не является требованием.
Требования могут относиться к различным характеристикам результатов проекта.
Это могут быть функциональные требования, описывающие те возможности, которые должны быть получены в результате проекта, или требования к надежности и другим параметрам, характеризующим качество результатов.
Процесс сбора требований включает следующие этапы.
1) определение участников и заинтересованных сторон;
2) выявление требований;
3) обзор и структуризация требований (включая определение индивидуальных и общих требований);
4) анализ и ранжирование требований;
5) формирование документов и спецификаций требований;
6) согласование и утверждение требований:
— участники проекта подписываются под тем, что эти требования являются правильным отражением их потребностей;
— менеджер и/или куратор проекта подписываются под тем, что требования, которые должны быть выполнены в результате реализации проекта, согласованы.
Трудная часть сбора требований – определение того, что их собрано достаточно. Участники могут приходить с дополнительными требованиями на протяжении долгого периода времени. В какой-то момент сбор требований должен быть остановлен, чтобы можно было продолжать реализацию проекта.
Менеджер проекта должен решить, достаточно ли собрано требований. Для этого надо задать вопрос: «Если вы реализуете все эти требования, получите ли вы результаты, соответствующие поставленным целям?»
Проекты должны быть практичными и реализуемыми. Во время сбора требований часто собирают их больше, чем может быть выполнено за определенное время и выделенные деньги.
Некоторые требования в этом случае необходимо исключить. Это можно сделать с помощью ранжирования (чем в большей степени требование способствует достижению целей проекта, тем выше его приоритетность; требования, не имеющие отношения к достижению целей проекта, должны быть исключены).
Шаги по сокращению списка требований:
1) свяжите требования снова с первоначальными целями. Если требование не способствует достижению цели, оно должно быть исключено;
2) распределите требования по категориям:
— «должно быть включено» – если эти требования не будут включены, не будет достигнута цель;
— «желательно включить» – если эти требования не будут включены, цели не будут реализованы в полном объеме;
— «хорошо бы включить» – это полезные требования, но они не способствуют достижению первоначальных целей;
— «нужно отклонить» – это требования, которые не соответствуют первоначальным целям.
3) приведите список требований в соответствие с возможностями:
— удалите требования категории «нужно отклонить»;
— удалите столько требований категории «хорошо бы включить», сколько необходимо для того, чтобы проект принял разумный масштаб; сконцентрируйтесь на удалении самых сложных, дорогих и рискованных требований;
— если необходимо, удалите некоторые требования категории «желательно включить»;
— иногда для сокращения числа требований необходимо создать несколько версий плана в зависимости оттого, какие требования включаются.
4) если вы считаете, что необходимо удалить некоторые требования категории «должно быть включено», следует вернуться и просмотреть цели со спонсором проекта до того, как двигаться дальше.
5) создайте спецификацию требований, которая будет служить основой для контроля изменений;
6) решите, что вы хотите делать с требованиями, которые были отклонены; их необходимо сохранить для будущих обзоров как нереализованные потребности.
Существуют различные способы определения требований:
1) интервьюирование и ответы на структурированные вопросы;
2) «мозговые штурмы» и другие групповые сессии;
3) демонстрация примеров и прототипов («Если результат будет выглядеть подобным образом, удовлетворит ли это ваши потребности?»).
Необходимо убедиться в том, что требования являются конкретными (т.к. непонятные требования не могут быть реализованы).
Правильно сформулированные требования должны быть:
1) соответствующими целям проекта;
2) понятными и четкими;
4) хорошо структурированными;
5) позволяющими отследить их источник;
6) тестируемыми (проверяемыми на то, что они выполняются).
Требования документируются и служат основой для документа, определяющего содержание проекта.
Для небольших проектов это может быть достаточно короткий документ, описывающий результаты и содержание проекта в общем виде.
Для технически сложных проектов это может быть комплект документов, включая техническое задание, описание и спецификацию конфигурации продукта проекта, и т.п.
Техническое задание на разработку программного обеспечения должно содержать следующие разделы:
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) согласование процедуры тестирования решения для обеспечения соответствия требованиям после его разработки.
Проектировщики решений участвуют в реализации требований (они могут помочь участникам выявить новые требования и исключить невозможные или нецелесообразные требования). Заинтересованные стороны, в свою очередь, могут привлекаться к проектированию (в случае наличия необходимых компетенций), что гарантирует реализацию их потребностей.
По результатам проектирования уточняется содержание проекта.
При определении содержания проекта может быть полезным также явно указывать не только работы и результаты проекта, но и те результаты, которые не являются продуктом проекта, а также работы, которые должны быть выполнены вне проекта.
Это позволяет более четко определить ответственность менеджера проекта и избежать неверных предположений заказчика относительно содержания проекта.
Источник
Способы определения требований проекта
Не только те разработчики, кто уже год-два работает с крупными проектами с миллионными бюджетами, но и самые обычные средние студии всё чаще сталкиваются с заказами, проектами, которые подразумевают сотни тысяч, а то и миллионы хитов в день. Как правило, это современные интернет-магазины с очень большой номенклатурой товаров (например, магазин с 500 000 карточек товаров и 3 млн SKU) . Но могут быть и информационные и корпоративные проекты. Всё это надо как-то уметь проектировать, обслуживать, как-то с этим работать.
Создание проекта веб-студией надо рассматривать с двух сторон: с позиции менеджера и с технической. Игнорирование любой из них с высокой долей вероятности ведёт к провалу заказа. На практике, особенно в небольшой студии, развести эти моменты бывает достаточно сложно, так как, например, ведущий программист выступает, как правило, ещё и менеджером проекта. В нашем курсе обе этих стороны будут постоянно пересекаться, но мы постараемся выделять и отделять организационные моменты от технических.
Проблемы перед веб-студиями возникают как только они получают заказ на проект чуть более сложный, чем обычно. Немного более сложный, немного более большой, немного более высоконагруженный. (В рамках Bitrix Framework это означает, что как только запросы клиента выходят за пределы административной части, инфоблоков с контентом, то начинаются сложности.) В этом курсе мы постараемся дать простые методики как выжить в данном случае.
Надо понимать, что сложный проект и высоконагруженный проект — это немного разные вещи. Возможен высоконагруженный проект на штатном функционале CMS. В этом случае требуется, главным образом, настройка серверов. И возможен сложный проект, где требуется большая работа по написанию кода в дополнение к имеющемуся, но проект не подразумевает большого числа посетителей.
В первом случае полезна будет, в первую очередь, глава про эксплуатацию, во втором — глава про разработку.
Цель курса — помочь веб-студиям в организации работ, разработки и эксплуатации проектов. Этот курс — не столько теоретический, сколько практический, он построен на опыте разработки больших и малых, высоконагруженных и простых проектов.
Курс рассматривает вопросы создания высоконагруженных и сложных проектов без привязки к нашим продуктам. Примеры на базе платформы Bitrix Framework, приведённые в курсе, даны как один из вариантов реализации. Всё, что говорится на страницах ниже, можно применить и при работе с другими системами.
На каждой странице курса авторизованный на сайте посетитель может дать комментарий к содержимому страницы. Комментарий — не форум, там не ведётся обсуждений или разъяснений. Это инструмент для сообщений нам об ошибках, неточностях. Для отправки комментария воспользуйтесь расположенной в правом нижнем углу окна браузера кнопкой: 
Баллы опыта
В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:
уроке.
Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат — это если общее число набранных Вами баллов отличается от максимального на 1-2%.
Если нет интернета
Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла — от 02.11.2021.
Источник
