Как правильно составить техническое задание программисту. Письмо программисту (ТЗ или тех задание)! Как правильно написать техническое задание для программистов

Зачастую на готовый сайт требуется добавить какой-нибудь полезный сервис. Готовые решения вас не устраивают, и вы нанимаете программиста. Но как правильно составить техническое задание (ТЗ), чтобы потратить меньше времени и денег?

Когда вы ищете программиста -фрилансера, то лучше сразу сузить круг поиска. Пишите короткое объявление по типу:

«Нужен программист, который добавит функцию Х на готовый сайт на Битрикс»

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

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

1. Сроки выполнения работы, а также ситуации, когда дедлайн можно подвинуть.

2. Способ и вариант оплаты.

3. Правки и штрафы.

4. Подробное описание вашего видения того, что должно получиться.

5. Техническая информация.

6. Тестирование.

Первая тройка есть во всех договорах подряда, а последнюю стоит разобрать подробнее.

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

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

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

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

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

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

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

Главное, при составлении ТЗ для фрилансера-программиста быть предельно скрупулезным, также как во время составления ТЗ для разработки сайта. Лучше все заранее продумать, чтобы потом не спотыкаться во ходе работы и не терять время с деньгами. Часто люди сталкиваются с проблемой, когда фрилансеры предоставляют услуги крайне низкого качества, не укладываются в поставленные сроки или попросту перестают отвечать на сообщения и звонки. Мы не рекомендуем работать без подписания договора, в котором будут обозначены обязанности обоих сторон. А такие сложные и масштабные проекты как: разработка крупного интернет магазина, портала, сайта для гос.учреждения - точно лучше заказывать у профессионалов.

Пример плохого т/з:

нужен калькулятор стоимости кухни под заказ как у site.ru

В моем варианте:

Задание: разместить калькулятор для расчета стоимости кухни под заказ.

Формула расчета кухни s*(a+b)+c=x, где s - цена погонного метра, a и b - длина стен вдоль которых стоит кухня, с - стоимость доп. услуг.

Каждый параметр калькулятора в скрипте отметить комментарием.

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

Значит у вас нет четкого и понятного технического задания (т/з).

Я помогу вам изложить все ваши сумбурные пожелания в т/з которое поймет любой исполнитель.

Пример плохого т/з:

нужен калькулятор стоимости кухни под заказ как у site.ru

В моем варианте:

Задание: разместить калькулятор для расчета стоимости кухни под заказ.

Формула расчета кухни s*(a+b)+c=x, где s - цена погонного метра, a и b - длина стен вдоль которых стоит кухня, с - стоимость доп. услуг.

Каждый параметр калькулятора в скрипте отметить комментарием.

В результате расчета пользователь видит 5 цен для кухонь из различных материалов, напротив каждой цены - кнопка "заказать".

При нажатии на кнопку "заказать" всплывает форма заказа с 1 полем "телефон" в формате +7 (...) ... -. . -. . и кнопка "отправить".

При нажатии на кнопку "отправить" проверяем корректно заполненный телефон, если телефон заполнен некорректно - делаем подсветку поля красным цветом, рядом добавляем сообщение "Проверьте телефон", если проверка прошла успешно, отправляется письмо на почту и показываем всплывающее окно с уведомлением "Спасибо, заказ принят!" , которое исчезает через 5 сек после появления.

В жизни очень часто бывает так, что человек не может объяснить, что хочет, даже в бытовых вещах. Когда дело доходит до объяснения программисту своих «хотелок», человек просто впадает в ступор.

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

Зачем нужно техническое задание?

Любые , в идеале, должны сопровождаться техническим заданием. Это, во-первых, четкое определение задачи, сроков и метода выполнения. Во-вторых, это документ, с помощью которого решаются все спорные моменты в будущем. Писать ТЗ или нет — дело, конечно, Ваше, лично мне ТЗ облегчает работу и общение с клиентом.

Получите 267 видеоуроков по 1С бесплатно:

Что должно содержать в себе техническое задание?

Тех. задание обязательно должно содержать в себе:

• цель — задача, которую мы решим, реализуя данное ТЗ;
• описание — краткое изложение предстоящих доработок;
• способ реализации — подробное описание методов решения цели. В этом пункте необходимо описать все нюансы задачи на языке программиста: какие , создаем/редактируем, как должен выглядеть интерфейс и т.д. Если Вы не владеете «языком программиста», но «что-то слышали», лучше не пытаться писать на техническом языке — получается достаточно весело. Описание должно быть однозначным и не вызывать вопросов. Также может содержать в себе пример реализации подобного решения в другой сфере;
• оценка работы — очень важный пункт, описание трудозатрат.

