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