Как написать ТЗ, чтобы подрядчик понял вас с первого раза

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

Шесть блоков хорошего ТЗ

• Цель: что бизнес должен получить — «принимать заявки», «продавать онлайн», «снять нагрузку с менеджеров».
• Аудитория: кто этим пользуется и с какого устройства.
• Сценарии: что человек делает по шагам — «зашёл → выбрал → оплатил».
• Примеры: 2–3 сайта или продукта, которые нравятся, с пояснением чем именно.
• Ограничения: сроки, бюджетная вилка, обязательные интеграции (оплата, CRM).
• Контент: что у вас уже есть (тексты, фото, лого), а что нужно создать.

Чего делать не нужно

Не пытайтесь описать технологии и «как» — это работа подрядчика. Ваша зона — «что» и «зачем». Если по каждому пункту выше есть пара ясных предложений, у вас уже лучшее ТЗ, чем у 80% входящих заявок. Готовые шаблоны ТЗ под сайт, бота и приложение мы выложили бесплатно в разделе «Инструменты».

Что это даёт на практике

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

Что происходит с ТЗ дальше

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

Частые вопросы

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

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

• Цель сформулирована как результат для бизнеса, а не как «сделать сайт».
• Есть 2–3 сценария по шагам: что человек делает от входа до результата.
• Указаны сроки, вилка бюджета и обязательные интеграции — без них оценка будет гаданием.
• Приложены примеры и антипримеры с пояснением, чем именно.
• Понятно, какой контент уже есть, а какой создаём в рамках проекта.

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