Search
Write a publication
Pull to refresh

Comments 108

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

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

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

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

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

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

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

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

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

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

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

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

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

Я об этом писал у себя в книге про фриланс в главе «Профессиональные и непрофессиональные клиенты».

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

Как говорил монтер Мечников: "согласие есть продукт при полном непротивлении сторон". Мне кажется, что вы решаете проблему, которую сами себе и выдумали.

Если сайт требует 50 часов работы специалиста, чей час оценивается в 1000р, и клиент готов платить за это, то значит ровно столько создание сайта и стоит. Если вы тратите на создание сайта в 5 раз меньше времени, то это просто означает, что ваша квалификация выросла, и стоимость вашего часа работы так же выросла в 5 раз. Но это ваше личное дело, сколько времени у вас уходит на работу, а для клиента сайт как стоил 50 условных человеко-часов, так столько и стоит.

это просто означает, что ваша квалификация выросла,

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

стоимость вашего часа работы так же выросла в 5 раз.

продукт согласия же. Если стоимость вашего часа выросла, но клиент сколько платить не готов, и сделка не состоялась - стоимость часа равна 0.

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

Поставьте себя на место заказчика: вы ведь в разработке ПО покупаете не товар, а услугу мастера.

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

В заказе услуги и плате по-времени есть очень неприятный риск - где гарантии, что проект будет выполнен за оговоренные 100 часов, а не растянется на 300? А на 300 у меня может бюджета не хватить или же при такой стоимости он в принципе становится мне не интересен.

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

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

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

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

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

Никаких гарантий, но если исполнитель работает с задачами "под ключ", оценил сам для себя задачу в 100 часов и выставил их заказчику в виде фиксированной суммы в инвойсе, а по факту он ошибся, и задача для него заняла 300 часов, то он этот риск сам за свой счёт и будет покрывать. А в случае почасовой работы риск перекладывается как раз на заказчика. Вам как удобнее было бы?

Никаких гарантий, но если исполнитель работает с задачами "под ключ", оценил сам для себя задачу в 100 часов и выставил их заказчику в виде фиксированной суммы в инвойсе, а по факту он ошибся, и задача для него заняла 300 часов, то он этот риск сам за свой счёт и будет покрывать. А в случае почасовой работы риск перекладывается как раз на заказчика. Вам как удобнее было бы?

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

Это примерно как со строительством. Да, в итоге я хочу получить здание, как готовый результат всех работ. Но в проекте здания у меня всё нормировано. Я знаю объемы земляных работ, знаю, сколько кубометров бетона будет уложено, сколько кабельных трасс проложено, сколько квадратных метров отделочных работ выполнено. Знаю стоимость материалов, необходимое время и стоимость услуг работника. Это для меня прозрачно, и я, как заказчик, могу оценить, в рынке ли полученное мной предложение, или нет.

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

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

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

Платить как будем по объему сделанного из рыночной цены или по потраченному времени конкретно этого исполнителя игнорируя его особенности?

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

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

Во фразе "а если хотите быстрее, то цена х3" есть одна очень большая проблема. Клиенты могут вообще не понимать, как работает среднестатистический дизайнер/разработчик и так далее. Потому что обьективный жизненный час не всегда равен часу работы. И увеличенная скорость часа - это условно ускорение юнита, который может растягиваться на неопределённый календарный срок. Условно, есть лендинг на 5-6 страниц, простой. Я могу его сделать за 8 часов - это 1 день. А могу по 2 часа в течении недели. Должен ли заказчик платить за 1 календарный день вместо 4-х? В моей практике, это тяжело обьясняется.

Не скажу, что универсально, но в свое время, получив требование объяснить разницу, мне пришлось сказать "... найму помощников...".

и "..отложу задачи других клтентов, отдам приоритет вашей задаче, соответственно, неполучу оплаты от других, а, может, и вовсе потеряю их"

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

А зачем им понимать, объяснять и т.п.?

Вот этот красненький телефончик стоит 50к, а вот этот унылый чёрненький 40. Почему? Да патамушто производитель так решил. Не нравится - бери с соседней полки зелёный.

Почему то торгаши отлично понимают что такое "наценка" когда продают свои услуги, но моментально начинают болеть деменцией, когда им самим надо кому то платить.

Почему то торгаши отлично понимают что такое "наценка" когда продают свои услуги, но моментально начинают болеть деменцией, когда им самим надо кому то платить.

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

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

