Японский full stack-разработчик Такуя Мацуяма около 30 процентов времени он работает над «внешними» проектами, а 70 процентов времени тратит на собственные, но при этом его доход не уменьшается. Программист утверждает, что это стало возможным потому, что он перешёл с почасовой оплаты на попроектную. Мацуяма поделился опытом работы по такой схеме в своём блоге. dev.by приводит перевод записи.

Обычно я работаю со стартапами. Сначала я договариваюсь с ними о встрече и объясняю, что могу сделать для проекта. Объём и вид работы различается. Например, создание UI, front-end или back-end разработка, мобильные приложения, управление базами данных, анализ данных и т.д. После того, как мы оговорили задачи, я составляю оценку и предлагаю клиенту.

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

Но как правильно рассчитать стоимость проекта? Здесь нет каких-то универсальных формул или правил, но есть несколько критериев, на которые можно опираться при работе с любыми клиентами.

Доверяйте себе

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

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

Ориентируйтесь в ценах на рынке

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

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

Оцениваем проект

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

Критерий 1 — эффективность

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

Критерий 2 — срочность

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

Критерий 3 — специфичность

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

Критерий 4 — результативность

Разработка интересна тем, что при одинаковом ТЗ все разработчики выполнили бы заказ абсолютно по-разному. От разработчика будет зависеть качество конечного продукта. Минимальное приемлемое качество — продукт просто «работает». А если продукт ещё и нравится пользователям или засветился в СМИ, это повышает ценность разработчика. Но клиентам придётся доказать, что они получат действительно классный продукт: лучше один раз увидеть, чем сто раз услышать.

Не «продавайте» себя слишком дешево

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

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