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

Управление изменениями

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

Контроль статуса требований

В автоматизированных средствах управления проектами, например MS Project, для контроля степени выполнения той или иной работы используется понятие степени выполнения (progress), выражаемой в процентах. Данный способ слабо применим в программистских разработках, где, в силу их слабой формализованности, трудно оценить работу в процентах. При управлении требованиями рекомендуется оперировать не процентом, а статусом. К.Вигерс предлагает следующий шаблон для определения статуса требования:

Таблица 13.1.
Состояние	Определение
Proposed (Предложено)	Требование запрошено авторизированным источником
Approved (Одобрено)	Требование проанализировано, его влияние на проект просчитано, и оно было размещено в базовой версии определенной версии. Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики ПО обязались реализовать его
Implemented (Реализовано)	Код, реализующий требование, разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода
Verified (Проверено)	Корректное функционирование реализованного требования подтверждено в соответствующем продукте. Требование отслежено до соответствующих вариантов тестирования. Теперь требование считается завершенным
Deleted (Удалено)	Утвержденное требование удалено из базовой версии. Опишите причины удаления и назовите того, кто принял это решение
Rejected (Отклонено)	Требование предложено, но не запланировано для реализации ни в одной будущих версий. Опишите причины отклонения требования и назовите того, кто принял это решение

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

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

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

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

• 80% проектов по разработке систем управления информацией;
• 70% проектов по разработке военных систем ПО;
• 45% проектов по созданию ПО, выполняемых по контракту.

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

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

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

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

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

Дата добавления: 2014-11-29