Вопросы для ТЗ: универсальный шаблон, который спасает от переделок

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

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

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

Что такое вопросы для ТЗ и когда они спасают

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

Они спасают в нескольких ситуациях:

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

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

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

Специфика ниши: вопросы для ТЗ

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

1. Вопрос должен создавать обязательство, а не просто информировать

Плохой вопрос: «Какой хотите дизайн?» Он собирает вкус, но не фиксирует результат. Лучше: «Какие 2–3 референса вам нравятся и что именно в них важно: цвет, композиция, шрифт, настроение?» Такой ответ можно перенести в ТЗ и использовать как критерий приёмки.

Хороший вопрос всегда заканчивается проверяемым следствием: числом, форматом, сроком, списком, доступом, документом, сценарием или критерием.

2. Слишком много вопросов парализует проект

Соблазн — отправить заказчику список из 80 пунктов. В реальности его либо не заполнят, либо заполнят формально. Лучше разделить вопросы на три уровня:

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

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

3. Разные ниши требуют разной глубины

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

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

4. Ответы должны быть привязаны к разделам ТЗ

Бессмысленно собирать ответы «в пустоту». Каждый блок вопросов должен映射иться на раздел документа:

• цель — в раздел «Задача и метрики»;
• аудитория и сценарии — в «Пользовательские пути» или «Контент»;
• объём — в «Что входит / не входит»;
• технические требования — в «Функционал», «Дизайн», «Оборудование», «Материалы»;
• сроки — в «Этапы»;
• приёмка — в «Критерии готовности»;
• правки — в «Порядок изменений».

Если ответ не попадает ни в один раздел, он либо лишний, либо указывает на пропущенный блок ТЗ.

5. Вопросы выявляют скрытые допущения

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

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

Структура вопросов для ТЗ

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

1. Цель и бизнес-задача

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

• Какую бизнес-проблему должен решить проект?
• Какое целевое действие должен совершить пользователь, зритель, покупатель или внутренний сотрудник?
• Как мы поймём, что задача выполнена успешно: по метрикам, сроку, объёму, качеству, конверсии?
• Есть ли у проекта жёсткая дата запуска, отчёт, событие, сезонность?
• Что важнее: скорость, бюджет, качество, функциональность, соответствие бренду, юридическая чистота?
• Есть ли уже похожие решения, которые работали или провалились?

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

2. Требования: функциональные, качественные и ограничивающие

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

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

Примеры вопросов:

• Какие функции обязательны для запуска, а какие можно отложить?
• Есть ли требования к скорости, нагрузке, точности, мощности, размеру, весу, цвету, формату?
• Какие стандарты, ГОСТ, СП, регламенты, правила площадок или внутренние политики необходимо соблюдать?
• Есть ли запрещённые приёмы, слова, изображения, материалы, технологии?
• Какие интеграции, сервисы, оборудование, доступы, API или данные нужны?
• Кто отвечает за подготовку входных материалов: текстов, фото, чертежей, списков, допусков, макетов?

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

3. Объём: что входит и что не входит

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

• Какие артефакты входят в результат: страницы, экраны, макеты, файлы, чертежи, отчёты, исходники, документация?
• Сколько объектов нужно обработать: товаров, страниц, видео, деталей, сцен, документов?
• Что точно не входит в задачу, но может быть ошибочно ожидаемо заказчиком?
• Есть ли MVP и вторая очередь?
• Кто предоставляет материалы, доступы, согласования, тестовые данные?
• Как считаем изменение объёма: новая задача, допсоглашение, почасовая оплата, фикс?

Формулировка «что не входит» часто полезнее, чем длинный список того, что входит. Она снимает иллюзии.

4. Сроки, этапы и зависимости

Срок без этапов — это лотерея. Лучше разбить проект на точки контроля.

