Гарантия на разработку сайта: как отличить ошибку от новой функции

Ошибка и новая задача сравниваются с принятой версией

Ошибка и новая функция — разные задачи. Если привычная форма перестала передавать сообщение, нужно найти причину сбоя и восстановить отправку; если к ней хотят добавить документ и распределение обращений по специалистам, предстоит описать ещё не существовавшее поведение.

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

Я рекомендую сначала записать происходящее, а потом выбирать категорию обращения: спор «это гарантия или доработка» без описания сбоя заставляет стороны защищать названия, хотя они ещё не знают причины. Иногда достаточно уточнить данные формы и получателя, чтобы предмет разговора заметно изменился.

Что изменилось: поведение, требование или окружение

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

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

Изменение внешних условий

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

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

Как описать проблему, чтобы её смогли повторить

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

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

Повторяемость и основание ожидания

Короткий заголовок помогает найти обращение позже. Лучше назвать действие и сбой, чем писать «Сайт работает неправильно». В описании отмечают, возникает ли проблема каждый раз, только на одном устройстве или при определённом наборе данных. Если повторить не удалось, сохраняют обстоятельства первоначального события. Следующая успешная попытка уточняет картину: исполнитель видит, что требуется сравнивать условия нескольких отправок.

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

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

Какие сведения об изменениях стоит собрать

После запуска сайт продолжает меняться. Редактор обновляет материалы, администратор устанавливает версии модулей, почтовый сервис меняет параметры подключения. Для поиска причины нужна короткая хронология: когда форма работала, когда замечена проблема, кто менял настройки и какие действия выполнялись между этими моментами, включая автоматические обновления, о которых редактор мог не знать. Хронология сужает поиск. Каждый её пункт служит поводом для сопоставления, а не готовым объяснением сбоя.

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

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

Доступ для диагностики

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

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

Когда пожелание становится отдельной доработкой

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

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

Раздельная приёмка исправления и улучшения

Я советую разделять восстановление отправки и необязательное улучшение, даже когда они относятся к одной форме: если их можно выполнить независимо, работа над новым дизайном не задержит возвращение существующего способа связи. У них разная приёмка. Исправление сопоставляют с исходным действием, а улучшение — с новой задачей. В записи сохраняют эту границу, чтобы срочный запрос не превратился в бесконечное обсуждение ещё не выбранных полей и текстов. Если же изменения связаны технически, исполнитель объясняет связь и предлагает порядок работ, по которому видно, когда снова начнёт действовать форма.

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

Как закрыть обращение после исправления

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

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

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

Когда возвращаться к улучшениям

К расширению формы стоит переходить, когда описано восстановленное действие и отдельно сформулирован нужный компании новый результат. Для первого разговора с исполнителем достаточно показать нынешний путь обращения и объяснить, что в нём предстоит изменить. С таким сравнением можно обсудить со ШТАБ ИТ диагностику и дальнейшие доработки сайта, сохраняя разные задачи и критерии их приёмки.