Проблема вообще находить клиентов с деньгами. В 2013-2014 годах пытался работать на себя, так находились лишь "сделай сайт за 5 тыс за неделю".

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

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

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

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

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

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

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

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

А ваши и другие риски для заказчика вы не учитываете?

  1. Человек в штате выполнит любую прихоть работодателя. Хоть в середине проекта, хоть в конце. (Думаю, что это ключевой фактор разницы в сроках - один месяц у вас, против трех месяцев штатного сотрудника. Изменения по ходу работы, переделки. )

  2. В отпуск вы ходите или батрачите без перерыва? Кто его оплатит? Тоже самое с болезнями.

  3. Риск того что вы внезапно пропадете. "Bus-фактор" вольно наемного сотрудника всегда выше штатного: сложности возникли - решил не доделывать, предложили лучший проект - текущий отложил в сторону. Возможно, вы лично так никогда не делаете, но во первых заказчик об этом не знает, во вторых - другие делают.

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

  5. Про риск неверной оценки сроков и объема работ вы сами пишите, но почему то не делаете выводов. А вывод из 5 пунктов прост - стоимость работы на заказ с договором должна быть кратно выше зп обычного сотрудника. Потому что за сотрудника все риски несет бизнес, а здесь их несет исполнитель самостоятельно. Исключенич могут быть: типовые проекты, "старые заказчики, по старой цене". Но и всë пожалуй. Остальные - либо аутсорс с почасовкой (проблему с малым количеством часов я вообще не понял. Делайте больше работы, сами же пишите, что теперь стали тщательнее все прорабатывать... Раньше значит была "халява"... 😁), либо договор " по взрослому" , с наценкой за риски в 100-200%. При работе по договору надо быть готовым,что может понадобится пойти в суд защищать свои права или выполнить доп объем работ себе в убыток. Это отличает бизнес от простой продажи своей способности к труду. (В этом плане "читят" так называемые "галеры", которые вроде и бизнес, а продают время своих бойцов. И не за что не отвечают. Но как по мне к таким конторам обращаются те, кто вообще не понимают как устроена разработка и имеют негативный "опыт - сын ошибок трудных") И это работает с теми клиентами, кому действительно нужно. Остальные могут нанять студента или сегодня уже нейросеть. Придут к вам с этим выкидышем потом по двойному тарифу 😎

Могу попробовать заочно подискутировать)

1. По идее, наёмный ИПшник тоже должен выполнять любую прихоть? За этим его и нанимают, или я не так понял?
2. 40%-50% к зп каждый месяц с лихвой покрывают 1-2 отпуска в год.
3. Справедливости ради, и компания может обанкротиться. Тут всё-таки надо идти от потребности заказчика и репутации исполнителя. Если это высококвалифицированный специалист, врятли он исчезнет, но обратно, также может исчезнуть и наёмный сотрудник. Максимум его ответственности - это увольнение и штраф. По-факту, ИПэшника просто сложнее запрячь.
4. Такие вопросы обычно решаются предоплатой за определённый период. Если на полпути что-то такое произошло, уходим на другой проект, предоплату оставляем себе.
5. "Раньше значит была "халява" - а я вот по-другому это понял. Раньше квалификация была ниже, сроки оценивались, скорее всего, хуже, поэтому всё закономерно.

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

  1. По идее, наёмный ИПшник тоже должен выполнять любую прихоть? За этим его и нанимают, или я не так понял?

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

Да можно начинать каждую неделю с подписания допника в котором указано, что включили в работы, что исключили, как изменились сроки и стоимость. Но пока это согласуешь с ЛПР уже выйдут сроки начального договора.
Очень часто заказчик, который с прихотями и заказчик который подписывают - это разные люди.

1. По идее, наёмный ИПшник тоже должен выполнять любую прихоть? За этим его и нанимают, или я не так понял?

Есть 2 "вида" договора:

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

2. Классический аутстаф, ака наемники, когда продается время, договор оформляется рамочный с указанием часовой ставки, с расторжением по почесу левой пятки, а выполненные работы оформляются актами. Именно в актах указываются недостающие данные, которые дополняют договор до полного, в соответствии с законодательством. Хочет заказчик тоже самое, но с перламутровыми пуговицами? Да пожалуйста, получите в конце периода акт на перламутровые пуговицы, у вас 5 дней на претензию, а иначе акт считается подписанным.

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

На месте ИП есть опции подумать

