Как составить ТЗ на доработку сайта

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

Начните с проблемы и ожидаемого результата

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

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

Для сложной функции полезно обозначить пользователя, его действие и цель. В руководстве GOV.UK по пользовательским историям предлагается фиксировать действующее лицо, его потребность и причину этой потребности. Это не обязательный формат для каждого ТЗ, но он помогает проверить, решает ли запрошенная функция реальную задачу.

Опишите текущее и требуемое поведение

Если речь идёт об ошибке или изменении существующей функции, разделите описание на два блока: «сейчас» и «должно быть». В первом зафиксируйте наблюдаемое поведение, во втором — ожидаемый результат. Для ошибки добавьте последовательность действий, после которой она появляется: страницу, роль пользователя, введённые данные, нажатую кнопку и полученное сообщение.

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

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

Зафиксируйте границы доработки

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

Разбейте крупную доработку на самостоятельные части: страницы, роли, формы, интеграции, уведомления, перенос данных и настройку аналитики. Укажите приоритет, если не все части одинаково важны. Это позволяет оценивать один и тот же объём, а при необходимости — запускать изменения поэтапно. Официальный Scrum Guide описывает уточнение элементов работы как добавление деталей и разделение на более точные элементы; размер работы оценивают специалисты, которые будут её выполнять.

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

Добавьте материалы и технические условия

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

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

Не вставляйте пароли, ключи API и другие секреты в ТЗ. Передавайте доступ отдельно и выдавайте только те права, которые нужны для проверки или выполнения работы. Перед изменениями также следует согласовать, где будет проводиться проверка, кто создаёт резервную копию и каким способом доработка переносится на рабочий сайт.

Сформулируйте критерии приёмки

Критерии приёмки описывают проверяемый результат. Они отвечают на вопрос: что должно произойти, чтобы пункт считался выполненным? Формулировка «блок выглядит современно» зависит от личной оценки. Проверяемый вариант указывает макет, состав элементов, поведение на нужных разрешениях и результат нажатия кнопки.

GOV.UK определяет критерии приёмки как перечень результатов, по которому команда проверяет, выполнена ли пользовательская задача. Scrum Guide отдельно использует понятие Definition of Done — общее понимание состояния, в котором работа соответствует требованиям к качеству продукта. В обычном ТЗ эти подходы можно применить без специальной терминологии: перечислить наблюдаемые условия для конкретной функции и общие требования к готовому изменению.

• Каждый обязательный сценарий можно повторить по указанным шагам.
• Результат описан через действие системы, а не через субъективную оценку.
• Ошибочные данные и сообщения об ошибках учтены там, где это важно.
• Указаны страницы, роли пользователей и устройства, которых касается проверка.
• Согласовано, кто проводит приёмку и где фиксируются замечания.

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

Проверьте ТЗ перед отправкой разработчику

Прочитайте документ как человек, который впервые видит сайт и не участвовал в обсуждении. Понятно ли ему, где находится нужный раздел, что сейчас происходит, какой результат нужен и что не входит в задачу? Открываются ли ссылки на макеты и материалы? Нет ли противоречий между описанием и критериями приёмки?

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

Готовое ТЗ служит общей точкой отсчёта, но не отменяет обсуждение с разработчиком. Во время технической проверки могут обнаружиться ограничения текущего сайта или более безопасный способ реализации. После согласования обновите документ, чтобы в нём осталась актуальная версия задачи.

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