Как составить ТЗ на сайт, приложение или AI-продукт: 12 разделов, пример и 9 ошибок
12 разделов ТЗ на сайт или AI-продукт: признаки провала каждого, формулировки «плохо — хорошо», 9 ошибок заказчика и приёмка по измеримым критериям.
Коротко
Материал актуален на 05.10.2026.
- ТЗ (техническое задание) — это документ, по которому результат разработки можно принять. Если пункт нельзя проверить командой, замером или скриншотом, это пожелание, а не требование.
- Рабочая структура — 12 разделов: от контекста и приоритетов P0/P1/P2 до чеклиста приёмки и списка «чего трогать нельзя».
- Каждое требование пишите парой «факт — критерий»: не «сайт должен быть быстрым», а «LCP не выше 2,5 с на мобильном замере». В нашем аудите скорости исходный LCP был 12,5 с при норме не выше 2,5 с — цифра убирает спор о вкусах.
- Приёмка — часть ТЗ, а не разговор после сдачи. В нашем кейсе AI-продукта прогон дал 16 из 16 функциональных и 33 из 33 визуальных проверок, потому что проверки были описаны до начала работ.
- Юридически ТЗ работает в связке с договором подряда: ст. 703 ГК РФ (работа с передачей результата), ст. 720 ГК РФ (приёмка), ст. 1296 ГК РФ (права на программу для ЭВМ, созданную по заказу).
Чем плохое ТЗ отличается от отсутствия ТЗ?
Отсутствие ТЗ — это когда всё решается на ходу, а каждое расхождение становится предметом торга. Плохое ТЗ хуже: оно выглядит как документ, но принять работу по нему нельзя. Формулировки «быстро», «красиво», «как у конкурентов» не дают подрядчику ориентира, а заказчику — основания для претензии.
По умолчанию закон исходит из того, что у работы есть результат. Пункт 1 ст. 703 ГК РФ (часть вторая, ред. от 24.06.2025): «Договор подряда заключается на изготовление или переработку (обработку) вещи либо на выполнение другой работы с передачей её результата заказчику». То есть результат обязаны передать — а вот что именно считается результатом, определяет ТЗ. Без него стороны имеют в виду разные вещи и узнают об этом на приёмке.
Хорошая новость: ТЗ не обязано быть толстым. Наше реальное ТЗ на код-правки сайта заняло 38 КБ текста с замерами, а ТЗ на внутренний AI-продукт — 103 раздела, и отклонение от любого из них считается дефектом, если оно не задокументировано. Подробно о том, к чему приводят размытые требования, мы писали в статье «Почему AI-проекты не окупаются: 9 ошибок бизнеса до запуска разработки».
Какие 12 разделов включить в ТЗ на сайт, приложение или AI-продукт?
Ниже — структура, которую мы используем сами: по ней собрано и наше ТЗ на код-правки, и задания на разработку для клиентов. Третий столбец — признак, что раздел провален: если узнаёте его в своём документе, раздел нужно переписать.
| Раздел | Что пишем | Признак, что раздел провален |
|---|---|---|
| 1. Контекст и цель | Что за бизнес, для кого продукт, зачем он именно сейчас. Что знать до начала: стек, ограничения, где живут данные. | Исполнитель вынужден догадываться, «для чего это всё». |
| 2. Предмет работ | Что именно создаётся или правится — списком, в терминах результата, а не технологии. | Формулировки вида «улучшить сайт» без перечня изменений. |
| 3. Объём и приоритеты | Каждому пункту — приоритет. В нашем ТЗ: P0 — без этого продвижение невозможно или есть риск взлома; P1 — заметно влияет; P2 — гигиена. | «Важно всё», порядка работ нет. |
| 4. Требования к пунктам | Текущий замер, целевое значение, способ проверки. Факт и критерий — в одном пункте. | «Быстро», «удобно», «современно» без единой цифры. |
| 5. Чего трогать нельзя | Поля, модули, интеграции, договорённости, которые ломать запрещено. В нашем ТЗ — семь таких запретов. | После выката молча ломается соседняя функциональность. |
| 6. Интерфейс и UX | Экраны, состояния, поведение при ошибке и на пустых данных. | На приёмке спорят «это не то, что мы представляли». |
| 7. Данные и интеграции | Источники данных, форматы, доступы, кто владеет ключами API. | Данные и пароли передаются на словах в мессенджере. |
| 8. Нефункциональные требования | Скорость, безопасность, нагрузка, доступность — с пороговыми значениями. | Требования «всплывают» после оплаты, как доработки. |
| 9. Критерии приёмки | Чеклист проверок, которые запускаются без доступа к серверу: команды, скриншоты, ожидаемые значения. | Приёмка выглядит как «посмотрим и решим». |
| 10. Порядок работ и этапы | Этапы с зависимостями и оценкой трудоёмкости. У нас: безопасность, затем пререндер и мета, затем вёрстка, разметка, изображения, доступность. | Сроки сдвигаются без объяснения причин. |
| 11. Отчётность и изменения | Что присылает исполнитель после этапа, как фиксируются отклонения и сознательно отложенные пункты. | Отклонения обнаруживаются только на финальной приёмке. |
| 12. Приложения | Формулы, скриншоты, словарь терминов, ссылки на первоисточники. | Сложная геометрия и логика описаны словами «на глаз». |
Два приёма из нашего ТЗ, которые стоит забрать себе. Первый — раздел «что знать до начала»: наблюдаемый снаружи стек, таблица маршрутов, где физически лежит контент. Второй — приложения с формулами вместо слов.
Геометрию среза обложки статьи мы описали не прилагательными, а расчётом: при высоте контейнера 500 px и кадре 1280×720 масштаб равен W/1280, а срез с каждой стороны — (720·W/1280 − 500)/2 / (720·W/1280). Отсюда 16,1 % на вьюпорте 1440, 19,8 % на 1600 и 25,2 % на 1920. Разработчик может перепроверить каждое число сам — и спорить не о чем.
Как формулировать требования: четыре пары «плохо — хорошо»
Все примеры — из нашей практики: ТЗ на код-правки сайта и аудитов скорости. Слева — то, что заказчики пишут чаще всего, справа — то, что можно принять.
| Плохо | Хорошо |
|---|---|
| «Сайт должен загружаться быстро» | «LCP не выше 2,5 с и FCP не выше 1,8 с в мобильном замере на 4G. Базовый замер: LCP 12,5 с, отчёт сохранён текстом и скриншотом». |
| «Сделать так, чтобы обложка не обрезалась» | «На вьюпортах 1440, 1600 и 1920 значимая полоса кадра 1280×720 (y 190…530) видна целиком; подтверждение — скриншот на каждом разрешении». |
| «Защитить админку от посторонних» | «Запрос на запись данных без сессии возвращает 401, с валидной сессией — 200. Проверка на staging: на проде боевая база лидов». |
| «При необходимости доработать по ходу» | «Отступление от эталонного стека фиксируется в GAP-отчёте с причиной и способом вернуться к эталону. Незадокументированное отступление — дефект». |
Общий принцип один: формулировку «хорошо» можно проверить командой, скриншотом или сохранённым отчётом. Формулировку «плохо» — нельзя, поэтому она и порождает переделки.
Почему ТЗ проваливается: 9 типичных ошибок заказчика
- Критерии заменены прилагательными. «Быстрый», «стильный», «интуитивный» не принимаются никем. Спор превращается в спор о вкусах, а он не решается договором.
- Нет приоритетов. Когда всё — P0, исполнитель делает то, что ему удобнее, а не то, что важнее для бизнеса.
- Нет раздела «чего трогать нельзя». Правка одного блока молча ломает соседний. В нашем ТЗ — отдельный список: поля контента в БД, контракт админки, сессионные пути без теста на staging.
- Цифры без способа измерения. «Тормозит» — не факт. Факт — «LCP 12,5 с в мобильной эмуляции, сеть 4G с низкой скоростью, отчёт сохранён».
- Заказчик диктует средства вместо результата. Библиотеки и фреймворки — зона подрядчика. Ваша зона — что измеряется на выходе и какие пороги считаются успехом.
- Приёмку не описали до начала работ. П. 1 ст. 720 ГК РФ (ред. от 24.06.2025): «Заказчик обязан в сроки и в порядке, которые предусмотрены договором подряда, осмотреть и принять работу». То есть порядок приёмки должен существовать заранее — в договоре и в ТЗ.
- Устные договорённости не попали в документ. «Мы же обсуждали» не работает. Правило из нашего ТЗ на 103 раздела: отклонение считается дефектом, если оно не задокументировано.
- Нет порядка работ и зависимостей. В аудите скорости сжатие и вес идут перед архитектурой рендеринга, потому что усиливают её эффект. Переставьте этапы местами — потеряете часть результата.
- ТЗ не связано с договором. Документ, который живёт отдельно от договора подряда, в спорной ситуации остаётся просто файлом.
Как принимать результат по ТЗ?
Приёмка — это зеркало разделов ТЗ: на каждый проверяемый пункт нужен свой тест. Наше ТЗ на код-правки заканчивается чеклистом из 11 команд, которые заказчик запускает с локальной машины, без доступа к серверу: размер и число слов в серверном HTML, наличие каноника, заголовки безопасности, коды ответов API, мобильный скролл, снимки обложки на трёх разрешениях.
Как это выглядит в нашем собственном конвейере контента. Каждая статья перед записью проходит гейт: 19 проверок на серверный HTML с ботовым user-agent, на мобильном — ширина документа ровно 390 px, чтобы страница не растягивалась таблицами. Запись в базу подтверждается read-back по 41 полю: «записалось» не утверждается без обратной проверки. Точечные правки идут по схеме «план — гейт — применение — обратная проверка» со списками фраз, которые обязаны появиться и обязаны исчезнуть.
Тот же принцип в кейсе «AI-продукт с нуля: локальный ассистент с приёмкой 16 из 16 и 33 из 33»: функциональные проверки гоняют реальный pipeline импорта, визуальные снимают каждый экран headless-браузером и сверяют с макетом. После смены темы прогон повторили — снова 16 из 16 и 33 из 33. А в аудите скорости сайта приёмка правок — это ровно тот же прогон в тех же условиях плюс полевые данные CrUX через 28 дней. Подробнее о механике гейтов — в статье «Гейты качества при сборке сайта».
Что сделать сегодня: три шага без подрядчика и без бюджета
- Напишите цель на одну страницу. Для кого продукт, какую задачу решает, каким числом вы поймёте, что получилось. Признак готовности: незнакомый с темой человек после чтения пересказывает цель своими словами без искажений.
- Соберите список «чего трогать нельзя». Действующие интеграции, данные, договорённости с текущими подрядчиками, дизайн-решения. Это пятнадцать минут работы, которые экономят недели переделок.
- Разложите хотелки по P0/P1/P2. P0 — без этого запуск невозможен, P1 — заметно влияет, P2 — гигиена. Признак провала: все пункты оказались в P0 — значит, приоритеты не выбраны.
Эти три шага уже превращают «нужен сайт» в заготовку ТЗ, с которой можно идти к любому подрядчику и сравнивать его ответы.
Где заканчивается самостоятельное ТЗ и нужен разработчик или юрист?
Честная граница такая. Цель, объём, бизнес-критерии, приоритеты и список запретов заказчик пишет сам — и сделает это лучше любого подрядчика, потому что знает свой бизнес.
Базовые технические замеры — уже не ваша зона. Чтобы написать «LCP не выше 2,5 с», нужен исходный замер: вес страницы, цепочка критических запросов, заголовки ответов. В нашем кейсе «Технический аудит скорости коммерческого сайта» такой замер превратился в ТЗ на 26 пунктов: 6 блокирующих, 13 важных, 7 улучшений. Самостоятельно повторить это без инструментов нереально, и это нормально.
Договорные формулировки — зона юриста. Особенно права на код. П. 1 ст. 1296 ГК РФ (часть четвёртая, в ред. ФЗ от 12.03.2014 № 35-ФЗ): исключительное право на программу для ЭВМ, базу данных или иное произведение, созданные по договору (по заказу), принадлежит заказчику, если договором не предусмотрено иное. То есть по умолчанию результат ваш, но одна строка в договоре переворачивает это «по умолчанию». Как отличать сильных исполнителей от слабых — в материале «Как выбрать AI-подрядчика: 12 критериев».
В задании фиксируют сумму, а не налоговую рамку. С 1 октября 2026 года применяют поправки в статьи 166 и 168 НК РФ (293-ФЗ): для длящегося договора, где цену не меняли и в тексте нет условия на такой случай, НДС берут расчётным методом из цены договора. Что проверить в контракте на разработку — в разборе 293-ФЗ.
Как проверить подрядчика по его отношению к ТЗ?
Сильный подрядчик не боится ТЗ — он помогает его уточнить: задаёт вопросы про критерии до оценки сроков, предлагает измеримые формулировки вместо прилагательных и сам пишет раздел «чего трогать нельзя». Слабый — уговаривает «не бюрократизировать» и оценить «примерно».
Если требования нужно собрать с нуля, начните с двух наших материалов: «Как создать AI-MVP и не слить бюджет» про объём первой версии и «Не покупайте AI-агента, пока не ответите на эти 10 вопросов» про вопросы до подписания договора. Оба кейса выше — приёмка AI-продукта 16 из 16 и ТЗ на 26 пунктов из аудита — показывают, как документ с критериями выглядит в работе.
Мы в Artifica начинаем разработку с консультации и аудита требований: собираем цели и ограничения, снимаем базовые замеры и превращаем их в ТЗ с приоритетами, критериями приёмки и списком запретов — таким, по которому результат можно принять командой или скриншотом. Отдельной строки в прайсе на «составить ТЗ» нет: это часть предпроектной работы. Напишите нам через страницу контактов — в ответ на заявку вы получите не коммерческое предложение «от и до», а список уточняющих вопросов и черновик разделов ТЗ под вашу задачу.