Конкурс по машинному обучению
С призовым фондом в 100 млн рублей
Условия
Финансы
Reactive
1806

Сколько должен стоить ИТ-проект

Мы часто сталкиваемся с вопросом: «Почему так дорого?» Настало время подробно рассказать о том, как рассчитывается стоимость IT-проекта.

В закладки

Работа компании должна быть рентабельной – окупать все вложенные ресурсы и сохранять перспективы развития. Рентабельность измеряется в процентах и показывает долю прибыли в каждом рубле полученных от проекта средств. Иногда мы ориентируемся на определенный доход, а иногда проект несет в себе имиджевое преимущество. Например, имиджевым для нас было сотрудничество с баскетбольным клубом «Парма».

Разные по масштабу проекты требуют разных расчетов. Один и тот же процент от 100 тысяч и от 10 миллионов имеет разный вес, а труд работающих над проектом людей не может стоить по-разному. У менеджеров на маленькие проекты уходит не меньше, а иногда даже больше времени, чем на крупные. Поэтому во время предварительной оценки мы закладываем больший процент рентабельности в маленькие проекты. Сделки до миллиона рублей должны приносить рентабельность 30% и более. Сделки от миллиона – 20%. Проекты от пяти миллионов рассчитываются индивидуально.

Основные статьи наших затрат:

  • зарплаты разработчиков,
  • премии менеджеров,
  • налоги,
  • хостинг, подписки и т. п.

Эти затраты мы учитываем в денежном выражении.

Все остальные издержки (оклады менеджеров и административного персонала с налоговыми отчислениями, аренда и содержание офиса, реклама и маркетинг) мы закладываем в расчеты в виде коэффициента. Его величина оценивается экспертно и зависит от веса проекта в общем портфеле. Вес проекта – это доля всех операционных затрат компании, которая приходится именно на него.

Как происходит оценка проекта?

1. Встречаемся с заказчиком, проводим брифинг. Определяем цели, аудиторию, формат, технические аспекты.

2. Передаем информацию аналитикам. Они предварительно оценивают проект и составляют смету.

3. Проект рассматривает отдел продаж: он выявляет возможные риски, подводные камни, особенности.

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

5. Оцениваем финансовые риски: готов ли клиент платить аванс или нам необходимо обеспечивать проект своими средствами.

6. Вносим данные в таблицы с формулами.

Разберем один пример наших внутренних расчетов при оценке рентабельности проекта. Смету именно этого проекта вы видели в начале. Это был контракт на разработку мобильного приложения. Предварительная стоимость – 2 401 350 руб.

Считаем стоимость работы каждого специалиста. Для этого умножаем количество рабочих часов на стоимость часа с учетом налогов (см. таблицу ниже). Суммируем полученные результаты. Получаем 992 550 руб.

От предварительной стоимости проекта (2 401 350 руб.) считаем 7% на премии менеджерам и разработчикам. Получаем 168 094,5 руб. Умножаем на налоговый коэффициент, в нашем случае это 1,272. Итог: 213 816 руб.

Не забываем про налоги на доход. В нашем случае они рассчитываются по упрощенной системе налогообложения (УСНО): 6% от стоимости (2 401 350 руб.). Это 144 081 руб..

Для этого проекта необходимо приобретение хостинга и использование аутсорса. На первое необходимо 20 000 руб., на второе – 120 000 руб. В сумме получаем 140 000 руб.

Считаем коэффициент операционных издержек – 20% от стоимости (2 401 350 руб.). Это 480 270 руб.

Складываем все затраты на проект, получаем 1 970 717 руб.

В таком случае прибыль составит 430 633 руб (2 401 350 – 1 970 717). Рентабельность – 18%. Наш норматив для сделок такой категории – 20% Необходимо пересмотреть либо трудоемкость проекта, либо его стоимость.

Если у вас остались вопросы или вы хотите поделиться своим опытом – пишите нам.

{ "author_name": "Reactive", "author_type": "self", "tags": [], "comments": 17, "likes": 12, "favorites": 61, "is_advertisement": false, "subsite_label": "finance", "id": 150050, "is_wide": false, "is_ugc": true, "date": "Thu, 13 Aug 2020 17:40:42 +0300", "is_special": false }
МегаФон
Тренажер для речи, приложение для нетворкинга и IoT в больницах: выпускники лаборатории 5G МегаФона защитили проекты
30 июня 2020 года прошел выпускной первой в России лаборатории 5G_Dream_Lab — совместного проекта МегаФона и…
Объявление на vc.ru
0
17 комментариев
Популярные
По порядку
Написать комментарий...
3

