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

Поисковое продвижение сайтов (SEO), создание сайтов в Минске (Беларусь).

Подпишись на рассылку блога об интернет-бизнесе:

Архивы на тему ‘разработка’

Что такое хорошее техническое задание на сайт?

пока комментариев нет

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

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

Вводная

Зачем составлять техническое задание (ТЗ) на сайт?
Какую бы методику разработки вы не использовали, и какого бы размера ни был ваш сайт, вы в любом случае столкнетесь с вопросом: «А когда мы будем заканчивать работу, то как мы поймем, что мы ее действительно закончили?» В разработке как ПО, так и любого сайта частая проблема - никто не видит конечной точки. С одной стороны можно сказать, что конечным видением проекта должен обладать проектный менеджер. Но если конечный продукт совпадет с образом менеджера, но не совпадет с ожиданиями клиента? А если за время проекта меняется 3 менеджера?

Следствие закона Паркинсона «девяносто-девяносто»:
Первые 90% кода отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки.

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

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

О чем эта статья.

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

Добавлю ограничения.

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

Стоит разделять ТЗ для малых и больших сайтов. Это - два. Различия маленьких и больших проектов заключаются не в объеме документа на выходе, а в процессе их разработки. Если у вас всего 4 человека в проектной группе, все давно знают друг друга, то можно предполагать отсутствие формализма. Если же разработкой занимаются несколько «отделов», а проектная команда состоит из более 10-ка (до бесконечности) сотрудников, то управлять этой ордой может только процесс. Процесс рождает формализацию, а формализм накладывает свой отпечаток на формат документации.

По сути, толщина документов зависит от сложности процесса в больше степени, нежели от размеров проекта.

Мы будем следовать самому сложному пути.

ТЗ отвечает на вопросы

ТЗ изначально создается для нескольких участников разработки:

  1. Разработчики проекта (дизайнеры и программисты).
  2. Проект-менеджер.
  3. Клиент.
  4. Бюрократы (они могут не участвовать в проекте, но на них тоже надо рассчитывать).

Оглядываясь на приведенные группы участников можно предположить, что ТЗ в первую очередь должно отвечать на их вопросы. В идеале вся предпроектная документация в каскадном методе создается так, чтобы снять вопросы в процессе разработки.
Итак, на какие вопросы отвечает ТЗ.

Для кого создается сайт и для чего?

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

Как будут решены задачи заказчика и пользователей?

Собственно если не ответить на этот вопрос, то написание ТЗ можно признать бумагомарательством. Это основной и значимый вопрос. Ему может быть посвящена отдельная статья, поэтому останавливаться на нем подробном пока не будем.

Как будет проходить создание проекта?

Как я уже писал выше, ТЗ (а может и отдельный документ) иногда описывает процесс разработки проекта. Это совершенно необходимо, если принять во внимание, что сайт может разрабатываться по отличной от принятой в компании методики разработки, которая как правило не описывается ни одним документом. Можно сколько угодно долго мучить себя мечтами о стандартизации по ISO, но что показать дотошному заказчику?
По ГОСТу предусмотрен отдельный раздел «Этапы разработки системы». В таком разделе можно не слишком подробно описать процесс и установить майлстоуны.

Что будет приниматься на выходе?

ТЗ начинает разработку и ставит в ней точку.
В идеале вы должны пройтись по всем пунктам ТЗ вместе с заказчиком, свериться с полученной системой и спустя неделю сказать: «Уф-ф. Вроде все сделали».
«ТЗ является средством верификации выполненных работ.» - такая фраза записана во введении многих моих ТЗ.

Что требуется для дальнейшего запуска проекта?

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

Из чего состоит ТЗ

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

Общая информация

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

Общая информация включает в себя:

  • Информацию о заказчике и исполнителе.
    Обязательно указание ответственных лиц с каждой стороны. Указываются документы, на основании которых производится разработка. Как правило, подобным документом является договор. Статус текущего документа и конфиденциальность.
  • Назначение проекта.
    Указывается: для чего будет использоваться полученный продукт.
  • Цели создания и задачи, которые должен решить ресурс.
    С одной стороны это довольно короткий раздел, но по важности проработки он занимает первое место. Если цели и задачи поставлены нечетко и неизмеримо, то может быть довольно сложно им следовать.
  • Описание аудитории проекта.
    Критично важная информация для разработки хороших и правильных сайтов. Ясно, что информацию об аудитории не только надо правильно собирать, но еще важнее это уметь этой информацией пользоваться.
    Описание аудитории должно содержать не только информацию, которую так любят маркетологи (демография, потребности, сегментирование и т.п.), но также информация, которая пригодится дизайнерам и проектировщикам: какие задачи решает пользователь, какие его цели в работе с сайтом, что его привлекает. Алан Купер рекомендует описывать аудиторию сайта не в виде безликой массы, а выделять персонажи - описывать собирательный образ конкретных людей.
  • Термины и определения.
    В большом документе вы сможете употребить огромное количество терминов и сленговых выражений, которые редко понимают специалисты по маркетингу или крупные руководители. Они могут читать этот документ, поэтому лучше предусмотреть для них список определений. Я не тешу себя надеждой, что этот список хоть раз в жизни был прочтен, но зато я могу всегда сослаться на него.

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

