Comments 43
Скажу про разработку сайтов: очень многие проблемы сразу отпадают при наличии правильно и грамотно составленного договора. Приходит заказчик к вам, вы обсуждаете и оговариваете все нюансы, подписывается договор, составляется ТЗ. Честно говоря, тут проблем никаких.
был прецедент (участвовал не я, но в курсе событий), когда договор был, но составлен так, что не подкопаешься и на (похоже что, сам я договор не видел) другое юр. лицо. как результат - недоплата половины суммы. так что наличие договора еще не дает гарантии. в случае с достаточно большими проектами, все-таки лучше привлекать юриста.
ну и для начинающих полезно знать о таких вещах :)
ну и для начинающих полезно знать о таких вещах :)
"это нужно вчера"
Ну значит сегодня уже можно не делать (=
Ну значит сегодня уже можно не делать (=
Если сомневаетесь в заказчике, то разделите всю работу на 3-5 частей и просите оплату по окончании каждой. По крайней мере в деньгах не сильно потеряете, в случае чего.
Ещё не разу не встречался с заказчиком, который бы «забивал» на проект свой.
Гораздо более частый вариант — придирки к каждой мелочи, и поиск другого смысла в пунктах ТЗ.
Ещё не разу не встречался с заказчиком, который бы «забивал» на проект свой.
Гораздо более частый вариант — придирки к каждой мелочи, и поиск другого смысла в пунктах ТЗ.
как до начала работ определить, что после выполнения заказа все останутся довольны?Никак. Вот к середине можно догадываться об этом, если с заказчиком на одной волне.
Предлагаю альтернативную тему - про разработчиков. Как найти ответственных и порядочных разработчиков, если у вас все же есть не ТЗ, но описание проекта и сториборды к нему, приемлимые сроки и бюджет. Недавно как раз искала )) Чуть было сюда не пришла искать, но темы создавать нигде не могу ))
Уже много сказано в блоге Управление проектами.
Так же, если не видели, рекомендую видео Управление проектами в реальной жизни — Правила Ашманова (Игорь Ашманов РИТ-2007).
Не нашёл от куда скачивал презентации, по этому выложил тут.
Так же, если не видели, рекомендую видео Управление проектами в реальной жизни — Правила Ашманова (Игорь Ашманов РИТ-2007).
Не нашёл от куда скачивал презентации, по этому выложил тут.
Большое спасибо, скачиваю.
Не за что, автору скажите спасибо: 
Ashmanov
Ashmanov
Про ТЗ всеми руками и ногами поддерживаю. Уже задолбали эти "перламутровые пуговицы".
Рекомендую к договору подкалывать допсоглашение, по которому заказчик обязуется никогда не просить "поиграть со шрифтами" и\или "попробовать с цветами поэкспериментировать". :) Как вариант - за каждую просьбу увеличивать бюджет на 15% :)
Ну, так это в договоре в отдельном пункте))) За отдельную плату: и по пунктам... Вот, например: «ЗАМОВНИК не має права вимагати від ВИКОНАВЦЯ внесення змін у вже прийняті етапи робіт. У випадку виникнення таких змін, умови їх виконання розглядаються та оцінюються окремо від умов даного Договору»
это что за тарабарщина?
Это один из пунктов реального договора. На укр. языке, могу перевести, если не понятно: «ЗАКАЗЧИК не имеет права требовать от ИСПОЛНИТЕЛЯ внесения изменений в уже принятые этапы работ. В случае возникновения таких изменений, условия рассматриваются и оцениваются отдельно от условий данного Договора»
А я с одной тётенькой уже два месяца копошусь вокруг договора. Вряд ли дело дойдёт до работы, но всё-таки прикольно.
Переделав кучу заданий как во фрилансе, так и вне его утвердился в нескольких вещах
1. ТЗ надо делать самому. И брать за это деньги.
2. Прописать все ньюансы в договоре. Если невозможно все прописать - задирать сумму повыше
3. Дробить работу на этапы. Закрыли очередной этап: подписали акт и оплатили денежку, вот тогда начинаем следующий.
4. Если уже на первой встрече (никакого ТЗ нет и в помине) Заказчик требует назвать хоть примерный бюджет, то пользуюсь правилом - всплывающую в мозгу цифру (что уже всплыло после озвучивания всех требований вперемешку) умножить на 2, прибавить НДС и сообщить Клиенту.
5. Пословица "Ничто так не укрепляет веру в человека как 100% предоплата" при несоблюдении пунктов 1 - 4 позволяет Заказчику никогда не принять проект, требуя бесконечнеых бесплатных доделок.
Резюме: Каждый берет свою часть ответсвенности на себя. И как ни странно подчас для Клиентов это слышать - у них есть ответственность не только в финансовом плане.
1. ТЗ надо делать самому. И брать за это деньги.
2. Прописать все ньюансы в договоре. Если невозможно все прописать - задирать сумму повыше
3. Дробить работу на этапы. Закрыли очередной этап: подписали акт и оплатили денежку, вот тогда начинаем следующий.
4. Если уже на первой встрече (никакого ТЗ нет и в помине) Заказчик требует назвать хоть примерный бюджет, то пользуюсь правилом - всплывающую в мозгу цифру (что уже всплыло после озвучивания всех требований вперемешку) умножить на 2, прибавить НДС и сообщить Клиенту.
5. Пословица "Ничто так не укрепляет веру в человека как 100% предоплата" при несоблюдении пунктов 1 - 4 позволяет Заказчику никогда не принять проект, требуя бесконечнеых бесплатных доделок.
Резюме: Каждый берет свою часть ответсвенности на себя. И как ни странно подчас для Клиентов это слышать - у них есть ответственность не только в финансовом плане.
Отличные 5 пунктов.
Вот да, при чем сказано здесь куда больше чем в статье.
Все правильно. Хорошие пункты. Договор и ТЗ необходимы в любом случае.
Без них мы как раз упираемся в бесконечное кол-во необходимых доработок.
А стоимость и сроки я обычно озвучиваю только ориентировочные, пока не будет написанно ТЗ.
Без них мы как раз упираемся в бесконечное кол-во необходимых доработок.
А стоимость и сроки я обычно озвучиваю только ориентировочные, пока не будет написанно ТЗ.
вы описали весь мой опыт работы с заказчиками...
* утирает слезу умиления...
* утирает слезу умиления...
Обычно делаю так:
1. Цена от балды. Примерно можно понять, что хочет заказчик. Но обязательно обговаривается разбивка на этапы. И цена за первый этап. Если в качестве примера - разработка сайта, то цена за сайт визитку.
2. Аванс обязательно (не менее 30 процентов).
3. На первой неделе постоянный контакт с выяснением обстоятельств и деталей. Обычно за одну-две недели находится взаимопонимание.
4. После выполнения первого этапа и получения всех обговоренных денег - переход к более "нестандартным" разработкам, всякие скрипты, продвижение, флеш и т.д. Далее цена и условия формируются в зависимости от оценки взаимодействий по первому этапу.
ТЗ надо, но почему-то обычно заказчик не знает, что хочет. Часто приходится говорить не о самой работе, а о необходимых для сайта текстах и функциях. Но при этом можно установить хороший доверительный уровень взаимодействия. Для меня это очень важно!
Чуть о сроках.. Не было случая, когда СРОЧНО действительно было срочно. :) Обычно укладываюсь в обговорённые сроки, но ВСЕГДА заказчик сам не готов предоставить нужные для сайта материалы!
1. Цена от балды. Примерно можно понять, что хочет заказчик. Но обязательно обговаривается разбивка на этапы. И цена за первый этап. Если в качестве примера - разработка сайта, то цена за сайт визитку.
2. Аванс обязательно (не менее 30 процентов).
3. На первой неделе постоянный контакт с выяснением обстоятельств и деталей. Обычно за одну-две недели находится взаимопонимание.
4. После выполнения первого этапа и получения всех обговоренных денег - переход к более "нестандартным" разработкам, всякие скрипты, продвижение, флеш и т.д. Далее цена и условия формируются в зависимости от оценки взаимодействий по первому этапу.
ТЗ надо, но почему-то обычно заказчик не знает, что хочет. Часто приходится говорить не о самой работе, а о необходимых для сайта текстах и функциях. Но при этом можно установить хороший доверительный уровень взаимодействия. Для меня это очень важно!
Чуть о сроках.. Не было случая, когда СРОЧНО действительно было срочно. :) Обычно укладываюсь в обговорённые сроки, но ВСЕГДА заказчик сам не готов предоставить нужные для сайта материалы!
Да я и не спорю.. Будем считать, что мы хорошие :) Но есть и кто-то "плохой" :)
У меня заказы попроще.. И "скоро" - это значит за 3-4 дня. Я так и делал.. Потом выяснялось, что заказчики специально сроки такие ставили, чтоб уж через две недели всё было! На следующих этапах сроки были адекватные..
А что значит - "не приступили в течении 2-х дней"? Из-за этого, кстати, делаю сразу тестовый сайт и выкладываю первую шаблонную страничку сайта. И показываю заказчику. Оба понимаем - к выполнению задачи приступили :) Хотя.. на моих заказчиках приходится неделю думать, что же им надо? Как и писал выше - на первой неделе постоянный контакт.. Умный заказчик - мечта всех нормальных фрилансеров!
У меня заказы попроще.. И "скоро" - это значит за 3-4 дня. Я так и делал.. Потом выяснялось, что заказчики специально сроки такие ставили, чтоб уж через две недели всё было! На следующих этапах сроки были адекватные..
А что значит - "не приступили в течении 2-х дней"? Из-за этого, кстати, делаю сразу тестовый сайт и выкладываю первую шаблонную страничку сайта. И показываю заказчику. Оба понимаем - к выполнению задачи приступили :) Хотя.. на моих заказчиках приходится неделю думать, что же им надо? Как и писал выше - на первой неделе постоянный контакт.. Умный заказчик - мечта всех нормальных фрилансеров!
хе хе... да - заказчики бывают похлеще нечестных фрилансеров .)))
меня больше всего убивают люди, которые не умеют компьютером элементарно пользоваться, а ты пытаешься их обучить как пользоваться своим софтом .)))
тут сразу масса невинных вопросов типа "я вот папку открываю, а там не печатается" =))
меня больше всего убивают люди, которые не умеют компьютером элементарно пользоваться, а ты пытаешься их обучить как пользоваться своим софтом .)))
тут сразу масса невинных вопросов типа "я вот папку открываю, а там не печатается" =))
XP и Agile методики не говорят о том, что все нужно пускать на самотек. Ето просто еще один инструмент, который имеет совершенно определенные границы применения, а не серебряная пуля.
тут, как вы понимаете, есть много нюансов, которые могут работать в случае заказной разработки и не работать в случае с фрилансом. я не имею ничего против XP, но в контексте данного топика (фриланс), имхо стоит более внимательно работать по таким технологиям.
а в остальном действительно в проектах с множеством планируемых изменений лучше присматриваться к XP, нежели к чему-то другому :)
а в остальном действительно в проектах с множеством планируемых изменений лучше присматриваться к XP, нежели к чему-то другому :)
Комрады, несколько слов на тему договора
Первое.
Достаточно часто фирмам не хочется возиться с бухгалтерским оформлением сайт (как проводить, как держать на балансе, как амортизировать и т.д.) и поэтому договора заключаются на "помойки". Соответственно имейте в виду, что бодаться придется не с непосредственным заказчиком, а с "помойкой"-однодневкой.
Второе.
При работе (по крайней мере, с сайтами, программами и т.д.) часто случаются достаточно скользкие моменты: оплата налом или через электронные деньги, работа с гражданами других государств, не четко описанная процедура приемки этапов работы (например, далеко не каждый суд готов будет принять в качестве утверждения дизайна электронное письмо типа "Ок, первый вариант подходит, работаем дальше"). Нужно иметь это в виду и четко прописывать процедуру приема работы (особенно это важно при приеме этапов работы) и критерии определения полноты и качества выполнения работы. Без этого договор бумажка, где многа букыв.
Третье.
Хорошо бы иметь хотя бы для себя четкое представление, насколько полно будет использован договор. То есть договор - это некая возможность потыкать заказчика носом в отдельные пункты или основа для судебного разбирательства (для этого, естественно, потребуется значительная юридическая поддержка). Из моего опыта общения с отдельными разработчиками и с целыми коллективами могу сказать, что первое используется часто и иногда с толком, вторым занимаются только единицы.
К чему я это все?
К тому, что договор - это не Чип&Дейл, которые всегда спешат на помощь, и уповать единственно на него нет смысла. Вместо месяца потраченного на составление детальнейшего и подробнейшего договора на 20 страницах, лучше потратить время на несколько встреч (ну или сеансов общения, если нет возможности встречаться), и понять, что за человек заказчик. Насколько он вменяем, зануден, зануден ли он по существу или просто от общего неудовлетворения миром, насколько он заинтересован в результатах работы (ведь не секрет, что часто начинается работа, которая, по сути, никому не нужна), насколько он понимает специфику работы, сколько этапов утверждения будет проходить работа, сколько человек принимают решения и т.д. То есть пробивать заказчика на общую вменяемость - это первое с чего надо начинать и самое важное.
Небольшое дополнение.
Сразу оговорюсь, чтобы не возникло недопонимания, я двумя руками и головой за договор, хотя бы потому, что совместное составление договора позволит разработчику узнать заказчика получше, и заставит заказчика собраться, ответственнее отнестись к работе и четче сформулировать свои требования, пожелания и критерии оценки работы.
Первое.
Достаточно часто фирмам не хочется возиться с бухгалтерским оформлением сайт (как проводить, как держать на балансе, как амортизировать и т.д.) и поэтому договора заключаются на "помойки". Соответственно имейте в виду, что бодаться придется не с непосредственным заказчиком, а с "помойкой"-однодневкой.
Второе.
При работе (по крайней мере, с сайтами, программами и т.д.) часто случаются достаточно скользкие моменты: оплата налом или через электронные деньги, работа с гражданами других государств, не четко описанная процедура приемки этапов работы (например, далеко не каждый суд готов будет принять в качестве утверждения дизайна электронное письмо типа "Ок, первый вариант подходит, работаем дальше"). Нужно иметь это в виду и четко прописывать процедуру приема работы (особенно это важно при приеме этапов работы) и критерии определения полноты и качества выполнения работы. Без этого договор бумажка, где многа букыв.
Третье.
Хорошо бы иметь хотя бы для себя четкое представление, насколько полно будет использован договор. То есть договор - это некая возможность потыкать заказчика носом в отдельные пункты или основа для судебного разбирательства (для этого, естественно, потребуется значительная юридическая поддержка). Из моего опыта общения с отдельными разработчиками и с целыми коллективами могу сказать, что первое используется часто и иногда с толком, вторым занимаются только единицы.
К чему я это все?
К тому, что договор - это не Чип&Дейл, которые всегда спешат на помощь, и уповать единственно на него нет смысла. Вместо месяца потраченного на составление детальнейшего и подробнейшего договора на 20 страницах, лучше потратить время на несколько встреч (ну или сеансов общения, если нет возможности встречаться), и понять, что за человек заказчик. Насколько он вменяем, зануден, зануден ли он по существу или просто от общего неудовлетворения миром, насколько он заинтересован в результатах работы (ведь не секрет, что часто начинается работа, которая, по сути, никому не нужна), насколько он понимает специфику работы, сколько этапов утверждения будет проходить работа, сколько человек принимают решения и т.д. То есть пробивать заказчика на общую вменяемость - это первое с чего надо начинать и самое важное.
Небольшое дополнение.
Сразу оговорюсь, чтобы не возникло недопонимания, я двумя руками и головой за договор, хотя бы потому, что совместное составление договора позволит разработчику узнать заказчика получше, и заставит заказчика собраться, ответственнее отнестись к работе и четче сформулировать свои требования, пожелания и критерии оценки работы.
Sign up to leave a comment.
Как проверить заказчика «на вшивость»