Главная проблема почасовой оплаты труда

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

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

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

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

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

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

2016
Популярное