Сайты. SEO.
Хочу сайт
Хочу SEO
Хочу лендинг Сайт в подарок!
Контакты
+7 (812) 318-74-97

Офис в Санкт-Петербурге

hello@web-industry.pro Подробнее
Как правильно поставить ТЗ на создание сайта

Как правильно поставить ТЗ на создание сайта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наше ТЗ готово, можно везти его к заказчику.
Перед началом работы Советы и Консультации Школа интернет-маркетинга Курсы 1С-Битрикс О САЙТАХ О SEO О ДИЗАЙНЕ Аудиты и рекомендации по созданию и продвижению сайтов Кейсы Помощь
Говорит и показывает Яндекс
Сфера информационных технологий такова, что нужно все время держать руку на пульсе, чтобы оставаться на плаву. Тренды изменяются молниеносно, новшества, которые прежде казались фантастикой, становятся частью нашей жизни, еще вчера безупречно работавшие инструменты сегодня не просто бесполезны, но даже могут навредить... Хотите всегда быть в курсе происходящего? Позвольте нам быть вашим гидом! 

Здесь мы собираем свежие новости, гайды, FAQ'и, статьи и прочую информацию, которую считаем интересной и полезной. Следите за обновлениями!
Форма заказа

Сайты в подарок

Настоящая помощь малому и среднему бизнесу. Сайты в подарок при заказе продвижения или техподдержки! Рассрочка!

Делаем сейчас — платишь потом!

Отличный старт

При заказе комплексного тарифа «Эволюция 8» на год (ежемесячный платёж — 12800 р.) — новый сайт «Лёгкий старт» в подарок!

Лучший выбор

При заказе комплексного тарифа «Эволюция 15» на год (ежемесячный платёж — 24000 р.) — новый сайт для SEO «Правильный выбор» в подарок!

Лидер

При заказе комплексного тарифа «Эволюция 25» на год (ежемесячный платёж — 40000 р.) — новый сайт для SEO «На шаг впереди» (КАТАЛОГ) в подарок!

Онлайн-продажи

При заказе комплексного тарифа «Эволюция 35» на год (ежемесячный платёж — 56000 р.) — новый сайт для SEO «Онлайн-продажи» (ИНТЕРНЕТ-МАГАЗИН) в подарок!

Скидки на сайты

«Лёгкий старт»

65 000 руб. 35 000 руб.
То, что нужно для начала! В пакет входят:
  • новый одностраничный сайт;
  • 2 часа профессиональных консультаций руководителя отдела ведения интернет-проектов (опыт — 10 лет);
  • настройка контекстной рекламы.

«Лёгкий старт PRO»

65 000 руб. + 45 000 руб. 35 000 руб. + 35 000 руб.
Это прочная основа для развития! В пакет входят:
  • новый одностраничный сайт по стандарту Web-Industry Group;
  • до двух часов профессиональных консультаций руководителя отдела ведения интернет-проектов (опыт — 10 лет);
  • настройка контекстной рекламы;
  • +
  • профессиональный подбор семантического ядра (СЯ);
  • маркетинговое исследование;
  • регистрация компании на 100 профильных порталах.

Сайт для SEO «Правильный выбор»

180 000 120 000 руб.
Это сайт, в который на этапе создания заложено всё необходимое для продвижения. В пакет входят:
  • новый Сайт для SEO по стандарту Web-Industry Group;
  • лицензия «1С-Битрикс: Управление сайтом - Старт»;
  • до четырёх часов профессиональных консультаций руководителя отдела ведения интернет-проектов (опыт — 10 лет);
  • профессиональный подбор семантического ядра (СЯ);
  • SEO-оптимизация (до 200 ключевиков);
  • настройка контекстной рекламы;
  • маркетинговое исследование;
  • регистрация компании на 100 профильных порталах;
  • 2 месяца техподдержки.

Сайт для SEO «На шаг впереди»

320 000 240 000 руб.
Сайт, уже на этапе создания максимально заряженный на успешное продвижение. Первые позиции — сразу после выкладки! В пакет входят:
  • новый Сайт для SEO «КАТАЛОГ» по стандарту Web-Industry Group;
  • лицензия «1С-Битрикс: Управление сайтом - Старт»;
  • до восьми часов профессиональных консультаций руководителя отдела ведения интернет-проектов (опыт — 10 лет);
  • разработка концепции сайта под руководством арт-директора;
  • профессиональный подбор семантического ядра (СЯ);
  • SEO-оптимизация (до 300 ключевиков);
  • настройка контекстной рекламы;
  • маркетинговое исследование;
  • регистрация компании на 100 профильных порталах;
  • 2 месяца техподдержки;
  • 2 месяца маркетинговой поддержки.
!! Возможна рассрочка до конца года !!

Сайт для SEO «Онлайн-продажи»

560 000 360 000 руб.
То, что нужно для уверенных позиций и хороших продаж! В пакет входят:
  • новый Сайт для SEO «ИНТЕРНЕТ-МАГАЗИН» по стандарту Web-Industry Group;
  • лицензия «1С-Битрикс: Управление сайтом - Малый бизнес»;
  • до 16 часов профессиональных консультаций руководителя отдела ведения интернет-проектов (опыт — 10 лет);
  • разработка концепции сайта под руководством арт-директора;
  • профессиональный подбор семантического ядра (СЯ);
  • SEO-оптимизация (до 500 ключевиков);
  • настройка контекстной рекламы;
  • маркетинговое исследование;
  • регистрация компании на 100 профильных порталах;
  • 2 месяца техподдержки;
  • 2 месяца маркетинговой поддержки.
!! Возможна рассрочка до конца года!!

Поддержите нас во время карантина — и мы поддержим вас, когда он закончится!

Никто точно не знает, что будет, когда страна вернётся с вынужденной самоизоляции. Сколько малого/среднего/любого бизнеса поляжет вслед за рублём, сколько креативных сотрудников пойдут работать на завод (но не дойдут, потому что завода-то нет уже!), сколько квартир в Москве можно будет купить на тысячу евро и сколько миллионов рублей придётся выложить за пачку гречки. Ужас и прелесть этой ситуации в том, что мы не знаем, кто именно из наших коллег, партнёров и конкурентов в новогоднюю ночь будет петь и танцевать на улице под бубен.

Государство не объявляет режим ЧС, а это значит, что подмога не придёт, нужно справляться самим.

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

До конца 2020 года мы распродаём часы работы наших сотрудников по смехотворно низкой цене — всего 900 рублей! Купите сейчас любое количество — и:

  1. наши мозги, талант и способности останутся с вами,
  2. вы сможете потратить часы на любые услуги с января 2021 и до конца года — в горячие деньки, когда цены будут пробивать потолок, а уцелевшие компании — рвать друг другу глотки.

Часы от Web-Industry Group, как доллар и биткоин, — важно купить вовремя!


Перейти к заказу
Сайт в подарок! Акции и скидки на сайты и продвижение
Чтобы сделать сайт еще удобнее, мы анализируем пользовательский опыт - собираем данные...
Подробнее
Чтобы сделать сайт еще удобнее, мы анализируем пользовательский опыт - собираем данные с помощью файлов cookie, журналов истории доступа и web-счетчиков. Согласно Федеральному закону «О персональных данных» мы обязаны сообщить вам об этом. Продолжая работу с ресурсом, вы выражаете согласие на обработку ваших данных. Более подробная информация размещена в разделе «Политика конфиденциальности»