Как составить техническое задание на доработку сайта: примеры понятных требований
Для небольшой доработки сайта не всегда нужен документ на десятки страниц. Но даже короткую задачу важно описать так, чтобы заказчик и разработчик одинаково понимали результат. Разбираем, что включить в техническое задание и как заменить общие пожелания проверяемыми требованиями.
Фраза «сделать форму удобнее» оставляет слишком много вариантов. Один человек ожидает уменьшения количества полей, другой — изменения дизайна, третий — подключения CRM. Пока эти ожидания не согласованы, даже аккуратно выполненная работа может оказаться не тем, что нужно бизнесу.
Техническое задание помогает определить объём доработки, подготовить оценку и договориться о проверке. Его подробность зависит от задачи: замене текста достаточно короткого описания, а для личного кабинета или обмена данными потребуется разобрать несколько сценариев.
Начните с текущей ситуации и цели
Опишите, что происходит сейчас и почему это мешает. Например: «На странице услуги форма содержит восемь обязательных полей. Для первого разговора менеджеру достаточно имени и телефона. Нужно сократить форму, сохранив отправку заявок на рабочую почту». Здесь есть исходная ситуация, желаемое изменение и функция, которую важно сохранить.
Для ошибки добавьте последовательность действий: открыть страницу контактов, заполнить форму, нажать «Отправить». Затем отдельно укажите фактический результат: появляется сообщение об успехе, но письмо получателю не приходит. Приложите адрес страницы и время проверки, чтобы разработчику было проще найти связанное событие.
Необязательно самостоятельно определять причину. Предположение «сломался плагин» может направить проверку по неверному пути. Наблюдаемое поведение, снимок экрана и условия воспроизведения полезнее, чем неподтверждённый технический диагноз.
Если пока непонятно, что именно нужно менять, сначала полезно оценить состояние существующего сайта. По результатам диагностики большую проблему можно разделить на конкретные задачи.
Укажите страницы и границы работы
Запишите точные адреса и расположение элементов. Задача «изменить телефон» может затронуть шапку, подвал, страницу контактов, мобильное меню и ссылки для звонка. Если перечислить эти места заранее, результат будет проще проверить.
- Какие страницы, формы и языковые версии входят в работу?
- Нужно ли изменить поведение на компьютерах и телефонах?
- Кто готовит тексты, изображения и другие материалы?
- Какие существующие данные и интеграции необходимо сохранить?
- Что должно остаться доступным для редактирования через административную панель?
Например, добавление карточек проектов не обязательно включает перенос всего старого портфолио. Согласуйте количество карточек, состав материалов и ответственного за наполнение. Если часть сведений появится позже, определите, можно ли выпускать раздел без неё.
Связанные ограничения лучше записать рядом с задачей. При изменении страницы услуги может быть важно сохранить её адрес, действующие ссылки и передачу источника обращения в CRM. Разработчик должен знать об этом до выбора решения.
Замените общие пожелания ожидаемым поведением
Слова «современно», «удобно» и «быстро» выражают направление, но не определяют готовый результат. Описывайте то, что можно увидеть или воспроизвести. Для визуальных изменений приложите макет либо отметьте нужную область на снимке экрана.
Если используете другой сайт как пример, поясните, что именно подходит: порядок блоков, раскрытие меню, расположение цены или взаимодействие с формой. Ссылка без пояснения оставляет исполнителю слишком много предположений.
| Общее пожелание | Проверяемое требование |
|---|---|
| Упростить форму | Оставить имя и телефон. Телефон обязателен. После отправки показать подтверждение и передать заявку получателю. |
| Исправить мобильную версию | На согласованных страницах меню и форма доступны, а закреплённая панель не перекрывает кнопку отправки. |
| Добавить портфолио | Карточка содержит изображение, название и описание. Нажатие открывает страницу проекта. Материалы редактируются в административной панели. |
Таблица задаёт основу обсуждения. Для каждой строки ещё могут понадобиться адреса страниц, макет, форматы данных и условия проверки. Не стоит пытаться вместить все подробности сложной задачи в одно предложение.
Пример задания на изменение формы
Предположим, на странице ремонта оборудования нужно сократить форму обращения. Задание может выглядеть так:
- Оставить поля «Имя» и «Телефон». Телефон обязателен, имя — нет. Текст кнопки: «Отправить заявку».
- Согласовать допустимые форматы телефона с учётом клиентов компании. Проверить ручной ввод, вставку и исправление номера.
- Если обязательное поле не заполнено, показать рядом с ним пояснение. Остальные введённые данные сохранить.
- После успешного приёма обращения показать подтверждение. При ошибке отправки предложить повторить попытку и сохранить заполненные поля.
- Передавать имя, телефон и адрес страницы в существующий канал получения заявок. Сохранить текущую защиту от нежелательных отправок.
Отдельно укажите получателя заявок и какие поля должны приходить в письмо или CRM. Если требуется новый канал доставки, это самостоятельная часть работы: нужно определить доступы, формат передачи и поведение при недоступности внешней системы.
Не требуйте сообщение об успехе только потому, что человек нажал кнопку. Согласуйте, какое событие считается успешным приёмом заявки и как проверить её фактическое получение. Это помогает избежать красивой формы, которая теряет обращения.
Опишите ошибки и исключения
Кроме успешного сценария, разберите ситуации, в которых действие не удаётся завершить. Для поиска это отсутствие результатов, для загрузки файла — неподходящий формат, для CRM — ошибка передачи данных. Пользователь должен понимать, что произошло и что можно сделать дальше.
Например: «Если файл превышает согласованный размер, загрузка не начинается. Рядом с полем показывается допустимый размер. Остальные данные формы сохраняются». Разработчик получает конкретное поведение, а заказчик — способ проверить его.
Для интеграции обсудите повторную отправку и возможные дубликаты. Если клиент дважды нажал кнопку или система повторила запрос после сбоя, важно заранее решить, как обрабатывается такое обращение. Нужная реализация зависит от возможностей используемой CRM.
Согласуйте критерии приёмки
Критерии приёмки отвечают на вопрос: как убедиться, что задача выполнена? Они должны следовать из требований. Для формы это проверка полей, сообщений об ошибках, успешного получения заявки и работы на согласованных устройствах.
Запишите набор страниц и браузеров, на которых будете проверять результат. Вместо обещания «работает везде» полезнее согласовать поддерживаемые условия, опираясь на посетителей сайта. Уточните, кто выполняет проверку и где фиксирует замечания.
Если задача касается скорости, определите страницы, способ измерения и условия сравнения. На показатели влияют устройство, сеть и состояние кеша. Одна удачная проверка не подтверждает улучшение для всех посетителей, поэтому заранее согласуйте, какие измерения будут основанием для приёмки.
Зафиксируйте внедрение и порядок изменений
Договоритесь, где разработчик покажет результат: на тестовой копии или в согласованном разделе. Для изменений, затрагивающих важные функции или данные, определите порядок резервного копирования и возврата к предыдущему состоянию.
Новые пожелания записывайте отдельно и уточняйте их влияние на срок и стоимость. Например, добавление загрузки фотографии к уже согласованной форме меняет объём работы: появляются ограничения файлов, хранение и дополнительные проверки.
Пароли не включайте в текст задания, который пересылается нескольким исполнителям. Согласуйте передачу доступов отдельно и предоставляйте их в объёме, необходимом для работы. В самом документе достаточно указать, к каким частям проекта потребуется доступ.
Короткий шаблон для одной доработки
- Задача: что требуется изменить и для чего.
- Страница или раздел: адрес и расположение элемента.
- Сейчас: фактическое поведение и проблема.
- Нужно: ожидаемый результат и важные исключения.
- Материалы: тексты, изображения, макет и ответственный за подготовку.
- Ограничения: данные и функции, которые необходимо сохранить.
- Приёмка: действия и условия проверки результата.
- Внедрение: порядок согласования, публикации и проверки на рабочем сайте.
Для небольшой задачи заполните эти пункты несколькими предложениями. Если описание становится слишком большим, разделите работу на самостоятельные части с понятным результатом. Так проще оценивать приоритеты и принимать доработки по мере готовности.