Техническое задание на разработку сайта

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

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

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

Зачем ТЗ нужно на самом деле

ТЗ часто воспринимают как формальность, которую требует исполнитель. Но по-настоящему оно защищает обе стороны — и вот от чего.

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

Даёт сопоставимые оценки. Когда вы отправляете одинаковое ТЗ трём исполнителям, вы получаете три предложения по одной и той же задаче — их можно сравнивать. Без задания каждый считает что-то своё, и цифры отличаются не потому, что кто-то дороже, а потому, что все посчитали разный объём работы.

Становится основанием для приёмки. Когда работа сдана, ТЗ — это то, по чему вы сверяете результат. Есть список того, что должно быть, — значит, есть чем сказать «готово» или «вот здесь ещё нет». Без него приёмка превращается во вкусовщину.

Обратите внимание: ни одна из этих функций не про технологии. Все три — про договорённость между людьми.

Что обязательно должно быть в ТЗ

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

• Что за бизнес и что вы продаёте. Кажется очевидным, но исполнитель не знает вашу сферу так, как вы. Опишите простыми словами: чем занимаетесь, что предлагаете, чем отличаетесь от соседей. Пропустите — получите сайт «про всё и ни о чём». У разных отраслей и структура сайта разная — как именно, видно на страницах под конкретные сферы.

• Кто ваш клиент и как он принимает решение. Сайт для молодой мамы и сайт для строительной компании устроены по-разному, потому что решают по-разному. Напишите, кто к вам приходит и что ему важно понять, прежде чем согласиться. Без этого дизайнер рисует «для всех», а значит — ни для кого.

• Какое действие человек должен совершить. У сайта всегда есть цель: оставить заявку, позвонить, записаться, скачать прайс. Назовите её прямо. Если цель не задана, сайт выходит «красивым», но непонятно, что на нём делать, — и обращений он не приносит.

• Кто конкуренты и чьи сайты вам нравятся. Дайте две-три ссылки и объясните, чем именно они хороши: «здесь понятно с первого экрана», «здесь солидно выглядит». Это быстрее описывает ваш вкус, чем страница прилагательных. Пропустите — оставите исполнителя гадать, что вам понравится.

• Какие страницы нужны. Хотя бы черновиком: главная, услуги, о компании, контакты, блог. От числа страниц напрямую зависят объём работы и срок. Без списка исполнитель либо заложит лишнее, либо забудет нужное. Если страниц немного — главная, о компании, услуги и контакты, — вы, по сути, описываете сайт-визитку.

• Что нужно интегрировать. CRM, онлайн-оплата, доставка, запись в календарь, чат, телефония. Каждая связка — отдельная работа, и о ней важно сказать заранее. Всплывёт в конце — сдвинутся и сроки, и бюджет.

• Кто даёт тексты и фотографии. Самый недооценённый пункт. Если контент на вас — закладывайте на это время; если ждёте его от исполнителя — это отдельная работа, которую надо обговорить. Молчание здесь — главная причина, по которой проекты застревают перед самым запуском.

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

Каждый пункт короткий, но, если его пропустить, пробел всё равно всплывёт — только позже и дороже, уже в виде переделки.

Образец технического задания на создание сайта

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

В квадратных скобках — места, куда подставляются ваши факты; рядом показано, как это формулируется на практике. Пример ТЗ на разработку сайта написан для мебельного производства, но структура не меняется от ниши: меняется наполнение.

Скачать шаблон для Word (.docx)

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

Развернуть шаблон ТЗ на разработку сайта

1. О компании и задаче

Мы — [название], делаем [что именно] с [года]. Работаем по [город / вся Россия]. Сейчас клиенты приходят из [источник: сарафан, доска объявлений, реклама].

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

Чего сайт делать не должен: [если есть ограничение — назовите]. Пример: «продавать онлайн не нужно, оплата и замер идут офлайн».

2. Кто клиент и как он принимает решение

