Методика · 20 сентября 2026 г.

Техническое задание на опрос: что должно быть внутри

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

Зачем ТЗ, если можно обсудить всё в чате

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

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

Раздел 1. Контекст и решение

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

Раздел 2. Аудитория и размер выборки

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

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

Раздел 3. Метрики и гипотезы

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

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

Раздел 4. Метод, канал и формулировки-ограничения

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

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

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

Раздел 5. Сроки, бюджет и формат результата

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

Пример короткого заполненного ТЗ

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

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

Как согласовать ТЗ за один заход

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

1. Заполните черновик ТЗ сами по шаблону — легче править готовый текст, чем писать с нуля.
2. Отправьте его сразу всем, чьё согласие нужно, а не по очереди одному за другим.
3. Задайте конкретные вопросы по спорным пунктам вместо общего «посмотрите, пожалуйста».
4. Назначьте дедлайн на правки — без него согласование растягивается на неопределённый срок.
5. Зафиксируйте финальную версию и не меняйте её без явного решения всех согласовавших.

Ограничения формата

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

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

Типичные ошибки

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

С чего начать

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