Уже несколько лет я занимаюсь определением стоимости проектов по разработке, но в первые годы постоянно терпел провалы. Да, можно создать API за неделю, но если вы берёте за это копейки и работаете, как проклятый, то больше похожи на волонтёра, которому компенсируют хлеб и воду. Я бессчётное количество выставлял слишком низкий ценник, делал больше, чем от меня требовалось, а потом ощущал себя болваном. Этот пост — не какой-то манифест гуру; всему этому я научился, набив достаточно шишек. Если вы занимаетесь разработкой на фрилансе, возможно, мои ошибки уберегут вас от части мучений.

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

Сегодня я пользуюсь простым и понятным шаблоном ценообразования:

Внутренние расчёты: (Почасовая оплата_FE×Часы_FE) + (Почасовая оплата_BE×Часы_BE) + (Другие сотрудники)

Множители: Размер компании/Ценность × Срочность × Риск/Неопределённость

Оплата: 50% предоплата + поэтапные платежи, чётко определённые условия задержек/дополнительного объёма работ, точный масштаб и допущения, условия пересчёта стоимости

FE = Фронтенд

BE = Бэкенд

Эта формула наконец-то положила конец моим мытарствам с ценами за услуги. Чтобы выработать её, мне понадобились годы и куча потерянных денег, но вот, что важно: она не только хороша для вас, но понятна для клиентов. Если показать им такую разбивку, они перестают думать, что мы договариваемся о каких-то случайных числах, и начинают видеть логику. Они понимают, почему цена именно такая. Прозрачность и объяснимость позволяют избавиться от постоянных торгов, и внезапно непонятная фиксированная цена становится источником реального разговора с реальными числами.

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

1. Отталкиваемся полностью от проекта, без понимания времени

Самый большой провал в моей карьере: я ненавидел почасовую оплату. Я говорил: «Не, мне это не нужно, я ориентирован на результат». Вроде звучит круто, да? Нифига. Я приклеивал на проект ярлычок с ценой, допустим 20–30 тысяч долларов за то, что казалось быстрой разработкой API, а потом приходилось сталкиваться с реальностью. Мой график не полностью выделен только под одного этого клиента, возникают случайности и форс-мажоры. В результате всё тянется вечно. Я ощущал, что мне недоплачивают, потому что так и было. Клиентам нравятся фиксированные цены, потому что так они понимают максимум своих затрат, но если вы недооцените свою работу (а так и будет каждый раз), то вам придётся тратить часы бесплатно. Хуже того, когда проект «может занять неделю или месяц», я просто действовал по наитию, не оставляя буфер на наихудший случай.

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

Посчитайте в уме или в электронной таблице: почасовая ставка, умноженная на примерное количество часов с диапазоном для учёта неопределённости. Выставьте цену по верхней планке или разбейте стоимость на уровни и задайте чёткие правила, например: «если сработает вот это условие, мы выполняем пересчёт». Я так не поступал, и это больно било по мне.

2. Игнорируем множители и размер компании

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

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

Как же узнать реальный бюджет компании? Здесь всё довольно сложно. Иногда это публичная информация, которую можно узнать за десяток минут: финансирование Series B, отчёты о доходах, количество сотрудников в LinkedIn. А иногда приходится становиться детективом, делая догадки на основании впечатлений от офиса, размеров команды и того, как люди из компании говорят о деньгах.

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

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

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

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

3. Даём скидки из-за собственной ошибочной оценки времени

Это мучает меня до сих пор. Когда проект долго тянется, например, потому, что клиент не торопится с обратной связью или из-за превратностей жизни, я ощущаю вину. «Получилось дольше, чем я рассчитывал, вот вам скидка». Получается, я сам платил за свою работу. Такое случилось на четырёхмесячном заказе, где я и так продешевил. Все, кого я спрашивал, говорили, что подходящей ценой будет 20–30 тысяч долларов, но я обесценил себя и обжёгся. Причина задержек в 99% такая: клиент должен предоставлять контекст по своей бизнес-логике, недоступные вам знания предметной области, спецификации, написанные его командой разработчиков, и обратную связь по вашей работе. И каждый раз они не торопятся всё это давать. Теперь я сразу говорю: какая обратная связь мне нужна, какие материалы, какие знания предметной области. Перечислите все зависимости, за которые они отвечают, донесите до них, чтобы они знали, что это реальность, а затем внесите это в договор вместе с дедлайнами. «На пятый день клиент предоставляет документацию по API. Клиент проверяет этап 1 за 3 рабочих дня». Пусть это станет обязанностью клиента в чётко указанных временных рамках. Благодаря этому в случае задержек по проекту из-за того, что клиент две недели не даёт вам важный отзыв, это не вы компенсируете свои затраты, а он платит за вызванную им задержку.

Урок: добавляйте буферы для задержек. Если он переполняется из-за клиента, берите больше денег. Прозрачность побеждает вину. Скажите ему: «Это было запланировано на X часов, но из-за ваших задержек добавилось Y, поэтому я прибавляю Z долларов». Заранее объявите об этом в предложении: в случае непредоставления зависимостей со стороны клиента (обратной связи, ресурсов, доступа), то мы переходим на расчёты за время и материалы или меняем условия договора. Больше вы не будете допускать бесконечного растягивания проектов на фиксированной ставке. Добавьте временное окно, а после его исчерпания пусть клиент выплачивает обговорённую сумму или переходит на почасовую оплату, пока не разберётся с со своими организационными проблемами.

