Пишете техническое задание на разработку сайта? Никогда раньше этого не делали? Не уверены, что знаете, как правильно? Эта статья поможет Вам. Возможно, что-то Вы уже знаете, но что-нибудь интересное наверняка найдете.
Конечно, в небольших проектах нет необходимости прописывать все приведенные ниже требования. Так, например, часто персонала в веб-сайте вообще нет, поэтому такие разделы можно пропустить.
Общая информация о сайте
Общая информация включает в себя:
Информацию о заказчике и исполнителе.
- Обязательно указание ответственных лиц с каждой стороны. Указываются документы, на основании которых производится разработка. Как правило, подобным документом является договор. Статус текущего документа и конфиденциальность.
Назначение проекта.
- Указывается: для чего будет использоваться полученный продукт.
Цели создания и задачи, которые должен решить ресурс.
- С одной стороны это довольно короткий раздел, но по важности проработки он занимает первое место. Если цели и задачи поставлены не четко и неизмеримо, то может быть довольно сложно им следовать.
Описание аудитории проекта.
- Критично важная информация для разработки хороших и правильных сайтов. Ясно, что информацию об аудитории не только надо правильно собирать, но еще важнее это уметь этой информацией пользоваться.
- Описание аудитории должно содержать не только информацию, которую так любят маркетологи (демография, потребности, сегментирование и т.п.), но также информация которая пригодится дизайнерам и проектировщикам: какие задачи решает пользователь, какие его цели в работе с сайтом, что его привлекает. Алан Купер рекомендует описывать аудиторию сайта не в виде безликой массы, а выделять персонажи – описывать собирательный образ конкретных людей.
Термины и определения.
- В большом документе вы сможете употребить огромное количество терминов и сленговых выражений, которые редко понимают специалисты по маркетингу или крупные руководители. Они могут читать этот документ, поэтому лучше предусмотреть для них список определений. Я не тешу себя надеждой, что этот список хоть раз в жизни был прочтен, но зато я могу всегда сослаться на него.
Вводная общая часть документа содержит информацию о том, с чего мы начинали при проектировании. Конечно, в процессе анкетирования специалистов заказчика информации накапливается на порядок больше, но читать ее никому не интересно.
Рамки проекта
Рамочный уровень проектирования в любом случае проходит любой проект, поэтому записать его будет не лишним. Кроме того, большие шефы как со стороны разработчиков, так и стороны заказчика очень не любят долго читать, но любят быть в курсе всего что происходит. Этот раздел надо написать в том числе и для них.
Рамки проекта пишутся в виде сценариев работы пользователей с сайтом и описывают общую функциональность и интеракции с интерфейсом.
Пример: Вы пишите, что на сайте будет работать “регистрация пользователей”, но не пишите, как конкретно она будет устроена, или какие поля должен будет заполнить пользователь.
Если подальше отойти от своего дома и, обернувшись, в взглянуть на него, то издали вы не сможете различить детали строения. Вы можете подсчитать окна, двери, но не разберете из какого они материала, вы можете любоваться архитектурой и строением, но сможете только догадываться о принципах его строительства, вам не будут видны внутренности квартир или удобства домовладельца.
Структура сайта
Структура сайта (Карта сайта) выполняется графическим способом. Лучше именно рисовать карту сайта, потому как в этом случае полученная структура получается наиболее наглядной и удобной в дальнейшем использовании. С одной стороны может показаться, что в виде списка написать карту сайта будет куда проще, но когда вы сами задумаетесь над связями различных областей сайта между собой, вы волей неволей начнете чиркать квадратики на бумаге.
О том, как можно рисовать структуру сайта с помощью нотаций, используя Visio написаны целые статьи, поэтому останавливаться на этом не будем. Статьи написаны, правда, на английском, но вы легко сможете воспользоваться ими.
Не забывайте присваивать номер каждой отдельной странице карты сайта. Это потребуется на этапе описания контента.
Полезные советы при рисовании карты сайта:
- Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг то друга. Это поможет читабельности карты.
- Не мельчите. Прочитать текст, напечатанный в 4 px, в принципе можно, но это уже причина для злости.
- Выравнивайте “квадратики” страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
- Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны “перескакивать” одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
- Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
- Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.
Шаблоны страниц сайта
На уровне Структуры сайта каждая страница представляет для нас только “квадратик” на листе бумаги. Для дизайнера, верстальщика и программиста этого недостаточно, чтобы разработать сайт. Надо еще знать наличие и расположение блоков информации и функций на страницах сайта. Поэтому мы переходим к шаблонам сайта. В идеале каждый квадратик должен быть детализирован до схемы каждой отдельной страницы. Это прототипирование сайта. Использование прототипирования зависит от принятой схемы работы в компании-разработчике, но стоит признать, что это становится для заказчика крайне не дешево.
Для упрощения выделяют ряд шаблонов интерфейса сайта, которые описываются вслед за картой сайта.
Описание шаблонов состоит из 3х частей:
- Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
- Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
- Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.
P.S.: шаблоны интерфейса сайта не надо путать с шаблонами в программной системе, на которой будет работать сайт. Шаблоны интерфейса описывают количество типовых страниц, достаточное для дизайна сайта.
Описание контента сайта
Самая долгая и нудная часть работы в техническом задании. Описание контента должно включать в себя перечень всех страниц сайта с точным указанием размещаемого на каждой странице текста, картинок и т.п. Также там указывается какой шаблон используется для данной страницы (см. выше). Я рекомендую использовать для этого таблицу.
Далеко не всегда на момент написания ТехЗадания можно с уверенностью знать какой будет контент на сайте: точное количество информационных страниц, размещение графической информации, поэтому не думайте, что в данном разделе приводится самое точное описание. Часто это не так. Но если вы опишите требуемый контент на данном этапе, то далее проект-менеджер на его основе сможет составить план поставки контента и оценить объем внесения этой информации на сайт. У клиента же всегда перед глазами будет перечень того, что ему потребуется подготовить и отредактировать.
Хорошее описание контента залог успешной работы на этапе запуска сайта и внесения информации.
Функциональность
Описание функционала сайта в техническом задании один из ключевых разделов. В особенности это касается сайтов с большим процентом программных работ: электронная коммерция, онлайн-сервисы и т.п.
Хороший пример описания функционала дает ГОСТ. Рекомендую держаться стандарта при описании функционала разрабатываемого в рамках сайта программ.
Должны быть описаны:
- общая система;
- общие функциональности подсистем и модулей;
- взаимосвязь подсистем и модулей между собой;
- перечисление всех функций модулей с более или менее подробным описанием их работы;
Для каждого модуля должны быть расписаны объекты, которые создаются или используются в работе программы.
Можно также описывать структуру базы данных, предварительные алгоритмы работы, но само по себе техническое задание этого не требует. По ГОСТу подобные подробности должны описывать в дальнейших документах: эскизный и технический проекты.
Иногда при разработке крупных сайтов приходится долго посидеть, чтобы описать весь функционал внешней и внутренней части сайта. Некоторые разработчики против такой детализации. Они считают, что функционал надо описывать поверхностно, чтобы “клиенту было понятно”. Полная ерунда! Лишней детализации не бывает. В случае проблем в проекте менеджеры проекта с обоих сторон становятся редкостными буквоедами! Они вычитывают Тех.Задание вдоль и поперек стараясь доказать свою правоту. Поэтому если функционал в Тех.Задания прописан общими словами клиент все равно заставит сделать то, что ему надо.
Требования
Отдельный раздел должен быть посвящен требованиям к проекту или проекта к окружению.
Требования, которые могут быть описаны в Тех. Задании:
- Технические требования к системе;
- Требования к персоналу;
- Требования к надежности;
- Требования к эргономике и технической эстетике;
- Требования к защите информации от НСД;
- Требования по сохранности информации при авариях;
- Требования к видам обеспечения;
- Требования к программным средствам;
- Требования к информационному обеспечению;
- Требования к техническим средствам;
Все требования необходимо четко формулировать и стараться не забыть ничего из аспектов разработки вашего проекта.
Конечно, в небольших проектах нет необходимости прописывать все приведенные выше требования. Так, например, часто персонала в веб-сайте вообще нет, поэтому такие разделы пропускают.
Прочее
В процессе ведения проектов вы можете заметить, что возникают ситуации выходящие за рамки технического задания. Возможно, вы что-то упустили, или возникла нештатная ситуация, которую вы ранее не могли предусмотреть. Все это поможет вам в дальнейшем развивать документ, привнося в него новую информацию, которая поможет использовать его в коммуникациях с заказчиком и разрешать проблемы.
Что дальше?
Проект далеко не всегда идет по заранее запланированному пути. Мы стараемся что-то улучшить, изменить, часто меняются требования заказчика. Техническое задание это документ, а не скрижали. С изменением требований к проекту должно меняться и техническое задание. Обычно это делается дополнительными документами со списком изменений. Естественно, они составляются только в том случае если это действительно необходимо, на практике встречается редко.
Также вы должны быть готовы, что в процессе глубокого изучения Тех.Задания всеми участниками разработки в процессе работы над проектом будут найдены ошибки. Количество ошибок в большом документе прямо пропорционально его объему и обратно пропорционально времени затраченному на его написание. Т.к. времени постоянно не хватает, следует ожидать, что ошибки в Тех.Задании будут возникать.
Итог: хорошее Тех.Задание на сайт должно содержать в себе:
- Общую информацию о документе и его составителях;
- Цели и задачи сайта;
- Описание пользователей сайта, их цели и задачи;
- Рамки проекта;
- Информационная архитектура сайта: карта сайта, шаблоны, описание интерфейса;
- Описание контента сайта;
- Описание функционала сайта;
- Описание процессов если требуется;
- Перечень всевозможных требований при разработке сайта.
Надеюсь, что информация будет полезна широкому кругу читателей. 