Стоимость разработки программного обеспечения на заказ: часть I

Размер проекта

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

Это и есть группа факторов под кодовым названием «размера проекта».

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

Для наглядности, приведем самый простой пример. Давайте сравним следующие два приложения:

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

Являются ли эти два проекта одинаковыми с точки зрения объема работ, которые разработчику нужно выполнить в раках реализации проекта? Можно ли их оценить одинаковым количеством человеко-часов? Конечно, нет! Следовательно, данный пример наглядно показывает, что количество пользовательских историй формирует размер проекта.

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

Сложность проекта

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

Поясним этот момент на нескольких условных примерах.

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

Следовательно, первое приложение может иметь достаточно простой и лаконичный дизайн, в то время как второе должно быть интересным и привлекательным, поэтому для его создания требуется больше усилий.

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

Подводя итог, сложность проекта представляет собой агрегированный фактор, который имеет дело со следующими составляющими:

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

Неопределенность проекта

Как правило, данный фактор имеет наибольшую актуальности при работе по фиксированному контракту.

Чем детальнее спецификация, которую предоставляет заказчик, тем меньше неопределенности у исполнителя. (Хотя, даже самое детальное не может гарантировать полное отсутствие непредвиденных трудностей на пути к развертыванию заданной информационной системы).

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

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

Выводы

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