Как выбрать программиста с адекватной ценой за час?

На рынке я знаю цену помидорам, а рынок знает цену создания страницы с выводом простой таблицы? Сколько часов\минут понадобиться для этого? Считаю что оплата должна быть не за часы работы умноженные на самооценку\скиллы, т.к. самооценка часто не равна опыту. Должен же быть конкретный ценник за определенные действия программиста. Вывести простую форму, добавляющуую запись в таблицу, с несложной логикой может иметь цену от 100 до 100000т.р так по вашему? И как на этом рынке найти адекватную цену?

Дмитрий, а вы цены на аналогичные задачи посмотрите, и портфолио у специалистов разнообразное,а не одни лединги...

Дмитрий, У помидоров есть сорт и цена часто зависит от сорта, рынок наименование сорта знает. У вашего задания есть ТЗ, но его никто кроме вас не знает, а от того что там написано и зависит цена

Дмитрий, не будет никогда конкретного ценника в таких вещах. причем не только в IT сфере. И не бывает конкретных цен за действия программиста. Цена действий всегда будет разной у разных программистов.
А что по вашему адекватная цена? Один клиент заплатит за работу 100к р. Для него это будет адекватная цена, а вы к примеру и 100 будете считать дорогим ценником. Что же считать адекватной ценой?

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

Minifets, что-то мелькало раньше, была подобная площадка.

Дмитрий, вы сравниваете товар (помидоры) и услугу (разработку по Вашему ТЗ) — это не корректно. Корректное сравнение — это готовые решения vs помидоры. В таком случае, Вы можете загуглить и найти все сорта плагинов для вывода табличек и выбрать адекватную цену. И будет как на рынке.

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

P.S. Кстати, почему одни помидоры стоят 50 рублей, а другие 250 за килограмм? Я считаю, что это некорректно, это же просто помидор и он не должен зависеть от самооценки производителя и тем более от того, что ему было сложнее его сделать или сложнее привезти или неурожай у него. Пусть производит там где выгоднее и проще, он же в конце концов профессионал в данной сфере и должен уметь подбирать оптимальные решения.

Minifets, Вот и я о том же.

Дмитрий, Так почему бы все не бросить и не пойти торговать помидорами? Зачем лезть в сложную сферу IT-услуг?

zooks, Хочу торговать помидорами по-новому, а вы программисты, мне поможете))

Дмитрий, честно говоря, с таким подходом это вряд ли получится.

zooks, Я уже понял. Чтож, придется искать компромисс. То, что смогу сам, сделаю сам, а более сложные задачи, отдам средним спецам.

Minifets,

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

Это например не написать сайт под заказ, а поставить готовый wordpress с минимальным ребрендингом?

Saboteur, можно разработку и на чистом php разделить на типовые задачи. Ну и естествено учитывать поправку на cms или framework, где-то быстрее, где-то дольше, а где-то и готовый плагин уже есть.

Minifets, только самое простое, типа "слайдер+корзина+оплата PayPal+каталог". Это исполнитель и сам разбивает и оценивает. А как вы опишите в конструкторе как это должно выглядеть? Как должно меняться поведение? Смысла в бирже - 0.

Minifets, это называется "составить техзадание"

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

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

Minifets,

можно разработку и на чистом php разделить на типовые задачи. Ну и естествено учитывать поправку на cms или framework, где-то быстрее, где-то дольше, а где-то и готовый плагин уже есть.

Типовые задачи, которые встречаются часто - уже реализованы на каком-то движке. Таким образом требовать такое на чистом php означает нестандартную задачу написания своего велосипеда.
То есть типовые задачи - это на 90% уже реализованные вещи, которые нужно просто интегрировать/настроить.

Saboteur, Ну да, так это и должно выглядеть. Заказчик например выбирает php/wordpress и ему нужен интернет-магазин. Конструктор ему предлагает из возможных вариантов поставить WooCommerce, тут же ему ссылки на демку с чистой установленной woo + в качестве опций например установка темы, или другие модификации woo, которые "обычно" заказывают. Если, что-то хочет из того чего нет в базе (список опций), он может добавить свои опции и описать их (В дальнейшем эти опции будут модерироваться и заноситься в базу).
В итоге: Есть тз, заказчик примерно знает за какую стоимость ему должны это сделать (у кого дороже/дешевле) и примерные сроки реализации.

Minifets,

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

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

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

Minifets,

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

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

а типовое ТЗ....
так не бывает.

бывают опросники, checklist для составления ТЗ.

awesomer,

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

И как заказчик поймет, много запросил разработчик или нет? Как на базаре ходить и узнавать, кто сколько просит?

а типовое ТЗ....
так не бывает.