Иметь своего/юлизкого/знакомого адвоката/юриста - это полезно далеко не только ИП и ООО. А лучшая защита от судов - это грамотно составленный договор, для которого опять таки нужен "свой" юрист, что бы дал по шее еще до подписания.

  1. Нет. Он будет выполнять только то что в договоре В крайнем случае - то что ему выгодно

  2. Так в том и дело что не идет речь не окаких 40-50. За теже деньги - экономия же ))

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

  4. Не решаются. Куда уходим, когда в договоре написано "не доделал в срок - штраф в размере двукратного вознагрждения за выполненный проект" ? Ну я может утрирую, но что то мне кажется и такое есть. А если этого нет - то см п3, уже заказчик несет риски. Споры же наемного сотрудника с работодателем в 90% случаев укладываются в трудовой кодекс и регулируются государством.

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

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

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

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

Платить за «появляешься в офисе 160 часов в месяц» более применимо к сервисной сфере, где надо либо с клиентами постоянно взаимодействовать "с 9 до 18", либо автобус там какой водить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тех задание должен делать заказчик

Как любит говорить Di Halt, это пока Вам 5ю точку конкуренты не припекают.

Вот у меня один знакомый как-то раз хотел заказать партию печатных плат на местном заводе, они ему - давай документацию по ГОСТу. Стоит ли говорить о том, что заказ после этого уехал к китайцам.

это и есть его хотелки

Хотелки != ТЗ

Только он знает что он хочет.

Не знает.

Не вижу смысла тратить время на заказчика, которому лень написать ТЗ и жаба платить за его разработку.

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

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

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

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

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

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

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

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

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

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

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

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

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

Все проекты, которые я разрабатываю руками сам, я предварительно проектирую. Да, с насмотренностью и опытом всё проще делать всё «на лету». Да только всё равно это разные процессы с разными приоритетами. Гораздо меньше шансов ошибиться, когда работаешь по собственной проектной документации. Задача из абстрактной превращается в прикладную.

С проектированием. Спроектировал → посмотрел на результат → внёс правки в прототип. Пошёл кодить финализированный вариант. Это делается быстро.

Без проектирования. Закодил → посмотрел на результат → внёс правки в код. Это делается уже медленнее. Параллельная работа с большим количеством файлов, попытка одновременно думать и об интерфейсе, и о программной архитектуре, отвлекаешься на мелкие трудности, по которым ещё нет опыта.

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

Проектирование - это учет требований и пожеланий заказчика.

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

Это такой минималистичный пример, которым я хочу показать что я подразумеваю под проектированием, а что под кодированием. Наверное за 300 проектов вы через все это прошли и код для среднего заказчика уже есть. Ваше искусство - каждую доработку в новый проект оформлять не как частный случай, а как кирпичик с возможностью переиспользования. Поначалу это большая работа, создавать универсальное. Но такая инвестиция в свои компоненты в долгосрочной перспективе и позволяет выйти на "проект за 2 часа". Мало того, что у вас готовый результат кодируется быстро. У вас параллельно появляется такой же конструктор прототипов. Чтобы собирая требования очень быстро получать демонстрацию. В идеале - разговаривая в чате с заказчиком второй рукой набрасывать сразу же прототип.

Вы замахаетесь на рынке РФ это объяснять. Я занимаюсь примерно тем же самым, умею делать заказчику хорошо и варианты у него следующие: а) нанять меня за много денег б) заплатить много сначала за предпроект а потом за проект. Все вопросы по стоимости часа, а чего так дорого итд итп - нахер, жизнь моя слишком коротка чтобы с этйо чушью разбираться.

PS а еще я все больше думаю что пора оставлять созданные клевые вещи себе

PSPS а вы клевые штуки делаете?

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

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

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

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

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

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

Вы просто подстроились под психологическую модель.

Если представить что между вами и клиентом есть воображаемый менеджер, который передаёт от вас стоимость клиенту, и далее придумывает что угодно на вопросы клиента не касающиеся ТЗ - то модель ничуть не поменяется.

Почему дорого? потому что 100 человек в 3 смены будут работать целый месяц.
Почему успели не за месяц а за 2 недели? Наняли ещё 100 человек в качестве подарка.
Почему 100 человек а не 50? Потому что это среднерыночные трудозатраты.

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

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

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

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

