Расчёт затрат имеет решающее значение при разработке ПО, так как неточная оценка (завышенная или заниженная) часто сказывается отрицательно на бюджете разработчика.
А ещё это может привести к неэффективному распределению ресурсов, что негативно повлияет на производительность проекта. Как оценить стоимость разработки, подробнее рассмотрим в этом материале.
Что такое расчёт цены разработки
Это процесс определения расходов на создание конкретного продукта, при котором оценивается объём работы, необходимые ресурсы (люди, оборудование, программное обеспечение), сроки выполнения задач, риски и другие факторы. Подобный расчёт можно проводить как в начале, так и по мере продвижения проекта.
Существует несколько основных типов оценки:
-
Приблизительный расчёт. Даёт общее представление о диапазоне затрат на внедрение и доработку продукта.
-
Бюджетная смета. Это фактический прогноз капитала, необходимого для выполнения проектных работ. Несмотря на более точный расчёт, по-прежнему может содержать предположения и примерные оценки.
-
Описание услуг. Включает конкретные виды работ, а также конечные результаты и сроки реализации проекта. Это даёт клиенту чёткое представление обо всех аспектах разработки и помогает избежать недопониманий с заказчиком.
Из чего складывается стоимость разработки
Программное обеспечение — широкое понятие. Чтобы точно понять, сколько будет стоить конкретный проект, необходимо учитывать следующие факторы.
Тип проекта
Определение типа проекта — первый и важнейший шаг в планировании бюджета разработки. Выделяют следующие основные типы:
-
Разработка с нуля. Создание нового ПО под индивидуальные запросы клиента.
-
Модификация. Обновление существующего ПО в соответствии с новыми функциями. Например, проекты по исправлению ошибок.
-
Интеграция. Применение пользовательского кода для внедрения существующего ПО в другие процессы. Например, через CPaaS-платформу МТС Exolve можно перенаправлять данные с сайта, мессенджеров, SMS и прочих сервисов в любую CRM-систему компании.
Для каждого из приведённых выше типов нужен разный состав команды, объём ресурсов и индивидуальная стоимость разработки.
Сложность проекта
Стоимость разработки в значительной степени зависит от архитектуры, количества функций и бизнес-логики ПО. Чем насыщеннее будет структура будущего проекта, тем больше ресурсов потребуется для его создания, тестирования и внедрения.
В контексте технической сложности ПО можно разделить на три категории:
Базовое
-
основной набор функций без интеграции сторонних сервисов;
-
простой дизайн с общими элементами интерфейса;
-
обработка небольших и средних объёмов данных.
Сроки разработки — 1–3 месяца.
Среднее
-
основной набор + дополнительные функции (платежи, общение в чате в режиме реального времени и аналитические решения);
-
адаптивный дизайн с более сложными элементами интерфейса и визуальными эффектами;
-
обработка средних и больших объёмов данных.
Сроки разработки — 3–6 месяцев.
Сложное
-
продвинутый набор функций (обработка видео, синхронизация и различные сторонние интеграции и т. д.);
-
адаптивный дизайн с расширенными элементами интерфейса, сложными взаимодействиями и визуальными эффектами;
-
обработка крупномасштабных данных (с высокой производительностью).
Сроки разработки — от 6 месяцев.
Таким образом, для создания первой версии MVP (минимально жизнеспособного продукта) достаточно основных функций и базовых элементов дизайна. В этом случае бюджет будет минимальным.
С другой стороны, разработка комплексного программного продукта со сложными функциями, логикой и продвинутым UX/UI-дизайном потребует бóльших денежных затрат.
Размер проекта
В этом случае рассчитывается количество файлов, строк кода, модулей и других переменных, связанных с физическим объёмом будущей программы.
При этом большинство проектов можно разделить на следующие категории:
-
Малые. Относятся к ПО с ограниченной функциональностью и относительно небольшой кодовой базой. Обычно это простые программы или утилиты вроде текстового редактора.
-
Средние. Комплексные программы большего размера. Они могут включать в себя несколько модулей или компонентов. Например, системы управления тестированием (TestRail, Qase).
-
Крупные. Содержат множество взаимосвязанных модулей, баз данных и сложную бизнес-логику. Такое ПО обычно применяют в корпоративных системах и комплексных программных решениях.
Таким образом, чем масштабнее программа, тем ресурсозатратнее будет её создание, что прямо повлияет на стоимость оценки разработки проекта.
Состав команды
Цены на разработку ПО также зависят от навыков и опыта программистов, участвующих в проекте. Обычно для стандартного проекта привлекаются:
-
руководитель группы (тимлидов)
-
разработчики front-end и back-end
-
UX/UI-дизайнер
-
тестировщики
В более крупных проектах участвуют:
-
DevOps-инженер.
-
специалист по информационной безопасности.
-
продуктовый аналитик.
-
QA-инженер.
Также могут привлекаться архитекторы баз данных, мобильных приложений (для Swift, Kotlin и т. д.), гейм-дизайнеры и множество других экспертов.
Как правило, такие специалисты делятся на джунов, мидлов и сеньоров:
-
Джуны (англ. junior, «младший»). Находятся в начале своей карьеры и во многом зависят от помощи своих коллег. Обычно они занимаются разработкой несложных проектов (или его частей) и требуют систематического обучения.
-
Мидлы (англ. middle, «средний»). Опытные специалисты, которые хорошо знакомы с одной или несколькими платформами и языками программирования. Они редко нуждаются в менторстве, более автономны и могут участвовать в архитектурных решениях или руководить частью проекта.
-
Сеньоры (от англ. senior, «старший»). Мастера в своей сфере с большим практическим опытом в используемом на проекте стеке. Они отвечают за разработку сложных компонентов, принимают ключевые технические решения и участвуют в планировании всего проекта. Часто помогают менее опытным сотрудникам.
Помимо тимлидов к крупным проектам могут привлекаться техлиды — специалисты, которые отвечают за все значимые технические моменты.
Следовательно, чем выше уровень задействованных в проекте разработчиков, тем выше стоимость работ.
Технологический стек
Комплекс языков программирования, фреймворков и остального ПО, который обычно называют технологическим стеком, — ещё один важный аспект оценки стоимости проекта. Он определяет набор интерфейсных и серверных средств проекта (языки программирования, фреймворки, библиотеки и т. д.), необходимых для создания масштабируемого, производительного и устойчивого продукта.
Разберём подробнее:
-
Технологии внешнего (клиентского) интерфейса. Относятся ко всему, что связано с UI. К примеру, в интерфейсном стеке веб-приложений будут использоваться такие элементы, как CSS, HTML и JavaScript.
-
Серверная часть. Этот аспект разработки включает в себя всё, что относится к базам данных, API, облачным платформам и серверам: PostgreSQL, GraphQL, Node.js, Express.js, Amazon Web Services (AWS) — и многое другое.
В связи с уникальностью каждого проекта единого решения для технологического стека не существует, и при его создании нужно отталкиваться от целей проекта. Например:
-
Для высокой масштабируемости можно использовать языки программирования вроде Python и Javascript.
-
Для быстрого вывода на рынок подойдут такие фреймворки, как Ruby on Rails (RoR) или Express.js.
-
Для отличной функциональности и выразительности кода можно использовать мультипарадигменный язык программирования Scala и т. д.
Таким образом, чем сложнее техстек будущего ПО, тем выше стоимость проекта. Также нужно учитывать лицензионные расходы, будущие обновления, наличие готовых решений и другие аспекты разработки.
Сроки
Время разработки — один из важнейших факторов, который влияет на конечную стоимость проекта.
Так, для создания сложного ПО в сжатые сроки разработчикам придётся увеличить бюджет — например, на привлечение в команду специалистов на аутсорсе. В счёт пойдёт и оплата времени, которое программисты будут тратить на разработку ПО.
Определяя сроки, нужно всегда учитывать:
-
Форс-мажор. Сюда можно отнести технические проблемы или неисправности оборудования, экономический или политический кризис в стране, хакерские атаки и т. д.
-
Задержки, связанные с членами команды. Например, в связи с их отпуском, больничным, командировкой, увольнением и другими обстоятельствами.
-
Изменение первоначальных требований. Клиент вправе внести корректировки на любой стадии разработки. Кроме того, доработка ПО может понадобиться даже после сдачи проекта — для внесения мелких изменений и обработки комментариев заказчика.
-
Проблема с поставкой сторонних компонентов. Если проект зависит от сторонних библиотек, инструментов или сервисов, задержки в их поставке или проблемы с их совместимостью могут заметно замедлить разработку.
Также для оценки стоимости создания ПО нужно учитывать интеграцию сторонних систем, миграцию данных, время выхода на рынок, тип платформы, размер команды и множество других важных факторов.
Скрытые затраты проекта
Это непредвиденные или косвенные расходы, необходимые для завершения и корректной работы проекта, но не включённые в его первоначальный бюджет.
Некоторые из них возникают на этапе оценки работ, некоторые — после введения ПО в эксплуатацию. Именно эти факторы объясняют завершённость предполагаемых затрат.
Учитывая, что в IT-сфере существуют сотни видов ПО, рассмотрим скрытые затраты на примере оценки стоимости разработки мобильного приложения.
-
Корректировка ошибок и текущее обслуживание (в том числе обеспечение безопасности и поддержка старых версий ПО).
-
Регулярные обновления и добавление новых функций приложения.
-
Мониторинг производительности ПО.
-
Тестирование на реальных устройствах.
-
Маркетинговые исследования, анализ конкурентов и постоянный мониторинг обратной связи от пользователей.
-
Рекламные кампании и оптимизация метаданных для повышения видимости приложения в магазинах.
-
Плата за сервер или облачный хостинг (в зависимости от объёма трафика и данных).
-
Администрирование базы данных, а также обновление и оптимизация её структуры.
-
Текущий аудит безопасности, в том числе с помощью сторонних услуг и сервисов для обнаружения и предотвращения угроз.
-
Процедуры аварийного восстановления (например, после сбоев или резервного копирования данных).
-
Масштабирование инфраструктуры для поддержания роста базы пользователей.
-
Механизмы кеширования и сетей доставки контента (CDN) для повышения производительности и оптимизации скорости загрузки.
-
Обновление компьютеров разработчиков.
-
Изготовление и тестирование прототипов, а также их доработка на основе обратной связи от заказчика.
-
Подключение инструментов управления проектами и совместной работы.
-
Плата за программу Apple для разработчиков.
-
Плата за API для разработчиков Google Play.
-
Лицензии на интеграцию с картами (Google Maps, «Яндекс Карты» и т. д.).
-
Расходы на платёжный шлюз и т. д.
-
Управление проектами (например, обучение сотрудников и подключение специализированных программ).
-
Подписка на средства коммуникации.
-
Создание и поддержание документации (пользовательское руководство, политика проекта и т. д.).
-
С новыми функциями или интеграциями.
-
С проектированием, прототипированием и внедрением нового UX/UI-дизайна.
-
С тестированием и оптимизацией дополнительных поддерживаемых устройств.
-
С адаптацией контента и маркетинга под обновлённую аудиторию проекта.
Понимая косвенные расходы проекта, можно составлять более подробную смету и точнее планировать бюджет.
Методы оценки стоимости разработки сайта и прочего ПО
Определить цену будущего программного продукта можно разными способами. Вот самые распространённые из них:
-
Экспертная оценка. Основана на опыте и знании специалистов команды, которые анализируют задачи, технические требования и спецификации проекта, а также сложность и объём работ. При этом финальное решение принимают с учётом позиции нескольких специалистов. Если мнения сильно разделятся или по некоторым вопросам у команды не хватит экспертизы — всегда можно привлечь консультантов со стороны.
-
Метод аналогии («Сверху вниз»). В этом случае команда анализирует прошлые кейсы, похожие по структуре, сложности, объёму и прочим параметрам с текущим проектом. Затем эти данные применяются в разработке нового продукта (с учётом его различий и уникальных особенностей), что облегчает планирование расходов и ресурсов программирования. Такой подход отлично работает, когда у команды есть собственные задокументированные кейсы.
-
Метод «Снизу вверх». Вместо того чтобы оценивать проект в целом, команда разбивает его на более мелкие элементы вроде задач, этапов или компонентов. Это позволяет точнее определить ресурсы, необходимые для каждой подзадачи, а затем уложить данные в общую картину стоимости выполнения проекта. Из минусов — подход увеличивает сроки планирования, из плюсов — более точная оценка стоимости, а также эффективное управление рисками и ресурсами.
-
COCOMO (Constructive Cost Model). Этот подход использует формулы, связывающие несколько ключевых параметров проекта.
Базовая формула основана на оценке трудозатрат, зависящих от размера кодовой базы. А для повышения точности оценки в COCOMO учитываются дополнительные факторы вроде сложности продукта, опыта команды и требований к технической эффективности:
Где:
-
Effort — трудозатраты в человеко-месяцах
-
А и В — параметры, зависящие от типа проекта
-
Size — размер кодовой базы в тысячах строк кода (KLOC)
-
УФА — коэффициент влияния факторов, учитывающих сложность продукта, опыт команды и прочие параметры
Приведённые методы помогают принять обоснованные решения по бюджетированию, планированию и контролю проектов, а также обеспечивают разработчикам ясность в отношении размера ресурсов и времени для успешной реализации проекта.
Заказная разработка? Аутсорс? Или своя команда (in-house)?
Когда встает вопрос стоимости разработки, естественное желание многих руководителей — попытаться сэкономить, наняв собственную команду или арендовав команду по модели аутсорс, чтобы не оплачивать накладные расходы и прибыль агентства. Однако этот подход часто приводит к тому, что проект так и не выходит в свет.
Давайте посмотрим, какие есть варианты и для каких типов проектов они подходят.
Если ваш проект разовый, нагрузка нестабильна, или вам нужно срочно выпустить продукт (или MVP), но нет времени, ресурсов и желания заниматься координацией и управлением командой — заказная разработка станет оптимальным решением. Просто потому, что:
-
у вас будет заранее известная стоимость проекта (или вилка стоимости)
-
вас не будут беспокоить простои команды
-
не надо думать о найме, обучении, мотивации
-
можно требовать, а не “пасти котов”
Если ваш проект развивается стабильно, у вас есть долгосрочные планы на 1-2 года вперед, и требуется 200−400 часов разработки в месяц, агентство скорее всего выделит для вас отдельную команду (аутсорс). Да, внутри команды могут происходить ротации. Но это уже не ваша забота.
Можно выкупить команду и частично, но это может привести к снижению фокуса на ваших задачах. При аутсорсе обычно оплачивается фактическое время работы, соответственно, получается дешевле заказной разработки, когда агентству приходится закладывать в цену свои риски. Стоимость задач варьируется в зависимости от их срочности.
Собственная команда оправдана только в случае, если проект стабильно требует от 1000 часов в месяц, и вы уверены, что эта нагрузка сохранится в долгосрочной перспективе. Иначе вы просто не перекроете свои затраты на найм, менеджмент, рабочие места и так далее. При этом вы должны быть готовы построить внутренний производственный процесс, и разобраться с тактикой организации in-house-команды.
Заключение
Таким образом, рассчитать, сколько стоит сделать сайт или приложение, — сложная задача, она требует тщательной подготовки. Здесь учитывается масса переменных: состав команды, сложность и размер проекта, а также сроки выполнения работ.
Кроме того, важно правильно распределять свои ресурсы, налаживать контакты в команде и с заказчиком, а также использовать популярные методы оценки разработки ПО.