Заказчик редко приходит с готовым техническим заданием. Чаще пишут в телеграм: «Нужно допилить сайт, тут кнопка не туда ведёт, а ещё хотели бы добавить оплату и раздел с отзывами». За годы работы с Tilda, WordPress и кастомными сервисами я перестал ждать идеального документа перед стартом - с большинством клиентов задачу приходится собирать по кускам из переписки, скриншотов и созвона на 15-20 минут. И это нормально, если знать, что спросить и в каком порядке, чтобы доработка не превратилась в бесконечный пинг-понг уточнений.
Почему доработка сайта обычно обходится без технического задания
ТЗ пишут на старте большого проекта, когда нужно зафиксировать бюджет и сроки перед разработкой с нуля. Для доработки существующего сайта это почти всегда избыточно: правки локальные, сайт уже работает, изменения точечные. Клиент хочет починить форму заявки или добавить фильтр в каталог, а не согласовывать документ на пятнадцать страниц.
Из практики: из десяти обращений на доработку с готовым ТЗ приходит хорошо если одно. Остальные девять - это набор сообщений, скриншотов интерфейса и фраза «разберитесь, пожалуйста, как удобнее». Проблема не в том, что заказчик ленится оформить документ - просто для мелкой правки это несоразмерные трудозатраты с обеих сторон. Задача разработчика не в том, чтобы вытребовать ТЗ, а в том, чтобы задать правильные вопросы и получить нужный минимум за один заход, а не за пять итераций переписки.
Что нужно разработчику, чтобы взяться за доработку без ТЗ
Прежде чем начинать, мне нужно закрыть пять пунктов - без них оценка срока и цены будет пальцем в небо:
- Доступ к самому сайту: админка, хостинг, репозиторий или личный кабинет конструктора (Tilda, WordPress, самописный SPA)
- Описание поведения «как есть» и «как должно быть» - желательно со скриншотом или ссылкой на конкретную страницу
- Список уже подключённых интеграций: эквайринг, CRM, служба доставки, аналитика - чтобы не сломать то, что и так работает
- Контакт человека, который может оперативно выдать недостающие доступы, если сам заказчик их не знает
- Хотя бы примерный бюджетный ориентир, чтобы сразу отсечь несовместимые ожидания
Пример из практики: клиент пишет «оплата не проходит» на магазине WooCommerce с подключённым T‑Bank эквайрингом. Без доступа к личному кабинету банка и без понимания, тестовый это режим или боевой, разработчик потратит первый час не на исправление, а на выяснение, что вообще происходит. Если сразу приложить скриншот ошибки, номер заказа и режим (тест/прод) - правка занимает 20 минут вместо созвона на полчаса.
Как сформулировать задачу на доработку сайта одним сообщением
Рабочая структура, которая экономит время всем - я прошу заказчиков придерживаться примерно такого порядка:
- Что не так сейчас - конкретно, с примером или ссылкой на страницу
- Что должно получиться в итоге - описание результата, а не реализации
- Где смотреть - URL страницы или раздел админки
- Есть ли референс - похожий пример у конкурентов или на другом сайте
- Ориентир по срокам и бюджету
Плохо: «Сделайте, чтобы сайт работал лучше и выглядел современнее»
Хорошо: «На странице /catalog/ карточка товара не показывает цену без НДС - нужно вывести две цены рядом, как уже сделано на /product/123. Срок - 3-5 дней, бюджет обсуждаем после оценки»
Разница не в объёме текста, а в том, что второй вариант даёт разработчику точку отсчёта и критерий готовности. Без этого любая доработка рискует превратиться в бесконечное «нет, я имел в виду не так».
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Примеры доработок из практики и что для них нужно знать заранее
Под разные типы доработок нужен разный минимум вводных. Вот как это выглядит на реальных задачах:
| Тип доработки | Что нужно от заказчика | Пример из практики | Средний срок |
|---|---|---|---|
| Интеграция эквайринга (T‑Bank) в WooCommerce | Доступ в личный кабинет банка, тестовые ключи, текущая логика оформления заказа | Подключение оплаты частями на интернет-магазине | 1-2 недели |
| Расчёт доставки через СДЭК | API-ключ СДЭК, список ПВЗ, тарифная сетка | Доработка калькулятора доставки на Tilda | 3-7 дней |
| Скрипт на Tilda (валидация, скрытие блока) | Ссылка на страницу, условие срабатывания | Скрытие цены до авторизации пользователя | 1-3 дня |
| Доработка Telegram-бота на aiogram | Доступ к репозиторию, токен бота, тестовый чат | Добавление напоминаний в бота записи на услуги | 1-2 недели |
| Новый сценарий в n8n | Доступ к инстансу n8n, credentials сервисов | Дублирование заявок с сайта в CRM и Telegram одновременно | 2-5 дней |
Если задача типовая - прежде чем заказывать отдельную разработку, стоит заглянуть в библиотеку готовых скриптов для Tilda: часть мелких доработок вроде скрытия блоков по условию или валидации формы уже написана и не требует индивидуальной оценки.
Сколько стоит допилить сайт и от чего зависит цена
Цена доработки зависит не от объёма кода, а от того, сколько времени уходит на понимание существующей системы. Простая правка в скрипте Tilda - от 3 000 ₽. Комплексная интеграция вроде эквайринга или СДЭК с логикой заказов - от 40 000 ₽. Если доработка сайта на WordPress требует переписывания части функционала - от 60 000 ₽, как за полноценный проект, потому что объём работ по факту сопоставим. Доработка бота на aiogram - от 30 000 ₽, добавление сценария в n8n - от 25 000 ₽.
На рынке разработчики и студии часто считают доработку почасово - ставки колеблются от 1 500 до 4 000 ₽ в час в зависимости от квалификации и региона, это рыночный ориентир, не моя ставка. Для доработки без ТЗ почасовая оплата опасна с обеих сторон: заказчик не понимает, где остановиться, разработчик не может спрогнозировать итоговую сумму. Я стараюсь давать фиксированную оценку по объёму после короткого созвона - это дисциплинирует и меня, и заказчика.
Частые ошибки при постановке задачи на доработку
- «Сделайте как у конкурента» без уточнения, что именно нравится - дизайн, логика формы или скорость загрузки
- Доступы выдаются по частям в течение недели, вместо того чтобы сразу открыть админку и хостинг
- Задача разрастается на середине работ - «а ещё вот тут нужно» - без обсуждения нового бюджета и срока
- Ожидание, что доработка сайта включает бесплатную поддержку после сдачи - это отдельная услуга с отдельной оплатой, я обычно оформляю её через ежемесячный тариф на техподдержку
- Правки сразу вносятся на боевой сайт без тестового окружения, из-за чего любая ошибка сразу видна посетителям
Последний пункт особенно критичен для интеграций с оплатой и доставкой: если тестировать логику расчёта СДЭК прямо на проде, есть риск на пару часов сломать оформление заказа для реальных покупателей. Для таких задач я всегда прошу тестовый контур или хотя бы тестовый режим у платёжного провайдера.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Нужно ли писать ТЗ, если доработка сайта небольшая?
Нет, для точечных правок достаточно описать текущее поведение и желаемый результат в одном сообщении с примером или ссылкой на страницу. Полноценное ТЗ имеет смысл только для крупных доработок с несколькими интеграциями и этапами сдачи.
Как понять сроки доработки, если разработчик ещё не назвал смету?
Ориентируйтесь на тип задачи: скрипт на Tilda - 1-3 дня, интеграция с оплатой или доставкой - от недели до двух. Точный срок разработчик называет после того, как посмотрит доступы и текущую структуру сайта, поэтому первая оценка на глаз всегда приблизительная.
Можно ли допилить сайт, если его делал другой разработчик и доступов к коду нет?
Можно, но сначала нужно восстановить доступ к хостингу, домену и админке - иногда через регистратора или хостинг-провайдера. Если код закрыт и недоступен вообще, часть функционала иногда проще переписать заново, чем разбирать чужую логику вслепую.
Что делать, если в процессе доработки заказчик придумывает новые задачи?
Обсуждать их отдельно от исходной сметы. Я фиксирую новые пункты как допработы с отдельной оценкой по времени и бюджету - это избавляет от ситуации, когда небольшая правка растягивается на месяц без понятной стоимости.