 |
|
|
 |
|
|
|
Постов: 83
Дата регистрации: 12.01.2005 |
Давно тема не поднималась, посвящается прежде всего тем, кто заказывает сайт, о наболевшем :) .
Возникла ситуация, когда на последнем этапе запуска сайта заказчик требует радикальных изменений, собрали консилиум и решли: этот блок туда, этот сюда, а это вообще не нужно. Последний этап это когда дизайн готов, разрезан, движок "натянут", сайт. Сайт, по нашему мнению на хорошем уровне и для их реализации доп требований потребуются ресурсы - править дизайн-макет, заново верстать и потом адаптировать движок.
Интересно было бы узнать как коллеги выходят из таких положений и как реалигуют на возможные варианты выхода из такой ситуации заказчики.
И в целом, хочу высказать пожелания к заказчикам сайтов. Не пытайтесь оценивать каждую деталь макета. Главное, что имеет значение в большинстве случаев - общее решение - цвет, стиль, ассоциативный ряд, удобство навигации, положительное восприятие - остальное оставьте профессионалам; аргументировать каждый конкретный графический элемент, просто не хватит времени, целую лекцию надо читать, поэтому до определенной степени нужно поверить. Иначе дизайн и вся разработка превращается в противостояние. |
|
 |
0 |
 |
0 |
| Комментарий понравился? |
|
0 |
|
0 |
    18.06.2005 01:27 |  |
