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

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

Теперь у вас есть все возможности получить сбалансированное ТЗ. :)

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

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

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

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

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

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

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

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

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

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

Наша компания использует разработанные шаблоны ТЗ с описанием специальных терминов и перечнем технических нюансов выпускаемого продукта: основные требования к структуре верстки страниц, к системе администрирования (90% наших проектов разрабатываются на CMS 1С Bitrix).

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

Для представления полной картины перед финальным утверждением ТЗ с клиентом утверждается динамический прототип сайта, который отображает функционал сайта и совпадает с ТЗ.

Начнём с того, что такое ТЗ. Один считает это общим описанием сайта — цели/задачи, требования, структура, основные возможности, — которое делает обычная веб-студия. Другой полагает, что это требования/видение заказчика.

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

Бывает, что программисты получают вводные и пишут ТЗ сами, но тут есть проблема: пишут они на своём языке, не для клиента, который в результате ничего не понимает и Будда знает что подписывает. А дальше вы понимаете...

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

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

1. Прототип проекта. Поскольку это визуальные картинки, связанные между собой, клиенту достаточно просмотреть их и понять, что именно ему предлагается.
    
2. Описание функционала. Дается человеческим и доступным заказчику языком. Как правило, он эту часть вполне осиливает :)
    
3. Описание требований к дизайну, верстке, хостингу и тп. Если у клиента есть четкие пожелания (чтобы была адаптивная верстка, чтобы работало в старых браузерах, чтобы была мобильная версия), он дает комментарии.
    
4. Описание структуры данных. Да, эту часть редко кто-то читает :) Она тяжела для понимания, но важна в случае конфликтов.

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

Это да, не читают. И не только клиенты, но и разработчики. Потому что не всякий документ — «толстый» он или «короткий» — можно назвать техническим заданием.

Чтобы понять, что должно быть в ТЗ, определимся, кому оно нужно и для чего.

ТЗ нужно бизнесу, который запускает IT-проект, чтобы озадачить разработчиков и получить предсказуемый результат.

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

Правильное ТЗ поможет ответить на эти вопросы. В итоге клиент должен получить:

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

Только после этого можно озадачивать разработчиков и стартовать проект.

Язык ТЗ должен быть понятен клиенту, разработчикам, маркетологам — короче, всем участникам. Зачем? Чтобы читали, думали и делали.

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

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

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

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

Стандартов по написанию ТЗ на разработку сайтов нет, и искать их в Рунете не стоит. За 7 лет разработки ТЗ, я для себя определил то, что обязательно должно содержать любое ТЗ. Во-первых, это базовые требования: под какие версии браузеров планируется разработка сайта, адаптивность, тип дизайна, информация про CMS и многое другое. Далее требуется расписать карту сайта, отдельно описать главную страницу, и разработать её варфрейм, чтобы заказчику легче воспринималось, то, что вы написали. Во-вторых, требуется описать все рубрики по заранее разработанной карте сайта. Это же относится к модульным страницам, описываются все поля, чек-боксы, механика их модерации. Кроме стартовой страницы желательно разработать варфреймы посадочных страниц сайта. Пилотную версию ТЗ утверждайте с Заказчиком, чтобы не было недопонимания. На базе утвержденного ТЗ составляется детальная смета работ, а это еще одна сторона медали, ради чего разрабатывается ТЗ.

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

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

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

Примеры прототипов : http://wtolk.ru/demo/cmsmagazine/main.png

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

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

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

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