Фриланс. Финальные рекомендации

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

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

Бюджет
Обрадованный клиент после успешного ознакомления с вашими работами стучит вам в интернет-пейджер и спрашивает, сколько будет стоить его проект (в идеале — даже подсовывает подобие ТЗ, в виде офисного документам из пяти строк или ста страниц мелким кеглем). Самое неправильное в данном вопросе — называть какое-либо ценовое предложение, потому что: а) у вас есть ставка, но нет оценки по времени; б) даже в случае типовой задачи всегда имеют место нюансы, которые, обычно вылезают после соглашения, а не до. Поэтому, на мой взгляд, наилучшей стратегией является получить максимально возможное количество информации о том, что заказчик желает в итоге получить. В идеале лучше привести все полученные данные к некоторому формализованному виду и подсунуть заказчику на утверждение — времени это займет немного, зато значительно облегчит жизнь в случае возникновения спорных ситуаций. В результате на выходе получим список требований, который следует преобразовать к списку задач, которые нужно выполнить для достижения проекта.

Поясню на примере. Заказчик высказал «хочу максимально простую форму регистрации, но чтобы с восстановлением пароля». Это выражение можно трактовать как «Система требует авторизации по паре «электронная почта-пароль». Так же должна быть предусмотрена возможность регистрации (поля: электронная почта, пароль с повторным вводом и определением стойкости, имя пользователя, защита от массовых регистраций) с отправкой активационной ссылки на почту (аккаунт активируется после перехода по ссылке). Помимо этого должна быть предусмотрена процедура восстановления пароля, когда по адресу электронной почты (с применением защиты от массовых запросов) высылается новый пароль.» Допустим, наш клиент так же хорошо представил, как это должно выглядеть и работать и согласился с нашим описанием. Теперь попробуем преобразовать это в список задач:

• Реализовать вход в систему (компоненты — форма регистрации, функция аутентификации);
• Создать форму и механизм регистрации (использование CAPTCHA) с отправкой активационной ссылки на почту;
• Создать механизм активации, включающийся в случае перехода по ссылке и активирующий аккаунт пользователя;
• Создать механизм принудительной смены пароля с отправкой нового пароля на почтовый ящик (форма, CAPTCHA, функция замены пароля).

И так далее в том же духе. Теперь на руках у нас есть список задач. Задачи в списке очень грубо можно поделить на несколько групп:

• вы раньше выполняли эту задачу и у вас есть наработки или код, который может это реализовать;
• вы раньше не выполняли эту задачу, но знаете наверняка, что есть код, который покроет указанную функциональность и вы уже его использовали (ключевое слово — наверняка)
• вы ранее не выполняли подобную задачу и абсолютно не уверены в наличии или допустимости применения имеющегося кода или функционала системы

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

Записав в электронной таблице список задач и время, требуемое на выполнение каждой из них, получаем бюджет рабочего времени на проект. Сумма затраченного на задачи времени, разделенная на количество рабочих часов в день (ранее мы условились, что это примерно 4 часа), даст нам оценку по сроку выполнения проекта в рабочих днях. Та же сумма, будучи умноженной на ставку, даст ценовую оценку проекта. Эти две цифры и следует назвать потенциальному заказчику, аргументируя бюджетом и ставкой. На этом этапе бюджет может быть подвергнут пересмотру, например, с целью сокращения цены заказчик может отказаться от части задач, что в итоге приведет к снижению стоимости проекта. В случае, если бюджет удовлетворяет обе стороны — фиксируется взаимное согласие, регулируются финансовые вопросы (выплачивается предоплата) и можно приступать к работе.

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

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

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

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

• работа начинает выполнятся только после внесения заказчиком 30-50% предоплаты (зависит от степени доверия к заказчику);
• любые доработки, выходящие за рамки бюджета проекта, должны быть оплачены вне зависимости их срочности, важности и критичности проекта;
• незначительные проекты, не требующие бюджета и согласования, часто являются высокорискованными, особенно в плане «а знаете, нам еще надо» или «наш следующий специалист не смог разобраться в вашем коде, не могли бы вы объяснить ему», поэтому за них лучше не браться
• если заказчик неприятен как человек и имеется хотя бы одно сомнение в его адекватности, компетентности и порядочности — лучше с ним не работать, риск остаться взаимно неудовлетворенным очень велик;
• при этом лучше всего практиковать политику максимальной открытости — в случае, если задачи не закрываются в срок или требуют больше времени, нежели предполагалось — ставить в известность заранее, обещать компенсировать бесплатными дополнительными часами работы в случае наличия собственной вины, но ни в коем случае не скрываться и замалчивать;
• оценка проекта — важная процедура, однако в случае ошибок в оценках ответственность целиком возлагается на исполнителя. Поэтому лучше незначительно перезаложиться по времени, нежели потом сожалеть о недооцененном проекте;
• в случае, если работа с заказчиком ведется впервые и у вас отсутствует портфель проектов по данной работе или же нельзя продемонстрировать работы, можно согласится на небольшую демонстрацию, но исключительно с условием, что написанный в процессе код войдет в проект и будет так же оплачен;
• скидок лучше не давать. Скидки обычно даются на товары/услуги с высокой наценкой, а в наших расчетах предполагается, что наценка отсутствует. Впрочем, если клиент с порога просит скидку — лучше продекларировать гораздо более высокую почасовую ставку, а затем сделать общую скидку от стоимости проекта (разумеется, меньшую, нежели процент, на который увеличена часовая ставка — разница послужит компенсацией риска работы таким заказчиком);
• ставка по времени не подлежит обсуждению, равно как и оценки задач. Если потенциальный заказчик пытается подвергнуть сомнению эти цифры — вряд ли сотрудничество будет продуктивным;
• любое уменьшение бюджета проекта ведет к сокращению числа задач. Подстраивание под финансовые возможности заказчика — черевато;
• если проект непрофильный или по временным/финансовым показателям не устраивает заказчика — можно посоветовать коллегу по цеху или знакомого специалиста, это снижает степень разочарования от разговора;
• вежливость — это важная и, порой, критичная норма делового этикета, которой нельзя пренебрегать;
• риск при работе с посредников может быть скомпенсированным только при увеличении бюджета проекта вдвое, поскольку гарантии, что на линии между принимающим проект и исполнителем нет никаких «сломанных телефонов», отсутствуют;
• очень полезно иметь знакомых специалистов в смежных и сопредельных областях — это позволит делегировать им непрофильные проекты, а также аккумулировать их возможности в случае серьезных и важных заказов.

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