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