Как составить ТЗ на разработку сайта

Привет!

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

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

Что такое ТЗ и зачем оно нужно

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

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

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

Если сформулировать совсем коротко, ТЗ напрямую влияет на три вещи, которые вас волнуют: сроки, стоимость и качество. Всё остальное в этой статье — расшифровка того, как именно.

Чем ТЗ не является

Важно сказать о том, чем ТЗ не является:

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

Отличия брифа и ТЗ

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

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

Кто и когда пишет ТЗ

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

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

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

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

Главный принцип: требование — это то, что можно проверить

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

Когда вы пишете строчку в ТЗ, задайте себе один вопрос: если мне сделают не то, что я просил, смогу ли я предъявить и доказать, что результат не соответствует требованию?

Это не про недоверие к подрядчику. Это про то, что вы сами лучше понимаете, чего хотите. А чем лучше вы понимаете, тем выше шансы получить то, что надо.

Прогоните через этот вопрос типичные формулировки:

• «Современный дизайн». Современный для бумеров или зумеров?
• «Продающий сайт». Ну подрядчик же вам его продал.
• «Побольше воздуха». Спросите у дайверов, сколько это.
• «Сайт должен быстро загружаться». 60 км/ч вас устроит?

Формулировки похитрее вроде «дизайнерский шаблон, близкий тематике „аксессуары для смартфонов“» спасут вас от того, что на сайт загрузят изображения газонокосилок, но в реальности мало что дадут. Лучше последовательно расписать структуру, контент и стили.

Пример, на котором всё видно

Возьмём требование к скорости. Допустим, вы где-то прочитали про LCP и написали в ТЗ: LCP не более 2 секунд.

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

Есть два способа, и мне бы очень хотелось назвать их хорошим и плохим, но дьявол в деталях.

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

Способ второй. На задеплоенном стенде (а в каких-то случаях и на локальной машине) разработчик просто откроет консоль браузера, посмотрит цифру, возможно, пару раз обновит страницу, чтобы она стала покрасивее, и на этом остановится.

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

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

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

Критерии хорошего требования

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

Полнота. В тексте есть вся нужная информация. Нет скрытых или пропущенных деталей.

Однозначность. Не допускает двух прочтений. «Страница загружается за 2–3 секунды» — это за 2 или за 3? На приёмке вы узнаете, что за 3.

Непротиворечивость. Требования не должны конфликтовать друг с другом.

Проверяемость. Есть способ ответить «да» или «нет» без спора о вкусах.

Атомарность. Одна строка — одна мысль. Если в требовании три условия через запятую, на приёмке окажется, что вам выполнили два.

Про технологии

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

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

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

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

Что должно быть в ТЗ

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

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

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

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

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

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

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

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

Интеграции. 1С, CRM, платёжные системы, службы доставки, SMS-шлюзы, аналитика. Это раздел, который может сильно вас удивить, особенно если окажется, что интегрироваться нужно с 7-й версией модифицированной 1С, выпущенной в 96 году конторой, которой давно не существует.

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

Контент. Здесь два вопроса, и оба денежные.

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

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

И отдельно: «контент наш» — частая причина срыва сроков. Кто и к какому числу передаёт материалы, стоит зафиксировать письменно.

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

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

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

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

Нефункциональные требования

Здесь есть важная развилка, которую полезно понимать заранее.

Часть требований — это просто базовая гигиена. sitemap.xml, robots.txt, SSL-сертификат, человекопонятные адреса, внутренняя перелинковка, отсутствие битых ссылок. Прописать их не будет лишним, но такие вещи не должны влиять на стоимость: они просто должны быть, как электричество в арендованном офисе. Если подрядчик выставляет за них отдельную строку в смете — это повод задать вопрос.

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

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

Адаптивность. Кажется само собой разумеющимся, но пропишите отдельно. И задумайтесь, нужна ли она в вашем случае в полном объёме. Если вы разрабатываете корпоративный портал, которым пользуются сотрудники, и вы точно знаете, что это происходит с десктопа, — приоритеты меняются. В таких проектах дизайн вообще отходит на второй план, потому что задача не привлекать и не продавать, а выполнять функцию.

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

Доступность. Стоит ли требовать соответствия стандартам — зависит от проекта. Но базовые вещи (контраст, читаемость, навигация с клавиатуры по ключевым сценариям) обычно стоят недорого, а пользу приносят всем. Детали, например про WCAG, можно почитать тут.