Заказчику, по большому счету, всë равно сколько Вы потратили на проект, его интересует прибыль, которую он получит от проекта. Лучше формировать ценность продукта не через себестоимость+%, а через выгоду от использования. А то так можно долго болтаться на грани рентабельности.

Ответить
0

Я как-то занимался мониторингом рынка услуг веб-студий и дигитальных агентств, для того чтобы понять стоит ли мне прокачивать это направление. Представлялся клиентом, которому нужен интернет-магазин и мой коронный вопрос был как раз как в статье — "а чо так дорого?". Обзвонил 50 или около того агенств и хоть бы кто-нибудь рассказал мне про прибыль в ответ. Тем более это логично, мать его, я хочу интернет-магазин, значит я буду продавать, значит мне нужны продажи, не? Чоб не предложить это обсудить? Но нет, усредненный ответ особо не зависел от региона и уровня агенства и примерно соответствовал статье — "Наш сайт и комплекс услуг по продвижению стоят 200к/500к/4кк/15кк, потому что им будет занимать КОМАНДА СПЕЦИАЛИСТОВ из 5/10/15 человек!". Особо отбитые рассказывали про налоги. А меж тем мне как клиенту насрать на вашу команду и связанную с ней арифметику... Особенно при первом касании.

Ответить
0

Участие в ваших прибылях - это не наземная работа, а партнерство. 

Ответить
0

Вот вы тугие-то:)
Зацепились за слово прибыль.
Не ребят, так вы слона не продадите.
Не хотите участвовать — пожалуйста, но зачем мне, как потенциальному клиенту, рассказывать про кол-во специалистов, которых надо кормить, налоги и рентабельность?
С таким подходом можно продавать какие-нибудь горячие пирожки, в разрезе статьи — лендинги, сайты на конструкторе, а в больших проектах с ценниками в n миллионов вопросы про прибыль всё равно возникнут.
Ну хотите рассказать про команду, расскажите про то, что у вас программисты все как один сертифицированные по своим направлениям, например, это хотя бы может повысить ценность команды косвенно.
А то мне сайт пытаются сторговать за 5 лямов вроде бы не совсем последнее агентство, которое за эти деньги посчитало, что может предоставить полный цикл услуг, т.е. аналитику, разработку, маркетинг и т.п. И чоб не сказать в ответ на "чо дорого?", что "Вы знаете, вот у нас есть кейсы, в которых мы увеличили оборот клиенту в 10 раз, поэтому наш комплекс услуг полного цикла стоит столько сколько стоит". Тем более на сайте агентства в разделах портфолио действительно были такие кейсы. Но нет, в ответ слышится какое-то невнятное мычание...

Ответить
0

Так наемная работа по сайту очень часто состоит из зарплат, так что просили - то и получили. А если наемный работник/компания будет работать на прибыль заказчика, то и делить ее надо вместе с ним. По моему так.

Ответить
1

Ну окай, мы просто про разных сферических коней говорим, я вот в основном продажу имею ввиду и для меня очень странно продавать что-либо с позиции "ну блиин, вон у меня какой штат большой, а ФОТ? вы видели мой ФОТ? а налоги? налоги ваще давят, поэтому вот у нас такая цена".
Возможно это сугубо российские реалии, когда заказчику нужно действительно показать, что исполнитель имеет рентабельность в 5-20% а не в 120% и функционирует на подсосе, чисто чтоб заказчика жаба не давила, что с его денег жируют.
По мне это очень слабая аргументация и еще более слабая, оправдательная позиция в переговорах. Мол не мы такие, а вот так сложились обстоятельства.
По поводу прибыли — с Васи, который делает лендос за 5к штука, действительно требовать какие гарантии глупо, там речь вообще не про продукт и даже не про законченную услугу, а сугубо про Васины жопочасы. А вот, когда ценник выкатывают 150 лямов, то можно поговорить и про прибыль, и про гарантии и даже про партнёрский %. Только, как показывает практика, говорят всё равно про ФОТ, налоги, внутреннюю кухню и про обстоятельства, а не про продукт.

Ответить
2

Ну по сути-то вы хотите, что бы ваши CAPEX затраты исполнитель оправдывал, но он-то тут при чем ? Это полностью ваша головная боль. Ситуация ровно 1 в 1 как покупка станка за 150 млн : приходит покупатель и хочет что бы ему производитель станка гарантировал что он с него заработает, что очень странно. А сайт почему это это не станок, да. 

Ответить
0

