Доработка сайта часто начинается с фразы:
«Нужно немного поправить».
А заканчивается:
- десятками часов;
- спорами;
- переделками;
- ростом бюджета;
- нервной перепиской.
Причина простая -задачу плохо описали на старте.
Клиент думает, что всё очевидно.
Разработчик видит только общее пожелание.
Менеджер уточняет по ходу.
В итоге проект живёт в режимехаоса:
- сегодня правим кнопку;
- завтра вспоминаем про фильтр;
- послезавтра - а, нужна интеграция с CRM;
- через неделю - а это должно работать и на мобильной версии.
Если коротко:
Техническое задание (ТЗ) на доработку сайта нужно не для бюрократии.
Оно нужно, чтобывсе участники одинаково понимали:
- что делать;
- сколько это займёт;
- как будет выглядеть результат;
- где проходят границы ответственности.
2. Прямой ответ: как составить техническое задание на доработку сайта
Хорошее ТЗ отвечает напростые вопросы:
- Что именно нужно изменить?
- Где именно это нужно изменить?
- Как это должно работать после доработки?
- Какие есть ограничения?
- Какие материалы и доступы нужны?
- Как понять, что задача выполнена правильно?
Хорошее ТЗ не обязано быть документом на 50 страниц.
Но онодолжно быть конкретным.
Плохо:
«Нужно улучшить карточку товара.»
Нормально:
«На странице карточки товара добавить блок с характеристиками, вывести наличие на складе, добавить кнопку “Купить в 1 клик”, передавать заявку в CRM с названием товара, телефоном клиента и источником обращения.»
Разница огромная.
В первом случае разработчикбудет угадывать.
Во втором — можнооценить сроки, стоимость и риски.
3. Почему доработка сайта без ТЗ почти всегда выходит дороже
Главная проблема -неопределённость.
Когда задача описана расплывчато, подрядчик не может точно оценить объём.
Он либо:
- закладывает риск в цену (и вы платите больше);
- либо даёт минимальную оценку, а потом начинаются доплаты.
Пример:
Клиент пишет:
«Нужно сделать фильтр в каталоге.»
Но фильтр может быть:
- по цене;
- по бренду;
- по характеристикам;
- по наличию;
- с ЧПУ-ссылками для SEO;
- с ajax-загрузкой;
- с учётом мобильной версии;
- с сохранением выбранных параметров;
- с интеграцией с импортом товаров.
Это может быть задача на5 часов.
А может - на40+ часов.
Если не уточнить - обе стороны будут недовольны:
- Клиент: «Я думал, это входит».
- Разработчик: «Этого не было в задаче».
Иоба будут правы.
Поэтому ТЗэкономит деньги, а не тратит их.
Оно убираетлишние переделки и споры.
4. Что обязательно указать в ТЗ на доработку сайта
1. Цель доработки
Не просто «поменять блок», азачемэто делается.
Например:
- увеличить количество заявок;
- упростить оформление заказа;
- ускорить работу менеджера;
- убрать ручной перенос данных;
- улучшить SEO-страницы;
- исправить ошибку в форме.
Когда понятна цель, разработчик может предложитьлучшее решение.
Иногда клиент просит одно, а бизнесу на самом деле нужно другое.
2. Место доработки
Укажитеконкретные страницы, разделы, шаблоны или элементы.
Например:
- главная страница;
- карточка товара;
- корзина;
- форма обратной связи;
- личный кабинет;
- раздел услуг;
- мобильная версия;
- административная часть.
3. Описание логики
Что происходит после действия пользователя.
Пример:
Пользователь нажимает кнопку → открывается форма → вводит имя и телефон → заявка уходит на почту и в CRM → менеджеру приходит уведомление → пользователь видит сообщение об успешной отправке.
4. Данные
- Какие поля нужны?
- Куда передаются?
- Что обязательно, что - нет?
- Какие ошибки показывать?
5. Внешний вид
Если есть макет — приложите.
Если нет — опишите словами или дайте пример.
Лучше сразу уточнить: нужна ли работа дизайнера или можно использовать текущий стиль сайта.
6. Ограничения
Чтонельзя менять:
- структуру URL;
- текущий шаблон;
- SEO-мета-теги;
- логику корзины;
- рабочие интеграции.
Также укажите:
- учёт мобильной версии;
- совместимость с текущими плагинами;
- требования к скорости загрузки.
7. Критерии приёмки
Как клиент поймёт, что задача сделана.
Пример:
«Форма отправляет данные в CRM, в письме указан источник, на сайте появляется сообщение “Спасибо, заявка отправлена”, форма работает на мобильных устройствах, ошибки валидации показываются корректно.»
Этот пунктважен. Без него доработка может бесконечно превращаться в:
«А ещё давайте вот это…»
5. Типичные ошибки клиентов при постановке задач
1. Писать задачу в одном сообщении без деталей
«Нужно сделать красиво» - это не ТЗ.
Красиво для вас, дизайнера и разработчика может означатьсовершенно разное.
2. Не прикладывать скриншоты
Скриншот с пометкамиэкономит больше времени, чем длинное описание.
Особенно если речь о конкретном блоке, форме или ошибке.
3. Забывать про мобильную версию
На десктопе всё может выглядеть хорошо, а на телефоне — ломаться.
Если мобильную версию не указать в задаче, её могутне заложить в оценку.
4. Не писать, что должно быть в админке
Клиент хочет сам менять текст, картинку, цену или порядок элементов.
Но если это не указано, разработчик может сделать блокстатичным.
Потом - переделывать отдельно.
5. Менять задачу по ходу работы
Иногда это неизбежно.
Но нужно понимать:если меняется логика - меняются сроки и стоимость.
Разработка - это не пластилин, который можно бесконечно мятьбесплатно.
6. Как делаем мы в RG3
Мы не начинаем серьёзную доработку с фразы:
«Давайте просто попробуем.»
Сначаларазбираем задачу:
- что нужно изменить;
- зачем это бизнесу;
- где находится проблема;
- кто будет пользоваться результатом;
- какие данные участвуют;
- есть ли влияние на SEO;
- нужны ли интеграции;
- как проверить результат.
После этого:
- формируем понятное ТЗ;
- или помогаем клиенту привести его задачу в рабочий вид.
Если задача маленькая- достаточно короткого описания и скриншотов.
Если сложная- разбиваем на этапы:
- Анализ;
- Прототип или описание логики;
- Оценка;
- Разработка;
- Тестирование;
- Публикация;
- Проверка после запуска.
Наш подход отличается тем, что мынаходим риски до начала работы.
Лучше потратить время на уточнение, чем потомпеределывать готовый функционал.
Это:
- безопаснее - меньше шанс сломать сайт;
- выгоднее - оценка становится точнее;
- удобнее - клиент понимает, за что платит.
7. Мини-кейс: «маленькая доработка» превратилась в проект
Типовая ситуация.
Клиент просит:
«Добавить форму заявки на страницу услуги.»
На первый взгляд - задача на 2-3 часа.
Но при уточнении выясняется:
- форма должна передавать данные в CRM;
- нужно фиксировать источник заявки;
- нужно отправлять письмо менеджеру;
- нужно добавить согласие на обработку данных;
- нужно защитить форму от спама;
- нужен отдельный текст благодарности;
- нужно проверить мобильную версию;
- нужно добавить цель в аналитику.
До уточнения- 2-3 часа.
После нормального разбора- полноценная доработка, влияющая на продажи, аналитику и обработку заявок.
Результат:
- клиент заранее понял объём;
- команда не работала вслепую;
- заявки начали уходить в нужное место;
- менеджеры перестали вручную искать данные;
- аналитика стала показывать результат.
Вот для этого и нужнонормальное ТЗ.
Не чтобы усложнить работу, а чтобыне потерять важные детали.
8. Что вы получите, если обратиться к нам
Если вы обращаетесь в RG3, вы получаете не просто разработчика, который «что-то поправит на сайте».
Вы получаете команду, котораясначала разбирается в задаче.
Мы:
- поможем сформулировать доработку;
- проверим, какие части сайта она затрагивает;
- оценим риски;
- подскажем, что лучше сделать сразу, а что можно отложить;
- посчитаем объём работ;
- сделаем доработку аккуратно;
- проверим результат после внедрения.
Для бизнеса это полезно:
сайт развиваетсяуправляемо, а не хаотичными правками.
Этопонятные улучшения, которые можно оценить, проверить и развивать дальше.
9. Сколько стоит подготовка ТЗ и доработка сайта
Стоимость зависит от сложности задачи.
- Маленькая доработка - 5-15 часов;
- Средняя (форма, логика, тестирование) - 10–25 часов;
- Сложная (каталог, интеграция, личный кабинет) - от 30–50 часов и выше.
В RG3 мы считаем поэтапам и часам.
Наша ставка -2690 рублей в час.
Подготовка или уточнение ТЗ:
- Простая задача - 1-3 часа;
- Средняя - 4-8 часов;
- Сложный проект - 10+ часов.
Почемудёшево часто выходит дороже?
Потому что разработка без нормального описания почти всегда приводит кпеределкам.
А переделки стоятдороже, чем нормальное уточнение задачи на старте.
Если подрядчик сразу соглашается:
«Сделаем как-нибудь» -
это может выглядеть удобно.
Но потом вы получаете:
- не тот результат;
- не те сроки;
- не ту стоимость.
10. Вывод
Техническое задание на доработку сайта - это не лишняя бумага.
Это способ защитить:
- деньги;
- сроки;
- нервы.
Хорошее ТЗ помогает:
- клиенту - получить нужный результат;
- команде - сделать работу без угадывания.
Чем точнее описана задача - тем меньше хаоса в процессе.
