Привычным способом формирования цены работ в ИТ-сфере является оценка числа нормо-часов, и умножение на цену часа — совсем как в автосервисе. Оба числа — и количество часов, и стоимость одного часа — заказчику обычно приходится принимать на веру. Стоимость часа в гораздо большей степени зависит от баланса спроса и предложения, а также самооценки продавца, нежели от объективных факторов, связанных с затратами на разработку. Давайте проанализируем механизм формирования цены на ИТ-услуги, чтобы решить, сколько же стоит разработка на самом деле.

Итак, во-первых, говорить нужно о двух ипостасях стоимости часа:

— себестоимости, то есть той сумме, которую компания прямо или косвенно тратит на обеспечение работы программиста, и

— отпускной цены, которую за этот час платит клиент.

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

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

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

Понятно, что если Z < X, то Заказчик просто не будет заказывать продукт. А если Z > X, то Заказчик сэкономит деньги, и фактически получит прибыль свыше «запланированной». На практике та цена N, на которой сойдутся Заказчик и Подрядчик, лежит где-то между X и Z, и зависит от качества менеджерских усилий с обеих сторон (а также от сроков, брэнда, конкуренции и т.п.).

Эффективную цену, устанавливаемую для Заказчика (N), логичнее рассматривать с точки зрения теории предельной полезности. Если спрос в каких-то сегментах разработки превышает предложение, то редкость услуги начинает существенно влиять на ее стоимость. Она является тем фактором, который двигает цену сделки N от значения X вверх к Z. Конечно, ни одному Заказчику не захочется переплачивать за продукт, который «объективно» (то есть с позиций марксистской теории, которая на интуитивном уровне крепко сидит в голове у многих из нас) этих денег не стоит. Экономный Заказчик попробует найти поставщика, который сделает то же самое, но подешевле. Такой подход ведет к ситуации, которая сложилась на рынке разработки сайтов: заборы пестрят объявлениями о создании сайтов за 3000 руб. и меньше, то есть себестоимость труда разработчика потенциально стремится к нулю (как и стоимость производимых ими продуктов). Это очень усложняет жизнь тем, кто делает сайты за более адекватные деньги.

Также влияет на цену рыночная стратегия Подрядчика. Часто компания проходит естественный путь от бюджетных работ на массовом рынке, необходимых для набора первоначальных компетенций и выработке брэнда, до работы с премиальными заказчиками. Многие сознательно остаются в бюджетном сегменте, стараясь «взять количеством», и заработать благодаря тиражным решениям; некоторые стремятся попасть в премиум-сегмент с самого начала, используя иногда довольно оригинальные стратегии. Обычный же путь компании-разработчика в «колесе жизни» выглядит так.

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

Серьезной проблемой рынка разработки является недостаток квалифицированных кадров. Проще говоря, очень сложно наращивать количество хороших разработчиков, потому что их физически мало на рынке; перекупить их, чаще всего, не получается. Следовательно, компания ограничена тем производственным ресурсом, который она получила в результате «выращивания» собственных кадров, с небольшим плюс-минусом. С экономической точки зрения это означает, что потолок доходности бизнеса по заказной разработке известен, и компания не может рассчитывать на его радикальное увеличение (что для любого бизнеса звучит просто ужасно). Точнее, не может рассчитывать на серьезное увеличение прибыли за счет увеличения объема выполняемых работ. Остается путь повышения цены, путешествия вверх по кривой зависимости количества заказов от цены за час (цена выше, заказов меньше).

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

Сказанное объясняет существование на рынке множества компаний, предлагающих, в сущности, одну и ту же услугу по ценам, отличающимся на порядки. Конечно, роль в формировании такой ситуации играет и специфика крупных заказчиков: многие из них принципиально не могут заказать разработку, стоящую дешевле десятков миллионов рублей. К такой разработке обычно добавляется консалтинг, цена которого часто превышает размер контракта на разработку. Дело здесь не только в коррупционных практиках. Для менеджеров со стороны крупных заказчиков, принимающих решение о выборе подрядчика, крайне важно застраховать себя на случай неудачи; эту страховую премию с удовольствием получают именитые консалтинговые и ИТ-компании, часто не имеющие вообще никаких ресурсов, кроме имени и талантливых менеджеров по продажам. Работа затем обычно сдается на субподряд, потому что экономика таких компаний основана совершенно на других принципах. Фактическое выполнение работ было бы для них лишней обузой.