Нет, не 1 в 1: у станка есть нормативный срок службы, режимы работы, интервалы обслуживания, кол-во обработанного сырья или выточенных деталей и т.п. Это всё указано в паспорте у станка и опираясь на эти данные покупатель, внезапно, может планировать.
И действительно сайт не станок, чтоб получить возможность планирования и конвертировать сайт в деньги нужен маркетинг и прочее, что не нужно станку. 
Но 1. покажите мне того кто покупает просто сайт без сопутствующих маркетинговых услуг (впрочем, такие люди есть и с этим кейсом ваша позиция вполне монтируется, действительно странно требовать с программиста, который натарабанил кучу говнокода каких-то странных ROI и т.п.) 2. если продают полный цикл, то чоб и не гарантировать каких-то метрик? Особенно, если в кейсах пишут, про то как они ловко увеличивают обороты и т.п. Это было бы очень сильным предложением, которое бы оправдывало огромные бюджеты.
Более того, я как человек определенным образом причастный к интеграциям, могу сказать, что крупные компании примерно так и работают. Есть определенные показатели, которые должны быть достигнуты. Достигли? Молодцы, вот вам бонус, не достигли — атата.
В общем правильно там выше кто-то писал, что нужно про продукт и услугу говорить, а не тыкать заказчика в ФОТ. Тыкать заказчика в ФОТ нужно, когда тебе пытаются докинуть каких-то задач, которые не вошли в договор, а не во время продажи, этапа согласования и переговоров.

Ответить
0

нужен маркетинг и прочее, что не нужно станку.

Нужен он. Как продавать продукцию завода без маркетинга ? Дорогущий станок лишь автоматизирует пачку процессов, либо создает новые, предположительно более прибыльные. Сайт ровно так-же. Так что сумму за сам сайт вполне нормально обсчитать за ФОТ + прибыль. Услуги же маркетинга и прочего - да, вполне можно продавать как польза, но при соблюдении обязательств бизнеса полностью выполнять все рекомендации по изменению своих процессов и их поддержке. Если нет - все, гарантия кончимшись.

Ответить
0

Нет не так. Все верно. Вы продаете не сам продукт , а ценность для заказчика от его использования. И именно об этом надо говорить в 80% случаев.
Вот пример на первую попавшуюся статью по этому поводу.
https://sendpulse.com/ru/blog/offer-value-to-customers

Ответить
0

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

Ответить
0

Почему разработчик должен считать прибыль за вас?

Считать прибыль это задача предпринимателя. Задача эта может быть относительно трудоемкой и не факт, что ожидание сойдется с реальностью. Тем более что проект может не пережить как кассовый разрыв (не учли какой-то фактор), так и плановый приход прибыли (вместо реинвестирования растащили на кайфы). Кто в таком случае будет отвечать за провал?

Может еще фин модель бизнеса построить? Стратегию продвижения, внутреннюю инфраструктуру расписать, риски оценить, поставщиков найти и предварительно договориться?

Хм, а зачем тогда нужен вообще заказчик. Проще сделать проект для себя и развивать его.

Итого: Научитесь воспринимать сайт/цифровой продукт как CAPEX и моделируйте его окупаемость на основании бизнес-гипотез, ожиданий и принимайте на себя предпринимательский риск, либо оплатите соответствующую работу специалистам.

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

А то какая-то предпринимательская инфантильность: создайте, пообещайте (у многих в голове сразу это означает, что за обещанное придется нести ответ), а я буду "управлять".

Ответить
0

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

Зачем заказчик? Ну у него есть, например, товаропоток, часть которого можно завернуть в ваше решение и продавать к обоюдной выгоде.

Увы, но комплексные решение могут предложить единицы интеграторов и команд, а остальные, в большинстве своём, предлагают какой-то квази-инструмент — в том смысле, что мы вот вам сайт сделали, а дальше сами. А сайт такой дорогой, потому что вон у нам сколько жопочасов в смете. Ну-ну, удачи.

Я могу еще долго рассуждать про недостатки такого подхода, но наверное для продажи своих услуг Васе с магазином одежды/палаткой шаурмы подход будет работать, пускай Вася сам занимается всем остальным и морщит мозг как с этого выхлоп поиметь. Только вот таких Вась всё меньше и меньше. Странным образом это коррелирует с развитием экосистем различного толка и подходов (no-code, сайты конструкторы, вот это всё).

Впрочем, если вы называете предпринимательской инфантильностью ожидание ответа на вопрос "как конкретно ваше решение за n-миллионов будет помогать моему бизнесу? и где про это в договоре написано?", то и с вами такой подход сработает. Ну просадили лям другой под пение про то, что разработчики у нас красивые и хотят кушать, ну с кем не бывает, предпринимательский риск, да? Хороший вы клиент:) 

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

