Як писати повідомлення про застарілість електронної пошти англійською мовою

Електронна пошта з повідомленням про застарілий продукт - це обіцянка щодо майбутнього, і вона повинна бути достатньо конкретною, щоб зайнятий інженер, який її читає, міг негайно сказати, чи він зачеплений і що робити далі. Неясне повідомлення (« ця можливість буде скоро вилучена ») генерує набагато більше квитків підтримки, ніж точне повідомлення. У цьому підручнику описано структуру англійської мови для написання повідомлення про застарілий код, за яким користувачі будуть діяти.

Ключовий словник

** Дата застаріння ** — дата, коли функціональність буде позначено як застарілу і офіційно більше не рекомендується, відмінна від дати вилучення, коли функціональність перестане працювати повністю. “Дата зникнення — сьогодні, це означає, що стара кінцева точка все ще працює, але більше не рекомендується — дата вилучення, коли вона перестане працювати, — через три місяці.”

** Дата вилучення (дата заходу сонця) ** — конкретна дата, до якої вилучена функціональність буде вилучено або перестане функціонувати, вказуємо цю дату як тверду, а не як неясну.

• “Дата вилучення — 15 березня 2027 року — після цієї дати, запити до старої кінцевої точки повертатимуть відповідь 410 Gone.” *

** Захищена аудиторія ** — чіткий опис тих, на кого впливає зниження цінності, щоб читачі могли швидко самостійно визначити, чи є електронна пошта для них актуальною. “Це повідомлення впливає на будь-яку інтеграцію, що все ще викликає кінцеву точку /v1/users безпосередньо — якщо ви вже перейшли на /v2/users, ніяких дій не потрібно.”

** Шлях міграції ** — конкретний замінник і кроки, які слід виконати для переходу до нього, ідеально, якщо буде наведено посилання на документацію або приклад коду. “Шлях міграції простий: замініть /v1/users на /v2/users і оновіть поле id на userId — дивіться посібник з міграції, посилання на який наведено нижче, щоб побачити повний опис відмінностей.”

** Частота нагадування з підвищенням ** — серія сповіщень, які надсилаються зі зростаючою частотою, коли наближається дата вилучення, щоб повідомлення не було пропусчено у одній електронній пошті. “Ми надсилаємо це як перше з трьох повідомлень - це зараз, наступне через місяць і останнє нагадування за тиждень до видалення.”

Звичайні фрази

• «Це повідомлення актуальне для вас, якщо [конкретна умова] — якщо ні, то не потрібно жодних дій»
• « Дата застаріння — [дата]; дата вилучення, коли цей параметр перестане працювати повністю, — [дата]. »
• «To migrate, replace [old thing] with [new thing] — see [link] for full details.» (англійською)
• «Це повідомлення [1 з 3] — ви отримаєте додаткові нагадування, коли наближається дата вилучення»
• “Якщо у вас є питання або вам потрібно більше часу, будь ласка, зв’яжіться з [контакт] до [дата].”

Приклади висловлювань

Відкриття повідомлення про застарілу версію з чистим фільтром аудиторії:

• “Ця електронна пошта є важливою для вас, оскільки згідно з нашими записами, ваш обліковий запис здійснював виклики API до кінцевої точки /v1/reports протягом останніх 30 днів. Якщо ви вже перейшли на /v2/reports, ви можете проігнорувати це повідомлення. *

Вказування точних дат:

• “Кінечна точка /v1/reports є застарілим з сьогоднішнього дня і буде вилучено 1 вересня 2026 року. Між цим і тоді, він буде продовжувати працювати, але поверне заголовок попередження про застарівання на кожну відповідь. ”*

Надання конкретного шляху міграції:

• “Щоб перенести, оновіть інтеграцію, щоб замість цього викликати /v2/reports, і зауважте, що формат відповіді тепер вкладає результати під ключ data, а не повертає порожній масив. Повний приклад до і після доступний в нашому посібнику з міграції, посилання нижче. “*

Професійні поради

