Измерение трудозатрат, необходимых для управления требованиями

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

Основные трудозатраты по управлению требованиями [13.1]:

• предложение изменения требований и новых требований;

• оценка предложенных изменений, включая оценку влияния изменения;

• изменение работы;

• обновление документации требований или базы данных;

• сообщение об изменениях требований заинтересованным группам и отдельным лицам;

• контроль и отчет о состоянии требования;

• сбор информации о трассируемости требований.

Управление изменениями Управление незапланированным ростом объема

Незапланированный рост объема ставит под удар¹⁾:

• 80% проектов по разработке систем управления информацией;

• 70% проектов по разработке военных систем ПО;

• 45% проектов по созданию ПО, выполняемых по контракту.

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

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

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

Другая стратегия - это умение сказать: "Нет" . Психология большинства людей устроена так, что им тяжело отказывать, что в данном случае может привести к состоянию постоянного прессинга. К.Вигерс предлагает "смягчить" этот подход, заменив "Нет", на "Не сейчас" (требование обязательно будет выполнено, но не в текущей версии). Автор лекционного курса, соответственно, хотел бы добавить в эту копилку фразу "Зачем?". Опыт показывает, что данная фраза значительно упрощает общение и позволяет сподвигнуть представителя Заказчика на размышления: а действительно ли его идея хороша, а какую конкретную пользу она принесет бизнесу его предприятия?

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

Процесс контроля изменений

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

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

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

После регистрации запроса на изменение необходимо принять решение о его дальнейшей судьбе. Совет по управлению изменениями (change control board, CCB) (иногда его называют советом по управлению конфигурацией) был признан лучшим практическим решением при разработке ПО . На практике функции Совета могут быть делегированы и одному человеку (в зависимости от размеров проекта).

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

• а) из степени важности запроса для Заказчика и

• б) из его стоимости для Разработчика. Стоимость определяется на основании анализа влияния изменения.