Любой человек делавший что-то под заказ, знает странную тенденцию. Практически никогда постановка задачи заказчиком не бывает однозначной и на 100%. То один, то другой нюанс вас просят подправить в ходе работы, иногда подобные изменения могут чуть ли не в полной мере поменять первичную структуру проекта.

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

Каждый из нас хочет делать свое дело хорошо, каждый из нас пытается максимально полно применить свои знания и умения для удовлетворения нужд заказчика и выполнения заказа, но… Любой творческий позыв, любое усовершенствование возможно только тогда, когда заказчик готов его оплачивать, чтобы вы купили себе долгожданный лодочный мотор на сайте. Иначе вы банально потратите время, снизив соотношение временные затраты/деньги.

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

Пример 1. Заказчик просит консультацию по продвижению ресурса. Консультация носит постоянный характер, т.е. по мере развития проекта моя задача сводится к выдаче рекомендаций, что до всех аспектов его популяризации по обстановке. Выдается первая рекомендация выполнить заточку под НЧ запросы с пояснением как это сделать. Через 3 месяца недовольный заказчик бурчит мне в телефон, что мол посещаемость и ныне там, а мы вам платим. Делаю краткий обзор ресурса. Нахожу 3 страницы под НЧ. Кто виноват?

Пример 2. Дофига лет назад по неопытности беру ТЗ на разработку системы управления клубом. Проработка ТЗ идет от функционала, т.е. как будут считаться деньги, что система без централизованного сервера (т.е. работает автономно на каждой машине), что блокируется (устройства), что нет. Как выглядит меню пользователя бла бла бла.

Через месяц начинаю сдавать работу и с удивлением выясняю, что заказчик хотел переписать Locker. Кто виноват?

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

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