Есть сайт с логинкой на Yii2 и фронтом на jQuery, клиент хочет сделать ajax логинку без перезагрузки, чем не типовая задача?

Minifets,

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

тем, что какую конкретно логику

Minifets,

И как заказчик поймет, много запросил разработчик или нет? Как на базаре ходить и узнавать, кто сколько просит?

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

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

Чтобы оценить качество результата, нужно самому быть программистом.

Дмитрий Евграфович, это скорее из глупостей, как то же хедхантеры ищут программистов и сами ни разу не программисты

Пума Тайланд, после хэдхантера кандидату обычно устраивают собеседование с техническими специалистами, так что последнее слово не за ним.

Да-да все верно. Только человек говорит о суммах 100 долларов. Кто будет вникать во все тонкости за 100 долларов как только вопрос чуть не типовой? В АСУ ТП - постоянная нехватка специалистов не потому что очень трудно что-то изменить в программе PLC, а потому что перед этим надо пару лет вникать в сложности завода и опасности. Но заказчик считает - а что это я буду за эти пару лет платить? Мне надо то раз в месяц привязать датчик к уже существующей системе на существующем и РАБОТАЮЩЕМ заводе (с его точки зрения это все упрощает, по факту все многократно усложняет, так как есть опасноть остановки установки). Вот и выдают в среднем зарплату по РФ по 50 тыщ рублей для полевых, да и то чтобы не сбежали. Для справки - от 50 долларов в час на международном рынке чистыми при хорошо сегрегированной и документированной системе (как правило к вендору обращаются, который уже нанимает под этот проект) минимально как правило работа на неделю по 12 часов, меньше просто никто к нему не поедет.

PavelSyz, А теперь представь, потребовалось мне прикрутить датчик к контролеру Siemens(например), специалистов не много, они дорогие. Я готов заплатить за их опыт, за скорость работы. Допустим я найду пять фирм, занимающиеся этими контроллерами и у всех цены на мою задачу будут кардинально отличаться. Ониж все крутые, у всех большой опыт.... А задачка то простая.... И себестоимость этой задачи должна быть. Сколько человек должен учиться для того что бы подключить датчик контролеру и настроить запись в базу данных? Думаю не много. Для более сложных задач, я готов гораздо большие суммы платить, но для типовых\элементарных задач, платить как за крутого спеца, как-то многовато будет. Разделять на разных подрядчиков по сложности задачи? Или все же лучше к группе спецов обращаться, там где есть и синьоры и мидлы, и джуниоры(как раз для типовых задач)... Там они уже сами делегируют задачи. ...

Дмитрий, вот там где вы писали про 100+ таблиц, вы это серьезно? Вот вам наивный взгляд с позиции исполнителя:
Опа! Заказчик хочет выводить 100+ тупых таблиц, и вообще не в теме как что работает. Если удастся договорится с ним об оплате "потаблично" я прикручу первый попавшийся CRUD-генератор, затратив пару часов, а затем буду получать неплохие деньги за пару кликов, потому что этот генератор будет делать всю работу за меня!

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

А его "подробное ТЗ" - чаще всего просто обман. Нет у него подробного ТЗ, иначе он бы уже примерно представлял сложность и стоимость.

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

Разделять на разных подрядчиков по сложности задачи? Или все же лучше к группе спецов обращаться, там где есть и синьоры и мидлы, и джуниоры(как раз для типовых задач)... Там они уже сами делегируют задачи. ...

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

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

Вот ни разу не попадались такие заказчики
всегда пойди туда не знаю куда сделай то не знаю что

Станислав

работа по ТЗ - это всего лишь один из вариантов

Что значит 'один из'? ТЗ должно быть всегда, и чем продуманнее, тем лучше. Без ТЗ работа не должна выполняться от слова совсем...

он работоспособен только в тех проектах, которые уже живут своей жизнью

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

то есть заранее известен весь функционал

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

Дмитрий,

Вот ни разу не попадались такие заказчики
всегда пойди туда не знаю куда сделай то не знаю что

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

Что значит 'один из'? ТЗ должно быть всегда, и чем продуманнее, тем лучше.

Agile, Scrum, Kanban - видимо, вам либо незнакомы данные термины, либо вы до конца не понимаете их, либо вы никогда не работали по таким методологиям.

Без ТЗ работа не должна выполняться от слова совсем

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

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

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

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

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

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

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

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

Что значит 'один из'? ТЗ должно быть всегда,

Ничего подобного. Читайте Lean Startup.

и чем продуманнее, тем лучше.

Это неверно даже при обычной работе по ТЗ. Хотя смотря что вы имели в виду под "продуманнее".