|
|
|
Новичок
Постов: 3527
Дата регистрации: 07.06.2004 |
Если предыдущие макеты были согласованы - дизайн и структура утверждена, то творчество заказчика несомненно приветствуется и выражается в доп. работах по окончании первых этапов.
Мы как-то выкручивались: надо довести первый вариант до конца (вглухую). Все пожелания к изменениям игнорировать вплоть до этапа подписания акта сдачи приемки первого варианта, приведенного в соответствии с согласованным ранее макетами и структурой.
Если ничего согласованного ранее не было, то тут заказчик барин - что хочет то и будет просить, а вы должны делать.
Можете в часах выражать проект. Выкатить счет на оплату предыдущих проектных часов (или просто путь подпишется, что согласен в том что он понял что это за часы и что он уже несколько должен). Доп. поиски тоже в часах запросить, в меньших по сравнению с основным проектом, но мотивировать их и указать на необходимость их дофинансирования.
И так дальше ... пусть хоть пять переделок будет - выставляйте доп. счета. Вместо одного сайта заказчик купит разработку трех *8)) |
|
--------
бренд "Cивой Кобылы" |
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
18.06.2005 01:58 | |
|
|
|
Постов: 83
Дата регистрации: 12.01.2005 |
С одной стороны формальный подход, конечно, удобен, если есть подписанный дизайн, бриф, ТЗ, это многое упрощает. Но надо понимать, что, например, разработка полноценного ТЗ, в котором четко все прописано - это само по себе отдельный проект, да и в ТЗ обычно прописывается фукционал, как пропишешь дизайн? - только в общем. По моему мнению такой формализм работает против заказчика, т.к. заказчик и веб-технологиях зачастую не разбирается и поэтому скорее всего будет пытаться максимально конкретизировать дизайн, что не всегда хорошо, т.к. наша главная цель - создать оригинальный, запоминающийся сайт, с изюминкой, ставить минимум ограничений дизайнеру (в основном определяемых функциональностью, юзабилити, а не взаимным расположением блоков дизайна).
Как вы считаете, позиция игнорирования требований по причине, что "нам виднее" и "позже вы все равно поймете,что мы были правы и будете нам благодарны" имеет право на существование или это будет показателем низкого качества сервиса? Думаю, разработчики индивидуальных (не шаблонных) решений с этим сталкиваются... |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
19.06.2005 01:18 | |
|
|
|
Новичок
Постов: 3527
Дата регистрации: 07.06.2004 |
2 Пашкин
Мы как раз начали работать именно так с заказчиками
- вы заказываете, мы - делаем... а не вы. Результат вас все равно устроит. Всех всегда устраивало и вас устроит.
Это не низкое качество сервиса. Как себя поставишь перед заказчиком так и будете работать. Скажете, что вы спциалист и работаете так как надо, то все так и будет. Будете постоянно интересоваться у заказчика : " а так ли это , а может быть так... я не уверен, вы посмотрите - скажите". Тут- то заказчик и начинает вас воспринимать не как специалиста или контору, а как наеемного работника. .. Ну и начинает диктовать условия.
Будьте лучше черным ящиком - на входе т.з. и деньги - на выходе работа.
Хотите панибратства с заказчиком - он вас съест |
|
--------
бренд "Cивой Кобылы" |
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
19.06.2005 08:52 | |
|
|
|
Постов: 20
Дата регистрации: 31.05.2005 |
Могу высказаться с другой стороны - стороны заказчика:
Вы тоже должны нас понять, что представить будущий сайт на этапе согласования ТЗ очень сложно, особенно, когда в этом сам не разбираешься. Для нас во многом (но не во всем !) требования к сайту выражаются в простых категориях типа: цвет, управление, картинки и т.д. А так же в том какие цели мы ставим перед собой, когда хотим иметь корп.сайт. Вот и все! На самом деле никто сначала не видит его в готовом виде. Но тем не менее, когда нам (мне лично, не буду говорить от лица всех и вся) показывают готовый вариант очень ясно начинают проступать недостатки, то что надо улучшить и доработать...
Это не выход:
Автор оригинала Пашкин
Как вы считаете, позиция игнорирования требований по причине, что "нам виднее" и "позже вы все равно поймете,что мы были правы и будете нам благодарны" |
- скорее всего вы потеряете заказчика.
Это мой сайт! И я лучше знаю, что там д.б.
Кстати, JhaZZ, сейчас, у меня похожая ситуация: мне админ начинает говорить, что там и как будет, а то что предлагаю я, отметает как "нереальные идеи". Касается в частности меню, цветовых решений, форума... - и знаешь, чем это закончится? - лишней потерей времени для нас! В итоге я посмотрю, пощупаю и мы вновь начнем все переделывать. :(
___
извините за скомканность... |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
19.06.2005 23:55 | |
|
|
|
Постов: 83
Дата регистрации: 12.01.2005 |
2 Yury
На самом деле, мне кажется, вы путаете понятия: "каким должен быть сайт с точки зрения заказчика" и
"каким должно быть цветовое, стилевое, навигационное решение с учетом пожеланий заказчика". Это абсолютно разные понятия. И получаем противоречие, когда с одной стороны заказчик мотивирует различные доделки на последнем этапе своей некомпетнтностью в веб-технологиях, интернет-маркетинге, в тз не можем всего учесть и т.п., а с другой - говорит, что мне лучше знать каким должен быть ваш сайт и поэтому я лучше знаю в каком месте каким цветом надо покрасить. |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
20.06.2005 10:37 | |
|
|
|
Ужасающее зрелище, душераздирающее зрелище... Кошмар!
Постов: 7690
Дата регистрации: 18.05.2005 |
Автор оригинала Yury
Это мой сайт! И я лучше знаю, что там д.б.
|
Я тоже заказчик. И, безусловно, именно заказчик должен определять каким должен быть сайт. Но я отлично понимаю и те эмоции, которые возникают у специалистов в момент когда этот заказчик на стадии завершения вдруг просит "поиграться со шрифтами". Позиция "я лучше знаю, что там должно быть" и верна и ошибочна одновременно. Дело в границе между "что" и "как". Профессионализм дизайнера - найти уникальное сочетание графики, цвета и композиции, обеспечивающее требуемый эффект. Постановка задачи (тот самый эффект) - дело заказчика. А вот если заказчик начинает вмешиваться в "технологию" - это проблема.
Причин здесь две - увы, не всегда профессионализм дизайнеров убедителен. Вторая - заказчик путает свое, личное, восприятие, с восприятием целевой аудитории + "творческий зуд". Ну да ладно, писать об этом можно много, но времени нет.
По теме - единственный способ борьбы с этим - разбиение по этапам и четкая формулировка рамок. Подписали дизайн - дальше его не трогаем. Если же меняем, то уже за отдельную плату. Это не совсем ТЗ, просто заказчику надо обяснять технологию. |
|
--------
Я так и думал - с этой стороны ничуть не лучше... |
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
20.06.2005 11:33 | |
|
|
|
Постов: 1719
Дата регистрации: 04.03.2005 |
Ваша проблема возникла из-за недостаточной формализации процесса разработки. Я Вам рекомендую формализовывать отношения с Заказчиком до начала технических работ тремя типами документов:
1. ТЗ на программирование. В нем фиксируются разделы сайта, описываются его функции и детали их работы.
2. ТЗ на дизайн. Этот документ разрабатывается на основании брифа, заполненного клиентом, и описывает корпоративные стандарты заказчика, его дополнительные пожелания и примеры нравящихся ему проектов. Если что-нибудь добавите в ТЗ на дизайн про семантику цвета и стиль проекта, то совсем хорошо.
3. Информационная структура основных страниц сайта. В ней все индивидуальные с точки зрения информационной структуры страницы рисуются в схематичном виде. Лучше это делать в Visio, а заказчику сохранять в Pdf или jpeg. Больше 10 уникальных страниц редко получается, так что с третьего раза трудоемкость таких работ вполне приемлемая. А такая схема позволит Вам избежать подобных проблем с Заказчиком.
Каждый из документов должен быть упомянут в договоре и подписан актом после его согласования.
В Вашем случае если новая структура сайта Заказчика реально лучше и все изменения обоснованы, то Вам придется их вносить. Лучший для Вас вариант, это прийти к компромиссу, внеся не трудоемкие изменения.
Если Вы уверены, что изменения Заказчика не улучшают проект, то подберите аргументы и постарайтесь его убедить. При этом не упоминайте о трудоемкости - это не интересует и раздражает заказчика. А лучше объясните ему, что изменения не приведут к улучшению, и что лучше сейчас запустить сайт в том виде, в котором он находится, чем через месяц запустить его измененным. За этот месяц сайт продаст немного товара, а изменения могут оказаться ненужными после изучения статистики посещения и путей посетителя по сайту. Кстати, лучший аргумент - это подобрать хороший сайт с похожей на текущую структурой и объяснить Заказчику на его примере, что текущая структура не так и плоха. |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
20.06.2005 13:33 | |
|
|
|
Постов: 83
Дата регистрации: 12.01.2005 |
2 Artus
Спасибо за небольшой ликбез :) Естественно, все вами перечисленные документы составляются, кроме блок-схем, последнее не всегда. Вы предлагаете формальный подход, который, во-первых, применяется в компаниями с "серийным" производством сайтов и может привести к запуску сайтов, которые будет стыдно показывать в портфолио. Я считаю, что для каждого клиента надо найти индивидульный процент формализма, необходмый при работе с ним. И, конечно, все мы ошибаемся и при моем подходе неизбежно возникнет вышеописанный прецендент. |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
20.06.2005 14:39 | |
|
|
|
Постов: 1719
Дата регистрации: 04.03.2005 |
Вам виднее:)
С моей точки зрения документы, процессы и инструкции должны быть стандартны, а вот идеи и решения, описываемые в этих документах - индивидуальны. Что касается индивидуального подхода к необходимой формализации, то я тоже так думал, пока Ваша ситуация не повторилась несколько раз;) После чего я понял, что проще не оправдывать себя перед собой же каждый раз, а потратить время на необходимую формализацию. |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
20.06.2005 14:57 | |
|
|
|
Новичок
Постов: 3527
Дата регистрации: 07.06.2004 |
При разработке небольших сайтов, кстати, формирование структуры сайта очень удобно делать вживую сайтбилдером. Чтобы не гонять туда-сюда вордовские файлы с абстрактными для заказчика структурами.
Сразу на лету формируется структура и возможно самим же заказчиком перекомпановывается в онлайне. Ну это так... риторика. ;)
2 Artus
Эх .. если бы заказчик умел писать т.з. или хотя бы всегда понимать то т.з., которое ему формируем мы. Но несомненно хотя бы минимальная формализация отношений пристутсвовать должна, особенно когда "чувствуешь", что заказчик любит играть в разработчика.
2 Пашкин
Рекомендую все в часах измерять. Жить проще *8)) оплата этапов по факту закрытия часов. Часы закрывает заказчик после каждого мини-этапа. Только, чтобы заказчик вас не боялся вы должны весь будущий проект расписать в часах (Estimation Plan) с этапами. Затем он его утверждает. Дольше ли вы делаете проект или быстрее - неважно. Эти часы как база - ее он потом закрывает. Если заказчик начинает играться вы его предупреждаете о доп. фин. часов.
И потом каждую игру заранее оцениваете в часах и проводите словесное/письменное согласование. И в конце этапа выкатываете (Time Spent Report) с утвержденными ранее часами пректными + дополнительными.
Как вам такая схема? |
|
--------
бренд "Cивой Кобылы" |
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
20.06.2005 19:35 | |
|
|
|
Постов: 83
Дата регистрации: 12.01.2005 |
2 JhAZZ
Эта схема породит целую теорию оценки эффективности работы дизайнеров, программистов и т.п. Либо брать цифры с потолка и подстраивать их под итоговую сумму.
Во-первых, это увеличение накадных расходов, перестраховка - влечет увеличение итоговой цены для заказчика. Во-вторых, иногда часть задач отдаются на аутсорсинг, который в принципе в лучшем случае работает с точностью по дня. В-третьих, как и с ТЗ заказчик не способен оценить насколько реальны цифры, которые он должен подписать. Вообще, насколько я знаю, некоторые крупные веб-студии разрабатывают проекты по 4-7 месяцев, в зависимости от сложности, т.е. просто, перестраховываясь, изначально называют срок раза в полтора превышающий оценочный. |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
21.06.2005 14:04 | |
|
|
|
Постов: 1719
Дата регистрации: 04.03.2005 |
Автор оригинала JhAZZ
2 Artus
Эх .. если бы заказчик умел писать т.з. или хотя бы всегда понимать то т.з., которое ему формируем мы. |
Я считаю, что Заказчик должен только формулировать цели и задачи сайта на маркетинговом уровне, предоставить информацию о конкурентных преимуществах и описывать свои пожелания (если таковые имеются) любым способом. Все остальное - концепцию сайта, структуру, ТЗ и прочее должен разрабатывать Исполнитель. Заказчик же должен лишь утверждать предложенные варианты и только в случае, если исполнитель не предлагает ничего достойного, то пытаться предлагать что-то свое (но это уже сомнительная стратегия, т.к. Заказчик редко предлагает что-то действительно интересное).
Если говорить о понимании ТЗ Заказчиком, то можно, например, делать ТЗ в двух видах - для программистов и технических специалистов (пусть это называется ТЗ на программирование) и для менеджера Заказчика - в простых понятных терминах (например, этот документ можно назвать Функциональным Заданием). |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
21.06.2005 14:29 | |
|
|
|
Новичок
Постов: 3527
Дата регистрации: 07.06.2004 |
2 Артус
Я согласен, что формирование т.з. - это диалог. Вопрос в том, как исполнителю удержать свои профессиональные позиции и не потерять веса в глазах заказчика. И как заказчику определить степень профессионализма исполнителя и в нужный момент его схватить за шкирку, когда тот делает ошибку?
2 Пашкин
День - это положим 7 часов. Эскизное проектирование веб-сайта к примеру 20 часов (картинки предоставлены заказчиком). Последующие варианты 5 часов/вариант. Макетирование выбранного варианта: 4-10 часов. Средний объем несложного веб-сайта с уникальной новостной линейкой (с какими-то наворотами), публикатор прайса (тоже с зашибами): 100-120 часов.
Американцы в этих часах прекрасно разбираются, потому что есть компании специализирующиеся на IT-аудите, которые потом смотрят на эти часы и говорят: завышены/занижены. От срока можно отступать +/- 20%. Если отступаете больше, значит либо завышаете сроки(воруете) либо занижаете (неэффективная работа специалистов). Вот Новософт например был аудитором. Сдулся правда.
Так вот и живем. |
|
--------
бренд "Cивой Кобылы" |
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
21.06.2005 21:24 | |
|
|
|
Постов: 83
Дата регистрации: 12.01.2005 |
Автор оригинала JhAZZ
День - это положим 7 часов. Эскизное проектирование веб-сайта к примеру 20 часов (картинки предоставлены заказчиком). Последующие варианты 5 часов/вариант. Макетирование выбранного варианта: 4-10 часов. Средний объем несложного веб-сайта с уникальной новостной линейкой (с какими-то наворотами), публикатор прайса (тоже с зашибами): 100-120 часов. |
Если бы быть уверенным что дизайнер за 3 дня выдаст отличный дизайн...
Как всегда возникает человеческий фактор, который и будет вынуждать вас перестраховываться раза в полтора минимум. По опыту могу утверждать, что 1й вариант, который исходит от дизайнера процентах в 90 не готов для его восприятия заказчиком, да, за 3 дня он будет готов, но еще столько же уйдет на его шлифовку. Эта тема была частично затронута в вашей теме "дизайнер должен быть маркетологом" Потом идут неизвежные баги в верстке, неаккуратности в растяжке, наложения фонов, зависимость верстки от табуляции и прочее и прочее...Программных багов удается избежать лишь в стандатных решениях, если надо что-то особенное, программисты так устроены, что какая-нибудь мелочь, да найдется - обязательно надо проводить комплексное тестирование. Итого получим сильно растянутый диапазон сроков. При хорошем раскладе уложимся в месяц для среднего сайта как вы написали, это бесспорно. И, кстати, в вашей почасовой модели с оплатой за доп. часы как предусмотрена ответственность за задержки сроков? Как вы просчитываете риски задержек и учитываете их в цене? ИМХО, без этих вещей все часы и расчеты превратятся в показуху...
Автор оригинала JhAZZ
Американцы в этих часах прекрасно разбираются, потому что есть компании специализирующиеся на IT-аудите, которые потом смотрят на эти часы и говорят: завышены/занижены. От срока можно отступать +/- 20%. Если отступаете больше, значит либо завышаете сроки(воруете) либо занижаете (неэффективная работа специалистов). Вот Новософт например был аудитором. Сдулся правда.
Так вот и живем. |
американцы в принципе разработкой сайтов занимаются по-другому, другие суммы, другая организация, да и сайты другие, ориентированы понятное дело на американцев. Собственно дизайну, оригинальным программным решениям там, по моим наблюдениям, уделяется меньше внимание. Если надо "копать от забора до обеда" тут и риски невелики. |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
22.06.2005 09:54 | |
|
|
|
Mamontino<<
< |
2Пашкин:
"...наша главная цель - создать оригинальный, запоминающийся сайт, с изюминкой, ставить минимум ограничений дизайнеру (в основном определяемых функциональностью, юзабилити, а не взаимным расположением блоков дизайна)...".
Я сейчас как раз над планом по редизайну сайта работаю с исполнителями, так мне от сайта нужна не "изюминка и запоминаемость", а решение вполне конкрентных маркетинговых и рекламных задач. При этом мне ваимное расположение блоков информации (дизайна) для меня важно, как и внутренняя логика работы будущего оператора. При этом собственно до дизайна еще долго дело не дойдет.
Кстати, многое из программных решений и "изюминок программной реализации", предлагаемой программистами на этапе планирования нам просто не нужно - и слишком сложно, и просто нам не подходит(лишнее это) по специфике работы ;-) |
|
<
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
22.06.2005 11:31 | |
|
|
|
Постов: 1719
Дата регистрации: 04.03.2005 |
Автор оригинала JhAZZ
2 Артус
Я согласен, что формирование т.з. - это диалог. Вопрос в том, как исполнителю удержать свои профессиональные позиции и не потерять веса в глазах заказчика.
|
Как вариант - объяснять Заказчику каждую функцию и каждую идею в разрезе целей сайта и решения конкретной задачи. Очень часто Заказчику не нужны сложные функции, а нужны правильные тексты и правильная структура страниц сайта (особенно внутренних). Если, например, рисуя схему основных страниц сайта вверху вписать в каждую страницу описание целевой аудитории, а каждый информационный блок заполнять не шаблонным текстом, а описанием задачи, которую решает этот блок (функция) и ссылаться при этом на Бриф заказчика (или другой аналогичный документ), то клиенту станет легче. Хотя на словах все легко, а на практике...:)
И как заказчику определить степень профессионализма исполнителя и в нужный момент его схватить за шкирку, когда тот делает ошибку?
|
Только путем привлечения независимого аудитора. Даже квалифицированный менеджер проекта у Заказчика не сможет быть полностью объективным. |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
22.06.2005 14:00 | |
|
|
|
Постов: 9
Дата регистрации: 03.05.2005 |
[QUOTE]Автор оригинала Artus
у вас чего-то у вашего сайта в Mozillе с горизонтальная прокрутка. Проверьте, видимо ошибка. (я не со зла, просто чтобы исправили) |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
23.06.2005 05:36 | |
|
|
|
Постов: 1719
Дата регистрации: 04.03.2005 |
| Спасибо, но мы жертвуем Мозилой и еще несколькими браузерами в угоду основным браузерам. Это возможно спорный подход, но таковы корпоративные стандарты:) |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
23.06.2005 10:51 | |
|
|
|
 | Только зарегистрированные пользователи могут оставлять сообщения в этом форуме |
|
|
|
|
|
© "ООО Состав.ру" 1998-2025
тел/факс: +7 495 225 1331 адрес: 109004, Москва, Пестовский пер., д. 16, стр. 2
При использовании материалов портала ссылка на Sostav.ru обязательна!
Администрация Sostav.ru просит Вас сообщать о всех замеченных технических неполадках на E-mail
|
|
|
|
