«Сколько стоит?» Рассказываем, из чего складывается стоимость дизайна и разработки IT–продукта

Меня зовут Владислав, я руководитель продуктовой разработки в студии Art UX. Больше 5 лет я помогаю компаниям и стартапам создавать и развивать продукты digital. Кроме этого, с 2021-го года мы провели сделку по слиянию со стартапом «Арента», и сейчас разрабатываем первый нон-хьюман сервис в сегменте почасовой аренды коммерческой недвижимости.

За 5 лет я столько раз готовил оценки объемов и стоимости работ, что ни за что не вспомню. При чем, часть из них выдвигались на основе эксель-таблиц с времязатратами, а часть, что называется, «от балды». И, к слову, второй метод нередко оказывался более точным.

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

То есть ни при каких обстоятельствах невозможно точно учесть, сколько внутренних часов сотрудников израсходуется на дизайн или разработку. Об этом можно узнать только по факту.

И тем не менее, до сих пор огромная доля проектов на заказную разработку заключается по модели фиксированной цены:

— Сколько стоит?
— Два миллиона.
— Ну ладно.

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

А вот тут давайте поподробнее. Наценка за риски — это цифра, которая появляется в голове сметчика, опираясь на его опыт работы с подобными проектами. А вот насколько она достоверна, никто гарантий не несет: может он заложит +10%, а может +40%. По итогу, выходит сумма, которую и без смет можно было бы назвать «от балды».

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

— Ну давай сделаем эту штучку.
— Ну давай не будем.

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

Какие есть альтернативы?

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

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

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

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

Time & Materials.

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

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

1–2 раза в месяц студия присылает отчетные листы, в которых указывается сколько времени и на что ушло. На основе них выставляются акты. Если необходимо, дополнительно могут прикрепляться отчеты из программ, фиксирующих время за работой. Например, из Timing App. Это в принципе, полезный софт для Mac, чтобы отслеживать, куда делось время за день.

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

О ставках за час.

Чтобы понять, какую ставку считать нормальной, а какую завышенной, ниже я предложу незамысловатую формулу, где ±30% от результата — это справедливая цена.

(Рыночная зарплата специалиста /160 часов) × 2.5

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

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

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

Retainer или Outstaff.

Формат, при котором заказчик на определенный период арендует готовую команду, и, зачастую, соединяет её со своими менеджерами. Способ предусматривает, что команда студии может работать прямо из офиса заказчика. Оплата фиксированная за команду в месяц. Если проект большой, то получается выгоднее, чем при модели Time & Materials.

Логичный вопрос — зачем арендовать дизайнеров или разработчиков у студии, если можно нанять своих?

Подробнее об этом рассказали в статье о сочетании собственного штата и подрядчиков, но если коротко, то главных причин три:

1. Уровень компетенций, который долго придется хантить или растить.

2. Сработанность. Свои подходы и понимание друг-друга с полу-слова.

3. Не нужно разбираться с зарплатой.

Резюме.

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

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

0
5 комментариев
Дмитрий Вершанский

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

Ответить
Развернуть ветку
Юрий Антузинский

Я не понял, какие среднепостоянные и заведомо известные тайминги вы имеете в виду. Если речь не о конвейерном производстве (почти) без согласований. 

Круто платить за результат. Но факт в том, что в начале проекта заказчик примерно представляет, что ему нужно для решения бизнес-задач, а разработчик (агентство) - примерно представляет, как это можно реализовать.

Дальше начинаются подводные камни каждой отдельной функциональности и человеческий фактор. 

Есть студии, которые умеют флексить (оставлять только приоритетную функциональность), чтобы доставить результат точно в срок. Но таких мало. С большинством адекватно работать под T&M, а если смета выглядит подозрительно - задавать вопросы и расставаться при необходимости.

Ответить
Развернуть ветку
Дмитрий Вершанский

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

Ответить
Развернуть ветку
Павел Шабалин

Согласовывать часы можно же "на берегу"? Я как разработчик, работаю именно по таймингу, клиент вправе взять на проект несколько специалистов и например отдать задачу в оценку нескольким ребятам, чья ставка устроит за работу, тому и задача. Есть только одно большое НО, заказчик должен уметь в проджекты и менеджерить свой проект.

Ответить
Развернуть ветку
Дмитрий Вершанский

Вы сами вывели себя на "чистую воду".

Ответить
Развернуть ветку
2 комментария
Раскрывать всегда