Подготовка тз. Что такое тз

1. Место, условия и сроки выполнения работ по ремонту помещения (далее – работ):

1.1. Место выполнения работ:

Нежилое помещение № 50, расположенное на 5-м этаже здания по адресу:

1.2. Условия выполнения работ:

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

Работы выполняются в соответствии с Локальной сметой на выполнение работ по ремонту помещения (Приложение к договору № от (далее-Договор)).

1.3. Сроки выполнения работ:

Подрядчик обязуется приступить к выполнению работ после подписания настоящего Договора Сторонами не позднее дня, следующего за днем согласования Локальной сметы на выполнение работ по ремонту помещения с Департаментом управления имуществом и земельными ресурсами администрации города Твери, выполнить все работы и передать их результат Заказчику в срок не позднее 30 (тридцати) календарных дней со дня начала работ.

2. Общие характеристики работ:

Выполнение работ по ремонту нежилого помещения № 50 расположенного на 5-м этаже здания по адресу: (далее – помещение).

3. Требования к качеству и безопасности работ:

3.1 Требования к качеству, техническим характеристикам работ и иные показатели, связанные с определением соответствия выполняемых работ потребностям Заказчика, установлены действующими Строительными нормами и правилами (далее СНиП), сводами правил по строительству (далее СП), ведомственными строительными нормами (далее ВСН), санитарными правилами и нормами (далее СанПиН), государственными стандартами (далее ГОСТ), техническими условиями (далее ТУ), нормами пожарной безопасности (далее НПБ), правилами пожарной безопасности (далее ППБ), правилами устройства электроустановок (далее ПУЭ) и иными нормативными документами.

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

Строительные нормы и правила СНиП «Безопасность труда в строительстве»;

Федеральный закон -ФЗ «Технический регламент о безопасности зданий и сооружений»;

Федеральный закон -ФЗ «О пожарной безопасности»;

Строительные нормы и правила СНиП «Пожарная безопасность зданий и сооружений»;

Нормы пожарной безопасности НПБ 244-97 «Материалы строительные. Декоративно-отделочные и облицовочные материалы. Материалы для покрытия полов. Кровельные, гидроизоляционные и теплоизоляционные материалы. Показатели пожарной безопасности».

Федеральный закон -ФЗ «Технический регламент о требованиях пожарной безопасности».

3.2. Риск случайной гибели или случайного повреждения нежилых помещений при выполнении работ до приемки Заказчиком несет Подрядчик.

4. Требования к организации работ :

4.1. Работы должны выполняться в будние дни: понедельник, вторник, среда, четверг с 09.00 до 18.00, пятница с 09.00 до 16.45. Организация работ в субботу осуществляется по предварительному согласованию с Заказчиком с 09.00 до 16.00.

4.2. Подрядчик обязан обеспечить выполнение работ из своих материалов, своими силами и средствами. Состав материалов указывается в Локальной смете на выполнение работ по ремонту помещения (приложение №1 к Договору).

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

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

5. Требования к материалам и оборудованию

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

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

6. Требования к отделочным работам

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

6.2. Обшивка стен гипсокартоном , с устройством технологических ниш под географические карты, видеокамеры , технику аудиоусиления. Устройство трубостоек для размещения и крепления бесшовной видеопанели.

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

6.3. Устройство подвесных потолков.

Для потолков помещений использовать - подвесной потолок «Армстронг» и плитку потолочную «Байкал».

6.4. Ремонт пола.

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

6.5. Устройство межкомнатных перегородок.

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

6.6. Произвести демонтаж старых оконных переплетов, деревянных подоконных досок, установить оконные блоки из двухкамерных ПВХ стеклопакетов, пластиковые подоконные доски.

Цвет стеклопакетов – белый. Окна должны иметь открывающиеся части не менее 1/3 площади. Оконные проемы должны быть снабжены жалюзи и роль-шторами, цвет согласовывается с Заказчиком. Подоконники – пластиковые, глубиной не менее 50 см.

6.7. Косметический ремонт батарей центрального отопления.

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

7. Требования к электромонтажным работам

7.1. Электромонтажные работы провести в соответствии со Схемой электропроводки (п. 9 Технического задания).

7.2. При производстве электромонтажных работ руководствоваться требованиями СНиП 3.05.06-85 «Электротехнические устройства». Розетки установить в установленных кабель-каналах на расстоянии не менее 0,5 м от уровня пола, внешним монтажом.

7.3. Установить электрический распределительный щит (РЩ) с установкой 9 автоматических выключателей (автоматов защиты сети АЗС).

7.4. Для освещения и подсветки ниш с картами использовать энергосберегающие экологичные светильники.

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

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

7.7. Прокладка кабельных трасс подлежит уточнению при выполнении работ.

7.8. При монтаже использовать кабель с медными жилами ПВХ изоляции в ПВХ оболочке негорючей, изготовлен согласно ГОСТ 22483 «Жилы токопроводящие медные для кабелей, проводов и шнуров. Основные параметры. Технические требования». Розетки должны соответствовать евростандарту. Все материалы и оборудование должны иметь сертификаты, технические паспорта и другие документы, удостоверяющие их качество, соответствовать требованиям ПУЭ, СНиП и ППБ. Все материалы должны быть новыми и изготовлены не позднее 1 квартала 2012 года.

8. Требования к сроку гарантии качества работ

Срок гарантии качества на выполняемые работы с учетом применяемых материалов должен составлять 36 месяцев в объеме 100% со дня подписания Акта о приемке выполненных работ (форма КС–2). В течение гарантийного срока Подрядчик обязан устранять любые недостатки результата выполненных работ по Договору за свой счет в срок не более 15 (пятнадцати) календарных дней со дня обращения Заказчика.

9. Схема электропроводки.

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

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

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

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

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

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

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

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

Что нужно для того, чтобы начать разработку дизайна сайта? Иногда этот вопрос выносят в отдельный документ, к примеру в договор. Но для составления ТЗ он тоже имеет значение. От ответа на этот вопрос зависит то, сколько специалистов можно привлечь, какие программы использовать и т.д.

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

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

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

Вводная

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

Следствие закона Паркинсона “девяносто-девяносто”:
Первые 90% кода отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки.
Из книги А.Купера “Психбольница в руках пациентов”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример разворота из ТЗ с описанием шаблона интерфейса (вайрфрейма).

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

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

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

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

Функционал

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

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

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

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

Требования

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

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

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

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

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

Прочее

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

Что дальше?

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

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

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

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

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

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

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

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

ГОСТ 34.602-89.

Юрий Шиляев

Юрий Шиляев, г. Минск. проектировщик сайтов, консультант. Директор минского офиса компании Artics Internet Solutions.