Также существуют государственные стандарты к написанию ТЗ — ГОСТы. На практике мало где применяются, но бывает, заказчик настаивает на этом.

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

Примеры и образцы ТЗ для 1С

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

Вступление

Все слышали про pre poduction , но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания - еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования . А вот как были достигнуты эти результаты? - загадка во тьме .

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

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

Самое важное:

1. Четкое понимание конечного результата. (Контроль качества.)
2. Сроки исполнения.

Зачем нужна документация:

1. Экономия времени на коммуникациях. (Один раз написать, вместо того чтобы 100 раз пересказывать, путаясь в показаниях.)
2. Способ увидеть, как будет выглядеть готовый проект.
3. Анализ и выявление проблем еще на стадии планирования. (Чем раньше будет выявленна архитектурная ошибка - тем дешевле ее исправить)
4. Фиксирование принятых решений. (Точные данные, вместо разрозненных слухов разной степени свежести.)
5. Планирование работ.

Какие бывают документы:

1. Концепция («Про че игра?»)
2. Спецификация (Что мы хотим получить?)
3. Техническое задание (Как это устроено - именно о нем будет идти речь.)
4. План работ (Как мы это будем делать.)

Кто участвует в обсуждении ТЗ:

1. Геймдизайнер (Написание документации)
2. Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
3. Программист (Оценка объемов работ.)

Требования к оформлению документации:

1. Форматирование. (Легко напечатать и приятно читать/держать в руках)
2. Выделение ключевых фраз. (Для чтения документа по диагонали)
3. Составление списков. (Вместо сплошного текста)
4. Разбиение длинных списков по группам. (По три пункта в группе)
5. Многократные повторения. (Избегать ссылок по документу)
6. Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
7. Оглавление, список документов, история изменений. (Для поиска по документации/версиям)

Требования к содержанию ТЗ

1. Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
2. Никаких общих слов типа:
   • все возможные варианты
   • карта придумывается компьютером
   • взаимодействие различных объектов
   • после всех действий и т.д.
3. Все названия видов сущностей(классов) должны иметь:
   • русское название (для игрока)
   • английское (для кода)
   • краткое описание (расшифровка/подсказка/комментарий)
4. Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
5. Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
6. Все что можно измерить, должно быть измерено.
   • размеры картинки в пикселях и байтах
   • количество столбцов и клеток в таблице
   • количество символов в текстовом поле
   • количество оружия на уровень
   • время сессии и т.д.

Главные требования к результату работы программиста:

1. Гибкость системы к изменениям. (Динамические требования.)
2. Автоматический сбор данных об ошибках. (Обратная связь.)
3. Простота запуска и настройки заказчиком. (Демонстрация результата.)

Первый этап написания ТЗ:

1. База данных (метаданные)
   • список типов объектов
   • характеристики объектов
   • связь/зависимость между объектами
2. Бизнес-процессы (полный игровой цикл)
   • список процессов (сценарии работы)
   • список функционала (что должен уметь)
   • список ожидаемых изменений (что вообще может быть)

Второй этап написания ТЗ:

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

Третий этап написания ТЗ:

1. Исследование необходимых технологий
   • Список требований к каждой технологии
   • Описание тестов/демонстрации работы каждой технологии
   • Список будущих требований/возможных проблем (что дальше?)
2. Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
3. Список небходимых инструментов для работы с контентом (редактор карт, админка квестов,).
4. Расстановка приоритетов по задачам.
5. Требования к первой работающей сборке (что должен уметь первый прототип).
6. Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)

Сопровождение документации

1. Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
2. Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
3. Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
4. Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
5. После каждого цикла планирования - проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно .)
6. Составить список неудобных вопросов . Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
7. Предоставлять краткие инструкции конечным исполнителям . Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
8. Признак мастерства : каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.

Срезание углов

1. Проект в 2-3 месяца.
2. Команда из 2-3 человек.
3. Ограниченный бюджет. (Он всегда ограничен)
4. Нет требований к документации. (Никто не знает как надо делать)
5. От нее нет никакой пользы. (Никогда не использовали документацию)

Первые шаги

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

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

Вводная

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функционал

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

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

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

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

Требования

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

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

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

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

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

Прочее

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

Что дальше?

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

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

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

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

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

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

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

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