close

Вход

Забыли?

вход по аккаунту

?

как грамотно составить техническое задание на разработку

код для вставкиСкачать
© Алексей ЕФАНОВ, 1998-2013
тел. +7 (906) 215-3918
E-mail: montigomo@aport.ru
КАК ГРАМОТНО СОСТАВИТЬ
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
НА РАЗРАБОТКУ САЙТА?
Несмотря на то, что в последние годы число Интернет-сайтов растёт в геометрической
прогрессии, мне встречалось очень мало методических статей, посвящённых проектированию сайтов и созданию программ на русском языке, написанных русскоязычными авторами.
Вероятно, это можно объяснить тем, что большая часть программистов и разработчиков
ориентирована на работу за рубежом, да и отсутствие массового опыта создания информационных продуктов в нашей стране тоже сказывается. Решил исправить это и помочь
тем, кто ощутил перед собой проблему составления качественных документов на разработку сайта.
ОБЩИЕ ПОЛОЖЕНИЯ
Зачем составлять Техническое Задание (ТЗ) на сайт?
Во-первых, это необходимо для того, чтобы понять Исполнителю и Заказчику что необходимо сделать, для чего это необходимо сделать, кто будет этим
пользоваться, в какие сроки можно получить готовый продукт и сколько это
будет стоить. Или кратко: что? где? когда? и почём? :-)
А во-вторых, какую бы методику разработки вы не использовали, и какого
бы размера ни был ваш сайт, вы в любом случае столкнётесь с вопросом: “А
когда придёт время заканчивать работу, то как мы поймем, что мы её действительно закончили?” В разработке как ПО, так и любого сайта, частая проблема
— никто не видит конечной точки. С одной стороны можно сказать, что конечным видением проекта должен обладать проектный менеджер. Но если конечный продукт совпадёт с образом менеджера, но не совпадёт с ожиданиями клиента? А если за время проекта меняется 3-4 менеджера?
Следствие закона Паркинсона “девяносто-девяносто”: первые 90% кода
отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки. (Из книги А. Купера “Психбольница в руках пациентов”).
ТЗ — это не просто список требований, это документ. Если Договор регулирует процесс организационных и финансовых взаимоотношений, то ТЗ регулирует процесс разработки и конечный результат.
В этом случае не имеет никакого значения большой разрабатывается сайт
или малый. Проблема рассогласования ожиданий может возникнуть в независимости от объёма затраченных средств, вот только последствия могут быть
разными.
1
О ЧЁМ ЭТА СТАТЬЯ
Эта статья о том, что может пригодиться в процессе написания ТЗ на сайт,
а также о том, что будет уж точно необходимо и достаточно. Но эта статья не о
том, как надо создавать проектную документацию. В конечном итоге, главная
задача проектировщика не написать классный документ, а спроектировать сайт.
Хороший документ — лишь отражение подхода и уважения ко всем участникам
разработки.
ОГРАНИЧЕНИЯ
Во-первых. Когда я говорю о написании ТЗ, то имею в виду, конечно же,
каскадную методику разработки. В случае других вариантов (например, экстремальное программирование) составляются другие документы и, часто, по другим принципам.
Во-вторых. Стоит разделять ТЗ для малых и больших сайтов. Различия маленьких и больших проектов заключаются не в объёме документа на выходе, а в
процессе их разработки. Если у вас всего 4 человека в проектной группе, все
давно знают друг друга, то можно предположить отсутствие формализма. Если
же разработкой занимаются несколько “отделов”, а проектная команда состоит
из 10 и более сотрудников, то управлять этой ордой может только процесс. Процесс рождает формализацию, а формализм накладывает свой отпечаток на формат документации.
ВАЖНО! По сути, толщина документов зависит от сложности про­
цесса в больше степени, нежели от размеров проекта.
ДЛЯ КОГО СОЗДАЁТСЯ ТЗ?
ТЗ изначально создается для нескольких участников разработки:
1) Разработчики проекта (дизайнеры и программисты).
2) Проект-менеджер (руководитель проекта).
3) Клиент (заказчик).
4) Бюрократы (они могут не участвовать в проекте, но на них тоже надо
рассчитывать).
Оглядываясь на привёденные группы участников можно предположить,
что ТЗ в первую очередь должно отвечать на их вопросы. В идеале вся предпроектная документация в каскадном методе создается так, чтобы снять вопросы в процессе разработки.
НА КАКИЕ ВОПРОСЫ ОТВЕЧАЕТ ТЗ?
1. Для кого создается сайт и для чего?
Сайт создаётся для Заказчика и для его Клиентов (пользователей). Это
основные «потребители» будущего проекта. Наилучшим вариантом будет, если
в Техническом Задании вы опишите всех пользователей сайта, как внутренних,
так и внешних. Это описание может включать в себя маркетинговые, демографические, социальные данные, цели и задачи потенциальных пользователей, их
требования к будущему сайту.
2
2. Как будут решены задачи Заказчика и пользователей?
Собственно, если не ответить на этот вопрос, то написание ТЗ можно признать бумагомарательством. Это основной и весьма значимый вопрос! Ему может быть посвящена отдельная статья, поэтому останавливаться на нём подробно пока не будем.
3. Как будет проходить создание проекта?
Как я уже писал выше, ТЗ (а может и отдельный документ) иногда описывает процесс разработки проекта. Это совершенно необходимо, если принять во
внимание, что сайт может разрабатываться по отличной от принятой в компании
методики разработки, которая, как правило, не описывается ни одним документом. Можно сколько угодно долго терзать себя мечтами о стандартизации по
ISO, но что показать дотошному Заказчику? По ГОСТ предусмотрен отдельный
раздел “Этапы разработки системы”. В таком разделе можно не слишком подробно описать процесс.
4. Что будет приниматься на выходе?
ТЗ начинает разработку и ставит в ней точку. В идеале вы должны пройтись по всем пунктам ТЗ вместе с заказчиком, свериться с полученной системой
и спустя неделю сказать: “У-у-ф-ф. Вроде всё сделали!”.
ВАЖНО! ТЗ является средством верификации (проверки) выполненных работ.
ИЗ ЧЕГО СОСТОИТ ТЗ
1. Общая информация
Первая часть ТЗ содержит введение и общую информацию о документе и
проекте в целом. Введение надо написать один раз и на всю жизнь. :-) Как правило, там пишутся настолько абстрактные фразы, что в каждом новом
проекте надо лишь подправить пару слов.
Общая информация включает в себя:
­ Информацию о заказчике и исполнителе. Обязательно указание
ответственных лиц с каждой стороны. Указываются документы, на основании
которых производится разработка (как правило, подобным документом является
Договор), статус текущего документа и конфиденциальность.
­ Назначение проекта. Указывается, для чего будет использоваться
полученный продукт.
­ Цели создания и задачи, которые должен решить ресурс. С одной
стороны, это довольно короткий раздел, но по важности проработки он занимает
первое место. Если цели и задачи поставлены нечётко и неизмеримо, то может
быть довольно сложно им следовать.
­ Описание целевой аудитории проекта. Критично важная информация
для разработки хороших и правильных сайтов! Ясно, что информацию об
аудитории не только надо правильно собирать, но ещё важнее — уметь этой информацией пользоваться. Описание аудитории должно содержать не только
3
информацию, которую так любят маркетологи (демография, потребности,
сегментирование и т. п.), но также информация, которая пригодится дизайнерам
и проектировщикам: какие задачи решает пользователь, какие его цели в работе
с сайтом, что его привлекает. Алан Купер рекомендует описывать аудиторию
сайта не в виде безликой массы, а выделять персонажи — описывать
собирательный образ конкретных людей.
­ Термины и определения. В большом документе вы сможете употребить огромное количество терминов и сленговых выражений (профессиональных жаргонизмов), которые редко понимают специалисты по маркетингу или крупные руководители. Они могут читать этот документ, поэтому лучше предусмотреть для
них список определений. Я не тешу себя надеждой, что этот список хоть раз в
жизни кем-то будет прочтён, но зато я могу всегда сослаться на него.
Вводная общая часть документа содержит информацию о том, с чего мы
начинали при проектировании. Конечно, в процессе анкетирования специалистов Заказчика, информации накапливается на порядок больше, но читать её никому не интересно. Эта информация собирается в рамки проекта.
2. Рамки проекта
Если подальше отойти от своего дома и, обернувшись, взглянуть на него,
то издалека вы не сможете различить детали строения. Вы сможете подсчитать
окна, но не разберёте из какого они материала, вы сможете любоваться архитектурой дома, но сможете только догадываться о принципах его строительства,
вам не будут видны внутренности квартир или нацарапанное слово на входной
двери.
Рамки проекта — это примерно то же самое. Прочитав эту главу каждый
должен представлять, что будет получено в процессе разработки, но абсолютно
не вдаваясь в детали. Вы пишите, что на сайте будет работать “регистрация
пользователей”, но не пишите, как конкретно она будет устроена, или какие
поля должен будет заполнить пользователь.
Рамочный уровень проектирования в любом случае проходит любой
проект, поэтому записать его будет не лишним. Кроме того, большие шефы как
со стороны Разработчиков, так и стороны Заказчика очень не любят долго читать, но любят быть в курсе всего, что происходит. Этот раздел надо написать в
том числе и для них.
Рамки проекта пишутся в виде сценариев работы пользователей с сайтом
и описывают общую функциональность и интеракции с интерфейсом.
3. Информационная архитектура и интерфейс
Раздел, посвящённый информационной архитектуре (ИА) сайтов, не стандартизируется ни одним известным стандартом (автору такие пока не знакомы).
Но любой, кто разрабатывал сайты, понимает, что ИА — это чуть ли не главное,
что нужно знать для разработки сайта. ИА определят как будет выглядеть и работать сайт с пользователями.
4
Для описания ИА потребуется описывать сверху вниз:
1. Структуру сайта. Это так называемые высокоуровневые прототипы.
2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
3. Описание контента. Табличное описание содержания каждой страницы
сайта.
4. Структура (карта) сайта
Карта сайта выполняется графическим способом в одной из известных нотаций, например, Visio. Я советую именно рисовать карту сайта, потому как в
этом случае полученная структура получается наиболее наглядной и удобной в
дальнейшем использовании. С одной стороны, может показаться, что в виде
списка изобразить карту сайта будет куда проще, но когда вы сами задумаетесь
над связями различных областей сайта между собой, вы волей-неволей начнёте
рисовать квадратики на бумаге.
О том, как можно рисовать структуру сайта с помощью нотаций, используя Visio, написаны целые статьи, поэтому останавливаться на этом не будем.
Не забывайте присваивать номер каждой отдельной странице карты сайта.
Это потребуется на этапе описания контента.
ВАЖНО!
Не жалейте места. Старайтесь располагать блоки так, чтобы они
были отделены друг от друга. Это повысит читабельность карты.
Не мельчите. Прочитать текст, напечатанный 4 кеглем, в
принципе можно, но это уже причина для ненависти.
Выравнивайте «квадратики» страниц относительно друг друга,
выстраивая в линии. Это улучшит восприятие уровней вложенности
страниц.
Не пересекайте линии. Старайтесь избегать большого количества
пересечений линий связей. Если они пересекаются, то должны «перескакивать» одна над другой (кто занимался черчением функциональных схем в
университете, тот меня поймёт).
Подписывайте карту. Подпишите саму карту, а также отдельные
блоки. Это позволит меньше путаться в дальнейшем.
Почаще сохраняйте файл. Банально, но надо просто помнить об
этом. (Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чём не виноваты).
Карту сайта целесообразно помещать в раздел “Приложения”. Как правило, она настолько большая, что поместить её посреди ТЗ становится нереально.
5. Шаблоны страниц
На уровне карты сайта каждая страница представляет для нас только
«квадратик» на листе бумаги. Для дизайнера, верстальщика и программиста этого недостаточно, чтобы разработать сайт. Надо ещё знать наличие и расположение блоков информации и функций на страницах сайта. Поэтому мы переходим
5
к шаблонам сайта. В идеале каждый квадратик должен быть детализирован до
схемы каждой отдельной страницы. Это создание прототипа сайта. Использование прототипирования зависит от принятой схемы работы в компании-разработчике, но стоит признать, что это становится для Заказчика крайне недёшево.
Для упрощения выделяют ряд шаблонов интерфейса сайта, которые описываются вслед за картой сайта.
Описание шаблонов состоит из 3-х частей:
1. Перечень шаблонов — выявляются основные типы страниц и описывается их использование.
2. Типовой шаблон. Основные блоки — описываются основные блоки
страниц с целью уменьшения повторяемости информации.
3. Описание каждого шаблона согласно перечня - шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и
др.), а затем дополняются кратким описанием.
ВАЖНО! шаблоны интерфейса сайта не надо путать с шаблонами в
программной системе, на которой будет работать сайт. Шаблоны интерфейса описывают количество типовых страниц, достаточное для дизайна
сайта.
6. Описание контента
Самая долгая и нудная часть работы. Описание контента должно включать
в себя перечень всех страниц сайта с точным указанием размещаемого на каждой странице текста, картинок и т. п. Также, там указывается какой шаблон используется для данной страницы (см. выше). Я рекомендую использовать для
этого таблицу.
Далеко не всегда на момент написания ТЗ можно с уверенностью знать какой будет контент на сайте: точное количество информационных страниц, размещение графической информации, поэтому не думайте, что в данном разделе
приводится самое точное описание. Часто это не так. Но если вы опишите требуемый контент на данном этапе, то далее проект-менеджер на его основе сможет составить план поставки контента и оценить объём внесения этой информации на сайт. У клиента же всегда перед глазами будет перечень того, что ему потребуется подготовить и отредактировать.
Хорошее описание контента — это залог спланированной работы на этапе
запуска сайта и внесения информации.
7. Функциональные возможности
Описание функционала сайта в Техническом Задании — один из ключевых разделов. В особенности это касается сайтов с большим процентом программных работ: электронная коммерция, on-line-сервисы и т. п.
Хороший пример описания функционала даёт ГОСТ (ГОСТ 34.602-89).
Рекомендую придерживаться стандарта при описании функционала разрабатываемого в рамках сайта программ. Должны быть описаны: общая система, общие функциональности подсистем и модулей, взаимосвязь подсистем и модулей
между собой и, наконец, перечисление всех функций модулей с более или менее
подробным описанием их работы. Для каждого модуля должны быть расписаны
6
объекты, которые создаются или используются в работе программы.
Можно также описывать структуру базы данных, предварительные алгоритмы работы, но само по себе Техническое Задание этого не требует. По ГОСТ
подобные подробности должны описывать в дальнейших документах: эскизный
и технический проекты.
Иногда, при разработке крупных сайтов, приходится долго посидеть, чтобы описать весь функционал внешней и внутренней части сайта. Некоторые разработчики против такой детализации. Они считают, что функционал надо описывать поверхностно, чтобы “клиенту было понятно”. Полная ерунда! По опыту
могу сказать, что лишней детализации не бывает. В случае проблем в проекте
руководители проекта с обеих сторон становятся редкостными буквоедами! Они
вычитывают ТЗ вдоль и поперёк стараясь доказать свою правоту. Поэтому, если
функционал в ТЗ прописан общими словами, Клиент всё равно заставит сделать
то, что ему надо.
8. Требования
Отдельный раздел должен быть посвящён требованиям к проекту или
проекта к окружению. Требования, которые могут (и должны) быть описаны в
Техническом Задании на сайт, следующие:
• Технические требования к системе;
• Требования к персоналу;
• Требования к надёжности;
• Требования к эргономике и технической эстетике;
• Требования к защите информации от несанкционированного доступа
(НСД);
• Требования по сохранности информации при авариях;
• Требования к видам обеспечения;
• Требования к программным средствам;
• Требования к информационному обеспечению;
• Требования к техническим средствам;
Может быть также ряд специфических требований.
Все требования необходимо чётко формулировать и стараться не забыть
ничего из аспектов разработки вашего проекта.
Конечно, в небольших проектах нет необходимости прописывать все приведённые выше требования. Так, например, часто персонала в WEB-сайте вообще нет, поэтому такие разделы пропускают.
9. Прочее
В процессе ведения проектов вы можете заметить, что возникают ситуации, выходящие за рамки Технического Задания. Возможно, вы что-то упустили
или возникла нештатная ситуация, которую вы ранее не могли предусмотреть.
Всё это поможет вам в дальнейшем развивать документ, привнося в него новую
информацию, которая поможет использовать его в коммуникациях с Заказчиком
и разрешать проблемы.
7
ЧТО ДАЛЬШЕ?
ТЗ составлено, подписано и поступило в работу. Что дальше? Заканчивается ли работа с ним на этом этапе? Нет.
Проект далеко не всегда идёт по заранее запланированному пути. Мы стараемся что-то улучшить, изменить, часто меняются требования Заказчика. Техническое задание — это документ, а не скрижали. С изменением требований к
проекту должно меняться и Техническое Задание. Обычно это делается дополнительными документами со списком изменений. Естественно, они составляются только в том случае, если это действительно необходимо, что на практике
встречается редко. :-)
Также вы должны быть готовы, что в процессе глубокого изучения ТЗ всеми участниками разработки в процессе работы над проектом будут найдены
ошибки. Количество ошибок в большом документе прямо пропорционально его
объёму и обратно пропорционально времени, затраченному на его написание.
Так как времени постоянно не хватает, то следует ожидать, что ошибки в ТЗ будут возникать.
В ИТОГЕ
Итак, хорошее, вернее, грамотное ТЗ на сайт должно содержать в себе:
Общую информацию о документе и его составителях;
Цели и задачи сайта;
Описание пользователей (целевой аудитории) сайта, их цели и задачи;
Рамки проекта;
Информационная архитектура (ИА) сайта: карта сайта, шаблоны, описание интерфейса;
Описание контента сайта;
Описание функционала сайта;
Описание процесса и майлстоунов, если требуется;
Перечень всевозможных требований при разработке сайта и верификации полученной работы.
Возможно, кому-то данная статья покажется слишком длинной и неинтересной, мол, мы раньше это всё делали без всяких там ТЗ, так, прямо «на коленках». Но это всё было раньше, в эпоху развития и становления. А сейчас, в
эпоху жёсткой конкуренции, без детальной проработки каждого шага крайне
сложно создавать конкурентоспособный продукт.
Надеюсь, что данная информация будет полезна не только специалистам,
но и широкому кругу читателей.
***
Автор выражает благодарность своему другу и консультанту
Олегу Львовичу ГРОМОВЕНКО (г. Киев)
за помощь в написании данной статьи.
8
Документ
Категория
Типовые договоры
Просмотров
428
Размер файла
175 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа