Спасибо! Мы свяжемся с Вами в ближайшее время.
Начать проект
Ценообразование
Как формируется стоимость проекта по разработке it-решений
6 минут на чтение
Рынок заказной разработки ПО и сложных интернет-решений весьма неоднороден. Отправив запрос с одинаковыми вводными в десяток компаний можно получить цены отличающиеся на порядок.
Чтобы Вы лучше могли понимать из чего состоит бюджет, мы подготовили упрощенную детализацию стоимости работ. Ниже я опишу простой принцип формирования стоимости кастомной разработки, основанный на расчете себестоимости, который мы используем.
Задача статьи — дать понимание о составляющих цены и показать, почему кастомная разработка не может стоить ниже некоторой границы по естественным причинам. В противном случае это либо не кастомная разработка (а попытка втиснуть что-то готовое под требования), либо проект выполнен не будет из-за неверной оценки.
Люди и роли
Чтобы сделать программу нужны не только программисты. Разработка состоит из работы команды с разными ролями. Каждый сотрудник команды выполняет свои процессы, в результате которых получаются промежуточные артефакты, с которыми работают другие сотрудники, и в результате этих действий получается продукт.
Разные методологии могут иметь свой набор ролей и свои названия, но так или иначе это все сводится к следующим основным функциям:
- Менеджмент проекта
- Аналитика (системная аналитика, бизнес-аналитика)
- UI/UX-дизайн (пользовательский интерфейс)
- Программирование (стек проекта может включать несколько платформ, для которых обычно нужны отдельные специалисты)
- Тестирование (функциональное, интеграционное, нагрузочное и т.д. — разные процессы и часто разные люди).
- Специалист по серверной инфраструктуре (devops/системный администратор, для небольших проектов не требуется)
Таким образом, в зависимости от проекта, в нем может быть задействовано минимум 5 ролей, необходимых для осуществления работ.
Можно предположить что один человек в маленьком проекте может покрыть все роли, но в реальности возникают внутренние конфликты между ролями для одного сотрудника. Например, программист не должен сам тестировать свою работу, а оценка сроков и планирование менеджером, который является и разработчиком будет некорректна. Все это негативно влияет на качество и прогнозируемость работ.
Если проект маленький, некоторые роли могут совмещаться. Программист может настроить серверную площадку для проекта, если обладает соответствующими знаниями, а менеджер может осуществлять приемку задач вместе с тестированием, если это небольшие изолированные задачи с понятным функционированием. Тем не менее, это скорее исключение и применимо в частных случаях, т.к. многое зависит от самих людей в команде.
Процесс производства
Необходимость множества ролей на проекте объясняется сложностью процесса работ от первичных требований до продукта. Сам по себе процесс состоит из нескольких фаз, в каждой из которых ключевыми являются разные процессы (подробнее про процессы).
Ниже приведен общий, упрощенный процесс выполнения работ. Этот цикл справедлив как для разработки продукта в целом, так и для отдельных задач на этапе поддержки и обслуживания.
Иногда может появиться соблазн отказаться от этапов этой цепочки с целью экономии времени/бюджета. Если нарушить эту цепочку или объединять ее в одном человеке мы получим следующие результаты:
- отсутствие целостной картины проекта и понимания что происходит
- невозможность планировать работы, хаос в разработке
- аналитику и разработчикам приходится постоянно консультировать клиента
- снижение общей эффективности
- демотивация команды
- задачи без проработки и детализации попадают к программистам, вследствие чего понимание задачи и результат искажены
- недостаточная декомпозиции больших высокоуровневых задач, вследствие чего снижается качество планирования
- из-за нечеткой формулировки задачи и повторных изменений растет технической долг
- демотивация команды
- непрофильные сотрудники начинают осуществлять тестирование, вследствие чего снижается качество (отсутствует квалификация и системность)
- привлечение программистов к тестированию — расход наиболее ценного ресурса на простые задачи
- снижение общей эффективности из-за выполнения непрофильных задач
- демотивация команды
Может показаться, что демотивация команды — это не значительная проблема. В действительности, в нашей сфере люди — основной инструмент производства. Демотивация команды — это уход людей, низкая эффективность и низкое качество. Только потери от ухода опытного специалиста могут составить порядка 3-5 его окладов за счет издержек менеджмента, нарушений сроков проекта и поиска замены (что само по себе сложная и долгая работа).
В далеком 2007 году, мы, будучи студентами, начинали с небольших сайтов и эволюционно пришли к сложным кастомным решениям. На этом пути мы наступили на множество граблей, включая вышеописанные. Последствия, которые мы получали, расплачиваясь за это своим временем и деньгами дали нам ясное понимание необходимости разделения ролей на проекте для получения предсказуемого и качественного результата.
Ценообразование
Бюджет проекта состоит из 4-х составляющих:
- Себестоимость работ
- Управленческие расходы
- Коммерческие расходы
- Маржа
Себестоимость
Для понимания ценообразования давайте рассмотрим некоторый условный проект. Предположим, это будет маркетплейс услуг сделанный с использованием современных подходов (веб-версия на основе vue.js, SPA с серверным рендерингом на основе nuxt.js, бекендом на основе symfony/laravel, панелью управления для менеджеров и кросс-платформенным мобильным приложением на flutter).
Себестоимость проекта мы считаем как затраты на разработчиков, необходимых для разработки полноценной версии сервиса, готового к масштабированию и дальнейшему развитию.
В некоторых случаях, если требуется сделать совсем простой MVP без необходимости дальнейшего развития, состав команды может быть проще, а объем работ меньше. С другой стороны, если в проекте множество специфичных функций и интеграций — объем работ и состав команды будет больше.
В крупных популярных интернет-проектах часто формируются отдельные небольшие команды с основными ролями для ключевых функций. Например, команда карточки товара, или команда формы оформления заказа. Общий штат разработчиков при этом может достигать нескольких десятков или сотен человек, а ежемесячный бюджет составлять десятки миллионов рублей.
Команда
В таблице приведен список производственных ролей, необходимых для выполнения проекта. Загрузка каждой роли неравномерна по мере выполнения проекта. Реальная загрузка будет показана далее.
В нашем случае налоговая нагрузка на фонд оплаты труда составляет около 28% от получаемых на руки денег , т.к. мы являемся аккредитованными Минкомсвязи РФ разработчиками ПО и применяем соответствующие льготы для разработчиков ПО.
Приведенная таблица ставок не учитывает затраты на поиск, найм, обучение. Для удобства мы считаем, что люди уже есть в команде и им просто надо платить. Тем не менее, их надо найти, обучать и мотивировать. Эти затраты мы закладываем в управленческие расходы, о которых речь пойдет ниже.
Ставка на руки приведена на основе данных «HeadHunder.ru» и «Хабр Карьера» на лето 2020 года, а также нашего опыта поиска и найма сотрудников.
Загрузка команды
В таблице приведена загрузка специалистов на каждый месяц работы над проектом в человеко-месяцах. Расчет приведен для проекта условно средней сложности.
Дополнительные затраты производства
В себестоимость также следует включить инструменты производства — ПО, амортизацию оборудования и другие, но относительно стоимости специалистов общий порядок существенно не изменится, поэтому в этом расчете мы эти расходы проигнорируем.
С учетом специфики бизнеса, в себестоимость также следовало бы включить HR-расходы. Это уже будет существенная часть бюджета, т.к. HR является одним из ключевых бизнес-процессов. В разработке HR обеспечивает качество и прогнозируемость основного производственного ресурса, что напрямую сказывается на результатах производства. К сожалению, расходы на HR сложно рассчитать в контексте одного проекта, поэтому они вынесены в управленческие расходы.
Итого
Таким образом, себестоимость время работы сотрудников составляет 6,580 млн. руб.
В реальных проектах часто получается снизить бюджет за счет имеющихся наработанных решений, которые могут сэкономить несколько человеко-месяцев. С другой стороны, если проект разрабатывается по договору с фиксированной оценкой, в себестоимость закладывается небольшой буфер на случай непредвиденных задач.
Управленческие, коммерческие расходы и маржа
Управленческие расходы необходимы для существования компании и поддержания ее деятельности. Сюда входит широкий спектр расходов, от кофемашины и аренды офиса до заработной платы генерального директора. Для удобства расчетов к управленческим расходам мы также относим HR, хотя в нашей сфере это скорее производственный процесс.
Коммерческие расходы включают в себя затраты на привлечение клиента и продажи. Сюда входят затраты на рекламу, маркетинг и другие активности, задача которых привести потенциальных клиентов к нам.
Коммерческие и управленческие расходы являются постоянными расходами, поэтому их можно посчитать как дополнительную наценку к себестоимости.
Для удобства расчетов, при оценке финальной стоимости проекта мы закладываем общую наценку, равную 55% от себестоимости производства для покрытий коммерческих и управленческих расходов, а также получения прибыли. Некоторые расходы, заложенные в наценку:
- Оплата обучения и развития сотрудников
- Найм сотрудников, оплата больничных и отпусков, другие hr расходы
- Покупка и модернизация рабочих мест и программного обеспечения
- Офис для офисных специалистов, интернет, сервера, тестирование
Итого
Сравнение с внутренней разработкой
Своя разработка выгоднее, если Вы имеете достаточную компетенцию в этой сфере, у Вас есть солидные бюджеты, длинный горизонт работ и много времени.
Если есть необходимые компетенции (например, в команде есть технический директор с опытом управления разработкой), Вы можете самостоятельно организовать подбор специалистов, организацию рабочих мест и координацию процесса разработки. В горизонте 1-2 лет это будет дороже заказной разработки, но на горизонте 3-5 лет это может быть оправдано и экономически выгоднее.
Если же необходимых компетенций нет, но есть солидный бюджет, тогда Вам придется доверять этот бюджет наемным техническим менеджерам. Их техническую квалификацию Вы еще можете как-то проверить, но их собственные цели и приоритеты нет, а когда что-то по их вине пойдет не так, они просто уволятся и не будут нести ответственность за свои ошибки. Мы знаем случаи, когда наемному техническому директору было интересно поработать с новыми модными решениями, в следствии чего работу команды за несколько месяцев пришлось класть в стол и переделывать проект с нуля.
Дополнительно потребуется немало времени для набора команды, выработки процесса разработки внутри команды.