О принципах

Отношения заказчик-работник всегда вызывают много споров. То заказчик обидел, то работник не прав. Фриланс – это то еще болото, и часто заказчик уже «опытный» и при первом разговоре ставит в известность, что «никаких предоплат, ибо повидали!». Вот мои принципы:

· Всегда берите от 30% предоплату. Злопамятные заказчики, которые обобщают всех фрилансеров в одну кучу, в общем-то, не совсем адекватные люди. Но(!) если необходимо это правило нарушить, то нужно договариваться на следующее: «я показываю прототип, а вы тут же перечисляете мне деньги». Ну и понятно, что тут bootstrap + скаффолдинг и 2-3 дня, у нас уже есть что показать, заказчик уходит в лояльность и высылает деньги.

· Всегда сами пишите ТЗ. Хотя бы тезисно. Если заказчик предоставляет ТЗ, а в большинстве своем какой-то документ есть, то не факт что вы поймете правильно. И у меня были такие случаи, что когда я переписал ТЗ, то заказчик сообщил что «всё совсем не так». Так что ТЗ пишите сами. О нем еще поговорим.

· Уделяйте внимание общению. Созвонитесь по скайпу и как можно более подробно проговорите подробности. Не беритесь за создание проекта, пока не закроете все неточности. Если такой возможности нет, то в бюджет проекта пропишите сумму, которая нужна для решения вот этой непонятной задачи. Конечно, сумма может быть большая, и заказчика сразу взволнует этот момент, и, скорее всего, он найдет время сэкономить эти деньги. Если же данной копейки он не заметил, то тем лучше, задача заранее оплачена сполна.

· Никогда, ни при каких обстоятельствах не пропадайте надолго, не предупредив. Этим грешат все. Запороли дедлайн. Должны были стартовать проект, а старый еще недописан, банальная ошибка выбила из колеи на 2 дня. Сроки горят. Всё это фигня, никогда не пропадайте. Если спросят, что происходит – ответьте честно. Если давят на ранюю договоренность, что вы подводите, что «говорили что будет в понедельник, а уже пятница!» - почувствуйте, что вы большой, толстый и меланхоличный слон. Худшее, что вы можете, это поддаться на эту провокацию, хамить в ответ, не сделать работу и свалить.

· Имейте запас денег. Иметь денежную «подушку» на 2-3 месяца такой же качественной жизни. как вы ведете в данный момент, - очень важно. Во-первых, вы не работаете в запарке, что вот долги растут. Во-вторых, не попадете в кабалу текущего проекта. В третьих, если вас кинут, то вы спокойно разрулитесь на следующем проекте.

· Не отдавайте проект на чужой сервер до полной оплаты. Даже, если вам внесли предоплату, и вы отдаете проект, то у заказчика есть возможность вас кинуть. Давайте тестировать на своем сервере.

· Будьте лояльны к доработкам и правкам. Некоторые вещи тяжело предусмотреть, но они могут иметь ключевое значение для проекта. Если это произошло и заказчик настаивает на том, что это было изначально проговорено, то тут два варианта. Всё, что вы напишете в ТЗ, имеет больший вес. Но, если доработки незначительны (чаще всего так и бывает), то проще сделать. Не обязательно каждую мелочь превращать в предмет для дискуссии, но и не позволяйте садиться на голову.

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

· Не беритесь за поддержку чужих проектов. Не стоит недооценивать то, что вам хотят подсунуть. У меня было несколько проектов, которые нужно было поддерживать, и они были написаны до меня. Мне приходилось разбираться с чужим кодом, на это уходило время, и часто заказчику нельзя было объяснить, какую пользу это приносит. Вторым моментом было то, что часто случался коллапс на ровном месте, код переставал работать, и нужно было искать причину, которая была не до конца ясна.

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

· Спорьте о проекте, но помните, что он платит деньги. Да, возможно, что некоторые его идеи и размышления не верны, и вы можете предложить лучшее решение. Предлагайте, убеждайте, даже если это решение и будет стоить дороже. Старайтесь избавиться от глупых решений, но если заказчик сильно настаивает – принимайте его сторону. Он платит, даже за свои ошибки.

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

· Показывайте прогресс. Уведомляйте заказчика о движении по проекту. Ничто так не успокаивает как Progress Bar. Даже если вы опаздываете со сроками, показывайте, что дело идет, не оставляйте в неведении.

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

· Не работайте по ночам. Не будьте рабом работы, не старайтесь сделать работу за ночь/за выходные. Вы сорветесь, и будете долго восстанавливаться. Но если работа идет и уже три часа ночи – работайте, об этих моментах вы будете вспоминать с удовольствием.

· Посмотрите на проблему издалека. Изучите ТЗ полностью прежде, чем что-то писать. Сформируйте образ, представьте, как будут реализованы блоги, но поставьте вопрос «а как можно это сделать быстрее в три раза, за 2 часа?», «Как можно внести много сложных данных без единой ошибки?», «Быстрее ли будет написать парсер или нет?», «Применимо ли для данного случая разработать свой шаблон или скаффолдер?»

· Не объявляйте сроки и стоимость до тех пор, пока не напишете ТЗ. Тут даже не пытайтесь что-то в уме посчитать, всегда ошибетесь.