Главный наш вывод состоит в следующем: оценивать стоимость услуги нужно с позиций ее ценности для заказчика, а не себестоимости. Кроме того, покупая услугу, надо быть готовым к тому, что зависимость качества от цены имеет нелинейный характер. То есть, небольшое повышение качества услуги может привести к серьезному повышению ее стоимости. А дальше уже дело каждого конкретного Заказчика — решить, нужно ли ему это качество, или он готов повысить свои будущие риски ради экономии.

Вместо приложения: расчет стоимости нормо-часа, основанный на затратах.

Вернемся к началу нашего рассуждения, и попробуем рассчитать себестоимость и отпускную цену труда программиста. Стартовым компонентом себестоимости является, конечно же, зарплата. Предположим, что программист получает «на руки» 80 т.р. в месяц. С учетом налоговой нагрузки, при использовании льготного налогового режима, затраты для предприятия на его зарплату составят 114 т.р. Все-все-все затраты на офис, уборщиц, бухгалтера, электричество, амортизацию оборудования, по моему опыту, не превышают 15 т.р. в месяц на сотрудника. Сложив ее с предыдущим результатом, и немного округлив, получим сумму в 130 т.р. Теперь разделим ее на 176 рабочих часов, содержащихся в месяце, и получим цифру 740 рублей в час. Можно ли «накрутить» на нее прибыль, и продавать по такой цене час клиенту? Конечно же, нет.

Во-первых, нельзя думать, что все 176 рабочих часов будут проданы клиентам. Понятно, что при заключении сделки с клиентом стоимость, так или иначе, формируется исходя из оценки количества часов, которые будут затрачены на выполнение работы. Кстати, многие заказчики придерживаются точки зрения, что они платят за результат работ, а не за часы; в таком случае разговор с ними легко будет перевести в плоскость оценки ожидаемого экономического эффекта от этого результата. Подрядчик же в любом случае закладывает на выполнение работ какое-то количество часов. Теоретически, часы закладываются «с запасом», но на практике часто получается, что фактическая трудоемкость превышает расчетную, потому что:

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

— программист отчего-то работал медленнее, чем предполагалось,

— при оценке не были учтены какие-то факторы, и недооценена трудоемкость,

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

Еще есть процесс отладки и устранения ошибок, который может занять больше времени, чем сама разработка. В общем, по моим наблюдениям, среднестатистической является ситуация, когда из 176 рабочих часов в месяц заказчик реально платит за 120 (и то, достижение такого показателя стоит серьезных управленческих усилий). Соответственно, цену приходится «масштабировать» — получаем себестоимость уже 1080 рублей за час.

Мы учли труд программистов и «технического» персонала (бухгалтеры, уборщицы и т.д.), но есть и другие участники процесса, которые «обслуживают» программиста. Как минимум, это менеджер по продажам, руководитель проекта и/или постановщик задач, а также тестировщик. Проще всего не загромождать ими таблицу цен, вызывая у клиента ощущение, что стоимость проекта пытаются раздуть за счет увеличения числа часов, а включить их в стоимость часа программиста, что на практике и делается. Предположим, что каждый из перечисленных сотрудников обеспечивает работой (или обслуживает) четырех программистов. Округлим число этих специалистов до двух, положим им такую же зарплату, как программисту, и в результате нехитрых вычислений получим стоимость часа программиста, равную 1625 рублей.

Наконец-то мы можем перейти к вопросу наценки. Предположим, нас устроит чистая прибыль в 20% (да еще 15% налога мы уплатим с разницы между доходами и расходами). Получается, что час работы программиста можно продать клиенту за 2000 рублей. Скрестить пальцы и надеяться, что не будет таких проектов, где клиент с нами не расплатится, что не нужно тратиться на найм новых сотрудников (первые несколько месяцев они не приносят прибыли, то есть их нужно финансировать за счет компании), не нужно развивать собственные проекты и решения... Очевидно, что так не бывает. Премию на подобные расходы каждая компания определяет самостоятельно. Однако и без нее мы достигли более чем двукратной разницы между «зарплатной» частью себестоимости (740 руб.) и отпускной ценой (2000 руб.).

Оригинал: http://serge-gorshkov.livejournal.com/12637.html