Пока отношение к работе будет как к проделанному объему, и ожидайте оплату соответствующую. Вот есть у меня уникальный станок, который делает хитрое отверстие нужной точности за минуты. Без этого станка такое на неразъемной детали сделать практически невозможно. Либо тратится несколько дней ручного труда. Как вы спозиционируете по цене эту работу перед заказчиком? Вероятно, заложите в работу аммортизацию этого дорогущего станка. И заказчик либо согласится на ваши условия, либо пойдет по рынку искать другого исполнителя. Так же и тут, у разработчика есть условно-уникальный набор скриптов, который делает работу за несколько минут. Обоснование цены аммортизацией не получится, но у нас есть RnD - он закладывается в стоимость таких работ. Заказчик хочет дешевле - просто делается данная работа за стандартное время, без использования этого инструмента, чтобы не было его "аммортизации".

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

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

Если заказчик считает вас лжецом и это озвучивает, то лучше свернуть проект тут же и разорвать все отношения с ним.

Я писал не про кейс "заказчик почему-то вас считает лжецом", а про кейс "вы на чистом глазу грубо лжёте заказчику и ожидаете, что он это схавает". Это другое (с)

При таком раскладе заказчик сам всё свернет и разорвёт, вам даже напрягаться не придётся.

При таком раскладе заказчик сам всё свернет и разорвёт, вам даже напрягаться не придётся.

Чудесно, леди вышла из машины и та поехала быстрее

Ну это чудесно только если вы настолько хороший, что заказчики за вас в очереди бьются. Оно сейчас у многих так?

У высококлассных спецов - у всех. Другой вопрос что их не так уж много осталось здесь, потому, например работу они ищут минут 5. Другой вопрос что значит в очереди. Я настаиваю на том чтобы искать клевых заказчиков потому, что я уже давно устал от тех кто покупает мопед а пашет как на тракторе. По моему даже на хабре есть пара статей как ребятки бизнес в штаты перевозили и получали на ровном месте в 10 меньше геморроя и в 10 раз больше денег. К чему это я? А к тому что в отсутствии института репутации, когда начиная крупные проект/устраиваясь в крупную компанию ты вынужден годами набирать репутацию, часто с подключением корпоративной политики, желательно чтобы потом можно было это конвертировать в годы приятной работы.

У высококлассных спецов - у всех. Другой вопрос что их не так уж много осталось здесь, потому, например работу они ищут минут 5.

Это чересчур надуманно. Дескать, если высококлассный, то заказчиков за дверью очередь, а если не очередь, это не потому, что времена другие, а просто ты не высококлассный :)

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

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

А проблема в чем? Если после этих 25 лет вы способны учиться - то есть варианты.

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

есть некоторое зерно истины

А проблема в чем?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Он и должны быть выше. Возможно, в разы. Какой смысл не иметь никаких "плюшек" и защиты по ТК, но работать за сопоставимый или меньший ценник?

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

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

У 1С ников любят абонентскую, смысл такой что наперед не известно крякнется что-то или нет, они тебе заранее платят (зачастую меньше чем если бы покупали часы) и потом в случае чего тебя дёрнут, ты должен быть особо готов к концам квартала и прочим сдачам отчётности, а так сидишь в ус не дуешь

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

При абонентке за время не платят. Платят помесячно даже если человек ничего не делал в этот месяц.

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

Если абонентка определяется как какое-то количество часов в месяц, то да. Но автор явно не это имел в виду, у него абонентка - это сдельная, но с помесячной платой. Т.е. предопределено количество работ, а не часов.

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

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

Спасибо за статью, иногда они попадают прямо в цель)

Проходил в своём опыте ровно через то же самое. Была часовая ставка 1500 руб. При этом работал в 2-3 раза быстрее рядового разработчика. Клиентов было куча помимо основной работы, и в какой-то момент пришло понимание, что так больше продолжаться не может. Надо либо повышать ставку, либо менять принцип ценообразования. Рад узнать, что я не один такой)

Хак с ИП тоже полезный. Есть несколько товарищей, которые в какой-то момент открыли тайну, что чудесным образом зарабатывают в 2-3 раза больше меня на тех же позициях. Потом выяснилось, что они попросту берут по несколько проектов, практикуя monkey branching, неся минимальные риски, выполняя, по-сути ту же самую работу. Жаль, что об этом мало пишут т.к. не вполне этичная вещь.

Проектная документация сэкономила нам месяцы работы разработчиков, а какие доказательства пользы моего труда после этого ещё нужны? 

Как именно была подсчитана эта экономия времени работы?

