Функционал, реализуемый на сайте, можно поделить на две группы: стандартный (типовой) и нестандартный.
Стандартный функционал покрывает базовые потребности владельцев большинства сайтов вашего типа. Его просто реализовать технологически. Он же обычно сразу приходит в голову, когда задумываешься об устройстве того или иного раздела.
Например, что должно быть в разделе новостей?
Обычно он состоит из:
Допустимы небольшие отклонения от этого шаблона: например, у новости может быть несколько картинок, видео, или в разделе может быть несколько рубрик.
Таких типовых разделов довольно много: список услуг, каталог товаров, акции, отзывы, галерея, контакты, команда, вопрос-ответ и т.д.
Когда весь сайт состоит из таких стандартных разделов, для его реализации обычно не требуется составлять техническое задание, достаточно при расчете стоимости проекта и заключении договора перечислить, какие разделы вам будут необходимы.
Если вы работаете с нами, и перед стартом работы у вас есть сомнения по функционалу типовых разделов, вы можете запросить у нас их детальное описание.
Конечно, многое зависит от подрядчика. Если вы уверены, что в процессе разработки он найдет вместе с вами наилучшее решение в рамках вашего бюджета и будет отвечать за качество результата, то можно не беспокоиться насчет ТЗ.
Если ваш сайт не сложный, но у вас в голове уже есть ряд требований — какие разделы должны быть, из чего структурно должна состоять страница, как выглядеть, какие элементы интерфейса содержать — можно подготовить ТЗ со структурированным перечислением этих требований. Необходимо, чтобы исполнитель согласовал его перед разработкой — возможно, он предложит какие-то альтернативные решения для упрощения разработки или что-то уточнит.
При подготовке даже простого ТЗ важно понимать, что для всех требований должны быть объективные причины, и делать просто потому что «так хочется» — не лучшая идея. Потому что это не просто не оправдает себя коммерчески, но и может привести к внеплановым затратам на разработку.
Можно попробовать продумать требования к реализации самостоятельно, но:
Такой вариант можно пробовать только с ТЗ на несложный сайт. Но обязательно согласуйте его с подрядчиками.
Для реализации средних и сложных проектов мы советуем обращаться к надежным подрядчикам и делать ТЗ вместе с ними, иначе решение сэкономить может выйти совсем не экономным.
У вас могут быть подготовлены технические требования к будущему сайту. Допустим, это просто список общих положений, которым должен соответствовать сайт: валидность верстки в современных версиях всех популярных браузеров, адаптивность под разные типы устройств, оптимизация изображений для WEB, настройка robots.txt и т.д. Хорошим решением будет сделать этот список приложением к договору, а не отдельным ТЗ (техзадание — это более обширный детализированный документ, описывающий целиком сайт или его нестандартные разделы).
У нас соответствие таким требованиям по умолчанию включено в разработку, но если вам принципиально важно что-то нетиповое, необходимое именно для вашего проекта (например, корректность отображения сайта в каком-то редко используемом браузере), необходимо указать это при передаче проекта на оценку — о таких вещах нам лучше знать заранее. Переделка проекта под требования всегда дороже, чем разработка с изначально заложенными требованиями.
В тех случаях, когда вам не нужно реализовывать нестандартный функционал. Обычно это:
Здесь есть ещё одна оговорка: если вы пока не определились, с помощью каких технологий (на каком движке) собираетесь создавать сайт, то не стоит сразу же делать ТЗ без планирования, как и с кем вы собираетесь реализовывать проект. Сначала мы рекомендуем вместе со специалистами определить оптимальные инструменты для решения ваших задач.
Если придумывать ТЗ без привязки к платформе, предложенные решения не будут оптимизированы под конкретное окружение, и после выбора платформы могут возникнуть проблемы при реализации на ней.
Если планируется, что ТЗ и сайт будут разрабатывать разные исполнители, а технология выбрана непопулярная, вам сложно будет найти специалистов, которые смогут реализовать заявленный функционал. И велик риск, что придется составлять ТЗ еще раз. Если исполнитель один и тот же — он сделает вам сайт, который сложно будет поддерживать и дорабатывать, если вы позднее решите прекратить сотрудничество.
Если подрядчик, создающий ваше ТЗ, не занимается полной реализацией подобных проектов, то нет гарантии, что всё пойдёт гладко: он просто соберет ваши требования в общий документ, но не подумает про их оптимизацию для экономии при реализации. И получится так, что все ваши «хочу» собраны по-максимуму, но сделать это выйдет очень дорого.
Обратите внимание, что разработка ТЗ позволяет использовать в дальнейшем классическую каскадную модель. Если вы решили создавать сайт без технического задания, проверьте, разработка в рамках какой модели предпочтительнее именно для вашей компании.
В любых случаях, когда требуется реализовать нестандартный функционал.
Нестандартный функционал — это вывод или поведение элементов страницы, отличное от типового; любая логика, которая не является самой простой для реализации — и потому не будет очевидно одинаковой для заказчика и исполнителя.
Когда такой функционал планируется на сайте, необходимо продумать его «на берегу», иначе при разработке сайта бюджет может сильно превысить запланированный. Чтобы этого избежать, нужно часть работы по проектированию сайта (с меньшей детализацией, но всё же) проделывать перед стартом реализации проекта — это и есть ТЗ.
Во-первых, нужно иметь какие-то начальные требования к функционалу — если вы решили делать ТЗ, значит, у вас есть представление и идеи о том, каким должен быть сайт. Соберите их вместе, описав максимально подробно в свободной форме, если можете — с примерами в ссылках и картинках. Это будет стартовый документ для начала работы.
Во-вторых, перед началом работы по ТЗ очень важно выбрать одно ответственное лицо — человека, имеющего самую полную картину функционала, который необходимо реализовать, и транслирующего единственно правильную выбранную заказчиком концепцию. Важно, чтобы этот человек не менялся в процессе. Если вы в ходе разработки ТЗ захотите разнообразия и будете добавлять новых согласующих с новым видением и новыми требованиями:
И всё потому, что у того, кто принимает итоговый сайт, иное видение, чем у того, кто со стороны клиента курировал разработку ТЗ.
В-третьих, важно подготовиться к тому, что понадобится плотное сотрудничество с подрядчиком, разрабатывающим ТЗ: вам необходимо будет оперативно, подробно и регулярно отвечать на уточняющие вопросы. Все требования к функционалу будут разрабатываться при вашем участии. Задача подрядчика на этапе сбора требований — задавать правильные вопросы и обговаривать с клиентом ограничения и компромиссы в случаях, если возникнут нестыковки или неоптимальные решения. Помните, что в процессе создания ТЗ придумывать какие-то альтернативные, более экономичные решения вместо изначальной задумки — нормально.
Работая над ТЗ, мы задаем большое количество вопросов не потому, что не знаем, как это сделать, а потому, что сделать можно по-разному, а нам нужно реализовать именно по-вашему.
Главная задача — чтобы обе стороны понимали, что описано в ТЗ, и у них не возникло вопросов, почему договаривались об одном, а в процессе реализации разрабатывается другое.
После составления ТЗ по вашим требованиям мы согласуем его текст с вами, вы вносите корректировки и получаете финальную версию.
Чем больше нестандартных разделов планируется на сайте, чем больше требований к их функционалу и чем больше связей между ними — тем больше времени будет потрачено на создание ТЗ.
Вот пример того, что мы делаем в процессе проработки ТЗ.
Составляем базовую часть:
Прорабатываем архитектуру сайта:
Определяем роли пользователей:
Определяем события:
Прорабатываем функционал:
Таким образом мы «собираем» на бумаге сайт, которого ещё нет. Для этого требуется думать одновременно обо всех вещах, которые имеют отношение к созданию сайта, чтобы не возникло противоречий в функционале и логических нестыковок.
Для простоты подсчёта можно ориентироваться на то, что по итогу разработки технического задания стоимость одной страницы составляет в среднем от 800 до 8000 рублей в зависимости от количества и уровня специалистов, задействованных в этом процессе и сложности требуемого функционала.
Техническое задание на разработку интернет-магазина, например, займёт от 20 страниц, а стоимость страницы будет средней, в пределах 4000 рублей.
Состав итогового документа сильно зависит от проекта, его сложности и особенностей. Размер тоже может быть разный — обычно это документ в несколько десятков страниц.
По умолчанию ТЗ содержит базово разделы с глоссарием, общими положениями и требованиями. Техническое задание содержит обычно детализацию и для программистов, и для отдела дизайна.
Дальше — в зависимости от проекта — может быть:
При этом в техническом задании учтены все связи между разделами, событиями и пользователями, и всё это разработано в соответствии с ограничениями выбранного движка сайта.
Техзадание определяет и организует процесс создания сайта. От него зависит, будет ли он готов в срок и укомплектован всем необходимым функционалом. Подойдите ответственно к созданию ТЗ — и вы получите именно такой сайт, который вам нужен, без переплаты за избыточный функционал или доработки.
Есть вопросы, нужна консультация по ТЗ? Напишите нам на hello@web-industry.pro.Настоящая помощь малому и среднему бизнесу. Сайты в подарок при заказе продвижения или техподдержки! Рассрочка!
Делаем сейчас — платишь потом!