Разбор технического задания - первое, что я делаю перед тем, как называть заказчику сумму и сроки. За годы разработки я не раз брался чинить проекты, где на входе было ТЗ на полторы страницы с формулировкой «сделать как у конкурента, но лучше». Дальше начинались сюрпризы: то выясняется, что интеграция с СДЭК нужна не для расчёта доставки, а для полного трекинга посылок в личном кабинете покупателя, то заказчик молчит про интеграцию с T‑Bank до третьей недели работы. Ниже - как я читаю ТЗ, что в нём ищу и какие вопросы задаю до того, как согласовать смету.
Зачем нужен разбор технического задания на старте, а не после оценки
Оценка по диагонали - самый частый способ потерять деньги на проекте. Я видел десятки ТЗ, где строчка «настроить оплату и доставку» на деле означает интеграцию эквайринга T‑Bank с вебхуками на статус заказа плюс синхронизацию тарифов СДЭК через API, а не просто виджет на сайте. Если разбор ТЗ сделан поверхностно, оценка получается заниженной, а потом либо приходится доплачивать по ходу работы, либо доделывать бесплатно, лишь бы не разругаться с клиентом.
Разбор технического задания на старте решает три вещи разом: показывает реальный объём работы, вскрывает противоречия в требованиях заказчика и даёт материал для сметы, которую потом не стыдно защищать. На практике час-полтора, потраченный на вдумчивое чтение и список уточняющих вопросов, экономит недели споров о том, что входило в изначальную договорённость, а что нет.
Из каких разделов состоит вменяемое ТЗ и на что смотреть в первую очередь
Прежде чем разбирать конкретные пункты, проверяю, есть ли в документе вообще нужные разделы. Если заказчик присылает файл на две страницы без структуры - это не значит, что работать нельзя, но структуру придётся достраивать самому на этапе уточняющих вопросов.
В нормальном ТЗ должны быть:
- Цель проекта и то, для кого он делается - без этого невозможно понять приоритеты
- Функциональные требования - конкретные действия пользователя и системы, а не общие фразы
- Нефункциональные требования - нагрузка, скорость отклика, требования к хранению данных
- Список интеграций с указанием, что именно передаётся и куда
- Дизайн-референсы или готовый макет
- Сроки и этапы приёмки
- Бюджетные рамки, если заказчик готов их обозначить
Если бюджета в ТЗ нет - это нормально, спрашиваю отдельно. А вот отсутствие функциональных требований в измеримом виде - сигнал, что придётся самому формулировать сценарии использования и присылать их на согласование, прежде чем считать смету.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как декомпозировать задачи из ТЗ на конкретные модули разработки
Когда структура ТЗ понятна, раскладываю каждый крупный пункт на модули, которые можно оценить отдельно. Это и есть декомпозиция - без неё смета превращается в одну цифру «под ключ», которую невозможно объяснить клиенту при последующих правках.
Для интернет-магазина на WooCommerce с оплатой и доставкой декомпозиция обычно выглядит так:
- Настройка каталога и категорий под структуру ассортимента
- Интеграция эквайринга T‑Bank - приём платежа, обработка вебхуков, синхронизация статусов заказа
- Интеграция СДЭК - расчёт стоимости на фронте, передача заказа в личный кабинет перевозчика, обновление статуса доставки у покупателя
- Настройка уведомлений на каждом этапе оформления заказа
Для Telegram-бота на aiogram декомпозиция другая: сценарии диалога, хранение состояния пользователя, интеграция с внешним API (CRM, оплата, база знаний), логика уведомлений и админ-панель для контента. Если в ТЗ написано просто «бот с оплатой», всегда уточняю, идёт ли речь о разовом платеже или о подписке с автосписанием - это разные по сложности модули.
Декомпозиция полезна ещё и потому, что показывает заказчику, за что он платит. Вместо одной строки «Telegram-бот - фиксированная сумма» получается список из пяти-шести пунктов, и объём работы обсуждается совместно, а не постфактум.
Технические нюансы интеграций, которые нужно уточнить до старта
Общая декомпозиция - это первый уровень. Второй - вопросы по конкретным интеграциям, которые в ТЗ почти никогда не расписаны до нужной степени детализации.
| Интеграция | Что уточнить | Что будет, если пропустить |
|---|---|---|
| T‑Bank эквайринг | Боевой или тестовый терминал, нужны ли вебхуки на возврат средств, схема чеков по 54-ФЗ | Доработка после запуска, срыв сроков на неделю-две |
| СДЭК | Нужен договорной номер или работа через публичный тариф, нужен ли трекинг статуса в личном кабинете покупателя | Пересчёт логики доставки на середине проекта |
| Tilda-скрипты | Правки через встроенный редактор кода или отдельный JS-файл на хостинге, есть ли доступ к Zero Block | Лишний раунд согласований с владельцем аккаунта Tilda |
| Автоматизация в n8n | Сколько workflow нужно, где хостится n8n - свой сервер или облако, какие внешние API дёргаются | Недооценка по числу узлов и цепочек в смете |
Отдельно уточняю хранение персональных данных клиентов, если в проекте есть CRM или бот с базой пользователей. По 152-ФЗ данные российских клиентов должны лежать на серверах в РФ, и я никогда не завожу такие данные в Google Sheets или Airtable, даже если заказчик просит по-быстрому. Это обсуждается на этапе разбора ТЗ, а не после жалобы юриста.
Типичные ошибки при чтении технического задания
- Верить формулировке «сделать как у конкурента» без разбора, какие именно функции конкурента нужны, а какие лишние
- Не спрашивать про нагрузку и число одновременных пользователей - это меняет архитектуру, а не только дизайн
- Игнорировать нефункциональные требования: скорость загрузки, SEO-структуру, требования к резервному копированию
- Не проверять доступы - домен, хостинг, аккаунты Tilda или n8n - до подписания договора
Если ТЗ описывает типовую доработку Tilda - кастомную форму, попап с валидацией, интеграцию с CRM - прежде чем закладывать в смету часы на разработку с нуля, проверяю, нет ли готового решения в библиотеке готовых скриптов для Tilda: иногда задача из ТЗ закрывается адаптацией уже написанного кода, а не новой разработкой с нуля.
Как оформить результат разбора ТЗ: смета, договор, критерии приёмки
После декомпозиции формализую результат в смету с разбивкой по модулям - либо фиксированной ценой на весь объём, либо повременной оплатой для частей с неясным объёмом (например, доработки по ходу тестирования). Каждое допущение из разбора ТЗ фиксирую письменно и прикладываю к договору отдельным приложением, чтобы не спорить потом, что входило в изначальную договорённость.
Цены на доработки различаются на порядок в зависимости от объёма: простой кастомный скрипт для Tilda - от 3 000 ₽, комплексная интеграция с CRM, эквайрингом и СДЭК на той же платформе - от 40 000 ₽. Telegram-бот с нуля - от 30 000 ₽, но если в ТЗ добавляется база знаний с RAG-поиском по документам, это отдельная строка от 50 000 ₽, потому что архитектура и стоимость инфраструктуры другие. Автоматизация процессов в n8n - от 25 000 ₽, парсинг и сбор открытых данных на Python - от 20 000 ₽.
На рынке у студий подобная интеграция часто оценивается вилкой в десятки тысяч рублей сразу, без разбивки по модулям - именно потому, что ТЗ не разобрано заранее и в цену закладывают риск недооценки объёма.
В смету добавляю раздел критериев приёмки - по каким сценариям заказчик проверяет готовый функционал перед оплатой финального этапа. Без этого раздела разбор ТЗ работает только наполовину: смета готова, а порог «работа принята» остаётся размытым.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Сколько времени занимает разбор технического задания перед стартом проекта?
Для небольшого сайта или доработки на Tilda хватает часа-полутора. Для системы с несколькими интеграциями - CRM, эквайринг, доставка - закладываю от трёх часов до целого рабочего дня, потому что нужно свести список уточняющих вопросов и обсудить их с заказчиком до сметы.
Что делать, если заказчик не может нормально описать ТЗ?
Задаю уточняющие вопросы сам и предлагаю совместно оформить функциональные требования в виде конкретных сценариев - что делает пользователь, что происходит в системе. Часто это оформляется как отдельная консультация, на которой разбираем идею и фиксируем модули будущего проекта.
Нужно ли платить за разбор ТЗ отдельно от разработки?
Если проект понятный и укладывается в типовую схему, разбор входит в подготовку сметы бесплатно. Если требований много, задействовано несколько сторон (маркетолог, юрист, действующий подрядчик) или нужно выбрать архитектуру среди вариантов - оформляю это отдельной консультацией от 3 000 ₽.
Как понять, что ТЗ детализировано достаточно для точной оценки?
Если в документе каждое функциональное требование можно проверить сценарием («пользователь нажимает кнопку - система делает X»), интеграции расписаны с указанием, что именно передаётся, а формулировок вида «сделать как у конкурента» нет - ТЗ готово к точной оценке. Если нет - сначала уточняющие вопросы, потом смета.