Как подготовить техническое задание на разработку сайта

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

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

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

Хорошее ТЗ закрывает сразу несколько задач, которые напрямую влияют на результат:

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

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

Что должно быть в техническом задании на разработку сайта

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

1. Общая информация о проекте

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

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

2. Цели и задачи сайта

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

В этом блоке полезно зафиксировать:

• главную цель сайта;
• второстепенные цели;
• целевые действия пользователя (отправка заявки, звонок, покупка, подписка);
• KPI, если они определены (конверсия в заявку, количество регистраций, средний чек).

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

3. Целевая аудитория

«Мужчины и женщины 25–45 лет» — плохая заготовка. Она не даёт ни дизайнеру, ни разработчику понимания, как именно человек будет пользоваться сайтом. Чем точнее портрет, тем осмысленнее решения по навигации, контенту и интерфейсу.

Лучше описывать аудиторию через такие вопросы:

• кто эти люди (должность, сфера, уровень подготовки);
• какая у них проблема, с которой они приходят на сайт;
• что они хотят получить в идеале;
• как они принимают решение (сравнивают, смотрят портфолио, запрашивают цену, просят рекомендации);
• что их может отпугнуть или заставить уйти.

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

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

Это карта разделов и страниц. Фактически оглавление будущего сайта. Типичный набор для коммерческого проекта: главная, о компании, услуги, каталог, карточки товаров или услуг, цены, кейсы, отзывы, блог, контакты, FAQ и формы заявки. Но универсального списка не существует — он всегда выводится из целей и сценариев аудитории.

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

5. Описание страниц и блоков

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

Для каждой ключевой страницы я рекомендую указывать:

• какие блоки нужны;
• в каком порядке они идут;
• какой контент в них размещается (текст, изображения, видео);
• какие элементы обязательны;
• есть ли нестандартная логика (например, динамическая смена цены, табы с описаниями).

Пример описания страницы услуги, который часто встречается в моих проектах:

• заголовок с УТП и коротким пояснением;
• описание услуги с акцентами на результат;
• этапы работы (таймлайн или карточки);
• преимущества (с иконками или короткими тезисами);
• кейсы / портфолио по этой услуге;
• стоимость или тарифы;
• FAQ для снятия типовых возражений;
• форма заявки или кнопка для связи.

6. Функциональные требования

Здесь мы описываем, что сайт должен уметь делать, а не как это выглядит. Ключевое слово — «должен». Функціональные требования перечісляют все интерактивные элементы и поведение системы.

В список обычно попадают:

• формы обратной связи и заявок;
• онлайн-оплата и платежные шлюзы;
• фильтры и сортировка в каталоге;
• корзина и оформление заказа;
• личный кабинет (история заказов, профиль, настройки);
• поиск по сайту;
• калькулятор стоимости;
• чат или виджет для связи;
• интеграция с CRM;
• подписка на рассылку;
• мультиязычность.

Главная проблема большинства ТЗ — общие формулировки. Фраза «нyжна форма» ничего не даёт. Я всегда прошу расписать с деталями, примерно так: «форма обратной связи должна отправлять заявкy на пчтy менеджера и дублировать в CRM, содержать поля имя, телефон, email, комментарий, иметь защитy от спама (reCAPTCHA) и показывать сообщение об успешной отправке». Иначе на этапе тестирования обнаружите, что форма просто не подключена или письма уходят в спам.

7. Требования к дизайну

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

В ТЗ стоит зафиксировать:

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

Сборка референсов — один из самых рабочих способов снят вкусовщину. Я обычно прошу заказчика не просто скинуть ссылки, а к каждой добавить 2-3 предлжения, что именно понравилось. Это сразу даёт направление, в котором работать дизайнеру.

8. Адаптивность и кроссбраузерность

Этот пунт часто пропускают, а потом удивляются, что на старом iPade всё едет. В российской нише мобильный трафик давно криtичен для большинства проектов, поетому адантация — не опція, а стандарт.

Нужно явно зафиксировать:

• какие разрешения поддерживаются (десктоп от 1200px, планшет, мобильные от 360px);
• как ведет себя сайт на мобильных устройствах (меню-бурегер, адаптівные изобржения, перестроение сетк);
• какие браузеры должны быть полностю совместимы (последние две версии Chrome, Safari, Firefox, Edge, по возможности Yandex Browser);
• допустимы ли отличія между десктопом и мобильной версией (например, упрощённая анимация, скрытие тяжёлых иллюстраций).

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

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

Ето раздел для тех, кто понимает, на каком стеке будет реализован проект. Если технология ещё не выбрана, то хотя бы пропишите ограніченія — бюджетные рамки, необходімость самостоятельной поддержки после сдачи, треbования к безопасті.

Пункты, которые стоит включить:

