Как составить техзадание на сайт или бот, чтобы не переплатить

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

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

Зачем нужно ТЗ

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

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

Что включить в ТЗ

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

• Цель и задачи. Зачем вообще нужен этот проект и что он должен приносить. «Собирать заявки на услугу и передавать их в CRM» — это цель. «Сделать красивый сайт» — нет. От цели зависит буквально всё остальное.
• Целевая аудитория. Кто будет пользоваться продуктом: возраст, устройства, уровень технической подготовки. Сайт для пенсионеров и сайт для айтишников проектируются по-разному, и это влияет на трудоёмкость.
• Функции. Что именно продукт должен уметь: регистрация, оплата, фильтры, личный кабинет, уведомления. Каждую функцию — отдельным пунктом. Это главный драйвер стоимости.
• Структура и страницы. Список экранов или разделов: главная, каталог, карточка товара, корзина, контакты. Для бота — список сценариев и команд.
• Интеграции. С какими внешними системами продукт должен работать: CRM, платёжный шлюз, службы доставки, 1С, мессенджеры, аналитика. Забытая интеграция — самая частая причина перерасхода бюджета.
• Примеры и референсы. Ссылки на сайты или боты, которые вам нравятся, с пометкой, что именно нравится: «вот такой каталог», «вот такое оформление заявки». Референс экономит десятки часов объяснений.
• Что НЕ входит. Явно перечислите, чего в проекте не будет: «мобильное приложение не разрабатываем», «наполнением контентом занимается заказчик». Это граница, за которую подрядчик не залезет бесплатно, но и вы не заплатите за лишнее.
• Сроки и этапы. К какой дате нужен результат и можно ли разбить работу на очереди: сначала запуск базовой версии, потом расширение. Этапность помогает не платить сразу за весь функционал.
• Критерии приёмки. Как вы поймёте, что работа сделана. «Форма отправляет заявку на почту и в Telegram, письмо приходит за минуту» — это проверяемый критерий. «Всё работает» — нет.

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

Частые ошибки в ТЗ

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

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

Рабочая структура ТЗ

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

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

FAQ

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

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

Кто должен писать техзадание — заказчик или исполнитель? Идеально — вместе. Заказчик знает бизнес и цели, исполнитель знает, как это реализуемо и во что оценивается. На практике первый черновик чаще делает заказчик, а подрядчик его дополняет и уточняет. Главное — чтобы итоговый документ обе стороны прочитали и согласовали до начала работ и до оплаты.

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

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

Коротко о главном

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