минимизация рисков в отношениях фрилансера и заказчика

[admin]

Автор: Вадим Тимофеев
Опубликовано: Weblancer.net

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

Давайте рассмотрим, чем рискует фрилансер.

Риск фрилансера 1.

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

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

Риск фрилансера 2.

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

Риск фрилансера 3.

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

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

Риск фрилансера 4.

Нечеткая постановка задачи. Фрилансер сделал проект, а заказчик продолжает присылать свои дополнения - «хотелки», например добавьте такую-то возможность, и такую, хочу то, и это.

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

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

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

Риск заказчика 1.

Полная или частичная оплата фрилансеру за невыполненную работу. Фрилансер перед стартом проекта требует предоплату, или же может требовать оплату по частям, привязав платежи к milestones. Это разумно. Но после предоплаты, или оплаты за очередной milestone, он может просто исчезнуть.

Или другой случай – проект разбит на части, оплата за проект привязана к этим частям. Но нюанс в том, что на первых стадиях разработки фрилансер всегда может отговориться «так это же лишь макет» или «это же лишь альфа версия», фактически сделав при этом лишь малую часть от запланированного объема работ. Затем, получив например 30% платеж, опять-таки или исчезнуть, или пойти на принцип по какой-нибудь мелкой хотелке заказчика и под этим предлогом порвать отношения мотивируя «я бы делал проект, но заказчик захотел в 50 раз больше!».

Риск заказчика 2.

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

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

Риск заказчика 3.

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

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

Итак, подытожим. Рискуют все, и фрилансеры, и заказчики. Риск неизбежен, так как по сути дела начинают сотрудничать люди, до этого ничего не знающие друг о друге. К счастью, эти риски можно минимизировать.

Давайте рассмотрим правила минимизации подобных рисков.

Правило 1.

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

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

При поиске исполнителя желательно получить:
- подробное резюме;
- портфолио;
- физический адрес (если это уместно);
- телефон (мобильный и домашний).

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

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

[admin]

Правило 2.

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

Конечно, если стартует проект на разработку баннера 88x31, то это делать необязательно. Но если проект более-менее серьезен, то составление договора и проектной документации себя оправдывает.

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

Правило 3.

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

Например, при разработке сайта, нужно сразу задать заказчику вопросы:
- Какие допускаются версии используемого программного обеспечения?
- Можно ли использовать в проекте GPL решения?
- Кто будет делать дизайн?
- Какие версии браузеров необходимо поддерживать?
- Если заказывается только функциональность без дизайна, то как это должно выглядеть? Все равно же придется выделять время на HTML кодинг?
- Нужна ли проектная документация, включая инструкцию по установке проекта?
- Нужно ли проводить тестирование на больших объемах данных, и оплачивается ли время на проведение этого тестирования?
- Нужно ли устанавливать проект на хост заказчика, оплачивается ли это?
- Оплачивается ли интернет трафик?

И так далее, таких аспектов десятки. Все это желательно включить в техническое задание, даже если эти аспекты не были изначально упомянуты заказчиком.

Правило 4.

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

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

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

Правило 5.

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

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

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

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