Была возможность сравнить, как команда справлялась со схожими по размерам задачами. Одни задачи были сопровождены подробной проектной документацией, другие — нет. Разница в скорости составляла 2-3 раза. Это субъективное наблюдение. Объективно произвести измерения невозможно (предыдущая моя статья на Хабре как раз начинается с этого тезиса).

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

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

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

Нет. По факту автор выполняет в своих проектах несколько ролей, все честно

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

Да не нужна никакая нормировка. Нужно убедить заказчика, что цена вашего труда окупается для него. А потом доказать это делом. И если это действительно так, он будет платить вам столько, на сколько договорились.

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

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

Это вот классический пример, что думает заказчик со своей стороны, когда исполнитель думает: "Ну раз я попадаю в бюджет, и в итоге для заказчика все равно будет какая-то прибыль с моей работы, значит, давай накручу по максимуму".

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

В разработке ПО получается, что если Вы потратили на освоение какого-то стека технологий допустим 2-3 года, и расчитываете в дальнейшем на этом стеке реализовать допустим 10-12 проектов, то надо в каждый проект закладывать 2-3 месяца времени, потраченных на освоение этого стека технологий. Тогда всё будет честно и без скверных ощущений.

Кажется, самый слложный шаг здесь оценить сколько проектов я планирую реализовать с использованием стека, который только что освоил. 10-12 или 1-2? а может 50-60?

Ну хотя бы какие-то ориентировочные рамки человек себе представляет, когда ввязывается в изучение какой-то штуки? Например "за год освою, а потом 2-3 года буду использовать эти знания, получая минимум в 2 раза больше чем дворник - т.е. уже на 3-м годе с начала обучения образовательная инвестиция окупится".

В разработке ПО получается, что если Вы потратили на освоение какого-то стека технологий допустим 2-3 года, и расчитываете в дальнейшем на этом стеке реализовать допустим 10-12 проектов

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

Такое тоже бывает, но вообще говоря в классическом понимании джун - это же не полный ноль с 2-мя классами образования, а специалист, который 4-5 лет учил в ВУЗе всякие линейные алгебры, полиморфизмы, инкапсуляции и прочие алгоритмы и структуры данных. И в школьное время вместо того чтобы гонять мяч, он просиживал за компом, пытаясь писать всякие программульки на питоне/паскале, а также учился устанавливать и администрировать операционные системы и поэтому в общих чертах понимает, что как и к чему. Вот это всё затраченное время и надо учитывать (как коэффициент по отношению к ставке условного дворника).

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

Вот это всё затраченное время и надо учитывать (как коэффициент по отношению к ставке условного дворника).

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

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

Удивительная трансформация за 10 лет: "связанные с валидацией данных, сообщениями об ошибках, неявными сценариями взаимодействия пользователей с системой. ... начал задаваться всё большим количеством вопросов: А что, если пользователь перезагрузит вкладку во время заполнения формы? А что, если в списке будет больше 100 000 строк?.."

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

И я рад, что спустя десяток лет работы эти вопросы стали приходить к Вам.

Удачи!

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

- Сколько стоит час вашей работы?
- 8400
....
- Сколько стоит час вашей работы?
- бла бла бла бла ... 147000 страниц объяснений своей уникальности ... бла бла бла (+ потратил ЧАС на неоплаченный никому не нужный ответ на вопрос, который не задавали).

Хотите интересный вброс? Компания, условная ООО на ОСН с налогом на прибыль, когда платит за сотрудника его зарплату и все взносы и налоги (то, что называет фонд оплаты труда - ФОТ) - там самым уменьшает свою прибыль и соответственно - сумму налога на прибыль. По недавним расчетам с финансистом, сотрудник, получающий на руки 250к, компании обходится в 252к, с учетом снижения налога на прибыль, а ИПешник, получающий столько же - 205 к. Могут быть нюансы от налоговых условий конкретной компании, льгот, и т.п. но примерно картина такая. То есть не совсем уж разница в 40%, а примерно в 20%.

Простите, но вот эта фраза полностью всё ломает:

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

Тут что-то психологическое, которое надо тренировками (наверное) изживать. Вы верите, что по рынку есть некая цена, но по вашему опыту, Вы просили (и получали) выше, чем рынок - и никого это не напрягло. Либо качество устроило, либо "средняя оплата по рынку" не больше относится к правде, чем "средняя температура по больнице".

