Как составить техзадание фрилансеру на доработку сайта

Половина фрилансеров получает задачу в переписке: «доработайте сайт, добавьте пару функций, поправьте дизайн» - без единого документа. Через неделю выясняется, что заказчик хотел не пару функций, а новый раздел с фильтрами, а исполнитель понял задачу как косметику. Дальше начинаются правки, споры о доплате и упрёки в непрофессионализме - хотя проблема не в квалификации фрилансера, а в отсутствии технического задания.

В моей практике с 2013 года такие ситуации повторяются с завидной регулярностью: заказчик и исполнитель по-разному представляют себе результат работы, и обе стороны искренне уверены, что говорили об одном и том же. Мы в студии «Мельница» видим это и со стороны заказчиков-компаний, которые нанимают фрилансеров напрямую, и со стороны специалистов, которые приходят к нам разгребать чужие недоделки. Расскажем, как указать в ТЗ всё нужное и не упустить важное.

Техническое задание на доработку сайта - это письменный документ, который фиксирует цель работы, конкретный функционал, сроки, бюджет и критерии приёмки до начала работы, а не после.

Эта статья - про доработку существующего сайта на WordPress или WooCommerce силами фрилансера или небольшой команды; для сайтов на 1С-Битрикс, Tilda или конструкторах логика составления ТЗ похожа, но детали интерфейса и терминология отличаются.

Зачем нужно ТЗ фрилансеру и что будет, если его не составить

Отсутствие технического задания приводит к спорам о результате работы почти в каждом втором проекте, с которым я сталкивался за годы работы в вебе. Заказчик формулирует задачу в переписке своими словами, фрилансер додумывает детали по своему опыту - и на выходе получается не то, что представлял себе клиент. Документ нужен не потому, что фрилансеру нельзя доверять, а потому что человеческая память и устные договорённости плохо хранят детали через две недели работы. ТЗ помогает обеим сторонам держать в голове одну и ту же картину результата и заметно снижает число ошибок на этапе сдачи.

Размытые формулировки вроде «сделать красиво» или «доработать функционал» приводят к конфликту ожиданий на этапе сдачи. Заказчик под «красиво» имеет в виду конкретную референсную страницу конкурента, а исполнитель ориентируется на собственный вкус - его стиль работы просто отличается от того, что представлял клиент. Такие ситуации не решаются взаимными претензиями - их предотвращают заранее, прописывая в задании конкретные примеры и референсы вместо оценочных прилагательных.

Цена ошибки в устной постановке задачи измеряется не только деньгами, но и временем. На одном из проектов нашей студии заказчик обратился к фрилансеру с задачей «добавить фильтры в каталог», не уточнив, какие именно параметры нужны для фильтрации. Фрилансер сделал фильтр по цене и категории - а клиенту требовался фильтр по совместимости с моделями техники, что было ключевым для его B2B-каталога. Одна из главных причин таких промахов - отсутствие у исполнителя понимания бизнес-контекста заказчика. Переделка заняла ещё неделю, хотя изначально на весь объём работы закладывалось три дня.

Технический документ экономит деньги ещё и потому, что задаёт единую точку отсчёта для обеих сторон при обсуждении дополнительной оплаты. Если в процессе работы выясняется, что нужна доработка сверх изначального объёма, зафиксированное ТЗ прямо показывает, что было оговорено сначала, а что - новая задача. Без такого документа любой спор о доплате превращается в выяснение, кто что имел в виду.

Есть и юридический аспект: ТЗ, приложенное к договору или переписке с фрилансером или подрядчиком-агентством, - это единственное доказательство объёма работ при конфликте. Я не советую полагаться на переписку в мессенджере как на полноценную замену документа - сообщения теряются, редактируются, а структурированный документ с датой согласования остаётся понятным ориентиром для обеих сторон и даёт возможность обратной связи по каждому пункту, а не только по итоговому результату. Заодно такой документ работает как ориентир для контроля качества выполнения задачи на всех этапах.

Кто составляет ТЗ и когда без него можно обойтись

Бриф предшествует составлению полного технического задания в большинстве проектов, с которыми я работаю. Сначала заказчик описывает задачу в свободной форме - что не устраивает на сайте, какой результат нужен, - а уже на основе этого брифа появляется структурированный документ с разделами, сроками и критериями приёмки.