Безопасность. Защита от типовых веб-уязвимостей, разграничение прав доступа, защита форм от спама.

Локализация и требования законодательства. Языки, валюты, форматы дат. Для России — работа с персональными данными по 152-ФЗ (согласия, политика конфиденциальности, размещение данных), для интернет-магазинов — 54-ФЗ и онлайн-чеки. Если планируете использовать зарубежные системы аналитики, нужно помнить про вопросы трансграничной передачи данных и уведомления регулятора: это отдельная тема, в которой цена ошибки измеряется не в часах разработки.

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

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

Требования к окружению и эксплуатации

Вопросы эксплуатации, в отличие от разработки, будут преследовать вас гораздо дольше.

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

Хостинг. Стоимость, расположение серверов, конфигурация. Многие хостинги предлагают дополнительные услуги, которые вам, скорее всего, не нужны, особенно для несложного сайта. Обсудите со специалистом, почему он предлагает именно такой вариант.

Окружения. Нужен ли отдельный тестовый стенд. Требуется далеко не всем, но если всё-таки да, то это должно быть написано.

Резервное копирование. Частота, срок и место хранения, процесс восстановления.

Логи и мониторинг. Что и как долго хранится, кто получает уведомления о падениях. Когда у клиента не пройдёт оплата, без логов вы даже не узнаете, что у вас был потенциальный покупатель.

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

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

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

Чего в ТЗ всё равно не будет

Теперь неприятная правда: ТЗ не бывает стопроцентным. Всё прописать невозможно.

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

Но из этого следует практический вопрос: что делать с тем, что не прописали? И здесь важно понимать разницу между двумя вещами.

Дефект — это расхождение с требованием. Требование есть, оно проверяемое, результат ему не соответствует. Такое исправляется в рамках работ и за счёт исполнителя.

Новая хотелка — это требование, которого не было. Или было, но такое, что проверить его нельзя. Такое стоит либо денег, либо времени, а чаще и того, и другого.

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

Как вести документ

Формальная сторона проще, чем кажется.

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

Версионирование обязательно: номер версии, дата, список изменений. Сейчас очень просто скинуть всю эту рутину на нейросети.

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

Ещё стоит упомянуть, что на ТЗ есть ГОСТы, например ГОСТ 34.602-2020 и ГОСТ 19.201-78. Но это отдельная тема, и погружаться в неё имеет смысл, только если вы крупный государственный заказчик.

Часть вторая: ТЗ, написанное нейросетью

Перейдём к практике. Я зашёл с позиции клиента, который хочет интернет-магазин, и попросил нейросеть проинтервьюировать меня и составить ТЗ. Получил документ на четырнадцать страниц и одиннадцать разделов. Разберём, что вышло.

Как проходило интервью

Я использовал Opus 5 со следующим запросом: «мне нужен сайт для интернет-магазина, проинтервьюируй меня, чтобы составить ТЗ на разработку».

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

Я отвечал, целясь в нечто усреднённое: электроника, от 100 до 1000 товаров, розница в России, есть бренд и логотип, курьерская доставка и самовывоз по одному городу, учёт в 1С, нужны личный кабинет, сравнение и избранное, SEO и промокоды, дизайн индивидуальный, первичная загрузка каталога от разработчика, срок два-четыре месяца.

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

Заняло всё минут десять.

Чтобы не быть голословным — полная выгрузка ниже, из неё видно всё, о чём пойдёт речь в замечаниях (убраны только служебные строки интерфейса):

Результат

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

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

Что сделано хорошо

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

Сквозные сценарии в приёмке. «Проверка сквозных сценариев: поиск → карточка → корзина → чекаут → оплата → заказ в 1С → уведомления». Это уже больше похоже на критерий приёмки, чем «сайт работает».

Права и передача. Прямо прописана передача заказчику исходного кода, всех доступов и учётных записей, а также требование об отсутствии лицензионных рисков.

Законодательство. Модель сама, без наводящих вопросов, вспомнила про 152-ФЗ и 54-ФЗ, потребовала размещения персональных данных на серверах в РФ и фискализации чеков.

Замечание 1. Формулировки, которые нельзя проверить

Их много, и они рассыпаны по всему документу. Так что приведу только пару примеров.

Требование к платформе: интеграция с 1С «из коробки или через проверенный модуль». Проверенный кем и как? Уточнение, которое ничего не уточняет, а лишь добавляет шума и ложной уверенности.

