— Я не продаю часы, — ответил я.

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

— Я обычно оцениваю работу под ключ. Часовой ставки у меня нет.

— У всех есть такая ставка, хотят они того или нет.

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

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

Почему же я сразу не назвал своей часовой ставки?

Да потому что она слишком высокая для рынка! И плавающая. Сейчас объясню.

Но для начала о себе. Я — проектировщик интерфейсов. Точнее, так моя профессия называлась 10-15 лет назад. Сейчас она раздробилась на системных и бизнес-аналитиков, UX и UI-дизайнеров, UX-писателей, менеджеров проектов и ещё много других. Сегодня, если кто-то не понимает, чем я занимаюсь, я отвечаю проще: «Собираю функциональные требования, делаю интерактивные прототипы и пишу функциональные спецификации». Хм, перечитал и вижу, что, похоже, не намного проще. Ещё можно сказать, что я на 50% системный аналитик, на 40% UX-дизайнер и на 10% — всё остальное.

В общем, в 2008 году я был простым проектировщиком, и мой час для клиентов на фрилансе стоил 1000 рублей. Тогда это было чуть выше рынка, но в целом клиентов устраивало. Хорошо работало сарафанное радио, в портфолио уже было около сотни прототипов (плоды работы в агентстве Webaster.spb). Моими услугами интересовались, в основном, другие агентства. Работа по часам казалась им достаточно прозрачной.

Через какое-то время начались проблемы. Я, как машина, делал прототип за прототипом и внезапно понял, что всё реже сталкиваюсь с уникальными задачами. Это я уже делал, то я уже делал. В тот период были популярны интернет-магазины и социальные сети — и придумать там что-то новое было довольно сложно. После пяти соцсетей и десяти интернет-магазинов ты работаешь, как по шаблону.

И там, где я раньше тратил на интернет-магазин 50 часов, теперь всё делал за 10. А соцсеть, на которую раньше уходило 250 часов, теперь занимала меньше 100.

То есть, тратя столько же ресурсов на привлечение новых клиентов, как и раньше, я в итоге стал зарабатывать от двух до пяти раз меньше, чем мои коллеги. Вы можете подумать: «Ну и что? Просто берёшь больше проектов — и готово!». Но это так не работает. Во-первых, они на дороге не валялись (и не валяются). Во-вторых, цикл заключения сделки иногда растягивался на месяцы. В-третьих, мои скорость и качество могли оценить только те, кто уже поработали со мной (и имели возможность сравнить с другими), поэтому по факту я не обладал никакими конкурентными преимуществами на рынке.

Что делать в таких условиях?

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

Затем я попробовал повысить стоимость часа. Но зачем работать со мной за 3 000 в час, если рынок наполнен предложениями по 1000? Агентства не готовы были платить дороже 1 500.

И тут я понял одну вещь. Если средний проектировщик тратит 90 часов на проектирование интернет-магазина и получает за это 90 000 рублей, то почему бы мне не продать такую же работу под ключ за те же деньги, но сделать за 20 часов? Получается по 4 500 в час. Но мне и 3 000 хватило бы! А значит я автоматически мог называть цены даже ниже рынка и при этом зарабатывать больше!

О, это был очень интересный период! Поначалу я набил несколько шишек, ошибившись в расчётах. Например, оценивал, казалось бы, типовой проект в 100к, а потом получалось, что делал его 70-80 часов, приближая ставку к минимальной.

Это привело к тому, что я стал более внимательно и тщательно погружаться в детали до начала работ. И иногда это было непросто. «Я же уже делал нечто подобное, ну что там может пойти не так?». Вот такие мысли были навсегда вытравлены из моей головы переработками там, где я просто недостаточно пообщался с клиентом перед стартом.

Затем я понял, что оценка под ключ выглядит более надёжно и понятно в глазах клиента. Сравните:

— Я сделаю эту работу за 100 часов. Стоимость часа — 2 000 рублей.

— Я сделаю эту работу за 200 000 рублей и календарный месяц.

Вы тоже чувствуете, как в первом предложении повисла угроза: «А если он не уложится в 100 часов, я ведь буду должен дальше платить по 2 000 рублей в час, верно?».

Второе предложение как будто от такого избавлено. Если исполнитель не справится и не уложится в срок (что происходит сплошь и рядом) — 200 000 останутся неизменными, а сроки растянутся.

И уж совсем мало людей подумают, глядя на второе предложение: «Хм, а что, если он сделает этот проект за 20 часов?». А я делал! И это была лучшая эпоха в моей работе. Которая продлилась где-то до 2017 года.

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

Так постепенно в моих функциональных спецификациях стали появляться всё новые и новые тезисы, связанные с валидацией данных, сообщениями об ошибках, неявными сценариями взаимодействия пользователей с системой. Работая над прототипами я начал задаваться всё большим количеством вопросов: «А что, если?». А что, если пользователь перезагрузит вкладку во время заполнения формы? А что, если в списке будет больше 100 000 строк? А что, если у нас привязка к региону, а пользователь не делится этой информацией? А что, если у нас в кукис хранится информация, конфликтующая с информацией, записанной в профиле аутентифицированного пользователя? И так далее, и тому подобное. Вот эта моя статья на Хабре про проектирование форм хорошо иллюстрирует ситуацию.

Чем больше аспектов я охватывал во время проектирования, тем больше у меня на это уходило времени.

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

