Сколько стоит разработка программного обеспечения? Анатомия ценообразования заказной разработки программного обеспечения
Если у вас индивидуальные требования, и ваш проект требует специальных функциональных возможностей, обусловленных требованиями отрасли, в которой вы работаете, то разработка программного обеспечения на заказ может стать вашим решением.
Индивидуальное решение может удовлетворить потребности заказчика более эффективно, чем готовое программное обеспечение, и позволит вашему продукту выделиться на фоне конкурентов. Но сколько стоит заказная разработка программного обеспечения?
Этот вопрос аналогичен вопросу "Сколько стоит автомобиль?". - Здесь нет единого ответа, поскольку стоимость разработки программного обеспечения зависит от нескольких факторов.
Жизненный цикл разработки программного обеспечения может быть сложным и требовать наличия команды разработчиков, обладающих определенными ноу-хау. Если у вас нет таких специалистов, то вам придется передать проект на аутсорсинг компании, занимающейся разработкой программного обеспечения.
Что же сложного в ценообразовании на заказную разработку ПО?
Многие потенциальные заказчики разработки программного обеспечения не знают, сколько им следует платить. Возможно, вы относитесь к их числу. Вам может быть трудно понять, какие факторы обусловливают ту или иную цену, почему она выше или ниже ожидаемой, как партнеры по разработке программного обеспечения определяют ее размер.
В результате вы можете засомневаться, стоит ли с самого начала брать на себя все обязательства по сотрудничеству, даже если агентство по разработке программного обеспечения имеет только хорошие намерения. Они не смогут согласовать ваши ожидания с ценой, которую придется заплатить. Именно поэтому понимание всего процесса имеет решающее значение для достижения успеха.
Какова средняя стоимость разработки заказного программного обеспечения?
Справедливо будет сказать, что на форму и цену проекта влияют сотни факторов. По этой причине определение средней стоимости разработки программного обеспечения представляется сложной задачей.
Но если бы мы могли указать диапазон, то он составил бы от 5 млн. руб. до 25 млн. руб. в зависимости от сложности и типа проекта. Стоимость может увеличиваться или уменьшаться в зависимости от времени разработки, используемых технологий и других индивидуальных особенностей, которые мы подробно рассмотрим в следующих разделах статьи.
Следует отметить, что эти цифры относятся к заказным программным решениям 2023 года. На данный момент сложно прогнозировать стоимость такой услуги в 2024 году и далее, поскольку темпы разработки постоянно меняются.
Ценовой диапазон услуг, предлагаемых выбранной компанией-разработчиком, - это одно, но существует множество других факторов, которые необходимо учитывать при определении стоимости разработки программного обеспечения.
Какие факторы влияют на стоимость разработки программного обеспечения
Вы когда-нибудь видели генеалогическое дерево? Мы считаем, что да. Ценообразование проектов по разработке ПО может происходить по тому же принципу. Существует множество ветвей, которые порождают другие ветви, и ценообразование определяется именно таким образом.
Тип выполняемого проекта
Этот фактор влияет на другие этапы и позволяет хотя бы приблизительно определить цену.
Можно перечислить различные технические области каждого проекта. Точнее, можно сказать, что каждый проект по разработке программного обеспечения состоит из нескольких основных элементов, которые, как правило, требуют совершенно разных навыков. Как правило, чем крупнее проект, тем больше в нем необходимых компонентов, особенно если требуется back-end часть.
Прежде всего, необходимо определить, относится ли проект только к веб-разработке или к мобильной разработке, а может быть, и к тому, и к другому. Однозначного ответа на вопрос, что лучше или что экономичнее, нет - все зависит от целей бизнеса, требований и бюджета в конечном итоге.
Затем необходимо указать, относится ли объем проекта только к back-end, front-end или к обоим. Ниже приведено более подробное описание каждой части оценки.
Разработка фронтенда
Под "фронтенд-разработкой" мы понимаем визуальную часть веб-приложения, предназначенную для конечных пользователей системы или связанную с UI/UX панели управления системой. Как правило, мы исходим из того, что каждый создаваемый нами сайт должен быть отзывчивым (автоматически масштабироваться при просмотре на мобильном или планшетном устройстве). При таком допущении стоимость разработки программного обеспечения обычно увеличивается на 10%. Кроме того, ваше приложение может быть оптимизировано для мобильного использования, выглядеть и вести себя как мобильное приложение - здесь в игру вступают прогрессивные веб-приложения. Кроме того, на оценку стоимости сильно влияют используемые визуальные эффекты - анимация или пользовательские переходы, а также сложность коммуникационных протоколов.
Мобильная разработка
При разработке мобильного приложения необходимо уточнить у партнера по разработке программного обеспечения, будет ли оно разрабатываться как нативное или как кроссплатформенный проект. Цена также может зависеть от того, находится ли проект в стадии разработки, не готов ли он вообще или уже завершен. Кроме того, возможные интеграции с внешними API - как по количеству, так и по объему - также могут повлиять на конечную цену.
Разработка мобильных приложений может быть простой, но может быть и чрезвычайно сложной и трудоемкой.
Вероятно, это предложение вас не шокировало, но учтите, что иногда стоимость мобильных приложений может составлять сотни тысяч долларов и более.
В процессе оценки самое главное, на что обращается внимание, - это количество экранов, которые будут реализованы. Каждый экран может добавить небольшой объем работы, который в итоге может вылиться в значительное количество потраченного времени.
Android и iOS предоставляют большое количество стандартных макетов и стилей. Если необходимо создать что-то необычное, обычно требуются дополнительные усилия.
Как и при разработке внешнего интерфейса, интеграция с внутренним интерфейсом также необходима, поскольку может быть задействовано множество протоколов связи. Существуют также такие соображения, как push-уведомления и интеграция с внешними устройствами, как правило, по протоколу BLE (Bluetooth Low Energy). Разработка концептуально простого мобильного приложения, как вы понимаете, может оказаться непростой задачей.
Разработка back-end
Особенно сложно оценить back-end часть. Наши рекомендации могут варьироваться в зависимости от проекта. Обычно мы рекомендуем бессерверный подход, поскольку это наиболее масштабируемая архитектура для backend-системы.
Также очень важен поставщик облачного решения. Например, и Amazon Web Services, и Google Cloud Platform предоставляют значительное количество готовых к использованию компонентов, что снижает стоимость разработки и потенциально увеличивает стоимость решения в долгосрочной перспективе. Кроме того, может повлиять и цена внешних сервисов, подключаемых к системе, - для некоторых типовых поставщиков услуг мы можем предложить свою реализацию, снизив общую стоимость проекта.
Проекты, выполняемые в облаке, по определению стоят дороже, поскольку требуют дополнительных услуг DevOps (команда, отвечающая за саму технологию, включая внедрение, мониторинг и текущее сопровождение продукта). Это может увеличить общую стоимость проекта на довольно значительную сумму.
Таким образом, выбранная среда также может оказать влияние на конечную цену. Например, то, как должен быть задан back-end проекта, исключает возможность реализации проекта в облаке. Это может включать внедрение упомянутых выше AWS или GCP, но не ограничиваться этими технологиями.
DevOps
В настоящее время деятельность в области DevOps становится все более важной. При оценке проекта мы рассматриваем эти мероприятия как инвестиции в будущие проекты. DevOps позволяет существенно снизить затраты на разработку ПО, особенно когда речь идет о более сложных проектах, требующих развитой архитектуры back-end.
Подход Configuration as a Code позволяет не заблудиться во множестве конфигураций, развернутых на нескольких хостах, и не беспокоиться о конфигурации облачного провайдера. Чем сложнее проект, тем выше стоимость DevOps. С другой стороны, в будущем вы сэкономите больше, затраты на обслуживание также сократятся.
UI/UX-дизайн
Когда речь заходит о проектировании пользовательского интерфейса и пользовательского опыта, необходимо задать себе несколько вопросов:
- Есть ли у вас свои эскизы или вам нужен дизайнер продукта в команде?
- Есть ли у вас полный список требований и возможностей, необходимых для данного проекта?
- Для скольких различных платформ вы хотите разработать свое программное обеспечение?
- Сложное ли это приложение? А именно, сколько различных экранов необходимо подготовить для проекта?
- Нужна ли в приложении анимация или индивидуальные графические решения?
Ответы на эти вопросы подскажут, нужно ли проводить Product Workshop для обсуждения технических деталей, укажут количество разработчиков, которые должны быть задействованы в проекте, и количество времени, необходимое для его завершения. Разумеется, все эти факторы повлияют на конечную стоимость программного обеспечения.
Сроки и дедлайн
Есть такая поговорка:
Если быстро и дешево, то это нехорошо.
Если хорошо и дешево, то это не быстро.
Если быстро и хорошо, то это не дешево.
Это, безусловно, относится и к разработке заказного программного обеспечения.
Важно помнить, что для проектов, которые реализуются "быстро", также характерно большое количество динамических изменений. Особенно это проявляется в среде стартапов, где основатели не имеют опыта создания ИТ-проектов.
Важно отметить, что процессы являются одним из важнейших элементов любой организации. Быстрый темп может привести к задержке внедрения жизнеспособных процессов и методологий.
Это приводит к тому, что заказчик принимает нерациональные решения, а команда не успевает внедрить соответствующие рекомендации и технические решения, теряя время на многоуровневые изменения.
Тем не менее, следует понимать, что если проект должен быть сдан немедленно, и у вас нет времени на исследования и тестирование, то цена может быть значительно выше. Если же времени на разработку еще достаточно, то эти ресурсы могут быть распределены ответственно и привести к долгосрочной экономии средств. Совместная работа с командой над масштабом и сроками проекта позволит вам выбрать наиболее оптимальное решение.
Команда
Еще одним фактором, определяющим стоимость внедрения программных решений, является команда разработчиков. Количество разработчиков, необходимых для "сдачи" проекта, имеет большое значение для его стоимости, поскольку даже один лишний разработчик может привести к значительному изменению цены. Кроме того, существует неравномерное распределение разработчиков, поэтому стаж работы и специализация (язык программирования и технологии) также должны быть учтены и определены для ценообразования. Важно учитывать изменения, даже если они не являются постоянными (могут относиться только к определенному этапу) или кажутся незначительными.
Однако здесь следует обратить внимание на требуемый набор навыков.
Определяющим фактором может быть язык программирования или целевая технология, на которой будет разрабатываться приложение. В крупных проектах требуется участие архитектора программного обеспечения, который задает технические ориентиры и разрабатывает техническую документацию проекта. Также мы рекомендуем использовать в проектах автоматизированный подход DevOps, когда каждый компонент архитектуры настраивается и автоматизируется при минимальном вмешательстве человека, что увеличивает начальную стоимость проекта, но обеспечивает значительную экономию в будущем, а также существенное снижение затрат на сопровождение.
Интересно отметить, что некоторые заказчики в целях снижения затрат предпочитают внедрять собственных тестировщиков или добиваются исключения их из состава команды тестирования. Экономия, кажущаяся на предварительном этапе, может обернуться значительным увеличением затрат в будущем, если процесс проверки окажется несовершенным или вовсе отсутствующим.
Кроме того, крайне сложно оценить стоимость работы менеджера проекта или QA, поскольку это не постоянная работа - она зависит от размера команды.
По нашим оценкам, время работы менеджера проекта составляет 15% от времени, затраченного программистами и дизайнерами, входящими в проектную команду. Аналогично, на долю QA приходится 15% от общей стоимости, но для кроссплатформенных мобильных проектов это соотношение возрастает до 30%.
Еще одной темой является дизайн - приносит ли клиент заранее разработанный макет, или его придется переделывать или создавать с нуля дизайнеру продукта.
Сложность
Несомненно, львиная доля цен на разработку программного обеспечения определяется функциональными возможностями приложения или сайта. Функциональные требования определяют функции, которые должно выполнять приложение или сайт, и определяют конечную цену.
Каждая функция имеет свою стоимость, поскольку требует написания функций, разработки их интерфейса, установки, настройки и обучения персонала. Стоимость каждой функции различна, так же как и комбинации функций или сложность их компонентов.
Чтобы точно рассчитать стоимость и выбрать подходящие решения, необходимо определить функциональные потребности. Если очевидно, что в будущем конкретный проект по разработке программного обеспечения будет расширяться и модифицироваться, то можно более точно выбрать решение и тем самым снизить стоимость прогнозируемых обновлений и модернизаций.
Методология
Ценообразование проекта зависит от используемого процесса и методологии. Неправильное использование процесса и методологии может привести к резкому увеличению стоимости реализации проекта.
Например, если команда работает по методологии Agile Scrum с владельцем продукта заказчика, то затраты могут быть снижены.
Принятие agile-методологии и правильный процесс взаимодействия между владельцем продукта (возможно, со стороны клиента) и командой, которую обычно представляет менеджер проекта, могут сыграть важную роль в снижении стоимости проекта.
Более ранние водопадные подходы приводят к чрезмерно жесткому разделению процесса на этапы, что увеличивает риск потери времени на то, что впоследствии окажется ненужным или вызовет критику со стороны конечного пользователя. Если проект разрабатывается с использованием scrum, то требуется дополнительное время на проведение совещаний, что отражается как на стоимости, так и на продолжительности поставки.
Кроме того, невозможно постоянно вносить изменения, что крайне важно для многих проектов по разработке программного обеспечения. Все это влияет на потенциальную цену.
Возможные модели тарификации, используемые в ИТ
Существует несколько методов ценообразования, которые используют различные компании-разработчики программного обеспечения для оценки стоимости продукта. Здесь мы приводим три наиболее часто применяемые модели тарификации.
Фиксированная цена
При этой модели цена работ оценивается заранее. На этом этапе работы над проектом в него не могут быть внесены изменения без пересмотра условий договора. Кроме того, в связи с тем, что цена на конкретные работы устанавливается заранее, она требует от заказчика очень четких спецификаций и деталей.
Этот вариант возможен для всех проектов, стоимость которых может быть определена до начала работ. Однако при этом необходимо тщательно проработать спецификацию проекта, учитывая также сроки его выполнения, график и объем работ.
Время и материал
Метод "время и материал" является наиболее популярным и удобным для обеих сторон способом расчета за разработку программного обеспечения. Это метод расчета, основанный на фактически отработанных каждым сотрудником в проекте единицах времени. Контракт допускает значительную гибкость, поскольку в ходе разработки могут вноситься изменения.
В этой модели заказчик регулярно информируется о состоянии проекта и получает подробный отчет о его ходе. Он использует эту информацию для проверки состояния проекта и внесения необходимых изменений.
Эта модель предпочтительна для заказчиков, которые имеют общее представление о конечном продукте, но не могут точно описать объем работ и сроки. Ее преимущество заключается в снижении накладных расходов, поскольку заказчик оплачивает почасовую стоимость разработки программного обеспечения без дополнительных затрат на риск.
FBSC: Фиксированный бюджет и контролируемый объем работ
Это немного гибридный вариант.
Цель состоит в том, чтобы в самом начале проекта иметь хорошее представление о нем как со стороны клиента, так и со стороны партнера по разработке ПО. Используя мнение клиента и опыт партнера по разработке ПО, можно определить ответственный бюджет и сроки. Благодаря такому подходу объем всего проекта не задается заранее и может быть изменен путем изменения приоритетов отдельных задач без ущерба для сроков и бюджета.
Тесное сотрудничество с заказчиком позволяет отслеживать финансовое состояние проекта, что дает возможность вносить коррективы по своему усмотрению, делая продукт более качественным.
Как мы решаем задачу оценки стоимости программного обеспечения
Лучше всего об этом говорит следующая цитата:
"Когда мы обсуждаем вопросы ценообразования и оценки проектов с нашими потенциальными заказчиками, мы всегда стараемся дать большую обратную связь. Заказчики часто сталкиваются с проблемой обширного спектра получаемых ими предложений. Очень важно адекватное разделение объема и обоснование цифр, а также соответствующее обоснование технических решений. Мы многое даем с самого начала, чтобы сделать разницу - наш процесс оценки и ценообразования ориентирован на клиента, поскольку именно это приносит наибольшую ценность в конечном итоге"..
PM, точно зная объем проекта, записывает его в пользовательские истории, например, "как пользователь приложения, я хотел бы иметь возможность просматривать статистику, касающуюся моей деятельности". Затем на основе этих историй определенные задачи поручаются конкретным людям. Для проекта отбираются наиболее опытные люди с наиболее глубоким пониманием требований проекта.
Затем эти задачи оцениваются по времени, и общее количество часов работы привлеченных лиц умножается на их почасовую ставку. Кроме того, можно экстраполировать данные прошлых работ для построения сметы текущего проекта, если текущий проект похож на прошлый.