Быть или не быть? Создавать или не создавать? Написать на коленке или заказать серьезную проработку документа у меня, или у кого-то другого, в котором будут описаны все нюансы?

Встретил на просторах сети отличное выражение: "Без внятного ТЗ результат - ХЗ". Не знаю, кто автор, но ему низкий поклон за такую тонкую формулировку.

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

Допустим, вы решили описать документ, который нарекли громким словосочетанием "Техническое задание" и описали все страницы сайта, все функциональные блоки на страницах, возможно, даже в 2-х вариантах - авторизованного пользователя и для анонима. Супер! Любой проектировщик вам будет благодарен, т.к. вы создали введение для Технического задания:). 

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

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

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

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

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

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

Углубляемся. Остановимся на основном функционале интернет-магазина - странице оформлении заказа. Команда разработчиков 1С-Битрикс создали очень продуманный и очень сложный для кастомизаций механизм шаблон оформления заказа, но если вы все же решили создать свой собственный шаблон, то это должно быть обосновано. В механизме оформления заказа, как и в любой другой форме, получающей информацию от пользователей, должно быть большое количество проверок на корректность внесенных данных, многие данные должны приводиться в корректный вид системой в автоматическом режиме, но все же бывают моменты, когда корректные данные может выбрать только пользователь. Пользователю нужно! сообщить о том, что данные введены не корректно, или просто убрать некорректные данные? а если выдать сообщение о том, что данные не корректные, то где его показать, как его показать, что сделать с данными, введенными пользователем, что делать дальше? 

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

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

Основные разделы, которые должно содержать техзадание:

1. Введение. Тут должна быть описана основная задача сайта. Каждый, кто просмотрит этот мини-раздел, должен понимать, что должно быть результатом посещения пользователем данного сайта и с помощью каких инструментов. Т.е. если это интернет магазин, то основной идеей данного раздела должно быть что-то вроде: покупатель заходит на сайт и покупает товар сайта или через покупку в 1 клик (когда вся покупка передается менеджерам), или через добавление товаров в корзину и полноценное оформление заказа.
2. Раздел с описанием дизайна сайта. Тут должны быть описаны все функциональные составляющие страниц, прописано разделение дизайна на шапку, подвал и рабочую область, прописаны все шрифты, цветовые схемы ... Наличие такой информации в техзадании является хорошей палочкой-выручалочкой не только при верстке дизайна сайта, но и для оптимизации стилей. Также, при необходимости доработок/переработок дизайна сайта, будет проще найти где именно вносить правки, а это - сокращение трудозатрат на редизайн.
3. Основной раздел сайта с описанием функционала. Вот это, наверное, самый важный раздел. Если предыдущий раздел может и отсутствовать, хотя это не желательно, то без этого раздела не может быть ТЗ, в принципе. Тут мы описываем каждую страницу сайта, начиная с главной (хотя в разработке главная делается самой последней, т.к. она строится на базе всех остальных, поэтому и в данном разделе главная страница должна идти самой последней). Если для создания данной страницы нужна какая-то сущность в базе данных - описание страницы начинаем с описания структуры данной сущности, чтобы в хронологическом порядке все шло верно: сначала создали инфоблок, настроили его, прописали сео-шаблоны (если нужно), настроили урл-адреса для показа сущностей, потом создали раздел, описали все поля раздела, потом создали элемент инфоблока, описали все поля и только после этого перешли к описанию страницы с разделами, с разделом, с элементом, а после этого - уже описывать функционал страниц: что должно происходить по клику на тот или иной объект, куда должны осуществляться переходы с ссылок и т.д. и т.п.
4. Далее должны быть описаны механизмы синхронизации сайта с другими внешними системами: 1С, прайс-агрегаторы, торговые порталы... Описаны подробно какие-то свои собственные механизмы экспорта/импорта данных. Описаны механизмы обновления цен на товары в каталоге (если это интернет-магазин). Возможно еще какие-то механизмы. Если на сайте используется несколько видов цен - эти виды цен также должны быть описаны с указанием того, кому какой тип цены доступен (к стати, не забывайте, что для нескольких типов цен нужна редакция БУС "Бизнес").
5. Далее описываем права доступа. Тут должны быть описаны все рабочие группы пользователей. Всегда это Администратор, Авторизованный пользователь и Неавторизованный пользователь. Если нужны какие-то еще - они обязательно должны быть описаны. 
6. Предпоследний раздел должен содержать основные сценарии поведения пользователей на сайте: пользователь просто зашел на сайт, на главную страницу - значит ему нужно показать акции, новинки, спец.предложения ...; пользователь пришел из поиска, т.е. он уже ищет какой-то товар, значит ему нужно продать этот товар или предложить аналоги и так далее. Пользователь может зайти на любую страницу сайта и все это нужно предусмотреть. Если пользователь зашел на страницу, к которой у него нет доступа - ему об этом должно быть выдано сообщение. Каждый сайт будет содержать свой собственный набор таких правил
7. Последний раздел содержит календарный план сдачи функционала проекта с разделением на блоки.

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

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