Фиксировано, в час или гонорар: как платить разработчику на фрилансе?

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

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

Фиксированная оплата может быть выплачена разом по окончании работы или порционно на определенных этапах разработки, как например:

Проблема с высчитыванием времени по списку требований заключается в том, что ваши подсчеты, скорее всего, будут неверными. Согласно докладу «Стэндиш групп», более 83% ИТ-проектов сталкиваются с различными проблемами, то есть не выполняются строго по составленному заранее плану. Как и показано на диаграмме ниже, большинство подобных проблем связаны с перерасходом времени.

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

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

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

Эта практика известна как «гибкая разработка ПО», то есть метод разработки, в котором регулярные изменения и поставка рабочих прототипов воспринимаются как нормальные явления. Большинство программистов предпочитают именно гибкую разработку, однако её сущность идет вразрез с фиксированной выплатой. Ведь как только первоначальные требования заказчика выполняются, проект считается законченным. Разработчик вряд ли согласится продолжить работу без дополнительной платы.

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

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

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

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

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

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

Многие фрилансеры и заказчики для подсчёта человеко-часов используют такие программы как Paydirt и Toggl, которые позволяют максимально честно оценить стоимость услуг.

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

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

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

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

Как и в предыдущих случаях стоимость услуг зависит от почасовой ставки разработчика, однако в договоре прописано количество часов в неделю, в течение которых фрилансер обязан оставаться на должности. Таким образом, руководитель проекта может быть уверен, что исполнитель будет доступен, например, 20 часов в неделю на протяжении 10 недель. Получается, какими бы ни были обстоятельства, разработчик обязан выделить указанное количество времени на написание ПО.

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

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

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

Итак, как же выглядеть комфортная поездка? Вы нанимаете водителя, чтобы он отвез вас из города «А» в город «В». Вы обяжете его каждый день вести вас по четыре часа на протяжении двух недель (непредвиденные остановки и перестройки маршрута также допустимы), но на половине пути вы решаете остановиться у придорожной закусочной, чтобы спросить дорогу. Побеседовав с посетителями, вы понимаете, что теперь вы хотите отправиться в город «С». Ваш водитель соглашается отвезти вас туда, но предупреждает, что дорога до города «С» займет больше времени и вам придется выплатит ему сверхурочные. В конечном итоге вы доезжаете до желаемого пункта назначения довольные комфортным путешествием.

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

Когда вы ставите перед исполнителем задачу по разработке ПО, вы должны быть уверены, что он сможет выполнить ваши требования. Следует проверить портфолио фрилансера, его аккаунт на GitHub и отзывы клиентов, если они есть.

Лучшее лекарство от дефицита доверия – это найм разработчиков, руководствуясь их качеством их работ и опытом, а не стоимостью услуг. Помните, бесплатный сыр только в мышеловке. Опасайтесь девелоперов с почасовой ставкой ниже среднего показателя по рынку. Хорошие разработчики для поиска работы полагаются в первую очередь на свою репутацию. Они заинтересованы в том, чтобы обсудить с вами все детали проекта и выполнить его наилучшим образом. Именно таких «водителей» вам и нужно искать для ваших «поездок».

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

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

А на каких условиях работаете именно вы?

Оригинал.