Краткие теоретические и учебно-методические материалы по теме

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

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

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

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

1. Разработчик представляет Заказчику согласованный план работ c детализацией с точностью до конкретных исполнителей.

2. Разработчик осуществляет ежедневные сборки, регрессионное тестирование компонентов разрабатываемого продукта и тестирование продукта в целом.

3. Все управленческие и проектные действия передаются в режиме online с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий.

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

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

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

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

Осуществимость (выполнимость) является в некоторой степени конкурирующим по введенным выше двум свойствам.

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

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

Выполнимость требования на практике определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами. Так, если стоимость контракта на разработку информационной системы составляет $10000, а затраты на выполнение нового требования, возникшее в момент, когда проект выполнен наполовину, оценивается в $4000, является ли оно невыполнимым? Скорее всего, да, если Исполнитель докажет Заказчику новизну требования (требование не входило в согласованные спецификации) и сложность его исполнения. Но, если требование является критически важным, необходимым, но выпало из поля зрения при подписании контракта Заказчик готов выделить дополнительно финансирование, а Исполнитель - трудовые ресурсы - значит, требование выполнимо.

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

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

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

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

1. Какие требования к продукту предъявляет заказчик?

2. Как заказчик может осуществлять контроль над проектом на расстоянии?

3. Кто такие стейтхолдеры?

Задания для практического занятия:

1. Назначьте стейтхолдеров для проекта проведения занятий дополнительного образования (ДОУ) и заполните в таблицу, аналогичную приложению Т.

2. Проведите такой же анализ для произвольного проекта. Тему проекта продумайте с преподавателем.