Кто именно садится писать ТЗ, зависит от масштаба доработки и от того, работает заказчик с частным фрилансером или через студию. Если задачу берёт менеджер проекта в веб-студии, он обычно сам формулирует документ на основе разговора с клиентом - это часть услуги, и клиенту не нужно разбираться в технических формулировках. Иногда на стороне заказчика в этом процессе участвует маркетолог, который лучше понимает бизнес-цели доработки, чем технические детали. Если заказчик нанимает фрилансера напрямую через биржу, чаще всего документ приходится готовить самому заказчику или обсуждать его совместно с исполнителем.

Совместное составление - рабочий вариант, когда заказчик понимает бизнес-задачу, но не знает, как её описать технически. В этом случае имеет смысл предложить фрилансеру: опишите своими словами, что видите на сайте сейчас и что должно получиться, а исполнитель уже переформулирует это в конкретные пункты с указанием технологий и ограничений. Хороший фрилансер сам задаёт уточняющие вопросы на этом этапе, а не молча берётся за работу с неполными вводными - ему важно понимать логику бизнеса заказчика, а не только техническое описание.

Не всякая доработка требует многостраничного документа. Если правка сильно ограничена по объёму - поменять текст в футере, обновить номер телефона, поправить цвет кнопки - достаточно короткого брифа в одном сообщении: что именно поменять, где именно это находится на сайте, к какому сроку нужен результат. Раздувать такие задачи до формального ТЗ бессмысленно, это трата времени обеих сторон.

Полноценное задание нужно, когда доработка меняет функционал сайта: добавляется новый раздел, интегрируется внешний сервис, переделывается логика оформления заказа в WooCommerce. Здесь общих формулировок недостаточно - нужно фиксировать, как новая функция должна работать в разных сценариях, какие данные показывать и что считается завершённой задачей. Я обычно советую заказчикам считать простое правило: если доработку нельзя описать одним предложением без «примерно» и «как-нибудь» - нужен документ, а не сообщение в мессенджере. Если вы знаете, что задача выходит за рамки мелкой правки, лучше заранее обсудить объём работ с исполнителем и решить, каким вы считаете разумный срок и бюджет на подготовку самого ТЗ.

Из каких разделов состоит ТЗ на доработку сайта

ТЗ на доработку сайта фиксирует требования заказчика и сроки выполнения работ - в этом его практический смысл, а не в объёме документа. Структура технического задания в разработке ПО отчасти опирается на старый ГОСТ 19.201-78: он регламентирует состав разделов документации, хотя сам сайт под этот стандарт формально не подпадает. В реальной работе с фрилансерами достаточно упрощённого шаблона, который включает несколько обязательных пунктов - список моментов, которые нужно зафиксировать, обычно укладывается в один бриф на пару страниц.

Не все разделы одинаково важны для каждой задачи. Если доработка небольшая, можно объединить дизайн-требования с функциональными в один пункт. Но цель, сроки и критерии приёмки я советую фиксировать всегда - без них сложно доказать, что работа сделана так, как договаривались, если возникнет спор. Содержание ТЗ стоит закрепить и в договоре или отдельном приложении к нему - тогда стоимость доработки и формат сдачи работы не станут поводом для разногласий, а объём задачи будет понятен обеим сторонам с самого начала.

Как описать цель, функционал и дизайн доработки - пошагово

Референсы сайтов конкурентов помогают сформулировать требования к дизайну быстрее, чем словесное описание. Вместо того чтобы объяснять фрилансеру, каким должен быть новый блок на лендинге, проще прислать три-четыре ссылки на похожие сайты с пометкой, что именно нравится - расположение кнопки, крупные изображения товаров, минимум текста на экране. Это работает и для интернет-магазина, и для маркетплейса, и для корпоративного сайта, только акценты будут разными.

Прежде чем описывать функционал, стоит определить тип платформы, на которой стоит сайт. Одна и та же задача "добавить фильтр по параметрам" реализуется по-разному на лендинге с одной страницей и в полноценном интернет-магазине с каталогом на тысячи позиций. Дальше нужно перечислить конкретные функциональные элементы интерфейса, которые затрагивает доработка: кнопку, форму, корзину, карточку товара - и описать, какие функции должны срабатывать при взаимодействии с каждым из них.

Прототип страницы фиксирует расположение блоков ещё до вёрстки, и это экономит время обеим сторонам. Не обязательно рисовать детальный макет в Figma - достаточно схематичного наброска от руки или в простом редакторе, где видно, что кнопка "В корзину" находится под изображением товара, а не сбоку. Если в проекте уже есть графические элементы - логотип, фирменные цвета, шрифты, брендбук с правилами оформления - их нужно приложить к ТЗ, а не описывать словами.

