Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 203
P.S. Главное, не давайте читать эту статью своим знакомым стоматологам…Они и без подобных статей ушлые по самое не балуй :)
Что касается статьи — в отличие от Запада, почасовой рейт на наших теренах пока больше дикость, чем практика.
Я же описываю общую температуру по больнице, а не отдельные случаи.
Знаю не мало людей, которые работают с почасовой оплатой. Но их кол-во не выбивается за несколько процентов.
Знаю не мало людей, которые работают с почасовой оплатой. Но их кол-во не выбивается за несколько процентов.
странно, в моей области, предоставление услуг по 1С программированию, во всех франчайзи которые я знаю, все программисты работают на почасовой оплате.
это выгоднее для работодателя. один человек делает в среднем 10 выездов в неделю.
Я сам работал во франче, деньги смешные
Я сам работал во франче, деньги смешные
Все зависит от работодателя. сейчас я неделями сижу дома и задания получаю по почте и телефону, отчитываюсь таймшитами и готовым кодом. Прям фриланс с одним работодателем.) До этого я год таким вот сотрудником франчи работал на одного всего лишь клиента, то есть по факту не мотался с места на место но оплату получал по отработанному времени. опять же таки все зависит от того насколько разумно начальство построит схему работы.
Зарплата, все зависит от вашей квалификации и следовательно ставки. Получаешь ты там 7мь долларов в час к примеру, и уж сколько отработаешь столько и заработаешь.
Ваш случай, если вы имеете в виду тоже 1С франчайзинг то я представляю такую мотанину только на уровне низкоквалифицированного рабочего которому поручают лишь пару часовые обновления баз данных клиентов по всему городу.
Зарплата, все зависит от вашей квалификации и следовательно ставки. Получаешь ты там 7мь долларов в час к примеру, и уж сколько отработаешь столько и заработаешь.
Ваш случай, если вы имеете в виду тоже 1С франчайзинг то я представляю такую мотанину только на уровне низкоквалифицированного рабочего которому поручают лишь пару часовые обновления баз данных клиентов по всему городу.
а если вы имеете в виду что наоборот слишком мало выездов и мало денег, то это вам с франчайзи не повело, у множества роботы через край, было бы желание работать.
Как в топике расписано это полный фейл, если применять в масштабах рынка (по крайней мере нашего) – прозрачности ноль.
Да и для себя бы применять не стал – платить нужно за готовое решение в комплексе, а не за процесс его выполнения.
Да и для себя бы применять не стал – платить нужно за готовое решение в комплексе, а не за процесс его выполнения.
Все чисто по XP. Да так и надо. Но даже отцы говорят что они до сих пор ждут своего идеального клиента.
После длительной работы с клиентом и установления доверительных, партнерских отношений нам иногда удается перейти на такую схему даже в России.
Но очень редко с первого раза.
Всем нужна смета на весь проект, для согласования с руководством.
А руководство обычно слишком занято чтоб вникать в подробности.
После длительной работы с клиентом и установления доверительных, партнерских отношений нам иногда удается перейти на такую схему даже в России.
Но очень редко с первого раза.
Всем нужна смета на весь проект, для согласования с руководством.
А руководство обычно слишком занято чтоб вникать в подробности.
Все сильно зависит от разработчика. Кто-то любит подумать дважды и затем сделать, кто-то делает «налету» и почти не ошибается.
Например, я бы не стал брать почасовую оплату, потому что не уверен, что сделаю быстро (смотря что делать). Если же программист уже достиг просветления в своем деле — тогда нет вопросов :)
Например, я бы не стал брать почасовую оплату, потому что не уверен, что сделаю быстро (смотря что делать). Если же программист уже достиг просветления в своем деле — тогда нет вопросов :)
На моей прошлой работе, в офисе, была почасовая ставка. Работало так: вы устраиваетесь на определенную зарплату, исходя из этого считается ваша часовая ставка, и дальше вы в багтрэкере указываете у каждого задания, сколько времени затратили. И потом по выставленным вами часам выплачивается зарплата.
Сейчас помимо основной работы (уже в другой компании), удаленно подрабатываю, тоже с почасовой ставкой (заказчик из России). Так что не такая уж и редкость :)
Сейчас помимо основной работы (уже в другой компании), удаленно подрабатываю, тоже с почасовой ставкой (заказчик из России). Так что не такая уж и редкость :)
Сначала заказчик действительно с подозрением относится к такой системе оплаты, но немного поработав оценивает все плюсы. Исчезают конфликты, решения становятся взвешенными, риски разбухания проекта практически исчезают.
Есть советы по-поводу того чем замерять время и автоматически передавать эти данные заказчику? Знаю про oDesk. Может еще есть варианты?
Я замеряю время Emacs + org-mode: habrahabr.ru/blogs/emacs/63424/
Для автоматической передачи из коробки ничего, вроде бы, нет, но нетрудно что-нибудь придумать.
Для автоматической передачи из коробки ничего, вроде бы, нет, но нетрудно что-нибудь придумать.
Есть VimOutliner и VimWiki, но они сильно слабее.
Я юзаю фрэшбук, есть более-не менее удобный плазмоид для кде, так что отдал предпочтение ему…
www.freshbooks.com/
www.freshbooks.com/
freshbook удобен для выставления счетов. А для подсчета затраченного времени нужен посторонний тайм-менеджер. Нативный как-то не очень. При закрытии браузера — останавливается.
а что за плазмоид если не секрет?
Та какой секрет, обычный плазмоид
kde-look.org/content/show.php/FreshBooks+Plasmoid?content=115754
Если что, то у меня он нормально скачался через стандартную систему установки новых плазмоидов, по моему ещё когда кеды были 4.2 или 4.3, уже не помню =)
kde-look.org/content/show.php/FreshBooks+Plasmoid?content=115754
Если что, то у меня он нормально скачался через стандартную систему установки новых плазмоидов, по моему ещё когда кеды были 4.2 или 4.3, уже не помню =)
я использую toggl.com
Rescue Time сохраняет информацию обо всех запускаемых программах и времени, которое вы провели в них. Вы можете указывать какие программы используются для работы, а какие только отвлекают вас (в том числе и конкретные сайты). Думаю, при необходимости, отчёт можно будет показывать заказчику.
Под Windows использую TimeTracker: 0xff.net/
Manictime.com. Хоть я работаю на постоянной основе, тем не менее веду учет сделанных задач по проектам. Manictime в этом очень помогает.
У Eclipse есть очень мощный плагин для управления тикетами/задачами mulyn. Он умеет затраченное на каждое задание время считать (время проведенное в IDE когда это задание помечено как активное)
А общего назначения — hamster applet для Gnome projecthamster.wordpress.com/screenshots/
А общего назначения — hamster applet для Gnome projecthamster.wordpress.com/screenshots/
Пробовал arbtt — сдохла при попытке анализа данных, накопившихся за пару лет.
Пробовал hamster — глючил.
В итоге остановился на timetrap. Управляется с командной строки, при желании можно свои форматтеры для отчётов написать, если штатные не устраивают.
Пробовал hamster — глючил.
В итоге остановился на timetrap. Управляется с командной строки, при желании можно свои форматтеры для отчётов написать, если штатные не устраивают.
я пользую плагин для редмайна
www.redmine.org/wiki/redmine/Plugin_List#TimeTracker-plugin
открываю задачу нажмаю старт потом закрываю, делаю, открываю любую страницу редмайна и нажимаю стоп.
к задаче приплюсовывает, можно еще повестить хук на коммит, но тогда надо номер тикета помнить.
www.redmine.org/wiki/redmine/Plugin_List#TimeTracker-plugin
открываю задачу нажмаю старт потом закрываю, делаю, открываю любую страницу редмайна и нажимаю стоп.
к задаче приплюсовывает, можно еще повестить хук на коммит, но тогда надо номер тикета помнить.
taskcoach.org
Mylyn плагин для eclipse?! — «time tracking» connector Вот сейчас сам сижу с ними разбираюсь.
Вот эту программу использую.
www.timeedition.com
Маленькая, бесплатная, кроссплатформенная, отчеты, синхронизация с Google календарем и т.п.
www.timeedition.com
Маленькая, бесплатная, кроссплатформенная, отчеты, синхронизация с Google календарем и т.п.
Странно, что не упомянули slimtimer.com
Мы для этой цели даем доступ заказчику с систему постановки задач. Он видит ход работ по проекту и отработанное время. Очень удобно. Изначально использовали Bugzilla, теперь перешли на redmine
Есть ManicTime под виндоус.
Gnome Time Tracker
Billings для OS X
Это помогает отслеживать, сколько времени «копал». Ну сколько времени искал нужную информацию по специфической проблеме — это еще можно тоже сосчитать и включить в счет. А как отследить «сколько думал» или «сколько ждал»? Я вот сталкиваюсь с ситуацией, когда можно запустить какое-то тестирование, и раз в 20 минут перезапускать его с другими параметрами. С одной стороны — я не могу в это время уйти пиво пить — так что время это — затраченное. С другой — я в это время шарюсь по интернету, смотрю фильмы итд. Запрашивать за это по полной ставке — как-то невежливо. Запрашивать только за время, когда по клавиатуре стучал — тоже как-то странно — вроде и весь день потратил с утра до вечера, а вроде и стучал-то в сумме полчаса всего. Нанимать на эту задачу тестера тоже не выход, потому что только я знаю как правильно инерпретировать результаты тестов, какие пару строчек поменять в коде после теста и какой запустить следующий тест, чтобы получить наиболее показательные и интересные результаты.
Или обратная ситуация — загрузился какой-то рабочей проблемой, был какой-то план как сделать что-то, скажем, за 20 часов. И тут на выходных, пока загруженный ходил (в нерабочее время) вдруг озарение — это все можно хитрее сделать за 4-5 часов. И? Включать теперь выходные в рабочее время? «Дарить» заказчику забесплатно это свое озарение (и угробленные выходные, потому что если б пил с утра — не было б этого озарения)? Делать вид что его не было и работать по кривой, тратить 20 часов?
Вроде никакой из этих вариантов однозначно правильным не выглядит. Так что почасовая система только с одной стороны выглядит простой и честной. Но если работа не «щелкать по клавиатуре», тогда не всегда ее можно легко в часы сконвертировать.
Или обратная ситуация — загрузился какой-то рабочей проблемой, был какой-то план как сделать что-то, скажем, за 20 часов. И тут на выходных, пока загруженный ходил (в нерабочее время) вдруг озарение — это все можно хитрее сделать за 4-5 часов. И? Включать теперь выходные в рабочее время? «Дарить» заказчику забесплатно это свое озарение (и угробленные выходные, потому что если б пил с утра — не было б этого озарения)? Делать вид что его не было и работать по кривой, тратить 20 часов?
Вроде никакой из этих вариантов однозначно правильным не выглядит. Так что почасовая система только с одной стороны выглядит простой и честной. Но если работа не «щелкать по клавиатуре», тогда не всегда ее можно легко в часы сконвертировать.
Да, есть такое дело. Я например делаю 3D, и тоже не всегда сам «работаю» — иногда нужно тестовый рендер запустить на 5 минут, иногда еще что-то… Если оно действительно 3-5 минут — я это время учитываю по полной ставке, т.к. все равно сижу, смотрю что получается, думаю… Если нужно что-то посложнее, минут на 20 — счетчик выключаю и занимаюсь другими проектами или своими делами, или отдыхаю.
В общем, стараюсь балансировать, чтобы и самому целый день не сидеть за 30 минут рабочего времени, и машинное время не считать.
Финальные рендеры так вообще запускаются на ночь в очередь. Это время, естественно, не учитывается, но уже тоже подумываю ввести какие-то ставки на машино-часы, т.к. бывают ситуации, когда нужно что-то доточить в готовом проекте, работы на 5 минут, а перерендериваить опять на всю ночь, я всё-таки не рендерферма :)
В общем, стараюсь балансировать, чтобы и самому целый день не сидеть за 30 минут рабочего времени, и машинное время не считать.
Финальные рендеры так вообще запускаются на ночь в очередь. Это время, естественно, не учитывается, но уже тоже подумываю ввести какие-то ставки на машино-часы, т.к. бывают ситуации, когда нужно что-то доточить в готовом проекте, работы на 5 минут, а перерендериваить опять на всю ночь, я всё-таки не рендерферма :)
Испольщую gtimelog уже 3 года. Простой тайм-трекер, удобнее не видел.
Почасовая оплата годится только для оплаты узбеков копающих яму. Во всех остальных случаях это перекладывание ответственности на заказчика. такое мало какому заказчику нравится.
Расскажите это адвокатам, консультантам, звукорежиссерам и, самое главное, не забудьте про дорогих репетиторов. :)
Неудачность такого сравнения вот в чём — в отличие от, допустим, репетитора, программист работает не за одним столом с заказчиком. Если я пришёл к репетитору и заплатил ему за час, ему будет очень и очень трудно не отработать этот час сполна :)
А что там делал в этот час программист — заказчику толком неизвестно.
А что там делал в этот час программист — заказчику толком неизвестно.
Аргументы против почасовой оплаты, глазами заказчика по Вашим пунктам:
2. Дело тут не в деньгах, а в фиксированных сроках и объемах работ. переплатить за код можно при любом подходе.
3. Фиксированная стоимость за проект не обязательно подразумевает разовую оплату. можно бить на этапы, авансы. При этом заказчику легко планировать бюджет, в отличии от не очень прогнозируемых платежей при почасовой оплате.
4. Любое задание обязано поместиться в ТЗ.- это прописная истина. Другое дело, что существует для сложных проектов такое понятие как многостадийное проектирование. Когда на первом этапе разрабатывается фиксированная часть проекта, реализуется и после нее разрабатывается следующий этап со своими ТЗ, сроками, стоимостью и т.д. Такая практика применяется во всех без исключения крупных инженерных проектах.
5. Программист или менеджер проекта несет ответственность конечному заказчику неважно. Ему важно чтобы исполнитель отвечал (читай гарантированно выполнил) в установленные сроки. Заказчик по умолчанию менее компетентен в предмете, тем более в оценке сроков и рисков. Он платит деньги за результат и оценивать должен исполнитель — следовательно нести ответственность за оценку.
6. Тут есть обратная сторона медали — большинство реальных задач, как правило нацелены на результат, и не всегда заказчик желает платить за то что задача реализована по фэншую и в соответствии с последними веяниями моды. Чем злоупотребляют многие разработчики.
7. Заказчик не хочет давать четкие инструкции. У него нет времени, он некомпетентен. Он хочет заплатить денег и получить результат в коробочке.
2. Дело тут не в деньгах, а в фиксированных сроках и объемах работ. переплатить за код можно при любом подходе.
3. Фиксированная стоимость за проект не обязательно подразумевает разовую оплату. можно бить на этапы, авансы. При этом заказчику легко планировать бюджет, в отличии от не очень прогнозируемых платежей при почасовой оплате.
4. Любое задание обязано поместиться в ТЗ.- это прописная истина. Другое дело, что существует для сложных проектов такое понятие как многостадийное проектирование. Когда на первом этапе разрабатывается фиксированная часть проекта, реализуется и после нее разрабатывается следующий этап со своими ТЗ, сроками, стоимостью и т.д. Такая практика применяется во всех без исключения крупных инженерных проектах.
5. Программист или менеджер проекта несет ответственность конечному заказчику неважно. Ему важно чтобы исполнитель отвечал (читай гарантированно выполнил) в установленные сроки. Заказчик по умолчанию менее компетентен в предмете, тем более в оценке сроков и рисков. Он платит деньги за результат и оценивать должен исполнитель — следовательно нести ответственность за оценку.
6. Тут есть обратная сторона медали — большинство реальных задач, как правило нацелены на результат, и не всегда заказчик желает платить за то что задача реализована по фэншую и в соответствии с последними веяниями моды. Чем злоупотребляют многие разработчики.
7. Заказчик не хочет давать четкие инструкции. У него нет времени, он некомпетентен. Он хочет заплатить денег и получить результат в коробочке.
Где-то у же писал тут, что компетентные заказчики зачастую не заказчики, а подрядчики/генподрядчики, то есть посредники между заказчиком, который платит за результат и непосредственным исполнителем, который получает по трудоемкости. Хорошие посредники берут на себя риски и заказчика, и исполнителя (конечно, не без выгоды для себя), ну, и коммуникации с «некомпетентным» заказчиком.
Если во втором случае компания производит софт на заказ, а не для собственных нужд, то можно считать посредником (трудовой договор вы же с ними всё равно не заключаете?)
Я вот делаю :), да и многие продукты, в частности open source, появились именно для собственных нужд, а потом были выложены с мыслью «а вдруг кому-нибудь ещё пригодится». Под «посредничеством» имею в виду продажу непосредственно программы, изготовленной другими, а не результатов её работы или, тем более, использование этих результатов для продажи чего-то другого («управления бизнес-процессами»).
>Расскажите это адвокатам
В последнее время в США (где работа юриста традиционно оплачивалась на почасовой основе) все большую популярность приобретает фиксированная оплата, которая позволяет клиентам более надежно прогнозировать свои расходы.
Оплата по часам возможна только на уже сформировавшемся всококонкурентном рынке, где репутация не является просто красивым словом, а имеет значимое экономическое выражение.
Думаю, что на сегодняшний день в России таких секторов экономики не существует, поэтому-то работа на условиях почасовой оплаты если и имеет место, то в качестве исключения.
В последнее время в США (где работа юриста традиционно оплачивалась на почасовой основе) все большую популярность приобретает фиксированная оплата, которая позволяет клиентам более надежно прогнозировать свои расходы.
Оплата по часам возможна только на уже сформировавшемся всококонкурентном рынке, где репутация не является просто красивым словом, а имеет значимое экономическое выражение.
Думаю, что на сегодняшний день в России таких секторов экономики не существует, поэтому-то работа на условиях почасовой оплаты если и имеет место, то в качестве исключения.
Заказчикам нравиться, когда они платят ровно столько сколько потребовалось, зачастую меньше чем рассчитывали. Когда их изменения и дополнения приветствуются. Когда делают тщательно и хорошо, досконально все проверяют.
Да, определенные риски перекладываются на заказчика, но и положительные тоже. Иначе, исполнитель просто выставит эти риски в смете в виде запаса по сумме, но и выгоду от положительных рисков получит он же.
Да, определенные риски перекладываются на заказчика, но и положительные тоже. Иначе, исполнитель просто выставит эти риски в смете в виде запаса по сумме, но и выгоду от положительных рисков получит он же.
Для такого нужен довольно большой опыт, чтобы точно оценить срок и в него же уложиться. А ещё убедительный вид, чтобы донести до клиента «XX $/час кажутся большой суммой, но а) я чертовски хорош и б) я работаю быстро.» и «Я благороден и не стану завышать цену.»
Во первых точно оценивать не надо. Надо оценить верхнюю границу. Если потратиться часов меньше, то всем только в плюс — заказчик не платит, исполнитель получает положительное отношение и никто ничего не теряет.
Что бы убедить достаточно немного поработать и накопить историю. Но имхо нормальных и не истеричных клиентов достаточно что бы начать с нуля.
Что бы убедить достаточно немного поработать и накопить историю. Но имхо нормальных и не истеричных клиентов достаточно что бы начать с нуля.
тут в том дело, что с новой задачей ты не знаешь сколько ее делать и какова верятность уткнутся в стену в чистом поле.
плюс есть вероятность недооценить верхнюю планку, что тогда делать — честно сказать об этом работодателю или, чтобы не потерять авторитет сделать по тихому?
плюс есть вероятность недооценить верхнюю планку, что тогда делать — честно сказать об этом работодателю или, чтобы не потерять авторитет сделать по тихому?
Ну абсолютно новое для меня не интересно, для того что я еще не делал, но понимаю как это можно сделать — я могу оценить худо-бедно.
Вероятность уткнуться есть всегда — баг в компиляторе или сервере может надолго запрячь в troubleshooooooting :) Я всегда предпочитаю честность — если я второй час ковыряюсь в том что хотел сделать за 10 минут — стоит об этом сразу сказать что мол проблема такая-то — фиг знает когда порешаю.
Я не боюсь потерять авторитет ( что вообще этот заказчик смыслит в моей работе? ), я боюсь потерять доверие.
Вероятность уткнуться есть всегда — баг в компиляторе или сервере может надолго запрячь в troubleshooooooting :) Я всегда предпочитаю честность — если я второй час ковыряюсь в том что хотел сделать за 10 минут — стоит об этом сразу сказать что мол проблема такая-то — фиг знает когда порешаю.
Я не боюсь потерять авторитет ( что вообще этот заказчик смыслит в моей работе? ), я боюсь потерять доверие.
>фиг знает когда порешаю
просто после вот этой фразы не понятно как должен себя повести заказчик и какая позиция будет у разработчика — тут все не так однозначно.
>Я не боюсь потерять авторитет ( что вообще этот заказчик смыслит в моей работе? ), я боюсь потерять доверие.
это конечно игра слов, но для меня авторитет это намного больше чем доверие, те вам доверяют настолько, что вы авторитет. а с «просто доверием» обычно идет комплект — «просто проверяю», а это может сильно накалить отношения, в особенности когда начнут ссылаться на соседа Васю.
помоему в статье описан идеальный случай взаимодействия с почасовой оплатой, а вот самого главного, как выходить из патовых ситуаций не написано.
просто после вот этой фразы не понятно как должен себя повести заказчик и какая позиция будет у разработчика — тут все не так однозначно.
>Я не боюсь потерять авторитет ( что вообще этот заказчик смыслит в моей работе? ), я боюсь потерять доверие.
это конечно игра слов, но для меня авторитет это намного больше чем доверие, те вам доверяют настолько, что вы авторитет. а с «просто доверием» обычно идет комплект — «просто проверяю», а это может сильно накалить отношения, в особенности когда начнут ссылаться на соседа Васю.
помоему в статье описан идеальный случай взаимодействия с почасовой оплатой, а вот самого главного, как выходить из патовых ситуаций не написано.
Masterkey ↑: это конечно игра сло
Авторитет — вес моих мнений по отношению к другим. Я могу высказать свое мнение, если надо то могу его обосновать. Могу поспорить с соседом Васей относительно его возражений. Пусть заказчик консультируется где-то еще — это его право. Технические и организационные моменты всегда можно разрешить диалогом и логикой.
Доверие — признание правдивости моих слов. Очень часто возникают ситуации когда нельзя проверить или оценить мои слова. И для меня важно что не возникает неприятных ситуаций на пустом месте. Например те же часы — треккер может зацепить пришедшее сообщение от левого чувака или браузер с левыми сайтами, которые у меня висят в фоне сутками, ожидая свободного времени. И не будет дурацких вопросов.
У меня может тупо упасть инет на день. Я могу уехать на выходной и там застрять на пару дней. Все это форс мажор и я не могу его предусмотреть. Я могу потом выкладываться больше что бы наверстать время, если оно критично, но в ответ прошу лишь адекватной реакции.
Masterkey ↑: просто после вот этой фразы не понятно как должен себя повести заказчик и какая позиция будет у разработчика — тут все не так однозначно.
Конечно. Мы живем не в идеальном мире. Всегда есть риск нарваться на непредусмотренную фичу или багу где угодно — в окружении, в используемых инструментах. Сам факт локализации баги в таких случаях нетривиален. А устранение — тем более. И в силу нетривиальности нельзя предсказать время решения.
Нормальный заказчик должен понимать что есть риски, которые не были учтены и никогда не учитываются не параноиками. И реагировать на такой сюрприз адекватно. Да он несет финансовые потери в этом случае, но и я выкладываюсь по полной. Зачастую в нерабочее и нетарифицируемое время ищу возможные причины по инету, вместо почитывания хабра. Иногда могу подскочить с кровати и побежать проверять решение, пришедшее на ум.
Masterkey ↑: как выходить из патовых ситуаций не написано
А никто и не напишет. Нет идеальной модели в отношениях. Надо просто набираться опыта и импровизировать. Держаться определенных принципов и не давать волю эмоциям.
>Нормальный заказчик должен понимать что есть риски, которые не были учтены и никогда не
>учитываются не параноиками. И реагировать на такой сюрприз адекватно. Да он несет финансовые
>потери в этом случае, но и я выкладываюсь по полной. Зачастую в нерабочее и нетарифицируемое
>время ищу возможные причины по инету, вместо почитывания хабра. Иногда могу подскочить с
>кровати и побежать проверять решение, пришедшее на ум.
воот, наконец-то, вот он ответ — заказчик рискует деньгами (в случае проблем), а ты рискуешь и отвечаешь своим свободным временем (без фанатизма).
>учитываются не параноиками. И реагировать на такой сюрприз адекватно. Да он несет финансовые
>потери в этом случае, но и я выкладываюсь по полной. Зачастую в нерабочее и нетарифицируемое
>время ищу возможные причины по инету, вместо почитывания хабра. Иногда могу подскочить с
>кровати и побежать проверять решение, пришедшее на ум.
воот, наконец-то, вот он ответ — заказчик рискует деньгами (в случае проблем), а ты рискуешь и отвечаешь своим свободным временем (без фанатизма).
> фиг знает когда порешаю.
в таких ситуациях, если они не критические, всегда делал соотв. пометку в трекере и переключался на другую задачу
в таких ситуациях, если они не критические, всегда делал соотв. пометку в трекере и переключался на другую задачу
Уже не найду статью, но программисты довольно быстро и просто учатся планировать время на свою работу. Там как-то ключ в детализации был. Оценка типа «10 часов» явно будет ошибочной и точно нуждается в детализации. Это полезно и само по себе, даже если без оплаты.
При небольшом опыте начинает получаться довольно точно, сам удивился.
При небольшом опыте начинает получаться довольно точно, сам удивился.
А я вот не понимаю такого подхода. Все таки программировать, например — это не траншею рыть. когда то нужно подумать над задачей больше, когда-то меньше, иногда нет настроения, иногда вдохновения, в итоге производительность труда в разное время может очень отличаться. Допустим сегодня я не в духе, но нужно решить какую-то задачу — запускаю таймер и ковыряю ее весь день. А на следующий день приходит озарение и все решается за полчаса. Все таки слишком размытая такая «тарификация» да и непрозрачаня для заказчика.
Но ведь пока вы «ковыряю ее весь день» — вы тоже тратите свое рабочее время, которое должно быть оплачено. Или же заказчик должен платить только пока есть вдохновение?
Заказчик должен платить за решение заказанной им задачи, мне так кажется.
Вы говорите о таких работах, как копка траншей. Тут да: и заказчик и работник имеют возможность предугадать, сколько им это будет стоить. Если же вы придёте и попросите подготовить участок под фундамент, то это совсем другая неоднозначность, никто не возьмётся, разве что если посулите миллион за квадратный метр.
Нет в строительстве неоднозначностей (почти, ну и форс-мажоры, конечно бывают) при грамотно составленном проекте. Нормируется и калькулируется всё с большой точностью с учётом текущих цен (ежемесячно, если не чаще уже, выпускаются официальные региональные сборники цен и различных поправочных коэффициентов, включая накладные расходы). Завысить объёмы работ при грамотном заказчике (и добросовестных отдельных его представителях) практически не реально. В теории «играть» на тендерах, особенно государственных, без изменения проекта можно только прибылью (и то, не бухгалтерской, а сметной). На практике, конечно, всё по другому (особенно, если заказчик не заинтересован в эффективном использовании ресурсов), но отталкиваются и заказчик, и подрядчик от одних цифр, рассчитанных по одним исходным данным и по одним методикам. В ИТ такого, не знаю к счастью, или к сожалению, нет практически.
=) даже если заказчик заинтересован — есть много «смежных» областей, чья неоднозначность просто зашкаливает — вывод земли, согласования, поставки материалов, их качество, подводка инфраструктуры, соответствие нормам и требованиям, проверки и комиссии… Все сроки и сметы летят не из-за того что неправильно рассчитали, а из-за внешних «хотелок».
Тупо построить из материала здание — это все равно что дать программисту кусок кода на бумаге и сказать «перепиши и скомпилируй» — в IT такое тоже — очень однозначное и нормируемое по времени. Только это не IT…
Только очень талантливые или абсолютно невменяемые люди работают по первоначальному плану от и до.
Тупо построить из материала здание — это все равно что дать программисту кусок кода на бумаге и сказать «перепиши и скомпилируй» — в IT такое тоже — очень однозначное и нормируемое по времени. Только это не IT…
Только очень талантливые или абсолютно невменяемые люди работают по первоначальному плану от и до.
И что, если вас подвести к участку и попросить построить дом, вы сразу телекинетически определите, сколько там скрыто коммуникаций, подземных рек там протекает и как глубоко поезда метро ходят, и геологическая разведка вам не нужна?
Геологическая разведка и существующие коммуникации и прочая привязка к местности это предпроектная стадия, на основе которых формируются проектные решения. Могут быть форс-мажоры, в виде, например, незамеченных пустот или отсутствующих на плане коммуникаций, но на то они и форс-мажоры.
Ну, если рассматривать это как предпроектную стадию, то и проекты разработки ПО делаются абсолютно предсказуемым способом. Просто программист кодер требует от заказчика максимально полное ТЗ с описанием платформы, списком всех подводных камней и максимально полными спецификациями готового продукта.
Кстати, для интереса, а что делают строительные девелоперы, если обнаруживают пустоту? Оплачивают из дохода по другим заказам? И как это формулируется (всё-таки, форс-мажором обычно зовутся другие виды событий).
Кстати, для интереса, а что делают строительные девелоперы, если обнаруживают пустоту? Оплачивают из дохода по другим заказам? И как это формулируется (всё-таки, форс-мажором обычно зовутся другие виды событий).
Когда писал предыдущие комменты тоже слово «кодер» в голове всплыло :) Если разделять разработчиков программного продукта на архитекторов и кодеров, то аналогии со строительством почти прямые, просто в ИТ не принято разделять эти процессы на разные организации, в лучшем случае только на разные отделы (не в последнюю очередь, имхо, из-за трудностей «вербальной» передачи знаний, то есть составление того самого максимального полного ТЗ для кодеров, практически исключающего необходимость общения с архитектором, экономически неоправдано, ну и не требуется, за редким исключением, государством в отличии от строительства).
На моей практике работы в строительной (не проектной) организации был один «форс-мажорный» случай — уровень залегания грунтовых вод оказался намного выше данных георазведки, произведенной год назад и, как следствие, проект оказался негодным: заморозив «нулевой цикл», мы с представителем заказчика составили акт о невозможности соблюдения СНиП при выполнение предоставленного проекта в данных условиях, тот отдал его проектировщикам (проект заказали «ткнув пальцем в лес», георазведка выполняли субподрядчики проектного института), они за свой счёт выполнили допразведку, изменили проект (основное изменение — более длинные и с большей площадью сечения сваи), мы «выставили счёт» (доп. соглашение к договору) заказчику и на допработы, и на прямые потери, и на вынужденный простой — он его оплатил, а потом, афаик, передал его проектировщикам, мировой не достигли и он подал иск в суд… что дальше было не знаю. Наше поведение, если бы, например, заказчик отказался подписать акт и/или компенсировать убытки и неполученную прибыль сказать не могу, но переживали те, кто в теме сильно, но не по поводу необходимости допработ за свой счёт, а по поводу необходимости расторжения договора (страниц 20 12 кеглем, не считая приложений с «ТТХ») и сомнительности, в этом случае, добровольного получения с заказчика компенсации хотя бы оплаты выполненных работ и прямых убытков, связанных с резким прекращением оставшихся. Основная проблема была в том, что мы не имели права изменять проектные решения самостоятельно, а заказ таких изменений на стороне делал строительство для нас невыгодным.
На моей практике работы в строительной (не проектной) организации был один «форс-мажорный» случай — уровень залегания грунтовых вод оказался намного выше данных георазведки, произведенной год назад и, как следствие, проект оказался негодным: заморозив «нулевой цикл», мы с представителем заказчика составили акт о невозможности соблюдения СНиП при выполнение предоставленного проекта в данных условиях, тот отдал его проектировщикам (проект заказали «ткнув пальцем в лес», георазведка выполняли субподрядчики проектного института), они за свой счёт выполнили допразведку, изменили проект (основное изменение — более длинные и с большей площадью сечения сваи), мы «выставили счёт» (доп. соглашение к договору) заказчику и на допработы, и на прямые потери, и на вынужденный простой — он его оплатил, а потом, афаик, передал его проектировщикам, мировой не достигли и он подал иск в суд… что дальше было не знаю. Наше поведение, если бы, например, заказчик отказался подписать акт и/или компенсировать убытки и неполученную прибыль сказать не могу, но переживали те, кто в теме сильно, но не по поводу необходимости допработ за свой счёт, а по поводу необходимости расторжения договора (страниц 20 12 кеглем, не считая приложений с «ТТХ») и сомнительности, в этом случае, добровольного получения с заказчика компенсации хотя бы оплаты выполненных работ и прямых убытков, связанных с резким прекращением оставшихся. Основная проблема была в том, что мы не имели права изменять проектные решения самостоятельно, а заказ таких изменений на стороне делал строительство для нас невыгодным.
Спасибо.
В IT так редко поступают, мне кажется, в основном из-за того, что часто задание на разработку как раз предусматривает итеративную разработку:
— что вы хотите?
— ну, кажется, дом.
— сделано, с вас $N
— а теперь, пожалуйста, повесьте на крыше башенки-пристройки, как на Петропавловской крепости, не знаю, как называются.
— O_o ну ладно, вот тут надо стены усилить, будет стоить $M0
— X_x а почему так дорого? Это же всего башенки!
Вот для такой ситуации почасовая оплата, всё таки, была бы полезна. Т.к. даже если предпоследняя фраза будет «К сожалению, при заложенной в оригинальном проекте прочности каркаса и стен, это невозможно, до свиданья. Если кто-нибудь напишет внятное ТЗ, приходите, поговорим.», осадочек у клиента останется очень толстый. :)
В IT так редко поступают, мне кажется, в основном из-за того, что часто задание на разработку как раз предусматривает итеративную разработку:
— что вы хотите?
— ну, кажется, дом.
— сделано, с вас $N
— а теперь, пожалуйста, повесьте на крыше башенки-пристройки, как на Петропавловской крепости, не знаю, как называются.
— O_o ну ладно, вот тут надо стены усилить, будет стоить $M0
— X_x а почему так дорого? Это же всего башенки!
Вот для такой ситуации почасовая оплата, всё таки, была бы полезна. Т.к. даже если предпоследняя фраза будет «К сожалению, при заложенной в оригинальном проекте прочности каркаса и стен, это невозможно, до свиданья. Если кто-нибудь напишет внятное ТЗ, приходите, поговорим.», осадочек у клиента останется очень толстый. :)
Согласен, очень вероятно, что именно частая итеративность вносит коррективы на отсутствие «разделения труда» фирм-архитекторов и фирм-кодеров, но, с другой стороны, и при почасовой оплате за «всего лишь башенки», при необходимости полностью менять архитектуру «дома», осадок останется не многим тоньше, а уж если клиента заранее не предупредить, что очередная фича будет стоить больше, чем весь проект до этого…
Просто при повремёнке немного легче, как мне кажется, предложить клиенту альтернативу: «а может, вас устроит мансардный этаж? Это будет стоить всего $L и займёт, ориентировочно, K0 часов. Но если хотите, я, всё таки, сделаю вариант с башенками — это $M0, если получится сделать, ориентировочно, за Q0 часов, но могут возникнуть осложнения, тогда переработка будет оплачиваться по часовой ставке $M0/$Q0.».
Я непосредственно с внешними заказчиками по часовой ставке не работал (работал только для внутреннего), но мне бы наличие таких честных альтернатив понравилось больше, чем вариант с фиксированными ценами. В последнем случае у меня бы, возможно, возникло ощущение, что меня пытаются принудить делать более знакомый/простой/выгодный для подрядчика вариант.
Я непосредственно с внешними заказчиками по часовой ставке не работал (работал только для внутреннего), но мне бы наличие таких честных альтернатив понравилось больше, чем вариант с фиксированными ценами. В последнем случае у меня бы, возможно, возникло ощущение, что меня пытаются принудить делать более знакомый/простой/выгодный для подрядчика вариант.
Вы говорите о таких работах, как копка траншей. Тут да: и заказчик и работник имеют возможность предугадать, сколько им это будет стоить. Если же вы придёте и попросите подготовить участок под фундамент, то это совсем другая неоднозначность,Хм, не вижу особых проблем и в данном случае.
Всё обычно в строительстве делается через смету. И строители всегда примерно говорят что и как. Я уж не знаю как там у «профессиональных» строителей, с большими стройками дел не имел. Но опыт общения с разными рабочими и строителями есть, и ремонты мы заказывали. Вот мы сруб брали, например. Если рабочий мне скажет, что, например, сборка привезённого сруба будет стоить не N килорублей, а 500 рублей в час, то я задумаюсь, надо ли мне это. Зачем это так и почему? Неизвестные переменные напрягают, мне надо, чтобы я завтра приехал, а у меня стоял сруб нормально собранный. И токари, когда я им заказывал детали, всегда называли конечную цену, а не тариф в час. И рабочие в автомастерских аналогично. И т.д. и т.п.
Повторюсь, несомненно, есть случаи, когда повремёнка допустима и даже предпочтительна, но пока, имхо, тут всё речь не о том.
В вашем примере всё относительно просто, потому что участок без геологических сложностей и обременений. Такие простенькие халтурки и в IT-разработке бывают. Конечно, идеально, когда заказчик приносит проработанное ТЗ, не предусматривающее исследовательской работы, но так бывает далеко не всегда. Вообще, к примеру, веб-студии вполне нормируют похожие операции, также, как и автомастерские, но речь не о них, а о более широком классе проектов.
Если же вы покажете строителям на голый подтопленный участок с лесом, никто вам цену на дом, который там надо построить, сразу никогда не назовёт, не обманывая вас при этом и не надеясь на разводы в будущем на дополнительные работы/доработку.
Если же вы покажете строителям на голый подтопленный участок с лесом, никто вам цену на дом, который там надо построить, сразу никогда не назовёт, не обманывая вас при этом и не надеясь на разводы в будущем на дополнительные работы/доработку.
Часик потратил сегодня и часик через неделю. Вроде и заказчику платить всего за два часа, но и времени ушла неделя…
Так вы размышляете? :)
Так вы размышляете? :)
Все просто. Чем выше ваша квалификация, тем быстрее вы решаете задачи и меньше тратите времени на ковыряние, тем выше ваша часовая ставка. Если вы ковыряете одну часовую задачу 10 часов, ваша ставка примерно в 10 раз меньше, чем ставка того, кто эту задачу решает за час.
Вдохновение тут играет второстепенную роль. Если на ковыряние задачи уходит весь день и вы это видите, отложите ее на следующий день, займитесь другим делом. И вы время не теряете и клиент лишнего не платит.
Вдохновение тут играет второстепенную роль. Если на ковыряние задачи уходит весь день и вы это видите, отложите ее на следующий день, займитесь другим делом. И вы время не теряете и клиент лишнего не платит.
Дело в том что чем выше ваша квалификация — тем с более сложными задами приходится сталкиваться. Если не стоять на месте конечно и не строгать все время что-то одно, что уже действительно всегда просто и оценить и сделать.
Я считаю заказчик должен платить за решение задачи. А оценивать ее предварительно можно в том числе и по прогнозу затраченного на нее времени. Т.е. не играться с секундомерами, а сразу прикидывать — на это у меня уйдет 2-3 часа, моя ставка такая-то — умножаем — получаем оценку задачи. Все просто и гораздо прозрачнее и для себя и для заказчика.
Я считаю заказчик должен платить за решение задачи. А оценивать ее предварительно можно в том числе и по прогнозу затраченного на нее времени. Т.е. не играться с секундомерами, а сразу прикидывать — на это у меня уйдет 2-3 часа, моя ставка такая-то — умножаем — получаем оценку задачи. Все просто и гораздо прозрачнее и для себя и для заказчика.
а как оценить проект на три месяца с неопределенным, туманным ТЗ? видимо, именно про такие проекты идет речь в статье
Большой проект разбивается на этапы, которые по мере выполнения и возможных корректировок в процессе и оцениваются. Просто уже например не в часах, а в днях, аналогично. Этот этап по прогнозу займет столько то дней, день стоит столько, умножаем, закладываем риски — получаем оценку этапа или проекта.
Как то разумнее мне это кажется, даже если поставить себя на место заказчика. Допустим решили делать ремонт в квартире, приходит Джамшут и говорит — будем делать пока не сделаем, час стоит столько то. Я бы сразу попрощался, т.к. я платить готов за результат — сделанный ремонт, а не за процесс, который неизвестно когда закончится.
Как то разумнее мне это кажется, даже если поставить себя на место заказчика. Допустим решили делать ремонт в квартире, приходит Джамшут и говорит — будем делать пока не сделаем, час стоит столько то. Я бы сразу попрощался, т.к. я платить готов за результат — сделанный ремонт, а не за процесс, который неизвестно когда закончится.
В случае Джамшута я должен объяснить ему что именно я хочу. Обычно у заказчиков с этим проблемы. Обычно что-то вроде: «Я хочу вот как там но не так и еще вот это сюда оттуда но не так как у них...». Если у таких клиентов потребовать ТЗ — они не смогут его составить. Вот и получается разговор глухого со слепым. Обычно такой проект стоит больших нервов (если Вы имели глупость его взять) и редко заканчивается так, что обе стороны остаются довольны.
когда мой отец строил дом — он имел планы, которые никому не показывал.
он нанял строителей, платил им по дням зарплату столько, пока они этот дом не сделали. потому что требования время от времени менялись
он нанял строителей, платил им по дням зарплату столько, пока они этот дом не сделали. потому что требования время от времени менялись
Ну профи и отличается от прочих тем что его плюс/минус очень небольшой. А работать без настроения никто не заставляет и ни один нормальный человек не будет возражать против выходного.
за собой такое замечаю очень часто, но в последнее время я стараюсь в такие моменты просто заниматься другими делами или отдыхать, вместо многочасового ковыряния одного и того же, если не идет, значит ну его хотя бы на пару часов ;)
а еще такой момент — то время, которое я не программирую. это не значит, что я не работаю. вот сегодня я ехал полтора часа в междугороднем автобусе и всю дорогу думал про работу (планировал, анализировал, перебирал в голове варианты), короче делал то, без чего работу не сделать. это считать за рабочее время, или нет?
Расскажите поподробнее, пожалуйста. Я тоже хочу попробовать odesk, но боюсь. :)
Проблема в том, что непосредственно набор кода обычно занимает меньше половины времени, а остальное время — изучение предметной области задачи, обдумывание архитектуры, чтение стандартов, документации к библиотекам и т.п. Как доказывать заказчику, что я не бездельничаю половину времени, а выполняю непосредственно его работу?
Проблема в том, что непосредственно набор кода обычно занимает меньше половины времени, а остальное время — изучение предметной области задачи, обдумывание архитектуры, чтение стандартов, документации к библиотекам и т.п. Как доказывать заказчику, что я не бездельничаю половину времени, а выполняю непосредственно его работу?
Не бойтесь :)
oDesk предоставляет програмку, которая висит у вас запущенной, и когда вы включаете т.н. «трекинг» — скриншотит ваш экран раз в 10 минут (а заодно считает кол-во нажатий клавиш и частоту движений мышки). Надо куда-то отойти — выключаете трекинг. Садитесь работать — включаете. Заказчик может увидеть всю эту информацию в вашем Work Diary.
oDesk предоставляет програмку, которая висит у вас запущенной, и когда вы включаете т.н. «трекинг» — скриншотит ваш экран раз в 10 минут (а заодно считает кол-во нажатий клавиш и частоту движений мышки). Надо куда-то отойти — выключаете трекинг. Садитесь работать — включаете. Заказчик может увидеть всю эту информацию в вашем Work Diary.
Ну вот как раз получается, что будет учитываться только то время, что я набираю код.
Да нет же, вы когда читаете документацию — не выключаете трекинг просто. Это ваше время и оно должно быть оплачено. Для статуса "billed time, online" скриншоту достаточно одного-двух нажатий клавиш. При обдумывании архитектуры вы впоследствии добавляете "offline time" с пометкой «обдумывал архитектуру». Это время получает статус "billed time, offline". Злоупотреблять оффлайн-временем не стоит, но обычно заказчики все прекрасно понимают и соглашаются с ним (вернее, не «не соглашаются»).
Я искал такой таймер, не нашел ничего удобного. На день рождения попрошу знакомых подарить оффлайновые шахматные часы.
Это всё очень хорошо и классно, когда знаешь сколько времени займёт та или иная задача. И даже можно приблизительно оценить займёт это больше 4-х часов или нет.
А как быть в случае если попросили сделать то чего раньше никогда не делал и тут же просят предоставить эстимейт на таск? Ведь это явно займёт больше 4-х часов, но точное время неизвестно.
И как то будет не очень красиво говорить заказчику сначала одно время, а потом другое.
Или если не имел с этим дело, то лучше не браться?
А как быть в случае если попросили сделать то чего раньше никогда не делал и тут же просят предоставить эстимейт на таск? Ведь это явно займёт больше 4-х часов, но точное время неизвестно.
И как то будет не очень красиво говорить заказчику сначала одно время, а потом другое.
Или если не имел с этим дело, то лучше не браться?
«Любой инженер-строитель шарахнется от такого предложения, программисты же в своей жажде заключить сделку прикинут смету, удвоят ее, добавят 30% и будут надеяться на лучшее. Как отвечаю на такой вопрос я?»
я так понимаю, тут автор перевел developers как программисты — хотя на самом деле тут имелось ввиду девелоперы, которые строят дома — да, они так называются.
я так понимаю, тут автор перевел developers как программисты — хотя на самом деле тут имелось ввиду девелоперы, которые строят дома — да, они так называются.
Any engineer would immediately recoil from such a suggestion, however many times software developers, probably anxious to close the deal, will do a wild estimate, double it and add 30% and hope for the best.
Право, не вижу, как можно трактовать software developer как домостроитель?
см. «Если бы программисты строили дома»
наоборот, в оригинале было не «инженер-строитель» а просто инженер, и явно software-developer
В таком идеальном положении дел, как в описании, всё выглядит клёво. И может быть, в отдельных случаях такое может получиться. Но на деле для этого нужна недюжинная дисциплина, трезвая оценка и большой опыт, то есть в итоге в большинстве случаев это выльется в разводилово с точки зрения клиента.
Да, есть много случаев, когда почасовой тариф предпочтительнее, но не очень понятно, в чём проблема заранее просчитать человекочасы, которые потребуются, чтобы «добавить несколько возможностей в небольшое приложение на Django» и не назвать заказчику хотя бы вилку. При опыте, который потребуется, чтобы трезво оценить себя почасово, это вообще пустяковая задача.
Да, есть много случаев, когда почасовой тариф предпочтительнее, но не очень понятно, в чём проблема заранее просчитать человекочасы, которые потребуются, чтобы «добавить несколько возможностей в небольшое приложение на Django» и не назвать заказчику хотя бы вилку. При опыте, который потребуется, чтобы трезво оценить себя почасово, это вообще пустяковая задача.
Дисциплина как раз нужна когда оплачивают фиксированную сумму. А когда ты продаешь свое время, то понимаешь что сходив покурить ты стырил пару баксов :) Я год назад перешел на рейт и с дисциплиной у меня стало все намного лучше.
Проблемы были перечислены в статье. Фиксированный рейт вызывает постоянные споры что входит в скоп, а что нет. Многочисленные мелкие изменения после крупной работы иногда просто бесят. Дополнения надо обсуждать не только по смыслу а еще и по деньгам. В общем много не нужных разговоров и эмоций, полностью отсутствующие при почасовой оплате.
Трезвая оценка, опыт и прочее не помешают никогда.
Проблемы были перечислены в статье. Фиксированный рейт вызывает постоянные споры что входит в скоп, а что нет. Многочисленные мелкие изменения после крупной работы иногда просто бесят. Дополнения надо обсуждать не только по смыслу а еще и по деньгам. В общем много не нужных разговоров и эмоций, полностью отсутствующие при почасовой оплате.
Трезвая оценка, опыт и прочее не помешают никогда.
Уважаемый автор, вся ваша схема держится исключительно на вашей порядочности!
Так работают многие софтверные компании, работающие на аутсорсе.
Скорее на репутации
«Я благороден и не стану завышать цену.»-ключевая фраза…
Из серии «мы все Джентельмены и доверяем друг другу...», заказчик это вряд ли поймет и оценит… )
Из серии «мы все Джентельмены и доверяем друг другу...», заказчик это вряд ли поймет и оценит… )
Западный заказчик оценит и поймет. А вот если вдруг случится так, что это окажется ложью, то вы потеряете не только этого заказчика. Это назыается «репутация».
А вообще, поработав немного с западными заказчиками меня приятно удивило то, насколько грамотно и четко они могут формулировать ТЗ. Буквально пару недель назад получил ТЗ на простенькую игру, в котором даже прототипы интерфейса нарисованы и оипсаны все возможные действия пользователя!
А вообще, поработав немного с западными заказчиками меня приятно удивило то, насколько грамотно и четко они могут формулировать ТЗ. Буквально пару недель назад получил ТЗ на простенькую игру, в котором даже прототипы интерфейса нарисованы и оипсаны все возможные действия пользователя!
В данном случае я выступаю от имени российского заказчика.И к сожалению неоднократно сталкивался с необязательностью исполнителей.
При том что мы приняли все условия исполнителя и вовремя представили ТЗ.
Как минимум это задержка сроков, как максимум- отказ от завершения работы,
причина?- смерть домашнего животного.
Возможно нам просто не везло…
При том что мы приняли все условия исполнителя и вовремя представили ТЗ.
Как минимум это задержка сроков, как максимум- отказ от завершения работы,
причина?- смерть домашнего животного.
Возможно нам просто не везло…
Это перевод, но да, схема держится на порядочности. И не только исполнителя, но и заказчика. Ведь он всегда может сказать «ха, да это можно было сделать за два часа вместо восьми — ты гонишь! Я не буду платить за 8 часов.»
Нужно иметь очень высокую репутацию, чтобы это работало.
Да и множество клиентов отсеются только потому, что они предпочтут не доверять даже самому авторитетному работнику.
Да и множество клиентов отсеются только потому, что они предпочтут не доверять даже самому авторитетному работнику.
В статье затронута интересная проблема: чтобы давать часовую ставку, время надо знать. Реальное время, а не недели чтения башорга и ковыряния в носу. Многие, если не большинство разработчиков, реальных затрат на проекте не знают. Даже конторы с большим штатом не особо учитывают.
Лично для меня почасовой рейт — показатель зрелости. Это как минимум означает, что исполнитель поставил задачу учета и худо-бедно контролирует затраты.
Например, последний год веду хронометраж проектов. Личный и сотрудников. Очень сильно отрезвляет. Даже без почасовой ставки. Знал бы заранее, что в одном проекте будет 37 часов обсуждений и почти 11 на телефоне — калькуляция была бы другой.
Лично для меня почасовой рейт — показатель зрелости. Это как минимум означает, что исполнитель поставил задачу учета и худо-бедно контролирует затраты.
Например, последний год веду хронометраж проектов. Личный и сотрудников. Очень сильно отрезвляет. Даже без почасовой ставки. Знал бы заранее, что в одном проекте будет 37 часов обсуждений и почти 11 на телефоне — калькуляция была бы другой.
Вы говорите про внутренний учет. Тут с Вами не поспоришь — время как ресурс в России учитывать, планировать, распределять и т.д. как-то не очень умеют (вернее, в большинстве случаев не осознают это как задачу).
Но насчет показателя зрелости готов поспорить. То, по какому принципу осуществляется оплата, зависит не от зрелости исполнителя, а в определяющей степени — от заказчика (еще точнее — от рынка, на котором работает исполнитель). Если рынок еще не готов к почасовой оплате, то с этим мало что можно поделать. Исключения, конечно, возможны (как на уровне конкретных проектов, так и на уровне отдельных очень умело позиционирующихся компаний). Но они все равно будут составлять лишь незначительную долю.
Но насчет показателя зрелости готов поспорить. То, по какому принципу осуществляется оплата, зависит не от зрелости исполнителя, а в определяющей степени — от заказчика (еще точнее — от рынка, на котором работает исполнитель). Если рынок еще не готов к почасовой оплате, то с этим мало что можно поделать. Исключения, конечно, возможны (как на уровне конкретных проектов, так и на уровне отдельных очень умело позиционирующихся компаний). Но они все равно будут составлять лишь незначительную долю.
>Клиент: Вот участок, на котором мы будем строиться. Вот наброски того, что мы хотим построить. Можете назвать точную стоимость постройки?
>Любой инженер-строитель шарахнется от такого предложения
Весьма-весьма сомнительно про строителей. По своему опыту работы в стройфирмах: прикинут объёмы (ресурсоемкость проекта), если нет готовой проектной документации, составят на них смету (стараясь не сильно её раздувать), добавят накладные расходы и сметную прибыль (точные значение не помню, причём зависят они по нормативам от вида и условий работы, но в среднем да, около 30%, если склероз не изменяет), озвучат и если порядок цен заказчика устроит, то начнут проектировать (за отдельную плату), стараясь раздуть смету (более дорогие материалы и виды работ, «фичи» и т. п.) в рамках оценки платежеспособности клиента.
>Любой инженер-строитель шарахнется от такого предложения
Весьма-весьма сомнительно про строителей. По своему опыту работы в стройфирмах: прикинут объёмы (ресурсоемкость проекта), если нет готовой проектной документации, составят на них смету (стараясь не сильно её раздувать), добавят накладные расходы и сметную прибыль (точные значение не помню, причём зависят они по нормативам от вида и условий работы, но в среднем да, около 30%, если склероз не изменяет), озвучат и если порядок цен заказчика устроит, то начнут проектировать (за отдельную плату), стараясь раздуть смету (более дорогие материалы и виды работ, «фичи» и т. п.) в рамках оценки платежеспособности клиента.
Прочитал про сметную прибыль как концепцию и просто офигел. Это ж просто бред. Вы можете представить чтобы кто-то в ИТ взял и ключил в договор подряда некий коэффициент Х, который увеличивает стоимость проекта на столько, сколько мы хотим пустить на налоги, премирование, и т.п.?!?
Или это бред, или я чего-то не понимаю…
Или это бред, или я чего-то не понимаю…
Исходят из того, что ресурсоемкость (включая трудоемкость и фонд оплаты труда непосредственно рабочих) объекта по одному проекту не зависит от исполнителя: существуют так называемые федеральные и территориальные единичные расценки (ФЕР/ТЕР), для бюджетных заказов они обязательны, афаик, небюджетные (те, кто в теме) на них ориентируются, т. к. уменьшение ресурсоемкости (кроме ФОТ, но не трудоемкость), будет означать несоответствие СНиПам/ГОСТам, что чревато вплоть до УК, а увеличение -неэффективному использованию ресурсов заказчика… То есть, если есть проект, то теоретическая «себестоимость» его будет одинакова для любой фирмы-исполнителя, равно как и накладные расходы. «Играть» (например, на тендере) остается только сметной прибылью (ну, может, накладными расходами чуть-чуть, иногда изменениями проектных решений, но это надо постараться заказчика (или конкретного его представителя ;), убедить в их целесообразности, ну или условиями поставки материалов ниже среднерыночных (официально выходят ежемсячные сборники средних цен), но последнего на практике почти не встречал, поскольку часто материалы оплачивает непосредственно заказчик или требуются подтверждающие документы, что, правда, не проблема, есть есть не одно юрлицо). На деле, конечно, стараются всеми способами (не всегда законными/этичными) уменьшить реальную себестоимость (вплоть до невыполнения некоторых видов работ вообще, наиболее часто — экономия ФОТ рабочих) и увеличить сметную стоимость (доп.работы, зачастую высосанные из пальца и т. п.).
Кстати, некоторые виды работ относящиеся вроде как к ИТ, например устройство СКС, нормируются этими расценками тоже, по крайней мере на достаточно крупных объектах или в ходе других СМР. Ну а так, поскольку в других отраслях ИТ, таких как разработка софта, сложно (будем считать, что возможно) оценить прежде всего трудоемкость и часовые ставки (у рабочих есть разряды) с точностью до минуты и копейки, а значит вывести хотя бы теоретическую себестоимость продукта, то такие методы даже отдаленно не применимы и кажутся с точки зрения «свободного рынка» (какое дело заказчику до реальной себестоимости? или устраивает предлагаемая цена решения, или нет) бредом. Переключаться, кстати, сложно.
Кстати, некоторые виды работ относящиеся вроде как к ИТ, например устройство СКС, нормируются этими расценками тоже, по крайней мере на достаточно крупных объектах или в ходе других СМР. Ну а так, поскольку в других отраслях ИТ, таких как разработка софта, сложно (будем считать, что возможно) оценить прежде всего трудоемкость и часовые ставки (у рабочих есть разряды) с точностью до минуты и копейки, а значит вывести хотя бы теоретическую себестоимость продукта, то такие методы даже отдаленно не применимы и кажутся с точки зрения «свободного рынка» (какое дело заказчику до реальной себестоимости? или устраивает предлагаемая цена решения, или нет) бредом. Переключаться, кстати, сложно.
Я бы не стал с таким работать. Попросту — мне перед начальством отчитываться за потраченные деньги и время, и мне нужно заранее знать сколько это будет стоить и сколько уйдет времени. Будь они даже в 2-а раза завышенные. Иначе меня пошлют подальше.
Он говорит о каких то оценках задания. Эх. Сколько я видел таких оценщиков, хоть бы один попал в +- 30% от названного.
Короче не верю я в это. Возможно при работе один на один это и прокатит, но не более.
Он говорит о каких то оценках задания. Эх. Сколько я видел таких оценщиков, хоть бы один попал в +- 30% от названного.
Короче не верю я в это. Возможно при работе один на один это и прокатит, но не более.
Работаю так с голландской компанией более 5 лет. Они научили меня многому. Вкратце, все действительно как описал автор и это работает отлично. Более того, они (мой customer) другого пути взаимодействия не приемлют. Они приходят ко мне с большим проектом, но не отдают его сразу целиком. Они сами разбивают его на user story. Сами выделяют tasks в user story. Я только даю свой estimate. Они либо соглашаются с ним, либо нет. Если не соглашаются, то я им делаю work break down c estimate по каждому пункту. В этом случае они лишний раз убеждаются что я их не обманываю и это перерастает в нерушимое доверие. Они платят только за prefect часы. Им это выгодно потому что они не платят за мой простой. Им это выгодно потому что они подрядчики, а я субподрядчик. Часы которые я им выставил в качестве estimate, они выставляют своему customerу и получают за это также пропорционально часам или больше, я не знаю, может они и увеличивают. Для сравнения, их час стоит 60EUR. Мой в разы меньше. Все счастливы. Но если я делаю проект для них, то тоже все хорошо, потому что они мне верят и час для их проекта стоит чуть меньше, потому что я понимаю что они тут платят из своего кармана, а свои деньги всегда считаешь.
С ними работать не просто. Каждый день standup. Три вопроса — что сделал, что собираюсь делать, есть ли проблемы. Все это по скайпу текстом. Разговор отбирает больше времени. Все отработано так чтобы время тратилось эффективно. На болтовню редко уходит больше 30 минут, но никогда больше 1 часа.
Мне кажется это отличная схема для честных отношений. Она позволяет защитить и интересы разработчика и интересы заказчика. Заказчик знает за что платит, а разработчик учится давать точные с определенной вероятностью оценки, которые позволяют ему включить и тестирование и риски и никуда не спешить и не вгонять себя в стресс. При такой схеме работы по выходным не случается, переработок тоже. А если хочешь подработать или сил много, то пожалуйста, начинай раньше, заканчивай позже. При этом ты знаешь что получишь процентов на >50% больше… Мотивация хорошая…
С ними работать не просто. Каждый день standup. Три вопроса — что сделал, что собираюсь делать, есть ли проблемы. Все это по скайпу текстом. Разговор отбирает больше времени. Все отработано так чтобы время тратилось эффективно. На болтовню редко уходит больше 30 минут, но никогда больше 1 часа.
Мне кажется это отличная схема для честных отношений. Она позволяет защитить и интересы разработчика и интересы заказчика. Заказчик знает за что платит, а разработчик учится давать точные с определенной вероятностью оценки, которые позволяют ему включить и тестирование и риски и никуда не спешить и не вгонять себя в стресс. При такой схеме работы по выходным не случается, переработок тоже. А если хочешь подработать или сил много, то пожалуйста, начинай раньше, заканчивай позже. При этом ты знаешь что получишь процентов на >50% больше… Мотивация хорошая…
Да, так я работаю в самоорганизующейся команде, которая состоит из ответственных и опытных разработчиков, которых не надо гонять палкой. Менеджера или Тимлидера с нашей стороны нет. Кастомер сам рулит нами ненавязчиво. Да, кстати, раз я уже заговорил про цифры, то скажу что их менеджер в час стоит 90 EUR… Это если кто-то задается вопросами ценообразования…
Еще стоит сказать про гранулярность времени. Оценка всегда дается в часах и кратно часу. Не бывает оценок 8 часов 23 минуты. Округление всегда вверх. Задач меньше чем на 1 час не бывает. За редким исключением. Например, поменять текст у кнопки — 30 минут. Не 1 и не 10, а не меньше 30. Задач больше 40 часов не бывает…
Да, время на коммуникацию тоже оплачивается тоже… Т.е. после каждого скайп чата можно смело писать в систему трекинга времени — standup 0.5h.
Да, время на коммуникацию тоже оплачивается тоже… Т.е. после каждого скайп чата можно смело писать в систему трекинга времени — standup 0.5h.
Для сравнения, их час стоит 60EUR
Чем-то вы не тем занимаетесь…
Судя по ключевым словам (user stories, tasks, estimates, perfect time, daily stand-ups с тремя вопросами), Ваши заказчики однозначно исповедуют методологию Scrum :)
Вот в отношения генподрядчик-субподрядчик («обычный» подрядчик работает на заказчика своими силами) повременная оплата имеет очень большое право на жизнь по одной простой причине — генподрядчик «в теме» и не будет ни требовать заведомо невозможно малое время, ни переживать, что его «кидают», заставляя оплачивать «пинание балды» или, ещё «лучше», работу на конкурента. Конечно, встречаются и заказчики «в теме» или доверяющие подрядчикам на слово, но, имхо, нельзя исключить, что ваш генподрядчик получает (в итоге или поэтапно — не суть) от заказчика не по трудоемкости, а по цене решения задачи (возможно где-то теряя, если вы оказались недостаточно «расторопны», а где-то наоборот имеет внеплановую прибыль)
У Вас скрам головного мозга
Очень интересная ситуация.
Вообще, давно уже страдаю, что нет у нас услуг «прораб в аренду» (чтобы нанять его и таджиков, и он следит и чтобы дом строили «как полагается», и самому заказчику объяснит, что в проекте не очень хорошо, и следит чтобы материалы покупались за честные деньги итд). Заплатить тысяч 50-150 за его хлопоты, но знать, что ты ни за что не переплатил, и дом у тебя не развалится оттого что половину цемента продали, а остальной разбодяжили. У нас же известное правило состоит в том, что если нанять прораба, чтобы следил за тем, чтоб таджики не воровали — то воровать будут и они и он :-).
А тут, оказывается, что такая полезная услуга, она вообще и в IT существует и востребована. Можно даже попробовать свои силы в этой сфере.
Вообще, давно уже страдаю, что нет у нас услуг «прораб в аренду» (чтобы нанять его и таджиков, и он следит и чтобы дом строили «как полагается», и самому заказчику объяснит, что в проекте не очень хорошо, и следит чтобы материалы покупались за честные деньги итд). Заплатить тысяч 50-150 за его хлопоты, но знать, что ты ни за что не переплатил, и дом у тебя не развалится оттого что половину цемента продали, а остальной разбодяжили. У нас же известное правило состоит в том, что если нанять прораба, чтобы следил за тем, чтоб таджики не воровали — то воровать будут и они и он :-).
А тут, оказывается, что такая полезная услуга, она вообще и в IT существует и востребована. Можно даже попробовать свои силы в этой сфере.
Какие утилиты используете? Такс-трекеры, тайм-трекеры? Взаимодействие с заказчиком (кроме скайпа)?
Всё, решил для себя, что нужно купить таймер. Тогда я смогу точно оценить сколько времени я работаю и сколько трачу на ерунду.
Посоветуйте настольные часы с таймером, кто какие может использует !?
Посоветуйте настольные часы с таймером, кто какие может использует !?
А чем вас часы в таскбаре не устраивают. Вам шашечки или ехать?
Самые очевидные недостатки:
Почасовка стимулирует к обману, туплению, неэффективному расходу времени, и в то же время с другой стороны — к переработке от жадности. Можно сто раз сказать «я самый умный, честный и благородный», но рано или поздно природа возьмёт своё и будет завал или в халтуру, или в переработку и падение эффективности.
Кроме того, разные задачи очень отличаются по удельной нагрузке на мозги.
Если результат почасовой оплаты напрямую влияет на личный заработок, то ещё и финансовое положение всё время колбасит.
Провалы в загрузке по вине клиента приводят к провалу в финансах.
Для кратковременных заказных задач и плохой организации (например, когда ТЗ перекраивается ежедневно) почасовка нормальный вариант, просто потому что ничего лучше нету.
Для нормальной работы — всё должно быть как у людей, ставка, премия и т.п., никаких почасовок.
За 10 лет познал немало почасовок. Было периодами и также прекрасно, как автор расписывает. Но по сравнению с нормальной системой з/п — в гробу видал в белых тапочках.
Почасовка стимулирует к обману, туплению, неэффективному расходу времени, и в то же время с другой стороны — к переработке от жадности. Можно сто раз сказать «я самый умный, честный и благородный», но рано или поздно природа возьмёт своё и будет завал или в халтуру, или в переработку и падение эффективности.
Кроме того, разные задачи очень отличаются по удельной нагрузке на мозги.
Если результат почасовой оплаты напрямую влияет на личный заработок, то ещё и финансовое положение всё время колбасит.
Провалы в загрузке по вине клиента приводят к провалу в финансах.
Для кратковременных заказных задач и плохой организации (например, когда ТЗ перекраивается ежедневно) почасовка нормальный вариант, просто потому что ничего лучше нету.
Для нормальной работы — всё должно быть как у людей, ставка, премия и т.п., никаких почасовок.
За 10 лет познал немало почасовок. Было периодами и также прекрасно, как автор расписывает. Но по сравнению с нормальной системой з/п — в гробу видал в белых тапочках.
Все дуально в нашей жизни. И так хорошо и так хорошо и так плохо и так плохо. Может лучше рассуждать кому как больше нравится…
А я 11 лет работал на зарплате и вот уже второй год пошел как на почасовом рейте и доволен.
Провалов нет, если сам себе их не устроишь. У меня всегда есть 2-3 заказчика крупных и периодически подбираю мелкие заказы, которые иногда становятся крупными. Так что больше чем в 2 раза не проседаю и зарабатываю столько сколько работаю. Но премии видел чаще в последний год чем за все те годы что сидел на зарплате и они были за дело.
Ни к чему такому не стимулирует. Мне проще сделать другую работу другому Заказчику чем обманывать. Завал — это мой завал, взял выходной — смотался в горы и отдохнул. Никто при этом не напрягается.
Да задачи разные. Но и рейт тоже разный. Если задача трудная, уникальная и я чувствую что буду там выкладываться, то и рейт поднимаю.
Если честно я еще ни разу не видел нормальный ТЗ на старте. Чесслово! Вот 5 лет работал ПМ-ом и имел миллионые проекты и третий год как фрилансю — не было такого что бы ТЗ написали сразу нормально.
Провалов нет, если сам себе их не устроишь. У меня всегда есть 2-3 заказчика крупных и периодически подбираю мелкие заказы, которые иногда становятся крупными. Так что больше чем в 2 раза не проседаю и зарабатываю столько сколько работаю. Но премии видел чаще в последний год чем за все те годы что сидел на зарплате и они были за дело.
Ни к чему такому не стимулирует. Мне проще сделать другую работу другому Заказчику чем обманывать. Завал — это мой завал, взял выходной — смотался в горы и отдохнул. Никто при этом не напрягается.
Да задачи разные. Но и рейт тоже разный. Если задача трудная, уникальная и я чувствую что буду там выкладываться, то и рейт поднимаю.
Если честно я еще ни разу не видел нормальный ТЗ на старте. Чесслово! Вот 5 лет работал ПМ-ом и имел миллионые проекты и третий год как фрилансю — не было такого что бы ТЗ написали сразу нормально.
Я имел в виду, что лично мне жить с помесячной оплатой больше нравится, чем с почасовой. Но с 2-3 заказчиками и ещё мелкими — кроме почасовки, в общем, нормальных вариантов просто нету.
А как справляетесь с ситуацией двух одновременных заказов от заказчиков, которым отказывать очень не хочется, чтобы их не потерять? Говорите, что, например, это займёт часов 40, но больше 20 часов в ближайшую неделю я на вас работать не смогу или как?
В принципе примерно так и получается, просто не так явно.
Ставятся ( я запрашиваю ) задачи и приоритеты, иногда просят оценку стоимости для фич, но как правило если надо значить надо. Я делаю то что мне в данный момент удобнее или нравиться из более приоритетного.
Мелкие заказы я просто не считаю — ну часик-другой поработал вместо просмотра очередной каприки… зато развлекся. Неинтересное не беру само собой.
Ставятся ( я запрашиваю ) задачи и приоритеты, иногда просят оценку стоимости для фич, но как правило если надо значить надо. Я делаю то что мне в данный момент удобнее или нравиться из более приоритетного.
Мелкие заказы я просто не считаю — ну часик-другой поработал вместо просмотра очередной каприки… зато развлекся. Неинтересное не беру само собой.
То есть, грубо говоря, заказчики за вами бегают, а не вы за ними?
Не могу сказать что я только и делаю что отказываю, но приглашения приходят регулярно. При чем если на odesk-e я просматриваю rss регулярно, вместе с rss хабра например, то на двух других биржах, где я не работаю активно уже давно, все равно раз в неделю кто-то что-то предлагает.
Еще есть несколько «старых» клиентов, которые подбрасывают работу регулярно — то что-то доделать, то проблему порешать, то сайт клиента на WP перекинуть.
Я стараюсь иметь не меньше 2 текущих заказчиков и не больше 4 одновременно и это мне легко удается.
Еще есть несколько «старых» клиентов, которые подбрасывают работу регулярно — то что-то доделать, то проблему порешать, то сайт клиента на WP перекинуть.
Я стараюсь иметь не меньше 2 текущих заказчиков и не больше 4 одновременно и это мне легко удается.
Спору нет, где-то такая система существует! Только работает она в основном там где клиенту впринципе пофиг как и на что расходуются деньги. Например государственный заказ! Или выше звучащий пример — покупаю часы за 10 Евро час а перепродаю за 100! Тогда даже пятикратное привышение часов все покроет!
> С почасовой оплатой вы можете сказать «ок, давайте я оценю, во сколько это вам обойдется» — а там пусть клиент сам решает, стоит ли оно того.
смешно там у них в Греции, заказчику на программера с трудом хватает :)
смешно там у них в Греции, заказчику на программера с трудом хватает :)
oDesk.com и его TimeClient?
Не понял новаторства.
Для работы которая исчисляется в часах это и так всеми применяется.
Применять почасовую оплату для проекта — бред, а не новаторство. В отличие от узбеков, копающих яму, очень велик риск напрограммировать ерунду на 200 часов и кто их будет оплачивать и главное за что?
При огромном рынке ПО пугать клиента таким подходом к оплате не стоит. Они и без того запутанные и чумные.
Для работы которая исчисляется в часах это и так всеми применяется.
Применять почасовую оплату для проекта — бред, а не новаторство. В отличие от узбеков, копающих яму, очень велик риск напрограммировать ерунду на 200 часов и кто их будет оплачивать и главное за что?
При огромном рынке ПО пугать клиента таким подходом к оплате не стоит. Они и без того запутанные и чумные.
Опытный программист вполне способен рассчитать более или менее приблизительное время, которое ему понадобится на разработку конкретного задания.
То же самое касается, зачастую, и дизайнеров.
Разработка концепции — дело другое, но за это можно как раз брать фиксированную цену и брать завышенные планки по стоимости.
На рассчитанное работниками время грамотный менеджер набрасывает ещё от 50 до 100%.
Расчёт стоимости работы конкретного сотрудника — дело не трудное (даже если брать в расчёт все нюансы по аренде офиса и т.п.).
Я знаю не одну студию и не одного фрилансера, которые так работают, и работают, прошу заметить, вполне успешно.
Так что ваш комментарий можно вполне сопоставить с уровнем вашего опыта.
То же самое касается, зачастую, и дизайнеров.
Разработка концепции — дело другое, но за это можно как раз брать фиксированную цену и брать завышенные планки по стоимости.
На рассчитанное работниками время грамотный менеджер набрасывает ещё от 50 до 100%.
Расчёт стоимости работы конкретного сотрудника — дело не трудное (даже если брать в расчёт все нюансы по аренде офиса и т.п.).
Я знаю не одну студию и не одного фрилансера, которые так работают, и работают, прошу заметить, вполне успешно.
Так что ваш комментарий можно вполне сопоставить с уровнем вашего опыта.
Очень смеялся прочитав про «более или менее приблизительное время» плюс «от 50 до 100%»
Есть ещё более точная формула расчёта — умножай всё на три.
Вообще почасовая оплата это или консультации или шабашки, если говорить об IT.
Потому что при этой форме труда может быть достигнут РЕЗУЛЬТАТ, который прежде всего и покупает нормальный клиент. Нормальный не для программиста, а для своего бизнеса.
Почасовая оплата хорошо себя проявляет в том виде труда где существуют микрооперации, например токарные работы или сборочный конвейер или наоборот когда затраты незначительны — уборщик помещения, сиделка. И в случае если надо нагнать пафосу — юрист.
Я не сталкивался с серъёзными командами которые оперирует перед заказчиком почасовой оплатой. Точнее когда они умножат на три они могут сказать это 100000 человеко-часов. Один человеко-час 20 долларов. С вас два миллиона. Приходите через три месяца. Но это не почасовая оплата. Это чистый понт и шляпа с точки зрения научной организации труда. Естати, именно в руководствах по научной организации труда есть огромное облако тумана относительно нормирования рабочего времени инженеров и проектировщиков. А с ремеслиенниками всё на высшем уровне. Нормировлись даже движения фаланги пальца. Так что можно говорить о посекундной оплате труда. Размял пальчики с утра гы гы
Есть ещё более точная формула расчёта — умножай всё на три.
Вообще почасовая оплата это или консультации или шабашки, если говорить об IT.
Потому что при этой форме труда может быть достигнут РЕЗУЛЬТАТ, который прежде всего и покупает нормальный клиент. Нормальный не для программиста, а для своего бизнеса.
Почасовая оплата хорошо себя проявляет в том виде труда где существуют микрооперации, например токарные работы или сборочный конвейер или наоборот когда затраты незначительны — уборщик помещения, сиделка. И в случае если надо нагнать пафосу — юрист.
Я не сталкивался с серъёзными командами которые оперирует перед заказчиком почасовой оплатой. Точнее когда они умножат на три они могут сказать это 100000 человеко-часов. Один человеко-час 20 долларов. С вас два миллиона. Приходите через три месяца. Но это не почасовая оплата. Это чистый понт и шляпа с точки зрения научной организации труда. Естати, именно в руководствах по научной организации труда есть огромное облако тумана относительно нормирования рабочего времени инженеров и проектировщиков. А с ремеслиенниками всё на высшем уровне. Нормировлись даже движения фаланги пальца. Так что можно говорить о посекундной оплате труда. Размял пальчики с утра гы гы
Прикольно.
Как вспомню взгляды сотрудников на часы в офисе — так сразу же становится тепло на душе…
Не для нас это… Не для нас.
Как вспомню взгляды сотрудников на часы в офисе — так сразу же становится тепло на душе…
Не для нас это… Не для нас.
Лично мне на почасовке порой бывает туго. Большие проекты сложно просчитать заранее и определить время, которое на них уйдет, чтобы клиент мог оценить примерные сроки и стоимость. Маленькие задачки вызывают необходимость тратить уйму времени на просчет их стоимости. Часто приходится работать, что называется, по факту затраченного времени, но такое бывает редко.
Мы в нашей компании работаем и по повременной оплате и по фиксированной за результат. 90% повременка — клиенты понимают, что так на самом деле дешевле, т.к. при фиксированной сумме — в нее мы добавляем риски, что что то не учли, стоимость риска от 20% до бесконечности в зависимости от вменяемости заказчика. И еще очень много экономиться на ТЗ, не в том плане что мы его не делаем, а в том что его не обязательно становиться расписывать во всех подробностях, т.к. чуть-чуть поправить по просьбе клиента, зачастую, намного проще, чем расписать ТЗ до винтиков. И самое главное результат при почасовке достигается в 100% случаев.
Я работал так с программером. Я давал ему подробное ТЗ, он мне давал полный расклад, сколько времени на что он потратит.
Все сверхурочные обсуждаются отдельно… Но в 99% случаях он всегда укладывался в план, который сам и нарисовал по моему ТЗ.
А платить за что-то можно, но вопрос когда?
Все сверхурочные обсуждаются отдельно… Но в 99% случаях он всегда укладывался в план, который сам и нарисовал по моему ТЗ.
А платить за что-то можно, но вопрос когда?
Уже несколько лет готовлю предложения на запрос о разработке в виде сметы с пунктами работ, временем на их реализацию и стоимостью по пунктам из расчёта 3000 рублей 1 рабочий день (8 часов).
При этом перерасход времени за мой счёт (из требуемого функционала), а при доработках дополнительные сметы.
Естественно предварительно беседую с клиентом, чтобы разузнать что же ему необходимо — клиент редко представляет, что же ему надо на самом деле.
Все довольны.
Сумма в 50-100 т.рублей может шокировать клиента, а описание конкретных модулей с расчасовкой и их стоимостью аккурат складываются в эту цифру и клиент понимает за что он платит.
Психология.
Когда руководил студией — у нас был калькулятор, где расчитывали каждую роль по часам, там шестизначные доллоравые суммы складывались из множества десятков и сотен. У клиентов редко возникали вопросы. Разве что отказывались иногда от глобальных доработок. Или наоборот.
При этом перерасход времени за мой счёт (из требуемого функционала), а при доработках дополнительные сметы.
Естественно предварительно беседую с клиентом, чтобы разузнать что же ему необходимо — клиент редко представляет, что же ему надо на самом деле.
Все довольны.
Сумма в 50-100 т.рублей может шокировать клиента, а описание конкретных модулей с расчасовкой и их стоимостью аккурат складываются в эту цифру и клиент понимает за что он платит.
Психология.
Когда руководил студией — у нас был калькулятор, где расчитывали каждую роль по часам, там шестизначные доллоравые суммы складывались из множества десятков и сотен. У клиентов редко возникали вопросы. Разве что отказывались иногда от глобальных доработок. Или наоборот.
Пример про здание очень неудачный: обычно когда проектируют здание и планируют его постройку, то сразу делают смету, по которой считаются расходы на постройку здания и выделяется бюджет.
А откуда проектировщики знают, какие коммуникации и прочие подземные камни находятся на планируемом участке прежде, чем приступить к разработке? Как можно проектировать котлован под фундамент не зная, глинозём там, песок или гранит?
Аналогия между разработкой (девелопингом) земельных участков и разработкой ПО на самом деле вполне адекватная. А основная идея обсуждаемого грека (скрытая за реализацией в виде почасовой оплаты) — в том, что надо ставить реальные цели, по которым можно предсказать стоимость их достижения. В разработке ПО это достигается очень мелкими итерациями — как раз от получаса до половины рабочего дня.
Аналогия между разработкой (девелопингом) земельных участков и разработкой ПО на самом деле вполне адекватная. А основная идея обсуждаемого грека (скрытая за реализацией в виде почасовой оплаты) — в том, что надо ставить реальные цели, по которым можно предсказать стоимость их достижения. В разработке ПО это достигается очень мелкими итерациями — как раз от получаса до половины рабочего дня.
Сам работал с программистами и так и так. На данный момент могу сказать, что почасовая оплата лучше
мне кажется разумнее комбинированная схема
Минимальная почасовая оплата + существенное вознаграждение после выполнение этапа
Минимальная почасовая оплата + существенное вознаграждение после выполнение этапа
Очень давно сталкиваемся с данным вопросом. Я не могу сказать, что почасовая ставка удобна и прибыльна (!) для всех видов проектов. Например, если проект небольшой, плюс у вас уже есть определенные заготовки и нужно совсем немного времени, чтобы с их помощью склеить новый проект, то в этом случае гораздо выгодней «продать» все это за фиксированную цену.
Вообще, вопрос о выборе способа оплаты поднимается с каждым новым клиентом. Для этого мы составили небольшую сводную таблицу плюсов и минусов обоих подходов (на английском) — Fixed price vs Hourly rate и всех кого мучает данный вопрос просим с ней ознакомится.
Вообще, вопрос о выборе способа оплаты поднимается с каждым новым клиентом. Для этого мы составили небольшую сводную таблицу плюсов и минусов обоих подходов (на английском) — Fixed price vs Hourly rate и всех кого мучает данный вопрос просим с ней ознакомится.
Когда несколько лет назад от меня требовали почасовых отчетов, я написал специальный ява-апплет, который по хоткею вылезал — текстовое поле небольшое посередине экрана, я забивал туда что делаю и ентер.
Дальше если занимаюсь чем-то еще и это что-то больше 5 минут то правило было — включить эту хрень и вбить что я делаю.
Потом все это оказывалось в парсябильном текстовом файле. Все эти хоткеи реализовались через JNI, с либой для виндов и линухов.
Фишка в том, что т.к. оно не занимает места на экране, нет мыши, и выскакивает только небольшое текст. поле — не происходит отвлечения от работы, нет переключения контекста мозга. Нажал хоткей — вбил что делаю (1 строка) — нажал enter на сохранить. небольшое поле позволяет не отвлекаться от работы.
Служило это не только для работы, но и для собственного тайм-менеджмента. Потом, просматривая логи, понимаешь, куда действительно уходит время и сколько. Такой вот ретроанализ. Главное — не забывать жать на хоткей если что-то занимает больше чем 5 минут.
Например, пишу этот коммент. Постфактум вижу что он занял 10 минут. А ведь не собирался. Должен нажать на хоткей и залогать эту трату времени.
Исходники этого дела до сих пор валяются на каком-то из моих старых винтов. Писал сам, т.к. ничего более удобного не нашел. Наверняка сейчас есть что-то подобное лучше, но я не знаю.
— Илья
Дальше если занимаюсь чем-то еще и это что-то больше 5 минут то правило было — включить эту хрень и вбить что я делаю.
Потом все это оказывалось в парсябильном текстовом файле. Все эти хоткеи реализовались через JNI, с либой для виндов и линухов.
Фишка в том, что т.к. оно не занимает места на экране, нет мыши, и выскакивает только небольшое текст. поле — не происходит отвлечения от работы, нет переключения контекста мозга. Нажал хоткей — вбил что делаю (1 строка) — нажал enter на сохранить. небольшое поле позволяет не отвлекаться от работы.
Служило это не только для работы, но и для собственного тайм-менеджмента. Потом, просматривая логи, понимаешь, куда действительно уходит время и сколько. Такой вот ретроанализ. Главное — не забывать жать на хоткей если что-то занимает больше чем 5 минут.
Например, пишу этот коммент. Постфактум вижу что он занял 10 минут. А ведь не собирался. Должен нажать на хоткей и залогать эту трату времени.
Исходники этого дела до сих пор валяются на каком-то из моих старых винтов. Писал сам, т.к. ничего более удобного не нашел. Наверняка сейчас есть что-то подобное лучше, но я не знаю.
— Илья
Сейчас таксисты берут минимальную оплату при посадке, сразу, в Москве уж точно. Вроде 500 руб.
Никто не поедет от вокзала до подворотни на 1 км, быстро-быстро за 5 минут, чтобы получить 50 рублей.
— Если специалист-разработчик будет работать за почасовую оплату, но сделает он проект, качественно и надёжно не за 6 месяцев, например, как другие, а за один месяц? И что же? Он получит в 6 раз меньше? Ему это выгодно? Нет.
Договариваться нужно только о фиксированной оплате. Хороший спец всегда знает себе цену, даже ничего не подсчитывая детально. Новички будут подетально рассматривать ТЗ, подсчитывать каждый абзац и высчитывать копейки за каждое слово (утрирую), а профи просто ЗНАЕТ, что ему на этот проект нужно пару месяцев чистого времени (включая доработки, тестирование, телефонные переговоры и т.п.)
То есть, важен результат.
А ещё лучше всего, если разработчик будет заинтересован в том, чтобы проект хорошо работал, был надёжен, лёгок в поддержке, а ещё приносил прибыль. Важно стимулирование, но не временное. За время работают люди в некоторых офисах и на заводах — от забора до обеда. Простой? Это же выгодно — «Мы сидим, а денежка идёт» — пословица всех рабочих.
Посмотрите фильм «Премия» 1974 года…
Никто не поедет от вокзала до подворотни на 1 км, быстро-быстро за 5 минут, чтобы получить 50 рублей.
— Если специалист-разработчик будет работать за почасовую оплату, но сделает он проект, качественно и надёжно не за 6 месяцев, например, как другие, а за один месяц? И что же? Он получит в 6 раз меньше? Ему это выгодно? Нет.
Договариваться нужно только о фиксированной оплате. Хороший спец всегда знает себе цену, даже ничего не подсчитывая детально. Новички будут подетально рассматривать ТЗ, подсчитывать каждый абзац и высчитывать копейки за каждое слово (утрирую), а профи просто ЗНАЕТ, что ему на этот проект нужно пару месяцев чистого времени (включая доработки, тестирование, телефонные переговоры и т.п.)
То есть, важен результат.
А ещё лучше всего, если разработчик будет заинтересован в том, чтобы проект хорошо работал, был надёжен, лёгок в поддержке, а ещё приносил прибыль. Важно стимулирование, но не временное. За время работают люди в некоторых офисах и на заводах — от забора до обеда. Простой? Это же выгодно — «Мы сидим, а денежка идёт» — пословица всех рабочих.
Посмотрите фильм «Премия» 1974 года…
Видимо, вы о «типовом» девелопменте, типа вебстудий, да? Со сложным проектом время не всегда очевидно имхо.
Я не за время голосую, и не за фиксированную оплату тоже. А за результат.
Поясняю: например, один строитель может построить дом за 3 месяца, другой за 6 месяцев, третий за 2 года. Кого выбрать?
Первый строитель построит за 3 месяца, но на 112 день отлетает полка в ванной, на 123-ий пол трескается, а на 200-ый день, чтобы поставить окно в гостиной, нужно переделывать весь дом ещё 2 месяца.
Третий строитель делал-делал 2 года, а чего 2 года дом никому оказался не нужным уже, время ушло. Например, вместо жж появился твиттер и крутое расширение для жж для файрфокса просто тупо никому не нужно.
Второй строитель сделал всё чётко за 6 месяцев, в срок, поддерживать дом легко, как конструктор лего, жить в доме хорошо и удобно, каждый день жители ходят на работу и зарабатывают деньги, не думают больше о доме, нигде ничего не отваливается и т.п.
А теперь вопросы:
1. Какой строитель сколько денег может запросить за строительство описанных вариантов домов?
2. Кого выберет клиент?
Поясняю: например, один строитель может построить дом за 3 месяца, другой за 6 месяцев, третий за 2 года. Кого выбрать?
Первый строитель построит за 3 месяца, но на 112 день отлетает полка в ванной, на 123-ий пол трескается, а на 200-ый день, чтобы поставить окно в гостиной, нужно переделывать весь дом ещё 2 месяца.
Третий строитель делал-делал 2 года, а чего 2 года дом никому оказался не нужным уже, время ушло. Например, вместо жж появился твиттер и крутое расширение для жж для файрфокса просто тупо никому не нужно.
Второй строитель сделал всё чётко за 6 месяцев, в срок, поддерживать дом легко, как конструктор лего, жить в доме хорошо и удобно, каждый день жители ходят на работу и зарабатывают деньги, не думают больше о доме, нигде ничего не отваливается и т.п.
А теперь вопросы:
1. Какой строитель сколько денег может запросить за строительство описанных вариантов домов?
2. Кого выберет клиент?
Methos ↑: Если специалист-разработчик будет работать за почасовую оплату, но сделает он проект, качественно и надёжно не за 6 месяцев, например, как другие, а за один месяц? И что же? Он получит в 6 раз меньше? Ему это выгодно? Нет.
Ну что же вы все там мыслите узко-то? Выгодно конечно. Ему же не полгода жить а намного больше.
И в случае такой большой разницы и рейт у такого крутого перца будет соответствующий.
К сожалению, в большинстве случае, почасовая оплата — способ накрутить цену еще круче, чем +30%.
Почасовая оплата говорит неумении планировать работу наперед, это намек на недисциплинированность.
Я бы с таким работать не стал. Мне нужен четкий план, надежные сроки, конкретная сумма.
Сколько часов будет на самом деле работать программист — мне фиолетово.
Хотя на вкус и цвет…
Я бы с таким работать не стал. Мне нужен четкий план, надежные сроки, конкретная сумма.
Сколько часов будет на самом деле работать программист — мне фиолетово.
Хотя на вкус и цвет…
Работаю на почасовой оплате. Со временем заказчики уже сами знают что и с какой скоростью я делаю.
Главные плюсы: мотивация (не работаешь-не получаешь деньги) и получение заслуженной суммы.
И да, я принимаю оплату так: если заказ — небольшой (до 10 часов), то беру оплату по факту, если больше, то каждые 4 часа. 4 часа могу наработать как за день, так и за неделю. Бывает, что в голове возникает «блин, что же я это так долго делаю» и тогда помечаю в логах работу как неоплачиваемую.
Главные плюсы: мотивация (не работаешь-не получаешь деньги) и получение заслуженной суммы.
И да, я принимаю оплату так: если заказ — небольшой (до 10 часов), то беру оплату по факту, если больше, то каждые 4 часа. 4 часа могу наработать как за день, так и за неделю. Бывает, что в голове возникает «блин, что же я это так долго делаю» и тогда помечаю в логах работу как неоплачиваемую.
Можно копья зря не ломать — у каждого метода свои плюсы и минусы есть, у каждого своя область применения, где он лучше альтернативного. Все эти плюсы и минусы уже тут назвали по десять раз.
Хочу про другое поговорить немного. Тут не зря слово «риск» сказали. Оно тут одно из основных. При почасовой — есть риск, что заказчику проект выйдет дороже, чем ожидалось (С другой стороны — а он и должен рисковать. Даже если дешево выйдет проект — есть риск, что прибыли не будет. А если прибыль будет бешеная — он же с программистом делиться не будет). При фиксированной — программист рискует долгими беседами (а это тоже время) на тему того, что «мы вот в ТЗ имели в виду вот так-то, надо дописать-переписать», а заказчик — тем, что получит некоторую фуету, которая, строго говоря, соответствует ТЗ, но при этом все равно ужас. (да, можно сказать, что сам виноват, но попробуйте тут в комментах мне написать ТЗ на что-то, чтобы другие не смогли предложить варианта как это сделать неправильно. И при этом чтобы затраты на разработку ТЗ не оказались дороже затрат на сам кодинг).
Наемный специалист, на мой взгляд, не должен нести много рисков — он наемник, а не придприниматель-авантюрист. Но при этом вешать все возможные риски на заказчика тоже нельзя — в конце концов, программист может работать по проекту, получать какие-то платежи, а потом — то ли по своим личным соображениям, то ли потому что код проекта стал кошмарным, то ли проект поблизости нарисовался подороже — бросить все и уйти. Работал N месяцев по этому проекту, получал деньги за это время, сейчас бросил. И ничего не потерял. Заказчик потерял ВСЕ. И время и деньги. Сами знаете, брать полуготовый проект (который тоже неспроста забросили), и пытаться его доработать — дураков ведь нет.
У меня комбинированный вариант. Суммы считаем по часам, но в оплату идет только часть. Остальное копится и платится по достижении этапа. В итоге я знаю, что любые доработки будут оплачены. Проект будет (в меру возможностей конечно) красивым, потому что мне не нужно ужиматься по часам чтобы какую-то фичу сделать на соплях. Я знаю, что свою сумму я получу, потому что заказчику сбегать на половине проекта невыгодно. Заказчик знает, что я не сбегу, потому что у него мой bonus fund в заложниках.
Остается, пожалуй, одна только проблема — согласование часов. Где-то я могу безнаказанно накрутить, и заказчику придется оплатить (а ему не хочется). Где-то упорно трудишься какое-то время, делаешь титаническую работу, а заказчик думает, что ее можно в 2 раза быстрее сделать было.
Хочу про другое поговорить немного. Тут не зря слово «риск» сказали. Оно тут одно из основных. При почасовой — есть риск, что заказчику проект выйдет дороже, чем ожидалось (С другой стороны — а он и должен рисковать. Даже если дешево выйдет проект — есть риск, что прибыли не будет. А если прибыль будет бешеная — он же с программистом делиться не будет). При фиксированной — программист рискует долгими беседами (а это тоже время) на тему того, что «мы вот в ТЗ имели в виду вот так-то, надо дописать-переписать», а заказчик — тем, что получит некоторую фуету, которая, строго говоря, соответствует ТЗ, но при этом все равно ужас. (да, можно сказать, что сам виноват, но попробуйте тут в комментах мне написать ТЗ на что-то, чтобы другие не смогли предложить варианта как это сделать неправильно. И при этом чтобы затраты на разработку ТЗ не оказались дороже затрат на сам кодинг).
Наемный специалист, на мой взгляд, не должен нести много рисков — он наемник, а не придприниматель-авантюрист. Но при этом вешать все возможные риски на заказчика тоже нельзя — в конце концов, программист может работать по проекту, получать какие-то платежи, а потом — то ли по своим личным соображениям, то ли потому что код проекта стал кошмарным, то ли проект поблизости нарисовался подороже — бросить все и уйти. Работал N месяцев по этому проекту, получал деньги за это время, сейчас бросил. И ничего не потерял. Заказчик потерял ВСЕ. И время и деньги. Сами знаете, брать полуготовый проект (который тоже неспроста забросили), и пытаться его доработать — дураков ведь нет.
У меня комбинированный вариант. Суммы считаем по часам, но в оплату идет только часть. Остальное копится и платится по достижении этапа. В итоге я знаю, что любые доработки будут оплачены. Проект будет (в меру возможностей конечно) красивым, потому что мне не нужно ужиматься по часам чтобы какую-то фичу сделать на соплях. Я знаю, что свою сумму я получу, потому что заказчику сбегать на половине проекта невыгодно. Заказчик знает, что я не сбегу, потому что у него мой bonus fund в заложниках.
Остается, пожалуй, одна только проблема — согласование часов. Где-то я могу безнаказанно накрутить, и заказчику придется оплатить (а ему не хочется). Где-то упорно трудишься какое-то время, делаешь титаническую работу, а заказчик думает, что ее можно в 2 раза быстрее сделать было.
>>> Где-то упорно трудишься какое-то время, делаешь титаническую работу, а заказчик думает, что ее можно в 2 раза быстрее сделать было
С этим согласен. Была маленькая задачка, которая из 8 часов вылилась в 3 недели из-за бага в LifeRay… Заказчик заплатил за 1 неделю только. Но тут надо было шустрее баг искать )
С этим согласен. Была маленькая задачка, которая из 8 часов вылилась в 3 недели из-за бага в LifeRay… Заказчик заплатил за 1 неделю только. Но тут надо было шустрее баг искать )
Почасовая работа хороша, когда ее в избытке. Тоесть я уверен, что сегодня я раотаю восемь часов, завтра, послезавтра, а в конце месяца у меня в кармане будут деньги. Если же у заказчика то густо, то пусто – почасовая оплата, безусловно, выгодна ему, а вы рискуете заработать меньше, чем взявшись за проект с фиксированным бюдежтом.
Лучшая в мире статья. 4 раза подряд не угадал бюджет ((
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я работаю на почасовой оплате