Надеюсь, что эта статья пригодится для тех, кто ощутил перед собой двоякость составления качественных документов наразработку сайта. Документов, которые были бы немного полезны.Для чего составлять техническое задание (ТЗ) на сайт?
Какую бы методику разработки вы не использовали, и какого бы размера ни был ваш сайт, вы в любом случае столкнетесь с вопросом: “А когда мы будем завершать работу, то как мы поймем, что мы ее закончили?” Конечно, конечным видением проекта должен обладать проектный менеджер. Но если готовый сайт соответствует представлениям менеджера, но не совпадет с ожиданиями клиента? А если за время проекта менялось несколько менеджеров?
Следствие закона Паркинсона “девяносто-девяносто”:
Закон гласит, что первые 90% кода отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки. Этот закон подтверждён практически.
ТЗ является документом, а не просто перечень требований. Если контракт регулирует процесс организационных и денежных прав и обязанностей сторон, то ТЗ регулирует процесс разработки сайта или чего-либо и конечный итог.
В этом случае не имеет никакого значения размер создаваемого интернет сайта, он может быть большим, либо малым. Неувязка рассогласования ожиданий может показаться в независимости от размера затраченных средств, вот лишь последствия могут быть различными.
Зачем нужна эта статья?
Это может пригодиться в процессе подготовки перед написанием ТЗ на сайт, а также рекомендации чего не стоит делать, а что сделать лучше. Но тут совсем не о том, как нужно писать проектную документацию. В конечном итоге основная задача разработчика проекта не написать классный документ, а спроектировать и разработать сайт. Хороший документ является лишь отражением подхода, а также уважения ко всем участникам разработки сайта.
Постоянно когда я рассуждаю о написании ТЗ, то имею в виду, многоступенчатую методику разработки сайта. Стоит разделять ТЗ для малых и огромных сайтов. Различия маленьких и огромных проектов заключаются не в объеме документа на выходе, а в процессе их разработки. Если у вас немного человек в проектной группе, то наверняка они давно знают друг друга, и можно предположить отсутствие формализма. Но если бывает, что разработкой сайта, занимаются большая организация, состоящая из нескольких отделов, а проектная команда состоит из большого количества служащих, то управлять данным коллективом может лишь процесс. Но он приводит к появлению формализации, а формализм накладывает свой отпечаток на формат документации.
Тут срабатывает ещё один закон, который гласит, что толщина документов зависит от трудности процесса в больше степени, чем от размеров проекта.
Начальный этап. ТЗ создается для участников разработки:
1. Разработчики проекта (дизайнеры и программисты).
2. Проект-менеджер.
3. Клиент.
4. Бюрократы (они могут не участвовать в проекте, но от них зависит документооборот, поэтому на них тоже нужно рассчитывать).
Нужно предполагать, что ТЗ в первую очередь обязано отвечать на вопросы тех, кто разрабатывает сайт. В оптимальном варианте вся предпроектная документация в каскадном способе создается так, чтоб снять вопросы в процессе разработки сайта.
Для кого создается сайт и для чего?
Сайт создается для Заказчика и для его клиентов. Это основные пользователи создаваемого проекта. Наилучшим вариантом будет, если в Техническом задании вы опишите всех пользователей сайта, как внутренних, так и внешних. Это описание может включать в себя маркетинговые, демографические, социальные данные, цели и задачи вероятных пользователей сайта, их требования к будущему сайту.
Как будут решены задачи заказчика и пользователей сайта?
Первый, основополагающий вопрос, без ответа на него написание ТЗ можно признать совершенно не нужным. Эту вопросу может быть посвящена целая отдельная статья, поэтому останавливаться на нем подробно мы не будем.
Как будет проходить создание проекта сайта?
Как уже было описано выше, ТЗ в некоторые моменты времени обрисовывает процесс разработки проекта сайта. Можно упорно ждать, когда ТЗ станет отвечать всем стандартам по ISO, но что показать дотошному заказчику? В ГОСТе, на подобный случай, существует отдельный раздел “Этапы разработки системы”. В этом разрезе можно не совершенно подробно обрисовать процесс.
Что должно быть на выходе?
Самое оптимальное, если вы обязаны пройтись по всем пунктам ТЗ совместно с заказчиком, свериться с полученной системой и спустя неделю сказать: “Вроде всё получилось, как вы хотели”.
Что делать дальше для дальнейшего запуска проекта?
На этот вопрос заказчик должен получить ответ. Конечно, это уже консалтинг, но почти во всех случаях его нужно провести в процессе проектирования. Необходимо спланировать количество рабочих мест, требуемое программное и аппаратное обеспечение и т.д.
Из чего состоит ТЗ
У меня ушел целый час на принятие решения: обрисовывать состав ТЗ в виде конкретной четкой структуры либо просто поведать о том, что обязано там быть. Вспомнив все свои ТЗ, я пришел к выводу, что структура этого документа так часто изменялась в зависимости от целого ряда факторов, что четкое указание структуры будет напоминать плохой совет по выбору костюма. Представьте, что вам рекомендуют что-то надеть на вечер, даже не осведомившись, куда вы направляетесь.
Общественная информация
Первая часть ТЗ содержит введение и общую информацию о документе и проекте в целом. Введение нужно написать один раз и на всю жизнь. Как правило, там пишутся так абстрактные фразы, что в каждом новом проекте нужно только подправить пару слов. Общественная информация включает в себя:
Непременно указание ответственных лиц с каждой стороны. Указываются документы, на основании которых делается разработка сайта. Как правило, схожим документом является контракт. Статус текущего документа и конфиденциальность.
Указывается: для чего будет употребляться проектируемый сайт.
С одной стороны это достаточно миниатюрный раздел, но по значимости проработки он занимает первое место. Если цели и задачи поставлены нечетко и неизмеримо, то может быть достаточно трудно им следовать.
Критично принципиальная информация для разработки не плохих и правильных страниц сайта. Ясно, что информацию об аудитории не только нужно верно собирать, но еще важнее это уметь данной информацией пользоваться.
Описание аудитории обязано содержать не только информацию, которую так любят маркетологи, но также информацию, которая пригодится дизайнерам и проектировщикам: какие задачи решает пользователь сайта, какие его цели в работе с сайтом, что его привлекает.
В большом документе вы сможете употребить большущее количество определений и сленговых выражений, которые редко соображают мастера по маркетингу либо крупные руководители. Они могут читать этот документ, поэтому лучше предугадать для них перечень определений. Я не тешу себя надеждой, что этот перечень хоть раз в жизни был прочтен, но зато я могу постоянно сослаться на него.
Вводная общественная часть документа содержит информацию о том, с чего мы начинали при проектировании. Естественно, в процессе анкетирования профессионалов заказчика информации накапливается на порядок больше, но читать ее никому не интересно.Рамки проекта
Если подальше отступить от собственного дома и, обернувшись, взглянуть на него, то издали вы не сможете различить детали строения. Вы можете подсчитать окна, но не разберете из какого они материала, вы можете наслаждаться архитектурой (”любоваться”, естественно, можно не каждым домом), но сможете лишь догадываться о принципах его стройки, вам не будут видны внутренности квартир либо нацарапанное слово на входной двери.
Рамки проекта приблизительно то же самое. Прочитав эту главу каждый обязан представлять, что будет получено в процессе разработки, но полностью не вдаваясь в детали. Вы пишите, что на сайте будет работать “регистрация пользователей”, но не пишите, как непосредственно она будет устроена, либо какие поля обязан будет заполнить пользователь сайта. Рамочный уровень проектирования сайта в любом случае проходит хоть какой проект, поэтому записать его будет не лишним. Не считая того, огромные шефы как со стороны разработчиков, так и стороны заказчика совсем не любят долго читать, но любят быть в курсе всего что происходит. Этот раздел нужно написать в том числе и для них. Рамки проекта пишутся в виде сценариев работы юзеров с сайтом и обрисовывают общую функциональность и интеракции с интерфейсом.
Информационная архитектура и интерфейс сайта
Раздел посвященный информационной архитектуре (ИА) страниц не стандартизируется ни одним известным прототипом (автору такие пока не знакомы). Но хоть какой, кто разрабатывал сайты, соображает, что ИА это чуть ли не основное, что необходимо знать для разработки сайта. ИА определят как будет смотреться и работать сайт с юзерами. Для описания ИА будет нужно обрисовывать сверху вниз:
Структура сайта
Карта сайта выполняется графическим методом. Я рекомендую рисовать карту сайта, потому как в этом случае полученная структура выходит более наглядной и удобной в дальнейшем использовании. С одной стороны может показаться, что в виде перечня написать карту сайта будет намного проще, но когда вы сами задумаетесь над связями разных областей сайта меж собой, ничего не останется, как начнёте рисовать карандашом квадратики на бумаге.
Старайтесь присваивать номер каждой отдельной странице карты сайта. Это будет нужно на этапе описания контента.
Полезные рекомендации при рисовании карты сайта:
Шаблоны страниц
На уровне карты сайта совсем не важно какая страница представляет для нас лишь какую-либо отметку на листе бумаги. Для дизайнера, верстальщика и программиста этого мало, чтоб сделать сайт. Нужно еще знать наличие и размещение блоков информации и функций на страницах сайта. Поэтому мы переходим к шаблонам сайта. Оптимально каждая отметка должна быть детализирован до схемы каждой отдельной страницы. Для упрощения выделяют ряд шаблонов интерфейса сайта, которые описываются вслед за картой сайта.
Описание шаблонов состоит из 3х частей:
Сразу отмечу, что шаблоны интерфейса сайта не нужно путать с шаблонами в программной системе, на которой будет работать сайт. Шаблоны интерфейса обрисовывают количество типовых страниц, достаточное для дизайна сайта.Описание контента
Очень долгая и нудная часть работы. Описание контента обязано включать в себя список всех страниц сайта с точным указанием размещаемого на каждой странице текста, картинок и т.д. Также там, указывается какой шаблон употребляется для данной страницы. Рекомендую употреблять для этого таблицу.
Далеко не постоянно на момент написания ТЗ можно с уверенностью знать какой будет контент на сайте: точное количество информационных страниц, размещение графической информации, поэтому не думайте, что в данном разделе приводится самое точное описание. Часто это не так. Но если вы опишите требуемый контент на данном этапе, то далее проект-менеджер на его базе сможет составить план поставки контента и оценить размер внесения данной информации на сайт. У клиента же постоянно перед глазами будет список того, что ему будет нужно приготовить и отредактировать. Не плохое описание контента залог спланированной работы на этапе запуска сайта и внесения информации.
Функционал
Описание функционала сайта в техническом задании один из ключевых разделов. В особенности это касается страниц с огромным процентом программных работ: электронная коммерция, онлайн-сервисы и т.д.
Хороший пример описания функционала дает ГОСТ. Рекомендую держаться эталона при описании функционала разрабатываемого в рамках сайта программ. Обязаны быть описаны: общественная система, общие функциональности подсистем и модулей, взаимосвязь подсистем и модулей меж собой и, наконец, перечисление всех функций модулей с более либо менее подробным описанием их работы. Для каждого модуля обязаны быть расписаны объекты, которые создаются либо употребляются в работе программы.
Можно также обрисовывать структуру базы данных, предварительные методы работы, но само по себе техническое задание этого не просит. По ГОСТу подобные подробности обязаны обрисовывать в дальнейших документах: эскизный и технический проекты. Время от времени при разработке больших страниц приходится долго посидеть, чтоб обрисовать весь функционал наружной и внутренней части сайта. Некие создатели против таковой детализации. Они считают, что функционал нужно обрисовывать поверхностно, чтоб “клиенту было понятно”. Полная ерунда! По опыту могу сказать, что лишней детализации не бывает. В случае трудностей в проекте менеджеры проекта с обоих сторон стают редкостными буквоедами! Они вычитывают ТЗ вдоль и поперек стараясь доказать свою правоту. Поэтому если функционал в ТЗ прописан общими словами клиент все равно заставит сделать то, что ему нужно.
Требования
Отдельный раздел обязан быть посвящен требованиям к проекту либо проекта к окружению. Требования, которые могут быть описаны в техническом задании на сайт:
Может быть также ряд специфичных требований. Все требования нужно верно формулировать и стараться не забыть ничего из параметров разработки вашего проекта. Естественно, в маленьких проектах нет необходимости прописывать все приведенные выше требования. Так, к примеру, часто персонала в интернет-сайте вообще нет, поэтому такие разделы пропускают.Прочее
В процессе ведения проектов вы можете заметить, что появляются ситуации, выходящие за рамки технического задания. Может быть, вы что-то упустили, либо появилась нештатная ситуация, которую вы ранее не могли предугадать. Все это поможет вам в дальнейшем развивать документ, привнося в него новенькую информацию, которая поможет употреблять его в коммуникациях с заказчиком и разрешать трудности.
Что дальше?
ТЗ составлено, подписано и поступило в работу. Что дальше? Заканчивается ли работа с ним на этом этапе? Нет. Проект далеко не постоянно идет по заблаговременно запланированному пути. Мы стараемся что-то улучшить, изменить, часто изменяются требования заказчика. Техническое задание это документ, а не скрижали. С конфигурацией требований к проекту обязано изменяться и техническое задание. Традиционно это делается дополнительными документами со списком конфигураций. Естественно, они составляются лишь в том случае если это вправду нужно, на практике встречается редко. Также вы обязаны быть готовы, что в процессе глубочайшего исследования ТЗ всеми участниками разработки в процессе работы над проектом будут найдены ошибки. Количество ошибок в большом документе прямо пропорционально его размеру и обратно пропорционально времени, затраченному на его написание. Времени постоянно не хватает, следует ждать, что ошибки в ТЗ будут возникать.
Подведём итог: хорошее ТЗ на сайт обязательно должно содержать в себе:
Надеюсь, что информация будет полезна широкому кругу читателей.
автор:Юрий Шиляев