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