Недавно я рассказал приятелю, что собираюсь нанять фрилансера на разовую работу. Приятель, 15 лет назад уехавший в США, спросил меня — “А сколько в час ты планируешь ему платить?”.
-В час? — удивился я. — У нас никто за время не платит, только за выполненную работу.
Приятель начал со мной спорить, убеждая в том, что повременная оплата самая лучшая. А я задумался. И решил составить список плюсов и минусов (а еще опасений) внедрения почасовой оплаты как для работника, так и для работодателя.
Надо сказать, что картина получилась весьма не однозначная. Итак…
Допустим у вас есть задача и вы ищете исполнителя. Как выглядит типичный сценарий при оплате за выполненную работу?
- Заказчик должен максимально полно и тщательно написать Техническое задание. Ничего не забыть и не допустить двойного толкования.
- Исполнитель читает ТЗ и на основе своего опыта определяет сколько времени необходимо на создание продукта и какую сумму он хочет за это получить.
- Заказчик и исполнитель долго торгуются по цене. Весьма вероятно, что будет сравниваться несколько вариантов (а значит несколько исполнителей бесплатно будут изучать ТЗ).
- Определяется ориентировочный срок завершения проекта. Часто заказчик любит устанавливать штрафные санкции за просрочку.
- Проект разбивается на этапы. Исполнитель тоже хочет регулярно кушать, поэтому после завершения каждого этапа ему выплачивается денежка.
И вот наступает час Хы, исполнитель показывает первую версию продукта… и заказчик хватается за голову. Нет, не это видел он в своих розовых снах, не об этом мечтал, не за это готовы платить его клиенты.
-Паааазвольте! — говорит исполнитель и тычет пальцем в ТЗ, — вот тут все написано.
Дальше начинается долгий и неуютный диалог про то, кто как писал и кто что понял. В результате обе стороны идут на уступки. Заказчик усмиряет свои ожидания и наступает на горло своей мечте, а исполнитель соглашается еще немного доработать продукт. В результате одна сторона расстается с первой порцией денег, а вторая их обретает, но у обоих появляется чувство, что их… (немного обманули).
Потом наступает второй акт марлезонского балета и все повторяется по-новой. Снова крики «ах, я совсем не то хотел» и вопли «давай деньги, деньги давай».
Скорее всего к середине проекта заказчик и исполнитель (словно молодая семья) притрутся друг к другу, научатся понимать с полуслова и идти на компромисс. Тогда у проекта хорошие шансы успешно завершиться.
Если же исполнитель будет слишком сильно упирать на ТЗ, а заказчик на свои невысказанные мечты, то пара может наговорить гадостей и разбежаться. Понятно, что история продукта на этом закончится.
Теперь рассмотрим другой сценарий, когда заказчик готов платить исполнителю за время работы над проектом.
- Заказчик не пишет ТЗ. Или пишет, но с желаемой для него степенью подробности. Исполнитель по ходу работы над проектом будет уточнять его видение готового продукта.
- Заказчик с исполнителем договариваются о стоимости часа (или дня) и о ориентировочной длительности проекта. А также о том как часто будут выплачиваться деньги (например раз в неделю).
- Исполнитель периодически представляет промежуточные версии продукта. Заказчик говорит, что ему нравится, а что нет. Исполнитель все безропотно переделывает — ведь его время оплачивается.
- В конце недели исполнитель присылает отчет о том сколько часов было потрачено на проект. Заказчик платит.
- В конце концов, путем долгих итераций исполнитель создает продукт, о котором и мечтал заказчик.
Ура-ура, все счастливы. Прямо рай…
Фигушки! Скорее всего будет так…
- Заказчик не верит, что исполнитель действительно потратил ХХ часов на работу над проектом. Потому что он уверен / ему сказали эксперты, что на самом деле работы тут было в два раза меньше.
- Заказчик считает, что исполнитель плохой специалист и потому работает слишком медленно. Там где другие успеваю за час, ему требуется три. А оплачивает-то все это кто??!
- Заказчик рассчитывал на другой бюджет. Он помножил стоимость часа на ориентировочную длительность проекта. А все это удовольствие уже стоит в два раза дороже!
- Следствие из предыдущего пункта. У заказчика закончились деньги...
Какой первый вывод можно сделать? Если у вас ограниченный бюджет в сочетании с хорошо прописанным ТЗ, то выбирайте вариант оплаты за проект. Снимете с себя кучу рисков. Хотя идеальный продукт, скорее всего, не получите.
Продолжаем размышлять. Чего опасаются заказчики?
- Фальсификаций в отчетах о количестве затраченных часов.
- Низкой квалификации исполнителей, а как следствие, долгой работы над проектом и ошибок.
Проблема фальсификации решается двумя способами:
- Техническим контролем за процессом работы исполнителя.
- Контролем его репутации.
К сожалению, с контролем репутации дело обстоит не очень хорошо. Далеко не все обманутые заказчики напишут отрицательный отзыв. Далеко не все заказчики знают, что их обманули. Далеко не все заказчики читают отзывы об исполнителях. А многие исполнители получают заказы с нескольких сайтов.
Систем для технического контроля достаточно много. Их предлагают как независимые разработчики, так и биржи фрилансеров (тот же Upwork). Они работают независимо или встраиваются в IDE. Делятся они на три основные группы:
- Исполнитель отмечает момент начала работы над проектом и момент его окончания. Система в конце отчетного периода генерирует отчет сколько времени потратил исполнитель на проект. Минус для заказчика — приходится верить на слово исполнителю.
- Система периодически делает снимки экрана компьютера разработчика. Заказчик получает отчет в комплекте со скриншотами и в теории должен убедиться, что исполнитель действительно был занят работой. На самом деле в этот момент он вполне мог на другом ПК заниматься другим проектом.
- Система контроля позволяет записывать видео экрана разработчика или просматривать его в реальном времени. Разработчик включает мониторинг при начале работы над проектом и исполнитель в любой момент может убедиться, что работа действительно идет. Поскольку все, что делает исполнитель в этот момент будет принадлежать заказчику, то не приходится опасаться утечки важной информации.
Наилучший результат получается, если сочетать первый и третий способы. В этом случае разработчик будет уверен, что каждая его рабочая минута будет оплачена, а конфликтов с заказчиком не будет. Если раньше злобный заказчик мог сказать — «А вот я не верю, что ты столько работал», то теперь ему можно будет предъявить видео-запись.
А вот квалификацию исполнителя измерить весьма непросто. Один разработчик пишет быстро, но сажает много ошибок. Другой качественно, но медленно. Третий всем хорош, но не знает нужных для проекта API / фреймворков, которые изучает прямо «на ходу», причем нередко за деньги заказчика.
Как тут быть?
Заранее оговаривать все технологии, которые будут использованы в проекте и требовать от исполнителя знания этих технологий на достаточном уровне.
Да сложно, да требует вникания в процесс и определенных знаний у самого заказчика, но интернет забит рассказами восторженно хихикающих фрилансеров о том как они радостно брались за разработку на AngularJS, впервые услышав о нем от заказчика.
А дальше следует совет новичкам — всегда так делайте! Мол, сам автор раньше был полнейшим нулем в программировании, а в процессе разработки выучился (при почасовой оплате, конечно).
Устанавливайте штрафные санкции на превышение количества ошибок. Конечно написать полностью чистый код невозможно. Но профессионал именно тем и отличается от любителя, что готов отвечать за качество. И уж совсем откровенные ляпы он всегда отловит.
Не жадничайте. Хорошие специалисты стоят дорого, но работают быстро и обычно беспроблемно. В отличие от начинающих кодеров, которые возьмут немного, но тянуть с вас деньги будут «до морковкина заговенья».
Единственное — они востребованы и, возможно, будут заниматься не только вашим проектом. Поэтому имеет смысл оговорить либо предельные сроки завершения, либо % времени, который исполнитель будет тратить на ваш проект.
В общем вывод можно сделать следующий.
Почасовая оплата более выгодна и исполнителю и заказчику, но при соответствии квалификации исполнителя ожиданиям заказчика, а также при должном контроле над расходом времени.
Комментарии (28)
kroshanin
01.11.2016 13:09+1Много воды, много картинок, ожидал от статьи большего.
Вывод тоже очень и очень неоднозначный. У каждого хорошего специалиста есть свои наработки, созданные за годы кропотливой работы и размножающиеся обычно копипастом. Как быть с ними при часовой оплате труда? Не использовать и писать все заново или скопировать и получить деньги за пять минут работы?
mail_to_me
01.11.2016 13:15Я старался писать статью больше с точки зрения заказчика.
Дело в том, что в большинстве компаний даже удаленный персонал использовать боятся, а уж платить по часам — тем более.
Так что основным посылом было развеять страх потенциальных заказчиков и дать возможность программистам зарабатывать.
Landgraph
01.11.2016 13:28Только вчера столкнулся с ситуацией, когда тестовый набор отличается от реальных данных, пришлось фактически переписать значительный кусок программы =)
Мне кажется, что статья описывает скорее работу кодера, но не программиста.
Это, считаю, как оценивать работу художника по количеству мазков или ставить над ним камеру и учитывать только время касания холста кистью. Ну и, конечно, не оплачивать те мазки, поверх которых были сделаны другие…
С другой стороны, очень часто наблюдаю ситуацию полнейшей незаинтересованности исполнителя в реализации проекта и, как следствие, попытки потом прикрываться сознательно плохо составленным ТЗ. А сколько раз я сталкивался (в роли эксперта при приёмке) с позицией исполнителя «в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
Я всегда стараюсь сесть вместе с заказчиком и постараться вместе с ним разобраться, что же всё-таки нужно получить в итоге, расписываются плюсы и минусы на перспективу и т.д. Вот тогда идёт работа на результат. Тогда же идёт и выбор инструментов для реализации, подбор используемых технологий и т.д. Ну и как бы в результате все остаются довольны.mail_to_me
01.11.2016 13:35Зачастую компании стараются не нанимать девушек, которые недавно вышли замуж. Считается, что они собираются завести ребенка, что компании в общем-то не сулит ничего хорошего…
И девушки часто получают необоснованные и немотивированные отказы. Одна моя знакомая придумала и написала некое «обязательство» не заводить детей в течение двух лет (это была ее инициатива, не работодателя).
Эта бумажка не имела никакой законной силы. Но работу после этого она получила.
Так же и с заказчиками. Есть множество причин, чтобы платить исполнителю за время, затраченное на проект. Но заказчики боятся это делать. Вот эти страхи и их преодоление я и постарался описать.
А методы убеждения заказчиков могут быть разными. Давайте подумаем какие еще бывают (кроме убеждения :) )Landgraph
01.11.2016 13:56Во-первых, считаю, главный метод — это честность. Очень много потенциальных заказчиков обожглись как раз на нечестном исполнении, после чего выбрали позицию «лучше купить готовый продукт, чем что-либо заказать».
Мне как-то один исполнитель очень долго доказывал, что система оповещения по электронной почте (вставить в функцию логов несколько строк для отправки уведомления в случае появления критических ошибок) из Java-приложения — это титанический труд, который как минимум удвоит стоимость и учетверит объем работы. Пришлось немного процитировать RFC (если просто на сокетах писать), ну либо предложил воспользоваться имеющимся в Java классом. Исполнитель негодовал.
Часто исполнители нагло пользуются незнанием заказчика. Это не хорошо. При чём это касается не только нашей отрасли, менталитет у нас что-ли такой: кинь ближнего своего, ибо не ведает он…mail_to_me
02.11.2016 18:21Тут мы опять возвращаемся к теме репутации. Которую пока в наших условиях сложно проверить.
RPG18
01.11.2016 14:28«в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
Если я не эксперт в предметной области, то без спецификаций мы ногу сделать хорошие тесты, да и не понятно корректные эти данные или нет. Поэтому получаются ситуации:
когда тестовый набор отличается от реальных данных, пришлось фактически переписать значительный кусок программы
Landgraph
01.11.2016 14:39Оооо… Вы слишком глубоко копаете, предметная область, спецификация… =)
Элементарный пример — поле, в которое должна быть введена цифра, например, целочисленное поле «кол-во»… Очепятываемся и, в зависимости от кучи факторов, получаем от нефатальной ошибки, до фатального вылета без сохранения =(
У нас в крае такая милая программа для сдачи данных в ПФР ходила (или до сих пор ходит): одна очепятка и фатал эррор с потерей данных. Хотя, судя по внешним признакам, можно было бы хотя бы в блок try… обернутьGryphon88
01.11.2016 14:51А кстати, как в таких случаях правильно? Допустим, есть поле для суммы в рублях и кто-то вбил туда 110ю00. Как обрабатывать такую ошибку?
1, попап «неправильно введена сумма», красный флажок у поля, пустое поле
2. попап «неправильно введена сумма», красный флажок у поля, старые данные в поле- «110ю00»
3. попап «исправлена опечатка», красный флажок и пустой чекбокс «проверено» у поля, в поле «110 руб. 00 коп.»
4. крэшиться и запускать ракеты
5. иначеLandgraph
01.11.2016 18:05Коллега, прямо на холивар провоцируете.
Считаю, что «правильность» реакции зависит от конкретной ситуации, используемого языка, окружения и т.д.
Если мы говорим про обычное прикладное ПО, то от себя могу сказать, что считаю п.4 неправильным, если иное не оговорено ТЗ. Во всех остальных случаях исключительная ситуация должна быть обработана и, как минимум, не должна приводить к потере/искажению данных.Gryphon88
01.11.2016 18:25Вопрос холиварный, но у меня совсем плохо с UI. Я понимаю, что нужно без потери данных известить пользователя, что что-то не так, но стоит ли додумывать за него, если это прямо не указано в ТЗ?
Landgraph
01.11.2016 19:13Додумывать (что именно сделать в случае ошибки) — по желанию.
Обрабатывать исключения, не давая обрушить систему — обязательно.
ИМХО, конечно.
FeNUMe
01.11.2016 21:33Я бы никогда не додумывал, во всяком случае в ситуациях когда нет единственно верного толкования действий пользователя. Стоит учитывать что у всех людей разные привычки по использованию софта и вводу данных и то что вам может казаться логичным и удобным для кого-то может оказаться раздражающим и стать причиной отказа от продукта. Лично я достаточно часто
ма...выражаюсь нецензурно из-за автокомплитов не к месту.
Daniil1979
01.11.2016 14:30>>А сколько раз я сталкивался (в роли эксперта при приёмке) с позицией исполнителя «в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
В данном случае заказчик сам себе злобный буратино.
kimisa
01.11.2016 14:31«в ТЗ ведь не прописано, что надо проверять входные данные на корректность...»
А бывает и такое — с заказчиком проговоришь, что они будут отдавать данные только в таком виде и проверяешь их на корректность. И тут раз — засада — данные в другом виде.
MurzikFreeman
01.11.2016 15:34Как должен выглядеть мониторинг, если исполнитель покинул рабочее место (не совершает никаких телодвижений по написанию кода в течении 3-х часов) и отправился гулять вокруг здания, обдумывая сложное место? Или предполагается что все сложные в реализации места проработаны и согласованы до начала работ?
mail_to_me
01.11.2016 15:35-3А это уже по договоренности с заказчиком. Если он готов оплачивать время обдумывания, то без проблем.
TyVik
01.11.2016 19:44+1В смысле «готов оплачивать время обдумывания»??? Нам платят именно за то, что мы думаем. Хочется больше строк кода — пускай берут машинистку, у неё это лучше получается.
SergeyUstinov
02.11.2016 11:54Это — самая проблемная часть всех контролей. Если есть хорошее и подробное ТЗ — то можно по нему просто писать код и замерять время написания. Но это работает в простых случаях.
А если надо написать нечто, о чем у всех очень смутное ощущение (у заказчика нет необходимых технических знаний, чтобы продумать, как все должно работать) — то много времени уйдет на придумывание алгоритма, а само написание кода займет относительно мало времени.mail_to_me
02.11.2016 11:55В этом случае выходом могло бы стать именно написание ТЗ самим исполнителем с повременной оплатой. А дальше точная оценка времени и работа за фиксированную сумму.
SergeyUstinov
02.11.2016 15:28И как проконтролировать, что исполнитель именно ТЗ пишет? :)
Иногда, чтобы написать пару абзацев, надо неделю ковыряться в задаче… И при этом ты ведь часто ничего, что может увидеть (проконтролировать) посторонний, не делаешь. Рисуешь что-то на доске — как другой человек поймет, это ты пытаешься структуру данных набросать, или имитируешь деятельность?
leon_nikitin
02.11.2016 11:55+1Тогда надо секундомер. Как пошел пописить, то сразу выключил секундомер.
Либо с заказчиком заранее обговорить, как будет оплачиваться время на пописитьmail_to_me
02.11.2016 12:02Так именно так и работают стандартные трекеры для фрилансеров.
leon_nikitin
02.11.2016 13:05Ну это ведь полное неуважение к себе, так работать.
Одно дело, когда голод и надо заработать на кусок хлеба.
А другое дело, когда гонятся за большими деньгами и так себя унижают
seryh
Тема не раскрыта. Кто и как будет определять за какие ошибки будут санкции? Зачем работнику идти к работодателю который может вдруг насчитать штрафов на половину зп за скажем поехавшую верстку в IE6, по штрафу за каждый уехавший блок. А что если в компании есть отдел тестирования?
mail_to_me
Увы, но объемы статьи не дают возможность раскрыть тему полностью. Значит буду писать продолжение…
А насчет примера с IE6. Всё-таки какой-то вариант ТЗ нужен. Если в нем будет прописано, что сайт должен работать под конкретными браузерами, то вёрстка ехать не должна.
Просто профессионал тонкости знает, и в случае необходимости может сделать даже отдельную верстку для IE6. А дилетант понадеется на авось.
FeNUMe
Лучше бы вы более подробную статью сделали без рекламы своего продукта, а потом уже как раскрытие темы писали маркетинговую статью с полным описанием продукта, примерами внедрения и использования и т.д. А так и тему(вполне интересную и холиварную) осветили поверхностно и за рекламу минусов словили.