Основная аудитория: [кто это, чем занимается, каков бюджет решения]. Пример: «семьи 30–45 лет, покупают кухню раз в десять лет, выбирают долго и сравнивают по три-четыре мастерских».

Что человеку важно понять до обращения: [список сомнений]. Пример: «из чего считается цена, сколько ждать, что будет, если не понравится результат, и делаем ли мы замер бесплатно».

Кто ещё смотрит сайт: [дизайнеры интерьера, подрядчики, поставщики — если есть].

3. Целевое действие

Главное действие: [заявка / звонок / запись / расчёт]. Пример: «оставить заявку на замер с указанием города и размеров помещения».

Второстепенное: [что делает тот, кто не готов сейчас]. Пример: «посмотреть галерею работ и сохранить страницу».

Куда уходит заявка: [почта, Telegram, CRM — назовите систему].

4. Структура сайта

Черновой список страниц: [перечислите]. Пример: «главная, каталог решений (кухни, шкафы, гардеробные), примеры работ с фотографиями, как мы работаем, цены, о производстве, контакты».

Что на каждой должно быть: [одна строка на страницу]. Пример: «на странице "как мы работаем" — этапы от замера до установки со сроками по каждому».

Чего быть не должно: [разделы, которые нечем наполнить]. Пример: «блог не нужен, писать его некому».

5. Содержание: тексты и фотографии

Тексты: [есть / частично / нет]. Кто их даёт: [вы, исполнитель, копирайтер]. Пример: «описания услуг напишем сами, тексты для главной и раздела о производстве — на исполнителе, факты предоставим».

Фотографии: [есть / нужна съёмка]. Пример: «есть сорок снимков готовых работ с телефона, съёмку цеха планируем, стоковые фотографии не подходят».

Что нельзя использовать: [ограничения]. Пример: «фотографии клиентских квартир без лиц и адресов».

6. Дизайн и впечатление

Сайт должен производить впечатление: [два-три слова]. Пример: «дорого, но не пафосно; чтобы было видно ручную работу».

Нравятся сайты: [две-три ссылки и чем именно]. Пример: «вот этот — понятно с первого экрана, чем они занимаются; вот этот — крупные фотографии, за которыми видно качество».

Не нравится: [что отталкивает]. Пример: «пёстрые баннеры и всплывающие окна с обратным отсчётом».

Фирменный стиль: [есть логотип и цвета / нет ничего].

7. Технические требования

Домен: [есть, оформлен на кого / нужен новый].

Что нужно подключить: [список]. Пример: «форма заявки с уведомлением в Telegram, Яндекс.Метрика, онлайн-запись на замер; интеграция с 1С не требуется».

Кто вносит правки после запуска: [вы сами / исполнитель]. От этого зависит, нужна ли админка.

Что должно остаться у нас после сдачи: [домен, хостинг, доступы, исходники].

8. Сроки и приёмка

Желаемая дата запуска: [дата] и почему именно она: [привязка]. Пример: «к началу сезона в марте, до этого идёт реклама на текущую страницу».

Ориентир по сроку у исполнителя: [например, от 7 дней для многостраничного сайта].

Сайт считается принятым, когда: [перечислите проверяемые условия]. Пример: «все страницы из списка выше опубликованы и наполнены, форма присылает заявку на рабочую почту и в Telegram, сайт открывается на телефоне без горизонтальной прокрутки, метрика фиксирует отправку заявки как цель».

Кто принимает работу с нашей стороны: [имя и должность одного человека].

9. Бюджет

Рассчитываем на [вилка] и готовы обсуждать состав, если что-то в неё не помещается.

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

Чего в реальных ТЗ быть не должно

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

«Сделать как у [конкурента], только лучше». Ссылка на чужой сайт вместо задачи. «Лучше» у всех разное, а копия чужой структуры воспроизводит чужие решения вместе с их ошибками. Скажите, что именно у конкурента работает и почему вы так считаете.

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

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

«Адаптивность, кроссбраузерность, валидный код». Это входит в нормальную работу по умолчанию, как руль в машину. Пункт занимает место и создаёт ложное ощущение, что задание проработано.

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

