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

ТЗ выглядит следующим образом: всё начинается с раздела «Общие положения», где мы пишем назначение документа, обычно забористая какая-нибудь фраза идёт, такая как ЦЕЛИ НАПИСАНИЯ ТЕХНИЧЕСКОГО ЗАДАНИЯ — ЭТО ДАТЬ КОМПЛЕКСНОЕ ОПИСАНИЕ ПРОДУКТА...В общем, — это общая обязательная часть, формальность, которая должна быть.

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

И после этого приступаем к крупноуровневому описанию требований к продукту. 

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

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

Поскольку, если наш продукт ориентирован на нагрузку в 100 человек в день — он должен будет крутится на одном оборудовании, если он ориентирован на 200 человек в день, — там разработчику потребуются совершенно другие мощности. — Это одна из характеристик нашего продукта.

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

Очень важный раздел — «Требования к безопасности». Такой раздел должен содержать разные требования к устойчивости от DDoS-атак, вирусных активностей и так далее.

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

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

Опять-таки этот раздел не должен занимать много страниц, обычно он достаточно ёмкий и простой.

Вот следующий раздел уже немножко важнее. Он описывает общую идеологию продукта.

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

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

Дальше мы приступаем к описанию интерфейсов. В этом разделе мы описываем навигационную структуру сайта. То есть описывать — какие у нас есть страницы и какие шаблоны на этих страницах существуют. Поскольку на сайтах СМИ обычно шаблонов не так много, но при этом есть куча разделов, есть куча хитрых взаимодействий между страницами, которые нужно отразить.

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

— Это вещь достаточно редкая для рынка веб-разработки. Почему-то так сложилось, что проектировщики дико не любят описывать интерфейсы. Но это является неотъемлемой частью продукта. Интерфейс подчиняется жёстким закономерностям.

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

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

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

Например, в конце мы пишем «кнопка заказа катания» — она вызывает сценарий открытие заказа катания номер такой-то, и в отдельном разделе мы этот функционал описываем. Формы описания могут быть разные. 

Раньше их описывали в виде блок-схем. Ещё раньше описывали в виде пространственных текстовых описаний. Сейчас мы пришли к формату полутекстовому, полудревовидному, когда мы описываем нормальное поведение функционального сценария.

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

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

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

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

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

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

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

Когда мы описали интерфейсы, внутренние шестерёнки, закономерности,  но внутри продукта в любом случае лежат данные, то есть там лежит какой-то контент. Все эти данные необходимо перечислить. Мы должны описать всю подноготную, которая есть,—  она выглядит похожей на описание структуры БАЗЫ данных, но на самом деле это описание структуры данных.

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

Кроме того часть данных будет образовывать справочники, которые будут прошиты в системе. Частые справочники — это справочник географических локаций, если мы говорим про Интернет-магазины, или это могут быть справочники категорий товаров в Интернет-магазине.

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

Мы описали фактически всё нутро нашего продукта, но у нас есть инфраструктура, — то, что окружает наш продукт. И, если что-то связывается извне с нашей системой, — мы должны это прописать. — Вариативность там космическая. Если, например, наша система связывается с 1С устаревшей версии, то на ночь на него лучше не смотреть. 

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

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

Почему мы не завязываемся на экран? — Поскольку мы живём в век фреймворков и коммерческих/некоммерческих CMS, — обычно они приходят с минимальной админкой.

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

И когда мы составляем все эти пункты, важно держать в голове принцип системности. — Это требование, про которое мы уже говорили. Сейчас, когда мы описываем продукт с разных сторон, крайне важно, чтобы КАЖДЫЙ раздел, не считая разделов основных положений и требований по безопасности, был связан с другими разделами. 

Например, мы описываем кнопку, кнопка ссылается на функциональный сценарий, функциональный сценарий ссылается на структуру данных, структура данных ссылается на другую структуру данных, та ссылается на справочник, а он ещё на что-то. 

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

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

Дальше мы описываем функционал — наши внутренние шестерёнки, оставляя хвосты, где структуры ссылаются на какие-то структуры данных, пока их не трогать. Далее описываем структуру данных и всё остальное, не забывая про такой раздел, как «словарь терминов».

Наше ТЗ готово, можно везти его к заказчику.