Сайт как бизнес

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

1. Тексты на статичные страницы

Необходимо ещё раз повторить структуру сайта (даже если она есть в Концепции), указав, для каких из них какие тексты нужны.

Например, для страницы «Услуги компании» требования могут звучать следующим образом:

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

Требования по высылаемым материалам могут выглядеть так:

Текст для каждой страницы должен быть помещён в отдельный текстовый документ. Название документа соответствует названию страницы (по Концепции).

2. Тексты новостей

(аналогично для статей и пресс-релизов)

Надо объяснить Заказчику, что для размещения на сайте новости необходима следующая информация:

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

Требования по высылаемым материалам:

Вся информация по одной новости должна размещаться в одном текстовом документе. Название документа соответствует дате публикации новости и её заголовку.

3. Фотографии

Если обработка фотографий не входит в стоимость проекта, то нужно указать Заказчику:

• размер фотографий (или несколько размеров, если это требуется по Концепции);
• формат изображений;
• требования по оптимизации изображений под web;
• описания для тех фотографий, которые используются в фотогалерее сайта.

Требования по высылаемым материалам:

Изображения, высылаемые для фотогалереи необходимо разместить в отдельных папках, соответствующих названиям разделов фотогалереи. Внутри каждой папки фотографии должны быть отсортированы в том порядке, в котором они будут размещаться на сайте, фотографии должны иметь названия 01, 02 и т.д. Все описания фотографий должны быть перечислены в общем текстовом документе, в виде:

• 01 — описание 1
• 02 — описание 2 и т.д.

4. Каталог

Что касается каталога, многое зависит от того, чем занимается компания и насколько полный каталог будет представлен на сайте. Могу привести пример того, какая информация для каталога может понадобиться:

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

Требования по высылаемым материалам:

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

5. Сотрудники компании

Информация о сотрудниках компании может использоваться на странице о руководстве или структуре компании. В этом случае будет нужна следующая информация:

• фамилия, имя, отчество;
• занимаемая должность;
• контактный телефон;
• контактный e-mail;
• фотография.

6. Сервисы на сайте

Если на сайте будут предусмотрены онлайновые сервисы, позволяющие общаться посетителям сайта и сотрудникам компании, то понадобится следующий список:

• фамилия, имя, отчество сотрудника;
• его контактный e-mail (на который будут отправляться сообщения от посетителей сайта);
• услуга или вопросы, за которые данный сотрудник является ответственным (например, вопросы по доставке или по техническому обслуживанию).

7. Интекрактивная карта

Это может быть карта дилеров компании, её офисов или клиентов, может быть карта построенных домов или, например, АЗС. В этом случае вся информация для карты должна быть представлена в следующем виде (на примере дилеров, расположенных в разных городах):

• название компании дилера;
• город;
• адрес;
• логотип;
• контактный телефон;
• контактное лицо;
• схема проезда.

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

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

Взято с http://habrahabr.ru/blogs/webdev/44886/

Однажды, когда я только начал доставать до верхнего шкафчика на кухне, я решил сделать себе кофе.

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

В один прекрасный день, едва оставшись дома один, я залез в шкафчик и достал заветную банку. «Сделаю кофе повкуснее«, — подумал я и щедро бухнул в чашку две ложки. Хорошенько размешав, я попробовал сделать глоток и тут же выплюнул: кофе получился ужасно горький.

«Мало кофе!«, — подумал я и положил еще две ложки… дальше описывать не буду, понятно, что в результате кофе отправился в раковину.

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

В начале все работали как работали, но темпы жизни нарастают, приходиться или что то менять в процеессах работ или тешиться «остатками» еды от монстров рынка. Тоже самое и касается web разработки. Многие основатели студий начинали наверняка с «слушай, вот сделай нам по быстрому вот то, то и то…». Потом «быстренько» перерастало в бесконечный труд, трату времени а как следствие и ресурсов, и в результате интересов (как финансовых, так и мотивационных).

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

— «Вот смотрите, мы хотим чтоб было все! Что б все было классно, чтоб было не как у всех, чтоб мы были в первой строчке выдачи всех поисковиков! » — типичные слова 50% заказчиков. Безусловно мы не имеем морального права спорить с заказчиком, ибо он прав по умолчанию, но речь идет именно о взаимных интересах. Веб студия зачастую ничего не знает ни о бизнесе заказчика, ни о его процедурах, его преимуществах перед конкурентами, не тем более о вкусах ответственного за выполнение работы со стороны заказчика.