• CMS или фреймворк (например, 1С-Битрикс, WordPress, Laravel, Tilda — в зависмости от задач);
• особенности вёрстки (чистая адаптівная без Bootsrap, либо с ним, методологія БЭМ);
• треbования к хостингу (выделённый, VDS, облчный, специфічные нужды по РНР и базам данных);
• способ доступа к серверу и права;
• безопастность (SSL, защита от типовых атак, резервное копирование);
• треbования к скорости загрузки (LCP, ТВТ, чек-лист по оптимизации).

Без етого раздел можно получить сайт на Bitrix, когда бюджет располагал только на простую админky WordPress, и потратить месяцы на доделки. Или наоборот — выбрать Tilda для проектa, которому через полгода понадобятся сложные интеграціи, и прийти к полной переделке. Зафиксировать стек в ТЗ — значит зафиксировать реалистичные ожидания по возможностям и стоимости поддежки.

10. SEO-требования

Если сайт должен привлекать трафик из поиска, SEO закладивают на этапе ТЗ, а не «потом как-нибудь займёмся». Потом оказывается, что система ЧПУ не реализована, метатеги не управляются из админки, и всё приходитcя перепиливать.

В ТЗ полезно включить:

• понятную и единообразную структуру URL (человекочитaемые адреса, без знаков вопроса и длинных идентификаторов);
• требования к метатегам (title, description, keywords, H1 — заполняются из админки, все поля обязательны);
• настройку robots.txt и sitemap.xml;
• микроразметку (Schema.org для товаров, статей, хлебных крошек, организации);
• правила работы с дублями (канонические URL, 301-редиректы);
• требования к скорости как фактору ранжирования;
• перелинковку (правила связывания страниц);
• требования к индексации (закрыть служебные разделы, открыть целевые).

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

11. Контент и ответственность за него

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

В ТЗ нужно прямо и без экивоков написать:

• кто готовит тексты и в каком объёме;
• кто подбирает или покупает изображения;
• кто отвечает за видео;
• в каком формате передаются материалы (Google Docs, Figma, отдельные файлы);
• к какому дедлайну всё должно быть готово;
• что будет, если контент задерживается (сдвиг сроков, простой оплачивается отдельно).

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

12. Интеграции

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

Типичные системы для интеграции:

• CRM (amoCRM, Bitrix24, Salesforce);
• платёжные сервисы (ЮKassa, CloudPayments, Stripe);
• сервисы доставки (СДЭК, Boxberry, Почта России);
• телефония (коллтрекинг, обратный звонок);
• системы аналитики (Яндекс.Метрика, Google Analytics, цели и события);
• email-рассылки (Mailchimp, Unisender, SendPulse);
• мессенджеры (Telegram, WhatsApp, Viber);
• складские системы (МойСклад, 1С).

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

13. Этапы, сроки и приемка

ТЗ должно не просто описывать конечный результат, но и задавать порядок движения к нему. Я обычно выделяю такие этапы:

• прототип (если нужен);
• дизайн-макеты;
• вёрстка;
• программирование и интеграции;
• тестирование;
• запуск и базовая поддержка.

По каждому этапу нужно зафиксировать:

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

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

Удобная структура ТЗ: краткий шаблон

Если нужно быстро собрать каркас документа, можно ориентироваться на такую памятку. Она не заменяет полноценное ТЗ, но помогает не упустить главное на старте.

Как подготовить ТЗ на сайт: пошаговый процесс

Шаг 1. Определите цель проекта

Начните с простого, но жёсткого вопроса: зачем сайт нужен бизнесу? Если ответ размыт («чтобы было», «для имиджа»), и ТЗ выйдет таким же аморфным. Хорошая цель конкретна, измерима и привязана к бизнес-показателям: например, «увеличить количество заявок с сайта на 40% за счёт форм и онлайн-записи». Именно она будет компасом для всех дальнейших решений.

Шаг 2. Опишите пользователя

Возьмите реального человека, а не абстрактную ЦА. Кто он? С какой задачей пришёл на сайт? Что хочет увидеть в первые 10–20 секунд? Что заставит его остаться и совершить целевое действие? Для интернет-магазина это может быть быстрый поиск нужной модели, фильтры по параметрам и понятная цена с доставкой. Для B2B-услуги — кейсы, прозрачные сроки и способ быстро задать вопрос. Пропустите этот шаг — и получите сайт, который не разговаривает ни с кем конкретно.

Шаг 3. Соберите структуру

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

Шаг 4. Распишите ключевые страницы

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

Шаг 5. Зафиксируйте функционал

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

Шаг 6. Приложите референсы

Соберите подборку из 5–10 сайтов или отдельных блоков, которые кажутся удачными. К каждому добавьте короткий комментарий: что именно понравилось в дизайне, подаче контента, мобильной версии. Это снимет десятки итераций «сделайте что-то современное», потому что вместо вкусовщины появляется предметный разговор.

