Основы методов оценки стоимости ИТ проектов. Введение.

В современных российских (и не только) ИТ компаниях, занимающихся как аутсорсингом, так и разработкой собственных проектов для внутреннего рынка и для внешних (зарубежных) заказчиков, кроме проблем относительно самих процессов разработки и проблем поиска заказчиков, существуют проблемы, которые находятся, условно говоря, между этими двумя. Со стороны компании необходимо произвести то, что требует заказчик в установленные сроки, с заданной функциональностью, а так же уложиться в бюджет. Со стороны заказчика, в свою очередь, требуется установить сроки разработки (которые как правило стремятся к нулю), определить список требований к функциональности (которые стремятся к бесконечности), а так же выделить на все это бюджет (который опять же стремится к нулю). Все эти три измерения напрямую влияют на вероятность успеха продукта при выходе его на рынок, а так же потенциальной прибыли заказчика. Еще эта модель более известна как железный треугольник (iron triangle, project management triangle).

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

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

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

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

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

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

Эта задача не так проста, как кому то может показаться на первый взгляд. В связи с этим были разработаны некоторые методики оценки приложений в различных показателях. Большинство появились на свет в США в 70-е – 80-е годы, когда развитие отрасли пошло бурными темпами, в связи с чем возрастала хаотичность в процессе деятельности по разработке. Были разработаны различные методики по управлению проектами, организации процесса разработки, управлению командой и много всего другого, в том числе и методы оценки продуктов.

Так какие же есть методы оценки?

• PERT – Project Evaluation and Review Technique — способ анализа задач, необходимых для выполнения проекта. В особенности, анализа времени, которое требуется для выполнения каждой отдельной задачи, а также определение минимального необходимого времени для выполнения всего проекта. Была разработана в 1958 году консалтинговой фирмой «Буз, Ален и Гамильтон» совместно с корпорацией «Локхид» по заказу Подразделения специальных проектов ВМС США в составе Министерства Обороны США для проекта создания ракетной системы «Поларис» (Polaris). (C)
• Анализ функциональных точек – стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом в середине 70-х. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group – IFPUG). (С)
• COCOMO и COCOMO II.
• другие (стоит ли о них писать?)

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