• Відокремте ** дату застарівання ** від ** дати вилучення ** явно — об’ єднання цих даних залишить читачів у невідомості щодо того, чи працює щось сьогодні, чи вже пошкоджено.
• Відкрити з ** зачепленими аудиторіями **, щоб читачі, які не зачеплені, могли негайно припинити читання, замість того, щоб читати всю електронну пошту, щоб дізнатися про це.
• Завжди включайте конкретний ** шлях міграції **, ідеально з прямим посиланням або прикладом коду — повідомлення про знищення без такого повідомлення створює тривогу, не даючи нікому можливості зробити наступний крок.
• Згадайте про ** частоту нагадування **, щоб адресати знали, що це не останній шанс діяти — це зменшить паніку, але все одно надасть відчуття невідкладності, оскільки наближається дата вилучення.

Практичні вправи

1. Напишіть два речення, які відкривають повідомлення про застарілий код, і які чітко вказують, хто має на це право.
2. Напишіть одне речення, яке відрізняє дату застарівання від дати вилучення.
3. Напишіть речення, у якому буде описано конкретний шлях переходу до гіпотетичної застарілої можливості.

Національний склад населення: Перепис населення 2001 року

Написання повідомлення про знищення не просто про те, що щось зникає; це про управління очікуваннями, мінімізації перешкод і демонстрації поваги до ваших користувачів. Для не-рідних носіїв англійської мови, тонкі зміни в словниковому запасі і фразування можуть бути особливо викликом. Це не просто * сказати * комусь, що функція зникне, але вести їх через перехід з точністю. Розглянемо різницю між словами « Ця функціональність більше не підтримується » і « Ми відмовляємося від цієї функціональності ». Останнє слово підтверджує залежність користувача від цієї функціональності і надає контекст для зміни.

Ключовим аспектом, на якому варто зосередитися, є використання мови, яка передає * чутливість до часу * без звучання тривожним або вимогливим. Такі фрази, як « заплановане знищення », « заплановане вилучення » або « майбутні зміни », загалом, є кращими за такі терміни, як « відкинуто » або « припинено ». Ці останні слова мають сильнішу, часто негативну, конотацію і можуть сприйматися як відверта відмова. Пам’ ятайте, що користувачі залежать від вашої системи; їм потрібно дати достатньо часу для адаптації — не поспішати з негайними діями. Також важливо чітко вказати * чому * зміна відбувається. Просто «Ми оновлюємо нашу платформу» недостатньо. Надання короткого пояснення, наприклад, «для поліпшення продуктивності і безпеки» або «як частина нашого постійного зобов’язання модернізувати наші послуги», додає прозорості і створює довіру. Зверніть увагу також і на структуру речення — довші речення можуть бути складними для деяких читачів; розбиття їх на коротші, легше засвоювані фрази покращує ясність.

Давайте розглянемо практичний приклад. Уявіть, що ви пишете повідомлення Slack, щоб повідомити про майбутнє видалення старої кінцевої точки API. Просте «Старий API йде» не зможе його розірвати. Замість цього ви можете сказати: « Привіт, команда, просто повідомлення, що ми відмовляємося від кінцевої точки /legacy_data на [Дата]. Ми переходимо на новий формат даних для покращення продуктивності і стабільності. Будь ласка, оновіть до цього часу ваші інтеграції — документацію можна знайти за адресою: [Посилання]». Зауважте, що у цьому повідомленні вказано контекст, вказано дату, наведено користувачів до додаткових відомостей і використано більш доступний тон (« Привіт, команда »). Аналогічно, в описі Pull Request, замість «Видалення функції X», ви можете написати «Рефакторинг інтерфейсу користувача для використання нового потоку даних — відмова від старої кінцевої точки /legacy_data як частини цього переходу»

І, нарешті, завжди будь готовий до питань. Передбачте, що користувачі можуть запитати про потенційний вплив на їх робочі потоки або про те, чи потрібно їм негайно вносити зміни. Наявність легкодоступного каналу часто задаваних питань або підтримки є безцінним. Проявлення співпереживання і надання допомоги може значно полегшити перехід і продемонструвати вашу прихильність до успіху користувача.