How to Write an Out-of-Office Handover Note in English

Записка про передачу поза офісом відрізняється від повного документа про передачу проекту — вона коротша, більш термінова і зосереджена виключно на тому, що може піти не так, коли ви не на зв’ язку. Хороший спосіб дозволяє вашому колегі діяти впевнено, не повідомляючи вас про відпустку; поганий спосіб або занадто мало говорить (оставлює їх у впевненості), або занадто багато (заховає терміново необхідні елементи у шумі).

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

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

• “Я визначив пріоритети за ймовірністю: конвеєр розгортання зазнавав невдач двічі цього місяця, отже це перший пункт, тоді як скрипт звітів, який ніколи не порушувався, рідко згадується.” *

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

** Назва шляху ескалації ** — надання резервного контакту для ситуацій, які надто невідкладні, щоб чекати, на випадок, якщо колега, який прикриває, також не зможе розв’ язати ситуацію. “Я назвав шлях ескалації: якщо щось не так, що [колега] не може впоратися, наступним контактом буде наш технічний керівник, а не я — я справді не буду перевіряти повідомлення.”

** Встановлення очікувань щодо вашої доступності ** — бути чітким і чесним щодо того, наскільки ви насправді доступні, а не нечітким « Я спробую зареєструватися », що створює неоднозначність. “Я поставив чіткі очікування щодо доступності: у мене не буде телефонного сигналу протягом перших чотирьох днів, а після цього, тільки справжні надзвичайні ситуації повинні до мене дістатися.”

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

• «Ось що найімовірніше з’явиться, поки я не буду, в порядку пріоритету»
• “Щодо будь-чого нижче [порогу], не соромтеся вирішувати без мене.”
• “Якщо це терміново і [колега] не може допомогти, наступним контактом буде [ім’я].”
• «Я буду повністю оффлайн до [дата] — будь ласка, не чекайте на мене нічого»
• «Все інше може почекати, поки я не повернуся на [дати]; я підніму це перше.»

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

Відкриття нотатки з обсягом та датами передачі: “Я буду вдома з 8-го по 19-е липня, без доступу до телефону протягом першого тижня. Ця записка описує, що, ймовірно, з’явиться і з ким зв’язатися для кожного». *

Спочатку визначається пріоритет найімовірнішої проблеми:

• “Найбільш ймовірно, що це станеться: нічне завдання ETL нещодавно не працювало належним чином — якщо воно зазнає невдачі, його можна виправити, перезапустивши його вручну з інтерфейсу Airflow; інструкції наведено нижче. Це траплялося три рази за останній місяць.»*

Ясно визначити право прийняття рішення:

• “Ви маєте повні права на схвалення будь- якого квитка на підтримку, який не передбачає повернення коштів на суму понад $200 — не потрібно чекати на мене щодо рутинних речей.” *

Закриття з чистим передаванням всіх нерозв’ язаних проблем: “Єдиний відкритий пункт, який я залишаю в середині польоту, це перегляд контракту з постачальником - це не спекотно, і я підніму його знову в день, коли повернуся.”

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

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

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

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

Науковий ступінь бакалавра: англійська мова, вивчення мови

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

Часта помилка - це зосереджуватися лише на тому, * що * ви робили, не пояснюючи * чому *. Розглянемо цей сценарій: розробник, Алекс, працював над зневадженням особливо складної проблеми у модулі обробки платежу. У стандартній ноті про передачу він може просто написати « Виправлено помилку у модулі платежу ». Проте, більш ефективним підходом буде написання « Виправлено постійну помилку, яка спричиняла невдачі транзакцій під час годин пік — визначено умову переслідування, яку спричинили одночасні виклики API. » Це включало впровадження механізму черги для зменшення проблем одночасності і додавання журналювання для поліпшення моніторингу. Зауважте додавання контексту: * проблема *, її потенційний вплив (незавершені транзакції), * причина * (стан гонки) і рішення (черга, журналювання). Це демонструє технічне розуміння і дозволяє отримувачу швидко зрозуміти ситуацію. Аналогічно, під час написання повідомлення Slack, у якому оголошується про вашу відсутність, уникайте нечітких вказівок, наприклад, « Захворів ». Замість цього спробуйте « Взяти відпустку з особистих причин. Я задокументував ключові завдання та оновлення щодо проекту Фенікс у ноті про передачу — будь ласка, дайте мені знати, якщо у вас є які-небудь терміново необхідні питання»

Інша область, на якій варто зосередитися, це формулювання запитів на допомогу. Замість того, щоб сказати « Потрібна допомога з X », що може звучати вимогливо, використовуйте ввічливу і активну мову. Наприклад, замість «Чи може хтось переглянути мій код?», Спробуйте «Я завершив початкову реалізацію можливості Y і був би вдячний за короткий перегляд коду, перш ніж я продовжу далі. Зокрема, я б цінував зворотній зв’язок щодо інтеграції з існуючим API. “Це демонструє, що ви шукаєте співпрацю і відкриті до конструктивної критики. Пам’ ятайте, що ваш колега, який виконує роль прикриття, ймовірно, має багато обов’ язків; якщо ви сформулюєте ваші потреби як запити на * зворотній зв’ язок * або * допомогу *, а не як вимоги, він буде більш сприйнятливим.

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