Как составить техзадание на сайт, чтобы получить то, что нужно

Зачем вообще нужно ТЗ

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

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

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

Есть и третий эффект, о котором редко думают. Пока вы формулируете ТЗ, вы сами начинаете лучше понимать свой проект. Вопрос «а что должно произойти после того, как человек оставил заявку?» заставляет впервые всерьёз подумать про воронку, а не только про картинку. Многие решения, которые потом экономят месяцы, рождаются именно на этапе, когда вы вынуждены проговорить словами то, что раньше жило смутным образом.

Что должно быть внутри

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

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

Ошибки, которые убивают ТЗ

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

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

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

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

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

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

Как написать, если вы не технарь

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

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

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

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

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

Что оно даёт и чего не гарантирует

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

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

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

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

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

Частые вопросы

Нужно ли техзадание для простого лендинга?

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

Кто должен писать ТЗ — заказчик или студия?

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

Что будет, если делать сайт вообще без ТЗ?

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

Насколько подробным должно быть техзадание?

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

Может ли ТЗ меняться в процессе работы?

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

Короткий вывод

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

Поможем собрать ТЗ и сделаем сайт

APST делает сайты в Воронеже с 2005 года. Не обязательно приходить с готовым техзаданием — расскажите про бизнес и задачу своими словами, а вопросы и структуру мы соберём вместе. Пришлите пару примеров сайтов, которые нравятся, — и на первом созвоне превратим это в понятный план работы.

Обсудить проект