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

Шаблон технического задания на доработку сайта: проблема, цель, ожидаемый результат, материалы и проверяемые критерии готовности.

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

Зачем составлять ТЗ на доработку сайта

Запрос «сделайте сайт удобнее» понятен как пожелание, но не даёт исполнителю границ работы. Один человек предложит поменять меню, другой — переписать главную, третий — сделать новый дизайн. В итоге оценки нельзя сравнить, а результат трудно принять.

ТЗ на доработку сайта фиксирует, что сейчас происходит, что должно измениться и как убедиться в результате. Оно не заменяет обсуждение задачи: если неясно, почему возникают проблемы с заявками или скоростью, сначала стоит разобраться в причинах. Затем можно заказать конкретную доработку сайта.

Семь пунктов понятной задачи

1. Адрес и область: URL страницы, раздел, шаблон или форма, которую нужно изменить.
2. Проблема: что происходит сейчас и при каких действиях; для ошибки — шаги воспроизведения.
3. Цель: зачем бизнесу изменение и что должен сделать посетитель.
4. Ожидаемый результат: что пользователь увидит и что произойдёт после его действия.
5. Материалы: тексты, цены, фотографии, макет, примеры, доступы или контакт ответственного.
6. Ограничения: что нельзя менять, какие интеграции и старые страницы нужно сохранить.
7. Проверка: наблюдаемые критерии приёмки на компьютере и телефоне.

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

Шаблон ТЗ на изменение сайта

Для одной кнопки этого достаточно. Для каталога, оплаты или CRM-интеграции документ будет подробнее: понадобятся состояния ошибки, права доступа, состав передаваемых данных и сценарии повторной отправки.

Примеры хорошей постановки задачи

Форма заявки

Слабо: «Починить форму, иногда не работает».

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

Если заявки теряются, отдельно проверьте весь маршрут, описанный в статье «Как проверить, что заявки с сайта доходят».

Страница услуги

Слабо: «Сделайте страницу красивее».

Проверяемо: «На странице услуги обновить первый экран по приложенному тексту, добавить блок этапов и кнопку “Получить расчёт”, ведущую к существующей форме. Сохранить текущий URL, контакты и SEO-поля. Проверить отображение на ширине телефона 390 px и компьютера».

Интеграция

Слабо: «Связать сайт с CRM».

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

Как зафиксировать объём работ и изменения по ходу проекта

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

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

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

Критерии приёмки: как понять, что работа завершена

Фраза «всё работает» слишком расплывчата. Критерий должен проверяться действием: открыть URL, нажать кнопку, отправить тестовую заявку, увидеть запись в CRM, сравнить страницу на телефоне, проверить редирект или цель аналитики.

Для аналитики проверяйте не только наличие кода счётчика, но и достижение цели после согласованного действия. Яндекс Метрика описывает проверку цели через отладочный режим и отчёт. Результаты лучше фиксировать при приёмке — об этом отдельный чек-лист владельца сайта.

Частые вопросы

Можно ли поставить задачу без готового ТЗ?

Да. Достаточно описать проблему, показать страницу и назвать желаемый результат. Исполнитель может помочь уточнить решение и оформить проверяемый список работ до начала реализации.

Нужно ли указывать технологию реализации?

Обычно владельцу сайта важнее поведение и ограничения. Технический способ выбирают после осмотра CMS и кода. Указывайте технологию только тогда, когда она действительно является требованием проекта.

Что делать, если в ходе работы обнаружилась новая проблема?

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

Что отправить исполнителю для начала

Адрес сайта, ссылку на страницу, короткое описание проблемы, ожидаемый результат, материалы и срок, к которому изменение действительно нужно. Этого достаточно, чтобы начать предметный разговор, уточнить неизвестное и составить реальное техническое задание на доработку сайта.