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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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