Срок «вчера» без даты. Если дата привязана к событию — выставке, сезону, запуску рекламы, — назовите событие. Тогда видно, что можно успеть к нему, а что доделать после.

Отдельно про ГОСТ. Иногда ТЗ требуют оформить по ГОСТ 34.602 — это про государственные закупки и тендеры, там документ пишется по формальной структуре и живёт по другим правилам. Для обычного коммерческого сайта такой формат ничего не добавляет, кроме объёма.

Чего в ТЗ писать не нужно

Теперь то, что снимет с вас лишнюю работу. В ТЗ не нужно — и даже вредно — писать вот это.

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

Не расписывайте цвета и шрифты. «Заголовки таким-то шрифтом, кнопки бирюзовые» — это не задача, а попытка сделать работу дизайнера за него. Ваше дело — сказать, какое впечатление сайт должен производить («дорого», «спокойно», «по-дружески»), а конкретные оттенки подберёт специалист.

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

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

Общий принцип простой: вы отвечаете за «что» и «зачем», исполнитель — за «как». Как только вы залезаете в «как», вы платите деньги за то, чтобы связать руки тому, кого наняли.

Как формулировать, чтобы поняли правильно

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

• «Сделайте красиво» → «Клиент должен за пять секунд понять, что мы делаем кухни на заказ, а не продаём готовую мебель».
• «Нужен современный сайт» → «Конкуренты выглядят дороже нас, хотя работают хуже. Хочу, чтобы по сайту был виден наш уровень».
• «Добавьте вау-эффект» → «Люди уходят с первого экрана. Нужно, чтобы захотелось листать дальше».
• «Пусть будет солидно» → «К нам приходят с крупными заказами и боятся довериться. Сайт должен снимать это недоверие».

Видите закономерность? Слева — оценка, которую каждый поймёт по-своему. Справа — задача, у которой есть измеримый смысл: понял или не понял, доверился или ушёл. Хорошая формулировка описывает не то, как сайт должен выглядеть, а что должно произойти с человеком, который на него попал. Если каждый ваш пункт проходит проверку вопросом «а как мы поймём, что это получилось?» — задание написано правильно.

ТЗ для веб-дизайнера: отдельный случай

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

Разница в том, что дизайнеру нужны не технические требования, а входные данные для решения: структура страниц, готовые тексты или хотя бы их объём, фотографии, впечатление, которое сайт должен производить, и примеры с объяснением, чем они нравятся. Разделы про интеграции, домен и приёмку из образца выше ему не нужны — они относятся к тому, кто будет собирать сайт.

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

Что делать, если не знаете, чего хотите

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

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

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

Бюджет в ТЗ: называть или нет

Отдельный вопрос, на котором спотыкаются почти все: указывать ли в ТЗ бюджет. Многие боятся — «назову сумму, и мне ровно на неё насчитают, даже если можно дешевле». Логика понятная, но на практике всё наоборот.

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

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

Что вы вправе получить в ответ на ТЗ

ТЗ — это половина разговора. Вторая половина — ответ исполнителя, и по нему видно, стоит ли с ним работать. В нормальном ответе на техническое задание есть:

• Понимание задачи своими словами. Исполнитель пересказывает вашу задачу так, как понял её сам. Совпало с тем, что вы имели в виду, — вас услышали. Пересказать не смог — не разобрался.
• Состав работ. Что именно будет сделано: какие страницы, какая механика, что входит, а что нет.
• Срок. Не «примерно месяц», а внятные этапы с последовательностью и датами.
• Цена и что в неё входит. Прозрачно, за что вы платите и где проходит граница «это уже отдельно».
• Правки. Сколько кругов правок входит и что считается правкой, а что — новой задачей.
• Кому принадлежит результат. Ваши ли после сдачи код, дизайн, домен и доступы, или вы остаётесь привязаны к исполнителю.

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

ТЗ — это разговор, записанный на бумаге

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

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