Отдельно стоит указать интеграции: с какой CRM синхронизируется форма, нужен ли доступ к хостингу для проверки логов, требуется ли настройка на стороне платёжной системы. CMS сайта - WordPress, 1С-Битрикс или самописное решение - определяет возможности доработки и напрямую влияет на то, сколько времени займёт задача. Указывать CMS в самом начале ТЗ - хорошая привычка, она сразу отсекает исполнителей, которые не работают с этой платформой.

Сроки, бюджет и договор - как зафиксировать деньги и даты

Договор с фрилансером фиксирует сроки и стоимость работ - без него любая договорённость держится только на переписке в мессенджере, а это не аргумент, если что-то пойдёт не так. Даже простой договор на пару страниц, где прописаны объём задач из ТЗ, стоимость, необходимые даты и месяц завершения проекта, снимает большую часть рисков для обеих сторон. В моей практике с 2013 года почти все конфликты с исполнителями возникали именно там, где договорённость об оплате была устной.

Сроки лучше разбивать не на одну финальную дату, а на промежуточные этапы: вёрстка - тестирование - публикация на боевом сайте. Так заказчик видит прогресс и может вовремя заметить, что фрилансер выбивается из графика, а не узнаёт об этом за день до дедлайна. Дедлайн с буфером времени снижает риск срыва сроков проекта - если задача рассчитана на 5 рабочих дней, в договор стоит закладывать 7, оставляя запас на правки и непредвиденные технические сложности. Контроль промежуточных этапов - это простое правило, которое экономит нервы: заказчик видит, что фрилансер готов уложиться в срок, задолго до финального часа сдачи.

По оплате есть несколько рабочих схем: полная предоплата, оплата по факту сдачи или частичная предоплата с авансом. Аванс защищает интересы исполнителя при частичной предоплате - фрилансер получает гарантию, что заказчик не пропадёт после выполнения работы, а заказчик при этом не рискует всей суммой сразу. На практике я советую клиентам студии схему 30-50% авансом и остаток после приёмки полного объёма работ - это баланс, который устраивает большинство исполнителей. Такая схема защиты интересов работает и на небольших фрилансерских тарифах, и на крупных проектах с финансовыми рисками для обеих сторон - разница только в сумме, которая фигурирует в договоре и выставляется в счёт.

В договоре стоит прописать не только сроки и суммы, но и порядок правок: сколько итераций входит в стоимость, что считается доработкой в рамках ТЗ, а что - новой задачей с отдельной оплатой. Без этого пункта споры возникают почти всегда, когда правки выходят за пределы исходного технического задания. Заранее оговоренные оценки трудозатрат на доработки тоже стоит зафиксировать письменно, чтобы обе стороны понимали, во сколько обойдётся выход за рамки ТЗ.

Как проверить и принять работу фрилансера

Критерии приёмки определяют момент, когда работа считается завершённой - и их нужно фиксировать заранее, а не придумывать по ходу проверки. Проверка работы фрилансера по доработке сайта должна идти по пользовательским сценариям: заказчик проходит путь реального посетителя - от главной страницы до оформления заявки или покупки - и смотрит, срабатывает ли новый функционал на каждом шаге так, как описано в ТЗ.

Отдельное внимание стоит уделить технической стороне доработки. Google Core Web Vitals - фактор оценки качества доработки сайта - набор метрик скорости и стабильности загрузки, который влияет на позиции в поисковой выдаче и итоговое продвижение проекта. После любой доработки я рекомендую прогонять страницу через PageSpeed Insights и смотреть, не просела ли скорость по сравнению с версией до правок - падение скорости напрямую сказывается на трафике и местах сайта в выдаче.

Адаптивность верстки проверяется на разных типах устройств и экранов - смартфон, планшет, десктоп с разным разрешением. Мы в студии «Мельница» всегда открываем доработанную страницу минимум на трёх реальных устройствах, а не только в режиме эмуляции в браузере, потому что эмулятор не всегда честно показывает поведение сложных блоков вроде каруселей или всплывающих форм. Мои рекомендации клиентам всегда включают этот пункт отдельной строкой - именно на нём чаще всего теряются заявки с мобильного трафика.

Чек-лист приёмки удобно свести в таблицу и проходить по ней последовательно, отмечая каждый пункт.

Если хотя бы один пункт из таблицы не сходится с ожиданиями, работа не принимается формально - фрилансер получает список замечаний со ссылкой на конкретный пункт ТЗ, а не общую фразу «не то, переделайте». Такой подход экономит время в правках: исполнитель понимает, что именно не устроило заказчика, вместо того чтобы гадать, а данные аналитики после публикации быстро покажут, действительно ли доработка пошла на пользу проекту.

