Фиксированная или почасовая оплата? Взгляд фрилансера.

Существует два основных способа оплаты работы фрилансеров: фиксированная ставка (fixed price) и почасовая оплата (hourly rate).
В этой статье я хочу рассказать, почему почасовая оплата может быть выгодна не только для исполнителя, но и для заказчика.

Качество кода

На проектах с почасовой ставкой, как правило, качество кода выше, и это происходит по той причине, что такие проекты, в своём большинстве, более длинные, и программист не торопится быстрее закончить - его поджимают только оговоренные сроки выполнения проекта (due date), а не жажда быстрее получить деньги, поэтому всё делается более основательно, без спешки. Кроме того, на проектах с почасовой оплатой разработчик надеется, что проект будет продолжаться, поэтому он пишет код так, чтобы потом с ним было приятно самому работать.
На проектах с почасовой оплатой у разработчика есть заинтересованность в проявлении инициативы и предложении новых интересных решений. Интерес в продолжении проекта выше, поэтому и больше вовлечённость и степень вникания в проект, что положительно сказывается на конечном результате.

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

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

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

Переговоры

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

Вывод: если даже вы работаете с фиксированной оплатой, то разбивайте проект на итерации, каждая из которых после старта не подлежит обсуждению и дополнению.

Мотивация

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

Вывод: если используется фиксированная оплата, лучше всего производить её по частям.

Безопасность

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

Итоги

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