Если кто-то заказывает, чтоб его позиции в серпе повысили тем или иным способом, логично предположить что кто-то может заплатить за то чтоб эти самые позиции понизили :) Большое спасибо за ответы.
И еще: оговаривается ли отдельно в договоре такой момент "не сотрудничать с такими-то компаниями в течении такого-то времени", наверно это отдельный вопрос который, отдельно оплачивается...
Вот мне интересно, а бывали у кого ситуации, когда вы взялись за раскрутку, уже добились определенных результатов, и к вам пришли конкуренты вашего клиента. Беретесь ли вы за такие заказы и на каких условиях?
С тем что существуют определенные обязательные пункты, определяющие правомочность договора, я полностью согласна. Мне интересны сформулированные договоры на разработку сайтов. Обычно моменты не оговоренные договором остаются на усмотрение разработчика и в последствии могут возникать проблемы. Бесспорно каждый проект индивидуален, но какие-то фреймворки договоров наверняка имеются :)
Был у нас заказчик, который хотел прорекламировать конфеты «Кара-кум» иллюстрацией верблюда, описал которого так: «Верблюд должен быть реалистичным и молодым верблюжонком, который улыбается на все лицо». Так что клиенты бывают очень разными :)))
Мне кажется, автор пытался выяснить этапы создания сайта, в частности дизайна. Так как этапы разработки во многом взаимосвязаны, я поделюсь своим видением:
У нас техническое задание составляет проектор, присутствующий вместе с менеджером по работе с клиентами на встрече с заказчиком, цель которой узнать «Для чего нужен сайт?» - концепция, «Что можно и нужно, чтоб было на сайте обязательно» - функциональная часть, «Какое впечатление должен производить сайт?» - дизайнерская сторона, «Предпочтения заказчика» и «Предпочтения целевой аудитории».
При этом из клиента не вытягивают клещами эту инфу, а превращают это в увлекательный для клиента процесс, сроду задач на логику. Менеджер, подготавливаясь к встрече с клиентом выбирает лучшие сайты по профильной тематике и если есть, сайты основных конкурентов. А во время встречи, этим сайтам перемываются косточки: и на предмет дизайна, и на предмет функционала, и на предмет утирания носа конкурентам :))).
Нелегко приходится, когда со стороны заказчика несколько человек ответственны за разработку сайта (бывает ведущие этого клиента сотрудники рекламных агентств), тогда к консенсусу прийти сложнее, но поверьте, возможно!
Так, о чем это я… ага – Тяжела судьба проектора, он похож на интерфейс. Он пишет ТЗ и приложения: общается с дизайнером, верстальщиком, программистом, сеошником и другими действующими лицами изъясняясь на ИХ языках и раздавая им задания.
То что автор статьи назвал ТЗ на дизайн, пишется с участием проектора, верстальщика и дизайнера. И это самое ТЗ на дизайн составляется после утвержденной с клиентом концептуальной и функциональной части.
А на стадии утверждения концептуальной и функциональной частей проектор намеренно избегает упоминаний о визуальном отображении вроде: «Здесь будет желтая кнопочка, здесь красненький цветочек», так как это может противоречить мнению дизайнера, и вообще это задача именно дизайнера, он профессионал в этом деле, ему ее и решать.
Если заказчик что-то придумал в дизайне и хочет именно этого, мы обычно делаем два макета: так как пожелал клиент и так как резоннее со стороны дизайнера, а при встрече аргументировано объясняем преимущества решения дизайнера.
Мораль сей басни такова, что верстальщик – верстает, программист – программирует, дизайнер – делает дизайн и они правят бал в своей сфере, каждый из них должен выполнять свою роль, нести за нее ответственность, и решающие слова в этой области остаются именно за профессионалом в ней.
У нас техническое задание составляет проектор, присутствующий вместе с менеджером по работе с клиентами на встрече с заказчиком, цель которой узнать «Для чего нужен сайт?» - концепция, «Что можно и нужно, чтоб было на сайте обязательно» - функциональная часть, «Какое впечатление должен производить сайт?» - дизайнерская сторона, «Предпочтения заказчика» и «Предпочтения целевой аудитории».
При этом из клиента не вытягивают клещами эту инфу, а превращают это в увлекательный для клиента процесс, сроду задач на логику. Менеджер, подготавливаясь к встрече с клиентом выбирает лучшие сайты по профильной тематике и если есть, сайты основных конкурентов. А во время встречи, этим сайтам перемываются косточки: и на предмет дизайна, и на предмет функционала, и на предмет утирания носа конкурентам :))).
Нелегко приходится, когда со стороны заказчика несколько человек ответственны за разработку сайта (бывает ведущие этого клиента сотрудники рекламных агентств), тогда к консенсусу прийти сложнее, но поверьте, возможно!
Так, о чем это я… ага – Тяжела судьба проектора, он похож на интерфейс. Он пишет ТЗ и приложения: общается с дизайнером, верстальщиком, программистом, сеошником и другими действующими лицами изъясняясь на ИХ языках и раздавая им задания.
То что автор статьи назвал ТЗ на дизайн, пишется с участием проектора, верстальщика и дизайнера. И это самое ТЗ на дизайн составляется после утвержденной с клиентом концептуальной и функциональной части.
А на стадии утверждения концептуальной и функциональной частей проектор намеренно избегает упоминаний о визуальном отображении вроде: «Здесь будет желтая кнопочка, здесь красненький цветочек», так как это может противоречить мнению дизайнера, и вообще это задача именно дизайнера, он профессионал в этом деле, ему ее и решать.
Если заказчик что-то придумал в дизайне и хочет именно этого, мы обычно делаем два макета: так как пожелал клиент и так как резоннее со стороны дизайнера, а при встрече аргументировано объясняем преимущества решения дизайнера.
Мораль сей басни такова, что верстальщик – верстает, программист – программирует, дизайнер – делает дизайн и они правят бал в своей сфере, каждый из них должен выполнять свою роль, нести за нее ответственность, и решающие слова в этой области остаются именно за профессионалом в ней.
P.S. простите за трактат, очень актуально :)))