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