Как проверить заказчика «на вшивость»

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

"это нужно вчера"
Ну значит сегодня уже можно не делать (=

Если сомневаетесь в заказчике, то разделите всю работу на 3-5 частей и просите оплату по окончании каждой. По крайней мере в деньгах не сильно потеряете, в случае чего.

Ещё не разу не встречался с заказчиком, который бы «забивал» на проект свой.
Гораздо более частый вариант — придирки к каждой мелочи, и поиск другого смысла в пунктах ТЗ.

как до начала работ определить, что после выполнения заказа все останутся довольны?

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

Предлагаю альтернативную тему - про разработчиков. Как найти ответственных и порядочных разработчиков, если у вас все же есть не ТЗ, но описание проекта и сториборды к нему, приемлимые сроки и бюджет. Недавно как раз искала )) Чуть было сюда не пришла искать, но темы создавать нигде не могу ))

Про ТЗ всеми руками и ногами поддерживаю. Уже задолбали эти "перламутровые пуговицы".

Рекомендую к договору подкалывать допсоглашение, по которому заказчик обязуется никогда не просить "поиграть со шрифтами" и\или "попробовать с цветами поэкспериментировать". :) Как вариант - за каждую просьбу увеличивать бюджет на 15% :)

А я с одной тётенькой уже два месяца копошусь вокруг договора. Вряд ли дело дойдёт до работы, но всё-таки прикольно.

Переделав кучу заданий как во фрилансе, так и вне его утвердился в нескольких вещах

1. ТЗ надо делать самому. И брать за это деньги.
2. Прописать все ньюансы в договоре. Если невозможно все прописать - задирать сумму повыше
3. Дробить работу на этапы. Закрыли очередной этап: подписали акт и оплатили денежку, вот тогда начинаем следующий.
4. Если уже на первой встрече (никакого ТЗ нет и в помине) Заказчик требует назвать хоть примерный бюджет, то пользуюсь правилом - всплывающую в мозгу цифру (что уже всплыло после озвучивания всех требований вперемешку) умножить на 2, прибавить НДС и сообщить Клиенту.
5. Пословица "Ничто так не укрепляет веру в человека как 100% предоплата" при несоблюдении пунктов 1 - 4 позволяет Заказчику никогда не принять проект, требуя бесконечнеых бесплатных доделок.

Резюме: Каждый берет свою часть ответсвенности на себя. И как ни странно подчас для Клиентов это слышать - у них есть ответственность не только в финансовом плане.

Обычно делаю так:
1. Цена от балды. Примерно можно понять, что хочет заказчик. Но обязательно обговаривается разбивка на этапы. И цена за первый этап. Если в качестве примера - разработка сайта, то цена за сайт визитку.
2. Аванс обязательно (не менее 30 процентов).
3. На первой неделе постоянный контакт с выяснением обстоятельств и деталей. Обычно за одну-две недели находится взаимопонимание.
4. После выполнения первого этапа и получения всех обговоренных денег - переход к более "нестандартным" разработкам, всякие скрипты, продвижение, флеш и т.д. Далее цена и условия формируются в зависимости от оценки взаимодействий по первому этапу.

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

Чуть о сроках.. Не было случая, когда СРОЧНО действительно было срочно. :) Обычно укладываюсь в обговорённые сроки, но ВСЕГДА заказчик сам не готов предоставить нужные для сайта материалы!

хе хе... да - заказчики бывают похлеще нечестных фрилансеров .)))

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

тут сразу масса невинных вопросов типа "я вот папку открываю, а там не печатается" =))

Комрады, несколько слов на тему договора

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

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

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

К чему я это все?
К тому, что договор - это не Чип&Дейл, которые всегда спешат на помощь, и уповать единственно на него нет смысла. Вместо месяца потраченного на составление детальнейшего и подробнейшего договора на 20 страницах, лучше потратить время на несколько встреч (ну или сеансов общения, если нет возможности встречаться), и понять, что за человек заказчик. Насколько он вменяем, зануден, зануден ли он по существу или просто от общего неудовлетворения миром, насколько он заинтересован в результатах работы (ведь не секрет, что часто начинается работа, которая, по сути, никому не нужна), насколько он понимает специфику работы, сколько этапов утверждения будет проходить работа, сколько человек принимают решения и т.д. То есть пробивать заказчика на общую вменяемость - это первое с чего надо начинать и самое важное.

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