Типичные ошибки при составлении ТЗ и как их избежать

Больше половины конфликтов с фрилансерами на доработке сайта начинаются с одной и той же формулировки: «сделайте красивый и удобный сайт». Слово «красивый» ничего не значит для исполнителя - у него нет доступа к вашим внутренним представлениям о вкусе, а есть только текст ТЗ. Формулировка ТЗ прямо указывает, какие идеи по дизайну исполнитель может предлагать сам, а какие решения нужно согласовывать перед тем, как вы переходите к вёрстке.

Вторая частая ошибка - забытые интеграции. Если вы забыли прописать, куда должны попадать заявки от формы и данные о покупках, эта часть решения достанется фрилансеру, а не вам. Список интеграций (CRM, аналитика) входит в раздел технических требований ТЗ - и если его пропустить, фрилансер сдаст форму без всякой связи с amoCRM или Яндекс Метрикой, а доработка окажется бесполезной ровно в день сдачи.

Третья типовая ситуация - отсутствие ТЗ на верстку под мобильные устройства. Заказчик проверяет макет на своём десктопе, всё нравится, работа принимается - а потом выясняется, что на телефоне блок съезжает или кнопка не помещается на экран. Отдельный пункт про адаптивность и конкретные разрешения экранов должен быть в ТЗ изначально, а не всплывать после жалоб реальных посетителей.

Ещё одна ловушка - фразы вроде «настроить как удобнее» вместо чётких инструкций. Начинать работу над формой без указания, куда ведёт реклама и откуда идут переходы, тоже не стоит - это часть логики фильтра. Настройка формы, каталога или фильтра без описанной логики отдаётся на откуп исполнителю, а он решает задачу по-своему - иногда даже вопреки тому, как эта часть сайта должна продавать.

Готовый шаблон ТЗ и с чего начать сегодня

Чтобы запустить доработку сайта без лишних кругов согласования, откройте документ и заполните пять разделов по порядку: цель доработки, техническое описание, дизайн-требования, критерии приёмки, сроки и бюджет. Такой шаблон закрывает и продающие задачи вроде роста числа заявок, и чисто технические - вроде оптимизации скорости загрузки.

В разделе дизайн-требований не пытайтесь описывать внешний вид словами. Скриншоты и макет в Figma заменяют словесное описание дизайна гораздо точнее, чем абзац текста - исполнитель видит расположение элементов, отступы и цвета напрямую, без риска домыслить что-то своё.

Когда документ готов, можно идти к исполнителю. Биржи фриланса (FL.ru, Kwork) используются для поиска исполнителя под готовое ТЗ - публикуете задание с документом во вложении и сравниваете отклики не по цене, а по вопросам, которые задают кандидаты: чем больше конкретики они уточняют, тем внимательнее прочитали ТЗ.

Если разбираться во всём этом самостоятельно не хочется, а составление ТЗ или поиск исполнителя под готовый документ проще доверить специалисту, для этого подходит Kwork: там можно заказать и подготовку ТЗ под конкретную доработку, и подбор фрилансера с нужным стеком под ваш продукт. Цены на такие услуги обычно начинаются от нескольких сотен рублей и доходят до нескольких тысяч в зависимости от сложности задачи.

Главная ошибка, которую совершает заказчик без ТЗ - это надежда, что фрилансер сам додумает то, что не проговорено. В итоге секрет успеха простой: документ на пять разделов помогает сайту стать лучше без лишних споров, а исполнитель успешно закрывает задачу, потому что видит перед собой готовый документ с требованиями, а не набор пожеланий, и достижения на каждом этапе видно сразу по чек-листу приёмки. Чем больше таких кейсов накопится в работе с одним исполнителем, тем быстрее идут все следующие доработки сайта.

Эта статья основана на личном опыте автора и актуальна на момент публикации. Материал не является юридической консультацией - для составления договора с фрилансером на серьёзную сумму рекомендую привлекать юриста. Интерфейсы сервисов и алгоритмы поисковых систем регулярно меняются - рекомендую проверять актуальность инструкций на официальных ресурсах. Если у вас остались вопросы - задайте их в комментариях.

Список литературы

1. Google - Core Web Vitals: Understanding the metrics // Search Central Documentation // developers.google.com
2. Редакция WordPress - Developer Resources: Themes Handbook // wordpress.org
3. Справка Яндекс.Вебмастера - Рекомендации по SEO-оптимизации сайта // yandex.ru
4. ГОСТ 19.201-78 - Техническое задание. Требования к содержанию и оформлению // Стандартинформ