Михаил Боде - Создание сайтов
- Название:Создание сайтов
- Автор:
- Жанр:
- Издательство:Array Издательство «Питер»
- Год:2014
- Город:Санкт-Петербург
- ISBN:978-5-496-00933-1
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Михаил Боде - Создание сайтов краткое содержание
В издании дано представление о том, кто и как может разработать сайт, как управлять проектом создания сайта, как именно и зачем смотреть на эти процессы глазами аналитика, дизайнера, менеджера и маркетолога. Затронуто также создание мобильной версии сайта и мобильного приложения.
Изучив методы и рекомендации, предлагаемые авторами, вы получите уникальный опыт и компетенции для того, чтобы создавать сайты разной степени сложности, грамотно связывая их со своими бизнес-процессами.
Издание адресовано всем заинтересованным в создании интернет-сайтов.
Создание сайтов - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
– Ладно. Есть ли какие-то особые требования к хостингу?
– А у вас сейчас есть хостинг? Или будете покупать его исходя из наших рекомендаций?
И так далее. Однако в самом документе предпочтительно использовать нейтральный стиль с официальными, но необязательно канцелярскими формулировками. Возьмите за правило: техническое задание не тайна за семью печатями, поэтому оно должно быть понятно без устных пояснений и дополнительных консультаций тому, кто откроет его впервые.
В конце каждой онлайн– или офлайн-встречи фиксируйте, чья очередь вносить изменения в концепцию (а далее в ТЗ), и оговаривайте сроки правок.
Итак, по итогам первых согласований черновик легким движением руки и напряженной работой мозга превращается в концепцию, которая вскоре сформируется в полновесное техзадание. Концепцию можно сегментировать, например, следующим образом:
• предназначение и задачи сайта;
• роли заказчика и исполнителя;
• структура сайта;
• содержание;
• краткий список сервисов и возможностей.
«Ну что за бюрократия “роли заказчика и исполнителя”!» – поморщится читатель, нетерпимый к канцелярскому языку. Тем не менее сколь скучно название раздела, столь важен он сам. К сожалению, случается, что если круг обязанностей исполнителя подробно не оговорен, то заказчик после месяца сотрудничества понимает, что создание дизайна в задачу разработчика не входит (обратное было бы странно). Или наоборот, не имея четкой договоренности относительно своих обязанностей, исполнитель ограничивается кодингом, а за верстку сайта и не думает браться.
Список разделов вы вправе изменять, расширять и сокращать исходя из своих потребностей. Помните упомянутое ранее расплывчатое пожелание анонимного заказчика: «Мне бы новостной сайт типа Lenta.ru…»? Справедливости ради необходимо отметить, что в ряде случаев на стадии обсуждения концепции допустимо или даже желательно указать, на какие интернет-проекты вы ориентируетесь, какие вам нравятся больше, а какие меньше.
Ни ваш драфт [2] Драфт (от англ . draft – «черновик», «предварительный план») – здесь: набросок концепции ТЗ, краткая декларация о намерениях.
, ни первая версия технического задания (будь она хоть подробнее некуда) – это не «окончательная бумажка», которой вожделел профессор Преображенский в «Собачьем сердце». Почти наверняка изменения и повторные согласования понадобятся. Чем чаще и подробнее они закрепляются сперва в концепции, затем в ТЗ, тем лучше.
Маленький совет, который, мы уверены, облегчит вам жизнь и приблизит момент открытия сайта. Именовать файлы с концепцией или техническим заданием следует так, чтобы с первого взгляда становилось ясно, кто автор редакции документа и является ли она актуальной. Например, ProjectSpecification0.1.doc. Здесь Project – название проекта, Specification – тип документа (в нашем случае техзадание; это может быть и Concept – «концепция»), а первая цифра маркирует версию, отправленную исполнителю; если это 0, значит, она еще не выслана и вы шлифуете документ собственными силами. Тогда 0.2 может обозначать новую редакцию документа, сделанную вами же и никому больше не показываемую. Когда же исполнитель ответит вам, прислав документ со своими уточнениями, вы создадите с учетом его поправок и ваших собственных доработок (версии 0.2) файл под номером 1.3.
При работе над ТЗ вам не помешает попробовать себя в амплуа занудливого параноика: «Новостной блок фиксированного размера находится на главной странице вверху справа, под шапкой. В нем отображаются четыре последние добавленные новости (с возможностью закрепить с помощью админки произвольно выбранную на верхней позиции). Длина текста – до двух строк. Под каждой новостью слева внизу шрифтом на два кегля меньше того, которым набран анонс новости, указана дата в формате DD.MM.YYYY, например 15.08.2013».
Пишущий такие формулировки в техническом задании не «человек дождя», хотя, очевидно, впадает в крайность. Он не страдает аутизмом, и если болеет, то лишь за успех интернет-проекта. Смотрите сами, готовы ли вы вообразить будущий сайт настолько подробно или лучше такие мелкие подробности закреплять постепенно с каждой новой версией документа. Между прочим, нередко графический эскиз страницы гораздо красноречивее текста (см. далее в подразделе «Как оно выглядит»).
Что должно входить в техническое задание
Едва ли не главное для технического задания (после смыслового наполнения, конечно) – четкая структура и простое, понятное форматирование. В конечном счете ТЗ должно представлять собой доработанную и обросшую деталями концепцию, в идеале – вплоть до внешнего вида и механики работы страницы каждого типа в отдельности. Возможна следующая рубрикация ТЗ.
• Термины и определения.
• Назначение технического задания.
• Обязанности исполнителя и заказчика.
• Назначение и задачи сайта.
• Описание работы сервиса и механики сайта.
• Структура сайта и его составляющие.
• Дизайн сайта.
• Требования к технической и программной реализации сайта.
• Условия сдачи и приемки.
Критически важно, чтобы из технического задания явствовали объективные критерии того, выполнена та или иная задача или нет. Недвусмысленность формулировок заранее отсекает риск многих претензий и разочарований как со стороны заказчика, так и со стороны исполнителя.
Никто не отменял каверзных законов Мерфи: если возможны разночтения, с высокой долей вероятности будет выбрано большее из зол. Гладко было на бумаге, да забыли про овраги. А также про тектонические трещины, вблизи которых сейсмическая активность столь сильна, что, вероятно, скоро никаких оврагов не будет. И про то, что овраги заодно с полями и лесами находятся в частной собственности.
Вообще попробуйте отнестись к ТЗ как к брачному контракту. Вам ведь со своим сайтом потом жить и жить.
Как оно выглядит
Форма подачи информации в техническом задании остается на ваше усмотрение и зависит от того, кто ваш подрядчик и каков его опыт, насколько сложна внутренняя логика сайта, делаются ли в одной фирме дизайн, программирование и верстка или нет. Существуют отраслевые стандарты по составлению ТЗ, включая предписываемый IEEE [3] IEEE (Institute of Electrical and Electronics Engineers) – Институт инженеров электротехники и электроники, регламентирующий в том числе многие мировые стандарты интернет-коммуникаций.
. Кроме того, простите за грубость, в интернет-фольклоре есть «правило 34», которое звучит так: «Про это есть порно». Так вот, можно было бы сформулировать и «правило 34.1»: «Про это есть ГОСТ». И по формату техзадания на разработку сайта ГОСТ имеется, и номер его – 34.602-89.
Интервал:
Закладка: