[admin]

Правило 2.

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

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

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

Правило 3.

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

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

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

Правило 4.

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

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

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

Правило 5.

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

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

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

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