И там, где я раньше потратил бы на типовой интернет-магазин (условный — потому что ну о каких уже интернет-магазинах может идти речь в 2025-м?) 10 часов, теперь спроектировал бы его за 20-30. Но не упустил бы ни одного аспекта, ни одного нюанса. Учитывал бы весь дальнейший путь его разработки и делал бы всё возможное, чтобы помочь программистам сделать их работу быстрее и качественнее.

Теперь, оценивая новые проекты под ключ, я дополнительно стал учитывать человеческий фактор. Сколько часов клиент и его команда могут посвятить погружению меня в контекст? Сколько понадобится времени на промежуточные согласования? Если проект длинный, на несколько месяцев — кто устанет первым или внезапно исчезнет на отпуск? Я также стал учитывать такой параметр как: «Надо сделать быстро и только основные функции, чтобы проверить гипотезу на этапе MVP или же это что-то серьёзное и хорошо финансируемое, что нужно проектировать с горизонтом планирования в два-три года?». В портфолио стали появляться ERP-системы, сервисы и low-code платформы — и это тоже добавило нюансов в оценке (поправка на размер и растянутость во времени).

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

Возвращаясь к рассказу из начала статьи. Честный и прямой ответ звучал бы так:

— Один час моей работы стоит от 10 000 рублей.

Но кто будет работать с таким проектировщиком? Никто (хотя вот я перечитываю свой текст перед публикацией и в этом месте глубоко задумываюсь: а откуда у меня такой вывод; так что здесь отдельный акцент на моей субъективности). Всегда можно найти кого-то в штат за 200−300к в месяц. Тогда компании, с учётом налогов и прочих расходов, придётся выложить за него 300−450к. И он за эти деньги будет должен отработать 160 часов в месяц по 2.8к в час (получая на руки 1.8к).

И не важно, что человек с ценником в 10к в час сделает работу за месяц и 400-500к, а сотрудник — за три. Такую цену называть просто нельзя. Только под ключ. Только после того, как очень внимательно оценил работу перед тем, как за неё взяться.

В итоге я за последний год всё больше склоняюсь к ещё одной схеме. С абонентской оплатой. Подход хорош в долгих и сложных проектах (ах, какой это кайф: тратить на погружение пару месяцев — и потом не искать следующий проект, где снова надо погружаться). Называть месячную ставку в рынке или чуть выше рынка (для моей профессии и стажа — это 150−250к в месяц в России). И так как я ИП на упрощёнке и работодателю не нужно платить за меня дополнительные 40% — это может показаться даже выгоднее найма в штат. Единственно, мне всё-таки кажется, что для компаний, к сотрудничеству с которыми действительно стоит стремиться, размер ежемесячной оплаты в принципе не будет стоп-фактором.

Так, всё, подвожу итоги.

Выводы по почасовой оценке.

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

  • Есть возможность приврать. Сделал работу быстро — накинул немного часов сверху. Слишком долго возился — скинул часов, чтобы не выглядеть слабо;

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

  • Постоплата. Это минус;

  • Высокая стабильность. После того, как наберётся пул клиентов, при продаже часов всегда найдётся какая-нибудь работа.

Выводы по попроектной оценке.

  • Нужен опыт, иначе будет много ошибок в расчётах;

  • Предоплата. Это плюс;

  • Непрозрачная стоимость часа. Это даёт возможность заработать на одном проекте гораздо больше, чем при почасовой оценке;

  • Проще продать, т.к. у клиента нет страха, что исполнитель проработает ну очень много времени;

  • Низкая стабильность. Сделал проект — берёшься за следующий. Тебя с меньшей вероятностью привлекут на следующие этапы, если не придумаешь какую-нибудь абонентскую историю или не озвучишь стоимость часа (а реальную стоимость часа озвучивать нельзя).

Выводы по абонентской оплате (без оценки).

  • Все плюсы попроектной оценки и при этом отсутствие её минусов;

  • Можно не особо ориентироваться на рынок и играть по своим правилам;

  • Сверхвысокая стабильность. Это как обычная работа с зарплатой, но при этом спокойно можно работать сразу на нескольких работах без использования термина «на пол-ставки»;

  • Из минусов: гораздо сложнее совершить сделку, чем во всех остальных случаях.

Комментарии (5)


  1. IosifLvovich
    24.06.2025 03:33

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

    Откровенно говоря, не понял, в чём проблема. Судя по

    И там, где я раньше тратил на интернет-магазин 50 часов, теперь всё делал за 10. А соцсеть, на которую раньше уходило 250 часов, теперь занимала меньше 100.

    заказчики были готовы платить 50к за магазин и 250к за скотсеть по старым строкам. И всё их устраивало. Ну так оставайся в тех же ценниках, но сделай предложение а-ля "а если хотите быстрее, то цена х3".

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


  1. 40kTons
    24.06.2025 03:33

    Выводы по абонентской оплате

    Вы изобрели работу за оклад? Т.е. просто как у почти всех?


    1. ky0
      24.06.2025 03:33

      О, господи - только бы не начал про это книгу опять писать...


  1. nikolz
    24.06.2025 03:33

    Мое мнение такое:

    Автор путает наем работника(почасовая оплата) с покупкой или арендой готового продукта.

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

    -------------------------

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

    ----------------------------

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

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


  1. zurabob
    24.06.2025 03:33

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