В общем всё очень тухло и абсолютно уныло, хотя бы потому, что ФОТ и смета единственный ответ на такой большой и сложный вопрос "а чо так дорого?".

Ответить
0

1. Фин модель это услуги иного порядка и требуют определённых знаний. 

2. Зачем разработчику/ студии непрофильный актив со всеми вытекающими: риски, бизнес-процессы, косты на управление.

3. Аналитика (маркетинг, которого у бОльшинства бизнесов в РФ до сих пор толком нет), сайт, с учетом SEO (чтобы заказчик потом не переплачивал за доработки), дизайн решения, отвечающие целям и задачам - иногда кастомные и требующие "часов" на разработку (а не просто в стиле "я дизигнер, я так вижу), фронт-енд с Блэк-джеком, бак-енд без тормозов и, как минимум, консалтинг по контенту -  это уже более чем комплексно.

4. Конструкторам/шаблонам и прочему no-cod'у уже лет 20 как минимум, а воз и ныне там. Все вышеперечисленное позволяет сократить затраты на front/back, но: во-первых, эти затраты занимают лишь часть сметы, во-вторых, далеко не всегда целесообразно эти затраты сокращать, а иногда и вовсе невозможно - но тут речь о сложных проектах уже.

"Вася" для шаурмы может запилить лентой на "тильде", но когда "Вася" захочет замутить программу лояльности, настроить оповещения об обновлении ассортимента (ведь вокруг еще пять таких же палаток), откроет сеть, начнет стримить с кухни, захочет собрать статистику с точек, введет доставку и тд, то no-code непотянет.

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

5. "Предпринимательской инфантильностью" я называю желание скинуть ответственность за свои бизнес-процессы / риски на плечи разработчиков. 
Вот в этой фразе "как конкретно ваше решение за n-миллионов будет помогать моему бизнесу?" есть полуправда.
1) Разработчик должен обосновать дизайн решение и технологический подход: почему нужна такая структура и Х макетов (каждая страница - деньги), почему нужны такие-то фичи, почему нужны такие-то технологии, сколько будет стоить запилить "но-код" и сколько будет стоить переделать, если "товарооборот" попрет.

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

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

Подписываться же под разработку за долю в бизнесе - такое практикуется, но продавцом уже будет носитель идеи, чтобы его убедили отойти от "налаженных" бизнес процессов (которые могут быть налажены только при крупном ценнике и с соответствующим запасом времени на проект и окунуться в новый для себя мир с человеком, которого он видит впервые в жизни.
 
Работающий бизнес + аутсорсинг имеет ограниченные рамки и если у аутсорсера нет ресурсов/желания лезть в ваш бизнес, то смысл возмущаться - это и есть инфантильность. Со мной не хотят дружить, плохие хоббиты. Или как? Ушлость? На рынке полно предложений. Кто ищет, тот всегда найдет.

6. Почему, например, при строительстве завода не всегда берут в долю а) строителей, б) производителей оборудования? Но всегда на производстве должен быть условный главный инженер, который еще на стадии разработки проекта будет подбирать линию. И ничего, что з/п ему нужно платить 2-3+, пока завод строится?

Если предприниматель в век тотальной цифровизации не может принять решения по разработке, то следует такого человека найти, либо обучиться. Вот только на один дизайн интерфейсов до хотя бы middle уровня уйдет минимум год (теория + постоянная практика при full time загрузке, часов по 12 в день). А еще есть фронт-енд/бэк-енд, аналитика, цифровой маркетинг и ряд смежных дисциплин..

Это, кстати, именно те знания и опыт, которые в т.н. "жопочасы" входят + маржа + премия за риск и прочие расходы. Интересно, как назвать "часы", если я идеи во время пробежки генерю?

7. Отдельно. Если разраб разводит клиента пением, то это нечестный разраб. А клиенту нужно либо научиться разбираться в людях, либо считать, что купил опыт - обманы были, есть и будут, к сожалению. Корень этого вопроса лежит вне отрасли веб разработки. Как снизить этот риск? см п.6

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

Ответить
0

Ну так прибыль заказчика оценить не возможно.

Ответить
0

По хорошему конечно в такие бы договора включать KPI заказчика и при их достижениях доп.бонус. В таком случае у IT компании было бы стремление ещё круче делать проект.

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

Ответить
–1

Коллеги, вопрос, как вы закладываете повышаете планируемую рентабельность проекта - количеством часов или управляеете внешним рейтом (в проектах с повышенной рентабельностью рейт больше)? – "во время предварительной оценки мы закладываем больший процент рентабельности в маленькие проекты. Сделки до миллиона рублей должны приносить рентабельность 30% и более. Сделки от миллиона – 20%."

Ответить

Комментарии

null