Это ваши условия задержек/дополнительного объёма работ в разделе «Оплата» формулы. Указывайте обязательства клиентов с дедлайнами, чтобы защитить себя на случай, если они станут причиной задержек.

4. Выбираем неподходящих клиентов

Половина моих первых заказов приходила от людей, которых кинули или начали игнорировать какие-то другие разработчики. Вроде бы, это должно быть выгодно? Абсолютно нет. Они травмированы и скупы, мы торговались за каждую копейку, а я уступал, потому что мне нужна была работа. Это было ошибкой. Мало платящие клиенты привносят драму, бесконечные пересмотры и увеличение объёмов проекта без дополнительной оплаты. Лучше общаться с меньшим количеством хорошо платящих клиентов, которые ценят тебя. Отфильтровывайте их надёжной логикой ценообразования. Если они будут против вашей прозрачной формулы (нижней границы почасовой оплаты, оценки проекта в часах, множителей), то отпустите их. Спокойствие всегда ценнее объёмов. Вся эта система, которую я показал, предназначена для отпугивания мусорных клиентов. Небольшая группа хорошо платящих клиентов всегда предпочтительнее кучи платящих плохо. Почему? Потому что дешёвые клиенты не просто плохо платят, но и постепенно стараются занижать цену, но ни в коем случае наоборот. Они увеличивают объёмы работ, ожидают, что ты будешь творить чудеса за копейки, и в результате оказывается, что ты жонглируешь пятью кошмарными проектами вместо двух стабильных. Чем больше клиентов, тем больше хаоса, трудностей с управлением и размазывания нагрузки. Если же выбрать небольшое количество хорошо платящих заказчиков, понимающих ваши расценки, то вам будет легче управлять работой, приятнее общаться и иметь больше времени.

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

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

Моя старая система была такой: задаток в 50% от общей суммы, 50% после cдачи готового проекта. Просто? Да. Глупо? Ужасно. Проекты растягиваются, клиенты не торопятся с обратной связью, вы пытаетесь получить тот последний платёж, а часики тикают. Моим кошмаром было увеличение объёмов проекта. Новые фичи приходят в виде «о, а можно добавить вот эту маленькую штуку?», а я соглашался, чтобы не расстроить клиента, превращая быструю победу в чёрную дыру времени. Я перешёл на поэтапную оплату: 50% сразу, а затем платежи за каждый этап, привязанный к конкретной сдаваемой работе. Это позволяет поставить проект на паузу, если клиент тормозит, и улучшает денежный поток. Заранее чётко определите объём проекта: список того, что в него входит, и допущения (например, «к третьему дню вы предоставляете ключи API»), сразу сообщаете, что добавление новых фич приводит к переоценке времени или оплачиваемым часам. Если вы быстро справляетесь с «простыми» задачами, которые кажутся сложными клиенту, то выставляйте счёт за ценность, а не за свою скорость. Больше я не позволяю своей интуиции занижать цену. Оценивайте восприятие клиента и пользу проекта для него.

Структура коммерческого предложения должна быть такой: 50% предоплата + поэтапная оплата, чёткий объём проекта и условия пересмотра стоимости и сроков. Поэтапная оплата защищает ваш денежный поток, чёткий объём предотвращает разрастание объёмов, а условия пересмотра не позволяют новой работе превратиться в бесплатную.

6. Игнорируем почасовой расчёт даже в случае фиксированной оплаты

Да, я говорил об этом выше, но возвращаюсь, потому что эта ошибка стоила мне больше, чем остальные вместе взятые. Обычно я отказывался от почасовой оплаты, потому что это казалось наёмным рабством. Я слишком поздно понял, что почасовой расчёт — это не про оплату за часы, а ваш внутренний ориентир. Оцените свою ставку (фронтенд, бэкенд, фулстек, сверьтесь с рыночной оплатой), умножьте на количество часов, добавьте множители объёма проекта или величины компании. Не всегда стоит показывать их в разбивке; чаще всего вы просто сообщаете окончательное значение. Но когда клиент начинает сомневаться, пытаться дать заднюю или выказывать недоверие, настаёт время сорвать занавес: «Вот моя ставка, оценка нагрузки в часах по причине X/Y, плюс множители под вашу ситуацию». Прогрессивное раскрытие. Вычисления защищают вас от провала. Когда в проектах возникают проблемы и клиенты начинают обвинять вас, у вас все записаны все ходы: «Мы выбились из графика из-за задержек вашей команды, поэтому добавляется дополнительная оплата». Я в течение долгих лет не делал этого, и в некоторых заказах моя реальная ставка снижалась практически до минимальной оплаты труда. Теперь же у меня есть тайное оружие, всегда подсчитанное и извлекаемое в случае необходимости. Хватит верить лозунгам «просто бери больше» без системы; эти громкие фразы не работают без поддержки математики. Замените эти нечёткие советы принципом: базовая ставка × часы × множители + буферы + поэтапный план. Это ваш фундамент. Всё остальное — показуха.

Всё это приводит нас такой формуле: (Почасовая оплата_FE×Часы_FE) + (Почасовая оплата_BE×Часы_BE) + (Другие сотрудники) — вашему внутреннему математическому фундаменту. Вычисляйте его всегда и раскрывайте клиенту с умом. Без этой опоры вы будете просто гадать.

Подведём итог

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

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

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

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

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

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

Дело не в страхе больших сумм. У меня никогда не возникало проблем в выставлении больших счетов, если они рассчитаны по системе. Но без системы вы просто гадаете. Лозунги «просто бери больше» хорошо звучат, но бесполезны без математики.

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