Что такое концепция сайта и зачем она нужна

≡ | Школа | 14.12.2009 13:21

Многих проблем можно избежать, если предварять разработку ТЗ подготовкой другого документа – концепции, описывающей требования верхнего уровня.

Посмотреть статью полностью

14.12.2009 13:50 | пишет prolis | ссылка

"КОНЦЕПЦИЯ" - неудачное слово, С методологической точки зрения такой документ является таким же фантиком, как и презентация в паверпонте. Есть же правильный термин BRD.

14.12.2009 13:59 | пишет Леха Андреев | ссылка

> Есть же правильный термин BRD.

Это тот самый BRD который переводится как ПТЦ? Ну, тоже не очень благозвучно.

14.12.2009 15:48 | пишет Борис М | ссылка

"КОНЦЕПЦИЯ" - неудачное слово! В ряду документов создаваемых от момента зарождения идеи до ее воплощения в жизнь данный этап называется "Задание на проектирование". Иногда его называют "Облик системы", что ближе к интернет индустрии. Где необходимо создавать различного рода информационные системы, призванных обслуживать информационные потоки.
А в общем все правильно!

14.12.2009 19:17 | пишет Злой демон | ссылка

Концепция - слово нормальное, но порядок разработки представлен слишком обобщенно. На этапе разработки автор тоже пляшет от дизайна - а это самая распространенная ошибка заказчиков. Должно быть так: сначала - функциональные требования, потом интерфейсы, потом графический дизайн.
Сроки никогда не соблюдают - это очень обобщенный поход. Есть понятие управления рисками, и оно предусматривает несколько вариантов готовности проекта, в том числе и срок, когда проект будет готов со 100%-ной вероятностью. На деле, стоит разработчикам заикнуться, что при стечении всех благоприятных обстоятельств и ненаступлении ни одного неприятного, проект будет готов к понедельнику, как этот понедельник автоматически назначают дедлайном.

15.12.2009 01:00 | пишет Андрей Акопянц | ссылка

Про порядок разработки я вообще системно не писал - просто набросал несколько тезисов (ошибки, которые обычно делают).

А дизайн - как показывает практика - самая проблемная вещь часто бывает. При качественном ТЗ добиться соответствующего ему функционала - не слишком сложно, и для приемки работ есть формальный критерий - соответствие ТЗ.

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

15.12.2009 11:14 | пишет Злой демон | ссылка

Ну собственно и беда в том, что процветает порочная практика, по которой графическому дизайнеру делегируется и создание низкоуровневой информационной архитектуры (а зачастую и высокоуровневой). И сидит бедный специалист по шрифтам и картинкам, пытаясь угадать, какие цели преследуют заказчики сайта.
Вообще, для людей которым лень или просто вдруг некогда читать книжки, статья весьма полезная. По мне, очень неплохо изложен "Веб-дизайн, ориентированный на пользователя" уважаемого тов. Джеймса Гарретта. За нюансами, наверное, действительно лучше туда.

15.12.2009 12:19 | пишет Леха Андреев | ссылка

> И сидит бедный специалист по шрифтам и картинкам

Беда в том, что он через это совсем не бедный. Я много раз видел веб-проекты, где у людей миллионы улетали в трубу только потому, что разработка основывалась на дизайне, а не наоборот. И очевидно многие дизайнеры с удовольствием поддерживают такое положение вещей.

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

А потом люди удивляются, почему на выходе очередной Top4top.

15.12.2009 12:28 | пишет Андрей Акопянц | ссылка

Думаю, что роль здесь играет малое количество специалистов на рынке, которые могут грамотно поставить задачу,и отсутствие понимание процесса заказчиками.

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

Другое дело, что согласование дизайна часто ограничивается главной страницей... И вот тогда начинается бардак - когда ТЗ нет, концепции нет. а есть только согласованная главная страница.

16.12.2009 02:24 | пишет Злой демон | ссылка

Специалист по постановке задач - это аналитик требований. Вы много раз видели вакансию "аналитик требований" в веб-проект? По пальцам одной руки можно пересчитать. Если загибать их в течение полугода. А проектирование, начатое что с дизайна, что с программирования - одни и те же яйца. Когда дизайн создается под цели, которые есть только в голове и хорошо если в одной, он ни разу не спасительнее написанного неизвестно под какие цели программного кода.

16.12.2009 10:04 | пишет Андрей Акопянц | ссылка

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

15.12.2009 11:32 | пишет Гость | ссылка

Йоперный театр. Давно уже есть готовые и работающие принципы разработки функционала и GUI. только почему-то то вЭб дивелаперофф они через Кассиопею идут, наверное.

15.12.2009 11:53 | пишет Андрей Акопянц | ссылка

> Давно уже есть готовые и работающие принципы разработки функционала и GUI.

А мужики - то и не знают. Фигачат себе по старинке....

15.12.2009 11:58 | пишет Гость | ссылка

Кто сказал, "по старинке"?!!! ФИГАЧАТ, КАК ФИГАЧИТСЯ!!!

16.12.2009 15:25 | пишет VSV | ссылка

Что первично, что вторично (дизайнер ли станет "раскрашивать" контролы, или программист "одинамичивать" картинки) зависит от двух вещей - от ситуации в стане заказчика и от типа создаваемого сайта.
Идеального универсального решения не существует.