Эта информация собирается в рамки проекта.

Рамки проекта

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

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

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

Рамки проекта пишутся в виде сценариев работы пользователей с сайтом и описывают общую функциональность и интеракции с интерфейсом.

Информационная архитектура и интерфейс

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

Для описания ИА потребуется описывать сверху вниз:

  1. Структуру сайта. Это так называемые высокоуровневые прототипы.
  2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
  3. Опись контента. Табличное описание содержания каждой страницы сайта.

Структура сайта

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

О том, как можно рисовать структуру сайта с помощью нотаций, используя Visio, написаны целые статьи, поэтому останавливаться на этом не будем. Статьи написаны, правда, на английском, но вы легко сможете воспользоваться ими.

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

Полезные советы при рисовании карты сайта:

  • Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг от друга. Это поможет читабельности карты.
  • Не мельчите. Прочитать текст, напечатанный 4 кеглем, в принципе можно, но это уже причина для ненависти.
  • Выравнивайте «квадратики» страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
  • Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны «перескакивать» одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
  • Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
  • Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.

Шаблоны страниц

На уровне карты сайта каждая страница представляет для нас только «квадратик» на листе бумаги. Для дизайнера, верстальщика и программиста этого недостаточно, чтобы разработать сайт. Надо еще знать наличие и расположение блоков информации и функций на страницах сайта. Поэтому мы переходим к шаблонам сайта. В идеале каждый квадратик должен быть детализирован до схемы каждой отдельной страницы. Это прототипирование сайта. Использование прототипирования зависит от принятой схемы работы в компании-разработчике, но стоит признать, что это становится для заказчика крайне недешево.

Для упрощения выделяют ряд шаблонов интерфейса сайта, которые описываются вслед за картой сайта.

Описание шаблонов состоит из 3х частей:

  1. Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
  2. Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
  3. Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.

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

Описание контента

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

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

Хорошее описание контента залог спланированной работы на этапе запуска сайта и внесения информации.

Функционал

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

Хороший пример описания функционала дает ГОСТ. Рекомендую держаться стандарта при описании функционала разрабатываемого в рамках сайта программ. Должны быть описаны: общая система, общие функциональности подсистем и модулей, взаимосвязь подсистем и модулей между собой и, наконец, перечисление всех функций модулей с более или менее подробным описанием их работы. Для каждого модуля должны быть расписаны объекты, которые создаются или используются в работе программы.

Можно также описывать структуру базы данных, предварительные алгоритмы работы, но само по себе техническое задание этого не требует. По ГОСТу подобные подробности должны описывать в дальнейших документах: эскизный и технический проекты.

Иногда при разработке крупных сайтов приходится долго посидеть, чтобы описать весь функционал внешней и внутренней части сайта. Некоторые разработчики против такой детализации. Они считают, что функционал надо описывать поверхностно, чтобы «клиенту было понятно». Полная ерунда! По опыту могу сказать, что лишней детализации не бывает. В случае проблем в проекте менеджеры проекта с обоих сторон становятся редкостными буквоедами! Они вычитывают ТЗ вдоль и поперек стараясь доказать свою правоту. Поэтому если функционал в ТЗ прописан общими словами клиент все равно заставит сделать то, что ему надо.

Требования

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

  • Технические требования к системе;
  • Требования к персоналу;
  • Требования к надежности;
  • Требования к эргономике и технической эстетике;
  • Требования к защите информации от НСД;
  • Требования по сохранности информации при авариях;
  • Требования к видам обеспечения;
  • Требования к программным средствам;
  • Требования к информационному обеспечению;
  • Требования к техническим средствам;

Может быть также ряд специфических требований.

Все требования необходимо четко формулировать и стараться не забыть ничего из аспектов разработки вашего проекта.

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

Прочее

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

Что дальше?

ТЗ составлено, подписано и поступило в работу. Что дальше? Заканчивается ли работа с ним на этом этапе? Нет.

Проект далеко не всегда идет по заранее запланированному пути. Мы стараемся что-то улучшить, изменить, часто меняются требования заказчика. Техническое задание это документ, а не скрижали. С изменением требований к проекту должно меняться и техническое задание. Обычно это делается дополнительными документами со списком изменений. Естественно, они составляются только в том случае если это действительно необходимо, на практике встречается редко.

Также вы должны быть готовы, что в процессе глубокого изучения ТЗ всеми участниками разработки в процессе работы над проектом будут найдены ошибки. Количество ошибок в большом документе прямо пропорционально его объему и обратно пропорционально времени, затраченному на его написание. Т.к. времени постоянно не хватает, следует ожидать, что ошибки в ТЗ будут возникать.