Решением данной дилемы служит Техническое задание — обычный документ, описывающий то, что хочет заказчик и в каком виде. С первого взгляда это может показаться лишней бюракратией, излищками «крупного» производства, или пустой тратой времени. Но поработов не один год по обеим вариантам могу заявить что всю мою жизнь можно разделить на два этапа — до того как я писал технические задания для заказчиков и после того. Я полностью убедился что техническое задание — не просто бумажка, не просто бюракратия — инструмент для работы, ровно такой же как клавиатура, мышка и web-сервер.

Как известно заказчик платит именно за время, потраченное на разработку проекта, или работает по fixed price (оговоренная сумма за конечный продукт). ТЗ на 99% процентов закрывает вопросы по оценке проекта (всегда известно что надо делать), всегда служит доказательством того что вы правы то что сделали — заказчик не упрекнет вас в том что вы что то не сделали или сделали не так — т.к. все что вы должно — описано в ТЗ. Да и в любой момент можно найти на возникающие вопросы — как где и что должно быть и работать на сайте.

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

Итак что же должно включать в себя техническое задание?! Вот мое примерное видение того что должно быть оговорено в ТЗ:
1. Наименование предприятия Заказчика Системы и его реквизиты — раздел, дающий общую информацию о предприятии. Контакты и т.д. Зачастую инмеенно отсюда вся информация попадает в раздел Контакты на сайте
2. Назначение проекта — описание функционального предназначения сайта. По функциям сайт может делиться на информационный сайт, портал, магазин, и т.д.
3. Задача проекта — кратко сочинение на тему того, для чего вообще создается сайт — для отмывания денег, для рекламы, для продвижения продукта.
4. Целевая аудитория проекта — несколько слов о том какого вы выидите конечного пользователя — возростная категория, социальный статус и даже цвет кожи могут играть роль
5. Требования к стилистическому и шрифтовому оформлению — всего скорей созрев до сайта у заказчика уже есть так называемый фирменный цвет. Было бы не плохо описать его здесь
6. Требования к графическому дизайну — здесь главное не увлекаться описанием и не начинать вольных сочинений на тему «красненькую точку надо разместить 33 пикселя от правой границы окна браузера…» Общих фраз типа легкий, изящный, тщательно проработаный детальный..
7. Требования к контенту и наполнению — структура сайта — далеко не сам сайт. Самое дорогое далеко не система управления, бизнес логика или дизайн — самое дорогое — тщательно проработаный контент. Опишите ваши требования, кто в каком виде предоставляет материалы
9. Структура сайта — один из ключевых разделов. Здесь описывается структура сайта, в виде разделов, их описаний и данных, которые будут представленны на этих страницах
10. Приложения к заданию — собственно говоря наша смета. Смета должна покрывать те пункты, которые описаны в задании. Если это пункт, говорязий что у нас на сайте будет авторизация и регистрация — значит в смете должен быть этот пункт.

Как видите тут нету почти ни слова про дизайн, какой он будет, эскизы и т.д. Почему мы его не включаем — потому что любое производство должно быть мануфактурным, т.е. ответственные за дизайн должны быть дизанеры, а за разработку — разработчики.

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

Резюме: если вы заказчик — не соглашайтесь начинать работу и какие то отношения с исполнителем не получив от него письменного подтверждения того что получите в результате. Если же вы исполнитель — перестрахуйтесь от двойной, тройной (n-ной) работы и бесконечных переделок с того как я вижу на то как надо — составьте ТЗ и будет взаимное счастье.

..Навеянно размышлениями о жизни…

Опробовав не одно CMS решение я задумался — какое же оно должно быть то..именно то, что доставляло бы радость при создании новых проектов. Будучи реалистом по жизни я не пытаюсь найти решение которое бы управлялось силой мысли, и могло бы построить то что хочет заказчик исключиельно словами «Трах-тибидох-тибидох…». Читать далее »

Сегодня хотел бы еще раз заострить внимание на XML и XSLT технологиях, используемых в разработках Web проектов.

Почему я сделал упор именно на эти технологии:

1. Поддержка мега-вендорами, такими как Microsoft, Oracle, и т.д.
2. Неограниченное количество степеней свободы данных (XML), т.е. данные могут быть представленны не в строгом «табличном» формате или в виде вложенности массивов
3. Легкая интеграция с другими решениями
4. Всегда правильный и валидный HTML на выходе
5. Удобные конструкции
6. Высокая производительность обработки шаблонов в отличие от того ;е SMARTY

Читать далее »