От рамок проекта к экспресс-планированию

Требования в управлении проектом

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

Такая постановка вопроса вполне логична и обоснована, это подтвердит любой Разработчик. Однако, она вызывает много вопросов, например:

• Где найти Заказчика, который согласится ждать 2-3 месяца, пока Разработчик составит для него коммерческое предложение?
• Кто оплатит работы по анализу требований? (очевидно, Заказчик)
• Как быть, если цена вопроса окажется непомерной и от проекта придется отказаться - кто возместит Заказчику убытки на проведение исследований?

Разумный Заказчик сможет найти выход из этого непростого положения, например:

• подыскав Разработчика, обладающего богатым опытом выполнения подобных проектов, который сможет дать требуемую оценку значительно быстрее (но риск ошибки при этом остается);
• взяв на себя риски возможного прекращения проекта на ранних стадиях, в случае, если выявится его несоответствие бюджетным ограничениям (в сложных рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета, чем все 100%, как это было в "каскадных" схемах разработки) - путь прогнозирующих методологий
• разделив с Разработчиком ответственность за конечный продукт, приготовившись день за днем работать с ним рука об руку вплоть до появления результата - путь гибких (agile) методологий.

Начальную, самую грубую оценку проекта можно сделать на основании документа "Видение". Так, шаблон Vision/Scope MSF содержит список ключевых характеристик/функций, критерии приемлемости и (что очень важно) перечень характеристик/функций, которые лежат "вне рамок" проекта. Параллельно с проработкой концепции, первая фаза MSF содержит работы по анализу рисков: выявляются и оцениваются главные риски проекта.

Чтобы сделать первое приближение плана и сметы проекта на ранних этапах анализа, в [15.1] предлагается следующий подход:

• Выделить 25 - 99 функций, характеризующих систему (совместно, Заказчик и Разработчик);
• Установить приоритеты для каждой из функций (Заказчик);
• Оценить трудозатраты (Разработчик);
• Оценить риски (Разработчик, возможно привлечение Заказчика);

Все оценки делаются по 3-балльной шкале (высокий, низкий, средний; критический, важный, полезный и т.п.) и сводятся в таблицу:

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

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