Pull to refresh

Comments 22

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

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

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

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

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

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

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

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

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

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

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

Обещаю, в этот раз обошлось без книги. Если и будет следующая книга — то именно о проектировании интерфейсов, а не чём-то, связанном с карьерой.

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

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

Такой подход редко нужен всем подряд, но оказывается полезен в сложных проектах.

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

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

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

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

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

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

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

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

Спасибо за комментарий! Есть важная специфика моей работы, которую, возможно, стоит отдельно пояснить.

Обычно на момент, когда я подключаюсь, у клиента как раз ещё нет готового ТЗ — оно появляется в процессе моей работы. Я как раз и занимаюсь тем, чтобы на основе обсуждений, требований бизнеса, технических ограничений и нюансов процессов собрать и оформить рабочую проектную документацию: прототипы, спецификации, схемы взаимодействий. То есть я не столько выполняю работу «по ТЗ», сколько создаю саму основу для будущей разработки.

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

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

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

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

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

Вы же пытаетесь разработать тех задание бесплатно, а потом сетуете, что Ваша работа стоит больше.

Попробуйте разделить мух от котлет.

Либо заказчик дает Вам тех задание и Вы делаете то, что там написано.

Либо Вы сначала разрабатываете ему тех задание (это отдельная и самостоятельная работа), а потом делаете то, что там написано.

Тех задание заказчик может заказать Вам или не Вам, как и работу по этому тех. заданию.

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

По аналогии. Архитектор -проектирует дом, а строитель - строит его по проекту.

Было бы прикольно, если бы строитель строил дом без проекта, а архитектор делал проект бесплатно,а потом строил дом заказчику.

Тех задание — это довольно абстрактное понятие. В каждом коллективе люди вкладывают в него разное значение.

Я обычно пишу функциональные требования к проекту, которые и становятся тех заданием на проектирование. А результат проектирования — тех заданием на разработку.

Если проект не объёмный и сбор первоначальных функциональных требований можно уместить в 1-3 часа, я действительно делаю эту работу бесплатно.

Если работа по составлению ФТ сама занимает много времени — я оцениваю её под ключ (обычно в диапазоне от 10 до 100к).

И я не сетую, что моя работа стоит больше. Точнее, до вашего комментария, я не думал, что сетую. Но со стороны-то всегда виднее. Спасибо за обратную связь!

В СССР был гост на тех задание на программное обеспечение.

Сейчас есть стандарты и требования на проектирование сооружений

Если нет тех задания, то что Вы делаете?

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

Тех задание должен делать заказчик - это и есть его хотелки. Только он знает что он хочет.

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

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

Спасибо, вы очень точно сформулировали.

Я как раз в статье описываю свой опыт в ситуации, когда проекта ещё нет, ТЗ ещё нет, а задача стоит как раз в том, чтобы этот фундамент для разработки создать.

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

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

Вроде на хабре была статья или большой коммент к статье, где была история про составителя смет или типа того. Он документы какие-то считал и оформлял. Клиенты были рады, всё хорошо. Но потом он оптимизировал работу - написал скрипт, с которым он раз в 25 быстрее всё делал. Однако ставку часовую не поменял, потому что суть не поменялась и приписывал часы по старому расходу времени.

А потом, однажды, ему попросили очень-очень срочно всё сделать и прислали 30 документов. И он их по быстрому сделал и отправил. А в ответ получил вопрос - "Как это? Полторы минуты на документ?! Мы вам платим за работу чтобы вы её делали, а её оказывается можно делать так быстро и вы делаете программой какой-то?!" И в итоге они оплатили эти документы, но больше не приходили, чувствуя себя обманутыми.

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

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

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

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

Хоть почасовая, хоть проектная, хоть "абонентка", хоть в каких угодно попугаях - как бы фрилансер ни экспериментировал с бизнес-моделями - но пока вы обмениваете результат своего труда на деньги - вы все равно продаете услугу, что очень слабо поддается масштабированию. Как бы вы ни переизобретали услугу по контактной разработке - услугой по разработке она от этого быть не перестает. Фрилансер остается фрилансером с доходом, сопоставимым с доходом трудоустроенного по ТК работника-удаленщика аналогичной квалификации, но без оплаты больничных, отпусков и отчислений в пенсионный.

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

Понимаю вашу точку зрения — я сам поначалу так рассуждал.

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

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

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

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

Но в данной статье я сознательно не касался темы масштабируемости, соцпакета, отпусков и т.п. Она не об этом. Это просто мой личный опыт того, как я за 20 лет прошёл три модели оценки проектной работы: почасовую, попроектную и абонентскую. За это время у меня было около 300 клиентов и команд — отсюда и делаю свои выводы.

Поэтому мне, честно говоря, в вашем комментарии даже больше интересен не ваш вывод, а ваш контекст: какой у вас личный опыт в работе по найму, на фрилансе? Как вы сами оцениваете свою работу? Как выбираете модель — почасовую, проектную, абонентскую? Почему?

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

какой у вас личный опыт в работе по найму, на фрилансе? Как вы сами оцениваете свою работу? Как выбираете модель — почасовую, проектную, абонентскую? Почему?

Фрилансил лет 5. Разрабатывал электронику под ключ. Фриланс помог набраться опыта, наметить интересные направления/ниши, научиться делегированию, но каких-то ощутимых денег не принес, увы. 

Тогда еще был доступен зарубежный заказчик (через тот же Upwork)

у фриланса тоже не такие уж низкие потолки, как принято считать

В итоге пришел к выводу, что даже с напряжением всех морально-волевых качеств навряд ли удастся выйти на стабильные 1 млн/мес. Сейчас же, когда доступен только Российский заказчик, который, очевидно, менее платежеспособен, чем Европейский или Американский, думаю и того меньше.

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

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

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

Да, стабильный миллион на фрилансе — это для меня задача не из лёгких. Но выполнимая. Я только однажды заработал чуть больше миллиона в апреле 2019 :) А потом в следующие полтора месяца — ничего. Но всё равно, тот апрель послужил мне живым примером выполнимости задачи. А миллион тогда и миллион сегодня — это разные миллионы.

А что за продукт разрабатываете?

базовые станции LoRaWAN

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

Что касается попроектной оплаты, то она тоже должна основываться на почасовой оценке, иначе потом по факту выйдет, что проект вроде и дорогой, но делаешь ты его полгода, с трудом покрывая расходы на свои повседневные нужды

Sign up to leave a comment.

Articles