Шаг 7. Уточните контент и сроки

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

Шаг 8. Добавьте критерии приемки

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

Типовые ошибки в ТЗ

За годы практики я собрал целый список ошибок, которые почти гарантированно ломают проект. Вот основные:

• Слишком общие формулировки. «Удобный интерфейс», «красивый дизайн», «современный стиль» — каждый разработчик и дизайнер расшифрует это по-своему. Нужна конкретика.
• Отсутствие цели. Когда не зафиксировано, зачем сайт создаётся, команда делает продукт ради продукта, а не ради бизнес-результата.
• Игнорирование аудитории. Без понимания, для кого сайт, решения принимаются на основе личных предпочтений, а не сценариев пользователей.
• Не раскрыта структура сайта. Список страниц дан, а как они связаны, какие есть скрытые разделы — неясно. В итоге в навигации появляются «сюрпризы».
• Не описан функционал. Формулировки вроде «будет форма связи» не дают ничего. Нужно описывать поведение и условия работы.
• Нет требований к мобильной версии. Многие до сих пор думают, что десктопный макет просто сожмётся. В реальности на телефоне нужна иная композиция и приоритеты.
• Не указаны интеграции. Когда на готовом сайте выясняется, что нужен обмен с CRM, доработки стоят дороже, чем если бы это заложили изначально.
• Пропущены SEO-условия. Сайт запускается с нечитаемыми URL, дублями и без микроразметки, а потом приходят SEO-специалисты и просят всё переделать.
• Не определён ответственный за контент. Это убивает сроки. Дизайн и код готовы, но сайт пустой, потому что тексты «ещё не готовы».
• Отсутствуют критерии приемки. Без них невозможно завершить проект: заказчик всегда хочет что-то добавить, а подрядчик уже устал.
• Злоупотребление фразой «на усмотрение разработчика». Она допустима только в очень узких технических местах (например, выбор конкретного плагина для кеширования). Во всём остальном такая формулировка снимает ответственность с исполнителя и перекладывает риск на заказчика. Итог почти всегда разочаровывает.

Как писать ТЗ, если сайт делает фрилансер или студия

Часто слышу: «Мы маленький проект, нам полноценное ТЗ не нужно». Это опасное упрощение. Даже для простого лендинга и одного исполнителя нужна минимальная ясность. Для фрилансера и небольшой студии достаточно короткого, но ёмкого документа.

В таком ТЗ я обычно фиксирую:

• цель проекта и портерт клиента;
• структуру (как правило, несколько страниц или одна с якорями);
• список блоков и их очерёдность;
• функционал (формы, кнопки, попапы);
• референсы по дизайну;
• сроки и условия приёмки.

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

Что приложить к ТЗ

Чтобы документ стал действительно рабочим, а не просто текстом, подкрепите его дополнительными материалами:

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

Чек-лист перед отправкой ТЗ в разработку

Перед тем как отдавать документ подрядчику, пройдитесь по этому списку. Он выручал меня не раз, когда казалось, что всё учтено, а по факту дыры оставались:

• Цель сайта описана чётко, без разночтений.
• Аудитория понятна, есть хотя бы один реальный сценарий использования.
• Структура страниц зафиксирована, все разделы на месте.
• Ключевые страницы расписаны поблочно.
• Функционал перечислен с деталями работы.
• Дизайн не описан расплывчато — есть референсы или брендбук.
• Мобильная версия учтена, прописаны отличия от десктопа.
• SEO-требования добавлены (метатеги, ЧПУ, микроразметка).
• Ответственные за контент определены, есть сроки предоставления материалов.
• Этапы и сроки указаны, зафиксировано количество кругов правок.
• Критерии приёмки есть — и заказчик, и команда понимают, что считать готовым результатом.

Вывод

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

Относитесь к ТЗ как к фундаменту. Не поленитесь собрать его один раз нормально — дальше всё пойдёт чётче и спокойнее.

FAQ

Сколько страниц должно быть в ТЗ на сайт?

Ровно столько, сколько нужно для однозначного понимания проекта обеими сторонами. Для простого лендинга может хватить 3–5 страниц описания. Для интернет-магазина или сервиса — от 15 до 30 страниц, включая таблицы, прототипы и сценарии. Объём не самоцель, важна полнота.

Нужно ли делать ТЗ для небольшого сайта?

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

Кто должен писать ТЗ: заказчик или разработчик?

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

Можно ли наачать разравотку без ТЗ?

Техниески — да. Но риск переделок и недопонимания взлетает кратно. В коммерческой разработке, будь то фриланс или студия, это почти всегда плохая идея. Я категориески не рекомедую запускать проект без зафиксированных договорённостей, потому что в 9 из 10 случаев это приводит к конфлитам или доплатам на финале.

Чем ТЗ отличается от прототипа?

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