• Когда нужен финальный результат?
• Есть ли промежуточные дедлайны: концепт, черновик, прототип, первая партия, тестовая версия?
• От чего зависит срок: от согласований, доступов, материалов, оплаты, внешних сервисов?
• Кто и в какой срок должен давать обратную связь?
• Что происходит при задержке со стороны заказчика или исполнителя?
• Нужен ли резерв на модерацию, тестирование, доработку, доставку?

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

5. Критерии приёмки

Критерии приёмки отвечают на вопрос: как стороны поймут, что работа готова?

• По каким параметрам будем проверять результат: функциональность, внешний вид, размеры, скорость, формат, количество, соответствие брифу?
• Какие тесты или сценарии нужно пройти?
• Что считается критическим дефектом, а что — допустимым отклонением?
• Кто принимает результат и в какой срок?
• В каком виде оформляется приёмка: акт, сообщение в чате, скриншот, протокол тестирования, отзыв?
• Считается ли работа принятой, если замечания не поступили в установленный срок?

Если критерии приёмки не измеримы, ТЗ не защищает ни заказчика, ни исполнителя. Споры сводятся к вкусовщине, а не к соответствию заданию.

6. Формат передачи и состав результата

Многие конфликты возникают не из-за качества, а из-за того, что стороны по-разному поняли, что именно передаётся.

• В каких форматах сдаётся результат: PDF, DOCX, Figma, AI, EPS, SVG, PNG, JPG, MP4, ZIP, SQL, Excel, CAD?
• Нужны ли исходники, редактируемые файлы, слои, проекты, макеты, чертежи, базы данных?
• Как должны быть названы файлы и структурированы папки?
• Нужна ли документация, инструкция, README, гайд, чек-лист, паспорт изделия?
• Кто и где размещает результат: на диске, в облаке, в репозитории, в CMS, на почте, в чате заказа?
• Есть ли требования к разрешению, цвету, весу файла, формату для печати или публикации?

Для цифровых задач формат передачи часто важнее, чем сам дизайн. Красивый макет без исходников может оказаться бесполезным, а хороший код без инструкции по развёртыванию —难以 поддерживать.

7. Правки, ответственность и порядок изменений

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

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

Блок про правки особенно важен для фриланса. Он защищает исполнителя от бесконечных «поиграем с вариантом» и заказчика от скрытых доплат за то, что изначально должно было входить в задачу.

Примеры применения банка вопросов: сайт, дизайн, разработка

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

Ниша 1: сайт или лендинг

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

• Какие страницы обязательны: главная, услуги, кейсы, блог, контакты, личный кабинет?
• Кто готовит тексты, фото, видео, отзывы, товары?
• Нужна ли CMS и кто будет наполнять сайт после сдачи?
• Какие интеграции обязательны: CRM, аналитика, оплата, доставка, мессенджеры, телефония?
• Какие требования к мобильной версии и скорости загрузки?
• Нужен ли SEO-базис: метатеги, карта сайта, редиректы, микроразметка?
• Как принимается сайт: по страницам, по формам, по скорости, по адаптиву?

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

Ниша 2: дизайн, логотип, айдентика

В дизайне самые опасные слова — «современно», «дорого», «минималистично», «как у Apple». Вопросы должны переводить вкус в носители, форматы и ограничения.

• Где будет использоваться результат: сайт, соцсети, упаковка, вывеска, одежда, презентация, маркетплейс?
• Какой минимальный размер должен выдерживать логотип или знак?
• Нужны ли версии: цветная, чёрно-белая, инверсная, компактная, иконка?
• Есть ли брендбук, фирменные цвета, шрифты, запрещённые приёмы?
• Сколько концептов ожидается и сколько кругов правок входит?
• Нужны ли мокапы, исходники, шрифты в кривых, файлы для печати?
• Кто принимает финальный вариант и по каким критериям?

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

Ниша 3: разработка ПО, приложение, сервис

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