Более того, заказчики весьма часто говорят "по рынку это стоит N за час, давай заплатим 10*N, но человека возьмём такого, которыё сделает хорошо, и переделывать не придётся!" Да мы и сами с Вами примерно так же ищем плиточника дома ванну делать - цена высока, но еще больше душит мысль, что "дешёвый" мастер доведет ванну до того, что станет совсем плохо.

В общем, мы все в таком были. Просто говорите именно так. Точнее, что сайт обычно обходится в M рублей, соцсеть в P рублей, при особых пожеланиях - стоимость часа вот такая.

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

чем лучше ты оптимизируешь процесс, тем дороже должен становиться твой час

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

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

Вы пишете, что сбор первоначальных требований, можно уместить в 1-3 часа, это получается совсем какой-то маленький проект. И вы делаете это бесплатно. Бесплатно наверное, потому что не предоставляете клиенту продукт.

Но на самом деле продукт можно предоставить - это документ под названием vision. Он должен занимать от одной до трёх страниц и описывать проект широкими мазками. Пишется на основании разговора с одним человеком, основным ЛПР скорее всего. Но я бы сказал что для маленького и простого проекта его можно написать за полдня, если чуть посложнее или побольше то за день, ну а для большого и сложного за два дня. Ну и соответственно три таксы можно озвучивать заказчику на vision. За малый, средний и большой. После того как заказчик одобрит vision - дальше идти будет проще. После написания этого документа станет понятен примерный объем работ, недели или месяцы или годы или десятилетия.

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

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

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

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

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

И платно оцениваю проекты с большим количеством ролей, процессов и разделов.

,,Непонятно , что за оценка проекта. Есть техзадание разработанное заказчиком, вы с ним ознакомились и предоставляете свою смету. Или вы за смету денег берете? ,😱

,Непонятно , что за оценка проекта. Есть техзадание разработанное заказчиком, вы с ним ознакомились

Это если есть техзадание. А если есть постановка задачи, а техзадание вам ещё самому нужно сделать, как бывает в каждом втором случае?

Обычно техзадание разрабатывают заказчики, если только это не особо крупное предприятие, там совсем по другому. Иначе заказчик не знает что хочет .

если только это не особо крупное предприятие,

Именно так, а ведь подавляющее большинство заказчиков как раз и есть не особо крупные предприятия. Они функцию разработки ТЗ обычно так же делегируют, зачастую как раз исполнителю, если тот обладает соответствующими компетенциями.

Очередное полотно из очевидностей с полотнами ни к чему не ведущих комментариев.

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

Я со скепсисом отношусь к таким статьям, так все хвалят себя. Ты на ремонт машины приезжаешь, или дома ремонт, то каждый новый специалист делает круглые глаза "кто же вам предыдущий так все испортил". Рынок есть рынок и чудес не бывает. Не надо обесценивать других. Если работаешь 10 часов где другой работает 20, то на 10 часов и наработаешь. Сократ мне друг, но истина дороже

Я пришёл к такой схеме на сложных ERP-проектах, которые длятся по 6–12 месяцев и требуют около 500 часов работы.

  • Предварительная оценка — бесплатно, но она приблизительная.

  • Ставка за час работы фиксируется в договоре и не изменяется в течение какого-то срока, например года, при условии своевременной оплаты со стороны клиента.

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

  • В договоре указывается, сколько часов в месяц мы гарантированно уделяем этому проекту (обычно 60–90).

  • Также в договоре описывается общая схема блоков и прописываются точки, в которых мы заранее видим, что клиент может не справиться. Например, если он говорит, что его сотрудники будут заполнять какую-то конскую форму, а мы по опыту знаем, что не будут — так и фиксируем это в договоре.

  • Стартовая эксплуатация оформляется актами, в которых указано количество заказов, расчётов и прочих операций, проведённых командой заказчика в новой системе.

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

  • Следующий блок оплачивается, когда израсходованы часы по предыдущему. Не оплатил — работы на паузе. Не оплатил в течение трёх недель — договор тоже на паузе. Оговаривается, что возобновление работ происходит только после оплаты + 4–6 недель (потому что мы уже будем заняты другим проектом).

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

  • Если проект дошёл до конца — подключается абонентка на сопровождение: чтобы 2–3 небольшие задачи в месяц не согласовывать отдельно. Абонентка на разработку — ни в коем случае. Это бесконечный конфликт про объём задач, который «должен быть выполнен».

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

Sign up to leave a comment.

Articles