Время — деньги, или аргументы за и против почасовой оплаты

Недавно я рассказал приятелю, что собираюсь нанять фрилансера на разовую работу. Приятель, 15 лет назад уехавший в США, спросил меня — “А сколько в час ты планируешь ему платить?”.

-В час? — удивился я. — У нас никто за время не платит, только за выполненную работу.

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

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

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

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

Потом наступает второй акт марлезонского балета и все повторяется по-новой. Снова крики «ах, я совсем не то хотел» и вопли «давай деньги, деньги давай».

Скорее всего к середине проекта заказчик и исполнитель (словно молодая семья) притрутся друг к другу, научатся понимать с полуслова и идти на компромисс. Тогда у проекта хорошие шансы успешно завершиться.

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

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

1. Заказчик не пишет ТЗ. Или пишет, но с желаемой для него степенью подробности. Исполнитель по ходу работы над проектом будет уточнять его видение готового продукта.
2. Заказчик с исполнителем договариваются о стоимости часа (или дня) и о ориентировочной длительности проекта. А также о том как часто будут выплачиваться деньги (например раз в неделю).
3. Исполнитель периодически представляет промежуточные версии продукта. Заказчик говорит, что ему нравится, а что нет. Исполнитель все безропотно переделывает — ведь его время оплачивается.
4. В конце недели исполнитель присылает отчет о том сколько часов было потрачено на проект. Заказчик платит.
5. В конце концов, путем долгих итераций исполнитель создает продукт, о котором и мечтал заказчик.

Фигушки! Скорее всего будет так…

• Заказчик не верит, что исполнитель действительно потратил ХХ часов на работу над проектом. Потому что он уверен / ему сказали эксперты, что на самом деле работы тут было в два раза меньше.
• Заказчик считает, что исполнитель плохой специалист и потому работает слишком медленно. Там где другие успеваю за час, ему требуется три. А оплачивает-то все это кто.
• Заказчик рассчитывал на другой бюджет. Он помножил стоимость часа на ориентировочную длительность проекта. А все это удовольствие уже стоит в два раза дороже!
• Следствие из предыдущего пункта. У заказчика закончились деньги.

Какой первый вывод можно сделать? Если у вас ограниченный бюджет в сочетании с хорошо прописанным ТЗ, то выбирайте вариант оплаты за проект. Снимете с себя кучу рисков. Хотя идеальный продукт, скорее всего, не получите.

Продолжаем размышлять. Чего опасаются заказчики?

1. Фальсификаций в отчетах о количестве затраченных часов.
2. Низкой квалификации исполнителей, а как следствие, долгой работы над проектом и ошибок.

1. Техническим контролем за процессом работы исполнителя.
2. Контролем его репутации.

Систем для технического контроля достаточно много. Их предлагают как независимые разработчики, так и биржи фрилансеров (тот же Upwork). Они работают независимо или встраиваются в IDE. Делятся они на три основные группы:

1. Исполнитель отмечает момент начала работы над проектом и момент его окончания. Система в конце отчетного периода генерирует отчет сколько времени потратил исполнитель на проект. Минус для заказчика — приходится верить на слово исполнителю.
2. Система периодически делает снимки экрана компьютера разработчика. Заказчик получает отчет в комплекте со скриншотами и в теории должен убедиться, что исполнитель действительно был занят работой. На самом деле в этот момент он вполне мог на другом ПК заниматься другим проектом.
3. Система контроля позволяет записывать видео экрана разработчика или просматривать его в реальном времени

Наилучший результат получается, если сочетать первый и третий способы. В этом случае разработчик будет уверен, что каждая его рабочая минута будет оплачена, а конфликтов с заказчиком не будет. Если раньше злобный заказчик мог сказать — «А вот я не верю, что ты столько работал», то теперь ему можно будет предъявить видео-запись.

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

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

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

А дальше следует совет новичкам — всегда так делайте! Мол, сам автор раньше был полнейшим нулем в программировании, а в процессе разработки выучился (при почасовой оплате, конечно).

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

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

Единственное — они востребованы и, возможно, будут заниматься не только вашим проектом. Поэтому имеет смысл оговорить либо предельные сроки завершения, либо % времени, который исполнитель будет тратить на ваш проект.

В общем вывод можно сделать следующий.

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