Сколько стоит разработка программного обеспечения? В целом, стоимость проекта здесь зависит от двух основных групп факторов: объем работ, необходимый для получения требуемого решения и рейт компании-разработчика.
Независимо от того, будет ли договор на условиях почасовой оплаты или же с фиксированной ценой, эти факторы работают всегда.
В этой статье мы поговорим о первой группе факторов стоимости проекта по разработке ПО. В следующей статье мы коснемся ставок компаний и объясним, почему они различаются у разных компаний.
Итак, факторы, обуславливающие объем работ, включают в себя:
Размер проекта
Размер проекта можно рассматривать как функционал информационной системы, т.е. количество функций, которыми она должна обладать. Пожалуй, это самый простой для понимания и оценки фактор.
Здесь функция – это опция, которую пользователь может использовать, чтобы решить конкретную задачу. Например, функционал CRM-системы может включать:
- Функцию ведения переговоров и/или переписки
- Функцию настройки уведомлений
- Функцию авторизации и аутентификации с разграничением прав доступа
- Функцию интеграции с внешними источниками
- Функцию загрузки и хранения файлов
- Функцию мониторинга действий пользователей
- Функцию взаимодействия с пользователями и т. д.
Чем больше функций должна содержать система, тем больше времени уходит на ее разработку.
В этом контексте можно вспомнить старую добрую поговорку: «время – деньги». Таким образом, становится очевидным, что чем выше должна быть функциональность приложения, разработку которого Вы планируете заказать, тем выше будет стоимость проекта.
Однако эта корреляция, являясь прямо пропорциональной, не является линейной, так как дополняется еще одним фактором, который также оказывает огромное влияние на стоимость разработки программного обеспечения — фактором сложности проекта.
Сложность проекта
Сложность проекта определяет, сколько усилий требуется для создания каждой функции, и насколько высоким должен быть уровень квалификации разработчиков для выполнения этой задачи.
Например, на создание одной функции может уйти всего несколько человеко-часов, а на разработку другой инженерам нужно потратить несколько десятков человеко-часов. Более того, одна функция может быть распространенной и простой в реализации, а другая требует глубоких знаний в области архитектуры и высокоуровневых навыков для ее реализации.
Ниже перечислены основные составляющие, определяющие сложность проекта:
- Особенности дизайна и особенностей фронтенда в целом – например, достаточно ли реализации стандартных элементов или необходимо создание аутентичных элементов и организация их взаимодействия
- Особенности бизнес-логики приложения – например, сколько в ней слоев (добавление каждого слоя усложняет бизнес-логику)
- Необходимый стек технологий – например, какие и сколько языков программирования необходимо интегрировать при создании или, чаще всего, доработки ПО
Необходимость использования разных технологий и их интеграции в одном решении требует дополнительных знаний и больше времени на выполнение поставленных задач
- Необходимость миграции данных и ее сложность
- Платформы развертывания – например, какие операционные системы должно поддерживать разрабатываемое решение (iOS и/или Android для мобильных приложений, Mac OS Unix, Linux или Windows для настольных приложений – каждый из них имеют свои особенности при развертывании)
- Сложность самих функций приложения – например, создание функции прямого доступа к приложению по трудоемкости существенно отличается от создания push-уведомлений в режиме реального времениОсобенности безопасности системы – например, нужно ли реализовывать многоуровневый доступ, необходимость обеспечения защиты приложения и обеспечение безопасности и сохранности данныхИ т.д.
Очевидно, что сложность проекта находит выражение в его трудоемкости. Что, в свою очередь, прямо пропорционально влияет на стоимость разработки требуемой информационной системы.
Риски по проекту
Под рисками здесь понимается вероятность возникновения непредвиденных затруднений при разработке требуемого приложения в рамках поставленных задач. В особенности этот фактор актуален при работе по контракту с фиксированной ценой.
Самый яркий пример – логику семиуровневой архитектуры сложно реализовать на практике, хотя на бумаге она может быть идеальной. Самый распространенный пример – банальное отсутствие четкой спецификации, в результате чего есть риск недопонимания всех особенностей проекта изначально.
Ну и, конечно, же, риски неидеального развития событий по проекту всегда есть в тех случаях, когда разработчику приходится сталкиваться с новыми для него технологиями. Равно как и при реализации крупных проектов со сложной бизнес-логикой или же работы с приложением, созданным кем-то другим – когда невозможно быть уверенным на 100%, что предыдущая команда все сделала правильно и нет ошибок в принятых ими решений или их реализации.
Общее правило: чем крупнее проект и выше его сложность, тем выше по нему риски. Иногда разработчики могут заложить в стоимость проекта эти риски в сумме до 30% от предварительной оценки его стоимости.
Заключение
Подводя итог, можно сказать, что размер и сложность проекта — это два взаимодополняющих фактора стоимости разработки программного обеспечения. Так что, вполне очевидно, что разработка многофункциональной ERP-системы стоит гораздо выше, чем, например, разработка RPA-системы. А разработка, например, трейдинговой платформы с отрисовкой графиков в режиме реального времени – выше, чем, например, разработка HR-платформы с простейшим фронтендом.
Кроме того, факторы «сложность проекта» и «риски по проекту» находятся в тесной корреляции – причем зачастую первый предопределяет второй. При этом, нечеткое тех задание также может спровоцировать активизацию второго фактора.
К счастью, такой фактор как риски по проекту можно полностью нивелировать, выбрав оплату по затраченному времени вместо контракта с фиксированной ценой. Потому как, в случае работы на условиях контракта с фиксированной ценой и реализации оптимистичного сценария, стоимость заложенных рисков не будет возвращена заказчику.