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