В шапке
Управление изменениями требований к продуктам проекта

Управление изменениями требований к продуктам проекта

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

После выполнения первого проекта в роли руководителя мне стало понятно, что план – это идеальная модель для неидеального мира и не стоит надеяться, что все пойдет, как задумано. Без плана трудно обойтись, но надо быть готовым к тому, что его придется менять по ходу проекта. В управлении проектами даже есть понятия «базового» плана и «текущего» плана.

Базовый план утверждается у заказчика проекта, а текущий – это тот план, с которым работает руководитель проекта и его команда.

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

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

Приведу определение термина «требование», которым я буду оперировать в статье, опираясь на два уважаемых источника:

Требование – потребность или ожидание, которое установлено, обычно предполагается или является обязательным (ГОСТ ISO 9000-2011)

Требование - условие или характеристика, которому должен соответствовать или которую должен иметь продукт, услуга или результат в соответствии с договором или другой формально предписанной спецификацией. (PMBOK V)

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

Я буду оперировать следующими определениями:

Потребность – это мотиватор для совершения действий по достижению некоторой итоговой ценности.

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

Требования – это потребности и технические характеристики продукта.

Отмечу, что требования имеют свою классификацию, которую я приводить в статье не буду.

Если нам удастся адекватно определить потребности, то через технические характеристики будущего продукта мы сможем выйти на список работ, которые нужно реализовать, чтобы получить продукт с нужными характеристиками. Список работ проекта, по сути, формирует то, что в PMBOK называется содержанием проекта (в англоязычной литературе используется термин scope).

Знаменитый проектный треугольник (треугольник тройного ограничения) учит нас тому, что изменение одной из сторон треугольника повлечет за собой изменения других сторон. То есть если у вас изменяется содержание проекта – пересмотрите сроки или бюджет проекта. Если у вас изменяются сроки проекта – пересмотрите содержание или бюджет и т.д.

При работе с треугольником мы должны понимать, какие его стороны (ограничения) являются зафиксированными, а какие изменяемыми.

В практике управления проектами чаще всего встречаются два случая:

В первом случае содержание проекта зафиксировано, а стоимость и срок являются изменяемыми (waterfall). А во втором - зафиксированы бюджет и срок, а содержание проекта является изменяемым (на картинке это случай для Agile):

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

Рассмотрим, как осуществляется управление изменениями для обоих вариантов.

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

Для ранжирования требований на важные и не очень можно использовать несколько подходов. На мой взгляд, одним из самых проработанных подходов является Quality Function Deployment (QFD). Этот подход был разработан в Японии в 60-е годы, однако на русском языке пока издано всего несколько книг. Одной из причин его возникновения, как пишет С.Хромов-Борисов в книге «Управление сложностью», стали следующие ключевые проблемы:

-при разработке новых продуктов не учитывается, что ни потребитель, ни производитель четко не разделяют потребности (вопрос «что») и способы их удовлетворения (вопрос «как»),

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

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

Один из самых известных инструментов в QFD – так называемый «дом качества», который показан на рисунке:

Дом качества состоит из восьми полей, в которые вносится следующая информация:

поле 1 — список потребностей;

поле 2 — веса (рейтинги) потребностей;

поле 3 — список технических характеристик продукта, удовлетворяющих потребности;

поле 4 — реляционная матрица;

поле 5 — веса (рейтинги) технических характеристик;

поле 6 — таблица потребительского бенчмаркинга;

поле 7 — таблица технического бенчмаркинга;

поле 8 — корреляционная матрица для технических характеристик.

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

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

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

Однако использование QFD требует от команды проекта серьезной подготовки, пройти которую в СНГ практически негде. Возможно, этот факт, наряду с достаточно сложным инструментарием QFD, и сдерживает его применение.

Рассмотрим вариант проекта, в котором требования являются фиксированными, а срок и бюджет проекта – изменяемыми.

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

Для работы с изменениями вводится специальный документ «Запрос на изменение» и алгоритм принятия решения, который выглядит примерно так:

Как мы видим из рисунка, для того чтобы принять решение о внесении изменения, руководитель проекта проделывает достаточно много действий (на шагах 4 и 5 привлекаются заказчик проекта и, возможно, даже специальный Комитет по управлению изменениями). Естественно, на обработку каждого запроса на изменение тратится много времени и сил. Но если этого не делать, то рамки проекта расползутся, а его сроки и бюджет, скорее всего, увеличатся.

Подведем итоги.

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

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

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

Если у вас есть какие-то мысли по поводу описанного в статье, готов обсуждать их.

Комментарии (2)
Макс Якубович2014-10-08 11:05:28
Александр, откуда такая уверенность , что "водопад" в разработке ПО не используется? Есть результаты опроса, которым можно доверять?
Александр Крица2014-10-08 08:11:09
Что касается разработки ПО, то "Вдопадной модели" в чистом виде не существует. Вместо нее используется V-образная модель. Изменение требований в ней можно автоматизировать с помощью IBM Rational DOORS (бывш. Telelogic). Разработка по Ajile не применима к большим системам, т.к. основана на "пользовательских историях", которые служат основой для требований к ПО.
Войти как