В сухом остатке

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

  • Общую информацию о документе и его составителях;
  • Цели и задачи сайта;
  • Описание пользователей сайта, их цели и задачи;
  • Рамки проекта;
  • Информационная архитектура (ИА) сайта: карта сайта, шаблоны, описание интерфейса;
  • Описание контента сайта;
  • Описание функционала сайта;
  • Описание процесса и майлстоунов, если требуется;
  • Перечень всевозможных требований при разработке сайта и верификации полученной работы.

Надеюсь, что информация будет полезна широкому кругу читателей.

Полезные ссылки

Написал Валерий Хвалев

15 августа, 2009 в 10:27 пп

Подпишись на обновления блога по e-mail или RSS!

Средства удовлетворения заказчика

пока комментариев нет

Все люди делятся на 2 роли, заказчики и исполнители. И роли эти зачастую меняются. Будучи по одну сторону прилавка магазина мы являемся заказчиками (покупателями), но стоит нам перелезть через прилавок — как мы становимся исполнителями. 

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

Итак условия задачи: 

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

Дано: заказчик — 1 шт. 

Необходимый результат: удовлетворенный заказчик — 1 шт.

Первый шаг

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

Неверный вопрос заказчику: Необходимо ли вам в поректе древовидная структура наследования объектов. 

Верный вопрос заказчику: Будет ли у вас каталог со вложенными разделами ?

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

Если это надо на самом деле Вам — позаботьтесь самостоятельно об том чтоб заказчик заполнил его. 

Далее важный момент — ТЗ. Не так давно я уже писал о его необходимости. Оно необходимо — и это аксиома! 

Планирование работ: 

Используйте в своей работы инструменты планирования работы с возможностью просмотра стадий, контрольных точек. Даже если вы уверенны что заказчик этим не будет пользоваться, а вы и так гений планирования и все планы готовы предоставить на post-it листочках — не стоит этого делать. Вы профессионал, и надо работать профессионально. Инструменты планирования проектов намного упрощают работу в проекте. А лишняя информативность заказчика никогда не помешает. 

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

Контрольные стадии проекта

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

  • сдача дизайна
  • сдача верстки
  • сдача модуля ХХХ (новости, каталог) 

Презентация конечного продукта

Сделав проект — не поленитесь сделать презентацию к нему — расскажите заказчику какой титанический объем работ вы выполнили. Включите в презентацию рассказ о больших событиях в проекте (освоили новый подход к решению тривиальной задачи) — пускай он даже ничего не поймет, но ему будет приятно что заплатив за сайт он получил множество всего. 

Сдал — забыл ??

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

Несколько бесплатных советов

Предоплата — ничто не добавляет уверенности в заказчике как предоплата :) Но если заказчик старый и проверенный друг — думаю вы уже доверяете друг другу. 

Передача исходных кодов — весьма спорный вопрос. Впринципе заказчик заплатил за проект и может расччитывать на обладанием прав на исходный код. Нет никакого смысла его кодировать (Zend Encoder..) т.к. это просто НЕ логично. 

Макеты сайта нарисованные в фотошопе тоже впринципе могут быть переданы заказчику — он заплатил за них.  

Итого

Чтобы получить удовлетворенного заказчика нам надо следовать следующим правилам: 

  1. Заказав сайт заказчик должен получить не только сайт но и заботу. 
  2. Не скупитесь на удобства для заказчика. Отчеты о работе, презениации и системы -все это добавляет вес вам. 
  3. Сдав проект не забывайте о заказчике. Интересуйтесь его делами, пригласите в офис для совместного распития чая
  4. Постоянно работайте над улучшением качество своего обслуживания. Нет пределу совершенства! 

Написал Валерий Хвалев

21 ноября, 2008 в 3:56 пп

Подпишись на обновления блога по e-mail или RSS!

Требования для подготовки контента

пока комментариев нет

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

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/

Написал Валерий Хвалев

18 ноября, 2008 в 3:27 пп

Подпишись на обновления блога по e-mail или RSS!

Чего хотят заказчики?

пока комментариев нет

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

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

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

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

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

Написал Валерий Хвалев

17 ноября, 2008 в 12:38 пп

Подпишись на обновления блога по e-mail или RSS!

Техническое задание на разработку сайта — бюракратия или жизненная необходимость

пока комментариев нет

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

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

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

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

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

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

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

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

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

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

Написал Валерий Хвалев

15 ноября, 2008 в 12:33 пп

Подпишись на обновления блога по e-mail или RSS!

CMS vs FRAMEWORK или прогибаем или прогибаемся под заказчика

пока комментариев нет

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

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

Написал Валерий Хвалев

10 ноября, 2008 в 1:16 дп

Подпишись на обновления блога по e-mail или RSS!

Используем XML и XSLT в качестве модели данных и шаблонов отображения

пока комментариев нет

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

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

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

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

Написал Валерий Хвалев

8 ноября, 2008 в 2:47 пп

Подпишись на обновления блога по e-mail или RSS!