Там же: решение должно быть «экономически обоснованным для проекта соответствующего масштаба». Вас тоже обдало бессмысленным канцеляризмом?

Дизайн: «соответствие макетов и вёрстки (pixel-perfect в разумных пределах)». Если вы дочитали до этого момента, то комментарии излишни.

Замечание 2. Требования без методики проверки

Раздел о производительности: «Время загрузки ключевых страниц — не более 2–3 секунд при нормальной нагрузке».

В одной строке собраны сразу несколько проблем. Вилка вместо числа — это 2 или 3? Не названа метрика — загрузка чего именно: первый ответ сервера, отрисовка основного контента, полная загрузка страницы? Не определена «нормальная нагрузка». Не заданы условия замера — какое устройство, какая сеть.

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

То же с бэкапами: «регулярное резервное копирование и процедура восстановления» — регулярное это как часто, храним сколько, как происходит восстановление?

Замечание 3. Требования, взявшиеся из ниоткуда

Вот это, на мой взгляд, самое интересное — и увидеть это можно, только сравнив документ с диалогом.

Про нефункциональные требования меня не спросили ничего. Ни про скорость, ни про нагрузку, ни про браузеры, ни про бэкапы, ни про домен, ни про хостинг, ни про права, ни про критерии приёмки. При этом в документе всё это есть.

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

Замечание 4. Детализация скачет

Карточка товара расписана хорошо: галерея с зумом, вкладки, вариации с пересчётом цены, блоки кросс-продаж, микроразметка, SEO-поля.

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

С 1С похоже: описано, чем обмениваемся и в какую сторону, но не описано, что происходит при конфликте данных или при сбое обмена. Частота обмена задана как «регулярный автоматический обмен по расписанию» — а мы помним, что для остатков электроники это ключевой параметр.

Главная страница — одна строка на весь раздел, при том что для магазина это витрина. Не описаны и остальные типовые страницы вроде «О компании».

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

Замечание 5. Эксплуатация почти не описана

Про домен в документе нет ни слова. Хостинг описан как «серверы в РФ». Логов и мониторинга нет. Порядка выкладки обновлений нет. Аналитика упомянута, но опять же размыто — «Яндекс Метрика, при необходимости цели и электронная коммерция».

Всё это всплывёт после запуска, когда договариваться будет уже поздно.

Вывод по эксперименту

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

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

Что с ним делать дальше, по приоритету:

1. Отметить требования, которых не было в вашем разговоре, и разобраться с каждым.
2. Переписать нефункциональные требования: числа, условия, методика проверки.
3. Проработать фильтры, поиск и логику обмена с 1С — вместе со специалистом, здесь доменная экспертиза важнее формулировок.
4. Дописать блок эксплуатации: домен, хостинг, доступы, бэкапы, логи, права.
5. Убрать «желательно» и «опционально», заменив на явный статус.
6. Определиться с платформой и прочими технологиями. Это хоть и не превратит ТЗ в документацию по системе, но поможет продолжить работу с другим подрядчиком, которому не придётся тратить время на реверс-инжиниринг.

Так выглядит, например, отрефакторенное требование к производительности:

Было

Время загрузки ключевых страниц — не более 2–3 секунд при нормальной нагрузке.

Стало

LCP главной страницы, страницы категории и карточки товара — не более 2,5 секунд. Замер: инструмент разработчика в браузере на продуктивном окружении, мобильный профиль, эмуляция соединения 4G, три последовательных замера, засчитывается медианное значение. Проверка проводится на карточке товара с полностью заполненными характеристиками и галереей от восьми изображений. Нагрузочное тестирование в объём работ не входит.

Последняя фраза здесь не менее важна, чем всё остальное: она снимает будущий спор о том, что именно было обещано.

И главное про нейросети

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

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

Что в итоге

ТЗ стоит потраченного на него времени. Оно определяет сроки, стоимость и качество проекта, и это тот этап, где ваше личное участие даёт максимальную отдачу.

Если запомнить из статьи одну вещь, пусть это будет вопрос, который стоит задавать каждой строчке: если мне сделают не то, что я просил, смогу ли я это доказать?

Шаблон я специально не прикладываю: в чужой рыбе мало смысла, потому что вы всё равно будете вычёркивать не своё и не заметите недостающего. Вместо этого — выгрузка моего диалога с Claude (выше, в разделе про интервью) и получившееся в результате ТЗ.

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