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