• Какие пользовательские роли и права доступа нужны?
• Какие сценарии обязательны для MVP, а какие откладываются?
• С какими системами нужна интеграция: CRM, 1С, платёжные шлюзы, API, мессенджеры, базы данных?
• Какие требования к нагрузке, скорости отклика, доступности и хранению данных?
• Где будет работать решение: веб, мобильное приложение, десктоп, сервер, облако, локальная сеть?
• Есть ли тестовое окружение, тестовые данные, доступ к репозиторию?
• Как сдаётся результат: код, доступы, документация, инструкция по развёртыванию, тесты?
• Каковы критерии приёмки: пройденные сценарии, отсутствие критических багов, метрики производительности?

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

Как собрать хорошие вопросы для ТЗ

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

1. Начинайте с цели, а не с деталей

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

2. Заменяйте оценки метриками

Вместо «быстрый сайт» — «время загрузки главной до 3 секунд на 4G». Вместо «надёжное оборудование» — «непрерывная работа не менее 72 часов без отказа». Вместо «удобный интерфейс» — «новый пользователь выполняет целевое действие без подсказок за 2 минуты».

3. Спрашивайте про исключения

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

4. Фиксируйте владельцев ответов

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

5. Не бойтесь вопроса «почему это важно?»

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

6. Используйте вопросы как фильтр объёма

Если на вопрос «это входит в первую очередь?» ответ «да, но потом можно упростить», значит, требование нужно декомпозировать. Если ответ «не знаю», это риск. Если ответ «нет, но очень хочется», это будущая новая задача.

Критерии приёмки результата: вопросы для ТЗ

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

• Цель проекта сформулирована измеримо. Понятно, какое действие должен совершить пользователь и как оценивать успех.
• Объём ограничен. Есть список того, что входит, и явный перечень того, что не входит.
• Требования не сводятся к прилагательным. «Быстро», «удобно», «качественно» заменены метриками, стандартами, сценариями или образцами.
• Определены зависимости. Известно, какие доступы, материалы, согласования и внешние сервисы нужны до старта.
• Есть этапы и сроки. Проект разбит на точки контроля, а не висит на одном финальном дедлайне.
• Критерии приёмки проверяемы. Можно пройти тест, сверить формат, проверить размер, количество, скорость, соответствие референсам.
• Формат передачи зафиксирован. Понятно, какие файлы, исходники, документация и доступы передаются заказчику.
• Порядок правок и изменений описан. Указаны лимит итераций, способ фиксации изменений и ответственность сторон.
• Риски названы. Есть хотя бы короткий перечень того, что может пойти не так и как на это реагировать.
• Все ключевые ответы имеют владельца. Не «где-то должно быть», а «кто, что и к какому сроку предоставляет».

Если хотя бы три пункта не закрыты, ТЗ ещё рано считать готовым. Лучше потратить час на уточнения, чем неделю на переделки.

Вопросы для уточнения до старта

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

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

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

Чек-лист готовности ТЗ

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

• Цель проекта и целевое действие сформулированы в одном-двух предложениях.
• Определены объём, MVP и список «не входит».
• Ключевые требования измеримы: сроки, форматы, количество, метрики, стандарты.
• Указаны зависимости: доступы, материалы, согласования, внешние сервисы.
• Есть календарь этапов и срок обратной связи по каждому этапу.
• Определены критерии приёмки и способ их проверки.
• Зафиксирован формат передачи: файлы, исходники, документация, доступы.
• Прописаны правила правок, изменений и ответственности сторон.

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

Как использовать вопросы для ТЗ на Workink

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

Платформа помогает превратить вопросы в рабочую договорённость:

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

Практический совет: не отправляйте исполнителю 50 вопросов сразу. Начните с 10–15 обязательных, а нишевые добавляйте по ходу обсуждения. Так вы получите диалог, а не анкету.

Найти исполнителя Разместить заказ Защита покупателей

Полезные материалы по теме

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