Заполните форму или отправьте нам письмо

Ценообразование

Как формируется стоимость проекта по разработке it-решений

Дмитрий Юркин
13 августа 2020
6 минут на чтение

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

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

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

Люди и роли

Чтобы сделать программу нужны не только программисты. Разработка состоит из работы команды с разными ролями. Каждый сотрудник команды выполняет свои процессы, в результате которых получаются промежуточные артефакты, с которыми работают другие сотрудники, и в результате этих действий получается продукт.

Разные методологии могут иметь свой набор ролей и свои названия, но так или иначе это все сводится к следующим основным функциям:

  • Менеджмент проекта
  • Аналитика (системная аналитика, бизнес-аналитика)
  • UI/UX-дизайн (пользовательский интерфейс)
  • Программирование (стек проекта может включать несколько платформ, для которых обычно нужны отдельные специалисты)
  • Тестирование (функциональное, интеграционное, нагрузочное и т.д. — разные процессы и часто разные люди).
  • Специалист по серверной инфраструктуре (devops/системный администраторов, для небольших проектов не требуется)

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

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

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

Процесс производства

Необходимость множества ролей на проекте объясняется сложностью процесса работ от первичных требований до продукта. Сам по себе процесс состоит из нескольких фаз, в каждой из которых ключевыми являются разные процессы (подробнее про процессы).

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

1
Формирование
Менеджер проекта
2
Аналитика
Системный аналитик
3
Выполнение
Программист
4
Тестирование
QA-специалист
Публикация
Руководитель разработки

Иногда может появиться соблазн отказаться от этапов этой цепочки с целью экономии времени/бюджета. Если нарушить эту цепочку или объединять ее в одном человеке мы получим следующие результаты:

Без менеджера проекта
  • отсутствие целостной картины проекта и понимания что происходит
  • невозможность планировать работы, хаос в разработке
  • аналитику и разработчикам приходится постоянно консультировать клиента
  • снижение общей эффективности
  • демотивация команды
Без аналитика
  • задачи без проработки и детализации попадают к программистам, вследствие чего понимание задачи и результат искажены
  • недостаточная декомпозиции больших высокоуровневых задач, вследствие чего снижается качество планирования
  • из-за нечеткой формулировки задачи и повторных изменений растет технической долг
  • демотивация команды
Без QA-специалиста
  • непрофильные сотрудники начинают осуществлять тестирование, вследствие чего снижается качество (отсутствует квалификация и системность)
  • привлечение программистов к тестированию — расход наиболее ценного ресурса на простые задачи
  • снижение общей эффективности из-за выполнения непрофильных задач
  • демотивация команды

Может показаться, что демотивация команды — это не значительная проблема. В действительности, в нашей сфере люди — основной инструмент производства. Демотивация команды — это уход людей, низкая эффективность и низкое качество. Только потери от ухода опытного специалиста могут составить порядка 3-5 его окладов за счет издержек менеджмента, нарушений сроков проекта и поиска замены (что само по себе сложная и долгая работа).

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

Ценообразование

Бюджет проекта состоит из 4-х составляющих:

  • Себестоимость работ
  • Управленческие расходы
  • Коммерческие расходы
  • Маржа

Себестоимость

Для понимания ценообразования давайте рассмотрим некоторый условный проект. Предположим, это будет маркетплейс услуг сделанный с использованием совремнных подходов (веб-версия на основе vue.js, SPA с серверным рендерингом на основе nuxt.js, бекендом на основе symfony/laravel, панелью управления для менеджеров и кросс-платформенным мобильным приложением на flutter).

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

В некоторых случаях, если требуется сделать совсем простой MVP без необходимости дальнейшего развития, состав команды может быть проще, а объем работ меньше. С другой стороны, если в проекте множество специфичных функций и интеграций — объем работ и состав команды будет больше.

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

Команда

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

В нашем случае налоговая нагрузка на фонд оплаты труда составляет около 28% от получаемых на руки денег , т.к. мы являемся аккредитованными Минкомсвязи РФ разработчиками ПО и применяем соответствующие льготы для разработчиков ПО.

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

Специализация
Ставка на руки
Себестоимость
Менеджер проекта
120 000 Р
153 600 Р
Аналитик / Продукт-менеджер
180 000 Р
230 400 Р
UI/UX дизайнер
120 000 Р
153 600 Р
Системный архитектор / Руководитель разработки
250 000 Р
320 000 Р
Back-end PHP Senior
170 000 Р
217 600 Р
Back-end PHP Middle
110 000 Р
140 800 Р
Front-end Web Senior
170 000 Р
217 700 Р
Front-end Web Middle
110 000 Р
140 800 Р
Mobile Senior
220 000 Р
281 600 Р
Mobile Middle
150 000 Р
192 000 Р
QA
80 000 Р
102 400 Р
Devops
180 000 Р
230 400 Р

Ставка на руки приведена на основе данных «HeadHunder.ru» и «Хабр Карьера» на лето 2020 года, а также нашего опыта поиска и найма сотрудников.

Загрузка команды

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

Специализация
Месяц 1
Месяц 2
Месяц 3
Месяц 4
Месяц 5
Месяц 6
Итого (ч/м)
Итого (руб.)
Менеджер проекта
0.3
0.3
0.3
0.3
0.3
0.3
1.8
276 480 Р
Аналитик
1
1
0.5
0.25
0.25
0.25
3.25
748 800 Р
UI/UX дизайнер
0.5
1.5
1
0.5
3.5
537 600 Р
Системный архитектор
0.25
0.5
1
0.25
0.25
0.25
2.5
800 000 Р
Back-end PHP Senior
1
1
0.5
0.5
2.75
598 400 Р
Back-end PHP Middle
1
1
1
0.5
3.5
492 800 Р
Front-end Web Senior
1
1
0.5
0.5
2.75
598 400 Р
Front-end Web Middle
1
1
1
0.5
3.5
492 800 Р
Mobile Senior
1
1
0.5
0.25
2.75
774 400 Р
Mobile Middle
1
1
1
0.5
3.5
672 000 Р
QA
0.5
1
2
3.5
358 400 Р
Devops
0.5
0.5
1
230 400 Р
Итого
34.3
6 580  480  Р

Дополнительные затраты производства

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

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

Итого

Таким образом, себестоимость время работы сотрудников составляет 6,580 млн. руб.

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

Управленческие, коммерческие расходы и маржа

Управленческие расходы необходимы для существования компании и поддержания ее деятельности. Сюда входит широкий спектр расходов, от кофемашины и аренды офиса до заработной платы генерального директора. Для удобства расчетов к управленческим расходам мы также относим HR, хотя в нашей сфере это скорее производственный процесс.

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

Коммерческие и управленческие расходы являются постоянными расходами, поэтому их можно посчитать как дополнительную наценку к себестоимости.

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

  • Оплата обучения и развития сотрудников
  • Найм сотрудников, оплата больничных и отпусков, другие hr расходы
  • Покупка и модернизация рабочих мест и программного обеспечения
  • Офис для офисных специалистов, интернет, сервера, тестирование

Итого

6,5
млн
руб
+
55
%
=
~10
млн
руб

Сравнение с внутренней разработкой

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

Если есть необходимые компетенции (например, в команде есть опытный технический директор с опытом разработки), Вы можете самостоятельно организовать подбор специалистов, организацию рабочих мест и координацию процесса разработки. В горизонте 1-2 лет это будет дороже заказной разработки, но на горизонте 3-5 лет это может быть оправдано и экономически выгоднее.

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

Дополнительно потребуется немало времени для набора команды, выработки процесса разработки внутри команды.