Проверка ТЗ перед заказом у разработчика - это то, что отделяет проект, который уложится в бюджет и срок, от проекта с бесконечными допсоглашениями. За практику на Tilda, WordPress, в Telegram-ботах на aiogram и в автоматизациях на n8n я вижу одну и ту же картину: заказчик приносит документ на две-три страницы с формулировкой «сделать красивый сайт с личным кабинетом», и уже на этапе оценки понятно, что реальная стоимость и сроки будут отличаться от написанного. Разберу, на что смотреть в техническом задании перед подписанием договора и переводом предоплаты - независимо от того, кто его составлял: вы сами, менеджер студии или сам исполнитель.
Зачем проверять ТЗ, если его писал не ты
Техническое задание - это единственный документ, на который можно опереться при споре о том, что входило в стоимость, а что - нет. Если в нём написано «интеграция с оплатой» без деталей, а через месяц выясняется, что заказчик имел в виду рекуррентные платежи и разбивку по чекам для налоговой, а разработчик посчитал обычный приём разовых платежей - доплата за доработку почти неизбежна.
Похожая история была на проекте с интернет-магазином на WooCommerce: в ТЗ значилось «подключить эквайринг Т‑Банка», без указания, нужна ли обработка статусов оплаты через вебхуки, отмена заказа при неуспешном платеже и возврат средств из панели администратора. Простое подключение виджета - это одна цена и один срок, а полноценная синхронизация статусов заказа с банком - совсем другая задача по трудозатратам. Спор возник именно потому, что в ТЗ не было зафиксировано, какой из двух вариантов оплачен.
Из каких разделов должно состоять техническое задание
Проверка технического задания начинается с простого вопроса: можно ли по этому документу восстановить объём работ, если разработчик исчезнет на середине проекта. Если нет - документ неполный, вне зависимости от того, сколько в нём страниц.
Рабочее ТЗ обычно закрывает такие блоки:
- Цель проекта и краткое описание бизнес-процесса, который автоматизируется или переносится в цифру
- Список экранов, страниц или сценариев с описанием, что на них происходит
- Нефункциональные требования: хостинг, ожидаемая нагрузка, требования к скорости загрузки
- Перечень интеграций с указанием конкретных сервисов и их API-версий, а не просто «CRM» или «доставка»
- Макеты или референсы дизайна, либо явное указание, что дизайн разрабатывается по ходу проекта
- Критерии приёмки для каждого пункта - что именно проверяется при сдаче этапа
- Сроки по этапам, а не единая дата «через два месяца»
Для Telegram-бота на aiogram, например, недостаточно написать «бот с оплатой и админкой». Нужно зафиксировать сценарии конечного автомата (FSM): какие состояния проходит пользователь, что происходит при обрыве диалога, хранятся ли данные в базе или только в памяти процесса, работает ли бот через polling или через вебхук на сервере. Без этого разработчик оценивает проект «на глаз», и итоговая цена почти всегда выше первой озвученной.
Как проверить формулировки и сроки в документе
В плохих ТЗ обычно повторяются одни и те же слова-паразиты: «и так далее», «по возможности», «современный дизайн», «включая, но не ограничиваясь». Каждое такое место - потенциальная точка спора на приёмке, потому что трактовать формулировку можно как угодно.
Проверка ТЗ перед заказом у разработчика на практике сводится к тому, чтобы напротив каждого пункта поставить вопрос «как я пойму, что это сделано». Если ответа нет - пункт нужно переписать в измеримую форму: не «удобная фильтрация товаров», а «фильтр по цене, категории и наличию с обновлением списка без перезагрузки страницы».
То же самое со сроками. Сайт на Tilda с готовым ТЗ и утверждённым дизайном у меня обычно занимает 5-10 рабочих дней от старта работ. Если в документе нет разбивки по этапам с датами приёмки, а есть только общая фраза «срок - три недели», риск в том, что все правки, включая мелкие, будут накапливаться до самого конца, и именно в последнюю неделю окажется, что нужно переделывать половину макета.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Проверка интеграций: где чаще всего теряются деньги
Интеграции - самая частая причина расхождения между ТЗ и счётом на доплату, потому что в общих формулировках прячется разный объём работы.
По СДЭК формулировка «доставка через СДЭК» может означать три разных вещи: виджет расчёта стоимости на сайте, полноценную интеграцию с созданием заказов и трек-номеров через API, либо только статичный тариф без реального расчёта. Разница в трудозатратах - кратная, а значит и в стоимости: простая доработка на Tilda обычно от 3 000 ₽, а комплексная интеграция с CRM, эквайрингом или СДЭК - от 40 000 ₽.
По n8n то же самое: «настроить автоматизацию» ничего не говорит о количестве сценариев, триггерах и системах на другом конце цепочки. Один workflow с вебхуком и отправкой в Telegram - это одна задача, а цепочка из пяти нод с обработкой ошибок, ретраями и логированием в Google Sheets - совсем другая по трудозатратам и по стоимости обслуживания.
Хороший пункт ТЗ по интеграции должен отвечать на четыре вопроса: какая система, какая версия API или протокол, что именно передаётся (создание заказа, статус, вебхук о смене состояния) и что происходит при ошибке - повтор запроса, уведомление в чат, запись в лог. Если хотя бы один из четырёх ответов отсутствует, смету по этому пункту нельзя считать окончательной.
При этом если у вас уже стоит Tilda и нужны точечные доработки - стоит сначала посмотреть на готовые скрипты для Tilda, чтобы понять реальный объём типовых задач и не платить за написание с нуля того, что уже отлажено на десятках проектов.
Таблица: слабые формулировки и как их исправить
| Раздел ТЗ | Слабая формулировка | Рабочая формулировка |
|---|---|---|
| Оплата | Подключить приём платежей | Т‑Банк, разовые платежи, обработка вебхука об успехе/отказе, возврат из админки |
| Доставка | Интеграция с СДЭК | Расчёт стоимости через API СДЭК на этапе оформления заказа, создание заявки после оплаты |
| Бот | Telegram-бот с оплатой | aiogram, FSM из 4 сценариев, хранение заказов в БД, webhook на сервере, админ-команды для менеджера |
| Автоматизация | Настроить n8n | 3 workflow: заявка с сайта → CRM, оплата → уведомление в Telegram, ежедневный отчёт в таблицу |
| Сроки | Готово через месяц | Этап 1-10 дней, приёмка по чек-листу; этап 2-15 дней, приёмка отдельно |
Красные флаги, когда ТЗ пишет сам разработчик
Если техническое задание готовит исполнитель, у него есть естественный соблазн описать объём так, чтобы он был выгоден именно ему - либо занизить детализацию, чтобы быстрее согласовать смету и потом добирать деньги на доработках, либо наоборот раздуть технический стек до сервиса, который не нужен для задачи такого масштаба.
Стоит насторожиться, если в документе:
- Нет ни одного измеримого критерия приёмки - всё держится на общих фразах
- Технологии выбраны без объяснения, почему именно они подходят под задачу и бюджет
- Цена указана одной суммой без разбивки по этапам или модулям
- Отсутствует раздел про то, что происходит при обнаружении ошибок после сдачи - это часто скрытая почва для платных «доработок», которые по сути являются багфиксом
- Нет фиксации того, кто оплачивает сторонние сервисы - хостинг, домен, платные API
В такой ситуации разумно закладывать независимую проверку ТЗ перед заказом у разработчика: попросить второго специалиста прочитать документ и указать на нестыковки. Это стоит несопоставимо меньше, чем переделка проекта на середине пути, когда уже внесена предоплата и потрачено время на согласования.
Что делать, если ТЗ ещё не готово, а заказ горит
Часто решение принимается быстро, а нормального технического задания просто нет - есть переписка в мессенджере и пара скриншотов референсов. В этом случае не стоит подписывать договор на основании устных договорённостей: лучше сначала заказать короткий аудит и составление ТЗ отдельным этапом, зафиксировать в нём объём и критерии приёмки, и только после этого утверждать смету на разработку.
Если сомневаетесь, что документ, который вам прислали, описывает именно то, что нужно, - разумно один раз оплатить разбор со стороны и получить конкретный список вопросов к исполнителю, а не выяснять это постфактум через несколько недель работы. Полный перечень задач, которые я беру в работу, и форматы технических заданий под них можно посмотреть на странице услуг.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Кто должен писать техническое задание - заказчик или разработчик?
Чаще пишет разработчик на основании брифа от заказчика, но финальную версию заказчику стоит прочитать самому и переспросить по каждому непонятному пункту. Если ТЗ составляли не вы, это не освобождает от проверки - договор фиксирует именно то, что написано в документе, а не то, что вы имели в виду при обсуждении.
Сколько стоит проверка готового ТЗ у стороннего специалиста?
Разбор существующего документа с указанием слабых мест обычно укладывается в рамки консультации - у меня это от 3 000 ₽ за разовую сессию с конкретными комментариями по разделам. Это дешевле, чем доплата за доработки, которые всплывают из-за нечётких формулировок в середине проекта.
Можно ли начинать разработку вообще без ТЗ?
Для простой правки на Tilda - можно, если задача укладывается в пару предложений и не требует интеграций. Для сайта на WordPress, магазина, бота или сервиса с бэкендом - нет: без зафиксированного объёма спор о том, что входило в цену, почти гарантирован при первой же неожиданности в проекте.
Что делать, если разработчик отказывается фиксировать ТЗ в договоре?
Это повод насторожиться и поискать другого исполнителя. Отказ фиксировать объём работ письменно обычно означает, что исполнитель хочет сохранить возможность трактовать задачу в свою пользу на этапе споров о доплатах или сроках - и это не тот риск, который стоит на себя брать ради экономии времени на старте.